前言：
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
上面修改的两个文件及时生效：
1. systemctl enable --now systemd-modules-load.service 2. 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
