Kubernetes (k8s) theoretical introduction

An open source system for automatically deploying, scaling and managing "containerized applications".
It can be understood that K8S is a cluster responsible for automated operation and maintenance of multiple containerized programs (such as Docker). It is a container orchestration framework tool with an extremely rich ecosystem.

2. Origin of K8s

K8S is based on Google's Borg system (Borg system, a large-scale container orchestration tool used internally by Google) as a prototype. It was later rewritten in the GO language using Borg's ideas and donated to the CNCF Foundation for open source.

The Cloud Native Foundation (CNCF) was established in December 2015 and is affiliated with the Linux Foundation. The first project incubated by CNCF was Kubernetes. With the widespread use of containers, Kubernetes has become the de facto standard for container orchestration tools.

Meaning: The word originates from the Greek helmsman and pilot.

Official website: https://kubernetes.io

GitHub：https://github.com/kubernetes/kubernetes

3. Why use K8S?

Imagine the traditional back-end deployment method: put the program package (including executable binary files, configuration files, etc.) on the server, then run the startup script to run the program, and at the same time start the daemon script to regularly check the program running status and restart if necessary. Pull up the program.

Imagine, what if the number of service requests increases and the deployed service cannot respond? The traditional approach is often that if the request volume, memory, and CPU exceed the threshold and an alarm is issued, the operation and maintenance personnel will immediately add a few more servers. After deploying the service, they will connect to load balancing to share the pressure of the existing services.
A problem arises: from monitoring alarms to deploying services, human intervention is required! So, is there a way to automatically deploy, update, uninstall, expand and shrink services?
And this is what K8S has to do: automate operation and maintenance management of containerized (Docker) programs .

K8S is Google's open source container cluster management system. Based on container technologies such as Docker, it provides a series of complete functions such as deployment and operation, resource scheduling, service discovery and dynamic scaling for containerized applications, improving the efficiency of large-scale container cluster management. Convenience.

4. Kubernetes functions

●Organize containers across hosts.
●Make fuller use of hardware resources to maximize the needs of enterprise applications.
●Deployment and upgrade of control and automation applications.
●Mount and add storage for stateful applications.
● Scale up or down containerized applications and their resources online.
●Declarative container management ensures that deployed applications operate according to the way we deploy them.
●Achieve application status checking and self-healing through automatic layout, automatic restart, automatic replication, and automatic scaling.
●Provide service discovery and load balancing for multiple containers, so that users do not need to consider container IP issues.

2: Kubernetes cluster architecture and components

1. Kubernetes cluster architecture and components

K8S belongs to the master-slave device model (Master-Slave architecture) , that is, the Master node is responsible for the scheduling, management, and operation and maintenance of the cluster, and the Slave node is the computing workload node in the cluster.
In K8S, the main node is generally called the Master node, and the slave node is called the Worker Node. Each Node will be assigned some workload by the Master.

The Master component can run on any computer in the cluster, but it is recommended that the Master node occupies a separate server. Because the Master is the brain of the entire cluster, if the node where the Master is located goes down or becomes unavailable, all control commands will become invalid. In addition to the Master, other machines in the K8S cluster are called Worker Nodes. When a Node goes down, the workload on it will be automatically transferred to other nodes by the Master.

2. Core component-Master component

（1）It was apiserver

Used to expose the Kubernetes API. Any resource request or call operation is performed through the interface provided by kube-apiserver. HTTP Restful API is used to provide interface services. All addition, deletion, modification, query and monitoring operations of object resources are handed over to the API Server for processing and then submitted to Etcd storage.

It can be understood that API Server is the request entry service of K8S. The API Server is responsible for receiving all K8S requests (from the UI interface or CLI command line tool), and then notifying other components to work according to the user's specific requests. It can be said that the API Server is the brain of the K8S cluster architecture.

（2）Kube-controller-manager

The operation management controller is a background thread that handles regular tasks in the K8S cluster. It is the automated control center for all resource objects in the K8S cluster.
In a K8S cluster, one resource corresponds to a controller, and the Controller manager is responsible for managing these controllers.

Composed of a series of controllers, it monitors the status of the entire cluster through the API Server and ensures that the cluster is in the expected working state. For example, when a Node unexpectedly crashes, the Controller Manager will promptly discover and execute an automated repair process to ensure that the cluster is always in good working order. Expected working condition.

