Azure Kubernetes Service (AKS)

Introduction to Deployments

Deployments in Kubernetes are a core object used to manage stateless applications. A Deployment provides declarative updates for Pods and ReplicaSets. You describe a desired state in a Deployment, and the Deployment Controller changes the actual state to the desired state at a controlled rate.

Key benefits of using Deployments include:

• Declarative Updates: Define your application's desired state, and Kubernetes handles the rest.
• Rolling Updates: Update your application with zero downtime by gradually replacing old Pods with new ones.
• Rollbacks: Easily revert to a previous version of your application if something goes wrong.
• Scaling: Manage the number of application instances dynamically.

Creating a Deployment

You can create a Deployment using Kubernetes configuration files (YAML) applied with kubectl. First, you need a container image for your application.

Here's a basic example of a Deployment manifest for a simple Nginx web server:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.21.6
        ports:
        - containerPort: 80
        resources:
          requests:
            memory: "64Mi"
            cpu: "250m"
          limits:
            memory: "128Mi"
            cpu: "500m"

To apply this manifest to your AKS cluster, save it as nginx-deployment.yaml and run:

kubectl apply -f nginx-deployment.yaml

This command will create a Deployment named nginx-deployment with 3 replicas of the Nginx container using the specified image.

Understanding Deployment Manifests

A typical Deployment manifest includes the following key fields:

• apiVersion: Specifies the Kubernetes API version.
• kind: Set to Deployment for Deployment resources.
• metadata: Contains name, labels, and other identifying information for the Deployment.
• spec: Defines the desired state of the Deployment.
  • replicas: The desired number of Pods for your application.
  • selector: How the Deployment finds which Pods to manage. It must match the labels defined in the Pod template.
  • template: A blueprint for creating the Pods that the Deployment manages.
    • metadata: Labels for the Pods.
    • spec: Specifications for the containers within the Pod, including the container image, ports, resource requests and limits, etc.

Updating Deployments

To update your application, modify the Deployment manifest (e.g., change the container image version) and apply it again using kubectl apply. Kubernetes will perform a rolling update by default. This means it will gradually stop old Pods and start new ones, ensuring your application remains available throughout the update process.

For example, to update the Nginx image to a newer version:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.22.0 # Updated image version
        ports:
        - containerPort: 80
        resources:
          requests:
            memory: "64Mi"
            cpu: "250m"
          limits:
            memory: "128Mi"
            cpu: "500m"

Apply the updated manifest:

kubectl apply -f nginx-deployment.yaml

You can monitor the progress of the rollout using:

kubectl rollout status deployment/nginx-deployment

Rolling Back Deployments

If an update introduces issues, you can roll back to a previous version. Kubernetes keeps a history of Deployment revisions.

First, view the revision history:

kubectl rollout history deployment/nginx-deployment

To roll back to a specific revision (e.g., revision 2):

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

You can also roll back to the previous revision without specifying a number:

kubectl rollout undo deployment/nginx-deployment

Advanced Deployment Strategies

Deployments support various strategies to control how updates are performed. The default is RollingUpdate. Other common strategies include:

• Recreate: Terminates all existing Pods before creating new ones. This can cause downtime.
• Blue/Green Deployments: Involves running two identical environments (blue and green), with one receiving live traffic. You deploy to the inactive environment, test, and then switch traffic. This is typically managed outside of a basic Deployment object using Services and Ingress.
• Canary Deployments: Gradually roll out new versions to a small subset of users before a full rollout. This also often involves additional Kubernetes objects like Services and Ingress controllers.

You can configure the strategy in the Deployment manifest:

spec:
  strategy:
    type: RollingUpdate # Or Recreate
    rollingUpdate:
      maxUnavailable: 1 # Number of Pods that can be unavailable during the update
      maxSurge: 1       # Number of Pods that can be created above the desired count