建站
咨詢
售后
建站咨詢
新聞中心
容器和Kubernetes已在計算界引入了一致性的新范式，為工程團隊提高了速度和敏捷性。通用聲明性語言提供了描述應用程序和操作任務的融合，使Kubernetes成為一種運行分布式工作負載的流行平臺。
在聲明性YAML中指定所需狀態(tài)后，Kubernetes著手解決和實現已聲明的狀態(tài)，比如應用程序的副本數。若有任何偏差，Kubernetes會竭力解決實際狀態(tài)與聲明狀態(tài)之間的差異，比如垂死和重新啟動的pod/容器。
對于初次部署到Kubernetes的用戶來說，感覺非?？焖?。一旦向kubectl發(fā)出了go [apply]命令，編寫最簡部署YAML意味著您啟動并運行起來。需要更改時，Kubernetes會利用其優(yōu)勢之一：滾動更新，逐步更改。觀看滾動更新進行，如果您習慣于手寫滾動更新規(guī)則的平臺，這使Kubernetes看起來輕而易舉。
盡管Kubernetes有種種好處，但擁有良好的CI/CD(持續(xù)集成/持續(xù)部署)實踐是關鍵。利用Kubernetes的優(yōu)勢推動您的CI/CD旅程。
CI和Kubernetes的優(yōu)秀實踐
持續(xù)集成(CI)是構建自動化的過程。比如說，Java應用程序需要內置到JAR中，然后如果進入到Kubernetes，需要進行Docker化處理，可能以Helm chart之類的格式進行打包/描述。在容器世界，由于容器不可變，需要的任何更改都將帶來新的映像，因此將頻繁調用CI過程來構建和打包新映像。
在Kubernetes上運行持續(xù)集成過程是謹慎的舉動，因為構建和打包軟件會占用大量的計算資源。每次提交啟動構建的現代方法實際上對基礎架構造成了負擔，對于容器化構建而言更是如此。利用Kubernetes構建和打包軟件是很好的用例，因為現代CI工具專注于在Kubernetes中創(chuàng)建臨時構建runner/節(jié)點。隨著構建請求進來，只需啟動新實例以創(chuàng)建構建工件，然后作業(yè)完成后關閉實例。
可以在臨時容器中輕松運行的持續(xù)集成信任建立步驟包括單元測試、集成測試和安全掃描等步驟。映像/容器掃描步驟可能是分解和驗證Docker層，計算尤其密集型，類似運行計算密集型的構建任務。由于每個構建都可能引入新的依賴項或新版本的依賴項，每次您構建新映像時，運行容器掃描很重要。
不過有些組件需要比臨時容器更持久，需要更持久的存儲。持續(xù)集成的退出步驟是將創(chuàng)建的工件/程序包發(fā)布到工件存儲庫，及/或將清單文件發(fā)布到相應的源代碼管理/程序包管理器解決方案。在Kubernetes界，這也可能是創(chuàng)建Kubernetes需要部署的所需清單文件，比如Helm chart或Kustomize/JSONNET資源。使用Kubernetes進行CI的目標是生成易于部署的工件，而程序包/配置/模板管理器允許這么做。
除非Kubernetes集群上的工作負載可以使用高可用性/持久存儲，否則將工件存儲庫作為SaaS來運行或在K8s集群上運行很明智。致命弱點是工件存儲庫本身就是存儲密集型。擁有可部署的工件/清單文件只是使您的想法落到最終用戶手里的一部分。下一步是部署。
CD和Kubernetes的優(yōu)秀實踐
持續(xù)交付(CD)的目的是將變更安全地部署到生產環(huán)境。Kubernetes能夠非常快速地部署，如果使用重建策略(所有pod被殺死并被替換)更是如此，而不是借助滾動策略增量部署。但是這會導致停機。我們大多數人處理一直運行的工作負載，因此停機將是不利因素。由于Kubernetes立即可用，忍住盡快部署的沖動似乎不合常理，卻是建立信任所需要的。
在您開始使用Kubernetes之后，從應用程序在Kubernetes之前經歷的建立信任演練入手仍然很重要。比如說，仍需要測試和覆蓋需求。至于Kubernetes，可能會有更多的問題。出于可移植性的原因，運行一致性測試來驗證要部署到的Kubernetes基礎架構并不罕見?？梢浦残援敵蹙褪抢肒ubernetes的一大賣點。
與在Kubernetes上運行持續(xù)集成步驟相似，在Kubernetes上運行某些持續(xù)交付步驟也是審慎的做法。在Kubernetes集群上可以輕松地搭建和關閉測試基礎架構。視信任建立步驟的長短，可能會有編排所需的工作流程方面。是否在Kubernetes上運行長期/有狀態(tài)的工作負載的相同設計原則和決策也適用于編排。
推進旅程
由于基礎架構和應用程序之間的界限因Kubernetes而模糊，常見的系統設計悖論在Kubernetes中很容易上演。Kubernetes出現之前，開發(fā)工程師將程序直接部署到生產環(huán)境并非常態(tài)。通常，它以某種CI / CD平臺作為門面，會有不同程度的自動化，批準后才可以進入到生產環(huán)境。
如果使用Kubernetes，您可以通過命名空間分離，輕松地在同一集群上面運行構建、信任建立步驟和部署，這取決于您在隔離與擁有單個集群方面走得多遠。由于現代工具和GitOps潮流受到追捧，開發(fā)者可以強制執(zhí)行標準，比如漂移檢測和部署聲明性狀態(tài)的自我愈合。
Kubernetes能做出一般的反應，比如按控制器定義來做出反應。好的方法是從基準偏離情況，關注監(jiān)控/可觀察性系統。如今可以在Harness平臺上以自動化的方式將這些工具編排成判斷調用(比如，決定是否需要回滾)。隨著更多組織進一步推進Kubernetes旅程，明智的做法是在擁抱這些新范式的同時，別忘記Kubernetes之前就有的準則或理念。
本文名稱：來自Kubernetes和CI/CD的優(yōu)秀實踐
當前網址：http://www.5511xx.com/article/cojspep.html
