這幾年云原生的熱度久高不下，許多大廠紛紛擁抱云原生。提到云原生，不少開發(fā)者可能會(huì)想到Kubernetes，也稱為K8s，是一個(gè)用于自動(dòng)部署、擴(kuò)展和管理“容器化（containerized）應(yīng)用程序”的開源系統(tǒng)。作為云原生的重要代表之一，它真的很不錯(cuò)。但也有不少開發(fā)者抱怨Kubernetes太復(fù)雜了。

近日，在國(guó)外知名的技術(shù)論壇網(wǎng)站Hacker News上，就有一位用戶對(duì)Kubernetes為什么這么復(fù)雜做出了自己的見(jiàn)解。

為什么Kubernetes這么復(fù)雜？

Kubernetes相比其他系統(tǒng)來(lái)說(shuō)，確實(shí)要更大，更復(fù)雜。相信不少人在使用它的過(guò)程中都曾試圖了解它為什么這樣。該用戶也是這樣，并將自己的理解寫了出來(lái)。

Kubernetes是一個(gè)集群操作系統(tǒng)

Kubernetes更像是一個(gè)通用的集群操作系統(tǒng)內(nèi)核。傳統(tǒng)操作系統(tǒng)的工作是將一臺(tái)計(jì)算機(jī)及其所有相關(guān)硬件的接口暴露出來(lái)，讓應(yīng)用程序可以訪問(wèn)這些接口。具體細(xì)節(jié)我們不明確，但這些接口都有相應(yīng)的設(shè)計(jì)目標(biāo)。

• ? ? 資源共享——將一臺(tái)物理計(jì)算機(jī)的資源細(xì)分給多個(gè)程序，使它們?cè)谀撤N程度上相互隔離；
• ? ? 可移植性——在一定程度上抽象出底層硬件的精確細(xì)節(jié)，這樣同一程序就可以在不同的硬件上運(yùn)行而無(wú)需修改，或者只需稍加修改；
• ? ? 通用性——當(dāng)有新的硬件插入計(jì)算機(jī)時(shí)，能夠以漸進(jìn)的方式將這些硬件納入抽象和接口，最好是在不大幅改變?nèi)魏谓涌诨蚱茐娜魏尾皇褂迷撚布默F(xiàn)有軟件的情況下。
• ? ? 整體性——與通用性相關(guān)，操作系統(tǒng)能夠調(diào)解對(duì)硬件的所有訪問(wèn)：軟件應(yīng)該很少或者不可能完全繞過(guò)操作系統(tǒng)的內(nèi)核。軟件可以使用操作系統(tǒng)內(nèi)核來(lái)建立與硬件的直接連接，從而使未來(lái)
• 的交互直接發(fā)生（例如建立一個(gè)內(nèi)存映射的命令管道），但最初的分配和配置仍然在操作系統(tǒng)的監(jiān)督之下。
• ? ? 性能——與 "直接編寫一個(gè)特殊用途的軟件，直接在硬件上運(yùn)行，并對(duì)硬件有獨(dú)占的直接訪問(wèn)權(quán)（如unikernel）”相比，希望擁有這種一個(gè)可接受的小的性能成本。在某些情況下，通過(guò)提供像I/O調(diào)度器或緩存層這樣的優(yōu)化，在實(shí)踐中達(dá)到比這樣的系統(tǒng)更高的性能。

操作系統(tǒng)內(nèi)核通常是圍繞上述目標(biāo)設(shè)計(jì)，然后編寫用戶空間庫(kù)，將低級(jí)的、通用的、高性能的接口包裝成更容易使用的抽象概念。操作系統(tǒng)開發(fā)者往往更關(guān)心的是怎么讓應(yīng)用運(yùn)行的更快，而不是應(yīng)用在我的系統(tǒng)上運(yùn)行時(shí)代碼更少。

