與雲無關的用於 Kubernetes 的自動化 CI/CD

首發於 Jenkins 中文社區

在本文中，我想討論一種在雲環境中爲 Kubernetes 工做負載實現自動化端到端 CI/CD 的方法。 這裏可能有其它解決方案，而像 AWS、Microsoft Azure 和 GCP 這樣的雲提供商也提供了本身的一套框架，以實現與 Kubernetes 相同的目標。

它的部署模型的核心是 Rancher，Rancher 負責爲託管在不一樣雲環境和裸機環境中的多個 Kubernetes 集羣提供集中管理與運營的能力。 根據應用程序和業務須要，這裏提到的工具能夠替換爲本身選擇的工具。

在詳細介紹以前，這裏有張部署模型的快照：

持續集成組件

咱們使用 JIRA、BitBucket、Bamboo 和 Nexus 做爲自動化持續集成組件。 需求和用戶故事來自 JIRA ； 開發人員將他們的代碼放進 BitBucket ； 代碼被代碼評審工具和靜態分析工具構建與集成，Bamboo 生成的 Docker 鏡像被推送到 Nexus。 這些鏡像會通過特定的容器安全檢查。

當你有許多微服務/應用程序須要構建時，那麼處理 Kubernetes 集羣工做負載的部署、升級和回滾可能會複雜。 版本控制是咱們須要考慮的另外一個挑戰。 Helm 有助於克服這些大多數挑戰，並使部署變得簡單。

若是你想知道你是否須要有一個 chart 將全部 deployments 包含在其中， 或者容許每一個應用程序和微服務都有一個單獨的 chart ， 那麼咱們但願將這些 charts 放到特定的應用程序或微服務的倉庫中， 這樣咱們就不須要有單獨的倉庫來維護 Helm 製品。 這就省去了爲實際的代碼和 Helm 模板維護兩個獨立倉庫的工做。 開發人員能夠對任何應用程序代碼更改所需的模板更改有更多的控制權。

Nexus 做爲 Docker 鏡像和 Helm chart（使用的是 Helm Nexus 插件）的倉庫。 每次成功構建應用程序後，鏡像和 chart 都是可用的並被推送到 Nexus 。

持續部署組件

爲了實現與雲無關的準備，咱們選擇了 Terraform ，由於它易於學習並易於部署。 咱們發現對於準備後的配置管理/維護活動， Terraform 並非很是有用，因此咱們還放置了一些 Ansible 腳本。 咱們也曾考慮 Ansible 用於準備，可是使用 Terraform 可讓咱們更好地控制啓動實例， 這些實例能夠做爲 Rancher Server/節點，而且能夠被自動的添加到自動伸縮組中。 咱們使用啓動腳本功能實現了這一點。

咱們認爲能夠將爲 AWS 編寫的大多數 Terraform 腳本重用到 Azure 中，但事實並不是如此。 咱們必須作出至關大的改變。

咱們部署了一個運行在三個不一樣實例上的高可用的 Rancher Server ，前面有一個 NGINX Server 來爲這三個實例作負載均衡。 部署是使用 Terraform 和啓動腳本完成的。 腳本使用 RKE ( Rancher Kubenetes 引擎)和 Rancher API 調用來啓動集羣(高可用的 Rancher Server )。

Rancher 提供了各類選項來在不一樣的雲提供商上添加 Kubernetes 集羣。 您能夠從選項中進行選擇，使用託管的 Kubernetes 提供商，或者使用基礎設施提供商的節點或自定義節點。 在這個場景中，咱們選擇使用 AWS 和 Azure 上的自定義節點，而不是託管的 Kubernetes 提供商。 這幫助咱們向自動伸縮組添加一組工做節點，並使用集羣自動伸縮器進行節點伸縮。

全部這些都是經過啓動腳本和 Rancher API 調用自動完成的，所以任何經過 ASG (和自動伸縮器)添加的新節點都會自動註冊爲一個 Rancher/Kubernetes 節點。 經過啓動腳本自動執行的一些活動包括:

