다음을 통해 공유

AKS(Azure Kubernetes Service) 클러스터를 다른 지역으로 재배치

  • 아티클

이 문서에서는 Azure Kubernetes Service 클러스터를 다른 지역으로 이전하는 방법에 대한 지침을 다룹니다.

기존 Azure 리소스를 한 지역에서 다른 지역으로 이동하려는 이유는 다양합니다. 다음을 수행하려고 할 수 있습니다.

  • 새 Azure 지역 활용.
  • 특정 지역에서만 사용할 수 있는 기능 또는 서비스 배포.
  • 내부 정책 및 거버넌스 요구 사항 충족.
  • 회사 인수 합병에 부합.
  • 용량 계획 요구 사항 충족.

참고 항목

빠른 릴리스 주기를 갖춘 고객은 종종 CI/CD 파이프라인을 활용합니다. 이런 경우 대상 지역에서 AKS 클러스터를 다시 배포하는 대신 빌드 및 릴리스 파이프라인을 변경하는 것을 고려할 수 있습니다.

필수 조건

재배치 계획 단계를 시작하기 전에 먼저 다음 필수 구성 요소를 검토합니다.

  • 대상 지역에 새 클러스터 노드를 수용할 만큼 충분한 용량(VM SKU)이 있는지 확인합니다.

  • 대상 구독에 대한 리소스 만들기 권한이 있는지 유효성을 검사합니다. Azure 정책이 AKS를 배포할 수 있는 지역을 제한하지 않는지 확인합니다.

  • (선택 사항) 원본 AKS 클러스터를 프로비전하는 데 사용된 IaC(코드 제공 인프라) 템플릿이나 스크립트를 수집합니다.

  • 대상 클러스터 내에서 애플리케이션 워크로드를 다시 만들기 위해 Kubernetes 매니페스트를 수집합니다.

    팁

    Flux와 같이 클러스터 내에서 실행되는 GitOps 운영자가 Kubernetes 구성 매니페스트를 Git 리포지토리에 저장하고 자동으로 적용하는 워크로드 배포에 대한 GitOps 방식을 평가합니다. GitOps 방식을 사용하면 GitOps 컨트롤러를 설치하고 리포지토리를 지정하는 것만큼 간단하게 워크로드를 다른 클러스터로 다시 배포할 수 있습니다.

  • 클러스터 수신 구현을 검토합니다.

  • 공용 도메인을 클러스터 수신 엔드포인트로 가리키기 위해 필요한 DNS 변경 내용을 문서화합니다.

  • 대상 클러스터로 마이그레이션해야 하는 영구 볼륨과 같은 상태 데이터를 클러스터에 저장하는지 여부를 검토합니다.

  • 공용 TLS 인증서 관리 및 배포를 문서화합니다.

  • AKS API 서비스 허용 목록에 정의된 모든 IP 주소를 캡처합니다.

  • 모든 종속 리소스를 이해합니다. 일부 리소스는 다음과 같습니다.

    • 큐, 메시지 버스, 캐시 엔진
    • Azure Key Vault
    • 관리 ID
    • 가상 네트워크 구성 Azure 고급 네트워킹 모델을 사용하는 경우 컨테이너 IP 증가를 허용할 만큼 충분한 서브넷 크기 정의
    • 공용 IP 주소
    • VNG(Virtual Network 게이트웨이). 대상 지역의 온-프레미스 환경에 사이트 간 통신이 필요한 경우 대상 가상 네트워크에 VNG를 만들어야 합니다.
    • Azure 프라이빗 엔드포인트. 프라이빗 링크 엔드포인트를 활용하는 Azure PaaS 리소스를 검토하고, ACR, Azure SQL DB, KeyVault 등과 같은 새 프라이빗 링크 인스턴스를 대상 지역에 만들어야 합니다.
    • Azure Application Gateway
    • Azure DNS
    • Azure Firewall
    • Azure Monitor(Container Insights)
    • Azure 컨테이너 레지스트리는 ACR 인스턴스 간에 이미지를 복제할 수 있습니다. 이미지를 끌어올 때 최적의 성능을 가져오려면 레지스트리가 대상 지역에 있어야 합니다.

      참고 항목

      Azure Container Registry를 사용하여 컨테이너 레지스트리에 인증하는 경우 새 AKS 클러스터의 관리 ID는 부여된 AcrPull RBAC 역할이 될 수 있습니다.

    • Azure Managed Disks
    • Azure 파일

