探究K8S-Service内部iptables路由规则

jiezi

5 年前

在 K8S 集群内部，应用常使用 Service 互访，那么，了解 Service 技术优缺点将有利于应用规划与部署，鉴于此，本文将通过简单案例以探索 Cluster-Ip 类型 Service 服务的利弊。

为便于讲解，我们先创建如下应用及 Service 服务：

# kubectl run --image=nginx nginx-web-1 --image-pull-policy='IfNotPresent'
# kubectl expose deployment nginx-web-1 --port=80 --target-port=80

Service探索

作者的 K8S 环境是 1.9 版本，其 Service 内部服务由 Kube-Proxy¹ 提供，且默认用 iptables 技术实现，故本文探索 K8S 集群 Service 技术，即研究 iptables 在K8S上的技术实现。

Service Route（服务路由）

如下可知，通过 nginx-web-1 服务可实际访问到后端pod：

# nginx pod ip 地址：# kubectl describe pod nginx-web-1-fb8d45f5f-dcbtt | grep "IP"
IP:             10.129.1.22

# Service 服务，通过 172.30.132.253:80 则实际访问到 10.129.1.22:80
# kubectl describe svc nginx-web-1 
...
Type:              ClusterIP
IP:                172.30.132.253
Port:              <unset>  80/TCP
TargetPort:        80/TCP
Endpoints:         10.129.1.22:80
Session Affinity:  None
...

# 重置 nginx web 页面：# kubectl exec -it nginx-web-1-fb8d45f5f-dcbtt -- \
               sh -c "echo hello>/usr/share/nginx/html/index.html"

# curl 10.129.1.22
hello
# curl 172.30.132.253
hello

Service服务分配的 CLUSTER-IP 以及监听的端口均虚拟的，即在 K8S 集群节点上执行 ip a 与netstat -an命令均无法找到，其实际上，IP与 Port 是由 iptables 配置在每 K8S 节点上的。在节点上执行如下命令可找到此 Service 相关的 iptables 配置，简析如下：

当通过 Service 服务 IP：172.30.132.253:80 访问时，匹配第 3 条规则链（KUBE-SERVICES）后，跳转到第 4 条子链（KUBE-SVC-…）上；
第 4 条子链做简单注释后，继而跳转到第 1、2 规则链（KUBE-SEP-…）上；
当源 Pod 通过 Service 访问自身时，匹配第 1 条规则，继而跳转到 KUBE-MARK-MASQ 链中；
匹配到第 2 条规则，此时通过 DNAT 被重定向到后端Pod：108.29.1.22:80。

# iptables-save | grep nginx-web-1
-A KUBE-SEP-UWNFTKZFYWNNNTK7 -s 10.129.1.22/32 -m comment --comment "demo/nginx-web-1:" \
   -j KUBE-MARK-MASQ
-A KUBE-SEP-UWNFTKZFYWNNNTK7 -p tcp -m comment --comment "demo/nginx-web-1:" \
   -m tcp -j DNAT --to-destination 10.129.1.22:80
-A KUBE-SERVICES -d 172.30.132.253/32 -p tcp -m comment \
   --comment "demo/nginx-web-1: cluster IP" -m tcp --dport 80 -j KUBE-SVC-SNP24T7IBBNZDJ76
-A KUBE-SVC-SNP24T7IBBNZDJ76 -m comment --comment "demo/nginx-web-1:" \
   -j KUBE-SEP-UWNFTKZFYWNNNTK7

详细分析 iptables 规则，执行 iptables-save 命令可发现 nat 的PREROUTING与 OUTPUT 链中均有 KUBE-SERVICES 规则链，且处于第一顺位。

*nat
-A PREROUTING -m comment --comment "kubernetes service portals" -j KUBE-SERVICES
-A OUTPUT -m comment --comment "kubernetes service portals" -j KUBE-SERVICES

当通过 Service 访问应用时，流量经由 nat 表中的 PREROUTING 规则链处理后，跳转到 KUBE-SERVICES 子链，而此链包含了对具体 Service 处理的规则。如下所示，访问 172.30.132.253:80 将被跳转到 KUBE-SEP-… 子规则链中。

-A KUBE-SERVICES -d 172.30.132.253/32 -p tcp -m comment \
   --comment "demo/nginx-web-1: cluster IP" -m tcp --dport 80 -j KUBE-SVC-SNP24T7IBBNZDJ76
