Share via

Amazon EKS에서 AKS(Azure Kubernetes Service)로 마이그레이션

  • 아티클

이 문서에서는 Amazon EKS에서 AKS(Azure Kubernetes Service)로 일반적인 상태 비정상 및 상태 저장 워크로드를 마이그레이션하기 위한 전략을 제공합니다.

고려 사항

실제 프로덕션 워크로드의 실제 배포 프로세스는 다음 요인에 따라 달라질 수 있습니다.

  • 배포 전략: GitOps와 기존 DevOps CI/CD(연속 통합/지속적인 배포) 방법 중에서 선택하는 것이 배포 접근 방식에 크게 영향을 줍니다. GitOps는 버전 제어 리포지토리를 통해 관리되는 선언적 인프라의 우선 순위를 지정하고 DevOps CI/CD는 애플리케이션 배달을 위한 자동화된 워크플로에 중점을 둡니다.

  • 배포 아티팩트: 배포 아티팩트 선택은 배포 구조를 정의하는 데 중요한 역할을 합니다. YAML 파일, 매니페스트 파일, Helm 차트 및 Kustomize 구성은 각각 강점 및 사용 사례와 함께 배포 설정을 지정하고 사용자 지정하는 다양한 방법을 나타냅니다.

  • 워크로드 인증 및 권한 부여: 설정에 따라 인증 및 권한 부여 방법이 다를 수 있습니다. 액세스 제어를 위해 AWS(Amazon Web Services) IAM(ID 및 액세스 관리) 역할, 워크로드 ID 메커니즘 또는 연결 문자열 사용할 수 있습니다.

  • 모니터링: 모니터링 솔루션 구현은 배포된 워크로드의 성능과 상태를 보장하기 위해 다양한 도구와 방법론을 포함할 수 있는 중요한 측면입니다. AKS 모니터링이 EKS와 비교되는 방법에 대한 자세한 내용은 Kubernetes 모니터링 및 로깅을 참조하세요.

마이그레이션을 시작하기 전에 다음 일반 지침 및 모범 사례 리소스를 검토하고 고려합니다.

워크로드 마이그레이션 고려 사항

이 섹션에서는 Amazon EKS에서 AKS로 워크로드를 마이그레이션하기 전에 고려해야 할 몇 가지 사항을 검토합니다.

기존 Amazon EKS 환경 이해

기존 EKS 환경을 분석하여 현재 아키텍처, 리소스 및 구성을 이해합니다.

  • EKS 구성 검토: 노드 유형, 노드 수, Kubernetes 버전 및 지원 정책, 크기 조정 구성과 같은 EKS 클러스터 구성을 평가합니다.

    참고 항목

    EKS를 사용하면 EKS 노드에 대한 사용자 지정 AMI 이미지를 만들 수 있습니다. AKS는 사용자 지정 노드 이미지를 사용할 수 없습니다. 배포에 노드 사용자 지정이 필요한 경우 kubelet 사용자 지정 및/또는 DaemonSets를 적용하여 노드를 사용자 지정할 수 있습니다.

  • 애플리케이션 워크로드 검토: 배포, 서비스, 상태 저장 집합, 수신 구성 및 영구 볼륨 클레임을 포함하여 EKS 클러스터에서 실행되는 모든 Kubernetes 워크로드를 식별합니다. 애플리케이션 및 관련 리소스의 전체 목록이 있는지 확인합니다.

  • 종속성 확인: EKS와 관련된 AWS 서비스에 대한 모든 종속성을 식별합니다.

    AWS 서비스 Dependency
    AWS 비밀 관리자 Azure Key Vault
    AWS Guard Duty Agent 컨테이너용 Microsoft Defender
    EKS Pod ID 에이전트 Microsoft Entra ID 워크로드 ID
    Amazon EFS(Elastic File System) 또는 EBS(Elastic Block Store) CSI(Container Storage Interface) 드라이버 AKS CSI 드라이버

  • 백업 EKS 클러스터: Velero와 같은 비 Microsoft 도구를 사용하여 Kubernetes 리소스 및 영구 볼륨을 백업하고 마이그레이션할 수 있습니다.

Azure AKS 환경 준비

Amazon VPC(가상 프라이빗 클라우드) CNI(컨테이너 네트워킹 인터페이스)는 EKS에서 지원하는 기본 네트워킹 플러그 인입니다. AKS 클러스터는 다음을 포함하여 가상 네트워크에 클러스터를 배포하는 여러 네트워크 플러그 인 및 메서드를 지원합니다.

AKS 클러스터를 준비하려면 다음 단계를 수행합니다.

  1. Azure에서 새 AKS 클러스터를 만들어 요구 사항에 맞게 원하는 네트워킹 설정을 구성합니다.
  2. EKS에서 사용되는 Kubernetes 매니페스트 및 YAML 파일을 검토합니다. AKS에서 지원하지 않는 잠재적인 Kubernetes API 버전 비호환성 또는 특정 EKS 구성을 확인합니다.
  3. AKS 클러스터에서 Docker 이미지 및 컨테이너 이미지 레지스트리 위치에 액세스할 수 있는지 확인합니다. 이미지에 액세스하기 위한 네트워크 연결 및 필요한 인증 및 권한 부여 설정을 확인합니다.

다음 단계에 따라 AKS 클러스터를 성공적으로 만들고 Kubernetes 매니페스트 및 Docker 이미지에 대한 호환성을 보장하여 EKS에서 AKS로 원활하게 마이그레이션할 수 있습니다.

