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
For example, let's talk about the networking part.
Although there are other pieces of the networking stack for Kubernetes, in this explanation, we'll stick to Container Network Interface (CNI).
CNI is the plug-in that allows Pods to communicate with each other by obtaining an IP address. Just like standard networking today with switches and routers, Pods need a way to obtain an IP address.
(cont)
Also, Kubernetes components like Services also need IP addresses and Pods need to be able to communicate with each other.
With a CNI, the control planes and worker nodes will sit in a `NotReady` state because the network is not installed. Also, the CoreDNS Pods will not go into a running state because it needs the CNI.
If you use something like Kubeadm to deploy a Kubernetes cluster (which is used for the test), the Controller, Scheduler, Etcd, API Server, Kube-Proxy, and CoreDNS get deployed as Pods.
This is just a brief example, but as you can see, it's a lot... so I highly recommend:
- Study for at least three months
- Do a lot of hands-on practice (the exam is all hands-on. No multiple choice)
It's definitely a great way to test your knowledge.
If you don't want to take the exam, that's okay. You could just go through the training for it and enhance your Kubernetes skills.
โข โข โข
Missing some Tweet in this thread? You can try to
force a refresh
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.
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