After a dive into learning Kubernetes I am at that magical point where i am hugely confident with it, but still have a lot to learn :)

Understanding Kubernetes is surprisingly easy, it consists of two main parts, the control plane and a set of nodes.

I recommend that you start with the idea of a cluster of computers that have various attributes for each (essentially, focus on the nodes and not the control plane).

The cluster is able to host many applications, and many instances of each type of application.

Kubernetes job is to manage the applications running on the cluster, it knows where the applications are, and how to communicate with them.

From the bottom, up.

Nodes

A node is best thought of as a physical machine. It has a set of resources, RAM, Disk, CPU, and Network, that are available for use.

Pods

A pod lives on a node. You can think of a pod as a virtual machine. There can be one or more pods per node. Each pod has its own IP address.

Containers

This is where the application lives, there can be more than one containers per pod, but they share the same IP, and cannot share a port.

These aren’t kubernetes per se, they can be any container that kubernetes can manage, docker, containerd, and so on.

Deployments and StatefulSets

There are two main ways of managing your pods in Kubernetes. One is for pods that will have no stored state, deployments. These are where your pods that manage the business logic, or API, or controller logic, will be.

The second type, the stateful sets are for applications that store state, databases. These need access to disk that will (usually) not be on the same node as the pod (but can be), instead the disk is normally somewhere that the entire cluster can access, so that the stateful container can be deployed to a pod on any node.

The deployment and stateful sets configuration documents are where the number of replica pods is determined, and where scaling is managed for that set of pods.

Note: There are DaemonSets too, but they’re not really used in the same way as the other two.

Services

The transient nature of a pod means that discovery can be problematic, so services run in front of a collection of pods and act as a load balancer inside the cluster for that set of pods.

The ClusterIP service will send traffic to a randomly selected pod that it manages. If a service definition sets ClusterIP to None then kubernetes will create a headless service.

Services use selectors to determine which pods they are managing. Selectors use labels in pod configurations to find the pods.

A service can be used to route traffic to more than one set of ports on the pods depending on the port that it receives traffic on.

Connections to the rest of the world.

It’s all very well to have all this computing power in the cluster with all these fancy applications, but, there needs to be a way for traffic to enter/exit the cluster, and that’s where Ingress and Load Balancer come in (note; Node Port also allows traffic in, but it shouldn’t be used directly in prod and, instead, Load balancer will create one and manage it).

Ingress, Loadbalancer, and Node Port are all services, like ClusterIP.

Ingress is, essentially, a reverse proxy, that receives requests to your cluster on a (presumably) public IP, and routes the request to the correct service that manages the pods that satisfy the request (which might involve contacted other services that manage other pods).

You can think of an ingress like a nginx or apache2 reverse proxy, different routes get matched to different services on whatever port they’re configured for.

A LoadBalancer is typically used in conjunction with a cloud service provider’s load balancer. Meaning that the cloud service load balancer holds the public IP, it forwards traffic to the LoadBalancer service that then forwards the traffic to the appropriate service inside the cluster.

Summary

This should have created a good picture in your mind of what you are doing when you configure kubernetes.