Standard에서 Autopilot로 마이그레이션할 준비


이 페이지에서는 서비스 중단을 최소화하면서 표준 Google Kubernetes Engine(GKE) 클러스터에서 Autopilot 클러스터로 워크로드를 마이그레이션하는 데 도움이 되는 고려사항과 권장사항을 제시합니다. 이 페이지의 내용은 Autopilot으로 마이그레이션하기로 결정한 클러스터 관리자를 대상으로 작성되었습니다. 마이그레이션 전에 자세한 정보가 필요하면 GKE 작업 모드 선택GKE Autopilot 및 Standard 비교를 참조하세요.

마이그레이션 작동 방식

Autopilot 클러스터는 Standard 클러스터에서 수동 구성이 필요한 많은 기능 및 기능을 자동화합니다. 또한 Autopilot 클러스터는 애플리케이션에 보다 안전한 기본 구성을 적용하여 프로덕션에 즉시 사용 가능한 환경을 제공하고 Standard 모드와 비교하여 필요한 관리 오버헤드를 줄입니다. Autopilot 클러스터는 기본적으로 여러 GKE 권장사항을 적용합니다. Autopilot은 Kubernetes 매니페스트에서 필요한 항목을 요청하고 GKE가 해당 인프라를 프로비저닝하는 워크로드 중심 구성 모델을 사용합니다.

Standard 워크로드를 Autopilot으로 마이그레이션할 때는, 매니페스트가 일반적으로 직접 프로비저닝해야 하는 인프라를 요청하게 함으로써 워크로드 매니페스트가 Autopilot 클러스터와 호환되도록 준비해야 합니다.

성공적인 마이그레이션을 준비하고 실행하려면 다음 상위 작업을 수행해야 합니다.

  1. 기존 Standard 클러스터에서 실행 전 검사를 실행하여 Autopilot과의 호환성을 확인합니다.
  2. 해당되는 경우 워크로드 매니페스트를 수정하여 Autopilot과 호환되도록 합니다.
  3. 워크로드가 Autopilot에서 올바르게 작동하는지 확인하는 테스트 실행을 수행합니다.
  4. Autopilot 클러스터를 계획하고 만듭니다.
  5. 해당하는 경우 코드형 인프라 도구를 업데이트합니다.
  6. 마이그레이션을 수행합니다.

시작하기 전에

시작하기 전에 다음 태스크를 수행했는지 확인합니다.

  • Google Kubernetes Engine API를 사용 설정합니다.
  • Google Kubernetes Engine API 사용 설정
  • 이 태스크에 Google Cloud CLI를 사용하려면 gcloud CLI를 설치한 후 초기화합니다. 이전에 gcloud CLI를 설치한 경우 gcloud components update를 실행하여 최신 버전을 가져옵니다.
  • 워크로드가 실행 중인 기존 Standard 클러스터가 있는지 확인합니다.
  • 테스트 실행을 수행할 워크로드가 없는 Autopilot 클러스터가 있는지 확인합니다. 새 Autopilot 클러스터를 만들려면 Autopilot 클러스터 만들기를 참조하세요.

Standard 클러스터에서 실행 전 검사 실행

Google Cloud CLI 및 Google Kubernetes Engine API는 실행 중인 Standard 워크로드의 사양을 검증하여 Autopilot 클러스터와의 비호환성을 식별하는 실행 전 검사 도구를 제공합니다. 이 도구는 GKE 버전 1.26 이상에서 사용할 수 있습니다.

  • 명령줄에서 이 도구를 사용하려면 다음 명령어를 실행합니다.
gcloud container clusters check-autopilot-compatibility CLUSTER_NAME

CLUSTER_NAME을 Standard 클러스터 이름으로 바꿉니다. 원하는 경우 이 명령어에 --format=json을 추가하여 JSON 파일로 출력을 가져옵니다.

출력은 실행 중인 모든 Standard 워크로드의 발견 항목을 포함하며 해당하는 경우 카테고리화되어 Autopilot과의 호환성을 보장하기 위해 실행 가능한 권장사항이 포함됩니다. 다음 표에서는 카테고리를 설명합니다.

게재 전 도구 결과
Passed 워크로드는 Autopilot에 필요한 구성 없이 예상대로 실행됩니다.
Passed with optional configuration

