この記事では、一般的なステートレスワークロードとステートフルワークロードを Amazon Elastic Kubernetes Service (EKS) から Azure Kubernetes Service (AKS) に移行する方法について説明します。
考慮事項
実際の運用ワークロードのデプロイ プロセスは、次の要因によって異なります。
デプロイ戦略: GitOps の方法と従来の DevOps の継続的インテグレーションと継続的デプロイ (CI/CD) の方法は、デプロイ アプローチに影響します。 GitOps は、バージョン管理されたリポジトリを通じて管理される宣言型インフラストラクチャに優先順位を付けます。 DevOps CI/CD では、アプリケーション配信のための自動化されたワークフローに重点を置いています。
デプロイ成果物: デプロイ成果物は、デプロイ構造の定義に役立ちます。 YAML ファイル、マニフェスト ファイル、Helm チャート、Kustomize 構成には、デプロイ設定を指定およびカスタマイズするためのさまざまな方法が用意されています。 各アプローチには、特定のユース ケースに役立つ固有の強みがあります。
ワークロードの認証と承認: 設定に応じて、認証方法と承認方法が異なります。 アクセス制御には、アマゾン ウェブ サービス (AWS) の ID およびアクセス管理 (IAM) ロール、ワークロード ID メカニズム、または接続文字列を使用できます。
モニタリング： 監視ソリューションを実装する場合は、さまざまなツールと手法を使用して、デプロイされたワークロードのパフォーマンスと正常性を確保できます。 AKS と EKS の監視の比較の詳細については、「 Kubernetes の監視とログ記録」を参照してください。
移行の前に、次の一般的なガイダンスとベスト プラクティス リソースを確認して検討してください。
クラスター オペレーターと開発者のベスト プラクティスを確認します。
アプリケーションが期待どおりに実行されるように、 監視とアラートの戦略 を定義します。
アプリケーションと AKS 環境の セキュリティ とコンプライアンスの要件を定義します。
アクセス制御ポリシーとその適用方法を定義します。 ワークロードが準拠する必要があるコンプライアンス標準を特定します。
AKS 環境とアプリケーションの ディザスター リカバリーとビジネス継続性計画 を定義します。
バックアップと復元のポリシーと手順を定義します。 目標復旧時間 (RTO) と目標復旧時点 (RPO) を特定します。
デプロイ中に発生する可能性のあるリスクや課題を特定します。
ライブ トラフィックを新しい AKS クラスターにリダイレクトする前に、アプリケーションが期待どおりに動作することを確認する機能をテストします。
ワークロードの移行に関する考慮事項
Amazon EKS から AKS にワークロードを移行する前に、次の点を考慮してください。
既存の Amazon EKS 環境を理解する
既存の EKS 環境を分析して、現在のアーキテクチャ、リソース、および構成を理解します。
EKS の構成を確認します。 ノードの種類、ノード数、Kubernetes のバージョンとサポート ポリシー、スケーリング構成など、EKS クラスター構成を評価します。
注
EKS では、EKS ノード用の カスタム AMI イメージ を作成できます。 AKS では、カスタム ノード イメージの使用は許可されません。 デプロイでノードのカスタマイズが必要な場合は、 kubelet カスタマイズ と DaemonSet を 適用してノードをカスタマイズできます。
アプリケーションのワークロードを確認します。 デプロイ、サービス、ステートフル セット、イングレス構成、永続ボリューム要求 (PVC) など、EKS クラスターで実行されるすべての Kubernetes ワークロードを特定します。 アプリケーションとその関連リソースの完全な一覧を作成します。
依存関係を確認します。 EKS に固有の AWS サービスへの依存関係を特定します。
AWS サービス 依存 AWS Secrets Manager Azure Key Vault Amazon GuardDuty エージェント Microsoft Defender for Containers EKS ポッド ID エージェント Microsoft Entra ワークロード ID Amazon Elastic File System (EFS) または Elastic Block Store (EBS) Container Storage Interface (CSI) ドライバー AKS CSI ドライバー EKS クラスターをバックアップします 。 Velero のような Microsoft 以外のツールを使用して、Kubernetes リソースと永続ボリューム (PV) をバックアップおよび移行できます。
Azure AKS 環境を準備する
Amazon Virtual Private Cloud (VPC) Container Networking Interface (CNI) は、EKS がサポートする既定のネットワーク プラグインです。 AKS クラスターでは、仮想ネットワークにクラスターをデプロイするための次のネットワーク プラグインと方法がサポートされています。
- Kubenet ネットワーク (AKS の既定)
- Azure CNI ネットワーク
- Azure CNI オーバーレイ
- 動的割り当てのための Azure CNI ネットワーク
- Azure CNI と Cilium の統合
- Microsoft 以外の CNI
AKS クラスターを準備するには、次の手順に従います。
Azure で新しい AKS クラスターを作成します。 要件に合わせて目的のネットワーク設定を構成します。
EKS で使用する Kubernetes マニフェストと YAML ファイルを確認します。 潜在的な Kubernetes API バージョンの非互換性または AKS でサポートされていない特定の EKS 構成を確認します。
Docker イメージとコンテナー イメージ レジストリの場所に AKS クラスターからアクセスできることを確認します。 ネットワーク接続と、イメージにアクセスするために必要な認証と承認の設定を確認します。
AKS クラスターを正常に作成し、Kubernetes マニフェストと Docker イメージの互換性を確保するには、次の手順に従います。 適切な互換性は、EKS から AKS へのスムーズな移行プロセスを保証するのに役立ちます。
移行の概要
Amazon EKS から AKS への移行には、次の手順が含まれます。
コンテナー イメージの移行: kubectl、Docker、コンテナー レジストリなどのツールを使用して、イメージをエクスポートおよびインポートします。
- EKS からイメージをエクスポートします。
- Azure コンテナー レジストリを設定し、必要に応じて AKS にアタッチします。
- コンテナー レジストリにイメージをプッシュします。
Azure 以外のパブリック リポジトリまたはプライベート リポジトリからコンテナー レジストリにコンテナー イメージを直接インポートすることもできます。 詳細については、「 コンテナー イメージのインポート」を参照してください。
Kubernetes マニフェストの移行: AKS では、Kubernetes YAML ファイル マニフェストを使用して Kubernetes オブジェクトを定義します。 デプロイは通常、
kubectl createまたはkubectl applyを使用して作成および管理されます。 配置を作成するには、マニフェスト ファイルを YAML 形式で定義します。 詳細については、 AKS サンプル マニフェストを参照してください。データ移行: データの損失や予期しないダウンタイムを回避するために、ステートフル アプリケーションの移行を慎重に計画します。
ステートレス ワークロードの移行に関する考慮事項
Kubernetes マニフェストを移行するときは、Azure 環境で動作するように構成を調整する必要があります。
マニフェストの更新: コンテナー レジストリの新しいイメージの場所を使用するように Kubernetes マニフェストを更新します。 YAML ファイル内のイメージ参照をコンテナー レジストリ パスに置き換えます。
VPC や IAM ロールなど、AWS 固有の構成については、既存の Kubernetes マニフェスト ファイルを確認します。
ノード、サービス アカウント、およびその他のリソースに関連付けられている EKS IAM ロールを確認します。 ロールを同等の Azure AKS ロールベース アクセス制御 (RBAC) ロールでマップします。 詳細については、「 Kubernetes ワークロード ID とアクセス」を参照してください。
マニフェスト ファイルを変更して、AWS 固有の設定を注釈などの Azure 固有の設定に置き換えます。
マニフェストを AKS に適用する:
kubectl apply -fを使用して、変更した Kubernetes マニフェスト ファイルを適用します。
ステートフル ワークロードの移行に関する考慮事項
アプリケーションでデータ ストレージに PV または PVC を 使用する場合は、必ずデータをバックアップしてください。 Velero などのツールを使用して、PV や PVC データなどのクラスター バックアップを実行します。 詳細については、「 Velero を使用した Amazon EKS クラスターリソースのバックアップと復元」を参照してください。
ステートフル アプリケーションには通常、永続的なデータ ストレージ要件があり、移行プロセスが複雑になります。 Amazon EKS と AKS のストレージ機能の比較については、 Kubernetes クラスターのストレージ オプションを参照してください。
永続的なデータをバックアップするには、次の手順に従います。
AzCopy コマンドを使用して、S3 バケットから Azure Blob Storage に Velero バックアップをコピーします。
AKS と EKS で PVC に異なる
storageClassNamesが使用されている場合は、ソースstorageClassNamesを AKS 互換のクラス名に変換するconfigMapを作成します。 EKS クラスターと AKS Kubernetes クラスターで同じストレージ ソリューションを使用する場合は、この手順をスキップします。Velero restore コマンドを使用して、バックアップを AKS に復元します。
Amazon Elastic Container Registry のコンテナー イメージへの参照やシークレットへのアクセスなど、復元されたオブジェクトに必要な変更を適用します。
貢献者
Microsoft では、この記事を保持しています。 次の共同作成者がこの記事を書きました。
主要な著者:
- Dixit Arora | ISV DN CoE のシニア カスタマー エンジニア
- ケタン・チャウダ |ISV DN CoE シニア カスタマー エンジニア
その他の共同作成者:
- Paolo Salvatori | プリンシパル カスタマー エンジニア、ISV & DN CoE
- Anthony Nevico | 主要クラウド ソリューション アーキテクト
- フランシスコ・シミー・ナハレス |シニア テクニカル スペシャリスト
公開されていない LinkedIn プロフィールを見るには、LinkedIn にサインインしてください。