【独家】K8S漏洞报告 | 近期bug fix解读&1.9.11主要bug fix汇总

*内容提要:

1. Kube-proxy长连接优雅断开机制及IPVS模式实现

2. 10/29--11/19 bug fix汇总分析

3. 1.9.11重要bug fix汇总

在本周的跟踪分析中,以1.11版本为例,共有9条bug fix,其中大部分是集群部署、第三方云提供商、测试相关的内容,与Kubernetes核心内容无关。而有一条Kube-proxy相关的bug fix比较重要,本文会作具体分析。

另外1.9版本已经停止维护,本周开始,将从1.9.11开始,持续更新1.9小版本的重要bug fix及简单分析,敬请关注。

1 bug fix解读

IPVS模式支持优雅删除

背景

IPVS模式是Kube-proxy的代理模式之一,Kube-proxy在1.9开始引入IPVS模式,1.11宣布该特性GA。关于IPVS模式的优势和具体介绍可以查看这篇文章:

基于IPVS的集群内负载均衡深入解读

IPVS模式得益于底层的底层的lvs,拥有高吞吐、低延时等诸多优势,同样也由于底层实现的差异,导致IPVS原生不能支持优雅删除。

Pod的优雅删除在kube-proxy层面是指,当pod删除时,外部与该pod不能创建新的网络链接,但是外部与该pod已经存在的长连接也不会被马上断掉。这样就允许pod内部的容器收到终止信号后主动发送断链请求,实现长连接正常断开。

问题分析

Kube-proxy的iptables和IPVS模式分别通过创建不同的规则实现流量service到后端实例的路由分发,其中iptables模式通过创建iptables规则实现,IPVS模式则是通过创建iptables规则和IPVS规则实现,具体规则创建逻辑可分别参见:

Iptables:https://github.com/kubernetes/kubernetes/blob/master/pkg/proxy/iptables/proxier.go#L780-L1318

IPVS: https://github.com/kubernetes/kubernetes/blob/master/pkg/proxy/ipvs/proxier.go#L760-L1048

Iptables原生支持链接延时断开,即当iptables规则删除时,新的链接不能建立,已经有的长链接链路也不会被主动删除,因此iptables模式实现优雅删除功能不需要任何的代码,以来底层机制即可。

IPVS却并没有这个机制,删除IPVS规则后长链接也会马上断开。这导致很多原来的应用切换到IPVS模式时不能正常工作。

解决方案

为了解决这个问题,IPVS模式的代码需要有专门的机制处理pod删除到长连接断开,链接被彻底删除这段时间的逻辑,其依赖的逻辑是:

IPVS后端的real server有权重机制,用于高级流量调度。当权重为0时,real server上已有的链接不会被断开,也不会有新的链接被分发过来。

因此解决方案的基本思路是,当pod被删除时,配置其对应的后端real server权重为0,等待到该real server的长连接全部断开之后再将其删除。

具体执行过程又会涉及到,比如real server还没完全删除期间重新添加该real server的问题,已删除service的清理逻辑,系统自带的权重为0的IPVS规则处理。

看具体代码实现,本bug fix添加了一个专门针对IPVS模式的GracefulTerminationManager,对外提供的主要方法如下:

// GracefulDeleteRS用于优雅删除后端,替代原来的DeleteRS

// 该方法检查对应RS的长连接,长连接存在的话则直接删除RS,不存在的话将权重置为0并加入优雅删除队列

func GracefulDeleteRS(vs, rs) error

// InTerminationList用于查看某个rs是否在删除队列中

func InTerminationList(uniqueRS string) bool

// MoveRSOutofGracefulDeleteList将某个RS从优雅删除队列移提前移除

func MoveRSOutofGracefulDeleteList(uniqueRS string) error

// Run创建一个协程,以1min为间隔,周期性检查队列中RS的长连接情况,一旦没有长连接就将其删除并移出队列

func Run()

PR信息

下面是该bug fix的PR号,大家感兴趣的话可以去社区自行查看原始PR,issue信息,了解该bug fix的更多信息。

 
 

2 一周bug fix数据分析

本周更新过去两周(10月29号--11月19号)1.11版本的bug fix数据。

在关注的时间段,1.11版本有9条bug fix,其分布情况如图所示:

 
 

其中cloud、volume、cluster均为云平台提供商相关,包括gce、azure、vsphere等,test则是社区使用的e2e测试更新,也无需太多关注。Kube-proxy有一条bug fix,即我们上面详细介绍的,该bug fix在1.11和1.12版本均有涉及,大家可以根据自己的需要,在1.11或者1.12的下个小版本及时升级修复。

 
 

Bug fix严重程度统计,2及以下的bug fix有8个,但主要是对特定的云平台会产生影响,如果没有使用上述云平台,也不用在意。

3 1.9.11重要bug fix解读

 
 
 
 

猜你喜欢

转载自www.cnblogs.com/huaweiyuncce/p/9996006.html