0Pricing
DevOps Bootcamp · Lesson

Deploying to Kubernetes with Actions

Set up Continuous Deployment to Kubernetes clusters, managing deployments and services directly from GitHub Actions.

Deploying to Kubernetes with Actions is a free DevOps Bootcamp lesson on CoddyKit — lesson 3 of 4. You can read the complete lesson below for free — then practise it hands-on in the browser with a built-in code editor and a 24/7 AI tutor. It is part of the DevOps Bootcamp learning path, one of 4 lessons in the course, and your progress syncs across the web and the CoddyKit app.

Intro to K8s CD with Actions

Welcome! In this lesson, you'll learn how to set up Continuous Deployment (CD) to Kubernetes clusters using GitHub Actions.

Automating deployments means your application changes can go live quickly and reliably, without manual steps.

We'll cover authentication, applying Kubernetes manifests, and managing updates.

K8s Deployment Essentials

Before we deploy, let's quickly recall two core Kubernetes resources:

  • Deployments: These manage your application's Pods, ensuring a desired number of replicas are always running. They handle updates and rollbacks.
  • Services: These define how to access your application (e.g., internally within the cluster or externally via a LoadBalancer).

Our goal is to apply YAML files defining these to our cluster from GitHub Actions.

Authenticating Actions to K8s

To deploy, your GitHub Actions workflow needs to communicate with your Kubernetes cluster's API server.

This requires authentication. The standard way to authenticate with Kubernetes is using a kubeconfig file.

We need to securely provide this file's content to our workflow runner.

Securing Kubeconfig

The kubeconfig file contains sensitive information like cluster endpoints and user credentials. It must be kept secret!

GitHub Actions provides Secrets for this purpose. You'll store your kubeconfig file's content as a repository secret.

How to get your kubeconfig? It depends on your K8s provider (e.g., aws eks update-kubeconfig, gcloud container clusters get-credentials).

Set Up K8s Context

Once your kubeconfig is stored as a secret (let's call it KUBE_CONFIG_DATA), your workflow can use it.

The common practice is to write the secret's content to a temporary file on the runner and then set the KUBECONFIG environment variable to point to it.

This tells kubectl where to find the cluster connection details.

Using `kubectl` in Workflows

kubectl is the official command-line tool for interacting with Kubernetes clusters. GitHub Actions runners have kubectl pre-installed.

After setting up the kubeconfig, you can run any kubectl command in your workflow steps.

Let's see a basic example:

name: K8s Setup Test

on: [workflow_dispatch]

jobs:
  test-kubeconfig:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Set up Kubeconfig
        env:
          KUBE_CONFIG_DATA: ${{ secrets.KUBE_CONFIG_DATA }}
        run: |
          mkdir -p ~/.kube
          echo "$KUBE_CONFIG_DATA" > ~/.kube/config
          chmod 600 ~/.kube/config
          echo "KUBECONFIG=$HOME/.kube/config" >> $GITHUB_ENV

      - name: Verify kubectl access
        run: kubectl version --client

Simple K8s Deployment Manifest

Here's a basic Kubernetes Deployment and Service manifest for a "hello-world" application. This is what we'll ask Kubernetes to run.

This example uses a simple Nginx image, exposing it on port 80.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: hello-app-deployment
spec:
  replicas: 1
  selector:
    matchLabels:
      app: hello-app
  template:
    metadata:
      labels:
        app: hello-app
    spec:
      containers:
      - name: hello-app
        image: nginx:latest
        ports:
        - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: hello-app-service
spec:
  selector:
    app: hello-app
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
  type: LoadBalancer

The Full Deployment Workflow

Now, let's integrate the deployment step into a workflow. After building and pushing your container image (from previous lessons), you can deploy it.

This workflow assumes your kubeconfig secret is set and the manifest file (e.g., k8s/deployment.yaml) exists in your repo.

name: Deploy to Kubernetes

on:
  push:
    branches:
      - main
  workflow_dispatch:

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Set up Kubeconfig
        env:
          KUBE_CONFIG_DATA: ${{ secrets.KUBE_CONFIG_DATA }}
        run: |
          mkdir -p ~/.kube
          echo "$KUBE_CONFIG_DATA" > ~/.kube/config
          chmod 600 ~/.kube/config
          echo "KUBECONFIG=$HOME/.kube/config" >> $GITHUB_ENV

      - name: Deploy application to K8s
        run: kubectl apply -f k8s/deployment.yaml

Updating Your Application

One of the great features of kubectl apply is its idempotence. If the resources defined in your YAML already exist, kubectl apply will update them instead of creating new ones.

To deploy a new version of your app, simply update the image tag in your deployment.yaml and push the change. GitHub Actions will then trigger, and Kubernetes will perform a rolling update, replacing old pods with new ones gradually, ensuring minimal downtime.

Quick Check

You've learned the essential steps to deploy an application to Kubernetes using GitHub Actions.

Which of the following is the correct sequence of steps for a GitHub Actions workflow to deploy a Kubernetes manifest?

Recap & Next Steps

Great job! You've learned how to set up Continuous Deployment to Kubernetes using GitHub Actions.

  • We store sensitive kubeconfig data in GitHub Secrets.
  • Workflows use this secret to configure kubectl.
  • kubectl apply -f is used to deploy or update K8s manifests.
  • Kubernetes handles rolling updates when changes are applied.

This powerful combination automates your deployments, making your development process smoother and faster. Keep exploring more advanced K8s features!

Frequently asked questions

Is the “Deploying to Kubernetes with Actions” lesson free?

Yes — the full text of “Deploying to Kubernetes with Actions” is free to read here on the web, and the DevOps Bootcamp course includes 4 lessons in total. To practise it interactively (a built-in code editor and a 24/7 AI tutor) and unlock the rest of the DevOps Bootcamp course, upgrade to CoddyKit PRO.

What will I learn in “Deploying to Kubernetes with Actions”?

Set up Continuous Deployment to Kubernetes clusters, managing deployments and services directly from GitHub Actions. You practise DevOps Bootcamp with hands-on code you run directly in the browser, and a 24/7 AI tutor answers your questions as you work through the lesson.

Do I need any experience to start DevOps Bootcamp?

No prior experience is required. DevOps Bootcamp on CoddyKit is structured for beginners through advanced learners; this is — lesson 3 of 4, so you can start here or from the beginning and move at your own pace.

How long does the “Deploying to Kubernetes with Actions” lesson take?

Most CoddyKit lessons take about 5–10 minutes. Each one is bite-sized and interactive, so you make steady progress and pick up exactly where you left off across the web and the app.

Can I write and run code in this DevOps Bootcamp lesson?

Yes. Every DevOps Bootcamp lesson includes a built-in code editor, so you write and run real code right in your browser and get instant AI feedback — no local setup required.

All lessons in this course

  1. Building Docker Images with Actions
  2. Pushing Images to Registries
  3. Deploying to Kubernetes with Actions
  4. Helm Charts and Kubernetes Manifests in CI/CD
← Back to DevOps Bootcamp