Part 1: 認命吧!有一好,就沒兩好! 軟多租戶 Soft Multi-Tenancy 硬多租戶 Hard Multi-Tenancy 單租戶 Single-Tenancy 租戶系統邊界 Kubernetes Namespace Kubernetes Cluster / Cloud Provider Kubernetes Cluster 隔離性 邏輯隔離 (共用 Kubernetes API) 主管叢集:邏輯隔離 (共用 Kubernetes API) 租戶叢集:實體隔離 (不共用 Kubernetes API) 實體隔離 (不共用 Kubernetes API) 4C’s Security Code / Container Code / Container / Cluster / Cloud Cluster / Cloud Network 重視東西向 Network Policy 的設計 重視南北向 Ingress 的設計 重視南北向 Ingress 的設計 Resource Management Ops 採 Resource Quotas 限制特定 Namespace 資源用量 Ops 採 VM 為主的估算, 限定 Cluster 資源用量 Ops 採 VM 為主的估算, 限定 Cluster 資源用量 白話文 Ops 建立單一 Kubernetes 塞全部 App 部門人在裡面 Ops 先建立主管叢集之後 再對個 App 部門發 Kubernetes 每個 App 部門自建一座 Kubernetes • 首先,多租戶跟單租戶在架構設計上是可以單獨使用或同時使用,廣義來說相互都兼具能力 • 其次,多租戶還有分 2 個: ◦ Soft Multi-Tenancy:最常見,以 Namespace 作為系統界線,CNCF CKA/CKAD 考試都是考基於這個的操作 ◦ Hard Multi-Tenancy:乙方 Infra Provider 會出現的設計,以一座主管叢集為核心,上面再長 Kubernetes 作為系 統邊界,後者長出來的 Kubernetes 也包含 Soft Multi-Tenancy 的能力,如 Managed Cluster 服務都算是 • 結論,反正就是你起碼會有一座 Kubernetes ,然後討論 Kubernetes API 要不要共用就對了 • 下表論述以 地端 Ops 維運人員角度為主 21