kustomize簡單使用

1.背景

　　在Kubernetes v1.14版本的釋出說明中，kustomize 成為了 kubectl 內建的子命令，並說明了 kustomize 使用 Kubernetes 原生概念幫助使用者創作並複用宣告式配置。

　　那麼，kustomize 出現的原因是什麼？在kustomize的github issue中找到了 kustomize 啟發來自一篇Kubernetes宣告性應用程式管理，這篇文章內容很多，主要提出了Kubernetes應用的配置規範，宣告式配置的優點以及引數化定製配置的缺陷以及一些改進方案。

　　在kustomize出現之前，Kubernetes管理應用的方式主要是通過Helm或者上層Paas 來完成。這些工具通常通過特定領域配置語言(DSL，如Go template、jsonnet) 來維護並管理應用，並且需要引數化模板方式(如 helm) 來自定義配置，這需要學習複雜的DSL語法及容易出錯。

2.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 into kubectl as apply -k.

　　根據官網的描述：kustomize 是 kubernetes 原生的配置管理，以無模板方式來定製應用的配置。kustomize使用k8s原生概念幫助建立並複用資源配置(YAML)，允許使用者以一個應用描述檔案（YAML 檔案）為基礎（Base YAML），然後通過 Overlay 的方式生成最終部署應用所需的描述檔案。

3.kustomize解決了什麼痛點？

　　一般應用都會存在多套部署環境：開發環境、測試環境、生產環境，多套環境意味著存在多套K8S應用資源YAML。而這麼多套YAML之間只存在微小配置差異，比如映象版本不同、Label不同等，而這些不同環境下的YAML 經常會因為人為疏忽導致配置錯誤。再者，多套環境的YAML維護通常是通過把一個環境下的YAML拷貝出來然後對差異的地方進行修改。一些類似Helm等應用管理工具需要額外學習DSL語法。總結以上，在k8s環境下存在多套環境的應用，經常遇到以下幾個問題：

如何管理不同環境或不同團隊的應用的Kubernetes YAML資源
如何以某種方式管理不同環境的微小差異，使得資源配置可以複用，減少copy and change的工作量
如何簡化維護應用的流程，不需要額外學習模板語法

　　Kustomize通過以下幾種方式解決了上述問題：

kustomize通過Base & Overlays方式(下文會說明)方式維護不同環境的應用配置
kustomize使用patch方式複用Base配置，並在Overlay描述與Base應用配置的差異部分來實現資源複用
kustomize管理的都是Kubernetes原生YAML檔案，不需要學習額外的DSL語法

4.kustomize術語

　　在 kustomize 專案的文件中，經常會出現一些專業術語，這裡總結一下常見的術語，方便後面講解

kustomization

　　術語kustomization指的是kustomization.yaml檔案，或者指的是包含 kustomization.yaml檔案的目錄以及它裡面引用的所有相關檔案路徑

base

　　base指的是一個kustomization , 任何的kustomization 包括overlay(後面提到)，都可以作為另一個kustomization的base(簡單理解為基礎目錄)。base中描述了共享的內容，如資源和常見的資源配置

overlay

　　overlay是一個kustomization, 它修改(並因此依賴於)另外一個kustomization. overlay中的kustomization指的是一些其它的kustomization, 稱為其base.沒有base, overlay無法使用，並且一個overlay可以用作另一個overlay的base(基礎)。簡而言之，overlay聲明瞭與base之間的差異。通過overlay來維護基於base的不同variants(變體)，例如開發、QA 和生產環境的不同variants

variant

　　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檔案

5.kustomize 官方示例

　　現在通過官方的示例來演示一下kustomize應該怎麼用，以及相應的一些規範。如果你沒有使用Kubernetes v1.14 版本，參考官方安裝教程進行安裝kustomize，或者直接下載 v1.14 版本kubectl二進位制，通過kubectl -k命令使用kustomize。

　　官方更多例項地址: https://github.com/kubernetes-sigs/kustomize/tree/master/examples

　　官方配置項地址: https://kubectl.docs.kubernetes.io/references/kustomize/kustomization/

5.1 ldap示例

　　1.新建一個Base目錄

　　首先建立工作目錄以及定義工作目錄變數等資訊

DEMO_HOME=/test/ldap

BASE=$DEMO_HOME/base

