Kubernetes 叢集節點管理對於系統穩定性和效能至關重要。本文以 microk8s 為例,探討如何監控節點狀態、管理 Pod 分佈以及 DaemonSet 的作用。實驗演示了節點故障時,Kubernetes 如何重新排程 Pod,以及節點還原後的行為。此外,文章也說明瞭 Kubernetes 的自動平衡機制,並提供相關 kubectl 指令操作與程式碼範例的詳細解析,讓讀者更深入理解 Kubernetes 叢集的運作機制。


title: “Kubernetes RBAC 許可權控管詳解” date: 2025-07-11T00:00:00+08:00 author: “玄貓(BlackCat)” categories: [“容器技術”, “資安”] tags: [“Kubernetes”, “RBAC”, “許可權控管”, “角色”, “角色繫結”, “microk8s”] draft: false math: true summary: “本文詳解 Kubernetes RBAC 許可權控管機制,說明如何根據使用者角色分配不同許可權,確保叢集安全。文章涵蓋 RBAC 的重要性、建立步驟、角色與角色繫結的概念,並以 DevOps 使用者為例,示範如何建立 Role 和 RoleBinding,以及驗證許可權組態。最後,文章也提出了安全性考量,提醒管理員注意最小許可權原則、定期稽核和群組管理等安全措施。”

RBAC 是 Kubernetes 叢集安全的重要機制,用於控制不同使用者對叢集資源的存取許可權。本文詳細說明瞭 RBAC 的重要性,並逐步演示如何建立 OS 使用者、啟用 RBAC、建立 Role 和 RoleBinding,以及驗證許可權。文章也涵蓋了 ClusterRole 和 ClusterRoleBinding 的概念,並以 DevOps 使用者為例,提供實作範例。最後,文章提醒管理員注意最小許可權原則、定期稽核和群組管理等安全措施,確保叢集安全。


title: “Kubernetes RBAC 新增使用者檢視許可權設定” date: 2025-07-11T00:00:00+08:00 author: “玄貓(BlackCat)” categories: [“容器技術”, “資安”] tags: [“Kubernetes”, “RBAC”, “許可權控管”, “Token”, “RoleBinding”, “microk8s”] draft: false math: true summary: “本文提供 Kubernetes RBAC 設定,專注於新增使用者並授權檢視許可權。文章逐步說明如何生成驗證 Token、將 Token 新增至 Kubernetes API 伺服器的靜態 Token 檔案、設定使用者 .kube/config 檔案、更新 RoleBinding,以及測試驗證。文章也詳細解密了相關指令和設定檔,並提供流程圖,方便讀者理解和操作。”

為新使用者設定 Kubernetes 檢視許可權需要正確組態 RBAC。本文提供詳細步驟,包含生成驗證 Token、設定 known_tokens.csv 和 .kube/config 檔案,以及更新 RoleBinding。文章也解析了相關指令和設定檔的細節,例如 /dev/urandom、base64 編碼、tee 命令等,並提供流程圖,幫助讀者理解整個設定流程,確保新使用者能安全地檢視叢集資源。

Kubernetes 叢集節點擴充套件與管理實務

在現代雲端運算環境中,Kubernetes 已成為容器協調的標準工具。正確管理叢集節點對於確保系統的高用性和效能至關重要。本文將探討 Kubernetes 叢集節點的管理,包括節點的擴充套件、維護和故障排除。

Kubernetes 叢集架構概述

Kubernetes 叢集由多個節點組成,每個節點都執行著 Kubernetes 的核心元件。這些節點可以分為兩類別:控制平面節點和工作節點。控制平面節點負責管理叢集的狀態,而工作節點則執行實際的工作負載。

叢集節點管理的關鍵概念

  1. 節點狀態監控:Kubernetes 持續監控每個節點的狀態,包括其健康狀況和資源利用率。
  2. Pod 分佈:Kubernetes 根據節點的資源和健康狀況,將 Pod 分佈到合適的節點上。
  3. DaemonSet:一種特殊的 Kubernetes 資源,用於確保每個節點上都執行一個特定的 Pod。

