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

时间 2019-11-12

标签原生生态周报 vol helm 发布 beta 版本繁體版

原文原文链接

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

业界要闻

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

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

2. cilium 1.6 版本发布

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

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

3. pivotal 开源了 controller - kpack

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

上游重要进展

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.1三、1.1四、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 开始制定测试方案，包括收集响应延迟结果和标准的集群跑测试用例。windows
eventing 将 channel 和 subscriptions 转移到 messaging.knative.dev API Group。代表 Channel 和 Subscription 的概念是消息的路由而不是事件的转发，涉及到如何迁移现存业务，改动较大。api

开源项目推荐

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 上游设计文档

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

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