次の方法で共有

Amazon EKS から Azure Kubernetes Service (AKS) に移行する

  • [アーティクル]

この記事では、一般的なステートレス ワークロードとステートフル ワークロードを Amazon EKS から Azure Kubernetes Service (AKS) に移行する方法について説明します。

考慮事項

現実世界での実動ワークロードの実際のデプロイ プロセスは、次の要因によって異なる場合があります。

  • デプロイ戦略: GitOps と従来の DevOps 継続的インテグレーション/継続的デプロイ (CI/CD) 手法の間での選択は、デプロイ アプローチに大きく影響します。 GitOps では、バージョン管理されたリポジトリを介して管理される宣言型インフラストラクチャを優先しますが、DevOps CI/CD では、アプリケーションデリバリー用の自動化されたワークフローに重点を置きます。

  • デプロイ成果物: デプロイ成果物の選択は、デプロイ構造を定義する上で重要な役割を果たします。 YAML ファイル、マニフェスト ファイル、Helm チャート、Kustomize 構成は、それぞれの長所とユース ケースにより、デプロイ設定の指定とカスタマイズを行うためのさまざまなアプローチを示します。

  • ワークロードの認証と承認: セットアップによって、認証方法と承認方法が異なる場合があります。 アクセス制御には、アマゾン ウェブ サービス (AWS) の ID およびアクセス管理 (IAM) におけるロール、ワークロード ID メカニズム、または接続文字列を使用できます。

  • 監視: 監視ソリューションの実装は、デプロイされたワークロードのパフォーマンスと正常性を確保するため、さまざまなツールと手法を伴う重要な局面です。 AKS 監視と EKS の比較の詳細については、「Kubernetes の監視とログ記録」を参照してください。

移行を開始する前に、次の一般的ガイダンスとベスト プラクティス リソースの確認と検討を行ってください。

ワークロードの移行に関する考慮事項

このセクションでは、Amazon EKS から AKS にワークロードを移行する前に考慮すべき事項をいくつか見てゆきます。

既存の Amazon EKS 環境を把握する

既存の EKS 環境を分析して、現在のアーキテクチャ、リソース、および構成を把握します。

  • EKS 構成を評価する: ノードの種類、ノード数、Kubernetes のバージョンとサポート ポリシー、スケーリング構成など、EKS クラスター構成を評価します。

    Note

    EKS では、EKS ノード用のカスタム AMI イメージを作成できます。 AKS では、カスタム ノード イメージの使用はできません。 デプロイでノードのカスタマイズが必要な場合は、kubelet カスタマイズやデーモンセット を適用してノードをカスタマイズできます。

  • アプリケーション ワークロードを確認する: デプロイ、サービス、ステートフル セット、イングレス構成、永続ボリューム要求など、EKS クラスターで実行されるすべての Kubernetes ワークロードを特定します。 アプリケーションとそれらの関連リソースの完全リストがあることを確かめます。

  • 依存関係をチェックする: EKS に固有の AWS サービスへの依存関係を特定します。

    AWS サービス 依存関係
    AWS Secret Manager Azure Key Vault
    AWS Guard Duty エージェント Microsoft Defender for Containers
    EKS Pod Identity エージェント Microsoft Entra ID ワークロード ID
    Amazon Elastic File System (EFS) または Elastic Block Store (EBS) の Container Storage Interface (CSI) ドライバー AKS CSI ドライバー

  • EKS クラスターをバックアップする: Velero などの Microsoft 以外のツールを使用して、Kubernetes リソースと永続ボリュームのバックアップと移行ができます。

Azure AKS 環境を準備する

Amazon Virtual Private Cloud (VPC) の Container Networking Interface (CNI) は、EKS でサポートされている既定のネットワーク プラグインです。 AKS クラスターでは、クラスターを仮想ネットワークにデプロイするための、次のような複数のネットワーク プラグインと手法をサポートしています。

AKS クラスターを準備するには、次の手順に従います。

  1. Azure に新しい AKS クラスターを作成し、要件に合わせて目的のネットワーク設定を構成します。
  2. EKS で使用されている Kubernetes マニフェストと YAML ファイルを確認します。 潜在的な Kubernetes API バージョンの非互換性、または AKS でサポートされていない特定の EKS 構成をチェックします。
  3. Docker イメージとコンテナー イメージ レジストリの場所に AKS クラスターからアクセスできることを確かめます。 ネットワーク接続と、イメージにアクセスするために必要な認証と承認の設定を確認します。

これらの手順に従うことで、AKS クラスターを正常に作成し、Kubernetes マニフェストと Docker イメージの互換性を確かめて、EKS から AKS へのスムーズな移行プロセスを確保できます。

