03 Kubernetes Core Concepts #

In this section, we will introduce the core concepts of Kubernetes.

What is Kubernetes #

According to the official website, Kubernetes is an industrial-grade container orchestration platform. The word Kubernetes is derived from Greek and can be translated into Chinese as “舵手” (helmsman) or “飞行员” (pilot). In some sources, you may come across the term “ks” or “k8s,” which is an abbreviation formed by replacing the eight letters “ubernete” with the number “8”.

But why was Kubernetes named after “舵手” (helmsman)? Take a look at this image:

It depicts a ship carrying a stack of containers, navigating the sea to deliver these containers to their respective destinations. Previously, we introduced the concept of containers, which in English also means “集装箱” (shipping containers). Kubernetes adopts this metaphor, aiming to become the ship that transports and manages these containers.

This is the reason behind choosing the name Kubernetes for this project. More specifically, Kubernetes is an automated container orchestration platform responsible for application deployment, elasticity, and management, all based on containers.

Kubernetes has the following core functionalities #

• Service discovery and load balancing;
• Automated container placement, also known as scheduling, which involves placing a container on a machine within a cluster. Kubernetes helps with storage orchestration, allowing the lifecycle of storage to be connected to the lifecycle of a container;
• Automated container recovery. In a cluster, there may be issues with the host machine or the operating system that can render a container unavailable. Kubernetes automatically recovers these unavailable containers;
• Automated application deployment and rollback, as well as managing configuration secrets related to the application;
• Kubernetes can handle batch execution for job-type tasks;
• Kubernetes also supports horizontal scaling to make the cluster and applications more elastic.

Now, we would like to provide three examples to introduce the capabilities of Kubernetes in a more practical way.

Scheduling #

Kubernetes can place the containers submitted by users on a node within the cluster managed by Kubernetes. The scheduler is the component responsible for this capability. It observes the size and specifications of the container being scheduled, such as the required CPU and memory. It then finds a relatively idle machine in the cluster for placement. In this example, it may place the red container on the second available machine to complete the scheduling process.

Automated Recovery #

Kubernetes has a node health check feature that monitors all the host machines in the cluster. When a host machine or software on it fails, the node health check automatically detects it. Kubernetes then automatically migrates the containers running on these failed nodes to a healthy host machine, enabling automatic recovery of the container cluster.

Horizontal Scaling #

Kubernetes has the ability to check the workload of a business. If the business itself has high CPU utilization or long response times, Kubernetes can perform horizontal scaling by increasing the number of instances of that business.

In the example below, if the yellow workload is overly busy, Kubernetes can scale up from one instance to three instances. Afterwards, it can use load balancing to evenly distribute the workload that was originally directed to the first yellow instance across the three yellow instances, thereby improving response time.

These are brief introductions to the three core capabilities of Kubernetes.

Architecture of Kubernetes #

The architecture of Kubernetes is a typical two-tier architecture and server-client architecture. The Master serves as the central control node and connects to the Nodes.

All UIs, clients, and user-side components only connect to the Master, sending desired states or commands to the Master, which in turn distributes these commands or states to the corresponding Nodes for execution.

The Kubernetes Master consists of four main components: API Server, Controller, Scheduler, and etcd. They are illustrated in the diagram below:

• API Server: As the name suggests, it handles API operations. All components in Kubernetes connect to the API Server for message transmission; components do not generally connect with each other independently.
• Controller: The controller manages the state of the cluster. For example, the two examples mentioned earlier, automatic container repair and horizontal scaling, are completed by the Controller in Kubernetes.
• Scheduler: The scheduler assigns workloads to nodes based on their CPU and memory requests. For example, in the first example we mentioned earlier, the scheduler finds a suitable node to place a submitted container based on the container’s CPU and memory requirements.
• etcd: etcd is a distributed storage system where the API Server stores the metadata it needs. Etcd itself is a highly available system, ensuring the high availability of Kubernetes Master components through etcd.

As for the components mentioned earlier, the API Server can be horizontally scaled, while the Controller is a deployable component that supports hot standby. Although there is only one active Controller, it can be hot backed up.

