初識 Kustomize
第一次聽說 Kustomize 其實是在 kubernetes 1.14 釋出時候，它被內建到
kubectl
中，成為了一個子指令，但也隻是掃了一眼，并沒有深究。真正讓我注意到它，并主動開始了解其功能和使用方法的，是張磊大神在雲栖社群發表的一篇文章
《從Kubernetes 1.14 釋出，看技術社群演進方向》，他在文中是這麼說的：
Kustomize 允許使用者以一個應用描述檔案 （YAML 檔案）為基礎（Base YAML），然後通過 Overlay 的方式生成最終部署應用所需的描述檔案，而不是像 Helm 那樣隻提供應用描述檔案模闆，然後通過字元替換（Templating）的方式來進行定制化。
這不正我在苦苦尋找的東西嘛！自從公司确定了應用容器化的方案，至今已有半年多了，這期間我們的服務一個接一個的實作了容器化，部署到了 kubernetes 叢集中。kubernetes 叢集也有原先了1個測試叢集，幾個節點，發展到了如今的多個叢集，幾十個節點。而在推進容器化的過程中，每個服務都對對應多個應用描述檔案（ YAML 檔案），而根據環境的不同，又配置了多套的應用描述檔案。随着服務越部越多，應用描述檔案更是呈爆炸式的增長。
感謝 devops 文化，它是我不需要為每個應用去寫 YAML 檔案，各個應用的開發組承擔了這一工作，我隻需要為他們提供基礎模闆即可。但應用上線後出現的 OOM 、服務無法拉起等 YAML 檔案配置有誤導緻的問題接踵而至，使得我必須要深入各個服務，為他們配置符合他們配置。雖然也使用了
helm
，但是其隻提供應用描述檔案模闆，在不同環境拉起一整套服務會節省很多時間，而像我們這種在指定環境快速疊代的服務，并不會減少很多時間。針對這種情況，我已經計劃要自己開發一套更符合我們工作這種場景的應用管理服務，內建在我們自己的 devops 平台中。
這時 Kustomize 出現了，我明銳的感覺到 Kustomize 可能就是解決我現階段問題的一劑良藥。
什麼是 Kustomize ？
Kubernetes native configuration management
Kustomize introduces a template-free way to customize application configuration that simplifies the use of off-the-shelf applications. Now, built intoaskubectl
.apply -k
kustomize
允許使用者以一個應用描述檔案 （YAML 檔案）為基礎（Base YAML），然後通過 Overlay 的方式生成最終部署應用所需的描述檔案。而其他使用者可以完全不受影響的使用任何一個 Base YAML 或者任何一層生成出來的 YAML 。這使得每一個使用者都可以通過類似fork/modify/rebase 這樣 Git 風格的流程來管理海量的應用描述檔案。這種 PATCH 的思想跟 Docker 鏡像是非常相似的，它可以規避“字元替換”對應用描述檔案的入侵，也不需要使用者學習額外的 DSL 文法（比如 Lua）。
而其成為
kubectl
子指令則代表這
kubectl
本身的插件機制的成熟，未來可能有更多的工具指令內建到
kubectl
中。拿張磊大神的這張圖不難看出，在 kubernetes 原生應用管理系統中，應用描述檔案在整個應用管理體系中占據核心位置，通過應用描述檔案可以組合和編排多種 kubernetes API 資源，kubernetes 通過控制器來保證叢集中的資源與應用狀态與描述檔案完全一緻。
Kustomize 不像 Helm 那樣需要一整套獨立的體系來完成管理應用，而是完全采用 kubernetes 的設計理念來完成管理應用的目的。同時使用起來也更加的得心應手。
![k8s部署es叢集和kibana[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)