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代码准备完成后文件结构如下：

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的示例中。

　　这时候，可以通过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 git@github.com:$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.参考

作者：小家电维修

相见有时，后会无期。

相关阅读:
函数
 文件的基本操作
 c语言程序设计案例教程（第2版）笔记（一）—零散、输入输出、最小公倍数、选择排序、冒泡排序
 c语言中的rand()函数用法
 c语言 error C4996: 'strupr': The POSIX name for this item is deprecated. Instead, use the ISO C and C++ conformant name
Python之列表生成式、生成器
 Python之迭代器
 Python之装饰器
 Linux之线程相关命令及常用命令
 重写、重构、重载区别
原文地址：https://www.cnblogs.com/lizexiong/p/14969791.html