편집

다음을 통해 공유

다중 테넌시를 위한 AKS(Azure Kubernetes Service) 고려 사항

Azure
AKS(Azure Kubernetes Service)

AKS(Azure Kubernetes Service)는 운영 오버헤드를 Azure 클라우드 플랫폼으로 오프로드하여 Azure에서 관리되는 Kubernetes 클러스터 배포를 단순화합니다. 호스팅되는 Kubernetes 서비스인 Azure는 상태 모니터링 및 유지 관리 같은 중요 작업을 처리합니다. Azure 플랫폼에서 AKS 컨트롤 플레인을 관리하며, 애플리케이션을 실행하는 AKS 노드에 대해서만 비용을 지불합니다.

AKS 클러스터는 다양한 시나리오 및 방법으로 여러 테넌트 간에 공유할 수 있습니다. 경우에 따라 다양한 애플리케이션을 동일한 클러스터에서 실행할 수 있습니다. 다른 경우에는 동일한 애플리케이션의 여러 인스턴스를 각 테넌트마다 하나씩 동일한 공유 클러스터에서 실행할 수 있습니다. 이러한 모든 유형의 공유는 상위 개념인 다중 테넌시를 사용하여 자주 설명됩니다. Kubernetes에는 최종 사용자 또는 테넌트에 대한 최고위 개념이 없습니다. 하지만 다양한 테넌트 요구 사항을 관리하는 데 도움이 되는 몇 가지 기능을 제공합니다.

이 문서에서는 다중 테넌트 시스템을 빌드할 때 유용한 AKS의 몇 가지 기능에 대해 설명합니다. Kubernetes 다중 테넌시에 대한 일반적인 참고 자료 및 모범 사례는 Kubernetes 설명서의 다중 테넌시를 참조하세요.

다중 테넌시 유형

여러 테넌트에서 AKS 클러스터를 공유하는 방법을 결정하는 첫 번째 단계는 원하는 경우 패턴 및 도구를 평가하는 것입니다. 일반적으로 Kubernetes 클러스터의 다중 테넌시는 두 가지 주요 범주로 분류되지만 여전히 많은 변형이 가능합니다. Kubernetes 설명서 에서는 다중 테넌시에 대한 두 가지 일반적인 사용 사례인 여러 팀과 여러 고객을 설명합니다.

여러 팀

일반적인 형태의 다중 테넌시는 조직 내의 여러 팀 간에 클러스터를 공유하는 것입니다. 각 팀은 하나 이상의 솔루션을 배포, 모니터링 및 운영할 수 있습니다. 이러한 워크로드는 종종 서로 통신하고 동일한 클러스터 또는 다른 호스트 플랫폼에 있는 다른 내부 또는 외부 애플리케이션과 통신해야 합니다.

또한 이러한 워크로드는 관계형 데이터베이스, NoSQL 리포지토리 또는 동일한 클러스터에서 호스트되거나 Azure에서 PaaS 서비스로 실행되는 메시징 시스템과 같은 서비스와 통신해야 합니다.

이 시나리오에서 팀 구성원은 kubectl과 같은 도구를 통해 Kubernetes 리소스에 직접 액세스할 수 있는 경우가 많습니다. 또는 구성원은Flux 및 Argo CD와 같은 GitOps 컨트롤러 또는 다른 유형의 릴리스 자동화 도구를 통해 간접적으로 액세스할 수 있습니다.

이 시나리오에 대한 자세한 내용은 Kubernetes 설명서의 여러 팀을 참조하세요.

여러 고객

다중 테넌시의 또 다른 일반적인 형태에는 SaaS(Software-as-a-Service) 공급업체가 자주 포함됩니다. 또는 서비스 공급자는 별도의 테넌트로 간주되는 고객을 위해 워크로드의 여러 인스턴스를 실행합니다. 이 시나리오에서 고객은 AKS 클러스터에 직접 액세스할 수 없지만 애플리케이션에만 액세스할 수 있습니다. 또한 애플리케이션이 Kubernetes에서 실행되는지도 모릅니다. 비용 최적화는 종종 중요한 문제입니다. 서비스 공급자는 리소스 할당량 및 네트워크 정책과 같은 Kubernetes 정책을 사용하여 워크로드가 서로 강력하게 격리되도록 합니다.

이 시나리오에 대한 자세한 내용은 Kubernetes 설명서의 여러 고객을 참조하세요.

격리 모델

Kubernetes 설명서에 따르면 다중 테넌트 Kubernetes 클러스터는 일반적으로 테넌트라고 하는 여러 사용자 및 워크로드가 공유합니다. 이 정의에는 조직 내에서 서로 다른 팀 또는 부서가 공유하는 Kubernetes 클러스터가 포함됩니다. 또한 SaaS(Software-as-a-Service) 애플리케이션의 고객별 인스턴스에서 공유하는 클러스터도 포함됩니다.

클러스터 다중 테넌트는 많은 단일 테넌트 전용 클러스터를 관리하는 대안입니다. 다중 테넌트 Kubernetes 클러스터의 운영자는 테넌트를 서로 격리해야 합니다. 이 격리는 손상된 테넌트 또는 악의적인 테넌트가 클러스터 및 다른 테넌트에서 미칠 수 있는 손상을 최소화합니다.

여러 사용자 또는 팀이 고정된 수의 노드로 동일한 클러스터를 공유하는 경우 한 팀이 공평하게 정해진 리소스 점유율 이상을 사용할 수 있다는 우려가 있습니다. 관리자는 리소스 할당량이라는 도구를 통해 이 문제를 해결할 수 있습니다.

격리에서 제공하는 보안 수준에 따라 소프트 다중 테넌시와 하드 다중 테넌시를 구분할 수 있습니다.

  • 소프트 다중 테넌트는 테넌트가 서로 신뢰하는 서로 다른 팀 또는 부서인 단일 기업 내에서 적합합니다. 이 시나리오에서 격리는 워크로드 무결성을 보장하고, 여러 내부 사용자 그룹에서 클러스터 리소스를 오케스트레이션하고, 가능한 보안 공격을 방어하는 것을 목표로 합니다.
  • 하드 다중 테넌시는 다른 유형의 테넌트가 종종 보안 및 리소스 공유 관점에서 서로를 신뢰하지 않는 시나리오를 설명하는 데 사용됩니다.

다중 테넌트 AKS(Azure Kubernetes Service) 클러스터를 구축하려는 경우 Kubernetes에서 제공하는 다음과 같은 리소스 격리 및 다중 테넌시 계층을 고려해야 합니다.

  • 클러스터
  • 네임스페이스
  • 노드 풀 또는 노드
  • Pod
  • 컨테이너

또한 여러 테넌트 간에 서로 다른 리소스를 공유할 때 보안에 미치는 영향을 고려해야 합니다. 예를 들어, 동일한 노드에 있는 다른 테넌트의 Pod를 예약하면 클러스터에 필요한 컴퓨터 수를 줄일 수 있습니다. 반면에 특정 워크로드가 같은 위치에 배치되는 것을 방지해야 할 수도 있습니다. 예를 들어 조직 외부의 신뢰할 수 없는 코드가 중요한 정보를 처리하는 컨테이너와 동일한 노드에서 실행되는 것을 허용하지 않을 수 있습니다.

Kubernetes는 테넌트 간의 완벽한 보안 격리를 보장할 수 없지만 특정 사용 사례에 충분할 수 있는 기능을 제공합니다. 각 테넌트와 해당 Kubernetes 리소스를 네임스페이스로 분리하는 것이 모범 사례입니다. 그런 다음 Kubernetes RBAC(역할 기반 액세스 제어) 및 네트워크 정책을 사용하여 테넌트 격리를 적용할 수 있습니다. 예를 들어 다음 그림은 각 테넌트에 대해 하나씩 동일한 클러스터에서 동일한 애플리케이션의 여러 인스턴스를 호스트하는 일반적인 SaaS 공급자 모델을 보여 줍니다. 각 애플리케이션은 별도의 네임스페이스에 있습니다.

