了解使用工具的方式是善用它的關(guān)鍵，這個概念不僅僅適用于您的周末愛好項目。就像 Kubernetes 這樣的 DevOps 要素一樣，藝術(shù)家最喜歡的畫筆或木工的車床也是如此——培養(yǎng)對系統(tǒng)的透徹理解可以提高您的工作效率。

...或者至少應(yīng)該如此。許多開發(fā)人員幾乎沒有足夠的時間來學(xué)習(xí)他們喜歡的工具包的基礎(chǔ)知識，更不用說深入研究使它們具有企業(yè)價值的復(fù)雜性了。事實上，掌握 Kubernetes 并非易事。雖然它的復(fù)雜性對于這樣一個強(qiáng)大的工具來說并不過分，但它往往會與那些試圖找到立足點的人背道而馳。

這正是我們創(chuàng)建2022 Kubernetes 基準(zhǔn)研究的原因。隨著采用率以健康的速度增長，越來越多的團(tuán)隊正在利用云原生工作流（但并不總能獲得他們預(yù)期的結(jié)果）。因此，我和我的團(tuán)隊花了幾個月的時間研究整個行業(yè)的 1160 多個開發(fā)團(tuán)隊，以對他們的 K8s 設(shè)置和實踐進(jìn)行基準(zhǔn)測試。在此過程中，我們探討了以下問題：

• 高性能組織的 K8s 使用有什么區(qū)別？
• 團(tuán)隊的結(jié)構(gòu)、文化和方法如何影響其在爭論 K8s 方面的成功？
• 從表現(xiàn)不佳的 K8s 新手到成功的容器化大師，是否有可行的途徑？
• 是否有正確的方法來創(chuàng)建面向未來的 K8s 設(shè)置？

我們的研究納入了自定義 Kubernetes 性能分?jǐn)?shù)或 KPS。根據(jù)他們對我們問題的回答和廣泛的數(shù)據(jù)點，我們授予組織 KPS，范圍從 0（低績效者）到 100（高績效者）。然后，我們將分析重點放在提供完整信息的團(tuán)隊上。盡管這極大地限制了受訪者群體，但我們認(rèn)為它描繪了當(dāng)前 K8s 生態(tài)系統(tǒng)中更公平的使用情況。

成功需要的不僅僅是良好的意愿：容器化實施和規(guī)劃能力作為績效衡量標(biāo)準(zhǔn)

我們的工作揭示了低績效者和高績效者之間的許多明顯區(qū)別。最令人痛心的是實施領(lǐng)域：超過 66% 的頂級績效領(lǐng)導(dǎo)者將他們的所有服務(wù)容器化，而略高于 22% 的低績效者效仿。

Kubernetes 采用的趨勢相同，這意味著適應(yīng)容器化是充分利用 K8s 的關(guān)鍵。這是完全有道理的，因為 K8s 是一個容器編排系統(tǒng)，但在推動成功的 K8s 遷移向前發(fā)展時，我們也聽到了一些其他常見的反對意見：

• 低估 K8s 的復(fù)雜性：高績效者和低績效者都經(jīng)歷過這一點，兩組之間的差異很小。因此，在開始啟動集群或購買云提供商之前，進(jìn)行深入的培訓(xùn)可能是值得的。
• 在采用之前有不切實際或不準(zhǔn)確的期望：許多潛在的采用者遇到了一些問題，比如發(fā)現(xiàn) K8s 很難使用——或者至少比他們想象的要難。其他人發(fā)現(xiàn)他們節(jié)省的錢比他們預(yù)期的要少，或者在整個過程中被云服務(wù)不兼容所絆倒。

簡而言之，如果你腳踏實地，你可能會過得更好。K8s 可以解決很多問題，但前提是要有適當(dāng)?shù)囊?guī)劃，而且更重要的是，要愿意全面致力于容器化。

技術(shù)障礙：安全、團(tuán)隊管理和開發(fā)人員自助服務(wù)程度

我們發(fā)現(xiàn)的一件有趣的事情是，在 K8s 遷移過程中，一些常見的技術(shù)障礙反復(fù)出現(xiàn)。您的里程可能會有所不同，但在考慮采用時應(yīng)牢記這些潛在的挑戰(zhàn)：

