0%

[Rancher 系列文] - 創建 k8s 叢集

前篇文章探討了 Rancher 其中一種安裝 Kubernetes(RKE) 的方式,該方式會先透過 API 請求 Service Provider(Azure) 幫忙創建相關的 VM,接者於這些 VM 上面搭建一個符合需求的 RKE 叢集。

為了讓簡化整個設定過程,我們學到了如何透過 Cloud Credential 以及 Node Template 兩種方式來事先解決繁瑣的操作,接者真正創建 RKE 叢集時則使用 Node Template 與 RKE Template 兩個方式讓整個創建過程變得很簡單,不需要填入太多資訊,只需要利用這兩個 Template 的內容加上自行設計要多少個 VM 節點,這些節點要屬於什麼身份以及該叢集最後要給哪個使用者/群組使用即可。

本篇文章將繼續把剩下兩種安裝方式給走一遍,三種安裝方式都玩過後會對 Rancher 的能力有更多的瞭解,同時也會為之後 Rancher Fleet 的使用先行搭建環境。

之前探討使用者管理與部署時於系統中創建了三種不同群組的使用者,包含了 DEV, QA 以及 IT。而這兩個章節探討的三種部署方式其實剛好就會剛好拿來搭配這些不同的使用者,期望透過不同方式搭造出來的三套 RKE 叢集本身權限控管上就有不同的設定。

目標狀況是三套叢集擁有的權限如下

  1. DEV 叢集 -> IT & DEV 可以使用
  2. QA 叢集 -> IT & QA 可以使用
  3. IT 叢集 -> IT 可以使用

基本上因為 IT 群組的使用者會被視為系統管理員,因此本身就有能力可以存取其他叢集,所以創建時只需要針對 DEV 以及 QA 兩個叢集去設計。
實務上到底會如何設計取決於團隊人數與分工狀況,這邊的設計單純只是一個權限控管的示範,並不代表真實應用就需要這樣做。

Existing Cluster

前篇文章探討的是動態創建 VM 並且於搭建 RKE 叢集,與之相反的另外一種架設方式就是於一個已經存在的節點上去搭建 RKE 叢集。

這個安裝方式大部分都會用於地端環境,部分使用者的地端環境沒有 vSphere/Openstack 等專案可以幫忙自動創建 VM,這種情況下一台又一台的 bare-metal 機器就會採用這種方式來安裝。

我先於我的 Azure 環境中創建兩個 VM,想要用這兩個 VM 搭建一個屬於 QA 群組使用者的 RKE 叢集

上圖中標示為 qa-rke{1,2} 的機器就是為了這個情況手動創建起來的。
準備好了相關 VM 之後,就切換到 Rancher 的介面去創建一個 RKE 叢集。

介面中選擇非常簡單,只有一個 Existing Nodes 可以選擇,點進去後可以看到類似下方頁面

與之前的安裝方式不同,這邊沒有所謂的 Node Pool 的概念,畢竟是要安裝到一個已存在的節點,所以沒有 Node Pool 需要設定也是合理的。
這邊我將該叢集分配給 QA 群組的使用者,令其為 Owner,擁有整個叢集的管理權限,同時下方繼續使用先前設定好的 RKE 叢集。

一切完畢後點選 Next 到下一個頁面,該頁面才是真正安裝的方式

該介面有三個地方要注意

  1. 最下方是安裝的指令,實際上是到該節點上透過 Docker 的方式去運行一個 Rancher Agent 的容器,該容器會想辦法跟安裝 RKE 並且跟遠方的 Rancher 註冊以方便被管理
  2. 最上方兩個區塊都是用來調整該節點到底要於 RKE 叢集中扮演什麼角色,這些變動都會影響下方 Docker 指令
  3. 就如同先前安裝一樣,這邊也需要選擇當前節點到底要當 ETCD/Control Plane/Worker 等
  4. Show advanced options 選項打開可以看到的是 Labels/Taints 等相關設定

我透過上述介面設定了兩種介面,分別是

  1. 單純的 worker
  2. 全包,同時兼任 worker/etcd/controlplane

接者複製這些 docker 指令到事先準備好的 VM 上去執行

到兩個機器上貼上指令後,就慢慢的等 Rancher 將整個 RKE 架設起來。

