云原生生态周报 Vol. 9 | K8s 1.15 后的性能提升-阿里云开发者社区

开发者社区> 云原生> 正文
登录阅读全文

云原生生态周报 Vol. 9 | K8s 1.15 后的性能提升

简介: 业界要闻 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发布。

业界要闻

  1. 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 体系中谢幕
  2. Talos发布。Talos是一款专门用于部署Kubernetes的操作系统。相对于CoreOS,RancherOS或者LinuxKit这些容器操作系统,Talos更为精简。但是由于去除了ssh等基础工具,这对于Ansible等基于ssh的Kubernetes部署工具影响巨大。(https://github.com/talos-systems/talos)
  3. 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 项目性能提升

  1. 大规模场景下一定要 Cherry Pick 的几个特性:

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

Kubernetes 可靠性和稳定性

  1. 新引入 WatchBookmark 特性。该特性能大大提高 Kube-Apiserver 的 List/Watch 性能,大家都知道,大规模集群下各个组件的 List/Watch 会消耗 Kube-Apiserver 巨大的性能开销,有了该特性,我们可以展望未来的集群规模又可以上升一个台阶。 (#74074, @wojtek-t)
  2. Admission 默认开启 StorageObjectInUseProtection。StorageObjectInUseProtection 能保护正在使用的 PV/PVC 被误删除。这对手速太快的开发和 SRE 同学是一个很大的福音。(#74610, @oomichi)
  3. 蚂蚁金服在大规模实践中,发现 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 项目

  1. knative-eventing 0.7.0 发布,主要特性是:重构channel,为每个 Channel 单独创建了CRD资源;支持事件顺序处理(Sequence);在 Channel, Subscription, Broker, 以及 Trigger 中增强注释信息;事件追踪支持;事件源增强。详细说明请见 knative-eventing 0.7.0解读文章
  2. knative-serving 0.7.0 发布,主要特性是:发布 serving.knative.dev/v1beta1 api ;HPA支持根据并发请求指标扩缩容;切换到非root用户容器;详细说明请见 knative serving 0.7.0 版本变更。
  3. 讨论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
  1. 期望在缩容的时候,由autoscaler来决定删除哪些pod。例如在scale-down时,各个pod的负载不平衡,这个时候希望能挑选sale-down代价最小的pod。serving-revision使用K8-deployment,如果不更换实现方式,需要k8底层支持,k8也有相关的讨论

本周阅读推荐

  1. Cloud 2.0:代码不再为王,Serverless 当道!》 这一篇不错的“务虚”文档,可以从技术演进的视角去思考云时代的技术演进。
  2. 《微服务架构之「 监控系统 」》 ,这篇文档详细且完整的描述了微服务架构下的监控系统。用户可以根据此文档对微服务的解决方案进行入门级的了解。
  3. 《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

ACK_

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
云原生
使用钉钉扫一扫加入圈子
+ 订阅

云原生时代,是开发者最好的时代

其他文章