k8s版本规划的意义

目录

• 本文目的
• k8s版本号的含义
• 每一个版本的支持时期
• 新版本和旧版本有什么区别？
• 在生产环境中是否应该尽可能使用新版本？
• 参考文档

本文目的

从如下几方面分析k8s版本的意义，做为维护生产环境k8s版本的参考标准。

• k8s版本号的含义。
• 每一个版本的支持时期。
• 新版本和旧版本有什么区别？
• 新版本对咱们开发产品调用k8s API接口有什么影响？
• 在生产环境中是否应该尽可能使用新版本？

---

k8s版本号的含义

Kubernetes版本表示为xyz，其中x是主要版本，y是次要版本，z是补丁版本，遵循语义版本控制术语。有关更多信息，请参阅Kubernetes发布版本。

• k8s 发行版与 github 分支的关系

  简单来说，kubernetes项目存在3类分支(branch)，分别为master，release-X.Y,release-X.Y.Z。 master分支上的代码是最新的，每隔2周会生成一个发布版本(release)，由新到旧以此为master-->alpha-->beta-->Final release，这当中存在一些cherry picking的规则，也就是说从一个分支上挑选一些必要pull request应用到另外一个分支上。 咱们能够认为X.Y.0为稳定的版本，这个版本号意味着一个Final release。一个X.Y.0版本会在X.(Y-1).0版本的3到4个月后出现。 X.Y.Z为通过cherrypick后解决了必须的安全性漏洞、以及影响大量用户的没法解决的问题的补丁版本。 整体而言，咱们通常关心X.Y.0(稳定版本)，和X.Y.Z(补丁版本)的特性。

• 例子

  v1.14.0 : 1为主要版本 : 14为次要版本 : 0为补丁版本

返回目錄

---

每一个版本的支持时期

Kubernetes项目维护最新三个次要版本的发布分支。结合上述一个X.Y.0版本会在X.(Y-1).0版本的3到4个月后出现的描述，也就是说1年前的版本就再也不维护，每一个次要版本的维护周期为9~12个月，就算有安全漏洞也不会有补丁版本。

返回目錄

---

新版本和旧版本有什么区别？

综上所述，新版本与旧版本区别主要在于应用了社区中通过cherrypick挑选出来的PR以及修复了安全性漏洞、没有workaround(临时解决办法)的bug。 如下连接中维护了全部当前的发行版的连接，可在此连接中查询相应版本与以前版本的区别: github.com/kubernetes/…

每一个稳定版本之间的release note也能够在kubernetes官网上查阅到: kubernetes.io/docs/setup/… 这其中包括了一些版本升级前必需要确认的事宜，以v1.14为例: kubernetes.io/docs/setup/…

KUBE-API服务器： 默认RBAC策略再也不授予对未经身份验证的用户的发现和权限检查API（由kubectl auth can -i使用）的访问权限。升级的群集保留了先前的行为，但但愿在新群集中授予未经身份验证的用户访问权限的群集管理员须要明确选择公开发现和/或权限检查API： kubectl create clusterrolebinding anonymous-discovery --clusterrole=system:discovery --group=system:unauthenticated kubectl create clusterrolebinding anonymous-access-review --clusterrole=system:basic-user --group=system:unauthenticated ...

返回目錄

---

新版本对咱们开发app调用k8s API接口有什么影响？

因为k8s自己是基于api的为服务架构，k8s系统内部也是经过互相调用api来运做的，整体而言kubernetes api在设计时遵循向上和/或向下兼容的原则。k8s的api是一个api的集合，称之为"API groups"。每个API group维护着3个主要版本，分别是GA，Beta，Alpha。 API的弃用只会经过在新的API group启用的同时宣告旧API group将会弃用的方式来推动。GA版本在宣告启用后将会向下兼容12个月或3个发行版。Beta版本则为9个月或3个发行版。而Alpha则会马上启用。 这个遵循kubernetes版本的升级规则，也就是总体而言集群升级不支持跨度在2个Final release发行版之上的操做。 每一个发行版的release note中也有对API重大改动的描述。开发者们能够参阅其修改API。

返回目錄

---

在生产环境中是否应该尽可能使用新版本？

从结论上来讲，是的。缘由也是因为上述的发行版都存在这对应的生命周期。 但值得注意的时，升级集群理论上只支持跨度为2个次要版本的操做。

返回目錄

---

参考文档

Kubernetes Version and Version Skew Support Policy Kubernetes Release Versioning Kubernetes Deprecation Policy The Kubernetes API