Part 14: From Git to Cluster: A Modern CI/CD and GitOps Workflow

We have come a long way. We know how to build applications, configure them, make them stateful, secure them, and package them with Helm. We can deploy our application to Kubernetes from our terminal using commands like kubectl apply and helm install.

This is fantastic for development, but it's not how changes are deployed in a real production environment. You don't want engineers running kubectl commands from their laptops against a live system. The process needs to be automated, auditable, and secure.

This is where we connect our development workflow (pushing code to Git) with our operations workflow (running applications in Kubernetes). This bridge is built with CI/CD and a modern pattern called GitOps.

What is CI/CD?

CI/CD is a cornerstone of modern software development. It stands for Continuous Integration and Continuous Deployment/Delivery.

• Continuous Integration (CI): This is the "build and test" part of the workflow. Every time a developer pushes code to a Git repository, an automated process kicks off. This process typically:

  1. Runs automated tests to check for bugs.
  2. Builds the application into a container image (e.g., using a Dockerfile).
  3. Pushes the newly built container image to a container registry (like Docker Hub, Google Artifact Registry, or AWS ECR) with a unique tag, often the Git commit hash (e.g., myapp:a1b2c3d).

• Continuous Deployment (CD): This is the "release" part. Once a new, tested container image exists, how does it get deployed to the Kubernetes cluster?

The CD Challenge: Push vs. Pull

Historically, the CD part was handled with a "push" model. The CI server (like Jenkins or a GitHub Actions runner) would be given powerful credentials to the Kubernetes cluster. After pushing the image, the CI server would run kubectl apply or helm upgrade to "push" the changes to the cluster.

This model works, but it has significant drawbacks:

• Security Risk: Your CI server needs admin-level access to your cluster. If the CI server is compromised, the cluster is compromised.
• State Drift: What if someone uses kubectl to make a manual change to the cluster? The CI server doesn't know about this. The state of the cluster has now "drifted" from the state defined in your Git repository.

GitOps: A Better Way Forward

GitOps is a modern, pull-based approach to Continuous Deployment that dramatically improves security and reliability.

The core principle of GitOps is this: The Git repository is the single source of truth for the desired state of the cluster.

Instead of a CI server pushing changes to the cluster, an agent running inside the cluster constantly watches a Git repository and pulls changes from it.

The GitOps Workflow in Action

The GitOps workflow typically involves two separate Git repositories:

1. Application Repository: The familiar repo where developers write the application code (main.py, app.js, Dockerfile, etc.).
2. Configuration Repository: A separate Git repo that contains all the Kubernetes YAML manifests (Deployments, Services, Helm charts) that define the desired state of the cluster.

Here’s how a change flows from a developer's machine to production:

1. Code Push: A developer makes a change to the application and pushes it to the Application Repo.

2. CI Pipeline Runs: The CI process kicks off. It tests the code, builds a new Docker image, and pushes it to a container registry with a new tag (e.g., myapp:v1.2.0).

3. Automatic Config Update: This is the key step. The CI pipeline's final job is to automatically make a commit to the Configuration Repo. It updates the deployment.yaml file to change the image tag to the new version it just built.
   image: my-company/myapp:v1.1.0 -> image: my-company/myapp:v1.2.0

4. The GitOps Agent Reacts: Inside the Kubernetes cluster, a GitOps agent (like Argo CD or Flux) is running. Its only job is to watch the Configuration Repo. It immediately detects the new commit that changed the image tag.

5. Cluster State is Synced: The agent compares the state described in the Git repo with the actual state running in the cluster. It sees a difference—the Deployment in the cluster is still running the old image. The agent automatically pulls the new manifest and applies it to the cluster, triggering a rolling update of the application.

This elegant workflow solves the problems of the push-based model. The CI server never needs credentials to the cluster, and the Git repository becomes a perfect, auditable log of every change ever made to the cluster's state. Rolling back is as simple as reverting a commit.

What's Next

We have now completed the entire journey, from understanding why Kubernetes exists to learning how to deploy and manage applications, and finally to automating the entire process with a modern GitOps workflow. You have seen the full picture of how cloud-native applications are built and run.

This series has provided the foundational knowledge to make you a confident Kubernetes practitioner. But the Kubernetes ecosystem is vast and ever-expanding.

In the final part of this series, we will celebrate your journey, recap the core skills you've learned, and look ahead at what's next on the horizon. We will introduce you to more advanced topics like Service Mesh, serverless computing, and security, giving you a roadmap for your continued learning in the exciting world of cloud-native technology.