實施適當(dāng)?shù)陌踩员瓤雌饋砀y

K8s 安全性是超過 70% 的受訪者的重要話題，但這并不意味著他們都處理得當(dāng)。盡管所有領(lǐng)導(dǎo)者都使用秘密管理工具，但仍有相當(dāng)一部分表現(xiàn)不佳的人犯下了一些嚴(yán)重的失禮行為。例如，許多存儲在其 repos 中的明文機(jī)密手動應(yīng)用更改或未能分離特定于環(huán)境和環(huán)境不可知的配置。此外，有些人對什么是最佳做法缺乏清晰的認(rèn)識。

不合適的組織文化可能會使 Kubernetes 遷移停止

遷移到 K8s 可能是一個巨大的文化轉(zhuǎn)變。但是，與大多數(shù)此類變化一樣，這些轉(zhuǎn)變似乎在自上而下發(fā)生時效果更好。

相比之下，低績效者通常會錯誤地在需要知道的基礎(chǔ)上傳播 K8s 知識，引入關(guān)鍵個體依賴性，這些依賴性后來可能成為主要弱點。與高績效者相比，低分者也未能準(zhǔn)確記錄和可視化他們的設(shè)置。他們還花更少的時間在 K8s 上引導(dǎo)開發(fā)人員。

自助服務(wù)需要更好地為開發(fā)人員服務(wù)

自助服務(wù)是另一個重要的劃分因素。盡管近 90% 的表現(xiàn)最好的人聲稱他們的開發(fā)人員可以獨立或按需部署，但只有 39% 的表現(xiàn)不佳的人這樣說。

令人擔(dān)憂的是，超過 31% 的低績效者認(rèn)為他們的大多數(shù)團(tuán)隊成員都不敢部署到 K8s 集群，因為害怕破壞某些東西！從組織的角度來看，這并不是一個好兆頭，但與其他領(lǐng)域相比，它給容器化操作帶來了更多的潛在問題。取決于人力資源瓶頸的集中式工作流程抵消了容器化的一些主要優(yōu)勢，例如能夠自主工作和快速配置基礎(chǔ)設(shè)施。

超越痛點

那么團(tuán)隊如何著手提高他們的 K8s 性能呢？我們發(fā)現(xiàn)，大多數(shù)成功的推出都存在于由平臺工程團(tuán)隊構(gòu)建的更大的內(nèi)部開發(fā)人員平臺(IDP) 框架內(nèi)。換句話說，高績效者構(gòu)建工具、支持系統(tǒng)和基礎(chǔ)設(shè)施，使他們的開發(fā)人員能夠有效地自助服務(wù)。

這應(yīng)該不足為奇；我們的 2022 年基準(zhǔn)報告并不是第一個將 DevOps 熟練程度與具有自助服務(wù)能力的內(nèi)部平臺相關(guān)聯(lián)的研究（例如，查看Puppet 的 2021 年 DevOps 狀態(tài)報告或Humanitec 的 2021 年 DevOps 基準(zhǔn)研究）。

同時，我們不能不指出有效的開發(fā)者生態(tài)系統(tǒng)必須追求整體理想。有效的 IDP 默認(rèn)執(zhí)行標(biāo)準(zhǔn)化和最佳實踐。在此過程中，他們讓開發(fā)人員與 K8s 交互，同時避免其不可否認(rèn)的復(fù)雜性的陷阱。通過這種方式，他們可以最大限度地減少開發(fā)團(tuán)隊的認(rèn)知負(fù)擔(dān)，讓他們能夠?qū)Ｗ⒂谥匾氖虑椤?/p>

通過學(xué)習(xí)更多來展現(xiàn)你最好的一面

K8s 是一個復(fù)雜但功能強(qiáng)大的系統(tǒng)，可以改善您團(tuán)隊的運(yùn)營。問題是您是否準(zhǔn)備好付出必要的努力來掌握它——并在采取這些關(guān)鍵的第一步之前為成功的遷移之旅構(gòu)建框架。

在更廣泛的方案中，Kubernetes 只是一個起點。它本身不能充當(dāng)您的整個開發(fā)人員平臺，但可以為您的平臺工程計劃打下堅實的基礎(chǔ)。