移行の概要

Amazon EKS から AKS への移行には、次のようないくつかの手順が含まれます。

  • コンテナー イメージの移行: コンテナー イメージの移行は、EKS から AKS に移行する際に重要な手順です。 kubectl、Docker、コンテナー レジストリなどのツールを使用して、イメージのエクスポートとインポートができます。

    1. EKS からイメージをエクスポートします。
    2. Azure Container Registry をセットアップ して、まだ AKS にアタッチしていない場合はアタッチします。
    3. コンテナー レジストリにイメージをプッシュします。

    コンテナー イメージは、Azure 以外のパブリック リポジトリやプライベート リポジトリからコンテナー レジストリに直接インポートすることもできます。 詳しくは、「コンテナー イメージをインポートする」を参照してください。

  • Kubernetes マニフェストの移行: AKS は、Kubernetes YAML ファイル マニフェストを使用して Kubernetes オブジェクトを定義します。 デプロイは通常、kubectl create か kubectl apply で作成および管理されます。 デプロイを作成するには、YAML 形式のマニフェスト ファイルを定義します。 詳細については、このサンプル AKS マニフェストを参照してください。 デプロイと YAML マニフェストを確認することで、Kubernetes での YAML ファイルの動作の詳細がわかります。

  • データの移行: データ損失や予期しないダウンタイムを回避するために、ステートフル アプリケーションの移行は慎重に計画してください。 詳細については、「ステートフル ワークロードの移行に関する考慮事項」を参照してください。

ステートレス ワークロードの移行に関する考慮事項

Kubernetes マニフェストの移行では、次の手順を含め、Azure 環境で動作するように構成を調整する必要があります。

  1. マニフェストを更新する: Kubernetes マニフェストを更新して、Container Registry の新しいイメージの場所を使用します。 YAML ファイル内のイメージ参照を Container Registry パスに置き換えます。

    1. VPC および IAM ロールなど、AWS 固有の構成については、既存の Kubernetes マニフェスト ファイルを確認します。
    2. ノード、サービス アカウント、および他のリソースに関連付けられている EKS IAM ロールを確認します。 それを同等の Azure AKS ロールベース アクセス制御 (RBAC) ロールでマップします。 詳細については、「Kubernetes ワークロード ID およびアクセス管理」を参照してください。
    3. マニフェスト ファイルを変更して、AWS 固有の設定を注釈などの Azure 固有の設定に置き換えます。

  2. マニフェストを AKS に適用する:

    1. AKS クラスターに接続します。
    2. 変更した Kubernetes マニフェスト ファイルを、kubectl apply -f を使用して適用します。

ステートフル ワークロードの移行に関する考慮事項

アプリケーションがデータ ストレージに永続ボリューム (PV) か永続ボリューム要求 (PVC) を使用する場合は、必ずこのデータをバックアップしてください。 Velero などのツールを使用して、PV や PVC データなどのクラスター バックアップを実行できます。 詳細については、「Velero を使用して Amazon EKS クラスターリソースのバックアップと復元を行う」を参照してください。

ステートフル アプリケーションには通常、永続的データ ストレージ要件があり、移行プロセスが複雑になります。 Amazon EKS と AKS のストレージ機能の比較については、「Kubernetes クラスターのストレージ オプション」を参照してください。

永続データをバックアップするには、次の手順に従います。

  1. Velero を AKS および EKS クラスターでセットアップします。
  2. EKS クラスターのバックアップを実行します。
  3. AzCopy コマンドを使用して、S3 バケットから Azure Blob Storage に Velero バックアップをコピーします。
  4. AKS と EKS では永続ボリューム要求に対して異なる storageClassNames を使う場合があるため、AKS と互換性のあるクラス名にソース storageClassNames を変換する configMap を作成します。 EKS と AKS の Kubernetes クラスターで同じストレージ ソリューションを使用している場合は、この手順を無視できます。
  5. バックアップを AKS に復元します (Velero 復元コマンドを使用)。
  6. Amazon Elastic Container Registry (ECR) のコンテナー イメージへの参照やシークレットへのアクセス権など、復元されたオブジェクトに必要な変更を適用します。

共同作成者

この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。

プリンシパルの作成者:

  • Dixit Arora | ISV DN CoE のシニア カスタマー エンジニア
  • ケタン・チャウダ | シニア カスタマー エンジニア (ISV DN CoE)

その他の共同作成者:

パブリックでない LinkedIn プロファイルを表示するには、LinkedIn にサインインします。

次のステップ