kube-proxy是kubernetes中网络核心组件，实现了服务暴露和转发等网络功能。如前面章节讲到，kube-proxy支持用户空间模式，ipvs和iptables三种代理模式。用户空间模式性能问题较严重，基本不再使用，应用最多的是iptables和ipvs模式。如果启动时不指定具体使用哪种模式，当前版本kube-proxy会优先使用iptables模式，如果探测到系统不支持则回滚到用户空间模式。当然，如果指定了ipvs模式，但是系统不支持的话也会回滚到iptables模式。
kube-proxy通过apiserver监听service和endpoint资源的变化，并动态更新网络配置规则。当前iptables应该是应用较多的模式，因此本节主要针对iptables规则进行分析。对于ipvs模式来说也并不是不需要iptables规则，在下列情况的时候还是会依赖iptables的规则实现相关功能：参考这里。在本节对iptables规则进行分析之后，可以按照这种方式再去分析ipvs相关规则配置，在分析ipvs规则时也需要要求我们熟悉ipvs和ipset等。
在kubernetes网络中，还有其他网络插件实现了和kube-proxy相同的功能，若kube-router，cilium，他们都支持kube-proxy实现的功能，因此在使用上述网络插件时，集群里可以不部署kube-proxy。
kube-proxy在同步iptables规则时是通过iptables-save方式获取当前的规则，然后根据集群内的service状态动态对已有规则进行更新，最后使用iptables-save将规则在配置到系统上。kube-proxy重启不会影响到新建链接和已有链接的状态。在删除已有service，kube-proxy还会释放相关的链接，以及对不同协议的额外处理操作，这里不做太多分析。
下面是一个固定nginx的service的来进行分析iptables规则。
[root@master1 ~]# kubectl get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 172.17.0.1 <none> 443/TCP 79d
nginx LoadBalancer 172.17.45.122 192.168.64.1,4.3.2.1 80:30935/TCP 3d5h
[root@master1 ~]# kubectl edit svc nginx
Edit cancelled, no changes made.
[root@master1 ~]# kubectl get svc nginx -oyaml
apiVersion: v1
kind: Service
metadata:
creationTimestamp: "2021-10-16T05:55:09Z"
labels:
app: nginx
name: nginx
namespace: default
resourceVersion: "619828"
uid: 58ad25b5-6ee0-4a10-8c60-3a4371db1bbc
spec:
clusterIP: 172.17.45.122
clusterIPs:
- 172.17.45.122…
kubernetes网络 – kube-proxy详解
发布于