Kubernetes新版本又來了 如何跟上變化“合理更新”？
Kubernetes LTS並不存在
每三個月釋出一個“vanilla”上游Kubernetes的1.xx“minor”版本，這種節奏可能會永遠持續下去。你必須跟上，同時也要密切關注Kubernetes API物件版本控制。這種堅定的步伐是Kubernetes統治分散式基礎設施領域的關鍵因素。
何為Kubernetes釋出週期？
我們與那些希望利用Kubernetes（特別是DIY部署）的人交談時遇到的問題之一，就是“你們如何保持同步？”
這帶來了對以下問題的好奇：
誰在管理Kubernetes社群專案？
它們的釋出週期和質量有多一致？
像Debian、Ubuntu或RHEL一樣，Kubernetes是否有長期支援版本，即Kubernetes LTS？
每次釋出新的Kubernetes版本時，叢集維護人員或產品負責人需要做什麼才能跟上？
叢集不用最新版本時會發生什麼？
它們是繼承管理Kubernetes的任務的合理替代嗎？
如果答案僅僅是“雲”，那麼使用“認證”Kubernetes平臺可以安全而不被鎖定嗎？
讓我們深入瞭解Kubernetes和這個專案背後的故事。
Kubernetes的由來
谷歌內部Kubernetes最早的管理人員圍繞該專案建立了一個強大的開放社群，從Linux核心專案、Mozilla、Openstack、Chrome甚至node.js分支中汲取了足夠多的經驗教訓。
commit 2c4b3a562ce34cddc3f8218a2c4d11c7310e6d56
Author: Joe Beda <[email protected]>Date: Fri Jun 6 16:40:48 2014 -0700
First commit
如果你進入這一領域較晚，你可以檢視近三年Techcrunch上關於Kubernetes 1.0版本的文章。
領導Linux基金會的開源社群構建積極分子Jim Zemlin是名副其實的矽谷算命先生，“我預測，這項技術好得讓人無法抗拒，現在沒有參與的人以後會改變主意。”
即使Bryan Cantrill（Joyent首席技術官和unix天才），在見證了Kubernetes的誕生之後，也承認自己之前的開源觀點有失偏頗。
Kubernetes成功的另一個祕密和主要原因是CNCF在Apache-2.0下發布它，這是一個有爭議的開源許可（有人說它是長久以來科技巨頭之間商業軟體專利冷戰的解藥）。
如果你直接問Jim Zemlin這一切有什麼特別之處，他會談到讓Alphabet貢獻出Kubernetes的驚人法律壯舉——一切都在受專利保護的開源許可之下！
伴隨著Kubernetes的發展，CNCF和Kubernetes的貢獻者們維持著一個以協作、開放和自我反思著稱的社群。該說說SIG（Special Interest Group）了。
Kubernetes Special Interest Group
除了谷歌Brog十多年的積累和CNCF的帶領之外，驅動Kubernetes發展的另一股力量是它的SIG模式。SIG是由技術上有共識的人組成的特別小組。它們採用與領先軟體公司中最好的團隊相同的模式。最關鍵的，SIG負責管理端到端測試和CI / CD系統（這些系統嚴格執行Kubernetes釋出程式）。對邊緣的或更深奧的部分感興趣的SIG隨工作進展而增減，在特定區域出現。甚至還有一個整體的產品管理SIG，由頂尖的PM負責。
在理解Kubernetes釋出週期的背景下，SIG和他們的工作組很有意思，因為領導力、節奏和長期質量等關鍵屬性都是SIG結構的成果。想了解SIG如何與更廣泛的企業利益生態系統相互作用，可以聽一下技術專案經理兼SIG產品負責人Caleb Miles的New Stack訪談。
SIG最棒的一點是，參與者和領導力的多樣性。然而，與別的流行的新興技術一樣，總有鞏固權力和影響路線圖的需要。收購CoreOS後，紅帽現在“驕傲的是，紅帽工程師能夠主導或共同主導12個SIG。”目前還不清楚這是好是壞，但其後果值得觀察。
Kubernetes版本控制
Kubernetes釋出的基本節奏是預期每三到四個月一次重要釋出。Kubernetes Release Versioning設計文件有一些非常好的細節。雖然最初的動力來自谷歌，但現在核心釋出團隊中的數十家科技公司輪番發力。
很多人會挑剔“vanilla”Kubernetes的質量，因此任何釋出目標的共同管理者都有很大的自由度來改變日期或推遲未被相關SIG認為就緒的pull請求。認真看了版本控制檔案的人會注意到，“目前沒有釋出2.0.0的標準”，並且Kubernetes對外一直是1.XY——其中X每季度增加一次，Y由社群的集體性突發奇想決定。請牢記：被貢獻者社群稱為“minor”的釋出可能會對運維和使用叢集的體驗產生巨大的（通常是積極的）影響。
Kubernetes歷史版本
自2015年夏天，Kubernetes已經發布了九個“minor”版本。
通過檢視新聞稿和git標籤，你會發現釋出基本遵守每季度或大約每一百天的節奏。
Kubernetes ReleaseDateCadence
Christening of 1.010th July 2015~one year from inception
From 1.0 to 1.19th November 2015122 days
From 1.1 to 1.216th March 2016128 days
From 1.2 to 1.31st July 2016107 days
From 1.3 to 1.426th September 201687 days
From 1.4 to 1.512th December 201677 days
From 1.5 to 1.628th March 2017106 days
From 1.6 to 1.730th June 201794 days
From 1.7 to 1.828th September 201790 days
From 1.8 to 1.915th December 201778 days
From 1.9 to 1.10ETA mid-March 2018~100 days
Kubernetes功能開發流程
Kubernetes二進位制元件的釋出本身沒什麼意思。真正有意思的是它的RESTful API代表的“基礎結構”。
Kubernetes的每個部分都使用定義良好的API與其他部分進行通訊。把這個API想成Kubernetes的心臟，它被“不斷跳動”的一系列元件包起來，將“氧氣”輸送到宣告式配置模式中。 “核心”所做的是協調叢集當前狀態與所需狀態。
API不斷髮展和改進，因為基礎設施編碼人員無休止地要求將越來越多的傳統資料中心構建塊抽象為可用的Kubernetes API端點。這些附加的Kubernetes功能（API）受貢獻者的熱情和更大的社群利益驅動，從alpha成長為beta。
Kubernetes的創始人專門設計了API版本控制和棄用標準來處理這種持續性的演變。與釋出的版本控制文件類似，關於開發人員和終端使用者應該期待的功能有更長期的策略。
這就是說，每個Kubernetes釋出中重要的不是釋出本身，而是API從“alpha”到“beta”到“stable”的細節。你甚至可以檢視更改日誌，找到哪些引數欄位被新增或刪除等詳細資訊。
雖然在Kubernetes進化過程中出現了一些明顯的錯誤，並且等待API物件從alpha或beta階段畢業很漫長，但穩定的API堅如磐石。
與Ubuntu LTS或RHEL相比
RedHat Enterprise Linux有著十年的長期支援保證。Ubuntu是五年。CoreOS的口號是“自動更新”。
主要雲提供商及其“託管Kubernetes平臺”，會負責為使用者控制更新。因此，Kubernetes平臺供應商神奇地處理了向後不相容的遷移或在上游Kubernetes API中的強制遷移。Kubernetes即服務產品，特別是Google Cloud的Kubernetes引擎（GKE），是目前最穩定和最適合生產環境的Kubernetes版本的領頭羊。
Kubernetes社群支援模式
前面所說的釋出版本控制設計提案指出，使用者需要保持“其在生產中使用的Kubernetes版本的合理更新”。另一個關鍵點是上游Kubernetes社群一次支援最多三個“minor” Kubernetes版本。實際上，1.X中的X很重要，三個minor的策略意味著在1.8釋出後，Kubernetes 1.5就不在SIG釋出的範圍之內了。也就是說，如果你在去年3月份Kubernetes 1.6推出後不久就部署了Kubernetes 1.6叢集，那麼在大約九個月內也就是十二月中旬1.9釋出時你得升級到1.7。
Kubernetes的釋出節奏和短暫的上游支援視窗會不會對專案造成傷害？老實說，從終端使用者的角度來看，並沒有很大的影響。如果你深入瞭解SIG會議記錄、Github事項、設計建議和郵件列表，你會發現社群對長期支援的共識仍在不斷變化。而且，也許正是如此，儘可能長期地保持上游專案的靈活性是非常有意義的。當已經發布的核心API原語大部分保持不變，或者很少出現向後不相容的更改時，為什麼要對“vanilla”Kubernetes版本進行人為約束呢？
從實踐和實際情況來看，對較早Kubernetes版本的支援，真正重要的是端到端測試管道的持續可用性和使用。
更新Kubernetes叢集
關於編排器的一個神奇的事情是它們（或它們的配置檔案）不可避免地變得幾乎圖靈完備。如果你有大的、有不同型別工作負載的Kubernetes叢集，那麼你會想要一個擁有Alan Turing級別Kubernetes智慧的SRE，以確保更新順利進行。
自主託管Kubernetes叢集想法的支持者將圖靈策略更進一步，並且正朝著叢集可以自主管理的概念發展。
雖然Kubernetes可靠提供的基本API正在成為各種分散式系統問題解決方案的關鍵構建模組，有人對“自主驅動，自主託管”叢集的概念表示質疑。
即使是社群認可的管理工具和安裝程式，也尚未實現企業級、高可用性的Kubernetes部署。Google Cloud本身將其GKE Kubernetes即服務控制面板與實時遷移的外部虛擬化VM一起執行，以避免元件故障（而不是叢集控制面板中的“自主驅動”）。
一個可行的策略是部署後就不管Kubernetes了，祈禱底層作業系統或Docker本身的bug不用你插手。對於面向內部的叢集，“延期維護”策略對許多早期採用者來說完全有效。
將Kubernetes工作負載遷移到新的叢集而不是更新
因此，更新叢集最可靠的策略是：如果你無法逐步更新Kubernetes控制面板（及其各種元件），你可以用外部負載路由逐步將舊叢集的負載遷移到新叢集。或者，即使你逐步就地更新，也要在嘗試階躍式遷移之前在新叢集上執行舊負載以確保更新的可靠性。
DIY Kubernetes的最佳替代
執行Kubernetes應用程式的最安全的地方仍然是谷歌的GKE。谷歌創造了Kubernetes，谷歌的SRE文化證明了它可以成功執行大型分散式系統。
如果你在GKE尚未存在的地方需要叢集（如rpi3），怎麼辦？
這可能是Kubernetes社群，特別是供應商最令人著迷的地方。現在至少有二十多個可行的Kubernetes發行版。就像Uber或InstaCart的複本一樣，它們是為了迎合細分市場而設計的。
那麼在你意識到kops叢集中的每個pod都具有對控制面板有root訪問許可權後，你會怎麼做？找到你最喜歡的VAR，並以任何形式要求vanilla Kubernetes，這是合理的跟上節奏和處理更新的方法。然後你要做的就是專注於構建產品。
關於Kubernetes釋出的最後思考
Kubernetes和分散式系統的“民主化”會持續下去。儘管跟上變化的步伐是困難的，但你還是得努力去做。
如果SIG停擺，谷歌的工程團隊被歐盟監管機構的反壟斷摧毀，我們仍然會在很長的時間內使用並熱愛Kubernetes v1.X。貢獻者和領導團體一直在討論穩定與速度之間的平衡。如果你還有什麼疑問，可以去看看最近的Kubecon上Brendan Burn（https://www.youtube.com/watch?v=gCQfFXSHSxw）的主題演講。
本文轉移K8S技術社群-ofollow,noindex">Kubernetes新版本又來了 如何跟上變化“合理更新”？