These controllers mainly include
Node Controller : Responsible for detecting and responding to node failures.
•Replication Controller : Responsible for ensuring that the number of Pod copies associated with an RC (resource object Replication Controller) in the cluster always maintains the preset value. It can be understood as ensuring that there are and are only N Pod instances in the cluster, where N is the number of Pod copies defined in RC.
•Endpoints Controller : Fills in endpoint objects (that is, connects Services and Pods), and is responsible for monitoring changes in Services and corresponding Pod copies. It can be understood that an endpoint is an access point exposed by a service. If you need to access a service, you must know its endpoint.
•Service Account & Token Controllers : Create default accounts and API access tokens for new namespaces.
•ResourceQuota Controller (resource quota controller) : Ensure that the specified resource object will not overoccupy the system's physical resources at any time.
•Namespace Controller (namespace controller) : manages the life cycle of namespace.
•Service Controller : An interface controller between the K8S cluster and the external cloud platform.

（3）Kube-scheduler

It is the process responsible for resource scheduling and selects an appropriate Node node for the newly created Pod according to the scheduling algorithm.

It can be understood as the scheduler of all K8S Node nodes. When a user wants to deploy a service, the Scheduler will select the most appropriate Node to deploy the Pod based on the scheduling algorithm.
•Predicate
•Priorities

The API Server receives the request to create a batch of Pods. The API Server will ask the Controller-manager to create Pods according to the preset template. The Controller-manager will go to the Scheduler through the API Server to select the most suitable Node node for the newly created Pod. For example, running this Pod requires 2C4G resources, and the Scheduler will filter out Node nodes that do not meet the policy through the preselection policy. The remaining resources in the Node node are reported to the API Server and stored in etcd. The API Server will call a method to find the remaining resources of all Node nodes in etcd, and then compare it with the resources required by the Pod. If a Node node has insufficient resources Or if you do not meet the conditions of the pre-selection strategy, you will not be able to pass the pre-selection. The nodes screened out in the pre-selection stage will be scored and ranked according to the optimization strategy in the pre-selection stage, and the Node with the highest score will be selected. For example, a Node with richer resources and smaller load may have a higher ranking.

3. Configure storage center

（1）etcd

K8S storage service. etcd is a distributed key-value storage system that stores key configurations and user configurations of K8S. Only the API Server in K8S has read and write permissions, and other components must pass the API Server interface to read and write data.

4. Node component

（1）Kubelet

The monitor of the Node node and the communicator with the Master node. Kubelet is the "eyeliner" of the Master node installed on the Node node. It will regularly report to the API Server the status of the services running on its Node node, and accept instructions from the Master node to take adjustment measures.

Obtain the expected status of the Pod on its own node from the Master node (such as what container to run, the number of running replicas, how to configure the network or storage, etc.), and directly interact with the container engine to implement the life cycle management of the container. If the status of the Pod on its own node is different from If the expected state is inconsistent, call the corresponding container platform interface (that is, the docker interface) to reach this state.

Manage the cleanup of images and containers to ensure that the images on the nodes do not occupy full disk space and the exited containers do not occupy too many resources.

Summary:
In a Kubernetes cluster, a kubelet service process is started on each Node (also known as Worker Node). This process is used to process tasks assigned by the Master to this node and manage Pods and containers in the Pods. Each kubelet process will register the node's own information on the API Server, regularly report the usage of node resources to the Master, and monitor container and node resources through cAdvisor.

（2）For Proxy

The Pod network proxy is implemented on each Node node, which is the carrier of Kubernetes Service resources and is responsible for maintaining network rules and four-layer load balancing. Responsible for writing rules to iptables and ipvs to implement service mapping access.

Kube-Proxy itself does not directly provide a network for Pods. The Pod's network is provided by Kubelet. Kube-Proxy actually maintains a virtual Pod cluster network.
Kube-apiserver updates Kubernetes Service and maintains endpoints by monitoring Kube-Proxy.

The load balancing of microservices in the K8S cluster is implemented by Kube-proxy. Kube-proxy is the load balancer inside the K8S cluster. It is a distributed proxy server that runs a Kube-proxy component on each node of K8S.

(3) docker or rocket

The container engine runs the container and is responsible for the local container creation and management.
When kubernetes schedules a pod to a node, the kubelet on the node instructs docker to start a specific container. Then, kubelet will continuously collect container information through docker, and then submit it to the master node. Docker will pull the container image and start or stop the container as usual. The only difference is that this is controlled by an automated system rather than manually performed by an administrator on each node.