마이그레이션 개요

Amazon EKS에서 AKS로 마이그레이션하려면 다음과 같은 몇 가지 단계가 필요합니다.

  • 컨테이너 이미지 마이그레이션: 컨테이너 이미지를 마이그레이션하는 것은 EKS에서 AKS로 이동할 때 중요한 단계입니다. kubectl, Docker 또는 컨테이너 레지스트리와 같은 도구를 사용하여 이미지를 내보내고 가져올 수 있습니다.

    1. EKS에서 이미지를 내보냅니다.
    2. Azure Container Registry 를 설정하고 아직 연결하지 않은 경우 AKS에 연결합니다.
    3. 이미지를 Container Registry에 푸시합니다.

    컨테이너 이미지를 비 Azure 공용 또는 프라이빗 리포지토리에서 직접 Container Registry로 가져올 수도 있습니다. 자세한 내용은 컨테이너 이미지 가져오기를 참조 하세요.

  • Kubernetes 매니페스트 마이그레이션: AKS는 Kubernetes YAML 파일 매니페스트를 사용하여 Kubernetes 개체를 정의합니다. 배포는 일반적으로 kubectl create 또는 kubectl apply를 사용하여 만들어지고 관리됩니다. YAML 형식의 매니페스트 파일을 정의하여 배포를 만듭니다. 자세한 내용은 이 샘플 AKS 매니페스트를 참조하세요. 배포 및 YAML 매니페스트를 검토 하여 YAML 파일이 Kubernetes에서 작동하는 방식에 대해 자세히 알아볼 수 있습니다.

  • 데이터 마이그레이션: 데이터 손실 또는 예기치 않은 가동 중지 시간을 방지하기 위해 상태 저장 애플리케이션의 마이그레이션을 신중하게 계획합니다. 자세한 내용은 상태 저장 워크로드 마이그레이션 고려 사항 섹션 을 참조하세요.

상태 비지정 워크로드 마이그레이션 고려 사항

Kubernetes 매니페스트를 마이그레이션하려면 다음 단계를 포함하여 Azure 환경에서 작동하도록 구성을 조정해야 합니다.

  1. 매니페스트 업데이트: Container Registry의 새 이미지 위치를 사용하도록 Kubernetes 매니페스트를 업데이트합니다. YAML 파일의 이미지 참조를 Container Registry 경로로 바꿉니다.

    1. VPC 및 IAM 역할과 같은 AWS 관련 구성에 대한 기존 Kubernetes 매니페스트 파일을 검토합니다.
    2. 노드, 서비스 계정 및 기타 리소스와 연결된 EKS IAM 역할을 검토합니다. 해당 Azure AKS RBAC(역할 기반 액세스 제어) 역할과 매핑합니다. 자세한 내용은 Kubernetes 워크로드 ID 및 액세스를 참조하세요.
    3. 매니페스트 파일을 수정하여 AWS 관련 설정을 주석과 같은 Azure 특정 설정으로 바꿉니다.

  2. AKS에 매니페스트 적용:

    1. AKS 클러스터에 커넥트.
    2. 를 사용하여 kubectl apply -f수정된 Kubernetes 매니페스트 파일을 적용합니다.

상태 저장 워크로드 마이그레이션 고려 사항

애플리케이션이 데이터 스토리지에 PV(영구 볼륨) 또는 PVC(영구 볼륨 클레임)를 사용하는 경우 이 데이터를 백업해야 합니다. Velero와 같은 도구를 사용하여 PC 및 PVC 데이터를 포함하여 클러스터 백업을 수행할 수 있습니다. 자세한 내용은 Velero를 사용하여 Amazon EKS 클러스터 리소스 백업 및 복원을 참조하세요.

상태 저장 애플리케이션에는 일반적으로 마이그레이션 프로세스에 복잡성을 더하는 영구 데이터 스토리지 요구 사항이 있습니다. Amazon EKS 및 AKS의 스토리지 기능을 비교하려면 Kubernetes 클러스터에 대한 스토리지 옵션을 참조하세요.

영구 데이터를 백업하려면 다음 단계를 수행합니다.

  1. AKS 및 EKS 클러스터에서 Velero를 설정합니다.
  2. EKS 클러스터의 백업을 수행합니다.
  3. az copy 명령을 사용하여 S3 버킷에서 Azure Blob Storage로 Velero 백업을 복사합니다.
  4. AKS 및 EKS는 영구 볼륨 클레임에 대해 다르게 storageClassNames 사용할 수 있으므로 원본 storageClassNames 을 AKS 호환 클래스 이름으로 변환하는 형식을 만듭니 configMap 다. EKS 및 AKS Kubernetes 클러스터에서 동일한 스토리지 솔루션을 사용하는 경우 이 단계를 무시할 수 있습니다.
  5. 백업을 AKS로 복원합니다(Velero 복원 명령 사용).
  6. ECR(Amazon Elastic Container Registry)의 컨테이너 이미지에 대한 참조 또는 비밀에 대한 액세스와 같이 복원된 개체에 필요한 변경 내용을 적용합니다.

참가자

Microsoft에서 이 문서를 유지 관리합니다. 원래 다음 기여자가 작성했습니다.

주요 작성자:

  • Dixit Arora | 수석 고객 엔지니어, ISV DN Coe
  • Ketan Chawda | 수석 고객 엔지니어, ISV DN Coe

기타 기여자:

비공개 LinkedIn 프로필을 보려면 LinkedIn에 로그인합니다.

다음 단계