Kubernetes Deployment

Manage the deployment and scaling of a set of replica Pods.

Manage and control the lifecycle of Pods, Here’s a breakdown of what a Kubernetes Deployment does:

1. Desired State Declaration: Kubernetes Deployment defines the desired state of containerized applications.
2. Replica Management: Ensures the specified number of replica Pods are running at all times for high availability.
3. Rolling Updates: Facilitates seamless updates by gradually replacing old Pods with new ones, minimizing downtime.
4. Rollback: Allows easy rollback to a previous stable version in case of issues or errors during updates.
5. Scaling: Supports both manual and automatic scaling of application replicas based on demand.
6. Self-healing: Automatically replaces failed Pods to maintain application availability and health.

Types of Deployment Strategies:

1. Rolling Update Deployment:

Default Strategies (To update a system without causing downtime)
Updates by Replacing old instance with new one
This creates a pod before deleting.

• Prepare new version: Develop and test the updated software version.
• Incremental updates: Update small subsets of instances sequentially to minimize downtime.
• Validation: Verify the functionality and health of each updated instance.
• Gradual rollout: Continue updating more instances until all are upgraded.
• Monitoring and rollback: Monitor system health and easily revert to the previous version if issues arise.

#deployment.yaml

apiVersion: apps/v1          #apiVersion and kind specify the Kubernetes resource type (Deployment).
kind: Deployment
metadata:                    #contains information like the name and labels of the deployment.
  name: my-app
  labels:
    app: my-app
spec:                        # defines the desired state of the deployment, including the number of replicas, selector, and template for the pods.
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-app
        image: your-docker-image:latest
        ports:
        - containerPort: 8080
  strategy:                        #specifies the update strategy, in this case, RollingUpdate.
    type: RollingUpdate
    rollingUpdate:                 #further configures the rolling update strategy 
      maxUnavailable: 1            #setting maxUnavailable to 1 (one instance can be unavailable at a time during the update) 
      maxSurge: 1                  #maxSurge to 1 (allowing one additional instance beyond the desired count during the update).

Recreate Deployment :

This Terminate the instance and creates new ones
This may lead to downtime

• Termination: All existing instances (pods) of the application are terminated at the same time.
• Creation of new instances: After all existing instances are terminated, new instances of the application are created using the updated version of the software.
• Validation: The newly created instances are validated to ensure that they are functioning correctly.
• Switch over: Once the new instances are confirmed to be healthy, traffic is switched over to them.

apiVersion: apps/v1       #apiVersion and kind specify the Kubernetes resource type (Deployment).
kind: Deployment
metadata:                 #metadata contains information like the name and labels of the deployment.
  name: my-app
  labels:
    app: my-app
spec:                     #spec defines the desired state of the deployment, including the number of replicas, selector, and template for the pods.
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-app
        image: your-docker-image:latest
        ports:
        - containerPort: 8080
  strategy:                    #strategy specifies the update strategy 
    type: Recreate             #Recreate, indicating that all existing instances will be terminated simultaneously before new instances are created.

Blue-green Deployment:

This maintains two identical production environment
One active: Blue, One Inactive: Green
This has zero downtime
Provide easy rollback and safe environment for testing new version

• Two Environments: Blue-green deployment maintains two identical production environments, “blue” and “green.”
• Traffic Routing: Live traffic is initially routed to the “blue” environment while updates are deployed to the “green” environment.
• Testing Phase: The new version undergoes thorough testing in the “green” environment before it serves live traffic.
• Switch-over: Once testing is successful, traffic routing is switched from “blue” to “green” to make the new version live.
• Fallback Mechanism: In case of issues, traffic can quickly be redirected back to the “blue” environment for a rollback.

#my-app-blue.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app-blue
  labels:
    app: my-app
    color: blue
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
      color: blue
  template:
    metadata:
      labels:
        app: my-app
        color: blue
    spec:
      containers:
      - name: my-app
        image: your-docker-image:blue #The my-app-blue Deployment uses the your-docker-image:blue  Docker image
        ports:
        - containerPort: 8080

#my-app-green.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app-green
  labels:
    app: my-app
    color: green
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
      color: green
  template:
    metadata:
      labels:
        app: my-app
        color: green
    spec:
      containers:
      - name: my-app
        image: your-docker-image:green    #my-app-green uses your-docker-image:green.
        ports:
        - containerPort: 8080

Canary Deployment:

Involves rolling out a new version to a small subset of users or instances first.
By Monitoring metrics and user feedback,
we can evaluate the performance of the new version in production with minimal impact before proceeding with the full rollout.

• Subset Deployment: Deploy a new version of the application to a small subset of users or servers initially.
• Monitoring and Testing: Monitor the performance and stability of the canary deployment closely.
• Gradual Increase: Gradually increase the percentage of user traffic or servers running the new version.
• Continuous Evaluation: Continuously evaluate the performance and stability of the new version throughout the rollout.
• Rollback Capability: Quickly halt or roll back the rollout if issues or anomalies are detected.
• Full Rollout: Once the new version is proven to be stable and performant, roll it out to the entire user base or infrastructure.

