Skip to content

我要 1 座 Kubernetes 還是要多座 Kubernetes? 還是都可以?

曾經於 SDN x Cloud Native Meetup #42 OPA + 單多叢集架構探討、簡報 分享過 Kubernetes 多叢集及單叢集架構選擇探討 的題目，當中有多租戶議題還蠻受到關注的，剛好因為工作關係也有蠻多客戶在問相同的題目，這邊想用文字的方式紀錄一下，供大家參考

Q1: 何謂 1 座 Kubernetes?

可單獨運行之 Kubernetes API 為最小管理單位，跟該座 Kubernetes 底下有多少節點完全無關，無論是 Control Plane 或 Worker Plane。實務上，可以使用 kubectl cluster-info 來做判斷

$ kubectl cluster-info
Kubernetes control plane is running at https://192.168.100.1:8443
CoreDNS is running at https://192.168.100.1:8443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy

如上所示，因 Kubernetes 的設計是所有的操作都需要跟 Kubernetes API Server 進行，該服務預設一定會建立在 Control Plane 上，也就是 https://192.168.100.1:8443 來進行溝通，所以如果你有 2 個以上的 Kubernetes 叢集，勢必會獲得到不一樣的 Kubernetes cluster-info 資訊

# 使用叢集 Dev-and-Staging-Cluster
kubectl config use-c context Dev-and-Staging-Cluster

# Kubernetes 叢集 Dev-and-Staging-Cluster
$ kubectl cluster-info
Kubernetes control plane is running at https://192.168.100.1:8443
CoreDNS is running at https://192.168.100.1:8443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy

# 切換至叢集 Prod-Cluster
kubectl config use-context Prod-Cluster

# Kubernetes 叢集 Prod-Cluster
$ kubectl cluster-info
Kubernetes control plane is running at https://192.168.200.1:8443
CoreDNS is running at https://192.168.200.1:8443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy

如上所示，透過 kubectl config use-context 可以切換至其他叢集進行操作，你會發現到 2 個叢集的 Control Plane 網址是不一樣的 https://192.168.100.1:8443 跟 https://192.168.200.1:8443，這代表你在跟不同的叢集在進行操作

上述流程若你有去考過 CNCF 3 個考試

  • Certified Kubernetes Administrator (CKA)
  • Certified Kubernetes Application Developer (CKAD)
  • Certified Kubernetes Security Specialist (CKS)

應該會覺得相當熟悉，因為考試的時候也會要你切來切去，其實就是避免不同的考題所需的環境影響到彼此，屬於實體方式隔離 Kubernetes 叢集

Q2: Kubernetes 多租戶隔離架構有多少種類型?

匯總 AKS、EKS、GKE 三家公有雲的實踐作法，會區分成 2 個方向，

  1. 以邏輯方式隔離 Kubernetes 叢集，也就是軟多租戶 (Soft Multi-Tenancy)
  2. 以實體方式隔離 Kubernetes 叢集，也就是硬多租戶 (Hard Multi-Tenancy)

還有一種比較特殊的硬多租戶，僅會出現在 Kubernetes 平台供應商方的軟體架構設計，因為我這篇主要是寫給單純的 Kubernetes 使用者看，所以不列入討論

Q3: 軟多租戶 (Soft Multi-Tenancy) 的邏輯方式隔離手段有哪一些?

下面引用 在 Azure Kubernetes Service (AKS) 中隔離叢集的最佳做法 的示意圖

以通過 CNCF Conformance 為主的 Kubernetes 叢集為主，邏輯方式隔離手段主要區分 4 個作法

  1. Kubernetes Namespace：單一叢集內部命名空間隔離
  2. Kubernetes Network Policy：單一叢集內部網路隔離
  3. Kubernetes RBAC：單一叢集權限隔離
  4. Resource Quota：單一叢集內之計算資源隔離

實際上就是拿到 1 座 Kubernetes 叢集後，針對該叢集進行上述 4 個作法的邏輯隔離來進行資源隔離，但最小操作單位是 Kubernetes Namespace 為主，而底層計算資源大家是共用的，如下所列，我這座 https://192.168.100.1:8443 叢集轄下的 Kubernetes Namespace 可透過 kubectl create ns <NAME> 新增 Namespace，除了系統必要的 Namespace 以外，另外還新增了 3 個面向專案或應用的 DevTeam1、DevTeam2、Staging Namespace 供各別服務使用

# 以 Dev and Staging Cluster 為例
$ kubectl cluster-info
Kubernetes control plane is running at https://192.168.100.1:8443
CoreDNS is running at https://192.168.100.1:8443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy

$ kubectl get namespace
NAME                        STATUS   AGE
default                     Active   16h <- Kubernetes 預設
DevTeam1                    Active   14s <- 使用者自己建的
DevTeam2                    Active   14s <- 使用者自己建的
kube-node-lease             Active   16h <- Kubernetes 預設
kube-public                 Active   16h <- Kubernetes 預設
kube-system                 Active   16h <- Kubernetes 預設
local-path-storage          Active   16h <- 特定廠商預設
Staging                     Active   10s <- 使用者自己建的
tanzu-package-repo-global   Active   16h <- 特定廠商預設
tanzu-system-ingress        Active   10h <- 特定廠商預設
tkg-system                  Active   16h <- 特定廠商預設

這方式也是絕大部分在學 Kubernetes 的維運管理操作的時候，著墨比較多的常見角度及常見學習路徑

Q4: 硬多租戶 (Hard Multi-Tenancy) 的實體方式隔離手段有哪一些?

恩...這個其實沒有什麼訣竅，就是再建立 1 座 Kubernetes就好，有獨立的 Kubernetes API、獨立的計算網路儲存資源，軟多租戶的邏輯方式隔離也可以完全使用

預期有這麼多的 Kubernetes 叢集被部署出來，還是要能夠被管理，以現行常見的多叢集管理作法，包括但不限於以下： - 多叢集網路規劃，包含對外負載均衡、跨叢集網路 - 多叢集策略管理 - Single Sign On 單一登入 - 集中化日誌收集 - 集中化資源監控 - ...

Q5: 兩者可不可以混用?

可，多建幾座 Kubernetes 裡面再用 Namespace 等軟多租戶的隔離方式切割，如圖所示

  • 詳細描述如下
  • 2 座 Kubernetes 叢集，分別為 Dev and Staging Cluster 和 Prod Cluster
  • 當中 Dev and Staging Cluster 叢集內，共有 3 個 Kubernets Namespace，分別為 DevTeam1、DevTeam2、Staging
  • 當中 Prod Cluster 叢集內，共有 3 個 Kubernetes Namespace, 分別為 Team1、Team2、Team3

Q6: 用槍時機?

主要判斷點就是 Kubernetes API 可不可以共用和資源隔離性的取捨，換個角度來講，如果單座 Kubernetes 爆炸了，上面的專案你能忍受多少是掛掉的狀態，如果你不能忍受，拆，能忍受，合

下面舉幾個我個人遇過會建議需要建多座的例子：

  1. 不同環境的網路隔離，如 DR / Staging / Dev / Prod //技術上沒得談
  2. Kubernetes 合規性，如 PCI-DSS、HIPPA 等不能於同一座 Kubernetes 混用合規檢測 //技術上沒得談
  3. 不同專案性質，如既有對於資訊系統的法規、核心系統、以 API Gateway 為主的 MASA 設計、共享服務平台 (CI/CD)、GPU 分享、指定 Kubernetes 版本等 //技術上可以，但我個人對於純地端客戶的理解相當不建議
  4. 底層 CPU 架構集不同，如 x86_64、ppc 等 //技術上可以，但我個人判斷相當不建議
  5. 不同部門之間技術落差 / 權限 / 內帳切割議題，如談錢保證傷感情的時候 //技術上可以，但我個人對於純地端客戶的理解相當不建議

上述有些說技術上可以的，建議可以嘗試把小弟的拙作 如何科學地估算 Kubernetes 所需的資源? App 角度篇 看完之後，請所有要住在一起的服務估算一下資源使用量有評估下災害爆炸半徑 (Blast Radius)，前者跟錢有關，後者跟 SLA 有關

最後給張梗圖

Q7: 如果建多座 Kubernetes 不就要耗費很多資源?

個人觀點，Kubernetes 與 Cloud OS 之於 Linux 與 OS 的相對關係

其實把 Kubernetes 當作一個雲原生作業系統 (Cloud OS) 的角度來看，應對不同的專案需求，大家對於 Kubernetes 的資源大小也會有所不同，類同於開發人員要弄一個專案總是要提出說，需要什麼 CPU / Memory / Disk / OS 用哪家的資源申請，這是很合理的，只是 Kubernetes 架構上需要多考量一些事情，所以保有 Kubernetes 叢集資源調整彈性及選擇是架構上需要考量的地方

所以小弟才會提以 2 個方向的角度來協助大家去科學地評估資源，而不是丟骰子的作法，當中一篇已經寫好了，可以參照參照

另外還有一篇大概也就 VMware 才有資格寫的多叢集 Kubernetes 於虛擬化平台之效能報告書 Performance Best Practices for Kubernetes with VMware Tanzu - Performance Study 也可以參考一下，寫得相當靠譜務實

Q8: 如果我就是僅建一座 Kubernetes 裡面服務塞好塞滿可不可以?

可，但要確保對於 Q3: 軟多租戶的邏輯方式隔離手段有哪一些? 所提之邏輯隔離手段，所有參與之上的租戶都要有相同的認知，然後設計該 Kubernetes 叢集的架構師，務必要相當熟悉通盤的網路架構，無論是 Kubernetes 內部或者是外部

References