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

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

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

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

前言

前篇文章探讨了 Fleet.yaml 的基本概念，而本篇文章就会针对各种不同的情境来示范如何使用 fleet.yaml 来达到客制化的需求。

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

Overlay

第一个要示范的情境是使用纯 Kubernetes YAML 为基础的客制化，因为纯 Kubernetes YAML 没有办法达到类似 Helm/Kustomize 的内容客制化，所以能够提供的变化有限，顶多只能做到不同档案的资源部署。

假设今天总共有四种资源，该四种资源为

1. Deployment A
2. Service A
3. Deployment B
4. Service B

希望达到的客制化为
Dev 丛集安装

1. Deployment A
2. Service A

IT 丛集安装

1. Deployment A
2. Service A
3. Deployment B

QA 丛集安装

1. Deployment A
2. Service A
3. Deployment B
4. Service B

前述有提过，对於纯 YAML 来说，Fleet 提供一个名为 overlay 的资料夹来客制化，因此先於专案中的 app 底下创建一个 basic_overlay 的资料夹。

由於 deployment A 这个资源三个丛集都需要，所以可以放到最外层，让所有丛集共享，只需要针对(2)/(3)/(4) 进行客制化即可。

客制化的作法很简单，於 overlays 底下创建不同的资料夹，然後於资料夹中放置想要客制化的档案即可。
这时候的架构应该会长得很类似下图

╰─$ tree .
.
├── fleet.yaml
├── frontend-deployment.yaml
└── overlays
    ├── dev
    │   └── frontend-service.yaml
    ├── it
    │   ├── frontend-service.yaml
    │   └── redis-master-deployment.yaml
    └── qa
        ├── frontend-service.yaml
        ├── redis-master-deployment.yaml
        └── redis-master-service.yaml

这边先忽略 fleet.yaml 的内容，仔细看剩下的内容。
frontend-deployment 就是 deployment A 的服务，而 overlays 底下的资料夹对应了三个不同的丛集，每个丛集内都放置更多的资源。
譬如 dev 底下多了 frontend-service，就是所谓的 Service A
it 相较於 dev 又新增了 redis-master-deployment.yaml, 也就是 Deployment B
qa 相较於 it 又新增了 redis-master-service.yaml, 也就是 service B

这些档案都准备完毕後，接下来要做的就是准备一个 fleet.yaml 的档案，让 Fleet 要针对不同丛集读取不同环境。

前述提到 Fleet.yaml 中会透过 label 的方式来选择目标丛集，没有特别设定的情况下，每个丛集会有一些预设的 label 可以使用。切换到该丛集并且以 YAML 方式浏览就可以观察到这些预设 label.

上图中呈现了三种 label，其中第一种是比较适合人类阅读的，该 label 呈现了丛集的名称，key 为 management.cattle.io/cluster-display-name
所以接下来 fleet.yaml 中就可以透过这个 label 来比对不同的 cluster。

namespace: basicoverlay
targetCustomizations:
- name: dev
  clusterSelector:
    matchLabels:
      management.cattle.io/cluster-display-name: ithome-dev
  yaml:
    overlays:
    - dev

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

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

上述是一个 Fleet.yaml 的范例，该 Fleet.yaml 希望将所有资源都安装到 basicoverlay 这个 namespace 中。

接者於 targetCustomizations 的物件中，针对三个不同环境撰写不同的 clusterSelector。
范例中使用 cluster-name 来比对，符合 ithome-dev 使用 overlays 这个语法来读取特定的环境，将 overlays/dev 中的资料夹一并纳入部署。
剩下两个环境如法炮制，一切都准备完毕之後，最後修改 repo/prod/app-basic.yaml 以及 repo/testing/app/app-basic.yaml 让其知道要扫描 app/basic_overlay 这个路径。

╰─$ cat repos/prod/app-basic.yaml
kind: GitRepo
apiVersion: fleet.cattle.io/v1alpha1
metadata:
  name: prod-app
  namespace: prod
spec:
  repo: https://github.com/hwchiu/fleet_demo.git
  branch: master
  paths:
    - app/basic
    - app/basic_overlay
  targets:
    - clusterSelector: {}
╰─$ cat repos/prod/app-basic.yaml
kind: GitRepo
apiVersion: fleet.cattle.io/v1alpha1
metadata:
  name: prod-app
  namespace: prod
spec:
  repo: https://github.com/hwchiu/fleet_demo.git
  branch: master
  paths:
    - app/basic
    - app/basic_overlay
  targets:
    - clusterSelector: {}

一切准备完毕後就将修改给推到远方的 Git 专案，然後静静等者 Fleet 开始处理。
当 Testing workspace 底下的 GitRepo 呈现 Active 後就代表环境已经部署完毕了。

这时候点选进去可以看到更为详细的内容，因为 Fleet 还是一个非常崭新的专案，我认为其还有很多值得改近的地方，譬如当前的 UI 就会将 Fleet.yaml 中描述的所有资源都一起放进来，而不是针对丛集客制化的资源去显示，这一点会容易混淆人。希望下一个版本 (v0.3.6) 有机会修复。

一切完毕後透过 kubectl 去观察三个丛集下 basicoverlay 内的资源变化

dev 的丛集可以看到只有 deployment A 配上 service A 的资源

it 丛集除了 dev 丛集的资源外，还多了 deployment B 也就是 redis-master 的 Pod.

qa 丛集则最完整，拥有 Deployment(A,B) 以及 Service (A,B)

下篇文章将针对 Kustomize 的范例介绍