AKS(Azure Kubernetes Service) 를 사용하면 운영 오버헤드를 Azure 클라우드 플랫폼으로 오프로드하므로 Azure에서 관리되는 Kubernetes 클러스터를 간단하게 배포할 수 있습니다. 호스트된 Kubernetes 서비스인 AKS는 상태 모니터링, 유지 관리 및 제어 평면 관리와 같은 중요한 작업을 처리합니다.
여러 테넌트에서 다양한 방식으로 AKS 클러스터를 공유할 수 있습니다. 동일한 클러스터에서 다양한 애플리케이션을 실행하거나 동일한 애플리케이션의 여러 인스턴스(각 고객에 대해 하나의 인스턴스)를 공유 클러스터에서 실행할 수 있습니다. 두 시나리오 모두 다중 테넌트 예입니다. Kubernetes에는 사용자 또는 테넌트에 대한 기본 제공 개념이 없지만 다양한 테넌트 요구 사항을 관리하는 데 도움이 되는 기능을 제공합니다.
이 문서에서는 다중 테넌트 시스템을 빌드하는 데 도움이 되는 AKS 기능에 대해 설명합니다. 자세한 내용은 Kubernetes 다중 테넌시에 대한 모범 사례를 참조하세요.
다중 테넌트 형식
여러 테넌트에서 AKS 클러스터를 공유하는 방법을 결정하려면 먼저 사용 가능한 패턴 및 도구를 평가합니다. Kubernetes 클러스터의 다중 테넌트는 두 가지 주요 범주를 가지고 있지만 많은 변형이 있습니다. 다중 테넌트용 두 가지 일반적인 사용 사례 에는 여러 팀과 여러 고객이 포함됩니다.
여러 팀
일반적인 형태의 다중 테넌트에서는 조직 내의 여러 팀 간에 클러스터를 공유하는 것이 포함됩니다. 각 팀은 하나 이상의 워크로드를 배포, 모니터링 및 운영합니다. 이러한 워크로드는 일반적으로 서로 통신하고 동일한 클러스터 또는 다른 호스팅 플랫폼의 다른 내부 및 외부 애플리케이션과 통신합니다. 또한 관계형 데이터베이스, NoSQL 리포지토리 또는 동일한 클러스터에서 호스트되거나 Azure에서 PaaS(Platform as a Service) 솔루션으로 실행되는 메시징 시스템과 같은 서비스와 통신합니다.
이 시나리오에서 팀 구성원은 다음 방법 중 하나로 Kubernetes 리소스에 액세스합니다.
자세한 내용은 여러 팀을 참조하세요.
여러 고객
다중 테넌트의 또 다른 일반적인 형태는 SaaS(Software as a Service) 공급업체 또는 고객을 위해 워크로드의 여러 인스턴스를 실행하는 서비스 공급자를 포함합니다. 각 인스턴스는 별도의 테넌트를 제공합니다. 고객은 AKS 클러스터가 아닌 애플리케이션에만 액세스하며 일반적으로 애플리케이션이 Kubernetes에서 실행되는지 모릅니다. 비용 최적화는 이 모델에서 중요한 문제입니다. 테넌트 워크로드 간에 강력한 격리를 보장하기 위해 서비스 공급자는 리소스 할당량 및 네트워크 정책과 같은 Kubernetes 정책을 사용합니다.
자세한 내용은 여러 고객을 참조하세요.
격리 모델
Kubernetes 설명서에 따르면 테넌트라고도 하는 여러 사용자 및 워크로드는 다중 테넌트 Kubernetes 클러스터를 공유합니다. 이 정의에는 조직 내의 여러 팀 또는 부서가 공유하는 Kubernetes 클러스터와 SaaS 애플리케이션의 여러 고객 인스턴스를 호스트하는 클러스터가 포함됩니다.
클러스터 다중 테넌트는 여러 단일 테넌트 전용 클러스터를 관리하는 대신 사용할 수 있습니다. 운영자는 손상된 테넌트 또는 악의적인 테넌트가 클러스터 또는 다른 테넌트에 미칠 수 있는 피해를 제한하기 위해 테넌트를 서로 격리해야 합니다.
여러 사용자 또는 팀이 고정된 수의 노드가 있는 클러스터를 공유하는 경우 한 팀이 리소스의 공평한 점유율 이상을 사용할 수 있습니다. 이 문제를 방지하기 위해 관리자는 리소스 할당량을 사용할 수 있습니다.
멀티테넌시는 격리와 신뢰 수준에 따라 두 가지 범주로 나뉩니다.
소프트 다중 테넌시는 서로 다른 팀 또는 부서가 서로를 신뢰하는 단일 기업 내에 적용됩니다. 격리는 워크로드 무결성, 팀 간 리소스 관리 및 우발적인 문제 또는 보안 공격에 대한 방어에 중점을 둡니다.
하드 다중 테넌트는 테넌트가 서로를 신뢰하지 않고 보안 및 리소스 사용 모두에 대해 엄격한 격리가 필요한 경우에 적용됩니다.
다중 테넌트 AKS 클러스터를 빌드하려는 경우 다음 Kubernetes 격리 계층을 고려합니다.
- Cluster
- 네임스페이스
- 노드 풀 또는 노드
- 포드
- 컨테이너
또한 여러 테넌트 간에 리소스를 공유하면 보안에 미치는 영향도 고려합니다. 예를 들어 동일한 노드에 다른 테넌트의 Pod를 스케줄링하는 것은 클러스터에 필요한 머신 수를 줄여줍니다. 그러나 특정 워크로드가 노드를 공유하지 못하도록 해야 할 수도 있습니다. 따라서 중요한 정보를 처리하는 컨테이너와 동일한 노드에서 신뢰할 수 없는 외부 코드를 실행하도록 허용하지 않을 수 있습니다.
Kubernetes는 테넌트 간에 완벽하게 안전한 격리를 보장하지는 않지만 많은 사용 사례에 충분한 기능을 제공합니다. 모범 사례로 각 테넌트와 Kubernetes 리소스를 전용 네임스페이스로 구분합니다. Kubernetes RBAC(역할 기반 액세스 제어) 및 네트워크 정책을 사용하여 테넌트 격리를 적용합니다. 다음 다이어그램은 단일 클러스터에서 동일한 애플리케이션의 여러 인스턴스를 호스트하는 일반적인 SaaS 공급자 모델(각 테넌트에 대해 하나의 인스턴스)을 보여 줍니다. 각 인스턴스는 별도의 네임스페이스에서 실행됩니다.
AKS는 다중 테넌트 솔루션을 디자인하고 빌드하는 여러 가지 방법을 제공합니다. 각 방법에는 인프라 배포, 네트워크 토폴로지 및 보안에 대한 장차가 있습니다. 선택은 격리 수준, 구현 노력, 운영 복잡성 및 비용에 영향을 줍니다. 요구 사항에 따라 컨트롤 플레인, 데이터 평면 또는 둘 다에서 테넌트 격리를 적용합니다.
컨트롤 플레인 격리
컨트롤 플레인 격리는 테넌트가 Pod 및 서비스와 같은 서로의 리소스에 액세스하거나 영향을 주지 않도록 방지합니다. 테넌트는 다른 테넌트 애플리케이션의 성능에도 영향을 주지 않습니다. 컨트롤 플레인 격리를 구현하려면 각 테넌트의 워크로드와 Kubernetes 리소스를 별도의 네임스페이스로 분리합니다. 자세한 내용은 컨트롤 플레인 격리를 참조하세요.
Kubernetes 설명서에 따르면 네임스페이스는 단일 클러스터 내에서 리소스 그룹의 격리를 지원하는 추상화입니다. 네임스페이스를 사용하여 Kubernetes 클러스터를 공유하는 테넌트 워크로드를 격리합니다.
네임스페이스를 사용하면 테넌트 워크로드가 서로의 작업에 영향을 주지 않고 자체 가상 작업 영역에 존재할 수 있습니다. 조직 내의 별도 팀은 충돌 없이 다른 네임스페이스에서 동일한 리소스 이름을 사용할 수 있으므로 네임스페이스를 사용하여 프로젝트를 격리할 수 있습니다.
RBAC 역할 및 역할 바인딩 은 테넌트 사용자 및 프로세스를 네임스페이스의 리소스 및 서비스로만 제한하는 네임스페이스 범위 리소스입니다. 팀은 단일 이름으로 사용 권한 또는 능력을 그룹화할 역할을 정의할 수 있습니다. 이러한 역할을 사용자 및 서비스 계정에 할당하여 권한 있는 ID만 지정된 네임스페이스의 리소스에 액세스하도록 합니다.
CPU 및 메모리에 대한
리소스 할당량은 이름 간격이 지정된 개체입니다. 이를 사용하여 동일한 클러스터를 공유하는 워크로드가 과도한 시스템 리소스를 사용하지 않도록 격리합니다. 이 메서드는 각 테넌트 애플리케이션에 필요한 리소스가 있는지 확인하고 클러스터의 다른 테넌트 애플리케이션에 영향을 줄 수 있는 시끄러운 인접 문제를 방지합니다. 네트워크 정책은 테넌트 애플리케이션이 보내고 받을 수 있는 네트워크 트래픽을 제어하는 이름 지정 개체입니다. 네트워크 정책을 사용하여 네트워킹 관점에서 동일한 클러스터를 공유하는 워크로드를 분리합니다.
다른 네임스페이스에서 실행되는 팀 애플리케이션은 별도의 서비스 계정을 사용하여 동일한 클러스터, 외부 애플리케이션 또는 관리되는 서비스 내의 리소스에 액세스할 수 있습니다.
네임스페이스는 컨트롤 플레인 성능을 향상시킵니다. 공유 클러스터의 워크로드를 여러 네임스페이스로 구성하는 경우 Kubernetes API는 작업을 실행할 때 검색할 항목이 적습니다. 이 방법은 API 서버 대기 시간을 줄이고 컨트롤 플레인 처리량을 증가시킵니다.
네임스페이스 수준에서 격리에 대한 자세한 내용은 다음 리소스를 참조하세요.
데이터 평면 격리
데이터 평면 격리를 통해 테넌트 Pod와 워크로드가 서로 분리된 상태로 유지됩니다. 자세한 내용은 데이터 평면 격리를 참조하세요.
네트워크 격리
Kubernetes에서 다중 테넌트 마이크로 서비스 기반 애플리케이션을 실행하는 경우 서로 통신할 수 있는 구성 요소를 제어합니다. 기본적으로 AKS 클러스터의 모든 Pod는 동일한 클러스터의 다른 애플리케이션과의 통신을 포함하여 제한 없이 트래픽을 보내고 받을 수 있습니다. 보안을 향상하려면 트래픽 흐름을 제어하는 네트워크 규칙을 정의합니다. Kubernetes에서 네트워크 정책은 Pod 간 통신에 대한 액세스 정책을 정의합니다. 네트워크 정책을 사용하여 동일한 클러스터의 테넌트 애플리케이션 간에 통신을 분리합니다.
AKS는 네트워크 정책을 구현하는 다음과 같은 방법을 제공합니다.
Azure 네트워크 정책: 네트워크 정책에 대한 Azure 네이티브 구현입니다.
Calico 네트워크 정책:Tigera의 오픈 소스 네트워크 및 네트워크 보안 솔루션입니다.
Cilium에서 제공하는 Azure CNI: 계층 7 필터링을 포함하여 향상된 네트워크 정책 성능 및 고급 기능을 제공하는 eBPF(확장 버클리 패킷 필터) 기반 네트워킹 솔루션입니다. 이 방법을 사용하려면 Kubernetes 1.29 이상이 필요합니다.
Azure 네트워크 정책 및 Calico 네트워크 정책은 모두 기본적으로 Linux iptable을 사용하여 정책을 적용합니다. 이러한 구현은 네트워크 정책을 허용된 IP 주소 쌍 및 허용되지 않는 IP 주소 쌍 집합으로 변환한 다음 iptables 필터 규칙으로 프로그래밍합니다. Cilium에서 제공하는 Azure CNI는 정책 적용을 위해 Linux 커널에 로드된 eBPF 프로그램을 사용하여 성능을 향상시키고 iptable 및 kube-proxy의 오버헤드를 제거합니다. Calico에 대한 eBPF 지원을 설정할 수도 있습니다. 세 가지 옵션은 모두 Azure CNI 네트워크 플러그 인 및 Azure CNI 오버레이 모드를 모두 지원합니다.
자세한 내용은 AKS에서 네트워크 정책을 사용하여 Pod 간의 트래픽 보안을 참조하고 네트워크 격리를 확인하세요.
서비스 메시
서비스 메시는 다중 테넌트 AKS 클러스터에서 마이크로 서비스 통신을 위한 고급 트래픽 관리, 보안 및 관찰 기능을 제공합니다. 서비스 메시는 계층 7에서 작동합니다. 계층 3과 4에서 네트워크 정책이 제공하는 것 이상으로 서비스 간 통신에 대한 세분화된 제어를 제공합니다.
AKS에는 Istio 컨트롤 플레인의 수명 주기, 크기 조정 및 구성을 관리하는 Istio 기반 서비스 메시 기능이 포함되어 있습니다. 서비스 메시는 다중 테넌트 시나리오에 대한 몇 가지 주요 기능을 제공합니다.
ID 및 인증: 서비스 메시는 mTLS(상호 TLS)를 제공하여 서비스 간 통신을 자동으로 암호화하고 인증합니다. 각 서비스는 테넌트 경계를 적용하기 위한 토대를 제공하는 네임스페이스 및 서비스 계정에 따라 암호화 ID를 받습니다.
권한 부여 정책: 서비스 ID, 네임스페이스 또는 사용자 지정 특성에 따라 서로 통신하는 서비스를 제어하는 세분화된 권한 부여 정책을 정의할 수 있습니다. 예를 들어 테넌트 A의 프런트 엔드만 테넌트 A의 백 엔드 서비스를 호출하여 테넌트 간 서비스 액세스를 방지하도록 적용합니다.
트래픽 관리: 서비스 메시는 다중 테넌트 배포를 지원하는 고급 트래픽 라우팅 기능을 제공합니다.
카나리아 배포 및 A/B 테스트
특정 테넌트 네임스페이스에 업데이트를 점진적으로 롤아웃하기 위한 트래픽 분할
헤더 또는 기타 특성을 기반으로 테넌트 트래픽을 직접 라우팅하도록 요청
테넌트 워크로드에서 연속 오류를 방지하기 위한 회로 중단 및 재시도 정책
테넌트 격리를 적용하려면 이러한 기능을 테넌트 분리 패턴과 결합해야 합니다.
별도의 네임스페이스에서 테넌트 격리
일관된 레이블 지정 전략을 적용합니다.
경로 기반 또는 호스트 기반 라우팅 규칙을 구성합니다.
필요한 경우 테넌트당 별도의 수신 게이트웨이를 배포합니다.
특정 테넌트 네임스페이스 또는 레이블을 대상으로 하는 명시적 라우팅 정책을 만듭니다.
관찰 가능성: 서비스 메시는 모든 서비스 간 통신에 대한 메트릭, 로그 및 분산 추적을 자동으로 생성합니다. 이 가시성을 통해 다중 테넌트 문제를 해결하고 시끄러운 인접 문제를 식별할 수 있습니다.
계층 7 보안 정책: 서비스 메시는 IP 주소 및 포트에서만 작동하는 네트워크 정책과 달리 HTTP 메서드, 경로 및 헤더를 기반으로 정책을 적용합니다. 예를 들어 특정 API 엔드포인트에 대한 GET 요청만 수행하도록 테넌트 서비스를 제한합니다.
다중 테넌트 환경에서 서비스 메시를 구현하는 경우 다음 요소를 고려합니다.
사이드카 프록시로 인해 서비스 메시가 각 Pod에 추가하는 리소스 오버헤드를 계획합니다. 그에 따라 노드 크기를 조정하고 테넌트 네임스페이스에 대한 리소스 할당량을 설정합니다.
네임스페이스 수준에서 Istio 권한 부여 정책을 적용하여 테넌트 격리 경계를 적용합니다.
테넌트 격리를 적용하도록 명시적 기본 거부 권한 부여 정책을 구성합니다. 기본적으로 모든 트래픽이 허용됩니다.
테넌트 계층(기본, 표준, 프리미엄)당 별도의 Istio 수신 게이트웨이를 사용하여 다양한 수준의 트래픽 관리 및 보안을 제공합니다.
자세한 내용은 AKS용 Istio 기반 서비스 메시 기능 배포를 참조하세요.
스토리지 격리
Azure는 워크로드에 대한 영구 볼륨으로 사용할 수 있는 다른 스토리지 서비스와 함께 Azure SQL Database 및 Azure Cosmos DB와 같은 관리되는 PaaS 데이터 리포지토리를 제공합니다. 공유 AKS 클러스터에서 실행되는 테넌트 애플리케이션은 데이터베이스 또는 파일 저장소를 공유하거나전용 데이터 리포지토리 및 스토리지 리소스를 사용할 수 있습니다. 자세한 내용은 다중 테넌트 솔루션의 스토리지 및 데이터에 대한 아키텍처 접근 방식을 참조하세요.
AKS 워크로드는 영구 볼륨을 사용하여 데이터를 저장할 수 있습니다. Azure Storage에서 지원되는 Kubernetes 리소스로 영구 볼륨 을 만들 수 있습니다. 데이터 볼륨을 수동으로 만들고 Pod에 직접 할당하거나 AKS에서 영구 볼륨 클레임을 사용하여 자동으로 만들 수 있습니다. AKS에는 Azure 관리 디스크, Azure Files 및 AzureNetApp Files 에서 지원하는 영구 볼륨을 만드는 기본 제공 스토리지 클래스가 포함되어 있습니다. 자세한 내용은 AKS의 애플리케이션에 대한 스토리지 옵션을 참조하세요. 보안 및 복원력을 위해 emptyDir 및 hostPath 를 통해 에이전트 노드에서 로컬 스토리지를 사용하지 마세요.
AKS 기본 제공 스토리지 클래스가 테넌트의 요구 사항에 맞지 않는 경우 특정 요구 사항을 해결하기 위해 사용자 지정 스토리지 클래스 를 만듭니다. 이러한 요구 사항에는 볼륨 크기, 스토리지 SKU, SLA(서비스 수준 계약), 백업 정책 및 가격 책정 계층이 포함됩니다.
예를 들어 각 테넌트에 대한 사용자 지정 스토리지 클래스를 만들고 이를 사용하여 비용 절감을 위해 네임스페이스의 영구 볼륨에 태그를 적용합니다. 자세한 내용은 AKSAzure 태그 사용
자세한 내용은 스토리지 격리를 참조하세요.
노드 격리
시끄러운 인접 문제를 방지하고 정보 공개 위험을 줄이기 위해 별도의 에이전트 노드에서 실행되도록 테넌트 워크로드를 구성합니다. 격리, 보안, 규정 준수 및 성능에 대한 엄격한 요구 사항이 있는 테넌트에 대해 별도의 클러스터 또는 전용 노드 풀을 만듭니다.
테넌트 Pod를 특정 노드 또는 노드 풀로 제한하려면 테인트 및 톨러레이션, 노드 레이블, 노드 선택기 및 노드 선호도를 사용합니다.
AKS는 여러 수준에서 워크로드 격리를 제공합니다.
커널 수준: AKS는 공유 에이전트 노드의 경량 VM(가상 머신)에서 테넌트 워크로드를 실행하고 Kata Containers를 기반으로 하는 Pod 샌드박싱을 사용할 수 있습니다.
물리적 수준: 전용 클러스터 또는 노드 풀에서 테넌트 애플리케이션을 호스트할 수 있습니다.
하드웨어 수준: 에이전트 노드 VM이 전용 물리적 컴퓨터에서 실행되도록 보장하는 Azure 전용 호스트 에서 테넌트 워크로드를 실행할 수 있습니다. 이 하드웨어 격리는 다른 VM이 전용 호스트를 공유하지 않도록 하여 테넌트 워크로드 격리의 추가 계층을 제공합니다.
필요에 따라 이러한 기술을 결합합니다. 예를 들어 Azure 전용 호스트 그룹에서 테넌트별 클러스터 및 노드 풀을 실행하여 하드웨어 수준에서 워크로드 분리와 물리적 격리를 모두 달성합니다. FIPS(Federal Information Process Standards),기밀 VM 또는 호스트 기반 암호화를 지원하는 공유 또는 테넌트별 노드 풀을 만들 수도 있습니다.
노드 격리를 사용하여 노드 또는 노드 풀 집합의 비용을 단일 테넌트에 쉽게 연결하고 다시 청구합니다. 사용자의 선택은 솔루션의 테넌시 모델에 따라 달라집니다. 자세한 내용은 노드 격리를 참조하세요.
테넌시 모델
AKS는 다양한 유형의 노드 격리 및 테넌시 모델을 제공합니다.
자동화된 단일 테넌트 배포
이 모델에서는 다음 예제와 같이 각 테넌트에 대한 전용 리소스 집합을 배포합니다.
각 테넌트 워크로드는 전용 AKS 클러스터에서 실행되며 고유한 Azure 리소스 집합에 액세스합니다. 이 모델은 일반적으로 IaC(Infrastructure as Code) 도구를 사용합니다. 테넌트 전용 리소스의 주문형 배포를 자동화하려면 Bicep, Azure Resource Manager, Terraform 또는 Resource Manager REST API를 사용합니다. 각 고객에 대해 별도의 인프라를 프로비전해야 하는 경우 이 방법을 사용합니다. 배포를 계획할 때 배포 스탬프 패턴을 고려합니다.
이 방법은 다음과 같은 이점을 제공합니다.
각 테넌트 AKS 클러스터에는 보안, 네트워킹 및 리소스 사용을 위해 테넌트 간에 격리를 보장하는 별도의 API 서버가 있습니다. 컨테이너를 제어하는 공격자는 단일 테넌트에 속하는 컨테이너 및 탑재된 볼륨에만 액세스합니다. 규정 준수 요구 사항이 높은 고객을 위해 완전 격리 테넌트 모델을 사용합니다.
테넌트는 서로의 시스템 성능에 영향을 주지 않으므로 이 방법은 시끄러운 인접 문제를 방지합니다. 이 고려 사항에는 모든 Kubernetes 클러스터의 공유 중요 구성 요소인 API 서버에 대한 트래픽이 포함됩니다. API 서버에 대해 규제되지 않은 대용량 트래픽을 생성하는 사용자 지정 컨트롤러는 클러스터 불안정을 유발하여 요청 실패, 시간 제한 및 API 재시도 폭풍으로 이어질 수 있습니다. 작동 시간 SLA 기능을 사용하여 트래픽 수요를 충족하기 위해 AKS 클러스터의 제어 평면을 확장합니다. 그러나 워크로드 격리 요구 사항이 강력한 고객에게 전용 클러스터를 프로비전하는 것이 더 좋을 수 있습니다.
시스템 전체 중단 가능성을 줄이기 위해 테넌트 간에 업데이트 및 변경 내용을 점진적으로 롤아웃할 수 있습니다. Azure 비용은 모든 리소스가 단일 테넌트에 전용이기 때문에 개별 테넌트에 쉽게 기인합니다.
모든 테넌트 클러스터에서 Azure CNI 오버레이를 사용하면 IP 주소 계획이 간소화되고 여러 격리된 클러스터에서 동일한 Pod CIDR 공간을 다시 사용할 수 있습니다.
이 방법에는 다음과 같은 위험이 있습니다.
모든 테넌트는 전용 리소스를 사용하므로 비용이 증가합니다.
각 테넌트에 대해 하나의 클러스터를 사용하여 여러 AKS 클러스터에서 유지 관리 작업을 반복해야 하므로 지속적인 유지 관리는 시간이 많이 걸립니다. 이러한 복잡성을 관리하려면 운영 프로세스를 자동화하고 환경을 통해 변경 내용을 점진적으로 적용합니다. 전체 자산에서 보고 및 분석과 같은 작업을 위해 여러 배포에서 데이터를 쿼리하고 조작하는 방법을 계획합니다.
완전 다중 테넌트 배포
완전 다중 테넌트 배포에서 단일 애플리케이션은 모든 테넌트의 요청을 제공하고 AKS 클러스터를 포함한 모든 Azure 리소스를 공유합니다. 이 컨텍스트에서는 배포, 모니터링 및 유지 관리할 인프라가 하나만 있습니다. 모든 테넌트는 다음 다이어그램과 같이 리소스를 사용합니다.
이 방법은 다음과 같은 이점을 제공합니다.
- 공유 구성 요소의 운영 비용을 낮춥니다. 모든 테넌트가 생성하는 트래픽을 처리하려면 더 큰 AKS 클러스터를 배포하고 공유 데이터 리포지토리에 더 높은 SKU를 사용해야 할 수 있습니다.
이 방법에는 다음과 같은 위험이 있습니다.
단일 애플리케이션은 모든 테넌트 요청을 처리합니다. 테넌트가 호출로 애플리케이션을 과도하게 사용하지 않도록 보안 조치를 설계하고 구현합니다. 이러한 호출은 전체 시스템을 느리게 하고 모든 테넌트에 영향을 줄 수 있습니다.
매우 가변적인 트래픽에는 클러스터 자동 크기 조정이 필요합니다. CPU 및 메모리와 같은 시스템 리소스 사용량에 따라 Pod 및 에이전트 노드 수를 조정하도록 AKS 클러스터 자동 크기 조정기를 구성합니다. 또는 Kubernetes 기반 KEDA(Event Driven Autoscaler)를 사용하는 외부 메시징 시스템의 보류 중인 요청 또는 메트릭 수와 같은 사용자 지정 메트릭을 기반으로 Pod 및 클러스터 노드를 확장합니다.
테넌트 간의 데이터 분리에는 신중한 구현이 필요합니다. 각 테넌트에 대한 데이터를 분리하고 테넌트 간의 데이터 누출을 방지하기 위한 보호 장치를 구현합니다.
실제 사용량에 따른 개별 테넌트에 대한 비용 추적 및 귀속은 복잡합니다. Azure 비용을 추적하여 개별 테넌트에 연결합니다. Kubecost와 같은 타사 솔루션은 여러 팀과 테넌트에서 비용을 계산하고 분석하는 데 도움이 될 수 있습니다.
Azure 리소스 집합을 하나만 업데이트하고 단일 애플리케이션을 유지 관리하므로 단일 배포를 사용하면 유지 관리가 더 간단합니다. 그러나 인프라 또는 애플리케이션 구성 요소에 대한 변경 내용은 전체 고객 기반에 영향을 줄 수 있습니다.
공유 리소스는 Azure 리소스 확장 제한에 도달할 가능성이 더 높습니다. 리소스 할당량 한도에 도달하지 않으려면 테넌트를 여러 Azure 구독에 분산시키십시오.
수평 분할된 배포
수평 분할은 모든 테넌트에서 일부 솔루션 구성 요소를 공유하고 개별 테넌트에 대한 전용 리소스를 배포합니다. 예를 들어 다음 다이어그램과 같이 단일 다중 테넌트 Kubernetes 애플리케이션을 빌드한 다음 각 테넌트에 대해 하나씩 개별 데이터베이스를 만듭니다.
이 방법은 다음과 같은 이점을 제공합니다.
- 가로로 분할된 배포는 시끄러운 인접 문제를 완화하는 데 도움이 됩니다. 특정 구성 요소가 Kubernetes 애플리케이션의 부하 대부분을 생성하고 각 테넌트에 대해 구성 요소를 별도로 배포할 수 있는 경우 이 방법을 사용합니다. 예를 들어 데이터베이스가 높은 쿼리 로드를 처리하는 경우 과도한 요청을 보내는 단일 테넌트는 자체 데이터베이스에만 영향을 줍니다. 애플리케이션 계층과 같은 다른 테넌트의 데이터베이스 및 공유 구성 요소는 영향을 받지 않습니다.
이 방법에는 다음과 같은 위험이 있습니다.
구성 요소, 특히 단일 테넌트에서 사용하는 구성 요소에 대한 배포 및 관리를 자동화해야 합니다.
이 모델은 내부 정책 또는 규정 준수 이유로 다른 테넌트와 리소스를 공유할 수 없는 고객에게 필요한 수준의 격리를 제공하지 않을 수 있습니다.
수직 분할된 배포
단일 테넌트 및 완전 다중 테넌트 모델의 이점을 활용하려면 여러 AKS 클러스터 또는 노드 풀에서 테넌트를 수직으로 분할하는 하이브리드 모델을 사용합니다. 이 방법은 이전의 두 테넌시 모델에 비해 다음과 같은 이점을 제공합니다.
단일 테넌트 및 다중 테넌트 배포의 조합을 사용할 수 있습니다. 예를 들어 대부분의 고객은 다중 테넌트 인프라에서 AKS 클러스터 및 데이터베이스를 공유할 수 있습니다. 또한 더 높은 성능과 격리가 필요한 고객을 위해 단일 테넌트 인프라를 배포할 수 있습니다.
구성이 다른 여러 지역 AKS 클러스터에 테넌트 배포할 수 있습니다. 테넌트가 여러 지역에 분산된 경우 이 기술을 사용합니다.
이 테넌시 모델의 다양한 변형을 구현할 수 있습니다. 예를 들어 다양한 기능 수준을 제공하는 계층화된 가격 책정으로 다중 테넌트 솔루션을 제공할 수 있습니다. 각 계층은 리소스 공유, 성능, 네트워크 및 데이터 분리를 위한 증분 수준의 성능 및 격리를 제공할 수 있습니다. 다음 예제 계층을 고려합니다.
기본 계층: 공유된 단일 다중 테넌트 Kubernetes 애플리케이션은 모든 테넌트 요청을 제공합니다. 모든 기본 계층 테넌트는 하나 이상의 데이터베이스를 공유합니다.
표준 계층: 각 테넌트에는 별도의 네임스페이스에서 실행되는 전용 Kubernetes 애플리케이션이 있습니다. 이 방법은 보안, 네트워킹 및 리소스 사용에 대한 격리를 제공합니다. 각 테넌트 애플리케이션은 다른 표준 계층 테넌트와 동일한 AKS 클러스터 및 노드 풀을 공유합니다.
프리미엄 계층: 각 테넌트 애플리케이션은 전용 노드 풀 또는 AKS 클러스터에서 실행됩니다. 이 방법은 더 높은 SLA, 더 나은 성능 및 더 강력한 격리를 보장합니다. 비용은 테넌트 애플리케이션을 호스트하는 에이전트 노드의 수와 SKU를 기반으로 합니다. 고유한 테넌트 워크로드를 격리하기 위해 Pod 샌드박싱 은 전용 클러스터 또는 노드 풀에 대한 대안을 제공합니다.
다음 다이어그램에서는 테넌트 A와 B가 공유 AKS 클러스터에서 실행되고 테넌트 C가 별도의 AKS 클러스터에서 실행되는 시나리오를 보여 줍니다.
다음 다이어그램에서는 테넌트 A와 B가 동일한 노드 풀에서 실행되고 테넌트 C가 전용 노드 풀에서 실행되는 시나리오를 보여 줍니다.
이 모델은 다른 계층에 대해 다른 SLA를 제공할 수도 있습니다. 예를 들어 기본 계층은 99.90% 가동 시간을 제공할 수 있고, 표준 계층은 99.95% 가동 시간을 제공할 수 있으며, 프리미엄 계층은 99.99% 가동 시간을 제공할 수 있습니다. 애플리케이션 소유자는 이러한 SLA를 정의하고 소유합니다. 더 높은 SLA를 구현하려면 고가용성 대상을 사용하도록 설정하는 서비스 및 기능을 사용합니다.
이 방법은 다음과 같은 이점을 제공합니다.
공유 인프라는 비용을 절감합니다. 기본 계층 및 표준 계층 테넌트에 대한 공유 클러스터 및 노드 풀을 배포합니다. 이 방법은 에이전트 노드에 대해 저렴한 VM 크기를 사용하고 더 나은 밀도를 제공합니다. 프리미엄 계층 테넌트에서 더 높은 VM 크기 및 최대 Pod 복제본 및 노드 수를 더 높은 가격으로 사용하여 AKS 클러스터 및 노드 풀을 배포할 수 있습니다.
전용 노드 풀에서 시스템 서비스를 격리합니다. 시스템 모드 노드 풀에서 CoreDNS, Konnectivity 또는 AGIC(Azure Application Gateway 수신 컨트롤러) 와 같은 시스템 서비스를 실행합니다. 하나 이상의 사용자 모드 노드 풀에서 테넌트 애플리케이션을 실행하려면 taint 및 tolerations, 노드 레이블, 노드 선택기 및 노드 선호도를 사용합니다.
노드 풀을 공유 리소스에 바칩니다. 공유 리소스를 실행하려면 taint 및 tolerations, 노드 레이블, 노드 선택기 및 노드 선호도를 사용합니다. 예를 들어 특정 VM 크기, 자동 크기 조정기 설정 및 가용성 영역 지원이 있는 전용 노드 풀에 수신 컨트롤러 또는 메시징 시스템을 사용할 수 있습니다.
이 방법에는 다음과 같은 위험이 있습니다.
Kubernetes 애플리케이션은 다중 테넌트 및 단일 테넌트 배포를 모두 지원해야 합니다.
공유 인프라에서 전용 인프라로 고객을 마이그레이션하려면 신중한 계획이 필요합니다.
여러 AKS 클러스터를 관리하고 모니터링하려면 중앙 집중식 모니터링과 일관된 전략이 필요합니다.
Autoscaling
테넌트 애플리케이션이 생성하는 트래픽 수요를 충족하려면 클러스터 자동 크기 조정기를 켜서 AKS의 에이전트 노드 크기를 조정합니다. 자동 크기 조정은 다음과 같은 상황에서 시스템이 응답성을 유지하는 데 도움이 됩니다.
특정 작업 시간 또는 기간 동안 트래픽 부하가 증가합니다.
테넌트 워크로드 또는 무거운 공유 부하가 클러스터에 배포됩니다.
가용성 영역 중단으로 인해 에이전트 노드를 사용할 수 없게 됩니다.
노드 풀에 대한 자동 크기 조정을 켜면 예상 워크로드 크기에 따라 최소 및 최대 노드 수를 지정합니다. 클러스터의 최대 노드 수는 모든 네임스페이스에 걸쳐 모든 테넌트 Pod에 충분한 용량을 보장합니다.
트래픽이 증가함에 따라 클러스터 자동 크기 조정기는 CPU 또는 메모리 부족으로 인해 Pod가 보류 중 상태로 전환되지 않도록 새 에이전트 노드를 추가합니다.
부하가 감소하면 클러스터 자동 크기 조정기는 구성된 경계 내의 노드 풀에서 에이전트 노드를 제거하여 운영 비용을 절감합니다.
Pod 자동 크기 조정은 리소스 요구에 따라 Pod의 크기를 자동으로 조정합니다. HorizontalPodAutoscaler 는 CPU, 메모리 또는 사용자 지정 메트릭에 따라 Pod 복제본의 크기를 조정합니다. KEDA 는 테넌트 애플리케이션이 사용하는 외부 시스템(예: Azure Event Hubs 또는 Azure Service Bus)의 이벤트를 기반으로 컨테이너 크기를 조정합니다.
VPA(Vertical Pod Autoscaler) 는 Pod에 할당된 CPU 및 메모리를 조정하여 테넌트 애플리케이션을 실행하는 데 필요한 노드 수를 줄입니다. 노드 수를 줄이면 총 비용이 절감되고 시끄러운 인접 문제를 방지할 수 있습니다.
테넌트 간의 리소스 할당 및 격리를 향상하려면 노드 풀에 용량 예약 그룹을 할당합니다.
Maintenance
클러스터 또는 노드 풀 업그레이드 중 테넌트 애플리케이션의 가동 중지 위험을 줄이려면 비사용 시간에 AKS 계획된 유지 관리를 예약하십시오. 워크로드 영향을 최소화하려면 매주 유지 관리 기간을 예약하여 테넌트 애플리케이션 및 노드 풀을 실행하는 AKS 클러스터의 제어 평면을 업데이트합니다. 일 또는 시간 범위를 정의하여 클러스터에서 주별 유지 관리 기간을 하나 이상 지정합니다. 모든 유지 관리 작업은 예약된 기간 내에 발생합니다.
Security
다음 섹션에서는 다중 테넌트 AKS 솔루션에 대한 보안 모범 사례를 설명합니다.
클러스터 액세스
조직 내의 여러 팀 간에 AKS 클러스터를 공유하는 경우 서로 다른 테넌트를 격리하는 최소 권한 원칙 을 구현합니다. kubectl, Helm, Flux 또는 Argo CD와 같은 도구를 사용하는 경우 사용자에게 Kubernetes 네임스페이스 및 리소스에 대한 액세스 권한만 부여합니다.
AKS를 사용한 인증 및 권한 부여에 대한 자세한 내용은 다음 문서를 참조하세요.
- AKS 대한
액세스 및 ID 옵션 - AKS 관리형 Microsoft Entra 통합
- AKS에서 Microsoft Entra ID를 사용하는 Kubernetes RBAC
워크로드 정체성
워크로드 ID는 다중 테넌트 AKS 클러스터에 대한 중요한 보안 요구 사항입니다. 여러 테넌트 애플리케이션이 AKS 클러스터를 공유하는 경우 각 테넌트의 워크로드는 테넌트 간 액세스 및 자격 증명 공유를 방지하기 위해 별도의 격리된 ID를 사용하여 Azure 리소스에 인증해야 합니다.
다중 테넌트 클러스터에서 워크로드 ID는 다음과 같은 몇 가지 중요한 보안 위험을 방지합니다.
자격 증명 공유: 워크로드 ID가 없으면 테넌트 애플리케이션은 서비스 주체를 공유하거나 자격 증명을 비밀에 저장하므로 테넌트 간 액세스의 위험이 증가합니다.
권한 에스컬레이션: 손상된 테넌트 워크로드는 공유 자격 증명을 통해 다른 테넌트의 Azure 리소스에 액세스할 수 있습니다.
자격 증명 노출: Kubernetes 비밀의 서비스 주체 자격 증명은 우발적인 공개 또는 무단 액세스에 취약합니다.
워크로드 ID는 Kubernetes 서비스 계정과 통합됩니다. 테넌트에 대한 네임스페이스를 생성할 때, 해당 테넌트를 위해 전용 Kubernetes 서비스 계정을 만들고, 그 계정에 Azure 관리 ID의 클라이언트 ID를 주석으로 추가합니다. AKS 클러스터는 OIDC 발급자 엔드포인트를 사용하여 신뢰 관계를 설정하는 Microsoft Entra ID와 페더레이션합니다. 주석이 추가된 서비스 계정을 사용하는 Pod는 Microsoft Entra 액세스 토큰을 교환하는 수명이 짧은 토큰을 자동으로 수신하므로 Azure 리소스 액세스를 보호할 수 있습니다.
구현 단계 및 코드 예제에 대한 자세한 내용은 AKS에서 Microsoft Entra 워크로드 ID 사용 및 AKS에서 워크로드 ID 배포 및 구성을 참조하세요.
Pod 샌드박싱
AKS Pod 샌드박싱 은 컨테이너 애플리케이션과 CPU, 메모리 및 네트워킹과 같은 컨테이너 호스트의 공유 커널 및 컴퓨팅 리소스 간에 격리 경계를 제공합니다. Pod 샌드박싱은 테넌트 워크로드가 중요한 정보를 보호하고 PCI DSS(Payment Card Industry Data Security Standard), ISO(International Organization for Standardization) 27001, HIPAA(Health Insurance Portability and Accountability Act)와 같은 규제, 산업 또는 거버넌스 규정 준수 요구 사항을 충족하는 데 도움이 되는 다른 보안 조치 및 데이터 보호 제어를 보완합니다.
별도의 클러스터 또는 노드 풀은 서로 다른 팀 또는 고객의 테넌트 워크로드에 대해 강력한 격리를 제공합니다. 이 방법은 많은 조직 및 SaaS 솔루션에 적합합니다. 그러나 공유 VM 노드 풀이 있는 단일 클러스터는 신뢰할 수 없는 신뢰할 수 있는 Pod를 함께 실행하거나 더 빠른 로컬 통신 및 기능 그룹화에 대해 권한 있는 컨테이너를 사용하여 DaemonSets를 공동 배치하는 경우와 같은 일부 시나리오에서 더 효율적입니다.
Pod 샌드박싱은 별도의 클러스터 또는 노드 풀을 요구하지 않고 공유 클러스터 노드에서 강력한 테넌트 애플리케이션 격리를 제공합니다. 다른 격리 방법과 달리 Pod 샌드박싱은 코드 다시 컴파일 또는 호환성 문제 없이 향상된 보안 VM 경계 내에서 수정되지 않은 컨테이너를 실행합니다.
하드웨어 적용 격리를 제공하기 위해 AKS의 Pod 샌드박싱은 AKS 스택용 Azure Linux 컨테이너 호스트에서 실행되는 Kata 컨테이너를 기반으로 합니다. Kata 컨테이너는 보안이 강화된 Azure 하이퍼바이저에서 실행됩니다. 각 Kata Pod는 자체 커널이 있는 중첩된 경량 VM에서 실행됩니다. Kata VM은 부모 VM 노드의 리소스를 사용합니다. 표준 컨테이너가 부모 VM에서 계속 실행되는 동안 단일 게스트 VM에서 많은 Kata 컨테이너를 실행할 수 있습니다. 이 방법은 공유 AKS 클러스터에서 강력한 격리 경계를 제공합니다.
AKS에서 Pod 샌드박싱을 위한 다음의 제한 사항을 고려하십시오.
Pod 샌드박싱은 중첩된 가상화를 지원하는 Azure Linux 3.0 이상 및 2세대 VM을 사용하는 Linux 노드 풀에서만 지원됩니다.
Kata 컨테이너는 Azure Files의 기존 컨테이너 및 고성능 로컬 SSD(반도체 드라이브)와 동일한 IOPS(초당 입력/출력 작업) 성능에 도달하지 못할 수 있습니다.
컨테이너용 Microsoft Defender는 Kata 런타임 포드의 보안 평가를 지원하지 않습니다.
호스트 네트워크 액세스는 지원되지 않습니다.
자세한 내용은 다음 문서를 참조하세요.
Azure 전용 호스트
Azure Dedicated Host 는 물리적 서버 수준에서 하드웨어 격리를 사용하여 단일 Azure 구독 전용 물리적 서버를 제공합니다. 지역, 가용성 영역 및 장애 도메인 내에서 전용 호스트를 프로비전하고 VM을 직접 배치할 수 있습니다.
AKS를 사용하는 전용 호스트는 다음과 같은 이점을 제공합니다.
하드웨어 격리: 다른 VM은 테넌트 워크로드에 대한 추가 격리 계층을 제공하는 전용 호스트에서 실행되지 않습니다. 전용 호스트를 비전용 호스트와 동일한 데이터 센터에 배포합니다. 동일한 네트워크 및 기본 스토리지 인프라를 공유합니다.
유지 관리 제어: Azure 플랫폼 유지 관리가 발생하는 시기를 제어합니다. 유지 관리 기간을 선택하여 서비스 영향을 줄이고 테넌트 워크로드의 가용성 및 개인 정보를 보장합니다.
전용 호스트는 SaaS 공급자가 테넌트 애플리케이션이 중요한 정보를 보호하기 위한 규정, 산업 및 거버넌스 규정 준수 요구 사항을 충족하도록 합니다. 자세한 내용은 AKS 클러스터에 전용 호스트 추가를 참조하세요.
노드 자동 프로비전
노드 자동 프로비전은 보류 중인 Pod 요구 사항에 따라 노드를 동적으로 프로비전하고 관리하는 관리되는 AKS 기능입니다. Kubernetes 스케줄러가 Pods를 예약할 수 없는 것으로 표시하면, 노드 자동 프로비저닝이 해당 워크로드를 실행하도록 적절하게 구성된 노드를 자동으로 만듭니다. 테넌트에 다양한 인프라 요구 사항이 있는 다중 테넌트 배포에서 이 기능을 사용합니다.
노드 자동 프로비전은 다음과 같은 방법으로 다중 테넌트 클러스터 작업을 향상시킵니다.
동적 테넌트별 노드 유형: 노드 자동 프로비전은 각 테넌트의 워크로드 요구 사항에 적절한 VM 크기를 프로비전합니다. 예를 들어 테넌트 A가 GPU 집약적 워크로드를 배포하고 테넌트 B가 메모리 집약적 애플리케이션을 실행하는 경우 노드 자동 프로비전은 테넌트 A에 대한 GPU 최적화 노드와 테넌트 B에 대한 메모리 최적화 노드를 만듭니다.
비용 최적화: 테넌트는 활성 워크로드가 있는 경우에만 컴퓨팅 리소스를 사용합니다. 노드 자동 프로비전은 테넌트 Pod가 삭제될 때 노드를 축소하거나 제거하므로 유휴 용량에 대한 비용을 지불하지 않습니다.
가용성 영역 배치: 노드 자동 프로비전은 Pod 토폴로지 제약 조건에 따라 테넌트 대기 시간 또는 데이터 상주 요구 사항을 충족하도록 특정 가용성 영역에 노드를 프로비전할 수 있습니다.
간소화된 노드 풀 관리: 노드 자동 프로비전은 실제 테넌트 워크로드 요구 사항에 따라 요청 시 노드를 프로비전합니다. VM 크기가 다른 다른 테넌트 계층에 대해 여러 노드 풀을 미리 프로비전할 필요가 없습니다.
리소스 사용률 향상: 노드 자동 프로비전은 동적으로 생성된 노드에서 지능형 bin 압축을 제공합니다. 이 기능은 정적 노드 풀에 비해 낭비되는 용량을 줄입니다. 다양한 리소스 프로필이 있는 많은 소규모 테넌트 워크로드를 실행할 때 이 방법을 사용합니다.
AKS 클러스터에서 노드 자동 프로비전을 사용하도록 설정하고 워크로드 요구 사항을 정의하려면 다음 Kubernetes 네이티브 구성을 사용합니다.
Pod 리소스 요청 및 제한을 사용하여 테넌트 워크로드에 대한 CPU 및 메모리 요구 사항을 지정합니다.
특정 VM 패밀리가 필요한 경우 테넌트 Pod에 노드 선택기 또는 노드 선호도 규칙을 적용합니다.
토폴로지 분산 제약 조건을 사용하여 가용성 영역 간 Pod 배포를 제어합니다.
노드에 taint 및 toleration을 적용하여 워크로드를 적절하게 프로비전된 노드로 제한합니다.
노드 자동 프로비전은 오픈 소스 Karpenter 프로젝트를 기반으로 합니다. AKS는 수명 주기 관리, 업그레이드 및 Azure 관련 최적화를 통해 관리되는 환경을 제공합니다. 대부분의 사용자는 노드 자동 프로비전을 관리되는 기능으로 사용해야 합니다. 자세한 내용은 노드 자동 프로비전참조하세요.
노드 자동 프로비전이 제공하는 것 이상으로 고급 사용자 지정이 필요한 경우 AKS에서 Karpenter를 직접 자체 호스팅할 수 있습니다. 이 방법은 Karpenter 구성에 대한 모든 권한을 제공하지만 수명 주기 및 업그레이드를 관리해야 합니다. 자세한 내용은 AKS Karpenter 공급자를 참조하세요.
기밀 가상 머신
기밀 VM을 사용하여 AKS 클러스터에 하나 이상의 노드 풀을 추가하여 테넌트의 엄격한 격리, 개인 정보 보호 및 보안 요구 사항을 해결합니다. 기밀 VM은 하드웨어 기반 신뢰할 수 있는 실행 환경사용할 있습니다.
AMD 보안 암호화 Virtualization-Secure 중첩 페이징(SEV-SNP) 기밀 VM은 VM 메모리 및 상태에 대한 하이퍼바이저 및 기타 호스트 관리 코드 액세스를 거부하므로 운영자 액세스에 대한 방어 및 심층 보호 계층을 추가합니다. 자세한 내용은 AKS 클러스터기밀 VM 사용
FIPS
FIPS 140-3 은 IT(정보 기술) 제품 및 시스템의 암호화 모듈에 대한 최소 보안 요구 사항을 정의하는 미국 정부 표준입니다. FIPS 규정 준수 는 암호화, 해시 및 기타 보안 관련 작업에 유효성이 검사된 암호화 모듈을 사용하도록 보장합니다.
AKS 노드 풀에 대한 FIPS를 구성하여 테넌트 워크로드 격리, 개인 정보 보호 및 보안을 강화합니다. FIPS 지원 노드 풀은 강력한 암호화 알고리즘 및 메커니즘을 사용하여 규정 및 업계 규정 준수 요구 사항을 충족하는 데 도움이 됩니다. 이 방법을 사용하여 다중 테넌트 AKS 환경의 보안 태세를 강화합니다.
Azure 디스크에 대한 BYOK(Bring Your Own Key)
Azure Storage는 OS(운영 체제) 및 AKS 클러스터의 데이터 디스크를 포함하여 미사용 스토리지 계정의 데이터를 암호화합니다. 기본적으로 Azure는 Microsoft 관리형 키를 통해 데이터를 암호화합니다. 암호화 키를 보다 자세히 제어하려면 AKS 클러스터의 나머지 OS 및 데이터 디스크에서 암호화를 위해 고객 관리형 키를 제공합니다. 자세한 내용은 다음 문서를 참조하세요.
호스트 기반 암호화
AKS의 호스트 기반 암호화는 기본 호스트 머신에서 미사용 데이터를 암호화하여 테넌트 워크로드 격리, 개인 정보 보호 및 보안을 더욱 강화합니다. 이 기능은 중요한 테넌트 정보를 무단 액세스로부터 보호합니다. 엔드투엔드 암호화를 켜면 임시 디스크 및 임시 OS 디스크가 플랫폼 관리형 키로 암호화됩니다.
AKS에서 OS 및 데이터 디스크는 기본적으로 플랫폼 관리형 키로 서버 쪽 암호화를 사용합니다. 디스크 캐시는 플랫폼 관리형 키를 통해 미사용 시 암호화됩니다. 래핑이라고도 하는 봉투 암호화를 사용하여 데이터 보호 키 암호화하는 고유한 키 암호화 키 지정할 수 있습니다. 디스크 캐시는 지정한 BYOK 를 통해 암호화됩니다.
호스트 기반 암호화는 다중 테넌트 환경에 대한 추가 보안 계층을 제공합니다. OS 및 데이터 디스크 캐시에 있는 각 테넌트의 데이터는 선택한 디스크 암호화 유형에 따라 고객 관리형 또는 플랫폼 관리형 키를 사용하여 미사용 시 암호화됩니다. 자세한 내용은 다음 문서를 참조하세요.
- AKS 호스트 기반 암호화
- AKS Azure 디스크를 사용하여 BYOK
- Azure Disk Storage의 서버 쪽 암호화
Networking
다음 섹션에서는 다중 테넌트 AKS 솔루션에 대한 네트워킹 모범 사례를 설명합니다.
다중 테넌트 클러스터에 대한 네트워크 토폴로지
다중 테넌트 AKS 배포를 위한 네트워크 토폴로지를 디자인할 때 Azure CNI Standard와 Azure CNI 오버레이 중에서 선택하는 것은 테넌트 워크로드의 크기를 조정하고 IP 주소 공간을 관리하는 방법에 영향을 줍니다.
기존 Azure CNI는 노드와 Pod 모두에 가상 네트워크 IP 주소를 할당합니다. 이 방법은 대규모 다중 테넌트 배포에서 사용 가능한 IP 주소 공간을 소진할 수 있습니다. Azure CNI 오버레이는 노드에만 가상 네트워크 IP 주소를 할당하고 Pod는 별도의 오버레이 CIDR을 사용합니다. Azure CNI 오버레이는 가상 네트워크 IP 주소 소모의 위험을 줄이고 동일한 가상 네트워크 주소 공간 내에 더 많은 테넌트 워크로드를 배포할 수 있도록 합니다.
다음 경우 다중 테넌트 시나리오에 Azure CNI 표준을 사용합니다.
외부 시스템은 Pod IP 주소에 대한 직접 라우팅 가능한 액세스가 필요합니다(대부분의 SaaS 다중 테넌트 패턴에서는 일반적이지 않습니다).
오버레이 모드를 지원하지 않는 고급 AKS 기능을 사용합니다.
가상 네트워크에 충분한 IP 주소 공간이 있으며 테넌트 클러스터가 거의 없습니다.
다음 경우 다중 테넌트 시나리오에 Azure CNI 오버레이를 사용합니다.
여러 전용 클러스터(테넌트당 또는 테넌트 계층당 하나)를 배포합니다.
동일한 가상 네트워크에 여러 AKS 클러스터를 배포합니다(테넌트별 또는 계층별 클러스터 모델에 공통).
테넌트 네임스페이스가 많은 공유 클러스터에서 높은 Pod 밀도를 실행합니다.
테넌트당 여러 환경(개발, 스테이징, 프로덕션)을 배포합니다.
IP 주소 공간이 제한되거나 다른 Azure 리소스에 대한 가상 네트워크 IP 주소를 예약해야 합니다.
여러 테넌트 배포에서 인프라 템플릿을 표준화해야 합니다.
자동화된 단일 테넌트 배포 모델(각 테넌트에 대한 전용 클러스터)을 배포하는 경우 Azure CNI 오버레이를 사용하면 여러 테넌트 클러스터에서 동일한 Pod CIDR(예: 10.244.0.0/16)을 다시 사용할 수 있습니다. 이 방법을 사용하면 테넌트당 고유한 Pod CIDR을 계획, 할당 및 추적할 필요가 없습니다. 모든 테넌트에서 IaC 템플릿을 표준화할 수 있습니다. CIDR 할당을 조정할 필요가 없으므로 테넌트 온보딩이 더 빠릅니다. 이 일관된 구성은 문제 해결을 간소화하고 구성 오류를 줄입니다.
Azure CNI 오버레이는 Azure CNI 표준과 동일한 테넌트 격리를 제공합니다. 두 토폴로지 모두 세 가지 네트워크 정책 엔진인 Azure 네트워크 정책, Calico 및 Cilium에서 제공하는 Azure CNI를 모두 지원합니다. 두 옵션 중 하나를 사용하여 테넌트 간에 네임스페이스 수준 네트워크 격리를 적용할 수 있습니다.
Azure CNI 오버레이는 SNAT(원본 네트워크 주소 변환)를 사용하여 트래픽이 클러스터를 떠날 때 테넌트 Pod IP 주소를 노드 IP 주소로 변환합니다. 외부 시스템 또는 방화벽 규칙에 대한 테넌트별 트래픽을 식별해야 하는 경우 다음 방법을 사용하여 테넌트별 송신 컨트롤을 구현합니다.
각 테넌트에 대한 전용 노드 풀을 만들고 특정 노드 레이블을 사용합니다.
여러 공용 IP 주소를 사용하는 Azure NAT Gateway를 배포하고 다른 노드 풀에 다른 IP를 할당합니다.
특정 규칙을 통해 테넌트 트래픽을 전송하는 UDR(사용자 정의 경로)을 사용하여 Azure Firewall을 구성합니다.
자세한 내용은 AKS에서 Azure CNI 오버레이 네트워킹 구성을 참조하세요.
API 서버에 대한 네트워크 액세스 제한
Kubernetes에서 API 서버는 리소스 만들기 또는 노드 크기 조정과 같은 클러스터 작업을 수행하라는 요청을 받습니다. 여러 팀에서 AKS 클러스터를 공유하는 경우 다음 솔루션 중 하나를 사용하여 제어 평면 액세스를 보호합니다.
프라이빗 AKS 클러스터
프라이빗 AKS 클러스터는 가상 네트워크 내에서 API 서버와 노드 풀 간의 네트워크 트래픽을 유지합니다. AKS는 프라이빗 API 서버 액세스를 위한 두 가지 방법을 제공합니다.
API Server 가상 네트워크 통합: 이 방법은 API 서버 엔드포인트를 클러스터의 가상 네트워크의 위임된 서브넷에 투영합니다. API 서버는 내부 부하 분산 장치를 사용합니다. 노드는 API 서버의 개인 IP 주소와 직접 통신합니다. 클러스터를 다시 배포하지 않고 공용 네트워크 액세스를 허용하거나 차단할 수 있습니다.
Azure Private Link를 사용하는 프라이빗 클러스터: 이 방법은 Private Link를 사용하여 공용 IP 주소 없이 프라이빗 엔드포인트를 만듭니다. API 서버는 프라이빗 엔드포인트를 통해서만 액세스됩니다. 프라이빗 DNS 영역을 통해 DNS(도메인 이름 시스템)를 구성해야 합니다.
프라이빗 AKS 클러스터는 동일한 가상 네트워크 또는 가상 네트워크 피어링, 가상 프라이빗 네트워크 또는 Azure ExpressRoute를 통해 연결된 리소스에 대한 제어 평면 액세스를 제한합니다. 자세한 내용은 프라이빗 AKS 클러스터만들기를 참조하세요.
권한 있는 IP 주소 범위
권한 있는 IP 주소 범위는 클러스터 보안을 개선하고 공격을 최소화합니다. 이 방법은 공용 AKS 클러스터의 컨트롤 플레인 액세스를 IP 주소 및 CIDR 범위의 특정 목록으로 제한합니다. API 서버는 공개적으로 노출되지만 지정된 IP 주소만 액세스할 수 있습니다.
Private Link 통합
Private Link 서비스는 애플리케이션이 Azure 프라이빗 엔드포인트를 통해 서비스에 비공개로 연결할 수 있는 인프라 구성 요소입니다. 프라이빗 엔드포인트는 가상 네트워크에 정의되며 Azure Load Balancer 인스턴스의 프런트 엔드 IP 구성에 연결됩니다. Private Link 를 사용하면 서비스 공급자가 데이터 반출 위험 없이 Azure 또는 온-프레미스에서 연결하는 테넌트에 서비스를 안전하게 제공할 수 있습니다.
Private Link 서비스 통합을 사용하여 인터넷에 퍼블릭 엔드포인트를 노출하지 않고도 테넌트가 AKS 호스팅 워크로드에 프라이빗 연결을 제공합니다.
자세한 내용은 다중 테넌트 및 Private Link를 참조하세요.
역방향 프록시
역방향 프록시는 들어오는 요청을 보호, 필터링 및 라우팅하기 위해 테넌트 애플리케이션 앞에 배치됩니다. 부하 분산 장치 및 API 게이트웨이로 작동합니다. 역방향 프록시는 부하 분산, SSL(Secure Sockets Layer) 종료 및 계층 7 라우팅과 같은 기능을 지원하여 보안, 성능 및 안정성을 향상합니다. Kubernetes에 널리 사용되는 역방향 프록시에는 다음 구현이 포함됩니다.
NGINX Ingress Controller는 부하 분산, SSL 종료 및 계층 7 라우팅을 지원하는 역방향 프록시 서버입니다. Ingress NGINX 프로젝트는 2026년 3월에 종료됩니다.
Traefik Kubernetes 인그레스 공급자는 인그레스 사양을 지원하여 클러스터 서비스에 대한 액세스를 관리하는 Kubernetes 인그레스 컨트롤러입니다.
HAProxy Kubernetes 수신 컨트롤러 는 TLS(전송 계층 보안) 종료, URL 경로 기반 라우팅 및 기타 표준 기능을 지원하는 Kubernetes의 역방향 프록시입니다.
컨테이너용 Application Gateway 는 AKS 호스팅 애플리케이션에 대해 계층 7 부하 분산을 제공하는 관리되는 ADC(애플리케이션 배달 컨트롤러)입니다. 고급 라우팅 기능, SSL 종료 및 WAF(웹 애플리케이션 방화벽) 기능을 제공하여 일반적인 웹 취약성 및 공격으로부터 테넌트 애플리케이션을 보호합니다. 컨테이너용 Application Gateway는 AGIC를 대체합니다. 새 배포에 컨테이너용 Application Gateway를 사용합니다. 기존 AGIC 배포를 사용할 수 있지만 컨테이너용 Application Gateway로 마이그레이션할 계획입니다.
AKS 호스팅 역방향 프록시를 사용하여 여러 테넌트 애플리케이션에 들어오는 요청을 보호하고 처리하는 경우 다음 권장 사항을 고려합니다.
전용 노드 풀에 역방향 프록시를 호스트하며, 이 노드 풀은 네트워크 대역폭이 높고 가속화된 네트워킹이 설정된 VM 크기를 사용하도록 구성되어 있습니다.
자동 크기 조정을 위해 역방향 프록시를 호스트하는 노드 풀을 구성합니다.
인그레스 컨트롤러 Pod가 트래픽 변동에 즉시 대응하여 확장될 수 있도록 자동 스케일링 정책을 정의합니다. 이 방법은 테넌트 애플리케이션에 대한 대기 시간 및 시간 제한을 증가하지 않습니다.
여러 수신 컨트롤러 인스턴스에서 들어오는 트래픽을 테넌트 애플리케이션으로 분할하여 확장성 및 분리를 높이는 것이 좋습니다.
컨테이너용 Application Gateway를 사용하는 경우 다음 모범 사례를 고려합니다.
서로 다른 테넌트 계층에 대해 별도의 Application Gateway for Containers 인스턴스를 배포하여 격리 및 다른 서비스 수준을 제공합니다. 인프라 운영자가 게이트웨이 리소스를 관리하고 테넌트가 자체 네임스페이스에서 HTTPRoute 리소스를 관리하는 Kubernetes Gateway API 역할 지향 모델을 사용합니다.
네임스페이스 격리를 유지하면서 공유 게이트웨이가 여러 테넌트 네임스페이스에서 백 엔드 서비스로 트래픽을 라우팅할 수 있도록 네임스페이스 간 라우팅을 구성합니다.
탄력적 자동 크기 조정을 사용하면 용량 계획을 수동으로 구성할 필요가 없습니다.
Azure Front Door와 통합
Azure Front Door 는 사용자와 웹 애플리케이션 간의 액세스를 제공하는 글로벌 계층 7 부하 분산 장치 및 클라우드 콘텐츠 배달 네트워크입니다. AKS 호스팅 다중 테넌트 애플리케이션을 공용 인터넷에 노출할 때 요청 가속, SSL 종료, 응답 캐싱, 에지의 WAF, URL 기반 라우팅, 다시 쓰기 및 리디렉션과 같은 Azure Front Door 기능을 사용합니다.
예를 들어 Azure Front Door를 사용하여 각 테넌트에 대해 하나씩 여러 사용자 지정 도메인을 관리하고 모든 트래픽을 단일 호스트 이름으로 구성된 AKS 호스팅 다중 테넌트 애플리케이션으로 라우팅합니다. 트래픽을 백 엔드 애플리케이션으로 라우팅하기 전에 에지에서 SSL 연결을 종료할 수 있습니다.
백 엔드 애플리케이션의 도메인 이름과 일치하도록 요청 원본 호스트 헤더 를 수정하도록 Azure Front Door를 구성합니다. Azure Front Door는 원래 Host 헤더를 X-Forwarded-Host 헤더로 전달하며, 다중 테넌트 애플리케이션 코드는 들어오는 요청을 올바른 테넌트에 연결하는 데 사용할 수 있습니다.
Azure Front Door의 Azure 웹 애플리케이션 방화벽은 웹 애플리케이션에 대한 중앙 집중식 보호를 제공합니다. Azure Web Application Firewall을 사용하여 악의적인 공격으로부터 인터넷에 퍼블릭 엔드포인트를 노출하는 AKS 호스팅 테넌트 애플리케이션을 방어합니다.
Private Link를 사용하여 내부 부하 분산 장치를 통해 AKS 클러스터에서 실행되는 테넌트 애플리케이션에 비공개로 연결하도록 Azure Front Door Premium을 구성합니다. 자세한 내용은 Private Link를 통해 내부 부하 분산 장치 원본에 Azure Front Door Premium 연결을 참조하세요.
아웃바운드 연결
AKS 호스팅 애플리케이션이 많은 데이터베이스 또는 외부 서비스에 연결하는 경우 클러스터는 SNAT 포트 소모를 초래할 수 있습니다. SNAT 포트는 동일한 컴퓨팅 리소스의 애플리케이션에서 고유한 트래픽 흐름을 유지하기 위해 고유 식별자를 생성합니다. 공유 AKS 클러스터에서 여러 테넌트 애플리케이션을 실행하면 많은 아웃바운드 호출이 생성되어 SNAT 포트가 고갈될 수 있습니다. AKS 클러스터는 세 가지 방법으로 아웃바운드 연결을 처리할 수 있습니다.
Azure Load Balancer: AKS는 기본적으로 송신 트래픽 관리를 위해 표준 SKU 부하 분산 장치를 프로비전합니다. 그러나 공용 IP 주소가 허용되지 않거나 송신에 추가 홉이 필요한 경우 기본 구성이 모든 시나리오 요구 사항을 충족하지 못할 수 있습니다. 공용 부하 분산 장치는 아웃바운드 규칙 에서 사용하는 기본 공용 IP 주소로 만들어집니다. 아웃바운드 규칙을 사용하여 공용 표준 부하 분산 장치에 대한 SNAT를 명시적으로 정의할 수 있습니다. 이 구성을 사용하면 부하 분산 장치의 공용 IP 주소를 사용하여 백 엔드 인스턴스에 대한 아웃바운드 인터넷 연결을 제공할 수 있습니다. SNAT 포트 소모를 방지하려면 공용 부하 분산 장치의 아웃바운드 규칙을 구성하여 더 많은 공용 IP 주소를 사용합니다.
자세한 내용은 아웃바운드 규칙통해 아웃바운드에 대한 부하 분산 장치의 프런트 엔드 IP 주소 사용을 참조하세요.
Azure NAT Gateway: Azure NAT Gateway를 사용하여 테넌트 애플리케이션에서 송신 트래픽을 경로 지정하도록 AKS 클러스터를 구성합니다. Azure NAT Gateway는 공용 IP 주소당 최대 64,512개의 아웃바운드 UDP(사용자 데이터그램 프로토콜) 및 TCP(Transmission Control Protocol) 트래픽 흐름을 지원하며 최대 16개의 IP 주소를 지원합니다. Azure NAT Gateway를 사용하여 AKS 클러스터에서 아웃바운드 연결을 처리할 때 SNAT 포트 소모를 방지하려면 더 많은 공용 IP 주소 또는 공용 IP 주소 접두사를 게이트웨이와 연결합니다.
자세한 내용은 다중 테넌트대한
Azure NAT Gateway 고려 사항을 참조하세요. UDR: 공용 IP 주소를 허용하지 않으며 클러스터가 NVA(네트워크 가상 어플라이언스) 뒤에 있어야 하는 시나리오와 같은 사용자 지정 네트워크 시나리오를 지원하도록 AKS 클러스터의 송신 경로를 사용자 지정합니다. UDR용 클러스터를 구성하는 경우 AKS는 송신 경로를 자동으로 구성하지 않습니다. 송신 경로를 구성해야 합니다. 예를 들어 Azure 방화벽을 통해 송신 트래픽을 라우팅합니다.
AKS 클러스터를 미리 구성된 서브넷이 있는 기존 가상 네트워크에 배포하고 명시적 송신을 설정합니다. 방화벽, 게이트웨이 또는 프록시와 같은 어플라이언스로 송신 트래픽을 보냅니다. 어플라이언스는 할당된 공용 IP 주소를 사용하여 NAT(네트워크 주소 변환)를 수행합니다.
허브 네트워크 또는 보안 어플라이언스로 송신을 라우팅할 필요가 없는 경우 Azure NAT Gateway를 사용하여 SNAT 포트 소모를 방지합니다.
모니터링
Azure Monitor 및 클라우드 네이티브 도구를 사용하여 Kubernetes 클러스터를 모니터링 하여 AKS 클러스터 및 테넌트 워크로드의 상태 및 성능을 관찰합니다. Azure Monitor는 로그 및 메트릭, 원격 분석 및 경고를 수집하여 문제를 사전에 감지합니다. Azure Managed Grafana를 사용하여 이 데이터를 시각화합니다.
비용
비용 거버넌스는 비용을 제어하는 정책을 지속적으로 구현하는 프로세스입니다. 네이티브 Kubernetes 도구를 사용하여 리소스 사용량 및 소비를 관리 및 관리하고 기본 인프라를 사전에 모니터링하고 최적화할 수 있습니다. 테넌트당 비용을 계산할 때 테넌트 애플리케이션에서 사용하는 리소스와 관련된 비용을 고려합니다. 테넌트 요금을 청구하는 방법은 솔루션의 테넌트 모델에 따라 달라집니다. 다음 목록에서는 테넌시 모델 비용을 자세히 설명합니다.
완전 다중 테넌트: 단일 다중 테넌트 애플리케이션이 모든 테넌트 요청을 제공하는 경우 리소스 사용량 및 각 테넌트가 생성하는 요청 수를 추적합니다. 그에 따라 고객에게 요금을 청구합니다.
전용 클러스터: 클러스터가 단일 테넌트에 전용인 경우 Azure 리소스 비용을 고객에게 다시 청구하기 쉽습니다. TCO(총 소유 비용)는 VM 수 및 크기, 네트워크 트래픽 비용, 공용 IP 주소, 부하 분산 장치 및 테넌트 솔루션이 사용하는 스토리지 서비스(예: 관리 디스크 또는 Azure Files)를 비롯한 여러 요인에 따라 달라집니다. 비용 청구를 간소화하기 위해 노드 리소스 그룹에서 AKS 클러스터 및 해당 리소스에 태그를 지정합니다. 자세한 내용은 클러스터태그 추가를 참조하세요.
전용 노드 풀: 단일 테넌트 전용의 새 노드 풀 또는 기존 노드 풀에 Azure 태그를 적용합니다. 태그는 노드 풀의 각 노드에 적용되며 업그레이드를 통해 유지됩니다. 태그는 스케일 아웃 작업 중에 노드 풀에 추가된 새 노드에도 적용됩니다. 태그는 정책 추적 및 비용 청구에 도움이 됩니다. 자세한 내용은 노드 풀에 태그 추가를 참조하세요.
기타 리소스: 태그를 사용하여 전용 리소스 비용을 특정 테넌트에 연결합니다. Kubernetes 매니페스트를 사용하여 공용 IP 주소, 파일 및 디스크에 태그를 지정합니다. 이러한 태그는 다른 메서드를 통해 업데이트하더라도 Kubernetes 할당 값을 유지합니다. Kubernetes를 통해 공용 IP 주소, 파일 또는 디스크를 제거하면 해당 태그도 제거됩니다. Kubernetes에서 추적하지 않는 리소스의 태그는 영향을 받지 않습니다. 자세한 내용은 Kubernetes사용하여 태그 추가를 참조하세요.
AKS 비용 분석 기능은 오픈 소스 OpenCost 프로젝트를 기반으로 비용 할당 도구를 배포하는 방법을 제공합니다. 이 기능은 클러스터 및 네임스페이스와 같은 Kubernetes 구문과 Azure 컴퓨팅, 네트워크 및 스토리지 리소스로 범위가 지정된 자세한 비용 할당을 표시합니다.
KubeCost와 같은 오픈 소스 도구를 사용하여 AKS 클러스터에 대한 비용을 모니터링하고 관리합니다. 클러스터 사용자에게 유연한 차지백 또는 쇼백을 지원하기 위해 배포, 서비스, 레이블, Pod 또는 네임스페이스에 대한 비용 할당 범위를 지정합니다.
자세한 내용은 다음 문서를 참조하세요.
Governance
여러 테넌트가 동일한 인프라를 공유하는 경우 데이터 개인 정보 보호, 규정 준수 및 규정 요구 사항을 관리하는 것이 복잡해질 수 있습니다. 강력한 보안 조치 및 데이터 거버넌스 정책을 구현합니다. 공유 AKS 클러스터는 데이터 위반, 무단 액세스 및 데이터 보호 규정을 준수하지 않는 위험을 증가합니다. 각 테넌트에는 고유한 데이터 거버넌스 요구 사항 및 규정 준수 정책이 있어 데이터 보안 및 개인 정보를 보장하기가 어려울 수 있습니다.
Defender for Containers 는 Kubernetes 환경에 대한 위협 탐지 및 보호를 제공하는 클라우드 네이티브 컨테이너 보안 솔루션입니다. Kubernetes 클러스터에서 여러 테넌트를 호스트할 때 이 서비스를 사용하여 데이터 거버넌스 및 규정 준수를 향상시킵니다. Defender for Containers는 중요한 데이터를 보호하고, 컨테이너 동작 및 네트워크 트래픽을 분석하여 위협을 감지하고 대응하며, 규정 요구 사항을 충족하는 데 도움이 됩니다. 감사, 로그 관리 및 보고서 생성을 제공하여 규제 기관 및 감사자 준수를 입증합니다.
기여자
Microsoft는 이 문서를 유지 관리합니다. 다음 기여자는 이 문서를 작성했습니다.
주요 작성자:
기타 기여자:
- 보단 체르치크 | 선임 고객 엔지니어
- John Downs | 주요 소프트웨어 엔지니어 - Azure 패턴 및 사례
- 채드 키텔 | 주요 소프트웨어 엔지니어 - Azure 패턴 및 사례
- 파올로 살바토리 | 수석 고객 엔지니어
- Arsen Vladimirskiy | 수석 고객 엔지니어
LinkedIn 비공개 프로필을 보려면, LinkedIn에 로그인하세요.
관련 리소스
- 다중 테넌트 솔루션 설계자 및 개발자를 위한
리소스