可以看到透過這種方式創建的叢集,其 Provider 會被設定成 Custom,跟之前創立的 Azure 有所需別。

點選該叢集名稱進去後,切換到節點區塊可以看到兩台機器正在建立中,這邊要特別注意,節點的 hostname 必須要不同,如果 hostname 一致的話會讓 Rancher 搞混,所以使用 bare-metal 機器建立時千萬要注意 hostname 不要衝突。

一切結束後,就可以於最外層的介面看到三個已經建立的叢集,一個是用來維護 Rancher 本身,兩個則是給不同群組的 RKE 叢集。

Managed Kubernetes Service

接者來看最後一個安裝方式,這個方式想要直接透過 Rancher 去創造 AKS 這種 Kubernetes 服務,並且安裝完畢後將 Rancher 的相關服務部署進去,這樣 Rancher 才有辦法控管這類型的叢集。

回到叢集安裝畫面,這時候針對最下面的服務,預設情況下這邊的選擇比較少,但是如果有到 Tools->Driver 去將 Cluster Driver 給打開的話,這邊就會出現更多的 Service Provider 可以選擇。

根據我的環境,我選擇了 Azure AKS,點選進去後就可以看到如下圖的設定頁面

進到畫面後的第一個選項就是 Azure 相關的認證資訊,這邊我認為是 Rancher 還沒有做得很完善的部分,先前創建 Node Template 時使用的 Cloud Credential 這邊沒有辦法二次使用,變成每次創建一個 AKS 叢集時都要重新輸入一次相關的資訊,這部分我認為還是有點不方便。
不過仔細觀察需要的資訊有些許不同,創造 Node Template 時不需要 Tenant ID,但是使用 AKS 卻需要。有可能因為這些設定不同導致 Cloud Credential 這邊就沒有辦法很輕鬆的共用。
不過作為使用者也是希望未來能夠簡化這些操作,否則每次創建都要翻找算是有點麻煩。

通過存取資訊驗證後,就可以來到設定頁面,因為這個是 AKS 叢集,因此並沒有辦法使用 RKE Template 來客製化內容,所有的設定內容都是跟 AKS 有關,因此不同的 K8S 服務提供的操作選項就不同。

一切準備就緒後,就可以看到最外層的叢集列表多出了一個全新的 Kubernetes 叢集,其 Provider 則是 Azure AKS。

此時觀看 Azure AKS 的頁面可以發現到也多了一個正在創建中的 AKS 叢集,名稱 c-xxxx 就是 Rancher 創造的證明,每個 Rancher 管理的 Kubernetes 叢集都會有一個內部ID,都是 c-xxxx 的形式。

等待一段時間待節點全部產生完畢,就可以看到一個擁有三個節點的 AKS 叢集被創建了

最後到外層叢集介面可以看到目前有四個 K8S 叢集被 Rancher 管理,其中一個是管理 Rancher 本身,剩下三個則是新創立的 K8s 叢集。同時這三個叢集都分配給不同群組的使用者使用。

如果這時候用 QA 使用者登入,就只會看到一個叢集,整個運作的確有符合當初的設計。

叢集都創立完畢後,接下來探討如何使用 Rancher 的介面來管理 Kubernetes,以及 Rancher 介面還提供了哪些好用的功能可以讓叢集管理員更加方便的去操作叢集。

叢集存取

對於大部分的 Kubernetes 工程師來說, kubectl 是個必須要會的使用工具,而 dashboard 更多時候是作為一個輔助的工具,提供更友善的視覺化方式來有效的提供資訊。
Rancher 本身提供非常友善的 Dashboard,可以讓非工程人員也可以快速地瀏覽與理解當前 Kubernetes 叢集的狀態,舉例來說隨便點進一個之前創立的 Kubernetes 叢集,會看到如下的畫面。

