An Intro To Kubernetes

If you know anything about me, it's that I love talking about Kubernetes. Heck, there's even an entire Kubernetes tag on this website! Therefore, I decided to share my knowledge through a series of how-to's and how-does-it-work's to hopefully convey the sheer awesomeness of Kubernetes, and why I'm so obsessed.

A long time ago, in a galaxy far, far away… monolith servers ruled the land. They were big, beefy machines with stunning specs. Really fat computers with a dedicated corner in the office to accommodate for their size. This was the beginning of servers - singular machines with phenomenal specs which dished out tens or maybe hundreds of services. At this point in time, they were the foundation of technology and many proud companies named their servers!

Well, I’m not here to talk about the past. Instead, let’s look towards the future of servers: cluster computing.

Cluster Computing?

As the name suggests, cluster computing involves the use of several physical computers which work together in an organised and orchestrated manner.

This format comes with many benefits over traditional monoliths. Most importantly, a single computer has limited hardware upgradability - there is a limit to the specs you can have in it. For example, try as I might, I cannot install 1TB RAM in my computer, nor can I have more than 16 cores (Ryzen AM4). Now, imagine I am hosting my blog on my PC and someday it suddenly blows up in popularity - my single computer can't realistically feed millions of requests, probably due to CPU and RAM being the limiting factors.

The idea of upgrading my computer is called vertical upgradability - deepening the resources owned by this server. Cluster computing introduces the idea of horizontal scalability, where you favour quantity over quality.

Another benefit is the fact that if my one node dies, that's it. My website will be inaccessible and everyone will lament the fact they can't access this awesome Kubernetes guide. With a cluster, however, I benefit from redundancy as one of the servers running my network-wide ad blocker can die, and PiHole will simply be moved to another server, and I won't have the affront of seeing ads online.

Some further benefits I will expand on shortly are better upgradability, availability and portability.

Kubernetes

This brings me to Kubernetes! It is an industry standard for cluster computing, and is one of the most prominent technologies used, alongside Apache Mesos, Docker Swarm, Nomad, and Hadoop. Interestingly, Google came up with Kubernetes and used it internally before releasing to the public and making it Open Source (Yay!). Kubernetes has a meaning, by the way: helmsman or pilot of a ship, in Greek.

One of the fundamentals of Kubernetes (K8S) is pods, which are the smallest unit of K8S. They contain containers (lol) such as Docker. Pods are able to be moved around across nodes of a cluster, hence providing the redundancy mentioned previously.

K8S provides certain facilities too, which I’ll cover very briefly.
Load Balancing allows sharing of work between nodes in the cluster, and equal distribution to ensure no node is overloaded.
K8S also allows scaling of apps, which is very useful in a production environment. Depending on demand for a certain service, K8S will automatically increase or decrease the number of pods, to make sure you’re using your resources optimally.
K8S provides facilities for exposing ports and IP addesses, with easy port mappings, similar to Docker.
And last but definitely not least, K8S will restart dead pods or move them around if the node they are running on dies or is overloaded.

Getting Kubernetes

This section is dedicated to those of you who want to get right into it! I personally run a K3S cluster on 7 single board computers with 4 core 1GHz CPUs and 2GB DDR3 RAM each. K3S is very cool as it is essentially a streamlined version of K8S and is advertised by Rancher as "batteries included but optional". Alternatively, you can run a Kind Cluster which generates a Kubernetes cluster with each node a Docker container on your machine.

Why You Want To Try K8S

Redundancy & High Availability

In a monolith server, hardware or software failures would usually impact services. As I mentioned earlier, this would equate to me seeing ads online, eww.

Cluster computing reduces this flaw, as pods exist detached from the nodes they run on. This means they can easily be moved around by the master node(s) in the case that a worker dies. This minimises downtime and uninterrupted service. To put this into perspective, it would be devastating for a bank to be down for even 30 minutes during peak hours in the days leading to Christmas! Hence Kubernetes helps minimise the impact of failures. One server on fire? Not even an inconvenience, just toss the pod elsewhere!

Blue Green Deployment

It’s a method of organising your containers and nodes to avoid downtime during upgrades. In a monolith system, if you’re upgrading your OS or HW, the system will be offline temporarily.

But with a cluster, you can upgrade nodes separately - in batches. You direct traffic away from one batch while you take it down for upgrading. The other batch(es) pick up on the slack. When the first batch has been upgraded and tested for stability, you can then redirect traffic back and repeat for the other batch(es).

This deployment is called Blue/Green as the Blue batch runs the current version while the green runs the updated version. In this method, there is no downtime and the service remains accessible.

I’ll compare this to McDonalds, to better explain. In a city, you have 2 outlets, but both need renovation. It makes logical sense to close only one at a time for renovation while the other continues to provide service.

Horizontal Scalability

As mentioned previously, clustering shifts focus from building the best server you can to instead buying the most servers you can without causing a nation-wide blackout. While you already have the benefit that 10x Ryzen CPUs is better than just 1, Kubernetes makes it extremely intuitive and fairly seamless to join new servers to a pre-existing cluster. If you are running bare-metal servers, for example, this would let your infra team increase your overall computing power without downtime or even re-building the entire cluster.

And On That Note...

I hope I've convinced you on the awesomness of Kubernetes. If so, you can expect more blogposts on [hopefully] a weekly basis, covering the ins and outs of K8S from pod/service creation to Databases on Kubernetes!