本周作者 | 墨封、衷源、元毅、有济、心水

业界要闻

1. Helm 3 首个 beta 版本 v3.0.0-beta.1 发布

该版本的重点是完成最后的修改和重构，以及移植其他 Helm 2 特性。https://github.com/helm/helm/releases

2. cilium 1.6 版本发布

完成了最后的两个核心需求，宣布已经可以 100% 替换 kube-proxy。https://cilium.io/blog/2019/08/20/cilium-16/

cilium 是一个基于 eBPF 实现的可用于提供容器网络连接和负载均衡的组件，不依赖 K-V store，以下是 cilium 的性能测试结果。
                

3. pivotal 开源了 controller - kpack

实现镜像构建和更新的资源控制器。https://github.com/pivotal/kpack

上游重要进展

Kubernetes 项目

1. apiserver 对 observed requests 进行更细致的分类， 对 requests 增加优先级。目前 apiserver 有比较简单的机制去防止过载，例如用 max-in-flight 去限制 mutating 和 readonly 的请求，但是除了这两类请求外，还有一些其他类型的请求可以去做不同的限制。这个 KEP 希望把 apiserver 收到的 request 按优先级等级进行分类，每个 request 分配到它对应的 concurrency pool，这样不同优先级的请求就可以做到不同的请求上限限制。作者在 KEP 里列举了一些目前在 1.16 中观察到的 requests。
2. 为 HA master 增加 StorageVersion API。HA master 在 roling upgrade 时，每一个 apiserver 可能会用不同的 storage version 去 encode resource。如果集群中有 storage version migrator，则会错误导致 storage migrator 升级 resource storage version 到不同的版本。增加了一个 StorageVersion API 在这种场景下会告诉 migrator，当前 HA 集群对 storage version 未达成一致，migrator 会阻塞 migrate 的进行。
3. scheduling framework：为 Kubernetes scheduler 设计的插件式的架构，让调度特性以插件的形式加入 scheduler（将在 1.17 进行 beta）。https://github.com/kubernetes/enhancements/issues/624 （KEP 比较早）。随着调度特性越来越多，scheduler 的代码越来越庞大，维护日益复杂，同时定制 scheduler 的开销也比较大。于是社区希望将 scheduler 做成一个 scheduling framework 的架构，让其他的调度特性以插件形式注册到 scheduler，对调度器的拓展也更加灵活。

1. 其他更新

• 修复 kubectl -f 在 windows 下不起作用的问题（显式 follow symlink）。
• Kubernetes API change 相关：CustomResourceDefaulting 被从 featuregate.Alpha 升级到 featuregate.Beta，并默认开启。v1beta1 webhooks/CRD types 被 deprecated。release 1.13、1.14、1.15中go 版本均升级（解决之前提到的 net/http 安全漏洞影响）
• 允许 apiserver 只以 http1 启动（DisableHTTP2)，方便某些特殊测试或者生产场景需求。
• scale client 支持非 namespace 的资源（例如 cluster 范围的 CRD）
• kubelet 计算 pod 使用资源时支持 pod-overhead的场景（evict 时用作参考）

etcd 项目

1. mvcc: 调整默认的 compact batch 为 1000，compact batch interval 为 10ms。compact batch 影响 compact 的速度，过大的 compact batch 会导致 put/range 的性能下降，过小的 compact batch 又 compact 不了太多的 key。在集团内部，我们把这两个参数设置为可变，不同的集群根据 qps 进行压测调节到最优参数。
2. raft：允许 learner 在特殊情况下进行投票。存在这样的场景：集群 id=1 是 learner，id=2 是 voter，id=3 是 voter，然后通过客户端将 learner promote 成 voter，因为网络分区等原因，消息还没传到 learner，但是此时 id=2 的 voter 挂了，那么 id=3 voter 则直接获得了选举胜利。实际上此时 learner 已经 promote 成 voter 了，还需要 id=1 的 voter 进行投票。该 PR 修复了这个场景，允许 learner 收到投票，当 learner 收到投票时，表明其他 quorum 将自己视为一个 voter 了。

knative 项目

1. serving 和 eventing 在功能和稳定性相对平稳后，开始进入性能优化阶段，开始进行 benchmark，包括：
   - deployment benchmark；
   - activator + throttler 的开启 Throttler ；关闭 Throttler；
   - eventing 开始制定测试方案，包括收集响应延迟结果和标准的集群跑测试用例。

2. eventing 将 channel 和 subscriptions 转移到 messaging.knative.dev API Group。表明 Channel 和 Subscription 的概念是消息的路由而不是事件的转发，涉及到如何迁移现存业务，改动较大。

开源项目推荐

microk8s

体积小，运行速度快，single-package 的 K8s 版本，适合用于做 K8s 的离线开发，IOT 和边缘设备。https://github.com/ubuntu/microk8s