mkdir -p $BASE

CONTENT="https://raw.githubusercontent.com\

/kubernetes-sigs/kustomize\

/master/examples/ldap"

curl -s -o "$BASE/#1" "$CONTENT/base\

/{deployment.yaml,kustomization.yaml,service.yaml,env.startup.txt}"

　　具體的程式碼檔案見以下，或者直接clonegit倉庫程式碼。

#deployment.yaml

apiVersion: apps/v1

kind: Deployment

metadata:

  name: ldap

  labels:

    app: ldap

spec:

  replicas: 1

  selector:

    matchLabels:

      app: ldap

  template:

    metadata:

      labels:

        app: ldap

    spec:

      containers:

        - name: ldap

          image: osixia/openldap:1.1.11

          args: ["--copy-service"]

          volumeMounts:

            - name: ldap-data

              mountPath: /var/lib/ldap

            - name: ldap-config

              mountPath: /etc/ldap/slapd.d

            - name: ldap-certs

              mountPath: /container/service/slapd/assets/certs

            - name: configmap-volume

              mountPath: /container/environment/01-custom

            - name: container-run

              mountPath: /container/run

          ports:

            - containerPort: 389

              name: openldap

      volumes:

        - name: ldap-data

          emptyDir: {}

        - name: ldap-config

          emptyDir: {}

        - name: ldap-certs

          emptyDir: {}

        - name: "configmap-volume"

          configMap:

            name: "ldap-configmap"

        - name: container-run

          emptyDir: {}

#service.yaml

apiVersion: v1

kind: Service

metadata:

  labels:

    app: ldap

  name: ldap-service

spec:

  ports:

    - port: 389

  selector:

app: ldap

#kustomization.yaml

resources:

- deployment.yaml

- service.yaml

configMapGenerator:

- name: ldap-configmap

  files:

- env.startup.txt

#env.startup.txt

# This is the default image startup configuration file

# this file define environment variables used during the container **first start** in **startup files**.

# This file is deleted right after startup files are processed for the first time,

# after that all these values will not be available in the container environment.

# This helps to keep your container configuration secret.

# more information : https://github.com/osixia/docker-light-baseimage

# Required and used for new ldap server only

LDAP_ORGANISATION: Example Inc.

LDAP_DOMAIN: example.org

LDAP_BASE_DN: #if empty automatically set from LDAP_DOMAIN

LDAP_ADMIN_PASSWORD: admin

LDAP_CONFIG_PASSWORD: config

LDAP_READONLY_USER: false

LDAP_READONLY_USER_USERNAME: readonly

LDAP_READONLY_USER_PASSWORD: readonly

LDAP_RFC2307BIS_SCHEMA: false

# Backend

LDAP_BACKEND: hdb

# Tls

LDAP_TLS: true

LDAP_TLS_CRT_FILENAME: ldap.crt

LDAP_TLS_KEY_FILENAME: ldap.key

LDAP_TLS_CA_CRT_FILENAME: ca.crt

LDAP_TLS_ENFORCE: false

LDAP_TLS_CIPHER_SUITE: SECURE256:+SECURE128:-VERS-TLS-ALL:+VERS-TLS1.2:-RSA:-DHE-DSS:-CAMELLIA-128-CBC:-CAMELLIA-256-CBC

LDAP_TLS_VERIFY_CLIENT: demand

# Replication

LDAP_REPLICATION: false

# variables $LDAP_BASE_DN, $LDAP_ADMIN_PASSWORD, $LDAP_CONFIG_PASSWORD

# are automaticaly replaced at run time

# if you want to add replication to an existing ldap

# adapt LDAP_REPLICATION_CONFIG_SYNCPROV and LDAP_REPLICATION_DB_SYNCPROV to your configuration

# avoid using $LDAP_BASE_DN, $LDAP_ADMIN_PASSWORD and $LDAP_CONFIG_PASSWORD variables

LDAP_REPLICATION_CONFIG_SYNCPROV: binddn="cn=admin,cn=config" bindmethod=simple credentials=$LDAP_CONFIG_PASSWORD searchbase="cn=config" type=refreshAndPersist retry="60 +" timeout=1 starttls=critical

