Introduction to the use of Kubernetes service discovery

1. Basic introduction

Pods in Kubernetes have a life cycle, and each Pod has its own IP address. But when we create and delete Pods, its IP address is not fixed. That is to say, when we provide the IP of the Pod to the front-end application, the probability of the service being unavailable is quite large. Official description

However, Kubernetes defines a Service resource, and each Service has a fixed VIP address. We can automatically bind the Service to the appropriate Pod application by tag matching , and when we request the Service, it will also forward the request to the backend Pod application.

1. The Kube-Proxy component runs on each nodehost and monitors the Service and Endpoints services in real time through APIServer.
2. When a user creates a Service with a label selector, Endpoints are also created to store the IP address that matches the Pod from the Service.
3. After Kube-Proxy monitors changes to Service and Endpoints, it iptableswill ipvsconfigure rules for or (to implement layer-4-based routing and forwarding)
4. Finally, the user realizes the mapping access of the service through the route forwarding provided by Kube-Proxy.

---

The above is actually for Pod applications. Another situation is that Pods want to access external applications, such as: there is now a RabbitMQ cluster consisting of three hosts. At this point, it is possible for the Pod to access the RabbitMQ service of any of the hosts, but there is no redundancy in this case.

So we can create without configuring the tag selector for it. In this case, Endpoints will not be created automatically. Next, we can customize to create Endpoints, here we only need to configure the Endpoints name and Service name to be the same.

The relationship between Service, Endpoints and Pod:

2. Introduction to the use of Kubernetes service discovery

[root@k8s-master01 ~]# vim nginx-web.yaml
apiVersion: v1
kind: Pod
metadata:
  name: nginx-web
  labels:
    app: nginx
spec:
  containers:
  - name: nginx-web
    image: nginx:1.18.0
    imagePullPolicy: IfNotPresent
    ports:
    - containerPort: 80
    volumeMounts:
    - mountPath: /usr/share/nginx/html
      name: index
  volumes:
  - hostPath:
      path: /app/nginx/html
    name: index
[root@k8s-master01 ~]# mkdir -p /app/nginx/html && echo "This is Nginx:80" > /app/nginx/html/index.html
[root@k8s-master01 ~]# kubectl create -f nginx-web.yaml

1.ClusterIP

By using the IP address defined inside K8s, the service access inside the cluster is realized (because it is defined internally, it cannot be directly accessed outside)

[root@k8s-master01 ~]# vim nginx-web-svc.yaml
apiVersion: v1
kind: Service
metadata:
  name: nginx-web
spec:
  type: ClusterIP							# Service 的默认类型
  ports:
  - name: nginx-web
    port: 8080								# Service 的显示端口
    targetPort: 80							# Pod 的服务端口
  selector:
    app: nginx
[root@k8s-master01 ~]# kubectl create -f nginx-web-svc.yaml

verify:

2.Headless Service

Headless services are mainly suitable for services that do not require ClusterIP. By configuring the label selector, CoreDNS can resolve the name of the Service to the Pod application.

[root@k8s-master01 ~]# vim nginx-web-svc.yaml
apiVersion: v1
kind: Service
metadata:
  name: nginx-web
spec:
  ports:
  - name: nginx-web
    port: 8080
    targetPort: 80
  clusterIP: "None"
  selector:
    app: nginx
[root@k8s-master01 ~]# kubectl create -f nginx-web-svc.yaml

---

Because the CoreDNS component is mainly used to provide the Service with a corresponding resolution relationship between the domain name and IP, but the headless service we configure here means that the Service does not provide the ClusterIP address. So when we parse below, we parse directly to the Pod application matched by the Service.

What needs to be understood is that when we configure a headless service, Kube-Proxy does not add this headless service to the iptablesor ipvsrule. However, we can access it as a domain name inside the container. As shown in the figure above, we use the nccommand to judge that nginx-webthe connectivity between the container and the domain name is normal.

3.NodePort

By mapping a port on all nodehosts , you can then route to the Service through the IP address and mapped portnode of any host .

[root@k8s-master01 ~]# vim nginx-web-svc.yaml
apiVersion: v1
kind: Service
metadata:
  name: nginx-web
spec:
  type: nodePort
  ports:
  - name: nginx-web
    port: 8080
    targetPort: 80
    nodePort: 30080
  selector:
    app: nginx
[root@k8s-master01 ~]# kubectl create -f nginx-web-svc.yaml

In addition to the above types, Service can also use LoadBalancer and ExternalName types.

• LoadBalancer: On the basis of NodePort, an external load balancer is created with the help of Cloud Provider (cloud vendor), and requests are forwarded to NodePort.
• ExternalName: used to introduce services outside the cluster into the cluster, so that it can be used directly inside the cluster (implemented through CoreDNS)

[root@k8s-master01 ~]# vim nginx-web-svc.yaml
apiVersion: v1
kind: Service
metadata:
  name: nginx-web
spec:
  type: ExternalName
  ports:
  - name: nginx-web
    port: 80
    targetPort: 80
    externalName: www.baidu.com
[root@k8s-master01 ~]# kubectl create -f nginx-web-svc.yaml