워크로드는 Autopilot에서 실행되지만 선택적 구성을 변경하여 환경을 최적화할 수 있습니다. 구성을 변경하지 않으면 Autopilot에서 기본 구성을 적용합니다.

예를 들어 워크로드가 Standard 모드의 N2 머신에서 실행 중인 경우 GKE는 Autopilot에 범용 컴퓨팅 클래스를 적용합니다. 원하는 경우 N2 머신이 지원하는 균형 있는 컴퓨팅 클래스를 요청하도록 워크로드를 수정할 수 있습니다.

Additional configuration required

구성을 변경하지 않으면 Autopilot에서 워크로드가 실행되지 않습니다.

예를 들어 표준에서 NET_ADMIN 기능을 사용하는 컨테이너가 있다고 가정해보세요. Autopilot은 기본적으로 보안을 강화하기 위해 이 기능을 삭제하므로 워크로드를 배포하기 전에 클러스터에서 NET_ADMIN을 사용 설정해야 합니다.

Incompatibility

Autopilot에서 지원하지 않는 기능을 사용하므로 워크로드가 Autopilot에서 실행되지 않습니다.

예를 들어 Autopilot 클러스터는 기본 포드 상태를 개선하기 위해 권한이 있는 포드(포드 사양의 privileged: true)를 거부합니다. Autopilot에서 애플리케이션을 실행하는 유일한 방법은 권한 있는 설정을 삭제하는 것입니다.

실행 전 결과를 기준으로 워크로드 사양 수정

실행 전 검사를 실행한 후 JSON 출력을 단계별로 살펴보고 변경해야 하는 워크로드를 식별하세요. 선택적 구성 권장사항도 구현하는 것이 좋습니다. 각 발견 항목은 워크로드 사양이 어떻게 표시되는지 보여주는 문서 링크도 제공합니다.

Autopilot과 표준의 가장 중요한 차이점은 Autopilot의 인프라 구성은 워크로드 사양에 따라 자동화된다는 점입니다. 노드 taint 및 톨러레이션(toleration)과 같은 Kubernetes 예약 제어는 실행 중인 워크로드에 자동으로 추가됩니다. 필요한 경우 Helm 차트 또는 Kustomize 오버레이와 같은 코드형 인프라 구성도 일치하도록 수정해야 합니다.

일반적으로 변경해야 하는 사항은 다음과 같습니다.

Autopilot의 일반적인 구성 변경사항
컴퓨팅 및 아키텍처 구성

Autopilot 클러스터는 기본적으로 E 시리즈 머신 유형을 사용합니다. 다른 머신 유형이 필요한 경우 워크로드 사양은 컴퓨팅 클래스를 요청해야 하며, 이 클래스는 특정 머신 유형 또는 아키텍처를 사용하는 노드에 이러한 포드를 배치하도록 Autopilot에 지시합니다.

자세한 내용은 Autopilot의 컴퓨팅 클래스를 참조하세요.

가속기

GPU 기반 워크로드는 워크로드 사양에서 GPU를 요청해야 합니다. Autopilot은 필요한 머신 유형과 가속기로 노드를 자동으로 프로비저닝합니다.

자세한 내용은 Autopilot의 GPU 워크로드 배포를 참조하세요.

리소스 요청

모든 Autopilot 워크로드는 포드 사양에서 resources.requests의 값을 지정해야 합니다. GKE는 이러한 값을 사용하여 포드를 실행하기에 적절한 머신 크기를 프로비저닝합니다. Autopilot은 생략한 경우 자동으로 적용되는 기본 요청을 자동으로 포함하며 워크로드의 컴퓨팅 클래스 또는 하드웨어 요청을 기반으로 특정 최솟값과 최댓값을 적용합니다.

자세한 내용은 Autopilot의 리소스 요청을 참조하세요.

스팟 VM의 내결함성 워크로드

워크로드가 표준 버전의 Spot VM에서 실행되는 경우 cloud.google.com/gke-spot=true의 노드 선택기를 설정하여 워크로드 구성의 Spot 포드를 요청하세요.

자세한 내용은 Spot 포드를 참조하세요.

스테이징 Autopilot 클러스터에서 테스트 실행 수행

각 워크로드 매니페스트를 수정한 후 새 스테이징 Autopilot 클러스터에서 테스트 실행 배포를 수행하여 워크로드가 예상대로 실행되는지 확인합니다.

명령줄

다음 명령어를 실행합니다.

