Are you using GitOps today in your Kubernetes cluster?
If not, let me show you how to get a GitOps operator up and running in under EIGHT minutes.
a thread ๐งต
Using Flux (a popular GitOps operator), you can:
- Install the controller on a Kubernetes cluster
- Connect to a GitHub org
- Point to a source control repo
- Deploy an app
- Have it managed by GitOps
in less time than you probably think.
If you're not familiar with GitOps, here's a quick breakdown.
GitOps gives you the ability to handle your Kubernetes Manifests by utilizing configuration management techniques. It's a controller that looks at a source control repo and confirms that what's deployed to the Kubernetes cluster (the current state) matches what's in the (cont).
source control repo (the desired state)
Learn how to set this all up on any Kubernetes cluster (even minikube) at the link below.
If so, ensure that you're comfortable in the following domains:
- Kubernetes storage
- Troubleshooting system components (control planes and worker nodes)
- Pod and other workload scheduling (including high availability)
(cont)
- Cluster architecture (building out clusters using Kubeadm)
- All of the control plane and worker node components (Etcd, Controller, Scheduler, etc.)
- RBAC
- Cluster security
- Kubernetes services and networking
I'm going to voice an extremely unpopular opinion.
One that could even get me "cancelled"...
There are quite a few different research firms out there, and we all know the big names.
A thread ๐งต
When you peel back the curtain, it's typically not real research that goes into it.
It looks like the following at a high level:
- There's a paper that needs to be written based on demand.
- You pick X amount of vendors to go into the paper.
(cont)
- You chat with all of them for about an hour. They show you a PowerPoint presentation/sales pitch about the product.
- You take that and write about it.
From unit tests to mock tests to integrations tests and the list continues.
But with Kubernetes Manifests, there aren't a lot of tests going on.
A thread ๐งต
There's a lot that can go wrong with a Kubernetes Manifest which includes :
- Using out-of-date APIs.
- Policies that your organization set aren't being used.
- Bad practices used like using the latest version of a container image.
And when tests do occur, they aren't done in a repeatable process, which is a problem in itself.
There's a way to solve these issues, and that's by scanning Kubernetes Manifests.
GitOps is the equivalent of a Kubernetes Controller
A Kubernetes Controller, which runs on the Kubernetes Control Plane, ensures that the observed state of the cluster matches the desired state
A thread ๐งต
A Kubernetes Controller, which runs on the Kubernetes Control Plane, ensures that the observed state of the cluster matches the desired state
For example, the Deployment Operator (like a Deployment spec in a Kubernetes Manifest) watches fo ensure that all of the applications running as a Kubernetes Deployment are in the desired state
When you're putting any application on Kubernetes, you have to confirm a few things if you want a successful deployment.
A thread ๐งต
A few things to keep in mind are:
- Is the Pod healthy
- Is the Pod running as expected
- Does Kubelet know when to restart a failed/unhealthy container
- Should a Pod receive requests
- Should Kubelet start accepting traffic
and A LOT more
Check out my latest video on how you can implement the above with Liveness and Readiness Probes