[Rancher 系列文] - Fleet 的介紹與使用

Posted on 2021-12-24

Rancher 系列文第八篇，探討Rancher Fleet 的概念

官方網站有列出非常詳細的安裝步驟，針對 Fleet Manager 安裝要用到的憑證與除錯方式，如何使用 Helm 安裝 CRD 與 Fleet Controller 都有介紹。
當 Fleet Manager 安裝與設定完畢後，接下來就可以參考 Cluster Registration Overview 這篇官方文章來學習如何將一個 Kubernetes 叢集作為 Fleet Agent 加入到 Fleet Manager 的管理中。

不過這邊要特別注意的是，以上所提的安裝方式都是針對純 Fleet 解決方案時才需要考慮的部分，因為 Fleet 是 Rancher 開發與維護的，因此任何由 Rancher 管理與創建的 Kubernetes 叢集都已經內建 Fleet Agent，大幅度簡化使用者的安裝方式。

當初安裝 Rancher 時會先準備一個 Kubernetes 叢集專門用來負責 Rancher 本身的維運，其他所有的叢集都會透過這個 Rancher 去創建與維護，Rancher Fleet 會採用相同的架構與方式去處理。專門用來部署 Rancher 的 Kubernetes 叢集會被安裝 Fleet Controller。

基於以上兩點，只要所有叢集都是由 Rancher 去創建與管理的， Fleet 就不需要自己手動安裝，Fleet Manager 與 Fleet Agent 都會自動的被安裝與部署到相關叢集中。

前述所述，用來安裝 Rancher 服務的 Kubernetes 叢集本身也會安裝 Fleet Controller，這部分可以到 Apps 的頁面去看到底有哪些應用程式被安裝到叢集中。同時透過畫面中提供的 kubectl 指令去觀察 fleet-system namespace 中安裝的 Pod，如下圖。

可以觀察到 local 也就是部署 Rancher 的 Kubernetes 叢集有部署三個 Pod，其中 fleet-controller 以及 gitjob 兩個 pod 是針對 fleet manager 而部署的 Pod，而 fleet-agent 則是給 fleet-agent 使用的。

此架構意味者管理者可以透過該 Fleet 來管理 local 這套 Kubernetes 叢集。
之前提到 Fleet 與大部分的 Operator 有相同的開發流程，所以會使用一個 Kubernetes Controller 配上很多預先設定的 CRD 物件，所以透過 kubectl get crd 就可以看到 local 叢集上有各式各樣關於 Fleet 的 CRD。

接下來觀察要被管理的 Kubernetes 叢集，譬如給 Dev 使用的叢集，這時候使用相同的方式去觀察該叢集內安裝的資源，可以觀察到 fleet-system 內只有安裝一個 Pod，該 Pod 就是扮演 Fleet Agent 的角色，讓該叢集能夠順利的 Fleet Manager 溝通，範例如下。

確認完畢之後就可以移動到 Rancher Fleet 的專屬頁面，移動的方式很簡單，不論當前是處於哪個叢集，點選左上方就可以找到一個名為 Continuous Delivery 的選項，點進去就會進入到 Rancher Fleet 的畫面。

進去畫面中後會看到如下的畫面，畫面中有非常多的新東西，接下來針對這些新東西慢慢探索

首先畫面最上方有一個下拉式選單可以選擇，該選單會列出所有可以使用的 Fleet Workspace，那到底什麼是 workspace 呢?

Fleet workspace 是一個管理單位，就如同大部分專案的 workspace 概念一樣，每個 workspace 都會有自己獨立的 GitRepo, Group, Bundle 等概念。
一個實務上的上作法會創立多種不同的 workspace，譬如 dev, qa 及 prod。

每個 workspace 內都可包含多個不同的 cluster 與其他的資源。

預設的情況下有兩個 workspace，分別是 fleet-local 以及 fleet-default. 所有剛加入到 Rancher 的叢集都會被加入到 fleet-default 這個 workspace 中。

畫面左邊有六個不同的資源

Git Repos:
Git Repos 內的資源是告訴 Fleet 希望追蹤哪些 Git 專案，該 Git 專案中哪些資料夾的哪些檔案要讓 Fleet 幫忙管理與安裝。

因為 Fleet 什麼都還沒有安裝與設定，所以 Git Repo 內目前是空空的，沒有任何要被安裝的應用程式。

