k8s版本規劃的意義

時間 2019-12-05

標籤 k8s 版本規劃意義简体版

原文原文鏈接

本文目的

從如下幾方面分析k8s版本的意義，做爲維護生產環境k8s版本的參考標準。git

k8s版本號的含義。
每一個版本的支持時期。
新版本和舊版本有什麼區別？
新版本對咱們開發產品調用k8s API接口有什麼影響？
在生產環境中是否應該儘可能使用新版本？

k8s版本號的含義

Kubernetes版本表示爲xyz，其中x是主要版本，y是次要版本，z是補丁版本，遵循語義版本控制術語。有關更多信息，請參閱Kubernetes發佈版本。github

k8s 發行版與 github 分支的關係api

簡單來說，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爲補丁版本架構

返回目錄app

每一個版本的支持時期

Kubernetes項目維護最新三個次要版本的發佈分支。結合上述一個X.Y.0版本會在X.(Y-1).0版本的3到4個月後出現的描述，也就是說1年前的版本就再也不維護，每一個次要版本的維護週期爲9~12個月，就算有安全漏洞也不會有補丁版本。this

返回目錄設計

新版本和舊版本有什麼區別？

綜上所述，新版本與舊版本區別主要在於應用了社區中通過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。

返回目錄