This film has a lot of textual explanations, but it can establish the cognitive structure of k8s in the reader's mind, and then after the in-depth understanding of k8s, look back again to further strengthen the higher-level understanding and learning of k8s .
K8s overview
1 Introduction
K8s is an open source, used to manage containerized applications on multiple hosts in the cloud platform. The goal of Kubernetes is to make the deployment of containerized applications simple and efficient. Kubernetes provides application deployment, planning, update, and maintenance. A mechanism of
One of the core features of K8s is the ability to independently manage containers to ensure that the containers in the cloud platform are running in accordance with the user's desired state (the user does not need to care about what to do, K8s will automatically monitor, and then restart, create a new one, in short, let apache always Provide services).
In K8s, all containers run in Pods. A Pod can carry one or more related containers. A Pod can also contain 0 or more disk volume groups (volumes), which will be listed as directories. The form is provided to a container, or shared by all containers in the Pod. For each Pod created by the user, the system will automatically select the healthy machine with sufficient capacity, and then create a container-like container. When the container creation fails, The container will be automatically restarted by the node agent, which is called kubelet.
All resources in k8s, such as Pod, are distinguished by something called URI. This URI has a UID. An important part of the URI is:
the type of object (such as pod)
, the name of the
object, and the namespace
of the object for special objects. Type, in the same namespace, all names are different, in the case where the object only provides the name, and does not provide the namespace, this situation is assumed to be the default namespace. UID is unique in time and space.
2. Brief overview
Cluster: Cluster refers to k8s using a series of physical machines, virtual machines and other basic resources to run your application;
Node: a node is a physical machine or virtual machine running k8s, and pod can be scheduled on it;
Pod : A pod corresponds to a container group consisting of containers and volumes;
Lable: A label is a key/value pair attached to a resource, such as attached to a pod, and a user-defined and identifiable one is passed to it Attributes, Labels can also be applied to organize and select resources in a subnet;
Selector: an expression that defines the relationship between resources by matching labels, such as specifying a target pod for a load-balanced service;
Replication Controller: To ensure certain The specified number of replicas of the pod can work normally at any time, not only allows the replication of your system to be easy to expand, but also handles the creation of a
pod again when the machine restarts or fails; Service: A service defines access to the pod The way is like the relationship between a single fixed ip address and its corresponding DNS name;
Volume: A volume is a directory that may be accessed as part of the container; k8s volume is built on docker vlume and supports adding And configure volume directories or other storage devices;
Secret: store sensitive data, such as permission tokens that allow containers to receive requests;
Name: the name defined by the user for the resource in k8s;
Namespace: namespace is like the prefix of the resource name, it helps different Shared clusters for projects, teams or customers, such as preventing naming conflicts between independent teams;
Annotation: A key-value pair with a larger capacity than the label. It may be unreadable data to us, just to store unrecognizable auxiliary data, especially some data that is used by tools or system extensions to operate .
k8s design architecture
K8s cluster contains node agent kubelet and Master components (APIs, scheduler, etcd), everything is based on a distributed storage system
1. The core components of K8s
Etcd: saves the state of the entire cluster;
Apiserver: provides operating resources as the only entry point, and provides authentication, authorization, access control, API registration and discovery mechanisms;
Controller manager: responsible for maintaining the state of the cluster, such as fault detection, automatic expansion, Rolling updates, etc.;
Scheduler: responsible for resource scheduling, scheduling pods to the corresponding machines according to a predetermined scheduling strategy;
Kubelet: responsible for maintaining the life cycle of the cluster, and also responsible for the management of volumes (CVI) and network (CNI);
Container runtime: responsible for image management and real operation of pods and containers (CRI);
kube-proxy: responsible for service discovery and load balancing within the cluster.
2. Non-core components of K8s
kube-dns is responsible for providing DNS services for the entire cluster;
Ingress Controller provides external network access for services;
Heapster provides resource monitoring;
Dashboard provides GUI;
Federation provides cross-availability zone clusters;
Fluentd-elasticsearch provides cluster log collection, storage and query.
3. The layered architecture of k8s
The design concept and function of Kubernetes is actually a layered architecture similar to Linux, as shown in the figure below
Core layer: The core function of Kubernetes. It provides external APIs to build high-level applications, and provides plug-in application execution environment internally.
Application layer: deployment (stateless applications, stateful applications, batch tasks, cluster applications, etc.) and routing (services) Discovery, DNS resolution, etc.);
Management layer: system metrics (such as infrastructure, container and network metrics), automation (such as automatic expansion, dynamic Provision, etc.) and policy management (RBAC, Quota, PSP, NetworkPolicy, etc.);
interface layer : Kubectl command line tool, client SDK and cluster federation;
Ecosystem: The ecosystem of the huge container cluster management and scheduling above the interface layer can be divided into two categories;
Outside of Kubernetes: logging, monitoring, configuration management, CI, CD, Workflow, FaaS, OTS applications, ChatOps, etc.;
inside Kubernetes: CRI, CNI, CVI, mirror warehouse, Cloud Provider, configuration and management of the cluster itself, etc.
4. Concept refinement
Kubelet: Responsible for managing pods and their containers, images mirrors, volumes, etc;
Kube-proxy: each node runs a simple network proxy and load balancing;
k8s dashboard: The panel can be divided into multiple parts, currently all Runs on a master;
Etcd: the continuous state of all masters exists in an instance of etcd, used to store configuration data;
K8s API-server: mainly handles rest operations, verifies and updates these objects in etcd and finally stores them;
Scheduler : The scheduler binds
unscheduled pods to the nodes through binding ip api; K8s control management server: All other cluster-level functions are currently in charge of the control manager.
The core technology concept of k8s
1 、 Pod
It is the smallest unit for running and deploying applications or services in a cluster;
Pod's design concept is to support multiple containers to share network addresses and file systems in a pod, and can be combined to complete services through inter-process communication and file sharing in a simple and efficient way ;
Pod is the basis of all business types in the k8s cluster, and if the business needs to be unavailable, the pod is executed. At present, the business in k8s is mainly divided into long-running, batch, node-deamon, and stateful application. The corresponding pod controller It is Deployment, job, DeamonSet, PetSet.
2. Replication controller (Replication controller, RC)
RC is the earliest API object in the k8s cluster that guarantees pod high availability;
it monitors the running pods to ensure that the specified number of copies are running in the cluster; when it is less than the specified number, RC will start and run new pod copies; when the specified number is , RC will kill redundant pod copies;
even when the specified number is 1, running pod through RC is wiser than running pod directly, because RC can also exert its high-availability ability to ensure that there will always be only 1 pod Running.
3. Replica Set (Replica Set, RS)
The new generation of RC provides the same high-availability capabilities. The main difference is that latecomers come first and can support more types of matching modes; replica set objects are generally not used alone, but as ideal state parameters of Deployment.
4. Deployment
Represents an update operation performed by the user on the k8s cluster; it
can be to create a new service, update a new service, or upgrade a service on a
rolling basis; to upgrade a service on a rolling basis is actually to create a new RS, and then gradually update the new RS A compound operation that increases the number of replicas in the old RS to an ideal state and reduces the number of replicas in the old RS to 0; such a compound operation is not easy to describe with RS, so it is described by deployment.
5. Service
In a k8s cluster, the service that the client needs to access is the service object;
RC, RS, and deployment only guarantee the number of pods that support the service's microservices, but they do not solve the problem of accessing the service;
a pod stops on a node, It will be created on another node, because it is impossible to provide services with a definite ip and port number;
to provide stable services requires service discovery and load balancing capabilities. The work done by service discovery is for the services accessed by the client and find the corresponding Back-end service instance. The service accessed by the client is the service object. Each service corresponds to a valid virtual IP in the cluster, and the cluster accesses a service through the virtual IP; the balance in k8s is implemented by kube-proxy, which is a k8s cluster The internal load balancer, a distributed proxy server, is available on each node. This design reflects its scalability advantages. The more nodes that need to be accessed, the more kube-proxy that provides load balancing capabilities. The available nodes also increase. In contrast, when we usually use a reverse proxy on the server side for load balancing, we still need to further solve the problem of reverse proxy load balancing and high availability.
6. Task (Job)
K8s is used to control the API objects of batch-type tasks;
the main difference between batch-type business and long-term server-type business try batch processing business has its beginnings and ends, and long-term server-type business runs without users stopping.
The pod managed by Jon automatically exits after completing the task according to the user's settings. The successful completion depends on different spe.completios strategies; single Pod-type tasks have a Pod successful to mark completion; fixed-number-successful tasks ensure that all N tasks are successful; work queue-type tasks mark success according to the global success confirmed by the application .
7. Background support service set (DaemonSet)
The core of long-term server-type and batch-processing services lies in business applications. Some nodes may run multiple Pods of the same business, and some nodes do not have such Pods. The core focus of back-end support services is on nodes in the K8s cluster. (Physical machine or virtual machine), to ensure that there is one such Pod running on each node. The node may be all cluster nodes or some specific nodes selected by nodeSelector. Typical back-end support services include storage, log, and monitoring services that support K8s cluster operation on each node.
8. Stateful service set (PetSet)
K8s released the Alpha version of the PetSet function in version 1.3. In the cloud-native application system, there are the following two sets of synonyms; the first group is stateless, cattle, nameless, and disposable; the second group is stateful, Pet (pet), having name (having name), non-disposable (non-disposable).
RC and RS mainly control the provision of stateless services. The name of the Pod they control is randomly set. If a Pod fails, it will be discarded. A new Pod is restarted in another place. The name changes, the name and It doesn't matter where it is started, what matters is the total number of Pods; PetSet is used to control stateful services, and the name of each Pod in PetSet is determined in advance and cannot be changed. The role of the Pod's name in PetSet is not because of the human nature of Spirited Away, but the status associated with the Pod.
For Pods in RC and RS, storage is generally not mounted or shared storage is mounted. What is saved is the shared state of all Pods. Pods are no different like livestock (this seems to mean that they have lost their human characteristics); for PetSet Each Pod mounts its own independent storage. If a Pod fails, start a Pod with the same name from another node, and the storage of the original Pod must be mounted to continue to provide services in its state.
Businesses suitable for PetSet include database services MySQL and PostgreSQL, cluster management services Zookeeper, etcd and other stateful services.
Another typical application scenario of PetSet is as a mechanism to simulate virtual machines that is more stable and reliable than ordinary containers. The traditional virtual machine is just a kind of stateful pet. The operation and maintenance personnel need to maintain it continuously. When the container first became popular, we used the container to simulate the use of the virtual machine, and all the state was stored in the container, and this has been proven It is very unsafe and unreliable. Using PetSet, Pod can still provide high availability by drifting to different nodes, and storage can also provide high reliability through external storage. What PetSet does is to associate certain Pods with certain storage to ensure state continuity. PetSet is only in the Alpha stage. We will continue to observe how the subsequent design evolves.
k8s network
K8s has a unique network model. K8s assigns an IP address to each pod. When you create a new cluster, in order to ensure that the pod gets an IP, you need to assign an IP address pool to k8s. The easiest way is that the communication between each node and node can be achieved in the following two ways:
(1) Configure the network to complete the pod's ip address routing-it is more difficult
(2) Establish a topological network- ---Easier
such as Flannel, weave, Open vSwitch (OVS)
(3) Some optional configuration methods
such as GCE, AWS
(4) Assign a CIDR subnet to each node's pod address or a
total of you need max- pods-per-node * max-number-of-pod IP addresses. If a "/24" lacks an IP address, a "/26" (62 nodes) or "/27" (30 nodes) can also be satisfied.
For example: use "10.10.0.0/16", "10.10.0.0/24" ", "10.10.255.0/24"
requires routing settings or connection to a topological network
K8s will assign an IP address to each service, but the address of the service is not necessarily routable. When the data leaves the node, kube-proxy needs to translate the service ip address into the pod ip address. Therefore, you need to also assign an address segment to the service. This network segment is called "SERVICE_CLUSTER_IP_RANGE". For example: you can set "SERVICE_CLUSTER_IP_RANGE=10.0.0.0/16", this will allow 65534 different services to run at the same time. Of course, you can adjust this ip address segment, but you cannot remove this network segment while the service and pod are running.
Similarly, you need to choose a static ip address for the master node and name this ip address "MASTER_IP". Configure the firewall to allow port 80 and 443 of the apiserver. Use sysctl to set "net.ipv4.ip_forward = 1" to enable IPv4 forwarding.