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

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

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

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

前言

前篇文章用很简易的方式去探讨如何使用 Fleet 的 GitOps 概念来管理资源，最後面用一个非常简易的 Deployment 物件来展示如何让 Fleet 将该资源部署到三个丛集中。

实务上使用的情境会更加复杂，譬如说

1. 应用程序来源不同，有的是纯 YAML 档案，有的是透过 Helm 包装，有的是透过 Kustomize 去包装
2. 希望针对不同丛集有不同客制化，以 Helm 来说可能不同的丛集要给不同的 values.yaml

因此接下来的文章就会针对上述两个概念来探讨，到底於 Fleet 中要如何满足上述要求。

GitRepo 扫描方式

Fleet 中要先准备 GitRepo 的物件，该物件中会描述

1. Git URL
2. 档案的路径来源

准备好该 GitRepo 物件後， Fleet 就会去扫描该 Git 专案并且扫描底下的路径，接者从里面找出可以使用的 Kubernetes 资源档案。

实际上 Fleet 的运作逻辑更加复杂，因为 Fleet 支援下列几种变化

1. 原生 YAML 档案
2. Helm Chart
3. Kustomize

这三种变化大抵上可以分成五种不同的档案来源，分别是

1. Chart.yaml
2. kustomization.yaml
3. fleet.yaml
4. *.yaml
5. overlays/{name}

Helm Chart 本身又分成两种部署方式，分别是

1. 使用远方的 Helm Server
2. 将 Helm Chart 直接放到 Git 专案中，所以专案内会有 charts.yaml, templates 等档案。

将上述的概念整合请来大抵上就是

1. 当路径上有 Chart.yaml 档案时，Fleet 就会认为要使用 Helm Chart 的概念去部署
2. 当路径上有 kustomization.yaml 档案时， Fleet 就会认为要使用 Kustomize 的方式来部署应用程序
3. 当路径上有 fleet.yaml 档案时， Fleet 会依照该档案中的作法去部署，实务上都会使用 fleet.yaml 去描述部署的策略
4. 当路径上没有 Chart.yaml 与 kustomization.yaml 时，Fleet 就会使用最直觉的 Kubernetes 资源去部署
5. overlays/{name} 这是针对(4)情况使用的客制化部署，是专门针对纯 Kubernetes 资源的客制化。

前篇文章只有准备一个 deployment.yaml，所以就会踩到 (4) 这种部署方式。实务上最常使用的就是 fleet.yaml，fleet.yaml 可以直觉去呈现每个应用程序针对不同丛集的客制化设定，同时还可以做到混合的效果，譬如单纯使用 Helm Chart, 单独使用 Kustomize，或是先 Helm Chart 再 Kustomize 的混合部署。

所以可以知道 Fleet.yaml 可以是整个 Fleet 部署的重要精灵与灵魂，所有的应用程序都需要准备一个 fleet.yaml

Fleet.yaml

Fleet.yaml 是一个用来控制 Fleet 如何去处理当前资料夹下的 YAML 档案，该用什麽方式处理以及不同的丛集应该要如何客制化。
每一个 fleet.yaml 都会被产生一个对应的 Fleet Bundle 物件，所以通常会将 fleet.yaml 放到每个应用程序的最上层路径。

Fleet.Yaml 的详细内容如下，接下来根据每个栏位介绍一下

defaultNamespace: default

namespace: default

kustomize:
  dir: ./kustomize

helm:
  chart: ./chart
  repo: https://charts.rancher.io
  releaseName: my-release
  constraint
  version: 0.1.0
  during
  values:
    any-custom: value
  valuesFiles:
    - values1.yaml
    - values2.yaml
  force: false

paused: false

rolloutStrategy:
    maxUnavailable: 15%
    maxUnavailablePartitions: 20%
    autoPartitionSize: 10%
    partitions:
    - name: canary
      maxUnavailable: 10%
      clusterSelector:
        matchLabels:
          env: prod
      clusterGroup: agroup
      clusterGroupSelector: agroup

targetCustomizations:
- name: prod
  namespace: newvalue
  kustomize: {}
  helm: {}
  yaml:
    overlays:
    - custom2
    - custom3
  specified,
  clusterSelector:
    matchLabels:
      env: prod
  clusterGroupSelector:
    matchLabels:
      region: us-east
  clusterGroup: group1

