【独家】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解读

 

 

 

 

原文：https://www.cnblogs.com/huaweiyuncce/p/9996006.html