이 참조 아키텍처는 활성/활성 및 고가용성 구성의 여러 지역에서 여러 AKS(Azure Kubernetes Service) 클러스터 인스턴스를 실행하는 방법을 자세히 설명합니다.
이 아키텍처는 Microsoft에서 AKS 인프라의 시작점으로 권장하는 AKS 기준 아키텍처를 기반으로 합니다. AKS 기준은 Microsoft Entra 워크로드 ID, 수신 및 송신 제한, 리소스 제한 및 기타 보안 AKS 인프라 구성과 같은 인프라 기능을 자세히 설명합니다. 이러한 인프라의 세부 정보는 이 문서에서 다루지 않습니다. 다중 지역 콘텐츠를 계속 진행하기 전에 AKS 기준을 숙지하는 것이 좋습니다.
아키텍처
이 아키텍처의 Visio 파일을 다운로드합니다.
이 아키텍처의 참조 구현은 GitHub에서 사용할 수 있습니다.
구성 요소
여러 구성 요소와 Azure 서비스가 다중 지역 AKS 참조 아키텍처에 사용됩니다. 이 다중 클러스터 아키텍처 고유의 구성 요소만 아래에 나열되어 있습니다. 나머지 구성 요소는 AKS 기준 아키텍처를 참조하세요.
- 여러 클러스터/여러 지역 여러 AKS 클러스터가 각각 별도의 Azure 지역에 배포됩니다. 정상적으로 작동하는 동안에는 네트워크 트래픽이 모든 지역 간에 라우팅됩니다. 한 지역이 사용할 수 없게 되면 요청을 발급한 사용자와 가장 가까운 지역으로 트래픽이 라우팅됩니다.
- 지역별 허브-스포크 네트워크 지역별 허브-스포크 네트워크 쌍은 각 지역 AKS 인스턴스에 대해 배포됩니다. Azure Firewall Manager 정책은 모든 지역에서 방화벽 정책을 관리하는 데 사용됩니다.
- 지역별 키 저장소 Azure Key Vault는 AKS 인스턴스와 관련된 중요한 값과 키를 저장하고 해당 지역에서 발견되는 서비스를 지원하기 위해 각 지역에 프로비저닝됩니다.
- Azure Front Door Azure Front Door는 트래픽 부하를 분산하고 각 AKS 클러스터 앞에 있는 지역별 Azure Application Gateway 인스턴스로 라우팅하는 데 사용됩니다. Azure Front Door는 계층 7 전역 라우팅을 허용하며, 둘 다 이 참조 아키텍처에 필요합니다.
- Log Analytics 지역별 Log Analytics 인스턴스는 지역 네트워킹 메트릭 및 진단 로그를 저장하는 데 사용됩니다. 또한 공유 Log Analytics 인스턴스는 모든 AKS 인스턴스에 대한 메트릭 및 진단 로그를 저장하는 데 사용됩니다.
- 컨테이너 레지스트리 워크로드에 대한 컨테이너 이미지는 관리형 컨테이너 레지스트리에 저장됩니다. 이 아키텍처에서는 클러스터의 모든 Kubernetes 인스턴스에 단일 Azure Container Registry가 사용됩니다. Azure Container Registry에 지역 복제를 사용하면 선택한 Azure 지역에 이미지를 복제하여 지역에서 중단이 발생하더라도 이미지에 대한 지속적인 액세스를 제공할 수 있습니다.
디자인 패턴
이 참조 아키텍처는 다음 두 가지 클라우드 디자인 패턴을 사용합니다. 지리적 노드(지오드) - 모든 지역에서 모든 요청을 처리할 수 있습니다. 배포 스탬프 - 애플리케이션 또는 애플리케이션 구성 요소의 여러 독립 복사본이 단일 원본(배포 템플릿)에서 배포됩니다.
지리적 노드 패턴 고려 사항
각 AKS 클러스터를 배포할 지역을 선택할 때 워크로드 소비자 또는 고객과 가까운 지역을 고려합니다. 또한 지역 간 복제본(replica) 활용해 보세요. 지역 간 복제는 재해 복구 보호를 위해 다른 Azure 지역에서 동일한 애플리케이션 및 데이터를 비동기적으로 복제합니다. 클러스터가 두 지역을 넘어 확장됨에 따라 AKS 클러스터의 각 쌍에 대해 지역 간 복제본(replica) 연결을 계속 계획합니다.
각 지역 내에서 AKS 노드 풀의 노드는 영역 오류로 인한 문제를 방지하기 위해 여러 가용성 영역에 분산됩니다. 가용성 영역은 제한된 지역에서만 지원되며, 지역 클러스터 배치에 영향을 줍니다. 지원되는 지역 목록을 포함하여 AKS 및 가용성 영역에 대한 자세한 내용은 AKS 가용성 영역을 참조 하세요.
배포 스탬프 고려 사항
다중 지역 AKS 클러스터를 관리할 때 여러 AKS 인스턴스가 여러 지역에 배포됩니다. 이러한 각 인스턴스는 스탬프로 간주됩니다. 지역 오류가 발생하거나 클러스터에 더 많은 용량 및/또는 지역 현재 상태를 추가해야 하는 경우 새 스탬프 인스턴스를 만들어야 할 수 있습니다. 배포 스탬프를 만들고 관리하는 프로세스를 선택할 때 다음 사항을 고려해야 합니다.
- 코드로서의 인프라와 같은 일반화된 구성을 허용하는 스탬프 정의에 적합한 기술을 선택합니다.
- 변수 또는 매개 변수 파일과 같은 배포 입력 메커니즘을 사용하여 인스턴스별 값 제공
- 유연하고 반복 가능한 멱등 배포를 허용하는 배포 도구 선택
- 활성/활성 스탬프 구성에서는 스탬프 간의 트래픽 균형을 맞추는 방법을 고려
- 스탬프가 컬렉션에 추가 및 제거될 때 용량 및 비용 문제를 고려
- 스탬프 컬렉션을 단일 단위로 표시하거나 모니터링하는 방법을 고려합니다.
이러한 각 항목은 이 참조 아키텍처의 다음 섹션에 있는 지침에 자세히 설명되어 있습니다.
차량 관리
이 솔루션은 모든 클러스터를 통합 플릿의 일부로 처리하는 고급 오케스트레이터가 포함되지 않은 다중 클러스터 및 다중 지역 토폴로지를 나타냅니다. 클러스터 수가 증가하면 참여하는 클러스터의 대규모 관리를 위해 Azure Kubernetes Fleet Manager에 멤버를 등록하는 것이 좋습니다. 여기에 제시된 인프라 아키텍처는 Fleet Manager에 등록할 때 근본적으로 변경되지 않지만, 2일차 작업 및 유사한 활동은 여러 클러스터를 동시에 대상으로 할 수 있는 컨트롤 플레인의 이점을 활용합니다.
고려 사항
이러한 고려 사항은 워크로드의 품질을 향상시키는 데 사용할 수 있는 일단의 지침 원칙인 Azure Well-Architected Framework의 핵심 요소를 구현합니다. 자세한 내용은 Microsoft Azure Well-Architected Framework를 참조하세요.
클러스터 배포 및 부트스트랩
지리적으로 분산된 고가용성 구성으로 여러 Kubernetes 클러스터를 배포하는 경우 각 Kubernetes 클러스터의 합계를 결합된 단위로 고려해야 합니다. 자동화된 배포 및 구성을 위한 코드 기반 전략을 개발하여 각 Kubernetes 인스턴스가 가능한 한 동일하도록 할 수 있습니다. 다른 Kubernetes 인스턴스를 추가하거나 제거하여 규모 확장 및 축소 전략을 고려할 수 있습니다. 지역별 오류 또는 기타 일반적인 시나리오를 고려하여 디자인 및 배포 및 구성 계획을 사용할 수 있습니다.
클러스터 정의
Azure Kubernetes Service 클러스터를 배포하는 다양한 옵션이 있습니다. Azure Portal, Azure CLI 및 Azure PowerShell 모듈은 모두 개별 또는 결합되지 않은 AKS 클러스터를 배포하기 위한 적절한 옵션입니다. 그러나 이러한 방법은 많은 긴밀하게 결합된 AKS 클러스터로 작업할 때 문제가 발생할 수 있습니다. 예를 들어 Azure Portal을 사용하면 단계 누락 또는 사용할 수 없는 구성 옵션으로 인해 구성이 잘못될 수 있습니다. 뿐만 아니라 포털을 사용하는 많은 클러스터의 배포 및 구성은 한 명 이상의 엔지니어가 집중해서 적시에 처리해야 하는 프로세스입니다. 명령줄 도구를 사용하여 반복 가능하고 자동화된 프로세스를 생성할 수 있습니다. 그러나 멱등성, 배포 실패 제어 및 실패 복구에 대한 책임은 사용자와 사용자가 빌드하는 스크립트에 있습니다.
많은 AKS 인스턴스를 작업하는 경우 Azure Resource Manager 템플릿, Bicep 템플릿 또는 Terraform 구성과 같은 코드 제공 인프라(Infrastructure as code)를 사용하는 것이 좋습니다. 코드 제공 인프라(Infrastructure as code)는 자동화되고 확장 가능한 멱등 배포 솔루션을 제공합니다. 이 참조 아키텍처는 솔루션 공유 서비스를 위한 ARM 템플릿과 AKS 클러스터 + 지역 서비스를 위한 다른 템플릿을 포함하고 있습니다. 코드 제공 인프라(Infrastructure as code)를 사용하면 네트워킹, 권한 부여 및 진단과 같은 일반화된 구성으로 배포 스탬프를 정의할 수 있습니다. 배포 매개 변수 파일에 지역별 값을 제공할 수 있습니다. 이 구성을 사용하면 단일 템플릿을 사용하여 모든 지역에 거의 동일한 스탬프를 배포할 수 있습니다.
코드 제공 인프라(Infrastructure as code)를 개발하고 유지 관리하는 데 많은 비용이 들 수 있습니다. 정적/고정 수의 AKS 인스턴스가 배포되는 경우와 같은 경우에 코드로서의 인프라 오버헤드가 이점보다 클 수 있습니다. 이러한 경우 명령줄 도구 또는 수동 접근 방식과 같은 보다 명령적 접근 방식을 사용해도 됩니다.
클러스터 배포
클러스터 스탬프가 정의되었으면 여러 옵션을 통해 개별 또는 여러 스탬프 인스턴스를 배포할 수 있습니다. GitHub Actions 또는 Azure Pipelines와 같은 최신 연속 통합 기술을 사용하는 것이 좋습니다. 연속 통합 기반 배포 솔루션은 다음과 같은 이점이 있습니다.
- 코드를 사용하여 스탬프를 추가하고 제거할 수 있는 코드 기반 배포
- 통합 테스트 기능
- 통합 환경 및 준비 기능
- 통합 비밀 관리 솔루션
- 코드/배포 소스 제어와 통합
- 배포 기록 및 로깅
글로벌 클러스터에서 새 스탬프가 추가되거나 제거되면 일관성을 유지하기 위해 배포 파이프라인을 업데이트해야 합니다. 참조 구현에서 각 지역은 GitHub 작업 워크플로(예제) 내에 개별 단계로 배포됩니다. 이 구성은 각 클러스터 인스턴스가 배포 파이프라인 내에서 명확하게 정의된다는 측면에서 간단합니다. 이 구성에는 배포에서 클러스터를 추가하고 제거하는 데 약간의 관리 오버헤드가 포함됩니다.
또 다른 옵션은 논리를 활용하여 원하는 위치 목록 또는 데이터 요소를 나타내는 기타 목록을 기반으로 클러스터를 만드는 것입니다. 예를 들어 배포 파이프라인에는 원하는 지역 목록이 포함될 수 있습니다. 그리고 파이프라인 내의 단계가 이 목록을 반복하고, 목록에 있는 각 지역에 클러스터를 배포할 수 있습니다. 이 구성의 단점은 배포 일반화가 복잡하고 각 클러스터 스탬프가 배포 파이프라인에서 명시적으로 자세히 설명되지 않는다는 점입니다. 긍정적인 이점은 파이프라인에 클러스터 스탬프를 추가 또는 제거하면 원하는 지역 목록이 간단하게 업데이트된다는 것입니다.
또한 배포 파이프라인에서 클러스터 스탬프를 제거한다고 해서 반드시 서비스 해제가 보장되는 것은 아닙니다. 배포 솔루션 및 구성에 따라 AKS 인스턴스가 적절하게 서비스 해제되었는지 확인하기 위한 추가 단계가 필요할 수 있습니다.
클러스터 부트스트랩
각 Kubernetes 인스턴스 또는 스탬프가 배포되면 수신 컨트롤러, ID 솔루션 및 워크로드 구성 요소와 같은 클러스터 구성 요소를 배포하고 구성해야 합니다. 또한 클러스터 전체에 보안, 액세스 및 거버넌스 정책을 적용하는 것도 고려해야 합니다.
배포와 마찬가지로 이러한 구성은 여러 Kubernetes 인스턴스에서 수동으로 관리하기가 어려울 수 있습니다. 따라서 이렇게 하지 말고 대규모 구성 및 정책이 가능한 다음 옵션을 사용하는 것이 좋습니다.
GitOps
Kubernetes 구성 요소를 수동으로 구성하는 대신 자동화된 메서드를 사용하여 Kubernetes 클러스터에 구성을 적용하는 것이 좋습니다. 이러한 구성은 원본 리포지토리에 검사. 이 프로세스를 GitOps라고도 하며, Kubernetes에 많이 사용되는 GitOps 솔루션은 Flux 및 Argo CD입니다. 이 구현에서는 AKS용 Flux 확장을 사용하여 클러스터가 배포된 직후에 클러스터를 자동으로 부트스트래핑할 수 있도록 합니다.
GitOps는 AKS 기준 참조 아키텍처에서 자세히 설명합니다. 여기서 중요한 점은 구성에 GitOps 기반 접근 방식을 사용하면 각 Kubernetes 인스턴스가 맞춤형 작업 없이 유사하게 구성되도록 하는 데 도움이 된다는 것입니다. 이는 플릿의 크기가 커짐에 따라 더욱 중요해집니다.
Azure Policy
여러 Kubernetes 인스턴스가 추가되면 정책 기반 거버넌스, 규정 준수 및 구성의 이점이 증가합니다. 특히 Azure Policy는 정책을 활용하여 클러스터 제어를 위한 중앙 집중식 확장성 있는 방법을 제공합니다. AKS 정책의 이점은 AKS 기준 참조 아키텍처에 자세히 설명되어 있습니다.
AKS 클러스터가 만들어지고 감사 모드에서 제한적인 이니셔티브를 할당하여 규정 비준수에 대한 가시성을 확보하면 이 참조 구현에서 Azure Policy를 사용할 수 있습니다. 또한 이 구현은 기본 제공 이니셔티브에 포함되지 않은 추가 정책을 설정합니다. 이러한 정책은 거부 모드로 설정됩니다. 예를 들어 승인된 컨테이너 이미지만 클러스터에서 실행되도록 하는 정책이 있습니다. 고유의 사용자 지정 이니셔티브를 만드는 것이 좋습니다. 워크로드에 적용 가능한 정책을 단일 할당으로 결합합니다.
정책 범위는 각 정책 및 정책 이니셔티브의 대상을 의미합니다. 이 아키텍처와 연결된 참조 구현에서는 ARM 템플릿을 사용하여 각 AKS 클러스터가 배포되는 리소스 그룹에 정책을 할당합니다. 전역 클러스터의 공간이 증가할수록 많은 정책이 중복됩니다. 정책의 범위를 Azure 구독 또는 Azure 관리 그룹으로 지정할 수도 있습니다. 이 방법을 사용하면 구독 범위 내의 모든 AKS 클러스터 및/또는 관리 그룹에 있는 모든 구독에 단일 정책 집합을 적용할 수 있습니다.
여러 AKS 클러스터에 대한 정책을 디자인할 때 다음 사항을 고려해야 합니다.
- 모든 AKS 인스턴스에 전역적으로 적용해야 하는 정책은 관리 그룹 또는 구독에 적용할 수 있습니다.
- 각 지역별 클러스터를 자체 리소스 그룹에 배치하면 지역별 정책을 리소스 그룹에 적용할 수 있습니다.
정책 관리 전략을 수립하는 데 도움이 되는 자료는 클라우드 채택 프레임워크 리소스 조직을 참조하세요.
워크로드 배포
AKS 인스턴스 구성 외에도 각 지역별 인스턴스 또는 스탬프에 배포되는 워크로드를 고려해야 합니다. 배포 솔루션 또는 파이프라인에서 각 지역별 스탬프를 수용하기 위한 구성이 필요합니다. 전역 클러스터에 더 많은 스탬프가 추가되면 새로운 지역별 인스턴스를 수용할 수 있을 만큼 배포 프로세스를 확장하거나 배포 프로세스가 유연해야 합니다.
워크로드 배포를 계획할 때 다음 사항을 고려해야 합니다.
- 단일 배포 구성을 여러 클러스터 스탬프에 사용할 수 있도록 Helm 차트와 마찬가지로 배포를 일반화합니다.
- 모든 클러스터 스탬프에 워크로드를 배포하도록 구성된 단일 지속적인 배포 파이프라인을 사용합니다.
- 스탬프별 인스턴스 세부 정보를 배포 매개 변수로 제공합니다.
- 애플리케이션 전체를 관찰할 수 있도록 애플리케이션 진단 로깅 및 분산 추적을 구성하는 방법을 고려합니다.
고가용성 및 장애 조치(failover)
다중 지역 Kubernetes 아키텍처를 선택하는 중요한 동기는 서비스 가용성입니다. 즉, 한 지역에서 서비스 또는 서비스 구성 요소를 사용할 수 없게 되면 해당 서비스를 사용할 수 있는 지역으로 트래픽을 라우팅해야 합니다. 다중 지역 아키텍처는 실패 지점이 여러 개 있습니다. 이 섹션에서는 이러한 잠재적 실패 지점에 대해 설명합니다.
애플리케이션 Pod(지역)
Kubernetes 배포 개체는 Pod의 여러 복제본(ReplicaSet)을 만드는 데 사용됩니다. 하나를 사용할 수 없게 되면 트래픽이 나머지 사이에서 라우팅됩니다. Kubernetes ReplicaSet는 지정된 수의 복제본을 계속 가동하려고 시도합니다. 한 인스턴스가 다운되면 새 인스턴스를 다시 만들어야 합니다. 마지막으로, 활동성 프로브를 사용하여 Pod에서 실행 중인 애플리케이션 또는 프로세스의 상태를 확인할 수 있습니다. 서비스가 응답하지 않는 경우 활동성 프로브는 Pod를 제거하여 ReplicaSet에서 새 인스턴스를 강제로 만듭니다.
자세한 내용은 Kubernetes ReplicaSet를 참조하세요.
애플리케이션 Pod(전역)
전체 지역이 사용할 수 없게 되면 클러스터의 Pod가 더 이상 요청을 처리할 수 없습니다. 이 경우 Azure Front Door 인스턴스는 모든 트래픽을 나머지 정상 지역으로 라우팅합니다. 이러한 지역의 Kubernetes 클러스터 및 Pod는 계속해서 요청을 처리합니다.
이 상황에서는 나머지 클러스터의 트래픽/요청 증가를 보상합니다. 다음가 같은 몇 가지 사항을 고려해야 합니다.
- 네트워크 및 컴퓨팅 리소스가 지역 장애 조치(failover)로 인한 급격한 트래픽 증가를 흡수할 수 있도록 적절한 크기로 조정합니다. 예를 들어 Azure CNI를 사용하는 경우 트래픽 부하가 급증하는 모든 Pod IP를 지원할 수 있는 서브넷을 확보합니다.
- 늘어난 지역 수요를 보상할 수 있도록 Horizontal Pod Autoscaler를 활용하여 Pod 복제본 수를 늘립니다.
- 늘어난 지역 수요를 보상할 수 있도록 AKS Cluster Autoscaler를 활용하여 Kubernetes 인스턴스 노드 수를 늘립니다.
자세한 내용은 Horizontal Pod Autoscaler 및 AKS Cluster Autoscaler를 참조하세요.
Kubernetes 노드 풀(지역)
Azure 서버 단일 랙의 전력 공급이 중단되는 경우처럼 가끔 컴퓨팅 리소스에 지역 장애가 발생할 수 있습니다. AKS 노드가 단일 지역 실패 지점이 되지 않도록 하려면 Azure 가용성 영역을 활용합니다. 가용성 영역을 사용하면 특정 영역의 AKS 노드가 다른 가용성 영역에 정의된 AKS 노드와 물리적으로 분리됩니다.
자세한 내용은 AKS 및 Azure 가용성 영역을 참조하세요.
Kubernetes 노드 풀(전역)
한 지역 전체가 사용할 수 없게 되면 Azure Front Door는 트래픽을 나머지 정상 지역으로 라우팅합니다. 마찬가지로, 이 상황에서는 나머지 클러스터의 트래픽/요청 증가를 보상합니다.
자세한 내용은 Azure Front Door를 참조하세요.
네트워크 토폴로지
AKS 기준 참조 아키텍처와 마찬가지로, 이 아키텍처는 허브 스포크 네트워크 토폴로지를 사용합니다. AKS 기준 참조 아키텍처에 나와 있는 고려 사항 외에도 다음 모범 사례를 고려해야 합니다.
- 허브-스포크 가상 네트워크가 피어링되도록 각 지역 AKS 인스턴스에 대해 허브-스포크를 구현합니다.
- 각 지역 허브 네트워크에 있는 Azure Firewall 인스턴스를 통해 모든 아웃바운드 트래픽을 라우팅합니다. Azure Firewall Manager 정책을 활용하여 모든 지역의 방화벽 정책을 관리합니다.
- 지역 장애가 발생하면 AKS 기준 참조 아키텍처의 IP 크기 조정을 따르고 노드 및 Pod 스케일링 작업에 더 많은 IP 주소를 허용합니다.
트래픽 관리
AKS 기준 참조 아키텍처를 사용하면 워크로드 트래픽이 Azure Application Gateway 인스턴스로 직접 라우팅된 다음, 백 엔드 부하 분산 장치/AKS 수신 리소스로 전달됩니다. 여러 클러스터로 작업하는 경우에는 클라이언트 요청이 Azure Front Door 인스턴스를 통해 라우팅되고, 다시 Azure Application Gateway 인스턴스로 라우팅됩니다.
이 다이어그램의 Visio 파일을 다운로드합니다.
사용자가 Azure Front Door 인스턴스로 확인되는 도메인 이름(예:
https://contoso-web.azurefd.net)에 요청을 보냅니다. 이 요청은 Azure Front Door의 모든 하위 도메인에 대해 발급된 와일드카드 인증서(*.azurefd.net)로 암호화됩니다. Azure Front Door 인스턴스는 WAF 정책과 비교하여 요청의 유효성을 검사하고, 가장 빠른 백 엔드를 선택하고(상태 및 대기 시간 기준), 공용 DNS를 사용하여 백 엔드 IP 주소(Azure Application Gateway 인스턴스)를 확인합니다.Front Door는 사용자가 선택한 적절한 Application Gateway 인스턴스에 요청을 전달합니다. 이 인스턴스는 지역 스탬프의 진입점 역할을 합니다. 트래픽이 인터넷을 통해 흐르고 Azure Front Door에 의해 암호화됩니다. Application Gateway 인스턴스가 Front Door 인스턴스의 트래픽만 허용하는 방법을 사용하는 것이 좋습니다. 한 가지 방법은 서브넷에서 Application Gateway를 포함하는 네트워크 보안 그룹을 사용하는 것입니다. 규칙은 원본, 포트, 대상과 같은 속성에 따라 인바운드(또는 아웃바운드) 트래픽을 필터링할 수 있습니다. 원본 속성을 통해 Azure 리소스의 IP 주소를 나타내는 기본 제공 서비스 태그를 설정할 수 있습니다. 이 추상화는 규칙을 쉽게 구성 및 유지 관리하고 IP 주소를 추적할 수 있게 합니다. 또한 Application Gateway 인스턴스가 Front Door 인스턴스의 트래픽만 허용하도록 백 엔드
X-Azure-FDID헤더에 Front Door를 활용하는 것이 좋습니다. Front Door 헤더에 대한 자세한 내용은 Azure Front Door의 HTTP 헤더에 대한 프로토콜 지원을 참조하세요.
공유 리소스 고려 사항
이 참조 아키텍처는 여러 Azure 지역에 여러 Kubernetes 인스턴스를 분산하는 데 중점을 두고 있지만, 모든 인스턴스에서 공유 리소스를 사용하는 것도 좋습니다. 단일 ARM 템플릿을 사용하여 모든 공유 리소스를 배포한 다음, 다른 템플릿을 사용하여 각 지역 스탬프를 배포하는 AKS 다중 지역 참조 구현입니다. 이 섹션에서는 여러 AKS 인스턴스에서 각 공유 리소스를 사용하기 위한 각 공유 리소스 및 고려 사항에 대해 자세히 설명합니다.
Container Registry
Azure Container Registry는 이 참조 아키텍처에서 컨테이너 이미지 서비스(끌어오기)를 제공하는 데 사용됩니다. 다중 지역 클러스터 배포에 Azure Container Registry를 사용할 때에는 다음 사항을 고려해야 합니다.
지리적 가용성
AKS 클러스터가 배포된 각 지역에 컨테이너 레지스트리를 배치하면 네트워크 닫기 작업을 수행할 수 있으므로 빠르고 안정적인 이미지 계층 전송이 가능합니다. 여러 이미지 서비스 엔드포인트가 있으면 지역 서비스를 사용할 수 없는 경우에도 가용성이 제공됩니다. Azure Container Registries 지역 복제 기능을 사용하면 여러 지역에 복제된 하나의 Container Registry 인스턴스를 관리할 수 있습니다.
AKS 다중 지역 참조 구현은 각 클러스터 지역에 이 인스턴스의 단일 Container Registry 인스턴스 및 복제본을 만들었습니다. Azure Container Registry 복제에 대한 자세한 내용은 Azure Container Registry의 지역 복제를 참조하세요.
Azure Portal 내의 여러 ACR 복제본을 보여주는 이미지
클러스터 액세스
각 AKS 인스턴스는 Azure Container Registry에서 이미지 계층을 끌어올 수 있는 액세스 권한이 필요합니다. Azure Container Registry에 대한 액세스를 설정하는 여러 가지 방법이 있습니다. 이 참조 아키텍처는 각 클러스터에 Azure 관리 ID를 사용합니다. 그러면 Container Registry 인스턴스에 AcrPull 역할이 부여됩니다. Container Registry 액세스에 관리 ID를 사용하는 방법에 대한 자세한 내용과 권장 사항은 AKS 기준 참조 아키텍처를 참조하세요.
새 스탬프가 배포될 때마다 새 AKS 인스턴스에 액세스 권한이 부여되도록 이 구성은 클러스터 스탬프 ARM 템플릿에 정의됩니다. Container Registry는 공유 리소스이므로, 배포 스탬프 템플릿에서 필요한 세부 정보(여기서는 Container Registry의 리소스 ID)를 사용할 수 있도록 합니다.
Azure Monitor
Azure Monitor 컨테이너 인사이트 기능은 클러스터 및 컨테이너 워크로드의 성능과 상태를 모니터링하고 이해하는 데 권장되는 도구입니다. 컨테이너 인사이트는 로그 데이터를 저장하기 위해 Log Analytics 작업 영역과 Azure Monitor 메트릭을 모두 활용하여 숫자 시계열 데이터를 저장합니다 . Prometheus 메트릭은 Container Insights에서 수집하고 Prometheus 또는 Azure Monitor 로그에 대한 Azure Monitor 관리 서비스로 데이터를 보낼 수도 있습니다.
AKS 컨트롤 플레인 구성 요소에서 리소스 로그를 수집하고 분석하고 Log Analytics 작업 영역으로 전달하도록 AKS 클러스터 진단 설정을 구성할 수도 있습니다.
AKS에 대한 자세한 내용은 AKS 기준 참조 아키텍처를 참조하세요.
이 참조 아키텍처와 같은 지역 간 구현에 대한 모니터링을 고려할 때 각 스탬프 간의 결합을 생각해야 합니다. 이 경우 각 스탬프를 단일 단위(지역 클러스터)의 구성 요소로 간주합니다. 다중 지역 AKS 참조 구현은 각 Kubernetes 클러스터에서 공유하는 단일 Log Analytics 작업 영역을 활용합니다. 다른 공유 리소스와 마찬가지로 단일 Log Analytics 작업 영역에 대한 정보를 사용하고 각 클러스터를 연결하도록 지역 스탬프를 정의합니다.
이제 각 지역 클러스터가 단일 Log Analytics 작업 영역에 진단 로그를 내보내고 있으므로 리소스 메트릭과 함께 이 데이터를 사용하여 전역 클러스터 전체를 나타내는 보고서 및 대시보드를 보다 쉽게 빌드할 수 있습니다.
Azure Front Door
Azure Front Door는 트래픽 부하를 분산하고 각 AKS 클러스터로 라우팅하는 데 사용됩니다. Azure Front Door는 계층 7 전역 라우팅을 허용하며, 둘 다 이 참조 아키텍처에 필요합니다.
클러스터 구성
지역 AKS 인스턴스가 추가되면 적절한 라우팅을 위해 Kubernetes 클러스터와 함께 배포된 Application Gateway를 Front Door 백 엔드로 등록해야 합니다. 이 작업을 수행하려면 코드 제공 인프라(Infrastructure as code) 자산을 업데이트해야 합니다. 또는 이 작업을 배포 구성에서 분리하고 Azure CLI와 같은 도구로 관리할 수도 있습니다. 포함된 참조 구현 배포 파이프라인은 이 작업에 고유한 Azure CLI 단계를 활용합니다.
인증서
Front Door는 개발/테스트 환경에서도 자체 서명된 인증서를 지원하지 않습니다. HTTPS 트래픽을 사용하려면 CA(인증 기관)에서 서명한 TLS/SSL 인증서를 만들어야 합니다. 참조 구현에서는 Certbot을 사용하여 Let's Encrypt Authority X3 인증서를 만듭니다. 프로덕션 클러스터를 계획할 때에는 조직에서 선호하는 TLS 인증서 조달 방법을 사용합니다.
Front Door에서 지원하는 다른 CA에 대한 자세한 내용은 Azure Front Door에서 사용자 지정 HTTPS를 사용하도록 설정하기 위한 허용된 인증 기관을 참조 하세요.
클러스터 액세스 및 ID
AKS 기준 참조 아키텍처에서 설명한 대로 Microsoft Entra ID를 클러스터의 액세스 ID 공급자로 사용하는 것이 좋습니다. 그런 다음, Microsoft Entra 그룹을 사용하여 클러스터 리소스에 대한 액세스를 제어할 수 있습니다.
여러 클러스터를 관리할 때에는 액세스 스키마를 결정해야 합니다. 다음 옵션을 사용할 수 있습니다.
- 구성원이 클러스터의 모든 Kubernetes 인스턴스에서 모든 개체에 액세스할 수 있는 전역 클러스터 수준 액세스 그룹을 만듭니다. 이 옵션은 관리 부담이 최소화되지만 모든 그룹 구성원에게 상당한 권한을 부여합니다.
- Kubernetes 인스턴스마다 개별 클러스터 인스턴스의 개체에 대한 액세스 권한을 부여하는 데 사용되는 개별 액세스 그룹을 만듭니다. 이 옵션을 사용하면 관리 오버헤드가 증가하지만 보다 세밀한 클러스터 액세스가 제공됩니다.
- Kubernetes 개체 형식 및 네임스페이스에 대한 세분화된 액세스 제어를 정의하고 그 결과를 Azure Directory 그룹 구조와 상호 연결합니다. 이 옵션을 사용하면 관리 오버헤드가 크게 증가하지만 각 클러스터뿐만 아니라 각 클러스터 내부의 네임스페이스 및 Kubernetes API에 대한 세밀한 액세스가 제공됩니다.
포함된 참조 구현을 사용하면 관리자 액세스를 위해 두 개의 Microsoft Entra 그룹이 만들어집니다. 두 그룹은 클러스터 스탬프 배포 시간에 배포 매개 변수 파일을 사용하여 지정됩니다. 각 그룹의 구성원은 해당 클러스터 스탬프에 대한 모든 액세스 권한을 갖습니다.
Microsoft Entra ID를 사용하여 AKS 클러스터 액세스를 관리하는 방법에 대한 자세한 내용은 AKS Microsoft Entra 통합을 참조하세요.
데이터, 상태 및 캐시
전역 분산 AKS 인스턴스 클러스터를 사용하는 경우 클러스터에서 실행될 수 있는 애플리케이션, 프로세스 또는 기타 워크로드의 아키텍처를 고려해야 합니다. 클러스터에 분산된 상태 기반 워크로드가 상태 저장소에 액세스해야 하나요? 장애로 인해 클러스터의 다른 곳에 프로세스가 다시 만들어질 때 워크로드 또는 프로세스가 계속해서 종속 상태 저장소 또는 캐싱 솔루션에 액세스해야 하나요? 상태는 여러 가지 방법으로 달성할 수 있지만 단일 Kubernetes 클러스터에서는 복잡할 수 있습니다. 여러 클러스터형 Kubernetes 인스턴스를 추가하면 복잡성이 증가합니다. 지역 액세스 및 복잡성 문제로 인해 전역적으로 분산된 상태 저장소 서비스를 사용하도록 애플리케이션을 디자인하는 것이 좋습니다.
다중 클러스터 참조 구현에는 상태 문제에 대한 데모 또는 구성이 포함되어 있지 않습니다. 클러스터형 AKS 인스턴스에서 애플리케이션을 실행하는 경우에는 Azure Cosmos DB와 같은 전역 분산 데이터 서비스를 사용하도록 워크로드를 설계하는 것이 좋습니다. Azure Cosmos DB는 데이터베이스의 로컬 복제본에서 데이터를 읽고 쓸 수 있도록 하는 전역적으로 분산된 데이터베이스 시스템입니다. 자세한 내용은 Azure Cosmos DB를 참조하세요.
워크로드가 캐싱 솔루션을 활용하는 경우 캐싱 서비스가 계속 작동하도록 설계되었는지 확인합니다. 이렇게 하려면 워크로드 자체가 캐시 관련 장애 조치(failover)에 복원력이 있고 캐싱 솔루션이 모든 지역 AKS 인스턴스에 있어야 합니다.
비용 최적화
Azure 가격 계산기를 사용하여 아키텍처에 사용되는 서비스 비용을 예측합니다. 기타 모범 사례는 Microsoft Azure 잘 설계된 프레임워크의 비용 최적화 섹션과 비용 최적화 문서의 특정 비용 최적화 구성 옵션에 설명되어 있습니다.
Kubernetes 특정 구문에 의한 세분화된 클러스터 인프라 비용 할당에 AKS 비용 분석을 사용하도록 설정하는 것이 좋습니다.