GitOps approach to Continuous Delivery for Kubernetes
In this post, I’d like to share my experience and learnings about configuring a deployment pipeline for Kubernetes. I’ll be using Gitlab CI/CD and AWS EKS to demonstrate the concept, but the core idea remains the same: all changes must come declaratively from a single source of truth.
GitOps is a relatively newer term in the town but goes back to the fundamentals of Infra as Code.
GitOps fundamentally is an operating model to perform tasks on Kubernetes related to deployments, configuration, secrets and monitoring workloads. All kind of changes must be performed via a single place, which happens to be a
git repo. Benefits of that are what basically benefits of version controlling the code is. So why treat infra as any different?
git happens to be the single source of truth for your infra, rollbacks are easy as reverting to last known good configuration and every change can be observed/verified.
A lot of tutorials/blog posts hitherto cover a very basic scenario where they do
kubectl apply and voila the deployment’s live. However we all know things are very different (to say the least) in production, so this post will cover all aspects of deployment:
- Creating Manifests
- Environment Promotion
- Handling config and secrets
- Authorization of CI/CD in the cluster
A GitOps workflow looks like:
Push vs Pull
There are 2 approaches to how you can handle deployments to a cluster.
This will be a push based CD pipeline. In simpler terms it simply means that the runner will need access to your Kubernetes cluster and has to authorize. So we need RBAC + Auth both to happen in the runner.
Writing the pipeline
I’ve created a docker image
eks-gitops which I’ll be using throughout the pipeline. This container image contains popular tools like
kubeval etc and scripts to configure access to cluster using
aws-iam-authenticator. I’ve written more about how RBAC works inside EKS here.