Architecture of Kubernetes: Node #

Kubernetes Nodes are responsible for running actual workloads, and each workload runs in the form of a Pod. Now, let’s introduce the concept of Pod. The critical component that runs Pods on the Node is called kubelet, which receives the Pod’s running status requirements from the API Server and submits them to the Container Runtime component, illustrated below.

The kubelet creates an environment on the OS for running containers and ultimately runs the containers or Pods. It also manages storage and networking. Kubernetes does not directly operate on storage and networking, but relies on Storage Plugins and Network Plugins. Users or cloud providers can develop their own Storage Plugins or Network Plugins to complete storage and network operations.

In the Kubernetes environment, there is also the Kubernetes Network, which is used to provide a service network for networking. (We will also introduce the concept of “service” later.) The component that completes service networking is Kube-proxy, which uses the abilities of iptables to build the Kubernetes Network, or the cluster network. These are the four components on the Node.

Kubernetes Nodes do not interact directly with users; their interaction is only with the Master. Users send information to the nodes through the Master. On each Kubernetes Node, these components we mentioned earlier are running.

Now, let’s look at how these components in the Kubernetes architecture interact with each other with an example.

Users can submit a Pod to Kubernetes for deployment through the UI or CLI. This request is first submitted to the Kubernetes API Server through the CLI or UI. The API Server then writes this information to its storage system, etcd. After that, the Scheduler receives this information through the watch or notification mechanism of the API Server: there is a Pod that needs to be scheduled.

At this point, the Scheduler makes a scheduling decision based on its internal state, and after completing the scheduling, it reports to the API Server: “OK! This Pod needs to be scheduled on a certain node.”

Upon receiving this operation, the API Server writes this result back to etcd and then notifies the corresponding node to start executing the Pod. The kubelet on the corresponding node receives this notification and uses the Container Runtime to start and configure the container and its runtime environment. The Storage Plugin and Network Plugin are also employed to configure storage and network.

From this example, we can see how these components communicate and coordinate with each other to complete the scheduling and execution of a Pod.

Core Concepts of Kubernetes and Its API #

Core Concepts #

First Concept: Pod #

A Pod is the smallest scheduling and resource unit in Kubernetes. Users can create a Pod using the Kubernetes Pod API, which allows Kubernetes to schedule the Pod and run it on a node managed by Kubernetes. In simple terms, a Pod is an abstraction of a group of containers, with one or more containers inside.

For example, in the image below, there are two containers in the Pod, and each container can specify the amount of resources it needs, such as 1 core and 1 GB of memory, or 0.5 cores and 0.5 GB of memory.

Of course, the Pod can also include other necessary resources, such as Volume for storage. For example, we may need 100 GB of storage or another 20 GB of storage.

Inside a Pod, we can also define how the containers should run, such as the command to run the container and environment variables. The Pod provides a shared runtime environment for these containers, which means they share the same network environment and can connect to each other using localhost. Pods are isolated from each other.

Second Concept: Volume #

Volume is used for managing storage in Kubernetes. It allows containers in a Pod to access file directories. A volume can be mounted at a specified path in one or more containers within a Pod.

Volume itself is an abstract concept and supports multiple backend storage options. For example, Kubernetes Volume supports many storage plugins, including local storage, distributed storage like ceph and GlusterFS, as well as cloud storage like Alibaba Cloud Disk, AWS EBS, and Google Cloud Disk.

Third Concept: Deployment #

Deployment is a higher-level abstraction based on the Pod. It can define the number of replicas of a Pod and the version of the Pod. Deployment is commonly used for managing applications, with the Pod being the smallest unit of a Deployment.

Kubernetes uses controllers to maintain the desired number of Pods in a Deployment and automatically recover failed Pods. For example, you can define a Deployment with two Pods, and when one Pod fails, the controller detects it and restores the number of Pods to two by creating a new Pod. Controllers also help with deployment strategies, such as rolling updates, recreate updates, or version rollbacks.

Fourth Concept: Service #

Service provides a stable access address for one or more Pod instances.

