AKS(Azure Kubernetes Service)
AKS 클러스터는 다양한 시나리오와 방법으로 여러 테넌트 간에 공유할 수 있습니다. 경우에 따라 다양한 애플리케이션을 동일한 클러스터에서 실행할 수 있습니다. 다른 경우에는 동일한 애플리케이션의 여러 인스턴스를 각 테넌트에 대해 하나씩 동일한 공유 클러스터에서 실행할 수 있습니다. 다중 테넌트
이 문서에서는 다중 테넌트 시스템을 빌드할 때 사용할 수 있는 AKS의 몇 가지 기능에 대해 설명합니다. Kubernetes 다중 테넌시에 대한 일반적인 지침 및 모범 사례는 Kubernetes 설명서의 다중 테넌트 참조하세요.
다중 테넌트 형식
여러 테넌트에서 AKS 클러스터를 공유하는 방법을 결정하는 첫 번째 단계는 사용할 수 있는 패턴 및 도구를 평가하는 것입니다. 일반적으로 Kubernetes 클러스터의 다중 테넌시는 두 가지 주요 범주에 속하지만 여전히 많은 변형이 가능합니다. Kubernetes 설명서 다중 테넌트용 두 가지 일반적인 사용 사례인 여러 팀과 여러 고객을 설명합니다.
여러 팀
다중 테넌시의 일반적인 형태는 조직 내의 여러 팀 간에 클러스터를 공유하는 것입니다. 각 팀은 하나 이상의 솔루션을 배포, 모니터링 및 운영할 수 있습니다. 이러한 워크로드는 종종 서로 통신하고 동일한 클러스터 또는 다른 호스팅 플랫폼에 있는 다른 내부 또는 외부 애플리케이션과 통신해야 합니다.
또한 이러한 워크로드는 관계형 데이터베이스, NoSQL 리포지토리 또는 동일한 클러스터에서 호스트되거나 Azure에서 PaaS(Platform as a Service) 서비스로 실행되는 메시징 시스템과 같은 서비스와 통신해야 합니다.
이 시나리오에서 팀 구성원은 종종 kubectl
이 시나리오에 대한 자세한 내용은 Kubernetes 설명서의 여러 팀 참조하세요.
여러 고객
다중 테넌트의 또 다른 일반적인 형태에는 SaaS(Software as a Service) 공급업체가 자주 포함됩니다. 또는 서비스 공급자는 고객을 위해 별도의 테넌트로 간주되는 워크로드의 여러 인스턴스를 실행합니다. 이 시나리오에서 고객은 AKS 클러스터에 직접 액세스할 수 없지만 애플리케이션에만 액세스할 수 있습니다. 또한 애플리케이션이 Kubernetes에서 실행되는지도 모릅니다. 비용 최적화는 종종 중요한 문제입니다. 서비스 공급자는 리소스 할당량 및 네트워크 정책같은 Kubernetes 정책을 사용하여 워크로드가 서로 강력하게 격리되도록 합니다.
이 시나리오에 대한 자세한 내용은 Kubernetes 설명서에서 여러 고객 참조하세요.
격리 모델
클러스터 다중 테넌트는 여러 단일 테넌트 전용 클러스터를 관리하는 대신 사용할 수 있습니다. 다중 테넌트 Kubernetes 클러스터의 연산자는 테넌트를 서로 격리해야 합니다. 이 격리는 손상되거나 악의적인 테넌트가 클러스터 및 다른 테넌트에 대해 수행할 수 있는 피해를 최소화합니다.
여러 사용자 또는 팀이 고정된 수의 노드와 동일한 클러스터를 공유하는 경우 한 팀이 리소스의 공평한 점유율 이상을 사용할 수 있습니다. 관리자는 리소스 할당량 사용하여 이 문제를 해결할 수 있습니다.
격리에서 제공하는 보안 수준에 따라 소프트 다중 테넌트와 하드 다중 테넌시를 구분할 수 있습니다.
- 소프트 다중 테넌트는 테넌트가 서로 다른 팀 또는 서로를 신뢰하는 부서인 단일 기업 내에서 적합합니다. 이 시나리오에서 격리는 워크로드 무결성을 보장하고, 여러 내부 사용자 그룹에서 클러스터 리소스를 오케스트레이션하며, 가능한 보안 공격 방지를 목표로 합니다.
- 하드 다중 테넌트는 종종 보안 및 리소스 공유 관점에서 다른 유형의 테넌트가 서로를 신뢰하지 않는 시나리오를 설명합니다.
다중 테넌트 AKS 클러스터를 빌드하려는 경우 다음을 포함하여 Kubernetes 에서 제공하는 리소스 격리 및 다중 테넌트 계층을 고려해야.
- 클러스터
- Namespace
- 노드 풀 또는 노드
- 포드
- 컨테이너
또한 여러 테넌트 간에 서로 다른 리소스를 공유하면 보안에 미치는 영향을 고려해야 합니다. 예를 들어 동일한 노드의 다른 테넌트에서 Pod를 예약하여 클러스터에 필요한 컴퓨터 수를 줄일 수 있습니다. 반면에 특정 워크로드가 정렬되지 않도록 해야 할 수 있습니다. 예를 들어 조직 외부의 신뢰할 수 없는 코드가 중요한 정보를 처리하는 컨테이너와 동일한 노드에서 실행되는 것을 허용하지 않을 수 있습니다.
Kubernetes는 테넌트 간에 완벽하게 안전한 격리를 보장할 수는 없지만 특정 사용 사례에 충분할 수 있는 기능을 제공합니다. 모범 사례로 각 테넌트와 Kubernetes 리소스를 네임스페이스로 구분해야 합니다. 그런 다음
동일한 클러스터에서 동일한 애플리케이션의 여러 인스턴스를 호스트하는 SaaS 공급자 모델을 보여 주는 
AKS를 사용하여 다중 테넌트 솔루션을 디자인하고 빌드하는 방법에는 여러 가지가 있습니다. 이러한 각 방법에는 인프라 배포, 네트워크 토폴로지 및 보안 측면에서 고유한 절충안 집합이 제공됩니다. 이러한 메서드는 격리 수준, 구현 노력, 운영 복잡성 및 비용에 영향을 줍니다. 요구 사항에 따라 컨트롤 및 데이터 평면에서 테넌트 격리를 적용할 수 있습니다.
컨트롤 플레인 격리
컨트롤 플레인 수준에서 격리된 경우 서로 다른 테넌트가 Pod 및 서비스와 같은 서로 다른 리소스에 액세스하거나 영향을 줄 수 없음을 보장합니다. 또한 다른 테넌트 애플리케이션의 성능에 영향을 줄 수 없습니다. 자세한 내용은 Kubernetes 설명서의 컨트롤 평면 격리 참조하세요. 컨트롤 플레인 수준에서 격리를 구현하는 가장 좋은 방법은 각 테넌트의 워크로드와 Kubernetes 리소스를 별도의 네임스페이스로 분리하는 것입니다.
Kubernetes 설명서따르면 네임스페이스 단일 클러스터 내에서 리소스 그룹의 격리를 지원하는 데 사용하는 추상화입니다. 네임스페이스를 사용하여 Kubernetes 클러스터를 공유하는 테넌트 워크로드를 격리할 수 있습니다.
- 네임스페이스를 사용하면 서로의 작업에 영향을 미칠 위험 없이 고유한 테넌트 워크로드가 자체 가상 작업 영역에 존재할 수 있습니다. 조직 내의 개별 팀은 이름이 겹칠 위험 없이 서로 다른 네임스페이스에서 동일한 리소스 이름을 사용할 수 있으므로 네임스페이스를 사용하여 프로젝트를 서로 격리할 수 있습니다.
- RBAC 역할 및 역할 바인딩 네임스페이스 범위 리소스는 테넌트 사용자 및 프로세스가 네임스페이스에서만 리소스 및 서비스에 액세스하도록 제한하는 데 사용할 수 있는 네임스페이스 범위 리소스입니다. 다른 팀은 단일 이름으로 사용 권한 또는 능력 목록을 그룹화하기 위한 역할을 정의할 수 있습니다. 그런 다음 사용자 계정 및 서비스 계정에 이러한 역할을 할당하여 권한 있는 ID만 지정된 네임스페이스의 리소스에 액세스할 수 있도록 합니다.
- CPU 및 메모리에 대한
리소스 할당량은 이름 간격이 지정된 개체입니다. 팀은 이를 사용하여 동일한 클러스터를 공유하는 워크로드가 시스템 리소스 사용과 강력하게 격리되도록 할 수 있습니다. 이 메서드는 별도의 네임스페이스에서 실행되는 모든 테넌트 애플리케이션에 실행해야 하는 리소스가 있는지 확인하고 시끄러운 인접 문제를 방지할 수 있습니다. 이 문제는 동일한 클러스터를 공유하는 다른 테넌트 애플리케이션에 영향을 줄 수 있습니다. - 네트워크 정책 지정된 테넌트 애플리케이션에 허용되는 네트워크 트래픽을 적용하기 위해 팀이 채택할 수 있는 이름 간격 개체입니다. 네트워크 정책을 사용하여 네트워킹 관점에서 동일한 클러스터를 공유하는 고유한 워크로드를 분리할 수 있습니다.
- 고유한 네임스페이스에서 실행되는 팀 애플리케이션은 서로 다른 서비스 계정 사용하여 동일한 클러스터, 외부 애플리케이션 또는 관리되는 서비스 내의 리소스에 액세스할 수 있습니다.
- 네임스페이스를 사용하여 컨트롤 플레인 수준에서 성능을 향상시킵니다. 공유 클러스터의 워크로드가 여러 네임스페이스로 구성된 경우 Kubernetes API는 작업을 실행할 때 검색할 항목이 적습니다. 이 조직은 API 서버에 대한 호출 대기 시간을 줄이고 컨트롤 플레인의 처리량을 늘릴 수 있습니다.
네임스페이스 수준에서 격리에 대한 자세한 내용은 Kubernetes 설명서의 다음 리소스를 참조하세요.
- 네임스페이스
- access 컨트롤
- 할당량
데이터 평면 격리
데이터 평면 격리는 고유 테넌트 Pod 및 워크로드가 서로 충분히 격리되도록 보장합니다. 자세한 내용은 Kubernetes 설명서의 데이터 평면 격리 참조하세요.
네트워크 격리
Kubernetes에서 최신 마이크로 서비스 기반 애플리케이션을 실행하는 경우 서로 통신할 수 있는 구성 요소를 제어하려는 경우가 많습니다. 기본적으로 AKS 클러스터의 모든 Pod는 동일한 클러스터를 공유하는 다른 애플리케이션을 포함하여 제한 없이 트래픽을 보내고 받을 수 있습니다. 보안을 강화하기 위해 트래픽 흐름을 제어하는 네트워크 규칙을 정의할 수 있습니다. 네트워크 정책은 Pod 간 통신에 대한 액세스 정책을 정의하는 Kubernetes 사양입니다. 네트워크 정책 사용하여 동일한 클러스터를 공유하는 테넌트 애플리케이션 간의 통신을 분리할 수 있습니다.
AKS는 네트워크 정책을 구현하는 두 가지 방법을 제공합니다.
- Azure에는 Azure 네트워크 정책이라는 네트워크 정책에 대한 구현이 있습니다.
- Calico 네트워크 정책Tigera설립한 오픈 소스 네트워크 및 네트워크 보안 솔루션입니다.
두 구현 모두 Linux iptables를 사용하여 지정된 정책을 적용합니다. 네트워크 정책은 허용된 IP 쌍 및 허용되지 않는 IP 쌍 집합으로 변환됩니다. 이러한 쌍은 iptables 필터 규칙으로 프로그래밍됩니다.
Azure CNI 네트워크 플러그 인으로 구성된 AKS 클러스터에서만 Azure 네트워크 정책을 사용할 수 있습니다. 그러나 Calico 네트워크 정책은 Azure CNI 및 kubenet모두 지원합니다. 자세한 내용은 Azure Kubernetes Service네트워크 정책을 사용하여 Pod 간 트래픽 보안
자세한 내용은 Kubernetes 설명서의 네트워크 격리 참조하세요.
스토리지 격리
Azure는
AKS에서 실행되는 워크로드는 영구 볼륨을 사용하여 데이터를 저장할 수도 있습니다. Azure에서 Azure Storage에서 지원하는 Kubernetes 리소스로
AKS
예를 들어 각 테넌트에 대한 사용자 지정 스토리지 클래스를 구성할 수 있습니다. 그런 다음 네임스페이스에서 만든 영구 볼륨에 태그를 적용하여 비용을 다시 청구할 수 있습니다. 자세한 내용은 AKSAzure 태그 사용
자세한 내용은 Kubernetes 설명서의 Storage 격리 참조하세요.
노드 격리
시끄러운 인접 문제를
taints, , 노드 레이블, 노드 선택기및 노드 선호도 사용하여 테넌트의 Pod가 특정 노드 또는 노드 풀 집합에서만 실행되도록 제한할 수 있습니다.
일반적으로 AKS는 다음을 비롯한 다양한 수준에서 워크로드 격리를 제공합니다.
- 커널 수준에서 공유 에이전트 노드의 경량 VM(가상 머신)에서 테넌트 워크로드를 실행하고 Kata Containers기반으로 Pod Sandboxing 사용합니다.
- 물리적 수준에서 전용 클러스터 또는 노드 풀에서 테넌트 애플리케이션을 호스팅합니다.
- 하드웨어 수준에서 Azure 전용 호스트에서 테넌트 워크로드를 실행하여 에이전트 노드 VM이 전용 물리적 컴퓨터를 실행하게 하는. 하드웨어 격리는 다른 VM이 전용 호스트에 배치되지 않도록 하며, 이는 테넌트 워크로드에 대한 추가 격리 계층을 제공합니다.
이러한 기술을 결합할 수 있습니다. 예를 들어 Azure Dedicated Host 그룹 테넌트별 클러스터 및 노드 풀을 실행하여 하드웨어 수준에서 워크로드 분리 및 물리적 격리를 달성할 수 있습니다. FIPS(Federal Information Process Standard)
노드 격리를 사용하여 노드 또는 노드 풀 집합의 비용을 단일 테넌트에 쉽게 연결하고 다시 청구합니다. 솔루션에서 채택한 테넌시 모델과 엄격하게 관련이 있습니다.
자세한 내용은 Kubernetes 설명서의 노드 격리 참조하세요.
테넌시 모델
AKS는 더 많은 유형의 노드 격리 및 테넌시 모델을 제공합니다.
자동화된 단일 테넌트 배포
자동화된 단일 테넌트 배포 모델에서는 다음 예제와 같이 각 테넌트에 대한 전용 리소스 집합을 배포합니다.
각각 별도의 배포가 있는 세 개의 테넌트가 표시된 
각 테넌트 워크로드는 전용 AKS 클러스터에서 실행되며 고유한 Azure 리소스 집합에 액세스합니다. 일반적으로 이 모델을 사용하여 빌드하는 다중 테넌트 솔루션은 IaC(Infrastructure as code)광범위하게 사용합니다. 예를 들어
혜택:
- 이 방법의 주요 이점은 각 테넌트 AKS 클러스터의 API 서버가 별개라는 것입니다. 이 방법은 보안, 네트워킹 및 리소스 소비 수준에서 테넌트 간에 완전한 격리를 보장합니다. 컨테이너를 제어하도록 관리하는 공격자는 단일 테넌트에 속하는 컨테이너 및 탑재된 볼륨에만 액세스할 수 있습니다. 완전 격리 테넌트 모델은 규정 준수 오버헤드가 높은 일부 고객에게 중요합니다.
- 테넌트는 서로의 시스템 성능에 영향을 주지 않으므로
시끄러운 인접 문제를 방지할 수 있습니다. 이 고려 사항에는 API 서버에 대한 트래픽이 포함됩니다. API 서버는 Kubernetes 클러스터에서 중요한 공유 구성 요소입니다. API 서버에 대해 규제되지 않은 대용량 트래픽을 생성하는 사용자 지정 컨트롤러는 클러스터 불안정을 일으킬 수 있습니다. 이러한 불안정으로 인해 요청 실패, 시간 제한 및 API 재시도 폭풍이 발생합니다. 작동 시간 SLA 기능을 사용하여 트래픽 수요를 충족하기 위해 AKS 클러스터의 제어 평면을 확장합니다. 그러나 전용 클러스터를 프로비전하는 것이 워크로드 격리 측면에서 강력한 요구 사항을 가진 고객에게 더 나은 솔루션이 될 수 있습니다. - 테넌트 전체에서 업데이트 및 변경 내용을 점진적으로 롤아웃하여 시스템 전체 가동 중단 가능성을 줄일 수 있습니다. 모든 리소스는 단일 테넌트에서 사용되므로 Azure 비용은 테넌트에 쉽게 다시 청구될 수 있습니다.
위험:
- 모든 테넌트는 전용 리소스 집합을 사용하기 때문에 비용 효율성이 낮습니다.
- 각 테넌트에 대해 하나씩 여러 AKS 클러스터에서 유지 관리 작업을 반복해야 하므로 지속적인 유지 관리는 시간이 많이 걸릴 수 있습니다. 운영 프로세스를 자동화하고 환경을 통해 변경 내용을 점진적으로 적용하는 것이 좋습니다. 전체 자산의 보고 및 분석과 같은 다른 배포 간 작업도 유용할 수 있습니다. 여러 배포에서 데이터를 쿼리하고 조작하는 방법을 계획해야 합니다.
완전 다중 테넌트 배포
완전 다중 테넌트 배포에서 단일 애플리케이션은 모든 테넌트의 요청을 제공하고 AKS 클러스터를 포함한 모든 Azure 리소스를 공유합니다. 이 컨텍스트에서는 배포, 모니터링 및 유지 관리할 인프라가 하나만 있습니다. 다음 다이어그램에 나와 있는 것처럼 모든 테넌트는 리소스를 사용합니다.
혜택:
- 이 모델은 공유 구성 요소를 사용하여 솔루션을 운영하는 비용이 낮기 때문에 매력적입니다. 이 테넌트 모델을 사용하는 경우 더 큰 AKS 클러스터를 배포하고 공유 데이터 리포지토리에 대해 더 높은 SKU를 채택해야 할 수 있습니다. 이러한 변경은 데이터 리포지토리와 같은 모든 테넌트의 리소스가 생성하는 트래픽을 유지하는 데 도움이 됩니다.
위험:
- 이 컨텍스트에서 단일 애플리케이션은 모든 테넌트의 요청을 처리합니다. 테넌트가 호출로 애플리케이션을 범람하지 않도록 보안 조치를 설계하고 구현해야 합니다. 이러한 호출은 전체 시스템을 느리게 하고 모든 테넌트에 영향을 줄 수 있습니다.
- 트래픽 프로필이 매우 가변적인 경우 AKS 클러스터 자동 크기 조정기를 구성하여 Pod 및 에이전트 노드 수를 변경해야 합니다. CPU 및 메모리와 같은 시스템 리소스 사용량을 기반으로 구성합니다. 또는 사용자 지정 메트릭에 따라 Pod 및 클러스터 노드 수를 확장하고 확장할 수 있습니다. 예를 들어 보류 중인 요청 수 또는 Kubernetes 기반 KEDA(Event Driven Autoscaler)사용하는 외부 메시징 시스템의 메트릭을 사용할 수 있습니다.
- 각 테넌트에 대한 데이터를 분리하고 서로 다른 테넌트 간에 데이터가 누출되는 것을 방지하기 위해 보호 장치를 구현해야 합니다.
- 실제 사용량에 따라 Azure 비용 개별 테넌트에 추적하고 연결해야 합니다. kubecost
같은 타사 솔루션은 여러 팀과 테넌트에서 비용을 계산하고 분석하는 데 도움이 될 수 있습니다. - 하나의 Azure 리소스 집합만 업데이트하고 단일 애플리케이션을 유지 관리하면 되므로 단일 배포를 사용하면 유지 관리가 더 간단할 수 있습니다. 그러나 인프라 또는 애플리케이션 구성 요소의 변경 내용이 전체 고객 기반에 영향을 줄 수 있으므로 위험할 수도 있습니다.
- 크기 조정 제한도 고려해야 합니다. 공유 리소스 집합이 있는 경우 Azure 리소스 확장 제한에 도달할 가능성이 더 높습니다. 리소스 할당량 한도에 도달하지 않도록 하려면 테넌트를 여러 Azure 구독에 분산할 수 있습니다.
수평 분할된 배포
또는 다중 테넌트 Kubernetes 애플리케이션을 수평 분할하는 것이 좋습니다. 이 방법은 모든 테넌트에서 일부 솔루션 구성 요소를 공유하고 개별 테넌트에 대한 전용 리소스를 배포합니다. 예를 들어 이 그림과 같이 단일 다중 테넌트 Kubernetes 애플리케이션을 빌드한 다음 각 테넌트에 대해 하나씩 개별 데이터베이스를 만들 수 있습니다.
혜택:
- 가로로 분할된 배포는
시끄러운 인접 문제를 완화하는 데 도움이 될 수 있습니다. Kubernetes 애플리케이션에서 트래픽 부하의 대부분이 각 테넌트에 대해 별도로 배포할 수 있는 특정 구성 요소 때문임을 식별하는 경우 이 방법을 고려합니다. 예를 들어 쿼리 로드가 높기 때문에 데이터베이스가 시스템 부하의 대부분을 흡수할 수 있습니다. 단일 테넌트가 솔루션에 많은 수의 요청을 보내는 경우 데이터베이스의 성능이 부정적인 영향을 받을 수 있지만 애플리케이션 계층과 같은 다른 테넌트의 데이터베이스 및 공유 구성 요소는 영향을 받지 않습니다.
위험:
- 수평 분할된 배포에서는 구성 요소, 특히 단일 테넌트에서 사용하는 구성 요소의 자동화된 배포 및 관리를 고려해야 합니다.
- 이 모델은 내부 정책 또는 규정 준수 이유로 다른 테넌트와 리소스를 공유할 수 없는 고객에게 필요한 수준의 격리를 제공하지 않을 수 있습니다.
수직 분할된 배포
여러 AKS 클러스터 또는 노드 풀에서 테넌트를 수직으로 분할하는 하이브리드 모델을 사용하여 단일 테넌트 및 완전 다중 테넌트 모델의 이점을 활용할 수 있습니다. 이 방법은 이전의 두 테넌시 모델에 비해 다음과 같은 이점을 제공합니다.
- 단일 테넌트 및 다중 테넌트 배포의 조합을 사용할 수 있습니다. 예를 들어 대부분의 고객이 다중 테넌트 인프라에서 AKS 클러스터 및 데이터베이스를 공유하게 할 수 있습니다. 더 높은 성능과 격리가 필요한 고객을 위해 단일 테넌트 인프라를 배포할 수도 있습니다.
- 여러 지역 AKS 클러스터에 테넌트 배포가 가능하며 구성이 다를 수 있습니다. 이 기술은 테넌트가 여러 지역에 분산되어 있는 경우에 가장 효과적입니다.
이 테넌시 모델의 다양한 변형을 구현할 수 있습니다. 예를 들어 여러 계층의 기능을 다른 비용으로 사용하여 다중 테넌트 솔루션을 제공하도록 선택할 수 있습니다. 가격 책정 모델은 리소스 공유, 성능, 네트워크 및 데이터 분리 측면에서 각각 증분 수준의 성능 및 격리를 제공하는 여러 SKU를 제공할 수 있습니다. 다음 계층을 고려합니다.
- 기본 계층: 테넌트 요청은 다른 테넌트와 공유되는 단일 다중 테넌트 Kubernetes 애플리케이션에서 제공됩니다. 데이터는 모든 기본 계층 테넌트가 공유하는 하나 이상의 데이터베이스에 저장됩니다.
- 표준 계층: 테넌트 요청은 보안, 네트워킹 및 리소스 사용 측면에서 격리 경계를 제공하는 별도의 네임스페이스에서 실행되는 전용 Kubernetes 애플리케이션에서 제공됩니다. 각 테넌트에 대해 하나씩 모든 테넌트의 애플리케이션은 다른 표준 계층 고객과 동일한 AKS 클러스터 및 노드 풀을 공유합니다.
- 프리미엄 계층: 테넌트 애플리케이션은 전용 노드 풀 또는 AKS 클러스터에서 실행되어 더 높은 SLA, 더 나은 성능 및 높은 수준의 격리를 보장합니다. 이 계층은 테넌트 애플리케이션을 호스트하는 에이전트 노드의 수와 SKU에 따라 유연한 비용 모델을 제공할 수 있습니다. 전용 클러스터 또는 노드 풀에 대한 대체 솔루션으로 Pod Sandboxing 사용하여 고유한 테넌트 워크로드를 격리할 수 있습니다.
다음 다이어그램에서는 테넌트 A와 B가 공유 AKS 클러스터에서 실행되는 반면 테넌트 C는 별도의 AKS 클러스터에서 실행되는 시나리오를 보여 줍니다.
세 개의 테넌트가 표시된 
다음 다이어그램에서는 테넌트 A와 B가 동일한 노드 풀에서 실행되는 반면 테넌트 C는 전용 노드 풀에서 실행되는 시나리오를 보여 줍니다.
세 개의 테넌트가 표시된 
이 모델은 다른 계층에 대해 다른 SLA를 제공할 수도 있습니다. 예를 들어 기본 계층은 99.9% 가동 시간을 제공할 수 있고, 표준 계층은 99.95% 가동 시간을 제공할 수 있으며, 프리미엄 계층은 99.99% 가동 시간을 제공할 수 있습니다. 고가용성 대상을 사용하도록 설정하는 서비스 및 기능을 사용하여 더 높은 SLA를 구현할 수 있습니다.
혜택:
- 여전히 인프라를 공유하고 있으므로 공유 다중 테넌트 배포를 사용할 때의 비용 이점을 얻을 수 있습니다. 여러 기본 계층 및 표준 계층 테넌트 애플리케이션에서 공유되는 클러스터 및 노드 풀을 배포할 수 있습니다. 이 애플리케이션은 에이전트 노드에 대해 저렴한 VM 크기를 사용합니다. 이 방법은 더 나은 밀도와 비용 절감을 보장합니다. 프리미엄 계층 고객의 경우 더 높은 VM 크기 및 최대 Pod 복제본 및 노드 수를 더 높은 가격으로 사용하여 AKS 클러스터 및 노드 풀을 배포할 수 있습니다.
- 전용 시스템 모드 노드 풀에서
CoreDNS ,Konnectivity 또는 Azure Application Gateway 수신 컨트롤러같은 시스템 서비스를 실행할 수 있습니다. taints, , 노드 레이블, 노드 선택기및 노드 선호도 사용하여 하나 이상의 사용자 모드 노드 풀에서 테넌트 애플리케이션을 실행할 수 있습니다. - taints, , 노드 레이블, 노드 선택기및 노드 선호도 사용하여 공유 리소스를 실행할 수 있습니다. 예를 들어 특정 VM 크기, 자동 크기 조정기 설정 및 가용성 영역이 지원되는 전용 노드 풀에 수신 컨트롤러 또는 메시징 시스템을 포함할 수 있습니다.
위험:
- 다중 테넌트 및 단일 테넌트 배포를 모두 지원하도록 Kubernetes 애플리케이션을 디자인해야 합니다.
- 인프라 간 마이그레이션을 허용하려는 경우 고객을 다중 테넌트 배포에서 자체 단일 테넌트 배포로 마이그레이션하는 방법을 고려해야 합니다.
- 더 많은 AKS 클러스터를 모니터링하고 관리하려면 일관된 전략과 단일 창 또는 하나의 관점이 필요합니다.
자동 크기 조정
테넌트 애플리케이션에서 생성하는 트래픽 수요를 따라가기 위해 클러스터 자동 크기 조정기 사용하도록 설정하여 AKS의 에이전트 노드 크기를 조정할 수 있습니다. 자동 크기 조정은 다음과 같은 상황에서 시스템이 응답성을 유지하는 데 도움이 됩니다.
- 트래픽 부하는 특정 작업 시간 또는 연중 기간 동안 증가합니다.
- 테넌트 또는 공유 부하가 클러스터에 배포됩니다.
- 가용성 영역의 중단으로 인해 에이전트 노드를 사용할 수 없게 됩니다.
노드 풀에 대해 자동 크기 조정을 사용하도록 설정하는 경우 예상 워크로드 크기에 따라 최소 및 최대 노드 수를 지정합니다. 최대 노드 수를 구성하면 실행되는 네임스페이스에 관계없이 클러스터의 모든 테넌트 Pod에 충분한 공간을 확보할 수 있습니다.
트래픽이 증가하면 클러스터 자동 크기 조정은 CPU 및 메모리와 같은 리소스 부족으로 인해 Pod가 보류 중인 상태로 전환되지 않도록 새 에이전트 노드를 추가합니다.
부하가 감소하면 클러스터 자동 크기 조정은 지정된 경계에 따라 노드 풀의 에이전트 노드 수를 줄여 운영 비용을 줄일 수 있습니다.
Pod 자동 크기 조정을 사용하여 리소스 요구에 따라 자동으로 Pod 크기를 조정할 수 있습니다.
HorizontalPodAutoscaler CPU 또는 메모리 사용률 또는 사용자 지정 메트릭에 따라 Pod 복제본 수를 자동으로 조정합니다.
VPA(Vertical Pod Autoscaler) Pod에 대한 효율적인 리소스 관리를 가능하게 합니다. Pod에 할당된 CPU 및 메모리를 조정하여 VPA를 사용하면 테넌트 애플리케이션을 실행하는 데 필요한 노드 수를 줄일 수 있습니다. 노드 수를 줄이면 총 소유 비용이 줄어들고
노드 풀에 용량 예약 그룹 할당하여 다양한 테넌트에 대한 리소스 할당 및 격리를 개선합니다.
정비
클러스터 또는 노드 풀 업그레이드 중에 테넌트 애플리케이션에 영향을 줄 수 있는 가동 중지 시간의 위험을 줄이려면 사용량이 많은 시간 동안 AKS 계획된 유지 관리 예약합니다. 주간 유지 관리 기간을 예약하여 워크로드 영향을 최소화하기 위해 테넌트 애플리케이션 및 노드 풀을 실행하는 AKS 클러스터의 제어 평면을 업데이트합니다. 특정 날짜에 일 또는 시간 범위를 지정하여 클러스터에서 주별 유지 관리 기간을 하나 이상 예약할 수 있습니다. 모든 유지 관리 작업은 예약된 기간 동안 발생합니다.
안전
다음 섹션에서는 AKS를 사용하는 다중 테넌트 솔루션에 대한 보안 모범 사례를 설명합니다.
클러스터 액세스
조직 내의 여러 팀 간에 AKS 클러스터를 공유하는 경우 서로 다른 테넌트를 격리하려면 최소 권한
AKS를 사용한 인증 및 권한 부여에 대한 자세한 내용은 다음 문서를 참조하세요.
- AKS 대한
액세스 및 ID 옵션 - AKS 관리형 Microsoft Entra 통합
- AKS Microsoft Entra ID를 사용하여 Kubernetes 역할 기반 액세스 제어
워크로드 ID
단일 AKS 클러스터에서 여러 테넌트 애플리케이션을 호스트하고 각 애플리케이션이 별도의 네임스페이스에 있는 경우 각 워크로드는 다른 Kubernetes 서비스 계정 및 자격 증명을 사용하여 다운스트림 Azure 서비스에 액세스해야 합니다. 서비스 계정은 Kubernetes의 기본 사용자 유형 중 하나입니다. Kubernetes API는 서비스 계정을 보유하고 관리합니다. 서비스 계정 자격 증명은 Kubernetes 비밀로 저장되므로 권한 있는 Pod는 이를 사용하여 API 서버와 통신할 수 있습니다. 대부분의 API 요청은 서비스 계정 또는 일반 사용자 계정에 대한 인증 토큰을 제공합니다.
AKS 클러스터에 배포하는 테넌트 워크로드는 Microsoft Entra 애플리케이션 자격 증명을 사용하여 Azure Key Vault 및 Microsoft Graph와 같은 Microsoft Entra ID로 보호되는 리소스에 액세스할 수 있습니다. Kubernetes Microsoft Entra 워크로드 ID는 Kubernetes 네이티브 기능과 통합되어 외부 ID 공급자와 페더레이션됩니다.
Pod 샌드박싱
AKS에는 컨테이너 애플리케이션과 CPU, 메모리 및 네트워킹과 같은 컨테이너 호스트의 공유 커널 및 컴퓨팅 리소스 간에 격리 경계를 제공하는 Pod Sandboxing이라는 메커니즘이 포함되어 있습니다. Pod Sandboxing은 테넌트 워크로드가 중요한 정보를 보호하고 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 Sandboxing 별도의 클러스터 또는 노드 풀에서 이러한 워크로드를 실행할 필요 없이 동일한 클러스터 노드에서 테넌트 애플리케이션을 강력하게 격리하는 데 도움이 될 수 있습니다. 다른 방법을 사용하려면 코드를 다시 컴파일하거나 다른 호환성 문제를 발생해야 하지만 AKS의 Pod Sandboxing은 향상된 보안 VM 경계 내에서 수정되지 않은 모든 컨테이너를 실행할 수 있습니다.
AKS의 Pod 샌드박싱은 AKS 스택용
자세한 내용은 다음을 참조하세요.
- AKS 사용하여 Pod 샌드박싱
- Pod 샌드박싱 AKS의 Kata VM 격리 컨테이너에 대한
지원
Azure 전용 호스트
Azure Dedicated Host 단일 Azure 구독 전용 물리적 서버를 제공하고 물리적 서버 수준에서 하드웨어 격리를 제공하는 서비스입니다. 지역, 가용성 영역 및 장애 도메인 내에서 이러한 전용 호스트를 프로비전할 수 있으며 VM을 프로비전된 호스트에 직접 배치할 수 있습니다.
AKS에서 Azure Dedicated Host를 사용하는 경우 다음과 같은 몇 가지 이점이 있습니다.
하드웨어 격리는 다른 VM이 전용 호스트에 배치되지 않도록 하며, 이는 테넌트 워크로드에 대한 추가 격리 계층을 제공합니다. 전용 호스트는 동일한 데이터 센터에 배포되며 격리되지 않은 다른 호스트와 동일한 네트워크 및 기본 스토리지 인프라를 공유합니다.
Azure Dedicated Host는 Azure 플랫폼이 시작하는 유지 관리 이벤트를 제어합니다. 유지 관리 기간을 선택하여 서비스에 미치는 영향을 줄이고 테넌트 워크로드의 가용성 및 개인 정보를 보장할 수 있습니다.
Azure Dedicated Host는 SaaS 공급자가 테넌트 애플리케이션이 중요한 정보를 보호하기 위한 규정, 산업 및 거버넌스 규정 준수 요구 사항을 충족하도록 할 수 있습니다. 자세한 내용은 AKS 클러스터Azure Dedicated Host 추가
카르펜터 (미국)
Karpenter Kubernetes용으로 빌드된 오픈 소스 노드 수명 주기 관리 프로젝트입니다. Kubernetes 클러스터에 Karpenter를 추가하면 해당 클러스터에서 워크로드를 실행하는 효율성과 비용이 향상될 수 있습니다. Karpenter는 Kubernetes 스케줄러가 예약할 수 없는 것으로 표시하는 Pod를 감시합니다. 또한 Pod 요구 사항을 충족할 수 있는 노드를 동적으로 프로비전하고 관리합니다.
Karpenter는 관리형 클러스터의 노드 프로비저닝 및 워크로드 배치에 대한 세분화된 제어를 제공합니다. 이 컨트롤은 리소스 할당을 최적화하고, 각 테넌트의 애플리케이션 간에 격리를 보장하고, 운영 비용을 줄여 다중 테넌트가 향상됩니다. AKS에서 다중 테넌트 솔루션을 빌드할 때 Karpenter는 다양한 테넌트를 지원하기 위해 다양한 애플리케이션 요구 사항을 관리하는 데 도움이 되는 유용한 기능을 제공합니다. 예를 들어 GPU 최적화 노드 풀에서 실행하려면 일부 테넌트의 애플리케이션이 필요하고 메모리 최적화 노드 풀에서 실행하려면 다른 테넌트의 애플리케이션이 필요할 수 있습니다. 애플리케이션에 스토리지 대기 시간이 짧은 경우 Karpenter를 사용하여 스토리지 및 애플리케이션 계층을 공동 배치할 수 있도록 특정 가용성 영역에서 실행되는 노드가 Pod에 필요함을 나타낼 수 있습니다.
AKS는 Karpenter를 통해 AKS 클러스터에서 노드 자동 프로비전을 사용하도록 설정합니다. 대부분의 사용자는 노드 자동 프로비전 모드를 사용하여 Karpenter를 관리되는 추가 기능으로 사용하도록 설정해야 합니다. 자세한 내용은 노드 자동 프로비전참조하세요. 고급 사용자 지정이 필요한 경우 Karpenter를 자체 호스팅하도록 선택할 수 있습니다. 자세한 내용은 AKS Karpenter 공급자
기밀 VM
기밀 VM 사용하여 AKS 클러스터에 하나 이상의 노드 풀을 추가하여 테넌트의 엄격한 격리, 개인 정보 보호 및 보안 요구 사항을 해결할 수 있습니다.
기밀 VM은 하드웨어 기반 신뢰할 수 있는 실행 환경사용할 있습니다.
AMD 보안 암호화 가상화 - 보안 중첩 페이징(SEV-SNP) 기밀 VM은 VM 메모리 및 상태에 대한 하이퍼바이저 및 기타 호스트 관리 코드 액세스를 거부하므로 운영자 액세스에 대한 방어 및 심층 보호 계층을 추가합니다. 자세한 내용은 AKS 클러스터기밀 VM 사용
FIPS(Federal Information Process Standards)
FIPS 140-3 정보 기술 제품 및 시스템의 암호화 모듈에 대한 최소 보안 요구 사항을 정의하는 미국 정부 표준입니다. AKS 노드 풀에
Azure 디스크를 사용하여 BYOK(사용자 고유의 키 가져오기)
Azure Storage는 AKS 클러스터의 OS 및 데이터 디스크를 포함하여 미사용 스토리지 계정의 모든 데이터를 암호화합니다. 기본적으로 데이터는 Microsoft 관리형 키로 암호화됩니다. 암호화 키를 보다 제어하기 위해 AKS 클러스터의 나머지 OS 및 데이터 디스크에서 암호화에 사용할 고객 관리형 키를 제공할 수 있습니다. 자세한 내용은 다음을 참조하세요.
- AKSAzure 디스크를 사용하여 BYOK를
. - Azure Disk Storage서버 쪽 암호화를
.
호스트 기반 암호화
AKS의 호스트 기반 암호화
AKS에서 OS 및 데이터 디스크는 기본적으로 플랫폼 관리형 키로 서버 쪽 암호화를 사용합니다. 이러한 디스크의 캐시는 플랫폼 관리형 키를 사용하여 미사용 시 암호화됩니다. 래핑이라고도 하는 봉투 암호화를 사용하여 데이터 보호 키 암호화하는 고유한 키 암호화 키 지정할 수 있습니다. OS 및 데이터 디스크에 대한 캐시는 지정한 BYOK 통해 암호화됩니다.
호스트 기반 암호화는 다중 테넌트 환경에 대한 보안 계층을 추가합니다. OS 및 데이터 디스크 캐시에 있는 각 테넌트의 데이터는 선택한 디스크 암호화 유형에 따라 고객 관리형 또는 플랫폼 관리형 키를 사용하여 미사용 시 암호화됩니다. 자세한 내용은 다음을 참조하세요.
- AKS 호스트 기반 암호화
- AKS Azure 디스크를 사용하여 BYOK
- Azure Disk Storage 서버 쪽 암호화
네트워킹
다음 섹션에서는 AKS를 사용하는 다중 테넌트 솔루션에 대한 네트워킹 모범 사례를 설명합니다.
API 서버에 대한 네트워크 액세스 제한
Kubernetes에서 API 서버는 리소스 만들기 또는 노드 수 조정과 같은 클러스터에서 작업을 수행하라는 요청을 받습니다. 조직 내의 여러 팀에서 AKS 클러스터를 공유하는 경우 다음 솔루션 중 하나를 사용하여 제어 평면에 대한 액세스를 보호합니다.
프라이빗 AKS 클러스터
프라이빗 AKS 클러스터를 사용하면 API 서버와 노드 풀 간의 네트워크 트래픽이 가상 네트워크 내에 남아 있는지 확인할 수 있습니다. 프라이빗 AKS 클러스터에서 컨트롤 플레인 또는 API 서버에는 AKS 클러스터의 동일한 가상 네트워크에 있는 Azure 프라이빗 엔드포인트통해서만 액세스할 수 있는 내부 IP 주소가 있습니다. 마찬가지로 동일한 가상 네트워크의 모든 가상 머신은 프라이빗 엔드포인트를 통해 컨트롤 플레인과 비공개로 통신할 수 있습니다. 자세한 내용은 프라이빗 AKS 클러스터만들기를 참조하세요.
권한 있는 IP 주소 범위
클러스터 보안을 개선하고 공격을 최소화하는 두 번째 옵션은
Private Link 통합
Azure Private Link 서비스 애플리케이션이 가상 네트워크에 정의되고 Azure Load Balancer 인스턴스의 프런트 엔드 IP 구성에 연결된 Azure 프라이빗 엔드포인트 통해 서비스에 개인적으로 연결할 수 있는 인프라 구성 요소입니다. Private Link통해 서비스 공급자는 데이터 반출 위험 없이 Azure 또는 온-프레미스 내에서 연결할 수 있는 테넌트에 서비스를 안전하게 제공할 수 있습니다.
Private Link 서비스 통합 사용하여 퍼블릭 인터넷에 퍼블릭 엔드포인트를 노출하지 않고도 안전한 방식으로 AKS 호스팅 워크로드에 대한 프라이빗 연결을 테넌트에 제공할 수 있습니다.
Azure 호스팅 다중 테넌트 솔루션에 대한 Private Link를 구성하는 방법에 대한 자세한 내용은 다중 테넌트 및 Private Link참조하세요.
역방향 프록시
역방향 프록시 일반적으로 테넌트 애플리케이션 앞에서 들어오는 요청을 보호, 필터링 및 디스패치하는 데 사용되는 부하 분산 장치 및 API 게이트웨이. 인기 있는 역방향 프록시는 부하 분산, SSL 종료 및 계층 7 라우팅과 같은 기능을 지원합니다. 역방향 프록시는 일반적으로 보안, 성능 및 안정성을 높이기 위해 구현됩니다. Kubernetes에 널리 사용되는 역방향 프록시에는 다음 구현이 포함됩니다.
- NGINX 수신 컨트롤러 부하 분산, SSL 종료 및 계층 7 라우팅과 같은 고급 기능을 지원하는 인기 있는 역방향 프록시 서버입니다.
- Traefik Kubernetes 수신 공급자 수신 사양을 지원하여 클러스터 서비스에 대한 액세스를 관리하는 데 사용할 수 있는 Kubernetes 수신 컨트롤러입니다.
- HAProxy Kubernetes 수신 컨트롤러 TLS 종료, URL 경로 기반 라우팅 등의 표준 기능을 지원하는 Kubernetes의 또 다른 역방향 프록시입니다.
- AGIC(Application Gateway 수신 컨트롤러)Kubernetes 애플리케이션이므로 AKS 고객이 Azure 네이티브 Application Gateway L7 부하 분산 장치를 사용하여 테넌트 애플리케이션을 공용 인터넷이나 가상 네트워크에서 실행되는 다른 시스템에 내부적으로 노출할 수 있습니다.
AKS 호스팅 역방향 프록시를 사용하여 여러 테넌트 애플리케이션에 들어오는 요청을 보호하고 처리하는 경우 다음 권장 사항을 고려합니다.
- 높은 네트워크 대역폭 및 가속화된 네트워킹 사용하도록 설정된 VM 크기를 사용하도록 구성된 전용 노드 풀에서 역방향 프록시를 호스트합니다.
- 자동 크기 조정을 위해 역방향 프록시를 호스팅하는 노드 풀을 구성합니다.
- 테넌트 애플리케이션에 대한 대기 시간 및 시간 제한을 늘리지 않도록 하려면 수신 컨트롤러 Pod 수를 즉시 확장하고 트래픽 변동에 맞게 계약할 수 있도록 자동 크기 조정 정책을 정의합니다.
- 수신 컨트롤러의 여러 인스턴스에서 테넌트 애플리케이션으로 들어오는 트래픽을 분할하여 확장성 및 분리 수준을 높이는 것이 좋습니다.
AZURE AGIC(Application Gateway 수신 컨트롤러)사용하는 경우 다음 모범 사례를 구현하는 것이 좋습니다.
- 수신 컨트롤러가 자동 크기 조정사용하는 Application Gateway 구성합니다. 자동 크기 조정을 사용하도록 설정하면 애플리케이션 트래픽 요구 사항에 따라 애플리케이션 게이트웨이 및 WAF(웹 애플리케이션 방화벽) v2 SKU가 확장되거나 확장됩니다. 이 모드는 애플리케이션에 더 나은 탄력성을 제공하고 애플리케이션 게이트웨이 크기 또는 인스턴스 수를 추측할 필요가 없습니다. 또한 이 모드를 사용하면 게이트웨이가 최대 최대 트래픽 부하에 대해 최대 프로비전된 용량에서 실행될 필요가 없으므로 비용을 절감할 수 있습니다. 최소(및 선택적으로 최대) 인스턴스 수를 지정해야 합니다.
- 테넌트 애플리케이션 수가
최대 사이트 양을 초과하는 경우 각각 별도의 애플리케이션 게이트웨이 연결된AGIC 여러 인스턴스를 배포하는 것이 좋습니다. 각 테넌트 애플리케이션이 전용 네임스페이스에서 실행한다고 가정하면 여러 네임스페이스 지원 사용하여 AGIC더 많은 인스턴스에 테넌트 애플리케이션을 분산합니다.
Azure Front Door와 통합
Azure Front Door 전 세계 사용자와 웹 애플리케이션 간에 빠르고 안정적이며 안전한 액세스를 제공하는 Microsoft의 글로벌 계층 7 부하 분산 장치 및 최신 CDN(클라우드 콘텐츠 배달 네트워크)입니다. Azure Front Door는 AKS 호스팅 다중 테넌트 애플리케이션을 공용 인터넷에 노출할 때 사용할 수 있는 요청 가속, SSL 종료, 응답 캐싱, 에지의 WAF, URL 기반 라우팅, 다시 쓰기 및 리디렉션과 같은 기능을 지원합니다.
예를 들어 AKS 호스팅 다중 테넌트 애플리케이션을 사용하여 모든 고객의 요청을 처리할 수 있습니다. 이 컨텍스트에서는 Azure Front Door를 사용하여 각 테넌트에 대해 하나씩 여러 사용자 지정 도메인을 관리할 수 있습니다. 에지에서 SSL 연결을 종료하고 모든 트래픽을 단일 호스트 이름으로 구성된 AKS 호스팅 다중 테넌트 애플리케이션으로 라우팅할 수 있습니다.
Azure Front Door 및 AKS가 연결하는 방법을 보여 주는 
백 엔드 애플리케이션의 도메인 이름과 일치하도록 요청 원본 호스트 헤더 수정하도록 Azure Front Door를 구성할 수 있습니다. 클라이언트에서 보낸 원래
Azure Front Door의 Azure Web Application Firewall웹 애플리케이션에 대한 중앙 집중식 보호를 제공합니다. 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 Load Balancer를 프로비전합니다. 그러나 공용 IP 주소가 허용되지 않거나 송신에 추가 홉이 필요한 경우 기본 설정이 모든 시나리오의 요구 사항을 충족하지 못할 수 있습니다. 기본적으로 공용 부하 분산 장치는 아웃바운드 규칙이 사용할 기본 공용 IP 주소로 만들어집니다. 아웃바운드 규칙을 사용하면 공용 표준 부하 분산 장치에 대한 SNAT를 명시적으로 정의할 수 있습니다. 이 구성을 사용하면 부하 분산 장치의 공용 IP 주소를 사용하여 백 엔드 인스턴스에 대한 아웃바운드 인터넷 연결을 제공할 수 있습니다. 필요한 경우 SNAT 포트 소모 방지하기 위해 공용 부하 분산 장치의 아웃바운드 규칙을 구성하여 더 많은 공용 IP 주소를 사용할 수 있습니다. 자세한 내용은 아웃바운드 규칙통해 아웃바운드에 대한 부하 분산 장치의 프런트 엔드 IP 주소 사용을 참조하세요. - azure NAT Gateway
: Azure NAT Gateway를 사용하여 테넌트 애플리케이션에서 송신 트래픽을 라우팅하도록 AKS 클러스터를 구성할 수 있습니다. NAT 게이트웨이는 공용 IP 주소당 최대 64,512개의 아웃바운드 UDP 및 TCP 트래픽 흐름을 허용하며 최대 16개의 IP 주소를 허용합니다. NAT 게이트웨이를 사용하여 AKS 클러스터에서 아웃바운드 연결을 처리할 때 SNAT 포트 소모 위험을 방지하기 위해 더 많은 공용 IP 주소 또는 공용 IP 주소 접두사 게이트웨이에 연결할 수 있습니다. 자세한 내용은 다중 테넌트 대한Azure NAT Gateway 고려 사항을 참조하세요. - UDR(사용자 정의 경로): 공용 IP 주소를 허용하지 않으며 클러스터가 NVA(네트워크 가상 어플라이언스) 뒤에 있어야 하는 것과 같은 사용자 지정 네트워크 시나리오를 지원하도록 AKS 클러스터의 송신 경로를 사용자 지정할 수 있습니다. 사용자 정의 라우팅클러스터를 구성하는 경우 AKS는 송신 경로를 자동으로 구성하지 않습니다. 송신 설정을 완료해야 합니다. 예를 들어 Azure Firewall통해 송신 트래픽을 라우팅합니다. 이전에 구성한 서브넷을 사용하여 AKS 클러스터를 기존 가상 네트워크에 배포해야 합니다. 표준 부하 분산 장치 아키텍처를 사용하지 않는 경우 명시적 송신을 설정해야 합니다. 따라서 이 아키텍처를 사용하려면 방화벽, 게이트웨이 또는 프록시와 같은 어플라이언스에 송신 트래픽을 명시적으로 보내야 합니다. 또는 아키텍처를 사용하면 표준 부하 분산 장치 또는 어플라이언스에 할당된 공용 IP에서 NAT(네트워크 주소 변환)를 수행할 수 있습니다.
모니터링
Azure Monitor 및 컨테이너 인사이트 사용하여 공유 AKS 클러스터에서 실행되는 테넌트 애플리케이션을 모니터링하고 개별 네임스페이스에 대한 비용 분석을 계산할 수 있습니다. Azure Monitor를 사용하여 AKS의 상태 및 성능을 모니터링합니다. 여기에는 로그 및 메트릭컬렉션, 원격 분석 및 수집된 데이터의 시각화가 포함되어 추세를 식별하고 중요한 문제를 사전에 알리는 경고를 구성합니다. 컨테이너 인사이트 사용하도록 설정하여 이 모니터링을 확장할 수 있습니다.
Kubernetes 모니터링에 널리 사용되는 Prometheus 및 Grafana같은 오픈 소스 도구를 채택할 수도 있습니다. 또는 모니터링 및 관찰성을 위해 타사 도구를 채택할 수 있습니다.
비용
비용 거버넌스는 비용을 제어하는 정책을 구현하는 지속적인 프로세스입니다. Kubernetes 컨텍스트에는 조직에서 비용을 제어하고 최적화하는 데 사용할 수 있는 몇 가지 방법이 있습니다. 이러한 방법에는 네이티브 Kubernetes 도구를 사용하여 리소스 사용량 및 소비를 관리 및 관리하고 기본 인프라를 사전에 모니터링하고 최적화하는 것이 포함됩니다. 테넌트당 비용을 계산할 때는 테넌트 애플리케이션에서 사용하는 리소스와 관련된 비용을 고려해야 합니다. 테넌트에 요금을 다시 부과하는 방법은 솔루션이 채택하는 테넌트 모델에 따라 달라집니다. 다음 목록에서는 테넌시 모델에 대해 자세히 설명합니다.
- 완전 다중 테넌트: 단일 다중 테넌트 애플리케이션이 모든 테넌트 요청을 제공하는 경우 리소스 사용량 및 각 테넌트가 생성하는 요청 수를 추적해야 합니다. 그런 다음 그에 따라 고객에게 요금을 부과합니다.
- 전용 클러스터: 클러스터가 단일 테넌트에 전용인 경우 Azure 리소스 비용을 고객에게 다시 청구하기 쉽습니다. 총 소유 비용은 VM의 수와 크기, 네트워크 트래픽의 네트워킹 비용, 공용 IP 주소, 부하 분산 장치 및 스토리지 서비스(예: 관리 디스크 또는 테넌트 솔루션에서 사용하는 Azure 파일)를 비롯한 여러 요인에 따라 달라집니다. 비용 청구 작업을 용이하게 하기 위해 노드 리소스 그룹에서 AKS 클러스터 및 해당 리소스에 태그를 지정할 수 있습니다. 자세한 내용은 클러스터태그 추가를 참조하세요.
- 전용 노드 풀: 단일 테넌트에 전용인 새 노드 풀 또는 기존 노드 풀에 Azure 태그를 적용할 수 있습니다. 태그는 노드 풀 내의 각 노드에 적용되며 업그레이드를 통해 유지됩니다. 태그는 스케일 아웃 작업 중에 노드 풀에 추가되는 새 노드에도 적용됩니다. 태그를 추가하면 정책 추적 또는 비용 청구와 같은 작업에 도움이 될 수 있습니다. 자세한 내용은 노드 풀에 태그 추가를 참조하세요.
- 기타 리소스: 태그를 사용하여 전용 리소스의 비용을 지정된 테넌트에 연결할 수 있습니다. 특히 Kubernetes 매니페스트를 사용하여 공용 IP 주소, 파일 및 디스크에 태그를 지정할 수 있습니다. 이러한 방식으로 설정된 태그는 나중에 다른 메서드를 사용하여 업데이트하더라도 Kubernetes 값을 유지 관리합니다. 공용 IP 주소, 파일 또는 디스크가 Kubernetes를 통해 제거되면 Kubernetes가 설정하는 모든 태그가 제거됩니다. Kubernetes에서 추적하지 않는 리소스의 태그는 영향을 받지 않습니다. 자세한 내용은 Kubernetes사용하여 태그 추가를 참조하세요.
kubeCost
다중 테넌트 애플리케이션에 대한 비용의 측정, 할당 및 최적화에 대한 자세한 내용은 다중 테넌트 솔루션비용 관리 및 할당에 대한
거버넌스
여러 테넌트가 동일한 인프라를 공유하는 경우 데이터 개인 정보 보호, 규정 준수 및 규정 요구 사항을 관리하는 것이 복잡해질 수 있습니다. 강력한 보안 조치 및 데이터 거버넌스 정책을 구현해야 합니다. 공유 AKS 클러스터는 데이터 위반, 무단 액세스 및 데이터 보호 규정을 준수하지 않는 위험이 더 높습니다. 각 테넌트에는 고유한 데이터 거버넌스 요구 사항 및 규정 준수 정책이 있어 데이터의 보안 및 개인 정보를 보장하기가 어려울 수 있습니다.
Microsoft Defender for Containers Kubernetes 환경에 대한 위협 탐지 및 보호 기능을 제공하는 클라우드 네이티브 컨테이너 보안 솔루션입니다. Defender for Containers를 사용하면 Kubernetes 클러스터에서 여러 테넌트를 호스트할 때 데이터 거버넌스 및 규정 준수 상태를 향상시킬 수 있습니다. Defender for Containers를 사용하여 중요한 데이터를 보호하고, 컨테이너 동작 및 네트워크 트래픽을 분석하여 위협을 감지 및 대응하고, 규정 요구 사항을 충족할 수 있습니다. 감사 기능, 로그 관리 및 보고서 생성을 제공하여 규제 기관 및 감사자 준수를 입증합니다.
참여자
이 문서는 Microsoft에서 유지 관리합니다. 그것은 원래 다음 기여자에 의해 작성되었습니다.
주 작성자:
- 파올로 살바토리 | 수석 고객 엔지니어
기타 기여자:
- 보단 체르치크 | 선임 고객 엔지니어
- John Downs | 주요 소프트웨어 엔지니어
- 채드 키텔 | 주요 소프트웨어 엔지니어
- 아르센 블라디미르스키 | 수석 고객 엔지니어
관련 리소스
- 다중 테넌트 솔루션 설계자 및 개발자를 위한
리소스