Kubernetes 101 series - brief
For most experienced IT professionals picking up new technologies is part and parcel of their job, and something that is expected in their industry. But Kubernetes is a different story. It’s the one tool that even gifted engineers often find surprisingly tough to get the hang of.
This isn't entirely their fault. Kubernetes is not just a new tool for running infrastructure; it requires an entirely different mindset that introduces a variation of abstractions (pods, nodes, deployments, services, config maps, PDBs, the list goes on) that are nested, interdependent and therefore inherently nebulous.
It is ephemeral by nature as, for example, pods - the smallest abstraction of compute within the Kubernetes eco-system - are disposable and meant to be killed, restarted, replaced both automatically and frequently.
I have worked in the industry just long enough to have had experience configuring traditional persistent IT infrastructure, and it is the polar opposite of this methodology.
Although the majority of my career has been spent working on greenfield cloud based architectures, I think this may be one of (if not the) reason why K8s has such a long learning curve for many engineers in the industry.
If Nedry had successfully managed to get Kubernetes to orchestrate Jurassic Park's entire infrastructure, maybe he wouldn't have gone rogue and told BioSyn to get lost?🦖
When working on a mixture of VMware servers and on-prem hardware (Lenovo ThinkSystems and IBM Power Systems) these servers were our babies. We nurtured them, gave them a stable IP addresses, frequently checked how happy they were, maintained them in the dead of the night and assigned them as our "london-prd-1, london-uat-2" servers, because how could they be our pets if we didn't give them a name?
One of the hardest parts about becoming proficient in Kubernetes is accepting that its most basic unit of compute (pods) are neither our babies, nor our pets. They are livestock, living in perpetuated ephemerality and will be killed or replaced if they do not work as expected.
However, this shift in mindset comes with a heap of benefits. Because Kubernetes has ephemerality, automation and abstraction built into its very core, it can deliver us self-healing infrastructure, automated scaling, a multitude of methods and tools to secure, isolate and fully control the boundaries of it's ecosystem, and (a big one) it does not require any downtime for deployments and rollbacks.
Moving on to the meat and potatoes of this post, for the next 20-30 entries in this section of my blog I will working through the most fundamental parts of the Kubernetes eco-system.
As much as I would love to write about more advanced topics right away (like CRDS, Operators, Service Meshes and GitOps tooling), Kubernetes requires quite a deep basis into the core parts that make it work before delving into it's broader tooling.
For my own learning (and I hope anyone who is also new to learning the technology), I will be writing a series of "101" posts based on my Kubernetes lab work.
My goal is to practice what I preach and really drill fundamentals of Kubernetes into my mind and use it as a basis to go deeper into other cloud-native technologies and philosophies.
Thanks for reading, I hope future posts will be helpful to your knowledge and development of your career👌
"The man who moves a mountain begins by carrying away small stones." - Confucius