-A KUBE-SVC-SNP24T7IBBNZDJ76 -m comment --comment "demo/nginx-web-1:" \
   -j KUBE-SEP-UWNFTKZFYWNNNTK7

如下所示，KUBE-SEP-…子链存在两条规则：

第 1 条规则：Pod通过 Service 访问自身时匹配，此规则仅作标记（MARK）处理；
第 2 条规则：通过 DNAT 重定向到后端 Pod 实例上，至此，通过 Service 最终将流量导向到后端实例上；

-A KUBE-SEP-UWNFTKZFYWNNNTK7 -s 10.129.1.22/32 -m comment --comment "demo/nginx-web-1:" \
   -j KUBE-MARK-MASQ
-A KUBE-SEP-UWNFTKZFYWNNNTK7 -p tcp -m comment --comment "demo/nginx-web-1:" \
   -m tcp -j DNAT --to-destination 10.129.1.22:80

-A KUBE-MARK-MASQ -j MARK --set-xmark 0x1/0x1

Loadbalance（负载均衡）

执行如下命令将 Deployment 扩展为 3 个Pod后，继而再观察 Service 负载均衡方面的技术或问题。

# kubectl scale deploy/nginx-web-1 --replicas=3

再次 dump 防火墙规则，发现 Service 经由 iptables 的statistic模块，以 random 方式均衡的分发流量，也即负载均衡模式为轮训。

存在 3 条DNAT与 KUBE-MARK-MASQ 规则，分别对应 3 个后端 Pod 实地址；
KUBE-SERVICES链中存在 3 条子链，除最后一条 KUBE-SVC-… 子链外，其余子链使用模块 statistic 的random模式做流量分割或负载均衡：第 1 条KUBE-SVC-…应用 33% 流量，第 2 条KUBE-SVC-…规则应用剩余的 50% 流量，第 3 条KUBE-SVC-…规则应用最后的流量。

# iptables-save | grep nginx-web-1
-A KUBE-SEP-BI762VOIAZZWU5S7 -s 10.129.1.27/32 -m comment --comment "demo/nginx-web-1:" \
   -j KUBE-MARK-MASQ
-A KUBE-SEP-BI762VOIAZZWU5S7 -p tcp -m comment --comment "demo/nginx-web-1:" \
   -m tcp -j DNAT --to-destination 10.129.1.27:80

-A KUBE-SEP-CDQIKEVSTA766BRK -s 10.129.1.28/32 -m comment --comment "demo/nginx-web-1:" \
   -j KUBE-MARK-MASQ
-A KUBE-SEP-CDQIKEVSTA766BRK -p tcp -m comment --comment "demo/nginx-web-1:" \
   -m tcp -j DNAT --to-destination 10.129.1.28:80

-A KUBE-SEP-W5HTO42ZVNHJQWBG -s 10.129.3.57/32 -m comment --comment "demo/nginx-web-1:" \
   -j KUBE-MARK-MASQ
-A KUBE-SEP-W5HTO42ZVNHJQWBG -p tcp -m comment --comment "demo/nginx-web-1:" \
   -m tcp -j DNAT --to-destination 10.129.3.57:80

-A KUBE-SERVICES -d 172.30.132.253/32 -p tcp -m comment \
   --comment "demo/nginx-web-1: cluster IP" -m tcp --dport 80 -j KUBE-SVC-SNP24T7IBBNZDJ76

-A KUBE-SVC-SNP24T7IBBNZDJ76 -m comment --comment "demo/nginx-web-1:" \
   -m statistic --mode random --probability 0.33332999982 -j KUBE-SEP-BI762VOIAZZWU5S7
-A KUBE-SVC-SNP24T7IBBNZDJ76 -m comment --comment "demo/nginx-web-1:" \
   -m statistic --mode random --probability 0.50000000000 -j KUBE-SEP-CDQIKEVSTA766BRK
-A KUBE-SVC-SNP24T7IBBNZDJ76 -m comment --comment "demo/nginx-web-1:" \
   -j KUBE-SEP-W5HTO42ZVNHJQWBG

Session Affinity（会话保持）

如下所示，调整 Service 服务，打开会话保持功能，并设置会话保持期限为 3 小时（PS：若不设置，则默认是 3 小时）：

# kubectl edit svc nginx-web-1
...
  sessionAffinity: ClientIP
  sessionAffinityConfig:
    clientIP:
      timeoutSeconds: 10800