준비

클러스터 재배치 프로세스를 시작하기 전에 다음 준비를 완료합니다.

  1. Azure CNI 네트워킹을 사용하는 경우 AKS 클러스터 노드와 Pod를 수용하려면 충분한 크기의 많은 서브넷으로 가상 네트워크를 배포합니다.

  2. Azure Key Vault를 사용하는 경우 Key Vault를 배포합니다.

  3. 관련 TLS 수신 인증서를 배포에 사용할 수 있는지 확인합니다(이상적으로는 Azure Key Vault와 같은 보안 저장소에 있음).

  4. 컨테이너 레지스트리를 배포합니다. 원본 레지스트리 이미지를 자동으로 동기화하거나 CI/CD 파이프라인 또는 스크립트를 사용하여 새 이미지를 다시 빌드하여 대상 레지스트리에 푸시합니다.

  5. Azure Monitor 작업 영역을 배포합니다.

  6. (선택 사항) Azure Application Gateway 배포를 통해 수신 트래픽 처리, AGIC(Application Gateway 수신 컨트롤러)는 클러스터와 긴밀하게 통합될 수 있음

  7. 클러스터 워크로드에 필요한 모든 데이터 원본을 배포하고 원본 데이터를 복원하거나 동기화합니다.

  8. 원본 클러스터와 해당 클러스터가 종속된 서비스를 배포하는 데 사용된 CI/CD 파이프라인에 정의된 기존 IaC 아티팩트를 실행합니다. 다른 리소스 그룹 및 Azure 지역으로 다시 배포하려면 코드 또는 템플릿 입력 매개 변수를 변경합니다.

재배포

다음 단계에 따라 데이터 마이그레이션 없이 AKS 클러스터를 배포합니다.

  1. Azure에서 대상 환경을 만들려면 로컬 워크스테이션에서 기존 IaC 아티팩트를 수동으로 실행합니다.

  2. 기존 IaC 자산이 없으면 현재 클러스터 구성을 ARM 템플릿으로 내보내고 대상 지역에 대해 실행할 수 있습니다. IaC 템플릿은 처음부터 만들어지거나 Bicep, JSON, Terraform 또는 다른 솔루션을 사용하여 샘플 템플릿을 수정한 버전입니다.

    참고 항목

    • Private Link 연결, ACR 연결 레지스트리 및 Azure Monitor 작업 영역 데이터 원본은 현재 이 방법을 사용하여 내보내질 수 없으므로 실행하기 전에 생성된 템플릿에서 제거해야 합니다.

  3. 컨테이너 워크로드를 AKS 클러스터에 배포하는 방법은 두 가지가 있습니다.

    • 풀 매니페스트는 리포지토리에서 끌어와 클러스터 내에서 실행되는 컨트롤러에 의해 적용되며, 이를 GitOps 방식이라고 합니다.
    • 푸시. 매니페스트는 CI/CD 파이프라인 또는 로컬 워크스테이션에서 Kubernetes API 서비스와 kubectl 명령줄 도구를 사용하여 클러스터에 푸시됩니다.

  4. 새 클러스터가 예상대로 작동하는지 확인하려면 테스트 및 유효성 검사를 수행합니다.

  5. 대상 클러스터의 외부 수신 IP(Azure 공용 Load Balancer IP 또는 Application Gateway 공용 IP)를 가리키도록 공용 DNS 항목을 변경합니다.

  6. Azure DNS 또는 Azure Traffic Manager와 같은 글로벌 부하 분산 솔루션을 사용하여 배포하는 경우에는 구성에 지역을 추가해야 합니다.

데이터 마이그레이션을 사용하여 다시 배포

클러스터 내에서 데이터를 저장하거나 데이터베이스 서비스를 호스팅하기 위해 영구 볼륨과 같은 로컬 스토리지를 사용하는 AKS 워크로드는 원본 클러스터에 백업하고 대상 클러스터에 복원할 수 있습니다. 백업 및 복원을 수행하는 방법을 알아보려면 Azure CLI를 사용하여 Azure Kubernetes Service 백업을 참조하세요.

관련 콘텐츠