Kubernetes-part-6

Ensuring Application Availability with ReplicaSets

It helps keep your application running by ensuring the correct number of pod replicas are always available, making it essential for scaling and reliability. ReplicaSets are often managed by Deployments, which provide more features like rolling updates. When you create a Deployment, it automatically creates a ReplicaSet for managing pod replicas.

Example:

If you set a ReplicaSet to have 3 pods, and one pod stops, the ReplicaSet will automatically create a new pod so that there are always 3 running.

• Defining a ReplicaSet: YAML Example

    apiVersion: apps/v1
    kind: ReplicaSet
    metadata:
      name: nginx-rs
      labels:
        app: nginx
    spec:
      replicas: 3
      selector:
        matchLabels:
          app: nginx
      template:
        metadata:
          labels:
            app: nginx
        spec:
          containers:
          - name: nginx
            image: nginx:latest
            ports:
            - containerPort: 80
  

  This YAML file tells Kubernetes to create 3 identical pods running the nginx web server. It will automatically make sure there are always 3 pods running, so if one stops, Kubernetes will start another. Each pod runs on port 80, and all are labeled with app: nginx for identification.

• Real-Time watch and monitor the status of your pods

    kubectl get pod -w
  

• To see the ReplicaSet present

    kubectl get rs
  

• To delete a replicaSet and all its pod

    kubectl delete rs <rs-file>
  

Understanding Propagation Policies in Kubernetes

It is used to control how resources are deleted, especially when dealing with related resources like ReplicaSets and their pods. It decides whether the resources created by a ReplicaSet (like pods) should be deleted right away or left running when the ReplicaSet is removed.

Types of Propagation Policies:

• Foreground: Pods are deleted first, then the ReplicaSet.

    kubectl delete replicaset nginx-rs --cascade=foreground
  

  Another way: using kubectl proxy with a curl command to delete a ReplicaSet using the Kubernetes API and specify a propagationPolicy

  • Start the Kubernetes Proxy

  kubectl proxy --port=8080
  

  This command starts a local proxy that allows you to interact with the Kubernetes API at localhost:8080 without needing to authenticate with tokens.

  kubectl proxy --port=8080
  curl -X DELETE 'http://localhost:8080/apis/apps/v1/namespaces/default/replicasets/nginx-rs' \
       -d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Foreground"}' \
       -H "Content-Type: application/json"
  

• Background: ReplicaSet is deleted first, pods are deleted later.

    kubectl delete replicaset nginx-rs --cascade=background
  

  Another way: using kubectl proxy with a curl command to delete a ReplicaSet using the Kubernetes API and specify a propagationPolicy

  • Start the Kubernetes Proxy

  kubectl proxy --port=8080
  

  This command starts a local proxy that allows you to interact with the Kubernetes API at localhost:8080 without needing to authenticate with tokens.

  curl -X DELETE 'http://localhost:8080/apis/apps/v1/namespaces/default/replicasets/nginx-rs' \
       -d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Background"}' \
       -H "Content-Type: application/json"
  

• Orphan: ReplicaSet is deleted, but the pods remain running.

    kubectl delete replicaset nginx-rs --cascade=orphan
  

  Another way: using kubectl proxy with a curl command to delete a ReplicaSet using the Kubernetes API and specify a propagationPolicy

  • Start the Kubernetes Proxy

  kubectl proxy --port=8080
  

  This command starts a local proxy that allows you to interact with the Kubernetes API at localhost:8080 without needing to authenticate with tokens.

  curl -X DELETE 'http://localhost:8080/apis/apps/v1/namespaces/default/replicasets/nginx-rs' \
       -d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Orphan"}' \
       -H "Content-Type: application/json"
  

Mastering Kubernetes Deployments

It is used to manage and automate the lifecycle of applications running in pods. It provides more advanced features than a ReplicaSet, such as rolling updates, rollback capabilities, and scaling.

• Creating and Managing Deployments with YAML

    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: nginx-deployment
    spec:
      replicas: 3
      selector:
        matchLabels:
          app: nginx
      template:
        metadata:
          labels:
            app: nginx
        spec:
          containers:
          - name: nginx
            image: nginx:1.16.1
            ports:
            - containerPort: 80
  

    kubectl apply -f deployment.yaml
  

