当前位置：网站首页>Yyds dry inventory kubernetes easy service discovery and load balancing (11)

Yyds dry inventory kubernetes easy service discovery and load balancing (11)

2022-06-26 07:31:00 【wzlinux】

After the previous chapters , We can already publish highly available services , adopt PV Persist data , adopt Deployment or Statefulset This type of workload to manage multiple instances , In order to ensure the high availability of services .

Think about it , At this time, if other applications access our services , What to do ？ Direct access to the back end Pod IP Do you ？ No , Here we also need to do service discovery （Service Discovery）.

Why service discovery is needed ？

Traditional application deployment , The network location of the service instance is fixed , That is, deploy on a given machine , At this time, the service address is usually the address of the machine IP Add a specific port number .

But in Kubernetes in , It's totally different . Business is through Pod To carry , Every Pod Its life cycle is very short , Burn immediately after use ,IP Addresses are also randomly assigned , Dynamic . and , We also often encounter some highly concurrent traffic , At this time, it is often necessary to expand the capacity quickly , The number of instances of the service will also be dynamically adjusted . So we can't use the traditional method based on IP To access a service . For all systems on the cloud , And micro service application system , Is a big problem . At this time, we need to do service discovery to determine the access address of the service .

Today we are going to talk about it Kubernetes Service discovery in —— Service.

Kubernetes Medium Service

In the previous course , We know Deployment、StatefulSet This kind of workload is through labelSelector To manage a group of Pod Of . that Kubernetes Medium Service The same approach has been adopted , Here's the picture .

#yyds Dry inventory # Kubernetes Easy service discovery and load balancing (11)_nginx

Such a Service All of the cluster will be selected label With medium app=nginx and env=prod Of Pod.

Let's take a look at such a Service How is it defined ：

$ cat nginx-svc.yaml
apiVersion: v1
kind: Service
metadata:  
  name: nginx-prod-svc-demo
  namespace: demo # service  yes  namespace  Level object 
spec:
  selector:       # Pod Selectors 
    app: nginx
    env: prod
  type: ClusterIP # service  The type of 
  ports:  
  - name: http 
    port: 80       # service  Port number 
    targetPort: 80 #  Corresponding to  Pod  Port number on 
    protocol: TCP  #  And support  udp,http  etc. 

     
      1.
      2.
      3.
      4.
      5.
      6.
      7.
      8.
      9.
      10.
      11.
      12.
      13.
      14.
      15.
      16.

Now let's take a look at the following Deployment The definition of ：

$ cat nginx-deploy.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-prod-deploy
  namespace: demo
  labels:
    app: nginx
    env: prod
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
      env: prod
  template:
    metadata:
      labels:
        app: nginx
        env: prod
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

     
      1.
      2.
      3.
      4.
      5.
      6.
      7.
      8.
      9.
      10.
      11.
      12.
      13.
      14.
      15.
      16.
      17.
      18.
      19.
      20.
      21.
      22.
      23.
      24.
      25.
      26.

We created this Deployment after , Look at the Pod state ：

$ kubectl get deploy -n demo
NAME                READY   UP-TO-DATE   AVAILABLE   AGE
nginx-prod-deploy   3/3     3            3           5s
$ kubectl get pod -n demo -o wide
NAME                                 READY   STATUS    RESTARTS   AGE   IP          NODE             NOMINATED NODE   READINESS GATES
nginx-prod-deploy-6fb6fbb77d-h2gn4   1/1     Running   0          87s   10.1.0.31   docker-desktop   <none>           <none>
nginx-prod-deploy-6fb6fbb77d-r78k9   1/1     Running   0          87s   10.1.0.29   docker-desktop   <none>           <none>
nginx-prod-deploy-6fb6fbb77d-xm8tp   1/1     Running   0          87s   10.1.0.30   docker-desktop   <none>           <none>

     1.
2.
3.
4.
5.
6.
7.
8.

Let's create the one defined above Service：

$ kubectl create -f nginx-svc.yaml
service/nginx-prod-svc-demo created
$ kubectl get svc -n demo
NAME                  TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)   AGE
nginx-prod-svc-demo   ClusterIP   10.111.193.186   <none>        80/TCP    6s

     1.
2.
3.
4.
5.

