Kubernetes Overview

Kubernetes is for orchestrating container workloads, that is monitoring, controlling and managing. Kubernetes does not itself run containers. It needs to work with a container runtime to do that. It does monitor what is going on and tells the container manager what needs to be done. (If you don’t know what a container is, check this out.)

Kubernetes doesn’t so much run individual containers as run a kind of ‘super-container’ called a pod. Each pod within Kubernetes has a single IP address allocated and has a single set of system resources. Its possible for multiple containers to be run within a pod, sharing the IP and system resources, but normally its one pod → one container.

Kubernetes (pronounced Koo-ber-net-ees) translates from Greek as helmsman and is often abbreviated to k8s – 8 represents the eight letters between k & s in Kubernetes (just as i18n is an abbreviation of “internationalisation”).

Kubernetes expects the container manager to work with its Container Runtime Interface (CRI). This gives you three options for container manager:

Containerd
CRI-O
Docker (recent version must use CRI-Docker as a intermediary)

By default all three of these end up using the “runc” low-level container runtime.

PodMan does not currently support CRI and does not work directly with Kubernetes. Container images prepared using PodMan however are OCI formatted and can be run by Docker, containerd or CRI-O within Kubernetes.

Kubernetes Terms

Cluster: whilst Kubernetes can run on a single host it typically runs across a number of servers and manages them as a single unit known as a cluster.

Node: one of the individual servers running within a Kubernetes cluster.

Master node / control-plane: The node that hosts the processes that control the cluster. These processes run inside containers. A basic cluster will have one master node but it is possible to improve resiliency by running a set of control-plane processes on multiple hosts (i.e. A control-plane runs across multiple nodes. There is no single master node).

kubelet: the primary Kubernetes code that runs on each node. It is installed as local software on each host (not within a container) and runs as a Unix service.

kubectl: command line utility that interacts with the Kubernetes cluster. Talks to the kubelet service running on the host. Used to operate Kubernetes.

Kubeadm: command line utility. Used in the set up of Kubernetes. Not normally used in operating a cluster – that’s Kubectl.

Pod: the processing unit Kubernetes manages. Each pod will normally run a single container though it is possible for more than one container to run in a pod. Pods run on nodes and are directly managed by the container runtime under the control of Kubernetes.

Service: A placeholder for network addressing. Pods can be short-lived and can move between nodes. A Kubernetes service is a placeholder for a TCP or UDP port and is equally visible and addressable across a cluster. Instead of trying to find a relevant pod, you contact the Kubernetes service which uses configuration to pass the request to an appropriate pod wherever it is running.

Secrets: When pods start up they may need passwords or certificates to access databases or remote resources. Kuberentes Secrets are a configuration element intended to store such items and make them available to pods securely.

Control Plane

When the Kubernetes control plane starts the following pods/containers are started. They run in the namespace “kube-system” and so aren’t visible by default (use “kubectl get pods -A” or “kubectl get pods –all-namespaces”.

kube-apiserver: Receives requests from clients and sets the desired state
kube-controller-manager: The main controlling process that tries to move from current state to the desired state
kube-proxy: runs on every node (including master) routes UDP/TCP and performs basic load balancing
kube-scheduler: The processes that determines on which node a pod should be run
etcd: The data store for the Kubernetes configuration
coredns: Provides the DNS service mapping from hostname to IP etc.

Networking

The etcd and coredns components of the control plane were not created by the Kubernetes project. They are third party software used within the Kubernetes product. Another aspect not covered by the Kubernetes project is networking. You have to use some kind of third party cloud/container networking software to link the operating Pods. If you install Kubernetes yourself you will have to source and install the networking software. A number of network offerings are available as listed here).

They range from the basic, like Flannel to a more feature rich that include various types of network policy and security enforcement, like Project Calico.

Operation

Kubernetes works a bit differently to basic container managers like Docker.

Container: imperative operation
Kubernetes: declarative operation

If you are using a container manager and you want three containers running, you issue a “run” command three times. You then need to monitor the state of the containers yourself. The container manager will give you tools to help but if one of the containers crashes for some reason you will have to detect this yourself and issue another “run” command to get back to your desired state.

With Kubernetes you “declare” that you want three pods / containers to be running. Kubernetes will then look at what is current running and decide itself what needs to be started. It will then issue the command the start 3 containers if necessary. It regularly checks that the current state matches your desired state and takes action itself to correct any discrepancies.

The declaration of your desired state is made via the Kubernetes API by passing the specification of Kubernetes “objects”.

Common Kubernetes Objects

Pod	A “super-container” that normally contains one running container. In simple scenarios can be defined directly but often created via other objects (ReplicaSet, Deployments).
Replica Set	A set of pods that have the same task (i.e. based on the same container image)
Deployment	A higher level object used to manage replica sets. During a version upgrade, a single deployment will have an ‘old’ replica set being wound down and a ‘new’ replica set being generated.
Service	A placeholder for TCP/UDP traffic. Pods can be short lived entities and can move about. The service gives a stable target for entities trying to contact a set of pods.
Secret	Password or certificate data meant to be kept secret. Using a Kubernetes secret avoids placing the confidential data in a configuration file or environment variable.

Defining Kubernetes Objects

The simplest way to define Kubernetes objects is creating “yaml” files and passing them to the control plane/ master node using the kubectl command.

apiVersion: v1
kind: Pod
metadata:
  name: examplepod
  labels:
    app: myApp
spec:
  containers:
  - name: localCtrName
    image: registry.fortaspen.com/library/exampleImage
    ports:
      - containerPort: 80
  imagePullSecrets:
  - name: regcred

Kubernetes yaml files have four top level sections

apiVersion – the API version being used in the definition
kind – the Kubernetes object type such as Pod, ReplicaSet or Service
metadata – fields identifying the object, includes the name but can include namespace
spec – the detail of the object being defined

To see Kubernetes configuration in action, check out our case study of a simple 3 tier application.