kube-proxy ipvs模式分析

负载均衡资源

k8s的核心功能就是基于POD的多副本实现负载均衡,负载基于所有的节点或者master节点(功能是kube-proxy提供)

三种模式(默认为iptables)

  • userspace :由node节点随机端口,任何连接到“代理端口”的请求,都会被代理到 Service 的backend Pods 中的某个上面(实际是根据Endpoints中)
  • iptables 代理模式:通过API Server的Watch接口实时跟踪Service与Endpoint的变更信息,并更新对应的iptables规则,Client的请求流量则通过iptables的NAT机制“直接路由”到目标Pod
  • ipvs 代理模式:类似iptables规则,在IPVS模式下,使用iptables的扩展ipset,而不是直接调用iptables来生成规则链。iptables规则链是一个线性的数据结构,ipset则引入了带索引的数据结构

Endpoints是可被访问的服务端点,即一个状态为running的pod,它是service访问的落点,外部不是直接访问的server而是通过Endpoints
在这里插入图片描述

iptables相比userspace 流程就少了一步建立连接,这里只要看iptables和ipvs区别

  1. 性能:iptables是线性增加规则,而ipvs是基于ipset集合实现恒定
  2. 健康检查:iptables本身无法做到健康检查,ipvs可以实现
  3. 调度算法:iptables基于随机算法,ipvs支持静态和动态算法(默认为RR)

开启k8s的ipvs功能

ipvs就是LVS,LVS支持三种模式,k8s是基于nat模式

  • VIP:调度器用于与客户端通信的IP地址
    • lvs本身vip是一台单独机器,而k8s是基于本地的kube-ipvs0接口
  • RIP:后端主机的用于与调度器通信的IP地址

配置k8s开启ipvs

cat >> /etc/sysctl.conf << EOF
net.ipv4.ip_forward = 1
net.bridge.bridge-nf-call-iptables = 1
net.bridge.bridge-nf-call-ip6tables = 1
EOF
sysctl -p
#net.ipv4.ip_forward对于ipvs是需要用转发

yum -y install ipvsadm  ipset
#安装客户端工具,一个看ipvs规则一个看ipset集合规则

modprobe -- ip_vs
modprobe -- ip_vs_rr
modprobe -- ip_vs_wrr
modprobe -- ip_vs_sh
modprobe -- nf_conntrack_ipv4
#验证内核是否支持ipvs的相关模块,网上很多说要永久加载,其实没必要的,模块会自动加载的,只要验证没问题即可

vi kube-proxy.conf 
--feature-gates=SupportIPVSProxyMode=true \
#开启ipvs支持

vi kube-proxy-config.yml
mode: ipvs
ipvs:
 scheduler: rr
#修改--config配置文件,开启ipvs及调度算法(可以配置其他,默认为rr)
#通过测试:如果配置了--config,配置信息都要在配置文件里,写到kube-proxy.conf无效,比如--proxy-mode=ipvs

curl localhost:10249/proxyMode
#查看当前模式

systemctl restart kube-proxy
systemctl status kube-proxy
#重启服务

–masquerade-all参数说明

看下官网说明:如果使用纯 iptables 代理,则对通过服务集群 IP 发送的所有流量进行 SNAT(通常不需要)

原因在于lvs的nat模式需要RIP需要制定VIR为网关
在这里插入图片描述

k8s中是无法实现的,所有就需要进行源nat,这样就无须需要网关,masquerade-all选项就是把server-IP做源nat,再进行目的nat,这样就无须网关,而这个功能其实已经被iptables打标签替代,所有才说通常不需要,而masquerade-all会隐藏CIP
在这里插入图片描述

可能理解不对,只是基于目前的资料验证,网上写的说明我是没怎么看懂

参考配置:kube-proxy.conf 点击访问
参考参数:kube-proxy-config点击访问

node-ip到pod访问分析

  • k8s都是基于自定义链,自定义链需要匹配默认的5个链规则才能生效(-j 跟的是动作就是操作动作,如果是自定义链就建立匹配)
  • nf_conntrack连接状态追踪是实现POD返回客户端的方式,因为进入已经允许,对于返回就没有必要再进行规则匹配
  • Ipset:iptables的扩展,它允许你创建 匹配整个地址集合的规则,通过hash结构存储,基于索引查找,大大提高查找效率
  • node-ip+端口:192.168.12.3:30303,CLUSTER-IP+端口:10.0.0.143:88

1、PREROUTING链匹配到自定义链 KUBE-SERVICES
在这里插入图片描述
2、入口流量引流到全局链KUBE-SERVICES中
在这里插入图片描述

来自源不是自身CLUSTER-IP的目的是KUBE-CLUSTER-IP进行打标签

KUBE-CLUSTER-IP
在这里插入图片描述
3、入口流量标签化处理
在这里插入图片描述
4、入口流量SNAT处理
在这里插入图片描述

ptables中POSTROUTING链最先将流量引流到KUBE-POSTROUTING中做进一步的SNAT处理

5、节点端口的转换
在这里插入图片描述

节点30303端口转换成88进入POD

KUBE-NODE-PORT-TCP
在这里插入图片描述

cluster-ip到pod访问也类似,区别在于cluster-ip是本机访问,所以要在OUTPUT这个链上来做匹配

nf_conntrack连接状态追踪回城路径
在这里插入图片描述

猜你喜欢

转载自blog.csdn.net/yangshihuz/article/details/112463242