Day 27 - Rancher Fleet Kustomize 应用程序部署

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

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

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

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

前言

前篇文章探讨了基於纯 Kubernetes YAML 的客制化行为，因为纯 Kubernetes YAML 没有办法针对档案内的 YAML 客制化，只能使用不同的档案来部署，如果想要针对档案内容进行客制化，这时候就要使用 Kustomize 或是 Helm 等技术来处理，本篇文章就来看看如何透过 Kustomize 来客制化应用程序。

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

Kustomize

这边简单说明一下 Kustomize 的概念， Kustomize 是基於 Patch 的概念去客制化 YAML 内容。
Patch 意味者环境中必须要先拥有一个基本档案，接者还要有一个描述差异的档案， Patch 就是将这个差异处给盖到这个基本档案上。这样就可以达到一个客制化。

举例来说有一个 Deployment 如下，该档案就是所谓的基本档案(Base)。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: redis-slave
spec:
  selector:
    matchLabels:
      app: redis
      role: slave
      tier: backend
  replicas: 2
  template:
    metadata:
      labels:
        app: redis
        role: slave
        tier: backend
    spec:
      containers:
      - name: slave
        image: gcr.io/google_samples/gb-redisslave:v1
        resources:
          requests:
            cpu: 100m
            memory: 100Mi
        ports:
        - containerPort: 6379

接者要准备一个描述差异处的档案(patch)

kind: Deployment
apiVersion: apps/v1
metadata:
  name: redis-slave
spec:
  replicas: 0

该差异处希望将 redis-slave 的 replicas 从 2 修改成 0。
Kustomize 基於这种概念去描述所有档案，环境要先准备一个名为 kustomization.yaml 的档案，该档案会告诉 kustomize 要去哪边寻找 base 档案，要去哪边寻找 patch 档案，最後将这两者结合产生出最终档案，譬如

resources:
- ../../base
patches:
- redis-slave-deployment.yaml
- redis-slave-service.yaml

上述范例是告知 Kustomize 请到 ../../base 去找寻所有的基本 YAML 档案(base)，接者使用当前资料夹底下的两个档案作为 patch，该 patch 就会尝试跟 base 中相对应的内容进行合并最後产生出差异化。

有了基本概念之後，接下来就准备来使用 Kustomize 客制化应用程序，这次继续使用类似上次的应用程序。
假设环境中依然有四个资源，分别是

Deployment A
Service A
Deployment B
Service B

这次三个丛集都会部署这四个资源，不过会透过 Kustomize 来客制化调整内容，这些参数於 base 环境中的预设值如下

Deployment A: Replica: 1
Service A: Type: ClusterIP
Deployment B: Replica: 1
Service B: Type: ClusterIP

dev 丛集

Deployment A -> Replica: 2
Deployment B -> Replica: 2

it 丛集

Deployment A -> Replica: 3
Deployment B -> Replica: 3
Service B -> NodePort

qa 丛集

Deployment A -> Replica: 1
Deployment B -> Replica: 3
Service A -> NodePort

有了基本概念後，就准备来修改 fleet_demo 的专案内容，先於 app 底下创建一个资料夹为 kustomize，并且先准备好基本资料夹。

╰─$ tree .
.
├── base
└── overlays
    ├── dev
    ├── it
    └── qa

首先来处理 base 资料夹，该资料夹中总共要放五个档案，分别是四个 Kubernetes 资源以及一个 kustomization.yaml，该 kustomization.yaml 主要是让 kustomzie 知道有哪些档案要载入去部署。

╰─$ tree .
.
├── frontend-deployment.yaml
├── frontend-service.yaml
├── kustomization.yaml
├── redis-master-deployment.yaml
└── redis-master-service.yaml

上述内容如下

╰─$ cat frontend-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: frontend
spec:
  selector:
    matchLabels:
      app: guestbook
      tier: frontend
  replicas: 1
  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
╰─$ cat frontend-service.yaml
apiVersion: v1
kind: Service
metadata:
  name: frontend
  labels:
    app: guestbook
    tier: frontend
spec:
  type: ClusterIP
  ports:
  - port: 80
  selector:
    app: guestbook
    tier: frontend
╰─$ cat redis-master-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: redis-master
spec:
  selector:
    matchLabels:
      app: redis
      role: master
      tier: backend
  replicas: 1
  template:
    metadata:
      labels:
        app: redis
        role: master
        tier: backend
    spec:
      containers:
      - name: master
        image: redis
        resources:
          requests:
            cpu: 100m
            memory: 100Mi
        ports:
        - containerPort: 6379
╰─$ cat redis-master-service.yaml
apiVersion: v1
kind: Service
metadata:
  name: redis-master
  labels:
    app: redis
    role: master
    tier: backend
spec:
  type: ClusterIP
  ports:
  - port: 6379
    targetPort: 6379
  selector:
    app: redis
╰─$ cat kustomization.yaml
resources:
- frontend-deployment.yaml
- frontend-service.yaml
- redis-master-deployment.yaml
- redis-master-service.yaml

准备好五个档案後，接下来就是针对不同客制化环境去准备相关的 Patch

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

准备好的架构如下，这边只列出 it 环境底下的客制化内容，其余两个的修改都非常类似。

╰─$ cat kustomization.yaml
resources:
- ../../base
patches:
- frontend-deployment.yaml
- redis-master-deployment.yaml
- frontend-service.yaml

╰─$ cat frontend-deployment.yaml
kind: Deployment
apiVersion: apps/v1
metadata:
  name: frontend
spec:
  replicas: 3

╰─$ cat frontend-service.yaml
kind: Service
apiVersion: v1
metadata:
  name: frontend
spec:
  type: NodePort

╰─$ cat redis-master-deployment.yaml
kind: Deployment
apiVersion: apps/v1
metadata:
  name: redis-master
spec:
  replicas: 3

该环境中准备了三个不同的 Patch 档案，并且於 kustomization.yaml 中去描述 base 的来源(../../base)，同时针对当前的环境去使用三个不同的 patch 档案。

一切准备完毕後接下来就是 fleet.yaml 的环境。

╰─$ cat fleet.yaml
namespace: appkustomize
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 的内容跟前述差不多，唯一的差别之前是透过 yaml.overlay 的方式去处理纯 Kubernetes YAML，而 Kustomize 则是改成使用 kustomize.dir 来描述目标丛集要以哪个资料夹当作 Kustomize 的起始资料夹。

一切都准备完毕後就将修改的内容推到远方的 Git，接者就继续等 Fleet 去处理。
题外话： Fleet 有时候处理上还不够完善，有可能 UI 跟底层部署没有同步，底层资源都完毕但是 UI 会显示 Not-Ready，这种情况下可以尝试将该 Bundle 给删除，让 GitRepo 重新产生一个全新的 Bundle 即可。

部署完毕後透过 kubectl 去观察三个丛集，是否都如同预期般的部署。

Dev 丛集希望两种 Deployment 的 Replica 都是 2，且 service 维持预设的 type: ClusterIP.