동일한 클러스터에서 동일한 애플리케이션의 여러 인스턴스를 호스트하는 SaaS 공급자 모델을 보여 주는 다이어그램.

AKS(Azure Kubernetes Service)를 사용하여 다중 테넌트 솔루션을 설계하고 빌드하는 방법에는 여러 가지가 있습니다. 이러한 각 메서드는 인프라 배포, 네트워크 토폴로지 및 보안 측면에서 고유한 절충안 집합과 함께 제공됩니다. 이러한 메서드는 격리 수준, 구현 노력, 운영 복잡성 및 비용에 영향을 줍니다. 요구 사항에 따라 컨트롤 플레인 및 데이터 평면에서 테넌트 격리를 적용할 수 있습니다.

컨트롤 플레인 격리

컨트롤 플레인 수준에서 격리된 경우 서로 다른 테넌트가 Pod 및 서비스와 같은 서로 다른 리소스에 액세스하거나 영향을 줄 수 없음을 보장합니다. 또한 다른 테넌트 애플리케이션의 성능에 영향을 미칠 수 없습니다. 자세한 내용은 Kubernetes 설명서의 컨트롤 플레인 격리를 참조하세요. 컨트롤 플레인 수준에서 격리를 구현하는 가장 좋은 방법은 각 테넌트의 워크로드와 Kubernetes 리소스를 별도의 네임스페이스로 분리하는 것입니다.

Kubernetes 설명서에 따르면 네임스페이스는 단일 클러스터 내에서 리소스 그룹의 격리를 지원하는 데 사용되는 추상화입니다. 네임스페이스를 사용하여 Kubernetes 클러스터를 공유하는 테넌트 워크로드를 격리할 수 있습니다.

  • 네임스페이스를 사용하면 서로의 작업에 영향을 미칠 위험 없이 고유한 테넌트 워크로드가 자체 가상 작업 영역에 존재할 수 있습니다. 조직 내의 별도 팀은 네임스페이스를 사용하여 이름이 겹칠 위험 없이 서로 다른 네임스페이스에서 동일한 리소스 이름을 사용할 수 있으므로 프로젝트를 서로 격리할 수 있습니다.
  • RBAC 역할 및 역할 바인딩은 팀에서 테넌트 사용자 및 프로세스가 네임스페이스에서만 리소스 및 서비스에 액세스하도록 제한하는 데 사용할 수 있는 네임스페이스 범위 리소스입니다. 서로 다른 팀은 단일 이름으로 권한 또는 기능 목록을 그룹화하기 위한 역할을 정의할 수 있습니다. 그런 다음 이러한 역할을 사용자 계정 및 서비스 계정에 할당하여 권한 있는 ID만 지정된 네임스페이스의 리소스에 액세스할 수 있도록 합니다.
  • CPU 및 메모리에 대한 리소스 할당량은 네임스페이스 개체입니다. 팀은 이를 사용하여 동일한 클러스터를 공유하는 워크로드가 시스템 리소스 사용량과 강력하게 격리되도록 할 수 있습니다. 이 메서드는 별도의 네임스페이스에서 실행되는 모든 테넌트 애플리케이션에 실행하는 데 필요한 리소스가 있는지 확인하고, 동일한 클러스터를 공유하는 다른 테넌트 애플리케이션에 영향을 줄 수 있는 노이지 네이버 이슈를 방지할 수 있습니다.
  • 네트워크 정책은 팀이 지정된 테넌트 애플리케이션에 허용되는 네트워크 트래픽을 적용하기 위해 채택할 수 있는 이름 지정 개체입니다. 네트워크 정책을 사용하여 네트워킹 관점에서 동일한 클러스터를 공유하는 고유한 워크로드를 분리할 수 있습니다.
  • 고유한 네임스페이스에서 실행되는 팀 애플리케이션은 서로 다른 서비스 계정을 사용하여 동일한 클러스터, 외부 애플리케이션 또는 관리되는 서비스 내의 리소스에 액세스할 수 있습니다.
  • 네임스페이스를 사용하여 컨트롤 플레인 수준에서 성능을 향상시킵니다. 공유 클러스터의 워크로드가 여러 네임스페이스로 구성된 경우 Kubernetes API는 작업을 실행할 때 검색할 항목이 적습니다. 이 조직은 API 서버에 대한 호출 대기 시간을 줄이고 컨트롤 플레인의 처리량을 늘릴 수 있습니다.

네임스페이스 수준의 격리에 대한 자세한 내용은 Kubernetes 설명서의 다음 리소스를 참조하세요.

데이터 평면 격리

데이터 평면 격리는 고유한 테넌트의 Pod 및 워크로드가 서로 충분히 격리되도록 보장합니다. 자세한 내용은 Kubernetes 설명서의 데이터 평면 격리를 참조하세요.

네트워크 격리

Kubernetes에서 최신 마이크로 서비스 기반 애플리케이션을 실행할 경우 어느 구성 요소들이 서로 통신할 수 있는지 제어하고 싶을 때가 있습니다. 기본적으로 AKS 클러스터의 모든 Pod는 동일한 클러스터를 공유하는 다른 애플리케이션을 포함하여 제한 없이 트래픽을 보내고 받을 수 있습니다. 보안을 강화하기 위해 트래픽의 흐름을 제어하는 규칙을 정의할 수 있습니다. 네트워크 정책은 Pod 간의 통신에 대한 액세스 정책을 정의하는 Kubernetes 사양입니다. 네트워크 정책을 사용하여 동일한 클러스터를 공유하는 테넌트 애플리케이션 간의 통신을 분리할 수 있습니다.

AKS(Azure Kubernetes Service)는 네트워크 정책을 구현하는 두 가지 방법을 제공합니다.

  1. Azure에는 Azure 네트워크 정책이라는 네트워크 정책에 대한 구현이 있습니다.
  2. Calico 네트워크 정책은 Tigera가 만든 오픈 소스 네트워크 및 네트워크 보안 솔루션입니다.

두 구현 모두 Linux IPTables를 사용하여 지정된 정책을 적용합니다. 네트워크 정책은 허용 및 허용되지 않는 IP 쌍 집합으로 변환됩니다. 이러한 쌍은 IPTable 필터 규칙으로 프로그래밍됩니다. Azure CNI 네트워크 플러그 인으로 구성된 AKS 클러스터에서만 Azure 네트워크 정책을 사용할 수 있습니다. 그러나 Calico 네트워크 정책은 Azure CNI와 kubenet을 모두 지원합니다. 자세한 내용은 AKS(Azure Kubernetes Service)에서 네트워크 정책을 사용하여 Pod 간 트래픽 보호를 참조하세요.

자세한 내용은 Kubernetes 설명서의 네트워크 격리를 참조하세요.

스토리지 격리

Azure는 Azure SQL Database 및 Azure Cosmos DB와 같은 다양한 관리형 PaaS(Platform-as-a-Service) 데이터 리포지토리 집합과 워크로드에 대한 영구 볼륨으로 사용할 수 있는 기타 스토리지 서비스를 제공합니다. 공유 AKS 클러스터에서 실행되는 테넌트 애플리케이션은 데이터베이스 또는 파일 저장소를 공유하거나 전용 데이터 리포지토리 및 스토리지 리소스를 사용할 수 있습니다. 다중 테넌트 시나리오에서 데이터를 관리하기 위한 다양한 전략 및 접근 방식에 대한 자세한 내용은 다중 테넌트 솔루션의 스토리지 및 데이터에 대한 아키텍처 접근 방식을 참조하세요.

AKS(Azure Kubernetes Service)에서 실행되는 워크로드는 영구 볼륨을 사용하여 데이터를 저장할 수도 있습니다. Azure에서 Azure Storage에서 지원되는 Kubernetes 리소스로 영구 볼륨을 만들 수 있습니다. 데이터 볼륨을 수동으로 만들어 Pod에 직접 할당하거나 AKS에서 영구 볼륨 클레임을 사용하여 자동으로 만들 수 있습니다. AKS는 Azure Disks, Azure Files 및 Azure NetApp Files에서 지원되는 영구 볼륨을 만드는 기본 제공 스토리지 클래스를 제공합니다. 자세한 내용은 AKS(Azure Kubernetes Service)의 애플리케이션에 대한 스토리지 옵션을 참조하세요. 보안 및 복원력을 위해 emptyDir 및 hostPath를 통해 에이전트 노드에서 로컬 스토리지를 사용하지 않아야 합니다.

