Kuberntes Mental Model for beginners
- What is kubernetes(k8s)?
k8s is an open-source cluster management tool for container orchestration.
- Provisioning and deployment
- Service Discovery and DNS resolution
- Monitoring (Health and Liveness)
- Management (Rollouts & rollbacks)
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
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
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.
A pod expected to terminate upon completion (suitable for batch jobs).
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.
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.
For simplicity, assume it as a next-generation Replication Controller (with selector support).
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.
A Deployment which provides guarantees about the ordering and uniqueness of these Pods along with data persistence often in the forms of persistent volumes.
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
- Secret — stores password, certs,truststore/keystore, docker-registry, etc..
- ConfigMap — configuration, environmental variables as a map
- Certificate / ClusterIssuer/ CSR — issuing certs with rotation for TLS/SSL
- SC / PV / PVC — Storage Class, persistent Volumes and claims.
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.