[[399937]]

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

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

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

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

CI和Kubernetes的優秀實踐

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

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

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

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

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

CD和Kubernetes的優秀實踐

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

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

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

推進旅程

由于基礎架構和應用程序之間的界限因Kubernetes而模糊，常見的系統設計悖論在Kubernetes中很容易上演。Kubernetes出現之前，開發工程師將程序直接部署到生產環境并非常態。通常，它以某種CI / CD平臺作為門面，會有不同程度的自動化，批準后才可以進入到生產環境。

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

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

原文標題：Kubernetes CI/CD Best Practices，作者：Ravi Lachhman

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