云原生生态周报 Vol. 12：K8s 1.16 API 重大变更_云原生_源三

前言

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

业界要闻

1 K8s 1.16 将废弃一系列旧的 API 版本：影响面涉及 NetworkPolicy、PodSecurityPolicy、DaemonSet, Deployment, StatefulSet, and 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 提供
迁移到networking.k8s.io/v1 API，存量数据可以通过新的 API 获取和更新
详细信息：https://kubernetes.io/blog/2019/07/18/api-deprecations-in-1-16/

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

上游重要进展

1 Kubernetes 设计增强提议（KEP）

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

2 knative 项目

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

开源项目推荐

1 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

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

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

责任编辑：木环