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

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

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

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

前言

前篇文章探讨了基於 Kustomize 的客制化行为，另外一个常见的应用程序处理方式就是 Helm， Helm 采用的是基於 template 的方式来动态渲染出一个可用的 YAML。
本篇文章就会探讨两种不同使用 Helm 的方式。

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

本地 Helm Chart

Helm Chart 基於 go-template 的方式来客制化 Yaml 内的数值，这意味者 Helm Chart 本身所拥有的 YAML 其实大部分情况下都不是一个合法 YAML，都需要让 Helm 动态的将相关数值给填入到 Helm YAML 中来产生最後的档案内容。

下方是一个 Helm YAML 的范例

apiVersion: apps/v1
kind: Deployment
metadata:
  name: frontend
spec:
  selector:
    matchLabels:
      app: guestbook
      tier: frontend
  replicas: {{ .Values.replicas }}
  template:
    metadata:
      labels:
        app: guestbook
        tier: frontend
    spec:
      containers:
      - name: php-redis
        image: gcr.io/google-samples/gb-frontend:v4
        resources:
          requests:
            cpu: 100m
            memory: 100Mi
        ports:
        - containerPort: 80

可以看到 replicas 的部分抽出来，变成一个 template 的格式，搭配下方的 values.yaml

replicas: 1

Helm 就会动态的将 replicas 的数值给填入到上方的 template 来产生最终要送到 Kubernetes 内的 YAML 物件。

有了基本概念之後，就可以来看看如何透过 Fleet 来管理 Helm 的应用程序。

这次的应用程序会直接使用 Helm 内建的范例应用程序，透过 helm create $name 就可以创建出来
所以移动到 app 资料夹底下，输入 helm create helm 即可

╰─$ helm create helm
Creating helm
╰─$ tree helm
helm
├── Chart.yaml
├── charts
├── templates
│   ├── NOTES.txt
│   ├── _helpers.tpl
│   ├── deployment.yaml
│   ├── hpa.yaml
│   ├── ingress.yaml
│   ├── service.yaml
│   ├── serviceaccount.yaml
│   └── tests
│       └── test-connection.yaml
└── values.yaml

该 Helm 的范例应用程序会部署一个 nginx 的应用程序，并且为其配上一个 service + ingress 的服务。

这次希望透过 Fleet 为两个不同的 workspace 去部署不同的环境，意味者 testing workspace 底下的两个丛集(dev/qa) 采用一组设定，而 prod workspace 底下的 it 丛集采用另外一组设定。

修改的部分采取简单好理解即可
针对 testing 的环境

1. replica 设定为 2 份，

prod 的环境

1. replica 为 3
2. 开启 Ingress 物件

为了完成这件事情针对 workspace 下多个 cluster 统一设定，必须要先完成下列之一

1. 将群组给 group 起来
2. 给丛集有对应的 Label

因此先到 UI 部分将 Prod Workspace 底下的 cluster (rke-it) 给予一个 env=prod 的 Label.

接者到 testing workspace 底下创建一组 Cluster Group，创建 Cluster Group 的时候可以根据条件去抓到符合条件的 Cluster，预设情况下没有设定的话就是全抓。
系统还会告诉你目前有多少个 Cluster 符合当前的 Selector，以我们的环境来说该 workspace 底下有两个不同的 cluster。

一切准备就绪後就来准备 Fleet.yaml

╰─$ cat fleet.yaml
namespace: helminternal
targetCustomizations:
- name: prod
  helm:
    values:
      replicaCount: 3
      ingress:
        enabled: true
        hosts:
          - host: rancher.hwchiu.com
            paths:
              - /testing
  clusterSelector:
    matchLabels:
      env: prod

- name: test
  helm:
    values:
      replicaCount: 2
  clusterGroup: testing-group

