Theoretical understanding of Kubernetes entry

Foreword:

As an operation and maintenance engineer, if you don't know k8s yet, then you are really out. This chapter mainly introduces the entry-level theoretical part of k8s (Kubernetes).

1. Introduction to kubernetes

1. What is Kubernetes?

Kubernetes is a portable, extensible open source platform for managing containerized workloads and services that facilitates declarative configuration and automation. It has a large and rapidly growing ecosystem. Kubernetes services, support, and tools are everywhere.

Kubernetes takes its name from the Greek word meaning helmsman or pilot. The result of K8s as an abbreviation comes from calculating the eight letters between "K" and "s". Google open-sourced the Kubernetes project in 2014. Kubernetes combines Google's 15+ years of experience running production workloads at scale with the best ideas and practices from the community.

Reference official website: https://kubernetes.io/docs/concepts/overview/what-is-kubernetes/, which mainly introduces the basic concepts and application scenarios of kubernetes, the design concept of K8s, and what K8s can do and cannot do.

2. Why do you need K8S?

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

Imagine, what if the service request volume increases and the deployed service fails to 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 servers and deploy After a good service, access load balancing to share the pressure of existing services. This problem arises: from monitoring alarms to deploying services, human intervention is required in the middle! So, is there a way to automatically complete the deployment, update, uninstallation, expansion, and contraction of services? And this is what K8S does: automated operation Dimensionally manages containerized (Docker) programs.

The goal of K8S is to make deploying containerized applications simple and efficient.

K8s solves several pain points of running Docker naked:

1.单机使用，无法有效集群
2.随着容器数量的上升，管理成本攀升
3.没有有效的容灾、自愈机制
4.没有预设编排模板，无法实现快速、大规模容器调度
5.没有统一的配置管理中心工具
6.没有容器生命周期的管理工具
7.没有图形化运维管理工具

K8S provides a series of functions such as container orchestration, resource scheduling, elastic scaling, deployment management, and service discovery .

Second, the characteristics of K8S

(1) Elastic scaling : Use commands, UI, or automatically and quickly scale up and down application instances based on CPU usage to ensure high availability when applications are concurrent during peak business peaks; recycle resources during low business peaks to run services at minimal cost.

(2) Self-healing : Restart failed containers, replace and redeploy when nodes fail, guarantee the expected number of replicas; kill containers that fail health checks, and will not process client requests until they are not ready to ensure online service is not interrupted.

(3) Service discovery and load balancing : K8S provides a unified access entry (internal IP address and a DNS name) for multiple containers, and load balances all associated containers, so that users do not need to consider container IP issues.

(4) Automatic release (default rolling release mode) and rollback: K8S uses a rolling strategy to update applications, updating one Pod one at a time instead of deleting all Pods at the same time. If there is a problem during the update process, the changes will be rolled back to ensure that the upgrade does not Affected business.

(5) Centralized configuration management and key management : Manage confidential data and application configuration without exposing sensitive data in the image, improve the security of sensitive data, and store some commonly used configurations in K8S, which is convenient application use.

(6) Storage orchestration : support external storage and orchestrate external storage resources, mount external storage systems, whether from local storage, public cloud (eg: AWS), or network village storage (eg: NFS, Glusterfs, Ceph) All are used as part of cluster resources, which greatly improves the flexibility of storage usage.

(7) Batch processing and running of tasks: Provide one-time tasks and scheduled tasks to meet the scenarios of batch data processing and analysis.

3. K8S cluster architecture and components

K8S belongs to the master-slave device model (Master-Slave architecture) , that is, the master node replicates the scheduling, management and operation of the cluster, and the slave node is the computing workload node of the cluster. In K8S, the master node is generally called the Master node, and the slave node is called the Worker Node 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 occupy an independent server, because the Master is the brain of the entire cluster. If the node where the Master is located is down or unavailable, all control commands will be invalid. . In addition to the Master, other machines in the K8S cluster are called Worker Node nodes. When a Node goes down, the workload on it will be automatically transferred by the Master to other nodes.

Fourth, the core components of K8S

1.Master component

1.1 Be 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, and all object resource additions, deletions, changes, and monitoring operations are handed over to API Server for processing and then submitted to Etcd for storage .

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

1.2 kube-controller-manager

The operation management controller is the background thread that processes routine tasks in the K8S cluster, and is the automatic control center for all resource objects in the K8S cluster. In a K8S cluster, a resource corresponds to a controller, and the Controller manager replicates and manages these controllers.