AKS 기본 제공 스토리지 클래스가 하나 이상의 테넌트에게 적합하지 않은 경우 사용자 지정 스토리지 클래스를 빌드하여 다양한 테넌트 요구 사항을 해결할 수 있습니다. 이러한 요구 사항에는 볼륨 크기, 스토리지 SKU, SLA(서비스 수준 계약), 백업 정책 및 가격 책정 계층이 포함됩니다.

예를 들어 각 테넌트마다 사용자 지정 스토리지 클래스를 구성할 수 있습니다. 그런 다음, 네임스페이스에서 만든 영구 볼륨에 태그를 적용하여 비용을 환불하는 데 사용할 수 있습니다. 이 시나리오에 대한 자세한 내용은 AKS(Azure Kubernetes Service)에서 Azure 태그 사용을 참조하세요.

자세한 내용은 Kubernetes 설명서의 네트워크 격리를 참조하세요.

노드 격리

Noisy Neighbor 문제를 방지하고 정보 공개 위험을 줄이기 위해 별도의 에이전트 노드에서 실행되도록 테넌트 워크로드를 구성할 수 있습니다. AKS에서 격리, 보안, 규정 준수 및 성능에 대한 엄격한 요구 사항이 있는 테넌트에 대해 별도의 클러스터 또는 전용 노드 풀만 만들 수 있습니다.

taint, tolerations, 노드 레이블, 노드 선택기 및 노드 선호도를 사용하여 특정 노드 또는 노드 풀 집합에서만 실행되도록 테넌트의 Pod를 제한할 수 있습니다.

일반적으로 AKS는 다양한 수준에서 워크로드 격리를 제공합니다.

  • 커널 수준에서 공유 에이전트 노드의 경량 가상 머신에서 테넌트 워크로드를 실행하고 Kata 컨테이너를 기반으로 하는 Pod Sandboxing을 사용합니다.
  • 물리적 수준에서 전용 클러스터 또는 노드 풀에서 테넌트 애플리케이션을 호스팅합니다.
  • 하드웨어 수준에서 에이전트 노드 VM이 전용 물리적 컴퓨터를 실행하게 하는 Azure 전용 호스트에서 테넌트 워크로드를 실행합니다. 하드웨어 격리는 다른 가상 머신이 전용 호스트에 배치되지 않도록 하여 테넌트 워크로드에 대한 추가 격리 계층을 제공합니다.

이러한 기술을 결합할 수 있습니다. 예를 들어 Azure Dedicated Host 그룹에서 테넌트별 클러스터 및 노드 풀을 실행하여 하드웨어 수준에서 워크로드 분리 및 물리적 격리를 달성할 수 있습니다. FIPS(Federal Information Process Standard), CVM(Confidential Virtual Machines) 또는 호스트 기반 암호화를 지원하는 공유 또는 테넌트별 노드 풀을 만들 수도 있습니다.

노드 격리를 사용하면 노드 또는 노드 풀 집합의 비용을 단일 테넌트로 쉽게 연결하고 환불할 수 있습니다. 솔루션에서 채택한 테넌시 모델과 엄격하게 관련이 있습니다.

자세한 내용은 Kubernetes 설명서의 노드 격리를 참조하세요.

테넌시 모델

AKS(Azure Kubernetes Service)는 더 많은 유형의 노드 격리 및 테넌시 모델을 제공합니다.

자동화된 단일 테넌트 배포

자동화된 단일 테넌트 배포 모델에서는 다음 예제와 같이 각 테넌트에 대한 전용 리소스 집합을 배포합니다.

각각 별도의 배포가 있는 3개의 테넌트를 보여 주는 다이어그램

각 테넌트 워크로드는 전용 AKS 클러스터에서 실행되며 고유한 Azure 리소스 집합에 액세스합니다. 일반적으로 이 모델을 사용하여 빌드된 다중 테넌트 솔루션은 IaC(Infrastructure as Code)를 광범위하게 사용합니다. 예를 들어 Bicep, Azure Resource Manager, Terraform 또는 Azure Resource Manager REST API는 테넌트 전용 리소스의 주문형 배포를 시작하고 조정하는 데 도움이 됩니다. 각 고객에 대해 완전히 별도의 인프라를 프로비저닝해야 하는 경우 이 방법을 사용할 수 있습니다. 배포를 계획할 때는 배포 스탬프 패턴을 사용하는 것이 좋습니다.

이점:

  • 이 방법의 주요 이점은 각 테넌트 AKS 클러스터의 API 서버가 분리되어 있다는 것입니다. 이 방법은 보안, 네트워킹 및 리소스 소비 수준에서 테넌트 간에 완전한 격리를 보장합니다. 컨테이너를 제어하기 위해 관리하는 공격자는 단일 테넌트에 탑재된 컨테이너 및 볼륨에만 액세스할 수 있습니다. 완전 격리 테넌시 모델은 규정 준수 오버헤드가 높은 일부 고객에게 매우 중요합니다.
  • 테넌트는 서로의 시스템 성능에 영향을 주지 않을 수 있으므로 노이즈 네이버 문제를 방지할 수 있습니다. 이 고려 사항에는 API 서버에 대한 트래픽이 포함됩니다. API 서버는 Kubernetes 클러스터에서 공유되는 중요한 구성 요소입니다. API 서버에 대해 규제되지 않은 대용량 트래픽을 생성하는 사용자 지정 컨트롤러는 클러스터 불안정을 일으킬 수 있습니다. 이러한 불안정은 요청 실패, 시간 초과 및 API 재시도 연발로 이어집니다. 작동 시간 SLA(서비스 수준 계약) 기능을 사용하면 트래픽 수요를 충족하기 위해 AKS 클러스터의 컨트롤 플레인을 스케일 아웃할 수 있습니다. 하지만 워크로드 격리 측면에서 강력한 요구 사항이 있는 고객에게 전용 클러스터를 프로비저닝하는 것이 더 나은 솔루션일 수 있습니다.
  • 업데이트 및 변경 내용을 테넌트 전체에 점진적으로 롤아웃하여 시스템 전체 가동 중단 가능성을 줄일 수 있습니다. 모든 리소스는 단일 테넌트에서 사용되므로 Azure 비용을 테넌트에 쉽게 환불할 수 있습니다.

위험:

  • 모든 테넌트가 전용 리소스 집합을 사용하기 때문에 비용 효율성이 낮습니다.
  • 지속적인 유지 관리는 여러 AKS 클러스터에서 각 테넌트마다 하나씩 복제해야 하므로 시간이 오래 걸릴 수 있습니다. 운영 프로세스를 자동화하고 환경을 통해 변경 내용을 점진적으로 적용하는 것이 좋습니다. 전체 자산에서 보고 및 분석과 같은 다른 배포 간 작업도 고려하면 도움이 됩니다. 마찬가지로 여러 배포에서 데이터를 쿼리하고 조작하는 방법을 계획해야 합니다.

완전 다중 테넌트 배포

완전 다중 테넌트 배포에서 단일 애플리케이션은 모든 테넌트의 요청에 대응하고 AKS 클러스터를 포함한 모든 Azure 리소스를 공유합니다. 이 컨텍스트에서는 배포, 모니터링 및 유지 관리할 인프라 집합이 하나만 있습니다. 모든 테넌트는 다음 다이어그램과 같이 리소스를 사용합니다.

모두 단일 공유 배포를 사용하는 세 개의 테넌트를 보여 주는 다이어그램

