當今企業(yè)大部分都會成為混合云用戶。2021 年 Statista 對 750 家企業(yè)的調(diào)查發(fā)現(xiàn)，82% 的企業(yè)采用了混合云計算戰(zhàn)略。

然而，這種混合采用統(tǒng)計數(shù)據(jù)并不意味著私有云與公共云的問題是通過采用兩種云風格的混合來巧妙地決定的。相反，這意味著部署架構很復雜，發(fā)展迅速，以“一次性”的方式?jīng)Q定云架構是沒有意義的。

事實上，現(xiàn)在云技術堆棧中正在發(fā)生的事情正在釋放新的潛力。經(jīng)過多年全球采用公共云的趨勢，這些新的動力正在改變云經(jīng)濟，重振私有云的理念，為管理公共云提供新的戰(zhàn)略選擇，并啟用新的裸機模型，如邊緣、物聯(lián)網(wǎng)和“裸機云”產(chǎn)品。

1、云經(jīng)濟學：v1.0

采用云計算的開始是因為本地數(shù)據(jù)中心的構建和維護成本很高。服務器價格昂貴并且已經(jīng)過時。他們需要來自多個服務提供商的設施、電力、冷卻、內(nèi)部網(wǎng)絡、廣域網(wǎng)連接和骨干連接。數(shù)據(jù)中心有架構師來隔離故障域并分配冗余資源，從而實現(xiàn)彈性。

工作人員維護、操作和保護它們。全職管理人員在優(yōu)化它們之前分析它們的性能、使用效率和其他特性，通常是緩慢而昂貴的。企業(yè)仍然被鎖定在特定的位置，并且可能陷入彈性悖論——為未使用的容量付費，但無法快速擴展以滿足意外需求。

這只是一個開始。為了實現(xiàn)低水平的運營效率，許多用戶繼續(xù)使用許可的操作系統(tǒng)實施“標準”數(shù)據(jù)中心堆棧，添加用于服務器配置和許可證管理的工具，并最終鎖定自己進入該解決方案集。

然后，為了提高速度并實現(xiàn)開發(fā)人員和業(yè)務部門的自助服務，他們添加了一個類似設計的、基于成本的私有云基礎架構即服務解決方案。這提高了效率，但也提高了技能的新要求，增加了新的鎖定因素和許多新成本。

與此相比，公有云看起來也是不錯的選擇。一切都是運營支出，沒有物理設備，也沒有運行物理數(shù)據(jù)中心所需的直接開銷或員工成本。企業(yè)永遠不必與運營商打交道，可以從小處著手，然后快速發(fā)展壯大，或者根據(jù)需要頻繁更改規(guī)模。

企業(yè)可以將工作負載放置在提供商所在區(qū)域的任何位置，并且可以使用一組 Web UI 和/或 API
來配置和配置任何想要的東西。這就像跳過整個“物理基礎設施”步驟的復雜性和限制，直接進入“彈性計算云即服務”部分。

1)提示云復雜性

每個使用公共云的公司都會受到復雜賬單的困擾。 云定價的復雜性也會使制定和實施成本降低策略變得困難。

同時，很少有企業(yè)在不采用一些傳統(tǒng)思維的情況下進入公共云。為了獲得敏捷性和彈性，企業(yè)往往會犧牲一致性。他們多年來一直在內(nèi)部構建以 VMware 為中心的基礎設施即代碼，現(xiàn)在他們聘請了專業(yè)人員來為 AWS 環(huán)境創(chuàng)建和維護新的代碼庫。

這樣做的成本是巨大且持續(xù)的。它會引入安全漏洞，為人為錯誤提供新的機會，并使一切變得更加困難。

在其他情況下，企業(yè)可能會嘗試通過加倍努力來保持一致性，當他們冒險進入公共云時，采用他們的“標準操作系統(tǒng)”和“標準 IaaS”操作模型，保持傳統(tǒng)的成本結構。或者，他們可能會轉向相反的方向，購買由公共云 Web UI 和 API 驅(qū)動的私有云解決方案，獲得一致性并減少對各種技能的需求，但代價是更大的鎖定。

2、云經(jīng)濟學：2.0 版

然而，將 Kubernetes 放入這種組合中，它會改變一些事情：

1)Kubernetes 并不關注 Linux 內(nèi)核之外的事情。如今，調(diào)整任何真實或虛擬的盒子和 Linux 變體來運行設計良好的 Kubernetes，通常只需要適當?shù)馁Y源配置(盒子需要足夠的內(nèi)核/RAM/存儲/網(wǎng)絡+安全性才能安全地完成工作)。

2)一致的 Kubernetes 實現(xiàn)了根本的工作負載和配置可移植性。除非工作負載對硬件有特定要求(大多數(shù)情況下沒有)，否則企業(yè)會期望在 Linux Spin X 上開發(fā)的工作負載可以在任何地方的任何 Linux X 機器上運行。

部署在邏輯上自相似的 Kubernetes 集群上的容器和配置也是如此。事實并非如此，因為人們構建或獲取了不同的集群，然后嘗試將它們編織到更大的架構中以加速軟件交付，使用 CI 自動化和其他工具，或者做手工勞動，以掩蓋增量。

