From a macro perspective, look at the overall architecture of kubernetes, including Master, Node and Etcd.
Master is the master node, responsible for controlling the entire kubernetes cluster, which 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, thus shielding direct interaction with Etcd. Its functions include security, registration and discovery, etc.
Scheduler: Responsible for scheduling Pods to Nodes according to certain scheduling rules.
Controller: The resource control center ensures that resources are in the expected working state.
Node is the working node, which provides computing power for the entire cluster. It is where the container actually runs, including running containers, kubelet, and kube-proxy:
kubelet: The main work includes managing the life cycle of the container, monitoring and health checking with cAdvisor, and regularly reporting node status.
kube-proxy: Mainly uses service to provide service discovery and load balancing within the cluster, while monitoring changes in service/endpoints and refreshing load balancing.
2. Deployment
Deployment is a controller resource used to orchestrate pods. Taking deployment as an example, let's take a look at what each component in the architecture does in the process of creating deployment resources.
First, kubectl initiates a request to create a deployment;
apiserver receives the deployment creation request and writes relevant resources to etcd; after that, all components interact with apiserver/etcd similarly;
Deployment controller list/watch resource changes and initiate a request to create a replicaSet;
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 its node and is responsible for the creation and subsequent life cycle management of the pod;
kube-proxy is responsible for initializing service-related resources, including network rules such as service discovery and load balancing;
At this point, through the division of labor and coordination among the various components of kubenetes, the entire process from creating a deployment request to the normal operation of each specific pod has been completed.
3. Pod
Among the many API resources in Kubernetes, pod is the most important and basic, and is the smallest deployment unit. The first question to consider is, why do you need pods? Pod can be said to be a container design pattern. It is designed for those containers with a "super close" relationship. You can imagine scenarios such as servinglet containers deploying war packages, log collection, etc. These containers often need to share networks, shared storage, and shared configurations. , hence the concept of pod.
For pods, different containers use infra containers to uniformly identify external network spaces, and by mounting the same volume, storage can naturally be shared, for example, it corresponds to a directory on the host.
4. Container Orchestration
Container orchestration is the specialty of kubernetes, so it is necessary 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, and job/cronjob for orchestrating offline services.
Taking the most widely used deployment as an example, the relationship between deployment, replicateset, and pod is a layer-by-layer control relationship. Simply put, replicaset controls the number of pods, and deployment controls the version attribute of the replicaset. This design pattern also provides the basis for the two most basic orchestration actions, namely horizontal expansion and contraction controlled by quantity, and update/rollback controlled by version attributes.
5. 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 replicaset, for example, from 2 to 3. Then the horizontal expansion is completed, and vice versa is horizontal shrinkage.
6. Update/rollback
Update/rollback reflects the necessity of the replicaset object. For example, if the version of three instances needs to be changed from v1 to v2, then the number of pod copies controlled by the v1 version replicaset will gradually change from 3 to 0, while the v2 version replicaset The number of controlled pods will change from 0 to 3, and the update will be completed when only the v2 version of the replicaset exists under the deployment. The action of rolling back is the opposite.
7. Rolling update
It can be found that in the above example, when updating the application, pods are always upgraded one by one, and a minimum of 2 pods are available and a maximum of 4 pods provide services. The benefit of this "rolling update" is obvious. Once the new version has bugs, the remaining two pods can still provide services and facilitate quick rollback.
In actual applications, the rolling update strategy can be controlled by configuring RollingUpdateStrategy. maxSurge indicates how many new Pods the deployment controller can create; and maxUnavailable refers to how many old Pods the deployment controller can delete.
8. Network in kubernetes
Now that we understand how container orchestration is accomplished, how do containers communicate? When it comes to network communication, kubernetes must first have a "three links" foundation:
Communication between node and pod is possible;
The pods of node can communicate with each other;
Pods between different nodes can communicate.
To put it simply, communication between different pods is achieved through the cni0/docker0 bridge, and node access to pods also communicates through the cni0/docker0 bridge.
There are many implementation solutions for pod communication between different nodes, including the more common flannel vxlan/hostgw mode. 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.
9. Microservice service
Before understanding the next content, you must first understand a very important resource object: service. Why is service needed? In microservices, pod can correspond to an instance, and service corresponds to a microservice. In the service calling process, the emergence of service solves two problems:
The IP of the pod is not fixed, and it is unrealistic to use non-fixed IP to make network calls;
Service calls require load balancing across different pods.
The service selects the appropriate pod through the label selector and builds an endpoint, that is, a pod load balancing list. In actual application, pod instances of the same microservice are generally labeled with a label similar to app=xxx, and a service with the label selector app=xxx is created for the microservice.
10. Service discovery and network calls in kubernetes
After having the above-mentioned "three links" network foundation, we can start how the network calls in the microservice architecture are implemented in kubernetes.
① Call between services
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 the service through iptables/ipvs. You only need to access the VIP to access the pods behind the service in a load-balanced manner.
The following is an implementation method of clusterIp, which also includes userSpace proxy mode (basically not used), and ipvs mode (better performance):
The dns mode is easy to understand. For the clusterIp mode service, it has an A record which is service-name.namespace-name.svc.cluster.local, pointing to the clusterIp address. Therefore, during general use, just call service-name directly.
② Access outside the service
North-south traffic, that is, external requests to access the kubernetes cluster, mainly includes three methods: nodePort, loadbalancer, and ingress.
nodePort is also a type of service. Through iptables, it is given the ability to access the underlying service by calling a specific port on the host.
Loadbalancer is another service type, implemented through the load balancer provided by the public cloud.
Accessing 100 services may require the creation of 100 nodePort/loadbalancers, so it is hoped to access the internal kubernetes cluster through a unified external access layer. This is the function of ingress. Ingress provides a unified access layer that matches different backend services through different routing rules. Ingress can be seen as "service of services". Ingress is often implemented in combination with nodePort and loadbalancer to complete its functions.