實驗環境設定

在我們的實驗環境中,我們建立了一個包含三個節點的 Kubernetes 叢集:wks01node02node03。我們使用 microk8s 作為 Kubernetes 的發行版。

檢視叢集節點狀態

microk8s kubectl get nodes

執行上述命令後,我們可以看到叢集中所有節點的狀態,包括其名稱、狀態、角色和 Kubernetes 版本。

DaemonSet 的運作原理

DaemonSet 是 Kubernetes 中的一種特殊資源,用於確保每個節點上都執行一個特定的 Pod。在我們的實驗中,calico-node 就是一個 DaemonSet。

檢視 DaemonSet 資訊

microk8s kubectl get daemonsets --namespace kube-system

這個命令顯示了 kube-system 名稱空間中的所有 DaemonSet,包括 calico-node。我們可以看到 calico-node 的期望數量、當前數量和就緒數量。

節點故障對叢集的影響

當一個節點故障時,Kubernetes 會自動將該節點上的 Pod 重新排程到其他健康的節點上。在我們的實驗中,當我們關閉 node03 時,calico-node-tkzbg Pod 仍然存在,但其狀態變為 NotReady

檢視 Pod 分佈

microk8s kubectl get pods -A -o custom-columns=NAME:metadata.name,NAMESPACE:metadata.namespace,NODENAME:spec.nodeName,HOSTIP:status.hostIP

這個命令顯示了所有名稱空間中的 Pod,包括其名稱、名稱空間、節點名稱和主機 IP。我們可以看到 calico-node-tkzbg 仍然在 node03 上,但 node03 已經變為 NotReady 狀態。

節點還原後的叢集行為

當我們重新啟動 node03 後,Kubernetes 會自動將其標記為 Ready 狀態。然而,由於我們之前對 node03 執行了 cordon 操作,其排程功能仍然被停用。

解除節點排程限制

microk8s kubectl uncordon node03

執行上述命令後,node03 還原了排程功能,可以再次接受新的 Pod。

Kubernetes 的自動平衡機制

Kubernetes 預設不會自動平衡節點上的 Pod,除非有必要(例如,節點資源不足)。在我們的實驗中,即使 node03 還原了正常,Kubernetes 也沒有自動將 Pod 遷移到 node03

檢視 Pod 分佈變化

microk8s kubectl get pods -A -o custom-columns=NAME:metadata.name,NAMESPACE:metadata.namespace,NODENAME:spec.nodeName,HOSTIP:status.hostIP

執行上述命令後,我們可以看到 Pod 的分佈沒有發生變化,calico-node-tkzbg 仍然在 node03 上。

重點回顧
  1. DaemonSet 的作用:確保每個節點上都執行一個特定的 Pod。
  2. 節點故障處理:Kubernetes 自動將故障節點上的 Pod 重新排程到其他健康的節點上。
  3. 節點還原後的行為:Kubernetes 自動將還原的節點標記為 Ready 狀態,但不會自動平衡 Pod。

程式碼範例解密

microk8s kubectl get pods -A -o custom-columns=NAME:metadata.name,NAMESPACE:metadata.namespace,NODENAME:spec.nodeName,HOSTIP:status.hostIP

內容解密:

此命令用於取得所有名稱空間中的 Pod 資訊,包括其名稱、名稱空間、節點名稱和主機 IP。這有助於我們瞭解 Pod 在叢集中的分佈情況。

microk8s kubectl uncordon node03

內容解密:

此命令用於解除對 node03 的排程限制,使其可以再次接受新的 Pod。這是 Kubernetes 節點管理中的一個重要操作。

microk8s kubectl get daemonsets --namespace kube-system

內容解密:

此命令用於取得 kube-system 名稱空間中的 DaemonSet 資訊。這有助於我們瞭解 DaemonSet 的組態和狀態。

隨著 Kubernetes 的不斷發展,未來可能會出現更多自動化的節點管理功能,例如自動平衡和智慧排程。這些功能將進一步提高 Kubernetes 叢集的可用性和效能。

參考資料

  1. Kubernetes 官方檔案:https://kubernetes.io/docs/
  2. Calico 官方檔案:https://docs.projectcalico.org/

圖表翻譯:

此圖示呈現了 Kubernetes 叢集的架構,包括控制平面節點和工作節點。控制平面節點負責管理叢集的狀態,而工作節點則執行實際的工作負載。

圖表翻譯: 此圖示呈現了 Kubernetes 叢集的架構,包括控制平面節點和工作節點之間的關係,以及 Pod 和容器的層級結構。

Kubernetes RBAC 許可權控管詳解

在現代的企業環境中,Kubernetes(K8S)叢集的管理與操作涉及多個不同角色的使用者。為了確保叢集的安全性與穩定性,Kubernetes 提供了 Role-Based Access Control(RBAC)機制,允許管理員根據使用者的角色分配不同的許可權,從而實作精細化的許可權控管。

為何需要 RBAC?

在 Kubernetes 中,預設情況下,叢集管理員擁有完整的控制許可權。然而,在實際的維運場景中,不同的使用者或團隊需要不同的操作許可權。例如:

  1. 叢集管理員(K8S Administrators):擁有完整的叢集管理許可權,可以進行叢集的組態、節點管理、資源排程等操作。
  2. 開發維運人員(DevOps Users):需要佈署應用程式、監控應用狀態、檢視日誌等許可權,但不應擁有叢集管理的許可權。
  3. 只讀使用者(Read-Only Users):僅需檢視叢集狀態、應用程式狀態等資訊,不應具備任何修改許可權。

為了滿足這些需求,Kubernetes 提供了 RBAC 機制,透過角色繫結來實作不同使用者群體的許可權控制。

建立 RBAC 的步驟

1. 建立對應的 OS 使用者

首先,我們需要為不同的角色建立對應的作業系統使用者,並將這些使用者加入到適當的群組中。例如:

sudo useradd -G microk8s -s /bin/bash -m k8sadmin01
sudo useradd -s /bin/bash -m k8sdevops01
sudo useradd -s /bin/bash -m k8sreadonly01

在上述範例中,k8sadmin01 被加入到 microk8s 群組,擁有叢集管理的許可權,而 k8sdevops01k8sreadonly01 則未被加入該群組,需要進一步組態 RBAC 規則來定義其許可權。

2. 啟用 RBAC 功能

在某些 Kubernetes 發行版中(如 MicroK8s),RBAC 功能預設是未啟用的。管理員需要手動啟用 RBAC:

microk8s enable rbac

啟用後,可以透過以下指令確認 RBAC 是否生效:

microk8s status

輸出結果中應顯示 rbac 已啟用。

Kubernetes 中的角色與角色繫結

Kubernetes 中的 RBAC 主要涉及兩個核心概念:角色(Role)角色繫結(RoleBinding)

  1. 角色(Role):定義了一組在特定名稱空間內的操作許可權。
  2. 叢集角色(ClusterRole):定義了一組跨名稱空間的操作許可權,適用於整個叢集。
  3. 角色繫結(RoleBinding):將角色繫結到使用者、群組或服務帳戶,使其獲得對應的許可權。
  4. 叢集角色繫結(ClusterRoleBinding):將叢集角色繫結到使用者、群組或服務帳戶,使其獲得叢集範圍內的許可權。

檢視現有的 ClusterRole

我們可以使用以下指令檢視叢集中預定義的 ClusterRole:

microk8s kubectl get clusterRole

輸出範例:

NAME CREATED AT
cluster-admin 2023-08-29T21:38:00Z
calico-kube-controllers 2023-08-27T23:57:03Z
calico-node 2023-08-27T23:57:03Z