3)除非在極端情況下，Kubernetes 可以讓復雜而棘手的應用程序順利運行，而無需持續(xù)的人工關注。畢竟，這就是它的設計目的。企業(yè)還可以在堆棧中的所有內(nèi)容上運行滾動更新，而無需使應用程序或操作脫機。

4)Kubernetes 允許企業(yè)添加自定義功能來觀察和維護復雜的系統(tǒng)狀態(tài)，并將系統(tǒng)融合到新狀態(tài)以響應聲明性配置的變化。這些能力可以從 Kubernetes 駐留在堆棧中的位置向上和向下工作。

因此，Kubernetes 操作符和類似結構可用于管理應用程序(向上)和底層基礎設施(向下)，例如物理和虛擬主機、虛擬網(wǎng)絡和云服務。

5)Kubernetes 可以進行配置和擴展，為應用程序提供大量服務。例如存儲、DNS，無論應用程序需要什么，Kubernetes 都可以代表工作負載提供和編排服務，這就是它的設計目的。

6)Kubernetes 的擴展速度非常快。不計算啟動節(jié)點所需的時間，現(xiàn)代 Kubernetes 發(fā)行版可以在幾分鐘內(nèi)擴展到任意數(shù)量的節(jié)點。

7)Kubernetes 可以非常精細。現(xiàn)代 Kubernetes 發(fā)行版應該讓開發(fā)人員在單個桌面容器或一對 Raspberry Pi 上啟動控制器和工作器。同一個發(fā)行版應該同樣能夠運行 50/100/500 節(jié)點的集群。

正如大多數(shù)長期用戶所發(fā)現(xiàn)的那樣，有機的“大量集群與一個巨大的集群”模型效果最佳，原因有很多。然而，真正的好處只有在“許多小集群”都可以自洽并集中管理生命周期時才能產(chǎn)生。

Kubernetes 的超能力以重要方式改變了游戲規(guī)則。如果企業(yè)可以部署、擴展和管理 Kubernetes
的生命周期，則可以使用它來鋪平公共和私有云基礎設施，積極優(yōu)化成本和開銷，并將 Kubernetes 下的所有內(nèi)容視為商品。

1)降低云運營成本。用戶的早期實驗表明，這種方法可以快速降低私有云運營的總成本。以 Kubernetes
為中心的基礎設施很大程度上會考慮自己，運營商會“向上”優(yōu)化工作負載，“向下”來管理主機、操作系統(tǒng)和其他支持服務和層。這使得運行私有云，特別是當它們變得更大時，成本和風險要低得多。

2)降低主機/客戶機操作系統(tǒng)許可和支持成本。Kubernetes 對 Linux 內(nèi)核和 CPU 有部分關注，但其他方面并不多。以 Kubernetes 為中心的基礎設施并沒有真正受益于底層昂貴的“企業(yè)”Linux。

企業(yè) Linux spin 提供的專用加密(例如 FIPS)等功能正在迅速上升到容器運行時和 Kubernetes 發(fā)行版中。可以啟用 Kubernetes 本身來管理原始裸機基礎設施，從而使服務器池管理解決方案變得不那么重要。

3)降低硬件成本。例如，全球轉向更便宜的 ARM64 CPU 的情況正在加速，部分原因是容器和 Kubernetes 使轉移和重建工作負載變得更加容易。

甚至在某些方面，以性能為導向(相對于成本、能源或其他方面)的硬件發(fā)展可能會停滯不前，尤其是在公共云中，因為“降低”硬件的經(jīng)濟性對規(guī)模供應商而言十分具有誘惑力。與此同時，可以說更重要的是出于監(jiān)管、管轄和主權原因以及連接性的位置。

這對私有云運營商來說是個好消息。如今，構建集中式計算/存儲/網(wǎng)絡比以往任何時候都便宜。數(shù)據(jù)中心本身正在發(fā)生變化，變得更小，使用更少的電力和冷卻，分布在更多的位置，向邊緣移動并進入微型設備群。

4)運行私有 IaaS 云的新的和更便宜的方式。以 Kubernetes 為中心的基礎架構非常適合以低運營成本穩(wěn)健、靈活地運行復雜的關鍵軟件。

例如，裸機服務器池可以在開源基礎設施即服務 OpenStack 下將 Kubernetes 作為底層運行，而不會降低性能，從而提供更高的彈性、無縫更新和輕松擴展，同時為經(jīng)典虛擬機、網(wǎng)絡和存儲提供強大的支持。

5)降低自動化成本。為開發(fā)、測試、暫存和交付應用程序到生產(chǎn)環(huán)境打造安全、可靠、高性能的工具鏈對于讓客戶滿意并降低業(yè)務風險至關重要。

如果企業(yè)的目標是一致的 Kubernetes 集群模型(相對于不同的私有云和公共云基礎設施)，那么只需要這樣做一次，然后花時間改進與底線相關的內(nèi)容。

3、一致的 Kubernetes 無處不在

使用 Kubernetes 作為“基礎設施”的底線要求是企業(yè)需要能夠在任何地方部署、觀察和管理一個一致的 Kubernetes 集群模型的生命周期。

這使得以 Kubernetes 層為目標的應用程序、配置、CI/CD 和操作自動化能夠以相同的方式工作，無論是針對在服務器機房的刀片上運行的集群還是針對在 AWS 實例上運行的集群。

這意味著有人正在啟用此功能并使 Kubernetes 能夠順利地主動管理各種底層基礎設施。