kustomize简单使用

kustomize简单使用

1.背景

在kustomize出现之前，Kubernetes管理应用的方式主要是通过Helm或者上层Paas 来完成。这些工具通常通过特定领域配置语言(DSL，如Go template、jsonnet) 来维护并管理应用，并且需要参数化模板方式(如 helm) 来自定义配置，这需要学习复杂的DSL语法及容易出错。

2.kustomize是什么？

来看看官网的描述：

Kubernetes native configuration managementKustomize 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

variant

variant是在集群中将overlay应用于base的结果。例如开发和生产环境都修改了一些共同base以创建不同的variant。这些variant使用相同的总体资源，并与简单的方式变化，例如deployment的副本数、ConfigMap使用的数据源等。简而言之，variant是含有同一组base的不同kustomization

resource

patch

5.kustomize 官方示例

现在通过官方的示例来演示一下kustomize应该怎么用，以及相应的一些规范。如果你没有使用Kubernetes v1.14 版本，参考​​官方安装教程​​进行安装kustomize，或者直接- v1.14 版本kubectl二进制，通过kubectl -k命令使用kustomize。

官方更多实例地址: ​​​​ldap示例

1.新建一个Base目录

首先创建工作目录以及定义工作目录变量等信息

DEMO_HOME=/test/ldapBASE=$DEMO_HOME/basemkdir -p $BASECONTENT="-s -o "$BASE/#1" "$CONTENT/base\/{deployment.yaml,kustomization.yaml,service.yaml,env.startup.txt}"

具体的代码文件见以下，或者直接clonegit仓库代码。

#deployment.yamlapiVersion: apps/v1kind: Deploymentmetadata: name: ldap labels: app: ldapspec: 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.yamlapiVersion: v1kind: Servicemetadata: labels: app: ldap name: ldap-servicespec: ports: - port: 389 selector:app: ldap#kustomization.yamlresources:- deployment.yaml- service.yamlconfigMapGenerator:- 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 : Required and used for new ldap server onlyLDAP_ORGANISATION: Example Inc.LDAP_DOMAIN: example.orgLDAP_BASE_DN: #if empty automatically set from LDAP_DOMAINLDAP_ADMIN_PASSWORD: adminLDAP_CONFIG_PASSWORD: configLDAP_READONLY_USER: falseLDAP_READONLY_USER_USERNAME: readonlyLDAP_READONLY_USER_PASSWORD: readonlyLDAP_RFC2307BIS_SCHEMA: false# BackendLDAP_BACKEND: hdb# TlsLDAP_TLS: trueLDAP_TLS_CRT_FILENAME: ldap.crtLDAP_TLS_KEY_FILENAME: ldap.keyLDAP_TLS_CA_CRT_FILENAME: ca.crtLDAP_TLS_ENFORCE: falseLDAP_TLS_CIPHER_SUITE: SECURE256:+SECURE128:-VERS-TLS-ALL:+VERS-TLS1.2:-RSA:-DHE-DSS:-CAMELLIA-128-CBC:-CAMELLIA-256-CBCLDAP_TLS_VERIFY_CLIENT: demand# ReplicationLDAP_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 variablesLDAP_REPLICATION_CONFIG_SYNCPROV: binddn="cn=admin,cn=config" bindmethod=simple credentials=$LDAP_CONFIG_PASSWORD searchbase="cn=config" type=refreshAndPersist retry="60 +" timeout=1 starttls=criticalLDAP_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=criticalLDAP_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 setupLDAP_REMOVE_CONFIG_AFTER_SETUP: true# ssl-helper environment variables prefixLDAP_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.yamlconfigMapGenerator:- name: ldap-configmap files: - env.startup.txt

这时候，可以通过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/overlaysmkdir -p $OVERLAYS/stagingmkdir -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:- ../../basepatchesStrategicMerge: - deployment.yamlnamePrefix: staging-configMapGenerator:- name: env-config files: - config.env#文件路径:$OVERLAYS/staging/deployment.yaml apiVersion: apps/v1kind: Deploymentmetadata: name: ldapspec: replicas: 2#config.env DB_USERNAME=adminDB_PASSWORD=somepw

下面简单简述以下每个文件的作用

Staging添加configMap

#文件路径: $OVERLAYS/staging/kustomization.yaml resources:- ../../basepatchesStrategicMerge: - deployment.yamlnamePrefix: staging-configMapGenerator:- name: env-config files: - config.env

已经增加2个副本

#文件路径:$OVERLAYS/staging/deployment.yaml apiVersion: apps/v1kind: Deploymentmetadata: name: ldapspec: 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/v1kind: Deploymentmetadata: name: ldapspec: replicas: 6 template: spec: volumes: - name: ldap-data emptyDir: null gcePersistentDisk: pdName: ldap-persistent-storage#文件路径:$OVERLAYS/production/kustomization.yaml resources: - ../../basepatchesStrategicMerge: - deployment.yamlnamePrefix: production-

3.配置区别对比

目录下现在包含：