• 安裝和配置所需的 Docker 版本
• 在全部實例上安裝和配置 Zabbix 代理(稍後將在監控中使用)
• 安裝所需的 GlusterFS 客戶端組件
• 安裝所需的 kubectl 客戶端
• 後端數據庫集羣所需的任何其餘自定義配置
• 自動掛載額外的 EBS 卷和 GlusterFS 卷
• 爲 Rancher 代理/Kubernetes 節點運行 Docker 容器並附加特定的角色( etcd/controlplane/worker )
• 檢查以確保 Rancher 代理可用、啓動和運行。

GlusterFS 被考慮能夠處理 EBS 和 Azure 中不可用的 ReadWriteMany 磁盤卷類型。 這對於咱們部署的許多應用程序都是必需的。

一個 ELK stack ( ElasticSearch、Logstash 和 Kibana )使用 Helm charts 部署在 Kubernetes 上， 並被配置爲經過 logstash 推送容器日誌、審計和其餘自定義日誌。

HAProxy 和 NGINX 被用於兩個不一樣的目的。 NGINX 是在 Rancher Server HA 設置期間所提供的默認 ingress controller 。 這用於三個 Rancher Server 的負載均衡。 咱們在 Kubernetes 集羣上部署了一個 HAProxy Ingress Controller， 這樣咱們就能夠經過這些特定的節點(其 IPs 映射到特定的 FQDNs)暴露應用程序的 end points 。 HAProxy ingress controller 被部署爲 daemonset ，所以對於任何額外的負載，節點的數量會基於自動伸縮組和自動伸縮器自動增長。

持續監控組件

咱們部署了 Prometheus、Grafana 和 Alertmanager 套件，用於容量規劃以及監控 Rancher/Kubernetes 集羣的狀態。 這再次經過 Rancher Helm Chart Provisioner 部署。 咱們也能夠經過常規的/穩定的 Helm charts 來部署它。 它確實有助於咱們監控和收集開發環境中諸如 CPU、內存利用率和 IO 操做之類的指標，並據此爲 staging 環境和生產環境進行容量規劃。

咱們還在集羣上部署了 Zabbix Server，它用於爲部署的全部節點監控各類操做系統級別的和應用程序特定的指標和警告。 這包括任何後端數據庫集羣節點、Kubernetes 節點、Rancher servers、文件服務器或經過 Terraform 提供的任何其餘服務器。 Zabbix Server 被配置爲節點/代理自動註冊，以便經過自動縮放組或自動縮放器添加到集羣中的任何新節點均可用於監控。

結論

這是咱們爲 Kubernetes 工做負載構建完整的 CI/CD 工具鏈所遵循的方法之一。 這個模型幫助咱們自動化全部的三個環境的準備。 經過 Rancher ，咱們可以提供一個開發環境，每一個開發人員均可以使用這個項目概念。 每一個開發人員都有一個節點和一個項目，它由 RBAC 控制，這樣他們就能夠部署和測試他們本身的更改。 沒有人能夠看到項目/節點的詳細信息，也不會妨礙其餘開發人員部署的 Kubernetes 工做負載。 因爲節點自動註冊到 Rancher Server，系統從新啓動不會影響節點的可用性。 即便在最壞的狀況下，若是節點丟失，也很容易在幾分鐘內打開一個新節點。 應用程序可使用 Helm charts 進行部署，也可使用 Rancher 提供的內置的 Helm charts 進行部署。

這些是咱們部署的來管理整個環境的一些高級組件。 咱們考慮的其餘方面是高可用性集羣環境，用於 Rancher servers、Kubernetes 集羣、Gluster 文件服務器集羣或任何其餘後端集羣。 在提出此方法時，須要考慮生產級環境所需的更改和更新。 還考慮了其餘方面，例如對集羣實例的安全訪問、升級、備份和恢復，以及根據行業標準提出的分層體系結構建議。

但願本文爲您提供一些參考，當您計劃爲多個雲提供商提供生產級環境準備時，能夠考慮這些參考。

譯者：王冬輝