Kustonmize 為何會出現
在 kustomize 出現之前，Kubernetes 管理應用的方式主要是通過 Helm 或者上層 Paas 來完成。
這些工具通常通過特定領域配置語言(DSL，如Go template、jsonnet) 來維護並管理應用，
並且需要參數化模板方式(如 helm) 來自定義配置，這需要學習復雜的 DSL 語法及容易出錯。
根據官網的描述：kustomize 是 kubernetes 原生的配置管理，以無模板方式來定制應用的配置。
kustomize 使用 k8s 原生概念幫助創建並復用資源配置(YAML)，允許用戶以一個應用描述文件 （YAML 文件）為基礎（Base YAML）
然后通過 Overlay 的方式生成最終部署應用所需的描述文件。
Kustomize 是一個獨立的工具，用來通過 kustomization 文件 定制 Kubernetes 對象。
從 1.14 版本開始，kubectl 也開始支持使用 kustomization 文件來管理 Kubernetes 對象。 要查看包含 kustomization 文件的目錄中的資源，執行下面的命令：
kubectl kustomize <kustomization_directory>
要應用這些資源，使用參數 --kustomize 或 -k 標志來執行 kubectl apply：
kubectl apply -k <kustomization_directory>
官網地址：
https://github.com/kubernetes-sigs/kustomize
kustomize 解決了什么痛點
1.如何管理不同環境或不同團隊的應用的 Kubernetes YAML 資源
2.如何以某種方式管理不同環境的微小差異，使得資源配置可以復用，減少 copy and change 的工作量
3.如何簡化維護應用的流程，不需要額外學習模板語法
kustomize 通過 Base & Overlays 方式(下文會說明)方式維護不同環境的應用配置
kustomize 使用 patch 方式復用 Base 配置，並在 Overlay 描述與 Base 應用配置的差異部分來實現資源復用
kustomize 管理的都是 Kubernetes 原生 YAML 文件，不需要學習額外的 DSL 語法
Kustomize安裝
安裝文檔
https://kubectl.docs.kubernetes.io/zh/installation/
我這邊選用二進制安裝
官方提供的安裝方式
cd /usr/bin/
curl -s "https://raw.githubusercontent.com/kubernetes-sigs/kustomize/master/hack/install_kustomize.sh" | bash
Kustomize 命令行包含build diff edit version h等子命令，其中最常使用的是build子命令
kustomize 官方實例
https://github.com/kubernetes-sigs/kustomize
更多官方的給的實例
https://github.com/kubernetes-sigs/kustomize/tree/master/examples
Kustomize 術語
參考文檔：
https://kubectl.docs.kubernetes.io/zh/api-reference/kustomization/
kustomization 指的是 kustomization.yaml 文件，或者指的是包含 kustomization.yaml 文件的目錄以及它里面引用的所有相關文件路徑
base
是一個 kustomization , 任何的 kustomization 包括 overlay (后面提到)，都可以作為另一個 kustomization 的 base (簡單理解為基礎目錄)。base 中描述了共享的內容，如資源和常見的資源配置
overlay
一個 kustomization它修改(並因此依賴於)另外一個 kustomization. overlay 中的 kustomization指的是一些其它的 kustomization, 稱為其 base. 沒有 base, overlay 無法使用，並且一個 overlay 可以用作 另一個 overlay 的 base(基礎)。簡而言之，overlay 聲明了與 base 之間的差異。通過 overlay 來維護基於 base 的不同 variants(變體)，例如開發、QA 和生產環境的不同 variants
variant
在集群中將 overlay 應用於 base 的結果。例如開發和生產環境都修改了一些共同 base 以創建不同的 variant。這些 variant 使用相同的總體資源，並與簡單的方式變化，例如 deployment 的副本數、ConfigMap使用的數據源等。簡而言之，variant 是含有同一組 base 的不同 kustomization
resource
在 kustomize 的上下文中，resource 是描述 k8s API 對象的 YAML 或 JSON 文件的相對路徑。即是指向一個聲明了 kubernetes API 對象的 YAML 文件
patch
修改文件的一般說明。文件路徑，指向一個聲明了 kubernetes API patch 的 YAML 文件
Kustomize 中有（bases） 和 （overlays） 的概念區分：
base 是包含 kustomization.yaml 文件的一個目錄，其中包含一組資源及其相關的定制。 基准可以是本地目錄或者來自遠程倉庫的目錄，只要其中存在 kustomization.yaml 文件即可。
overlays 也是一個目錄，其中包含將其他 kustomization 目錄當做 bases 來引用的 kustomization.yaml 文件。 基准不了解覆蓋的存在，且可被多個覆蓋所使用。 覆蓋則可以有多個基准，且可針對所有基准中的資源執行組織操作，還可以在其上執行定制。
這邊測試的一個實例
兩個不同的環境(開發，生產)
一個 deployments 資源和 service 資源為基礎資源
先看下目錄結構
當前文件夾下面添加一個名為kustomization.yaml的文件
可以用kustomizaton init生成
cat kustomizaton.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- service.yaml
- deployment.yaml
cat base/deployment.yaml
cat base/service.yaml
cat demo/overlays/pro/kustomization.yaml
cat demo/overlays/pro/limit.yaml
cat demo/overlays/pro/values.yaml
dev 相關的配置這里就不貼了
為了了解將安裝什么資源到集群中，我們在本文中主要使用kustomize build命令來代替kubectl apply -k命令。當然使用kubectl kustomize命令也是可以的，因為我們說了 kubectl 1.14 版本以后就已經集成了 kustomize。
在 kubectl 命令中使用 --kustomize 或 -k 參數來識別被 kustomization.yaml 所管理的資源。 注意 -k 要指向一個 kustomization 目錄。例如：
kubectl apply -k <kustomization 目錄>
kustomize build /usr/local/src/demo/overlays/pro/
如果想要直接部署
kustomize build /usr/local/src/demo/overlays/pro/ | kubectl apply -f -
或者
kubectl apply -k /usr/local/src/demo/overlays/pro/
定制配置
在這個工作流中，所有的配置（YAML 文件）都屬於用戶所有
現成配置
在這個工作流方式中，可從別人的 repo 中 fork kustomize 配置，並根據自己的需求來配置
通過上面兩種工作流方式，可以實現自定義管理應用的聲明式資源文件，或者基於別人的應用聲明式資源進行自定義修改
如果你經常使用 Kubernetes，那么應該對 Helm 和 Kustomize 不陌生，這兩個工具都是用來管理 Kubernetes 的資源清單的，但是二者有着不同的工作方式。
kustomize vs Helm
Helm 使用的是模板，一個 Helm Chart 包中包含了很多模板和值文件，當被渲染時模板中的變量會使用值文件中對應的值替換。而 Kustomize 使用的是一種無模板的方式，它對 YAML 文件進行修補和合並操作，此外 Kustomize 也已經被原生內置到 kubectl 中了。這兩個工具在 Kubernetes 的生態系統中都被廣泛使用，而且這兩個工具也可以一起結合使用
通過上面對 kustomize 的講解，可能已經有人注意到它與 Helm 有一定的相似。先來看看 Helm 的定位：Kubernetes 的包管理工具，而 kustomize 的定位是：Kubernetes 原生配置管理。兩者定位領域有很大不同，Helm 通過將應用抽象成 Chart 來管理, 專注於應用的操作、復雜性管理等, 而 kustomize 關注於 k8s API 對象的管理：
- Helm 提供應用描述文件模板(Go template)，在部署時通過字符替換方式渲染成 YAML，對應用描述文件具有侵入性。Kustomize 使用原生 k8s 對象，無需模板參數化，無需侵入應用描述文件(YAML), 通過 overlay 選擇相應 patch 生成最終 YAML
- Helm 專注於應用的復雜性及生命周期管理(包括 install、upgrade、rollback)，kustomize 通過管理應用的描述文件來間接管理應用
- Helm 使用 Chart 來管理應用，Chart 相對固定、穩定，相當於靜態管理，更適合對外交付使用，而 kustomize 管理的是正在變更的應用，可以 fork 一個新版本，創建新的 overlay 將應用部署在新的環境，相當於動態管理，適合於 DevOps 流程
- Helm 通過 Chart 方式打包並管理應用版本，kustomize 通過 overlay 方式管理應用不同的變體，通過 Git 來版本管理
- Helm 在v3 版本前有 Helm 和 Tiller 兩組件，需要一定配置，而 kustomize 只有一個二進制，開箱即用
總的來說，Helm 有自己一套體系來管理應用，而 kustomize 更輕量級，融入Kubernetes 的設計理念，通過原生 k8s API 對象來管理應用
總結
Kustomize 給 Kubernetes 的用戶提供一種可以重復使用配置的聲明式應用管理，從而在配置工作中用戶只需要管理和維護 Kubernetes 的原生 API 對象，而不需要使用復雜的模版。同時，使用 kustomzie 可以僅通過 Kubernetes 聲明式 API 資源文件管理任何數量的 kubernetes 定制配置，可以通過 fork/modify/rebase 這樣的工作流來管理海量的應用描述文件。