跳至主要内容

與下游使用者叢集通訊

本節描述 Rancher 如何佈建和管理執行你的應用程式和服務的下游使用者叢集。

下圖顯示叢集控制器、叢集代理和節點代理如何允許 Rancher 控制下游叢集。

與下游叢集通訊

Rancher Components

以下說明對應於上圖中的數字:

  1. 身份驗證代理
  2. 叢集控制器和叢集代理
  3. 節點代理
  4. 授權叢集端點

1. 身份驗證代理​

在此圖中,一個名為 Bob 的使用者想要查看在名為 User Cluster 1 的下游使用者叢集上執行的所有 Pod。從 Rancher 內部,他可以執行 kubectl 指令來查看 Pod。Bob 透過 Rancher 的身份驗證代理進行身份驗證。

身份驗證代理將所有 Kubernetes API 呼叫轉發到下游叢集。它與本地身份驗證、Active Directory 和 GitHub 等身份驗證服務整合。在每次 Kubernetes API 呼叫時,身份驗證代理都會對呼叫者進行身份驗證,並在將呼叫轉發到 Kubernetes master 之前設定適當的 Kubernetes 模擬標頭。

Rancher 使用服務帳戶與 Kubernetes 叢集通訊。Rancher 中的每個使用者帳戶都與下游叢集中的等效服務帳戶相關聯。Rancher 使用服務帳戶來模擬使用者,這提供了使用者應該擁有的所有權限。

預設情況下,Rancher 生成一個 kubeconfig 檔案,其中包含透過 Rancher 伺服器代理連接到下游使用者叢集上的 Kubernetes API 伺服器的憑證。kubeconfig 檔案(kube_config_rancher-cluster.yml)包含對叢集的完全存取權限。

2. 叢集控制器和叢集代理​

每個下游使用者叢集都有一個叢集代理,它會開啟一個通道到 Rancher 伺服器內相應的叢集控制器。

每個下游叢集都有一個叢集控制器和一個叢集代理。每個叢集控制器:

  • 監視下游叢集中的資源變更
  • 將下游叢集的目前狀態調整為所需狀態
  • 配置叢集和專案的存取控制原則
  • 透過呼叫所需的 Docker 機器驅動程式和 Kubernetes 引擎(例如 GKE)來佈建叢集

預設情況下,為了使 Rancher 能夠與下游叢集通訊,叢集控制器會連接到叢集代理。如果叢集代理不可用,叢集控制器可以改為連接到節點代理。

叢集代理,也稱為 cattle-cluster-agent,是在下游使用者叢集中執行的元件。它執行以下任務:

  • 連接到 Rancher 啟動的 Kubernetes 叢集的 Kubernetes API
  • 管理每個叢集內的工作負載、Pod 建立和部署
  • 套用每個叢集的全域原則中定義的角色和綁定
  • 透過通道(到叢集控制器)在叢集和 Rancher 伺服器之間通訊有關事件、統計資料、節點資訊和健康狀況

3. 節點代理​

如果叢集代理(也稱為 cattle-cluster-agent)不可用,其中一個節點代理會建立一個通道到叢集控制器以與 Rancher 通訊。

cattle-node-agent 使用 DaemonSet 資源部署,以確保它在 Rancher 啟動的 Kubernetes 叢集中的每個節點上執行。它用於在執行叢集操作時與節點互動。叢集操作的範例包括升級 Kubernetes 版本以及建立或還原 etcd 快照。

4. 授權叢集端點​

授權叢集端點 (ACE) 允許使用者連接到下游叢集的 Kubernetes API 伺服器,而無需透過 Rancher 身份驗證代理路由他們的請求。

ACE 可用於使用 Rancher 佈建或註冊的 RKE2 和 K3s 叢集。它不可用於託管 Kubernetes 提供者中的叢集,例如 Amazon 的 EKS。

使用者可能需要授權叢集端點的兩個主要原因:

  • 在 Rancher 故障時存取下游使用者叢集
  • 在 Rancher 伺服器和下游叢集相距很遠的情況下減少延遲

kube-api-auth 微服務被部署以提供授權叢集端點的使用者身份驗證功能。當你使用 kubectl 存取使用者叢集時,叢集的 Kubernetes API 伺服器透過使用 kube-api-auth 服務作為 webhook 來對你進行身份驗證。

與授權叢集端點一樣,kube-api-auth 身份驗證服務也僅適用於 Rancher 啟動的 Kubernetes 叢集。

範例情境: 假設 Rancher 伺服器位於美國,而 User Cluster 1 位於澳洲。使用者 Alice 也住在澳洲。Alice 可以透過使用 Rancher UI 來操作 User Cluster 1 中的資源,但她的請求必須從澳洲發送到美國的 Rancher 伺服器,然後代理回澳洲,即下游使用者叢集所在的地方。地理距離可能會導致顯著的延遲,Alice 可以透過使用授權叢集端點來減少延遲。

為下游叢集啟用此端點後,Rancher 會在 kubeconfig 檔案中生成一個額外的 Kubernetes 上下文,以便直接連接到叢集。此檔案具有 kubectl 和 helm 的憑證。

備註

要在你的 kubeconfig 中使用 ACE 上下文,請在啟用它後執行 kubectl use-context <ace context name>。

有關更多資訊,請參閱有關使用 kubectl 和 kubeconfig 檔案存取叢集的部分。

我們建議匯出 kubeconfig 檔案,這樣如果 Rancher 故障,你仍然可以使用檔案中的憑證來存取你的叢集。

