Azure Kubernetes Service(AKS)로 마이그레이션

이 가이드에서는 AKS(Azure Kubernetes Service)에 대한 성공적인 마이그레이션을 계획하고 실행하는 데 도움을 주기 위해 현재 권장되는 AKS 구성에 대한 세부 정보를 제공합니다. 이 문서에서는 모든 시나리오에 대해 설명하지 않지만 성공적인 마이그레이션 계획에 대한 자세한 정보를 볼 수 있는 링크를 포함하고 있습니다.

이 문서에서는 다음에 대한 마이그레이션 세부 정보를 요약합니다.

• Azure Migrate를 통해 애플리케이션 컨테이너화
• Azure Load Balancer(표준) 및 Virtual Machine Scale Sets를 사용하는 AKS
• 기존에 연결된 Azure 서비스
• 유효한 할당량 확인
• 고가용성 및 비즈니스 연속성
• 상태 비저장 애플리케이션에 대한 고려 사항
• 상태 저장 애플리케이션에 대한 고려 사항
• 클러스터 구성 배포

참고 항목

시나리오에 따라 다음 오픈 소스 도구가 마이그레이션에 도움이 될 수 있습니다.

• Velero(Kubernetes 1.7 이상 필요)
• Azure Kube CLI 확장

시작하기 전에

• 대상 Kubernetes 버전이 AKS에 대한 지원 범위에 속하는지 확인합니다. 이전 버전은 지원되는 범위 내에 있지 않을 수 있으며 AKS 지원을 위해 버전 업그레이드가 필요할 수 있습니다. 자세한 내용은 AKS 지원 Kubernetes 버전을 참조하세요.
• 최신 버전의 Kubernetes로 마이그레이션하려는 경우 Kubernetes 버전 및 버전 기울기 지원 정책을 검토하세요.

마이그레이션 프로세스의 일부로 일반적으로 사용되는 배포 및 테스트 패턴을 따르는 것이 중요합니다. 배포 전에 애플리케이션을 테스트하는 것은 품질, 기능 및 대상 환경에 대한 호환성을 보장하는 중요한 단계입니다. 이러한 작업은 애플리케이션 또는 기본 인프라의 성능, 보안 또는 유용성에 영향을 줄 수 있는 오류, 버그 또는 문제를 식별하고 해결하는 데 도움이 될 수 있습니다.

Azure Migrate을 사용하여 애플리케이션을 AKS로 마이그레이션합니다

Azure Migrate는 온-프레미스 서버, 인프라, 애플리케이션 및 데이터를 평가하고 Azure로 마이그레이션할 수 있는 통합 플랫폼을 제공합니다. AKS의 경우 다음과 같은 작업에 Azure Migrate를 사용할 수 있습니다.

• ASP.NET 애플리케이션 컨테이너화 및 AKS로 마이그레이션
• Java 웹 애플리케이션 컨테이너화 및 AKS로 마이그레이션

표준 Load Balancer 및 Virtual Machine Scale Sets가 있는 AKS

AKS는 관리 오버헤드가 낮은 고유한 기능을 제공하는 관리되는 서비스입니다. AKS는 관리되는 서비스이므로 AKS에서 지원하는 지역 집합에서 선택해야 합니다. 기존 클러스터에서 AKS로 전환하는 동안 AKS 관리 제어 평면에서 기존 애플리케이션을 정상 상태로 유지하기 위해 수정해야 할 수 있습니다.

Virtual Machine Scale Sets 및 Load Balancer(표준)에서 지원되는 AKS 클러스터를 사용하여 다음 기능을 가져오는 것이 좋습니다.

• 여러 노드 풀,
• 가용성 영역,
• 권한 있는 IP 범위,
• 클러스터 자동 크기 조정기,
• AKS에 대한 Azure Policy 및
• 출시된 다른 새로운 기능.