Clusters/Cluster Groups:
這邊顯示的是該 workspace 中有多少個 cluster，目前的環境中先前創立三個不同的 Kubernetes 叢集，而這些叢集預設都會被放入到 fleet-default workspace 內的 group。

假設 cluster 數量過多，還可以透過 Cluster Group 的概念來簡化操作，將相容用途的 cluster 用群組的方式來簡化之後的操作。

Workspace:
Workspace 可以看到目前系統有多少個 workspace，可以看到系統中有 fleet-default 以及 fleet-local，同時也會顯示這些 workspace 中目前管理多少個 cluster 。

Bundles:
之前提過 Bundle 是 Fleet controller 掃過 GitRepo 專案後會產生的安裝資源檔案。
可以當前的範例非常奇妙，沒有任何 Git Repo 的內容卻擁有這些 Bundle 檔案，主要是因為這三個 Bundle 是非常奇妙與特殊的 Bundle，仔細看的話可以觀察到這些 Bundle 的名稱都是 Fleet-agent-c-xxxx，這些 bundle 是用來安裝 fleet-agent 到目前 Rancher 下的所有 Kubernetes 叢集。
這些安裝是 Rancher 內建強迫的，所以使用上會稍微跟正常用法有點不同。

ClusterRegistrationTokens:
最後一個則是 Cluster(Fleet Agent) 要加入到 Fleet Manager 使用的 Token，不過因為目前的叢集全部都是由 Rancher 去管理與創造的，所以不需要參考官網自行安裝，因此 Rancher 會走比較特別的方式來將 Rancher 管理的叢集給加入到 Fleet manager 中，因此這邊就是空的。

此外透過 Cluster 內的操作，可以將該 workspace 下的 cluster 給移轉到其他的 workspace，所以之後根據需求創立不同的 workspace 後，就可以透過這個方式將 cluster 給移轉到屬於該用途的 workspace。

GitOps Example

為了使用 GitOps 來部署，必須要先準備一個 Git 的專案來放置要部署的資源，

本篇文章使用的範例都會放到我準備的一個公開 Git Repo Fleet Demo

Workspace

前述提到大部分 Rancher Fleet 的資源都是基於 Kubernetes CRD 去描述的，因此除了透過網頁操作外也是可以準備一個相關的 YAML 檔案，只要將該 YAML 給部署到 Kubernetes 內， Fleet Controller 就會根據該資源進行對應的操作與更新。

一開始先從簡單的部分開始練習，嘗試透過 GitOps 幫忙創建與管理 Workspace，預設的情況下叢集會有 fleet-default 與 fleet-local 這兩個 workspace，所以目標是想要創造兩個不同的 workspace，分別是 prod 以及 testing.

Workspace 的 YAML 非常簡單，一個範例如下

apiVersion: management.cattle.io/v3
kind: FleetWorkspace
metadata:
  name: prod
  namespace: prod

創建一個 FleetWorkspace 的物件，並且針對 name/ns 給予相對應的資料即可，因此針對兩個 workspace 準備兩個檔案，並且將這兩個檔案放到 git 專案下的 workspace 資料夾底下。示意圖如下。

╰─$ tree .
.
└── workspace
    ├── production.yaml
    └── testing.yaml

將上述內容給推向遠方 Git 專案中後，下一步就是要讓 Fleet 知道請追蹤這個 Git Repo 並且將相關的內容給部署到 Kubernetes 內。
切換到 Fleet 的介面，選擇到 Fleet-Local 這個 workspace 並且於 GitRepo 的頁面中點選創立，這時候可以看到如下的介面

該介面中我們需要設定幾個資訊

GitRepo 物件的名稱
Git 專案的 URL
Git 專案的 Branch
Git 專案是否需要透過權限去純取。
要從 Git 專案中的哪個位置去尋找相關 YAML 檔案。

因為示範專案是公開的，所以(4)可以直接忽略。
第五點要特別設定成 workspace/，因為前述我們將兩個 workspace 的 YAML 放到 workspace 資料夾底下。

創立完畢後就會看到系統上創建了一個名為 workspace 的 Git 物件，該物件的狀態會從 GitUpdating 最後變成 Active。

由於 fleet-local 這個 workspace 中只有一個 cluster，也就是 local，因此剛剛創立的 GitRepo 只會將相關資源給安裝到這個 local cluster 中，所以可以看到圖中顯示的 Clusters Ready 標示為 1。

