Chapter 4 of the KCNA exam: Basic knowledge needed to learn kubernetes

Article directory

1. Introduction to Kubernetes

Kubernetes is a very popular open source container orchestration platform that can be used to automate the deployment, scaling and management of containerized workloads. In this chapter, we will discover the basic architecture of a Kubernetes cluster and its components.
Originally designed and developed by Google, Kubernetes was open-sourced in 2014, with version 1.0 being donated to the newly formed cloud-native computing.

2. Learning Objectives

By the end of this chapter, you should be able to:

Discuss the basic architecture of Kubernetes.
Explain the different components of the control plane and worker nodes.
Learn how to get started with a Kubernetes setup.
Discuss how Kubernetes runs containers.
Discuss scheduling concepts in Kubernetes.

3. Kubernetes Architecture

Kubernetes is often used as a cluster, which means it spans multiple servers working on different tasks and distributes the load of the system. This was an initial design decision based on Google's needs, with billions of containers launching every week. Given the high vertical scalability of Kubernetes, it is possible to have clusters of thousands of server nodes across multiple data centers and regions.
From a high-level perspective, a Kubernetes cluster consists of two distinct server node types:

Control Plane Node(s)
These are the brains of the action. Control plane nodes contain various components that manage the cluster and control various tasks such as deployment, scheduling, and self-healing of containerized workloads.
Worker Nodes
Worker nodes are where applications run in the cluster. This is the only job for worker nodes, they do not have any further logic to implement. Their behavior, such as whether they should start a container, is completely controlled by the control plane nodes.

insert image description here

Kubernetes Architecture
Similar to the microservices architecture you choose for your own applications, Kubernetes incorporates multiple smaller services that need to be installed on nodes.

master node components:

kube-apiserver: This is the core point of Kubernetes. All other components interact with the api server, which is where users access the cluster.
etcd: The database that holds the cluster state. etcd is an independent project and not an official part of Kubernetes.
kube-scheduler: When a new workload should be scheduled, kube-scheduler will select an appropriate worker node based on different properties such as CPU and memory.
kube-controller-manager: Contains various non-terminating control loops that manage the state of the cluster. For example, one of the control loops ensures that the desired number of your application is always available.

node node components:

Container runtime: The container runtime is responsible for running containers on worker nodes. For a long time, Docker was the most popular choice, but it is now being superseded by other runtimes such as containerd .
kubelet: A small proxy that runs on every worker node in the cluster. The kubelet talks to the api server and the container runtime to handle the final stage of starting the container.
kube-proxy: A network proxy that handles communication inside and outside the cluster. If possible, the kube proxy tries to rely on the networking capabilities of the underlying operating system instead of managing the traffic itself.

Notably, this design allows applications already launched on worker nodes to continue running in the event that the control plane is unavailable. Although many important functions, such as scaling, scheduling new applications, etc., will not be possible to implement when the control plane is offline.
Kubernetes also has a concept of namespaces, not to be confused with the kernel namespaces used to isolate containers. Kubernetes namespaces can be used to divide a cluster into multiple virtual clusters, which can be used for multi-tenancy when using mul.

4. Kubernetes build

Setting up a Kubernetes cluster can be accomplished in many different ways. With the right tools, creating a test "cluster" is very easy:

If you want to set up a production-grade cluster on your own hardware or virtual machines, you can choose one of the various installers:

Some vendors are starting to package Kubernetes into a distribution and even offer commercial support:

These distributions often choose a stubborn approach and provide additional tools when using Kubernetes as a central part of their framework.
If you don't want to install and manage it yourself, you can use it from your cloud provider:

Interactive Tutorial - Creating a Cluster
In this interactive tutorial, you can learn how to set up your own Kubernetes cluster using Minikube .

5. Kubernetes API

Kubernetes APIIt is the most important component in a Kubernetes cluster. Without it, it is impossible to communicate with the cluster, every user and every component of the cluster itself needs the api-server.
Access Control Overview, Retrieved from Kubernetes Documentation
Before a request is processed by Kubernetes, it must go through three stages:

Authentication
The requester needs to provide a way to authenticate against the API. Typically digitally signed certificates (X.509) or external identity management systems are used. Kubernetes users are always managed externally. Service accounts can be used to authenticate technical users.
Authorization
It determines what the requester is allowed to do. In Kubernetes, this can be achieved through role-based access control (RBAC).
Allow control to add link description
In the final step, the admission controller can be used to modify or validate the request. For example, if a user tries to use a container graph from an untrusted registry

