· 955 words · 5 minute read

A highschool-level summary to Kubernetes

For a client I had to learn about Kubernetes. I found the excellent O’Reilly book “Kubernetes: up & running” and made a quick summary. I hope it’s useful for others as well.

The basics #

Kubernetes is also called k8s. It’s a way to create an infrastructure that is distributed (consists of many parts), reliable (should work consistently even if a part fails or is updated), scalable (can grow big).

Kubernetes objects are immutable: once on artifact is created it doesn’t change via user modification. To ‘update’ an object you replace it with a new version. This is different from mutable, where you create and then change the artefact to update (install new stuff, run updates, etc). The key benefit of immutable objects is that you have a record how it was created: you can create a new object with the same state incredibly easily.

You should not log into k8s objects to fix stuff. That’s an anti-pattern

Kubernetes is declarative. You describe the desired state of the system, and Kubernetes will fix it for you. This is different from imperative, where you give a sequence of instructions.

Kubernetes is selfhealing. Kubernetes tries to fix the system continuously to match the declarative state (if an object gets stuck, Kubernetes destroys it and creates a new version).

Objects in Kubernetes are decoupled (running independent from each other, micro-services). They have APIs and there are load balancers. To scale a service you just add more instances called replicas (by updating declaration, or letting k8s do it: autoscaling)

Primary objects #

Cluster: collection of nodes with pods with containers. Contains at least 1 worker node and 1 control plane (managing the cluster’s state, API-server, scheduler, CoreDNS service, discovery, and the scheduling of workloads – previously called master node). Kubernetes tries not to run stuff on the control plane.

Node: the thing that runs the pods. Can be a virtual machine, a real machine, a server in cloud. This has own OS&processor&disk&memory&Docker-instance. Nodes have: a name, status (ready, master), age (runtime) and version.

Pods: a group of containers that is a single deployable unit. Also does some DNS to handle traffic. All containers in a pod get to go on the same node (execution environment) and can talk to eachother through localhost. Different pods on same node might as well be on different servers (they communicate through the Kubernetes network model). Containers in a pod can mount the same volume. A pod can define what it needs (this much memory, a gpu, etc) but shouldn’t really care what type of node it runs on. (this is more difficult with LLM and genAI where you need more control over host machine).

Container: is a Docker image. Used to be system-containers (mimics a VM, has ssh, cron, etc) but now prefer application containers that run a singe program. That’s easier for setting budgets and creating pods. Btw: if your container goes over resource-budget, it gets killed and restarted. Data isn’t safe within the container (use persistent storage for that).

Job: creates temporary pods that are destroyed after a succesful termination. Can be part of a ‘work queue’ from a worker-job. Can be a cron-job.

Metadata #

Namespace: for pods (containers get same namespace as pod), services and deployments. Used for isolation and access control (which users&microservices can interact). Nodes cannot have namespaces. Namespaces cannot be nested (but pods can have identical names if they are in separate namespaces, so you can use in API: namespaces/default/pods/podname)

Label: assigned to pods (not containers). Used to filter/select/target pods. Consists of key/value pair: ~[acme.com/app-version](http://acme.com/app-version)~: 1.0.0 or env:prod or ver:2. With this you can do stuff like update all production pods of app blabla with version <2. Nodes can also have labels (gpu=yes).

Annotation: similar to labels key/value pair, but is used to add descriptions (mainly by externtal tools). Can store larger, more freeform data. Example: “I created this pod just for testing, can be destroyed at will” or build-hash, commit-message, etc.

More complex concepts #

Service: is cluster-wide and points to nodes, does stuff like load balancing, naming, discovery (→ to isolate microservices from eachother). Is not something that ‘runs’, is simply an abstraction for exposing pods in a stable and scalable way. They can expose pods to external traffic and maintain stable endpoints even if pods are replaced.

Ingress object: frontend combining multiple microservices into a single externalized API surface area. Manages HTTP(S) traffic, often includes SSL termination.

Replica set: acts as a cluster-wide pod manager (managed by a deployment, see below)

Workload: A workload in Kubernetes refers to an application running on the cluster. Workloads can be comprised of single or multiple pods. They are: 

  • deployments (stateless application like wordpress). It is ensured a specified number of identical pods are running (replicasets)
  • Statefulsets persistent identity or storage (databases like mysql)
  • daemonsets (infrastructure-level services like logging or monitoring)
  • jobs (run a task until completion)
  • cronjobs (similar to job, but run at set times, example optimize images in wordpress or nightly backups)

Example: my wordpress cluster has a deployment with 3 identical pods. Kubernetes handles load balancing. If one pod fails, traffic gets sent to other 2 pods and failing pod gets destroyed and new one created. Updates to new Wordpress-version happens per pod: terminate old pod, new pod online, repeat until all pods are updated.

User roles in Kubernetes #

There are four standard roles (for humans) within Kubernetes:

  • cluster-admin (manage entire cluster)
  • admin (manage a namespace)
  • edit (can modify namespace)
  • view (read-only access).

For more detailed and practical information, I can really recommend the book Kubernetes: Up and running on which most of this summary was based. I enhanced it with information from ChatGPT; as Kubernetes has been described extensively online, LLMs can reliably give details about it.