點選 workspace 這個資源進去可以看到更多關於該 GitRepo 的資訊，譬如相關的資源有哪些。
範例中可以看到底下提供了兩個屬於 FleetWorkspace 的物件，分別為 prod 以及 testing，這兩個物件都安裝到對應的 namespace 中。

之前也有提過針對每個 GitRepo 所掃描出來的物件都會創造出一個最基本的 Bundle 物件，該物件會描述這個應用程式的所有內容。所以切換到 Bundle 介面去尋找 workspace，可以看到如下的範例。

該 bundle 會把所有要安裝的資源都集中起來，同時因為這次的範例非常簡單，沒有要針對任何 Cluster 去客製化與過濾，所以 targets/targetRestrictions 都是空白的。
此時點選 workspace 的介面或是上方的選單，會發現先前描述的 testing 與 prod 這兩個 workspace 已經被自動創立了，這意味者 Fleet 已經自動地從 Git 專案中學習到要部署什麼資源，並且把資源給成功的部署到 Kubernetes 內，最後的結果也如預期一樣。

用 Fleet 管 GitRepo

下一個範例就是希望透過 Fleet 管理 GitRepo 物件，畢竟能夠盡可能減少 UI 操作是追求自動化過程中不可避免的一環。

首先到 GitRepo 中將該 Workspace 的物件移除，移除後可以觀察到 Bundle 中關於 prod/testing 的物件都不見，同時 workspace 中只剩下 fleet-local 以及 fleet-default.

為了讓 Fleet 幫忙管理，我們需要準備一個描述 GitRepo 的 YAML 檔案，將該檔案放到專案中的 repos/local 底下。

kind: GitRepo
apiVersion: fleet.cattle.io/v1alpha1
metadata:
  name: fleet-demo
  namespace: fleet-local
spec:
  repo: https://github.com/hwchiu/fleet_demo.git
  branch: master
  paths:
    - workspace/
  targets:
    - clusterSelector: {}

該 Yaml 描述的內容跟前述透過 UI 創建 GitRepo 是一致的，當系統中有愈來愈多應用程式要管理的時候，就修改該物件，讓 Paths 指令更多路徑即可。

準備好該物件後，接下來還是要到 Fleet UI 去創建一個 GitRepo 物件，該 GitRepo 物件是用來幫忙管理所有 GitRepo 物件的，因此必須要先手動創建一次，接下來就可以依賴 GitOps 的流程幫忙管理。

這邊先創造一個新的 GitRepo 物件，該物件指向 repos/local。

所以整個流程就會變成

Fleet 去讀取 Git 專案底下 repos/local 內的物件
repos/local 內的物件被套用到 Kubernetes 後就會產生另外一個名為 fleet-demo 的 GitRepo 物件
fleet-demo 物件會再次的去把專案內的 workspace/ 給抓進來進行後續安裝。

一切準備完畢後，會觀察到 GitRepo 列表呈現的如下圖，會有兩個 GitRepo

這時候如果點進去 fleet-demo 這個 GitRepo，可以看到該 GitRepo 會部署兩個 workspace，同時最上方還有一個額外的 label，該 label 是由 helm 產生的。
前述提過 Fleet 會將所有資源都動態的轉換為 Helm 格式。

轉移 Cluster

創立好兩個不同的 workspace 後，可以嘗試將三個預先創立的 k8s cluster 給搬移過去，舉例來說將
rke-qa 以及 ithome-dev 這兩套叢集搬移到 testing workspace，而 rke-it 則搬移到 prod workspace。

下一步就是真正實務上的需求，部署應用程式。為了讓 Fleet 安裝應用程式，所以也需要幫忙準備一個 GitRepo 的物件。針對 testing 以及 prod 各準備一個，並且依序放到 repos/testing, repos/prod 底下。

╰─$ cat 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
  targets:
    - clusterSelector: {}
╰─$ cat testing/app-basic.yaml
kind: GitRepo
apiVersion: fleet.cattle.io/v1alpha1
metadata:
  name: testing-app
  namespace: testing
spec:
  repo: https://github.com/hwchiu/fleet_demo.git
  branch: master
  paths:
    - app/basic
  targets:
    - clusterSelector: {}

目前系統上還沒有 app/basic 資料夾，可以先不用管它。

上述兩個 GitRepo 的差異處有兩個

