本文将於赛後同步刊登於笔者部落格

有兴趣学习更多 Kubernetes/DevOps/Linux 相关的资源的读者，欢迎前往阅读

更多相关科技的技术分享，欢迎追踪 矽谷牛的耕田笔记

对於 Kubernetes 与 Linux Network 有兴趣的可以参阅笔者的线上课程

前言

前篇文章探讨了基於 Helm 的客制化行为，透过两种不同方式来部署 Helm 的应用程序，透过 Helm Values 的设定可以让管理人员更容易的去设定与处理不同的设定。

实务上如果采用的是远方 Helm Chart Server 的部署方式，还是有机会遇到绑手绑脚的问题，譬如想要针对某些栏位客制化，但是该 Helm Chart 却没有定义等
这时候就可以补上 Kustomize 来进行二次处理，应用程序先透过 Helm 进行第一层处理，接者透过 Kustomize 进行二次处理，帮忙 Patch 一些不能透过 values.yaml 控制的栏位。

本篇所有 YAML 范例都来自於官方范例。

Helm + Kustomize

使用远方 Helm Chart 来部署应用程序的人可能都会有下列的经验

1. Helm Values 没有提供自己想要的栏位
2. 如果该 Helm Chart 里面需要 secret 的物件，需要自己额外部署，没有办法跟该 Helm Chart 融为一体。

不同问题会有不同解决方法，譬如

1. 尝试针对该 Helm Charts 提交 PR 去增加更多的 values 栏位可以使用。这种情况的解法比较漂亮，但是要花比较长的时间来处理程序码的合并与审核。
2. 复制远方的 Helm Chart 到本地环境中，手动修改栏位符合自己需求，没有将修改推回远方的 upstream.
3. 团队内创造一个全新的 Helm Chart，该 Helm Chart 透过 requirement 的概念来使用本来要用的 Helm Chart，接者於自己的环境中补上其他资源。

如果 Helm Values 没有提供自己想要的栏位，那(1)/(2) 这两种解法都可以处理，毕竟都有能力针对本来的 Helm YAML 进行改写。
但是如果今天的需求是想要加入一些全新的 YAML 档案，譬如上述的 Secret 物件，那(1)/(2)/(3) 三种方法都可以采用。

第一个方法需要花时间将修改合并到 upstream 的专案，而第二个方法其实维护起来很麻烦，因为每次远方有任何版本更新时都要重新检查。第三个方法又不能针对 values 的方式去客制化。

Fleet 中提供了一个有效的方式来解决这个困境，就是 Helm + Kustomize 的组合技
透过 Helm 进行第一次的渲染，接者透过 Kustomize 的方式可以达到

1. 动态增加不同的 Kubernetes 物件
2. 透过 Kustomize 的 Patch 方式可以动态修改栏位

因此上述的情境问题就可以完美解决。

注: Kustomize 今年的新版本也尝试提供 Helm 的支援，让你可以透过 Kustomize 的方式去部署 Helm 的应用程序，详细可以参考 kustomization of a helm chart

本次的范例继续使用前篇文章的 Helm Chart，使用 Rancher 提供的 guestbook 作为远方的 Helm Chart 档案，接者透过 Kustomize 的方式来动态修改栏位与增加资源。

这次的环境部署要求如下。
预设情况下先透过 Helm Values 将 frontend 的副本数调高为 3

dev 丛集:

1. 将 serviceType 改成 LoadBalancer

it 丛集:

1. 将 redis-slave 的副本数改成 0 (预设是2)

qa 丛集:

1. 新增一个基於 nginx 的 deployment

有了这些概念後，就来准备相关的档案，这次於 app 底下创建名为 helm_kustomize 的资料夹，并且於里面先准备一个 fleet.yaml 的档案。

╰─$ cat fleet.yaml
namespace: helmkustomize
helm:
  chart: https://github.com/rancher/fleet-examples/releases/download/example/guestbook-0.0.0.tgz
  values:
    replicas: 3
targetCustomizations:
- name: dev
  clusterSelector:
    matchLabels:
      management.cattle.io/cluster-display-name: ithome-dev
  kustomize:
    dir: overlays/dev

- name: it
  clusterSelector:
    matchLabels:
      management.cattle.io/cluster-display-name: rke-it
  kustomize:
    dir: overlays/it

- name: qa
  clusterSelector:
    matchLabels:
      management.cattle.io/cluster-display-name: rke-qa
  kustomize:
    dir: overlays/qa

上述的 fleet.yaml 中首先透过 helm chart 去抓取远方的 helm chart server，接者透过 values 的方式将 frontend 的副本数设定为三个。

接下来是丛集客制化的部分，每个丛集这次采用丛集名称作为比对的方式，接者使用 kustomize 的方式去 overlays 底下的资料夹来客制化。

╰─$ tree .
.
├── dev
│   ├── frontend-service.yaml
│   └── kustomization.yaml
├── it
│   ├── kustomization.yaml
│   └── redis-slave-deployment.yaml
└── qa
    ├── deployment.taml
    └── kustomization.yaml

╰─$ cat dev/frontend-service.yaml
kind: Service
apiVersion: v1
metadata:
  name: frontend
spec:
  type: LoadBalancer
╰─$ cat dev/kustomization.yaml
patches:
- frontend-service.yaml


╰─$ cat it/kustomization.yaml
patches:
- redis-slave-deployment.yaml
╰─$ cat it/redis-slave-deployment.yaml
kind: Deployment
apiVersion: apps/v1
metadata:
  name: redis-slave
spec:
  replicas: 0


╰─$ cat qa/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: test
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx-server
        image: nginx

╰─$ cat qa/kustomization.yaml
resources::
- deployment.yaml

准备好这些档案并且修改 repo/*/app-basic.yaml 後，就可以将修改给推到远方的 Git 专案，接者等待 Fleet 来帮忙处理部署。

使用 kubectl 工具观察

Dev 的环境可以观察到

1. Frontend 的 replica 是三个副本
2. Service 的类型改成 LoadBalancer

IT 的环境可以观察到

1. Frontend 的 replica 是三个副本
2. redis-slave 的 replica 变成 0

QA 的环境可以观察到

1. Frontend 的 replica 是三个副本
2. 新的一个 Deployment 叫做 test，有三个副本。

可以发现环境中的部署条件都有如先前所述，算是成功的透过 Helm + Kustomize 的方式来调整应用程序。

Fleet 本身发展的时间不算久，因此 UI 上有时候会有一些额外的 Bug，这些除了看官方文件外剩下都要看 Github 上的 issue 来找问题。

此外 Fleet 於 08/28/2021 正式推出 v0.3.6 版本，不过因为如果想要单纯使用 Rancher 来使用的话，那这样就必须要等待新版本的 Rancher 一起推出才可以直接享用新版本的整合。