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

posted @ 2021-07-04 20:16 小家电维修阅读(760) 评论(0) 编辑收藏举报

刷新页面返回顶部

小家电维修

kustomize简单使用

1.背景

2.kustomize是什么？

3.kustomize解决了什么痛点？

4.kustomize术语

5.kustomize 官方示例

5.1 ldap示例

1.新建一个Base目录

2.创建Overlays

3.配置区别对比

4.部署不同环境

5.2 helloWorld示例

1.新建一个Base目录

2.创建Overlays

3.配置区别对比

4.部署不同环境

6.workflows工作流

1.定制配置

2.现成配置

7.kustomize vs Helm

8.总结

9.参考

公告

　　1.新建一个Base目录

　　2.创建Overlays

　　3.配置区别对比

　　4.部署不同环境

　　1.新建一个Base目录

　　2.创建Overlays

　　3.配置区别对比

　　4.部署不同环境

　　1.定制配置

　　2.现成配置