kube-proxykube-proxy 是 K8s 服务于 Pod 网络的核心组件负责实现Service服务到Endpoint后端 Pod的流量转发与负载均衡。环境准备rootmaster30 ~13:52:52# kubectl create ns servicesrootmaster30 ~14:00:11# kubectl config set-context --current --namespace services工作模式类型kube-proxy 工作模式有以下几种模式地位性能适用场景特点iptables默认模式中服务数 1000小规模集群、环境稳定依赖内核 netfilter规则多时有性能损耗IPVS推荐模式极高服务数 10w中大规模生产环境基于内核 IPVS哈希表查找性能碾压 iptablesUserspace老旧/废弃低仅测试、兼容旧版全用户态转发性能最差K8s 1.25 已移除✅ 生产环境必选 IPVS 模式配合 Calico 网络插件性能与稳定性最佳。工作模式切换查看工作模式rootmaster30 ~14:34:00# kubectl get cm -n kube-system kube-proxy -o yaml|grep modemode: # mode值为空。# 查看pod/kube-proxy日志rootmaster30 ~14:35:03# kubectl get pods -n kube-system -l k8s-appkube-proxy -o namepod/kube-proxy-dhxmv pod/kube-proxy-jvd66 pod/kube-proxy-qvtxs rootmaster30 ~14:35:22# kubectl logs -n kube-system kube-proxy-dhxmv |grep UsinggI041513:03:28.3806431server.go:511]Using lenient decoding as strict decoding failederrI041513:03:28.3807961server_linux.go:69]Using iptables proxyI041513:03:28.4734061server_linux.go:165]Using iptables Proxier# 输出内容Using iptables proxy表明默认使用iptables修改工作模式# 步骤 1编辑 kube-proxy 配置 ConfigMaprootmaster30 ~14:00:37# kubectl edit cm -n kube-system kube-proxy# 找到并修改 mode 字段为相应的值例如ipvs。....metricsBindAddress:mode:ipvs....# 步骤 2重启 kube-proxy DaemonSetrootmaster30 ~14:17:44# kubectl rollout restart daemonset -n kube-system kube-proxy# 步骤 3验证模式切换rootmaster30 ~14:18:42# kubectl get pods -n kube-system -l k8s-appkube-proxy -o namepod/kube-proxy-dhxmv pod/kube-proxy-jvd66 pod/kube-proxy-qvtxs rootmaster30 ~14:19:13# kubectl logs -n kube-system kube-proxy-jvd66....I0811 06:18:10.1115991server_linux.go:233]Using ipvs Proxier....# 输出内容Using ipvs Proxier表明使用ipvsIPVS 模式IPVS 代理模式基于 netfilter 回调函数类似于 iptables 模式 但它使用哈希表作为底层数据结构在内核空间中生效。 这意味着 IPVS 模式下的 kube-proxy 比 iptables 模式下的 kube-proxy 重定向流量的延迟更低同步代理规则时性能也更好。 与其他代理模式相比IPVS 模式还支持更高的网络流量吞吐量。IPVS 为将流量均衡到后端 Pod 提供了更多选择rr轮询lc最少连接打开连接数最少dh目标地址哈希sh源地址哈希sed最短预期延迟nq最少队列工作原理kube-proxy 在宿主机内核中创建IPVS 虚拟服务器并将后端 Pod 作为Real Server注册。IPVS 基于哈希表存储转发规则查找效率为 O(1)。流量到达后IPVS 根据配置的调度算法直接将流量转发到后端 Pod绕过了复杂的 iptables 规则链。通信流程图访问 Service IP:Port哈希查找调度算法直接路由/隧道客户端 Pod宿主机网卡内核 IPVS 虚拟服务器选择最优后端 Pod后端 Pod IP:Port响应流量直接返回核心优势支持多种高级调度算法轮询 rr、加权轮询 wrr、最少连接 lc 等。性能与服务数量无关支持十万级服务规模。内置健康检查与 K8s Endpoint 联动。验证原理前置准备已安装 IPVS 依赖ipvsadm、ipset并加载内核模块。kube-proxy 已切换为 IPVS 模式。验证步骤1. 创建测试资源# 创建一个 nginx Deploymentrootmaster30 ~14:31:15# kubectl create deployment web --imagenginx --replicas3rootmaster30 ~14:31:31# kubectl get pods -o wide | awk {print $1,$6}NAME IP web-7c56dcdb9b-fgzdq10.224.26.147 web-7c56dcdb9b-qk97610.224.71.217 web-7c56dcdb9b-stb7n10.224.71.209# 设置 pod 主页内容为为自己的pod名称rootmaster30 ~14:31:37# \forpodin$(kubectl get pods-ocustom-columnsNAME:.metadata.name --no-headers)dokubectlexec$pod--bash-cecho$pod /usr/share/nginx/html/index.htmldone# 验证主页内容rootmaster30 ~14:32:07# curl http://10.224.26.147web-7c56dcdb9b-fgzdq rootmaster30 ~14:32:31# curl http://10.224.71.217web-7c56dcdb9b-qk976 rootmaster30 ~14:32:41# curl http://10.224.71.209web-7c56dcdb9b-stb7n# 创建Servicerootmaster30 ~14:32:49# kubectl expose deployment web --port80rootmaster30 ~14:33:04# kubectl get svc webNAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S)AGE web ClusterIP10.110.237.125none80/TCP 11s2. 查看 IPVS 规则在任意集群节点执行这里在master30节点执行查看 kube-proxy 创建的 IPVS 虚拟服务# 列出虚拟服务器rootmaster30 ~14:33:15# ipvsadm -Lnt 10.110.237.125:80看到类似如下的记录其中10.110.237.125:80是 Service IP80是 Service Portrootmaster30 ~14:33:15# ipvsadm -Lnt 10.110.237.125:80Prot LocalAddress:Port Scheduler Flags -RemoteAddress:Port Forward Weight ActiveConn InActConn TCP10.110.237.125:80 rr -10.224.26.147:80 Masq100-10.224.71.209:80 Masq100-10.224.71.217:80 Masq100结论IPVS 已成功为 Service 创建了虚拟服务并绑定了所有后端 Pod。3. 验证负载均衡效果在集群内或外部访问 Service观察流量是否分发到不同 Pod# 连续访问 60 次rootmaster30 ~14:33:35# for i in {1..60}; do curl -s 10.110.237.125; done| sort | uniq -c20web-7c56dcdb9b-fgzdq20web-7c56dcdb9b-qk97620web-7c56dcdb9b-stb7n调度算法选择rr轮询简单均衡节点配置一致时使用wrr加权轮询最推荐适合通用业务、Web、API、网关。wrr 权重来源1. 与 Pod 的 resources.requests.cpu/memory 成正比2. ipvsadm命令临时设置只适合临时测试。lc最少连接适合长连接、WebSocket、游戏服务sh源地址哈希配合 Service sessionAffinity: ClientIP 使用更改调度算法rootmaster30:~# kubectl edit configmap kube-proxy -n kube-system......ipvs: excludeCIDRs: null minSyncPeriod: 0s scheduler:wrr....... mode:ipvs.......# 重启 kube-proxyrootmaster30:~# kubectl rollout restart ds kube-proxy -n kube-system最佳配置apiVersion:kubeproxy.config.k8s.io/v1alpha1kind:KubeProxyConfigurationmode:ipvs# IPVS 核心调优 ipvs:# 调度算法生产推荐rr / wrr / lc 三选一scheduler:rr# 会话保持时间秒0 表示关闭tcpTimeout:900tcpFinTimeout:120udpTimeout:300# 排除 127.0.0.1 负载均衡必须开启excludeCIDRs:-127.0.0.1/32# 严格arp避免集群访问异常必须开启strictARP:true# 性能优化 # 最大打开文件数高并发必调oomScoreAdj:-999# Iptables 规则优化iptables:minSyncPeriod:5ssyncPeriod:30s# 日志级别logging:format:textverbosity:2iptables 模式工作原理kube-proxy 默认工作模式是 iptables 模式。kube-proxy 监听 Service 和 Endpoint 变化在宿主机内核中动态生成iptables 规则链KUBE-SERVICES、KUBE-SEP-XXX 等。当流量进入宿主机时通过 netfilter 框架逐条匹配 iptables 规则实现 DNAT目标地址转换和负载均衡。通信流程图访问 Service IP:Port匹配 Service 规则DNAT 转换客户端 Pod宿主机网卡内核 iptables 规则链随机选择后端 Endpoint IP后端 Pod IP:Port响应流量原路返回核心缺点每增加一个 Service 或 Endpoint都会新增/修改 iptables 规则。当服务数量超过 1000 时规则链膨胀CPU 占用飙升延迟显著增加。验证原理前置准备kube-proxy 已切换为 iptables 模式。验证步骤1. 创建测试资源使用ipvs实验环境准备的资源。2. 查看防火墙规则步骤1获取防火墙规则。在任意集群节点执行这里在master30节点执行保存防火墙规则rootmaster30:~# iptables-save iptables.list步骤2分析 svc-nginx 规则。rootmaster30:~# cat iptables.list |grep 10.103.143.120-AKUBE-SERVICES-d10.103.143.120/32-ptcp-mcomment--commentservices/web cluster IP-mtcp--dport80-jKUBE-SVC-7D76YWGERGEPC4GC-AKUBE-SVC-7D76YWGERGEPC4GC!-s10.224.0.0/16-d10.103.143.120/32-ptcp-mcomment--commentservices/web cluster IP-mtcp--dport80-jKUBE-MARK-MASQ分析防火墙规则第一条防火墙规则在nat表KUBE-SERVICES服务总入口链中匹配目的 IP 为 10.103.143.120/32、协议 TCP、目的端口 80的报文通过注释标识为 services/web 的 ClusterIP 服务并跳转至该服务专属调度链 KUBE-SVC-7D76YWGERGEPC4GC。第二条防火墙规则则在服务专属链KUBE-SVC-7D76YWGERGEPC4GC中匹配源地址非 Pod 网段 10.224.0.0/16、目的 IP 10.103.143.120/32、协议 TCP、目的端口 80的报文注释标识为 services/web cluster IP并跳转至 KUBE-MARK-MASQ 进行 SNAT 标记。步骤3进一步追踪链路KUBE-SVC-7D76YWGERGEPC4GC。rootmaster30:~# cat iptables.list | grep KUBE-SVC-7D76YWGERGEPC4GC:KUBE-SVC-7D76YWGERGEPC4GC -[0:0]-AKUBE-SERVICES-d10.103.143.120/32-ptcp-mcomment--commentservices/web cluster IP-mtcp--dport80-jKUBE-SVC-7D76YWGERGEPC4GC-AKUBE-SVC-7D76YWGERGEPC4GC!-s10.224.0.0/16-d10.103.143.120/32-ptcp-mcomment--commentservices/web cluster IP-mtcp--dport80-jKUBE-MARK-MASQ-AKUBE-SVC-7D76YWGERGEPC4GC-mcomment--commentservices/web - 10.224.113.164:80-mstatistic--moderandom--probability0.33333333349-jKUBE-SEP-HYZM2VM7RCC7M2HX-AKUBE-SVC-7D76YWGERGEPC4GC-mcomment--commentservices/web - 10.224.113.165:80-mstatistic--moderandom--probability0.50000000000-jKUBE-SEP-CHPZVFCOFL4YLCYM-AKUBE-SVC-7D76YWGERGEPC4GC-mcomment--commentservices/web - 10.224.19.38:80-jKUBE-SEP-HM7RLUR2RXSQ3D6F分析防火墙规则**第一条防火墙规则**已分析过。**第二条防火墙规则**已分析过。**第三条防火墙规则**在服务调度链KUBE-SVC-7D76YWGERGEPC4GC中对所有协议与地址的访问报文以1/3 随机概率将其跳转至后端端点链KUBE-SEP-HYZM2VM7RCC7M2HX注释标识该端点对应 services/web 服务后端 10.224.113.164:80。**第四条防火墙规则**在服务调度链KUBE-SVC-7D76YWGERGEPC4GC中对未被前序规则匹配的报文以剩余流量 1/2 随机概率总概率 1/3跳转至后端端点链KUBE-SEP-CHPZVFCOFL4YLCYM注释标识对应 services/web 后端 10.224.113.165:80。**第五条防火墙规则**在服务调度链KUBE-SVC-7D76YWGERGEPC4GC中对未被前序概率规则匹配的报文无条件跳转总概率 1/3至后端端点链KUBE-SEP-HM7RLUR2RXSQ3D6F注释标识对应 services/web 后端 10.224.19.38:80。步骤4进一步追踪上面最后三条规则目标链路。rootmaster30:~# cat iptables.list | grep -e KUBE-SEP-HYZM2VM7RCC7M2HX -e KUBE-SEP-CHPZVFCOFL4YLCYM -e KUBE-SEP-HM7RLUR2RXSQ3D6F | grep DNAT-AKUBE-SEP-CHPZVFCOFL4YLCYM-ptcp-mcomment--commentservices/web-mtcp-jDNAT --to-destination10.224.113.165:80-AKUBE-SEP-HM7RLUR2RXSQ3D6F-ptcp-mcomment--commentservices/web-mtcp-jDNAT --to-destination10.224.19.38:80-AKUBE-SEP-HYZM2VM7RCC7M2HX-ptcp-mcomment--commentservices/web-mtcp-jDNAT --to-destination10.224.113.164:80分析防火墙规则第一条防火墙规则在后端端点链KUBE-SEP-HM7RLUR2RXSQ3D6F中匹配TCP 协议报文注释标识为 services/web 服务执行DNAT 目标地址转换将报文目的地址修改为10.224.19.38:80。第二条防火墙规则在后端端点链KUBE-SEP-HYZM2VM7RCC7M2HX中匹配TCP 协议报文注释标识为 services/web 服务执行DNAT 目标地址转换将报文目的地址修改为10.224.113.164:80。第三条防火墙规则在后端端点链KUBE-SEP-CHPZVFCOFL4YLCYM中匹配TCP 协议报文注释标识为 services/web 服务执行DNAT 目标地址转换将报文目的地址修改为10.224.113.165:80。3. 总结全链路流程图入口访问 ClusterIP分流进入KUBE-SERVICES服务调度进入KUBE-SVC-XXXSNAT 负载均衡端点转发进入KUBE-SEP-XXX最终到达后端 Pod客户端访问ClusterIP: 10.103.143.120:80PREROUTINGnat 表KUBE-SERVICES服务总入口KUBE-SVC-7D76YWGERGEPC4GCservices/web 专属调度链SNAT 标记非 Pod 网段流量→ KUBE-MARK-MASQ概率 1/3 负载均衡概率 1/3 负载均衡默认 1/3 负载均衡KUBE-SEP-HYZM2VM7RCC7M2HXKUBE-SEP-CHPZVFCOFL4YLCYMKUBE-SEP-HM7RLUR2RXSQ3D6FDNAT 转发→ Pod: 10.224.113.164:80DNAT 转发→ Pod: 10.224.113.165:80DNAT 转发→ Pod: 10.224.19.38:80环境清理rootmaster30:~# kubectl delete ns services k8s-kube-proxy
kube-proxykube-proxy 是 K8s 服务于 Pod 网络的核心组件负责实现Service服务到Endpoint后端 Pod的流量转发与负载均衡。环境准备rootmaster30 ~13:52:52# kubectl create ns servicesrootmaster30 ~14:00:11# kubectl config set-context --current --namespace services工作模式类型kube-proxy 工作模式有以下几种模式地位性能适用场景特点iptables默认模式中服务数 1000小规模集群、环境稳定依赖内核 netfilter规则多时有性能损耗IPVS推荐模式极高服务数 10w中大规模生产环境基于内核 IPVS哈希表查找性能碾压 iptablesUserspace老旧/废弃低仅测试、兼容旧版全用户态转发性能最差K8s 1.25 已移除✅ 生产环境必选 IPVS 模式配合 Calico 网络插件性能与稳定性最佳。工作模式切换查看工作模式rootmaster30 ~14:34:00# kubectl get cm -n kube-system kube-proxy -o yaml|grep modemode: # mode值为空。# 查看pod/kube-proxy日志rootmaster30 ~14:35:03# kubectl get pods -n kube-system -l k8s-appkube-proxy -o namepod/kube-proxy-dhxmv pod/kube-proxy-jvd66 pod/kube-proxy-qvtxs rootmaster30 ~14:35:22# kubectl logs -n kube-system kube-proxy-dhxmv |grep UsinggI041513:03:28.3806431server.go:511]Using lenient decoding as strict decoding failederrI041513:03:28.3807961server_linux.go:69]Using iptables proxyI041513:03:28.4734061server_linux.go:165]Using iptables Proxier# 输出内容Using iptables proxy表明默认使用iptables修改工作模式# 步骤 1编辑 kube-proxy 配置 ConfigMaprootmaster30 ~14:00:37# kubectl edit cm -n kube-system kube-proxy# 找到并修改 mode 字段为相应的值例如ipvs。....metricsBindAddress:mode:ipvs....# 步骤 2重启 kube-proxy DaemonSetrootmaster30 ~14:17:44# kubectl rollout restart daemonset -n kube-system kube-proxy# 步骤 3验证模式切换rootmaster30 ~14:18:42# kubectl get pods -n kube-system -l k8s-appkube-proxy -o namepod/kube-proxy-dhxmv pod/kube-proxy-jvd66 pod/kube-proxy-qvtxs rootmaster30 ~14:19:13# kubectl logs -n kube-system kube-proxy-jvd66....I0811 06:18:10.1115991server_linux.go:233]Using ipvs Proxier....# 输出内容Using ipvs Proxier表明使用ipvsIPVS 模式IPVS 代理模式基于 netfilter 回调函数类似于 iptables 模式 但它使用哈希表作为底层数据结构在内核空间中生效。 这意味着 IPVS 模式下的 kube-proxy 比 iptables 模式下的 kube-proxy 重定向流量的延迟更低同步代理规则时性能也更好。 与其他代理模式相比IPVS 模式还支持更高的网络流量吞吐量。IPVS 为将流量均衡到后端 Pod 提供了更多选择rr轮询lc最少连接打开连接数最少dh目标地址哈希sh源地址哈希sed最短预期延迟nq最少队列工作原理kube-proxy 在宿主机内核中创建IPVS 虚拟服务器并将后端 Pod 作为Real Server注册。IPVS 基于哈希表存储转发规则查找效率为 O(1)。流量到达后IPVS 根据配置的调度算法直接将流量转发到后端 Pod绕过了复杂的 iptables 规则链。通信流程图访问 Service IP:Port哈希查找调度算法直接路由/隧道客户端 Pod宿主机网卡内核 IPVS 虚拟服务器选择最优后端 Pod后端 Pod IP:Port响应流量直接返回核心优势支持多种高级调度算法轮询 rr、加权轮询 wrr、最少连接 lc 等。性能与服务数量无关支持十万级服务规模。内置健康检查与 K8s Endpoint 联动。验证原理前置准备已安装 IPVS 依赖ipvsadm、ipset并加载内核模块。kube-proxy 已切换为 IPVS 模式。验证步骤1. 创建测试资源# 创建一个 nginx Deploymentrootmaster30 ~14:31:15# kubectl create deployment web --imagenginx --replicas3rootmaster30 ~14:31:31# kubectl get pods -o wide | awk {print $1,$6}NAME IP web-7c56dcdb9b-fgzdq10.224.26.147 web-7c56dcdb9b-qk97610.224.71.217 web-7c56dcdb9b-stb7n10.224.71.209# 设置 pod 主页内容为为自己的pod名称rootmaster30 ~14:31:37# \forpodin$(kubectl get pods-ocustom-columnsNAME:.metadata.name --no-headers)dokubectlexec$pod--bash-cecho$pod /usr/share/nginx/html/index.htmldone# 验证主页内容rootmaster30 ~14:32:07# curl http://10.224.26.147web-7c56dcdb9b-fgzdq rootmaster30 ~14:32:31# curl http://10.224.71.217web-7c56dcdb9b-qk976 rootmaster30 ~14:32:41# curl http://10.224.71.209web-7c56dcdb9b-stb7n# 创建Servicerootmaster30 ~14:32:49# kubectl expose deployment web --port80rootmaster30 ~14:33:04# kubectl get svc webNAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S)AGE web ClusterIP10.110.237.125none80/TCP 11s2. 查看 IPVS 规则在任意集群节点执行这里在master30节点执行查看 kube-proxy 创建的 IPVS 虚拟服务# 列出虚拟服务器rootmaster30 ~14:33:15# ipvsadm -Lnt 10.110.237.125:80看到类似如下的记录其中10.110.237.125:80是 Service IP80是 Service Portrootmaster30 ~14:33:15# ipvsadm -Lnt 10.110.237.125:80Prot LocalAddress:Port Scheduler Flags -RemoteAddress:Port Forward Weight ActiveConn InActConn TCP10.110.237.125:80 rr -10.224.26.147:80 Masq100-10.224.71.209:80 Masq100-10.224.71.217:80 Masq100结论IPVS 已成功为 Service 创建了虚拟服务并绑定了所有后端 Pod。3. 验证负载均衡效果在集群内或外部访问 Service观察流量是否分发到不同 Pod# 连续访问 60 次rootmaster30 ~14:33:35# for i in {1..60}; do curl -s 10.110.237.125; done| sort | uniq -c20web-7c56dcdb9b-fgzdq20web-7c56dcdb9b-qk97620web-7c56dcdb9b-stb7n调度算法选择rr轮询简单均衡节点配置一致时使用wrr加权轮询最推荐适合通用业务、Web、API、网关。wrr 权重来源1. 与 Pod 的 resources.requests.cpu/memory 成正比2. ipvsadm命令临时设置只适合临时测试。lc最少连接适合长连接、WebSocket、游戏服务sh源地址哈希配合 Service sessionAffinity: ClientIP 使用更改调度算法rootmaster30:~# kubectl edit configmap kube-proxy -n kube-system......ipvs: excludeCIDRs: null minSyncPeriod: 0s scheduler:wrr....... mode:ipvs.......# 重启 kube-proxyrootmaster30:~# kubectl rollout restart ds kube-proxy -n kube-system最佳配置apiVersion:kubeproxy.config.k8s.io/v1alpha1kind:KubeProxyConfigurationmode:ipvs# IPVS 核心调优 ipvs:# 调度算法生产推荐rr / wrr / lc 三选一scheduler:rr# 会话保持时间秒0 表示关闭tcpTimeout:900tcpFinTimeout:120udpTimeout:300# 排除 127.0.0.1 负载均衡必须开启excludeCIDRs:-127.0.0.1/32# 严格arp避免集群访问异常必须开启strictARP:true# 性能优化 # 最大打开文件数高并发必调oomScoreAdj:-999# Iptables 规则优化iptables:minSyncPeriod:5ssyncPeriod:30s# 日志级别logging:format:textverbosity:2iptables 模式工作原理kube-proxy 默认工作模式是 iptables 模式。kube-proxy 监听 Service 和 Endpoint 变化在宿主机内核中动态生成iptables 规则链KUBE-SERVICES、KUBE-SEP-XXX 等。当流量进入宿主机时通过 netfilter 框架逐条匹配 iptables 规则实现 DNAT目标地址转换和负载均衡。通信流程图访问 Service IP:Port匹配 Service 规则DNAT 转换客户端 Pod宿主机网卡内核 iptables 规则链随机选择后端 Endpoint IP后端 Pod IP:Port响应流量原路返回核心缺点每增加一个 Service 或 Endpoint都会新增/修改 iptables 规则。当服务数量超过 1000 时规则链膨胀CPU 占用飙升延迟显著增加。验证原理前置准备kube-proxy 已切换为 iptables 模式。验证步骤1. 创建测试资源使用ipvs实验环境准备的资源。2. 查看防火墙规则步骤1获取防火墙规则。在任意集群节点执行这里在master30节点执行保存防火墙规则rootmaster30:~# iptables-save iptables.list步骤2分析 svc-nginx 规则。rootmaster30:~# cat iptables.list |grep 10.103.143.120-AKUBE-SERVICES-d10.103.143.120/32-ptcp-mcomment--commentservices/web cluster IP-mtcp--dport80-jKUBE-SVC-7D76YWGERGEPC4GC-AKUBE-SVC-7D76YWGERGEPC4GC!-s10.224.0.0/16-d10.103.143.120/32-ptcp-mcomment--commentservices/web cluster IP-mtcp--dport80-jKUBE-MARK-MASQ分析防火墙规则第一条防火墙规则在nat表KUBE-SERVICES服务总入口链中匹配目的 IP 为 10.103.143.120/32、协议 TCP、目的端口 80的报文通过注释标识为 services/web 的 ClusterIP 服务并跳转至该服务专属调度链 KUBE-SVC-7D76YWGERGEPC4GC。第二条防火墙规则则在服务专属链KUBE-SVC-7D76YWGERGEPC4GC中匹配源地址非 Pod 网段 10.224.0.0/16、目的 IP 10.103.143.120/32、协议 TCP、目的端口 80的报文注释标识为 services/web cluster IP并跳转至 KUBE-MARK-MASQ 进行 SNAT 标记。步骤3进一步追踪链路KUBE-SVC-7D76YWGERGEPC4GC。rootmaster30:~# cat iptables.list | grep KUBE-SVC-7D76YWGERGEPC4GC:KUBE-SVC-7D76YWGERGEPC4GC -[0:0]-AKUBE-SERVICES-d10.103.143.120/32-ptcp-mcomment--commentservices/web cluster IP-mtcp--dport80-jKUBE-SVC-7D76YWGERGEPC4GC-AKUBE-SVC-7D76YWGERGEPC4GC!-s10.224.0.0/16-d10.103.143.120/32-ptcp-mcomment--commentservices/web cluster IP-mtcp--dport80-jKUBE-MARK-MASQ-AKUBE-SVC-7D76YWGERGEPC4GC-mcomment--commentservices/web - 10.224.113.164:80-mstatistic--moderandom--probability0.33333333349-jKUBE-SEP-HYZM2VM7RCC7M2HX-AKUBE-SVC-7D76YWGERGEPC4GC-mcomment--commentservices/web - 10.224.113.165:80-mstatistic--moderandom--probability0.50000000000-jKUBE-SEP-CHPZVFCOFL4YLCYM-AKUBE-SVC-7D76YWGERGEPC4GC-mcomment--commentservices/web - 10.224.19.38:80-jKUBE-SEP-HM7RLUR2RXSQ3D6F分析防火墙规则**第一条防火墙规则**已分析过。**第二条防火墙规则**已分析过。**第三条防火墙规则**在服务调度链KUBE-SVC-7D76YWGERGEPC4GC中对所有协议与地址的访问报文以1/3 随机概率将其跳转至后端端点链KUBE-SEP-HYZM2VM7RCC7M2HX注释标识该端点对应 services/web 服务后端 10.224.113.164:80。**第四条防火墙规则**在服务调度链KUBE-SVC-7D76YWGERGEPC4GC中对未被前序规则匹配的报文以剩余流量 1/2 随机概率总概率 1/3跳转至后端端点链KUBE-SEP-CHPZVFCOFL4YLCYM注释标识对应 services/web 后端 10.224.113.165:80。**第五条防火墙规则**在服务调度链KUBE-SVC-7D76YWGERGEPC4GC中对未被前序概率规则匹配的报文无条件跳转总概率 1/3至后端端点链KUBE-SEP-HM7RLUR2RXSQ3D6F注释标识对应 services/web 后端 10.224.19.38:80。步骤4进一步追踪上面最后三条规则目标链路。rootmaster30:~# cat iptables.list | grep -e KUBE-SEP-HYZM2VM7RCC7M2HX -e KUBE-SEP-CHPZVFCOFL4YLCYM -e KUBE-SEP-HM7RLUR2RXSQ3D6F | grep DNAT-AKUBE-SEP-CHPZVFCOFL4YLCYM-ptcp-mcomment--commentservices/web-mtcp-jDNAT --to-destination10.224.113.165:80-AKUBE-SEP-HM7RLUR2RXSQ3D6F-ptcp-mcomment--commentservices/web-mtcp-jDNAT --to-destination10.224.19.38:80-AKUBE-SEP-HYZM2VM7RCC7M2HX-ptcp-mcomment--commentservices/web-mtcp-jDNAT --to-destination10.224.113.164:80分析防火墙规则第一条防火墙规则在后端端点链KUBE-SEP-HM7RLUR2RXSQ3D6F中匹配TCP 协议报文注释标识为 services/web 服务执行DNAT 目标地址转换将报文目的地址修改为10.224.19.38:80。第二条防火墙规则在后端端点链KUBE-SEP-HYZM2VM7RCC7M2HX中匹配TCP 协议报文注释标识为 services/web 服务执行DNAT 目标地址转换将报文目的地址修改为10.224.113.164:80。第三条防火墙规则在后端端点链KUBE-SEP-CHPZVFCOFL4YLCYM中匹配TCP 协议报文注释标识为 services/web 服务执行DNAT 目标地址转换将报文目的地址修改为10.224.113.165:80。3. 总结全链路流程图入口访问 ClusterIP分流进入KUBE-SERVICES服务调度进入KUBE-SVC-XXXSNAT 负载均衡端点转发进入KUBE-SEP-XXX最终到达后端 Pod客户端访问ClusterIP: 10.103.143.120:80PREROUTINGnat 表KUBE-SERVICES服务总入口KUBE-SVC-7D76YWGERGEPC4GCservices/web 专属调度链SNAT 标记非 Pod 网段流量→ KUBE-MARK-MASQ概率 1/3 负载均衡概率 1/3 负载均衡默认 1/3 负载均衡KUBE-SEP-HYZM2VM7RCC7M2HXKUBE-SEP-CHPZVFCOFL4YLCYMKUBE-SEP-HM7RLUR2RXSQ3D6FDNAT 转发→ Pod: 10.224.113.164:80DNAT 转发→ Pod: 10.224.113.165:80DNAT 转发→ Pod: 10.224.19.38:80环境清理rootmaster30:~# kubectl delete ns services