이 문서는 AKS 클러스터를 프로덕션 환경에 배포하기 위한 권장 구성에 대한 철저한 검토를 제공하는 AKS 기준 아키텍처의 확장으로 간주됩니다. 이 문서의 핵심은 AKS에 Windows 컨테이너를 배포하는 방법에 대한 지침을 제공하는 것입니다. 따라서 이 문서에서는 AKS에서 Windows를 배포하는 것과 관련된 구성에 중점을 두고 있으며, 이미 설명된 구성에 대한 AKS 기준 설명서를 다시 참조해야 합니다.
샘플 배포 코드를 포함하여 이 참조 아키텍처와 연결된 참조 구현을 검토하려면 AKS Windows 기준 GitHub 프로젝트를 참조하세요.
네트워크 설계
이 아키텍처에 사용되는 네트워크 디자인은 AKS 기준 아키텍처에서 사용되는 디자인을 기반으로 하므로 다음 변경 내용을 제외하고 모든 핵심 구성 요소를 해당 디자인과 공유합니다.
- Windows 기반 워크로드를 지원하기 위해 Active Directory do기본 컨트롤러가 추가되었습니다.
- 이 아키텍처의 수신 솔루션은 AKS 기준 아키텍처에서 사용되는 Azure 앱 게이트웨이 대신 AFD(Azure Front Door) 및 AAP(Microsoft Entra 애플리케이션 프록시)를 사용합니다.
참고 항목
Windows 워크로드를 AKS로 마이그레이션하는 데는 일반적으로 주요 리팩터링 작업이 포함되지 않으며, 따라서 워크로드는 비교적 쉽게 온-프레미스를 구현할 수 있는 기능을 사용할 수 있지만 Azure에서는 문제가 될 수 있습니다. 한 가지 예는 gMSA 및 Kerberos 인증을 사용하는 애플리케이션입니다. 이는 일반적인 사용 사례이므로 이 아키텍처는 이러한 워크로드의 요구 사항을 해결하는 구성 요소를 제공합니다. 특히 AFD가 앞에 있는 AAP를 수신 경로의 일부로 사용합니다. 워크로드에 이 지원이 필요하지 않은 경우 수신에 대한 AKS 기준과 동일한 지침을 따를 수 있습니다.
수신 디자인
구성 요소:
- WAF를 사용하는 Azure Front Door: AFD는 AKS 클러스터에서 호스트되는 앱에 대한 공용 수신 지점입니다. AFD Premium은 프라이빗 네트워킹에 내부 앱 트래픽을 잠그고 최고 수준의 보안을 제공하는 Private Link를 사용할 수 있도록 하기 때문에 이 디자인에 사용됩니다. WAF(웹 애플리케이션 방화벽 )는 일반적인 웹 애플리케이션 악용 및 취약성으로부터 보호합니다.
- Microsoft Entra 애플리케이션 프록시: 이 구성 요소는 AKS에서 관리하는 내부 부하 분산 장치 앞의 두 번째 수신 지점 역할을 합니다. 사용자의 사전 인증을 위해 Microsoft Entra ID를 사용하도록 설정했으며 조건부 액세스 정책을 사용하여 권한 없는 IP 범위(AAP는 조건부 액세스 정책과 비교되는 원래 클라이언트 IP를 확인) 및 사용자가 사이트에 액세스하지 못하도록 방지합니다. WAF를 지원하는 Azure 서비스를 사용하는 동안 Kerberos 인증 요청을 라우팅하는 유일한 방법입니다. 애플리케이션 프록시 보호된 앱에 대한 Single Sign-On 액세스를 제공하는 자세한 설명은 애플리케이션 프록시 사용하여 앱에 대한 SSO(Single Sign-On)에 대한 Kerberos 제한 위임을 참조하세요.
- 내부 부하 분산 장치: AKS에서 관리합니다. 이 부하 분산 장치는 개인 고정 IP 주소를 통해 수신 컨트롤러를 노출합니다. 인바운드 HTTP 요청을 수신하는 단일 연락처 지점 역할을 합니다.
- 이 아키텍처에서는 클러스터 내 수신 컨트롤러(예: Nginx)가 사용되지 않습니다.
이 디자인을 구현하려면 앱이 해당 서비스에 게시될 때 생성되는 애플리케이션 프록시 URL을 사용하도록 AFD를 구성해야 합니다. 이 구성은 인바운드 트래픽을 프록시로 라우팅하고 사전 인증이 수행되도록 허용합니다.
참고 항목
클라이언트 원본 IP 유지 는 지원되지 않으므로 애플리케이션 설계자는 원본 IP 주소에 의존하는 앱에 대해 클러스터 외부에서 해당 논리를 외부화하기 위한 대체 조치를 계획해야 합니다.
네트워크 토폴로지
아래 다이어그램은 이 아키텍처에 사용되는 허브-스포크 네트워크 디자인을 보여 줍니다.
이 아키텍처의 Visio 파일을 다운로드합니다.
노드 풀 토폴로지
이 아키텍처는 Linux를 실행하는 시스템 노드 풀, Linux를 실행하는 사용자 노드 풀 및 Windows를 실행하는 사용자 노드 풀의 세 가지 노드 풀을 사용합니다. Windows 및 Linux 사용자 노드 풀은 워크로드에 사용되고 시스템 노드 풀은 CoreDNS와 같은 모든 시스템 수준 구성에 사용됩니다.
수신 트래픽 흐름
- 클라이언트는 도메인 이름(bicycle.contoso.com)에 HTTPS 요청을 보냅니다. 해당 이름은 Azure Front Door의 공용 IP 주소에 대한 DNS A 레코드와 연결됩니다. 이 트래픽은 클라이언트 브라우저와 게이트웨이 간의 트래픽을 검사하거나 변경할 수 없도록 암호화됩니다.
- Azure Front Door에는 WAF(통합 웹 애플리케이션 방화벽)가 있으며 bicycle.contoso.com TLS 핸드셰이크를 협상하여 보안 암호만 허용합니다. Azure Front Door Gateway는 WAF 검사 규칙을 처리하고 트래픽을 구성된 백 엔드로 전달하는 라우팅 규칙을 실행하는 데 필요하므로 TLS 종료 지점입니다. TLS 인증서는 Azure Key Vault에 저장되며,
- AFD는 사용자 요청을 Azure 애플리케이션 프록시로 라우팅합니다. AFD는 HTTPS 트래픽만 허용하도록 구성됩니다. 사전 인증을 사용하는 경우 사용자는 Microsoft Entra ID로 인증해야 합니다.
- 앱 프록시는 AKS 부하 분산 장치를 통해 사용자를 백 엔드 앱 컨테이너로 라우팅합니다.
참고 항목
흐름의 모든 홉에서 엔드투엔드 TLS 트래픽을 적용할 수 있지만 Pod 간 트래픽 보안을 결정할 때 성능, 대기 시간 및 운영 영향을 측정하는 것이 좋습니다. 적절한 제어 평면 RBAC 및 완성도 높은 소프트웨어 개발 수명 주기 방식을 사용하는 대부분의 단일 테넌트 클러스터의 경우 수신 컨트롤러까지 암호화를 강제 적용하고 WAF(웹 애플리케이션 방화벽)를 사용하여 백 엔드를 보호하는 것으로 충분합니다. 이 구성은 워크로드 관리 및 네트워크 성능 영향의 오버헤드를 최소화합니다. 워크로드 및 규정 준수 요구 사항에 따라 TLS 종료를 수행하는 위치가 결정됩니다.
송신 트래픽 흐름
AKS 기준 문서에 있는 모든 지침은 Windows 워크로드에 대한 추가 권장 사항과 함께 여기에 적용됩니다. 자동 Windows Server 업데이트를 활용하려면 Azure Firewall 규칙 집합에서 필요한 FQDN을 차단해서는 안 됩니다.
참고 항목
Linux 기반 및 Windows 기반 워크로드에 대해 별도의 노드 풀을 사용하려면 노드 선택기를 사용하여 지정된 워크로드를 배포할 때 워크로드 유형에 따라 적절한 노드 풀에 배포되도록 해야 합니다.
IP 주소 계획
Linux 노드 풀이 있는 AKS 클러스터와 달리 Windows 노드 풀이 있는 AKS 클러스터에는 Azure CNI가 필요합니다. Azure CNI를 사용하면 Pod에 Azure Virtual Network의 IP 주소가 할당될 수 있습니다. 그런 다음 Pod는 다른 디바이스와 마찬가지로 Azure Virtual Network를 통해 통신할 수 있습니다. ExpressRoute 또는 VPN을 사용하여 다른 Pod, 피어링된 네트워크 또는 온-프레미스 네트워크에 연결하거나 Private Link를 사용하여 다른 Azure 서비스에 연결할 수 있습니다.
AKS 기준 아키텍처 문서에 제공된 IP 주소 계획에 대한 모든 지침은 여기에 적용되며, 한 가지 추가 권장 사항인 할 일기본 컨트롤러에 대한 전용 서브넷 프로비저닝을 고려하세요. Windows 노드 풀과 관련하여 다른 노드 풀에서 별도의 서브넷을 통해 논리적으로 분리하는 것이 좋습니다.
노드 풀 업그레이드
Windows 노드 업그레이드 프로세스는 AKS(Azure Kubernetes Service) 노드 이미지 업그레이드 설명서에 제공된 지침과 변경되지 않지만 업그레이드 주기를 계획하려면 다음 일정 차이를 고려해야 합니다.
Microsoft는 매월 노드에 대해 최신 패치를 포함한 새로운 Windows Server 이미지를 제공하며 자동 패치 또는 업데이트를 수행하지 않습니다. 따라서 이 일정에 따라 노드를 수동으로 또는 프로그래밍 방식으로 업데이트해야 합니다. GitHub Actions를 사용하여 일정에 따라 실행되는 cron 작업을 만들면 매월 업그레이드를 프로그래밍 방식으로 예약할 수 있습니다. 위에 연결된 설명서에 제공된 지침은 Linux 노드 프로세스를 반영하지만 YAML 파일을 업데이트하여 cron 일정을 격주 단위가 아닌 매월 실행하도록 설정할 수 있습니다. 또한 YAML 파일의 "runs-on" 매개 변수를 "windows-latest"로 변경하여 최신 Windows Server 이미지로 업그레이드해야 합니다.
추가 지침은 작업자 노드 패치 및 업데이트에 대한 AKS 운영자 가이드를 참조하세요.
참고 항목
노드 및 노드 풀 업그레이드를 수행하기 전에 클러스터를 업그레이드해야 합니다. 클러스터 업그레이드 지침에 따라 업그레이드를 수행합니다.
컴퓨팅 고려 사항
Windows 서버 기반 이미지와 연결된 이미지 크기가 클수록 노드 풀에 적절한 크기의 OS 디스크를 배포해야 합니다. Windows를 비롯한 모든 노드에는 임시 OS 디스크를 사용하는 것이 좋습니다. 따라서 배포를 계획할 때 준수해야 하는 크기 요구 사항을 이해해야 합니다.
ID 관리
Windows 컨테이너는 조인할 수 없으므로기본 Active Directory 인증 및 권한 부여가 필요한 경우 gMSA(그룹 관리 서비스 계정)를 사용할 수 있습니다. gMSA를 사용하려면 Windows 노드를 실행하는 AKS 클러스터에서 gMSA 프로필을 사용하도록 설정해야 합니다. 아키텍처에 대한 전체 검토 및 프로필 사용 가이드는 gMSA AKS 설명서를 참조하세요.
노드 및 Pod 크기 조정
Windows 컨테이너에 대한 클러스터 자동 크기 조정기 지침은 변경되지 않습니다. 지침은 클러스터 자동 크기 조정기 설명서를 참조하세요.
기준 클러스터 설명서에서는 Pod 크기 조정에 사용할 수 있는 수동 및 자동 크기 조정 방법을 설명합니다. 두 방법 모두 Windows 컨테이너를 실행하는 클러스터에 사용할 수 있으며 이 문서에 제공된 지침 은 일반적으로 여기에도 적용됩니다.
Pod 크기 조정 작업과 관련하여 Linux 컨테이너와 Windows 컨테이너 간에 다른 점은 대부분의 경우 이미지 크기입니다. Windows 컨테이너의 이미지 크기가 클수록 크기 조정 작업이 완료되는 시간이 늘어나므로 크기 조정 방법에 대한 몇 가지 고려 사항을 고려해야 합니다. 이 시나리오는 .NET 런타임의 크기로 인해 레거시 .NET 애플리케이션에서 일반적입니다. 크기 조정 시간 동안 이미지를 아래로 끌어오는 지연을 완화하기 위해 DaemonSet을 사용하여 ACR에서 이미지를 끌어와 모든 Windows 노드에서 캐시하므로 이미지가 미리 로드된 Pod를 스핀업할 수 있습니다. 이 시점부터 Pod는 온라인 상태가 되기 전에 워크로드에 대해 정의된 앱 구성 프로세스를 실행하기만 하면 됩니다.
벤치마킹 연습을 수행하여 크기 조정 작업을 수행할 때의 시간 영향을 이해해야 하며 이 데이터는 비즈니스 요구 사항에 따라 측정되어야 합니다. 워크로드가 자동 크기 조정을 통해 가능한 것보다 빠르게 확장해야 하는 경우 다음과 같은 대체 "핫 스페어" 솔루션을 고려하는 것이 좋습니다.
먼저 기준 테스트를 수행하여 최대 로드 시간 및 사용량이 적은 로드 시간에 실행해야 하는 Pod 수를 식별해야 합니다. 이 기준이 설정되면 언제든지 사용할 수 있어야 하는 총 노드 수를 고려하여 노드 수를 계획할 수 있습니다. 이 솔루션에는 클러스터에 대해 수동 크기 조정을 사용하고 초기 노드 수를 필요한 사용량이 적은 노드 수로 설정하는 작업이 포함됩니다. 사용량이 많은 기간에 도달하면 노드의 최대 로드 시간 수로 선제적으로 크기를 조정해야 합니다. 시간이 지남에 따라 앱 사용량 또는 기타 비즈니스 요구 사항 변경을 고려하여 정기적으로 기준을 다시 설정해야 합니다.
모니터링
Windows를 실행하는 컨테이너는 Linux 컨테이너와 마찬가지로 Azure Monitor 및 Container Insights를 사용하여 모니터링할 수 있습니다. 따라서 AKS 기준 문서에 있는 지침 은 대부분의 경우 여기에도 적용됩니다. 그러나 Windows Server 클러스터에 대한 Container Insights 모니터링에는 다음과 같은 제한 사항이 있습니다.
- Windows에는 메모리 RSS 메트릭이 없습니다. 따라서 Windows 노드와 컨테이너에 사용할 수 없습니다. 작업 집합 메트릭을 사용할 수 있습니다.
- Windows 노드에 대한 디스크 스토리지 용량 정보는 제공되지 않습니다.
데이터 수집 규칙을 사용하여 Windows Server 시스템에서 이벤트 및 성능 카운터를 수집하여 Container Insights를 보완할 수도 있습니다.
참고 항목
Windows Server 2022 운영 체제에 대한 컨테이너 인사이트는 공개 미리 보기로 제공됩니다.
정책 관리
AKS 기준 문서에 있는 모든 정책 지침 은 Windows 워크로드에 적용됩니다. 고려해야 할 Azure Kubernetes Service 참조 문서에 대한 Azure Policy 기본 제공 정의에 있는 추가 Windows 관련 정책은 다음과 같습니다.
- Kubernetes 클러스터 Windows 컨테이너는 CPU 및 메모리를 과도하게 커밋해서는 안 됩니다.
- Kubernetes 클러스터 Windows 컨테이너는 ContainerAdministrator로 실행하지 않아야 함
- Kubernetes 클러스터 Windows 컨테이너에서 승인된 사용자 및 도메인 사용자 그룹으로만 실행해야 함
클러스터 부트스트랩
AKS 기준 문서에 제공된 클러스터 부트스트래핑 지침 과 마찬가지로 클러스터 운영자는 Windows 기반 워크로드에 대한 부트스트래핑 방법도 고려해야 합니다. AKS 기준 문서에 제공된 동일한 지침도 여기에 적용됩니다.
원가 관리
AKS 기준 문서에 있는 모든 비용 최적화 지침 은 Windows 워크로드에 적용됩니다. 고려해야 할 기타 비용 고려 사항은 다음과 같습니다.
- Windows Server의 라이선스 비용은 AKS 클러스터의 노드 비용을 증가합니다. 이 요소에 대한 비용 최적화 권장 사항에는 용량 예약 또는 다른 비즈니스 용도로 이미 있는 경우 기존 라이선스 사용이 포함됩니다.
- SA(Software Assurance) 적용 가능한 Windows Server 라이선스에 대한 할인에 대한 자세한 내용은 AHUB(Windows Server용 Azure 하이브리드 혜택 설명서를 참조하세요.
- 새 클러스터와 기존 클러스터에 혜택을 적용하는 방법에 대한 지침은 Windows Server 컨테이너 FAQ를 참조하세요.
- Windows 컨테이너 이미지의 크기는 여러 이미지에 필요한 스토리지의 양, ACR에서 끌어온 동시 노드 수 및 지역 복제본(replica) 요구 사항으로 인해 추가적인 ACR(Azure Container Registry) 비용이 발생할 수 있습니다.
참가자
Microsoft에서 이 문서를 유지 관리합니다. 원래 다음 기여자가 작성했습니다.
주요 작성자:
- 이사벨 베르사노 | 클라우드 솔루션 설계자
- Akshay Nimbalkar | 주요 클라우드 솔루션 설계자
- 클레이튼 지멘스 | 주 콘텐츠 개발자
비공개 LinkedIn 프로필을 보려면 LinkedIn에 로그인합니다.
다음 단계
- Windows 컨테이너에 대해 자세히 알아보기
관련 참고 자료
- AKS 클러스터에 Windows 노드 풀을 배포 하는 방법 알아보기