...

继续观察 iptables 实现，发现在原有基础上，iptables规则中添加了 recent 模块，此模块被用于会话保持功能，故 kube-proxy 通过在 iptables 中结合 statistic 与recent模块，实现了 Service 的轮训负载均衡与会话保持功能。

通过 Service 服务访问应用，封包进入 KUBE-SERVICES 规则链，并跳转到 KUBE-SVC-… 子链中；
在 KUBE-SVC-SNP… 子链中，recent位于 statistic 模块前，故而，有如下情况出现：
- 当客户端第一次访问 Service 时，KUBE-SVC-…子链中的规则（-m recent –rcheck –seconds 10800 –reap …–rsource）池中未记录客户端地址，故封包匹配失败，从而封包被后续的 statistic 模块规则处理后，均衡分发到 KUBE-SEP-… 子链中，此链中使用 recent 模块的 –set 参数将客户源地址记录到规则池后，DNAT到实际后端实例上；
- KUBE-SVC-…子链中 recent 模块配置了源地址记录期限，若客户端 3（–seconds 10800 –reap）小时内未访问服务，则recent 规则池中的客户端记录将被移除，此时客户端再次访问 Service 就如同第一次访问 Service 一样；
- 当客户端在 3 小时内再次访问 Service 时，匹配 KUBE-SVC-… 子链中的 recent 模块规则后，跳转到 KUBE-SEP 子链，其规则中 recent 模块 –set 参数将更新规则池中的 Record TTL，而后DNAT 到实际后端实例上；

# iptables-save | grep nginx-web-1
-A KUBE-SEP-BI762VOIAZZWU5S7 -s 10.129.1.27/32 -m comment --comment "demo/nginx-web-1:" \
   -j KUBE-MARK-MASQ
-A KUBE-SEP-BI762VOIAZZWU5S7 -p tcp -m comment --comment "demo/nginx-web-1:" \
   -m recent --set --name KUBE-SEP-BI762VOIAZZWU5S7 --mask 255.255.255.255 \
   --rsource -m tcp -j DNAT --to-destination 10.129.1.27:80
# 省略 2 条类似的 KUBE-SEP 规则
...

-A KUBE-SERVICES -d 172.30.132.253/32 -p tcp -m comment \
   --comment "demo/nginx-web-1: cluster IP" -m tcp --dport 80 -j KUBE-SVC-SNP24T7IBBNZDJ76

-A KUBE-SVC-SNP24T7IBBNZDJ76 -m comment --comment "demo/nginx-web-1:" \
   -m recent --rcheck --seconds 10800 --reap --name KUBE-SEP-BI762VOIAZZWU5S7 \
   --mask 255.255.255.255 --rsource -j KUBE-SEP-BI762VOIAZZWU5S7
# 省略 2 条类似的 KUBE-SVC 规则
...

-A KUBE-SVC-SNP24T7IBBNZDJ76 -m comment --comment "demo/nginx-web-1:" \
   -m statistic --mode random --probability 0.33332999982 -j KUBE-SEP-BI762VOIAZZWU5S7
-A KUBE-SVC-SNP24T7IBBNZDJ76 -m comment --comment "demo/nginx-web-1:" \
   -m statistic --mode random --probability 0.50000000000 -j KUBE-SEP-CDQIKEVSTA766BRK
-A KUBE-SVC-SNP24T7IBBNZDJ76 -m comment --comment "demo/nginx-web-1:" \
   -j KUBE-SEP-W5HTO42ZVNHJQWBG

K8S中的 Service 服务可提供负载均衡及会话保持功能，其通过 Linux 内核 netfilter 模块来配置 iptables 实现，网络封包在内核中流转，且规则匹配很少，故效率非常高；而 Service 负载均衡分发比较薄弱，其通过 statistic 的random规则实现轮训分发，无法实现复杂的如 最小链接 分发方式，鉴于此，K8S 1.9后续版本调整了 kube-proxy 服务，其可通过 ipvs 实现 Service 负载均衡功能。

K8S 1.9版本可使用 kube-router 替换 kube-proxy，且可使用ipvs 替换 iptables 来实现 service 服务。↩

探究K8S-Service内部iptables路由规则

前言

Service探索

Service Route（服务路由）

Loadbalance（负载均衡）

Session Affinity（会话保持）

总结