LDAP_REPLICATION_DB_SYNCPROV: binddn="cn=admin,$LDAP_BASE_DN" bindmethod=simple credentials=$LDAP_ADMIN_PASSWORD searchbase="$LDAP_BASE_DN" type=refreshAndPersist interval=00:00:00:10 retry="60 +" timeout=1 starttls=critical

LDAP_REPLICATION_HOSTS:

  - ldap://ldap.example.org # The order must be the same on all ldap servers

  - ldap://ldap2.example.org

# Do not change the ldap config

# - If set to true with an existing database, config will remain unchanged. Image tls and replication config will not be run.

#   The container can be started with LDAP_ADMIN_PASSWORD and LDAP_CONFIG_PASSWORD empty or filled with fake data.

# - If set to true when bootstrapping a new database, bootstap ldif and schema will not be added and tls and replication config will not be run.

KEEP_EXISTING_CONFIG: false

# Remove config after setup

LDAP_REMOVE_CONFIG_AFTER_SETUP: true

# ssl-helper environment variables prefix

LDAP_SSL_HELPER_PREFIX: ldap # ssl-helper first search config from LDAP_SSL_HELPER_* variables, before SSL_HELPER_* variables.

ldap程式碼準備完成後檔案結構如下：

└── base

    ├── deployment.yaml

    ├── env.startup.txt

    ├── kustomization.yaml

    └── service.yaml

　　接下來看看kustomization.yaml配置檔案中包含什麼內容：

resources:

- deployment.yaml

- service.yaml

configMapGenerator:

- name: ldap-configmap

  files:

    - env.startup.txt

　　這個檔案聲明瞭這些YAML資源(deployments、services、configmap 等)以及要應用於它們的一些自定義，如新增一個通用的標籤。kustomization還提供namePrefix、commonAnnoations、images等配置項.

　　這時候，可以通過kustomize build命令來看完整的配置：

$ kustomize build $BASE  # build 出來的 YAML 太長就不貼處理了

$ kustomize build $BASE | kubectl apply -f -  # 這種方式直接部署在叢集中

$ kubectl apply -k # 1.14 版本可以直接使用該命令部署應用於叢集中

　　2.建立Overlays

　　建立一個staging和production overlay，目錄樹結構如下所示：

OVERLAYS=$DEMO_HOME/overlays

mkdir -p $OVERLAYS/staging

mkdir -p $OVERLAYS/production

　　建立完成後目錄樹格式如下：

ldap

├── base

│   ├── deployment.yaml

│   ├── env.startup.txt

│   ├── kustomization.yaml

│   └── service.yaml

└── overlays

    ├── production

    └── staging

　　演示環境 kustomization

　　下載staging customization and patch

curl -s -o "$OVERLAYS/staging/#1" "$CONTENT/overlays/staging\

/{config.env,deployment.yaml,kustomization.yaml}"

　　Staging下所有程式碼如下

#檔案路徑: $OVERLAYS/staging/kustomization.yaml

resources:

- ../../base

patchesStrategicMerge:

 - deployment.yaml

namePrefix: staging-

configMapGenerator:

- name: env-config

  files:

  - config.env

#檔案路徑:$OVERLAYS/staging/deployment.yaml

apiVersion: apps/v1

kind: Deployment

metadata:

  name: ldap

spec:

  replicas: 2

#config.env

DB_USERNAME=admin

DB_PASSWORD=somepw

　　下面簡單簡述以下每個檔案的作用

　　Staging新增configMap

#檔案路徑: $OVERLAYS/staging/kustomization.yaml

resources:

- ../../base

patchesStrategicMerge:

 - deployment.yaml

namePrefix: staging-

configMapGenerator:

- name: env-config

  files:

  - config.env

　　已經增加2個副本

#檔案路徑:$OVERLAYS/staging/deployment.yaml

apiVersion: apps/v1

kind: Deployment

metadata:

  name: ldap

spec:

  replicas: 2

　　生產環境Kustomization

　　下載 production customization and patch

curl -s -o "$OVERLAYS/production/#1" "$CONTENT/overlays/production\

/{deployment.yaml,kustomization.yaml}"

　　下面也簡述以下各檔案程式碼的作用，可以看到生產環境增加了6個副本以及gce磁碟

#檔案路徑:$OVERLAYS/production/deployment.yaml

apiVersion: apps/v1

kind: Deployment

