使用 Kubernetes 為 CI/CD 流水線打造高效可靠的臨時環境

介紹

在不斷發展的科技世界中，快速構建高質量的軟件至關重要。在真實環境中測試應用程序是及早發現和修復錯誤的關鍵。但是，在真實環境中設置 CI/CD 流水線進行測試可能既棘手又昂貴。

Kubernetes 是一個流行的容器編排平臺，提供臨時環境解決方案。在 Kubernete 的幫助下，用戶能根據需求創建臨時的現實環境去允許您進行測試和部署應用程序，還無需擔憂管理永久基礎設施的麻煩。

本文深入探討了如何使用 Kubernetes 設置臨時環境，以確保徹底的測試和順利部署。了解一下如何使用 Kubernetes 簡化 CI/CD 流水線，提高代碼質量并節省成本。

CI/CD 流水線是什么

CI/CD 流水線是一種簡化的軟件開發方法，能夠使開發人員快速將代碼更改整合到他們的應用程序中。這種方法促進持續整合、測試和部署，從而能及時交付高質量的軟件。

CI/CD 流水線的好處

CI/CD流水線具有眾多的優勢，其中包括：

高效的開發周期：CI/CD 流水線可以自動執行重復的任務，精簡開發的過程并減少手動的工作量。開發者可以無縫合并代碼更改，消除瓶頸并加速功能交付。

早期漏洞檢測：納入到 CI/CD 流水線中的自動化測試有助于早些識別錯誤和問題。這種方法最大限度地減少了錯誤修復的成本并提高了整體代碼質量。

一致的測試覆蓋率：每一次代碼提交都會執行自動化測試，確保一致的測試覆蓋率和軟件質量的持續提升。這種積極主動的方法可以防止退化的出現，并促進產品的可靠性。

加強協作：CD/CI 流水線提供透明且可追蹤的開發活動記錄，培養成員們之間的協作。開發人員可以輕松的追蹤更改，識別編寫者并維護一致的開發流程。

臨時環境：敏捷測試和無縫部署

臨時環境是短暫且隔離的空間，為開發人員提供一個安全且受控的環境去測試和布置微服務，而不被中斷的生產環境所打擾。鑒于優秀的管理和擴展容器化應用程序的能力，Kubernetes 被視為創建臨時環境的理想工具。

通過使用 Kubernetes 中的自定義資源，開發人員可以定義這些環境的配置，包括資源需求，從而實現快速高效的創建和銷毀。

這個方法有利于敏捷開發，并使團隊能夠可靠、自信地交付代碼更改。

Kubernetes CI/CD 流水線的關鍵組件

Kubernetes 適用于基于容器的現代應用程序部署。因此，在使用 Kubernetes 構建有效的 CI/CD 流水線時應考慮以下關鍵組件：

容器：封裝代碼和依賴關系的獨立軟件單元，有助于在不同環境中快速、一致地部署應用程序。

運行集群：執行容器化應用程序的工作節點組。自動擴展功能可確保按照需求水平擴展，處理增加的流量或資源壓力。

版本控制系統（VCS）：便于管理源代碼變更，使開發人員能夠將更新無縫推送到共享源代碼庫中。

配置管理：追蹤 VCS 中的變更，深入了解代碼版本發展過程。支持跨網絡部署更新，簡化基礎架構管理。

鏡像 Registries：用于存儲容器鏡像的集中存儲庫，精簡了 CI/CD 流程中的訪問。

安全考慮因素：在從源代碼庫到生產部署，在整個 CI/CD 流水線中保護敏感數據。

持續的監測和可觀測性：利用 Prometheus 等工具實時監控應用程序性能，實現問題檢測和解決。

CI/CD 和 Kubernetes 的最佳實踐

說到建立基于 Kubernetes 的 CI/CD 流水線，這里有一些最佳實踐：
?

運用 GitOps

GitOps 利用 Git 版本進行控制，對所有與部署相關的操作進行適當跟蹤和監控，以確保可靠的部署流程。這有助于管理配置文件和跟蹤所有部署版本，從而提高可靠性。
?

運用 Helm 來打包應用程序

Helm 通過提供被稱為 charts 的打包應用程序而簡化了 Kubernetes 上的軟件包管理。它使開發人員更容易創建可重復的部署，同時還允許他們定制自己的應用程序，而無需編寫任何額外的代碼或腳本。
?

遵循安全最佳實踐

Kubernetes 環境中的安全問題不容忽視，因為它往往是現代企業在處理敏感數據時面臨的最大威脅之一。

實施 Kubernetes 安全最佳實踐，比如身份驗證模型和授權策略，有助于確保集群安全，防止惡意用戶對 Kubernetes 集群管理的資源進行未經授權的訪問或活動。

運用 canary/blue-green 部署模式

通過使用這些模式，您可以提高生產環境的可靠性和穩定性，同時確保可以識別和解決任何潛在問題，而不會影響用戶體驗或功能。
?