畫面中有幾個點可以注意

  1. Rancher 內部有兩種瀏覽介面,分別是 Cluster Manager 以及 Cluster Explorer,預設情況下都是使用 Cluster Manager 來瀏覽
  2. Rancher v2.5 之後將慢慢的轉往 Cluster Explorer 去使用,所以可以觀察到畫面上都有提示,告知使用者可以嘗試使用看看 Cluster Explorer 來管理與瀏覽 Kubernetes 叢集
  3. 畫面中間大大的顯示了三個關於 Kubernetes 資源的資訊,CPU, Memory 以及 Pod 的數量。Kubernetes 預設情況下每個節點最多只能部署110個 Pod,所以畫面中顯示的是 18/330,代表說目前已經有 18 個Pod 部署了。而 CPU/Memory 代表的則是有多少系統資源已經被預先保留,這部分是透過 Pod 裏面的 Resource.Request 來處理的
  4. 最下面還有四個健康狀態,代表整個叢集中的 Etcd, Control Plane(Controller,Scheduler) 以及節點之間的健康狀態
  5. 最下面 Events 展開則是可以看到 Kubernetes 內的相關 Event

上述的 Portal 簡單地呈現了當前 Kubernetes 叢集是否健康,特別是當叢集有任何問題時,下方的四個狀態都會變成紅色醒目的提醒使用者叢集有問題。

有了基本介面後,接下來把注意力移動到右上方兩個選項,分別是 Launch kubectl 以及 Kubeconfig File。
點選 Kubeconfig File,則會看到類似下列的畫面,該畫面中呈現的就是完整的 Kubeconfig file 內容。

這意味你可以把該檔案抓到你的電腦,直接於本地端使用 Kubectl 指令去存取目標叢集,示範中使用的是給 DEV 人員操作的叢集,所以該 Kubectl 本身對應的使用者其實也就是我當前用來登入 Rancher 系統的使用者。
如果熟悉 Kubeconfig 格式的讀者會觀察到, Rancher 本身會針對 Clusters 這個欄位填入多個組合,這些組合分兩大類,分別是

  1. 叢集中的 API Server 位置
  2. Rancher Server 本身

假如今天你有辦法直接存取到目標節點,譬如節點本身有 Public IP 且也有開啟 6443 Port,那就可以使用這個方式直接存取該 Kubernetes 叢集。
但是如果該節點今天是一個封閉的環境,沒有任何 Public IP 可以直接存取,那可以採取第二種方式,把任何 API 請求都打向 Rancher 服務,如圖中的 “https://rancher.hwchiu.com/k8s/clusters/c-z8j6q" 這個位置,然後 Rancher 就會幫忙把請求給轉發到目標叢集內,可以想像成是一個 Proxy By Pass 的概念。

補充一下: 因為目標 Kubernetes 叢集內都會安裝 Rancher 相關的服務,這些服務都會主動的跟 Rancher 進行連線,所以 Rancher 才有辦法把這些 API 請求給轉發到這些不能被外界主動存取的 Kubernetes 叢集。

以下是個範例,將上述檔案存成一個名為 ithome 的檔案,接者執行 kubectl 的時候可以透過 –kubeconfig 的參數來指定當前 kubectl 要使用哪個檔案

上述指令就呈現了當前 DEV 叢集中的相關 Pod 資訊,其中可以看到

  1. Flannel CNI 符合之前 RKE Template 的選擇
  2. RKE 叢集有滿多相關的服務
  3. cattle-system 有所謂的 cattle-node-agent,這些角色就是會負責跟 Rancher 溝通。

基本上只有擁有了 KUBECONFIG 的檔案,管理者就有辦法透過 kubectl,helm 等指令直接管理該叢集。
如果系統上剛好沒有安裝這些指令,但是又想要使用 kubectl 來操作怎麼辦?
Rancher 也想到了這一塊,所以叢集畫面右上方的 Launch Kubectl 按鈕給他點下去,
該功能會開啟一個 web-based 的終端機,裡面提供了 kubectl 的指令,同時 kubeconfig 也都設定完畢了。
所以可以直接於該環境中使用 kubectl 去操作叢集,範例如下

基本上掌握這兩個功能的用法,就等於掌握了直接操作當前 Kubernetes 叢集的能力,習慣使用 kubectl 的使用者也可以開始透過 kubectl 來管理與部署該 Rancher 上的各種應用,當然 Rancher 本身也有自己的架構能夠讓使用者去部署應用程式,好壞沒有絕對,都要進行評估與比較。