kubectl create --dry-run=server -f=PATH_TO_MANIFEST

PATH_TO_MANIFEST를 수정된 워크로드 매니페스트 경로로 바꿉니다.

IDE

Cloud Shell 편집기를 사용하는 경우 테스트 실행 명령어가 기본 제공되며 열린 매니페스트에서 실행됩니다. Visual Studio Code 또는 Intellij IDE를 사용하는 경우 Cloud Code 확장 프로그램을 설치하여 모든 열린 매니페스트에서 테스트 실행을 자동으로 실행합니다.

IDE의 문제 창에는 privileged: true을 지정한 매니페스트에 대한 실패한 테스트 실행을 보여주는 다음 이미지와 같은 테스트 실행 문제가 표시됩니다.

application.yaml이라는 매니페스트의 Visual Studio 코드에서 테스트 실행의 출력입니다. 메시지는 다음과 같습니다. 실패한 서버 테스트 실행이 현재 컨텍스트에서 적용됩니다. 허용 웹훅이 요청을 거부했습니다.

대상 Autopilot 클러스터 계획

테스트 실행에 더 이상 문제가 표시되지 않으면 워크로드의 새 Autopilot 클러스터를 계획하고 만듭니다. 이 클러스터는 이전 섹션에서 매니페스트 수정을 테스트하는 데 사용한 Autopilot 클러스터와 다릅니다.

기본 구성 요구사항은 GKE 온보딩 권장사항을 참조하세요. 그런 다음 다양한 레이어에서 사용 사례와 관련된 정보를 제공하는 Autopilot 개요를 읽습니다.

또한 다음 사항을 고려하세요.

  • Autopilot 클러스터는 VPC 기반이므로 경로 기반 Standard 클러스터에서 Autopilot으로 마이그레이션하지 않는 것이 좋습니다.
  • 모든 커스텀 방화벽 규칙과 VPC 설정을 포함하여 Autopilot 클러스터와 Standard 클러스터에 대해 동일하거나 유사한 VPC를 사용합니다.
  • Autopilot 클러스터는 GKE Dataplane V2를 사용하며 Cilium NetworkPolicy만 지원합니다. Calico NetworkPolicy는 지원되지 않습니다.
  • Autopilot에서 IP 매스커레이딩을 사용하려면 이그레스 NAT 정책을 사용하세요.
  • 비공개 Standard 클러스터가 있는 경우 비슷한 격리 설정으로 비공개 Autopilot 클러스터를 만듭니다.
  • 클러스터를 만드는 동안 Standard 클러스터와 동일한 범위 크기로 기본 IPv4 범위를 지정합니다.
  • 특히 대규모 클러스터가 있는 경우 모드 간 할당량 차이에 대해 알아보세요.
  • Standard와 다른 Autopilot의 노드당 최대 포드 수에 대해 알아보세요. 노드 또는 포드 어피니티를 자주 사용하는 경우 더 중요합니다.
  • 모든 Autopilot 클러스터는 Cloud DNS를 사용합니다.

Autopilot 클러스터 만들기

클러스터를 만들 준비가 되면 Autopilot 클러스터 만들기를 사용합니다. 모든 Autopilot 클러스터는 리전 클러스터이고 출시 채널에 자동으로 등록되지만 채널과 클러스터 버전을 지정할 수 있습니다. 프로덕션 워크로드가 즉시 예약될 수 있도록 작은 샘플 워크로드를 클러스터에 배포하여 노드 자동 프로비저닝을 트리거하는 것이 좋습니다.

코드형 인프라 도구 업데이트

Autopilot을 지원하는 코드형 인프라 제공업체는 다음과 같습니다.

원하는 공급업체의 문서를 읽고 구성을 수정합니다.

마이그레이션 방식 선택

사용하는 마이그레이션 방법은 개별 워크로드 및 멀티 클러스터 서비스멀티 클러스터 서비스 클러스터 인그레스와 클러스터의 Kubernetes 객체 상태 관리 방법을 설명합니다.

워크로드 유형 게재 전 도구 결과 마이그레이션 접근 방식
스테이트리스(Stateless)
  • 전달
  • 선택적 구성과 함께 전달
  • 추가 구성 필요