Kubernetes與上述設(shè)計(jì)理念非常類似，它的目標(biāo)是抽象出一整個(gè)數(shù)據(jù)中心或云。這個(gè)觀點(diǎn)有助于理解Kubernetes。它指出了Kubernetes為什么非常靈活。Kubernetes希望自己能擁有普遍性并獲得更強(qiáng)大的功能，它能夠在任何類型的硬件或虛擬機(jī)實(shí)例上部署任何類型的應(yīng)用程序。并且還不需要脫離Kubernetes的界面。不論它是否真的能實(shí)現(xiàn)這一目標(biāo)，這樣的設(shè)計(jì)都很有意義。

上述視角所解釋的設(shè)計(jì)選擇是Kubernetes的可插拔性和可配置性。一般來(lái)說(shuō)，在不付出奢侈的性能成本下，做不到對(duì)所有人都適用的選擇。在現(xiàn)代云環(huán)境中，應(yīng)用程序的類型和部署的硬件類型有很大不同，尤其是要求可以在不同位置快速部署時(shí)。這也就意味著，如果一個(gè)系統(tǒng)想讓所有人都適用，它就需要強(qiáng)大的快速配置性能。做到這一點(diǎn)確實(shí)會(huì)搭建出一個(gè)強(qiáng)大的系統(tǒng)，但缺點(diǎn)就是它會(huì)變得非常復(fù)雜。

許多用戶認(rèn)為Kubernetes本質(zhì)上是一個(gè)“Heroku”，即作為一個(gè)部署應(yīng)用程序的平臺(tái)，去抽象出大多數(shù)傳統(tǒng)的底層操作系統(tǒng)和分布式系統(tǒng)的細(xì)節(jié)。Kubernetes認(rèn)為自己解決的問(wèn)題更接近于 "CloudFormation"，在這個(gè)意義上，它希望足以定義整個(gè)基礎(chǔ)設(shè)施，它還試圖以一種在底層云提供商或硬件上都通用的方式做到這一點(diǎn)。

Kubernetes中的一切是一個(gè)控制循環(huán)

想象一個(gè)非常必要的 "集群操作系統(tǒng)"，就像上面描述的那樣，它暴露了 "分配5個(gè)CPU的計(jì)算量 " 或 "創(chuàng)建一個(gè)新的虛擬網(wǎng)絡(luò) "這樣的基元，這些基元反過(guò)來(lái)又支持系統(tǒng)內(nèi)部抽象的配置變化或?qū)C2 API（或其他基礎(chǔ)云提供商）的調(diào)用。

但Kubernetes并非是這樣進(jìn)行工作的，相反，Kubernetes的核心設(shè)計(jì)決定了所有的配置都是聲明性的，并且都是通過(guò)作為控制循環(huán)"操作者 "的方式實(shí)現(xiàn)。他們不斷地將期望的配置與現(xiàn)實(shí)的狀態(tài)進(jìn)行比較，并修改現(xiàn)實(shí)狀態(tài)，達(dá)到與期望狀態(tài)一致。

這是一個(gè)非常慎重且理由充分的設(shè)計(jì)抉擇。一般來(lái)說(shuō)，任何沒(méi)有被設(shè)計(jì)成控制循環(huán)的系統(tǒng)都將不可避免地偏離期望配置，因此，需要有人來(lái)編寫控制循環(huán)并通過(guò)內(nèi)部化來(lái)進(jìn)行控制。Kubernetes希望能讓大多數(shù)核心控制環(huán)路只寫一次，而且是由領(lǐng)域?qū)＜襾?lái)寫，從而使在其上構(gòu)建可靠的系統(tǒng)變得更加容易。這也是一個(gè)系統(tǒng)的自然選擇，因?yàn)樗谋举|(zhì)是分布式的，而且是為構(gòu)建分布式系統(tǒng)而設(shè)計(jì)的。分布式系統(tǒng)的決定性性質(zhì)是排除部分可能性的故障，這就要求超過(guò)一定規(guī)模的系統(tǒng)能夠自我修復(fù)，并收斂于正確的狀態(tài)，而不考慮局部故障。