其中,cluster-admin 是一個預定義的叢集管理員角色,擁有完整的叢集操作許可權。

實作範例:為 DevOps 使用者組態 RBAC

假設我們需要為 k8sdevops01 使用者組態許可權,使其能夠在 default 名稱空間中佈署應用程式並檢視相關資源。

1. 建立 Role

首先,建立一個 Role,定義在 default 名稱空間中的操作許可權:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: devops-role
  namespace: default
rules:
- apiGroups: ["*"]
  resources:
  - pods
  - deployments
  verbs: ["get", "list", "create", "update", "delete"]

套用該組態:

microk8s kubectl apply -f devops-role.yaml

2. 建立 RoleBinding

接著,建立 RoleBinding,將 devops-role 繫結到 k8sdevops01 使用者:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: devops-rolebinding
  namespace: default
roleRef:
  name: devops-role
  kind: Role
subjects:
- kind: User
  name: k8sdevops01
  apiGroup: rbac.authorization.k8s.io

套用該組態:

microk8s kubectl apply -f devops-rolebinding.yaml

3. 驗證許可權

切換到 k8sdevops01 使用者,驗證其許可權:

microk8s kubectl get pods -n default

如果組態正確,該使用者應能列出 default 名稱空間中的 Pod。

安全性考量

  1. 最小許可權原則:僅授予使用者完成工作所需的最小許可權,避免過度授權。
  2. 定期稽核:定期檢查 RBAC 組態,確保許可權設定的合理性。
  3. 群組管理:利用群組管理使用者許可權,簡化許可權組態流程。

Kubernetes RBAC 設定:新增使用者並授權檢視許可權

在 Kubernetes 中,Role-Based Access Control(RBAC)是一種用於管理叢集資源存取許可權的機制。本篇文章將詳細介紹如何為新使用者新增檢視叢集資源的許可權,並逐步解析相關的設定步驟。

為何需要 RBAC?

在 Kubernetes 叢集中,RBAC 能夠有效地控制不同使用者或服務帳戶對資源的存取許可權。透過 RBAC,管理員可以精確地定義哪些使用者可以執行哪些操作,從而提高叢集的安全性。

步驟 1:生成驗證 Token

首先,我們需要生成一個 base64 編碼的字串作為驗證 Token。有多種方法可以生成這個 Token,以下是幾種常見的方法:

方法一:使用 /dev/urandom 生成 Token

echo `dd if=/dev/urandom bs=128 count=1 2>/dev/null | base64 | tr -d "=+/ " | dd bs=32 count=1 2>/dev/null`

方法二:手動輸入隨機字元生成 Token

echo 'hdfUJgds537Hsg373$&jsg1!lkshfdjshGj&6sd3k2bs' | base64 -w 0

方法三:生成並儲存 Token 到檔案

dd if=/dev/urandom bs=48 count=1 2>/dev/null | base64 -w 0 | cut -b1-61 | tee mytoken.txt

無論採用哪種方法,請妥善儲存生成的 Token,因為它將用於後續的驗證。

內容解密:

  • /dev/urandom 是一個 Linux 系統中的特殊檔案,用於生成隨機數。
  • base64 編碼用於將二進位制資料轉換為可讀的字串格式。
  • tr -d "=+/ " 用於刪除 base64 編碼中可能出現的特殊字元,以符合 Token 的格式要求。
  • tee 命令用於將輸出結果儲存到檔案中。

步驟 2:將 Token 新增到 Kubernetes API 伺服器的靜態 Token 檔案

  1. 首先,需要找到 Kubernetes API 伺服器的設定檔。對於 microk8s 叢集,可以透過以下命令查詢相關設定:
ps -ef | grep [k]ube-apiserver
  1. 從輸出結果中找到 kube-apiserver 的啟動引數,其中包含了設定檔的路徑。