PassedPassed with optional configuration 워크로드의 경우 Backup for GKE를 사용하여 모든 워크로드를 Autopilot 클러스터로 이동할 수도 있습니다. Autopilot 클러스터를 타겟팅하려면 파이프라인 및 업스트림 매니페스트를 계속 업데이트해야 합니다. 대략적인 단계는 Backup for GKE를 사용하여 모든 워크로드 마이그레이션을 참조하세요.

스테이트풀(Stateful)
  • 전달
  • 선택적 구성과 함께 전달

다음 방법 중 하나를 사용하세요.

  • Backup for GKE: Backup for GKE를 사용하여 기존 PersistentVolume 관계를 유지하면서 스테이트풀(Stateful) 워크로드를 Autopilot 클러스터로 이동합니다. 대략적인 단계는 Backup for GKE를 사용하여 모든 워크로드 마이그레이션을 참조하세요. 리전 간 마이그레이션이 지원됩니다.
  • 수동: 스테이트풀(Stateful) 워크로드를 수동으로 이동합니다. 따라서 PersistentVolume 및 Compute Engine 디스크를 신중하게 계획해야 합니다. 대략적인 단계는 수동으로 스테이트풀(Stateful) 워크로드 마이그레이션을 참조하세요. 리전 간 마이그레이션은 지원되지 않습니다.
추가 구성 필요 Kubernetes 매니페스트를 업데이트하고 예약된 다운타임 동안 Autopilot에 다시 배포합니다. 대략적인 단계는 수동으로 스테이트풀(Stateful) 워크로드 마이그레이션을 참조하세요.

대략적인 마이그레이션 단계

마이그레이션을 시작하기 전에 실행 전 검사에서 Incompatible 또는 Additional configuration required 결과를 완료했는지 확인합니다. 이러한 결과가 포함된 워크로드를 수정하지 않고 Autopilot에 배포하면 워크로드가 실패합니다.

다음 섹션에서는 가상 마이그레이션에 대해 개략적으로 설명합니다. 실제 단계는 환경 및 각 워크로드에 따라 달라집니다. 프로덕션 환경을 마이그레이션하기 전에 워크로드를 계획하여 테스트하고 다시 테스트합니다. 고려사항은 다음과 같습니다.

  • 마이그레이션 프로세스의 기간은 마이그레이션하는 워크로드 수에 따라 달라집니다.
  • 스테이트풀(Stateful) 워크로드를 마이그레이션하는 동안 다운타임은 필수입니다.
  • 수동 마이그레이션을 사용하면 마이그레이션 중에 개별 워크로드에 집중할 수 있으므로 사례별로 문제를 실시간으로 해결할 수 있습니다.
  • 모든 경우에 스테이트리스(Stateless) 및 스테이트풀(Stateful) 워크로드의 기능을 용이하게 하는 서비스, 인그레스, 기타 Kubernetes 객체를 마이그레이션해야 합니다.

Backup for GKE를 사용하여 모든 워크로드 마이그레이션

Standard 클러스터에서 실행되는 모든 워크로드(스테이트풀(Stateful) 및 스테이트리스(Stateless))가 Autopilot과 호환되고 실행 전 도구가 모든 워크로드에 대해 Passed 또는 Passed with optional configuration를 반환하는 경우 Backup for GKE를 사용하여 Standard 클러스터와 워크로드의 전체 상태를 백업하고 Autopilot 클러스터에 백업을 복원합니다.

이 방식에는 다음과 같은 이점이 있습니다.

  • 필요한 최소한의 구성만으로 모든 워크로드를 표준에서 Autopilot 작업으로 이동할 수 있습니다.
  • 스테이트리스(Stateless) 및 스테이트풀(Stateful) 워크로드를 이동하고 워크로드와 연결된 PersistentVolume 간의 관계를 유지할 수 있습니다.
  • 롤백은 직관적이며 Google에서 관리합니다. 전체 마이그레이션을 롤백하거나 특정 워크로드를 선택적으로 롤백할 수 있습니다.
  • Google Cloud 리전에서 스테이트풀(Stateful) 워크로드를 마이그레이션할 수 있습니다. 스테이트풀(Stateful) 워크로드 수동 마이그레이션은 동일한 리전에서만 가능합니다.

이 방법을 사용하면 GKE는 실행 전 도구에서 Passed with optional configuration 결과를 수신한 워크로드에 Autopilot 기본 구성을 적용합니다. 이러한 워크로드를 마이그레이션하기 전 이러한 기본값을 숙지해야 합니다.