이점:

  • 이 모델은 공유 구성 요소를 사용하여 솔루션을 운영하는 비용이 낮기 때문에 매력적입니다. 이 테넌시 모델을 사용하는 경우 더 큰 AKS 클러스터를 배포하고 공유 데이터 리포지토리에 대해 더 높은 SKU를 채택하여 데이터 리포지토리와 같은 모든 테넌트의 리소스에서 생성된 트래픽을 유지해야 할 수 있습니다.

위험:

  • 이 컨텍스트에서 단일 애플리케이션은 모든 테넌트의 요청을 처리합니다. 테넌트가 애플리케이션에 호출이 넘치게 하지 않도록 보안 조치를 설계하고 구현해야 합니다. 이러한 호출은 전체 시스템을 느리게 하고 모든 테넌트에 영향을 줄 수 있습니다.
  • 트래픽 프로필이 매우 가변적이라면 AKS 클러스터 자동 크기 조정기를 구성하여 Pod 및 에이전트 노드 수를 변경해야 합니다. CPU 및 메모리와 같은 시스템 리소스 사용량에 따라 구성합니다. 또는 사용자 지정 메트릭에 따라 Pod 및 클러스터 노드 수를 스케일 아웃하고 스케일 인 할 수 있습니다. 예를 들어 Kubernetes KEDA(이벤트 기반 자동 크기 조정)를 사용하는 외부 메시지 시스템의 보류 중인 요청 수 또는 메트릭을 탐색할 수 있습니다.
  • 서로 다른 테넌트 간에 데이터가 누출되는 것을 방지하기 위해 각 테넌트별로 데이터를 분리하고 보호 장치를 구현해야 합니다.
  • 실제 사용량에 따라 Azure 비용을 추적하고개별 테넌트와 연결해야 합니다. kubecost와 같은 타사 솔루션은 다양한 팀과 테넌트에서 비용을 계산하고 분석하는 데 도움이 될 수 있습니다.
  • 하나의 Azure 리소스 집합만 업데이트하고 단일 애플리케이션을 유지 관리하면 되므로 단일 배포를 사용하면 유지 관리가 더 간단할 수 있습니다. 그러나 인프라 또는 애플리케이션 구성 요소의 변경 내용이 전체 고객 기반에 영향을 줄 수 있으므로 위험하기도 합니다.
  • 스케일링 제한도 고려해야 합니다. 공유 리소스 집합이 있다면 Azure 리소스 스케일링 한도에 도달할 가능성이 더 높습니다. 리소스 할당량 한도에 도달하는 것을 방지하려면 여러 Azure 구독에 테넌트를 분산하는 것이 좋습니다.

수평 분할된 배포

또는 다중 테넌트 Kubernetes 애플리케이션을 수평 분할하는 것이 좋습니다. 이 방법은 모든 테넌트에서 일부 솔루션 구성 요소를 공유하고 개별 테넌트를 위한 전용 리소스를 배포하는 것으로 구성됩니다. 예를 들어 다음 그림과 같이 단일 멀티 테넌트 Kubernetes 애플리케이션을 만든 다음, 각 테넌트에 하나씩 개별 데이터베이스를 배포할 수 있습니다.

각각 전용 데이터베이스와 단일 공유 Kubernetes 애플리케이션을 사용하는 세 테넌트를 보여 주는 다이어그램.

이점:

  • 수평 분할 배포는 노이즈 네이버 이슈를 완화하는 데 도움이 될 수 있습니다. Kubernetes 애플리케이션에서 트래픽 부하의 대부분이 각 테넌트별로 별도로 배포할 수 있는 특정 구성 요소 때문임을 확인했다면 이 방법이 좋습니다. 예를 들어 데이터베이스는 쿼리 부하가 높기 때문에 시스템의 부하 대부분을 흡수할 수 있습니다. 단일 테넌트가 솔루션에 많은 수의 요청을 보내는 경우 데이터베이스 성능에 부정적인 영향을 미칠 수 있지만 다른 테넌트의 데이터베이스(및 애플리케이션 계층과 같은 공유 구성 요소)는 영향을 받지 않습니다.

위험:

  • 수평 분할 배포에서는 구성 요소, 특히 단일 테넌트에서 사용하는 구성 요소의 자동화된 배포 및 관리를 고려해야 합니다.
  • 이 모델은 내부 정책 또는 규정 준수를 이유로 리소스를 다른 테넌트와 공유할 여유가 없는 고객에게 필요한 수준의 격리를 제공하지 않을 수 있습니다.

수직 분할된 배포

여러 AKS 클러스터 또는 노드 풀에서 테넌트를 수직 분할하는 하이브리드 모델을 사용하여 단일 테넌트 및 완전 다중 테넌트 모델의 이점을 활용할 수 있습니다. 이 방법은 이전의 두 테넌시 모델에 비해 다음과 같은 이점을 제공합니다.

  • 단일 테넌트 및 다중 테넌트 배포의 조합을 사용할 수 있습니다. 예를 들어 고객 대부분이 다중 테넌트 인프라에서 AKS 클러스터 및 데이터베이스를 공유하도록 할 수 있습니다. 하지만 더 높은 성능과 격리가 필요한 고객을 위해 단일 테넌트 인프라를 배포할 수도 있습니다.
  • 잠재적으로 다른 구성을 사용하여 여러 지역 AKS 클러스터에 테넌트를 배포할 수 있습니다. 이 기술은 테넌트가 여러 지역에 분산되어 있다면 가장 효과적입니다.

이 테넌시 모델의 다양한 변형을 구현할 수 있습니다. 예를 들어 다양한 계층의 기능을 다양한 비용으로 제공하는 다중 테넌트 솔루션을 선택할 수 있습니다. 가격 책정 모델은 여러 SKU를 제공할 수 있으며, 각 SKU는 리소스 공유, 성능, 네트워크 및 데이터 분리 측면에서 증분 수준의 성능 및 격리를 제공합니다. 다음 쿼리를 살펴보세요.

  • 기본 계층: 테넌트 요청은 다른 테넌트와 공유되는 단일한 다중 테넌트 Kubernetes 애플리케이션에서 대응합니다. 데이터는 모든 기본 계층 테넌트에서 공유하는 하나 이상의 데이터베이스에 저장됩니다.
  • 표준 계층: 테넌트 요청은 보안, 네트워킹, 리소스 사용 측면에서 격리 경계를 제공하는 별도의 네임스페이스에서 실행되는 전용 Kubernetes 애플리케이션에서 대응합니다. 각 테넌트마다 하나씩 모든 테넌트의 애플리케이션은 다른 표준 계층 고객과 동일한 AKS 클러스터 및 노드 풀을 공유합니다.
  • 프리미엄 계층: 테넌트 애플리케이션은 더 높은 서비스 수준 계약, 더 나은 성능 및 더 높은 수준의 격리를 보장하기 위해 전용 노드 풀 또는 AKS 클러스터에서 실행됩니다. 이 계층은 테넌트 애플리케이션을 호스트하는 데 사용되는 에이전트 노드의 수와 SKU를 기반으로 유연한 비용 모델을 제공할 수 있습니다. 전용 클러스터 또는 노드 풀을 사용하여 고유한 테넌트 워크로드를 격리하는 대체 솔루션으로 Pod Sandboxing을 사용할 수 있습니다.

다음 다이어그램에서는 테넌트 A와 B가 공유 AKS 클러스터에서 실행되는 반면 테넌트 C는 별도의 AKS 클러스터에서 실행되는 시나리오를 보여 줍니다.

세 테넌트를 보여 주는 다이어그램. 테넌트 A와 B는 AKS 클러스터를 공유합니다. 테넌트 C에는 AKS 클러스터가 있습니다.

마찬가지로 다음 다이어그램에서는 테넌트 A와 B가 동일한 노드 풀에서 실행되는 반면 테넌트 C는 전용 노드 풀에서 실행되는 시나리오를 보여 줍니다.

세 테넌트를 보여 주는 다이어그램. 테넌트 A와 B는 노드 풀을 공유합니다. 테넌트 C에는 전용 노드 풀이 있습니다.