It consists of a series of controllers. It monitors the status of the entire cluster through API Server and ensures that the cluster is in the expected working state. For example, when a Node goes down unexpectedly, the Controller Manager will detect and execute an automated repair process in time to ensure that the cluster is always in expected working state.

These controllers mainly include:

① Node Controller : Responsible for discovering and responding to node failures.

② Replication Controller : Responsible for ensuring that the Pod replica 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 N Pod instances in the cluster, where N is the number of Pod replicas defined in RC.

③ Endpoints Controller : Fill in the endpoint object (ie, connect Service and Pods), responsible for monitoring changes in Service and the corresponding Pod copy. It can be understood that the endpoint is an access point exposed by a service. If you need to access a service, then Its endpoint must be known.

④ Service Account & Token Controllers : Create a default account and API access token for the new namespace.

⑤ ResourceQuota Controller (namespace controller): Manage the life cycle of the namespace.

⑥ Service Controller : It belongs to an interface controller between the K8S cluster and the external cloud platform.

1.3 Be a scheduler

It is the process responsible for resource scheduling, and selects a suitable Node node for the newly created Pod according to the scheduling algorithm.

It can be understood as the scheduler of all Node nodes of K8S. When the user wants to deploy the service, the Scheduler will select the most suitable Node node to deploy the Pod according to the scheduling algorithm.

There are generally two strategies for the scheduling algorithm:

Budget strategy (predicate)

Priorities

1.4 Configuring Storage Center - etcd

K8S storage service. etcd is a distributed key-value storage system, which stores the key configuration and user configuration of K8S. In K8S, only API Server has read and write permissions, and other components can only read and write data through the API Server interface.

2. Node components

2.1Kubelet

The monitor of the Node node, as well as the communicator with the Master node, Kubelet is the "eyeline" that the Master node places on the Node node, it will regularly report to the API Server the status of the service running on its Node node, and accept the information from the Master node. Instructs to take corrective action.

Obtain the desired state of the Pod on its own node from the Master node (such as what container is running, the number of copies running, how the network or storage is configured, etc.), and directly interact with the container engine to realize the life cycle management of the container. If the expected state is inconsistent, call the corresponding container platform interface (that is, the interface of Docker) to achieve this state.

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

2.2 Be proxy

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

Kube-Proxy itself does not directly provide network to Pod. The network of Pod is provided by Kubelet, and what Kube-Proxy actually maintains is 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 a load balancer inside the K8s cluster, it is a distributed proxy server, and a Kube-Proxy component runs on each node of K8s.

2.3 docker or rocket

The container engine, which runs containers, is responsible for the creation and management of native containers. Now basically use docker

Five, Kubernetes core concepts

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

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

Kubernetes is actually a highly automated resource control system. It implements advanced functions such as automatic control and automatic error correction by tracking and comparing the difference between the expected state of resources saved in etcd storage and the actual resource state in the current environment.

1.Pod

A Pod is the smallest/simplest basic unit created or deployed by Kubernetes . A Pod represents a process running on a 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.

A Pod can run multiple containers, also known as SideCare mode. In a production environment, a single container or multiple containers with strong correlation and complementarity are generally used to form a Pod.

The same Pod and container can access each other through localhost, and can mount all data volumes in the Pod; but containers between different Pods cannot use localhost to access, nor can they mount data volumes of other Pods.

Pod network communication in Kubernetes is as follows:

2. Pod Controller

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

There are many Pod controllers provided in K8S, and the commonly used ones are as follows:

① Deployment : Stateless application deployment. The role of Deployment is to manage and control Pods and ReplicaSets, and control them to run in the state desired by the user.

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

It can be understood that Deployment is the general contractor, mainly responsible for supervising the work of the worker Pods under it, ensuring that the number of Pods required by the user is working at all times. If you find that a worker Pod is not working, quickly pull a new one. Pod comes over to replace it. And ReplicaSet is a small contractor under the head of the contractor.

From the perspective of K8S users, users only need to be related to Deployment and not to worry about the predecessor of ReplicaSet. It is officially recommended to use Deployment instead of 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, which is usually used to implement system-level background tasks.

④ Statefulset : Stateful application deployment.

⑤ Job : A one-time task. According to the user's settings, the Pod managed by the Job automatically exits after the task is successfully completed.

⑥ Cronjob : Periodically scheduled tasks.

3.Label

Label is a management method characteristic of K8S, which is convenient for classifying and managing resource objects.

Labels can be attached to various resource objects, such as: Node, Pod, Service, RC, etc., 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, and can also be dynamically added or deleted after the object is created.