defaultNamespace/namespace
defaultNamespace 代表的是如果 Kubernetes YAML 资源没有标示 namespace 的话，会自动的被部署到这个 defaultNamespace 所指向的位置。

namespace 则是强迫将所有资源给安装到某个 namespace 中，要特别注意的是如果目标 namespace 中已经有重复的资源的话，安装可能会失败，这点跟正常的 kubernetes 资源一样。

kustomize:
熟悉 kustomize 的朋友一定都知道 kustomize 习惯上都会透过一个又一个资料夹搭配 kustomization.yaml 来客制化资源，对於 Fleet 来说给予一个相对的资料夹位置， Fleet 就会尝试寻找该资料夹底下的 kustomization.yaml 并且客制化。

helm:
Helm Chart 本身有两种使用方式，一种是读取远方 Helm Server 上面的物件，一种是本地的 Helm 物件，因此 helm 格式内就有 chart/repo 等不同栏位要交互使用。
之後的文章都会有这些的使用范例，所以这边就不详细列出使用方式。

如果采用的是 helm server 的话，还可以指名想要安装的版本，同时可以透过两种不同的方式来客制化，一种是直接使用 values:.... 的格式来撰写，这种方式适合少量客制化的需求，当客制化的数量过多时就推荐使用第二种 valuesFiles 的方式来载入客制化内容。

pause:
Pause 的用途是让 Fleet 单纯做版本扫描确认有新版本，但是不会帮忙更新 Kubernetes 内的资源，管理人员需要自己手动从 UI 去点选 force update 来更新。
预设情况下都是 false，就代表 Fleet 不但会确认新旧差异也会帮忙更新资源。

rolloutStrategy:
Fleet 的用途是管理大量丛集的部署，因此其提供的 rolloutStrategy 的选项来客制化丛集间的更新策略，基本上跟 Kubernetes Deployment 的更新策略非常雷同，同时间可以有多少个 Cluster 可以处於更新的状态，

这个栏位中主要分成两大类

1. 如何将 Group 分类，称为 Partition
2. 如何针对所有的 Group/Partition 去设定更新的比率

targetCustomizations:
这个栏位是整个 Fleet.yaml 最重要的部分
前述的 Helm/Kustomization 代表的是如何渲染当前路径底下的 Kubernetes YAML 档案。
而 targetCustomizations 则是要如何针对不同的 Kubernetes 丛集进行二次客制化

重要的是下方三个选项，如何选择一个 Cluster，有三种不同方式

1. clusterSelector
2. clusterGroupSelector
3. clusterGroup

其中(2)/(3)两个都是针对 Cluster Group 直接处理，所以如果有相同类似的 Cluster 就可以直接群组起来进行处理，不然就要使用第一种方式透过 selector 的方式去处理。
clusterSelector 的方式跟 Kubernetes 内大部分的资源处理一样，都是透过 Label 的方式去处理。
Label 可以於 UI 方面透过点选的方式去加入这些 label，当然也可以透过 Terraform 去创建 RKE Cluster 的时候一起给予 Label。

从网页要给予 Label 的话，就点选到 Cluster 页面，找到目标的 Cluster ，点选 Edit Config/Edit YAML 都可以。

接者於画面中去填写想要使用的 Label，这些 Label 就可以於 fleet.yaml 去客制化选择。

如果想要尝试 Cluster Group 的话也可以尝试将不同的 Cluster 给群组起来，之後的范例都可以尝试看看。

简单范例

以下范例节录自官网范例

namespace: fleet-mc-helm-external-example
helm:
  chart: https://github.com/rancher/fleet-examples/releases/download/example/guestbook-0.0.0.tgz
targetCustomizations:
- name: dev
  helm:
    values:
      replication: false
  clusterSelector:
    matchLabels:
      env: dev

- name: test
  helm:
    values:
      replicas: 3
  clusterSelector:
    matchLabels:
      env: test

- name: prod
  helm:
    values:
      serviceType: LoadBalancer
      replicas: 3
  clusterSelector:
    matchLabels:
      env: prod

上述的 fleet.yaml 非常直觉

1. 使用 远方的 Helm Chart 档案作为目标来源
2. 使用 env 作为 label 来挑选三个不同的 cluster
3. 每个 cluster 使用时都会设定不同的 value 内容。

下篇文章就会尝试使用这些概念来实际部署应用程序