Kuberntes Mental Model for beginners

Image Source: https://kubernetes.io/

k8s is an open-source cluster management tool for container orchestration.

k8s, a CNCF graduated project, is inspired by Google’s BORG combined with best-of-breed ideas and practices from the community. Thought backed by Google, presently all major cloud providers, (AWS, Azure, Google Cloud, OpenStack & others) support k8s.

Let's discuss the ideas the makes up for a modern k8s.

Kubernetes And Abstractions

Everything in k8s is entirely designed around its restful API-Server, which is responsible for doing the actual work in reality what a developer intends to do which is often described using declarative abstractions. There are no private privileged API or other magic system-only calls. The following logical abstractions constitute a good understanding of the mental model of kubernetes

Pod

An abstraction of a group of tightly-coupled containers which share common Kubernetes services like shared storage, networking interfaces, deployment, and updates to them. When deployed, k8s API-server provisions the pod with all the resources requested.

They do not self-heal i.e a manually created pod won't be restarted in the event of pod/node failure or won't migrate in the event of a shortage of computing resources.

** One thing important to understand regarding pod’s networking is that they can talk to each other by their own IP address. k8s also provides DNS services for every pod to be reachable using their FQDN.

A pod’s lifecycle typically looks like

src: supergiant.io

Note: As most of the applications/examples use a single container in a pod, people are aligned to use the name pod and container interchangeably. This is clearly wrong, remember, a pod always represents a group of containers.

Note: As most of the applications/examples use a single container in a pod, people are aligned to use the name pod and container interchangeably. This is clearly wrong, remember, a pod always represents a set of containers.

Job

A pod expected to terminate upon completion (suitable for batch jobs).

Services

A logical group of pods and a policy by which they can be accessed.

Upcoming: More on the services could be found in the networking section.

Replication Controller

An abstraction designed to maintain the desired number of pods (replications). It watches the API-server and responds to changes to pod failure, node-failure, etc…

Can’t support upgrades, reverting failed changes.

Replica Set

For simplicity, assume it as a next-generation Replication Controller (with selector support).

Deployment

Replica Set which supports rolling-updates, revering failed changes. Creates replica-sets and manages them.

Can’t guarantee pod ordering and unique-naming of the pods useful for stateful applications.

Stateless applications like front-end apps, etc…. are provisioned as deployments.

Containers/Pod/ReplicaSet/Deployment

Statefulset

A Deployment which provides guarantees about the ordering and uniqueness of these Pods along with data persistence often in the forms of persistent volumes.

Deployment Vc StatefulSet.

A developer application must fit into one of the above-defined abstractions to be provisioned in a k8s environment. Some of the complicated-monolithic applications could be decomposed into small micro-services and each micro-service could fit in one of the above-mentioned abstractions.

Other useful k8s abstractions

These abstractions fill up the voids a developer finds to dynamically provision applications at scale. Kubernetes provides a well-defined approach for one to use custom resource definitions (CRD) for developers and third parties vendors to develop API objects.

Hopefully, a mental model is formed regarding kubernetes and its abstractions.

If you like my work, buy me a coffee.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store