metadata:

  name: ldap

spec:

  replicas: 6

  template:

    spec:

      volumes:

        - name: ldap-data

          emptyDir: null

          gcePersistentDisk:

            pdName: ldap-persistent-storage

#檔案路徑:$OVERLAYS/production/kustomization.yaml

resources:

  - ../../base

patchesStrategicMerge:

  - deployment.yaml

namePrefix: production-

　　3.配置區別對比

　　目錄下現在包含：

- a base directory - 對原始配置進行稍微定製的克隆
- an overlays directory，包含在叢集中建立不同的登臺和生產變體所需的kustomizations和補丁。

　　檢視一下最終結構目錄

tree $DEMO_HOME

/test/ldap

├── base

│   ├── deployment.yaml

│   ├── env.startup.txt

│   ├── kustomization.yaml

│   └── service.yaml

└── overlays

    ├── production

    │   ├── deployment.yaml

    │   └── kustomization.yaml

    └── staging

        ├── config.env

        ├── deployment.yaml

        └── kustomization.yaml

　　直接比較輸出，看看staging和production有何不同:

diff \

  <(kustomize build $OVERLAYS/staging) \

  <(kustomize build $OVERLAYS/production) |\

  more

　　差異如下

3,11d2

<   config.env: |

<     DB_USERNAME=admin

<     DB_PASSWORD=somepw

< kind: ConfigMap

< metadata:

<   name: staging-env-config-42m8gk5kg2

< ---

< apiVersion: v1

< data:

76c67

<   name: staging-ldap-configmap-4d7m6k5b42

---

>   name: production-ldap-configmap-4d7m6k5b42

83c74

<   name: staging-ldap-service

---

>   name: production-ldap-service

95c86

<   name: staging-ldap

---

>   name: production-ldap

97c88

<   replicas: 2

---

>   replicas: 6

126c117,118

<       - emptyDir: {}

---

>       - gcePersistentDisk:

>           pdName: ldap-persistent-storage

133c125

<           name: staging-ldap-configmap-4d7m6k5b42

---

>           name: production-ldap-configmap-4d7m6k5b42

　　4.部署不同環境

　　需要在生產環境部署應用，通過下面命令

$ kustomize build $OVERLAYS/staging | kubectl apply -f -   # 或者 kubectl apply -k

　　需要在演示環境部署應用，通過下面命令

$ kustomize build $OVERLAYS/production | kubectl apply -f -     # 或者 kubectl apply -k

5.2 helloWorld示例

　　1.新建一個Base目錄

　　首先建立工作目錄以及定義工作目錄變數等資訊

DEMO_HOME=/test/hello

BASE=$DEMO_HOME/base

mkdir -p $BASE

curl -s -o "$BASE/#1.yaml" "https://raw.githubusercontent.com\

/kubernetes-sigs/kustomize\

/master/examples/helloWorld\

/{configMap,deployment,kustomization,service}.yaml"

　　具體的程式碼檔案見以下，或者直接clonegit倉庫程式碼。

#configMap.yaml

apiVersion: v1

kind: ConfigMap

metadata:

  name: the-map

data:

  altGreeting: "Good Morning!"

  enableRisky: "false"

#deployment.yaml

apiVersion: apps/v1

kind: Deployment

metadata:

  name: the-deployment

spec:

  replicas: 3

  selector:

    matchLabels:

      deployment: hello

  template:

    metadata:

      labels:

        deployment: hello

    spec:

      containers:

      - name: the-container

        image: monopole/hello:1

        command: ["/hello",

                  "--port=8080",

                  "--enableRiskyFeature=$(ENABLE_RISKY)"]

        ports:

        - containerPort: 8080

        env:

        - name: ALT_GREETING

          valueFrom:

            configMapKeyRef:

              name: the-map

              key: altGreeting

        - name: ENABLE_RISKY

          valueFrom:

            configMapKeyRef:

              name: the-map

              key: enableRisky

#service.yaml

kind: Service

apiVersion: v1

metadata:

  name: the-service

spec:

  selector:

    deployment: hello

  type: LoadBalancer

  ports:

  - protocol: TCP

    port: 8666

targetPort: 8080

##kustomization.yaml

apiVersion: kustomize.config.k8s.io/v1beta1

kind: Kustomization