VM(가상 머신) 가용성 집합에서 지원하는 AKS 클러스터는 이러한 많은 기능에 대한 지원이 부족합니다.

Load Balancer(표준) 및 Virtual Machine Scale Sets를 사용하여 AKS 클러스터 만들기

Azure CLI

다음 예제에서는 Virtual Machine Scale Set에서 지원되는 단일 노드 풀을 사용하여 AKS 클러스터를 만듭니다. 또한 클러스터의 노드 풀에서 클러스터 자동 크기 조정기를 사용하도록 설정하고 최소 1개 및 최대 3개 노드를 설정합니다.

1. az group create 명령을 사용하여 리소스 그룹을 만듭니다.

   az group create --name myResourceGroup --location eastus
   

2. az aks create 명령을 사용하여 AKS 클러스터를 만듭니다.

   az aks create \
       --resource-group myResourceGroup \
       --name myAKSCluster \
       --node-count 1 \
       --vm-set-type VirtualMachineScaleSets \
       --load-balancer-sku standard \
       --enable-cluster-autoscaler \
       --min-count 1 \
       --max-count 3 \
       --generate-ssh-keys
   

Terraform

다음 코드는 Terraform을 사용하여 자동 크기 조정을 사용하도록 설정하고 특정 네트워크 설정을 사용하여 Azure에 리소스 그룹 및 Kubernetes 클러스터를 만듭니다.

참고 항목

이 문서의 샘플 코드는 Azure Terraform GitHub 리포지토리에 있습니다. Terraform의 현재 및 이전 버전의 테스트 결과가 포함된 로그 파일을 볼 수 있습니다.

Terraform을 사용하여 Azure 리소스를 관리하는 방법을 보여 주는 추가 문서 및 샘플 코드를 참조하세요.

1. 샘플 Terraform 코드를 테스트하고 실행할 디렉터리를 만들고 현재 디렉터리로 만듭니다.

2. 이름이 지정된 main.tf파일을 만들고 다음 코드를 삽입합니다.

   resource "random_pet" "rg_name" {
     prefix = var.resource_group_name_prefix
   }
   
   resource "azurerm_resource_group" "rg" {
     location = var.resource_group_location
     name     = random_pet.rg_name.id
   }
   
   resource "random_string" "aks_cluster_name" {
     length  = 12
     special = false
   }
   
   resource "azurerm_kubernetes_cluster" "aks_cluster" {
     name                = random_string.aks_cluster_name.result
     location            = azurerm_resource_group.rg.location
     resource_group_name = azurerm_resource_group.rg.name
     dns_prefix          = "myakscluster"
   
     default_node_pool {
       type                = "VirtualMachineScaleSets"
       name                = "default"
       node_count          = 1
       max_count           = 3
       min_count           = 1
       vm_size             = "Standard_DS2_v2"
       enable_auto_scaling = true
       upgrade_settings {
         drain_timeout_in_minutes      = 90
         max_surge                     = "10%"
         node_soak_duration_in_minutes = 0
       }
     }
   
     network_profile {
       network_plugin    = "azure"
       load_balancer_sku = "standard"
     }
   
     identity {
       type = "SystemAssigned"
     }
   
     tags = {
       Environment = "Production"
     }
   }
   

3. 이름이 지정된 outputs.tf파일을 만들고 다음 코드를 삽입합니다.

   output "resource_group_name" {
     value = azurerm_resource_group.rg.name
   }
   
   output "aks_cluster_name" {
     value = azurerm_kubernetes_cluster.aks_cluster.name
   }
   

4. 이름이 지정된 providers.tf파일을 만들고 다음 코드를 삽입합니다.

   terraform {
     required_providers {
       azurerm = {
         source  = "hashicorp/azurerm"
         version = "~>3.0"
       }
       random = {
         source  = "hashicorp/random"
         version = "~>3.0"
       }
     }
   }
   
   provider "azurerm" {
     features {}
   }
   