模擬​

從技術上講,使用者僅存在於上游叢集上。Rancher 建立引用 Rancher 使用者的 RoleBindings 和 ClusterRoleBindings,即使下游叢集上沒有實際的 User 資源。

當使用者透過身份驗證代理與下游叢集互動時,需要有一些實體在下游作為這些請求的執行者。Rancher 建立服務帳戶作為該實體。每個服務帳戶僅被授予一個權限,即模擬它們所屬的使用者。如果只有一個服務帳戶可以模擬任何使用者,那麼惡意使用者可能會破壞該帳戶並透過模擬另一個使用者來提升他們的權限。這個問題是 CVE 的基礎。

模擬疑難排解​

在下游叢集上,有五個資源處理模擬:

  • namespace: cattle-impersonation-system
  • service account: cattle-impersonation-system/cattle-impersonation-<user ID>
  • account token secret: cattle-impersonation-system/cattle-impersonation-<user ID>-token-<hash>
  • cluster role: cattle-impersonation-<user ID>
  • cluster role binding: cattle-impersonation-<user ID>

在這個典型模擬叢集角色的範例中,系統配置為使用 github 作為身份驗證提供者:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
creationTimestamp: "2021-10-06T18:20:13Z"
labels:
authz.cluster.cattle.io/impersonator: "true"
cattle.io/creator: norman
name: cattle-impersonation-user-abcde
resourceVersion: "3528"
uid: a7478731-72a0-4343-b09f-c3bf12552d77
rules:
# allowed to impersonate user user-abcde
- apiGroups:
- ""
resourceNames:
- user-abcde
resources:
- users
verbs:
- impersonate
# allowed to impersonate listed groups
- apiGroups:
- ""
resourceNames:
- github_team://123 # group from GitHub auth provider
- system:authenticated # automatic group from Kubernetes
- system:cattle:authenticated # automatic group from Rancher
resources:
- groups
verbs:
- impersonate
# allowed to impersonate principal ID github_user://098
- apiGroups:
- authentication.k8s.io
resourceNames:
- github_user://098 # principal ID from GitHub auth provider
resources:
- userextras/principalid
verbs:
- impersonate
# allowed to impersonate username example
- apiGroups:
- authentication.k8s.io
resourceNames:
- example # username from GitHub auth provider
resources:
- userextras/username
verbs:
- impersonate

當你對模擬問題進行疑難排解時,檢查這些資源是否存在於使用者,以及叢集角色中的規則是否與上述類似。例如:

kubectl --namespace cattle-impersonation-system get serviceaccount cattle-impersonation-<user ID>
kubectl --namespace cattle-impersonation-system get secret cattle-impersonation-<user ID>-token-<hash>
kubectl get clusterrole cattle-impersonation-<user ID> --output yaml
kubectl get clusterrolebinding cattle-impersonation-<user ID>

如果你在 UI 中看到與「模擬」相關的錯誤,請密切注意錯誤訊息的結尾,它應該指示請求失敗的真正原因。

重要檔案​

以下提到的檔案是維護、疑難排解和升級叢集所需的:

  • config.yaml:RKE2 和 K3s 叢集配置檔案。
  • rke2.yaml 或 k3s.yaml:你的 RKE2 或 K3s 叢集的 Kubeconfig 檔案。此檔案包含完全存取叢集的憑證。如果 Rancher 故障,你可以使用此檔案對 Rancher 啟動的 Kubernetes 叢集進行身份驗證。

有關在沒有 Rancher 身份驗證代理的情況下連接到叢集以及其他配置選項的更多資訊,請參閱 kubeconfig 檔案文件。

佈建 Kubernetes 叢集的工具​

Rancher 用於佈建下游使用者叢集的工具取決於正在佈建的叢集類型。

在基礎設施提供者中託管節點的 Rancher 啟動的 Kubernetes​

Rancher 可以在 Amazon EC2、DigitalOcean、Azure 或 vSphere 等提供者中動態佈建節點,然後在其上安裝 Kubernetes。

Rancher 使用 docker-machine 來佈建這種類型的叢集。

自訂節點的 Rancher 啟動的 Kubernetes​

設定這種類型的叢集時,Rancher 在現有節點上安裝 Kubernetes,這將建立一個自訂叢集。

Rancher 使用 RKE2 或 K3s 來佈建這種類型的叢集。

託管 Kubernetes 提供者​

設定這種類型的叢集時,Kubernetes 由 Google Kubernetes Engine、Amazon Elastic Container Service for Kubernetes 或 Azure Kubernetes Service 等提供者安裝。

Rancher 使用 kontainer-engine 來佈建這種類型的叢集。

匯入的 Kubernetes 叢集​

在這種類型的叢集中,Rancher 連接到已經設定好的 Kubernetes 叢集。因此,Rancher 不會佈建 Kubernetes,而只是設定 Rancher 代理以與叢集通訊。

Rancher 伺服器元件和原始碼​

此圖顯示 Rancher 伺服器由哪些元件組成:

Rancher Components

Rancher 的 GitHub 儲存庫可以在以下連結中找到:

這是最重要的 Rancher 儲存庫的部分清單。有關 Rancher 原始碼的更多詳細資訊,請參閱為 Rancher 做出貢獻的部分。要查看 Rancher 中使用的所有程式庫和專案,請參閱 rancher/rancher 儲存庫中的 go.mod 檔案。