이 모델은 다른 계층에 대해 서로 다른 서비스 수준 계약을 제공할 수도 있습니다. 예를 들어 기본 계층은 99.9%의 작동 시간을 제공할 수 있고, 표준 계층은 99.95%의 작동 시간을 제공할 수 있으며, 프리미엄 계층은 99.99%의 작동 시간을 제공할 수 있습니다. 더 높은 가용성 목표를 가능하게 하는 서비스 및 기능을 사용하여 더 높은 SLA(서비스 수준 계약)를 구현할 수 있습니다.

이점:

  • 여전히 인프라를 공유하고 있으므로 다중 테넌트 배포를 공유하면 비용 이점을 여전히 얻을 수 있습니다. 에이전트 노드에 더 저렴한 VM 크기를 사용하는 여러 기본 계층 및 표준 계층 테넌트 애플리케이션에서 공유되는 클러스터 및 노드 풀을 배포할 수 있습니다. 이 방법은 더 나은 밀도와 비용 절감을 보장합니다. 프리미엄 계층 고객의 경우 더 높은 가격으로 더 큰 VM 크기와 최대 수의 Pod 복제본 및 노드를 사용하여 AKS 클러스터 및 노드 풀을 배포할 수 있습니다.
  • 전용 시스템 모드 노드 풀에서 CoreDNS, Konnectivity 또는 Azure Application Gateway 수신 컨트롤러와 같은 시스템 서비스를 실행할 수 있습니다. taint,tolerations, 노드 레이블, 노드 선택기 및 노드 선호도를 사용하여 하나 이상의 사용자 모드 노드 풀에서 테넌트 애플리케이션을 실행할 수 있습니다.
  • taint,tolerations, 노드 레이블, 노드 선택기 및 노드 선호도를 사용하여 공유 리소스를 실행할 수 있습니다. 예를 들어 특정 VM 크기, 자동 크기 조정기 설정 및 가용성 영역을 지원하는 전용 노드 풀에 수신 컨트롤러 또는 메시지 시스템을 사용할 수 있습니다.

위험:

  • 다중 테넌트 및 단일 테넌트 배포를 모두 지원하도록 Kubernetes 애플리케이션을 설계해야 합니다.
  • 인프라 간 마이그레이션을 허용하려는 경우 다중 테넌트 배포에서 자체 단일 테넌트 배포로 고객을 마이그레이션하는 방법을 고려해야 합니다.
  • 더 많은 AKS 클러스터를 모니터링하고 관리하려면 일관된 전략과 단일 창(하나의 관점)이 필요합니다.

자동 확장

테넌트 애플리케이션에서 생성되는 트래픽 수요를 따라가기 위해 클러스터 자동 크기 조정기가 AKS(Azure Kubernetes Service) 에이전트 노드를 스케일링하도록 설정할 수 있습니다. 자동 크기 조정은 다음과 같은 상황에서 시스템이 응답성을 유지하는 데 도움이 됩니다.

  • 트래픽 부하는 특정 작업 시간 또는 연중 기간 동안 증가합니다.
  • 테넌트 또는 공유 부하가 클러스터에 배포됩니다.
  • 영역 중단으로 인해 에이전트 노드를 사용할 수 없게 됩니다.

노드 풀에 대해 자동 크기 조정을 사용하도록 설정하는 경우 예상되는 워크로드 크기에 따라 최소 및 최대 노드 수를 지정합니다. 최대 노드 수를 구성하면 실행되는 네임스페이스에 관계없이 클러스터의 모든 테넌트 Pod에 충분한 공간을 확보할 수 있습니다.

트래픽이 증가하면 클러스터 자동 크기 조정은 CPU 및 메모리 측면에서 리소스 부족으로 인해 Pod가 보류 중 상태로 전환되지 않도록 새 에이전트 노드를 추가합니다.

마찬가지로 부하가 감소하면 클러스터 자동 크기 조정은 지정된 경계에 따라 노드 풀의 에이전트 노드 수를 줄여 운영 비용을 줄이는 데 도움이 됩니다.

Pod 자동 크기 조정을 사용하여 리소스 요구에 따라 Pod를 자동으로 스케일링할 수 있습니다. HPA(Horizontal Pod Autoscaler)는 CPU/메모리 사용률 또는 사용자 지정 메트릭에 따라 Pod 복제본 수를 자동으로 스케일링합니다. KEDA(Kubernetes 이벤트 기반 자동 크기 조정)를 사용하면 테넌트 애플리케이션에서 사용하는 Azure Event Hubs 또는 Azure Service Bus 같은 외부 시스템의 이벤트 수에 따라 Kubernetes의 모든 컨테이너를 스케일링하도록 추진할 수 있습니다.

유지 관리

클러스터 또는 노드 풀 업그레이드 중에 테넌트 애플리케이션에 영향을 미칠 수 있는 가동 중지 시간의 위험을 줄이려면 사용량이 많은 시간에 AKS 계획된 유지 관리를 수행하도록 예약합니다. 계획된 유지 관리를 사용하면 주간 유지 관리 기간을 예약하여 테넌트 애플리케이션 및 노드 풀을 실행하는 AKS 클러스터의 컨트롤 플레인을 업데이트하여 워크로드 영향을 최소화할 수 있습니다. 특정 날짜에 날짜 또는 시간 범위를 지정하여 클러스터에서 하나 이상의 주별 유지 관리 기간을 예약할 수 있습니다. 모든 유지 관리 작업은 예약된 기간 동안 발생합니다.

보안

클러스터 액세스

조직 내의 여러 팀 간에 AKS 클러스터를 공유하는 경우 다양한 테넌트를 서로 격리하려면 최소 권한 원칙을 구현해야 합니다. 특히 kubectl, Helm, Flux, Argo CD 또는 기타 유형의 도구와 같은 도구를 사용할 때 사용자가 Kubernetes 네임스페이스 및 리소스에만 액세스할 수 있는지 확인해야 합니다.

AKS를 사용한 인증 및 권한 부여에 대한 자세한 내용은 다음 문서를 참조하세요.

워크로드 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 샌드박싱 을 사용하면 별도의 클러스터 또는 노드 풀에서 이러한 워크로드를 실행할 필요 없이 동일한 클러스터 노드에서 테넌트 애플리케이션을 강력하게 격리할 수 있습니다. 다른 방법을 사용하려면 코드를 다시 컴파일하거나 다른 호환성 문제를 발생해야 하지만 AKS의 Pod Sandboxing은 향상된 보안 VM 경계 내에서 수정되지 않은 모든 컨테이너를 실행할 수 있습니다.

AKS의 Pod 샌드박싱은 AKS 스택용 Azure Linux 컨테이너 호스트에서 실행되어 하드웨어 적용 격리를 제공하는 Kata Containers를 기반으로 합니다. AKS의 Kata 컨테이너는 보안이 강화된 Azure 하이퍼바이저를 기반으로 합니다. Pod당 격리는 부모 VM 노드의 리소스를 활용하는 중첩된 경량 Kata VM을 통해 수행됩니다. 이 모델에서 각 Kata Pod는 중첩된 Kata 게스트 VM에서 자체 커널을 가져옵니다. 이 모델을 사용하면 부모 VM에서 컨테이너를 계속 실행하면서 여러 Kata 컨테이너를 단일 게스트 VM에 배치할 수 있습니다. 이 모델은 공유 AKS 클러스터에서 강력한 격리 경계를 제공합니다.

자세한 내용은 다음을 참조하세요.

Azure Dedicated Host

Azure Dedicated Host 는 단일 Azure 구독 전용 물리적 서버를 제공하고 물리적 서버 수준에서 하드웨어 격리를 제공하는 서비스입니다. 이러한 전용 호스트는 지역, 가용성 영역 및 장애 도메인 내에서 프로비전할 수 있으며 프로비전된 호스트에 직접 VM을 배치할 수 있습니다.