5. 이름이 지정된 variables.tf파일을 만들고 다음 코드를 삽입합니다.

   variable "resource_group_location" {
     type        = string
     default     = "eastus"
     description = "Location of the resource group."
   }
   
   variable "resource_group_name_prefix" {
     type        = string
     default     = "rg"
     description = "Prefix of the resource group name that's combined with a random ID so name is unique in your Azure subscription."
   }
   

6. Terraform을 초기화합니다.

   terraform init를 실행하여 Terraform 배포를 초기화합니다. 이 명령은 Azure 리소스를 관리하는 데 필요한 Azure 공급자를 다운로드합니다.

   terraform init -upgrade
   

   주요 정보:

   • -upgrade 매개 변수는 필요한 공급자 플러그 인을 구성의 버전 제약 조건을 준수하는 최신 버전으로 업그레이드합니다.

7. Terraform 실행 계획을 만듭니다.

   terraform plan을 실행하여 실행 계획을 만듭니다.

   terraform plan -out main.tfplan
   

   주요 정보:

   • terraform plan 명령은 실행 계획을 만들지만 실행하지는 않습니다. 대신 구성 파일에 지정된 구성을 만드는 데 필요한 작업을 결정합니다. 이 패턴을 사용하면 실제 리소스를 변경하기 전에 실행 계획이 예상과 일치하는지 확인할 수 있습니다.
   • 선택 사항인 -out 매개 변수를 사용하여 계획의 출력 파일을 지정할 수 있습니다. -out 매개 변수를 사용하면 검토한 계획이 정확하게 적용됩니다.

8. Terraform 실행 계획을 적용합니다.

   terraform apply를 실행하여 실행 계획을 클라우드 인프라에 적용합니다.

   terraform apply main.tfplan
   

   주요 정보:

   • 예시 terraform apply 명령은 이전에 terraform plan -out main.tfplan를 실행했다고 가정합니다.
   • -out 매개 변수에 다른 파일 이름을 지정한 경우 terraform apply에 대한 호출에서 동일한 파일 이름을 사용합니다.
   • -out 매개 변수를 사용하지 않은 경우 매개 변수 없이 terraform apply를 호출합니다.

기존에 연결된 Azure 서비스

클러스터를 마이그레이션할 때 외부 Azure 서비스를 연결했을 수 있습니다. 다음 서비스는 리소스를 다시 만들지 않아도 되지만 기능을 유지하려면 이전 클러스터에서 새 클러스터로의 연결을 업데이트해야 합니다.

• Azure Container Registry
• Azure Log Analytics
• Azure Application Insights
• Azure Traffic Manager
• Azure Storage 계정
• 외부 데이터베이스

유효한 할당량 확인

마이그레이션 중에 다른 VM이 구독에 배포되므로 할당량과 한도가 이러한 리소스에 충분한지 확인해야 합니다. 필요한 경우 vCPU 할당량증가를 요청합니다.

네트워크 할당량에 대한 증가를 요청하여 ip가 고갈되지 않도록 해야 할 수도 있습니다. 자세한 내용은 AKS의 네트워킹 및 IP 범위를 참조하세요.

자세한 내용은 Azure 구독 및 서비스 제한을 참조하세요. 현재 할당량을 확인하려면 Azure Portal 구독 블레이드로 이동하여 구독을 선택한 다음 사용량 + 할당량을 선택합니다.

고가용성 및 비즈니스 연속성

애플리케이션에서 가동 중지 시간을 처리할 수 없는 경우 고가용성 마이그레이션 시나리오에 대한 모범 사례를 따라야 합니다. AKS(Azure Kubernetes Service)에서 복잡한 비즈니스 연속성 계획, 재해 복구 및 작동 시간 극대화를 위한 모범 사례에 대해 자세히 알아보세요.