Canary 部署只允許一小部分用戶訪問新功能，如果更新導致不良行為，可以快速回滾。

Blue-green 部署允許您在兩個相同版本的應用程序之間切換流量，這樣在測試階段成功解決任何重大錯誤之前，舊版服務仍可運行。
?

避免在容器中硬編碼機密和配置

容器鏡像不應包含密碼、API 密鑰或令牌等機密信息。相反，您應該將這些敏感信息存儲在外部秘密存儲中，如 AWS Secrets Manager 或 Hashicorp Vault，并在部署過程中使用 Helm Charts 或 kubectl 等工具檢索這些信息。

這將確保這些重要憑證經過加密，并與容器鏡像分開保存，因為容器鏡像可能會與其他服務共享，或者在容器鏡像被泄露時公開暴露。

設置和實際操作

我們將展示兩種方法。第一種是共享 Kubernetes 集群，其中每個臨時環境都是一個單獨的命名空間，但底層集群是相同的。第二種是為每個臨時環境建立一個單獨的集群。

第一種方法更具成本效益，而第二種方法則能在合規需要時提供不同環境之間更多的分離。

在這個演示中，我們將有一個由2個微服務和一個 Mongo 數據庫組成的系統，我們將在其中一個微服務上打開一個拉取請求，通過打開這個 PR，我們將在 Kubernetes 上創建一個新環境，我們將使用 vcluster 來創建和銷毀臨時環境，在完成測試后，我們應該更輕松地關閉或合并拉取請求，這將觸發另一個流水線來銷毀臨時環境。

我已經在本地的 Kubernetes 集群上部署了這些工作負載，使用 GitHub Action 工作流和 kustomize 創建了流水線，以輕松部署整個系統。
?
對于開發環境，我們需要創建流水線，為每個微服務自動創建臨時環境，我們的流水線應包含以下步驟：

檢驗代碼
建立 docker 鏡像
推進新的 docker 鏡像
更新 Kubernetes 的清單列表
部署新的臨時環境
部署這個環境中的整個系統
提供對該環境的訪問權限

?
請注意：這并不是開發工作流程的最終流水線，這些步驟只是為了演示。

我們將使用 vcluster 創建完全隔離的 Kubernetes 環境，請參考下面的 GitHub Action workflow 文件：
?

?
該流水線上的步驟將創建一個鏡像，并將其推送到我們的 docker registry，然后用新標簽更新 Github，之后將部署一個虛擬集群，并通過正常的 KUBECONFIG 文件提供對它的訪問。

您可以根據自己的用戶授權方式，以不同的方式處理集群訪問問題。

現在運行 vcluster list 命令，我們就能看到新創建的臨時集群，集群名稱取決于 GitHub 上的提交 SHA 和用戶 ID，以避免創建同名集群。

現在讓我們檢查已部署的工作負載。
?

?
現在我們已將全部的工作負載部署到新的環境并有且僅針對該環境。

由于開發環境是在開發人員需要時按需創建的，因此最好每隔幾個小時就自動銷毀這些開發環境，以避免主集群資源一直處于繁忙狀態。

現在，我們已經完成了開發工作，準備開啟拉取請求，將新變更合并到主分支，在創建 PR 時，將創建一個新環境，僅用于測試新變更，該環境應供 QA 和測試團隊使用，以接受新變更/功能。

PR GitHub workflow 與開發環境幾乎相同，但我們不會在 GitHub 上推送新的鏡像 tag，而是直接將其部署到新創建的臨時環境中。

?

?

總結

總之，臨時環境為大型團隊開發和測試軟件提供了一種經濟高效的方式。它們無需管理和維護永久環境，從而降低了基礎設施成本，加快了開發周期。隨著云原生技術的發展、微服務架構的普及，應用系統的服務及依賴資源的數量迅猛增長。在應用環境管理自動化程度不高的情況下，繁瑣的環境部署配置工作使得大量研發測試環境即便空閑時段也處于運行狀態，資源長期占用不釋放，導致不必要的開銷。因此，研發測試環境的資源治理是在降本增效大背景下一項艱巨的任務。

Walrus 支持對全套應用系統的統一編排，并在最新版本中提供環境隨時啟停的特性。用戶可以在閑時停止整個應用環境，回收底層運行的服務和環境資源。在環境停止期間，Walrus 保留整個應用系統的配置數據，便于下次重啟時，應用環境中的所有服務和資源可以輕松回到停止前的狀態，極大降低資源消耗成本，實現研發測試環境資源的有效治理。
?

除此之外，利用 Walrus 0.4 中提供的服務/資源草稿（Services/Resources Draft）功能和服務/資源/環境啟停和克隆功能，可以在資源有限的情況下一鍵啟停切換多套測試環境，以快速進行測試驗證工作，在增加資源利用率的同時提升部署效率并節省成本，切實助力企業降本增效。