다운타임 없이 스테이트리스(Stateless) 워크로드 수동 마이그레이션

서비스 다운타임 없이 스테이트리스(Stateless) 워크로드를 마이그레이션하려면 소스 및 대상 클러스터를 GKE Fleet에 등록하고, 멀티 클러스터 서비스 및 멀티 클러스터 인그레스를 사용하여 마이그레이션 중에 워크로드를 계속 사용할 수 있도록 합니다.

  1. 소스 클러스터와 대상 클러스터에 멀티 클러스터 서비스 및 멀티 클러스터 인그레스를 사용 설정하세요. 자세한 내용은 멀티 클러스터 서비스 구성멀티 클러스터 인그레스 설정을 참조하세요.
  2. 데이터베이스 워크로드와 같은 백엔드 종속 항목이 있는 경우 멀티 클러스터 서비스를 사용하여 Standard 클러스터에서 해당 서비스를 내보냅니다. 이를 통해 Autopilot 클러스터의 워크로드가 Standard 클러스터의 종속 항목에 액세스할 수 있습니다. 자세한 내용은 내보내기를 위한 서비스 등록을 참조하세요.
  3. 멀티 클러스터 인그레스 및 멀티 클러스터 서비스를 배포하여 클러스터 간 인바운드 트래픽을 제어하세요. 멀티 클러스터 서비스가 Standard 클러스터로만 트래픽을 전송하도록 구성합니다. 자세한 내용은 클러스터 간 인그레스 배포를 참조하세요.
  4. 업데이트된 매니페스트가 있는 스테이트리스(Stateless) 워크로드를 Autopilot 클러스터에 배포하세요. 내보낸 멀티 클러스터 서비스는 해당 스테이트풀(Stateful) 워크로드에 자동으로 트래픽을 연결하고 전송합니다.
  5. 멀티 클러스터 서비스를 업데이트하여 인바운드 트래픽을 Autopilot 클러스터로 전달합니다. 자세한 내용은 클러스터 선택을 참조하세요.

이제 Autopilot 클러스터에서 스테이트리스(Stateless) 워크로드를 제공합니다. 소스 클러스터에 스테이트리스(Stateless) 워크로드만 있고 종속 항목이 남아 있지 않으면 마이그레이션 완료를 진행합니다. 스테이트풀(Stateful) 워크로드가 있는 경우 스테이트풀(Stateful) 워크로드 수동 마이그레이션으로 진행합니다.

수동으로 스테이트풀(Stateful) 워크로드 마이그레이션

스테이트리스(Stateless) 워크로드를 마이그레이션한 후에는 Standard 클러스터에서 스테이트풀(Stateful) 워크로드를 정지하고 마이그레이션해야 합니다. 이 단계에서는 클러스터에 다운타임이 필요합니다.

  1. 환경 다운타임을 시작합니다.
  2. 스테이트풀(Stateful) 워크로드를 정지합니다.
  3. Autopilot 호환성을 위해 워크로드 매니페스트를 수정해야 합니다. 자세한 내용은 실행 전 결과를 기준으로 워크로드 사양 수정을 참조하세요.
  4. Autopilot 클러스터에 워크로드를 배포합니다.

  5. Autopilot 클러스터에 스테이트풀(Stateful) 워크로드를 위한 서비스를 배포합니다.

  6. 스테이트리스(Stateless) 워크로드가 백엔드 워크로드와 계속 통신하도록 클러스터 내 네트워킹을 업데이트합니다.

    • Standard 클러스터 백엔드 서비스에서 고정 IP 주소를 사용한 경우 Autopilot에서 해당 IP 주소를 다시 사용하세요.
    • Kubernetes가 IP 주소를 할당하도록 허용하면 백엔드 서비스를 배포하고, 새 IP 주소를 가져오고, 새 IP 주소를 사용하도록 DNS를 업데이트합니다.

이 단계에서는 다음 조건을 충족해야 합니다.

  • Autopilot에서 모든 스테이트리스(Stateless) 워크로드를 실행 중이어야 합니다.
  • 백엔드 스테이트풀(Stateful) 워크로드가 있는 경우에도 Autopilot에서 실행 중이어야 합니다.
  • 스테이트리스(Stateless) 및 스테이트풀(Stateful) 워크로드는 서로 통신할 수 있어야 합니다.
  • 멀티 클러스터 서비스는 모든 인바운드 트래픽을 Autopilot 클러스터로 전달해야 합니다.

