2

简介

kustomize 是基于目录,使用 Base + Overlay 的方式对应用的原始 YAML 进行派生,功能简单清晰,kubectl 直接支持。

helm

Helm 使用 Go Template 对应用部署所需的 YAML 进行抽象,形成应用部署模板,在需要进行部署时,可以编写 yaml 为模板中的变量进行赋值,也可以在 Helm CLI 的命令行中使用 --set name=value 的方式来对简单变量进行赋值,完成赋值之后,可以选择使用 helm template 指令将 Chart + Value 的组合渲染成为 YAML 供 kubectl 使用,也可以使用 helm install 直接通过 Tiller 进行安装

对比

对比kustomize简洁,helm则提供更多的功能,如:

  1. chart包的管理,类似应用市场的概念。
  2. 直接和k8s apiserver交互,提供应用生命周期管理

但同时也带来了更复杂的架构,比如服务端进程tiller提供和k8s的交互,Repository存储 Helm Chart 的仓库。给我们的感觉是对标于类似yum,apt和brew之类的管理系统。

因此如果用户的目的只是做yaml文件的渲染,不想为此花费更多的时间和精力,比较适合使用kustomize。 如果是管理严谨的大型公开项目,可能helm更合适。

部署

部署比较简单,下载对应的release版本,授权运行即可。
https://github.com/kubernetes...

使用

kustomize是基于目录进行yaml文件管理和派生的。

应用的多环境部署

应用部署在不同环境配置是有不同的,查看kustomize目录结构:

[root@master01 kustomize]# tree  helloWorld/
helloWorld/
├── base
│   ├── configMap.yaml
│   ├── deployment.yaml
│   ├── kustomization.yaml
│   └── service.yaml
└── overlays
    ├── production
    │   └── staging
    │       ├── kustomization.yaml
    │       └── deplyment.yaml
    └── staging
        ├── kustomization.yaml
        └── map.yaml

5 directories, 8 files

base目录是项目的基础yaml文件,overlay中的目录staging,production在base的基础上,生成不同环境的应用部署yaml文件。

base

渲染出yaml文件

[root@master01 helloWorld]# kustomize  build base/
apiVersion: v1
data:
  altGreeting: Good Morning!
  enableRisky: "false"
kind: ConfigMap
metadata:
  labels:
    app: hello
  name: the-map
---
apiVersion: v1
kind: Service
metadata:
  labels:
    app: hello
  name: the-service

部署

kustomize build base/ | kubectl apply -f -

staging

staging环境在base的基础上,做一些修改

kustomization.yaml

[root@master01 staging]# cat kustomization.yaml 
namePrefix: staging-
commonLabels:
  variant: staging
  org: acmeCorporation
commonAnnotations:
  note: Hello, I am staging!
resources:
- ../../base
patchesStrategicMerge: # 这里意思是我们要把base里的configmap用下面的configmap overlay一下
- map.yaml

map.yaml

[root@master01 staging]# cat map.yaml 
apiVersion: v1
kind: ConfigMap
metadata:
  name: the-map
data:
  altGreeting: "Have a pineapple!"
  enableRisky: "true"

渲染后的staging环境功能yaml文件如下:

[root@master01 helloWorld]# kustomize  build overlays/staging/
apiVersion: v1
data:
  altGreeting: Have a pineapple!   # 对base中configmap进行了覆盖
  enableRisky: "true"
kind: ConfigMap
metadata:
  annotations:                     # kustomize中定义的commonAnnotations
    note: Hello, I am staging!  
  labels:                          # kustomize中定义的commonLabels
    app: hello
    org: acmeCorporation
    variant: staging
  name: staging-the-map            # kustomize中定义的namePrefix
---
apiVersion: v1
kind: Service
metadata:
  annotations:
    note: Hello, I am staging!
  labels:
    app: hello
    org: acmeCorporation
    variant: staging
  name: staging-the-service
spec:
···

ci/cd

另一个常见的使用场景是在ci/cd中,需要根据项目的tag,修改应用部署的镜像。

此时可以通过kustomize提供的命令kustomize edit set image,来方便的修改。

kustomize edit set image alpine=quay.io/datawire/ambassador:0.85.0
[root@master01 staging]# cat kustomization.yaml 
namePrefix: staging-
commonLabels:
  org: acmeCorporation
  variant: staging
commonAnnotations:
  note: Hello, I am staging!
resources:
- ../../base
patchesStrategicMerge:
- map.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
images:          # 此处为增加的image设置
- name: alpine
  newName: quay.io/datawire/ambassador
  newTag: 0.85.0

渲染后的文件

[root@master01 overlays]# kustomize build staging/
···
        env:
        - name: ENABLE_RISKY
          valueFrom:
            configMapKeyRef:
              key: enableRisky
              name: staging-the-map
        image: quay.io/datawire/ambassador:0.85.0  # image已修改
        name: the-container
        ports:
        - containerPort: 8080

manshu
65 声望9 粉丝

clear is better than clever