[[399937]]

【51CTO.com快譯】容器和Kubernetes已在計算界引入了一致性的新范式，為工程團隊提高了速度和敏捷性。通用聲明性語言提供了描述應(yīng)用程序和操作任務(wù)的融合，使Kubernetes成為一種運行分布式工作負載的流行平臺。

在聲明性YAML中指定所需狀態(tài)后，Kubernetes著手解決和實現(xiàn)已聲明的狀態(tài)，比如應(yīng)用程序的副本數(shù)。若有任何偏差，Kubernetes會竭力解決實際狀態(tài)與聲明狀態(tài)之間的差異，比如垂死和重新啟動的pod/容器。

對于初次部署到Kubernetes的用戶來說，感覺非?？焖?。一旦向kubectl發(fā)出了go [apply]命令，編寫最簡部署YAML意味著您啟動并運行起來。需要更改時，Kubernetes會利用其優(yōu)勢之一：滾動更新，逐步更改。觀看滾動更新進行，如果您習(xí)慣于手寫滾動更新規(guī)則的平臺，這使Kubernetes看起來輕而易舉。

盡管Kubernetes有種種好處，但擁有良好的CI/CD(持續(xù)集成/持續(xù)部署)實踐是關(guān)鍵。利用Kubernetes的優(yōu)勢推動您的CI/CD旅程。

CI和Kubernetes的優(yōu)秀實踐

持續(xù)集成(CI)是構(gòu)建自動化的過程。比如說，Java應(yīng)用程序需要內(nèi)置到JAR中，然后如果進入到Kubernetes，需要進行Docker化處理，可能以Helm chart之類的格式進行打包/描述。在容器世界，由于容器不可變，需要的任何更改都將帶來新的映像，因此將頻繁調(diào)用CI過程來構(gòu)建和打包新映像。

在Kubernetes上運行持續(xù)集成過程是謹慎的舉動，因為構(gòu)建和打包軟件會占用大量的計算資源。每次提交啟動構(gòu)建的現(xiàn)代方法實際上對基礎(chǔ)架構(gòu)造成了負擔(dān)，對于容器化構(gòu)建而言更是如此。利用Kubernetes構(gòu)建和打包軟件是很好的用例，因為現(xiàn)代CI工具專注于在Kubernetes中創(chuàng)建臨時構(gòu)建runner/節(jié)點。隨著構(gòu)建請求進來，只需啟動新實例以創(chuàng)建構(gòu)建工件，然后作業(yè)完成后關(guān)閉實例。

可以在臨時容器中輕松運行的持續(xù)集成信任建立步驟包括單元測試、集成測試和安全掃描等步驟。映像/容器掃描步驟可能是分解和驗證Docker層，計算尤其密集型，類似運行計算密集型的構(gòu)建任務(wù)。由于每個構(gòu)建都可能引入新的依賴項或新版本的依賴項，每次您構(gòu)建新映像時，運行容器掃描很重要。

不過有些組件需要比臨時容器更持久，需要更持久的存儲。持續(xù)集成的退出步驟是將創(chuàng)建的工件/程序包發(fā)布到工件存儲庫，及/或?qū)⑶鍐挝募l(fā)布到相應(yīng)的源代碼管理/程序包管理器解決方案。在Kubernetes界，這也可能是創(chuàng)建Kubernetes需要部署的所需清單文件，比如Helm chart或Kustomize/JSONNET資源。使用Kubernetes進行CI的目標(biāo)是生成易于部署的工件，而程序包/配置/模板管理器允許這么做。

除非Kubernetes集群上的工作負載可以使用高可用性/持久存儲，否則將工件存儲庫作為SaaS來運行或在K8s集群上運行很明智。致命弱點是工件存儲庫本身就是存儲密集型。擁有可部署的工件/清單文件只是使您的想法落到最終用戶手里的一部分。下一步是部署。

CD和Kubernetes的優(yōu)秀實踐

持續(xù)交付(CD)的目的是將變更安全地部署到生產(chǎn)環(huán)境。Kubernetes能夠非常快速地部署，如果使用重建策略(所有pod被殺死并被替換)更是如此，而不是借助滾動策略增量部署。但是這會導(dǎo)致停機。我們大多數(shù)人處理一直運行的工作負載，因此停機將是不利因素。由于Kubernetes立即可用，忍住盡快部署的沖動似乎不合常理，卻是建立信任所需要的。

在您開始使用Kubernetes之后，從應(yīng)用程序在Kubernetes之前經(jīng)歷的建立信任演練入手仍然很重要。比如說，仍需要測試和覆蓋需求。至于Kubernetes，可能會有更多的問題。出于可移植性的原因，運行一致性測試來驗證要部署到的Kubernetes基礎(chǔ)架構(gòu)并不罕見。可移植性當(dāng)初就是利用Kubernetes的一大賣點。

與在Kubernetes上運行持續(xù)集成步驟相似，在Kubernetes上運行某些持續(xù)交付步驟也是審慎的做法。在Kubernetes集群上可以輕松地搭建和關(guān)閉測試基礎(chǔ)架構(gòu)。視信任建立步驟的長短，可能會有編排所需的工作流程方面。是否在Kubernetes上運行長期/有狀態(tài)的工作負載的相同設(shè)計原則和決策也適用于編排。

推進旅程

由于基礎(chǔ)架構(gòu)和應(yīng)用程序之間的界限因Kubernetes而模糊，常見的系統(tǒng)設(shè)計悖論在Kubernetes中很容易上演。Kubernetes出現(xiàn)之前，開發(fā)工程師將程序直接部署到生產(chǎn)環(huán)境并非常態(tài)。通常，它以某種CI / CD平臺作為門面，會有不同程度的自動化，批準(zhǔn)后才可以進入到生產(chǎn)環(huán)境。

如果使用Kubernetes，您可以通過命名空間分離，輕松地在同一集群上面運行構(gòu)建、信任建立步驟和部署，這取決于您在隔離與擁有單個集群方面走得多遠。由于現(xiàn)代工具和GitOps潮流受到追捧，開發(fā)者可以強制執(zhí)行標(biāo)準(zhǔn)，比如漂移檢測和部署聲明性狀態(tài)的自我愈合。

Kubernetes能做出一般的反應(yīng)，比如按控制器定義來做出反應(yīng)。好的方法是從基準(zhǔn)偏離情況，關(guān)注監(jiān)控/可觀察性系統(tǒng)。如今可以在Harness平臺上以自動化的方式將這些工具編排成判斷調(diào)用(比如，決定是否需要回滾)。隨著更多組織進一步推進Kubernetes旅程，明智的做法是在擁抱這些新范式的同時，別忘記Kubernetes之前就有的準(zhǔn)則或理念。

原文標(biāo)題：Kubernetes CI/CD Best Practices，作者：Ravi Lachhman

【51CTO譯稿，合作站點轉(zhuǎn)載請注明原文譯者和出處為51CTO.com】