Hello again! Now in this post we’ll cover some of the next basic Kubernetes component and concept that you need to know before becoming Kubernetes Administrator. In this article as you know from previous article, we’re going to discuss some of the basic object in Kubernetes. This object in most of the case are always used, in order for your application can be hosted in Kubernetes.

Okay let’s begin!

Kubernetes has it’s own file format in YAML in order to create an object in very specific way, it’s called Manifest YAML file. So after this, you’ll see a bunch of configuration file that must be placed on one file in YAML format. It’s similar to the blue print of an object. The indentation here’s using space and very sensitive to that, so be careful when you create it to avoid error in object creation.

1. Pod

Pod is contains one container or more. Also it is the smallest unit on Kubernetes Cluster component. Tips for writing the manifest file for pod is start from apiVersion, kind, metadata and spec. The image field in the container section we get from a default public container image registry Dockerhub. These are some of the example of pod.yaml for nginx pod :

apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:
    app: nginx
    tier: frontend
spec:
  containers:
  - name: nginx
    image: nginx

Save it. Then to create the pod from pod.yaml file just use:

kubectl create -f pod.yaml

Labels are just key=value that we can assign anything to it. We’ll gonna discuss label on the next article.

2. ReplicaSet

nginx 3 replicaset example logic arch

Replica set is the process to create multiple pod in order to make the application have a high availability performance. Once some pod are crash, replica set will make another pod for you. These are some example of how to write a basic and proper manifest file to create busy box application in pod-rs.yaml :

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: new-replica-set
spec:
  template:
    metadata:
      labels:
        app: busybox
    spec:
      containers:
      - name: busybox-pod
        image: busybox
  replicas: 4
  selector:
    matchLabels:
      app: busybox

You need to make a template column to make Replica set know what are the pod spec that we want to apply. We can scale it up or down using command :

kubectl scale —replicas=5 pod-rs.yaml

Anyways there is another concept that very similar to Replica set, which is Replication Controller, in terms of functionality it’s all same as Replica set. But the major different is in Replication Controller (older feature) has no selector, which prevent Replica to know what pod that you want to scale.

3. Deployment

Deployment has a such massive feature to make the application is ready for production. In deployment we create pod’s replica, rolling update for the version of your application, rolling back the update, if we want to change something we can pause and resume the deployment.

This is a logical image for where deployment at in Kubernetes Cluster:

The manifest file for Deployment is similar with Replica set, it’s just different in kind column, here are the example of deploying busy-box application:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: new-deployment
spec:
  template:
    metadata:
      labels:
        app: busybox
    spec:
      containers:
      - name: busybox-pod
        image: busybox
  replicas: 4
  selector:
    matchLabels:
      app: busybox

4. Namespace

Namespace is separate the processes of each Kubernetes component that we what to assign it differently. We also need to know that we can set the resource quota for each space so it doesn’t cross the border line. And when it comes to DNS, the way we connect for instance the databases into the service inside the default namespace, we use:

mysql.connect("db-service")

But if it inside the dev namespace, we have to specify the service DNS:

mysql.connect("db-service.dev.svc.cluster.local")

with the db-service as service name, dev as namespace’s name, svc as service, and cluster.local is the domain name.

Normally to be more organize, we assign the namespace under name’s metadata label:

apiVersion: v1
kind: Pod
metadata:
  name: nginx
	namespace: dev
  labels:
    app: nginx
    tier: frontend
spec:
  containers:
  - name: nginx
    image: nginx

Context

We can change the workspace from default namespace to another namespace that we want using context. So we don’t necessarily have to write the namespace while we assign something using kubectl.

For example, from : kubectl get pod -n kube-system -> to: kubectl get pod (and showing kube system namespace’s pod)

The way to do it just use:

kubectl config set-context --current --namespace=kube-system

5. Kubernetes Usage Convention

Using the kubectl run command can help in generating a YAML template. And sometimes, you can even get away with just the kubectl run command without having to create a YAML file at all. For example, if you were asked to create a pod or deployment with specific name and image you can simply run the kubectl run command.

Use the below set of commands and try the previous practice tests again, but this time try to use the below commands instead of YAML files. Try to use these as much as you can going forward in all exercises

Reference (Bookmark this page for exam. It will be very handy):

https://kubernetes.io/docs/reference/kubectl/conventions/

Create an NGINX Pod

kubectl run nginx --image=nginx

Generate POD Manifest YAML file (-o yaml). Don’t create it(–dry-run)

kubectl run nginx --image=nginx --dry-run=client -o yaml

Create a deployment

kubectl create deployment --image=nginx nginx

Generate Deployment YAML file (-o yaml). Don’t create it(–dry-run)

kubectl create deployment --image=nginx nginx --dry-run=client -o yaml

Generate Deployment YAML file (-o yaml). Don’t create it(–dry-run) with 4 Replicas (–replicas=4)

kubectl create deployment --image=nginx nginx --dry-run=client -o yaml > nginx-deployment.yaml

Save it to a file, make necessary changes to the file (for example, adding more replicas) and then create the deployment.

kubectl create -f nginx-deployment.yaml

OR

In k8s version 1.19+, we can specify the –replicas option to create a deployment with 4 replicas.

kubectl create deployment --image=nginx nginx --replicas=4 --dry-run=client -o yaml > nginx-deployment.yaml

6. Imperative vs Declarative

When you manage the object in Kubernetes using kubectl like above example, you’re using the Imperative way. There is some problem with it, like:

  • Commands do not integrate with change review processes.
  • Commands do not provide an audit trail associated with changes.
  • Commands do not provide a source of records except for what is live.
  • Commands do not provide a template for creating new objects.

So here is also another way, that is declarative way. Advantages compared to imperative object configuration:

  • Changes made directly to live objects are retained, even if they are not merged back into the configuration files.
  • Declarative object configuration has better support for operating on directories and automatically detecting operation types (create, patch, delete) per-object.

This is a command for creating object from a single file:

kubectl apply -f post-app.yaml

This is a command for create object from a one directory:

kubectl apply -f frontend/

So I think that’s all for this article. I hope you can understand it better and eager to know more about Kubernetes concept. In the next post we’ll learn about Service, some of the important concept too in order to create connectivity within a cluster.

See you !

If you want to deep dive more into this material please checkout Kubernetes Object Management | Kubernetes.

Last modified: April 18, 2022

Author

Comments

Write a Reply or Comment

Your email address will not be published.