1. What is Kubernetes
Kubernetes, as you can see from the official website, is an industrial-grade container orchestration platform. The word Kubernetes is Greek, and its Chinese translation is "helmsman" or "pilot". The word "ks" can also be seen in some common materials, that is, "k8s", which is an abbreviation caused by replacing the 8 letters "ubernete" with "8". Why is Kubernetes named after "helmsman"? You can take a look at this picture:
This is a ship carrying a bunch of containers, and the ship is running around on the ocean carrying the containers and delivering them to where they are supposed to go. We actually introduced a concept called container before. The English word container also has another meaning, which is "container". Kubernetes also uses this meaning to hope to become a ship that transports containers to help us manage these containers, that is, to manage these containers.
This is why the word Kubernetes was chosen to represent this project. To be more specific: Kubernetes is an automated container orchestration platform that is responsible for application deployment, application elasticity, and application management, all based on containers.
2. Kubernetes has the following core functions:
Service discovery and load balancing;
The automatic boxing of containers, we also call it scheduling, is "scheduling", put a container on a certain machine in a cluster, Kubernetes will help us do storage arrangement, so that the storage life cycle is consistent with the container's The life cycle can have a connection;
Kubernetes will help us do automated container recovery. In a cluster, host problems or OS problems often occur, resulting in the unavailability of the container itself, and Kubernetes will automatically restore these unavailable containers;
Kubernetes will help us to automatically release and roll back the application, as well as manage the configuration ciphertext related to the application;
For job type tasks, Kubernetes can perform batch execution;
In order to make this cluster and this application more elastic, Kubernetes also supports horizontal scaling.
Below, we hope to introduce the capabilities of Kubernetes to you more practically with three examples.
1. Scheduling
Kubernetes can put the container submitted by the user on a certain node of the cluster managed by Kubernetes. The Kubernetes scheduler is the component that performs this capability, and it observes the size and specification of the container being scheduled.
For example, the CPU it needs and the memory it needs, and then find a relatively idle machine in the cluster to perform a placement, that is, a placement operation. In this example, it may place the red container on the second idle machine to complete a scheduled job.
2. Automatic repair
Kubernetes has a node health check function, which will monitor all hosts in the cluster. When the host itself fails or the software fails, the node health check will automatically discover it. Next, Kubernetes will automatically migrate the containers running on these failed nodes to a healthy running host to complete the automatic recovery of the containers in the cluster.
3. Horizontal expansion
Kubernetes has the ability to check the business load. It will monitor the load on the business. If the CPU utilization of the business itself is too high or the response time is too long, it can expand the capacity of the business.
For example, in the following example, the yellow color is too busy, and Kubernetes can change the yellow color load from one to three. Next, it can evenly distribute the load originally assigned to the first yellow color to the three yellow-colored loads through load balancing, so as to improve the response time.
The above is a brief introduction to the three core capabilities of Kubernetes.
3. Architecture of Kubernetes
The Kubernetes architecture is a typical two-tier architecture and server-client architecture. Master, as the central control node, will connect to Node.
All UI, clients, and these user-side components will only connect with the Master, and send the desired state or commands to be executed to the Master, and the Master will send these commands or states to the corresponding nodes for final execution. implement.
3.1 Architecture of Kubernetes: Master
Contains four main components: API Server, Controller, Scheduler and etcd . As shown below:
API Server : As the name implies, it is used to handle API operations. All components in Kubernetes will be connected to the API Server. Generally, there is no independent connection between components, and they all rely on the API Server for message transmission;
Controller : It is the controller, which is used to complete some management of the cluster state. For example, in the two examples we mentioned just now, the first one automatically repairs the container, and the second one automatically expands horizontally, both of which are completed by the Controller in Kubernetes;
Scheduler : It is a scheduler. As the name suggests, a "scheduler" is to complete the scheduling operation. In the first example we just introduced, a Container submitted by a user is found according to its request size for CPU and memory. Node, place it;
etcd : It is a distributed storage system. The original information required by the API Server is placed in etcd. etcd itself is a high-availability system, and etcd ensures the high availability of the entire Kubernetes Master component. The API Server we just mentioned is a deployment component that can be expanded horizontally in terms of deployment structure; Controller is a deployment component that can be used for hot standby. It has only one active, and its scheduler is also corresponding. There is only one active, but hot standby can be performed.
3.2 Architecture of Kubernetes: Node
The Node of Kubernetes actually runs business loads, and each business load runs in the form of a Pod. In a moment I'll introduce the concept of a Pod. One or more containers running in a Pod, the component that actually runs these Pods is called kubelet, which is the most critical component on Node. It receives the required Pod running status through the API Server, and then submits it to us below Draw this Container Runtime component.
To create the running environment required by the container on the OS, and finally to run the container or Pod, it is also necessary to manage the storage and network. Kubernetes does not directly operate network storage, they rely on Storage Plugin or network Plugin to operate. Users or cloud vendors will write the corresponding Storage Plugin or Network Plugin to complete storage operations or network operations.
In Kubernetes' own environment, there will also be a Kubernetes Network, which is to provide a Service network for networking. (We will also introduce the concept of "service" in a moment.) Kube-proxy is the component that actually completes the service networking. It uses the ability of iptables to build the Kubernetes Network, which is the cluster network. The above is the Node above. of the four components.
The Node of Kubernetes does not directly interact with the user, its interaction will only pass through the Master. The User sends the information to the nodes through the Master. On each Node of Kubernetes, the components we just mentioned will run.
Let's take an example to see how these components in the Kubernetes architecture interact with each other.
Users can submit a Pod to Kubernetes for deployment through the UI or CLI. The Pod request will first be submitted to the Kubernetes API Server through the CLI or UI. Next, the API Server will write this information to its storage system etcd, and then the Scheduler will pass The watch or notification mechanism of the API Server gets this information: there is a Pod that needs to be scheduled.
At this time, the Scheduler will make a scheduling decision based on its memory status. After completing the scheduling, it will report to the API Server: "OK! This Pod needs to be scheduled to a certain node."
At this time, after the API Server receives the operation, it will write the result to etcd again, and then the API Server will notify the corresponding node to start the actual execution of the Pod. The kubelet of the corresponding node will get this notification, and the kubelet will adjust the Container runtime to actually start and configure the container and its operating environment, schedule the Storage Plugin to configure storage, and the network Plugin to configure the network.
In this example, we can see how these components communicate with each other and coordinate to complete a Pod scheduling execution operation.
Fourth, the core concept of Kubernetes
4.1 Pod
Pod is a minimum scheduling and resource unit of Kubernetes. Users can generate a Pod through the Pod API of Kubernetes, and let Kubernetes schedule the Pod, that is, put it to run on a node managed by Kubernetes. A Pod is simply an abstraction of a set of containers, which contains one or more containers.
For example, in the picture below, it contains two containers, and each container can specify the resource size it needs. For example, one core is one G, or 0.5 cores, 0.5 G.
Of course, this Pod can also contain some other required resources: for example, the storage resource of the Volume volume we have seen; for example, we need 100 GB of storage or another 20GB of storage.
In the Pod, we can also define the way the container needs to run. For example, the Command to run the container, the environment variables to run the container, and so on. The Pod abstraction also provides these containers with a shared operating environment. They will share the same network environment. These containers can use localhost for direct connections. And between Pod and Pod, there is isolation isolation from each other.
4.2 Volume
Volume is the concept of a volume. It is used to manage Kubernetes storage and to declare that the containers in the Pod can access the file directory. A volume can be mounted under the specified path of one or more containers in the Pod.
The Volume itself is an abstract concept, a Volume can support a variety of back-end storage. For example, the Volume of Kubernetes supports many storage plug-ins. It can support local storage and distributed storage, such as ceph, GlusterFS; it can also support cloud storage, such as cloud disk on Alibaba Cloud, AWS Cloud Disk on , Cloud Disk on Google, and more.
4.3 Deployment
Deployment is an abstraction higher on the abstraction of Pod. It can define the number of copies of a set of Pods and the version of this Pod. Generally, people use the abstraction of Deployment to manage the application, and Pod is the smallest unit of Deployment.
Kubernetes uses the Controller, which is the controller we just mentioned, to maintain the number of Pods in the Deployment, and it will also help the Deployment to automatically recover failed Pods.
For example, I can define a Deployment, which requires two Pods. When a Pod fails, the controller will detect it, and it will restore the number of Pods in the Deployment from one to two, and then generate a new Pod. A Pod. Through the controller, we also help with the published strategy. Examples include rolling upgrades, regenerated upgrades, or version rollbacks.
4.4 Service
Service provides a stable access address for one or more Pod instances.
For example, in the above example, we see that a Deployment may have two or more identical Pods. For an external user, access to which Pod is actually the same, so it wants to do a load balancing. While doing load balancing, I only want to access a certain fixed VIP, that is, the Virtual IP address, instead of Hope to know the IP address of each specific Pod.
We just mentioned that the pod itself may terminal go (terminate), and if a Pod fails, it may be replaced with a new one.
For an external user, multiple specific Pod addresses are provided, and the user must constantly update the Pod address. When the Pod fails to restart, we hope to have an abstraction that abstracts the access capabilities of all Pods into one An IP address of a third party, the Kubernetes abstraction that implements this is called Service.
There are many ways to implement Service. Kubernetes supports Cluster IP. The kuber-proxy network we mentioned above also supports nodePort, LoadBalancer and other access capabilities.
4.5 Namespace
Namespace is used for logical isolation within a cluster, including authentication, resource management, etc. Each resource in Kubernetes, such as the Pod, Deployment, and Service just mentioned, belongs to a Namespace. Resources in the same Namespace need to be named uniquely, and resources in different Namespaces can have the same name.
Namespace is a use case. For example, in Alibaba, there will be many business units inside. Between each business unit, it is hoped that there will be a view isolation, and the authentication is different, and it is different on cuda. We will use Namespace to provide each BU with an isolation mechanism as it sees.
