GitHub Actions for Kubernetes and Cloud

# CHAPTER 12

GitHub Actions for Kubernetes and Cloud #

1. Introduction #

2. Learning Objectives #

• Understand the difference between Server (SSH) deployments and Cluster (API) deployments.

• Authenticate GitHub Actions securely with a cloud provider (AWS/GCP/Azure).

• Utilize the kubectl tool within a workflow to update Kubernetes deployments.

• Understand the GitOps philosophy in relation to Kubernetes.

3. Beginner-Friendly Explanation #

• Server Deployment (SSH): You personally walk up to truck #5, open the hood, and change the oil. You have to know exactly which truck you are fixing.

• Cloud/Kubernetes Deployment (API): You sit in a control tower. You type a command into a computer: "I need 50 trucks on the road immediately running the new Version 2 engine." You don't know *which* specific trucks they are, and you don't care. The automated factory (Kubernetes) instantly builds them and puts them on the road.

GitHub Actions is the person sitting in the control tower sending the master commands to the factory.

4. Cloud Authentication (OIDC) #

# Example: Secure AWS Authentication without passwords
    steps:
      - name: Configure AWS Credentials
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::1234567890:role/GitHubDeploymentRole
          aws-region: us-east-1

5. Deploying to Kubernetes #

This is done using kubectl, the command-line tool for Kubernetes. The core command is a "Rolling Update": kubectl set image deployment/my-webapp webapp=myusername/my-webapp:v42

This tells Kubernetes: "Find the deployment named my-webapp. Take the old containers offline one-by-one, and replace them with the new v42 image."

6. Mini Project: Deploy App to a Cloud Platform Concept #

Step-by-Step Pipeline Concept:

name: Deploy to Kubernetes
on:
  push:
    branches: [ main ]

# Required to use OIDC authentication securely
permissions:
  id-token: write 
  contents: read

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

      # Step 1: Authenticate with the Cloud Provider securely via OIDC
      - name: Authenticate to Google Cloud
        uses: google-github-actions/auth@v2
        with:
          workload_identity_provider: 'projects/123/locations/global/workloadIdentityPools/my-pool/providers/my-provider'
          service_account: 'my-deployer-sa@my-project.iam.gserviceaccount.com'

      # Step 2: Get the Kubernetes credentials
      - name: Get GKE credentials
        uses: google-github-actions/get-gke-credentials@v2
        with:
          cluster_name: 'production-cluster'
          location: 'us-central1'

      # Step 3: Tell Kubernetes to update the live application!
      - name: Deploy to Kubernetes
        run: |
          # Apply any infrastructure YAML changes
          kubectl apply -f ./k8s/deployment.yaml
          
          # Force the rolling update to the new Docker image hash
          kubectl set image deployment/frontend-app frontend=myregistry/frontend:${{ github.sha }}
          
          # Wait for the deployment to finish successfully
          kubectl rollout status deployment/frontend-app

7. Real-World Scenarios #

8. Best Practices #

• Wait for Rollout: In Step 3 above, notice the command kubectl rollout status. This is crucial! If you just run kubectl set image, the GitHub Action instantly turns green and finishes. But Kubernetes might take 5 minutes to actually start the containers. If the containers crash, GitHub won't know. By adding rollout status, GitHub waits for Kubernetes to confirm the containers are healthy before marking the workflow as successful.

9. Security Recommendations #

• Least Privilege Roles: The IAM Role that GitHub assumes (e.g., GitHubDeploymentRole) must have the absolute minimum permissions required. It should only be allowed to update the specific Kubernetes namespace or AWS ECS service it is responsible for. It should NEVER have full AdministratorAccess to the cloud account.

10. Troubleshooting Tips #

• OIDC Configuration: If the authentication step fails with Not authorized to perform AssumeRoleWithWebIdentity, the error is almost never in the YAML file. The error is in the cloud provider's IAM console. You must verify that the "Trust Policy" exactly matches your GitHub Organization and Repository name.

11. Exercises #

1. 1. Explain why OIDC (OpenID Connect) authentication is vastly superior to storing long-lived AWS Access Keys in GitHub Secrets.

1. 2. What is the operational purpose of the kubectl rollout status command at the end of a CI/CD pipeline?

12. FAQs #

13. Interview Questions #

• Q: Describe the architectural flow of securely authenticating a GitHub Actions workflow with an AWS account using OIDC. What permissions must be declared in the YAML file?

• Q: You are tasked with migrating a monolithic SSH-based deployment workflow to a cloud-native Kubernetes deployment workflow. Contrast the actions taken by the CI/CD pipeline in these two distinct environments.

14. Summary #

15. Next Chapter Recommendation #