当一个Service对象在Kubernetes 集群中被定义出来时,集群内的客户端应用就可以通过服务IP访问到具体的Pod 容器提供的服务了。从服务iP到Pod 的负载均衡机制,则是由每个Node上的kube-proxy 负责实现的,本节对kube-proxy 的代理模式,会话保持机制和基于拓扑感知的服务路由机制(EndpointSlices)进行说明。
-
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 上的代理模式。 -
会话保持机制
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 实现了一种分布式应用的统一入口,免去了客户端应用获知后端服务实例列表和变化的复杂度。