복잡한 애플리케이션은 일반적으로 한 번에 전부 마이그레이션하기보다는 점차 마이그레이션을 수행합니다. 따라서 이전 환경과 새 환경이 네트워크를 통해 통신해야 할 수 있습니다. 이전에 ClusterIP 서비스를 사용하여 통신하던 애플리케이션은 LoadBalancer 유형으로 노출하고 적절하게 보호해야 할 수 있습니다.

마이그레이션을 완료하려면 클라이언트가 AKS에서 실행되는 새 서비스를 가리키도록 합니다. 트래픽을 리디렉션하는 경우 AKS 클러스터 앞에 있는 Load Balancer를 가리키도록 DNS를 업데이트하는 것이 좋습니다.

Azure Traffic Manager는 고객에게 원하는 Kubernetes 클러스터 및 애플리케이션 인스턴스로 보낼 수 있습니다. Traffic Manager는 네트워크 트래픽을 여러 지역에 분산할 수 있는 DNS 기반 트래픽 부하 분산 디바이스입니다. 최상의 성능 및 중복도를 위해 AKS 클러스터로 보내기 전에 Traffic Manager를 통해 모든 애플리케이션 트래픽을 전달합니다.

다중 클러스터 배포에서는 고객이 각 AKS 클러스터의 서비스를 가리키는 Traffic Manager DNS 이름에 연결해야 합니다. 이러한 서비스는 Traffic Manager 엔드포인트를 사용하여 정의합니다. 각 엔드포인트는 서비스 부하 분산 장치 IP입니다. 이 구성을 사용하여 한 지역의 Traffic Manager 엔드포인트에서 다른 지역의 엔드포인트로 네트워크 트래픽을 보낼 수 있습니다.

Azure Front Door 는 AKS 클러스터에 대한 트래픽을 라우팅하는 또 다른 옵션입니다. Azure Front Door를 사용하면 고가용성을 위해 최상의 성능 및 즉각적인 글로벌 장애 조치(failover)를 최적화하여 웹 트래픽에 대한 글로벌 라우팅을 정의, 관리 및 모니터링할 수 있습니다.

상태 비저장 애플리케이션에 대한 고려 사항

상태 비저장 애플리케이션 마이그레이션에는 다음 단계가 포함됩니다.

1. 리소스 정의(YAML 또는 Helm)를 새 클러스터에 적용합니다.
2. 모두 예상대로 작동하는지 확인합니다.
3. 트래픽을 리디렉션하여 새 클러스터를 활성화합니다.

상태 저장 애플리케이션에 대한 고려 사항

데이터 손실 또는 예기치 않은 가동 중지 시간을 방지하기 위해 상태 저장 애플리케이션의 마이그레이션을 신중하게 계획합니다.

• Azure Files를 사용하는 경우 파일 공유를 새 클러스터에 볼륨으로 탑재할 수 있습니다. 정적 Azure Files를 볼륨으로 탑재를 참조하세요.
• Azure Managed Disks를 사용하는 경우 VM에 연결되지 않은 경우에만 디스크를 탑재할 수 있습니다. 정적 Azure Disk를 볼륨으로 탑재를 참조하세요.
• 이러한 방법이 작동하지 않는 경우 백업 및 복원 옵션을 사용할 수 있습니다. Azure의 Velero를 참조하세요.

Azure 파일

디스크와 달리 Azure Files는 여러 호스트에 동시에 탑재할 수 있습니다. AKS 클러스터에서 Azure 및 Kubernetes는 AKS 클러스터가 여전히 사용하는 Pod를 만드는 것을 방해하지 않습니다. 데이터 손실 및 예기치 않은 동작을 방지하려면 클러스터가 같은 파일에 동시에 쓰지 않도록 합니다.

애플리케이션에서 동일한 파일 공유를 가리키는 여러 복제본을 호스팅할 수 있는 경우, 상태 비저장 마이그레이션 단계를 수행하고 YAML 정의를 새 클러스터에 배포합니다.

