1. Introduction to Kubernetes
1. What is Kubernetes?
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.
Origin:
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 G0 language using Borg's ideas and donated to the CNCF Foundation for open source
meaning:
The word originates from the Greek helmsman and pilot.
Official website:
GitHub: GitHub - kubernetes/kubernetes: Production-Grade Container Scheduling and Management
2. 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, if necessary Restart the program
Imagine what if the request volume of the service increases and the deployed service cannot respond? The traditional approach is 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 and deploy them. After the service is good, connect to load balancing to share the pressure of existing services.
So a problem arises: from monitoring alarms to deploying services, human intervention is required! So, is there a way to automatically complete the deployment, update, uninstallation, expansion and contraction of services?
And this is what K8S has to do: automate operation and maintenance of the container (Docker) program. The goal of K8s is to make deploying containerized applications simple and efficient
K8S solves several pain points of naked Docker:
●If used on a single machine, it cannot be effectively clustered.
●As the number of containers increases, management costs rise.
●No effective disaster recovery and self-healing mechanism
●Without a preset orchestration template, rapid and large-scale container scheduling cannot be achieved
●There is no unified configuration management center tool
●No management tools for container life cycle
●No graphical operation and maintenance management tools
k8s provides a series of functions such as container orchestration, resource scheduling, elastic scaling, deployment management, and service discovery.
3. Characteristics of k8s
●Elastic expansion and contraction
Use commands, UI, or automatically and quickly expand and shrink application instances based on CPU usage to ensure high availability during application business peak concurrency: recycle resources during low business peaks and run services at minimum cost
●Self-healing
Restart failed containers when a node fails, replace and redeploy to ensure the expected number of replicas: kill containers that fail health checks and will not process client requests until they are ready to ensure that online services are not interrupted
●Service discovery and load balancing
K8s provides a unified access entrance (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.
●Automatic release (default rolling release mode) and rollback
K8S uses a rolling update strategy to update applications, updating one Pod at a time instead of deleting all Pods at the same time. If a problem occurs during the update process, the changes will be rolled back to ensure that the upgrade does not affect the business.
●Centralized configuration management and key management
Manage confidential data and application configurations without exposing sensitive data in images, improving the security of sensitive data. And some commonly used configurations can be stored in K8S to facilitate application use.
●Storage orchestration, supports plug-in storage and arranges plug-in storage resources
Mounting external storage systems, whether from local storage, public cloud (such as AWS), or network storage (such as NFS, Glusterfs, Ceph), is used as part of the cluster resources, greatly improving storage usage flexibility
●Task batch processing running
Provide one-time tasks and scheduled tasks: meet the scenarios of batch data processing and analysis
2. k8s 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 is down or 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.
1. Master component
Master: cluster control management node, all commands are processed by the master
●Kube-apiserver
Used to expose Kubernetes API, any resource request or call operation is performed through the interface provided by kube-apiserver. HTTP Restful API
Provides interface services. All additions, deletions, modifications, 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. API Server is responsible for receiving all K8S requests (from UI interface or CLI command line tool),
Then according to the user's specific request, other components are notified to work. It can be said that the API Server is the brain of the K8S cluster architecture.
●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, a resource corresponds to a controller, and the Controller manager is responsible for managing these controllers.
It consists of a series of controllers that monitor the status of the entire cluster through APIServer and ensure 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 the expected working state. working status
These controllers mainly include:
●Node Controller: Responsible for detecting and responding to node failures
●Replication Controller: Responsible for ensuring that the Pod associated with an RC (resource object Replication Controller) in the cluster
The number of copies always remains at the default 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 Service 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 (Service Account & Token Controllers): Create default accounts and API access tokens for new namespaces
●ResourceQuota Controller (resource quota controller): ensures that the specified resource object will not overoccupy the system's physical resources at any time
●Namespace Controller: manages the life cycle of namespace
●Service Controller: An interface controller between the K8S cluster and the external cloud platform
●Kube-scheduler
It is the process responsible for resource scheduling. It selects a suitable 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.
●Budget strategy (predicate)
●Priorities
2. Configure storage center - 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. Other components must read and write data through the API Server interface.
3. Worker Node component
3.1 Node node workflow:
Node nodes can be dynamically added to the kubernetes cluster, provided that the node has been correctly installed, configured and started with the above-mentioned key processes. By default, kubelet will register itself with the Master, which is also the Node management method recommended by kubernetes.
Once a Node is included in the cluster management scope, kubelet will regularly report its own situation to the Master, as well as which Pods were running before, etc., so that the Master can know the resource usage of each Node and implement an efficient and balanced resource scheduling strategy.
If the Node fails to report information on time, it will be judged as disconnected by the Master, the Node status will be marked as Not Ready, and then the Master will trigger the workload transfer process.
●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 report itself to the API Server regularly.
The status of the services running on the 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 containers are running, the number of running replicas, how the network or storage is configured, etc.),
Directly interact with the container engine to implement container life cycle management. If the status of the Pod on your own node is inconsistent with the expected status, call the corresponding container platform interface (i.e. docker interface) to achieve this status.
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.
●Kube-Proxy
The pod network agent 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 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.
●docker engine (docker or rocket)
Container engine runs containers and is responsible for local container creation and management.
3. K8s 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 saved in etcd for persistent storage.
Kubernets is actually a highly automated resource control system. It 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.
●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 (sideCara) mode. In a production environment, a single container or multiple containers with strong correlation and complementarity form a Pod.
Containers between 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.
●Pod controller (five major controllers)
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 users.
●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, 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 subcontractor 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 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. 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
●Label
Tags are a unique management method of K8S, which facilitates 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. The same Label can also be added to any number of resource objects. It can also be dynamically added or deleted 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 (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. Annotation values have no character length limit
●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)
●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 what we often call "service", but more like a gateway layer. It 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 is through labels. defined by selector.
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 back-end Pod. All network requests directly access the virtual IP of the Service, and the Service will automatically forward it to the back-end.
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.
Network forwarding can be achieved through the following three traffic scheduling modes: userspace (obsolete), iptables (on the verge of being abandoned), and ipvs (recommended, with the best performance).
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 services A has deployed 3
There are three copies, that is, three Pods; for users, they only need to pay attention to the entrance 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 be aware of IP changes caused by unexpected crashes of services on Pod. or K8S restarting Pods. External users also do not need to be aware of Pod replacements caused by upgrades and service changes. IP changes.
●Ingress
Service is mainly responsible for the network topology inside the K8S cluster. So how does the outside of the cluster access the inside of the cluster? At this time, Ingress is needed.
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 in the K8S cluster under the OSI network reference model. 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.ly.com:port ---> Ingress ---> Service ---> Pod
●Name
Since K8S internally uses "resources" to define each logical concept (function), each "resource" should have its own "name"
"Resources" include configuration information such as api version (apiversion), category (kind), metadata (metadata), definition list (spec), status (status), etc.
The "name" is usually defined in the "metadata" information of the "resource". Must be unique in the same namespace
●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 thousands of 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 Namespace can enable cluster administrators to better classify, manage and browse the services delivered to K8S.
The default namespaces in K8S include: default, kube-system, kube-public, etc.
To query a specific "resource" in K8S, you must bring the corresponding Namespace.
k8s architecture and workflow
master node: API server shceduler controller-manager
worker node node: kubelet kube-proxy docker engine
Workflow or functions of each component:
1. The user sends a request to the API server through the client. The API Server receives the request and creates a batch of Pods, and stores the pod data in etcd;
2. The Controller-manager reads etcd through the API Server to create a Pod according to the preset template, and the Controller-manager uses the API Server to ask the Scheduler to select the appropriate node for the newly created Pod;
3. Scheduler selects the most suitable Node node based on the budget strategy and optimization strategy, and then finds the kubelet on the corresponding node through the api server;
4. Kubelet performs Pod creation operations based on the scheduling results and monitors the node nodes. At the same time, it will regularly report the service status of its own node node running to the api server and store it in etcd;
5. The container on the node node specifically implements the creation of pod according to the instructions of Kubelet;
6. kube-proxy on the node node is used to implement the network proxy of the pod, which is the carrier of Kubernetes Service resources. Customers can access the business in the pod through the IP provided by kube-proxy