5. Kubernetes core concepts

Kubernetes contains many types of resource objects: Pod, Label, Service, Replication Controller , etc.

All resource objects can be added, deleted, modified, checked, etc. through the kubectl tool provided by Kubernetes, and stored in etcd for persistent storage.

Kubernets is actually a highly automated resource control system that realizes advanced functions such as automatic control and automatic error correction by tracking and comparing the difference between the expected resource status saved in etcd storage and the actual resource status in the current environment.

（1）Pod

Pod is the smallest/simplest basic unit created or deployed by Kubernetes. A Pod represents a process running on the cluster.
Pods can be understood as pea pods, and each container in the same Pod is a pea.

A Pod consists of one or more containers. The containers in the Pod share network, storage and computing resources and run on the same Docker host.
Multiple containers can run in a Pod, also called SideCar mode. In a production environment, a single container or multiple containers with strong correlation and complementarity form a Pod.

Containers in the same Pod can access each other through localhost, and can mount all data volumes in the Pod; however, containers between different Pods cannot access through localhost, nor can they mount the data volumes of other Pods.

(2) Pod controller

Pod controller is a template for Pod startup, which is used to ensure that Pods started in K8S should always run according to user expectations (number of copies, life cycle, health status check, etc.).

K8S provides numerous Pod controllers , the following are commonly used:
•Deployment : stateless application deployment. The role of Deployment is to manage and control Pods and ReplicaSets, and control them to run in the state expected by the user.

•Replicaset : Ensures the expected number of Pod replicas. The role of ReplicaSet is to manage and control Pods and control them to work well. However, ReplicaSet is controlled by Deployment.

It can be understood that Deployment is the general contractor, who is mainly responsible for supervising the work of the worker Pods below and ensuring that the number of Pods required by the user is working at all times. If you find that a worker Pod is out of service, quickly pull in a new Pod to replace it. ReplicaSet is the sub-contractor under the general contractor.
From the perspective of K8S users, users will directly operate the Deployment deployment service, and when the Deployment is deployed, K8S will automatically generate the required ReplicaSet and Pod. Users only need to care about Deployment and not ReplicaSet.
The resource object Replication Controller is the predecessor of ReplicaSet. It is officially recommended to use Deployment to replace Replication Controller to deploy services.

•Daemonset : Ensure that all nodes run the same type of Pod, and ensure that there is one such Pod running on each node. It is usually used to implement system-level background tasks.

•Statefulset : stateful application deployment

•Job : One-time task. According to the user's settings, the Pod managed by the Job will automatically exit after the task is successfully completed.

•Cronjob : Periodic scheduled tasks

（3）Label

Tags are a unique management method of K8S, which facilitates the classification and management of resource objects.
Labels can be attached to various resource objects, such as Node, Pod, Service, RC, etc., and are used to associate objects, query and filter.
A Label is a key-value pair, where the key and value are specified by the user.
A resource object can define any number of Labels, and the same Label can also be added to any number of resource objects, or it can be added or deleted dynamically after the object is created.
Multi-dimensional resource grouping management functions can be achieved by bundling one or more different Labels with specified resource objects.

Similar to Label, there is also Annotation .
The difference is that a valid tag value must be 63 characters or less, and must be empty or start and end with alphanumeric characters ([a-z0-9A-Z]), and can include dashes (-), underscores ( _), dot (.) and letters or numbers. Comment values have no character length limit.

(4) Label selector (Label selector)

Defining a Label for a resource object is equivalent to giving it a label; then you can query and filter resource objects that have certain Labels through the label selector (Label selector).
There are currently two types of tag selectors: based on equivalence relationships (equal to, not equal to) and based on set relationships (belongs to, does not belong to, exists).

（5）Service

In a K8S cluster, although each Pod will be assigned a separate IP address, because Pods have a life cycle (they can be created and will not be restarted after being destroyed), they may change at any time due to business changes. As a result, this IP address will also disappear when the Pod is destroyed.

