云原生生态周报 Vol. 17 | Helm 3 发布首个 beta 版本

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

业界要闻

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 项目

apiserver 对 observed requests 进行更细致的分类，对 requests 增加优先级。目前 apiserver 有比较简单的机制去防止过载，例如用 max-in-flight 去限制 mutating 和 readonly 的请求，但是除了这两类请求外，还有一些其他类型的请求可以去做不同的限制。这个 KEP 希望把 apiserver 收到的 request 按优先级等级进行分类，每个 request 分配到它对应的 concurrency pool，这样不同优先级的请求就可以做到不同的请求上限限制。作者在 KEP 里列举了一些目前在 1.16 中观察到的 requests。
为 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 的进行。
scheduling framework：为 Kubernetes scheduler 设计的插件式的架构，让调度特性以插件的形式加入 scheduler（将在 1.17 进行 beta）。https://github.com/kubernetes/enhancements/issues/624 （KEP 比较早）。随着调度特性越来越多，scheduler 的代码越来越庞大，维护日益复杂，同时定制 scheduler 的开销也比较大。于是社区希望将 scheduler 做成一个 scheduling framework 的架构，让其他的调度特性以插件形式注册到 scheduler，对调度器的拓展也更加灵活。

其他更新

修复 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 项目

mvcc: 调整默认的 compact batch 为 1000，compact batch interval 为 10ms。compact batch 影响 compact 的速度，过大的 compact batch 会导致 put/range 的性能下降，过小的 compact batch 又 compact 不了太多的 key。在集团内部，我们把这两个参数设置为可变，不同的集群根据 qps 进行压测调节到最优参数。
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 项目

serving 和 eventing 在功能和稳定性相对平稳后，开始进入性能优化阶段，开始进行 benchmark，包括：
- deployment benchmark；
- activator + throttler 的开启 Throttler ；关闭 Throttler；
- eventing 开始制定测试方案，包括收集响应延迟结果和标准的集群跑测试用例。
eventing 将 channel 和 subscriptions 转移到 messaging.knative.dev API Group。表明 Channel 和 Subscription 的概念是消息的路由而不是事件的转发，涉及到如何迁移现存业务，改动较大。

开源项目推荐

microk8s

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

microk8s 紧跟上游 K8s 的 feature，刚刚 release 了 1.16-beta，同时它包含了主流 K8s 生态的其他工具，包括 serverless（knative），service mesh（istio），monitoring（prometheus，grafana），machine learning（kubeflow）。

qlkube

Kubernetes 的 GraphQL API，允许你使用 graphql 与 Kubernetes api 进行交互。https://github.com/qlkube/qlkube?utm_sq=g5n76aa1mt

GraphQL 是 Facebook 2015 年开源的数据查询规范。对于现在大多数的 RESTful API，都存在以下场景：

client 需要向 server 发若干个请求才能获得所需要查询的内容；
GraphQL 则希望让 API 数据间以图的形式，有关联和层次结构进行组织；
qlkube 是利用 Kubernetes 的 openapi/swagger api specification 自动生成的 GranphQL 接口。

kube-fzf

利用 kubectl 和 fzf 搭建的支持模糊搜索的命令行工具。https://github.com/thecasualcoder/kube-fzf

fzf （fuzzy finder）是一个非常丰富的命令行模糊搜索器，而 kube-fzf 把两个命令行工具结合，减少了 Kubernetes 日常运维时敲的大量 kubectl get po xxx -n xxxxx 的命令复杂度。目前支持搜索 pod，tail pod container，describe pod，exec into a pod，port forward pod。

本周阅读推荐

1. 《The State of State in Cloud Native Applications》

https://thenewstack.io/the-state-of-state-in-cloud-native-applications/
在云原生应用中，有状态应用的状态处理和发展过程以及未来走向。

2. 《How Kubernetes Could Orchestrate Machine Learning Pipelines》

https://thenewstack.io/how-kubernetes-could-orchestrate-machine-learning-pipelines/
在过去几年，Apache YARN 和 Mesos 往往是 data science 类型的 job（尤其是 machine learning）首选的资源调度器，而随着 Kubernetes 在社区的火爆，在 Kubernetes 上允许 big data 或 analytics job 的用户越来越多。文章介绍了如何使用 kubeflow pipeline 进行 ML 训练，以及 MLOps 的设计。

3. 《Kubernetes Web UIs in 2019》

https://srcco.de/posts/kubernetes-web-uis-in-2019.html
社区有非常多 Kubernetes Web UI 的项目，作者提出他自己对 Kubernetes UI 的期望，并对所有开源项目做了一个总结。

4. 《深度解读 Helm 3: 犹抱琵琶半遮面》

自去年年初开始放风 Helm v3 将要开始开发，就被一堆人追问到底啥时候发版本。Helm v3 在五月发布了第一个 alpha 版本，如今发布了 beta 版本，本文是一篇旧文解读 Helm v3 aplha，但是绝对是一篇有助于理解 Helm V3的好文章。

5. 《Knative Eventing 之 Choice 介绍》

从 Knative Eventing 0.8 开始，支持根据不同的过滤条件对事件进行选择处理。通过 Choice 提供了这样的能力。本文旨在介绍一下 Choice 特性。

6. 《Service Mesh 发展趋势(续)：棋到中盘路往何方》

继续探讨 ServiceMesh 发展趋势，以灵魂拷问的方式深度分析 Istio 的重大革新 Mixer v2，Envoy 支持 Web Assembly 的意义所在; 深入介绍 Google Traffic Director 对虚拟机模式的创新支持方式，以及最近围绕 SMI 发生的故事。

名词解释：KEP - Kubernetes Enhancement Proposal，即 Kubernetes 上游设计文档

--
本周报由阿里巴巴容器平台联合蚂蚁金服共同发布

本周作者：墨封，衷源，元毅，有济，心水
责任编辑：木环