三十、Kubernetes中kube-proxy三种工作模式详解

1、概述

        在kubernetes中，pod是应用程序的载体，我们可以通过pod的ip来访问应用程序，但是pod的ip地址不是固定的，这也就意味着不方便直接采用pod的ip对服务进行访问。

        为了解决这个问题，kubernetes提供了Service资源，Service会对提供同一个服务的多个pod进行聚合，并且提供一个统一的入口地址。通过访问Service的入口地址就能访问到后面的pod服务。

        Service在很多情况下只是一个概念，真正起作用的其实是kube-proxy服务进程，每个Node节点上都运行着一个kube-proxy服务进程。当创建Service的时候会通过api-server向etcd写入创建的service的信息，而kube-proxy会基于监听的机制发现这种Service的变动，然后它会将最新的Service信息转换成对应的访问规则。 

 2、kube-proxy三种工作模式

2.1、userspace 模式        

这种（遗留）模式使用 iptables 添加拦截规则，然后使用 kube-proxy 工具执行流量转发。 kube-proxy 监视 Kubernetes 控制平面对 Service 和 EndpointSlice 对象的增加、修改和删除。 对于每个 Service，kube-proxy 在本地节点上打开一个端口（随机选择）。 任何对这个代理端口的连接都将代理到 Service 的一个后端 Pod（通过 EndpointSlices 报告）。 kube-proxy 在决定使用哪个后端 Pod 时会考虑 Service 的 sessionAffinity 设置。

        用户空间代理添加 iptables 规则，这些规则捕获流向 Service 的 clusterIP（虚拟 IP）和 port 的流量。 这些规则将这些流量重定向到代理后端 Pod 的代理端口。

默认情况下，用户空间模式下的 kube-proxy 通过轮询算法选择后端。

 2.2、iptables 模式

        iptables模式下，kube-proxy为service后端的每个Pod创建对应的iptables规则，直接将发向Cluster IP的请求重定向到一个Pod IP。 该模式下kube-proxy不承担四层负责均衡器的角色，只负责创建iptables规则。该模式的优点是较userspace模式效率更高，但不能提供灵活的LB策略，当后端Pod不可用时也无法进行重试。

2.3、ipvs 模式 

ipvs模式和iptables类似，kube-proxy监控Pod的变化并创建相应的ipvs规则。ipvs相对iptables转发效率更高。除此以外，IPVS 为将流量均衡到后端 Pod 提供了更多选择。

IPSV 支持LB算法如下：

• rr：轮询 默认是这个
• lc：最少连接（打开连接数最少）
• dh：目标地址哈希
• sh：源地址哈希
• sed：最短预期延迟
• nq：最少队列

说明：

要在 IPVS 模式下运行 kube-proxy，必须在启动 kube-proxy 之前确保节点上的 IPVS 可用。

当 kube-proxy 以 IPVS 代理模式启动时，它会验证 IPVS 内核模块是否可用。 如果未检测到 IPVS 内核模块，则 kube-proxy 会退回到 iptables 代理模式运行。

 3、更改kube-proxy工作模式

因为kube-proxy 的配置是通过 ConfigMap 完成的，所以我们只需要更改 name=kube-proxy 的 ConfigmMap 然后删除 所有 拥有标签k8s-app=kube-proxy（更改后不会立即生效，需要删除后，自动重建pod）的pod，即可生效。当然针对每种工作模式，是有前提要求的，咱们以ipvs为例讲解。

3.1、更改ConigMap

# 在kube-system命名空间中查找 name=kube-proxy 的 ConfigMap(cm)
[root@k8s-master ~]# kubectl get cm -n kube-system
NAME                                 DATA   AGE
calico-config                        4      12d
coredns                              1      12d
extension-apiserver-authentication   6      12d
kube-proxy                           2      12d
kube-root-ca.crt                     1      12d
kubeadm-config                       1      12d
kubelet-config                       1      12d


# 编辑 大概47行 修改 mode=ipvs 保存
[root@k8s-master ~]# kubectl edit cm kube-proxy -n kube-system
configmap/kube-proxy edited

3.2、删除kube-system

由于更改了配置文件不会立即生效，将所有kube-system pod删除，k8s会立即新建kube-system pod这个时候新的配置即可生效

#查看 kube-system 命名空间下所有的 pod 可发现 3个以“kube-proxy-” 为前缀的pod，是因为我本地只有3个k8s节点，这三个节点都有相同的label叫“k8s-app=kube-proxy” 那咱们通过label删除即可全部删除
[root@k8s-master ~]# kubectl get pod -n kube-system --show-labels
NAME                                       READY   STATUS    RESTARTS   AGE    LABELS
calico-kube-controllers-59697b644f-bqhsg   1/1     Running   0          12d    k8s-app=calico-kube-controllers,pod-template-hash=59697b644f
calico-node-6x9rq                          1/1     Running   0          12d    controller-revision-hash=55f6f6844b,k8s-app=calico-node,pod-template-generation=1
calico-node-9npwl                          1/1     Running   0          12d    controller-revision-hash=55f6f6844b,k8s-app=calico-node,pod-template-generation=1
calico-node-s9g7k                          1/1     Running   0          12d    controller-revision-hash=55f6f6844b,k8s-app=calico-node,pod-template-generation=1
coredns-c676cc86f-n4nj8                    1/1     Running   0          12d    k8s-app=kube-dns,pod-template-hash=c676cc86f
coredns-c676cc86f-rhvwg                    1/1     Running   0          12d    k8s-app=kube-dns,pod-template-hash=c676cc86f
etcd-k8s-master                            1/1     Running   0          12d    component=etcd,tier=control-plane
kube-apiserver-k8s-master                  1/1     Running   0          12d    component=kube-apiserver,tier=control-plane
kube-controller-manager-k8s-master         1/1     Running   0          12d    component=kube-controller-manager,tier=control-plane
kube-proxy-2jk2g                           1/1     Running   0          16m    controller-revision-hash=dd4c999cf,k8s-app=kube-proxy,pod-template-generation=1
kube-proxy-h5tgq                           1/1     Running   0          16m    controller-revision-hash=dd4c999cf,k8s-app=kube-proxy,pod-template-generation=1
kube-proxy-nbmv2                           1/1     Running   0          16m    controller-revision-hash=dd4c999cf,k8s-app=kube-proxy,pod-template-generation=1
kube-scheduler-k8s-master                  1/1     Running   0          12d    component=kube-scheduler,tier=control-plane
metrics-server-f68c598fc-vt4pz             1/1     Running   0          2d2h   k8s-app=metrics-server,pod-template-hash=f68c598fc