abasedirectory - 对原始配置进行稍微定制的克隆anoverlaysdirectory，包含在集群中创建不同的登台和生产变体所需的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-4d7m6k5b4283c74< name: staging-ldap-service---> name: production-ldap-service95c86< name: staging-ldap---> name: production-ldap97c88< replicas: 2---> replicas: 6126c117,118< - emptyDir: {}---> - gcePersistentDisk:> pdName: ldap-persistent-storage133c125< 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/helloBASE=$DEMO_HOME/basemkdir -p $BASEcurl -s -o "$BASE/#1.yaml" "v1kind: ConfigMapmetadata: name: the-mapdata: altGreeting: "Good Morning!" enableRisky: "false"#deployment.yamlapiVersion: apps/v1kind: Deploymentmetadata: name: the-deploymentspec: 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.yamlkind: ServiceapiVersion: v1metadata: name: the-servicespec: selector: deployment: hello type: LoadBalancer ports: - protocol: TCP port: 8666targetPort: 8080#kustomization.yamlapiVersion: kustomize.config.k8s.io/v1beta1kind: Kustomizationmetadata: name: arbitrary# Example configuration for the webserver# at app: helloresources:- 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/v1beta1kind: Kustomizationmetadata: name: arbitrary# Example configuration for the webserver# at app: helloresources:- deployment.yaml- service.yaml- configMap.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/overlaysmkdir -p $OVERLAYS/stagingmkdir -p $OVERLAYS/production

创建完成后目录树格式如下：

hello├── base│ ├── configMap.yaml│ ├── deployment.yaml│ ├── kustomization.yaml│ └── service.yaml└── overlays ├── production └── staging

演示环境 kustomization

在staging kustomization文件中，定义一个新的名称前辍以及一些不同的标签

#文件路径: $OVERLAYS/staging/kustomization.yamlcat <<'EOF' > $OVERLAYS/staging/kustomization.yamlnamePrefix: staging- #定义的 yaml 文件中为名称添加前缀commonLabels: #为资源添加标签和选择器。如果资源上已存在标签键，则该值将被覆盖。 variant: staging org: acmeCorporationcommonAnnotations: #为资源添加注释。如果资源上已存在注释键，则该值将被覆盖。 note: Hello, I am staging!bases: - ../../basepatchesStrategicMerge: #补丁文件来源，若有相同配置，就覆盖- map.yamlEOF

演示环境 patch

添加一个ConfigMap自定义把base中的ConfigMap中的 "Good Morning!" 变成" Have a pineapple!"

#文件路径: $OVERLAYS/staging/map.yamlcat <$OVERLAYS/staging/map.yamlapiVersion: v1kind: ConfigMapmetadata: name: the-mapdata: altGreeting: "Have a pineapple!" enableRisky: "true"EOF

生产环境 kustoimzation

在生产环境目录下，创建一个kustomization.yaml文件，定义不同的名称及标签

#文件路径:$OVERLAYS/production/kustomization.yamlcat <$OVERLAYS/production/kustomization.yamlnamePrefix: production-commonLabels: variant: production org: acmeCorporationcommonAnnotations: note: Hello, I am production!bases:- ../../basepatchesStrategicMerge:- deployment.yamlEOF

生产环境 patch

创建一个生产环境的 patch, 定义增加副本数量

#文件路径:$OVERLAYS/production/deployment.yamlcat <$OVERLAYS/production/deployment.yamlapiVersion: apps/v1kind: Deploymentmetadata: name: the-deploymentspec: replicas: 10EOF

3.配置区别对比

目录下现在包含：

abasedirectory - 对原始配置进行稍微定制的克隆anoverlaysdirectory，包含在集群中创建不同的登台和生产变体所需的kustomizations和补丁。

查看一下最终结构目录

tree $DEMO_HOMEhello├── 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: production13c13(...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 ~/ldap2、创建一个 basemkdir -p ~/ldap/base # 在这个目录中创建并提交 kustomization.yaml 文件和一组资源，例如 deployment、service3、创建 overlaysmkdir -p ~/ldap/overlays/stagingmkdir -p ~/ldap/overlays/production4、生成 variantskustomize build ~/ldap/overlays/staging | kubectl apply -f -kustomize build ~/ldap/overlays/production | kubectl apply -f -kubectl v1.14 版使用下面：kubectl apply -k ~/ldap/overlays/stagingkubectl apply -k ~/ldap/overlays/production

2.现成配置

在这个工作流方式中，可从别人的repo中fork kustomize配置，并根据自己的需求来配置

# 现成配置工作流步骤如下：1、通过 fork 方式获得现成配置2、clone 作为你的 basemkdir ~/ldapgit clone ~/ldap/basecd ~/ldap/basegit remote add upstream git@github.com:$USER/ldap 3、创建并填充 overlaysmkdir -p ~/ldap/overlays/stagingmkdir -p ~/ldap/overlays/production4、生成 variantskustomize build ~/ldap/overlays/staging | kubectl apply -f -kustomize build ~/ldap/overlays/production | kubectl apply -f -5、(可选)更新上游配置，用户可以定期更新他的 base, 以更新上游所做的修改cd ~/ldap/basegit fetch upstreamgit 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生成最终YAMLHelm 专注于应用的复杂性及生命周期管理(包括 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.总结

9.参考

​​kustomize官网​​

​​官方更多实例地址​​

​​官方配置项地址​​

​​kustomize github​​

​​kubectl docs​​

作者：​​小家电维修​​

​

转世燕还故榻,为你衔来二月的花。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。