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

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

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

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

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

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

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

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

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

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

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

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

實(shí)施適當(dāng)?shù)陌踩员瓤雌饋?lái)更難

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

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

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

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

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

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

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

超越痛點(diǎn)

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

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

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

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

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

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