缘起

在 kustomize 呈现之前，Kubernetes 治理利用的形式次要是通过 Helm 或者下层 Paas 来实现。这些工具通常通过特定畛域配置语言(DSL，如Go template、jsonnet) 来保护并治理利用，并且须要参数化模板形式(如 helm) 来自定义配置，这须要额定学习简单的 DSL 语法及容易出错。

kustomize 是什么

kustomize 是 kubernetes 原生的配置管理，以无模板形式来定制利用的配置。kustomize 应用 k8s 原生概念帮忙创立并复用资源配置(YAML)，容许用户以一个利用形容文件 （YAML 文件）为根底（Base YAML），而后通过 Overlay 的形式生成最终部署利用所需的形容文件。

kustomize 解决了什么痛点

  • 如何治理不同环境或不同团队的利用的 Kubernetes YAML 资源
  • 如何以某种形式治理不同环境的渺小差别，使得资源配置能够复用，缩小 copy and change 的工作量
  • 如何简化保护利用的流程，不须要额定学习模板语法

Kustomize 通过以下几种形式解决了上述问题：

  • kustomize 通过 Base & Overlays 形式形式保护不同环境的利用配置
  • kustomize 应用 patch 形式复用 Base 配置，并在 Overlay 形容与 Base 利用配置的差别局部来实现资源复用
  • kustomize 治理的都是 Kubernetes 原生 YAML 文件，不须要学习额定的 DSL 语法

官网示例

指标: 应用 kustomize 治理 stage、production 两个环境的 helloword 利用

前提

  • 两个不同的环境(演示、生产)
  • 一个 deployments 资源和 service 资源
  • 环境之间有不同的 replicas 或者 ConfigMap

最终文件构造

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

新建一个 Base 目录

这里应用官网的 helloWorld 的 YAML 资源文件作为示例，在 base 目录下新增几个 k8s YAML 资源文件，文件构造如下：

demo└── base    ├── configMap.yaml    ├── deployment.yaml    ├── kustomization.yaml    └── service.yaml

接下来看看 kustomization.yaml 配置文件中蕴含什么内容：

# filename: demo/base/kustomization.yamlcommonLabels:  app: helloresources:- deployment.yaml- service.yaml- configMap.yaml

这个文件申明了这些 YAML 资源(deployments、services、configmap 等)以及要利用于它们的一些自定义，如增加一个通用的标签。kustomization 还提供了namePrefix、commonAnnoations、images 等配置项

其余几个文件别离如下：

# filename: demo/base/configMap.yamlapiVersion: v1kind: ConfigMapmetadata:  name: the-mapdata:  altGreeting: "Good Morning!"  enableRisky: "false"
# filename: demo/base/service.yamlkind: ServiceapiVersion: v1metadata:  name: the-servicespec:  selector:    deployment: hello  type: LoadBalancer  ports:  - protocol: TCP    port: 8666    targetPort: 8080
# filename: demo/base/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

这时候，能够通过 kustomize build 命令来看残缺的配置：

kustomize build demo/base

另外部署的时候能够间接应用上面的命令

# kubectl apply -k demo/base # 这种形式间接部署在集群中

build 进去的 YAML 每个资源对象上都会存在通用的标签 app: hello

上面为 build 后果：

apiVersion: v1data:  altGreeting: Good Morning!  enableRisky: "false"kind: ConfigMapmetadata:  labels:    app: hello  name: the-map---apiVersion: v1kind: Servicemetadata:  labels:    app: hello  name: the-servicespec:  ports:  - port: 8666    protocol: TCP    targetPort: 8080  selector:    app: hello    deployment: hello  type: LoadBalancer---apiVersion: apps/v1kind: Deploymentmetadata:  labels:    app: hello  name: the-deploymentspec:  replicas: 3  selector:    matchLabels:      app: hello      deployment: hello  template:    metadata:      labels:        app: hello        deployment: hello    spec:      containers:      - command:        - /hello        - --port=8080        - --enableRiskyFeature=$(ENABLE_RISKY)        env:        - name: ALT_GREETING          valueFrom:            configMapKeyRef:              key: altGreeting              name: the-map        - name: ENABLE_RISKY          valueFrom:            configMapKeyRef:              key: enableRisky              name: the-map        image: monopole/hello:1        name: the-container        ports:        - containerPort: 8080

创立 Overlays

创立一个 staging 和 production overlay，目录树结构如下所示：

demo├── base│   ├── configMap.yaml│   ├── deployment.yaml│   ├── kustomization.yaml│   └── service.yaml└── overlays    ├── production    └── staging
演示环境 kustomization

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

# filename: demo/overlays/staging/kustomization.yamlnamePrefix: staging-commonLabels:  variant: staging  org: acmeCorporationcommonAnnotations:  note: Hello, I am staging!bases:- ../../basepatchesStrategicMerge:- map.yaml
演示环境 patch

增加一个 ConfigMap 自定义把 base 中的 ConfigMap 中的 "_Good Morning!_" 变成 "Good Night!"

# 文件门路 demo/overlays/staging/map.yamlapiVersion: v1kind: ConfigMapmetadata:  name: the-mapdata:  altGreeting: "Have a pineapple!"  enableRisky: "true"
生产环境 kustoimzation

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

# filename: demo/overlays/production/kustomization.yamlnamePrefix: production-commonLabels:  variant: production  org: acmeCorporationcommonAnnotations:  note: Hello, I am production!bases:- ../../basepatchesStrategicMerge:- deployment.yaml
生产环境 patch

创立一个生产环境的 patch, 定义减少正本数量

# filename: demo/overlays/production/deployment.yamlapiVersion: apps/v1kind: Deploymentmetadata:  name: the-deploymentspec:  replicas: 10

部署不同环境

须要在演示环境部署利用，通过上面命令

kubectl apply -k  demo/overlays/staging

比照 base 、staging 生成的文件

kustomize build demo/base > /tmp/base.yamlkustomize build demo/overlays/staging > /tmp/staging.yamlvimdiff /tmp/base.yaml /tmp/staging.yaml

须要在生产环境部署利用，通过上面命令

kubectl apply -k  demo/overlays/production

比照 base 、production 生成的文件

kustomize build demo/base > /tmp/base.yamlkustomize build demo/overlays/production > /tmp/production.yamlvimdiff /tmp/base.yaml /tmp/production.yaml

参考

kustomize github 地址
kustomize 本文示例
kustomize 官网所有示例
kustomize 最简实际