In the example above, we see that a Deployment may have two or more identical Pods. For an external user, accessing any of the Pods is the same. Therefore, they want to do load balancing and only want to access a fixed Virtual IP (VIP) address, without needing to know the specific IP addresses of each Pod.

As mentioned earlier, a Pod may terminate and be replaced by a new one if it fails.

For an external user, providing multiple specific Pod addresses requires them to constantly update the Pod addresses. To solve this, Kubernetes provides an abstraction called Service, which abstracts the access capabilities of all Pods into a third-party IP address. There are multiple ways to implement Services, and Kubernetes supports Cluster IP. As we mentioned earlier, kube-proxy is responsible for networking, and it also supports capabilities such as nodePort and LoadBalancer for accessing Services.

Fifth Concept: Namespace #

Namespace is used for logical isolation within a cluster, including authentication and resource management. Every resource in Kubernetes, such as Pods, Deployments, and Services, belong to a Namespace. Resources within the same Namespace need to have unique names, while resources in different Namespaces can have the same name.

One use case for Namespace is in companies like Alibaba, where there are multiple business units (BUs). We may want to have a visual isolation between each BU and have different authentication and resource configurations. We can use Namespace to provide each BU with a mechanism to achieve this isolation.

Kubernetes API #

Now let’s introduce some basic knowledge about the Kubernetes API. From a high-level perspective, the Kubernetes API consists of HTTP+JSON: users access the API through HTTP, and the content of the API is in JSON format.

kubectl, the command line tool of Kubernetes, Kubernetes UI, or even curl can communicate directly with Kubernetes using HTTP+JSON.

Here’s an example: for a resource of type Pod, the HTTP access path is the API, followed by apiVersion: V1, the corresponding Namespace, the resource (Pods), and finally the Pod name.

When we submit or get a Pod, its content is expressed in JSON or YAML. In the example above, there is a YAML file describing a Pod resource. The description of the Pod resource is divided into several parts.

The first part is usually the API version. For example, in this example, the version is V1, and it indicates which resource we are operating on. For example, if the kind is pod, we will write the name of the Pod in the Metadata section. We can also assign labels to the Pod, which we will talk about later. Sometimes, the Metadata section may include annotations, which are additional user-level descriptions of the resource.

One important part is called the Spec, which represents the desired state of the Pod. For example, it specifies which containers should be running inside the Pod. In this case, there is an nginx container, which image should be used, and what port should be exposed.

When we retrieve a resource from the Kubernetes API, typically there will be a status section under Spec, which indicates the current state of the resource. For example, the status of a Pod might be scheduled, running, or terminated.

Previously, we introduced an interesting metadata called “label” in the API. This label can be a set of KeyValuePairs.

For example, in the first Pod shown in the figure below, the label could be color=red, indicating that its color is red. Of course, you can add other labels, such as size=big, indicating it is of a large size. These labels can be queried by a selector. This capability is similar to SQL’s select statement. In the example below, we can select Pods whose name color is red. As a result, only two Pods are selected because only they have a label of red. The other Pod, whose label states that its color is yellow, will not be selected.

Through labels, Kubernetes’ API layer can filter these resources. This filtering is the default way Kubernetes represents collections of resources.

For example, as we mentioned earlier, Deployment represents a group of Pods. It is an abstraction over a group of Pods, expressed through label selectors. Similarly, a Service corresponds to a group of Pods and is selected by a label selector.

Labels are a fundamental concept of the Kubernetes API. In the upcoming course, we will focus on explaining and introducing the concept of labels and how to use them effectively.

Ending with a demo #

In the last part, I want to conclude with an example and invite everyone to try Kubernetes together. Before trying Kubernetes, I hope everyone can install Kubernetes on their local machine and set up a Kubernetes sandbox environment.

To install this sandbox environment, there are three main steps:

• First, you need to install a virtual machine to run Kubernetes. We recommend using VirtualBox as the virtual machine environment.

Install VirtualBox: https://www.virtualbox.org/wiki/Downloads

• Next, we need to start Kubernetes in the virtual machine. Kubernetes has a very interesting project called Minikube, which allows you to start a minimal local Kubernetes environment.