/var/snap/microk8s/5643/credentials/known_tokens.csv
  1. 編輯 known_tokens.csv 檔案,並在檔案末尾新增以下格式的內容:
<Token>,<使用者名稱>,<角色>

範例:

No6sy49awQnHRLmrBmn/kt0ucSLvFYNnPpKcFCpxZ6Yw1Ye2QNop9OybP6Iac,k8sreadonly01,k8sreadonly02,view

這行內容表示:當使用者 k8sreadonly01k8sreadonly02 使用指定的 Token 進行驗證時,將被授予 view 角色的許可權。

內容解密:

  • known_tokens.csv 是 Kubernetes 用於儲存靜態 Token 的檔案。
  • 每行的格式為 <Token>,<使用者名稱>,<角色>,用於將 Token 與特定使用者和角色進行對映。

步驟 3:設定使用者的 .kube/config 檔案

  1. 將生成的 Token 新增到使用者的 .kube/config 檔案中,以完成驗證設定。
apiVersion: v1
kind: Config
users:
- name: k8sreadonly01
  user:
    token: No6sy49awQnHRLmrBmn/kt0ucSLvFYNnPpKcFCpxZ6Yw1Ye2QNop9OybP6Iac

內容解密:

  • .kube/config 檔案儲存了 Kubernetes 叢集的連線設定,包括使用者驗證資訊。
  • token 欄位用於指定使用者的驗證 Token。

步驟 4:更新 RoleBinding

使用以下命令將 k8sreadonly01 使用者繫結到 view 角色:

kubectl create rolebinding k8sreadonly01-view --clusterrole=view --user=k8sreadonly01 --namespace=default

內容解密:

  • rolebinding 用於將角色與使用者進行繫結。
  • --clusterrole=view 指定要繫結的角色為 view
  • --user=k8sreadonly01 指定要繫結的使用者。

步驟 5:測試驗證

  1. 切換到 k8sreadonly01 使用者,並執行以下命令驗證許可權:
kubectl get pods --all-namespaces

如果一切設定正確,該使用者應該能夠檢視叢集中的 Pod 資源。

  1. 嘗試執行需要更高許可權的操作,例如建立或刪除資源:
kubectl create deployment test --image=nginx

預期結果是操作失敗,因為 view 角色僅具有檢視許可權。

內容解密:

  • kubectl get pods --all-namespaces 用於檢視叢集中所有名稱空間中的 Pod 資源。
  • view 角色具有檢視叢集資源的許可權,但無法執行建立或修改操作。

Kubernetes RBAC 設定流程

@startuml
skinparam backgroundColor #FEFEFE
skinparam componentStyle rectangle

title Kubernetes 叢集節點擴充套件管理實務

package "Kubernetes Cluster" {
    package "Control Plane" {
        component [API Server] as api
        component [Controller Manager] as cm
        component [Scheduler] as sched
        database [etcd] as etcd
    }

    package "Worker Nodes" {
        component [Kubelet] as kubelet
        component [Kube-proxy] as proxy
        package "Pods" {
            component [Container 1] as c1
            component [Container 2] as c2
        }
    }
}

api --> etcd : 儲存狀態
api --> cm : 控制迴圈
api --> sched : 調度決策
api --> kubelet : 指令下達
kubelet --> c1
kubelet --> c2
proxy --> c1 : 網路代理
proxy --> c2

note right of api
  核心 API 入口
  所有操作經由此處
end note

@enduml

圖表翻譯: 此圖展示了 Kubernetes RBAC 設定的流程:

  1. 首先生成驗證 Token。
  2. 將 Token 新增到 Kubernetes API 伺服器的靜態 Token 檔案中。
  3. 設定使用者的 .kube/config 檔案以使用該 Token。
  4. 更新 RoleBinding,將使用者與特定角色進行繫結。
  5. 進行測試驗證,確保設定正確。
  6. 完成 RBAC 設定,確保叢集資源的安全性和可控性。