Kubernetes允許用戶從應(yīng)用程序管理和基礎(chǔ)架構(gòu)選項(xiàng)的開放生態(tài)系統(tǒng)中進(jìn)行選擇組件，并且在CNCF的領(lǐng)導(dǎo)下，Kubernetes已成為新型的Linux。

正因?yàn)槿绱耍琄ubernetes才成為容器編排的事實(shí)選擇。

[[324018]]

為什么?

為了支持各種用例，早期的Kubernetes開發(fā)人員為該平臺(tái)故意留白，以為其用戶提供靈活性。Kubernetes并非是萬(wàn)能的平臺(tái)，而是一個(gè)可擴(kuò)展的平臺(tái)，用戶和供應(yīng)商可以使用自定義資源(CRD)，容器存儲(chǔ)接口(CSI)和容器網(wǎng)絡(luò)接口(CNI)輕松定制其環(huán)境。根據(jù)自己的要求。Kubernetes中的故意留白為基礎(chǔ)架構(gòu)和應(yīng)用程序?qū)犹峁┝遂`活性。

云原生環(huán)境的構(gòu)建塊

Cloud Native Infrastructure的故意留白

基礎(chǔ)設(shè)施

如今，有許多運(yùn)行Kubernetes的基礎(chǔ)架構(gòu)可供選擇。它可以在本地或公共云中運(yùn)行。它也可以在虛擬機(jī)或裸機(jī)服務(wù)器上運(yùn)行。因此，用戶需要根據(jù)自己的功能特性，性能要求，效率和成本要求做出明智的決策。但是，錯(cuò)誤的決定會(huì)對(duì)項(xiàng)目結(jié)果和客戶體驗(yàn)產(chǎn)生負(fù)面影響。

存儲(chǔ)

就像基礎(chǔ)架構(gòu)一樣，對(duì)于Kubernetes用戶而言，選擇存儲(chǔ)解決方案也可能是一項(xiàng)艱巨的任務(wù)。盡管多年來(lái)，存儲(chǔ)技術(shù)取得了巨大進(jìn)步，但大多數(shù)用戶仍面臨I/O瓶頸問(wèn)題。隨著Kubernetes成為無(wú)狀態(tài)應(yīng)用程序和有狀態(tài)應(yīng)用程序的標(biāo)準(zhǔn)，選擇能夠提供現(xiàn)代數(shù)據(jù)服務(wù)–如災(zāi)難恢復(fù)(DR)和高可用性(HA)，具有高吞吐量和低延遲的存儲(chǔ)系統(tǒng)非常重要。

網(wǎng)絡(luò)

網(wǎng)絡(luò)是任何云原生應(yīng)用的基本要求。Kubernetes可以管理集群網(wǎng)絡(luò)，但是將應(yīng)用程序暴露給外界，應(yīng)用程序擴(kuò)展、安全地互連是Kubernetes用戶面臨的最大挑戰(zhàn)。因此，用戶在選擇網(wǎng)絡(luò)解決方案時(shí)需要考慮網(wǎng)絡(luò)拓?fù)洌踩裕舆t和吞吐量等。

資源利用率

Kubernetes 在CPU和內(nèi)存級(jí)別解決了 noisy neighbor 問(wèn)題，但是共享存儲(chǔ)和共享網(wǎng)絡(luò)仍然容易受到占用系統(tǒng)資源的應(yīng)用程序的攻擊。用戶需要采取措施來(lái)避免 存儲(chǔ)和網(wǎng)絡(luò)的noisy neighbor 問(wèn)題，并實(shí)現(xiàn)資源利用率的最大化。

noisy neighbor ，共享基礎(chǔ)架構(gòu)的云環(huán)境中，過(guò)度占用帶寬，磁盤I/O，CPU和其他資源的租戶，很可能對(duì)其他用戶的云性能產(chǎn)生負(fù)面影響，導(dǎo)致共享基礎(chǔ)架構(gòu)的其他虛擬機(jī)和應(yīng)用程序遭受云網(wǎng)絡(luò)性能不均的困擾。

Cloud Native Application Management的故意空白

用戶和集群管理

由于Kubernetes與基礎(chǔ)架構(gòu)無(wú)關(guān)，因此它僅提供基本的集群和用戶管理。大多數(shù)企業(yè)需要比現(xiàn)成可用的功能更強(qiáng)大的功能，包括諸如Active Directory集成、用戶和事件跟蹤、日志記錄之類的功能。

高級(jí)自定義選項(xiàng)

雖然Kubernetes專為容器編排和管理而設(shè)計(jì)，但它還包含許多用于進(jìn)一步定制的高級(jí)選項(xiàng)，包括增強(qiáng)的安全性和配置控制等領(lǐng)域。

與Linux一樣，這些選項(xiàng)適用于熟悉它們的人。

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

Kubernetes編排容器，但不編排應(yīng)用程序。開發(fā)人員通常更關(guān)心應(yīng)用程序生命周期管理，而不是管理單個(gè)容器。注意：在Kubernetes中，使用ALM組件升級(jí)應(yīng)用程序，變得復(fù)雜。

多集群管理

隨著Kubernetes的迅速采用，組織為了簡(jiǎn)化和隔離，傾向于使用多個(gè)Kubernetes集群(用于開發(fā)，測(cè)試，生產(chǎn)等)。但是，這帶來(lái)了從單個(gè)面板管理多個(gè)群集的復(fù)雜性。在不同(或相同)云提供商之間，不同數(shù)據(jù)中心和不同區(qū)域之間移動(dòng)應(yīng)用程序及其數(shù)據(jù)也增加了復(fù)雜性。

Kubernetes社區(qū)的改進(jìn)

在CNCF的領(lǐng)導(dǎo)下，Kubernetes社區(qū)通過(guò)標(biāo)準(zhǔn)的接口和框架，積極地發(fā)展和改善了平臺(tái)的核心功能。這些努力，使生態(tài)系統(tǒng)中的供應(yīng)商和其他貢獻(xiàn)者能夠彌補(bǔ)上述空白。

Operators 框架

Operators 是專門用于Kubernetes特定應(yīng)用程序生命周期管理的專用控制器。Kubernetes社區(qū)開發(fā)了此框架，以提供自動(dòng)化，標(biāo)準(zhǔn)化，易用性和應(yīng)用程序管理的靈活性。

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

CSI和CNI

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

FlexVolume插件使有狀態(tài)應(yīng)用程序能夠在Kubernetes上運(yùn)行。FlexVolume后來(lái)演變?yōu)镃SI，在Kubernetes 1.13和更高版本中完全支持。同樣，Kubernetes社區(qū)開發(fā)了CNI插件，該插件允許用戶將Kubernetes與首選的網(wǎng)絡(luò)解決方案集成。

這些標(biāo)準(zhǔn)接口有助于通過(guò)第三方解決方案擴(kuò)展Kubernetes。但是，這帶來(lái)了額外挑戰(zhàn)：如何選擇正確的供應(yīng)商或解決方案來(lái)滿足存儲(chǔ)和網(wǎng)絡(luò)需求。

填補(bǔ)留白

如上所述，Kubernetes有許多故意的留白，這使其可以靈活地在任何平臺(tái)上運(yùn)行。服務(wù)提供商和基礎(chǔ)架構(gòu)提供商有責(zé)任填補(bǔ)這些空白。

每個(gè)公共云提供商都提供Kubernetes服務(wù)，其中有意填補(bǔ)與特定計(jì)算，存儲(chǔ)和網(wǎng)絡(luò)基礎(chǔ)設(shè)施的集成中的空白。但是，公共云被設(shè)計(jì)為同質(zhì)資源。這意味著生產(chǎn)應(yīng)用程序會(huì)受到noisy neighbor 的困擾，這迫使用戶過(guò)度配置基礎(chǔ)架構(gòu)，從而導(dǎo)致成本增加。

Kubernetes生態(tài)系統(tǒng)的參考架構(gòu)

另外，在本地基礎(chǔ)架構(gòu)上運(yùn)行Kubernetes并不總是那么容易。使用DIY方法部署Kubernetes會(huì)帶來(lái)一個(gè)問(wèn)題，即選擇和管理許多不同的組件，例如CSI，CNI，硬件，操作系統(tǒng)，安全性，身份和用戶管理。去年，許多供應(yīng)商已經(jīng)開始提供CNCF認(rèn)證的Kubernetes發(fā)行版。

針對(duì)Kubernetes設(shè)計(jì)的Diamanti超融合基礎(chǔ)架構(gòu)

DIY Kubernetes的替代方法是利用現(xiàn)代的超融合基礎(chǔ)架構(gòu)(HCI)方法來(lái)填補(bǔ)這些空白。

Diamanti是該領(lǐng)域的先驅(qū)，提供了完全集成的計(jì)算，存儲(chǔ)，網(wǎng)絡(luò)和安全解決方案，還負(fù)責(zé)集群管理，身份和用戶管理，監(jiān)控以及混合云管理。

這使開發(fā)人員和操作員可以專注于應(yīng)用程序開發(fā)和部署。此外，Diamanti平臺(tái)通過(guò)其獨(dú)特的IO管理解決方案，完全消除了noisy neighbor 問(wèn)題，從而提供了很高的應(yīng)用程序性能。

結(jié)論

Kubernetes顯然是容器編排的最佳平臺(tái)，旨在在任何環(huán)境中運(yùn)行。但是，建立Kubernetes的基礎(chǔ)原則，也使得啟動(dòng)和運(yùn)行現(xiàn)成的程序具有挑戰(zhàn)性。隨之而來(lái)的挑戰(zhàn)是，Kubernetes中有許多故意留白留給社區(qū)和供應(yīng)商解決。

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

譯者：王延飛

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