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分支中汲取了足夠多的經驗教訓。
如果你進入這一領域較晚，你可以查看近三年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功能開發流程
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）的主題演講。
TAG:K8S技術社區 |