Kubernetes新版本又來(lái)了 如何跟上變化“合理更新”？

Kubernetes LTS并不存在? ?



每三個(gè)月發(fā)布一個(gè)“vanilla”上游Kubernetes的1.xx“minor”版本，這種節(jié)奏可能會(huì)永遠(yuǎn)持續(xù)下去。你必須跟上，同時(shí)也要密切關(guān)注Kubernetes
API對(duì)象版本控制。這種堅(jiān)定的步伐是Kubernetes統(tǒng)治分布式基礎(chǔ)設(shè)施領(lǐng)域的關(guān)鍵因素。

何為Kubernetes發(fā)布周期？


我們與那些希望利用Kubernetes（特別是DIY部署）的人交談時(shí)遇到的問(wèn)題之一，就是“你們?nèi)绾伪３滞?？?br>
這帶來(lái)了對(duì)以下問(wèn)題的好奇：

誰(shuí)在管理Kubernetes社區(qū)項(xiàng)目？
它們的發(fā)布周期和質(zhì)量有多一致？
像Debian、Ubuntu或RHEL一樣，Kubernetes是否有長(zhǎng)期支持版本，即Kubernetes LTS？
每次發(fā)布新的Kubernetes版本時(shí)，集群維護(hù)人員或產(chǎn)品負(fù)責(zé)人需要做什么才能跟上？
集群不用最新版本時(shí)會(huì)發(fā)生什么？
它們是繼承管理Kubernetes的任務(wù)的合理替代嗎？
如果答案僅僅是“云”，那么使用“認(rèn)證”Kubernetes平臺(tái)可以安全而不被鎖定嗎？

讓我們深入了解Kubernetes和這個(gè)項(xiàng)目背后的故事。

Kubernetes的由來(lái)



谷歌內(nèi)部Kubernetes最早的管理人員圍繞該項(xiàng)目建立了一個(gè)強(qiáng)大的開(kāi)放社區(qū)，從Linux內(nèi)核項(xiàng)目、Mozilla、Openstack、Chrome甚至node.js分支中汲取了足夠多的經(jīng)驗(yàn)教訓(xùn)。

commit 2c4b3a562ce34cddc3f8218a2c4d11c7310e6d56
Author: Joe Beda <[email protected]>Date: Fri Jun 6 16:40:48 2014
-0700

First commit

如果你進(jìn)入這一領(lǐng)域較晚，你可以查看近三年Techcrunch上關(guān)于Kubernetes 1.0版本的文章。

領(lǐng)導(dǎo)Linux基金會(huì)的開(kāi)源社區(qū)構(gòu)建積極分子Jim Zemlin是名副其實(shí)的硅谷算命先生，“我預(yù)測(cè)，這項(xiàng)技術(shù)好得讓人無(wú)法抗拒，現(xiàn)在沒(méi)有參與的人以后會(huì)改變主意?！?br>
即使Bryan Cantrill（Joyent首席技術(shù)官和unix天才），在見(jiàn)證了Kubernetes的誕生之后，也承認(rèn)自己之前的開(kāi)源觀點(diǎn)有失偏頗。


Kubernetes成功的另一個(gè)秘密和主要原因是CNCF在Apache-2.0下發(fā)布它，這是一個(gè)有爭(zhēng)議的開(kāi)源許可（有人說(shuō)它是長(zhǎng)久以來(lái)科技巨頭之間商業(yè)軟件專(zhuān)利冷戰(zhàn)的解藥）。

如果你直接問(wèn)Jim Zemlin這一切有什么特別之處，他會(huì)談到讓Alphabet貢獻(xiàn)出Kubernetes的驚人法律壯舉——一切都在受專(zhuān)利保護(hù)的開(kāi)源許可之下！

伴隨著Kubernetes的發(fā)展，CNCF和Kubernetes的貢獻(xiàn)者們維持著一個(gè)以協(xié)作、開(kāi)放和自我反思著稱(chēng)的社區(qū)。該說(shuō)說(shuō)SIG（Special
Interest Group）了。

Kubernetes Special Interest Group



