[Cloud Native] k8s Service realizes service discovery and load balancing

foreword

In a container orchestration system, such as Kubernetes, a Pod is the smallest unit of deployment. A group of Pods usually provide some kind of service to the outside world. In Kubernetes, Service is a resource object used to expose a set of Pod services. Service can be accessed through IP address and port number to provide external services.

Service Introduction

Service is a very important concept in Kubernetes, which can encapsulate a set of Pods into a logical service unit.

Service can bind a group of Pods together through the defined Label Selector to form a Service. Through the Service, users can easily access the service without worrying about the specific IP address and port number of the Pod, and do not need to worry that the change in the number of Pods will affect the access to the service.

Four types of Service and how to use them

There are four types of Service in Kubernetes, namely ClusterIP, NodePort, LoadBalancer and ExternalName.

• ClusterIP: is the default type of Service, it will create a Cluster IP for Service, this IP can only be accessed within the cluster. Through ClusterIP, users can access the Pod associated with the Service.
• NodePort: Bind a port on each node to expose the Service to the outside of the cluster. Users can access the Service through the IP address of any node and the port number.
• LoadBalancer: Create a VIP on the load balancer provided by the cloud vendor to expose the Service to the outside of the cluster. Users can access the Service through this VIP address.
• ExternalName: The Service can be mapped to a DNS name outside the cluster, thereby exposing the Service to the outside of the cluster.

In addition, existing services can also be added to the Kubernetes cluster in the form of Service. You only need to not specify a Label selector when creating a Service, but manually add an endpoint to it after the Service is created.

Definition and use of Service

Service can also be defined through yaml.

The following is a YAML file with selector and type that defines a Service named nginx, and forwards port 80 of the service to port 80 of the Pod with the label run=nginx in the default namespace:

apiVersion: v1
kind: Service
metadata:
  name: nginx
spec:
  selector:
    run: nginx
  type: ClusterIP
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80

Among them, type is the type of Service, which can be ClusterIP, NodePort, LoadBalancer and ExternalName.

The type in this example is ClusterIP, which means the type of the Service is ClusterIP.

The following are the operation steps and expected display content of creating and viewing the created service through commands.

Create a service with the command

1. Use kubectl createthe command to create a nginxservice named , and forward port 80 of the service to port 80 of the Pod with run=nginxlabel . Run the following command:

kubectl create service clusterip nginx --tcp=80:80 --dry-run=client -o yaml > nginx-service.yaml

This command will generate a YAML file nginx-service.yamlnamed , which contains the configuration information needed to create a Service.

Expected display content:

service/nginx created (dry run)

2. Use the kubectl apply command to create a Service. Run the following command:

kubectl apply -f nginx-service.yaml

This command will create a Service named nginx according to the configuration information in the YAML file.

Expected display content:

service/nginx created

View created services

1. Use the kubectl get command to view the created Service. Run the following command:

kubectl get services

This command will display all created Services, including their name, type, Cluster IP, port and other information.
Expected display content:

NAME         TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)    AGE
kubernetes   ClusterIP   10.96.0.1      <none>        443/TCP    4h19m
nginx        ClusterIP   10.96.58.173   <none>        80/TCP     1m

2. Use the kubectl describe command to view the details of the specified Service. Run the following command:

kubectl describe service nginx

This command will display the detailed information of the Service named nginx, including its type, Cluster IP, port, Selector and other information.

Expected display content:

Name:              nginx
Namespace:         default
Labels:            run=nginx
Annotations:       <none>
Selector:          run=nginx
Type:              ClusterIP
IP:                10.96.58.173
Port:              <unset>  80/TCP
TargetPort:        80/TCP
Endpoints:         10.244.0.7:80
Session Affinity:  None
Events:            <none>

Services without Selectors specified

When a user creates a Service, the Label Selector may not be specified, and this kind of Service is called a no selector service (no selector service). A selectorless service cannot be bound to a Pod, but only provides a fixed IP and port for accessing backend services. This kind of service is usually used to proxy to external services, such as databases, message queues, etc.

Headless service

There is also a special type of Service in Kubernetes called Headless service. The ClusterIP of the headless service is None, it will not create a Cluster IP for the Service. Through the Headless service, users can directly access the Pod associated with the Service without accessing through the Service.

Service working principle and schematic diagram

The working principle of Service is realized through the proxy mode, that is, kube-proxy is responsible for balancing the service load to the backend Pod.
When a user accesses the Service through the IP and port of the Service, the request will first reach the Service proxy, and then the proxy forwards the request to the backend Pod.
When the Pod changes, the Service will automatically update the Endpoint to ensure that the request can reach the backend Pod correctly.
Here is a schematic diagram of how a Service works:

Ingress explanation

Ingress is another important resource object in Kubernetes, which is used to route HTTP(S) traffic outside the cluster to Service inside the cluster. Through Ingress, users can define a domain name outside the cluster, and then route the domain name to the Service. Ingress can implement grayscale publishing, load balancing, SSL termination and other functions.

How to access services outside the cluster

When the user needs to access the Service in Kubernetes from outside the cluster, it can be achieved through NodePort, LoadBalancer or Ingress. The specific method is as follows:

• NodePort

Users can access the Service through the IP address of any node and the port number bound to the node. For example, if the port of NodePort is 30080 and the node IP address is 192.168.0.10, users can access the Service through http://192.168.0.10:30080.

• LoadBalancer

When the type of Service is LoadBalancer, the cloud vendor will create a VIP for the Service on the load balancer it provides, and users can access the Service through this VIP address.

• Ingress

Through Ingress, users can define a domain name outside the cluster and route the domain name to the Service. Users can access the Service through this domain name.

Summarize

The above is an introduction to Service in Kubernetes, including the introduction and definition of Service, the working principle of four types of Service, the explanation of Ingress, and how to access services outside the cluster.

When using the Service, users do not need to care about the specific IP address and port number of the Pod, nor do they need to worry that the change in the number of Pods will affect the access to the service.

Through Ingress, users can define a domain name outside the cluster, and then route the domain name to the Service, so as to realize gray scale publishing, load balancing, SSL termination and other functions.