For Minikube, we recommend using the Alibaba Cloud version mentioned below. The main difference between this version and the official Minikube is that it uses faster mirrors for the dependencies needed in Minikube, which makes installation easier for everyone.

Install Minikube (China version): https://yq.aliyun.com/articles/221687

• Finally, after installing VirtualBox and Minikube, you can start Minikube with the command below.

Start command: minikube start --vm-driver virtualbox

If you’re not using a Mac system, please visit the following link to see how to install the Minikube sandbox environment on other operating systems.

https://kubernetes.io/docs/tasks/tools/install-minikube/

Once you have successfully installed Minikube, we will do an example together to perform three tasks:

• Deploy an Nginx deployment.

kubectl apply -f https://k8s.io/examples/application/deployment.yaml

• Upgrade the Nginx deployment.

kubectl apply -f https://k8s.io/examples/application/deployment-update.yaml

• Scale the Nginx deployment.

kubectl apply -f https://k8s.io/examples/application/deployment-update.yaml

In the first step, we will submit an Nginx deployment and then upgrade the version of the Pod inside the deployment. Finally, we will try to scale the Nginx deployment horizontally. Let’s try these three operations together.

First, let’s check the status of Minikube. You can see that the kubelet master and kubectl are configured correctly.

Next, let’s use kubectl to check the status of the selected cluster. As we can see, the master node is already in “running” state:

Let’s take this node as an example and try to see the “Deployment” resource in the cluster:

We can see that there is no Deployment in the cluster. We can use the “watch” command to monitor the changes in the Deployment resource.

Next, let’s perform the three operations we wanted to do earlier. The first operation is to create a Deployment. As shown in the first image below, this is an API content, with the kind as “Deployment”, name as “nginx-deployment”, replicas as 2, and image version as 1.7.9.

Next, we will use the kubectl command to perform the actual operation for this Deployment. As shown in the image below, a simple operation will keep generating replicas for the Deployment.

The number of replicas for the Deployment is 2. We can also describe the current state of the Deployment. We know that the Deployment did not exist before, now we will describe the nginx-deployment.

In the image below, we can see that a nginx-deployment has been created. The number of replicas, selector, and image version are all as we desired. We can also see that the deployment-controller is managing the generation of the Deployment.

Next, let’s upgrade the version of this Deployment. First, download another yaml file deployment-update.yaml, where the image version is upgraded from 1.7.9 to 1.8.

Next, let’s apply the new deployment-update yaml file.

As shown on the other side of the screen, the deployment upgrade operations are displayed, and the “up-to-date” value is changed from 0 to 2, indicating that all containers and pods are up to date. We can also describe to see if all pod versions have been updated. We can see that the image version has been updated from 1.7.9 to 1.8.

Finally, we can see that the controller has executed several new operations. This controller is maintaining the status of the entire Deployment and its pods.

Lastly, let’s demonstrate scaling the Deployment horizontally. Download another yaml file deployment-scale.yaml, where the number of replicas is changed from 2 to 4.

Go back to the initial window and use kubectl to apply the new deployment-scale.yaml file. In the other window, we can see that after executing the deployment-scale operation, the number of container pods changed from 2 to 4. We can describe the current state of the deployment again and see that the number of replicas has changed from 2 to 4. We can also see that the controller has performed several new operations. The scale-up was successful.

Finally, let’s use the delete operation to delete the Deployment we just created. kubectl delete deployment, followed by the deployment name. After deleting it, all the operations we did today are completed.

Let’s get the Deployment again, and it will show that this resource no longer exists. The cluster returns to the clean state it was in at the beginning.

That’s all the content for this lesson. We have covered the core concepts and architecture design of Kubernetes. I hope you have gained some knowledge in this lesson, and I also hope you will pay attention to other content in the Cloud Native Technology Classroom. Thank you for watching!

Summary #

• Kubernetes is an automated container orchestration platform that is responsible for application deployment, application elasticity, and application management, all of which are based on containers.
• The architecture of Kubernetes is a typical two-layer architecture and a server-client architecture.