Service is the core concept used to solve this problem.
Service in K8S does not mean "service" as we often say, but more like a gateway layer, which can be regarded as the external access interface and traffic balancer of a group of Pods that provide the same service.
Which Pods the Service acts on are defined through label selectors.
In a K8S cluster, Service can be regarded as the external access interface of a group of Pods that provide the same service. The service that the client needs to access is the Service object. Each Service has a fixed virtual IP (this IP is also called Cluster IP), which is automatically and dynamically bound to the backend Pod. All network requests directly access the virtual IP of the Service, and the Service will automatically forward to the backend. .
In addition to providing a stable external access method, Service can also function as a load balancer, automatically distributing request traffic to all back-end services. Service can transparently scale horizontally to customers. ).
The key to realizing the service function is kube-proxy. kube-proxy runs on each node and monitors changes in service objects in the API Server. The network can be implemented through the following three traffic scheduling modes: userspace (obsolete), iptables (on the verge of being abandoned), and ipvs (recommended, best performance) forwarding.

Service is the core of K8S services. It shields service details and exposes service interfaces to the outside in a unified way, truly achieving "microservices". For example, one of our service A has deployed 3 copies, that is, 3 Pods; for users, they only need to pay attention to the entrance of a Service, and do not need to worry about which Pod should be requested.
The advantages are very obvious: on the one hand, external users do not need to be aware of IP changes caused by unexpected crashes of services on Pods or K8S restarting Pods. External users also do not need to be aware of IP changes caused by Pod replacements due to upgrades or service changes. Variety.

（6）Ingress

Service is mainly responsible for the network topology within the K8S cluster. So how does the outside of the cluster access the inside of the cluster? Ingress is needed at this time. Ingress is the access layer of the entire K8S cluster and is responsible for communication inside and outside the cluster.
Ingress is a layer 7 application that works under the OSI network reference model in the K8S cluster. It is an externally exposed interface. The typical access method is http/https.
Service can only perform traffic scheduling on the fourth layer, in the form of ip+port. Ingress can schedule business traffic in different business domains and different URL access paths.
For example: the client requests http://www.qhw.com:port ---> Ingress ---> Service ---> Pod

（7）Name

Since K8S uses "resources" internally to define each logical concept (function), each "resource" should have its own "name".
"Resources" include api version (apiversion), category (kind), metadata (metadata), definition list (spec), status (status) and other configuration information.
The "name" is usually defined in the "metadata" information of the "resource". Must be unique within the same namespace.

（8）Namespace

As projects increase, personnel increase, and cluster scale expands, a method is needed that can logically isolate various "resources" within K8S. This is Namespace.
Namespace was born to divide a K8S cluster into several virtual cluster groups whose resources cannot be shared.
The names of "resources" in different namespaces can be the same, but the "names" of the same type of "resources" in the same namespace cannot be the same.
Proper use of K8S's Namespace can enable cluster administrators to better classify, manage and browse the services delivered to K8S.
The namespaces that exist by default in K8S include: default, kube-system, kube-public, etc.
To query a specific "resource" in K8S, you need to bring the corresponding Namespace.

6. k8s workflow

1. The user sends a request to kube apiserver through authentication to create a pod request.

2. apiserver will write relevant information into etcd.

3. The apiserver will find the kube controller-manager to create the corresponding pod resources.

4. The controller-manager will read the data in etcd through apiserver to find the corresponding pod information.

5. The apiserver finds the scheduler to schedule the pod. Regarding where to transfer the pod, the apiserver reads the data in etcd to obtain the relevant node information, and finds the node most suitable for running the pod. Finally, the scheduler schedules the pre-selection strategy and the preferred strategy through an algorithm. Calculate which node the pod should be scheduled to run on.

6. The scheduler finds the kubelet component on the corresponding node through apiserver, creates and maintains pods through this component, and related containers are created through docker.

7. Then these pods are associated to form a cluster through kube proxy. The kube proxy uses service resources to expose them using a unified IP address. External users can use this IP address to access the services running in the pod.

8. Kubelet will monitor how many resources are running on this node, as well as pod-related status and information, and send them to apiserver, which will write the information to etcd and save it. Pod maintenance is done by controller-manager. When the number of pods does not meet the preset number, it will create the corresponding preset number to ensure the total number of pods.

Three: K8s installation

1. Common K8S installation and deployment methods

(1) Minikube

Minikube is a tool that can quickly run a single-node micro K8S locally. It is only used for learning and previewing some features of K8S.
Deployment address: https://kubernetes.io/docs/setup/minikube

（2）Cube admin

Kubeadm is also a tool that provides kubeadm init and kubeadm join for rapid deployment of K8S clusters, which is relatively simple.
https://kubernetes.io/docs/reference/setup-tools/kubeadm/kubeadm/