Kubectl 與 Kubecfongi File 旁邊有一個按鈕,該按鈕點下去後可以看到一些關於 Kubernetes 叢集的選項,而不同的搭建的叢集顯示的功能都不同,譬如

如果節點是透過 AKS 搭建的,可以看到選項非常少,只有編輯與刪除是常見會使用的功能,編輯頁面中可以針對叢集名稱,叢集的使用權限,甚至針對 K8S 叢集的選項進行調整。不過由於該叢集是由 AKS 維護的,所以修改的內容也都是跟 AKS 有關。

第二個看到的是透過 Docker 指令於現存節點上安裝的 RKE 叢集,這種狀況下可以選擇的操作非常多,譬如

  1. Rotate Certificates,該功能主要是針對 Kubernetes 內各元件溝通用的憑證,譬如 API Server, Controller..等
  2. Snapshot 主要會針對 etcd 進行備份與還原,該備份並沒有辦法針對使用者部署的應用程式去處理備份跟還原,之後可以細談一下這塊
  3. Registration Cmd,由於該叢集是透過讓節點運行 Docker 指令將其加入到 RKE 叢集中,因此如果今天有新的節點要使用時,就可以直接點選該指令取得相關的 docker 指令,介面中也可以重新選擇身份與相關的標籤/Taint等。
  4. Run CIS Scan,這個功能會慢慢被淘汰,v2.5 後 Cluster Explorer 內關於 App 的管理方式有更好的處理方式,建議使用那邊的 CIS 處理。

最後一個則是透過 API 請求 Azure 創造 VM 的 RKE 叢集,基本上差異就只是沒有 Docker 指令可以處理。

從上述三個叢集的觀察到可以發現, Rancher 很多功能都跟 RKE 叢集有關,所以如果今天是讓 Rancher 管理並非是由 Rancher 創造的叢集,功能上都會有所限制,並不能完全發揮 Rancher 的功能。

看完叢集相關的狀態後,切換到節點頁面,節點頁面也會因為不同安裝方式會有不同的呈現方式

下圖是基於 AKS 所創造的叢集,該叢集顯示了三個節點,這些節點因為 AKS 的關係被打上了非常多的標籤。

如果該叢集是透過 API 要求 Azure 動態新增 VM 所創造的叢集,則該頁面是完全不同的類型

上述畫面中有幾個點可以注意

  1. 每個 Node Pool 都是獨立顯示,可以看到該 Node Pool 下目前有多少節點,每個節點的 IP 等資訊
  2. 每個 Node Pool 右方都有 +- 兩個按鈕,可以讓你動態的調整節點數量
  3. 由於這些節點都是動態創立的,因此如果今天有需求想要透過 SSH 去存取這些節點的話,實際上可以到每個節點旁邊的選項去下載該節點的 SSH Keys,這個功能是只有這種創造方式的叢集才擁有的。其他創造方式的叢集節點沒有辦法讓你下載相關的 SSH Key。

上述畫面除了 Cluster, Nodes 外還有其他選項,Member 頁面可以重新設定到底該叢集的擁有者與會員有誰,譬如最初 DEV 叢集只有 DEV 群組的使用者可以操作,目前嘗試將 QA 群組的使用者加入進去,並且設定權限為 Cluster Member,設定完後的畫面如下。

這種情況下,如果使用 QA 使用者登入,就可以看到這個 DEV 叢集,接者使用該 QA 使用者嘗試去存取該 DEV 叢集並且獲取該 Kubeconfig 就可以順利的使用了。

如果熟悉 Kubernetes RBAC 的讀者,可以嘗試挖掘一下到底 Rancher 是如何把設定的這些權限給對應到 Kubernetes 內的權限。下圖是一個範例。

下圖是 QA 使用者存取 DEV 叢集用的 Kubeconfig,可以看到 User 部分使用的 Token 進行驗證,該 Token 中有一個資訊代表的是該 User 的 ID,u-dc5fezjbyi

擁有該資訊後,可以到該 Kubernetes 叢集內去找尋 cattle-system 底下 ClusterUserAttribute 這個物件,看看是否有符合這個名稱的物件,找到後可以看到該物件描述了這使用者本身有一個 Group 的屬性。
該 Group 很明顯跟 Azure 有關,其值為 azuread_group://ec55ce9e-dbd4-427c-905c-d8063b19f150.
這個 Group 就會被用到 ClusterRoleBinding 中的 Subject