除了谷歌Brog十多年的積累和CNCF的帶領(lǐng)之外，驅(qū)動(dòng)Kubernetes發(fā)展的另一股力量是它的SIG模式。SIG是由技術(shù)上有共識(shí)的人組成的特別小組。它們采用與領(lǐng)先軟件公司中最好的團(tuán)隊(duì)相同的模式。最關(guān)鍵的，SIG負(fù)責(zé)管理端到端測(cè)試和CI
/
CD系統(tǒng)（這些系統(tǒng)嚴(yán)格執(zhí)行Kubernetes發(fā)布程序）。對(duì)邊緣的或更深?yuàn)W的部分感興趣的SIG隨工作進(jìn)展而增減，在特定區(qū)域出現(xiàn)。甚至還有一個(gè)整體的產(chǎn)品管理SIG，由頂尖的PM負(fù)責(zé)。


在理解Kubernetes發(fā)布周期的背景下，SIG和他們的工作組很有意思，因?yàn)轭I(lǐng)導(dǎo)力、節(jié)奏和長(zhǎng)期質(zhì)量等關(guān)鍵屬性都是SIG結(jié)構(gòu)的成果。想了解SIG如何與更廣泛的企業(yè)利益生態(tài)系統(tǒng)相互作用，可以聽(tīng)一下技術(shù)項(xiàng)目經(jīng)理兼SIG產(chǎn)品負(fù)責(zé)人Caleb
Miles的New Stack訪談。


SIG最棒的一點(diǎn)是，參與者和領(lǐng)導(dǎo)力的多樣性。然而，與別的流行的新興技術(shù)一樣，總有鞏固權(quán)力和影響路線圖的需要。收購(gòu)CoreOS后，紅帽現(xiàn)在“驕傲的是，紅帽工程師能夠主導(dǎo)或共同主導(dǎo)12個(gè)SIG。”目前還不清楚這是好是壞，但其后果值得觀察。

Kubernetes版本控制


Kubernetes發(fā)布的基本節(jié)奏是預(yù)期每三到四個(gè)月一次重要發(fā)布。Kubernetes Release
Versioning設(shè)計(jì)文檔有一些非常好的細(xì)節(jié)。雖然最初的動(dòng)力來(lái)自谷歌，但現(xiàn)在核心發(fā)布團(tuán)隊(duì)中的數(shù)十家科技公司輪番發(fā)力。


很多人會(huì)挑剔“vanilla”Kubernetes的質(zhì)量，因此任何發(fā)布目標(biāo)的共同管理者都有很大的自由度來(lái)改變?nèi)掌诨蛲七t未被相關(guān)SIG認(rèn)為就緒的pull請(qǐng)求。認(rèn)真看了版本控制文件的人會(huì)注意到，“目前沒(méi)有發(fā)布2.0.0的標(biāo)準(zhǔn)”，并且Kubernetes對(duì)外一直是1.XY——其中X每季度增加一次，Y由社區(qū)的集體性突發(fā)奇想決定。請(qǐng)牢記：被貢獻(xiàn)者社區(qū)稱(chēng)為“minor”的發(fā)布可能會(huì)對(duì)運(yùn)維和使用集群的體驗(yàn)產(chǎn)生巨大的（通常是積極的）影響。

Kubernetes歷史版本


自2015年夏天，Kubernetes已經(jīng)發(fā)布了九個(gè)“minor”版本。

通過(guò)查看新聞稿和git標(biāo)簽，你會(huì)發(fā)現(xiàn)發(fā)布基本遵守每季度或大約每一百天的節(jié)奏。
Kubernetes Release Date Cadence
Christening of 1.0 10th July 2015 ~one year from inception
From 1.0 to 1.1 9th November 2015 122 days
From 1.1 to 1.2 16th March 2016 128 days
From 1.2 to 1.3 1st July 2016 107 days
From 1.3 to 1.4 26th September 2016 87 days
From 1.4 to 1.5 12th December 2016 77 days
From 1.5 to 1.6 28th March 2017 106 days
From 1.6 to 1.7 30th June 2017 94 days
From 1.7 to 1.8 28th September 2017 90 days
From 1.8 to 1.9 15th December 2017 78 days
From 1.9 to 1.10 ETA mid-March 2018 ~100 days

Kubernetes功能開(kāi)發(fā)流程


Kubernetes二進(jìn)制組件的發(fā)布本身沒(méi)什么意思。真正有意思的是它的RESTful API代表的“基礎(chǔ)結(jié)構(gòu)”。


Kubernetes的每個(gè)部分都使用定義良好的API與其他部分進(jìn)行通信。把這個(gè)API想成Kubernetes的心臟，它被“不斷跳動(dòng)”的一系列組件包起來(lái)，將“氧氣”輸送到聲明式配置模式中。
“核心”所做的是協(xié)調(diào)集群當(dāng)前狀態(tài)與所需狀態(tài)。

