【独家】K8s 漏洞报告｜引起 Kube-Apiserver 崩溃的 PR

1. 近期 BugFix 汇总

2. 近期重要 BugFix 分析

——本期更新内容

1

近期 Bug Fix 数据汇总

Kubernetes 1.17 已于一个月前发布，针对此版本的 bug fix 相对较少，且到现在为止仍然只有 1.17.0 一个小版本。笔者通过分析发现绝大多数的 Bug Fix 都是一些小的或者冷门特性的修复，不影响正常使用。下面会挑选用户可能比较关心的 Bug 进行解读。

1

近期重要 Bug Fix 分析

回滚# 83520: 引起 Kube-Apiserver 崩溃的 PR

按照 Kubernetes 的设计，在进行 List 操作时，请求参数 option 的 ResourceVersion 字段有以下三种设置：

1. 如果不设置，则请求 Etcd 中最新的数据。

2. 如果设置为 0，则返回 Api-server 中缓存的所有数据。

3. 如果设置为非 0 值，则返回至少与给定值一样新的结果。

#83520 这个 PR 合入之前，Client-go 中的 List 操作总是将请求参数 option 中的 ResourceVersion 设置为“0”，也就是返回 Api-server 中缓存的所有数据。这样会导致在重新 List 时，有返回旧数据的可能。

#83520 合入后，在重新 List 时，option 中的 ResourceVersion 不再设为 0，而是设置为上一次收到的资源的 ResourceVersion。这样可以避免收到老的事件且重复处理。如果服务端返回 410（即请求中的 ResourceVersion 太旧），将会把 ResourceVersion 设为空并继续 List，此时将请求 Etcd 中最新的数据。

但在测试过程中发现#83520 合入后，在 master 滚动升级的过程中会引起集群失败。原因在于：

1. 大规模集群环境下，在滚动升级 master 的过程中，新起的 Api-Server 都是从 Etcd 获取的最新数据。

2. 客户端用本地缓存的上一次收到的资源的 ResourceVersion 去 List，此时服务端将给客户端返回 410，那么客户端都会将 ResourceVersion 设为空并继续 List。

3. 此时对于每个请求 Api-Server 都会去 Etcd 请求数据，并且转码。

4. 大规模场景下，大量的客户端执行此操作，这将使 Api-Server 卡死，出现集群失败的情况。

目前#83520 已经被回滚，并且 cherry-pick 到 release-1.17，但是还未出现在小版本中。

受影响版本： v1.17.0

相关 PR、Issue：

https://github.com/kubernetes/kubernetes/pull/83520

https://github.com/kubernetes/kubernetes/pull/86824

https://github.com/kubernetes/kubernetes/issues/86483

END

原文： https://www.infoq.cn/article/rsJKxKpSgzVNmBy1uxtb