다음을 포함하여 AKS에서 Azure Dedicated Host를 사용하여 몇 가지 이점을 얻을 수 있습니다.

  • 하드웨어 격리는 다른 VM이 전용 호스트에 배치되지 않도록 하며, 이는 테넌트 워크로드에 대한 추가 격리 계층을 제공합니다. 전용 호스트는 동일한 데이터 센터에 배포되며 격리되지 않은 다른 호스트와 동일한 네트워크 및 기본 스토리지 인프라를 공유합니다.

  • Azure Dedicated Host는 Azure 플랫폼에서 시작하는 유지 관리 이벤트를 제어합니다. 유지 관리 기간을 선택하여 서비스에 미치는 영향을 줄이고 테넌트 워크로드의 가용성 및 개인 정보를 보장할 수 있습니다.

Azure Dedicated Host는 SaaS 공급자가 테넌트 애플리케이션이 중요한 정보를 보호하기 위한 규정, 산업 및 거버넌스 규정 준수 요구 사항을 충족하도록 할 수 있습니다. 자세한 내용은 AKS(Azure Kubernetes Service) 클러스터에 Azure Dedicated Host 추가를 참조하세요.

기밀 가상 머신

CVM(Confidential Virtual Machines)을 사용하여 AKS 클러스터에 하나 이상의 노드 풀을 추가하여 테넌트의 엄격한 격리, 개인 정보 보호 및 보안 요구 사항을 해결할 수 있습니다. CVM은 하드웨어 기반 TEE(신뢰할 수 있는 실행 환경)를 사용합니다. AMD 보안 암호화 가상화 - SEV-SNP(Secure Nested Paging) 기밀 VM은 VM 메모리 및 상태에 대한 하이퍼바이저 및 기타 호스트 관리 코드 액세스를 거부하여 운영자 액세스에 대한 심층 방어 계층을 추가합니다. 자세한 내용은 AKS 클러스터에서 CVM 사용을 참조 하세요.

FIPS(Federal Information Process Standards)

FIPS 140-3 은 정보 기술 제품 및 시스템의 암호화 모듈에 대한 최소 보안 요구 사항을 정의하는 미국 정부 표준입니다. AKS 노드 풀에 FIPS 규정 준수를 사용하도록 설정하면 테넌트 워크로드의 격리, 개인 정보 보호 및 보안을 향상시킬 수 있습니다. FIPS 규정 준수는 암호화, 해시 및 기타 보안 관련 작업에 유효성이 검사된 암호화 모듈을 사용하도록 보장합니다. FIPS 사용 AKS 노드 풀을 사용하면 강력한 암호화 알고리즘 및 메커니즘을 사용하여 규정 및 업계 규정 준수 요구 사항을 충족할 수 있습니다. Azure는 AKS 노드 풀에 FIPS를 사용하도록 설정하는 방법에 대한 설명서를 제공하므로 다중 테넌트 AKS 환경의 보안 태세를 강화할 수 있습니다. 자세한 내용은 AKS 노드 풀에 FIPS 사용 설정을 참조 하세요.

Azure 디스크를 사용하여 BYOK(사용자 고유의 키 가져오기)

Azure Storage는 AKS 클러스터의 OS 및 데이터 디스크를 포함하여 미사용 스토리지 계정의 모든 데이터를 암호화합니다. 기본적으로 데이터는 Microsoft 관리형 키로 암호화됩니다. 암호화 키를 보다 제어하기 위해 AKS 클러스터의 나머지 OS 및 데이터 디스크에서 암호화에 사용할 고객 관리형 키를 제공할 수 있습니다. 자세한 내용은 다음을 참조하세요.

호스트 기반 암호화

AKS의 호스트 기반 암호화 는 테넌트 워크로드 격리, 개인 정보 보호 및 보안을 더욱 강화합니다. 호스트 기반 암호화를 사용하도록 설정하면 AKS는 기본 호스트 컴퓨터에서 미사용 데이터를 암호화하여 중요한 테넌트 정보가 무단 액세스로부터 보호되도록 합니다. 엔드투엔드 암호화를 사용하는 경우 임시 디스크와 임시 OS 디스크는 플랫폼 관리형 키를 사용하여 미사용 시 암호화됩니다.

AKS에서 OS 및 데이터 디스크는 기본적으로 플랫폼 관리형 키로 서버 쪽 암호화를 사용합니다. 이러한 디스크의 캐시는 플랫폼 관리형 키를 사용하여 미사용 시 암호화됩니다. 봉투 암호화(래핑이라고도 함)를 사용하여 DEK(데이터 보호 키)를 암호화하도록 KEK(키 암호화 키)를 지정할 수 있습니다. OS 및 데이터 디스크에 대한 캐시는 지정한 BYOK를 통해 암호화됩니다.

호스트 기반 암호화는 다중 테넌트 환경에 대한 보안 계층을 추가합니다. OS 및 데이터 디스크 캐시에 있는 각 테넌트의 데이터는 선택한 디스크 암호화 유형에 따라 고객 관리형 또는 플랫폼 관리형 키를 사용하여 미사용 시 암호화됩니다. 자세한 내용은 다음을 참조하세요.

네트워킹

API 서버에 대한 네트워크 액세스 제한

Kubernetes에서 API 서버는 클러스터에서 리소스를 만들거나 노드 수를 스케일링하는 등의 작업을 수행하라는 요청을 수신합니다. 조직 내의 여러 팀에서 AKS 클러스터를 공유하는 경우 다음 솔루션 중 하나를 사용하여 컨트롤 플레인에 대한 액세스를 보호합니다.

프라이빗 AKS 클러스터

프라이빗 AKS 클러스터를 사용하면 API 서버와 노드 풀 간의 네트워크 트래픽이 가상 네트워크 내에 남아 있는지 확인할 수 있습니다. 프라이빗 AKS 클러스터에서 컨트롤 플레인 또는 API 서버에는 AKS 클러스터의 동일한 가상 네트워크에 있는 Azure 프라이빗 엔드포인트를 통해서만 액세스할 수 있는 내부 IP 주소가 있습니다. 마찬가지로 동일한 가상 네트워크의 모든 가상 머신은 프라이빗 엔드포인트를 통해 컨트롤 플레인과 비공개로 통신할 수 있습니다. 자세한 내용은 프라이빗 Azure Kubernetes Service 클러스터 만들기를 참조하세요.

권한 있는 IP

클러스터 보안을 개선하고 공격을 최소화하는 두 번째 옵션은 권한 있는 IP를 사용하는 것입니다. 이 방법은 공용 AKS 클러스터의 컨트롤 플레인에 대한 액세스를 잘 알려진 IP(인터넷 프로토콜) 주소 목록 및 CIDR(Classless Inter-Domain Routing)으로 제한합니다. 권한 있는 IP를 사용하는 경우 여전히 공개적으로 노출되지만 액세스는 IP 범위 집합으로 제한됩니다. 자세한 내용은 AKS(Azure Kubernetes Service)에서 권한 있는 IP 주소 범위를 사용하는 안전한 API 서버 액세스를 참조하세요.

PLS(Azure Private Link Service)는 애플리케이션이 가상 네트워크에 정의되고 ALB(Azure Load Balancer) 인스턴스의 프런트 엔드 IP 구성에 연결된 Azure PE(프라이빗 엔드포인트)를 통해 서비스에 비공개로 연결할 수 있도록 하는 인프라 구성 요소입니다. Azure Private Link를 통해 서비스 공급자는 데이터 반출 위험 없이 Azure 또는 온-프레미스 내에서 연결할 수 있는 테넌트에 서비스를 안전하게 제공할 수 있습니다.

Azure Private Link 서비스 통합을 사용하여 공용 인터넷에서 퍼블릭 엔드포인트를 노출할 필요 없이 안전하게 AKS 호스트 워크로드에 대한 프라이빗 연결을 테넌트에 제공할 수 있습니다.

Azure 호스트 다중 테넌트 솔루션에 대한 Private Link를 구성하는 방법에 대한 일반적인 지침은 다중 테넌트 및 Azure Private Link를 참조하세요.

역방향 프록시

