kube-proxy 详解
前言
在kubernets集群的每个节点上都运行着kube-proxy进程,负责实现Kubernetes中service组件的虚拟IP服务。目前kube-proxy有如下三种工作模式:
- User space 模式
- iptables 模式
- IPVS 模式
User space模式
在这种模式下,kube-proxy通过观察Kubernetes中service和endpoint对象的变化,当有新的service创建时,所有节点的kube-proxy在node节点上随机选择一个端口,在iptables中追加一条把访问service的请求重定向到这个端口的记录,并开始监听这个端口的连接请求。
比如说创建一个service,对应的IP:1.2.3.4,port:8888,kube-proxy随机选择的端口是32890,则会在iptables中追加
-A PREROUTING -j KUBE-PORTALS-CONTAINER-A KUBE-PORTALS-CONTAINER -d 1.2.3.4/32 -p tcp --dport 8888 -j REDIRECT --to-ports 32890
KUBE-PORTALS-CONTAINER 是kube-proxy在iptable中创建的规则链,在PREROUTING阶段执行
执行过程:
- 当有请求访问service时,在PREROUTING阶段,将请求jumpKUBE-PORTALS-CONTAINER
- KUBE-PORTALS-CONTAINER中的这条记录起作用,把请求重定向到kube-proxy刚监听的端口32890上,数据包进入kube-proxy进程内,
- 然后kube-proxy会从这个service对应的endpoint中根据SessionAffinity来选择一个作为真实服务响应请求。
这种模式的缺点就是,请求数据需要到kube-proxy中,就是用户空间中,才能决定真正要转发的实际服务地址,性能会有损耗。并且在应用执行过程中,kube-proxy的可用性也会影响系统的稳定
iptables 模式(目前kube-proxy默认的工作模式)
在这种模式下,kube-proxy通过观察Kubernetes中service和endpoint对象的变化,当有servcie创建时,kube-proxy在iptables中追加新的规则。对于service的每一个endpoint,会在iptables中追加一条规则,设定动作为DNAT,将目的地址设置成真正提供服务的pod地址;再为servcie追加规则,设定动作为跳转到对应的endpoint的规则上,
默认情况下,kube-proxy随机选择一个后端的服务,可以通过iptables中的 -m recent 模块实现session affinity功能,通过 -m statistic 模块实现负载均衡时的权重功能
比如说创建了一个service,对应的IP:1.2.3.4,port:8888,对应一个后端地址:10.1.0.8:8080,则会在iptables中追加(主要规则):
-A PREROUTING -j KUBE-SERVICES-A KUBE-SERVICES -d 1.2.3.4/32 -p tcp –dport 8888 -j KUBE-SVC-XXXXXXXXXXXXXXXX-A KUBE-SVC-XXXXXXXXXXXXXXXX -j KUBE-SEP-XXXXXXXXXXXXXXXX-A KUBE-SEP-XXXXXXXXXXXXXXXX -p tcp -j DNAT –to-destination 10.1.0.8:8080
KUBE-SERVICES 是kube-proxy在iptable中创建的规则链,在PREROUTING阶段执行
执行过程:
- 当请求访问service时,iptables在prerouting阶段,将讲求jump到KUBE-SERVICES,
- 在KUBE-SERVICES 中匹配到上面的第一条准则,继续jump到KUBE-SVC-XXXXXXXXXXXXXXXX,
- 根据这条准则jump到KUBE-SEP-XXXXXXXXXXXXXXXX,
- 在KUBE-SEP-XXXXXXXXXXXXXXXX规则中经过DNAT动做,访问真正的pod地址10.1.0.8:8080。
在这种逻辑下,数据转发都在系统内核层面做,提升了性能,并且即便kube-proxy不工作了,已经创建好的服务还能正常工作 。但是在这种模式下,如果选中的第一个pod不能响应,请求就会失败,不能像userspace模式,请求失败后kube-proxy还能对其他endpoint进行重试。
这就要求我们的应用(pod)要提供readiness probes功能,来验证后端服务是否能正常提供服务,kube-proxy只会将readiness probes测试通过的pod写入到iptables规则中,以此来避免将请求转发到不正常的后端服务中。
IPVS 模式
介绍
由于在iptables模式中,kube-proxy需要为每一个服务,每一个endpoint都生成相应的iptables规则,当服务规模很大时,性能也将显著下降,因此kubernetes在1.8引入了IPVS模式,1.9版本中变成beta,在1.11版本中成为GA。在IPVS模式下,kube-proxy观察Kubernetes中service和endpoint对象的变化,通过调用netlink接口创建相应的IPVS规则,并周期性的对Kubernetes的service、endpoint和IPVS规则进行同步,当访问一个service时,IPVS负责选择一个真实的后端提供服务。
IPVS模式也是基于netfilter的hook功能(INPUT阶段),这点和iptables模式是一样的,但是用的是内核工作空间的hash表作为存储的数据结构,在这种模式下,iptables可通过ipset来验证具体请求是否满足某条规则。在service变成时,只用更新ipset中的记录,不用改变iptables的规则链,因此可以保证iptables中的规则不会随着服务的增加变多,在超大规模服务集群的情况下提供一致的性能效果。
在对规则进行同步时的性能也要高于iptables(只用对特定的一个hash表进行更新,而不是像iptables模式下对整个规则表进行操作),所以能提供更高的网络流量。
IPVS在对后端服务的选择上也提供了更多灵活的算法:
- rr: round-robin
- lc: least connection (最少连接数算法)
- dh: destination hashing(目的hash算法)
- sh: source hashing(原地址hash算法)
- sed: shortest expected delay(最短延迟算法)
- nq: never queue
kube-proxy启用IPVS
由于IPVS的优势,所以尽可能的采用IPVS作为kube-proxy的工作模式,通过以下步骤在创建集群时启用IPVS
安装依赖工具包
apt install -y ipvsadm ipset
- ipset是IPVS工作时会用刀的工具包
- ipvsadm 是一个客户端工具,可以让我们和ipvs表的数据进行交互
kube-proxy启用IPVS时依赖模块:
ip_vs ip_vs_rr ip_vs_wrr ip_vs_sh nf_conntrack
可通过如下命令检查系统是否启用了这些模块
$ lsmod | grep -e ip_vs -e nf_conntrack
如果没有启用,通过如下命令启用
$ modprobe -- ip_vs $ modprobe -- ip_vs_rr $ modprobe -- ip_vs_wrr $ modprobe -- ip_vs_sh $ modprobe -- nf_conntrack
kube-proxy配置文件中追加IPVS相关配置
proxy-mode: "ipvs" ipvs-min-sync-period: ipvs 规则刷新的最小时间间隔 ipvs-scheduler: ipvs的负载算法(rr、lc等) ipvs-sync-period: ipvs规则刷新的最大时间间隔(30s)
采用用IPVS模式时,在启动kube-proxy前必须要确保IPVS模块在服务上存在,如果kube-proxy启动时,经过验证发现IPVS模块不可用,kube-proxy自动采用iptables模式工作,参考代码:server_others.go
在介绍kube-proxy如何使用IPVS实现对service的请求前,先看下IPVS的简单介绍及工作原理
IPVS
介绍
IPVS是Linux服务器中用来实现LVS(Linux virtual service)的一个模块,工作在内核空间是一种基于虚拟IP的负载均衡技术,通过用户空间的ipvsadm来执行规则制定,常见术语名称 解释 RS Real Server 后端请求处理服务器 CIP Client IP,客户端IP VIP Director Virtual IP,负载均衡器虚拟IP DIP Director IP,负载均衡器IP RIP Real Server IP,后端处理请求的真实服务器IP 工作原理
因为IPVS是hook到netfilter的input链中执行的,所以需要先了解下数据在netfilter中的流转过程
正常流程:
- 数据进入内核空间,到达PreRouting
- 进行路由决策
- 请求是发往本机的进入input
- 进入用户空间处理
- 处理完进入output
- 进入postrouting
- 发送出去
- 请求不是本机的,进入forward
- 进入postrouting
- 发送出去
加入IPVS后的简化逻辑图
- 请求到达负载均衡器的内核空间时,到达PREROUTING链
- 当内核根据路由决策发现地址是本机时,将数据包送往INPUT链
- 数据包到达INPUT链时,首先会被IPVS检查,如果请求的目的地址、端口信息不在自己的hash表中时,数据正常发往用户空间处理
- 如果hash表中的规则匹配到请求记录,依据IPVS的工作模式,对请求头中的信息进行修改,之后直接交由POSTROUTING链执行
- POSTROUTING根据IPVS修改后的请求头信息(此时目的地址是真实的服务地址),通过路由表,用正确的设备将请求转发出去
可以看到,当IPVS模块工作后,在input链上会再次对请求做匹配,匹配到的直接做postrouting,不再进入用户空间处理,而是把请求发送到IPVS选中的提供真实服务的服务器
IPVS有三种工作模式NAT(Masq)、DR、TUN,因为kube-proxy采用的是NAT模式,所以下面只对NAT模式进行分析
NAT:Network Address Transition(网络地址转换),工作在此模式下的IPVS,首先根据scheduler策略选择一个真实的后端服务,接着将请求头中的目的地址IP、端口转换成真实服务的IP和端口,之后进入POSTROUTING,向真实的服务器发起请求。当响应数据返回时,再通过masqreade,将返回数据的源地址修改成虚拟服务器的地址,具有有如下特性:
Real Server应该使用私有ip地址,和client IP不在一个网段中(如果在一个网段中,real Server可以将数据直接返回客户端,不会再经过Director Server返回)
一般Real Server的网关应该指向DIP,不然的话无法保证响应报文经过Director Server(IP 协议,数据发送给不在同一个网段的服务器时,会把数据发送给网关)
RIP要和DIP应该在同一网段内
进出的报文,无论请求还是响应都要经过Directory server(满足上面三点,这个是自然而然的)
支持端口映射
Real Server可以使用任意系统,只要端口对应即可
其流程如下:
当用户请求到达DirectorServer,此时请求的数据报文会先到内核空间的PREROUTING链。 此时报文的源IP为CIP,目标IP为VIP 。
PREROUTING检查发现数据包的目标IP是本机,将数据包送至INPUT链。
IPVS比对数据包请求的服务是否为集群服务,若是,修改数据包的目标IP地址为后端服务器IP,然后将数据包发至POSTROUTING链。 此时报文的源IP为CIP,目标IP为RIP ,在这个过程完成了目标IP的转换。
POSTROUTING链通过选路,将数据包发送给Real Server。
Real Server比对发现目标为自己的IP,开始构建响应报文。 此时报文的源IP为RIP,目标IP为CIP 。
因为Real Server的网关指向DIP,并且通常情况下CIP和RIP不在同一个网段内,在这种情况下,Real Server会先将数据发送给Director Server(网关),这样数据就可以沿原路返回。
Director Server在响应客户端前,此时会将源IP地址修改为自己的VIP地址,然后响应给客户端。 此时报文的源IP为VIP,目标IP为CIP。
在此过程中CIP一直是不发生变化的
kube-proxy如何使用IPVS
从IPVS的工作原理上可以知道,kube-proxy想使用IPVS,需要完成以下几个工作
- 需要路由决策判断要访问的service的VIP属于本机,否则,数据不经过input,直接forward出去,IPVS就没有机会工作了
- iptables中的规则需要允许对service请求通过,否则数据被过滤掉也不会经过IPVS
- IPVS要能够判断出访问的service服务是属于集群服务
- IPVS要能够根据service服务对应的VIP,找到真实的服务,之后修改请求头,向真实的服务发送请求
- 由于在kubernetes下工作的IPVS,不一定满足经典的NAT模式的特性,所以数据返回路径不一定和请求路径一致,会出现Real Server直接返回数据给客户端的情况
为了让node节点识别对应的VIP,kube-proxy启动时创建了一个虚拟网络设备kube-ipvs0,类型是dummy,并把service的VIP都设置到这个设备下面。创建这个设备,以及向设备中追加VIP的逻辑都在代码proxier.go中
$ ip addr 27: kube-ipvs0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN group default link/ether ba:6b:cb:b9:61:89 brd ff:ff:ff:ff:ff:ff inet 10.254.0.1/32 brd 10.254.0.1 scope global kube-ipvs0valid_lft forever preferred_lft forever inet 10.254.0.2/32 brd 10.254.0.2 scope global kube-ipvs0valid_lft forever preferred_lft forever inet 10.254.199.160/32 brd 10.254.199.160 scope global kube-ipvs0valid_lft forever preferred_lft forever
对应的service
$ kubectl get svc -A NAMESPACE NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE default clientip ClusterIP 10.254.199.160 <none> 8080/TCP 23h default kubernetes ClusterIP 10.254.0.1 <none> 443/TCP 25d kube-system kube-dns ClusterIP 10.254.0.2 <none> 53/UDP,53/TCP,9153/TCP 23d kube-system kubelet ClusterIP None <none> 10250/TCP 18d
可以看到所有的VIP都在kube-ipvs0这个设备下面
为了让iptables中的规则允许对Servcie的请求通过,kube-proxy在iptables中追加了如下几条主要规则(iptables.masqueradeAll=false;clusterCIDR=172.30.0.0/16,clusterCIDR就是集群中的pod能分配的IP地址段):
NAT表中:
$ iptables -t nat -nLChain PREROUTING (policy ACCEPT) target prot opt source destination KUBE-SERVICES all -- 0.0.0.0/0 0.0.0.0/0 /* kubernetes service portals */Chain OUTPUT (policy ACCEPT) target prot opt source destination KUBE-SERVICES all -- 0.0.0.0/0 0.0.0.0/0 /* kubernetes service portals */Chain POSTROUTING (policy ACCEPT) target prot opt source destination KUBE-POSTROUTING all -- 0.0.0.0/0 0.0.0.0/0 /* kubernetes postrouting rules */Chain KUBE-MARK-MASQ (3 references) target prot opt source destination MARK all -- 0.0.0.0/0 0.0.0.0/0 MARK or 0x4000Chain KUBE-POSTROUTING (1 references) target prot opt source destination MASQUERADE all -- 0.0.0.0/0 0.0.0.0/0 /* kubernetes service traffic requiring SNAT */ mark match 0x4000/0x4000 MASQUERADE all -- 0.0.0.0/0 0.0.0.0/0 match-set KUBE-LOOP-BACK dst,dst,srcChain KUBE-SERVICES (2 references) target prot opt source destination KUBE-MARK-MASQ all -- !172.30.0.0/16 0.0.0.0/0 match-set KUBE-CLUSTER-IP dst,dst ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 match-set KUBE-CLUSTER-IP dst,dst
有两点需要解释下
关于规则
KUBE-MARK-MASQ all -- !172.30.0.0/16 0.0.0.0/0 match-set KUBE-CLUSTER-IP dst,dst
意思是对于非集群内的pod访问集群的cluster IP时会执行masquerade,这是因为在kube-proxy的启动条件设置成了iptables.masqueradeAll=false;clusterCIDR=172.30.0.0/16才这样
如果设置成iptables.masqueradeAll=false;clusterCIDR=,即不设置CIDR规则会变成
KUBE-MARK-MASQ all -- 0.0.0.0/0 0.0.0.0/0 match-set KUBE-CLUSTER-IP src,dst
效果应该是对自己访问自己的请求做masquerade,其他请求都不做
如果iptables.masqueradeAll=true,规则变成
KUBE-MARK-MASQ all -- 0.0.0.0/0 0.0.0.0/0 match-set KUBE-CLUSTER-IP dst,dst
效果对所有请求都做masquerade
关于匹配语法 -m set --match-set 。。。 代表用set模块的对请求进行匹配
语法如下:
-m set --match-set name flags
具体传入的flags要依据 name指定的set的类型来传入,具体ipset的用法可通过如下命令查看
ipset --help
这里以KUBE-CLUSTER-IP为例
$ ipset --list KUBE-CLUSTER-IP Name: KUBE-CLUSTER-IP Type: hash:ip,port Revision: 5 Header: family inet hashsize 1024 maxelem 65536 Size in memory: 408 References: 2 Number of entries: 5 Members: 10.254.0.2,udp:53 10.254.0.1,tcp:443 10.254.0.2,tcp:9153 10.254.199.160,tcp:8080 10.254.0.2,tcp:53
对应的类型信息:Type: hash:ip,port
结合前面的规则
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 match-set KUBE-CLUSTER-IP dst,dst
表述的意思是请求的目的地址IP、目的端口和KUBE-CLUSTER-IP中的Members有匹配时,就接收请求
filter表中
$ iptables -nL -t filter Chain FORWARD (policy ACCEPT) target prot opt source destination KUBE-FORWARD all -- 0.0.0.0/0 0.0.0.0/0 /* kubernetes forwarding rules */Chain OUTPUT (policy ACCEPT) target prot opt source destination KUBE-FIREWALL all -- 0.0.0.0/0 0.0.0.0/0Chain KUBE-FIREWALL (2 references) target prot opt source destination DROP all -- 0.0.0.0/0 0.0.0.0/0 /* kubernetes firewall for dropping marked packets */ mark match 0x8000/0x8000Chain KUBE-FORWARD (1 references) target prot opt source destination ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 /* kubernetes forwarding rules */ mark match 0x4000/0x4000 ACCEPT all -- 172.30.0.0/16 0.0.0.0/0 /* kubernetes forwarding conntrack pod source rule */ ctstate RELATED,ESTABLISHED ACCEPT all -- 0.0.0.0/0 172.30.0.0/16 /* kubernetes forwarding conntrack pod destination rule */ ctstate RELATED,ESTABLISHED
通过分析kube-proxy追加的这些规则,可以看到访问service提供的服务时,iptables中的规则最终都会允许请求通过,并且通过 -m set --match-set 的规则匹配机制,kube-proxy不用随着servcie的创建和销毁来修改iptables中的规则,只用修改对应的ipset中相应的Members就能够达到效果,保证iptables的规则表固定大小,实现大规模服务集群中保持性能的稳定
请求通过了iptables中的规则后,在INPUT阶段,需要IPVS来对请求进行判断,看请求的服务是否属于集群服务,是的话还要能找出正确的真实服务地址,这个kube-proxy如何实现呢
kube-proxy通过监听API server,当有service创建时,通过调用系统的netlink 接口,将service和对应的endpoint插入到IPVS对应的hash表中,对应代码在proxier.go中,用户可以通过ipvsadm工具查看ipvs hash表中的数据
$ ipvsadm --list IP Virtual Server version 1.2.1 (size=4096) Prot LocalAddress:Port Scheduler Flags-> RemoteAddress:Port Forward Weight ActiveConn InActConn TCP promote.cache-dns.local:http rr-> master:6443 Masq 1 1 0 TCP promote.cache-dns.local:doma rr-> 172.30.78.2:domain Masq 1 0 0 TCP promote.cache-dns.local:9153 rr-> 172.30.78.2:9153 Masq 1 0 0 TCP promote.cache-dns.local:http rr-> 172.30.22.4:http-alt Masq 1 0 0-> 172.30.78.4:http-alt Masq 1 0 0 UDP promote.cache-dns.local:doma rr-> 172.30.78.2:domain Masq 1 0 0
因为启用了DNS的cache功能,所以这个地方看到的service信息是DNS缓存信息
通过上述几个步骤后,kube-proxy就把需要使用IPVS的依赖条件都实现,就可以在请求到来时利用IPVS机制对请求进行转发了。
kube-proxy 详解相关推荐
- Spring AOP 的proxy详解
spring 提供了多种不同的方案实现对 bean 的 aop proxy, 包括 ProxyFactoryBean, 便利的 TransactionProxyFactoryBean 以及 AutoP ...
- nginx proxy 详解,代理路径的转发
1.proxy_pass 为urL时,没有/,视为相对路径,则会把匹配的路径部分给代理走,即会添加上这段匹配location的uri. server {listen 80;server_name lo ...
- centos 安装mysql-proxy_详解在Centos 5.2下安装最新Mysql Proxy LUA教程
在Centos 5.2下安装***Mysql Proxy LUA教程是本文要介绍的内容,主要是来了解Mysql Proxy LUA的安装过程,文章中有很详细的讲解,具体内容来看本文详解. mysql ...
- Proxy和Reflect内容详解
ES6中的Proxy和Reflect内容详解 监听对象的操作 我们先来看一个需求:有一个对象,我们希望监听这个对象中的属性被设置或获取的过程 通过我们前面所学的知识,能不能做到这一点呢? 其实是可以的 ...
- Proxy和Reflect详解
Proxy和Reflect详解 之前一直没有理解proxy代理是啥意思,只是感觉很深奥的样子,最近正好在研究vue3的响应式原理,发现vue3是使用proxy完成响应式的,因此仔细的研究了一下prox ...
- 基于Kubernetes构建Docker集群管理详解
from: 基于Kubernetes构建Docker集群管理详解 Kubernetes是Google开源的容器集群管理系统,基于Docker构建一个容器的调度服务,提供资源调度.均衡容灾.服务注册.动 ...
- Istio 中的 Sidecar 注入及透明流量劫持过程详解
图片来源:上海五角场 by Jimmy Song 本文基于 Istio 1.5.1 版本,将为大家介绍以下内容: 什么是 sidecar 模式和它的优势在哪里. Istio 中是如何做 sidecar ...
- kubectl常用命令大全详解
文章目录 说明 基础命令详解:create.delete.get.run.expose.set.explain.edit create 命令:根据文件或者输入来创建资源 创建Deployment和Se ...
- 详解 K8S 高可用部署,超详细
一.前言 二.基础环境部署 1)前期准备(所有节点) 2)安装容器 docker(所有节点) 3)配置 k8s yum 源(所有节点) 4)将 sandbox_image 镜像源设置为阿里云 goog ...
- HTTP协议详解(真的很经典)
转自:http://blog.csdn.net/gueter/archive/2007/03/08/1524447.aspx Author :Jeffrey 引言 HTTP是一个属于应用层的面向对象的 ...
最新文章
- 一年参加一次就够,全新升级的AI开发者大会议程出炉!
- forward declaration of class 错误
- abap如何找屏幕增强_因增强导致BDC录屏执行异常的梗
- SAP上线前数据重置方式总结
- 监控主机安装需要材料
- [译]WPF开源控件扩展库ControlzEx
- 数据结构和算法练习网站_视频和练习介绍了10种常见数据结构
- utf8编码为什么这么普遍,优势在哪里?
- Oracle 技术集锦
- 【玩转Atlas200DK系列】为Atlas200DK配置wifi外挂模块
- 计算机工作过程中 电压应稳定在,计算机组装与维修前三章测评卷.doc
- Java——自定义图片和居中
- 枚举类(Enumerated types)介绍
- 如何查看windows的CUDA版本
- Chrome 浏览器关闭第三方Cookie会导致内嵌的哔哩哔哩视频无法加载
- ps中给图片加文字不显示解决办法
- php shopex,shopex官网 用PHP为SHOPEX增加日志功能代码
- 服务器usb驱动安装系统安装失败怎么办,USB3.0驱动无法安装失败怎么办?USB驱动失败失败的解决方法...
- 2021.4.14 html学习第二天
- 流行编曲(5)采样、小打、Pad、声场