Borg Omega and kubernetes · Linux學習文檔

### :-: **Borg Omega and kubernetes**。最近新起了對于容器技術的廣泛興趣，在大型的Linux容器管理上，我們google已經有超過十年的經驗，并且已經構建過3個不同的容器管理系統，每一個系統都深刻的影響到了他的繼任者，盡管他們處于不同的目的開發，這篇文章描述了我們在開發過程中以及在操作中學習經驗。 ??第一個由google開發管理的容器系統我們內部稱為Borg，他被構建為管理長時運行服務，以及處理batch job。這兩個任務之前被兩個系統分開處理，一個叫babysister，一個叫Globe Work Queue。后者的架構強烈的影響了Borg，但主要關注點是batch job，兩者都早于Linux control group.Borg在這兩種類型的應用程序之間共享機器，以提高資源利用率并從而降低成本，之所以進行這種共享，是因為Linux內核中的容器支持。（事實上，大多數Kernel的容器代碼都是google貢獻的）。這在面向用戶的延遲敏感性任務與CPU需求型batch處理上開啟了更好的隔離。　　 ??隨著越來越多的應用在Borg之上被構建，我們的應用團隊與基礎設置團隊開發了一系列的工具與服務生態，這些系統提供了用于配置和更新作業的機制，預測資源需求，動態將配置文件推送到運行的作業，服務發現與負載均衡，自動伸縮，機器生命周期管理，配額管理，以及其他許多。這些生態的發展被來自于google內部不同的團隊所驅動。結果形成了一個異構的，ad-hoc的一個系統，Borg用戶不得不與之交互與配置。采用了幾種不同的配置語言與處理過程。因為Borg的規模是如此之大，功能又廣，健壯性又高因此它仍然是google內部最主要的容器。 Omega，borg的后代，處于改變Borg軟件生態系統的目地，他應用了許多Borg上被證明成功了的模式。但他是從頭開始構建的，具有更一致，更原則的體系結構。omega將集群的狀態存儲在基于Paxos的集中式面相事務的存儲中，該存儲由控制集群平面的不同部分（例如調度程序訪問），使用樂觀并發控制來處理偶爾的沖突，這種解耦使得Borgmaster的功能分解為獨立的組件并扮演為一個peer。而不是把每一個變化都匯集到整體的，集中化的master中。許多Omega的創新都被整合到了Borg中（包括多調度器）。 ??第三代googe開發的容器管理系統是kubernetes。它是在外部開發人員開始對Linux容器感興趣的環境中構思和開發的。google開發了一項銷售公共云基礎設置的業務，該業務不斷增長，與Borg和Omega形成鮮明地比的，kuberntes是開源的，后兩者完全作為google內部系統開發。像omega，kubernets的核心是共享持久存儲，組件監視相關對象的更改，對比omega,后者直接將存儲暴露給受信任的控制平面組件。kubernetes里的狀態只能通過一個指定的REST API去訪問，驗證，semantics, 與策略。支持多樣化的客戶端，更重要的是，更重要的是，Kubernetes的開發更加關注開發人員編寫在集群中運行的應用程序的體驗：其主要設計目標是使其易于部署和管理復雜的分布式系統，同時也使得容器的利用率提高。 這篇文章主要講述了google從Borg到Kubernetes的旅途以及從中獲取到的經驗。 ## **CONTAINERS** 早先時候，第一代容器僅僅提供了對于root文件系統的隔離（通過chroot），以及freeBSD jails擴展到了額外的namespace比如process IDs。Solaris 之后探索并開創了許多其他增強的功能。Linux控制集（Cgroup）采納了許多這樣的想法，并且一直發展持續到了今日。 容器提供的資源隔離使google的利用率明顯高于行業規范。例如，Borg使用容器在同一臺物理機器將延遲敏感性，面向對象用戶與Batch jobs置于一起。面向用戶的作業保留了比通常所需更多的資源，從而使它們能夠處理負載高峰和故障轉移，并且可以回收這些最未被使用的資源來運行批處理作業。容器提供了資源管理的工具使得這成為了可能。以及強大的內核級資源隔離，以防止進程相互干擾。 我們通過Borg的開發與增強Linux容器來達到這一點。隔離并不完美，容器無法阻止操作系統內核無法管理的資源受到干擾。例如三級處理器緩存與內存寬帶。容器需要被另外的安全層支持（比如：虛擬機）以防止在云中發現的各種惡意行為。 現代化的容器不僅僅是一個隔離機制。他同樣包括了一個Image-一個在容器內部組成應用程序的文件，在google，MPM（Midas Package Manager）被用來構建和部署容器鏡像。隔離機制與MPM之間的共生關系與Docker daemon和Docker image registry相似。在這篇文章的剩余部分我們使用容器來包含這諸多方面：運行時隔離與鏡像。 ## **APPLICATION-ORIENTED INFRASTRUCTURE：** 隨著時間的推移，集裝箱化的好處越來越明顯，不僅僅是提高利用率。容器話將面向機器的方向轉變為面向應用程序的方向。本節討論了兩個實例： ●容器封裝應用程序環境，從應用程序的開發與基礎設施的部署中抽象出了許多機器與操作系統的細節。 ●因為設計良好的容器和容器映像的范圍僅限于單個應用程序，許多容器意味著管理應用而不是機器，這種從面向機器到面向應用程序的管理API的移動極大的改善了應用程序的部署與自檢。 ## **應用程序環境** 內核中的cgroup，chroot，和namespace的功能最初是為了保護應用程序不受干擾，以及其他不良的影響。將他們與容器鏡像結合在一起創建了一個抽象，該抽象也將應用程序與（異構）運行于其上的操作系統隔離開來。映像和OS的這種解耦使得可以在開發和生產中提供相同的部署環境，從而通過減少不一致和摩擦來提高部署可靠性并加快開發速度。實現這種抽象的關鍵是有一個密封的容器映像，它可以將應用程序的幾乎所有依賴項封裝到可以部署到容器中的包中。如果這被正確的操作了，那么剩下的外部依賴就只是本地Linux內核的系統調用接口了。盡管這種接口的限制性極大的提高了容器的可移植性，但他并不完美，應用程序仍然會暴露在操作系統混亂的接口中。特別是套接字選項暴露的大片區域，/proc，以及對于ioctl的參數調用，我們的目標是不斷的努力使得開發容器計劃以后會統一容器抽象的表面區域。 ??這里有許多的方法實現密閉的鏡像。在Borg里面，程序的二進制文件在構建靜態鏈接時鏈接到公司范圍內的有效版本庫中。即使如此，Borg的容器鏡像并不像本來的那樣封閉。應用程序共享一個所謂的基本映像，該映像只在機器上安裝一次，而不是打包在每個容器中。這個基礎鏡像包含例如tar與libc庫文件。因此，對基本鏡像的升級可能會影響運行的應用程序，有時還會造成很大的麻煩。 ??許多現代化的容器鏡像格式例如Docker與ACI，進一步加強了這種抽象，并通過消除隱式的主機操作系統依賴和要求顯式的用戶命令來共享容器之間的映像數據，使之更接近于密封的理想狀態（More modern container image formats such as Docker and ACI harden this abstraction further and get closer to the hermetic ideal by eliminating implicit host OS dependencies and requiring an explicit user command to share image data between containers.）。（這一句話就是一段。。） ## **容器作為管理單元** 圍繞容器而不是機器構建管理API，將數據中心的“主鍵”從機器轉移到應用程序。這有許多好處，它使應用程序開發人員和操作團隊不必擔心機器和操作系統的特定細節；它使基礎架構團隊能夠靈活地推出新硬件和升級操作系統，而對運行中的應用程序及其開發人員的影響最小；它將管理系統收集的遙測數據(例如CPU和內存使用等指標)與應用程序而不是機器聯系起來，這極大地改善了應用程序的監視和自檢。特別是在伸縮性，機器故障，或者維護造成的應用程序實例移動。容器提供了方便的點去注冊通用API，在系統管理與應用程序之間開啟信息的流動而不用知道太多關于其他特別的實現。在Borg，這個API是一系列附在每一個容器上的HTTP端點。例如 /healthz 端點報告應用程序的狀況給調度器。當檢測到一個不健康的應用程序時，它自動終結并重啟它。這種自修復是可靠分布式系統的關鍵構建點。（kubernetes提供相似的功能，健康檢查采用一個用戶指定的HTTP端點或者exec命令在容器里運行。） 額外的信息可以被容器提供或者為容器提供并顯示各種用戶接口。例如：Borg提供一種動態更新的簡單的文字狀態信息。kubernetes提供存儲在每一個對象的元數據下的備注，用于傳達應用程序結構。這種備注可以被容器自身或者管理系統中的其他參與者設置。（例如，該過程推出了容器的更新版本。） 另一方面，容器管理可以將信息傳遞到容器比如資源限制。容器元數據，用過傳播到日志記錄和監控，（例如,用戶名，job那么，身份。）以及在節點維護之前提供正常終止警告的通知。 　　容器還可以通過其他方式提供面向應用程序的監視，Linux Kernel cgroup 提供關于應該用程序的資源利用率數據。并且這些可以通過使用HTTP API導出的自定義指標進行擴展，如前面描述的那樣，利用這些數據，可以開發通用工具，例如自動縮放器或cAdvisor3，這些工具可以記錄和使用指標，而無需了解每個應用程序的細節。因為容器就是應用程序，there is no need to (de)multiplex signals from multiple applications running inside a physical or virtual machine.。（無需對來自物理或虛擬機中運行的多個應用程序的信號進行（解復用）。）這更簡單，更強大，并允許更精細的報告控制指標與日志。相比于通過ssh登錄到一臺機器上運行top，盡管開發人員有可能需要ssh進他們的容器中，但他們很少需要這樣做。 　　監視方式是一個例子，面向應用程序的轉變對整個管理基礎架構都有連鎖反應。我們的負載均衡并不能平衡計算機之間的流量。他們在應用程序的實例間保持平衡，日志由應用程序鍵入，而不是機器，因此可以輕松地跨實例收集和聚合它們，而不會受到多個應用程序或系統操作的污染。We can detect application failures and more readily ascribe failure causes without having to disentangle them from machine-level signals.從根本上講，由于容器管理器管理的實例的身份與應用程序開發人員期望的實例的身份完全一致，這使得構建管理，調試，都變得更加容易。 　　最后，盡管到目前為止我們將注意力們集中在應用程序域容器比例在1：1上，in reality we use nested containers that are co-scheduled on the same machine:（實際上，我們使用在同一臺機器上共同調度的嵌套容器。）最外層提供有一個資源池，內部提供部署隔離，在Borg，最外層的容器被稱作一個資源分配，or alloc，在kubernetes里，這被稱作pod，Borg同樣允許高層的應用程序容器運行在allocs外面。這同樣帶來了很多的不方便，因此Kubernetes規范化了事情并總是讓應用程序容器運行在頂層的pod中，即使這個pod只包含一個容器。 　　對于pod來說一個常用的使用模式是保存一個復雜的應用程序實例。應用程序的主要部分位于一個字容器中。其他子容器則運行支持功能比如日志切割或者將日志卸載到分布式系統中。與將功能組合到單個二進制文件相比，這使得不同的團隊開發不同的功能時變得更加容易。同時這也提高了健壯性，（即使主應用層序被wedged了卸載仍然會繼續），可組合性，（可以很輕松的添加一個新的小型支持服務），因為這個操作是在由容器自身提供的私有環境當中，和細粒度的資源隔離（每一個都運行它自己資源，每個應用程序都在自己的資源中運行，因此日志記錄系統不會餓死主應用程序，反之亦然） 　 ## **Orchestration is the beginning, not the end（編排是開始，而不是結束），** 原始的Borg系統在共享的機器上運行不同的工作負載成為可能，這提高了資源利用率。同時迅速發展的Borg生態系統支持服務，但是，表明容器管理本身僅僅是開發和管理可靠的分布式系統的環境的開始。在Borg上和周圍建立了許多不同的系統，以改進Borg提供的基本容器管理服務。以下列出了它們大致的范圍與種類。 ●　命名與服務發現（Borg命名服務，或者BNS）。 ●　Master選定，使用Chubby。 ●　應用感知負載平衡。 ●　水平（實例數量）和垂直（實例大小）自動縮放。 ●　推出新的工具管理謹慎的部署新的二進制文件與配置數據。 ●　工作流程工具，（允許在相互依賴的階段之間運行多作業的分析管道。） ●　監視工具收集容器信息，聚合，呈現在控制面板上，同時觸發警告。 　　這些服務是有機構建的，旨在解決應用程序團隊遇到的問題。成功的版本被采納，被廣泛使用，并使其他開發人員的生活更加輕松，不幸的是，這些工具通常選擇特殊的api，約定(如文件位置)，Borg整合的深度，意外的副作用是增加了在Borg生態系統中部署應用程序的復雜性。Kubernetes試圖通過對其API采用一致??的方法來避免這種增加的復雜性。例如，每一個kubernetes目標有三個基礎字段的描述：對象元數據，規范與狀態。 　　系統中所有對象的對象元數據都相同；它包含對象名稱、UID(唯一標識符)、對象版本號(用于樂觀并發控制)、和標簽（鍵值對，請參見下文）。規格和狀態的內容因對象類型而異，但他們的概念并不是：Spec用于描述對象的所需狀態，而Status提供有關對象當前狀態的只讀信息。 　　統一的API提供了許多的好處，學習系統更簡單，相似的信息應用到所有的對象上，編寫跨所有對象的通用工具更加簡單了。同時這也提升了用戶體驗。從Borg與Omega當中學習，Kubernetes是由一組可組合的構建基塊構建的，用戶可以輕松地對其進行擴展。通用的API和對象元數據結構使這一過程變得更加容易。例如，人們可以使用pod API，kubernetes內部組件，以及外部的自動化工具，為了對一致性更進一步，kubernetes將會擴展到開啟動態的添加用戶自己的API。alongside the core Kubernetes functionality。還可以通過Kubernetes API中的解耦來實現一致性。API組件之間分離的關注點是更高級別的服務都共享相同的公共基本構建塊。這方面分離的一個例子是Kubernetes的replication 控制器與水平自動縮放系統。一個復制控制器確保給定角色的現有的pods數量等于所需的（比如前端）。反過來，自動擴縮器，依靠此功能，只需要簡單的調整所需要的pods數量。而不動擔心pod如何被創建于刪除。自動縮放其道實施可以著重于需求和使用情況的預測。以及忽略如何去實施決策的細節。 　　解耦確保多個相互關聯卻不同的組件共享一個相似的外觀，例如，kubernetes具有三種不同形式的復制pod， ReplicationController:永久運行的復制容器。 DaemonSet:在集群上確保每一個節點的單一實例。 Job:一個直到運行完成的控制器，知道如何從運行從開始到結束（可能是并行的）。 　　盡管是三種不同的策略，但這三種控制器依靠的都是公共的pod對象去指定他們要在哪些容器上運行。對于不同的kubernetes組件一致性同樣通過公共設計模式實現。The idea of a reconciliation controller loop is shared throughout Borg, Omega, and Kubernetes to improve the resiliency of a system:相比于一個所需的狀態，（例如：多少個pod應該與標簽選擇器查詢匹配。）對比觀察到的狀態。（可以被找到的這樣的pod數量。）并對所觀察到的狀態和所需狀態采取行動。因為所有的行為都基于觀察而不是狀態圖，調節循環對故障和擾動具有健壯性：當控制器故障或者重啟時，他簡單的又從上次失效的地方開始。Kubernetes設計為微服務和小型控制循環的結合，是通過編排進行控制的一個示例-通過組合寫作的各個獨立實體的效果來實現所需的緊急行為。預計集中式的編排系統相比，這是一個有意識的設計選擇。剛開始時可能更容易構建，但隨著時間的流逝會變得脆弱而僵化，尤其是在出現意外錯誤或狀態變化的情況下。 ## 　　**需要避免的事情** 在開發這些系統時，我們學到了幾乎不值得做的事情，我們把它共享在這里，方便其他人能夠犯新的錯誤而不是重復我們這些。 ??不要讓容器系統管理端口號，所有在Borg上的容器系統都共享了主機的IP地址，因此Borg會在調度過程中為容器分配唯一的端口號，當容器移動到一個新的機器時他會得到一個新的端口號，（有時候）當他相同的機器上重啟了，這意味著傳統的網絡服務比如DNS必須替換掉通過home-brew versions;service clients do not know the port number assigned to the service a priori and have to be told;（服務器并不知道分配給服務的端口號，這必須被告知），端口號不能被嵌入到URL中，需要name-base的重定向機制，需要重寫依賴于簡單IP地址的工具，以處理IP：端口對。 　　重Borg當中學到的，我們決定為每一個pod分配一個ip地址，從而使網絡身份（IP地址）與應用程序身份保持一致。這使得在kubernetes上運行現成的軟件更加容易了。應用程序免費使用靜態的常見端口（例如80），and existing。熟悉的工具可以被用于網絡分段，帶寬限制與管理，所有流行的云平臺都提供了啟用IP-pod的網絡基礎。在裸機上，可以使用SDN（軟件定義網絡）覆蓋或配置L3路由以再每臺計算機上處理多個IP。 ## 　　**不要給容器編號：給他們標簽。** 如果你允許用戶輕松的創建容器，他們傾向于其創建許多，然后就需要一種方法去組織與分類。Borg提供了jobs去分類相同的任務然后組織他們，從零開始順序索引，這種方式簡潔有力，但用了一段時間后就后悔了，例如，當一個任務死掉了之后必須在另一臺機器上重啟，這會使得任務槽中的位置重復，當在vector中間的任務退出時，the vector ends up with holes.The vector makes it very hard to support jobs that span multiple clusters in a layer above Borg. There are also insidious, unexpected interactions between Borg’s job-update semantics (which typically restarts tasks in index order when doing rolling upgrades) and an application’s use of the task index (e.g., to do sharding or partitioning of a dataset across the tasks):如果應用程序基于任務索引使用范圍分片，Borg的重啟策略可能會導致數據不可用。因為它會減少鄰近的任務。Borg同樣也沒有提供簡單的方法來添加與應用程序相關的元數據到作業中。比如角色（例如前端）。或者推出狀態，因此人們將這些信息編碼為工作名稱，然后使用正則表達式對其進行解碼。 　　相比起來，kubernetes首先使用標簽去給容器分組。一個標簽使用鍵值對它包含容器信息去幫助確認目標，一個pod可能有標簽role=frontend 與 stage=production,指示此容器充當生產前端實例。標簽可以動態添加。刪除，然后通過自動化工具或者用戶修改。而且不同的團隊可以在很大程度上獨立管理自己的標簽。對象的集合由標簽選擇器定義，(e.g., stage==production && role==frontend).集可以重疊。一個對象可以有多個集合。因此，標簽在本質上比對象的顯式列表或簡單的靜態屬性更靈活。因為集合是由動態查詢定義的，可以在任何時候創建一個新的。Kubernetes的分組機制是標簽選擇器。并定義可以跨越多個實體的所有管理操作的范圍。在某些情況下，能夠定位一個任務所在的集合是有幫助的。例如，用于靜態角色分配和工作分區或分片，可以使用適當的per-pod標簽來重現任務索引的效果，盡管kubernetes有責任提供此類標簽（或者Kubernetes外部的其他管理系統）。標簽和標簽選擇器提供了一種通用機制，可以同時發揮兩者的優點。 ## **Be careful with ownership（謹慎處理所有權）** 在Borg中，任務并不能獨立于jobs獨立存在。創建一個job便創建了一個task，這些任務永遠與該特定工作關聯在一起。刪掉job便刪掉了task。這很方便，但是卻有一個很大的不足。以為這里只有一種分組機制，他需要處理所有用例，例如，作業必須存儲僅對服務或批處理作業有意義的參數，但不能同時對兩者有意義，當job的抽象并不能處理用例時，用戶必須自己制定解決方案。例如：集群中一個daemonset復制單個pod到所有的節點上。在Kubernetes中，pod生命周期管理組件例如replication控制器決定哪一個pod對使用標簽選擇器負責。因此多個控制器可能會認為他們對某個pod具有控制權限。通過適當的配置選擇來防止這種沖突是很重要的。但是，標簽的靈活性也有相應的優勢，分離的控制器與pod意味著”orphan”與“adopt”是可能的。考慮一個負載均衡服務他使用一個標簽選擇器去標識要將流量發送到pod的集。如果其中的一個pod出現了異常。可以刪除目標pod的標簽來隔離該pod對于負載均衡的請求。這個pod就將不在負載traffic。但它將保留下來，可以在原地進行調試。與此同時，管理該服務的容器控制器會自動為不正常的pdo創建一個新的pod。 ## **不要暴露原始狀態：Don’t expose raw state** 在Borg，Omega,與kubernetes之間的一個關鍵不同點是他們的API架構，Borgmaster是一個獨立組件，它知道每個API操作的語義。它包含集群管理邏輯，例如作業，任務和計算機的狀態；并且運行基于Paxos的復制存儲系統，該系統用于記錄master的狀態，相比之下，Omega除了存儲之外沒有集中組件，它僅保留被動狀態信息并執行樂觀并發控制：所有邏輯和語義都被推到存儲的客戶機中，這直接讀寫存儲內容，在實際上，在實際上，每個Omega組件對存儲使用相同的客戶端庫。這會對數據結構進行打包/解包、重試，并強制執行語義一致性。Kuberntes選擇了一種中間立場，既提供了Omega組件化體系結構的靈活性和可伸縮性，又加強了系統范圍的不變量，策略，和數據轉換。它通過一個集中的API服務器來強制所有的存儲訪問，該服務器隱藏存儲實現的細節，并為對象驗證，默認值，和版本控制提供服務，就像在Omega中一樣，客戶端組件彼此分離，并且可以獨立發展或替換（這在開源環境中尤其重要），但是集中化使得實施通用語義、不變量和策略變得容易。 ## **一些開放的，困難的問題：** 即使在多年的容器管理經驗之后，我們仍對于一些問題感到頭疼。這一屆我們描述幾個特別棘手的問題。希望能夠促進討論宇宙哦啊到解決方案。 ## **配置** 在我們面臨的所有問題當中，最耗費腦力、墨水和代碼的問題都與管理配置有關，提供給應用程序的一組值，而不是硬編碼到應用程序中。事實上，我們本可以用整篇文章來討論這個問題，而且還有更多要說的。以下是一些亮點。First, application container-management system doesn’t (yet) do. Over the history of Borg this has included: becomes the catchall location for implementing all of the things that the （容器管理系統做不了的地方都變成了應用程序的配置去實現。）在Borg的歷史上包括： ●　Boilerplate reduction（減少樣板）：(例如，適用于工作負載的默認任務重啟策略，例如服務或批處理作業)。 ●　調整和驗證應用程序參數和命令行標志。 ●　為缺少的API抽象實現解決方案，比如包(映像)管理。 ●　應用程序的配置模板庫。 ●　發布管理工具 ●　鏡像版本指定 　　為了應付這些需求，配置文件管理系統傾向于發明一種特定于域的配置語言，該語言能夠成為圖靈完整的，從對配置中的數據執行計算開始（調整內存量以根據服務中的分片數量為服務器提供服務），其結果是一種難以理解的“配置就是代碼”，人們試圖通過消除應用程序源代碼中的硬編碼參數來避免這種情況。它不會降低操作的復雜性，也不會使配置更容易調試或更改;它只是將計算從一種實際的編程語言轉移到一種特定于領域的語言，該語言通常具有較弱的開發工具，例如調試器和單元測試框架。 　　我們認為最有效的方法是接受這種需求，接受程序化配置的必然性，然后維護一個清晰的分割在計算與數據之間。這種語言對于呈現數據應該當簡單，數據格式僅僅像JSON或者yaml那樣。并應以一種真正的編程語言對這些數據進行編程修改，這里有很好理解的語義，以及良好的工具，有趣的是，這種計算和數據的分離也可以在Angular等框架的前端開發中看到，Angular在標記(數據)和JavaScript(計算)之間保持了清晰的分離。 ## **Dependency management（依賴管理）** 運行一項服務通常意味著運行一系列的相關連的服務（例如監視，存儲，持續交付與集成），如果一個應用程序對于其他應用程序有所依賴，如果這些依賴可以被集群管理系統自動安裝與初始化不是很nice嗎（以及它們可能具有的傳遞依賴關系）？ 　　更為復雜的東西，實例化的依賴關系并不像啟動一個新副本那么簡單，例如，它需要在已有的服務上注冊為一個消費者。（例如Bigtable 作為服務）以及傳遞認證方式，授權。以及這些傳遞依賴項中的計費信息。然而，幾乎沒有系統能夠捕獲、維護或公開此類依賴信息，因此在基礎設施級別實現自動化甚至是常見的情況幾乎是不可能的。對于用戶來說，打開一個新的應用程序仍然很復雜，對于開發者來說，這使得開發新的服務更為困難。and often results in the most recent best practices not being followed,（并經常導致未遵循最新的最佳做法，）這又會影響到servers的可靠性。 　　一個顯著的問題是，如果手動提供依賴項信息，則很難使其保持最新狀態，and at the same time attempts to determine it automatically (e.g., by tracing accesses) fail to capture the semantic information needed to understand the result.（Did that access have to go to that instance, or would any instance have sufficed?）取得進展的一種可能方法是要求應用程序枚舉其依賴的服務，并讓基礎設施拒絕允許訪問任何其他的。（我們這樣做是為了在構建系統中進行編譯器導入。）例如自動設置、身份驗證和連接。不幸的是，表達，分析和使用系統依賴關系的系統的復雜性太高了，因此他們還沒有被添加到主流的容器管理系統中，我們仍然希望kubernetes能夠成為一個能夠構建這類工具的平臺，但這仍然是一個挑戰。 ## **結語：** 這一個十年來建立容器管理系統的經驗教會了我們許多，我們已經把我們學到的許多都放入到了Kubernetes中，我們的目標是建立一個明顯能夠使得程序的生產效率得以提升并且能夠幫助我們自動化的管理的系統，我們希望您能夠加入我們去擴展與提升他。