The context in which Service appears

  1. The POD is transient and can be turned on or off at any time.
  2. Kubernetes assigns IP addresses to pods that have been scheduled to nodes before pod startup. The client cannot know the IP address of the pod that provides the service in advance.
  3. Each POD has its own IP address and cannot handle multiple pods providing the same service.

The Kubernetes service is a resource that provides a single, unchanging access point for a set of pods that have the same functionality. When a service exists, its IP address and port do not change.

The label selector determines which pods belong to the service, and the connection of the service is load-balanced for the back-end pod.

1. Basic use

1) Create a service from a YAML file

ApiVersion: v1 kind: Service metadata: name: my-service spec: ports: -port: available Service port targetPort: selector: App: [Label value]Copy the code

kubectl create -f my-service.yaml

A service called my-service is created that will receive the request on port 80 and route the connection to port 8080 of the pod with a label selector of app=MyApp.

2) View the list of services

kubectl get svc

3) Configure session affinity for the service

SessiongAffinity: controls the service load balancing mode. The value can be:

  • None, random scheduling, default
  • ClientIP, where all requests made by a particular client point to the same POD each time

Modify the YAML file of the Service to configure session affinity for the Service

ApiVersion: v1 kind: Service Service: spec.sessionAffinity: ClientIP......Copy the code

4) Multi-port Service

The same service exposes multiple ports. When multiple ports are used, all port names must be provided to make them unambiguous, for example:

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app: MyApp
  ports:
    - name: http
      protocol: TCP
      port: 80
      targetPort: 9376
    - name: https
      protocol: TCP
      port: 443
      targetPort: 9377
Copy the code

Note: The port name can contain only lowercase letters, digits, and hyphens, and must start and end with a letter or digit.

2. Three proxy modes of Service

In a Kubernetes cluster, each Node runs a Kube-Proxy process. Kube-proxy is responsible for implementing a VIP form for the Service.

1) UserSpace agent mode

Implementation: Kube-Proxy monitors the addition and removal of Service and Endpoints objects by the Kubernetes control plane. For each service, it opens a random port on the local Node. Any request to connect to a “proxy port” is proxyed to one of the Service’s back-end Pods.

Kube-proxy determines which back-end Pod to access based on SessionAffinity. By default, Kube-proxy selects the back end through a rotation algorithm. When the first Pod selected does not respond, Kube-Proxy will detect that the connection to the Pod has failed and automatically retry with another Pod.

2) Iptables proxy mode

Implementation: Kube-proxy monitors the addition and removal of Service objects and Endpoints objects by The Kubernetes control node. Configure the Iptables rules for each Service to capture requests arriving at the clusterIP and port of that Service, and today redirect the requests to a Pod on a set of back ends of the Service.

By default, Kube-proxy randomly selects a back end, and the connection fails when the first Pod selected does not respond. To avoid sending traffic to a Pod that has failed, you can verify that the Pod is working using a Pod readiness probe so that kube-Proxy only sees pods that are tested properly.

3) IPVS proxy mode

Implementation: Kube-Proxy monitors Kubernetes services and endpoints, invokes the NetLink interface to create appropriate IPVS rules, and periodically synchronizes IPVS rules with Kubernetes services and endpoints.

Compared with kube-proxy in iptables mode, kube-Proxy in IPVS mode has a shorter redirection delay and better performance in synchronizing proxy rules. IPVS mode supports higher network traffic throughput than other proxy modes.

Note: in order to ensure that every time transfer from a specific client connect to the same Pod, can through to service. Spec. SessionAffinity set to “ClientIP” (the default “None”)

3. Four types of Service

Kubernetes ServiceTypes Specifies the Service type. Different types of services are exposed to the outside of the Kubernetes cluster in different ways.

1) ClusterIP

The service is exposed by the internal IP of the cluster. If you select this value, the service can only be accessed within the cluster. The default value is the default value.

2) NodePort

The service is exposed by IP and static port (NodePort) on each node.

3) the LoadBalancer

Expose services externally using the cloud provider’s load balancer. External load balancers can route traffic to the automatically created NodePort service and ClusterIP service.

4) ExternalName

By returning CNAME and the corresponding value, the service can be mapped to the contents of the externalName field without creating any proxies.

Reference: kubernetes. IO/useful/docs/con…