Some scattered features of k8s service

Posted on Views: Waline: Word count in article: 460 Reading time ≈ 2 mins.
This article introduces the load distribution strategies of Service, including round - robin and session affinity. It also mentions the usage and configuration of exposing the same port through different protocols. Finally, it explains the load distribution characteristics of Headless Service, which is suitable for Kubernetes users as a reference.

Load Distribution Strategies of Service

As we all know, a service can correspond to multiple pods. So, there must be some methods to forward the requests (loads) received by the service to the pods.

Generally, there are two strategies. One is round - robin, and the other is session affinity.

The round - robin strategy is quite simple, so I won’t elaborate much. This is also the default strategy of the service. When no relevant configuration is done, the round - robin strategy is used.

Here, let’s talk about the session affinity strategy. First, a specific example is given below, and then it will be explained.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  sessionAffinity: ClientIP
  sessionAffinityConfig:
    ClientIP:
      timeoutSeconds: 10800
  selector:
    app.kubernetes.io/name: MyApp
  ports:
    - protocol: TCP
      port: 80
      targetPort: 9376

The main parameters are sessionAffinity and sessionAffinityConfig.
Configuring sessionAffinity as ClientIP means that requests from the same IP are distributed to the same pod according to the source IP of the request.
sessionAffinityConfig.ClientIP.timeoutSeconds represents the timeout period, with a default value of 10800.

To be honest, many current applications are authenticated based on JWT (JSON Web Token), and there aren’t many applications based on session, especially in new projects. JWT doesn’t require session affinity, but this strategy is still very important for those applications that are authenticated based on session.

Exposing the Same Port through Different Protocols

Recently, I discovered a new usage for the first time, which is to expose the same port with different protocols. For example, port 53 is exposed through both TCP and UDP. Here is the specific YAML configuration.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
apiVersion: v1 
kind: Service 
metadata: 
  name: kube-dns 
  namespace: kube-system 
  labels: 
    k8s-app: kube-dns 
    kubernetes.io/cluster-service: "true" 
    kubernetes.io/name: "KubeDNS" 
  spec: 
    selector: 
      k8s-app: kube-dns 
      clusterIP: 169.169.0.100 
      ports: 
      - name: dns 
        port: 53
        protocol: UDP 
      - name: dns-tcp 
        port: 53 
        protocol: TCP

To be honest, this usage is quite rare. I’ve been using k8s since 2019 and have never seen this usage in projects. However, existence has its reason. I’ll make a note of it to deepen my impression.

Load Distribution Strategy of Headless Service

Intuitively, the biggest difference between a headless service and a regular service is that a headless service doesn’t have a ClusterIP. This is correct, but more precisely, the difference between a headless service and a regular service is that it doesn’t provide load - balancing functionality.

As mentioned before, a service has two load - balancing strategies: round - robin and session affinity. The characteristic of a headless service is that when there is a client request, it returns all the matching pods to the client through the label selector, and the client decides which pod to access.

StatefulSet returns multiple available addresses to the client through a headless service.