基於 KubeSphere 的分級管理實踐

KubeSphere 發表於 2022-06-28
作者:許偉,航天網信研發工程師

K8s 是容器編排和分散式應用部署領域的領導者,在 K8s 環境中,我們只需要關心應用的業務邏輯,減輕了我們伺服器網路以及儲存等方面的管理負擔。對於一個使用者而言,K8s 是一個很複雜的容器編排平臺,學習成本非常高。KubeSphere 抽象了底層的 K8s,並進行了高度的產品化,構建了一個全棧的多租戶容器雲平臺,為使用者提供了一個健壯、安全、功能豐富、具備極致體驗的 Web 控制檯,解決了 K8s 使用門檻高和雲原生生態工具龐雜等痛點,使我們可以專注於業務的快速迭代,其多維度的資料監控,對於問題的定位,提供了很大的幫助。

為什麼要在 KuberSphere 上實現分級管理

在 KubeSphere 中,資源可以在租戶之間共享,根據分配的不同角色,可以對各種資源進行操作。租戶與資源之間、資源與資源之間的自由度很高,許可權粒度也比較大。在我們的系統中,資源是有許可權等級的,像是低等級使用者可以通過邀請、賦予許可權等操作來操作高等級資源,或者像是低等級專案中的 Pod 可以排程到高等級的節點上,對資源。諸如此類跨等級操作資源等問題,我們在 KubeSphere 基礎上來實現了分級管理。

什麼是分級體系

分級,顧名思義就是按照既定的標準對整體進行分解、分類。我們將其抽象成一個金字塔模型,從地基到塔頂會有很多個層級,我們將公共資源作為金字塔的地基,擁有最高許可權的 admin 作為塔頂,其他資源按照許可權等級劃分成不同等級。低層級資源是不能訪問高等級資源,高等級資源可以獲取它等級之下的所有資源,構建了這樣一個權益遞減、層級間隔離的分級體系。

基於 KubeSphere 的分級管理實踐

如何實現分級管理

我們定義了一個代表等級的標籤 kubernetes.io/level。以一個多節點的叢集為例,首先我們會給使用者、企業空間、節點等資源打上代表等級的標籤。在邀請使用者加入企業空間或者專案時,要求加入的企業空間或者專案的等級不得高於使用者的等級,同樣專案在繫結企業空間時,也要求專案的等級不得高於企業空間的等級,才能對資源進行納管;我們認為同一專案下的資源的等級是相同的,基於專案建立的負載、Pod、服務等資源的等級跟專案保持一致;同時 Pod 中加入節點親和性,以使 Pod 排程到不高於其許可權等級的節點上。

基於 KubeSphere 的分級管理實踐

例如這裡,我們建立了一個許可權等級是 3 的使用者 demo-user,他可以加入許可權等級不高於3的企業空間或者專案中。

kind: User
apiVersion: iam.kubesphere.io/v1alpha2
metadata:
  name: demo-user
  labels:
    kubernetes.io/level: 3
spec:
  email: [email protected]

建立一個許可權等級是 2 的專案 demo-ns,那麼基於專案建立的負載、Pod、儲存等資源的許可權等級也是 2。

apiVersion: v1
kind: Namespace
metadata:
   name: demo-ns
   labels:
     kubernetes.io/level: 2

基於 demo-ns 專案建立了一個nginx 的 Pod,他的許可權等級也是 2,同時加入節點親和性,要求其排程到許可權等級不高於 2 的節點上。

apiVersion: apps/v1
kind: Pod
metadata:
  labels:
    kubernetes.io/level: 2
  name: nginx
spec:
  containers:
  - name: nginx
    image: nginx
    imagePullPolicy: IfNotPresent
    ports:
    - containerPort: 80
      protocol: TCP
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
       nodeSelectorTerms:
        - matchExpressions:
          - key: kubernetes.io/level
            operator: Lt
            values:
            - 2
        - matchExpressions:
          - key: kubernetes.io/level
            operator: In
            values:
            - 2

如何實現資源的升降級

在分級管理體系中,支援等級的無限劃分,只需要定義一箇中間值,就可以在兩個等級之間插入一個新的等級,無需操作其他資源;在對資源進行升降級時,只需要修改對應資源的 label 標籤,就可以對資源進行升降級操作。當然,在對資源進行升降級的時候,我們需要對資源進行檢測,保證升級時,其上層資源的許可權等級不得低於目標等級;同時,降級時,其下層資源的許可權等級不得高於目標等級。在不滿足升降級操作條件時,需要將對應資源也做相應調整才可以。

基於 KubeSphere 的分級管理實踐

不同層級間 Pod 的網路隔離

在分級體系中,我們要求高等級的 Pod 能訪問低等級的 Pod,但是低等級的 Pod 不能訪問高等級的 Pod,那我們需要如何保證不同層級間 Pod 的網路通訊呢。

專案在不開啟網路隔離的情況下,Pod 間的網路是互通的,所以這裡會新增一個黑名單的網路策略。

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all
  namespace: demo-ns
  labels:
    kubernetes.io/level: 2
spec:
  podSelector: {}
  policyTypes:
  - Ingress

podSelector:{} 作用於專案中所有 Pod,阻止所有流量的流入。

然後放行標籤等級大於目標等級(這裡是 2)的流量流入(我們對 Ingress 流量沒有做限制)。

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: level-match-network-policy
  namespace: demo-ns
  labels:
    kubernetes.io/level: 2
spec:
  podSelector:
    matchExpressions:
    - key: kubernetes.io/level
      operator: Gt
      values:
      - 2
  policyTypes:
  - Ingress

總結

KubeSphere 解決了使用者構建、部署、管理和可觀測性等方面的痛點,它的資源可以在多個租戶之間共享。但是在資源有許可權等級的場景中,低等級資源可以操作高等級資源,造成資源越權管理的問題。為解決這一問題,我們在 KubeSphere 的基礎上進行了改造,以適應租戶與資源之間和資源與資源之間的分級管理,同時在專案的網路策略中,增加黑名單和白名單策略,增強了專案間的網路隔離,讓資源的管理更安全。

本文由部落格一文多發平臺 OpenWrite 釋出!