• Get Deployment Status

    kubectl get deployments
  

• Scaling Deployments for Optimal Performance

    kubectl scale deployment nginx-deployment --replicas=5
  

• Updating Deployment Images

    kubectl set image deployment/nginx-deployment nginx=nginx:1.17.0
  

• Checking Deployment Status

    kubectl rollout status deployment/nginx-deployment
  

• Checking Rollout History

    kubectl rollout history deploy/nginx-deployment
  

• View Specific Revision

    kubectl rollout history deploy/nginx-deployment --revision=2
  

• Rolling Back to Previous Deployment Revisions

    kubectl rollout undo deployment/nginx-deployment --to-revision=1
  

• Pause a Rollout

    kubectl rollout pause deployment/nginx-deployment
  

• Edit Deployment Directly

    kubectl edit deployment/nginx-deployment
  

Recreate Strategy: Minimizing Downtime During Updates

With this strategy, when a new version of an application is deployed, Kubernetes first deletes all existing pods before creating the new ones. This can cause some downtime because there will be a gap between the old pods being terminated and the new ones starting.

Example YAML for Recreate Strategy

apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo-deployment
spec:
  replicas: 3
  strategy:
    type: Recreate
  selector:
    matchLabels:
      app: demo
  template:
    metadata:
      labels:
        app: demo
    spec:
      containers:
      - name: demo
        image: nginx:latest
        ports:
        - containerPort: 80

kubectl apply -f <recreate-yml-file>

kubectl set image deploy/demo-deployment demo=nginx:14.0

Probes: Ensuring Pod Health and Readiness

This is used to check the health of pod. They help Kubernetes know when a pod is ready to start serving traffic or if it’s still alive and functioning correctly. If a probe fails, Kubernetes can take action like restarting the pod

Types of probes in Kubernetes

• Liveness Probe: Checks if the pod is alive. Restarts it if it’s stuck.

• Readiness Probe: Checks if the pod is ready to serve traffic. Stops sending traffic if it’s not ready.

• Startup Probe: Gives the pod time to fully start. Ensures it isn’t marked as failed too early.

Implementing Probes in Deployment YAML

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:latest
        ports:
        - containerPort: 80
        livenessProbe:
          httpGet:
            path: /
            port: 80
          initialDelaySeconds: 15
          timeoutSeconds: 2
          periodSeconds: 5
          failureThreshold: 3
        readinessProbe:
          httpGet:
            path: /
            port: 80
          initialDelaySeconds: 5
          timeoutSeconds: 2
          periodSeconds: 5
          successThreshold: 1
          failureThreshold: 3
        startupProbe:
          httpGet:
            path: /
            port: 80
          initialDelaySeconds: 10
          periodSeconds: 5
          failureThreshold: 10

kubectl apply -f <yaml-file>

• Liveness Probe: Checks if the container is still running. If it fails 3 times (every 5 seconds), the container is restarted.

• Readiness Probe: Checks if the container is ready to serve traffic. If it fails 3 times, the container won’t receive traffic until it passes.

• Startup Probe: Gives the container 10 chances (every 5 seconds) to start before other probes begin checking it.

Blue-Green Deployment: Minimizing Downtime and Risk

• A strategy for deploying applications that minimizes downtime and risk.

• It involves running two environments: Blue and Green

• Blue represents the current version of the application that's live and handling user traffic.

• Green is a new version of the application that is being prepared for release.

Example: You have an application running with version 1 (Blue) and want to deploy version 2 (Green)

• Current Deployment (Blue) : This is the live version

    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: myapp-blue
    spec:
      replicas: 2
      selector:
        matchLabels:
          app: myapp
          version: blue
      template:
        metadata:
          labels:
            app: myapp
            version: blue
        spec:
          containers:
          - name: myapp
            image: myapp:1.0
            ports:
            - containerPort: 80
  