2. Binary installation and deployment

The first choice for production, download the binary package of the distribution version from the official, manually deploy each component and self-signed TLS certificate to form a K8S cluster, recommended for novices.
https://github.com/kubernetes/kubernetes/releases

Kubeadm lowers the deployment threshold, but blocks many details, making it difficult to troubleshoot problems. If you want to make it easier and more controllable, it is recommended to use binary packages to deploy Kubernetes clusters. Although manual deployment is more troublesome, you can learn a lot of working principles during the process, which is also beneficial to later maintenance.

3. The difference between k8s deployment binary and high availability

●Binary deployment
is difficult to deploy, easy to manage, has good cluster expansion performance and is more
stable. When the cluster scale reaches a certain scale (hundreds of nodes, tens of thousands of Pods), the binary stability is higher than that of kubeadm deployment
. When a failure occurs, the host machine will , the process will also start

●kubeadm deployment is
simple to deploy but difficult to manage.
It allows components and services to be managed by containers. The fault recovery time is slower than binary. When a fault
occurs, start the host, then start the process, and finally start the container, so that the cluster can be restored. Slower than binary

Summarize

ansible application-level multi-machine orchestration tool
docker container engine container runtime
dockerfile build image
docker compose single-machine container cluster orchestration tool

docker swarm Docker's container multi-machine orchestration tool is a tool for realizing Docker container cluster management and scheduling.
kubernetes Google's container multi-machine orchestration tool occupies more than 80% of the market share and has become the de facto standard for container orchestration tools
mesos + marathon mesos : Distributed resource management framework, which can uniformly schedule and manage the hardware resources of multiple hosts in the cluster
marathon: Mesos' container orchestration framework, used to schedule and run container services

What components does K8S have?
K8S hastwo types of nodes : master and worker node.
The master node has apiserver controller-manager scheduler and etcd is used as the database of the k8s cluster.
The node node has kubelet kube-proxy container engine/container runtime (docker, containerd).

What does the component do?
apiserver : It is the unified access entrance for all service requests.
Controller-manager : The controller manager is responsible for managing resource objects such as Pod replica sets, namespaces, endpoints, nodes, and deployed controllers; monitoring the status of the entire K8S cluster through apiserver. And ensure that the cluster is in the expected working state
scheduler : Resource scheduler, responsible for scheduling Pod resources, selecting the most suitable node node for the deployed Pod through scheduling algorithm (pre-selection strategy, preferred strategy) etcd: K8S cluster database,
is a A distributed database with a key-value storage structure, responsible for storing all important information of the K8S cluster. Only apiserver has read and write permissions.

kubelet : receives requests from the master, creates and manages Pods and containers, interacts with the container engine to manage the life cycle of the container; collects node resource information and Pod running status and reports to the master's apiserver kube-proxy: as
a service The carrier of resources, implements the network proxy of Pod, maintains network rules and four-layer load balancing work.
Container engine/container runtime: runs the container

What is the workflow for creating Pods in K8S?
1) The user sends a request to create a Pod to the apiserver on the master node through the client.
2) The apiserver will first write the request information into etcd and save it, and then find the controller-manager to create the Pod resource according to the preset resource configuration template.
3) Then The controller-manager will go to the scheduler through the apiserver to select the most suitable node for the newly created Pod.
4) The scheduler selects the most suitable node for scheduling through the pre-selection strategy and optimization strategy of the scheduling algorithm.
5) Then it will find the corresponding node through the apiserver. The kubelet on the node node creates and manages Pods
6) The kubelet will interact with the container engine to manage the life cycle of the Pod/container
7) Users can also write network rules on kube-proxy through apiserver, create service resources, and implement Pod control Service discovery and load balancing

K8S resource object
Pod: It is the smallest unit that K8S can create and manage. A Pod can contain one or more application containers, and the containers in a Pod share resources such as network and storage.
Pod controller:

deployment : deploy stateless applications. Also responsible for management

replicaset (maintaining the number of Pod copies as expected) and Pod (a containerized application process)
statefulset : deploying stateful applications
daemonset : deploying the same Pod on all node nodes
job : deploying short-term task Pods at one time, Pod
Cronjob will automatically exit after executing the task: Pods for short-term tasks are periodically deployed, and the Pod will automatically exit after executing the task.