版本支持
Kubernetes 版本的格式为 x.y.z，其中 x 是主版本号，y 是次版本号，而 z 则是修订版本。版本的格式遵循 Semantic Versioning ，即
主版本号：当你做了不兼容的 API 修改，
次版本号：当你做了向下兼容的功能性新增，
修订号：当你做了向下兼容的问题修正。
Kubernetes 项目只维护最新的三个次版本，每个版本都会放到不同的发布分支中维护。上游版本发现的严重缺陷以及安全修复等都会移植到这些发布分支中，这些分支由 patch release manager 来维护。
次版本一般是每三个月发布一次，所以每个发布分支一般会维护 9 个月。
不同组件的版本支持情况
在 Kubernetes 中，不同组件的版本并不要求完全一致，但不同版本的组件混合部署时也有一些最基本的限制。
kube-apiserver
在 highly-availabile (HA) clusters 集群中，kube-apiserver 的版本差不能超过一个次版本号。比如最新的 kube-apiserver 版本号为 1.13 时，其他 kube-apiserver 的版本只能是 1.13 或者 1.12。
kubelet
Kubelet 的版本不能高于 kube-apiserver 的版本，并且跟 kube-apiserver 相比，最多可以相差两个次版本号。比如：
kube-apiserver的版本是 1.13相应的
kubelet的版本为 1.13, 1.12, and 1.11再比如，一个高可用的集群中：
kube-apiserver版本号为 1.13 and 1.12相应的
kubelet版本为 1.12, and 1.11 ( 1.13 不支持，因为它比 kube-apiserver 的 1.12 高)kube-controller-manager, kube-scheduler, and cloud-controller-manager
kube-controller-manager,kube-scheduler, 和cloud-controller-manager不能高于 kube-apiserver 的版本。通常它们的版本应该跟 kube-apiserver 一致，不过也支持相差一个次版本号同时运行。比如：kube-apiserver版本为 1.13相应的
kube-controller-manager,kube-scheduler, 和cloud-controller-manager版本为 1.13 and 1.12再比如，一个高可用的集群中：
kube-apiserver版本为 1.13 and 1.12相应的
kube-controller-manager,kube-scheduler, 和cloud-controller-manager版本为 1.12 ( 1.13 不支持，因为它比 apiserver 的1.12 高)kubectl
kubectl 可以跟 kube-apiserver 相差一个次版本号，比如：
kube-apiserver版本为 1.13相应的
kubectl版本为 1.14, 1.13 和 1.12版本升级顺序
当从 1.n 版本升级到 1.(n+1) 版本时，必须要遵循以下的升级顺序。
kube-apiserver
前提条件：
单节点集群中， kube-apiserver 的版本为 1.n；HA 集群中，kube-apiserver 版本为 1.n 或者 1.(n+1)。
kube-controller-manager,kube-scheduler以及cloud-controller-manager的版本都是 1.n。kubelet 的版本是 1.n 或者 1.(n-1)
已注册的注入控制 webhook 可以处理新版本的请求，比如 ValidatingWebhookConfiguration 和 MutatingWebhookConfiguration 已经更新为支持 1.(n+1) 版本中新引入的特性。
接下来就可以把 kube-apiserver 升级到 1.(n+1)了，不过要注意版本升级时不可跳过次版本号。
前提条件：
kube-apiserver 已经升级到 1.(n+1) 版本。
接下来就可以把 kube-controller-manager, kube-scheduler 和 cloud-controller-manager 都升级到 1.(n+1) 版本了。
前提条件：
kube-apiserver 已经升级到 1.(n+1) 版本。
升级过程中需要保证 kubelet 跟 kube-apiserver 最多只相差一个次版本号。
接下来就可以把 kubelet 升级到 1.(n+1)了。
