Exploring Kubernetes Node Architecture.

Photo by Danny Saltaren on Unsplash

In this guide, we will explore the Node Architecture in Kubernetes, and how your containers can communicate with each other over the network.

Pods, Nodes, and Containers

In green, you can see the pods. We have Pod 1, Pod 2, and Pod 3 on Node 1 and Pod 4, Pod 5, and Pod N on Node 2. Within those pods, you have the containers inside them. Also, you can see the one container on Pod 2 and Pod 5 which are denoted in red. You can also have multiple containers if you take a look at Pod 3. It has 2 containers and Pod 1 has 3 containers.

Those containers can communicate easily with each other using the port number & localhost. If you have two small services, one a backend, and the other one an authentication service, they can easily communicate with each other over the network same as the Pods within a cluster can also communicate with each other, but that has to go over the network. Those containers in the Pods in the picture above are running on Docker, and on your nodes, you need to have Docker installed. You can also use an alternative container engine, but it’s best to always use Docker.

Kubelet and a Kube-proxy

On those Nodes, you also have Kubelet and a Kube-proxy service running. the Kubelet is responsible for launching the pods. It’s going to connect to the master Node to get the information.

The Kube-proxy is going to feed its information about what pods are on these nodes to iptables. iptables is the firewall in Linux and it can be used to route traffic. So whenever a new pod is launched, Kube-proxy is going to change the iptables rules to make sure that your pod is routable within the cluster.

Service

The easiest way to remember how a Service works is just to imagine yourself as a Load Balancer 😅. Your service can be the ELB (Elastic Load Balancer) on AWS. This Elastic Load balancer on AWS is going to be publicly available so that clients from the internet can connect to your load balancer and your load balancer is then going to forward traffic to your Kubernetes cluster which is going to have all the Nodes listed and the traffic is all going to arrive at iptables.

iptables has then the rules to forward traffic to another node. For instance, if the Pod is on the second Node, then it will forward traffic to the pod and to the specific container in the pod. The communication between the service and the nodes is going over one port. In AWS case, you can configure your ELB to use one port configured so that all your nodes can listen to that port and iptables will route the traffic that comes from that port to the correct pod.

To translate this to a Yaml file:

apiVersion: v1
kind: Pod
metadata:
name: hello-world.example.com
labels:
app: hello-world
spec:
containers:
- name: docker-demo
image: thecraftman/docker-demo
ports:
- name: python-port
containerPort: 3000

From the configuration above, we have a container and the pod definition. spec refers to a container, and this container refers to the red block within the pod in our diagram above. The whole green pod is actually the full definition you see in your yaml configuration above. The container is everything you see under spec.

If you would have two containers, you will just have a spec with two containers.

gracias

Enjoyed the read? Leave some ‘claps’ below so others can find this post 🙂