k8s版本规划的意义_weixin_33811539-K8S/Kubernetes

本文目的

从以下几方面分析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。

返回目錄