You can see , This Service Assigned to an address of 10.111.193.186 Of Cluster IP, It's a virtual IP（VIP） Address , All of the Pod and Node Through this virtual IP Address plus port to access the Service. This Service According to the label selector , Match it to Pod Of IP The addresses are all attached to the back end . We use kubectl describe Take a look at this Service：

$ kubectl describe svc -n demo nginx-prod-svc-demo
Name:              nginx-prod-svc-demo
Namespace:         demo
Labels:            <none>
Annotations:       <none>
Selector:          app=nginx,env=prod
Type:              ClusterIP
IP:                10.111.193.186
Port:              http  80/TCP
TargetPort:        80/TCP
Endpoints:         10.1.0.29:80,10.1.0.30:80,10.1.0.31:80
Session Affinity:  None
Events:            <none>

     1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.

You can see , Now Service The associated Endpoints There are three of them IP Address , And what we saw above Pod IP The address matches perfectly .

We try to shrink the volume Deployment Number of copies , Look again. Service The associated Pod IP What's the change in the address ：

$ kubectl scale --replicas=2 deploy -n demo nginx-prod-deploy
deployment.apps/nginx-prod-deploy scaled
$ kubectl get pod -n demo -o wide
NAME                                 READY   STATUS    RESTARTS   AGE   IP          NODE             NOMINATED NODE   READINESS GATES
nginx-prod-deploy-6fb6fbb77d-r78k9   1/1     Running   0          11m   10.1.0.29   docker-desktop   <none>           <none>
nginx-prod-deploy-6fb6fbb77d-xm8tp   1/1     Running   0          11m   10.1.0.30   docker-desktop   <none>           <none>
$ kubectl describe svc -n demo nginx-prod-svc-demo
Name:              nginx-prod-svc-demo
Namespace:         demo
Labels:            <none>
Annotations:       <none>
Selector:          app=nginx,env=prod
Type:              ClusterIP
IP:                10.111.193.186
Port:              http  80/TCP
TargetPort:        80/TCP
Endpoints:         10.1.0.29:80,10.1.0.30:80
Session Affinity:  None
Events:            <none>

     1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.

Visible when Pod When the life cycle of , Such as volume shrinking or abnormal exit ,Service Will automatically put the problem Pod Remove from the back-end address . The advantage of this is , We can always pass a virtual stability IP Address to access the service , Don't worry about the change of the real instance of its back end .

Service The type of

Kubernetes in Service There are four types , Except for the above ClusterIP, also NodePort、LoadBalancer and ExternalName.

among LoadBalancer Used more on the cloud , It needs to be adapted to various cloud manufacturers when using , For example, deploy the corresponding cloud-controller-manager. If you are interested , You can see This document , See how to use on the cloud .LoadBalancer It is mainly used for external service discovery , That is, access exposed to the outside of the cluster .

ExternalName Type of Service The frequency used in practice is not particularly high , But there are some uses for some special scenes . For example, an application service is already running on the cloud or inside , But it doesn't run in Kubernetes in , If you want me to Kubernetes In the cluster Pod Access the service , At this time, of course, you can directly use its domain name address , It can also be done through ExternalName Type of Service To solve . In this way, you can have direct access to Kubernetes Inside Service 了 .

This facilitates the migration of subsequent services to Kubernetes in , Second, it is also convenient to switch to the backup service at any time , Without changing Pod Any configuration in . Because the frequency of use is not high , We won't focus on , If you are interested, please refer to this article file .

Let's finally look at another kind of NodePort Type of Service：

apiVersion: v1
kind: Service
metadata:  
  name: my-nodeport-service
  namespace: demo
spec:
  selector:    
    app: my-app
  type: NodePort #  Here, set the type to  NodePort
  ports:  
  - name: http
    port: 80
    targetPort: 80
    nodePort: 30000
    protocol: TCP

     
      1.
      2.
      3.
      4.
      5.
      6.
      7.
      8.
      9.
      10.
      11.
      12.
      13.
      14.
      15.

seeing the name of a thing one thinks of its function , This type of Service Through any Node Node IP Address , Add the port number to access Service The back end is loaded . Let's look at the flow chart below , Easy to understand .

#yyds Dry inventory # Kubernetes Easy service discovery and load balancing (11)_ Port number _02