역방향 프록시는 일반적으로 들어오는 요청을 보호, 필터링 및 디스패치하기 위해 테넌트 애플리케이션 앞에서 사용되는 부하 분산 장치 및 API 게이트웨이입니다. 인기 있는 역방향 프록시는 부하 분산, SSL 종료 및 계층 7 라우팅과 같은 기능을 지원합니다. 역방향 프록시는 일반적으로 보안, 성능 및 안정성을 높이기 위해 구현됩니다. Kubernetes에 널리 사용되는 역방향 프록시에는 다음 구현이 포함됩니다.

  • NGINX 수신 컨트롤러는 부하 분산, SSL 종료 및 계층 7 라우팅과 같은 고급 기능을 지원하는 인기 있는 역방향 프록시 서버입니다.
  • Traefik Kubernetes 수신 공급자는 수신 사양을 지원하여 클러스터 서비스에 대한 액세스를 관리하는 데 사용할 수 있는 Kubernetes 수신 컨트롤러입니다.
  • HAProxy Kubernetes 수신 컨트롤러는 TLS 종료, URL 경로 기반 라우팅 등과 같은 표준 기능을 지원하는 Kubernetes의 또 다른 역방향 프록시입니다.
  • AGIC(Azure Application Gateway 수신 컨트롤러)는 AKS(Azure Kubernetes Service) 고객이 Azure의 네이티브 Application Gateway L7 부하 분산 장치를 활용하고 가상 네트워크에서 실행되는 다른 시스템에 공용 인터넷 또는 내부적으로 테넌트 애플리케이션을 노출할 수 있도록 하는 Kubernetes 애플리케이션입니다.

AKS 호스트 역방향 프록시를 사용하여 여러 테넌트 애플리케이션에 들어오는 요청을 보호하고 처리하는 경우 다음 권장 사항을 고려합니다.

  • 높은 네트워크 대역폭 및 가속화된 네트워킹을 사용하도록 설정된 VM 크기를 사용하도록 구성된 전용 노드 풀에서 역방향 프록시를 호스트합니다.
  • 자동 크기 조정을 위해 역방향 프록시를 호스트하는 노드 풀을 구성합니다.
  • 테넌트 애플리케이션의 대기 시간 및 시간 제한을 늘리지 않도록 하려면 수신 컨트롤러 Pod 수를 즉시 확장하고 트래픽 변동에 맞게 계약할 수 있도록 자동 크기 조정 정책을 정의합니다.
  • 들어오는 트래픽을 수신 컨트롤러의 여러 인스턴스에 걸쳐 테넌트 애플리케이션으로 분할하여 확장성 및 분리 수준을 높이는 것이 좋습니다.

AGIC(Azure Application Gateway 수신 컨트롤러)를 사용하는 경우 다음 모범 사례를 구현하는 것이 좋습니다.

  • 자동 크기 조정을 위해 수신 컨트롤러에서 사용하는 Application Gateway를 구성합니다. 자동 크기 조정 기능을 사용하면 Application Gateway 및 WAF v2 SKU가 애플리케이션 트래픽 요구 사항에 따라 스케일 아웃 또는 인됩니다. 이 모드는 애플리케이션에 더 나은 탄력성을 제공하고 Application Gateway 크기 또는 인스턴스 수를 추측할 필요를 없애줍니다. 또한 이 모드를 사용하면 게이트웨이가 예상되는 최대 트래픽 부하에 맞게 프로비저닝된 최대 용량에서 실행될 필요가 없으므로 비용을 절감할 수 있습니다. 최소 및 최대(선택적) 인스턴스 수를 지정해야 합니다.
  • 테넌트 애플리케이션 수가 최대 사이트 양을 초과하는 경우 각각 별도의 Application Gateway가 연결된 AGIC(Application Gateway 수신 컨트롤러)의 여러 인스턴스를 배포하는 것이 좋습니다. 각 테넌트 애플리케이션이 전용 네임스페이스에서 실행한다고 가정하면 여러 네임스페이스 지원을 사용하여 AGIC(Application Gateway 수신 컨트롤러)의 더 많은 인스턴스에 테넌트 애플리케이션을 분산합니다.

Azure Front Door와 통합

Azure Front Door는 전 세계 사용자와 웹 애플리케이션 간 빠르고 안정적이며 안전한 액세스를 제공하는 글로벌 계층 7 부하 분산 장치 및 Microsoft의 최신 CDN(클라우드 콘텐츠 배달 네트워크)입니다. Azure Front Door는 AKS 호스트 다중 테넌트 애플리케이션을 공용 인터넷에 노출할 때 익스플로잇할 수 있는 요청 가속, SSL 종료, 응답 캐싱, 에지의 WAF, URL 기반 라우팅, 다시 쓰기 및 리디렉션과 같은 기능을 지원합니다.

예를 들어 AKS 호스트 다중 테넌트 애플리케이션을 사용하여 모든 고객의 요청에 대응하고자 할 수 있습니다. 이 컨텍스트에서 Azure Front Door를 사용하여 각 테넌트마다 하나씩 여러 사용자 지정 도메인을 관리할 수 있습니다. 에지에서 SSL 연결을 종료하고 모든 트래픽을 단일 호스트 이름으로 구성된 AKS 호스트 다중 테넌트 애플리케이션으로 라우팅할 수 있습니다.

Azure Front Door 및 AKS 연결 방법을 보여 주는 다이어그램.

백 엔드 애플리케이션의 도메인 이름과 일치하도록 요청 원본 호스트 헤더를 수정하기 위해 Azure Front Door를 구성할 수 있습니다. Host클라이언트에서 보낸 원래 헤더는 헤더를 통해 전파되며X-Forwarded-Host 다중 테넌트 애플리케이션 코드는 이 정보를 사용하여 들어오는 요청을 올바른 테넌트에 매핑할 수 있습니다.

Azure Front Door의 Azure WAF(웹 애플리케이션 방화벽)는 웹 애플리케이션을 중앙 집중식으로 보호합니다. Azure WAF를 사용하여 악의적인 공격으로부터 인터넷의 퍼블릭 엔드포인트를 노출하는 AKS 호스트 테넌트 애플리케이션을 방어할 수 있습니다.

Azure Private Link Service를 사용하여 내부 부하 분산 장치 원본을 통해 AKS 클러스터에서 실행되는 하나 이상의 테넌트 애플리케이션에 비공개로 연결하도록 Azure Front Door 프리미엄을 구성할 수 있습니다. 더 자세한 내용은 프라이빗 링크를 사용하여 Azure Front Door 프리미엄을 내부 부하 분산 장치 원본에 연결을 참조하세요.

아웃바운드 연결

