Kubernetes允許用戶從應用程序管理和基礎架構選項的開放生態系統中進行選擇組件，并且在CNCF的領導下，Kubernetes已成為新型的Linux。

正因為如此，Kubernetes才成為容器編排的事實選擇。

[[324018]]

為什么?

為了支持各種用例，早期的Kubernetes開發人員為該平臺故意留白，以為其用戶提供靈活性。Kubernetes并非是萬能的平臺，而是一個可擴展的平臺，用戶和供應商可以使用自定義資源(CRD)，容器存儲接口(CSI)和容器網絡接口(CNI)輕松定制其環境。根據自己的要求。Kubernetes中的故意留白為基礎架構和應用程序層提供了靈活性。

云原生環境的構建塊

Cloud Native Infrastructure的故意留白

基礎設施

如今，有許多運行Kubernetes的基礎架構可供選擇。它可以在本地或公共云中運行。它也可以在虛擬機或裸機服務器上運行。因此，用戶需要根據自己的功能特性，性能要求，效率和成本要求做出明智的決策。但是，錯誤的決定會對項目結果和客戶體驗產生負面影響。

存儲

就像基礎架構一樣，對于Kubernetes用戶而言，選擇存儲解決方案也可能是一項艱巨的任務。盡管多年來，存儲技術取得了巨大進步，但大多數用戶仍面臨I/O瓶頸問題。隨著Kubernetes成為無狀態應用程序和有狀態應用程序的標準，選擇能夠提供現代數據服務–如災難恢復(DR)和高可用性(HA)，具有高吞吐量和低延遲的存儲系統非常重要。

網絡

網絡是任何云原生應用的基本要求。Kubernetes可以管理集群網絡，但是將應用程序暴露給外界，應用程序擴展、安全地互連是Kubernetes用戶面臨的最大挑戰。因此，用戶在選擇網絡解決方案時需要考慮網絡拓撲，安全性，延遲和吞吐量等。

資源利用率

Kubernetes 在CPU和內存級別解決了 noisy neighbor 問題，但是共享存儲和共享網絡仍然容易受到占用系統資源的應用程序的攻擊。用戶需要采取措施來避免 存儲和網絡的noisy neighbor 問題，并實現資源利用率的最大化。

noisy neighbor ，共享基礎架構的云環境中，過度占用帶寬，磁盤I/O，CPU和其他資源的租戶，很可能對其他用戶的云性能產生負面影響，導致共享基礎架構的其他虛擬機和應用程序遭受云網絡性能不均的困擾。

Cloud Native Application Management的故意空白

用戶和集群管理

由于Kubernetes與基礎架構無關，因此它僅提供基本的集群和用戶管理。大多數企業需要比現成可用的功能更強大的功能，包括諸如Active Directory集成、用戶和事件跟蹤、日志記錄之類的功能。

高級自定義選項

雖然Kubernetes專為容器編排和管理而設計，但它還包含許多用于進一步定制的高級選項，包括增強的安全性和配置控制等領域。

與Linux一樣，這些選項適用于熟悉它們的人。

應用程序生命周期管理(ALM)

Kubernetes編排容器，但不編排應用程序。開發人員通常更關心應用程序生命周期管理，而不是管理單個容器。注意：在Kubernetes中，使用ALM組件升級應用程序，變得復雜。

多集群管理

隨著Kubernetes的迅速采用，組織為了簡化和隔離，傾向于使用多個Kubernetes集群(用于開發，測試，生產等)。但是，這帶來了從單個面板管理多個群集的復雜性。在不同(或相同)云提供商之間，不同數據中心和不同區域之間移動應用程序及其數據也增加了復雜性。

Kubernetes社區的改進

在CNCF的領導下，Kubernetes社區通過標準的接口和框架，積極地發展和改善了平臺的核心功能。這些努力，使生態系統中的供應商和其他貢獻者能夠彌補上述空白。

Operators 框架

Operators 是專門用于Kubernetes特定應用程序生命周期管理的專用控制器。Kubernetes社區開發了此框架，以提供自動化，標準化，易用性和應用程序管理的靈活性。

Operators 的示例，一些是各種供應商發布的數據庫Operators ，例如Microsoft SQL Server，MongoDB和CrunchyPostgreSQL。使用數據庫Operators，可以用完全自動化的方式創建，銷毀，克隆，擴展或數據庫分片。此外，Operators還提供了在生產環境中運行數據庫所需的關鍵功能，例如高可用性(HA)，復制，負載平衡，故障轉移和快照。

CSI和CNI

在Kubernetes的早期，不支持將存儲集成到Kubernetes中。Diamanti提供了一個名為“ FlexVolume”的存儲插件，為將存儲集成到Kubernetes中鋪平了道路。

FlexVolume插件使有狀態應用程序能夠在Kubernetes上運行。FlexVolume后來演變為CSI，在Kubernetes 1.13和更高版本中完全支持。同樣，Kubernetes社區開發了CNI插件，該插件允許用戶將Kubernetes與首選的網絡解決方案集成。

這些標準接口有助于通過第三方解決方案擴展Kubernetes。但是，這帶來了額外挑戰：如何選擇正確的供應商或解決方案來滿足存儲和網絡需求。

填補留白

如上所述，Kubernetes有許多故意的留白，這使其可以靈活地在任何平臺上運行。服務提供商和基礎架構提供商有責任填補這些空白。

每個公共云提供商都提供Kubernetes服務，其中有意填補與特定計算，存儲和網絡基礎設施的集成中的空白。但是，公共云被設計為同質資源。這意味著生產應用程序會受到noisy neighbor 的困擾，這迫使用戶過度配置基礎架構，從而導致成本增加。

Kubernetes生態系統的參考架構

另外，在本地基礎架構上運行Kubernetes并不總是那么容易。使用DIY方法部署Kubernetes會帶來一個問題，即選擇和管理許多不同的組件，例如CSI，CNI，硬件，操作系統，安全性，身份和用戶管理。去年，許多供應商已經開始提供CNCF認證的Kubernetes發行版。

針對Kubernetes設計的Diamanti超融合基礎架構

DIY Kubernetes的替代方法是利用現代的超融合基礎架構(HCI)方法來填補這些空白。

Diamanti是該領域的先驅，提供了完全集成的計算，存儲，網絡和安全解決方案，還負責集群管理，身份和用戶管理，監控以及混合云管理。

這使開發人員和操作員可以專注于應用程序開發和部署。此外，Diamanti平臺通過其獨特的IO管理解決方案，完全消除了noisy neighbor 問題，從而提供了很高的應用程序性能。

結論

Kubernetes顯然是容器編排的最佳平臺，旨在在任何環境中運行。但是，建立Kubernetes的基礎原則，也使得啟動和運行現成的程序具有挑戰性。隨之而來的挑戰是，Kubernetes中有許多故意留白留給社區和供應商解決。

因此，在組織中采用Kubernetes時，要考慮如何減少可以滿足整體要求的基礎架構和應用程序管理所需的時間，精力和成本。集成方法是一種在確保所有這些差距都得到彌補的同時，可以縮短交貨時間的方法。

譯者：王延飛

原文鏈接：https://thenewstack.io/why-those-gaps-in-kubernetes-are-really-a-good-thing/