蜜桃av色欲a片精品一区,麻豆aⅴ精品无码一区二区,亚洲人成网站在线播放影院在线,亚洲 素人 字幕 在线 最新

  K8s 為什么這么復雜

發(fā)布日期：2022/2/11 18:46:47      瀏覽量：

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

    近日，在國外知名的技術論壇網站Hacker News上，就有一位用戶對Kubernetes為什么這么復雜做出了自己的見解。

為什么Kubernetes這么復雜？

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

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

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

• 資源共享——將一臺物理計算機的資源細分給多個程序，使它們在某種程度上相互隔離；

• 可移植性——在一定程度上抽象出底層硬件的精確細節(jié)，這樣同一程序就可以在不同的硬件上運行而無需修改，或者只需稍加修改；

• 通用性——當有新的硬件插入計算機時，能夠以漸進的方式將這些硬件納入抽象和接口，最好是在不大幅改變任何接口或破壞任何不使用該硬件的現(xiàn)有軟件的情況下。

• 整體性——與通用性相關，操作系統(tǒng)能夠調解對硬件的所有訪問：軟件應該很少或者不可能完全繞過操作系統(tǒng)的內核。軟件可以使用操作系統(tǒng)內核來建立與硬件的直接連接，從而使未來的交互直接發(fā)生（例如建立一個內存映射的命令管道），但最初的分配和配置仍然在操作系統(tǒng)的監(jiān)督之下。

• 性能——與 "直接編寫一個特殊用途的軟件，直接在硬件上運行，并對硬件有獨占的直接訪問權（如unikernel）”相比，希望擁有這種一個可接受的小的性能成本。在某些情況下，通過提供像I/O調度器或緩存層這樣的優(yōu)化，在實踐中達到比這樣的系統(tǒng)更高的性能。

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

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

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

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

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

    想象一個非常必要的 "集群操作系統(tǒng)"，就像上面描述的那樣，它暴露了 "分配5個CPU的計算量 " 或 "創(chuàng)建一個新的虛擬網絡 "這樣的基元，這些基元反過來又支持系統(tǒng)內部抽象的配置變化或對EC2 API（或其他基礎云提供商）的調用。

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

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

    然而，這種設計也帶來了系統(tǒng)的復雜性和一定幾率的混亂。挑兩個具體的例子。

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

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

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

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

    以上就是來自Hacker News的博主分享的他對Kubernetes為什么這么復雜的看法。該博主認為，對Kubernetes本身、其復雜性以及對其服務的目標有個很好地理解，是一件非常有意義的事。希望這篇文章對剛開始使用Kubernetes的人能有一定幫助。

    https://buttondown.email/nelhage/archive/two-reasons-kubernetes-is-so-complex/