探讨基于阿裡雲容器技術架構（三）

閱讀本篇需要了解 Kustomization 和 Helm 相關知識。

上篇介紹了網關基于 YAML 的部署方式，本篇我們探讨這種部署方式可能遇到的問題，以及有哪些方法解題。

問題

在企業級研發流程中，釋出一個應用的流程會更複雜。為了保證産品品質和開發、測試、運維等不同職能協作，一般研發流程在環境部分，包括：Dev、Test、 Staging 和 Prod 環境。

以網關部署的配置檔案為例，一個 YAML 部署檔案包括Deployment、Service 等内容，假設一個應用有4個環境組成，那麼 YAML 檔案的重複配置是非常多的。因為4個環境，除了 Pod 副本數量、namespace、limit 不同，其他都是相同的。如此，造成 YAML 後期維護難度增加、容易出錯等風險。

解題思路

圍繞 Kubernetes 生态，敏銳的開發者已經捕捉到這個機會，可能的方案譬如：Helm、Kustomization 。

Helm

Helm 提供了一套 Kubernetes 包管理的解決方案。Helm 3 是基于 Helm 2 的基礎之上，Helm 3 的内部實作相較于 Helm 2 發生了很大變化。最明顯的變化是删除 Tiller 。

從架構圖上可以看出，Helm 有幾個新的概念：

• Repository

  Repository 是存儲 Helm Chart 的倉庫，可以在 Client 檢索，也可以擷取 Chart 并進行後續操作。

• Client

  用戶端工具，可以搜尋 Chart 項目、安裝 Chart、建構 Chart。也可以把 Chart 渲染為 Kubernetes 需要的 YAML 檔案。

• Tiller

  負責接收來自用戶端的指令，完成對叢集内應用生命周期的控制。

• Chat

  Chat 是 YAML 檔案的集合，生成Kubernetes應用程式所需的大量 Kubernetes 資源。一個典型的 Chat 目錄檔案結構如下：

  

Kustomization

Kustomization 是一個輕量級的解決方案，沒有 Helm 諸多新的概念，基本遵從 Kubernetes 原生的模式。在 Kubernetes 1.14 之後，甚至直接內建到 kubectl ，成為其中的一部分。他有兩部分組成：

• Base

  Base 是包含 YAML 檔案的目錄結構，是對基礎資源配置的申明。若基礎部分有改動，隻需改這個目錄即可，提升可維護性。

• Overlay

  Overlay 是一個目錄結構，可以包含各個環境的個性化配置，其他基礎配置繼承 Base 即可。一個完整的Kustomization 目錄配置如下：

方案

我們選用輕量級的 Kustomization 方案，以網關為例，目錄如下，進入到 pro 目錄，執行 kustomize build 目錄獲得完整 YAML 檔案。使用 kustomize build | kubectl apply -f - 部署應用。在 v1.14 中，使用 kubectl 通過 -k 标志部署即可。源碼：

https://github.com/Tony-Hangzhou/mvp-samples/tree/master/kustomize/gateway

。

Kustomization 可以在運作時編輯資源，使用 edit 指令即可，請參考官網。

總結

本篇我們探讨了原生 YAML 部署遇到的問題，以及使用 Kustomization 提升可維護性。