前言：

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: nullminSyncPeriod: 0sscheduler: "wrr"strictARP: falsesyncPeriod: 0stcpFinTimeout: 0stcpTimeout: 0sudpTimeout: 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 1000link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00inet 127.0.0.1/8 scope host lovalid_lft forever preferred_lft foreverinet6 ::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 1000link/ether 00:0c:29:e9:9e:89 brd ff:ff:ff:ff:ff:ffinet 192.168.217.17/24 brd 192.168.217.255 scope global ens33valid_lft forever preferred_lft foreverinet6 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:ffinet 172.17.0.1/16 brd 172.17.255.255 scope global docker0valid_lft forever preferred_lft forever
4: dummy0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN qlen 1000link/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:ffinet 10.0.0.1/32 brd 10.0.0.1 scope global kube-ipvs0valid_lft forever preferred_lft foreverinet 10.0.0.2/32 brd 10.0.0.2 scope global kube-ipvs0valid_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-systemipvs:excludeCIDRs: nullminSyncPeriod: 0sscheduler: ""strictARP: falsesyncPeriod: 0stcpFinTimeout: 0stcpTimeout: 0sudpTimeout: 0skind: KubeProxyConfigurationmetricsBindAddress: ""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

云原生|kubernetes|集群网络优化之启用ipvs相关推荐

云原生|kubernetes|网络插件flannel二进制部署和calico的yaml清单部署总结版
前言: 前面写了一些关于calico的文章,但感觉好像是浅尝辄止,分散在了几篇文章内,并且很多地方还是没有说的太清楚云原生|kubernetes|kubernetes的网络插件calico和flann ...
腾讯云EMR基于YARN针对云原生容器化的优化与实践
导语 | 传统HADOOP生态系统使用YARN管理/调度计算资源,该系统⼀般具有明显的资源使⽤周期.实时计算集群资源消耗主要在⽩天,而数据报表型业务则安排在离线计算集群中.离在线业务分开部署的首要问题 ...
【云原生 | Kubernetes 系列】---Skywalking部署和监控
[云原生 | Kubernetes 系列]-Skywalking部署和监控 1. 分布式链路追踪概念在较大的web集群和微服务环境中,客户端的一次请求可能需要经过多个不同的模块,多个不同中间件,多个 ...
【云原生 | Kubernetes 实战】18、K8s 安全实战篇之 RBAC 认证授权（上）
目录一.k8s 安全管理:认证.授权.准入控制概述 1.1 认证认证基本介绍授权基本介绍准入控制基本介绍为什么需要准入控制器呢? k8s 客户端访问 apiserver 的几种认证方式 ku ...
【云原生 | Kubernetes 实战】18、K8s 安全实战篇之 RBAC 认证授权（下）
目录一.常见角色(role)授权的案例 1.1 允许读取核心 API 组的 Pod 资源 1.2 允许读写 apps API 组中的 deployment 资源 1.3 允许读取 Pod 以及读写 ...
【云原生Kubernetes系列第五篇】kubeadm v1.20 部署K8S 集群架构（人生这道选择题，总会有遗憾）
系列文章目录 ??即日起,更新云原生相关知识,喜欢的小伙伴可以给我点个三连喔 ??收录至专栏云原生 ??[云原生Docker系列第一篇]Docker镜像管理 ??[云原生Docker系列第二篇]Do ...
【云原生 | Kubernetes 实战】01、K8s-v1.25集群搭建和部署基于网页的 K8s 用户界面 Dashboard
目录一.K8s 概述可以查看官方文档:概述 | Kubernetes 组件交互逻辑: 二.kubeadm 安装 K8s-v1.25高可用集群 k8s 环境规划: 1.初始化环境 2.安装 Dock ...
【云原生 · Kubernetes】部署Kubernetes集群
[云原生 · Kubernetes]搭建Harbor仓库接着上次的内容,后续来了! 在master节点执行脚本k8s_master_install.sh即可完成K8S集群的部署,具体步骤参考如下(1 ...
云原生|kubernetes|多集群管理之kubeconfig文件配置和使用（定义，使用方法，合并管理多集群）
前言: kubernetes集群通常并不是只有一个集群,特别是对于业务量比较多的公司来说,可能集群的规模会非常大.所有的业务都放到一个kubernetes集群内是不现实的,也不是科学的,就如同你不会把 ...

云原生|kubernetes|集群网络优化之启用ipvs

前言：