使用Kubernetes實現CI/CD幾個注意點 - harness

CI的Kubernetes（CI with Kubernetes） 最佳實踐
持續整合 (CI)是構建自動化的過程。
例如，需要將 JAVA 應用程式構建到 JAR 中，然後如果要使用 Kubernetes，則需要進行 Docker 化，並可能以 Helm Chart 等格式進行打包/描述。
在容器化的世界中，由於容器是不可變的，任何需要的改變都會產生一個新的映象，因此你的 CI 過程將被大量呼叫來構建和打包新的映象。 
在 Kubernetes 上執行你的持續整合過程是一個謹慎的舉動。
構建和打包軟體可能會佔用大量計算資源。使用每次提交都啟動構建的現代方法，它可能對基礎設施造成很大負擔——尤其是容器化構建。利用 Kubernetes 來構建和打包軟體是一個很好的用例，因為現代 CI 工具專注於在 Kubernetes 中建立臨時構建執行器/節點。當構建請求到來時，啟動一個新例項來建立構建工件，然後在作業完成時停止例項。 
可以在臨時容器中輕鬆執行的持續整合建立信任步驟是單元測試、整合測試和安全掃描步驟。尤其是映象/容器掃描步驟在分解和驗證 Docker 層時可能需要大量計算，類似於執行計算量大的構建任務。由於每次構建都可能引入新的依賴項或新版本的依賴項，因此每次構建新映象時執行容器掃描都很重要。 
持續整合的一個完成步驟是：將建立的工件/包釋出到工件儲存庫；或將清單釋出到相應的原始碼管理/包管理器解決方案。在 Kubernetes 世界中，這也可以是建立 Kubernetes 需要部署的清單。還例如Helm Charts 或 Kustomize/JSONNET 資源。CI with Kubernetes 的一個目標是生成一個易於部署的工件，並且包/配置/模板管理器允許這樣做。 
除非Kubernetes叢集上的工作負載可以使用高可用性/永續性儲存，否則以SaaS或K8s叢集執行工件/腳手架的儲存庫是有意義的。阿喀琉斯之踵是，人工腳手架儲存庫在設計上過於繁重。
 

CD和Kubernetes 的最佳實踐
持續交付 (CD)的目標是以安全的方式將您的更改投入生產。
Kubernetes 具有非常快速的部署能力，特別是如果使用“重新建立策略”，其中所有 Pod 都被殺死並替換為滾動策略增量；但這會導致停機。儘管我們中的大多數人都在處理一直在執行的工作負載，但停機時間會是不利的。
在Kubernetes之前應用程式進行的建立信任練習並沒有隨著Kubernetes神奇地消失。測試和覆蓋要求並沒有消失。有了Kubernetes，出現了更多擔憂的可能性。在 Kubernetes 本身上執行某些持續交付步驟是謹慎的。在 Kubernetes 叢集上可以輕鬆地建立測試基礎設施，但是需要停止測試基礎設施。根據建立信任步驟的時間長短，編排可能需要長期的工作流程方面。在 Kubernetes 上或從 Kubernetes 執行長期/有狀態工作負載的相同設計原則和決策適用於編排。 
Kubernetes 非常適合藍綠或金絲雀釋出等釋出策略。雖然可以手工使用幾個精心設計的 Kubernetes 清單並及時應用這些清單，但涵蓋這些釋出策略的工具正在增加。
構建適當的執行狀況檢查（例如活動性和就緒性探測器）以支援增量部署繼續進行是關鍵。