How Kubernetes works

Container Isolation

  • Linux Namespaces ensure that each process sees its own personal view of the system.

  • Linux Control Groups (cgroups) limit the amount of resources process can consume.

Linux Namespaces

  • By default, all processes in a Linux system belong to one namespaces.

  • The different kinds of namespaces that exist are:

    • Mount (mnt)

    • Process ID (pid)

    • Network (net)

    • Inter-process communication (ipc)

    • UTS (UNIX Timesharing System for having a separate hostname)

    • User ID

  • Each container uses its own Network namespace and thus sees its own set of network interfaces.

Limits to Container Portability

  • All containers running on a host uses the host’s Linux kernel. Hence, if a containerised application requires a specific kernel version, it may not work on that host’s container

  • A containerised app built for a specific hardware architecture can only run on another machine that has the same architecture.

Kubernetes Runtime Components

../../_images/k8-onprem-and-cloud.png

The Kubernetes control plane can work across different environments

../../_images/AKS01.png

Kubernetes components of the Azure Kubernetes Service

../../_images/AKS02.png

The customer managed worker nodes are Azure VMs

../../_images/Minikube01.png

Local development machine using the minikube single worker architecture.

../../_images/On-PremiseKubernetes.png

The non-cloud Kubernetes architecture

  • Kubernetes master: Is responsible for managing and scheduling the workloads in addition to network and communication across the entire cluster. It is also called the Control Plane.

  • Control Plane: The control plane continually runs in a loop, responding to changes in the cluster and works to make the actual state of all objects in the system match the desired state.

  • kubectl: command line interface to the api-server

  • api-server: entry point to the control plane. Provides the interaction for management tools such as kubectl or the Kubernetes dashboard. Manages requests from the worker nodes.

  • etcd: highly available distributed open source key/value store that can be accessed by all nodes in the cluster. It stores the configuration data of the cluster’s state.

  • controller manager: Oversees several smaller controllers and checks desired state to current state and performs actions such as replicating pods and handling node operations.

  • scheduler: assigns newly created pods to a node and starts the node. By default, the scheduler only schedules pods to worker nodes as there is a tain on the master node that prevents normal nodes from being run on the master node.

  • Kubernetes DNS server: the DNS server used in the cluster’s internal network

  • Worker nodes: runs workloads according to the schedule provided by the master. The interaction between the master and worker nodes is known as the control plane.

  • kubelet: a node agent that is responsible for the containers in the worker node. It acts as a conduit between the api-server and the container runtime in its node.

  • kube-proxy: balances network traffic between application components.

  • container runtime: the software that runs containers on the node, typically Docker or any implementation of the Kubernetes container.