Kubernetes has become the king in the field of container orchestration.It is a container-based cluster orchestration engine with multiple features such as cluster expansion, rolling upgrade and rollback, elastic scaling, automatic healing, and service discovery.
This article will take everyone to quickly understand kubernetes and understand what we are talking about when we talk about kubernetes.
From a macro perspective, the overall architecture of kubernetes, including Master, Node, and Etcd.
Master is the master node, responsible for controlling the entire kubernetes cluster. It includes Api Server, Scheduler, Controller and other components. They all need to interact with Etcd to store data.
Api Server: Mainly provides a unified entrance for resource operations, so that direct interaction with Etcd is blocked. Functions include security, registration and discovery, etc.
Scheduler: Responsible for scheduling Pod to Node according to certain scheduling rules.
Controller: Resource control center to ensure that resources are in the expected working state.
Node is a working node that provides computing power for the entire cluster.It is where the container really runs, including running containers, kubelet, and kube-proxy.
Kubelet : The main tasks include managing the life cycle of containers, monitoring with cAdvisor, health checks, and regular reporting of node status.
kube-proxy : Mainly use service to provide service discovery and load balancing within the cluster, while monitoring changes in service/endpoints and refreshing load balancing.
Start with the creation of deployment
Deployment is a controller resource used to orchestrate pods, which we will introduce later. Here we take deployment as an example to see what each component in the architecture does in the process of creating deployment resources.
First, kubectl initiates a request to create a deployment
The apiserver receives the request to create a deployment and writes the related resources into etcd; after that, the interaction between all components and apiserver/etcd is similar
The deployment controller list/watch resource changes and initiates a request to create a replicaSet
The replicaSet controller list/watch resource changes and initiates a pod creation request
The scheduler detects unbound pod resources, and selects the appropriate node for binding through a series of matching and filtering
Kubelet finds that it needs to create a new pod on node, and is responsible for pod creation and subsequent life cycle management
kube-proxy is responsible for initializing service-related resources, including network rules such as service discovery and load balancing
At this point, after the division of labor and coordination of the various components of kubenetes, the entire process from creating a deployment request to the normal operation of specific pods has been completed.
Among the many api resources of kubernetes, pod is the most important and basic, and the smallest deployment unit.
The first question we have to consider is, why do we need pods? Pod can be said to be a container design pattern.It is designed for containers with "super intimate" relationships.We can imagine scenarios such as deploying war packages and log collection in servelet containers.These containers often need to share networks, shared storage, and sharing.Configuration, so we have the concept of pod.
For pods, different containers use the infra container to uniformly identify the external network space, and by mounting the same volume, it is natural to share storage, for example, it corresponds to a directory on the host.
Container orchestration is the housekeeping skill of kubernetes, so we need to understand it. There are many orchestration-related control resources in kubernetes, such as deployment for orchestrating stateless applications, statefulset for orchestrating stateful applications, daemonset for orchestrating daemons, job/cronjob for orchestrating offline services, and so on.
Let's take the most widely used deployment as an example. The relationship between deployment, replicatset, and pod is a relationship controlled by layers. Simply put, replicaset controls the number of pods, and deployment controls the version attribute of replicaset. This design pattern also realizes the foundation for the two most basic orchestration actions, namely, the horizontal expansion and contraction of quantity control, and the update/rollback of version attribute control.
Horizontal expansion and contraction
Horizontal expansion and contraction is very easy to understand.We only need to modify the number of pod copies controlled by the replicaset, for example, from 2 to 3, then the horizontal expansion is completed, and vice versa.
Update/rollback reflects the necessity of replicaset. For example, we need to change the version of 2 instances from v1 to v2, then the number of pod replicas controlled by the v1 version of the replicaset will gradually change from 2 to 0, and the number of pods controlled by the v2 version of the replicaset will be annotated from 0 to 2.Only the v2 version of the replicaset has been updated. The action of rollback is the opposite.
It can be found that in the above example, when we update the application, the pods are always upgraded one by one, and at least 2 pods are available and at most 4 pods provide services. The benefits of this "rolling update" are obvious.Once the new version has a bug, the remaining two pods can still provide services, and at the same time facilitate quick rollback.
In practical applications, we can control the rolling update strategy by configuring RollingUpdateStrategy.maxSurge indicates how many new Pods can be created by the deployment controller; and maxUnavailable refers to how many old Pods can be deleted by the deployment controller.
Network in kubernetes
We understand how container orchestration is done, so how do containers communicate?
When it comes to network communication, kubernetes must first have a "three links" basis:
Can communicate between node and pod
Node pods can communicate
Pods between different nodes can communicate
In simple terms, communication between different pods is achieved through the cni0/docker0 bridge, and node access to the pod is also through the cni0/docker0 bridge.
There are many implementation schemes for pod communication between different nodes, including the vxlan/hostgw mode of flannel which is more common now. Flannel learns the network information of other nodes through etcd, and creates a routing table for this node, ultimately enabling cross-host communication between different nodes.
Before understanding the next content, we must first understand a very important resource object: service.
Why do we need service? In microservices, pod can correspond to an instance, then service corresponds to a microservice. In the process of service invocation, the emergence of service solves two problems:
The pod's ip is not fixed, and it is unrealistic to use a non-fixed ip to make network calls
Service calls need to load balance different pods
The service selects the appropriate pod through the label selector, and constructs an endpoint, that is, a pod load balancing list. In actual use, we generally
app=xxxlabel the pod instances of the same microservice with similar tags, and create a service with a tag selector for
Service discovery and network call in kubernetes
With the above-mentioned "three links" network foundation, we can start how the network calls in the microservice architecture are implemented in kubernetes.
This part of the content is actually talking about how Kubernetes implements service discovery.It is clearer.For more details, you can refer to the above article.Here is a brief introduction.
The first is the east-west traffic call, that is, the call between services. This part mainly includes two calling methods, namely clusterIp mode and dns mode.
clusterIp is a type of service.In this type mode, kube-proxy implements a VIP (virtual ip) form for service through iptables/ipvs. Only need to visit the VIP, you can load balanced access to the pod behind the service.
The figure above is an implementation of clusterIp, in addition to userSpace proxy mode (basically not used), and ipvs mode (better performance).
The dns mode is well understood.For a service in the clusterIp mode, it has an A record
service-name.namespace-name.svc.cluster.localthat points to the clusterIp address. Therefore, in general use, we can directly call service-name.
North-south traffic, that is, external requests to access the kubernetes cluster, mainly includes three methods: nodePort, loadbalancer, and ingress.
The nodePort is also a type of service.Through iptables, the ability to call the specific port on the host can access the service behind it.
Loadbalancer is another type of service, implemented through a load balancer provided by the public cloud.
We may need to create 100 nodePort/loadbalancer to access 100 services. We hope to access the internal kubernetes cluster through a unified external access layer, which is the function of ingress. Ingress provides a unified access layer, matching to different back-end services through different routing rules. Ingress can be regarded as "service of service". Ingress is often implemented in combination with nodePort and loadbalancer to complete the function.
So far, we have briefly understood the related concepts of kubernetes, roughly how it works, and how microservices run in kubernetes.