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 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.参考