概述
为了支持集群的水平扩展、高可用性，k8s抽象出了Service的概念。Service是对一组Pod的抽象，它会根据访问策略来访问这组Pod。
k8s创建Service时会为服务分配一个虚拟的IP地址，客户端通过访问这个虚拟的IP地址来访问服务，服务则负责将请求转发到后端的Pod上，其起到反向代理作用。
不同之处：
- IP地址是虚拟的，外面不能直接访问
- 它的部署和启动是k8s自动管理的
kube-proxy在每个Node上运行，可以看做是代理和负载均衡器。它能在运行的过程中动态创建与Service相关的iptables规则，这些规则实现了将访问服务的请求负载分发到后端的Pod上。由于iptables机制针对的是本地的kube-proxy端口，所以在每个Node上都要运行kube-proxy组件。
数据同步与监听
kube-proxy 首先会通过与 Kubernetes API 服务器交互，获取集群中所有服务（Services）和 endpoints（即服务背后实际运行的 Pods 列表）的信息。它持续监听这些信息的变化，一旦有新的服务被创建、修改或删除，kube-proxy 会立即更新其内部状态以反映这些变化。
网络转发模式
kube-proxy 支持几种不同的工作模式，主要取决于 Kubernetes 集群的网络插件配置。常见的模式包括：
- iptables: 在这种模式下，
kube-proxy使用iptables规则来实现服务的负载均衡。每当服务发生变化时，kube-proxy会相应地更新 iptables 规则，从而将流入的服务请求重定向到后端的一个或多个Pod上。 - IPVS (IP Virtual Server) : IPVS 提供了比 iptables 更高性能的负载均衡解决方案。它在内核空间中维护一个负载均衡器，可以更高效地分发流量到后端 Pods。当启用
IPVS模式时，kube-proxy会使用 IPVS 来实现服务到 Pod 的负载均衡。 - Userspace: 较旧的一种模式，现在已经不推荐使用。在此模式下，
kube-proxy直接在用户空间中处理和转发服务请求到后端 Pods，这种方式性能较低，因为数据包需要在用户态和内核态之间切换。
iptables和IPVS对比
- IPVS为大型集群提供更好的可扩展性和性能
- IPVS支持比iptables更复杂的负载均衡算法
- IPVS支持服务器健康检查和连接重试等功能
- IPVS可以动态修改ipset的集合
IPVS图
会话亲和性（Session Affinity）
kube-proxy 还支持会话亲和性（Session Affinity），允许来自同一客户端的请求尽可能地被路由到同一 backend Pod。这通常是通过在负载均衡策略中加入客户端 IP 哈希实现的，确保了诸如用户会话之类的状态一致性。
结语
kube-proxy 作为 Kubernetes 集群内部的服务发现与负载均衡的核心组件，通过动态地调整网络规则或利用内核级负载均衡技术，确保了外部或集群内部对服务的访问能够高效、正确地被转发到后端 Pods 上。其具体的工作机制依赖于所配置的运行模式，但核心目标始终是保持服务的高可用性和可访问性。