An admission controller may block this request. Tools like Open Policy Agent can be used to manage admission control externally .
Like many other APIs, the Kubernetes API is implemented as a RESTful interface exposed over HTTPS. Through this API, users or services can create, modify, delete or retrieve resources residing in Kubernetes.

6. Running containers on Kubernetes

How is running a container on a local machine different from running a container in Kubernetes? In Kubernetes, instead of launching a container directly, Pods are defined as the smallest unit of computation, which Kubernetes turns into a running container. We'll learn more about Pods later, but for now think of it as a wrapper around a container.
When creating a Pod object in Kubernetes, there are several components involved before getting the container running the node.
Here is an example using Docker:

To allow the use of other container runtimes instead of Docker, Kubernetes introduced the Container Runtime Interface (CRI) in 2016 .

containerd: Containerd is a lightweight, high-performance implementation of running containers. Arguably the most popular container runtime out there. It is used by all major cloud providers of Kubernetes-as-a-Service offerings.
CRI-O: CRI-O was created by Red Hat and has a similar codebase closely related to podman and buildah.
Docker: This standard has been around for a long time, but was never really used for container orchestration. The use of Docker as a Kubernetes runtime has been deprecated and will be removed in Kubernetes 1.23. Kubernetes has a great blog post that answers all your questions on this subject.

Creating containers with containerd is much simpler than with Docker
containerdand CRI-Othe idea is very simple: provide a runtime that contains only what is absolutely necessary to run the container. However, they have some additional features, such as the ability to integrate with container runtime sandbox tools. These tools try to solve the security problems that come with sharing the kernel among multiple containers. The most commonly used tools are:

gvisor : Created by Google, provides an application kernel that sits between the containerized process and the host kernel.
Kata Containers : Provides a secure runtime for lightweight virtual machines, but behaves like containers.

7. Networking

Kubernetes networking can be very complex and difficult to understand. Many of these concepts are unrelated to kubernetes and are covered in the container orchestration chapter. Likewise, we have to deal with a large number of containers that need to communicate across a large number of nodes. Kubernetes distinguishes between four network problems that need to be solved:

Container-to-Container Communication
This can be solved with the Pod concept, which we will learn about later.
Pod-to-Pod Communication
This can be solved by overlay networks.
Pod-to-Service communication
on the node through kube-proxy and packet filtering to achieve
External-to-Service communication
on the node through kube-proxy and packet filter (packet filter).

There are different ways of implementing networking in Kubernetes, but there are also three important requirements:

All pods can communicate with each other across nodes.
All nodes can communicate with all pods.
There is no network address translation (NAT).

To achieve networking, you can choose from a variety of network providers:

In Kubernetes, each Pod has its own IP address, so no manual configuration is required. Additionally, most Kubernetes setups include a DNS server add-on called core-dns , which provides service discovery and name resolution within the cluster.

8. Scheduling

In its most basic form, scheduling is a subclass of container orchestration that describes the process of automatically selecting the correct (worker) nodes to run container workloads. In the past, scheduling was more of a manual task, with system administrators choosing the right server for an application by keeping track of available servers, their capacity, and other attributes such as their location.

In a Kubernetes cluster, the kube scheduler is the component that makes scheduling decisions, but is not responsible for actually launching the workload. The scheduling process in Kubernetes always starts when a new Pod object is created. Remember, Kubernetes uses a declarative approach, where the Pod is just described first, and then the scheduler chooses a node where the Pod will actually be started by the kubelet and the container runtime.

A common misconception about Kubernetes is that it has some form of "artificial intelligence" to analyze workloads and move pods around based on resource consumption, workload type, and other factors. The fact is that the user has to provide information about the needs of the application, including requests for CPU and memory and the properties of the nodes. For example, a user can request that their application requires two CPU cores, 4g of memory, which is best scheduled on a node with fast disks.
The scheduler will use this information to filter all nodes that meet these requirements. If multiple nodes meet the demand on average, Kubernetes will schedule Pods on the node with the smallest number of Pods. This is also the default behavior if the user does not specify any further requirements.

The desired state may not be established, for example, because the worker nodes do not have enough resources to run the application. In this case, the scheduler will retry to find an appropriate node until the state can be established.

9. Other resources

9.1 The History of Kubernetes and the Legacy of Borg

From Google to the world: The Kubernetes origin story, by Craig McLuckie (2016)
Large-scale cluster management at Google with Borg, by Abhishek Verma, Luis Pedrosa, Madhukar R. Korupolu, David Oppenheimer, Eric Tune,John Wilkes (2015)

9.7 Kubernetes Security Tools

9.8 Kubernetes Playground

Play with Kubernetes

✈ Recommended reading: