前言

K8s 是容器編排和分布式應(yīng)用部署領(lǐng)域的領(lǐng)導(dǎo)者，在 K8s 環(huán)境中，我們只需要關(guān)心應(yīng)用的業(yè)務(wù)邏輯，減輕了我們服務(wù)器網(wǎng)絡(luò)以及存儲等方面的管理負擔(dān)。對于一個用戶而言，K8s 是一個很復(fù)雜的容器編排平臺，學(xué)習(xí)成本非常高。KubeSphere 抽象了底層的 K8s，并進行了高度的產(chǎn)品化，構(gòu)建了一個全棧的多租戶容器云平臺，為用戶提供了一個健壯、安全、功能豐富、具備極致體驗的 Web 控制臺，解決了 K8s 使用門檻高和云原生生態(tài)工具龐雜等痛點，使我們可以專注于業(yè)務(wù)的快速迭代，其多維度的數(shù)據(jù)監(jiān)控，對于問題的定位，提供了很大的幫助。

為什么要在 KuberSphere 上實現(xiàn)分級管理

在 KubeSphere 中，資源可以在租戶之間共享，根據(jù)分配的不同角色，可以對各種資源進行操作。租戶與資源之間、資源與資源之間的自由度很高，權(quán)限粒度也比較大。在我們的系統(tǒng)中，資源是有權(quán)限等級的，像是低等級用戶可以通過邀請、賦予權(quán)限等操作來操作高等級資源，或者像是低等級項目中的 Pod 可以調(diào)度到高等級的節(jié)點上，對資源。諸如此類跨等級操作資源等問題，我們在 KubeSphere 基礎(chǔ)上來實現(xiàn)了分級管理。

什么是分級體系

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

如何實現(xiàn)分級管理

我們定義了一個代表等級的標(biāo)簽 kubernetes.io/level。以一個多節(jié)點的集群為例，首先我們會給用戶、企業(yè)空間、節(jié)點等資源打上代表等級的標(biāo)簽。在邀請用戶加入企業(yè)空間或者項目時，要求加入的企業(yè)空間或者項目的等級不得高于用戶的等級，同樣項目在綁定企業(yè)空間時，也要求項目的等級不得高于企業(yè)空間的等級，才能對資源進行納管；我們認為同一項目下的資源的等級是相同的，基于項目創(chuàng)建的負載、Pod、服務(wù)等資源的等級跟項目保持一致；同時 Pod 中加入節(jié)點親和性，以使 Pod 調(diào)度到不高于其權(quán)限等級的節(jié)點上。

例如這里，我們創(chuàng)建了一個權(quán)限等級是 3 的用戶 demo-user，他可以加入權(quán)限等級不高于3的企業(yè)空間或者項目中。

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

創(chuàng)建一個權(quán)限等級是 2 的項目 demo-ns，那么基于項目創(chuàng)建的負載、Pod、存儲等資源的權(quán)限等級也是 2。

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

基于 demo-ns 項目創(chuàng)建了一個nginx 的 Pod，他的權(quán)限等級也是 2，同時加入節(jié)點親和性，要求其調(diào)度到權(quán)限等級不高于 2 的節(jié)點上。

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

如何實現(xiàn)資源的升降級

在分級管理體系中，支持等級的無限劃分，只需要定義一個中間值，就可以在兩個等級之間插入一個新的等級，無需操作其他資源；在對資源進行升降級時，只需要修改對應(yīng)資源的 label 標(biāo)簽，就可以對資源進行升降級操作。當(dāng)然，在對資源進行升降級的時候，我們需要對資源進行檢測，保證升級時，其上層資源的權(quán)限等級不得低于目標(biāo)等級；同時，降級時，其下層資源的權(quán)限等級不得高于目標(biāo)等級。在不滿足升降級操作條件時，需要將對應(yīng)資源也做相應(yīng)調(diào)整才可以。

不同層級間 Pod 的網(wǎng)絡(luò)隔離

在分級體系中，我們要求高等級的 Pod 能訪問低等級的 Pod，但是低等級的 Pod 不能訪問高等級的 Pod，那我們需要如何保證不同層級間 Pod 的網(wǎng)絡(luò)通信呢。

項目在不開啟網(wǎng)絡(luò)隔離的情況下，Pod 間的網(wǎng)絡(luò)是互通的，所以這里會新增一個黑名單的網(wǎng)絡(luò)策略。

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，阻止所有流量的流入。

然后放行標(biāo)簽等級大于目標(biāo)等級（這里是 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

總結(jié)

KubeSphere 解決了用戶構(gòu)建、部署、管理和可觀測性等方面的痛點，它的資源可以在多個租戶之間共享。但是在資源有權(quán)限等級的場景中，低等級資源可以操作高等級資源，造成資源越權(quán)管理的問題。為解決這一問題，我們在 KubeSphere 的基礎(chǔ)上進行了改造，以適應(yīng)租戶與資源之間和資源與資源之間的分級管理，同時在項目的網(wǎng)絡(luò)策略中，增加黑名單和白名單策略，增強了項目間的網(wǎng)絡(luò)隔離，讓資源的管理更安全。

以上就是KubeSphere分級管理實踐及解析的詳細內(nèi)容，更多關(guān)于KubeSphere分級管理實踐的資料請關(guān)注腳本之家其它相關(guān)文章！

最新評論