그렇지 않은 경우 한 가지 가능한 마이그레이션 방법에 다음 단계가 포함됩니다.

1. 애플리케이션이 올바르게 작동하는지 확인합니다.
2. 새 AKS 클러스터에 대한 라이브 트래픽을 가리킵니다.
3. 이전 클러스터의 연결을 끊습니다.

빈 공유로 시작한 다음, 원본 데이터의 복사본을 만들려면 az storage file copy 명령을 사용하여 데이터를 마이그레이션할 수 있습니다.

영구적 볼륨 마이그레이션

기존 영구 볼륨을 AKS로 마이그레이션하는 경우 일반적으로 다음 단계를 수행합니다.

1. 애플리케이션에 쓰기 작업을 정지합니다.
   • 이 단계는 선택 사항이며 가동 중지 시간이 필요합니다.
2. 디스크의 스냅숏을 생성합니다.
3. 스냅샷에서 새 관리 디스크 만들기.
4. AKS에서 영구적 볼륨 만들기.
5. PersistentVolumeClaims(정적 프로비전) 대신 기존 볼륨을 사용하도록 Pod 사양 업데이트.
6. 애플리케이션을 AKS에 배포합니다.
7. 애플리케이션이 올바르게 작동하는지 확인합니다.
8. 새 AKS 클러스터에 대한 라이브 트래픽을 가리킵니다.

Important

쓰기 작업을 정지하지 않으려면 새 배포에 데이터를 복제해야 합니다. 그렇지 않으면 디스크 스냅샷을 찍은 후 작성된 데이터가 누락됩니다.

다음 오픈 소스 도구는 관리 디스크를 만들고 Kubernetes 클러스터 간에 볼륨을 마이그레이션하는 데 도움이 될 수 있습니다.

• Azure CLI Disk Copy 확장은 리소스 그룹 및 Azure 지역에서 디스크를 복사하고 변환합니다.
• Azure Kube CLI extension는 ACS Kubernetes 볼륨을 열거하고, 이를 AKS 클러스터로 마이그레이션합니다.

클러스터 구성 배포

AKS에 알려진 정상 구성을 배포하려면 기존 연속 통합 및 지속적인 업데이트 파이프라인을 사용하는 것이 좋습니다. Azure Pipelines를 사용하여 애플리케이션을 빌드하고 AKS에 배포할 수 있습니다. 기존 배포 작업을 복제하고 kubeconfig에서 새 AKS 클러스터를 가리키는지 확인합니다.

가능하지 않은 경우 기존 Kubernetes 클러스터에서 리소스 정의를 내보낸 다음 AKS에 적용합니다. kubectl을 사용하여 개체를 내보낼 수 있습니다. 예시:

kubectl get deployment -o yaml > deployments.yaml

출력을 검사하고 불필요한 라이브 데이터 필드를 제거해야 합니다.

기존 리소스를 다른 영역으로 이동

AKS 클러스터 를 AKS에서 지원하는 다른 지역으로 이동할 수 있습니다. 다른 지역에 새 클러스터를 만든 다음, 리소스 및 애플리케이션을 새 클러스터에 배포하는 것이 좋습니다.

AKS 클러스터에서 실행 중인 서비스가 있는 경우 해당 서비스를 새 지역의 클러스터에 설치하고 구성해야 합니다.

이 문서에서는 다음에 대한 마이그레이션 세부 정보를 요약합니다.

• Azure Migrate를 통해 애플리케이션 컨테이너화
• Load Balancer(표준) 및 Virtual Machine Scale Sets를 사용하는 AKS
• 기존에 연결된 Azure 서비스
• 유효한 할당량 확인
• 고가용성 및 비즈니스 연속성
• 상태 비저장 애플리케이션에 대한 고려 사항
• 상태 저장 애플리케이션에 대한 고려 사항
• 클러스터 구성 배포