Kubernetes

History

The history of Kubernetes is apparently pretty long. It all started with borg, which was too monolithic and complex. It was later rewritten into Omega (Omega? really?) with a much more consistent and constrained architecture, which was unfortunately not good for a public cloud. Kubernetes (K8) is the climax of all these rewrites and focuses on individual components

1. a shared data store
2. components watching for changes to said store
3. domain-specific REST API

The third point is key because it allowed for flexibility. You can already examples of this extensibility through operators or in the form of CRDs (Custom Resource Definitions). Anyways, we should be good with the history now.

Declare Your Will

The big idea of Kubernetes is declarative automation, you describe what you want and the system tries its best to reach that state. This differs from imperative automation where you instead list the steps. Anyways kubernetes was the result of incorporating declarative automation from the get go instead of hacking imperative automation into a declarative one.

This is kind of big, because it is much easier to overlay declarative layers than imperative layers since there is much less information leaked through declarative automation. You are essentially just saying, "I want this, I don't care how you get there but just get me there", while with imperative you greatly constrain the system to the point where adding layers becomes difficult.

Automate Everything

Now that you can describe state, you should be able to store it somewhere too right? In K8, states can be dynamic configuration like a ConfigMap or a Secret or even configuration for components themselves like a LoadBalancer, a Service, a Route, or even a HorizontalPodAutoscaling Policy. Or if an application is stateful, a StatefulSet is required.

These "components" and "configurations" are standardized but of course you can define your own, so long as you provide a means of interpreting your state. And since they are so easily described, they can be easily modified too. Which leads us to GitOps! You store your configs (manifest files) somewhere, and then since they are soooo easy to modify (they are just text after all), you can trigger modifications from another repository, see GitOps Pipelines Example.

Then you can ArgoCD or flux to monitor changes to your manifest repo and automatically roll out deployments. And after some time, you might realize that you can have your manifest repo generate manifest files by itself which it feeds to K8. I believe this step is optional, but the big plus of this is that you can see past the abstractions of kustomize and see what your "manifests" actually look like.