因此透過 kubectl 搭配 jq 的一些語法去找,看看有沒有哪些 ClusterRoleBinding 裏面是對應到這個 Group 群組,可以發現系統中有四個物件符合這個情況,而這四個物件對應到的 Role 分別是 read-only-promoted, cluster-member, p--namespaces-readonly,後面那個包含 “p-“ 字串的物件會跟之後探討的 Project 概念有關。

接者有興趣的可以再繼續看這些不同的 Roles 實際上被賦予什麼樣的權限與操作。

除了 Member 可以操作外, Cluster 還有一個 Tools 的清單可以玩

裡面有很多第三方整合工具可以安裝,但是如果是 v2.5 的使用者,非常建議直接忽略這個頁面,因為這邊都是舊版安裝與設
定行為,v2.5 後這些整合工具除了 Catalog 外基本上都已經搬移到 Cluster Explorer 頁面去安裝與操作。
因此接下來就嘗試進入到 Cluster Explorer 來看看這個 Rancher 想要推廣的新操作介面。

Cluster Explore 的介面跟 Cluster Manager 是截然不同的,這邊列出幾個重點

  1. 右上方可以選擇當前是觀看哪個叢集,可以快速切換,同時提供一個按鈕返回 Cluster Manager.
  2. 中間簡單呈現當前 Kubernetes 叢集的資訊,版本,提供者與節點資訊
  3. 跟之前一樣呈現系統的資源使用量,不過 CPU/Memory 本身同時提供當前使用量已經當前被預約使用量,這兩個數字可以更好的去幫助管理員去設計當前相關資源的 request/limit 要多少
  4. 左上方是重要的功能選單,不少功能都可以點選該處來處理
  5. 左下方呈現 Kubernetes 中的各項資源,每個資源都可以點進去觀看,譬如 ClusterRoleBinding 就會更友善的呈現每個物件對應到的到底是 User , Group 還是 Service Account。

點選左上方 Cluster Explorer 後切換到 Apps & Marketplace,可以看到類似下方的畫面

該畫面中呈現了可以讓使用者輕鬆安裝的各類應用程式,這些應用程式分成兩大類,由 Rancher 自行維護整合的或是由合作夥伴提供的。
如果安裝的是由 Rancher 整合的 Application,那安裝完畢左上方都會出現一個針對該 App 專屬的介面,譬如我們可以嘗試安裝 CIS Benchmark。

安裝過程中,畫面下方會彈出一個類似終端機的視窗告知使用者安裝過程,待一切安裝完畢後可以透過畫面中間的 “X” 來關閉這個視窗。

接者重新點選左上方的清單就會看到這時候有 CIS Benchmark 這個應用程式可以使用,該應用程式可以用來幫助管理去掃描 Kubernetes 叢集內是否有一些安全性的疑慮,該專案背後是依靠 kube-bench 來完成的,基本上 Rancher 有提供不同的 Profile 可以使用,所以對於安全性有需求的管理員可以安裝這個應用程式並且定期掃描。

一個掃描的示範如上,該圖片中顯示了使用的是 rke-profile-permissions-1.6 這個 profile,然後跑出來的結果有 62 個通過, 24 個警告, 36 測試不需要跑。
如果拿 RKE 的 profile 去跑 AKS 的叢集就會得到失敗,因為 RKE 的 profile 是針對 RKE 的環境去設計的,因此可能會有一些功能跟 AKS 的設計不同,會失敗也是可以預料的。

Rancher 本身提供的 Application 非常多,下篇文章就來仔細看看其中最好用的 Monitoring 套件到底能夠提供什麼功能,使用者安裝可以如何使用這個套件來完成 Promethues + Grafana 的基本功能。

個人資訊

我目前於 Hiskio 平台上面有開設 Kubernetes 相關課程,歡迎有興趣的人參考並分享,裡面有我從底層到實戰中對於 Kubernetes 的各種想法

詳細可以參閱
線上課程詳細資訊: https://course.hwchiu.com/

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

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

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

Welcome to my other publishing channels