metadata:

  name: arbitrary

# Example configuration for the webserver

# at https://github.com/monopole/hello

commonLabels:

  app: hello

resources:

- deployment.yaml

- service.yaml

- configMap.yaml

　　這裡使用官網的helloWorld的YAML資原始檔作為示例，程式碼準備完成後檔案結構如下：

hello

└── base

    ├── configMap.yaml

    ├── deployment.yaml

    ├── kustomization.yaml

    └── service.yaml

　　接下來看看kustomization.yaml配置檔案中包含什麼內容：

apiVersion: kustomize.config.k8s.io/v1beta1

kind: Kustomization

metadata:

  name: arbitrary

# Example configuration for the webserver

# at https://github.com/monopole/hello

commonLabels:

  app: hello

resources:

- deployment.yaml

- service.yaml

- configMap.yaml

　　這個檔案聲明瞭這些YAML資源(deployments、services、configmap 等)以及要應用於它們的一些自定義，如新增一個通用的標籤。kustomization還提供namePrefix、commonAnnoations、images等配置項，全部配置在github的示例kustomization.yaml中。

　　這時候，可以通過kustomize build命令來看完整的配置：

$ kustomize build $BASE  # build 出來的 YAML 太長就不貼處理了

$ kustomize build $BASE | kubectl apply -f -  # 這種方式直接部署在叢集中

$ kubectl apply -k # 1.14 版本可以直接使用該命令部署應用於叢集中

　　build出來的YAML每個資源物件上都會存在通用的標籤app:hello

　　2.建立Overlays

　　建立一個staging和production overlay，目錄樹結構如下所示：

OVERLAYS=$DEMO_HOME/overlays

mkdir -p $OVERLAYS/staging

mkdir -p $OVERLAYS/production

　　建立完成後目錄樹格式如下：

hello

├── base

│   ├── configMap.yaml

│   ├── deployment.yaml

│   ├── kustomization.yaml

│   └── service.yaml

└── overlays

    ├── production

    └── staging

　　演示環境 kustomization

　　在staging kustomization檔案中，定義一個新的名稱前輟以及一些不同的標籤

#檔案路徑: $OVERLAYS/staging/kustomization.yaml

cat <<'EOF' > $OVERLAYS/staging/kustomization.yaml

namePrefix: staging-              #定義的 yaml 檔案中為名稱新增字首

commonLabels:         #為資源新增標籤和選擇器。如果資源上已存在標籤鍵，則該值將被覆蓋。

  variant: staging

  org: acmeCorporation

commonAnnotations:    #為資源添加註釋。如果資源上已存在註釋鍵，則該值將被覆蓋。

  note: Hello, I am staging!

bases:

- ../../base

patchesStrategicMerge:   #補丁檔案來源，若有相同配置，就覆蓋

- map.yaml

EOF

　　演示環境 patch

　　新增一個ConfigMap自定義把base中的ConfigMap中的 "Good Morning!" 變成" Have a pineapple!"

#檔案路徑: $OVERLAYS/staging/map.yaml

cat <<EOF >$OVERLAYS/staging/map.yaml

apiVersion: v1

kind: ConfigMap

metadata:

  name: the-map

data:

  altGreeting: "Have a pineapple!"

  enableRisky: "true"

EOF

　　生產環境 kustoimzation

　　在生產環境目錄下，建立一個kustomization.yaml檔案，定義不同的名稱及標籤

#檔案路徑:$OVERLAYS/production/kustomization.yaml

cat <<EOF >$OVERLAYS/production/kustomization.yaml

namePrefix: production-

commonLabels:

  variant: production

  org: acmeCorporation

commonAnnotations:

  note: Hello, I am production!

bases:

- ../../base

patchesStrategicMerge:

- deployment.yaml

EOF

　　生產環境 patch

　　建立一個生產環境的 patch, 定義增加副本數量

#檔案路徑:$OVERLAYS/production/deployment.yaml

cat <<EOF >$OVERLAYS/production/deployment.yaml

apiVersion: apps/v1

kind: Deployment

metadata:

  name: the-deployment

spec:

  replicas: 10

EOF

　　3.配置區別對比

　　目錄下現在包含：

- a base directory - 對原始配置進行稍微定製的克隆
- an overlays directory，包含在叢集中建立不同的登臺和生產變體所需的kustomizations和補丁。