• New Deployment (Green): This is the new version

    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: myapp-green
    spec:
      replicas: 2
      selector:
        matchLabels:
          app: myapp
          version: green
      template:
        metadata:
          labels:
            app: myapp
            version: green
        spec:
          containers:
          - name: myapp
            image: myapp:2.0
            ports:
            - containerPort: 80
  

    kubectl apply -f myapp-green.yaml
  

• Service: The service will route traffic to the live version (initially Blue). Later, it will be updated to point to the Green version.

    apiVersion: v1
    kind: Service
    metadata:
      name: myapp-service
    spec:
      selector:
        app: myapp
        version: blue # Initially points to Blue
      ports:
      - protocol: TCP
        port: 80
        targetPort: 80
      type: LoadBalancer
  

• Switch Traffic to Green: Update the service to point to the Green version

    apiVersion: v1
    kind: Service
    metadata:
      name: myapp-service
    spec:
      selector:
        app: myapp
        version: green # Now points to Green
      ports:
      - protocol: TCP
        port: 80
        targetPort: 80
      type: LoadBalancer
  

    kubectl apply -f myapp-service.yaml
  

To rollback to Blue, just update the service selector back to the Blue version

Canary Deployment: Gradual and Safe Application Updates

A strategy where a new version of an application is deployed to a small portion of users (e.g., 10%), while the rest continue using the old version. This allows you to test the new version in production with minimal risk. If it works well, you gradually increase its usage (e.g., 50%, then 100%) and If the canary version causes issues, you can quickly rollback and send all traffic back to the old version.

Example : Let's say you have version 1 of your app running and you want to canary release version 2

• Existing Deployment (Version 1)

    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: myapp-v1
    spec:
      replicas: 4
      selector:
        matchLabels:
          app: myapp
          version: v1
      template:
        metadata:
          labels:
            app: myapp
            version: v1
        spec:
          containers:
          - name: myapp
            image: myapp:1.0
            ports:
            - containerPort: 80
  

• Canary Deployment (Version 2)

    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: myapp-canary
    spec:
      replicas: 1 # Canary version has only 1 replica
      selector:
        matchLabels:
          app: myapp
          version: canary
      template:
        metadata:
          labels:
            app: myapp
            version: canary
        spec:
          containers:
          - name: myapp
            image: myapp:2.0
            ports:
            - containerPort: 80
  

    kubectl apply -f myapp-canary.yaml
  

• Service: The service can be configured to split traffic between the two versions. Initially, it will send most traffic to version 1 (v1) and a small portion to the canary version

    apiVersion: v1
    kind: Service
    metadata:
      name: myapp-service
    spec:
      selector:
        app: myapp
        version: v1
      ports:
      - protocol: TCP
        port: 80
        targetPort: 80
      type: LoadBalancer
  

• Update Service: Modify the service to route a small portion of traffic to the Canary deployment

    apiVersion: v1
    kind: Service
    metadata:
      name: myapp-service
    spec:
      selector:
        app: myapp
      ports:
      - protocol: TCP
        port: 80
        targetPort: 80
      type: LoadBalancer
  

  You can use Kubernetes features like weighted routing in an Ingress controller, to route a portion of traffic to the Canary or manage it through a service mesh.

• Monitor Canary: Check the performance and stability of the Canary version. If there are no issues, you can gradually increase the traffic directed to Canary.

• Full Rollout: Once confident in the Canary’s stability, update the service selector to point to the new version and increase the replicas of the Canary deployment while reducing the replicas of the Stable deployment.

• Cleanup: Remove the old stable deployment after the Canary version is fully rolled out and stable.

Canary deployments help ensure that new releases are stable and function correctly with minimal risk.

Conclusion

In this article, we explored various aspects of Kubernetes, including ReplicaSets, Deployments, Probes, and deployment strategies like Blue-Green and Canary deployments. Understanding these concepts is crucial for managing and scaling applications efficiently in a Kubernetes environment. By leveraging these tools and strategies, you can ensure high availability, reliability, and seamless updates for your applications, ultimately enhancing your overall DevOps practices.

---

💡 Let’s connect and discuss DevOps, cloud automation, and cutting-edge technology

🔗 LinkedIn | 💼 Upwork | 🐦 Twitter | 👨‍💻 GitHub