The multi-dimensional resource grouping management function can be realized by bundling one or more different Labels to the specified resource object.

Similar to Label, there is Annotation.

The difference is that a valid tag value must be 63 characters or less, and must be empty or alphanumeric ([a-z0-9A-Z]) at the beginning and end, and can contain dashes (-), underscores (), A dot (.) and a letter or number. Comment values ​​have no character length limit.

4 .Label selector (Label selector)

Defining a Label for a resource object is equivalent to adding a label to it, and then you can query and filter resource objects with certain Labels through the Label selector.

There are currently two types of tag selectors: based on equivalence (equal, not equal) and set based (belongs, does not belong, exists).

5.Service

In a K8S cluster, although each Pod will be assigned a separate IP address, since 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 with the destruction of the Pod.

And Service is the core concept used to solve this problem.

Service in K8S is not the meaning of "service" that we often say, but more like a gateway layer, which can be regarded as a set of external access interfaces and traffic balancers for Pods that provide the same service.

Which Pods a Service acts on is defined by a label selector.

In a K8S cluster, a Service can be regarded as an external access interface for a group of Pods that provide the same service. The service that the client needs to access is the Service object. each Service

There is a fixed virtual ip (this ip is also called Cluster IP), which is automatically and dynamically bound to the Pod of the backend. All network requests directly access the virtual ip of the Service, and the Service will automatically forward it to the backend.

In addition to providing stable external access, Service can also function as Load Balance, automatically distributing request traffic to all services on the backend. Service can scale horizontally transparently to customers. ).

The key to realizing the function of service is kube-proxy. kube-proxy runs on each node, monitoring the changes of service objects in API Server,

The following three traffic scheduling modes are available:

**userspace (abandoned), iptables (on the verge of abandonment), ipvs (recommended, best performance)** to achieve network forwarding.

Service is the core of K8S services, which shields service details and exposes service interfaces in a unified manner, truly achieving "microservices". For example, one of our service A deploys 3 replicas, that is, 3 Pods; for users, they only need to pay attention to the entry of one 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 perceive IP changes caused by unexpected service crashes on Pod. and K8S restarting Pods, and external users also do not need to perceive Pod replacements caused by upgrades and service changes. IP changes.

6.Ingress

Service is mainly responsible for the network topology inside the K8S cluster, so how can 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 and exposes the interface to the outside world. The typical access method is http/https. Service can only perform traffic scheduling at the fourth layer, in the form of ip+port. Ingress can schedule business traffic of different business domains and different URL access paths.

7 .Name

Since K8S uses "resources" to define each logical concept (function), each "resource" should have its own "name".

"Resources" have configuration information such as api version (apiversion), category (kind), metadata (metadata), definition list (spec), and status (status).

The "name" is usually defined in the "metadata" information of the "resource". Must be unique within the same namespace.

8.Namespace

With the increase of projects, the increase of personnel, and the expansion of the scale of the cluster, a method that can logically isolate various "resources" in K8S is required, which is Namespace. Namespace was born to divide a K8S cluster into thousands of virtual cluster groups whose resources cannot be shared. "Resources" in different Namespaces can have the same name, and the same "Resources" in the same Namespace cannot have the same "Name".

Reasonable use of K8S's Namespace enables cluster administrators to better manage and browse the services delivered to K8S. The default namespaces in K8S are: default, kube-system, kube-public, etc.

To query a specific "resource" in K8S, you need to bring the corresponding Namespace.

6. Workflow of K8S to create POd

1.首先API Server接受请求创建一批 POd，API Server 会把相关信息写入到etcd当中 。然后API Server会让Controller-manager 按照预设的模板（就是按照etcd里的信息）去创建Pod
2.Controller-manager会通过API Server 去找 Scheduler 为新创建的POD，Scheduler会通过预选策略或择优策略选择一个为新创建的Pod 最合适nod节点（Schduler是通过etcd里的pod信息来进行筛选node的）
3.scheduler找到node后，会通过API Server去找到 对应node上面的 Kubelet，然后通过kubelet去创建（创建的话要通过docker引擎去创建），维护pod并且管理pod的生命周期
4.创建完pod群集之后 ，kube-proxy 讲这些pod 关联起来，使用一个service资源（pod群集统一使用一个ip地址，并且暴露出去）
5.外部用户通过 这个暴露的ip 访问到pod 里面运行的业务
6.运维人员通过 node节点中的Kubelet 监控 pod 中跑了哪些业务 ，使用了哪些资源和一些相关状态，然后kubelet通过 kube_apiserver 将这些信息写入到 etcd中 保存起来