　　檢視一下最終結構目錄

tree $DEMO_HOME

hello

├── base

│   ├── configMap.yaml

│   ├── deployment.yaml

│   ├── kustomization.yaml

│   └── service.yaml

└── overlays

    ├── production

    │   ├── deployment.yaml

    │   └── kustomization.yaml

    └── staging

        ├── kustomization.yaml

        └── map.yaml

　　直接比較輸出，看看staging和production有何不同:

diff \

  <(kustomize build demo/overlays/staging) \

  <(kustomize build demo/overlays/production) |\

  more

　　差異如下

<   altGreeting: Have a pineapple!

<   enableRisky: "true"

---

>   altGreeting: Good Morning!

>   enableRisky: "false"

8c8

<     note: Hello, I am staging!

---

>     note: Hello, I am production!

11c11

<     variant: staging

---

>     variant: production

13c13

(...truncated)

　　4.部署不同環境

　　需要在生產環境部署應用，通過下面命令

$ kustomize build demo/overlays/production | kubectl apply -f -   # 或者 kubectl apply -k

　　需要在演示環境部署應用，通過下面命令

$ kustomize build demo/overlays/staging | kubectl apply -f -     # 或者 kubectl apply -k

6.workflows工作流

　　kustomize將對Kubernetes應用的管理轉換成對Kubernetes manifests YAML檔案的管理，而對應用的修改也通過YAML檔案來修改。這種修改變更操作可以通過Git版本控制工具進行管理維護, 因此使用者可以使用Git風格的流程來管理應用。workflows是使用並配置應用所使用的一系列Git風格流程步驟。官網提供了兩種方式，一種是定製配置，另一種是現成配置

　　1.定製配置

　　在這個工作流中，所有的配置（YAML 檔案）都屬於使用者所有。

　　通過上面兩種工作流方式，可以實現自定義管理應用的宣告式資原始檔，或者基於別人的應用宣告式資源進行自定義修改

# 定製工作流步驟如下：

1、建立一個目錄用於版本管理

git init ~/ldap

2、建立一個 base

mkdir -p ~/ldap/base  # 在這個目錄中建立並提交 kustomization.yaml 檔案和一組資源，例如 deployment、service

3、建立 overlays

mkdir -p ~/ldap/overlays/staging

mkdir -p ~/ldap/overlays/production

4、生成 variants

kustomize build ~/ldap/overlays/staging | kubectl apply -f -

kustomize build ~/ldap/overlays/production | kubectl apply -f -

kubectl v1.14 版使用下面：

kubectl apply -k ~/ldap/overlays/staging

kubectl apply -k ~/ldap/overlays/production

　　2.現成配置

　　在這個工作流方式中，可從別人的repo中fork kustomize配置，並根據自己的需求來配置

# 現成配置工作流步驟如下：

1、通過 fork 方式獲得現成配置

2、clone 作為你的 base

mkdir ~/ldap

git clone https://github.com/$USER/ldap ~/ldap/base

cd ~/ldap/base

git remote add upstream [email protected]:$USER/ldap

3、建立並填充 overlays

mkdir -p ~/ldap/overlays/staging

mkdir -p ~/ldap/overlays/production

4、生成 variants

kustomize build ~/ldap/overlays/staging | kubectl apply -f -

kustomize build ~/ldap/overlays/production | kubectl apply -f -

5、(可選)更新上游配置，使用者可以定期更新他的 base, 以更新上游所做的修改

cd ~/ldap/base

git fetch upstream

git rebase upstream/master

　　通過上面兩種工作流方式，可以實現自定義管理應用的宣告式資原始檔，或者基於別人的應用宣告式資源進行自定義修改

7.kustomize vs Helm

　　通過上面對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 物件來管理應用

8.總結

　　Kustomize給Kubernetes的使用者提供一種可以重複使用配置的宣告式應用管理，從而在配置工作中使用者只需要管理和維護Kubernetes的原生API物件，而不需要使用複雜的模版。同時，使用kustomzie可以僅通過Kubernetes宣告式 API 資原始檔管理任何數量的kubernetes 定製配置，可以通過fork/modify/rebase 這樣的工作流來管理海量的應用描述檔案。

9.參考

kustomize簡單使用