#deployment.yaml = Defines the Deployment resource for managing the application pods.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
  labels:
    app: my-app
spec:
  replicas: 5
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-app
        image: your-docker-image:current    #my-app Deployment uses the Docker image your-docker-image:current, representing the current version of the application.
        ports:
        - containerPort: 8080

#service.yaml =  Defines the Service resource for exposing the application within the Kubernetes cluster.

apiVersion: v1
kind: Service
metadata:
  name: my-app
spec:
  selector:
    app: my-app     #my-app is defined to expose the application within the Kubernetes cluster.
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080

#ingress.yaml =  Defines the Ingress resource for exposing the application externally with a specified hostname.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-app-ingress
spec:
  rules:
  - host: your-app.example.com  #expose the application externally with a specified hostname (your-app.example.com).
    http:
      paths:
      - pathType: Prefix
        path: "/"
        backend:
          service:
            name: my-app
            port:
              number: 80

AB testing Deployment:

Allow us to deploy multiple versions simultaneously and direct a portion of the traffic to each version.

• Variants Creation: Develop multiple versions or implementations of the application or feature to be tested.
• User Segmentation: Segment users or traffic into different groups, each exposed to a different variant.
• Metrics Collection: Gather data on user engagement, conversion rates, or performance for each variant.
• Analysis: Analyze collected data to determine which variant performs better based on predefined metrics.
• Decision Making: Use analysis results to decide which variant to adopt or iterate upon for further improvement.

#We have two separate deployments for Variant A and Variant B of the application.
#Each deployment has its own Docker image and unique labels identifying the variant.


#Deployment for Variant A (variant-a-deployment.yaml):

apiVersion: apps/v1
kind: Deployment
metadata:
  name: variant-a
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
      variant: a
  template:
    metadata:
      labels:
        app: my-app
        variant: a
    spec:
      containers:
      - name: my-app
        image: your-docker-image:variant-a
        ports:
        - containerPort: 8080

#We have two separate deployments for Variant A and Variant B of the application.
#Each deployment has its own Docker image and unique labels identifying the variant.

#Deployment for Variant B (variant-b-deployment.yaml):

apiVersion: apps/v1
kind: Deployment
metadata:
  name: variant-b
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
      variant: b
  template:
    metadata:
      labels:
        app: my-app
        variant: b
    spec:
      containers:
      - name: my-app
        image: your-docker-image:variant-b
        ports:
        - containerPort: 8080

#We define a Kubernetes Service to expose the application internally within the cluster.

#Service to Split Traffic (ab-testing-service.yaml):

apiVersion: v1
kind: Service
metadata:
  name: ab-testing
spec:
  selector:
    app: my-app
  ports:
  - protocol: TCP
    port: 80
    targetPort: 8080

#We use Istio's VirtualService to split traffic between Variant A and Variant B based on a 50/50 weight.

#Istio's VirtualService for Traffic Splitting (ab-testing-virtualservice.yaml):

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: ab-testing
spec:
  hosts:
  - my-app.example.com
  http:
  - route:
    - destination:
        host: ab-testing
        subset: variant-a
      weight: 50
    - destination:
        host: ab-testing
        subset: variant-b
      weight: 50

Istio’s : Istio is an open-source service mesh platform that provides a uniform way to connect, manage, and secure microservices.

Multicluster Deployment:

For Redundancy, performance optimization, or Regulatory compliance
We can orchestrate deployment across multiple Kubernetes clusters
Eg : Kubernetes federation Gitops

• Scalability: Distribute workloads across multiple Kubernetes clusters to handle increased traffic or workload demands effectively.
• Redundancy and High Availability: Ensure continuous service availability by deploying applications across clusters for redundancy and failover capabilities.
• Disaster Recovery: Replicate applications and data across multiple clusters to minimize downtime and data loss in the event of a cluster failure or outage.
• Geographic Distribution: Improve performance and reduce latency for users worldwide by deploying applications closer to their geographic locations.
• Isolation and Compliance: Achieve better isolation of workloads and data, facilitating compliance with regulatory requirements or security policies.
• Hybrid and Multi-Cloud Deployment: Support hybrid and multi-cloud strategies by deploying applications across on-premises and cloud environments or across multiple cloud providers.

#Cluster A Deployment YAML (cluster-a-deployment.yaml):

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app-cluster-a
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
      cluster: cluster-a
  template:
    metadata:
      labels:
        app: my-app
        cluster: cluster-a
    spec:
      containers:
      - name: my-app
        image: your-docker-image:latest
        ports:
        - containerPort: 8080

#Cluster B Deployment YAML (cluster-b-deployment.yaml):

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app-cluster-b
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
      cluster: cluster-b
  template:
    metadata:
      labels:
        app: my-app
        cluster: cluster-b
    spec:
      containers:
      - name: my-app
        image: your-docker-image:latest
        ports:
        - containerPort: 8080

If there’s a specific topic you’re curious about, feel free to drop a personal note or comment. I’m here to help you explore whatever interests you!

Thanks for spending your valuable time learning to enhance your knowledge!