Automated Kubernetes Deployments in CD Pipelines

1. From an Image in a Registry to a Running Application

Our CI pipeline ends with a tagged Docker image sitting in Amazon ECR. The goal of Continuous Deployment is to automatically get this new version running in our Kubernetes cluster with no manual intervention.

The process looks like this:

To achieve this, our GitHub Actions workflow needs a new deploy job that will:

1. Wait for the build-and-push job to complete successfully.
2. Authenticate with the Kubernetes cluster so it can issue commands.
3. Update the Kubernetes Deployment manifest to point to the new Docker image tag.
4. Apply the updated manifest to the cluster, triggering a rolling update.

Let's walk through how to implement this securely and efficiently.

2. Setting Up Secure Access to Kubernetes

Just as we used secrets for AWS credentials, we must never expose our Kubernetes cluster's configuration directly in a workflow file. The standard way to access a Kubernetes cluster is via a kubeconfig file. Our first step is to provide this file to our GitHub Actions runner securely.

The process involves two key steps:

1. Retrieving the content of your kubeconfig file.
2. Storing this content as an encrypted secret in your GitHub repository.

By storing the kubeconfig content in a GitHub secret, you allow your workflow to authenticate with your cluster without ever exposing sensitive credentials in your codebase.

3. Automating Deployment with GitHub Actions

With authentication handled, we can now build the deploy job. We'll use a pre-built, trusted GitHub Action from Azure, azure/k8s-deploy, which simplifies the process of deploying to any Kubernetes cluster.

Let's first understand the core components of the workflow and the Kubernetes manifests.

Dissecting the deploy Job

Let's construct our full ci-cd.yml workflow. It will contain the build-and-push job from our previous lesson and add the new deploy job.

name: Build, Push to ECR, and Deploy to Kubernetes

on:
  push:
    branches: [ main ]

env:
  ECR_REPOSITORY: my-spring-app
  AWS_REGION: us-east-1 # Change to your region

jobs:
  # This job is from our previous lesson
  build-and-push:
    runs-on: ubuntu-latest
    outputs:
      image: ${{ steps.build-image.outputs.image }}
    steps:
      - name: Checkout repository
        uses: actions/checkout@v3

      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v2
        with:
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          aws-region: ${{ env.AWS_REGION }}

      - name: Login to Amazon ECR
        id: login-ecr
        uses: aws-actions/amazon-ecr-login@v1

      - name: Build, tag, and push image to Amazon ECR
        id: build-image
        env:
          ECR_REGISTRY: ${{ steps.login-ecr.outputs.registry }}
          IMAGE_TAG: ${{ github.sha }}
        run: |
          docker build -t $ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG .
          docker push $ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG
          echo "image=$ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG" >> $GITHUB_OUTPUT

  # This is our new deployment job
  deploy:
    runs-on: ubuntu-latest
    needs: build-and-push # Ensures this job runs only after build-and-push succeeds
    steps:
      - name: Checkout repository
        uses: actions/checkout@v3

      # 1. Set the Kubernetes context
      - name: Set Kubernetes context
        uses: azure/k8s-set-context@v3
        with:
          method: kubeconfig
          kubeconfig: ${{ secrets.KUBECONFIG }} # Use the secret we created

      # 2. Deploy to Kubernetes
      - name: Deploy to Kubernetes cluster
        uses: azure/k8s-deploy@v4
        with:
          manifests: |
            kubernetes/deployment.yaml
            kubernetes/service.yaml
          images: |
            ${{ needs.build-and-push.outputs.image }}
          action: 'deploy'

Key Elements of the New deploy Job:

1. needs: build-and-push: This line creates a dependency. The deploy job will only start if the build-and-push job completes successfully. This is fundamental to a reliable pipeline.
2. outputs and needs...outputs: We've modified the build-and-push job to output the full image name and tag. The deploy job then consumes this output using the needs context. This is the correct way to pass data between jobs.
3. azure/k8s-set-context@v3: This action takes the kubeconfig data from your GitHub secret and configures the kubectl command-line tool on the runner, enabling it to communicate with your cluster.
4. azure/k8s-deploy@v4: This is the core of our CD step.
   • manifests: We provide the path to our Kubernetes manifest files (e.g., deployment.yaml).
   • images: This is where the magic happens. We pass the full image URL from the previous job. The action intelligently finds the image field in your deployment.yaml and substitutes its value with this new one before applying it. This is a clean and robust alternative to using command-line tools like sed to modify files.
   • action: 'deploy': This tells the action to perform a standard deployment, which typically results in a rolling update in Kubernetes.

4. Deep Dive: The k8s-deploy Action

For a senior-level interview, it's good to know more about the tools you use. The azure/k8s-deploy action is highly configurable.

This action handles many complexities of Kubernetes deployments, allowing you to define your CD process declaratively within your workflow file.

Conclusion

Congratulations! You have now designed and implemented a complete, end-to-end CI/CD pipeline. Your workflow automatically tests your code, packages it into a container, versions it, stores it in a secure registry, and deploys it to a Kubernetes cluster. This level of automation is the standard for high-performing engineering teams and is a crucial topic in technical interviews for senior roles.

Key Takeaways:

• Continuous Deployment (CD) for Kubernetes automates the rollout of new application versions.
• Sensitive data like the kubeconfig file must be stored in encrypted GitHub Secrets.
• The needs keyword in GitHub Actions is used to create dependencies between jobs, ensuring a sequential flow (build then deploy).
• Specialized actions like azure/k8s-deploy simplify deployment by handling details like manifest parsing and image substitution.
• Understanding common failure modes like ImagePullBackOff and their solutions is critical for both production operations and interviews.

Preview of the Next Lesson:
Our current pipeline uses a rolling update, which is the default strategy in Kubernetes. While effective, it's just one of several ways to deploy new code. In our next lesson, "Explain zero-downtime deployment strategies like rolling updates and blue-green deployments," we will dive deeper into the mechanics of rolling updates and compare them to other powerful strategies like Blue-Green and Canary deployments, which help further reduce risk and downtime.