云原生生态周报 Vol. 12 | K8s 1.16 API 重大变更-阿里云开发者社区

开发者社区> 阿里巴巴云原生> 正文

云原生生态周报 Vol. 12 | K8s 1.16 API 重大变更

简介: 本文作者:源三、临石、张磊、莫源 业界要闻 1. K8s 1.16 将废弃一系列旧的 API 版本 影响面涉及 NetworkPolicy、PodSecurityPolicy、DaemonSet, Deployment, StatefulSet, ReplicaSet 和 Ingress。

本文作者:源三、临石、张磊、莫源

业界要闻

1. K8s 1.16 将废弃一系列旧的 API 版本

影响面涉及 NetworkPolicy、PodSecurityPolicy、DaemonSet, Deployment, StatefulSet, ReplicaSet 和 Ingress。请各位 K8s 用户和开发者关注,相关 API 都是进行了如下迁移:

  • NetworkPolicy: 在 v1.16 中不再使用 extensions/v1beta1;

    • 迁移到 networking.k8s.io/v1 API,自 v1.8 之后可用,存量数据可以通过新的API获取和更新。
  • PodSecurityPolicy:在 v1.16 不再使用 extensions/v1beta1;

    • 迁移到 policy/v1beta1 API,自 v1.10 之后可用,存量数据可以通过新的 API 获取和更新。
  • Deamon Set、Deployment、StatefulSet 和 ReplicaSet:从 v1.16 开始将不再通过 extension/v1beta1、apps/v1beta1、或 apps/v1beta2 提供;

    • 迁移到 apps/v1 API,自 v1.9 已经可用,存量数据可以通过新的 API 获取和更新。
  • Ingress:从 v1.18 开始不再通过 extensions/v1beta1 提供;

2. Prometheus 持续备受瞩目,多家云厂商推出托管或集成服务

作为 CNCF 下的另一个成功项目,Prometheus 已经被在微软 Azure 上与 Azure Monitor 进行集成,现已进入预览阶段。 上个月,阿里云推出了托管版的 Prometheus 监控产品,支持白屏化安装 exporter,开箱即用的监控大盘,开源组件全兼容,无需运维基础能力免费使用。此外,阿里云也推出了开源增强的 Prometheus 解决方案,在采集指标丰富度、采集指标准确性等方面做了增强,支持使用阿里云 TSDB 时序数据库做数据的持久化与高可用,可以简单方便的通过 Helm Chart 进行一键安装管理。

上游重要进展

Kubernetes 设计增强提议(KEP)

  • IPv6 支持进入 Beta 阶段
  • Cloud Provider Label 准备 GA 目前的 cloud provider label 都是 beta,计划去掉并修改。

Knative 项目

  • 计划 8 月 6 日发布 Serving 0.8,相关的 issue 主要是可用性和稳定性的改善;
  • 增强直接从 source 消费 event 的易用性,确定了扩展 Knative CLI 的场景以及需要修改事件使用模型。

开源项目推荐

kopf

一个面向 Python 用户的 Kubernetes Operator Framework。它提供了一组简洁的原语,使得用户可以用简单的 Python 代码来快速实现一个 Operator,并且通过这些原语屏蔽掉 Operator 的技术细节,专注在 Operator 里面的运维逻辑上。

本周阅读推荐

Best Practices: Benchmarking Service Mesh Performance
文章介绍对 Service Mesh 性能(Istio)进行 Benchamark 的最佳实践。
451 Research 的 Cloud Price Index
第三方机构推出商业调研报告,针对全球不同区域的公有云和私有云价格提供了其分析和洞察。
Cloud-Native CI/CD with OpenShift Pipelines
介绍了在 OpenShift 4.1 中发布的 OpenShift Pipelines 开发者预览版(developer preview),OpenShift Pipelines 这是 OpenShift 对 Tekton 项目的集成实践。
Avoid time-of-measurement bias with Prometheus
我们目前有很多工具(例如 Prometheus)来监控我们一个 Server 的性能,但是很多情况下,一个 Server 的服务是由后面的很多 worker 以异步的方式提供的。
在实践中经常发生的情况是:尽管我们由各种各样的 Metrics,但是我们还是不知道那些异步提供服务的 worker 究竟在做什么,而这经常导致我们(尽管手头一堆工具)不能快速定位问题。这篇博客通过一个经典案例描述了其中的痛点和实践办法,同时介绍了开源工具:https://github.com/lawrencejones/prometheus-client-tracer-ruby

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

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

关注云原生中间件、微服务、Serverless、容器、Service Mesh等技术领域、聚焦云原生技术趋势、云原生大规模的落地实践

官方博客