API不斷發(fā)展和改進(jìn)，因?yàn)榛A(chǔ)設(shè)施編碼人員無(wú)休止地要求將越來(lái)越多的傳統(tǒng)數(shù)據(jù)中心構(gòu)建塊抽象為可用的Kubernetes
API端點(diǎn)。這些附加的Kubernetes功能（API）受貢獻(xiàn)者的熱情和更大的社區(qū)利益驅(qū)動(dòng)，從alpha成長(zhǎng)為beta。


Kubernetes的創(chuàng)始人專(zhuān)門(mén)設(shè)計(jì)了API版本控制和棄用標(biāo)準(zhǔn)來(lái)處理這種持續(xù)性的演變。與發(fā)布的版本控制文檔類(lèi)似，關(guān)于開(kāi)發(fā)人員和最終用戶應(yīng)該期待的功能有更長(zhǎng)期的策略。


這就是說(shuō)，每個(gè)Kubernetes發(fā)布中重要的不是發(fā)布本身，而是API從“alpha”到“beta”到“stable”的細(xì)節(jié)。你甚至可以查看更改日志，找到哪些參數(shù)字段被添加或刪除等詳細(xì)信息。

雖然在Kubernetes進(jìn)化過(guò)程中出現(xiàn)了一些明顯的錯(cuò)誤，并且等待API對(duì)象從alpha或beta階段畢業(yè)很漫長(zhǎng)，但穩(wěn)定的API堅(jiān)如磐石。

與Ubuntu LTS或RHEL相比


RedHat Enterprise Linux有著十年的長(zhǎng)期支持保證。Ubuntu是五年。CoreOS的口號(hào)是“自動(dòng)更新”。


主要云提供商及其“托管Kubernetes平臺(tái)”，會(huì)負(fù)責(zé)為用戶控制更新。因此，Kubernetes平臺(tái)供應(yīng)商神奇地處理了向后不兼容的遷移或在上游Kubernetes
API中的強(qiáng)制遷移。Kubernetes即服務(wù)產(chǎn)品，特別是Google
Cloud的Kubernetes引擎（GKE），是目前最穩(wěn)定和最適合生產(chǎn)環(huán)境的Kubernetes版本的領(lǐng)頭羊。

Kubernetes社區(qū)支持模式



前面所說(shuō)的發(fā)布版本控制設(shè)計(jì)提案指出，用戶需要保持“其在生產(chǎn)中使用的Kubernetes版本的合理更新”。另一個(gè)關(guān)鍵點(diǎn)是上游Kubernetes社區(qū)一次支持最多三個(gè)“minor”
Kubernetes版本。實(shí)際上，1.X中的X很重要，三個(gè)minor的策略意味著在1.8發(fā)布后，Kubernetes
1.5就不在SIG發(fā)布的范圍之內(nèi)了。也就是說(shuō)，如果你在去年3月份Kubernetes 1.6推出后不久就部署了Kubernetes
1.6集群，那么在大約九個(gè)月內(nèi)也就是十二月中旬1.9發(fā)布時(shí)你得升級(jí)到1.7。


Kubernetes的發(fā)布節(jié)奏和短暫的上游支持窗口會(huì)不會(huì)對(duì)項(xiàng)目造成傷害？老實(shí)說(shuō)，從最終用戶的角度來(lái)看，并沒(méi)有很大的影響。如果你深入了解SIG會(huì)議記錄、Github事項(xiàng)、設(shè)計(jì)建議和郵件列表，你會(huì)發(fā)現(xiàn)社區(qū)對(duì)長(zhǎng)期支持的共識(shí)仍在不斷變化。而且，也許正是如此，盡可能長(zhǎng)期地保持上游項(xiàng)目的靈活性是非常有意義的。當(dāng)已經(jīng)發(fā)布的核心API原語(yǔ)大部分保持不變，或者很少出現(xiàn)向后不兼容的更改時(shí)，為什么要對(duì)“vanilla”Kubernetes版本進(jìn)行人為約束呢？

從實(shí)踐和實(shí)際情況來(lái)看，對(duì)較早Kubernetes版本的支持，真正重要的是端到端測(cè)試管道的持續(xù)可用性和使用。

更新Kubernetes集群



