学到这里,我们都知道,k8s集群的外部网络分发,借助kube-proxy组件来完成;
问题:我们为什么要将代理模式修改为ipvs而不继续使用iptables呐?
因为:
1,iptables底层使用四表五链完成网络代理,效率比较低,而ipvs是采用了iphash的方式实现代理的,效率比较高,因此才会采用ipvs作为生产环境中的网络代理;
2,iptables不太适合【读】,可读性太低,很乱;
[root@k8s231 ingress]# kubectl get pods -n kube-system -o wide
通过查看kube-proxy的日志,我们就知道了我们正在使用iptables还是ipvs为代理模式了;
[root@k8s231 ingress]# kubectl logs -n kube-system kube-proxy-nbt6h
[root@k8s231 ingress]# kubectl get svc
[root@k8s231 ingress]# iptables-save | grep 10.200.11.39
[root@k8s231 ingress]# iptables-save | grep KUBE-SVC-CL34MMSZRUFQFSPM
[root@k8s231 ingress]# iptables-save | grep KUBE-SEP-YLLYZD7DXDNDFOFC
通过一层一层的路由查询,我们就知道了目标地址的终点ip是什么;
从k8s的1.11版本之后,支持iptables和ipvs两种模式,如果ipvs没有开启,则自动降级为iptables。
[root@k8s231 ingress]# kubectl -n kube-system get pods kube-proxy-nbt6h -o yaml
可以看到有一个cm资源
查看这个cm资源
[root@k8s231 ingress]# kubectl describe cm -n kube-system kube-proxy
发现“”里面什么都没写,就代表是默认的iptables
yum -y install conntrack-tools ipvsadm.x86_64
cat > /etc/sysconfig/modules/ipvs.modules <
#!/bin/bash modprobe -- ip_vs
modprobe -- ip_vs_rr
modprobe -- ip_vs_wrr
modprobe -- ip_vs_sh
modprobe -- nf_conntrack_ipv4
EOF
chmod 755 /etc/sysconfig/modules/ipvs.modules && bash /etc/sysconfig/modules/ipvs.modules && lsmod | grep -e ip_vs -e nf_conntrack_ipv4
修改cm资源(kube-proxy)
[root@k8s231 ~]# kubectl -n kube-system edit cm kube-proxy
切记,【i/a】修改后,要保存退出【:wq】
删除后会重新拉起,然后就修改成功了
[root@k8s231 ~]# kubectl get pods -n kube-system | grep kube-proxy | awk '{print $1}' | xargs kubectl -n kube-system delete pods
等待重新拉起pod
[root@k8s231 ~]# kubectl logs -n kube-system kube-proxy--4hjgr
[root@k8s231 ~]# ipvsadm -ln | grep 10.200.0.1 -A 5
至此,咱们iptable升级ipvs的代理模式修改就学习完毕了;