Kubernetes Service负载均衡机制

当一个Service对象在Kubernetes 集群中被定义出来时，集群内的客户端应用就可以通过服务IP访问到具体的Pod 容器提供的服务了。从服务iP到Pod 的负载均衡机制，则是由每个Node上的kube-proxy 负责实现的，本节对kube-proxy 的代理模式，会话保持机制和基于拓扑感知的服务路由机制（EndpointSlices）进行说明。

1. kube-proxy 的代理模式
   目前kube-proxy 提供了以下代理模式（通过启动参数–proxy-mode设置）。
   （1）userspace 模式： 用户空间模式，由kube-proxy 完成代理的实现，效率最低，不再推荐使用。
   （2）iptables模式：kube-proxy 通过设置liunx Kernel 的iptables 规则，实现从Service 到后端Endpoint 列表负载分发规则，效率很高，但是，如果某个后端Endpoint 在转发时不可用，此次客户端请求就会得到失败的响应，相对于userspace 模式来说更不可靠。此时应该通过为Pod设置readinessprobe(服务可用性健康检查)来保证只有达到ready 状态的Endpoint 才会被设置Service 的后端Endpoint。
   （3）ipvs模式：在Kubernetes 1.11 版本中达到Stable 阶段，kube-proxy 通过设置liunx kernel 的netlink 接口设置IPVS 规则模块，转发效率和支持的吞吐率都是最高的，ipvs 模式要求林下kernel 启用IPVS 模块，如果操作系统未启用IPVS 内核模块，kube-proxy 则会自动切换至iptables模式，同时，ipvs 模式支持更多的负载均衡策略，如下所述。
   <1>rr: round-robin，轮询。
   <2>lc: least connection，最小连接数。
   <3>dh: destination hashing，目的地址哈希。
   <4>sh: source hashing ,原地址哈希。
   <5>sed: shortest expected delay，最短期望延时。
   <6>nq: never queue ，永不排队。
   （4）kernelspace模式： windows server 上的代理模式。

2. 会话保持机制

service 支持通过设置 sessionAffinity 实现基于客户端IP 的会话保持机制，即首次将某个客户端来源IP发起的请求到后端的某个Pod上，之后从相同的客户端IP 发起的请求都将被转发到相同的后端Pod 上，配置参数为servic.spec.sessionAffinity，例如：

apiVersion: v1
kind: Service
metadata: 
  name: webapp
spec: 
  sessionAffinity: ClientIP
  ports: 
  - protocol: TCP
    port: 8080
    targetPort: 8080
  selector: 
    app: webapp

同时，用户可以设置会话保持的最长时间，在此时间之后重置客户端来源IP 的保持规则，配置参数为service.spec.sessionAffinityConfig.clientIP.timeoutSeconds。例如下面服务将会话保持时间设置为10800s( 3h )。

apiVersion: v1
kind: Service
metadata: 
  name: webapp
spec: 
  sessionAffinity: ClientIP
  sessionAffinityConfig: 
    clientIP: 
      timeoutSeconds: 10800
  ports: 
  - protocol: TCP
    port: 8080
    targetPort: 8080
  selector: 
    app: webapp
    

通过Service 的负载均衡机制，Kubernetes 实现了一种分布式应用的统一入口，免去了客户端应用获知后端服务实例列表和变化的复杂度。