前言：
kubernetes集群的网络是比较复杂的，为了更为方便的使用集群，因此，有使用cni网络插件。cni是容器网络接口,作用是实现容器跨主机网络通信.，pod的ip地址段，也称为cidr，现在抛开插件不说，主要是说明一哈kubernetes的三种网络负载均衡模式，由此得出为什么要使用ipvs。
kk8s的kube-proxy支持三种网络负载均衡模式
1、userspace 代理模式
2、iptables代理模式
3、ipvs代理模式
userspace抛开不说，kubernetes自1.8版本开始强推ipvs，之前版本默认使用iptables，这个iptables大家应该比较熟悉的，Linux默认防火墙嘛，它是比较古老的一种网络模式。kubernetes在版本v1.6中已经支持5000个节点，但使用 iptables 的 kube-proxy 实际上是将集群扩展到5000个节点的瓶颈。 在5000节点集群中使用 NodePort 服务，如果有2000个服务并且每个服务有10个 pod，这将在每个工作节点上至少产生20000个iptable 记录，这可能使内核非常繁忙。因此，如果是大集群的话，iptables可能会造成集群崩溃。
ipvs也称之为lvs，以往写过一个简单的lvs服务实现，LVS-NAT集群的搭建以及快速验证负载均衡_zsk_john的博客-CSDN博客 那么，它的优点是哪些呢？
1、底层hash算法，查找复杂度为O(1) 事先将所有路由存储到hash表，不像iptables底层O(0)的复杂度，需要一条条规则从上到下匹配，这样随着service的增多（nat规则增多），内核越来越忙，集群性能越来越差。 2、支持多种负载均衡策略 加权、最少连接、最小负载等 3、支持健康检查和重试（后端pod异常重试去访问另一个后端pod） 也就是说ipvs在同等资源占用下拥有最佳的性能 在这种模式下kube-proxy会监视k8s集群中的对象和端点（endpoint），调用netlink接口以相应地创建ipvs规则并定期与k8s中的service对象和endpoints同步ipvs规则，以确保ipvs状态与期望一致。当访问svc时流量就会被重定向到后端的一个pod。 与 iptables 类似，ipvs 于 netfilter 的 hook 功能，但使用哈希表作为底层数据结构并在内核空间中工作。 这说明 ipvs 可以更快地重定向流量，并且在同步代理规则时具有更好的性能。此外，ipvs 为负载均衡算法提供了更多选项，例如： rr ：轮询调度 lc ：最小连接数 dh ：目标哈希 sh ：源哈希 sed ：最短期望延迟 nq ： 不排队调度
其实说了这么多，总结一哈要表达的意思，
- 1，ipvs比iptables性能更好，这个更好指的是大集群多节点的情况下，小集群可以忽略不计，因此，生产上还是需要开启ipvs的，如果是测试的集群，那无所谓喽，爱谁谁喽。
- 2，网络负载基本都是发生在service资源上的，因此，service越多网络负载会越高，当然，生产上不会只使用NodePort形式的service还会使用ingress形式的service，这无疑会进一步加剧网络负担，因此，ipvs的启用是有一定的道理的。
- 3，ipvs开启主要是在kube-proxy 这个核心服务上启用。
- 4，在kubernetes集群中启用ipvs的先决条件是内核支持。
好了，不废话了，前因后果我想应该是讲清楚了，那么，下面将是实施步骤了。
kubernetes启用ipvs的步骤：
一，
升级内核到4.1.9版本以上
升级方法：Linux centos7升级内核（两种方法：内核编译和yum更新）_zsk_john的博客-CSDN博客_centos升级内核 我的博客内写的应该还算详细。
注：
linux kernel 4.19版本已经将nf_conntrack_ipv4 更新为 nf_conntrack， 而 kube-proxy 1.13 以下版本，强依赖 nf_conntrack_ipv4。 解决方式：
1、降级内核到 4.18
2、升级kube-proxy到 1.13+ （推荐，无需重启机器，影响小）
kube-proxy的版本查询（其实也不需要查，现在应该没人用1.13的kubernetes了吧~~~~~~~~~）：
[root@slave1 cfg]# ../bin/kube-proxy --version Kubernetes v1.18.3
例如升级到5.15：
[root@slave1 cfg]# uname -a Linux slave1 5.16.9-1.el7.elrepo.x86_64 #1 SMP PREEMPT Thu Feb 10 10:39:14 EST 2022 x86_64 x86_64 x86_64 GNU/Linux
二，
安装管理工具后面测试用：
yum install ipvsadm ipset -y
三，
内核修改：
如果内核是 4.18改为nf_conntrack_ipv4
cat > /etc/modules-load.d/50-kubernetes.conf <<EOF # Load some kernel modules needed by kubernetes at boot ip_vs ip_vs_lc ip_vs_wlc ip_vs_rr ip_vs_wrr ip_vs_lblc ip_vs_lblcr ip_vs_dh ip_vs_sh ip_vs_fo ip_vs_nq ip_vs_sed ip_vs_ftp ip_vs_sh nf_conntrack ip_tables ip_set xt_set ipt_set ipt_rpfilter ipt_REJECT ipip EOF
内核优化：
cat > /etc/sysctl.d/50-kubernetes.conf <<EOF net.ipv4.ip_forward=1 net.bridge.bridge-nf-call-iptables=1 net.bridge.bridge-nf-call-ip6tables=1 fs.inotify.max_user_watches=525000 fs.may_detach_mounts = 1 net.ipv4.conf.all.route_localnet = 1 vm.overcommit_memory=1 vm.panic_on_oom=0 fs.file-max=52706963 fs.nr_open=52706963 net.netfilter.nf_conntrack_max=2310720 net.ipv4.tcp_keepalive_time = 600 net.ipv4.tcp_keepalive_probes = 3 net.ipv4.tcp_keepalive_intvl =15 net.ipv4.tcp_max_tw_buckets = 36000 net.ipv4.tcp_tw_reuse = 1 net.ipv4.tcp_max_orphans = 327680 net.ipv4.tcp_orphan_retries = 3 net.ipv4.tcp_syncookies = 1 net.ipv4.tcp_max_syn_backlog = 16384 net.ipv4.ip_conntrack_max = 65536 net.ipv4.tcp_max_syn_backlog = 16384 net.ipv4.tcp_timestamps = 0 net.core.somaxconn = 16384 EOF
上面修改的两个文件及时生效：
systemctl enable --now systemd-modules-load.service sysctl -p
最好是重启一哈服务器，然后查看内核，确认lvs都开启了：
[root@slave1 cfg]# !185 lsmod | grep ip_vs ip_vs_sed 16384 0 ip_vs_nq 16384 0 ip_vs_fo 16384 0 ip_vs_sh 16384 0 ip_vs_dh 16384 0 ip_vs_lblcr 16384 0 ip_vs_lblc 16384 0 ip_vs_wrr 16384 0 ip_vs_rr 16384 3 ip_vs_wlc 16384 0 ip_vs_lc 16384 0 ip_vs 159744 25 ip_vs_wlc,ip_vs_rr,ip_vs_dh,ip_vs_lblcr,ip_vs_sh,ip_vs_fo,ip_vs_nq,ip_vs_lblc,ip_vs_wrr,ip_vs_lc,ip_vs_sed nf_conntrack 155648 5 xt_conntrack,nf_nat,nf_conntrack_netlink,xt_MASQUERADE,ip_vs nf_defrag_ipv6 24576 2 nf_conntrack,ip_vs libcrc32c 16384 4 nf_conntrack,nf_nat,xfs,ip_vs
四，
修改kube-proxy的配置文件
二进制方式安装部署的集群：
最后加一段mode: "ipvs"即可，如果想修改lvs的算法，scheduler: "" 这里是lvs的调度算法，默认是rr，当然也可以改成wrr或者sh等等其它算法，看自己需要啦。
[root@slave1 cfg]# cat kube-proxy-config.yml kind: KubeProxyConfiguration apiVersion: kubeproxy.config.k8s.io/v1alpha1 bindAddress: 0.0.0.0 metricsBindAddress: 0.0.0.0:10249 clientConnection: kubeconfig: /opt/kubernetes/cfg/kube-proxy.kubeconfig hostnameOverride: k8s-node1 clusterCIDR: 10.0.0.0/24 mode: "ipvs" ipvs: excludeCIDRs: null minSyncPeriod: 0s scheduler: "wrr" strictARP: false syncPeriod: 0s tcpFinTimeout: 0s tcpTimeout: 0s udpTimeout: 0s
然后重启服务：
systemctl restart kube-proxy
此时的网络状态：
[root@master cfg]# k get svc -A NAMESPACE NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE default kubernetes ClusterIP 10.0.0.1 <none> 443/TCP 30d kube-system coredns ClusterIP 10.0.0.2 <none> 53/UDP,53/TCP 29d
多了一个kube-pivs0网卡，现有多少个service都写上面了。
[root@slave1 cfg]# ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: ens33: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000 link/ether 00:0c:29:e9:9e:89 brd ff:ff:ff:ff:ff:ff inet 192.168.217.17/24 brd 192.168.217.255 scope global ens33 valid_lft forever preferred_lft forever inet6 fe80::20c:29ff:fee9:9e89/64 scope link valid_lft forever preferred_lft forever 3: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN link/ether 02:42:fa:3e:c9:3f brd ff:ff:ff:ff:ff:ff inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0 valid_lft forever preferred_lft forever 4: dummy0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN qlen 1000 link/ether e2:7b:0c:50:67:28 brd ff:ff:ff:ff:ff:ff 5: kube-ipvs0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN link/ether 4a:05:45:0b:b0:bc brd ff:ff:ff:ff:ff:ff inet 10.0.0.1/32 brd 10.0.0.1 scope global kube-ipvs0 valid_lft forever preferred_lft forever inet 10.0.0.2/32 brd 10.0.0.2 scope global kube-ipvs0 valid_lft forever preferred_lft forever
查看一哈日志：
这个时候的日志告诉我们，ipvs调度模式（也叫做算法）没有指定，因此，使用的轮询rr模式作为默认，OK，这样就已经基本可以满足大集群的使用了。
[root@slave1 cfg]# cat ../logs/kube-proxy.slave1.root.log.WARNING.20220926-102105.4110 Log file created at: 2022/09/26 10:21:05 Running on machine: slave1 Binary: Built with gc go1.13.9 for linux/amd64 Log line format: [IWEF]mmdd hh:mm:ss.uuuuuu threadid file:line] msg W0926 10:21:05.426300 4110 proxier.go:429] IPVS scheduler not specified, use rr by default
cat kube-proxy.INFO ipvs相关日志：
I0926 13:06:32.992903 14326 server_others.go:259] Using ipvs Proxier. I0926 13:06:32.993480 14326 proxier.go:426] nodeIP: 192.168.217.17, isIPv6: false I0926 13:06:32.993907 14326 server.go:583] Version: v1.18.3 I0926 13:06:32.994533 14326 conntrack.go:52] Setting nf_conntrack_max to 262144
kubeadm方式部署的集群：
scheduler: "" 这里是lvs的调度算法，默认是rr，当然也可以改成wrr或者sh等等其它算法，看自己需要啦。
kubectl edit configmap kube-proxy -n kube-system ipvs: excludeCIDRs: null minSyncPeriod: 0s scheduler: "" strictARP: false syncPeriod: 0s tcpFinTimeout: 0s tcpTimeout: 0s udpTimeout: 0s kind: KubeProxyConfiguration metricsBindAddress: "" mode: "ipvs" #修改此处 nodePortAddresses: null
然后删除kube-proxy相关的pod以重启pod即可：
kubectl get pod -n kube-system kubectl delete pod kube-proxy-5ntj4 kube-proxy-82dk4 kube-proxy-s9jrw -n kube-system
查看pod日志，日志出现Using ipvs Proxier即可
确认是否成功操作，如下，列出了service的IP即为正确（当然，算法也列出来了，具体算法百度即可。）：
[root@slave1 cfg]# ipvsadm -Ln IP Virtual Server version 1.2.1 (size=4096) Prot LocalAddress:Port Scheduler Flags -> RemoteAddress:Port Forward Weight ActiveConn InActConn TCP 10.0.0.1:443 rr -> 192.168.217.16:6443 Masq 1 0 0 TCP 10.0.0.2:53 rr -> 10.244.0.22:53 Masq 1 0 0 UDP 10.0.0.2:53 rr -> 10.244.0.22:53 Masq 1 0 0
OK，kubernetes集群启用ipvs（lvs）就成功了，别忘记了，所有的kube-proxy都要修改的哦，如果是二进制安装的话。
安装完ipvs后的一个错误解决：云原生|kubernetes|解决kube-proxy报错：Not using `--random-fully` in the MASQUERADE rule for iptables_zsk_john的博客-CSDN博客
也就是升级一哈iptables（内核都升级了，ipvs相关的iptables也需要来一哈嘛）
最后，在kubernetes之前的版本中，需要通过设置特性开关SupportIPVSProxyMode来使用IPVS。在kubernetes v1.10版本中，特性开关SupportIPVSProxyMode默认开启，在1.11版本中该特性开关已经被移除。但是如果您使用kubernetes 1.10之前的版本，需要通过--feature-gates=SupportIPVSProxyMode=true开启SupportIPVSProxyMode才能正常使用IPVS