NodePort Type of Service When it's created ,Kubernetes Will be in every Node Open a port on the node , Like here 30000 port . At this time, we can visit any Node Of IP Address , adopt 30000 Port to access the service .

So if you are inside the cluster , How to access these Service Well ？

How to access in the cluster Service？

Generally speaking , stay Kubernetes Within cluster , We have two ways to access a Service.

If it's time to Service Yes ClusterIP, We can directly use this virtual IP To visit . Like the one we created above nginx-prod-svc-demo This Service, We go through kubectl get svc nginx-prod-svc-demo -n dmeo or kubectl get svc nginx-prod-svc-demo -n dmeo You can see it Cluster IP by 10.111.193.186, The port number is 80. So we go through http(s)/10.111.193.186:80 You can access the service .
Of course, we can also use this Service Domain name of , It depends on the DNS Can access . Let's use the above example to illustrate , Same as namespace Under the Pod You can go directly through nginx-prod-svc-demo This Service Name to access . If it's different namespace Under the Pod You need to add this Service Where namespace name , namely nginx-prod-svc-demo.demo To visit .

If in a certain namespace Next ,Service Precede Pod created , that kubelet Creating Pod When , Will automatically put these namespace same Service Access information is injected as environment variables Pod in , namely {SVCNAME}_SERVICE_HOST and {SVCNAME}_SERVICE_PORT. here SVCNAME Corresponding to each Service Capitalized name of , The horizontal lines in the name are automatically converted to underscores . such as ：

# env
KUBERNETES_PORT=tcp://10.96.0.1:443
KUBERNETES_SERVICE_PORT=443
HOSTNAME=nginx-prod-deploy2-68d8fb9586-4m5hr
NGINX_PROD_SVC_DEMO_SERVICE_PORT_HTTP=80
NGINX_PROD_SVC_DEMO_SERVICE_HOST=10.111.193.186
KUBERNETES_PORT_443_TCP_ADDR=10.96.0.1
NGINX_PROD_SVC_DEMO_SERVICE_PORT=80
NGINX_PROD_SVC_DEMO_PORT=tcp://10.111.193.186:80
KUBERNETES_PORT_443_TCP_PORT=443
KUBERNETES_PORT_443_TCP_PROTO=tcp
NGINX_PROD_SVC_DEMO_PORT_80_TCP_ADDR=10.111.193.186
NGINX_PROD_SVC_DEMO_PORT_80_TCP_PORT=80
NGINX_PROD_SVC_DEMO_PORT_80_TCP_PROTO=tcp
KUBERNETES_PORT_443_TCP=tcp://10.96.0.1:443
KUBERNETES_SERVICE_PORT_HTTPS=443
KUBERNETES_SERVICE_HOST=10.96.0.1
NGINX_PROD_SVC_DEMO_PORT_80_TCP=tcp://10.111.193.186:80
...

     1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.

Knowing these two access methods , We can start up Pod When , By injecting environment variables 、 Start parameters or mount configuration files , To specify which Service Information . If it's the same namespace Of Pod, You can know the same from your environment variables namespace Others under Service Access to .

So this way through the Service When doing an interview ,Kubernetes How to achieve load balancing , I.e. the traffic will be sent to the backend mounted Pod The above to ？

How to achieve load balancing within a cluster ？

It's all through kube-proxy To achieve . On all nodes, there will be a kube-proxy Service for , Main monitor Kubernetes Medium Service and Endpoints. When Service or Endpoints When something changes , The corresponding interface will be called to create corresponding rules , The common patterns are iptables Patterns and IPVS Pattern .iptables The model is relatively simple , It's easy to use . and IPVS Support higher throughput and complex load balancing policies , You can go through Official documents Learn more about IPVS How the mode works .

at present kube-proxy The default way of working is iptables Pattern , Let's go through the following iptables Let's take a look at the actual access link as an example .

#yyds Dry inventory # Kubernetes Easy service discovery and load balancing (11)_nginx_03

When you pass Service Domain name to access , Will pass first CoreDNS It is concluded that Service Corresponding Cluster IP, It's virtual IP. After the request reaches the network of the host , Will be kube-proxy The configured iptables Blocked by rules , The request is then forwarded to each actual back end Pod The above to , This enables load balancing .

Headless Service

If we're defining Service When , take spec.clusterIP Set to None, Created at this time Service Will not be assigned to a Cluster IP, At this point it is called Headless Service.

