기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
테넌트 격리
다중 테넌시를 생각할 때 종종 공유 인프라에서 실행되는 다른 사용자 또는 애플리케이션과 사용자 또는 애플리케이션을 격리하려고 합니다.
Kubernetes는 단일 테넌트 오케스트레이터입니다. 즉, 컨트롤 플레인의 단일 인스턴스가 클러스터 내의 모든 테넌트 간에 공유됩니다. 그러나 다중 테넌시의 스모블링을 생성하는 데 사용할 수 있는 다양한 Kubernetes 객체가 있습니다. 예를 들어 네임스페이스와 역할 기반 액세스 제어(RBAC)를 구현하여 테넌트를 서로 논리적으로 격리할 수 있습니다. 마찬가지로 할당량 및 제한 범위를 사용하여 각 테넌트가 사용할 수 있는 클러스터 리소스의 양을 제어할 수 있습니다. 그럼에도 불구하고 클러스터는 강력한 보안 경계를 제공하는 유일한 구문입니다. 이는 클러스터 내의 호스트에 액세스하기 위해를 관리하는 공격자가 해당 호스트에 탑재된 모든 보안 암호, ConfigMaps 및 볼륨을 검색할 수 있기 때문입니다. 또한 Kubelet을 가장하여 노드의 속성을 조작하거나 클러스터 내에서 측면으로 이동할 수 있습니다.
다음 섹션에서는 Kubernetes와 같은 단일 테넌트 오케스트레이터 사용의 위험을 완화하면서 테넌트 격리를 구현하는 방법을 설명합니다.
소프트 멀티테넌시
소프트 멀티테넌시에서는 네임스페이스, 역할 및 역할 바인딩, 네트워크 정책과 같은 네이티브 Kubernetes 구문을 사용하여 테넌트 간에 논리적 분리를 생성합니다. 예를 들어 RBAC는 테넌트가 서로의 리소스에 액세스하거나 조작하지 못하도록 할 수 있습니다. 할당량 및 제한 범위는 각 테넌트가 사용할 수 있는 클러스터 리소스의 양을 제어하는 반면, 네트워크 정책은 서로 다른 네임스페이스에 배포된 애플리케이션이 서로 통신하는 것을 방지하는 데 도움이 될 수 있습니다.
그러나 이러한 제어 중 어느 것도 서로 다른 테넌트의 포드가 노드를 공유하는 것을 방지하지 않습니다. 더 강력한 격리가 필요한 경우 노드 선택기, 친화 방지 규칙 및/또는 테인트 및 허용치를 사용하여 여러 테넌트의 포드를 별도의 노드로 강제 예약할 수 있습니다. 이를 종종 유일한 테넌트 노드라고 합니다. 테넌트가 많은 환경에서는 다소 복잡하고 비용이 많이 들 수 있습니다.
중요
네임스페이스로 구현된 소프트 다중 테넌시는 네임스페이스가 전역적으로 범위가 지정된 유형이므로 테넌트에게 필터링된 네임스페이스 목록을 제공할 수 없습니다. 테넌트가 특정 네임스페이스를 볼 수 있는 경우 클러스터 내의 모든 네임스페이스를 볼 수 있습니다.
주의
soft-multi-tenancy를 사용하면 테넌트는 기본적으로 클러스터 내에서 실행되는 모든 서비스에 대해 CoreDNS를 쿼리할 수 있는 기능을 유지합니다. 공격자는 클러스터의 모든 포드 ..svc.cluster.local에서 dig SRV를 실행하여 이를 악용할 수 있습니다. 클러스터 내에서 실행되는 서비스의 DNS 레코드에 대한 액세스를 제한해야 하는 경우 CoreDNS용 방화벽 또는 정책 플러그인을 사용하는 것이 좋습니다. 자세한 내용은 https://github.com/coredns/policy#kubernetes-metadata-multi-tenancy-policy
Kiosk
-
공유 Kubernetes 클러스터에서 테넌트를 분리할 계정 및 계정 사용자
-
계정 사용자를 위한 셀프 서비스 네임스페이스 프로비저닝
-
클러스터를 공유할 때 서비스 품질과 공정성을 보장하기 위한 계정 제한
-
안전한 테넌트 격리 및 셀프 서비스 네임스페이스 초기화를 위한 네임스페이스 템플릿
Loft
-
여러 클러스터의 스페이스에 대한 액세스 권한을 부여하기 위한 다중 클러스터 액세스
-
절전 모드는 비활성 기간 동안 스페이스의 배포를 축소합니다.
-
GitHub와 같은 OIDC 인증 공급자를 사용한 Single Sign-On
소프트 멀티테넌시로 해결할 수 있는 세 가지 주요 사용 사례가 있습니다.
엔터프라이즈 설정
첫 번째는 "테넌트"가 직원, 계약업체이거나 조직의 승인을 받았다는 점에서 "테넌트"가 반신뢰되는 엔터프라이즈 설정입니다. 각 테넌트는 일반적으로 부서 또는 팀과 같은 관리 부서에 맞춰집니다.
이러한 유형의 설정에서 클러스터 관리자는 일반적으로 네임스페이스를 생성하고 정책을 관리할 책임이 있습니다. 또한 특정 개인이 네임스페이스를 감독하는 위임된 관리 모델을 구현하여 배포, 서비스, 포드, 작업 등과 같은 정책이 아닌 관련 객체에 대해 CRUD 작업을 수행할 수 있습니다.
컨테이너 런타임에서 제공하는 격리는이 설정 내에서 허용 가능하거나 포드 보안을 위한 추가 제어로 강화해야 할 수 있습니다. 더 엄격한 격리가 필요한 경우 다른 네임스페이스의 서비스 간 통신을 제한해야 할 수도 있습니다.
서비스형 Kubernetes
반대로 소프트 멀티테넌시는 Kubernetes를 서비스형(KaaS)으로 제공하려는 설정에서 사용할 수 있습니다. KaaS를 사용하면 애플리케이션이 PaaS 서비스 세트를 제공하는 컨트롤러 및 CRDs 모음과 함께 공유 클러스터에서 호스팅됩니다. 테넌트는 Kubernetes API 서버와 직접 상호 작용하며 정책이 아닌 객체에 대해 CRUD 작업을 수행할 수 있습니다. 테넌트가 자체 네임스페이스를 생성하고 관리하도록 허용될 수 있다는 셀프 서비스 요소도 있습니다. 이러한 유형의 환경에서 테넌트는 신뢰할 수 없는 코드를 실행하는 것으로 간주됩니다.
이러한 유형의 환경에서 테넌트를 격리하려면 포드 샌드박싱뿐만 아니라 엄격한 네트워크 정책을 구현해야 할 수 있습니다. 샌드박싱은 Firecracker와 같은 마이크로 VM 내부 또는 사용자 공간 커널에서 포드의 컨테이너를 실행하는 곳입니다. 현재 EKS Fargate를 사용하여 샌드박스 포드를 생성할 수 있습니다.
서비스형 소프트웨어(SaaS)
소프트 멀티테넌시의 최종 사용 사례는 Software-as-a-Service(SaaS) 설정입니다. 이 환경에서 각 테넌트는 클러스터 내에서 실행 중인 애플리케이션의 특정 인스턴스와 연결됩니다. 각 인스턴스에는 종종 자체 데이터가 있으며 일반적으로 Kubernetes RBAC와 독립적인 별도의 액세스 제어를 사용합니다.
다른 사용 사례와 달리 SaaS 설정의 테넌트는 Kubernetes API와 직접 인터페이스하지 않습니다. 대신 SaaS 애플리케이션은 Kubernetes API와 인터페이스하여 각 테넌트를 지원하는 데 필요한 객체를 생성할 책임이 있습니다.
Kubernetes 구문
이러한 각 인스턴스에서 다음 구문은 테넌트를 서로 격리하는 데 사용됩니다.
네임스페이스
네임스페이스는 소프트 멀티테넌시 구현의 기본입니다. 이를 통해 클러스터를 논리적 파티션으로 나눌 수 있습니다. 다중 테넌시를 구현하는 데 필요한 할당량, 네트워크 정책, 서비스 계정 및 기타 객체는 네임스페이스로 범위가 지정됩니다.
네트워크 정책
기본적으로 Kubernetes 클러스터의 모든 포드는 서로 통신할 수 있습니다. 이 동작은 네트워크 정책을 사용하여 변경할 수 있습니다.
네트워크 정책은 레이블 또는 IP 주소 범위를 사용하여 포드 간의 통신을 제한합니다. 테넌트 간에 엄격한 네트워크 격리가 필요한 다중 테넌트 환경에서는 포드 간의 통신을 거부하는 기본 규칙과 모든 포드가 이름 확인을 위해 DNS 서버를 쿼리하도록 허용하는 다른 규칙으로 시작하는 것이 좋습니다. 이를 통해 네임스페이스 내에서 통신을 허용하는 더 허용적인 규칙을 추가할 수 있습니다. 필요에 따라 이를 더욱 개선할 수 있습니다.
참고
Amazon VPC CNI는 이제 Kubernetes 네트워크 정책을 지원
중요
네트워크 정책은 필요하지만 충분하지 않습니다. 네트워크 정책을 적용하려면 Calico 또는 Cilium과 같은 정책 엔진이 필요합니다.
역할 기반 액세스 제어(RBAC)
역할 및 역할 바인딩은 Kubernetes에서 역할 기반 액세스 제어(RBAC)를 적용하는 데 사용되는 Kubernetes 객체입니다. 역할에는 클러스터의 객체에 대해 수행할 수 있는 작업 목록이 포함됩니다. 역할 바인딩은 역할이 적용되는 개인 또는 그룹을 지정합니다. 엔터프라이즈 및 KaaS 설정에서 RBAC를 사용하여 선택한 그룹 또는 개인이 객체를 관리할 수 있습니다.
할당량
할당량은 클러스터에서 호스팅되는 워크로드에 대한 제한을 정의하는 데 사용됩니다. 할당량을 사용하면 포드가 사용할 수 있는 최대 CPU 및 메모리 양을 지정하거나 클러스터 또는 네임스페이스에 할당할 수 있는 리소스 수를 제한할 수 있습니다. 제한 범위를 사용하면 각 제한에 대한 최소값, 최대값 및 기본값을 선언할 수 있습니다.
공유 클러스터에서 리소스를 과도하게 커밋하면 리소스를 최대화할 수 있기 때문에 종종 유용합니다. 그러나 클러스터에 대한 무제한 액세스로 인해 리소스 부족이 발생하여 성능이 저하되고 애플리케이션 가용성이 손실될 수 있습니다. 포드의 요청이 너무 낮게 설정되고 실제 리소스 사용률이 노드 용량을 초과하는 경우 노드에 CPU 또는 메모리 압력이 발생하기 시작합니다. 이 경우 포드가 다시 시작되거나 노드에서 제거될 수 있습니다.
이를 방지하려면 클러스터에서 포드를 예약할 때 테넌트가 요청 및 제한을 지정하도록 강제하는 다중 테넌트 환경의 네임스페이스에 할당량을 적용할 계획을 세워야 합니다. 또한 포드가 사용할 수 있는 리소스의 양을 제한하여 잠재적인 서비스 거부를 완화할 수 있습니다.
할당량을 사용하여 테넌트의 지출에 맞게 클러스터의 리소스를 할당할 수도 있습니다. 이는 KaaS 시나리오에서 특히 유용합니다.
포드 우선 순위 및 선점
포드 우선 순위 및 선점은 다른 포드에 비해 포드에 더 중요한 역할을 하려는 경우에 유용할 수 있습니다. 예를 들어 포드 우선 순위를 사용하면 고객 B보다 높은 우선 순위로 실행되도록 고객 A의 포드를 구성할 수 있습니다. 사용 가능한 용량이 충분하지 않으면 스케줄러는 고객 B의 우선 순위가 낮은 포드를 제거하여 고객 A의 우선 순위가 높은 포드를 수용합니다. 이는 고객이 프리미엄 요금을 지불하려는 SaaS 환경에서 특히 유용할 수 있습니다.
중요
포드 우선 순위는 우선 순위가 낮은 다른 포드에 원치 않는 영향을 미칠 수 있습니다. 예를 들어, 피해자 포드는 정상적으로 종료되지만 PodDisruptionBudget는 보장되지 않으므로 포드 쿼럼에 의존하는 우선 순위가 낮은 애플리케이션이 중단될 수 있지만 선점 제한을 참조하세요
제어 완화
다중 테넌트 환경의 관리자로서 주요 관심사는 공격자가 기본 호스트에 액세스할 수 없도록 하는 것입니다. 이 위험을 완화하려면 다음 제어를 고려해야 합니다.
컨테이너용 샌드박스 실행 환경
샌드박싱은 각 컨테이너가 자체 격리된 가상 머신에서 실행되는 기법입니다. 포드 샌드박싱을 수행하는 기술에는 Firecracker
Firecracker를 EKS에 지원되는 런타임으로 만들기 위한 노력에 대한 자세한 내용은 https://threadreaderapp.com/thread/1238496944684597248.html
정책 에이전트(OPA) 및 게이트키퍼 열기
Gatekeeper
또한 CoreDNS에 대한 실험적 OPA 플러그인
키버노
Kyverno
Kyverno를 사용하여 네임스페이스를 격리하고, 포드 보안 및 기타 모범 사례를 적용하고, 네트워크 정책과 같은 기본 구성을 생성할 수 있습니다. 이 프로젝트의 GitHub 리포지토리
테넌트 워크로드를 특정 노드로 격리
테넌트 워크로드가 특정 노드에서 실행되도록 제한하면 소프트 멀티테넌시 모델에서 격리를 강화하는 데 사용할 수 있습니다. 이 접근 방식을 사용하면 테넌트별 워크로드는 각 테넌트에 대해 프로비저닝된 노드에서만 실행됩니다. 이러한 격리를 달성하기 위해 네이티브 Kubernetes 속성(노드 선호도, 테인트 및 허용치)을 사용하여 포드 예약을 위한 특정 노드를 대상으로 지정하고 다른 테넌트의 포드가 테넌트별 노드에 예약되지 않도록 합니다.
1부 - 노드 선호도
Kubernetes 노드 선호requiredDuringSchedulingIgnoredDuringExecution 노드 선호도가 각 포드에 적용됩니다. 결과적으로 포드는 키/값으로 레이블이 지정된 노드를 대상으로 합니다node-restriction.kubernetes.io/tenant: tenants-x.
... spec: affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: node-restriction.kubernetes.io/tenant operator: In values: - tenants-x ...
이 노드 선호도를 사용하면 레이블이 예약 중에는 필요하지만 실행 중에는 필요하지 않습니다. 기본 노드의 레이블이 변경되면 해당 레이블 변경으로 인해 포드가 제거되지 않습니다. 그러나 향후 일정이 영향을 받을 수 있습니다.
주의
의 레이블 접두사는 Kubernetes에서 특별한 의미를 node-restriction.kubernetes.io/ 갖습니다. EKS 클러스터에 대해 활성화된 NodeRestrictionkubelet가이 접두사를 사용하여 레이블을 adding/removing/updating 방지합니다. 는 이러한 레이블을 수정할 수 kubelet’s credentials to update the node object or modify the system setup to pass these labels into `kubelet 없으므로 공격자kubelet는를 사용할 수 없습니다. 이 접두사를 모든 포드에서 노드로 예약하는 데 사용하는 경우 공격자가 노드 레이블을 수정하여 노드로 다른 워크로드 세트를 유치하려는 시나리오를 방지합니다.
노드 선호도 대신 노드 선택기
2부 - 테인트 및 허용치
포드를 노드로 끌어들이는 것은이 세 부분으로 구성된 접근 방식의 첫 번째 부분일 뿐입니다. 이 접근 방식이 작동하려면 포드가 승인되지 않은 노드로 포드가 예약되지 않도록 해야 합니다. 원치 않거나 승인되지 않은 포드를 제거하기 위해 Kubernetes는 노드 테인트tenant: tenants-x.
... taints: - key: tenant value: tenants-x effect: NoSchedule ...
위의 노드를 고려할 때 테인트를 허용하는 포드taint만 노드에서 예약할 수 있습니다. 승인된 포드를 노드에 예약하려면 아래 표시된 대로 각 포드 사양에 테인트에 toleration 대한가 포함되어야 합니다.
... tolerations: - effect: NoSchedule key: tenant operator: Equal value: tenants-x ...
위와 같은 포드toleration는 최소한 특정 테인트 때문에 노드에서 예약이 중지되지 않습니다. 또한 Kubernetes는 테인트를 사용하여 노드 리소스 압력과 같은 특정 조건에서 포드 예약을 일시적으로 중지합니다. 노드 선호도, 테인트 및 허용 오차를 사용하면 원하는 포드를 특정 노드로 효과적으로 유치하고 원치 않는 포드를 제거할 수 있습니다.
중요
특정 Kubernetes 포드는 모든 노드에서 실행해야 합니다. 이러한 포드의 예로는 컨테이너 네트워크 인터페이스(CNI)
3부 - 노드 선택을 위한 정책 기반 관리
CICD 파이프라인에서 규칙 적용을 포함하여 포드 사양의 노드 선호도 및 허용 오차를 관리하는 데 사용할 수 있는 몇 가지 도구가 있습니다. 그러나 격리 적용은 Kubernetes 클러스터 수준에서도 수행해야 합니다. 이를 위해 정책 관리 도구를 사용하여 요청 페이로드를 기반으로 인바운드 Kubernetes API 서버 요청을 변경하여 위에서 언급한 각 노드 선호도 규칙 및 허용치를 적용할 수 있습니다.
예를 들어 테넌트-x 네임스페이스로 향하는 포드에는 테넌트-x 노드에 대한 예약을 허용하는 올바른 노드 선호도 및 허용 오차를 찍을 수 있습니다. Kubernetes Mutating Admission Webhook
apiVersion: mutations.gatekeeper.sh/v1alpha1 kind: Assign metadata: name: mutator-add-nodeaffinity-pod annotations: aws-eks-best-practices/description: >- Adds Node affinity - https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#node-affinity spec: applyTo: - groups: [""] kinds: ["Pod"] versions: ["v1"] match: namespaces: ["tenants-x"] location: "spec.affinity.nodeAffinity.requiredDuringSchedulingIgnoredDuringExecution.nodeSelectorTerms" parameters: assign: value: - matchExpressions: - key: "tenant" operator: In values: - "tenants-x"
위 정책은 Kubernetes API 서버 요청에 적용되어 테넌트-x 네임스페이스에 포드를 적용합니다. 이 정책은 requiredDuringSchedulingIgnoredDuringExecution 노드 선호도 규칙을 추가하여 포드가 tenant: tenants-x 레이블이 있는 노드로 유인되도록 합니다.
아래에 표시된 두 번째 정책은 대상 네임스페이스 및 그룹, 종류 및 버전과 동일한 일치 기준을 사용하여 동일한 포드 사양에 허용치를 추가합니다.
apiVersion: mutations.gatekeeper.sh/v1alpha1 kind: Assign metadata: name: mutator-add-toleration-pod annotations: aws-eks-best-practices/description: >- Adds toleration - https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/ spec: applyTo: - groups: [""] kinds: ["Pod"] versions: ["v1"] match: namespaces: ["tenants-x"] location: "spec.tolerations" parameters: assign: value: - key: "tenant" operator: "Equal" value: "tenants-x" effect: "NoSchedule"
위의 정책은 포드에 고유합니다. 이는 정책 요소의 변형 location 요소 경로 때문입니다. 배포 및 작업 리소스와 같이 포드를 생성하는 리소스를 처리하기 위해 추가 정책을 작성할 수 있습니다. 나열된 정책 및 기타 예제는이 가이드의 동반 GitHub 프로젝트
이 두 변형의 결과는 포드가 원하는 노드로 끌리는 동시에 특정 노드 테인트에 의해 제거되지 않기 때문입니다. 이를 확인하기 위해 두 kubectl 호출의 출력 조각을 확인하여 로 레이블이 지정된 노드를 가져오tenant=tenants-x고 네tenants-x임스페이스에서 포드를 가져올 수 있습니다.
kubectl get nodes -l tenant=tenants-x NAME ip-10-0-11-255... ip-10-0-28-81... ip-10-0-43-107... kubectl -n tenants-x get pods -owide NAME READY STATUS RESTARTS AGE IP NODE tenant-test-deploy-58b895ff87-2q7xw 1/1 Running 0 13s 10.0.42.143 ip-10-0-43-107... tenant-test-deploy-58b895ff87-9b6hg 1/1 Running 0 13s 10.0.18.145 ip-10-0-28-81... tenant-test-deploy-58b895ff87-nxvw5 1/1 Running 0 13s 10.0.30.117 ip-10-0-28-81... tenant-test-deploy-58b895ff87-vw796 1/1 Running 0 13s 10.0.3.113 ip-10-0-11-255... tenant-test-pod 1/1 Running 0 13s 10.0.35.83 ip-10-0-43-107...
위 출력에서 볼 수 있듯이 모든 포드는 레이블이 지정된 노드에 예약됩니다tenant=tenants-x. 간단히 말해서 포드는 원하는 노드에서만 실행되고 다른 포드(필요한 선호도 및 허용 오차 없음)는 실행되지 않습니다. 테넌트 워크로드는 효과적으로 격리됩니다.
다음은 변형 포드 사양의 예입니다.
apiVersion: v1 kind: Pod metadata: name: tenant-test-pod namespace: tenants-x spec: affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: tenant operator: In values: - tenants-x ... tolerations: - effect: NoSchedule key: tenant operator: Equal value: tenants-x ...
중요
변경 및 검증 승인 웹후크를 사용하여 Kubernetes API 서버 요청 흐름에 통합된 정책 관리 도구는 지정된 기간 내에 API 서버의 요청에 응답하도록 설계되었습니다. 일반적으로 3초 이하입니다. 웹후크 호출이 구성된 시간 내에 응답을 반환하지 못하면 인바운드 API 서버 요청의 변형 및/또는 검증이 발생하거나 발생하지 않을 수 있습니다. 이 동작은 승인 웹후크 구성이 Fail Open 또는 Fail Close
위 예제에서는 OPA/Gatekeeper에 대해 작성된 정책을 사용했습니다. 그러나 노드 선택 사용 사례를 처리하는 다른 정책 관리 도구도 있습니다. 예를 들어이 Kyverno 정책을
참고
올바르게 작동하는 경우 정책을 변경하면 인바운드 API 서버 요청 페이로드에 원하는 변경 사항이 적용됩니다. 그러나 변경 사항이 지속되기 전에 원하는 변경 사항이 발생하는지 확인하기 위해 검증 정책도 포함되어야 합니다. 이는 tenant-to-node 격리에 이러한 정책을 사용할 때 특히 중요합니다. 또한 감사 정책을 포함하여 클러스터에 원치 않는 구성이 있는지 정기적으로 확인하는 것이 좋습니다.
참조
-
k-rail
특정 정책의 적용을 통해 다중 테넌트 환경을 보호하는 데 도움이 되도록 설계되었습니다.
하드 멀티테넌시
하드 멀티테넌시는 각 테넌트에 대해 별도의 클러스터를 프로비저닝하여 구현할 수 있습니다. 이는 테넌트 간에 매우 강력한 격리를 제공하지만 몇 가지 단점이 있습니다.
먼저 테넌트가 많은 경우이 접근 방식은 빠르게 비용이 많이 들 수 있습니다. 각 클러스터의 컨트롤 플레인 비용을 지불해야 할 뿐만 아니라 클러스터 간에 컴퓨팅 리소스를 공유할 수 없습니다. 이로 인해 결국 클러스터의 하위 집합이 제대로 사용되지 않는 반면 다른 하위 집합은 과도하게 사용되는 조각화가 발생합니다.
둘째, 이러한 모든 클러스터를 관리하기 위해 특수 도구를 구매하거나 구축해야 할 수 있습니다. 시간이 지나면 수백 또는 수천 개의 클러스터를 관리하는 것이 너무 불안정해질 수 있습니다.
마지막으로, 테넌트당 클러스터 생성은 네임스페이스 생성에 비해 느려집니다. 그러나 엄격한 테넌시 접근 방식은 규제가 엄격한 산업 또는 강력한 격리가 필요한 SaaS 환경에서 필요할 수 있습니다.
향후 지침
Kubernetes 커뮤니티는 소프트 멀티테넌시의 현재 단점과 하드 멀티테넌시의 문제를 인식했습니다. 다중 테넌시 특수 관심 그룹(SIG)
HNC 제안(KEP)은 테넌트 관리자가 하위 네임스페이스를 생성할 수 있는 기능과 함께 [정책] 객체 상속을 사용하여 네임스페이스 간에 상위-하위 관계를 생성하는 방법을 설명합니다.
가상 클러스터 제안에서는 클러스터 내의 각 테넌트('Kubernetes on Kubernetes'라고도 함)에 대해 API 서버, 컨트롤러 관리자 및 스케줄러를 포함하여 컨트롤 플레인 서비스의 별도의 인스턴스를 생성하는 메커니즘을 설명합니다.
다중 테넌시 벤치마크
다중 클러스터 관리 도구 및 리소스
