kubernetes service 原理精讲
介绍
Kubernetes Service 用于流量的负载均衡和反向代理，其通过 kube-proxy 组件实现。从服务的角度来看，kube-controller-manager 实现了服务注册，kube-proxy 实现了 kubernetes 集群内服务的负载均衡。
示意图如下：
kube-proxy 通过三种模式 userspace，iptables 和 IPVS 实现 Service 流量的负载均衡。userspace 不太常用，kube-proxy 自 v1.8 开始支持 IPVS，v1.11 GA。
iptables 和 IPVS 都是基于内核的 Netfilter 实现。iptables 基于 iptables 表匹配规则，复杂度为 O(n)，IPVS 基于哈希表实现规则匹配，复杂度为 O(1)。详细对比如下：
性能对比测试：
数据来源：Kubernetes 社区性能测试
多维度对比：
iptabls
iptables 介绍学习可参考 iptables，非常好的 iptables 学习资料，强烈推荐。
iptables 重点在五链五表，其示意图如下：
kube-proxy 通过在 INPUT，FORWARD，POST_ROUTING 链上添加钩子规则实现 Service 的负载均衡和反向代理。示意图如下：
图片来源于 公众号：云原生 Space
ipvs
IPVS 提供 DNAT 和负载均衡，需要和 iptables 配合使用才能实现 Service 的流量转发。
结合 ClusterIP 看 kube-proxy ipvs 是如何实现流量负载均衡的。
Service ClusterIP
Kubernetes Service：
ipvsadm 查看 svc 的负载均衡信息：
输出部分元素解释：
rr: 表示负载均衡策略，默认是 rr。
Masq：负载均衡模式，Masq 指的是 NAT 模式。IPVS 支持 Direct Routing，Tunneling 模式，这两种都不支持端口映射，IPVS 使用的是 Masq 模式。
IPVS 提供如下负载均衡策略：
rr：轮询调度
lc：最小连接数
dh：目标哈希
sh：源哈希
sed：最短期望延迟
nq： 不排队调度
只有负载均衡信息并不能使集群内访问 ClusterIP 的流量转发到后端服务。流量首先需要经过内核，由内核根据 iptables 策略决定丢弃/接受还是转发包。要接收访问 ClusterIP 的流量就需要在 iptables 的 PREROUTING 表中配置接受策略。并且需要创一个 dummy 接口，添加 ClusterIP 从而骗过内核，接收集群内发往 ClusterIP 的数据包。
kube-proxy 会创建 kube-ipvs0 的 dummy 接口，如下：
这里也从侧面印证了为什么是集群内访问，这是 dummy 接口，集群外不通
查看 iptables 策略看内核是如何接收访问 ClusterIP 的数据包的：
这里的逻辑很重要，为了理解清晰，有必要进一步介绍下 KUBE-MARK-MASQ 这条规则：
这条规则包括两个点：
1、match-set KUBE-CLUSTER-IP dst,dst 使用 iptables 的 ipset 模块匹配访问 ClusterIP 的流量。ipset 创建了一个包括 ip 信息等的集合 KUBE-CLUSTER-IP（实际是哈希表，查找复杂度为 O(1)）：
2、匹配到访问 ClusterIP 的流量后进入 KUBE-MARK-MASQ 规则：
KUBE-MARK-MASQ 规则将数据包打上 MARK:0x4000 标签。
这里留个问题，为什么需要打上
MARK:0x4000标签？
接着打上 MARK 标签的数据包被接收，进入 ipvs 负载均衡到相应的后端服务。
转发到哪里？
kubernetes 集群中每个节点都会起 kube-proxy 配置 iptables/ipvs 规则，并且这些规则是一致的。不同于传统负载均衡，kubernetes 集群内的负载均衡是分布式的。由 kube-proxy 保持信息一致。
集群内节点访问本节点的后端服务可以通过流量被接收后通过 ipvs 做 DNAT 直接转发到 pod 服务，没有问题。
那么，集群内节点访问 ClusterIP 转发到其它节点的 pod 该怎么做的呢？这涉及到跨节点通信，就需要 CNI 的帮忙了。示意图如下：
数据怎么回去？
前面提到通过 DNAT 数据包会转发到后端服务。后端服务的数据包又该怎么回去呢？
后端数据包经过 OUTPUT 链到 POSTROUTING 链，在 POSTROUTING 链做 SNAT 转发数据包到访问节点。
流程如下：
KUBE-POSTROUTING 的规则非常重要，值得拆开好好讲。
规则 1: MASQUERADE
MASQUERADE all -- anywhere anywhere /* Kubernetes endpoints dst ip:port, source ip for solving hairpin purpose */ match-set KUBE-LOOP-BACK dst,dst,src
这条规则是给 pod 访问自己用的，如果 pod 要访问自己，那就别匹配其它规则了，直接将流量转给自己。这称为发卡弯（hairping）模式。
这也是为什么这条规则在 KUBE-POSTROUTING 链最前面的原因。
继续往下看，我们的任务是探索后端服务的数据包又该怎么回去的。
规则 2: RETURN
RETURN all -- anywhere anywhere mark match ! 0x4000/0x4000
啊哈，还记得我们前面留的问题为什么要打 MARK:0x4000 标签吗？
答案就在这条规则，如果包不带 MARK:0x4000 则退出 KUBE-POSTROUTING,意味着只有带 MARK:0x4000 标签的数据包才会做 SNAT。MARK:0X4000 实际是用来区分是否做 NAT 的标签。
我们的数据包是带 MARK:0X4000 标签的，继续往下走。
规则 3: MARK
MARK all -- anywhere anywhere MARK xor 0x4000
MARK xor 0x4000 清除数据包的 MARK:0X4000 标签。
规则 4: MASQUERADE
MASQUERADE all -- anywhere anywhere /* kubernetes service traffic requiring SNAT */ random-fully
终于到 SNAT 规则了，对数据包做 SNAT，将请求转发回去。
小结
本文主要通过 kubernetes service 的 ClusterIP 示例介绍了 iptables 结合 ipvs 是如何管理集群内流量的。关于 NodePort，Ingress，LoadBalancer 并未在文中的讨论范围之内。后续看是否需要继续介绍其它 service 类型。
文章转载自：hxia043
还未添加个人签名 2025-04-01 加入
还未添加个人简介
评论