Now let's take a look through an example Headless Service What's special . We're up there Service On the basis of , Added spec.clusterIP by None, And named it nginx-prod-demo-headless-svc：

apiVersion: v1
kind: Service
metadata:  
  name: nginx-prod-demo-headless-svc
  namespace: demo 
spec:
  clusterIP: None
  selector: 
    app: nginx
    env: prod
  type: ClusterIP
  ports:  
  - name: http 
    port: 80 
    targetPort: 80 
    protocol: TCP 

     
      1.
      2.
      3.
      4.
      5.
      6.
      7.
      8.
      9.
      10.
      11.
      12.
      13.
      14.
      15.
      16.

adopt kubectl Once created , We are now kubectl get Let's have a look ：

$ kubectl get svc -n demo
NAME                           TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)   AGE
nginx-prod-demo-headless-svc   ClusterIP   None             <none>        80/TCP    4s
nginx-prod-svc-demo            ClusterIP   10.111.193.186   <none>        80/TCP    3d5h

     1.
2.
3.
4.

You can see this is called nginx-prod-demo-headless-svc Of Service Not assigned to One ClusterIP, In line with expectations , After all, we have set spec.clusterIP by None.

So let's create one Pod, have a look DNS Is there any difference between the records . Pod Of yaml The documents are as follows ：

apiVersion: v1
kind: Pod
metadata:
  name: headless-svc-test-pod
  namespace: demo
spec:
  containers:
  - name: dns-test
    image: busybox:1.28
    command: ['sh', '-c', 'echo The app is running! && sleep 3600']

     
      1.
      2.
      3.
      4.
      5.
      6.
      7.
      8.
      9.
      10.

The Pod When it's created , We go through kubectl exec Get into Pod in , Run the following two nslookup Query command , View the two in turn Service Corresponding DNS Record ：

$ kubectl exec -it -n demo headless-svc-test-pod sh
kubectl exec [POD] [COMMAND] is DEPRECATED and will be removed in a future version. Use kubectl kubectl exec [POD] -- [COMMAND] instead.
/ # nslookup nginx-prod-demo-headless-svc
Server:    10.96.0.10
Address 1: 10.96.0.10 kube-dns.kube-system.svc.cluster.local

Name:      nginx-prod-demo-headless-svc
Address 1: 10.1.0.32 10-1-0-32.nginx-prod-demo-headless-svc.demo.svc.cluster.local
Address 2: 10.1.0.33 10-1-0-33.nginx-prod-demo-headless-svc.demo.svc.cluster.local
/ # nslookup nginx-prod-svc-demo
Server:    10.96.0.10
Address 1: 10.96.0.10 kube-dns.kube-system.svc.cluster.local

Name:      nginx-prod-svc-demo
Address 1: 10.111.193.186 nginx-prod-svc-demo.demo.svc.cluster.local

     1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.

We can see the normal Servicenginx-prod-svc-demo Corresponding DNS The record is related to the virtual IP10.111.193.166 Relevant records , and Headless Service nginx-prod-demo-headless-svc Then it is resolved to all back-end Pod The address of .
Sum up , Headless Service There are mainly two scenarios as follows .

Users can choose which one to connect to Pod, By inquiring Service Of DNS Record to get the real load of the backend IP Address , Choose which to connect IP;
Can be used to deploy stateful Services . In retrospect , We are StatefulSet That class also has Headless Service Example , Every StatefulSet Managed Pod There is a single DNS Record , And the domain name remains unchanged , namely <PodName>.<ServiceName>.<NamespaceName>.svc.cluster.local. such Statefulset The individual Pod You can go through it directly Pod Names solve mutual identity and access problems .

Last

Service yes Kubernetes Very important object , Mainly responsible for exposing services for various workloads , Facilitate mutual visits between various services . Through a group of Pod Provide a unified entrance ,Service It is very convenient for users to use , Users only need to communicate with Service Just deal with it , Instead of paying too much attention to the changes of back-end instances , Such as expansion and contraction 、 Container exception 、 The node is down , wait .

It's because of Service Support for , you are here Kubernetes It will be very convenient to deploy the business , This is compared to Docker Swarm as well as Mesos Marathon Huge technical advantages , so to speak , It is Kubernetes It is the best carrier for running large-scale microservices .