Azure Stack HCI 22H2에서 Azure Arc에서 사용하도록 설정된 AKS에 대한 시스템 요구 사항
적용 대상: Azure Stack HCI, 버전 22H2; Windows Server 2022, Windows Server 2019
이 문서에서는 Azure Arc에서 사용하도록 설정된 AKS(Azure Kubernetes Service)를 설정하기 위한 요구 사항을 설명합니다. Arc에서 사용하도록 설정된 AKS에 대한 개요는 AKS 개요를 참조하세요.
하드웨어 요구 사항
Microsoft는 파트너로부터 유효성이 검사된 Azure Stack HCI 하드웨어/소프트웨어 솔루션을 구매하는 것이 좋습니다. 이러한 솔루션은 참조 아키텍처를 실행하고 호환성 및 안정성을 확인하여 신속하게 시작하고 실행할 수 있도록 설계, 어셈블 및 유효성을 검사합니다. 사용 중인 시스템, 구성 요소, 디바이스 및 드라이버가 Windows Server 카탈로그에 따라 Windows Server 인증되어 있는지 확인해야 합니다. 유효성이 검사된 솔루션은 Azure Stack HCI 솔루션 웹 사이트를 참조하세요.
Important
프로덕션 배포를 위한 호스트 시스템은 물리적 하드웨어여야 합니다. 가상 머신에 Azure Stack HCI 또는 Windows Server를 배포하고 해당 가상 머신에 AKS를 설치하는 것을 특징으로 하는 중첩된 가상화는 지원되지 않습니다.
지원되는 최대 하드웨어 사양
다음 사양을 초과하는 Azure Stack HCI 및 Windows Server 배포의 AKS는 지원되지 않습니다.
| 리소스 | 최대 |
|---|---|
| 클러스터당 물리적 서버 | 8(Azure Stack HCI 버전 22H2 및 Windows Server) |
| 총 VM 수 | 200 |
컴퓨팅 요구 사항
최소 메모리 요구 사항
다음과 같은 방법으로 AKS 클러스터를 설정하여 RAM이 제한된 단일 노드 Windows Server에서 AKS를 실행할 수 있습니다.
| 클러스터 유형 | 컨트롤 플레인 VM 크기 | 작업자 노드 | 업데이트 작업의 경우 | 부하 분산 장치 |
|---|---|---|---|---|
| AKS 호스트 | Standard_A4_v2 VM 크기 = 8GB | 해당 사항 - AKS 호스트에는 작업자 노드가 없습니다. | 8GB | 해당 사항 - AKS 호스트는 부하 분산을 위해 kubevip를 사용합니다. |
| 워크로드 클러스터 | Standard_A4_v2 VM 크기 = 8GB | 작업자 노드 1개에 대한 Standard_K8S3_v1 = 6GB | 이 예약된 8GB를 워크로드 클러스터 업그레이드에 다시 사용할 수 있습니다. | N/A kubevip가 부하 분산에 사용되는 경우(기본 HAProxy 부하 분산 장치 대신) |
총 최소 요구 사항: 30GB RAM.
이 최소 요구 사항은 컨테이너화된 애플리케이션을 실행하기 위해 하나의 작업자 노드가 있는 AKS 배포를 위한 것입니다. 작업자 노드 또는 HAProxy 부하 분산 장치를 추가하도록 선택하는 경우 최종 RAM 요구 사항이 그에 따라 변경됩니다.
권장 컴퓨팅 요구 사항
| Environment | 서버당 CPU 코어 수 | RAM |
|---|---|---|
| Azure Stack HCI | 32 | 256GB |
| Windows Server 장애 조치(failover) 클러스터 | 32 | 256GB |
| 단일 노드 Windows Server | 16 | 128GB |
프로덕션 환경의 경우 최종 크기 조정은 Azure Stack HCI 또는 Windows Server 클러스터에 배포하려는 애플리케이션 및 작업자 노드 수에 따라 달라집니다. 단일 노드 Windows Server에서 AKS를 실행하도록 선택하는 경우 Azure Stack HCI 또는 Windows Server 클러스터 또는 Windows Server 장애 조치(failover) 클러스터에서 AKS를 실행하는 고가용성 같은 기능을 얻을 수 없습니다.
Azure Stack HCI 및 Windows Server의 AKS에 대한 다른 컴퓨팅 요구 사항은 Azure Stack HCI 요구 사항에 부합합니다. Azure Stack HCI 서버 요구 사항에 대한 자세한 내용은 Azure Stack HCI 시스템 요구 사항을 참조하세요.
클러스터의 각 서버에 동일한 운영 체제를 설치해야 합니다. Azure Stack HCI를 사용하는 경우 클러스터의 각 서버에서 동일한 OS 및 버전이 동일해야 합니다. Windows Server Datacenter를 사용하는 경우 클러스터의 각 서버에서 동일한 OS 및 버전이 동일해야 합니다. 각 OS는 en-us 지역 및 언어 선택을 사용해야 합니다. 설치 후에는 이러한 설정을 변경할 수 없습니다.
저장소 요구 사항
Azure Stack HCI 및 Windows Server의 AKS는 다음 스토리지 구현을 지원합니다.
| 속성 | 스토리지 유형 | 필요한 용량 |
|---|---|---|
| Azure Stack HCI 클러스터 | 클러스터 공유 볼륨 | 1TB |
| Windows Server Datacenter 장애 조치(failover) 클러스터 | 클러스터 공유 볼륨 | 1TB |
| 단일 노드 Windows Server Datacenter | 직접 연결 스토리지 | 500GB |
Azure Stack HCI 또는 Windows Server 클러스터의 경우 가상 머신 워크로드를 실행하기 위해 지원되는 두 가지 스토리지 구성이 있습니다.
- 하이브리드 스토리지 는 플래시 스토리지 및 HDD(하드 디스크 드라이브)를 사용하여 성능과 용량의 균형을 조정합니다.
- 모든 플래시 스토리지 는 SSD(반도체 드라이브) 또는 NVMe를 사용하여 성능을 최대화합니다.
HDD 기반 스토리지만 있는 시스템은 Azure Stack HCI에서 지원되지 않으므로 Azure Stack HCI 및 Windows Server에서 AKS를 실행하는 데 권장되지 않습니다. 권장 드라이브 구성에 대한 자세한 내용은 Azure Stack HCI 설명서를 참조 하세요. Azure Stack HCI 카탈로그에서 유효성을 검사하는 모든 시스템은 이러한 두 가지 지원되는 스토리지 구성 중 하나에 속합니다.
Kubernetes는 etcd를 사용하여 클러스터의 상태를 저장합니다. Etcd는 실행 중인 Pod의 구성, 사양 및 상태를 저장합니다. 또한 Kubernetes는 서비스 검색에 저장소를 사용합니다. Kubernetes 작업 및 지원하는 워크로드에 대한 조정 구성 요소로서 etcd에 대한 대기 시간 및 처리량은 매우 중요합니다. SSD에서 AKS를 실행해야 합니다. 자세한 내용은 etcd.io 성능을 참조하세요.
Windows Server Datacenter 기반 클러스터의 경우 로컬 스토리지 또는 SAN 기반 스토리지를 사용하여 배포할 수 있습니다. 로컬 스토리지의 경우 기본 제공 저장소 공간 Direct 또는 해당하는 인증된 가상 SAN 솔루션을 사용하여 워크로드에서 사용할 클러스터 공유 볼륨을 제공하는 하이퍼 컨버지드 인프라를 만드는 것이 좋습니다. 저장소 공간 Direct의 경우 스토리지가 성능과 용량의 균형을 맞추는 하이브리드(플래시 + HDD) 또는 성능을 최대화하는 모든 플래시(SSD, NVMe)여야 합니다. SAN 기반 스토리지를 사용하여 배포하도록 선택하는 경우 SAN 스토리지가 여러 가상 머신 워크로드를 실행하기에 충분한 성능을 제공할 수 있는지 확인합니다. 이전 HDD 기반 SAN 스토리지는 여러 가상 머신 워크로드를 실행하는 데 필요한 수준의 성능을 제공하지 못할 수 있으며 성능 문제 및 시간 제한이 표시될 수 있습니다.
로컬 스토리지를 사용하는 단일 노드 Windows Server 배포의 경우 단일 물리적 호스트에서 여러 가상 머신을 호스트하는 데 필요한 성능을 제공하기 위해 모든 플래시 스토리지(SSD, NVMe)를 사용하는 것이 좋습니다. 플래시 스토리지가 없으면 HDD의 성능 수준이 낮을수록 배포 문제 및 시간 초과가 발생할 수 있습니다.
네트워크 요구 사항
다음 요구 사항은 Azure Stack HCI 22H2 클러스터 및 Windows Server Datacenter 클러스터에 적용됩니다. Azure Stack HCI 23H2의 네트워킹 요구 사항은 네트워킹 요구 사항을 참조 하세요.
- Azure Stack HCI 22H2 및 Windows Server의 경우 Windows Admin Center를 사용하는 경우 기존 외부 가상 스위치가 구성되어 있는지 확인합니다. HCI 또는 Windows Server 클러스터의 경우 이 스위치와 해당 이름은 모든 클러스터 노드에서 동일해야 합니다. HCI 23H2의 경우 네트워크 시스템 요구 사항을 참조하세요.
- 모든 네트워크 어댑터에서 IPv6을 사용하지 않도록 설정했는지 확인합니다.
- 성공적으로 배포하려면 Azure Stack HCI 또는 Windows Server 클러스터 노드 및 Kubernetes 클러스터 VM에 외부 인터넷 연결이 있어야 합니다.
- 클러스터에 대해 정의한 모든 서브넷이 서로 인터넷 간에 라우팅할 수 있는지 확인합니다.
- Azure Stack HCI 호스트와 테넌트 VM 간에 네트워크 연결이 있는지 확인합니다.
- 모든 노드가 서로 통신할 수 있도록 하려면 DNS 이름 확인이 필요합니다.
- (권장) AKS가 검색을 위해 DNS 시스템에 클라우드 에이전트 일반 클러스터 이름을 등록할 수 있도록 DNS 환경에서 동적 DNS 업데이트를 사용하도록 설정합니다.
IP 주소 할당
Arc에서 사용하도록 설정된 AKS에서 가상 네트워크는 이전에 나열된 대로 필요한 Kubernetes 리소스에 IP 주소를 할당하는 데 사용됩니다. 원하는 AKS 네트워킹 아키텍처에 따라 두 가지 네트워킹 모델 중에서 선택할 수 있습니다.
참고 항목
AKS 배포에 대해 여기에 정의된 가상 네트워킹 아키텍처는 데이터 센터의 기본 물리적 네트워킹 아키텍처와 다릅니다.
- 고정 IP 네트워킹: 가상 네트워크는 Kubernetes 클러스터 API 서버, Kubernetes 노드, 기본 VM, 부하 분산 장치 및 클러스터 위에서 실행하는 모든 Kubernetes 서비스에 고정 IP 주소를 할당합니다.
- DHCP 네트워킹: 가상 네트워크는 DHCP 서버를 사용하여 Kubernetes 노드, 기본 VM 및 부하 분산 장치에 동적 IP 주소를 할당합니다. Kubernetes 클러스터 API 서버 및 클러스터 위에서 실행하는 모든 Kubernetes 서비스는 여전히 할당된 고정 IP 주소입니다.
최소 IP 주소 예약
최소한 배포를 위해 다음 IP 주소를 예약해야 합니다.
| 클러스터 유형 | 컨트롤 플레인 노드 | 작업자 노드 | 업데이트 작업의 경우 | 부하 분산 장치 |
|---|---|---|---|---|
| AKS 호스트 | 1 IP | 해당 없음 | IP 2개 | 해당 없음 |
| 워크로드 클러스터 | 노드당 1 IP | 노드당 1 IP | IP 5개 | 1 IP |
또한 VIP 풀에 대해 다음 수의 IP 주소를 예약해야 합니다.
| 리소스 종류 | IP 주소 수 |
|---|---|
| 클러스터 API 서버 | 클러스터당 1 |
| Kubernetes 서비스 | 서비스당 1 |
볼 수 있듯이 필요한 IP 주소 수는 AKS 아키텍처 및 Kubernetes 클러스터에서 실행하는 서비스 수에 따라 가변적입니다. 배포를 위해 총 256개의 IP 주소(/24 서브넷)를 예약하는 것이 좋습니다.
네트워킹 요구 사항에 대한 자세한 내용은 AKS의 노드 네트워킹 개념 및 AKS의 컨테이너 네트워킹 개념을 참조하세요.
네트워크 포트 및 URL 요구 사항
Arc 요구 사항에서 사용하도록 설정된 AKS
Azure Stack HCI에서 Kubernetes 클러스터를 만들 때 클러스터의 각 서버에서 다음 방화벽 포트가 자동으로 열립니다.
Azure Stack HCI 물리적 클러스터 노드와 Azure Kubernetes 클러스터 VM이 두 개의 격리된 vlan에 있는 경우 이러한 포트는 다음 VLAN 간의 방화벽에서 열어야 합니다.
| 포트 | Source | 설명 | 방화벽 참고 사항 |
|---|---|---|---|
| 22 | AKS VM | 를 사용할 Get-AksHciLogs때 로그를 수집하는 데 필요합니다. |
별도의 VLAN을 사용하는 경우 물리적 Hyper-V 호스트는 이 포트의 AKS VM에 액세스해야 합니다. |
| 6443 | AKS VM | Kubernetes API와 통신하는 데 필요합니다. | 별도의 VLAN을 사용하는 경우 물리적 Hyper-V 호스트는 이 포트의 AKS VM에 액세스해야 합니다. |
| 45000 | 물리적 Hyper-V 호스트 | wssdAgent gRPC 서버. | VLAN 간 규칙은 필요하지 않습니다. |
| 45001 | 물리적 Hyper-V 호스트 | wssdAgent gRPC 인증. | VLAN 간 규칙은 필요하지 않습니다. |
| 46000 | AKS VM | wssdCloudAgent에서 lbagent로. | 별도의 VLAN을 사용하는 경우 물리적 Hyper-V 호스트는 이 포트의 AKS VM에 액세스해야 합니다. |
| 55000 | 클러스터 리소스(-CloudServiceCIDR) | 클라우드 에이전트 gRPC 서버. | 별도의 VLAN을 사용하는 경우 AKS VM은 이 포트에서 클러스터 리소스의 IP에 액세스해야 합니다. |
| 65000 | 클러스터 리소스(-CloudServiceCIDR) | 클라우드 에이전트 gRPC 인증. | 별도의 VLAN을 사용하는 경우 AKS VM은 이 포트에서 클러스터 리소스의 IP에 액세스해야 합니다. |
네트워크에 프록시 서버를 사용하여 인터넷에 연결해야 하는 경우 AKS에서 프록시 서버 설정 사용을 참조하세요.
다음 URL을 허용 목록에 추가해야 합니다.
| URL | 포트 | 주의 |
|---|---|---|
| msk8s.api.cdp.microsoft.com | 443 | SFS에서 Azure 로컬 제품 카탈로그, 제품 비트 및 OS 이미지에서 AKS를 다운로드할 때 사용됩니다. SFS에서 다운로드할 때마다 실행 Set-AksHciConfig 중일 때 발생합니다. |
msk8s.b.tlu.dl.delivery.mp.microsoft.com msk8s.f.tlu.dl.delivery.mp.microsoft.com |
80 | SFS에서 Azure 로컬 제품 카탈로그, 제품 비트 및 OS 이미지에서 AKS를 다운로드할 때 사용됩니다. SFS에서 다운로드할 때마다 실행 Set-AksHciConfig 중일 때 발생합니다. |
login.microsoftonline.com login.windows.net management.azure.com msft.sts.microsoft.com graph.windows.net |
443 | 를 실행할 Set-AksHciRegistration때 Azure에 로그인하는 데 사용됩니다. |
ecpacr.azurecr.io mcr.microsoft.com *.mcr.microsoft.com *.data.mcr.microsoft.com *.blob.core.windows.net US 엔드포인트: wus2replica*.blob.core.windows.net |
443 | 를 실행할 Install-AksHci때 컨테이너 이미지를 끌어오는 데 필요합니다. |
| <region.dp.kubernetesconfiguration.azure.com> | 443 | AKS 하이브리드 클러스터를 Azure Arc에 온보딩하는 데 필요합니다. |
| gbl.his.arc.azure.com | 443 | 시스템 할당 MSI(Managed Identity 증명서) 인증서를 끌어오기 위한 지역 엔드포인트를 가져오는 데 필요합니다. |
| *.his.arc.azure.com | 443 | 시스템이 할당한 관리 ID 인증서를 가져오는 데 필요합니다. |
| k8connecthelm.azureedge.net | 443 | Arc 지원 Kubernetes는 Helm 3을 사용하여 Azure 로컬 관리 클러스터의 AKS에 Azure Arc 에이전트를 배포합니다. 이 엔드포인트는 에이전트 Helm 차트의 배포를 용이하게 하기 위해 Helm 클라이언트 다운로드에 필요합니다. |
| *.arc.azure.net | 443 | Azure Portal에서 AKS 하이브리드 클러스터를 관리하는 데 필요합니다. |
| dl.k8s.io | 443 | Azure Arc용 Kubernetes 이진 파일을 다운로드하고 업데이트하는 데 필요합니다. |
| akshci.azurefd.net | 443 | 실행할 Install-AksHci때 Azure 로컬 청구의 AKS에 필요합니다. |
v20.events.data.microsoft.com gcs.prod.monitoring.core.windows.net |
443 | Azure 로컬 또는 Windows Server 호스트에서 Microsoft 필수 진단 데이터를 보내는 데 주기적으로 사용됩니다. |
참고 항목
Arc에서 사용하도록 설정된 AKS는 고객 데이터를 저장하고 처리합니다. 기본적으로 고객 데이터는 고객이 서비스 인스턴스를 배포하는 지역 내에 유지됩니다. 이 데이터는 지역 Microsoft 운영 데이터 센터 내에 저장됩니다. 데이터 보존 요구 사항이 있는 지역의 경우 고객 데이터는 항상 동일한 지역 내에 유지됩니다.
Azure Arc 기능에 대한 추가 URL 요구 사항
이전 URL 목록에는 청구를 위해 AKS 서비스를 Azure에 연결하는 데 필요한 최소 URL이 포함되어 있습니다. AKS 워크로드 클러스터에서 클러스터 연결, 사용자 지정 위치, Azure RBAC 및 Azure Monitor와 같은 기타 Azure 서비스를 사용하려면 추가 URL을 허용해야 합니다. Arc URL의 전체 목록은 Azure Arc 지원 Kubernetes 네트워크 요구 사항을 참조 하세요.
Azure Stack HCI URL도 검토해야 합니다. 서버 에이전트용 Arc는 이제 Azure Stack HCI 21H2 이상의 Azure Stack HCI 노드에 기본적으로 설치되므로 서버 에이전트 URL에 대한 Arc도 검토해야 합니다.
AKS의 확장된 클러스터
확장 클러스터 개요에 설명된 대로 Windows 확장 클러스터를 사용하여 Azure Stack HCI 및 Windows Server에 AKS를 배포하는 것은 지원되지 않습니다. 데이터 센터 운영 연속성을 위해 백업 및 재해 복구 방법을 사용하는 것이 좋습니다. 자세한 내용은 Azure Stack HCI 및 Windows Server에서 Velero 및 Azure Blob Storage를 사용하여 워크로드 클러스터 백업 또는 복원을 수행하고 애플리케이션 연속성을 위해 Flux v2 와 GitOps를 사용하여 AksHci에 구성 배포를 참조하세요.
Windows Admin Center 요구 사항
Windows Admin Center는 Azure Arc에서 사용하도록 설정된 AKS를 만들고 관리하기 위한 사용자 인터페이스입니다. Azure Stack HCI 및 Windows Server에서 AKS와 함께 Windows Admin Center를 사용하려면 다음 목록의 모든 조건을 충족해야 합니다.
Windows Admin Center 게이트웨이를 실행하는 컴퓨터에 대한 요구 사항은 다음과 같습니다.
- Windows 10 또는 Windows Server.
- Azure에 등록되었습니다.
- Azure Stack HCI 또는 Windows Server Datacenter 클러스터와 동일한 도메인에 있습니다.
- 소유자 권한이 있는 Azure 구독입니다. 구독으로 이동하고 Azure Portal의 왼쪽에서 액세스 제어(IAM)를 선택한 다음 내 액세스 보기를 선택하여 액세스 수준을 확인할 수 있습니다.
Azure 요구 사항
Azure 계정에 연결해야 합니다.
Azure 계정 및 구독
Azure 계정이 아직 없는 경우 계정을 만듭니다. 모든 유형의 기존 구독을 사용할 수 있습니다.
- 학생 또는 Visual Studio 구독자를 위한 Azure 크레딧이 있는 무료 계정입니다.
- 신용 카드가 있는 종량제 구독
- 기업계약(EA)를 통해 얻은 구독입니다.
- CSP(클라우드 솔루션 공급자) 프로그램을 통해 얻은 구독입니다.
Microsoft Entra 권한, 역할 및 액세스 수준
애플리케이션을 Microsoft Entra 테넌트에 등록할 수 있는 충분한 권한이 있어야 합니다.
충분한 권한이 있는지 확인하려면 아래 정보를 따르세요.
- Azure Portal로 이동하여 Microsoft Entra ID에서 역할 및 관리자를 선택하여 역할을 확인합니다.
- 사용자의 역할이 사용자인 경우 관리자가 아닌 사용자가 애플리케이션을 등록할 수 있는지 확인해야 합니다.
- 애플리케이션을 등록할 수 있는지 확인하려면 Microsoft Entra 서비스의 사용자 설정 으로 이동하여 애플리케이션을 등록할 수 있는 권한이 있는지 확인합니다.
앱 등록 설정이 아니요로 설정된 경우 관리자 역할이 있는 사용자만 이러한 유형의 애플리케이션을 등록할 수 있습니다. 사용 가능한 관리자 역할 및 각 역할에 지정된 Microsoft Entra ID의 특정 권한에 대해 알아보려면 Microsoft Entra 기본 제공 역할을 참조하세요. 계정에 사용자 역할이 할당되었지만 앱 등록 설정이 관리자 사용자로 제한되는 경우 관리자에게 앱 등록의 모든 측면을 만들고 관리할 수 있는 관리자 역할 중 하나를 할당하거나 사용자가 앱을 등록할 수 있도록 하도록 요청합니다.
애플리케이션을 등록할 수 있는 충분한 권한이 없고 관리자가 이러한 권한을 부여할 수 없는 경우 AKS를 배포하는 가장 쉬운 방법은 Azure 관리자에게 올바른 권한이 있는 서비스 주체를 만들도록 요청하는 것입니다. 관리자는 다음 섹션을 확인하여 서비스 주체를 만드는 방법을 알아볼 수 있습니다.
Azure 구독 역할 및 액세스 수준
액세스 수준을 확인하려면 구독으로 이동하고, Azure Portal의 왼쪽에서 액세스 제어(IAM)를 선택한 다음, 내 액세스 보기를 선택합니다.
- Windows Admin Center를 사용하여 AKS 호스트 또는 AKS 워크로드 클러스터를 배포하는 경우 소유자인 Azure 구독이 있어야 합니다.
- PowerShell을 사용하여 AKS 호스트 또는 AKS 워크로드 클러스터를 배포하는 경우 클러스터를 등록하는 사용자에게 다음 중 하나 이상이 있어야 합니다.
Azure 구독이 EA 또는 CSP를 사용하는 경우 AKS를 배포하는 가장 쉬운 방법은 Azure 관리자에게 올바른 권한이 있는 서비스 주체를 만들도록 요청하는 것입니다. 관리자는 서비스 주체를 만드는 방법에 대해 다음 섹션을 확인할 수 있습니다.
선택 사항: 새 서비스 주체 만들기
다음 단계를 실행하여 기본 제공 소유자 역할을 사용하여 새 서비스 주체를 만듭니다. 구독 소유자만 올바른 역할 할당을 사용하여 서비스 주체를 만들 수 있습니다. 구독으로 이동하고, Azure Portal의 왼쪽에서 액세스 제어(IAM)를 선택한 다음, 내 액세스 보기에서 선택하여 액세스 수준을 확인할 수 있습니다.
PowerShell 관리 창에서 다음 PowerShell 변수를 설정합니다. 구독 및 테넌트가 청구를 위해 AKS 호스트를 등록하는 데 사용할 것인지 확인합니다.
$subscriptionID = "<Your Azure subscrption ID>"
$tenantID = "<Your Azure tenant ID>"
AKS PowerShell 모듈을 설치하고 가져옵니다.
Install-Module -Name AksHci
Connect-AzAccount PowerShell 명령을 사용하여 Azure에 로그인합니다.
Connect-AzAccount -tenant $tenantID
Set-AzContext 명령을 실행하여 청구를 위해 AKS 호스트를 기본 구독으로 등록하는 데 사용할 구독을 설정합니다.
Set-AzContext -Subscription $subscriptionID
Get-AzContext PowerShell 명령을 실행하여 로그인 컨텍스트가 올바른지 확인합니다. 구독, 테넌트 및 계정이 청구를 위해 AKS 호스트를 등록하는 데 사용할 것인지 확인합니다.
Get-AzContext
Name Account SubscriptionName Environment TenantId
---- ------- ---------------- ----------- --------
myAzureSubscription (92391anf-... user@contoso.com myAzureSubscription AzureCloud xxxxxx-xxxx-xxxx-xxxxxx
New-AzADServicePrincipal PowerShell 명령을 실행하여 서비스 주체를 만듭니다. 이 명령은 소유자 역할을 사용하여 서비스 주체를 만들고 구독 수준에서 범위를 설정합니다. 서비스 주체를 만드는 방법에 대한 자세한 내용은 Azure PowerShell을 사용하여 Azure 서비스 주체 만들기를 참조하세요.
$sp = New-AzADServicePrincipal -role "Owner" -scope /subscriptions/$subscriptionID
다음 명령을 실행하여 서비스 주체의 암호를 검색합니다. 이 명령은 Az.Accounts 2.6.0 이하에서만 작동합니다. AksHci PowerShell 모듈을 설치하면 Az.Accounts 2.6.0 모듈을 자동으로 다운로드합니다.
$secret = $sp.PasswordCredentials[0].SecretText
Write-Host "Application ID: $($sp.ApplicationId)"
Write-Host "App Secret: $secret"
이전 출력에서 이제 AKS를 배포할 때 사용할 수 있는 애플리케이션 ID 와 비밀을 갖게 되었습니다. 이러한 항목을 기록하고 안전하게 저장해야 합니다. Azure Portal의 구독, 액세스 제어 및 역할 할당 아래에 새 서비스 주체가 표시됩니다.
Azure 리소스 그룹
등록하기 전에 오스트레일리아 동부, 미국 동부, 동남 아시아 또는 서유럽 Azure 지역에 Azure 리소스 그룹이 있어야 합니다.
Azure 지역
Warning
AKS Arc는 현재 다음과 같은 지정된 Azure 지역 내에서만 클러스터 만들기를 지원합니다. 이 목록 외부의 지역에 배포하려고 하면 배포 오류가 발생합니다.
AKS Arc 서비스는 등록, 청구 및 관리에 사용됩니다. 현재 다음 지역에서 지원됩니다.
- 미국 동부
- 미국 중남부
- 서유럽
Active Directory 요구 사항
2개 이상의 물리적 노드가 있는 AKS 장애 조치(failover) 클러스터가 Active Directory 환경에서 최적으로 작동하려면 다음 요구 사항이 충족되는지 확인합니다.
참고 항목
단일 노드 Azure Stack HCI 또는 Windows Server 배포에는 Active Directory가 필요하지 않습니다.
- 차이는 모든 클러스터 노드와 도메인 컨트롤러에서 2분보다 크지 않도록 시간 동기화를 설정합니다. 시간 동기화 설정에 대한 자세한 내용은 Windows 시간 서비스를 참조하세요.
- 업데이트를 추가하고 AKS 또는 Windows Server Datacenter 클러스터를 관리하는 데 사용되는 사용자 계정에 Active Directory에서 올바른 권한이 있는지 확인합니다. OU(조직 구성 단위)를 사용하여 서버 및 서비스에 대한 그룹 정책을 관리하는 경우 사용자 계정에는 OU의 모든 개체에 대한 목록, 읽기, 수정 및 삭제 권한이 필요합니다.
- AKS 또는 Windows Server Datacenter 클러스터의 서버 및 서비스에 대해 별도의 OU(조직 구성 단위)를 사용합니다. 별도의 OU를 사용하면 더 세분화된 액세스 및 권한을 제어할 수 있습니다.
- Active Directory의 컨테이너에서 GPO 템플릿을 사용하는 경우 Azure Stack HCI 및 Windows Server에 AKS를 배포하는 것이 정책에서 제외되는지 확인합니다.
다음 단계
위의 모든 필수 구성 요소를 충족한 후에는 다음을 사용하여 Azure Stack HCI에서 AKS 호스트를 설정할 수 있습니다.