Kubernetes kube-proxy 详解

iptables 模式（目前kube-proxy默认的工作模式）

在这种模式下，kube-proxy通过观察Kubernetes中service和endpoint对象的变化，当有servcie创建时，kube-proxy在iptables中追加新的规则。对于service的每一个endpoint，会在iptables中追加一条规则，设定动作为DNAT，将目的地址设置成真正提供服务的pod地址；再为servcie追加规则，设定动作为跳转到对应的endpoint的规则上，

默认情况下，kube-proxy随机选择一个后端的服务，可以通过iptables中的 -m recent 模块实现session affinity功能，通过 -m statistic 模块实现负载均衡时的权重功能

比如说创建了一个service，对应的IP：1.2.3.4,port:8888，对应一个后端地址：10.1.0.8:8080，则会在iptables中追加（主要规则）：

 -A PREROUTING -j KUBE-SERVICES

-A KUBE-SERVICES -d 1.2.3.4/32 -p tcp –dport 8888 -j KUBE-SVC-XXXXXXXXXXXXXXXX

-A KUBE-SVC-XXXXXXXXXXXXXXXX -j KUBE-SEP-XXXXXXXXXXXXXXXX

-A KUBE-SEP-XXXXXXXXXXXXXXXX -p tcp -j DNAT –to-destination 10.1.0.8:8080

KUBE-SERVICES 是kube-proxy在iptable中创建的规则链，在PREROUTING阶段执行

• 当请求访问service时，iptables在prerouting阶段，将讲求jump到KUBE-SERVICES，
• 在KUBE-SERVICES 中匹配到上面的第一条准则，继续jump到KUBE-SVC-XXXXXXXXXXXXXXXX，
• 根据这条准则jump到KUBE-SEP-XXXXXXXXXXXXXXXX，
• 在KUBE-SEP-XXXXXXXXXXXXXXXX规则中经过DNAT动做，访问真正的pod地址10.1.0.8:8080。

在这种逻辑下，数据转发都在系统内核层面做，提升了性能，并且即便kube-proxy不工作了，已经创建好的服务还能正常工作 。但是在这种模式下，如果选中的第一个pod不能响应，请求就会失败，不能像userspace模式，请求失败后kube-proxy还能对其他endpoint进行重试。

这就要求我们的应用(pod)要提供readiness probes功能，来验证后端服务是否能正常提供服务，kube-proxy只会将readiness probes测试通过的pod写入到iptables规则中，以此来避免将请求转发到不正常的后端服务中。