Kubernetes 在生產(chǎn)環(huán)境中的復(fù)雜性已經(jīng)成為常態(tài)，在2023年這個平臺工程盛行的時代，

容器管理的最大亮點可能在于其靈活性，然而在運維政策和治理等方面仍然存在諸多挑戰(zhàn)

。八年過去了，在生產(chǎn)環(huán)境中使用 Kubernetes 仍然需要面臨許多挑戰(zhàn)。 ? Spectro Cloud 剛剛與 Dimensional Research 合作發(fā)布了

2023年 Kubernetes 生產(chǎn)狀態(tài)報告

（

文末查看報告獲取方式

）。Spectro Cloud 的項目負責(zé)人 Ant Newman 強調(diào)，要在當(dāng)前的IT環(huán)境下實現(xiàn)標(biāo)準(zhǔn)化，為所有應(yīng)用程序提供相同的堆棧是不切實際的。相反，我們應(yīng)該關(guān)注如何管理多樣性。 ? Kubernetes 最大的吸引力之一在于其可擴展性和跨環(huán)境的廣泛用例。但是，強大的靈活性也帶來了復(fù)雜性。用戶面臨的挑戰(zhàn)包括企業(yè)護欄、運營技術(shù)人才的短缺以及不一致性等方面。在處理這些挑戰(zhàn)時，Kubernetes 用戶需要同時考慮靈活性和復(fù)雜性，這兩者都會對內(nèi)部開發(fā)人員的體驗產(chǎn)生重要影響。 ? 本文將帶你一起看看 2023年 Kubernetes 生產(chǎn)狀態(tài)報告中的關(guān)鍵發(fā)現(xiàn)。 ? K8s 的復(fù)雜性

無論是在云端、裸機還是虛擬機上，甚至是在邊緣設(shè)備上，DevOps 團隊希望能夠以一種靈活的方式管理容器。然而，要以安全可擴展的方式來應(yīng)對這種復(fù)雜性卻并不容易。

大多數(shù)受訪企業(yè)在一個以上的托管環(huán)境中擁有 10 個以上的 K8s 集群，14% 的企業(yè)擁有 100 個以上的 K8s 集群

。根據(jù)報告結(jié)果，多個數(shù)量的 Kubernetes 發(fā)行版增加了復(fù)雜性，每個發(fā)行版的使用模式和功能都略有不同，復(fù)雜性也隨之升級。 ? 同時調(diào)查還發(fā)現(xiàn)，83% 的受訪者擁有兩個到 10 個以上的發(fā)行版，包括服務(wù)發(fā)行版（如 AWS 的 EKS-D）、自托管發(fā)行版（如 RedHat OpenShift）、邊緣專用發(fā)行版（如 K3s 和 MicroK8s）等。這樣，在一個企業(yè)中就有大約 20 種不同的路徑，而這些差異大多是由于監(jiān)管或行業(yè)要求產(chǎn)生的。 ? Newman 表示，通過采訪發(fā)現(xiàn)開發(fā)人員越來越傾向于使用自助服務(wù)，以便更好地掌控和加速工作進程。Kubernetes 在過去幾年中極大地促進了開發(fā)人員的自主性。然而，這種做法也帶來了問題，即開發(fā)人員需要將相當(dāng)一部分時間花在文檔和配置維護上，隨之他們花在寫代碼的時間上越來越少。Newman 表示，各種規(guī)模的公司都在努力確定最適合自己的平衡點。不同企業(yè)在生產(chǎn)中使用 Kubernetes 方式不同，但每個企業(yè)都在積極探討如何在開發(fā)人員自助服務(wù)的速度與必要的運營控制之間實現(xiàn)平衡。 ? K8s 的運維困境

為了解決 Kubernetes 復(fù)雜性問題，許多團隊不斷嘗試各種工具，但嘗試過程就好像是在問題上不停堆砌工具但并未能解決核心問題，無法控制與自助服務(wù)之間的平衡。根據(jù)調(diào)查，14% 的受訪者曾試用過至少一種開發(fā)人員體驗工具但后來都放棄了。 ? 報告顯示另一大挑戰(zhàn)是

無法獲得能夠應(yīng)對不斷發(fā)展的 Kubernetes 環(huán)境的運維人才

。由于要滿足定期升級和修補大量解決方案的需求，運維人員無法避免地產(chǎn)生倦怠。他們需要不斷花費時間來排除故障和修補漏洞，因此沒有足夠的時間來構(gòu)建最優(yōu)路徑以及自動化，并研究如何簡化工作流程。 ? 此外，報告還發(fā)現(xiàn)，開發(fā)人員仍然不習(xí)慣為他們的代碼日后如何運行負責(zé)，并認為這會分散他們對傳統(tǒng)開發(fā)思維的注意力?！白笠啤鞭D(zhuǎn)移了開發(fā)人員對流程狀態(tài)的注意力，也因此增加了對工具的需求，62% 的受訪企業(yè)表示他們的開發(fā)人員已經(jīng)或正準(zhǔn)備采用工具加強或提高 Kubernetes 的利用。 ? 調(diào)查結(jié)果顯示 92% 的人認為開發(fā)人員應(yīng)該把時間花在編碼功能上而不是管理基礎(chǔ)架構(gòu)上，但 82% 的人表示運維團隊很難為每個開發(fā)團隊提供符合其偏好的集群。很明顯，Kubernetes 需要一條通往生產(chǎn)的黃金通道，或者說是多條通道。