安裝的 namespace 不同，注意這邊的 namespace 要跟 workspace 的名稱一致。

接者我們要讓最原始的 repos 一起幫忙處理這兩個 GitRepo，將 repos/local 底下的檔案修改為

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

這時候整個專案呈現如下

╰─$ tree -l
.
├── repos
│   ├── local
│   │   └── repos.yaml
│   ├── prod
│   │   └── app-basic.yaml
│   └── testing
│       └── app-basic.yaml
└── workspace
    ├── production.yaml
    └── testing.yaml

當這些修改都推到遠方 Git 專案後就會觀察到 fleet-local 下的兩個 GitRepo 物件都變成 NotReady 的狀態，如下

以 Fleet 的角度來解釋就是

fleet-demo 這個 GitRepo 本身會希望安裝三個路徑底下的物件，分別是 workspace/ repos/testing, repos/prod, 只要其中有一個沒有順利部署完成，身為老爸的 fleet-demo 也就自然不能說自己完成
fleet-demo 這個物件是由 repos 這個 GitRepo 去動態產生的，因此 fleet-demo 本身沒有順利完成的話，repos 物件也沒有辦法說自己順利完成。

接者點進去 fleet-demo 看一下到底是什麼物件沒有順利完成，可以看到剛剛創立的 prod-app 以及 testing-app 這兩個物件也都沒有完成，所以跟 workspace 無關。

這時候切換到 testing 的 workspace，可以觀察到系統上的 testing-app GitRepo 是呈現紅色的字眼，叫做 Git Updating。
同時最上方有顯示相關錯誤訊息，告知使用者為什麼該專案目前不能正常運作。
其訊息告知 Fleet 沒有辦法從專案底下的 app/basic 路徑找到可以用的 Kubernetes 物件，因此沒有辦法順利安裝資源，所以標示為錯誤。

為了解決這個問題，我從官方範例中複製了一個簡單的 Deployment 物件，將該物件給放到 apps/basic 底下。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: frontend
spec:
  selector:
    matchLabels:
      app: guestbook
      tier: frontend
  replicas: 3
  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

將這個物件推向遠方的 Git 專案後就可以觀察到 testing-app 成功順利的安裝物件到叢集中，由於 testing 的 workspace 底下有兩個不同的 cluster， ithome-dev 以及 rke-qa。
所以這個物件就會自動的安裝到這兩個叢集中。

這時候如果去 cluster explorer 的介面可以看到 deployment 中有一個名為 frontend 的 deployment 物件被創建出來。

本篇文章到這邊為止，我們嘗試透過 Fleet GitOps 的方式來管理 Fleet 本身並且部署了第一個應用程式，下一篇文章將來探討如何針對不同的 Cluster 給予不同的客製化，譬如 ithome-dev 跟 rke-qa 可以使用不同的參數或是檔案來部署。

我目前於 Hiskio 平台上面有開設 Kubernetes 相關課程，歡迎有興趣的人參考並分享，裡面有我從底層到實戰中對於 Kubernetes 的各種想法
詳細可以參閱
線上課程詳細資訊: https://course.hwchiu.com/

另外，歡迎按讚加入我個人的粉絲專頁，裡面會定期分享各式各樣的文章，有的是翻譯文章，也有部分是原創文章，主要會聚焦於 CNCF 領域
https://www.facebook.com/technologynoteniu

如果有使用 Telegram 的也可以訂閱下列頻道來，裡面我會定期推播通知各類文章
https://t.me/technologynote

你的捐款將給予我文章成長的動力

Buy me a coffee

[Rancher 系列文] - Fleet 的介紹與使用

[Rancher 系列文] - Fleet 的介紹與使用

GitOps Example

Workspace

用 Fleet 管 GitRepo

轉移 Cluster

Recommend

月入4万的【捏脸师】，元宇宙的第一批打工人

Pensieve: 2112

Data-Oriented Programming

Machine Learning Interview Questions & Answers

[Cloud Design Pattern] - Ambassador 模式

警惕年终奖“陷阱”！多拿1元钱需要多缴几千税

Web Scraping 🔍🔥

新冠研究急缺蝙蝠！科学家培育蝙蝠类器官解释蝙蝠与病毒共存却不生病

End of the Year Stats | Voice of the DBA

GUI Calender Using Tkinter in Python - Videos | GeeksforGeeks

About Joyk