Learn about kubernetes from scratch, who else will not?

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. For more information about Kubernetes, please refer to the old article: Kubernetes Past and Present (with learning map)

This article will take everyone to quickly understand kubernetes and learn kubernetes technology from scratch.

kubernetes architecture

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 relevant resources into etcd; after that, the interactions between all components and apiserver/etcd are 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.

Pod

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-close" 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.

For more details about Kubernetes pod, please refer to the old article: Kubernetes Pod Implementation Principle

Container Orchestration

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, that is, 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

Update/rollback reflects the necessity of replicaset. For example, if we need to change the version of 3 instances from v1 to v2, then the number of pod replicas controlled by the v1 version of the replicaset will gradually change from 3 to 0, and the number of pods controlled by the v2 version of the replicaset will be annotated from 0 to 3. Only the v2 version of the replicaset has been updated. The action of rollback is the opposite.

Rolling update

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 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.

Microservice—service

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 ip of a pod is not fixed. It is unrealistic to use a non-fixed ip to make network calls. Service calls need to be load-balanced for different pods. Service selects the appropriate pod through the label selector to construct an endpoint, that is, a pod load balancing list. In practice, we generally label the pod instances of the same microservice with a label similar to app=xxx, and create a service with a label selector of app=xxx for the microservice.

Service discovery and network call 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.

This part of the content can refer to: Kubernetes service discovery , for more details, you can refer to the above article, here is a brief introduction.

Inter-service call

The first is east-west traffic calls, that is, calls 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 the service in the clusterIp mode, it has an A record of service-name.namespace-name.svc.cluster.local, which points to the clusterIp address. Therefore, in general use, we can directly call service-name.

Out-of-service access

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. So when we hear others discuss kubernetes, we can know what they are discussing.

Author: fredalxin Address: https://fredal.xin/what-is-kubernetes