Azure Kubernetes Service (AKS) クラスターを別のリージョンに再配置する
この記事では、Azure Kubernetes Service クラスターを別のリージョンに再配置するためのガイダンスについて説明します。
既存の Azure リソースを 1 つのリージョンから他のリージョンに移動する必要が生じる理由は多数存在します。 以下を行うことができます。
- 新しい Azure リージョンの利点を活用する。
- 特定のリージョンでしか利用できない機能やサービスをデプロイする。
- 内部ポリシーやガバナンスの要件を満たす。
- 会社の合併と買収に合わせた調整を行う
- 容量計画の要件を満たす。
Note
リリース サイクルが速いお客様は、CI/CD パイプラインを利用することがよくあります。 このような場合は、ターゲット リージョンに AKS クラスターを再デプロイするのではなく、ビルドおよびリリース パイプラインを変更することを検討してください。
前提条件
再配置の計画ステージを始める前に、まず次の前提条件を確認してください。
ターゲット リージョンに、新しいクラスター ノードに対応できる十分な容量 (VM SKU) を確保します。
ターゲット サブスクリプションに対するリソース作成のアクセス許可を持っていることを確認します。 AKS をデプロイできるリージョンが Azure ポリシーで制限されていないことを確認します。
(省略可能) ソース AKS クラスターをプロビジョニングしたコードとしてのインフラストラクチャ (IaC) テンプレートまたはスクリプトを収集します。
ターゲット クラスター内にアプリケーション ワークロードを再作成するために、Kubernetes マニフェストを収集します。
ヒント
Kubernetes 構成マニフェストが Git リポジトリに格納され、Fluxなどのクラスター内で実行されている GitOps オペレーターによって自動的に適用される、ワークロード デプロイに対する GitOps アプローチを評価します。 GitOps アプローチでは、GitOps コントローラーをインストールしてリポジトリをポイントするのと同じくらい簡単に、ワークロードを異なるクラスターに再デプロイできます。
クラスターのイングレスの実装を確認します。
パブリック ドメインをクラスターのイングレス エンドポイントにポイントするために必要な DNS 変更を文書化します。
クラスターに、ターゲット クラスターに移行する必要がある状態データ (永続ボリュームなど) が格納されているかどうかを確認します。
パブリック TLS 証明書の管理と配布を文書化します。
AKS API サービスの許可リストで定義されているすべての IP アドレスをキャプチャします。
すべての依存リソースについて理解します。 次のようなリソースです。
- キュー、メッセージ バス、キャッシュ エンジン
- Azure Key Vault
- マネージド ID
- Virtual Network の構成。 Azure の高度なネットワーク モデルを使用する場合にコンテナーの IP 拡張を可能にする十分なサブネット サイズを定義します
- パブリック IP アドレス
- Virtual Network ゲートウェイ (VNG)。 ターゲット リージョン内のオンプレミス環境へのサイト間通信が必要な場合は、ターゲット仮想ネットワークに VNG を作成する必要があります。
- Azure プライベート エンドポイント。 プライベート リンク エンドポイントを使用する Azure PaaS リソースを確認し、ACR、Azure SQL DB、KeyVault などのターゲット リージョンに作成された新しいプライベート リンク インスタンスを確認する必要があります。
- Azure Application Gateway
- Azure DNS
- Azure Firewall
- Azure Monitor (コンテナーの分析情報)
- Azure Container Registry では、ACR インスタンス間でイメージをレプリケートできます。 イメージをプルするときに最適なパフォーマンスを得られるように、レジストリはターゲット リージョンに存在する必要があります。
Note
Azure Container Registry を使用してコンテナー レジストリに対する認証を行う場合、新しい AKS クラスターのマネージド ID は、付与された
AcrPullRBAC ロールにすることができます。 - Azure Managed Disks
- Azure Files
準備
クラスターの再配置プロセスを始める前に、次の準備が済んでいることを確認します。
AKS クラスター ノードとポッドに対応するために、Azure CNI ネットワークを使用している場合は、十分なサイズの多数のサブネットを含む仮想ネットワークをデプロイします。
Azure Key Vault を使用している場合は、Key Vault をデプロイします。
関連する TLS イングレス証明書が、理想的には Azure Key Vault などの安全なストアでのデプロイに使用できることを確認します。
コンテナー レジストリをデプロイします。 ソース レジストリ イメージを自動的に同期するか、CI/CD パイプラインまたはスクリプトを使用して新しいイメージを再構築してターゲット レジストリにプッシュします。
(省略可能) Azure Application Gateway をデプロイし、イングレス トラフィック Application Gateway イングレス コントローラー (AGIC) はクラスターと緊密に統合できるように処理します
クラスター ワークロードに必要なすべてのデータ ソースをデプロイし、ソース データを復元または同期します。
ソース クラスターとそれが依存するサービスのデプロイに使用された CI/CD パイプラインで定義されている、既存の IaC 成果物を実行します。 コードまたはテンプレートの入力パラメーターを変更して、別のリソース グループと Azure リージョンに再デプロイします。
Redeploy
次の手順に従って、データ移行を行わずに AKS クラスターをデプロイします。
Azure でターゲット環境を作成するには、ローカル ワークステーションで既存の IaC 成果物を手動で実行します。
既存の IaC 資産がない場合、現在のクラスター構成 を ARM テンプレートとしてエクスポートし、ターゲット リージョンに対して実行できます。 IaC テンプレート は最初から作成されるか、Bicep、JSON、Terraform、またはその他のソリューションを使用して変更されたバージョンのサンプル テンプレートです。
Note
- Private Link 接続、ACR 接続レジストリ、Azure Monitor ワークスペースのデータ ソースは現在、このメソッドを使用してエクスポートされていないため、実行前に生成されたテンプレートから削除する必要があります。
コンテナー ワークロードを AKS クラスターにデプロイします。これは、次の 2 つの方法で実現できます。
- "プル" マニフェストはリポジトリからプルされ、GitOps アプローチと呼ばれるクラスター内で実行されるコントローラーによって適用されます。
- プッシュ。 マニフェストは、Kubernetes API サービスと kubectl コマンド ライン ツールを使用して、CI/CD パイプラインまたはローカル ワークステーションからクラスターにプッシュされます。
新しいクラスターが予想どおりに実行されるようにするには、テストと検証を実行します。
パブリック DNS エントリを変更して、ターゲット クラスターの外部イングレス IP (Azure パブリック ロード バランサー IP または Application Gateway パブリック IP) をポイントするようにします。
Azure DNS や Azure Traffic Manager などのグローバル負荷分散ソリューションを使用するデプロイでは、リージョンを構成に追加する必要があります。
データ移行による再デプロイ
永続ボリュームなどのローカル ストレージを使用してクラスター内にデータを格納したり、データベース サービスをホストしたりする AKS ワークロードは、ソース クラスターでバックアップし、ターゲット クラスターに復元できます。 バックアップと復元を実行する方法については、「Azure CLI を使用して Azure Kubernetes Service をバックアップする」を参照してください。