业界要闻
- Helm这款包管理工具，作为业界Kubernetes上应用分发的事实标准，其 v3.0.0-alpha.1正式发布，这是Helm 3的第一个Alpha版本。（https://github.com/helm/helm/releases/tag/v3.0.0-alpha.1），标志着 Tiller 这个 Server 端组件正式从 Helm 体系中谢幕
- Talos发布。Talos是一款专门用于部署Kubernetes的操作系统。相对于CoreOS，RancherOS或者LinuxKit这些容器操作系统，Talos更为精简。但是由于去除了ssh等基础工具，这对于Ansible等基于ssh的Kubernetes部署工具影响巨大。(https://github.com/talos-systems/talos)
- Google推出深度学习容器，这是一种用于部署和测试利用机器学习应用与服务的优化环境。Beta 版本的深度学习容器可在云与本地工作，从而使得在本地或云中进行开发或原型设计成为可能。此外，该容器还能直接访问 CUDA、cuDNN、NCCL工具，支持 PyTorch、TensorFlow 2.0 和 TensorFlow 1.13框架。（https://cloud.google.com/blog/products/ai-machine-learning/introducing-deep-learning-containers-consistent-and-portable-environments）
上游重要进展
Kubernetes 项目性能提升
-
大规模场景下一定要 Cherry Pick 的几个特性：
- 优化 Watch event 的 dispatch https://github.com/kubernetes/kubernetes/issues/73958
- NodeLease 功能: https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/0009-node-heartbeat.md
- client-go 会把 List/Watch 超时设置为 [5min， 10min)，即在超时时间后会重新发起 List/Watch，建议 Daemenset 调整这个时间到几十分钟甚至数小时级别，不然 Apiserver 可能会因为大量访问崩溃。同时，也在考虑 kubelet 是否也要修改这个值，代码的注释里写着 5min 是为了平衡负载均衡以及解除负载均衡设备 watch 的hang住 bug。
- client-go RateLimiter 加入 Wait 方法，避免在异步场景下使用 client-go 引起 goruntine 积压：https://github.com/kubernetes/kubernetes/pull/79375
- Webhook 和 Adimission 支持 context-aware，在这个修复之前，Webhook 和 Admission 的性能也可能引起 Apiserver goruntine 积压从而影响 Apiserver 性能： https://github.com/kubernetes/kubernetes/pull/79376
- Kube-Apiserver 到达 IO 瓶颈时，metric 错误的将 IO 瓶颈错误归类到 504。我们需要将逻辑处理超时和写 IO 超时分开：https://github.com/kubernetes/kubernetes/pull/79609
Kubernetes 可靠性和稳定性
- 新引入
WatchBookmark特性。该特性能大大提高 Kube-Apiserver 的 List/Watch 性能，大家都知道，大规模集群下各个组件的 List/Watch 会消耗 Kube-Apiserver 巨大的性能开销，有了该特性，我们可以展望未来的集群规模又可以上升一个台阶。 (#74074, @wojtek-t) - Admission 默认开启 StorageObjectInUseProtection。StorageObjectInUseProtection 能保护正在使用的 PV/PVC 被误删除。这对手速太快的开发和 SRE 同学是一个很大的福音。(#74610, @oomichi)
- 蚂蚁金服在大规模实践中，发现 Daemonset 有各种发布和部署 Pod 被卡住的问题，蚂蚁同学对 Daemonset Controller 可能发生的一系列死锁问题做了修复。
参考：
https://github.com/kubernetes/kubernetes/pull/78974
https://github.com/kubernetes/kubernetes/pull/77773
https://github.com/kubernetes/kubernetes/pull/77208
https://github.com/kubernetes/kubernetes/pull/78170
Knative 项目
- knative-eventing 0.7.0 发布，主要特性是：重构channel，为每个 Channel 单独创建了CRD资源；支持事件顺序处理（Sequence）；在 Channel, Subscription, Broker, 以及 Trigger 中增强注释信息；事件追踪支持；事件源增强。详细说明请见 knative-eventing 0.7.0解读文章
- knative-serving 0.7.0 发布，主要特性是：发布 serving.knative.dev/v1beta1 api ；HPA支持根据并发请求指标扩缩容；切换到非root用户容器；详细说明请见 knative serving 0.7.0 版本变更。
- 讨论serving是否支持异步请求：要求请求后马上返回，另外可以根据id查询状态，当前还没有结论。从这个需求讨论可以看出serving在扩大自己的场景，不满足只做ping-pong式的处理。支持异步请求可以用在以下的场景
- Long-running jobs
-
-
- Notifications (e.g. mobile push notification, SMS notification, mass emails, etc)
- Database migrations
-
-
- Batch processing (e.g. data transformation)
- Stream processing
- Highly parallel jobs (document, image, … processing)
- Fan-out workloads
- Serveless Operator
- 期望在缩容的时候，由autoscaler来决定删除哪些pod。例如在scale-down时，各个pod的负载不平衡，这个时候希望能挑选sale-down代价最小的pod。serving-revision使用K8-deployment，如果不更换实现方式，需要k8底层支持，k8也有相关的讨论
本周阅读推荐
- 《Cloud 2.0：代码不再为王，Serverless 当道！》 这一篇不错的“务虚”文档，可以从技术演进的视角去思考云时代的技术演进。
- 《微服务架构之「 监控系统 」》 ，这篇文档详细且完整的描述了微服务架构下的监控系统。用户可以根据此文档对微服务的解决方案进行入门级的了解。
- 《Knative 核心概念介绍：Build、Serving和Eventing 三大核心组件》，面对火热的Serverless项目Knative，这篇文章对Knative的基础概念进行了精确的概括总结。
本周报由阿里巴巴容器平台联合蚂蚁金服共同发布
本周作者：心贵、莫源、元毅、衷源、张磊
责任编辑：涂南、木环
前期周报回顾
云原生生态周报 Vol. 8 | Gartner 发布云原生趋势
云原生生态周报 Vol. 7 | Docker 再爆 CVE
云原生生态周报 Vol. 6 | KubeCon EU 特刊
云原生生态周报 Vol. 5 | etcd性能知多少
云原生生态周报 Vol. 4 | Twitter 走向 K8s
云原生生态周报 Vol. 3 | Java 8 ️️ Docker
