Shulou(Shulou.com)05/31 Report--

This article shows you how Kubernetes works. It is concise and easy to understand. It will definitely brighten your eyes. I hope you can gain something through the detailed introduction of this article.

It is no secret that the popularity of running containerized applications has exploded over the past few years. Being able to iterate and publish the application by providing the application's dependencies by code is a huge victory. Gartner said that by 2022, "more than 75 per cent of global organizations will run containerized applications in production".

For organizations running on a large scale, one Linux container instance is not enough to meet all the needs of their applications. It is not uncommon for applications that are complex enough, such as those that communicate through microservices, to require multiple Linux containers that communicate with each other. The architecture introduces a new extension question: how to manage all these separate containers? Developers still need to arrange the deployment of containers on specific machines, manage the network between them, increase the resources allocated under high load, and so on.

Come to Kubernetes, a container orchestration system-a way to manage the life cycle of containerized applications. It is a meta-process that allows multiple containers to be automatically deployed and extended at the same time. Several containers running the same application are grouped together. These containers act as replicas (replica) and are used to load balance incoming requests. The container choreographer then supervises these groups to ensure that they run correctly.

A container choreographer is essentially an administrator responsible for operating a set of containerized applications. If you need to restart the container or get more resources, the choreographer will handle it for you.

This is a fairly broad overview of how most container choreographers work. Let's take a closer look at all the components of Kubernetes.

Kubernetes terminology and architecture

Kubernetes introduces many words to describe how applications are organized. We'll start with the smallest floor.

Pod

Kubernetes pod is a set of containers that is the smallest unit managed by Kubernetes. Pod has a separate IP address that is applied to each container in pod. Containers in Pod share the same resources, such as memory and storage. This allows a single Linux container within pod to be treated together as a single application, as if all containerized processes were running on the same host in a more traditional workload. Pod with only one container is common when an application or service is a single process that needs to be run. However, when things get more complex and multiple processes need to use the same shared data volumes to work together to achieve the correct operation, multi-container pod simplifies deployment configuration compared to setting up shared resources between containers separately.

For example, if you are working on an image processing service that creates a gif, a pod may have multiple containers working together to resize the image. The primary container may run a non-blocking micro-service application that receives requests, then run one or more auxiliary (side car) containers, run batch background processes, or clean up data artifacts in storage volumes as part of managing overall application performance.

Deployment

Kubernetes deployment (deployment) allows you to define the size of the application you want to run by setting the details of how you want to replicate pod on the Kubernetes node. Deployment describes the number of copies of the same pod that need to be run, as well as the preferred update strategy to use when updating the deployment. Kubernetes tracks the health of the pod and removes or adds pod as needed to bring the application deployment to the desired state.

Service

The lifespan of individual pod cannot be relied on; everything from their IP address to their existence can change. In fact, there is a concept in the DevOps community that servers are treated as "pets" or "cattle". Pets are something you need to take special care of, while cows are considered to be more worthy of sacrifice. Similarly, Kubernetes does not see its pods as the only long-running instance; if pod dies due to a problem, it is Kubernetes's job to replace it so that the application does not experience any downtime.

Service is an abstraction of pods and is essentially the only interface for various application consumers to interact with. When pod is replaced, their internal names and IP may change. Service mapping a single machine name or IP address to its base name and number can be an unreliable pod. Service ensures that everything looks the same in an external network.

Node

The Kubernetes node (node) manages and runs the pod; is the machine (whether virtual or physical) that performs a given job. Just like pod collects a single container that operates together, node collects the entire pod that works together. When you operate on a large scale, you want to be able to hand over the work to a node whose pod can receive the work.

Master server

This is the main entrance for administrators and users to manage various nodes. The operation is called through HTTP, or connected to the machine and sent to it by running a command-line script.

Cluster

Cluster (Cluster) is a combination of all the above components as a single unit.

Kubernetes component

With a rough idea of how Kubernetes is assembled, let's take a look at the various software components that make sure everything runs smoothly. Both the primary server and a single worker node have three main components.

Master server component

API Server

The API server exposes a REST interface to the Kubernetes cluster. All operations against pod, service, and so on are performed programmatically by communicating with the endpoints it provides.

Scheduler

The scheduler is responsible for assigning work to each node. It monitors resource capacity and ensures that the performance of the worker node (Worker node) is within the appropriate threshold.

Controller-manager

Controller-manager is responsible for ensuring that the shared state of the cluster works as expected. More precisely, the controller manager monitors various controllers that respond to events (for example, if a node fails).

Worker node component

Kubelet

Kubelet tracks the status of pod to ensure that all containers are running. It provides a heartbeat message to the primary server (Master server) every few seconds. If the replication controller (replication controller) does not receive the message, the node is marked as unhealthy.

Kube proxy

The Kube agent sends traffic from the service to the node. It forwards the work request to the correct container.

Etcd

Etcd is a distributed key-value store that Kubernetes uses to share information about the overall state of the cluster. In addition, nodes can reference the global configuration data stored there so that they can set themselves when they are regenerated.

The above is how Kubernetes works. Have you learned any knowledge or skills? If you want to learn more skills or enrich your knowledge reserve, you are welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.