關(guān)于編排器的一個(gè)神奇的事情是它們（或它們的配置文件）不可避免地變得幾乎圖靈完備。如果你有大的、有不同類(lèi)型工作負(fù)載的Kubernetes集群，那么你會(huì)想要一個(gè)擁有Alan
Turing級(jí)別Kubernetes智能的SRE，以確保更新順利進(jìn)行。

自主托管Kubernetes集群想法的支持者將圖靈策略更進(jìn)一步，并且正朝著集群可以自主管理的概念發(fā)展。

雖然Kubernetes可靠提供的基本API正在成為各種分布式系統(tǒng)問(wèn)題解決方案的關(guān)鍵構(gòu)建模塊，有人對(duì)“自主驅(qū)動(dòng)，自主托管”集群的概念表示質(zhì)疑。

即使是社區(qū)認(rèn)可的管理工具和安裝程序，也尚未實(shí)現(xiàn)企業(yè)級(jí)、高可用性的Kubernetes部署。Google Cloud本身將其GKE
Kubernetes即服務(wù)控制面板與實(shí)時(shí)遷移的外部虛擬化VM一起運(yùn)行，以避免組件故障（而不是集群控制面板中的“自主驅(qū)動(dòng)”）。


一個(gè)可行的策略是部署后就不管Kubernetes了，祈禱底層操作系統(tǒng)或Docker本身的bug不用你插手。對(duì)于面向內(nèi)部的集群，“延期維護(hù)”策略對(duì)許多早期采用者來(lái)說(shuō)完全有效。

將Kubernetes工作負(fù)載遷移到新的集群而不是更新



因此，更新集群最可靠的策略是：如果你無(wú)法逐步更新Kubernetes控制面板（及其各種組件），你可以用外部負(fù)載路由逐步將舊集群的負(fù)載遷移到新集群?；蛘?，即使你逐步就地更新，也要在嘗試階躍式遷移之前在新集群上運(yùn)行舊負(fù)載以確保更新的可靠性。

DIY Kubernetes的最佳替代


運(yùn)行Kubernetes應(yīng)用程序的最安全的地方仍然是谷歌的GKE。谷歌創(chuàng)造了Kubernetes，谷歌的SRE文化證明了它可以成功運(yùn)行大型分布式系統(tǒng)。

如果你在GKE尚未存在的地方需要集群（如rpi3），怎么辦？


這可能是Kubernetes社區(qū)，特別是供應(yīng)商最令人著迷的地方。現(xiàn)在至少有二十多個(gè)可行的Kubernetes發(fā)行版。就像Uber或InstaCart的復(fù)本一樣，它們是為了迎合細(xì)分市場(chǎng)而設(shè)計(jì)的。

那么在你意識(shí)到kops集群中的每個(gè)pod都具有對(duì)控制面板有root訪問(wèn)權(quán)限后，你會(huì)怎么做？找到你最喜歡的VAR，并以任何形式要求vanilla
Kubernetes，這是合理的跟上節(jié)奏和處理更新的方法。然后你要做的就是專(zhuān)注于構(gòu)建產(chǎn)品。

關(guān)于Kubernetes發(fā)布的最后思考


Kubernetes和分布式系統(tǒng)的“民主化”會(huì)持續(xù)下去。盡管跟上變化的步伐是困難的，但你還是得努力去做。

如果SIG停擺，谷歌的工程團(tuán)隊(duì)被歐盟監(jiān)管機(jī)構(gòu)的反壟斷摧毀，我們?nèi)匀粫?huì)在很長(zhǎng)的時(shí)間內(nèi)使用并熱愛(ài)Kubernetes
v1.X。貢獻(xiàn)者和領(lǐng)導(dǎo)團(tuán)體一直在討論穩(wěn)定與速度之間的平衡。如果你還有什么疑問(wèn)，可以去看看最近的Kubecon上Brendan
Burn（https://www.youtube.com/watch?v=gCQfFXSHSxw）的主題演講。

本文轉(zhuǎn)移K8S技術(shù)社區(qū)-Kubernetes新版本又來(lái)了 如何跟上變化“合理更新”？
<https://yq.aliyun.com/go/articleRenderRedirect?url=http%3A%2F%2Fk8s.cn%2Findex.php%2F2018%2F03%2F09%2F762%2F>

• ? 上一篇： 在Flutter中嵌入Native組件的正確姿勢(shì)是...
• ? 下一篇： 分享 KubeCon 2019 （上海）關(guān)于 Serverless 及 Knative 相關(guān)演講會(huì)議