然而，這種設(shè)計(jì)也帶來(lái)了系統(tǒng)的復(fù)雜性和一定幾率的混亂。挑兩個(gè)具體的例子。

第一：錯(cuò)誤延遲， 在Kubernetes中創(chuàng)建一個(gè)對(duì)象（例如一個(gè)pod），這只是在配置存儲(chǔ)中創(chuàng)建一個(gè)對(duì)象，斷言該對(duì)象的預(yù)期存在。如果由于資源限制（集群的容量），或者由于對(duì)象在某些方面內(nèi)部不一致（比如引用的容器鏡像不存在），系統(tǒng)在實(shí)際分配上不可能滿足該請(qǐng)求，但用戶在創(chuàng)建時(shí)無(wú)法看到系統(tǒng)的實(shí)際情況。事實(shí)上，只有當(dāng)開發(fā)者要修改創(chuàng)建對(duì)象時(shí)，系統(tǒng)才會(huì)產(chǎn)生錯(cuò)誤提示。

這種情況使得一切都更難調(diào)試和推理，因?yàn)槟悴荒苡?創(chuàng)建成功 "作為 "結(jié)果對(duì)象存在 "的一個(gè)速記。這也意味著，與失敗有關(guān)的日志信息或調(diào)試輸出信息不會(huì)出現(xiàn)在創(chuàng)建對(duì)象的進(jìn)程中。一個(gè)代碼完整，功能強(qiáng)大的控制器，系統(tǒng)會(huì)解釋正在發(fā)生的事情，或以其他方式注釋有問(wèn)題的對(duì)象；但對(duì)于較差的控制器，控制器的日志中只能找到日志垃圾。而且有些變化可能涉及到多個(gè)控制器，它們有時(shí)獨(dú)立行動(dòng)，有時(shí)聯(lián)合行動(dòng)，這就很難去追蹤發(fā)生故障的代碼。

聲明式的控制循環(huán)模式提供了一個(gè)隱含的承諾：用戶不需要擔(dān)心如何從狀態(tài)A到狀態(tài)B，只需要把狀態(tài)B寫進(jìn)配置數(shù)據(jù)庫(kù)，然后等待。當(dāng)它的代碼運(yùn)行良好時(shí)，從狀態(tài)A自然就進(jìn)入到狀態(tài)B了。這是一個(gè)巨大的簡(jiǎn)化。

但有時(shí)也會(huì)失誤，無(wú)法或需要等待很長(zhǎng)時(shí)間從狀態(tài)A到狀態(tài)B，即使?fàn)顟B(tài)B本身可以實(shí)現(xiàn)。這是一個(gè)罕見(jiàn)的例子，控制器的作者可能忘記實(shí)現(xiàn)它了。Kubernetes中的核心內(nèi)置基元經(jīng)過(guò)很多測(cè)試和使用，以此來(lái)一直保持正常工作。但當(dāng)用戶開始添加第三方資源，比如以管理TLS證書、云負(fù)載均衡器、托管數(shù)據(jù)庫(kù)或外部DNS名稱等去運(yùn)行系統(tǒng)時(shí)，程序就會(huì)偏離軌道，變得不能清楚的知道路徑是怎么經(jīng)過(guò)測(cè)試的。這個(gè)故障模式和延遲錯(cuò)誤一樣微妙。很難區(qū)分“變化被接受”和“變化永遠(yuǎn)不會(huì)被接受”的區(qū)別

結(jié)論

以上就是來(lái)自Hacker News的博主分享的他對(duì)Kubernetes為什么這么復(fù)雜的看法。該博主認(rèn)為，對(duì)Kubernetes本身、其復(fù)雜性以及對(duì)其服務(wù)的目標(biāo)有個(gè)很好地理解，是一件非常有意義的事。希望這篇文章對(duì)剛開始使用Kubernetes的人能有一定幫助。

參考鏈接：Two reasons Kubernetes is so complex ? Buttondown?