我们知道 kube-proxy 是 Kubernetes 中一个运行在每个节点上的守护进程,它基本上反映了集群中定义的服务已经对后端 Pod 负载均衡的规则管理。
假设我们有几个 API 微服务的 Pods 运行在我们的集群中,这些 Pods 的副本通过一个 Service 服务暴露,当一个请求到达 Service 的虚拟 IP 时,如何将请求转发到其中一个底层 Pod?其实就是通过 kube-proxy 创建的规则,虽然表面上并没有那么简单,但是我们还是可以进行大致的了解。
kube-proxy 可以在三种不同的模式下运行。
- iptables
- IPvs
- userspace(不再推荐)
虽然 iptables 模式对于许多集群和工作负载来说完全没有问题,但当服务数量很多时(超过1,000个),ipvs 就会很有优势了,由于 iptables 规则是按顺序读取的,如果集群中存在许多服务,那么它的使用会影响路由性能。
Tigera(Calico 的创建者和维护者)在这篇很棒的文章(https://www.tigera.io/blog/comparing-kube-proxy-modes-iptables-or-ipvs/)中详细介绍了 iptables 和 ipvs 模式的区别。
本文我们将专注于 iptables 模式(下一篇文章将专门介绍 ipvs 模式)来说明 kube-proxy 是如何定义 iptables 规则。
为此,