標(biāo)準(zhǔn)化將成為一個巨大的推動力

，以助于提高成本效益和安全性。 ?

建立企業(yè)護欄

也成為此次調(diào)研中多次被提及的挑戰(zhàn)。根據(jù)結(jié)果顯示，48% 的受訪者面臨這一挑戰(zhàn)，并且該挑戰(zhàn)在今年首次位居榜首。這表明 Kubernetes 的采用已成熟，當(dāng)企業(yè)開始在關(guān)鍵業(yè)務(wù)影響使用案例中管理容器時，復(fù)雜性就會增加。 ? 互操作性仍是一項挑戰(zhàn)

隨著 Kubernetes 戰(zhàn)略的擴展，互操作性也成為一個更大的挑戰(zhàn)。調(diào)查中四分之三的受訪者表示，他們會遇到互操作性問題，如服務(wù)網(wǎng)格、持久存儲和機密之間的互操作性問題。并且在生產(chǎn)中擁有 20 個或更多集群的企業(yè)因互操作性而出現(xiàn)問題的可能性是其他企業(yè)的三倍。 ? 受訪的企業(yè)表示對基于平臺的方法十分有信心，他們中有86%的受訪者希望能夠?qū)⑷萜骰ぷ髫撦d和虛擬機工作負載整合到同一個基礎(chǔ)架構(gòu)平臺上。值得注意的是，這種復(fù)雜性呈指數(shù)級增長，擁有 20 個以上生產(chǎn)集群的公司所報告的復(fù)雜性指標(biāo)明顯更高。這些公司更有可能報告說，他們有五個以上的分配器，以及另一項超過 15 個不同軟件元素的挑戰(zhàn)，其中包括：

Ingress

負載平衡器

機密管理

安全工具

服務(wù)網(wǎng)格

監(jiān)控和可觀測性

? Newman 說：“我們一直認為，Kubernetes 生產(chǎn)集群不僅僅是對分布式系統(tǒng)、CNI、CSI 和操作系統(tǒng)的選擇。80%的價值和80%的復(fù)雜性都來自于對集群中支持應(yīng)用的內(nèi)容所做的選擇。這些內(nèi)容也都大大增加了 Kubernetes 互操作性的難度?！闭{(diào)查發(fā)現(xiàn)，

集群越多，構(gòu)成堆棧的不同元素就越多，這反過來又增加了在整個組織內(nèi)實現(xiàn)標(biāo)準(zhǔn)化的難度

。 ? 元素越多，出現(xiàn)互操作性問題的機會就越多。企業(yè)需要配置和保護的工具就越多。需要打補丁和更新的東西就越多，這就是全棧式聲明管理十分重要的原因。 ? 自動化降低復(fù)雜性

那如何解決像 Kubernetes 復(fù)雜性這樣大規(guī)模的問題？運維團隊如何解決開發(fā)、暫存和生產(chǎn)環(huán)境各不相同的問題？怎樣才能花更少的時間排除故障，花更多的時間維護可用性和應(yīng)用程序性能？ ?

超過半數(shù)的受訪者認為自動化將顯著提高運營效率

。然而，該調(diào)查發(fā)現(xiàn)，企業(yè)在開發(fā)自動化腳本但不將其視為基礎(chǔ)設(shè)施重要組成部分，可能會在人員變動和腳本維護信息丟失時難以應(yīng)對。因此簡化軟件堆棧成為對上述挑戰(zhàn)——無法獲得能夠應(yīng)對不斷發(fā)展的 Kubernetes 環(huán)境的運維人才的解決方案。 ? 但企業(yè)需要為許多不同的團隊、許多不同的應(yīng)用程序和許多不同的環(huán)境提供服務(wù)。企業(yè)無法簡化所有的堆棧。每個團隊選擇不同的工具或環(huán)境都是有原因的，若企業(yè)能夠完善自動化工作，并為未來的操作人員記載自動化的緣由和步驟，就能保持軟件堆棧的多樣性，同時還能拓展運營覆蓋的范圍。 ? 關(guān)注gzh——“Seal軟件”，在gzh內(nèi)回復(fù)關(guān)鍵詞“

K8S23

”即可獲取報告。

? 參考鏈接:

https://thenewstack.io/the-2023-state-of-kubernetes-in-production/

?