云原生生态周报 Vol. 9：K8s 1.15 后的性能提升_云原生_心贵

HarmonyOS开发者限时福利来啦！最高10w+现金激励等你拿~ 了解详情 



 写点什么

前言

《云原生生态周报》由阿里云容器平台联合蚂蚁金服共同发布，每周一期。众多一线社区专家与您一起“跟踪动态，读懂社区”，分享云原生社区项目进展、活动发布、精选博客等信息。以下是第九期云原生生态周报的内容。

Helm 这款包管理工具，作为业界 Kubernetes 上应用分发的事实标准，其 v3.0.0-alpha.1 正式发布，这是 Helm 3 的第一个Alpha版本，标志着 Tiller 这个 Server 端组件正式从 Helm 体系中谢幕。
Talos发布。Talos 是一款专门用于部署 Kubernetes 的操作系统。相对于 CoreOS，RancherOS 或者 LinuxKit 这些容器操作系统，Talos 更为精简。但是由于去除了 ssh 等基础工具，这对于 Ansible 等基于 ssh 的 Kubernetes 部署工具影响巨大。
Google 推出深度学习容器，这是一种用于部署和测试利用机器学习应用与服务的优化环境。Beta 版本的深度学习容器可在云与本地工作，从而使得在本地或云中进行开发或原型设计成为可能。此外，该容器还能直接访问 CUDA、cuDNN、NCCL 工具，支持 PyTorch、TensorFlow 2.0 和 TensorFlow 1.13 框架。

client-go 会把 List/Watch 超时设置为 [5min， 10min)，即在超时时间后会重新发起 List/Watch，建议 Daemenset 调整这个时间到几十分钟甚至数小时级别，不然 Apiserver 可能会因为大量访问崩溃。同时，也在考虑 kubelet 是否也要修改这个值，代码的注释里写着 5min 是为了平衡负载均衡以及解除负载均衡设备 watch 的 hang 住 bug。
client-go RateLimiter 加入 Wait 方法，避免在异步场景下使用 client-go 引起 goruntine 积压。
Webhook 和 Adimission 支持 context-aware，在这个修复之前，Webhook 和 Admission 的性能也可能引起 Apiserver goruntine 积压从而影响 Apiserver 性能。
Kube-Apiserver 到达 IO 瓶颈时，metric 错误的将 IO 瓶颈错误归类到 504。我们需要将逻辑处理超时和写 IO 超时分开。

新引入 WatchBookmark 特性。该特性能大大提高 Kube-Apiserver 的 List/Watch 性能，大家都知道，大规模集群下各个组件的 List/Watch 会消耗 Kube-Apiserver 巨大的性能开销，有了该特性，我们可以展望未来的集群规模又可以上升一个台阶。 (#74074, @wojtek-t)
Admission 默认开启 StorageObjectInUseProtection。StorageObjectInUseProtection 能保护正在使用的 PV/PVC 被误删除。这对手速太快的开发和 SRE 同学是一个很大的福音。(#74610, @oomichi)
蚂蚁金服在大规模实践中，发现 Daemonset 有各种发布和部署 Pod 被卡住的问题，蚂蚁同学对 Daemonset Controller 可能发生的一系列死锁问题做了修复。

参考链接：

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 式的处理。支持异步请求可以用在以下的场景

Notifications (e.g. mobile push notification, SMS notification, mass emails, etc)

Database migrations

期望在缩容的时候，由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 的基础概念进行了精确的概括总结。

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

本周作者：心贵、莫源、元毅、衷源、张磊

责任编辑：涂南、木环

前期周报回顾