모든 워크로드 및 Kubernetes 객체를 새 클러스터로 마이그레이션한 후 마이그레이션 완료로 넘어가세요.

대안: 다운타임 시 모든 워크로드 수동 마이그레이션

다운타임을 최소화하면서 워크로드를 마이그레이션하기 위해 멀티 클러스터 서비스 및 멀티 클러스터 인그레스를 사용하지 않으려면 다운타임 중에 모든 워크로드를 마이그레이션합니다. 이 방법을 사용하면 서비스의 다운타임이 길어지지만 멀티 클러스터 기능을 사용할 필요가 없습니다.

  1. 다운타임을 시작합니다.
  2. Autopilot 클러스터에 스테이트리스(Stateless) 매니페스트를 배포합니다.
  3. 스테이트풀(Stateful) 워크로드를 수동으로 마이그레이션합니다. 자세한 내용은 스테이트풀(Stateful) 워크로드 수동 마이그레이션 섹션을 참조하세요.
  4. 서비스의 새 IP 주소를 사용하도록 클러스터 내 및 인바운드 외부 트래픽 모두에 대해 DNS 레코드를 수정합니다.
  5. 다운타임을 종료합니다.

마이그레이션 완료

모든 워크로드 및 서비스를 새 Autopilot 클러스터로 이전한 후 다운타임을 종료하고 환경이 미리 결정된 기간 동안 흡수되도록 허용합니다. 마이그레이션 상태에 만족하고 마이그레이션을 롤백할 필요가 없으면 마이그레이션 아티팩트를 정리하고 마이그레이션을 완료할 수 있습니다.

선택사항: 멀티 클러스터 기능 삭제

멀티 클러스터 인그레스 및 멀티 클러스터 서비스를 사용하여 마이그레이션하고 Autopilot 클러스터를 Fleet에 등록된 상태로 두지 않으려면 다음을 수행합니다.

  1. 인바운드 외부 트래픽의 경우 인그레스를 배포하고 워크로드를 노출하는 서비스의 IP 주소로 설정합니다. 자세한 내용은 외부 애플리케이션 부하 분산기용 인그레스를 참조하세요.
  2. 프런트엔드 워크로드에서 스테이트풀(Stateful) 종속 항목으로의 클러스터 내 트래픽의 경우 해당 서비스의 IP 주소를 사용하도록 클러스터 DNS 레코드를 업데이트합니다.
  3. 멀티 클러스터 인그레스 및 마이그레이션 중에 만든 멀티 클러스터 서비스 리소스를 삭제합니다.
  4. 멀티 클러스터 인그레스 및 멀티 클러스터 서비스를 사용 중지합니다.
  5. Fleet에서 Autopilot 클러스터의 등록을 취소합니다.

Standard 클러스터 삭제

마이그레이션이 완료된 후 충분한 시간이 경과하고 새 클러스터의 상태가 만족스러우면 Standard 클러스터를 삭제합니다. 백업된 표준 매니페스트를 유지하는 것이 좋습니다.

잘못된 마이그레이션 롤백

문제가 발생하여 Standard 클러스터로 되돌리려면 마이그레이션 수행 방법에 따라 다음 중 하나를 수행하세요.

  • 마이그레이션 중에 Backup for GKE를 사용하여 백업을 만든 경우 원본 Standard 클러스터에 백업을 복원합니다. 자세한 내용은 백업 복원을 참조하세요.

  • 워크로드를 수동으로 마이그레이션한 경우 Standard 클러스터와 표준 Autopilot 클러스터를 소스로 사용하여 이전 섹션의 마이그레이션 단계를 반복합니다. 대략적으로 다음 단계가 포함됩니다.

    1. 다운타임을 시작합니다.
    2. 스테이트풀(Stateful) 워크로드를 Standard 클러스터로 수동으로 마이그레이션합니다. 자세한 내용은 스테이트풀(Stateful) 워크로드 수동 마이그레이션 섹션을 참조하세요.
    3. 마이그레이션하기 전에 백업한 원래 매니페스트를 사용하여 스테이트리스(Stateless) 워크로드를 Standard 클러스터로 이동합니다.
    4. Standard 클러스터에 인그레스를 배포하고 서비스의 새 IP 주소로 DNS를 컷오버합니다.
    5. Autopilot 클러스터를 삭제합니다.

다음 단계