Orchestration: Managing the Linux Herd

In the previous lessons, we learned how to run one container. But a modern tech company might run 10,000 containers across 500 servers. You can't manually run docker run on 500 machines.

You need an Orchestrator.

Kubernetes (K8s) is the world's most popular orchestrator. In this lesson, we will look at K8s from the Linux Administrator's perspective. We will see how K8s takes the kernel features we've learned (Namespaces, Cgroups, Overlays) and "Orchestrates" them across a cluster.

1. The Pod: A Shared Namespace

In Docker, one container = one set of namespaces. In Kubernetes, we have the Pod. A Pod is a group of one or more containers that share the same Network and IPC namespaces.

This means that if you have a Web Server and a Database inside the same Pod, they can talk to each other on localhost, just like two processes on a normal Linux server!

2. The CRI (Container Runtime Interface)

Kubernetes is "Agnostic." It doesn't care if you use Docker, Containerd, or CRI-O. It talks to the runtime through a standardized plugin called the CRI.

K8s: "Please start a Pod with these CPU limits."
CRI: "Understood. I'll tell containerd to set up the Cgroups."

3. Flannel and Calico: Virtual Networking

How can a container on Server A talk to a container on Server B using a private IP? Linux doesn't do this by default. K8s uses a CNI (Container Network Interface) plugin.

It creates a Virtual Bridge (like we learned in Module 11).
It uses VXLAN (Virtual Extensible LAN) to "Tunnel" container traffic through the host's actual network.

4. The Kubelet: The On-Site Manager

Every Linux server in a K8s cluster runs a process called the Kubelet.

The Kubelet is the "Primary Admin" of the local machine.
It reports the machine's RAM and CPU to the central Master.
It monitors the local containers and restarts them if they crash.

5. Persistent Volumes: Moving the Disk

If a container moves from Server A to Server B, how does its data follow it? K8s uses CSIs (Container Storage Interface). It automatically "Mounts" (as we learned in Module 12) a remote network drive (NFS/EBS/Longhorn) to the local /var/lib/kubelet directory of whatever server the container happens to be running on.

6. Identification: Troubleshooting a Node

If a K8s Node (server) is failing, you don't use K8s commands alone. You use your Linux skills.

# 1. Is the Kubelet service running?
sudo systemctl status kubelet

# 2. Is the container runtime healthy?
sudo crictl info

# 3. Are the Cgroups full?
cat /proc/pressure/cpu

7. Example: A K8s Resource Pressure Monitor (Python)

K8s relies on Linux to "Evict" (kill) containers when the server is too busy. Here is a Python script that monitors the system's "Stall" time. If the system is stalling, it predicts that K8s is about to start killing your apps.

import os

def check_k8s_node_pressure():
    """
    Checks for CPU and Memory stalls that indicate 'Node Pressure'.
    """
    print("--- Linux K8s Node Health Audit ---")
    
    try:
        with open("/proc/pressure/memory", "r") as f:
            psi_content = f.read()
            # If 'full' > 0 for avg10, the system is struggling to swap/reclaim
            print(f"Memory Pressure: {psi_content.splitlines()[0]}")
            
        with open("/proc/pressure/cpu", "r") as f:
            cpu_content = f.read()
            print(f"CPU Pressure:    {cpu_content.splitlines()[0]}")
            
    except FileNotFoundError:
        print("PSI metrics not supported on this kernel.")

if __name__ == "__main__":
    check_k8s_node_pressure()

8. Professional Tip: Use 'Node Exporter'

If you are running a cluster, install the Prometheus Node Exporter. It translates every kernel metric we've discussed in this course into a format that Grafana can understand. This gives you a "Cockpit" where you can see the health of 500 servers on one screen.

9. Summary

Kubernetes is the manager; Linux is the worker.

Pods are shared namespaces for collaboration.
CRI, CNI, and CSI are the protocols K8s uses to talk to the Linux subsystems.
Kubelet is the bridge between the cluster and the local systemd / runc.
VXLAN tunnels create the illusion of a single global network.
Node troubleshooting requires deep Linux skills, not just K8s knowledge.

In the final lesson of this module, we will look at the ultimate shield: Container Security—Capabilities and Seccomp.

Quiz Questions

Why do containers in the same Pod share a Network namespace?
What is the role of the Kubelet on a Linux server?
How does a CNI plugin allow containers on different hosts to communicate?

Continue to Lesson 6: Container Security—Capabilities and Seccomp.

The Scalable Orchestra: Linux and Kubernetes