Introduction

YAML files are the configuration files for the pods.
Each YAML file will have the apiVersion, kind, metadata, and spec fields.
These are required fields.

apiVersion: This is the version of the Kubernetes API you're using to create the objects. Depending on what we are trying to create, we must use the right API version.

kind: The type of object that we are trying to create.
For example: Pod, ReplicaSet, or DeploymentSet.

metadata: Information about the object that we are trying to create.

spec: The last section in the configuration file is the specification section, written as spec. Depending on the object we are going to create, this is where we provide additional information to Kubernetes about that object.

This will be different for various objects, so it's important to understand or refer to the documentation to get the right format for each. Since we are only creating a pod with a single container, we need to ensure we use the correct format.

#To create the pod we use command
kubectl create -f pod-definition.yml

To get the pods

kubectl get pods

Replication Controllers and Replica Sets

The replication controller helps us run multiple instances of a pod in a single container, providing higher availability. If a pod goes down, it will automatically bring up another pod. The replication controller also works as a load balancer. When demand increases, it creates replicas of the current pods. Similarly, it scales down the number of pods when requests decrease.

How to implement replication

Using Replication Controller

apiVersion: v1
kind: ReplicationController
metadata:
    name: myapp-rc
    labels:
        app: myapp
        type: front-end
spec:
    template:
        metadata:
            name: myapp-pod
            labels:
                app: myapp
                type: forntend
        spec:
            containers:
                - name: nginx-container
                  image: nginx
    replicas: 3

YAML configuration sets up a Kubernetes ReplicationController named myapp-rc to manage three replicas of a Pod named myapp-pod. Each Pod contains a single container running the nginx image. The ReplicationController ensures that exactly three instances of the nginx container are always running, providing resilience and load balancing for the application.

Using Replica Set

apiVersion: v1
kind: ReplicationSet
metadata:
    name: myapp-rc
    labels:
        app: myapp
        type: front-end
spec:
    template:
        metadata:
            name: myapp-pod
            labels:
                app: myapp
                type: forntend
        spec:
            containers:
                - name: nginx-container
                  image: nginx
    replicas: 3
    selector: 
        matchLabels:
            type: front-end

YAML configuration sets up a Kubernetes ReplicaSet named myapp-rc, which ensures that three replicas of a Pod named myapp-pod (containing a container running the nginx image) are always running. The ReplicaSet uses the selector to manage Pods labeled with type: front-end.

Lables and Selector

Let us look at a simple scenario.

Say we deployed three instances of our front end web application as three parts.

We would like to create a replication controller or replica set to ensure that we have three active parts at any time. And yes, that is one of the use case of replica sets.

You can use it to monitor existing parts if you have them already created as it is in this example. In case they were not created, the replica set will create them for you.

The role of the replica set is to monitor the pods and if any of them were to fail deploy new ones. The replica set is in fact a process that monitors the parts.

Now how does the replica set know what parts to monitor? There could be hundreds of other parts in the cluster running different applications.

This is where labeling our pods during creation comes in handy. We could now provide these labels as a filter for replica set. Under the selector section we use the match labels filter and provide the same label that we used while creating the pods.

This way the replica set knows which pods to monitor.

How to scale the replica set

1. By updating the "replicas" value the configuration file.

2. By using scale command

kubectl scale --replicas=6 -f replicaset-definition.yml

Deployments

Deployment which is a Kubernetes object that comes higher in the hierarchy, the deployment provides us with the capability to upgrade the underlying instances seamlessly using rolling updates. Undo changes and pause and resume changes as required.

So how do we create a deployment.

apiVersion: apps/v1
kind: Deployment
metadata:
    name: myapp-rc
    labels:
        app: myapp
        type: front-end
spec:
    template:
        metadata:
            name: myapp-pod
            labels:
                app: myapp
                type: forntend
        spec:
            containers:
                - name: nginx-container
                  image: nginx
    replicas: 3
    selector: 
        matchLabels:
            type: front-end

Updates and Rollbacks in Deployment

When you first create a deployment, it triggers a rollout, a new rollout creates a new deployment revision.
Let's call it revision one.In the future when the application is upgraded, meaning when the container version is updated to a new one, a new rollout is triggered and a new deployment revision is created named Revision two.

This helps us keep track of the changes made to our deployment and enables us to roll back to a previous version of deployment if necessary.

How we update and push rollback

Recreate Strategy

The Recreate strategy involves terminating all existing Pods before creating new ones. This approach ensures that there are no overlapping versions of the application running simultaneously. It’s straightforward but can lead to downtime.

Workflow:

1. Terminate Old Pods: All existing Pods managed by the Deployment are stopped.

2. Create New Pods: New Pods with the updated specifications are created and started.

Advantages:

• Simplicity: The process is simple and easy to understand.

• Consistency: Only one version of the application runs at any given time.

Disadvantages:

• Downtime: There is a period when no instances of the application are running, which can be problematic for production environments requiring high availability.

Use Case:

• Suitable for applications where downtime is acceptable or where it’s crucial to ensure only one version of the application is running at any time.

Rolling Update Strategy

The Rolling Update strategy updates Pods incrementally. This approach allows for zero or minimal downtime by gradually replacing old Pods with new ones.

Workflow:

1. Incremental Update: Pods are updated in a controlled manner. A few Pods are terminated and replaced with new ones at a time, according to the specified parameters (like maxUnavailable and maxSurge).

2. Health Checks: Each new Pod undergoes health checks to ensure it’s running correctly before the next set of Pods is updated.

Parameters:

• maxUnavailable: Specifies the maximum number of Pods that can be unavailable during the update process. This ensures that there is always a minimum number of Pods available to serve traffic.

• maxSurge: Specifies the maximum number of Pods that can be created above the desired number of Pods during the update process. This allows the creation of new Pods before the old ones are terminated, ensuring extra capacity during the update.

Advantages:

• Zero or Minimal Downtime: By gradually replacing Pods, the application remains available throughout the update process.

• Rolling Back: If an issue is detected during the update, the process can be paused and rolled back to the previous stable state.

Disadvantages:

• Complexity: The process is more complex compared to the Recreate strategy.

• Resource Usage: Requires additional resources during the update process (especially with maxSurge).

Use Case:

• Ideal for production environments where maintaining application availability is crucial and downtime is not acceptable.

update the configuration and apply the following command

kubectl apply -f deployment-definition.yml

Let's look at how a deployment performs an upgrade under the hood.

Upgrade

When a new deployment is created, say, to deploy five replicas, it first creates a replica set automatically, which in turn creates the number of pods required to meet the number of replicas.
When you upgrade your application, the Kubernetes deployment object creates a new replica set under the hood and starts deploying the containers there at the same time taking down the pods in the old replica set following a rolling update strategy.

Rollback

kubectl rollout undo deployment/<deployment-name>