"다중 테넌트를 위해 Kubernetes를 어떻게 구성합니까?"라는 질문에 대답할 때 설계자는 먼저 사용 가능한 개념적 경계와 격리 모델을 이해해야 합니다. AKS의 다중 테넌시는 공유 Kubernetes 클러스터에서 서로 다른 팀, 애플리케이션 또는 고객에 속하는 여러 격리된 워크로드를 실행하는 방법입니다. 이 문서에서는 AKS(Azure Kubernetes Service) 다중 테넌트를 위한 핵심 개념 및 아키텍처 모델을 자세히 설명합니다.
Tip
AKS의 세 가지 다중 테넌트 모델은 무엇인가요? AKS 다중 테넌트는 네임스페이스 격리, 노드 풀 격리 및 테넌트당 클러스터의 세 가지 공통 모델이 있는 격리 스펙트럼을 사용합니다. 네임스페이스 격리는 신뢰할 수 있는 내부 팀과 최대 비용 효율성에 가장 적합하며, 노드 풀 격리는 중간 오버헤드로 더 강력한 워크로드 분리를 추가하며, 테넌트당 클러스터는 신뢰할 수 없거나 규제가 높은 시나리오에 대해 가장 강력한 격리를 제공합니다.
단계별 구현 지침 및 YAML 매니페스트는 AKS의 다중 테넌트 모범 사례 가이드를 참조하세요.
AKS에서 멀티 테넌시를 사용하는 이유는 무엇인가요?
다중 테넌트를 사용하면 여러 팀, 애플리케이션 또는 고객이 단일 Kubernetes 클러스터를 공유할 수 있습니다. AKS의 다중 테넌트 기본 근거는 비용 효율성 및 운영 규모입니다.
모든 애플리케이션 또는 팀에 대해 전용 클러스터를 실행하면 상당한 리소스 조각화, 유휴 컴퓨팅 용량 및 곱한 컨트롤 플레인 오버헤드가 발생합니다. 조직은 워크로드를 다중 테넌트 클러스터로 통합하여 리소스 사용률을 최대화하고 클라우드 지출을 줄입니다. 운영상 다중 테넌트에서는 플릿 크기를 줄입니다. 즉, 플랫폼 팀은 패치, 업그레이드, 모니터링 및 보안을 위한 클러스터 수가 적어 수명 주기 관리를 간소화합니다.
소프트 다중 테넌시와 하드 다중 테넌시의 차이점은 무엇인가요?
Kubernetes는 기본적으로 다중 테넌트 시스템이 아닙니다. 다중 테넌트를 달성하려면 테넌트 간의 신뢰 수준에 따라 "소프트" 또는 "하드" 격리 모델을 디자인해야 합니다.
Kubernetes의 소프트 및 하드 다중 테넌트 간의 차이는 주로 신뢰 모델과 결과 격리 요구 사항입니다. 소프트 다중 테넌트는 신뢰할 수 있는 내부 테넌트라고 가정하고 네임스페이스, RBAC 및 할당량과 같은 논리 컨트롤을 통한 우발적인 간섭을 방지하는 데 중점을 둡니다. 강한 다중 테넌시는 테넌트 간 신뢰 수준이 낮거나 전혀 없다고 가정하며, 악의적인 액세스, 측면 이동 및 데이터 노출의 위험을 줄이기 위해 더 강력한 격리 통제가 필요합니다.
| 모델 | 신뢰 수준 | 목표 | 사용 사례 | 예제 시나리오 |
|---|---|---|---|---|
| 소프트 멀티 테넌시 | 내부 테넌트 간의 높은 신뢰 | 우발적인 간섭, 리소스 부족 및 구성 충돌 방지 | 팀이 인프라를 공유하는 내부 플랫폼 환경 | 개발/테스트 및 내부 서비스를 위해 AKS 클러스터를 공유하는 한 조직의 여러 제품 팀 |
| 강력한 멀티 테넌시 | 테넌트 간 신뢰도 낮음 또는 제로 | 악의적인 공격, 횡적 이동 및 데이터 반출 방지 | 외부 고객 호스팅 및 규제 워크로드 | 테넌트 격리가 보안 및 규정 준수 요구 사항인 고객별 워크로드를 호스팅하는 SaaS 공급자 |
격리 스펙트럼
AKS의 다중 테넌시는 둘 중 하나를 택하는 문제가 아니라 연속선상에 있습니다. 스펙트럼을 넘어 이동하면 격리가 증가하지만 운영 복잡성과 비용도 증가합니다. 이 스펙트럼은 다중 테넌트 클러스터 디자인에 대한 구성 척추를 형성합니다.
- 네임스페이스 격리(논리): 테넌트는 동일한 노드 풀과 컨트롤 플레인을 공유하지만 Kubernetes 네임스페이스로 논리적으로 구분됩니다. 이것이 소프트 멀티테넌시의 기반입니다.
- 노드 풀 격리(물리적 컴퓨팅): 테넌트는 컨트롤 플레인을 공유하지만 전용 작업자 노드가 할당됩니다. 이렇게 하면 워크로드 분리 및 노이즈 네이버 완화가 향상되지만 제어 평면 및 클러스터 수준 구성 요소가 여전히 공유되기 때문에 테넌트 격리가 완료되지는 않습니다.
- 테넌트당 클러스터(전체 물리적): 테넌트는 자체 AKS 컨트롤 플레인 및 데이터 평면으로 완전히 격리됩니다. 이는 하드 멀티 테넌시의 궁극적인 형태로, Kubernetes 수준의 공유를 사실상 우회하고 Azure 수준의 격리를 택하는 방식입니다.
다중 테넌시를 위한 AKS 기본 구성 요소
AKS는 격리 스펙트럼을 적용하기 위해 네이티브 및 Azure 통합된 기본형 제품군을 제공합니다.
- Microsoft Entra ID: Kubernetes API에 사용자 및 자동화된 시스템을 인증하기 위한 중앙 집중식 ID 및 액세스 관리를 제공합니다.
- Azure RBAC: Microsoft Entra ID ID를 Kubernetes 권한에 매핑하여 테넌트가 권한 있는 리소스에만 액세스할 수 있도록 합니다.
- 관리되는 네임스페이스: 클러스터 내에서 테넌트 리소스를 그룹화하고 할당량을 적용하며 액세스 범위를 지정하는 논리적 경계를 제공합니다.
- Azure Policy/Gatekeeper: 클러스터 전체에서 중앙 집중식 규정 준수 및 거버넌스 규칙을 적용하여 테넌트가 안전하지 않거나 권한이 없는 구성을 배포하지 못하도록 합니다.
- Azure CNI: AKS 네트워킹에 대한 네이티브 가상 네트워크 통합을 제공하고 네트워크 정책 컨트롤을 사용하여 테넌트 트래픽 세분화를 지원합니다. Pod IP 동작은 선택한 CNI 모드(예: 오버레이 또는 Pod 서브넷)에 따라 달라집니다.
- Azure ACNS(Container Networking Services) Cilium L7: 테넌트 네트워크 트래픽을 엄격하게 격리하기 위해 고성능 eBPF 기반 네트워크 정책 및 계층 7 트래픽 필터링을 제공합니다.
- 워크로드 ID: 개별 Pod가 페더레이션 ID를 사용하여 외부 Azure 서비스에 안전하게 인증하여 테넌트 간의 공유 비밀을 제거할 수 있습니다.
평면 간 격리 계층 매핑
보안 다중 테넌트 아키텍처를 빌드하려면 클러스터 환경의 세 가지 개별 평면에 AKS 기본 형식을 적용해야 합니다.
| 비행기 | Description | 적용된 AKS 기본 형식 |
|---|---|---|
| 컨트롤 플레인 | Kubernetes API 서버 및 논리 경계에 대한 액세스 보안 | Microsoft Entra ID, Azure RBAC, 관리되는 네임스페이스 |
| 데이터 평면 | 네트워크 트래픽, 컴퓨팅 실행 및 노드 수준 경계를 보호합니다. | Azure CNI, ACNS Cilium L7, 노드 풀 |
| 리소스 평면 | 컴퓨팅 사용량, 외부 액세스 및 구성 규정 준수를 제어합니다. | Azure Policy, 워크로드 ID |
어떤 격리 모델을 선택해야 하나요?
다음 매트릭스를 사용하여 조직 요구 사항에 가장 적합한 격리 스펙트럼의 지점을 결정합니다.
| 격리 모델 | 보안 수준 | 비용 효율성 | 운영 복잡성 | 에 가장 적합 |
|---|---|---|---|---|
| 테넌트당 네임스페이스 | 낮음~중간(논리) | 높음(최대 공유) | 낮음 (관리할 단일 클러스터) | 내부 팀, 개발/테스트 환경, 느슨한 멀티 테넌시. |
| 테넌트별 노드 풀 | 높음(컴퓨팅 격리됨) | 중간 (공유 컨트롤 플레인) | 보통 (테인트/톨러레이션 관리) | 제어 플레인을 공유하면서도 더 강력한 컴퓨팅 격리가 필요한 내부 및 외부 워크로드에 적합하지만, 적대적인 제로 트러스트 테넌시 환경에는 적합하지 않습니다. |
| 테넌트당 클러스터 | 최고(물리적) | 낮음(높은 오버헤드) | 높음(차량 관리 필요) | 적대적인 다중 테넌트, 외부 엔터프라이즈 고객, 제로 트러스트. |
각 모델을 사용하는 경우
- 테넌트가 내부 또는 신뢰할 수 있는 경우 테넌트당 네임스페이스를 사용하고, 비용 효율성이 우선하며, 논리적 격리 제어로 충분합니다.
- 하나의 AKS 컨트롤 플레인을 공유하면서 더 강력한 컴퓨팅 분리 및 노이즈-인접 영향 감소가 필요한 경우 테넌트당 노드 풀을 사용합니다.
- 테넌트가 신뢰할 수 없거나, 규정 경계가 엄격하거나, 위험 모델에 최소한의 공유 인프라가 필요한 경우 테넌트당 클러스터를 사용합니다.
다음 단계
이제 다중 테넌트용 개념 모델 및 기본 형식을 이해했으므로 구현 가이드를 진행하여 이러한 개념을 클러스터에 적용합니다.
결론
- AKS(Azure Kubernetes Service) 다중 테넌트는 공유 Kubernetes 인프라에서 여러 격리된 테넌트 워크로드를 실행하여 비용을 절감하고 작업을 간소화하는 방법입니다.
- 테넌트당 네임스페이스는 논리적 경계를 적용하면서 인프라 공유를 최대화하므로 신뢰할 수 있는 내부 워크로드에 가장 비용 효율적인 모델입니다.
- 테넌트별 노드 풀은 컴퓨팅 리소스 분리와 노이지 네이버 제어를 개선하지만, 여전히 AKS 제어 평면과 기타 클러스터 수준 구성 요소를 공유합니다.
- 테넌트당 클러스터는 제로 트러스트 및 높은 규제 시나리오에 대해 가장 강력한 테넌트 격리를 제공하지만 더 높은 비용과 더 많은 운영 오버헤드가 필요합니다.