k8s core component operating mechanism diagram
1. Master
Master refers to the cluster control node. In each Kubernetes cluster, there needs to be a Master responsible for the management and control of the entire cluster. Basically, all control commands of Kubernetes are sent to it. It is responsible for the specific execution process, which we will execute later. All commands are basically run on the Master
Core components running on Master:
Kubernetes API Server（kube-apiserver）：
The key service process that provides the HTTP Rest interface is the only entry point for operations such as adding, deleting, modifying, and checking all resources in Kubernetes. It is also the entry process for cluster control.
Kubernetes Controller Manager（kube-controller-manager）：
The automated control center for all resource objects in Kubernetes can be understood as the "general manager" of resource objects.
Kubernetes Scheduler（kube-scheduler）：
The process responsible for resource scheduling (Pod scheduling) is equivalent to the "dispatching room" of the bus company.
2. Node
Node is the workload node in the Kubernetes cluster. Each Node will be assigned some workload (Docker container) by the Master. When a Node goes down, the workload on it will be automatically transferred to other nodes by the Master.
Core components running on Node:
kubelet: Responsible for tasks such as creating, starting and stopping the containers corresponding to the Pod, and working closely with the Master to implement the basic functions of cluster management.
kube-proxy: an important component that implements the communication and load balancing mechanism of Kubernetes Service.
3. Etcd
The officials of etcd position it as a trustworthy distributed key-value storage service that saves the status of the entire cluster. It can store some key data for the entire distributed cluster and assist in the normal operation of the distributed cluster.
4. Pod
Pod is the most important basic concept of Kubernetes. We see that each Pod has a special Pause container called a "root container". The image corresponding to the Pause container is part of the Kubernetes platform. In addition to the Pause container, each Pod also contains one or more closely related user business containers.
5. Label
Label is another core concept in the Kubernetes system. A Label is a key-value pair of key=value, where the key and value are specified by the user. Labels can be attached to various resource objects, such as Node, Pod, Service, RC, etc. A resource object can define any number of Labels, and the same Label can also be added to any number of resource objects. Label is usually determined when the resource object is defined, and can also be dynamically added or deleted after the object is created.
六、ReplicationController（RC）
It is used to ensure that the number of copies of the container application is always maintained at the user-defined number of copies. That is, if a container exits abnormally, a new Pod will be automatically created to replace it; if there is an exception, the extra containers will be automatically recycled. In the new version of Kubernetes, it is recommended to use ReplicaSet to replace ReplicationControlle.
7. ReplicaSet (RS)
There is no essential difference between ReplicaSet and ReplicationController, only the names are different, and ReplicaSet supports collective selectors. Although ReplicaSet can be used independently, it is generally recommended to use Deployment to automatically manage ReplicaSet, so that there is no need to worry about incompatibility with other mechanisms (such as ReplicaSet does not support rolling-update but Deployment does).
8. Deployment
Deployment provides a declarative definition method for Pod and ReplicaSet, which is used to replace the previous ReplicationController to conveniently manage applications. Typical application scenarios include:
1. Define Deployment to create Pod and ReplicaSet
2. Rolling upgrade and rollback application
3. Expansion and reduction
4. Pause and resume Deployment
9. DaemonSet
DaemonSet ensures that all (or some) Nodes are running a copy of the Pod. When a Node joins the cluster, a Pod will be added to them. When a Node is removed from the cluster, these Pods will also be recycled. Deleting a DaemonSet will delete all Pods it created. Some typical uses of DaemonSet:
1. Run the cluster storage daemon, such as glusterd and ceph on each Node.
2. Run the log collection daemon on each Node, such as fluentd and logstash.
3. Run the monitoring daemon on each Node, such as Prometheus Node Exporter
十、Horizontal Pod Autoscaling
Horizontal Pod Autoscaling is only applicable to Deployment and ReplicaSet. In the V1 version, it only supports expansion and contraction based on the CPU utilization of the Pod. In the v1alpha version, it supports expansion and contraction based on memory and user-defined metric.
11. StatefulSet
StatefulSet is designed to solve the problem of stateful services (corresponding to Deployments and ReplicaSets, which are designed for stateless services). Its application scenarios include:
1. Stable persistent storage, that is, the same persistent data can still be accessed after Pod is rescheduled, implemented based on PVC
2. Stable network sign, that is, the PodName and HostName remain unchanged after the Pod is rescheduled, and is implemented based on the Headless Service (that is, the Service without Cluster IP)
3. Orderly deployment and orderly expansion, that is, Pods are in order. When deployed or expanded, they must be carried out in sequence according to the defined order (that is, from 0 to N-1, all previous Pods must be deployed before the next Pod runs. Both are in Running and Ready states), implemented based on init containers
4. Orderly shrinkage and orderly deletion (i.e. from N-1 to 0 0)
12. Job
Job is responsible for batch tasks, that is, tasks that are executed only once, and it guarantees one or more Pods of batch tasks.
13. Cron Job
Cron Job manages time-based jobs, namely:
1. Run only once at a given time point
2. Run periodically at a given time point
14. ConfigMap
The ConfigMap function was introduced in Kubernetes 1.2, and many applications read configuration information from configuration files, command line parameters, or environment variables. The ConfigMap API provides us with a mechanism to inject configuration information into the container. ConfigMap can be used to save a single attribute, or it can be used to save the entire configuration file or a JSON binary large object.
15. Secret
Secret solves the configuration problem of sensitive data such as passwords, tokens, and keys without exposing these sensitive data to images or Pod Specs. Secret can be used as a Volume or environment variable.
16. Volume
The life cycle of files on the container disk is short-lived, which causes some problems when running important applications in the container. First, when a container crashes, the kubelet will restart it, but the files in the container will be lost - the container is restarted in a clean state (the original state of the image). Secondly, when multiple containers are running simultaneously in a Pod, files usually need to be shared between these containers. Volume in Kubernetes solves these problems very well
17. PersistentVolume (PV)
A PersistentVolume is a storage set up by an administrator that is part of a cluster. Just like nodes are resources in the cluster, PVs are also resources in the cluster. PV is a volume plug-in like Volume, but has a life cycle independent of the Pod using the PV. This API object contains the details of the storage implementation, that is, NFS, iSCSI, or a cloud vendor-specific storage system.
18. PersistentVolumeClaim (PVC)
PersistentVolumeClaim is a user stored request. It is similar to Pod. Pod consumes node resources, and PVC consumes PV resources. Pods can request specific levels of resources (CPU and memory). Claims can request specific sizes and access modes (e.g., can be mounted in read/write-once or read-only-many mode).
19. Service
Service is the core concept of Kubernetes. By creating a Service, you can provide a unified entry address for a group of container applications with the same functions, and distribute the request load to each container application on the backend.
20. NameSpace
Namespace is another very important concept in the Kubernetes system. Namespace is used in many cases to achieve multi-tenant resource isolation.