# 通过label 删除所有kube-proxy pod
[root@k8s-master ~]# kubectl delete pod -l k8s-app=kube-proxy -n kube-system
pod "kube-proxy-2jk2g" deleted
pod "kube-proxy-h5tgq" deleted
pod "kube-proxy-nbmv2" deleted
[root@k8s-master ~]#

# 再次查看 发现 kube-proxy pod已新建
[root@k8s-master ~]# kubectl get pod -n kube-system --show-labels
NAME                                       READY   STATUS    RESTARTS   AGE    LABELS
calico-kube-controllers-59697b644f-bqhsg   1/1     Running   0          12d    k8s-app=calico-kube-controllers,pod-template-hash=59697b644f
calico-node-6x9rq                          1/1     Running   0          12d    controller-revision-hash=55f6f6844b,k8s-app=calico-node,pod-template-generation=1
calico-node-9npwl                          1/1     Running   0          12d    controller-revision-hash=55f6f6844b,k8s-app=calico-node,pod-template-generation=1
calico-node-s9g7k                          1/1     Running   0          12d    controller-revision-hash=55f6f6844b,k8s-app=calico-node,pod-template-generation=1
coredns-c676cc86f-n4nj8                    1/1     Running   0          12d    k8s-app=kube-dns,pod-template-hash=c676cc86f
coredns-c676cc86f-rhvwg                    1/1     Running   0          12d    k8s-app=kube-dns,pod-template-hash=c676cc86f
etcd-k8s-master                            1/1     Running   0          12d    component=etcd,tier=control-plane
kube-apiserver-k8s-master                  1/1     Running   0          12d    component=kube-apiserver,tier=control-plane
kube-controller-manager-k8s-master         1/1     Running   0          12d    component=kube-controller-manager,tier=control-plane
kube-proxy-57d4m                           1/1     Running   0          3s     controller-revision-hash=dd4c999cf,k8s-app=kube-proxy,pod-template-generation=1
kube-proxy-5zxrg                           1/1     Running   0          3s     controller-revision-hash=dd4c999cf,k8s-app=kube-proxy,pod-template-generation=1
kube-proxy-z2fpg                           1/1     Running   0          3s     controller-revision-hash=dd4c999cf,k8s-app=kube-proxy,pod-template-generation=1
kube-scheduler-k8s-master                  1/1     Running   0          12d    component=kube-scheduler,tier=control-plane
metrics-server-f68c598fc-vt4pz             1/1     Running   0          2d2h   k8s-app=metrics-server,pod-template-hash=f68c598fc

3.3、安装ipvsadm

ipvsadm 是一个客户端工具，可以让我们和ipvs表的数据进行交互

# 在master 上安装 即可
yum install -y ipvsadm

3.4、通过ipvsadm查看流量转发信息

 ipvsadm -Ln

3.5、kube-proxy默认工作模式以及注意点

        目前 Linux 平台上有三种可用的代理模式：'userspace'（相对较老，即将被淘汰）、 'iptables'（相对较新，速度较快）、'ipvs'（最新，在性能和可扩缩性上表现好）。

        在 Windows 平台上有两种可用的代理模式：'userspace'（相对较老，但稳定）和 'kernelspace'（相对较新，速度更快）。

        在 Linux 平台上，如果代理的 mode 为空，则使用可用的最佳代理（目前是 iptables， 将来可能会发生变化）。如果选择的是 iptables 代理（无论原因如何），但系统的内核 或者 iptables 的版本不够高，kube-proxy 也会回退为 userspace 代理服务器所使用的模式。 当代理的 mode 设置为 'ipvs' 时会启用 IPVS 模式，对应的回退路径是先尝试 iptables， 最后回退到 userspace。

        在 Windows 平台上，如果代理 mode 为空，则使用可用的最佳代理（目前是 userspace， 不过将来可能会发生变化）。如果所选择的是 winkernel 代理（无论原因如何）， 但 Windows 内核不支持此代理模式，则 kube-proxy 会回退到 userspace 代理。

ipvs模式需要启动IPVS时依赖模块：

ip_vs
ip_vs_rr
ip_vs_wrr
ip_vs_sh
nf_conntrack

可通过如下命令确定系统是否启用了这些模块

lsmod | grep -e ip_vs -e nf_conntrack

如果没有启用，通过如下命令启用

modprobe -- ip_vs
modprobe -- ip_vs_rr
modprobe -- ip_vs_wrr
modprobe -- ip_vs_sh
modprobe -- nf_conntrack