導讀：如何解決多租戶集群的安全隔離問題是企業上雲的一個關鍵問題，本文主要介紹 Kubernetes 多租戶集群的基本概念和常見應用形態，以及在企業內部共享集群的業務場景下，基於 Kubernetes 原生和 ACK 集群現有安全管理能力快速實現多租戶集群的相關方案。
什麼是多租戶集群？
這裡首先介紹一下"租戶"，租戶的概念不止局限於集群的用戶，它可以包含為一組計算，網絡，存儲等資源組成的工作負載集合。而在多租戶集群中，需要在一個集群範圍內（未來可能會是多集群）對不同的租戶提供儘可能的安全隔離，以最大程度的避免惡意租戶對其他租戶的攻擊，同時需要保證租戶之間公平地分配共享集群資源。
在隔離的安全程度上，我們可以將其分為軟隔離 (Soft Multi-tenancy) 和硬隔離 (Hard Multi-tenancy) 兩種。
- 其中軟隔離更多的是面向企業內部的多租需求，該形態下默認不存在惡意租戶，隔離的目的是為了內部團隊間的業務保護和對可能的安全攻擊進行防護；
- 而硬隔離面向的更多是對外提供服務的服務供應商，由於該業務形態下無法保證不同租戶中業務使用者的安全背景，我們默認認為租戶之間以及租戶與 K8s 系統之間是存在互相攻擊的可能，因此這裡也需要更嚴格的隔離作為安全保障。
關於多租戶的不同應用場景，在下節會有更細緻的介紹。
多租戶應用場景
下面介紹一下典型的兩種企業多租戶應用場景和不同的隔離需求：
企業內部共享集群的多租戶
該場景下集群的所有用戶均來自企業內部，這也是當前很多 K8s 集群客戶的使用模式，因為服務使用者身份的可控性，相對來說這種業務形態的安全風險是相對可控的，畢竟老闆可以直接裁掉不懷好意的員工：）根據企業內部人員結構的複雜程度，我們可以通過命名空間對不同部門或團隊進行資源的邏輯隔離，同時定義以下幾種角色的業務人員：
- 集群管理員：具有集群的管理能力（擴縮容、添加節點等操作）；負責為租戶管理員創建和分配命名空間；負責各類策略（RAM/RBAC/networkpolicy/quota...）的 CRUD；
- 租戶管理員：至少具有集群的 RAM 只讀權限；管理租戶內相關人員的 RBAC 配置；
- 租戶內用戶：在租戶對應命名空間內使用權限範圍內的 K8s 資源。
在建立了基於用戶角色的訪問控制基礎上，我們還需要保證命名空間之間的網絡隔離，在不同的命名空間之間只能夠允許白名單範圍內的跨租戶應用請求。
另外，對於業務安全等級要求較高的應用場景，我們需要限制應用容器的內核能力，可以配合 seccomp / AppArmor / SELinux 等策略工具達到限制容器運行時刻 capabilities 的目的。
當然 Kubernetes 現有的命名空間單層邏輯隔離還不足以滿足一部分大型企業應用複雜業務模型對隔離需求，我們可以關注 Virtual Cluster，它通過抽象出更高級別的租戶資源模型來實現更精細化的多租管理，以此彌補原生命名空間能力上的不足。
SaaS & KaaS 服務模型下的多租戶
在 SaaS 多租場景下， Kubernetes 集群中的租戶對應為 SaaS 平台中各服務應用實例和 SaaS 自身控制平面，該場景下可以將平台各服務應用實例劃分到彼此不同的命名空間中。而服務的最終用戶是無法與 Kubernetes 的控制平面組件進行交互，這些最終用戶能夠看到和使用的是 SaaS 自身控制台，他們通過上層定製化的 SaaS 控制平面使用服務或部署業務（如下左圖所示）。
例如，某博客平台部署在多租戶集群上運行。在該場景下，租戶是每個客戶的博客實例和平台自己的控制平面。平台的控制平面和每個託管博客都將在不同的命名空間中運行。客戶將通過平台的介面來創建和刪除博客、更新博客軟體版本，但無法了解集群的運作方式。
KaaS 多租場景常見於雲服務提供商，該場景下業務平台的服務直接通過 Kubernetes 控制平面暴露給不同租戶下的用戶，最終用戶可以使用 K8s 原生 API 或者服務提供商基於 CRDs/controllers 擴展出的接口。出於隔離的最基本需求，這裡不同租戶也需要通過命名空間進行訪問上的邏輯隔離，同時保證不同租戶間網絡和資源配額上的隔離。
與企業內部共享集群不同，這裡的最終用戶均來自非受信域，他們當中不可避免的存在惡意租戶在服務平台上執行惡意代碼，因此對於 SaaS/KaaS 服務模型下的多租戶集群，我們需要更高標準的安全隔離，而 Kubernetes 現有原生能力還不足以滿足安全上的需求，為此我們需要如安全容器這樣在容器運行時刻內核級別的隔離來強化該業務形態下的租戶安全。
實施多租戶架構
在規劃和實施多租戶集群時，我們首先可以利用的是 Kubernetes 自身的資源隔離層，包括集群本身、命名空間、節點、pod 和容器均是不同層次的資源隔離模型。當不同租戶的應用負載能夠共享相同的資源模型時，就會存在彼此之間的安全隱患。為此，我們需要在實施多租時控制每個租戶能夠訪問到的資源域，同時在資源調度層面儘可能的保證處理敏感信息的容器運行在相對獨立的資源節點內；如果出於資源開銷的角度，當有來自不同租戶的負載共享同一個資源域時，可以通過運行時刻的安全和資源調度控制策略減少跨租戶攻擊的風險。
雖然 Kubernetes 現有安全和調度能力還不足以完全安全地實施多租隔離，但是在如企業內部共享集群這樣的應用場景下，通過命名空間完成租戶間資源域的隔離，同時通過 RBAC、PodSecurityPolicy、NetworkPolicy 等策略模型控制租戶對資源訪問範圍和能力的限制，以及現有資源調度能力的結合，已經可以提供相當的安全隔離能力。而對於 SaaS、KaaS 這樣的服務平台形態，我們可以通過阿里雲容器服務近期推出的安全沙箱容器來實現容器內核級別的隔離，能夠最大程度的避免惡意租戶通過逃逸手段的跨租戶攻擊。
本節重點關注基於 Kubernetes 原生安全能力的多租戶實踐。
訪問控制
AuthN & AuthZ & Admission
ACK 集群的授權分為 RAM 授權和 RBAC 授權兩個步驟，其中 RAM 授權作用於集群管理接口的訪問控制，包括對集群的 CRUD 權限（如集群可見性、擴縮容、添加節點等操作），而 RBAC 授權用於集群內部 Kubernetes 資源模型的訪問控制，可以做到指定資源在命名空間粒度的細化授權。
ACK 授權管理為租戶內用戶提供了不同級別的預置角色模板，同時支持綁定多個用戶自定義的集群角色，此外支持對批量用戶的授權。如需詳細了解 ACK 上集群相關訪問控制授權，請參閱相關幫助文檔。
NetworkPolicy
NetworkPolicy 可以控制不同租戶業務 pod 之間的網絡流量，另外可以通過白名單的方式打開跨租戶之間的業務訪問限制。
您可以在使用了 Terway 網絡插件的容器服務集群上配置 NetworkPolicy，這裡可以獲得一些策略配置的示例。
PodSecurityPolicy
PSP 是 K8s 原生的集群維度的資源模型，它可以在apiserver中pod創建請求的 admission 階段校驗其運行時刻行為是否滿足對應 PSP 策略的約束，比如檢查 pod 是否使用了 host 的網絡、文件系統、指定埠、PID namespace 等，同時可以限制租戶內的用戶開啟特權（privileged）容器，限制掛盤類型，強制只讀掛載等能力；不僅如此，PSP 還可以基於綁定的策略給 pod 添加對應的 SecurityContext，包括容器運行時刻的 uid，gid 和添加或刪除的內核 capabilities 等多種設置。
關於如何開啟 PSP admission 和相關策略及權限綁定的使用，可以參閱這裡。
OPA
OPA（Open Policy Agent）是一種功能強大的策略引擎，支持解耦式的 policy decisions 服務並且社區已經有了相對成熟的與 Kubernetes 的集成方案。當現有 RBAC 在命名空間粒度的隔離不能夠滿足企業應用複雜的安全需求時，可以通過 OPA 提供 object 模型級別的細粒度訪問策略控制。
同時 OPA 支持七層的 NetworkPolicy 策略定義及基於 labels/annotation 的跨命名空間訪問控制，可以作為 K8s 原生 NetworkPolicy 的有效增強。
資源調度相關
Resource Quotas & Limit Range
在多租戶場景下，不同團隊或部門共享集群資源，難免會有資源競爭的情況發生，為此我們需要對每個租戶的資源使用配額做出限制。其中 ResourceQuota 用於限制租戶對應命名空間下所有 pod 占用的總資源 request 和 limit，LimitRange 用來設置租戶對應命名空間中部署 pod 的默認資源 request 和 limit 值。另外我們還可以對租戶的存儲資源配額和對象數量配額進行限制。
關於資源配額的詳細指導可以參見這裡。
Pod Priority/Preemption
從 1.14 版本開始 pod 的優先級和搶占已經從 beta 成為穩定特性，其中 pod priority 標識了 pod 在 pending 狀態的調度隊列中等待的優先級；而當節點資源不足等原因造成高優先的 pod 無法被調度時，scheduler 會嘗試驅逐低優先級的 pod 來保證高優先級 pod 可以被調度部署。
在多租戶場景下，可以通過優先級和搶占設置確保租戶內重要業務應用的可用性；同時 pod priority 可以和 ResouceQuota 配合使用，完成租戶在指定優先級下有多少配額的限制。
Dedicated Nodes
注意：惡意租戶可以規避由節點污點和容忍機制強制執行的策略。以下說明僅用於企業內部受信任租戶集群，或租戶無法直接訪問 Kubernetes 控制平面的集群。
通過對集群中的某些節點添加污點，可以將這些節點用於指定幾個租戶專門使用。在多租戶場景下，例如集群中的 GPU 節點可以通過污點的方式保留給業務應用中需要使用到 GPU 的服務團隊使用。集群管理員可以通過如 effect: "NoSchedule" 這樣的標籤給節點添加污點，同時只有配置了相應容忍設置的 pod 可以被調度到該節點上。
當然惡意租戶可以同樣通過給自身 pod 添加同樣的容忍配置來訪問該節點，因此僅使用節點污點和容忍機制還無法在非受信的多租集群上保證目標節點的獨占性。
關於如何使用節點污點機制來控制調度，請參閱這裡。
敏感信息保護
secrets encryption at REST
在多租戶集群中不同租戶用戶共享同一套 etcd 存儲，在最終用戶可以訪問 Kubernetes 控制平面的場景下，我們需要保護 secrets 中的數據，避免在訪問控制策略配置不當情況下的敏感信息泄露。為此可以參考 K8s 原生的 secret 加密能力，請參閱這裡。
ACK 也提供了基於阿里雲 KMS 服務的 secrets 加密開源解決方案，可以參閱這裡。
總結
在實施多租戶架構時首先需要確定對應的應用場景，包括判斷租戶內用戶和應用負載的可信程度以及對應的安全隔離程度。在此基礎上以下幾點是安全隔離的基本需求：
- 開啟 Kubernetes 集群的默認安全配置：開啟 RBAC 鑒權並實現基於namespace的軟隔離；開啟 secrets encryption 能力，增強敏感信息保護；基於 CIS Kubernetes benchmarks 進行相應的安全配置；
- 開啟 NodeRestriction， AlwaysPullImages, PodSecurityPolicy 等相關 admission controllers；
- 通過 PSP 限制 pod 部署的特權模式，同時控制其運行時刻 SecurityContext；
- 配置 NetworkPolicy；
- 使用Resource Quota & Limit Range限制租戶的資源使用配額；
- 在應用運行時刻遵循權限的最小化原則，儘可能縮小pod內容器的系統權限；
- Log everything；
- 對接監控系統，實現容器應用維度的監控。
而對於如 SaaS、KaaS 等服務模型下，或者我們無法保證租戶內用戶的可信程度時，我們需要採取一些更強有力的隔離手段，比如：
- 使用如 OPA 等動態策略引擎進行網絡或 Object 級別的細粒度訪問控制；
- 使用安全容器實現容器運行時刻內核級別的安全隔離；
- 完備的監控、日誌、存儲等服務的多租隔離方案。
注意：文中圖片來源。
「阿里巴巴雲原生關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的技術圈。」導讀：如何解決多租戶集群的安全隔離問題是企業上雲的一個關鍵問題，本文主要介紹 Kubernetes 多租戶集群的基本概念和常見應用形態，以及在企業內部共享集群的業務場景下，基於 Kubernetes 原生和 ACK 集群現有安全管理能力快速實現多租戶集群的相關方案。
什麼是多租戶集群？
這裡首先介紹一下"租戶"，租戶的概念不止局限於集群的用戶，它可以包含為一組計算，網絡，存儲等資源組成的工作負載集合。而在多租戶集群中，需要在一個集群範圍內（未來可能會是多集群）對不同的租戶提供儘可能的安全隔離，以最大程度的避免惡意租戶對其他租戶的攻擊，同時需要保證租戶之間公平地分配共享集群資源。
在隔離的安全程度上，我們可以將其分為軟隔離 (Soft Multi-tenancy) 和硬隔離 (Hard Multi-tenancy) 兩種。
- 其中軟隔離更多的是面向企業內部的多租需求，該形態下默認不存在惡意租戶，隔離的目的是為了內部團隊間的業務保護和對可能的安全攻擊進行防護；
- 而硬隔離面向的更多是對外提供服務的服務供應商，由於該業務形態下無法保證不同租戶中業務使用者的安全背景，我們默認認為租戶之間以及租戶與 K8s 系統之間是存在互相攻擊的可能，因此這裡也需要更嚴格的隔離作為安全保障。
關於多租戶的不同應用場景，在下節會有更細緻的介紹。
多租戶應用場景
下面介紹一下典型的兩種企業多租戶應用場景和不同的隔離需求：
企業內部共享集群的多租戶
該場景下集群的所有用戶均來自企業內部，這也是當前很多 K8s 集群客戶的使用模式，因為服務使用者身份的可控性，相對來說這種業務形態的安全風險是相對可控的，畢竟老闆可以直接裁掉不懷好意的員工：）根據企業內部人員結構的複雜程度，我們可以通過命名空間對不同部門或團隊進行資源的邏輯隔離，同時定義以下幾種角色的業務人員：
- 集群管理員：具有集群的管理能力（擴縮容、添加節點等操作）；負責為租戶管理員創建和分配命名空間；負責各類策略（RAM/RBAC/networkpolicy/quota...）的 CRUD；
- 租戶管理員：至少具有集群的 RAM 只讀權限；管理租戶內相關人員的 RBAC 配置；
- 租戶內用戶：在租戶對應命名空間內使用權限範圍內的 K8s 資源。
在建立了基於用戶角色的訪問控制基礎上，我們還需要保證命名空間之間的網絡隔離，在不同的命名空間之間只能夠允許白名單範圍內的跨租戶應用請求。
另外，對於業務安全等級要求較高的應用場景，我們需要限制應用容器的內核能力，可以配合 seccomp / AppArmor / SELinux 等策略工具達到限制容器運行時刻 capabilities 的目的。
當然 Kubernetes 現有的命名空間單層邏輯隔離還不足以滿足一部分大型企業應用複雜業務模型對隔離需求，我們可以關注 Virtual Cluster，它通過抽象出更高級別的租戶資源模型來實現更精細化的多租管理，以此彌補原生命名空間能力上的不足。
SaaS & KaaS 服務模型下的多租戶
在 SaaS 多租場景下， Kubernetes 集群中的租戶對應為 SaaS 平台中各服務應用實例和 SaaS 自身控制平面，該場景下可以將平台各服務應用實例劃分到彼此不同的命名空間中。而服務的最終用戶是無法與 Kubernetes 的控制平面組件進行交互，這些最終用戶能夠看到和使用的是 SaaS 自身控制台，他們通過上層定製化的 SaaS 控制平面使用服務或部署業務（如下左圖所示）。
例如，某博客平台部署在多租戶集群上運行。在該場景下，租戶是每個客戶的博客實例和平台自己的控制平面。平台的控制平面和每個託管博客都將在不同的命名空間中運行。客戶將通過平台的介面來創建和刪除博客、更新博客軟體版本，但無法了解集群的運作方式。
KaaS 多租場景常見於雲服務提供商，該場景下業務平台的服務直接通過 Kubernetes 控制平面暴露給不同租戶下的用戶，最終用戶可以使用 K8s 原生 API 或者服務提供商基於 CRDs/controllers 擴展出的接口。出於隔離的最基本需求，這裡不同租戶也需要通過命名空間進行訪問上的邏輯隔離，同時保證不同租戶間網絡和資源配額上的隔離。
與企業內部共享集群不同，這裡的最終用戶均來自非受信域，他們當中不可避免的存在惡意租戶在服務平台上執行惡意代碼，因此對於 SaaS/KaaS 服務模型下的多租戶集群，我們需要更高標準的安全隔離，而 Kubernetes 現有原生能力還不足以滿足安全上的需求，為此我們需要如安全容器這樣在容器運行時刻內核級別的隔離來強化該業務形態下的租戶安全。
實施多租戶架構
在規劃和實施多租戶集群時，我們首先可以利用的是 Kubernetes 自身的資源隔離層，包括集群本身、命名空間、節點、pod 和容器均是不同層次的資源隔離模型。當不同租戶的應用負載能夠共享相同的資源模型時，就會存在彼此之間的安全隱患。為此，我們需要在實施多租時控制每個租戶能夠訪問到的資源域，同時在資源調度層面儘可能的保證處理敏感信息的容器運行在相對獨立的資源節點內；如果出於資源開銷的角度，當有來自不同租戶的負載共享同一個資源域時，可以通過運行時刻的安全和資源調度控制策略減少跨租戶攻擊的風險。
雖然 Kubernetes 現有安全和調度能力還不足以完全安全地實施多租隔離，但是在如企業內部共享集群這樣的應用場景下，通過命名空間完成租戶間資源域的隔離，同時通過 RBAC、PodSecurityPolicy、NetworkPolicy 等策略模型控制租戶對資源訪問範圍和能力的限制，以及現有資源調度能力的結合，已經可以提供相當的安全隔離能力。而對於 SaaS、KaaS 這樣的服務平台形態，我們可以通過阿里雲容器服務近期推出的安全沙箱容器來實現容器內核級別的隔離，能夠最大程度的避免惡意租戶通過逃逸手段的跨租戶攻擊。
本節重點關注基於 Kubernetes 原生安全能力的多租戶實踐。
訪問控制
AuthN & AuthZ & Admission
ACK 集群的授權分為 RAM 授權和 RBAC 授權兩個步驟，其中 RAM 授權作用於集群管理接口的訪問控制，包括對集群的 CRUD 權限（如集群可見性、擴縮容、添加節點等操作），而 RBAC 授權用於集群內部 Kubernetes 資源模型的訪問控制，可以做到指定資源在命名空間粒度的細化授權。
ACK 授權管理為租戶內用戶提供了不同級別的預置角色模板，同時支持綁定多個用戶自定義的集群角色，此外支持對批量用戶的授權。如需詳細了解 ACK 上集群相關訪問控制授權，請參閱相關幫助文檔。
NetworkPolicy
NetworkPolicy 可以控制不同租戶業務 pod 之間的網絡流量，另外可以通過白名單的方式打開跨租戶之間的業務訪問限制。
您可以在使用了 Terway 網絡插件的容器服務集群上配置 NetworkPolicy，這裡可以獲得一些策略配置的示例。
PodSecurityPolicy
PSP 是 K8s 原生的集群維度的資源模型，它可以在apiserver中pod創建請求的 admission 階段校驗其運行時刻行為是否滿足對應 PSP 策略的約束，比如檢查 pod 是否使用了 host 的網絡、文件系統、指定埠、PID namespace 等，同時可以限制租戶內的用戶開啟特權（privileged）容器，限制掛盤類型，強制只讀掛載等能力；不僅如此，PSP 還可以基於綁定的策略給 pod 添加對應的 SecurityContext，包括容器運行時刻的 uid，gid 和添加或刪除的內核 capabilities 等多種設置。
關於如何開啟 PSP admission 和相關策略及權限綁定的使用，可以參閱這裡。
OPA
OPA（Open Policy Agent）是一種功能強大的策略引擎，支持解耦式的 policy decisions 服務並且社區已經有了相對成熟的與 Kubernetes 的集成方案。當現有 RBAC 在命名空間粒度的隔離不能夠滿足企業應用複雜的安全需求時，可以通過 OPA 提供 object 模型級別的細粒度訪問策略控制。
同時 OPA 支持七層的 NetworkPolicy 策略定義及基於 labels/annotation 的跨命名空間訪問控制，可以作為 K8s 原生 NetworkPolicy 的有效增強。
資源調度相關
Resource Quotas & Limit Range
在多租戶場景下，不同團隊或部門共享集群資源，難免會有資源競爭的情況發生，為此我們需要對每個租戶的資源使用配額做出限制。其中 ResourceQuota 用於限制租戶對應命名空間下所有 pod 占用的總資源 request 和 limit，LimitRange 用來設置租戶對應命名空間中部署 pod 的默認資源 request 和 limit 值。另外我們還可以對租戶的存儲資源配額和對象數量配額進行限制。
關於資源配額的詳細指導可以參見這裡。
Pod Priority/Preemption
從 1.14 版本開始 pod 的優先級和搶占已經從 beta 成為穩定特性，其中 pod priority 標識了 pod 在 pending 狀態的調度隊列中等待的優先級；而當節點資源不足等原因造成高優先的 pod 無法被調度時，scheduler 會嘗試驅逐低優先級的 pod 來保證高優先級 pod 可以被調度部署。
在多租戶場景下，可以通過優先級和搶占設置確保租戶內重要業務應用的可用性；同時 pod priority 可以和 ResouceQuota 配合使用，完成租戶在指定優先級下有多少配額的限制。
Dedicated Nodes
注意：惡意租戶可以規避由節點污點和容忍機制強制執行的策略。以下說明僅用於企業內部受信任租戶集群，或租戶無法直接訪問 Kubernetes 控制平面的集群。
通過對集群中的某些節點添加污點，可以將這些節點用於指定幾個租戶專門使用。在多租戶場景下，例如集群中的 GPU 節點可以通過污點的方式保留給業務應用中需要使用到 GPU 的服務團隊使用。集群管理員可以通過如 effect: "NoSchedule" 這樣的標籤給節點添加污點，同時只有配置了相應容忍設置的 pod 可以被調度到該節點上。
當然惡意租戶可以同樣通過給自身 pod 添加同樣的容忍配置來訪問該節點，因此僅使用節點污點和容忍機制還無法在非受信的多租集群上保證目標節點的獨占性。
關於如何使用節點污點機制來控制調度，請參閱這裡。
敏感信息保護
secrets encryption at REST
在多租戶集群中不同租戶用戶共享同一套 etcd 存儲，在最終用戶可以訪問 Kubernetes 控制平面的場景下，我們需要保護 secrets 中的數據，避免在訪問控制策略配置不當情況下的敏感信息泄露。為此可以參考 K8s 原生的 secret 加密能力，請參閱這裡。
ACK 也提供了基於阿里雲 KMS 服務的 secrets 加密開源解決方案，可以參閱這裡。
總結
在實施多租戶架構時首先需要確定對應的應用場景，包括判斷租戶內用戶和應用負載的可信程度以及對應的安全隔離程度。在此基礎上以下幾點是安全隔離的基本需求：
- 開啟 Kubernetes 集群的默認安全配置：開啟 RBAC 鑒權並實現基於namespace的軟隔離；開啟 secrets encryption 能力，增強敏感信息保護；基於 CIS Kubernetes benchmarks 進行相應的安全配置；
- 開啟 NodeRestriction， AlwaysPullImages, PodSecurityPolicy 等相關 admission controllers；
- 通過 PSP 限制 pod 部署的特權模式，同時控制其運行時刻 SecurityContext；
- 配置 NetworkPolicy；
- 使用Resource Quota & Limit Range限制租戶的資源使用配額；
- 在應用運行時刻遵循權限的最小化原則，儘可能縮小pod內容器的系統權限；
- Log everything；
- 對接監控系統，實現容器應用維度的監控。
而對於如 SaaS、KaaS 等服務模型下，或者我們無法保證租戶內用戶的可信程度時，我們需要採取一些更強有力的隔離手段，比如：
- 使用如 OPA 等動態策略引擎進行網絡或 Object 級別的細粒度訪問控制；
- 使用安全容器實現容器運行時刻內核級別的安全隔離；
- 完備的監控、日誌、存儲等服務的多租隔離方案。
注意：文中圖片來源。
「阿里巴巴雲原生關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的技術圈。」
作者： 匡大虎