AKS 호스트 애플리케이션을 많은 수의 데이터베이스 또는 외부 서비스에 연결하는 경우 클러스터는 SNAT 포트가 소모될 위험이 있을 수 있습니다. SNAT 포트는 동일한 컴퓨팅 리소스 집합에서 실행되는 애플리케이션에서 시작하는 고유한 흐름을 유지하는 데 사용되는 고유 식별자를 생성합니다. AKS(공유 Azure Kubernetes Service) 클러스터에서 여러 테넌트 애플리케이션을 실행하면 많은 수의 아웃바운드 호출을 수행하여 SNAT 포트가 고갈될 수 있습니다. AKS 클러스터는 다음과 같은 세 가지 방법으로 아웃바운드 연결을 처리할 수 있습니다.

  • Azure 공용 Load Balancer: 기본적으로 AKS는 송신 연결에 설정하고 사용할 표준 SKU Load Balancer를 프로비저닝합니다. 그러나 공용 IP가 허용되지 않거나 송신에 대한 추가 홉이 필요한 경우에는 기본 설정이 모든 시나리오의 요구 사항을 충족하지 못할 수 있습니다. 기본적으로 공용 Load Balancer는 아웃바운드 규칙에 사용되는 기본 공용 IP 주소로 만들어집니다. 아웃바운드 규칙을 사용하여 퍼블릭 부하 분산 장치에 대한 SNAT(Source Network Address Translation)를 명시적으로 정의할 수 있습니다. 이 구성을 사용하면 부하 분산 장치의 공용 IP를 사용하여 백 엔드 인스턴스에 대한 아웃바운드 인터넷 연결을 제공할 수 있습니다. 필요한 경우 SNAT 포트 소모를 방지하기 위해 공용 부하 분산 장치의 아웃바운드 규칙을 구성하여 추가 공용 IP 주소를 사용할 수 있습니다. 더 자세한 내용은 아웃바운드 규칙을 통한 아웃바운드에 대한 부하 분산 장치의 프런트 엔드 IP 주소 사용을 참조하세요.
  • Azure NAT Gateway: Azure NAT Gateway를 사용하여 테넌트 애플리케이션에서 송신 트래픽을 라우팅하도록 AKS 클러스터를 구성할 수 있습니다. NAT Gateway는 최대 16개의 공용 IP 주소를 사용하여 IP 주소당 최대 64,512개의 아웃바운드 UDP 및 TCP 트래픽 흐름을 허용합니다. NAT Gateway를 사용하여 AKS 클러스터에서 아웃바운드 연결을 처리할 때 SNAT 포트 소모의 위험을 방지하기 위해 더 많은 공용 IP 주소 또는 공용 IP 주소 접두사를 게이트웨이에 연결할 수 있습니다. 자세한 내용은 다중 테넌시에 대한 Azure NAT Gateway 고려 사항을 참조하세요.
  • UDR(사용자 정의 경로): 공용 IP를 허용하지 않으며 클러스터가 NVA(네트워크 가상 어플라이언스) 뒤에 있어야 하는 것과 같은 사용자 지정 네트워크 시나리오를 지원하도록 AKS 클러스터의 송신 경로를 사용자 지정할 수 있습니다. 사용자 정의 라우팅을 위해 클러스터를 구성하는 경우 AKS는 송신 경로를 자동으로 구성하지 않습니다. 송신 설정을 직접 수행해야 합니다. 예를 들어 Azure Firewall을 통해 송신 트래픽을 라우팅합니다. AKS 클러스터는 이미 구성된 서브넷을 사용하여 기존 가상 네트워크에 배포되어야 합니다. SLB(표준 Load Balancer) 아키텍처를 사용하지 않는 경우 명시적 송신을 설정해야 합니다. 따라서 이 아키텍처를 사용하려면 방화벽, 게이트웨이 또는 프록시와 같은 어플라이언스에 송신 트래픽을 명시적으로 보내야 합니다. 또는 아키텍처를 사용하면 표준 부하 분산 장치 또는 어플라이언스에 할당된 공용 IP에서 NAT(Network Address Translation)를 수행할 수 있습니다.

모니터링

Azure Monitor 및 Container Insights를 사용하여 공유 AKS 클러스터에서 실행되는 테넌트 애플리케이션을 모니터링하고 개별 네임스페이스에 대한 비용 분석을 계산할 수 있습니다. Azure Monitor를 사용하여 AKS(Azure Kubernetes Service)의 상태 및 성능을 모니터링할 수 있습니다. 여기에는 추세를 식별하고 중요한 이슈에 대해 사전에 알림을 받도록 경고를 구성하기 위한 로그 및 지표, 원격 분석, 수집된 데이터 시각화의 컬렉션이 포함됩니다. 컨테이너 인사이트를 사용하도록 설정하여 이 모니터링을 확장할 수 있습니다.

Kubernetes 모니터링을 위해 커뮤니티에서 널리 사용되는 Prometheus 및 Grafana와 같은 오픈 소스 도구를 채택할 수도 있습니다. 또는 모니터링 및 가시성을 위해 다른 타사 도구를 채택할 수 있습니다.

비용

비용 거버넌스는 비용을 제어하는 정책을 지속적으로 구현하는 프로세스입니다. Kubernetes 컨텍스트에서는 조직이 비용을 제어하고 최적화하는 여러 방법이 있습니다. 여기에는 리소스 사용량 및 소비를 관리하고 제어하며 기본 인프라를 사전에 모니터링하고 최적화하는 네이티브 Kubernetes 도구가 포함됩니다. 테넌트당 비용을 계산할 때 테넌트 애플리케이션에서 사용하는 리소스와 관련된 비용을 고려해야 합니다. 테넌트에 요금을 환불하기 위해 따르는 방법은 솔루션에서 채택한 테넌트 모델에 따라 달라집니다. 자세한 내용은 다음 테넌시 모델을 통해 설명됩니다.

  • 완전 다중 테넌트: 단일 다중 테넌트 애플리케이션이 모든 테넌트 요청에 대응하는 경우 리소스 사용량과 각 테넌트에서 생성된 요청 수를 추적하는 것은 사용자의 책임입니다. 그런 다음, 그에 따라 고객에게 요금을 청구합니다.
  • 전용 클러스터: 클러스터가 단일 테넌트 전용인 경우 Azure 리소스 비용을 고객에게 쉽게 환불할 수 있습니다. 총 소유 비용은 가상 머신의 수와 크기, 네트워크 트래픽으로 인한 네트워킹 비용, 공용 IP 주소, 부하 분산 장치, 스토리지 서비스(예: 관리 디스크 또는 테넌트 솔루션에서 사용하는 Azure 파일 등)를 포함한 여러 요인에 따라 달라집니다. 비용 청구 작업을 용이하게 하기 위해 노드 리소스 그룹에서 AKS 클러스터 및 해당 리소스에 태그를 지정할 수 있습니다. 자세한 내용은 클러스터에 태그 추가를 참조하세요.
  • 전용 노드 풀: 단일 테넌트 전용인 새 노드 풀 또는 기존 노드 풀에 Azure 태그를 적용할 수 있습니다. 노드 풀에 적용되는 태그는 노드 풀 내의 각 노드에도 적용되며 업그레이드를 통해 유지됩니다. 태그는 스케일 아웃 작업 중에 노드 풀에 추가되는 새 노드에도 적용됩니다. 태그를 추가하면 정책 추적 또는 비용 청구와 같은 작업에 도움이 됩니다. 자세한 내용은 노드 풀에 태그 추가를 참조하세요.
  • 기타 리소스: 태그를 사용하여 전용 리소스 비용을 지정된 테넌트와 연결할 수 있습니다. 특히 Kubernetes 매니페스트를 사용하여 공용 IP, 파일 및 디스크에 태그를 지정할 수 있습니다. 이러한 방식으로 설정된 태그는 나중에 다른 메서드를 사용하여 업데이트하더라도 Kubernetes 값을 유지 관리합니다. 공용 IP, 파일 또는 디스크가 Kubernetes를 통해 제거되면 Kubernetes에서 설정한 모든 태그가 제거됩니다. Kubernetes에서 추적하지 않는 리소스의 태그는 영향을 받지 않습니다. 자세한 내용은 Kubernetes를 사용하여 태그 추가를 참조하세요.

KubeCost와 같은 오픈 소스 도구를 사용하여 AKS 클러스터 비용을 모니터링하고 제어할 수 있습니다. 비용 할당은 배포, 서비스, 레이블, Pod 및 네임스페이스로 범위가 지정될 수 있으므로 클러스터의 사용자에게 차지백 또는 쇼백을 하는 방법에 유연성이 있습니다. 자세한 내용은 Kubecost를 사용한 비용 거버넌스를 참조하세요.

다중 테넌트 애플리케이션에 대한 비용의 측정, 할당 및 최적화에 대한 자세한 내용은 다중 테넌트 솔루션에서 비용 관리 및 할당을 위한 아키텍처 접근 방식을 참조하세요. 비용 최적화에 대한 일반적인 참고 자료는 Azure Well-Architected Framework 문서인 비용 최적화 핵심 요소 개요를 참조하세요.

참가자

Microsoft에서 이 문서를 유지 관리합니다. 원래 다음 기여자가 작성했습니다.

보안 주체 작성자:

기타 기여자:

다음 단계

다중 테넌트 솔루션의 설계자 및 개발자를 위한 리소스를 검토합니다.