Kubernetes 博客

Thursday, July 18, 2019

Deprecated APIs Removed In 1.16: Here’s What You Need To Know

Author: Vallery Lancey (Lyft)

As the Kubernetes API evolves, APIs are periodically reorganized or upgraded. When APIs evolve, the old API is deprecated and eventually removed.

The 1.16 release will deprecate APIs for four services:

  • NetworkPolicy
  • PodSecurityPolicy
  • DaemonSet, Deployment, StatefulSet, and ReplicaSet
  • Ingress

None of these resources will be removed from Kubernetes or deprecated in any way. However, to continue using these resources, you must use a current version of the Kubernetes API.

Migration Details

  • NetworkPolicy: will no longer be served from extensions/v1beta1 in v1.16.
    • Migrate to the networking.k8s.io/v1 API, available since v1.8. Existing persisted data can be retrieved/updated via the networking.k8s.io/v1 API.
  • PodSecurityPolicy: will no longer be served from extensions/v1beta1 in v1.16.
    • Migrate to the policy/v1beta1 API, available since v1.10. Existing persisted data can be retrieved/updated via the policy/v1beta1 API.
  • DaemonSet, Deployment, StatefulSet, and ReplicaSet: will no longer be served from extensions/v1beta1, apps/v1beta1, or apps/v1beta2 in v1.16.
    • Migrate to the apps/v1 API, available since v1.9. Existing persisted data can be retrieved/updated via the apps/v1 API.
  • Ingress: will no longer be served from extensions/v1beta1 in v1.18.
    • Migrate to the networking.k8s.io/v1beta1 API. Existing persisted data can be retrieved/updated via the networking.k8s.io/v1beta1 API.

What To Do

Kubernetes 1.16 is due to be released in September 2019, so be sure to audit your configuration and integrations now!

  • Change YAML files to reference the newer APIs
  • Update custom integrations and controllers to call the newer APIs
  • Update third party tools (ingress controllers, continuous delivery systems) to call the newer APIs

Migrating to the new Ingress API will only require changing the API path - the API fields remain the same. However, migrating other resources (EG Deployments) will require some updates based on changed fields. You can use the kubectl convert command to automatically convert an existing object: kubectl convert -f <file> --output-version <group>/<version>.

For example, to convert an older Deployment to apps/v1, you can run: kubectl convert -f ./my-deployment.yaml --output-version apps/v1 Note that this may use non-ideal default values. To learn more about a specific resource, check the Kubernetes api reference.

You can test your clusters by starting an apiserver with the above resources disabled, to simulate the upcoming removal. Add the following flag to the apiserver startup arguments:

--runtime-config=apps/v1beta1=false,apps/v1beta2=false,extensions/v1beta1/daemonsets=false,extensions/v1beta1/deployments=false,extensions/v1beta1/replicasets=false,extensions/v1beta1/networkpolicies=false,extensions/v1beta1/podsecuritypolicies=false

Want To Know More?

Deprecations are announced in the Kubernetes release notes. You can see these announcements in 1.14 and 1.15.

You can read more in our deprecation policy document about the deprecation policies for Kubernetes APIs, and other Kubernetes components. Deprecation policies vary by component (for example, the primary APIs vs. admin CLIs) and by maturity (alpha, beta, or GA).

These details were also previously announced on the kubernetes-dev mailing list, along with the releases of Kubernetes 1.14 and 1.15. From Jordan Liggitt:

In case you missed it in the 1.15.0 release notes, the timelines for deprecated resources in the extensions/v1beta1, apps/v1beta1, and apps/v1beta2 API groups to no longer be served by default have been updated:

* NetworkPolicy resources will no longer be served from extensions/v1beta1 by default in v1.16. Migrate to the networking.k8s.io/v1 API, available since v1.8. Existing persisted data can be retrieved/updated via the networking.k8s.io/v1 API.
* PodSecurityPolicy resources will no longer be served from extensions/v1beta1 by default in v1.16. Migrate to the policy/v1beta1 API, available since v1.10. Existing persisted data can be retrieved/updated via the policy/v1beta1 API.
* DaemonSet, Deployment, StatefulSet, and ReplicaSet resources will no longer be served from extensions/v1beta1, apps/v1beta1, or apps/v1beta2 by default in v1.16. Migrate to the apps/v1 API, available since v1.9. Existing persisted data can be retrieved/updated via the apps/v1 API.

To start a v1.15.0 API server with these resources disabled to flush out dependencies on these deprecated APIs, and ensure your application/manifests will work properly against the v1.16 release, use the following --runtime-config argument:

--runtime-config=apps/v1beta1=false,apps/v1beta2=false,extensions/v1beta1/daemonsets=false,extensions/v1beta1/deployments=false,extensions/v1beta1/replicasets=false,extensions/v1beta1/networkpolicies=false,extensions/v1beta1/podsecuritypolicies=false

2019.06.11

欢迎参加在上海举行的贡献者峰会

Author: Josh Berkus (Red Hat)

贡献者小组讨论掠影,摄于 2018 年上海贡献者峰会,作者 Josh Berkus, 许可证 CC-BY 4.0

连续第二年,我们将在 KubeCon China 之前举行一天的 贡献者峰会。 不管您是否已经是一名 Kubernetes 贡献者,还是想要加入社区队伍,贡献一份力量,都请考虑注册参加这次活动。 这次峰会将于六月 24 号,在上海世博中心(和 KubeCon 的举办地点相同)举行, 一天的活动将包含“现有贡献者活动”,以及“新贡献者工作坊”和“文档小组活动”。

现有贡献者活动

去年的贡献者节之后,我们的团队收到了很多反馈意见,很多亚洲和大洋洲的贡献者也想要针对当前贡献者的峰会内容。 有鉴于此,我们在今年的安排中加入了当前贡献者的主题。

尽管我们还没有一个完整的时间安排,下面是当前贡献者主题所会包含的话题:

  • 如何撰写 Kubernetes 改进议案 (KEP)
  • 代码库研习
  • 本地构建以及测试调试
  • 不写代码的贡献机会
  • SIG-Azure 面对面交流
  • SIG-Scheduling 面对面交流
  • 其他兴趣小组的面对面机会

整个计划安排将会在完全确定之后,整理放在社区页面上。

如果您的 SIG 想要在 Kubecon Shanghai 上进行面对面的交流,请联系 Josh Berkus

新贡献者工作坊

参与过去年新贡献者工作坊(NCW)的学生觉得这项活动非常的有价值, 这项活动也帮助、引导了很多亚洲和大洋洲的开发者更多地参与到 Kubernetes 社区之中。

“这次活动可以让人一次快速熟悉社区。”其中的一位参与者提到。

如果您之前从没有参与过 Kubernetes 的贡献,或者只是做过一次或两次贡献,都请考虑注册参加新贡献者工作坊。

“熟悉了从 CLA 到 PR 的整个流程,也认识结交了很多贡献者。”另一位开发者提到。

文档小组活动

文档小组的新老贡献者都会聚首一天,讨论如何提升文档质量,以及将文档翻译成更多的语言。 如果您对翻译文档,将这些知识和信息翻译成中文和其他语言感兴趣的话,请在这里注册,报名参加文档小组活动。

参与之前

不论您参与的是哪一项活动,所有人都需要在到达贡献者峰会前签署 Kubernetes CLA。 您也同时需要考虑带一个合适的笔记本电脑,帮助文档写作或是编程开发。

  • Jan 1
  • Jan 1