因为 Fleet 会自己侦测若路径中有 Chart.yaml 档案的话，就会使用 Helm 的方式去处理，所以不需要特别於 Fleet.yaml 中去描述需要使用 Helm。
这次的范例会安装到 helminternal 这个 namespace 中，接者底下针对两种不同的客制化。
如果 cluster 本身含有 env:prod 这种标签的话，就会将其的复本数量设定为 3 个，并且将 ingress 给设定为 enable，为了让 Ingress 物件可以顺利创立，需要针对 hosts 底下的物件也给予设定，这边随便写就好，目的只是测试 ingress 物件的部署。

另外一个则是直接使用 testing-group 这个 cluster group，对其底下的所有 cluster 都设定副本数为 2 。

记得也要对 repo/*/app-basic.yaml 两个档案去增加 app/helm 的路径，这样 GitRepo 才知道也要去扫描 app/helm 的路径。

一切都部署完毕後，使用 kubectl 去观察部署的资源，可以观察到 rke-it 这个属於 prod workspace 的丛集被部署了三个副本的 deployment 外加一个 ingress 资源。

至於 testing workspace 下的两个丛集的部署资源都一致，都只有两个副本的 deployment，没有任何 ingress 物件。

远方 Helm Chart

实务上并不是所有部署到团队中的 Helm Chart 都是由团队自行维护的，更多情况下可能是使用外部别人包装好的 Helm Chart，譬如 Prometheus-operator 等。

这种情况下专案的路径内就是透过 fleet.yaml 来描述要使用哪个远方的 Helm Chart 以及要如何客制化。

这边直接使用官方 Helm-External的范例 来操作。

首先先於 app 资料夹底下创建一个 helm-external 的资料夹，因为这次不需要准备 Helm Chart 的内容，所以直接准备一个 fleet.yaml 的档案即可。

fleet.yaml 内容如下

╰─$ cat fleet.yaml
namespace: helmexternal
helm:
  chart: https://github.com/rancher/fleet-examples/releases/download/example/guestbook-0.0.0.tgz
targetCustomizations:
- name: prod
  helm:
    valuesFiles:
      - prod_values.yaml
  clusterSelector:
    matchLabels:
      env: prod

- name: test
  helm:
    valuesFiles:
      - testing_values.yaml
  clusterGroup: testing-group

如果要使用远方的 Helm Chart，总共有两种不同的写法，一种是参考上述直接於 chart 中描述完整的下载路径。
针对一般的 Helm Chart Server 来说会更常使用下列这种形式

helm:
    repo: https://charts.rancher.io
    chart: rancher-monitoring
    version: 9.4.202

这种形式更加容易理解要去哪个 Helm Chart 抓取哪个版本的 Helm Chart 应用程序。

接者这次的 fleet.yaml 要采用不同的方式去进行客制化，当 Helm Values 的客制化非常多的时候，有可能会使得 fleet.yaml 变得冗长与复杂，这时候可以透过 valuesFiles 的方式，将不同环境用到的 values 内容给独立撰写成档案，然後於 fleet.yaml 中将该档案给读取即可。

╰─$ cat prod_values.yaml
serviceType: NodePort
replicas: 3
╰─$ cat testing_values.yaml
serviceType: ClusterIP
replicas: 2

上述两个设定档案就是针对不同副本去处理，同时 prod 环境下会将 service 给转换为 NodePort 类型。
一切完毕後记得修改 repo/*/app-basic.yaml 内的路径。
注意的是这边的 replica/serviceType 只会影响 Helm 里面的 frontend deployment/service，纯粹是对方 helm chart 的设计。

部署完毕後透过 kubectl 观察部署的状况

可以观察到 prod workspace 底下的 rke-it 丛集内的确将 frontend 的 replica 设定成 3个，同时 frontend 的 service 也变成 NodePort

而剩下两个丛集也符合预期的是一个两副本的 deployment 与 ClusterIP

下篇文章将来探讨 fleet 最有趣的玩法，Helm + Kustomize 两者结合一起运行。