Service分发负载的策略

大家都知道，一个service可以对应多个pod，那么一定要有一些方法来把service接收到的请求（负载）转发到pod上。
一般来说，有两种策略，一种是轮询，还有一种会话状态保持。

轮询策略很简单，就不多说了，这也是service的默认策略，在不做什么相关配置的情况下就是使用轮询策略的。

这里讲一下会话状态保持策略，下面先给出一个具体的例子，然后再对其作解释

apiVersion: v1
kind: Service
metadata:name: my-service
spec:sessionAffinity: ClientIPsessionAffinityConfig:ClientIP:timeoutSeconds: 10800selector:app.kubernetes.io/name: MyAppports:- protocol: TCPport: 80targetPort: 9376

主要是sessionAffinity和sessionAffinityConfig这两个参数。
sessionAffinity配置为ClientIP表示根据请求的source ip把来自同一个IP的请求分发到同一个pod上。
sessionAffinityConfig.ClientIP.timeoutSeconds表示超时时间，默认是10800。

老实说，现在的应用很多都是基于jwt做认证的，基于session的不是非常多，尤其是新项目中。jwt是不需要做会话状态保持的，但是这个策略对于那些基于session做认证的应用还是很重要的。

---

同一端口通过不同协议暴露

最近第一次发现了一个新的用法，就是同一个端口用不同的协议暴露，比如53端口，同时通过TCP和UDP进行暴露，下面是具体的yaml配置。

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: 53protocol: UDP - name: dns-tcp port: 53 protocol: TCP

老实说，这种用法很少见，我从2019年开始使用k8s，从来没在项目中见过这种使用方法，但是存在既有道理，做个记录吧，也加深自己的印象。

Headless Service的负载分发策略

直观上看，headless service跟普通service最大的区别就是没有ClusterIP。这是对的，但是更正确的说，headless service跟普通service的区别是它不提供负载均衡的功能。

前面说过，service有轮询和会话状态保持两种负载均衡策略。headless service特点是，在有客户端请求的时候，它通过label selector把所有匹配的pod都返回给客户端，让客户端自己决定访问哪一个pod。

StatefulSet就是通过headless service向客户端返回多个可用的地址。