Shulou(Shulou.com)06/02 Report--

This article mainly introduces "how to use Kubernetes". In daily operation, I believe many people have doubts about how to use Kubernetes. The editor consulted all kinds of materials and sorted out simple and easy-to-use operation methods. I hope it will be helpful for you to answer the doubts about "how to use Kubernetes"! Next, please follow the editor to study!

Kubernetes architecture

From a macro point of view, the overall architecture of Kubernetes, including Master, Node and Etcd.

Master, the master node, is responsible for controlling the entire Kubernetes cluster. It includes API Server, Scheduler, Controller, and other components, all of which need to interact with Etcd to store data:

API Server: mainly provides a unified entrance to the operation of resources, thus blocking direct interaction with Etcd. Features include security, registration and discovery.

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 the working node, which provides computing power for the entire cluster. It is where the container really runs, including running container, kubelet, and kube-proxy:

Kubelet: the main work includes managing the life cycle of the container, monitoring with cAdvisor, health check, and reporting node status on a regular basis.

Kube-proxy: service is mainly used to provide service discovery and load balancer within the cluster, while listening for service/endpoints changes and refreshing load balancer.

Start by creating a Deployment

Deployment is a controller resource for orchestrating Pod, which we will introduce later. Taking Deployment as an example, let's take a look at what the components in the architecture do during the creation of Deployment resources.

The steps are as follows:

First, kubectl initiates a request to create a deployment.

Apiserver receives a request to create a deployment, and after writing related resources to the etcd;, all components interact with apiserver/etcd similarly.

Change deployment controller list/watch resources and initiate a request to create replicaSet

Changes in replicaSet controller list/watch resources and initiates a request to create pod.

Scheduler detects unbound pod resources and selects the appropriate node for binding through a series of matches and filtering.

Kubelet finds that he needs to create a new pod on his node, which is responsible for the creation of pod and subsequent lifecycle management.

Kube-proxy is responsible for initializing service-related resources, including network rules such as service discovery and load balancing.

So far, through the division of labor and coordination of the components of Kubenetes, the whole process from the creation of a Deployment request to the normal operation of each Pod 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 need to consider is why we need Pod?Pod, which can be said to be a container design pattern for "super-intimate" containers. We can imagine Servelet containers deploying War packages, log collection, and so on.

These containers often need to share networks, shared storage, and shared configurations, so we have the concept of Pod.

For Pod, different Container uniformly identify the external network space through Infra Container, and you can naturally share storage by mounting the same Volume, for example, it corresponds to a directory on the host.

Container arrangement

Container choreography is the key skill of Kubernetes, so we need to know about it.

There are many control resources related to orchestration in Kubernetes, such as Deployment for stateless applications, Statefulset for stateful applications, Daemonset for daemons and job/cronjob for offline services, etc.

Let's take the most widely used Deployment as an example. The relationship among Deployment, Replicatset and Pod is a relationship of layer by layer control.

Simply put, Replicaset controls the number of Pod, while Deployment controls the version property of Replicaset.

This design pattern also provides the basis for the two most basic choreography actions, namely, the horizontal expansion and reduction of quantity control and the update / rollback of version attribute control.

Horizontal expansion and reduction

Horizontal capacity expansion 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 capacity expansion is completed, and vice versa.

Update / rollback

The update / rollback reflects the necessity of the existence of the Replicaset object. For example, we need to change the version of 3 instances from v1 to v2.

Then the number of Pod copies controlled by v1 version Replicaset will gradually change from 3 to 0, while the number of Pod controlled by v2 version Replicaset will change from 0 to 3. When only v2 version of Replicaset exists under Deployment, the update will be completed. The action of rollback is the opposite.

Scrolling update

You can find that in the above example, when we update the application, Pod is always upgraded one by one, and at least 2 Pod are available and up to 4 Pod provide services.

The benefits of this "rolling update" are obvious. Once the new version has Bug, the remaining two Pod can still provide services and facilitate quick rollback.

In practical application, we can control the rolling update policy by configuring RollingUpdateStrategy.

MaxSurge indicates how many new Pod; the Deployment controller can create, while maxUnavailable refers to how many old Pod can be deleted by the Deployment controller.

Network in Kubernetes

We understand how container choreography is done, so how do containers communicate with each other?

When it comes to network communication, Kubernetes must first have the basis of "three links":

You can communicate between Node and Pod

You can communicate between Pod of Node.

Pod between different Node can communicate.

To put it simply, different Pod communicate with each other through cni0/docker0 bridge, and Node accesses Pod through cni0/docker0 bridge.

There are many ways to realize the Pod communication between different Node, including the vxlan/hostgw mode of Flannel, which is popular now.

Flannel learns the network information of other Node through Etcd, and creates a routing table for this Node, which ultimately enables cross-host communication between different Node.

Microservice-Service

Before we can understand the next content, we need to understand a very important resource object: Service.

Why do we need Service? In a microservice, Pod can correspond to an instance, so Service corresponds to a microservice.

In the process of service invocation, the emergence of service solves two problems:

The IP of Pod is not fixed, and it is not realistic to use non-fixed IP to make network calls.

Service invocation requires load balancing among different Pod

Service selects the appropriate Pod through the Label selector to build an Endpoints, that is, the Pod load balancer list.

In practice, we usually label the Pod instances of the same micro-service as app=xxx, and create a Service with a tag selector of app=xxx for the micro-service.

Service Discovery and Network invocation in Kubernetes

With the network foundation of the "three links" mentioned above, we can start how the network invocation in the micro-service architecture is implemented in Kubernetes.

This part of the content of its really talk about how Kubernetes is to achieve service discovery has been relatively clear, more details of the place can refer to the above article, here to do a simple introduction.

Inter-service call

The first is east-west traffic calls, that is, inter-service calls. This part mainly includes two kinds of calling methods, namely, ClusterIp mode and DNS mode.

ClusterIp is a type of Service in which kube-proxy implements a form of VIP (virtual IP) for Service through iptables/ipvs. You only need to access the VIP to access the Pod behind the Service in a load balanced manner.

The figure above is an implementation of ClusterIp, in addition to the userSpace proxy pattern (rarely used) and the ipvs pattern (better performance).

The DNS pattern is easy to understand, and for Service in ClusterIp mode, it has an A record called service-name.namespace-name.svc.cluster.local, which points to the ClusterIp address. Therefore, in the process of general use, we can call service-name directly.

Out of service access

The north-south traffic, that is, external requests to access the Kubernetes cluster, mainly includes three ways:

NodePort

Loadbalancer

Ingress

NodePort is also a type of Service, which gives you the ability to call a specific Port on the host to access the back Service through IPtables.

Loadbalancer is another type of Service, implemented through the load balancer provided by the public cloud.

We may need to create 100 nodePort/Loadbalancer to access 100 services. We want to access the internal Kubernetes cluster through a unified external access layer, which is the function of Ingress.

Ingress provides a unified access layer that matches to different Service at the back end through different routing rules.

Ingress can be thought of as "Service's Service". In implementation, Ingress often combines nodePort and Loadbalancer to complete the function.

At this point, the study on "how to use Kubernetes" is over. I hope to be able to solve your doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.