Azure Kubernetes Service (AKS) に移行する

Azure Kubernetes Service (AKS) への正常な移行を計画して実行できるように、このガイドでは、現在お勧めの AKS 構成の詳細について説明します。 この記事では、すべてのシナリオについて説明しているわけではなく、移行が成功するように計画するための詳細情報へのリンクが示されています。

この記事では、次に関連した移行の詳細について説明します。

  • Azure Migrate によるアプリケーションのコンテナー化
  • Standard Load Balancer と Virtual Machine Scale Sets を使用する AKS
  • 既存の接続されている Azure サービス
  • 有効なクォータを確保する
  • 高可用性とビジネス継続性
  • ステートレス アプリケーションに関する考慮事項
  • ステートフル アプリケーションに関する考慮事項
  • クラスター構成のデプロイ

注意

シナリオによっては、次のオープンソース ツールが移行に役立つ場合があります。

開始する前に

移行プロセスの一部として組み込むべき重要なプラクティスは、必ず一般に使われるデプロイとテストのパターンに従うことです。 デプロイ前にアプリケーションをテストすることは、その品質、機能、ターゲット環境との互換性を確保するための重要な手順です。 これにより、アプリケーションや基となるインフラストラクチャのパフォーマンス、セキュリティ、または使いやすさに影響を与える可能性があるエラー、バグ、または問題を特定し、修正できます。

Azure Migrate によるアプリケーションの AKS への移行

Azure Migrate により、オンプレミスのサーバー、インフラストラクチャ、アプリケーション、データの評価と、Azure へのそれらの移行を行うための統合プラットフォームが提供されます。 AKS には、次のタスクで Azure Migrate を使用できます。

Standard Load Balancer と Virtual Machine Scale Sets を使用する AKS

AKS は、管理オーバーヘッドが少ない独自の機能を提供するマネージド サービスです。 AKS はマネージド サービスであるため、AKS でサポートされている一連のリージョンから選択する必要があります。 既存のクラスターから AKS への移行中に、AKS のマネージド コントロール プレーンで正常性が維持されるよう、既存のアプリケーションの変更が必要になる場合があります。

次の機能を確実に利用できるように、Virtual Machine Scale Sets および Azure Standard Load Balancer を使用した AKS クラスターを使用することをお勧めします。

仮想マシン可用性セットを使用した AKS クラスターでは、これらの機能の多くがサポートされません。

Standard Load Balancer と Virtual Machine Scale Sets を使用する AKS を作成する

次の例では、仮想マシン (VM) スケール セットによってサポートされる 1 つのノード プールを使用して、AKS クラスターを作成します。 これにより、クラスターのノード プール上でクラスター オートスケーラーが有効になり、最小 1 つ、最大 3 つのノードが設定されます。

  1. az group create コマンドを使用して、リソース グループを作成します。

    az group create --name myResourceGroup --location eastus
    
  2. az aks create コマンドを使用して、AKS クラスターを作成します。

    az aks create \
      --resource-group myResourceGroup \
      --name myAKSCluster \
      --node-count 1 \
      --vm-set-type VirtualMachineScaleSets \
      --load-balancer-sku standard \
      --enable-cluster-autoscaler \
      --min-count 1 \
      --max-count 3
    

既存の接続されている Azure サービス

クラスターを移行するとき、外部の Azure サービスに接続していることがあります。 次のサービスではリソースを再作成する必要はありませんが、機能を維持するには接続を以前のクラスターから新しいクラスターへ更新する必要があります。

  • Azure Container Registry
  • Log Analytics
  • Application Insights
  • Traffic Manager
  • ストレージ アカウント
  • 外部データベース

有効なクォータを確保する

移行中にその他の VM がサブスクリプションにデプロイされるため、クォータと制限がこれらのリソースに十分であることを確認する必要があります。 必要に応じて、vCPU クォータの増量を要求します。

IP を使い切らないようにするには、ネットワーク クォータの増量を要求することが必要になる場合があります。 詳細については、AKS のネットワークと IP 範囲に関するページを参照してください。

詳細については、Azure サブスクリプションとサービスの制限 に関する記事を参照してください。 現在のクォータを確認するには、Azure portal でサブスクリプション ブレードに移動し、サブスクリプションを選択して [使用量 + クォータ] を選択します。

高可用性とビジネス継続性

アプリケーションでダウンタイムを処理できない場合は、高可用性の移行シナリオに関するベスト プラクティスに従う必要があります。 Azure Kubernetes Service (AKS) での複雑な事業継続の計画、ディザスター リカバリー、アップタイムの最大化に関するベスト プラクティスに関するページを参照してください。

複雑なアプリケーションの場合、通常は、一度にすべてではなく時間をかけて移行します。つまり、新旧の環境がネットワーク経由で通信する必要がある場合があります。 これまで ClusterIP サービスを使用して通信していたアプリケーションは、LoadBalancer タイプとして公開し、適切にセキュリティで保護する必要がある場合があります。

移行を完了するには、AKS で実行されている新しいサービスをクライアントが指すようにします。 AKS クラスターの前面に配置されたロード バランサーを指すように DNS を更新して、トラフィックをリダイレクトすることをお勧めします。

Azure Traffic Manager を使うと、お客様を目的の Kubernetes クラスターおよびアプリケーション インスタンスに送ることができます。 Traffic Manager は、ネットワーク トラフィックをリージョン間で分散することができる、DNS ベースのトラフィック ロード バランサーです。 パフォーマンスと冗長性を最大限に高めるため、すべてのアプリケーション トラフィックは、Traffic Manager を介して AKS クラスターへ送るようにします。

複数クラスターの環境では、各 AKS クラスター上のサービスを指す、Traffic Manager DNS 名に接続するようにしましょう。 これらのサービスは、Traffic Manager エンドポイントを使用して定義します。 各エンドポイントは、"サービス ロード バランサー IP" です。 この構成を使用して、あるリージョンの Traffic Manager エンドポイントから別のリージョンのエンドポイントにネットワーク トラフィックを送信します。

AKS with Traffic Manager

Azure Front Door Service は、AKS クラスターのトラフィックをルーティングするためのもう 1 つのオプションです。 Azure Front Door Service では、高可用性のために最大限のパフォーマンスと即時グローバル フェイルオーバーを最適化することで、Web トラフィックのグローバル ルーティングを定義、管理、監視することができます。

ステートレス アプリケーションに関する考慮事項

ステートレス アプリケーションの移行では、次の手順を実行します。

  1. リソース定義 (YAML または Helm) を新しいクラスターに適用します。
  2. すべてが想定どおりに動作していることを確認します。
  3. トラフィックをリダイレクトして新しいクラスターをアクティブにします。

ステートフル アプリケーションに関する考慮事項

データの損失や予期しないダウンタイムを回避するために、ステートフル アプリケーションの移行は慎重に計画してください。

Azure Files

ディスクとは異なり、Azure Files は複数のホストに同時にマウントできます。 AKS クラスターでは、Azure と Kubernetes によって、AKS クラスターでまだ使用されているポッドの作成は防止されません。 データ損失や予期しない動作を防ぐために、複数のクラスターが同じファイルに同時に書き込まないようにしてください。

お使いのアプリケーションが、同じファイル共有を指す複数のレプリカをホストできる場合は、ステートレスの移行手順に従って、YAML 定義を新しいクラスターにデプロイしてください。

できない場合は、使用可能な移行方法として、次の手順を実行します。

  1. アプリケーションが正常に動作していることを確認します。
  2. ライブ トラフィックを新しい AKS クラスターに送ります。
  3. 古いクラスターを切断します。

空の共有で開始し、ソース データのコピーを作成したい場合は、az storage file copy コマンドを使用してデータを移行できます。

永続ボリュームの移行

既存の永続ボリュームを AKS に移行する場合は、通常、次の手順に従います。

  1. アプリケーションの書き込みを停止します。
    • この手順は省略可能であり、ダウンタイムが必要になります。
  2. ディスクのスナップショットを作成します。
  3. スナップショットから新しいマネージド ディスクを作成します。
  4. AKS に永続ボリュームを作成します。
  5. PersistentVolumeClaims (静的プロビジョニング) ではなく既存のボリュームを使用するようにポッドの指定を更新します。
  6. アプリケーションを AKS にデプロイします。
  7. アプリケーションが正常に動作していることを確認します。
  8. ライブ トラフィックを新しい AKS クラスターに送ります。

重要

書き込みを停止しないことを選択した場合は、データを新しいデプロイにレプリケートする必要があります。 そうしないと、ディスクのスナップショットを作成した後に書き込まれたデータを失うことになります。

次のオープン ソースのツールは、マネージド ディスクを作成し、Kubernetes クラスター間でボリュームを移行するのに役立ちます。

クラスター構成のデプロイ

既存の継続的インテグレーション (CI) および継続的デリバリー (CD) パイプラインを使用して、既知の正常な構成を AKS にデプロイすることをお勧めします。 Azure Pipelines を使用すると、アプリケーションをビルドして AKS にデプロイできます。 既存のデプロイ タスクを複製し、kubeconfig が新しい AKS クラスターを指すようにします。

それが不可能な場合は、既存の Kubernetes クラスターからリソース定義をエクスポートし、AKS にそれを適用します。 オブジェクトをエクスポートするには kubectl を使用できます。 次に例を示します。

kubectl get deployment -o yaml > deployments.yaml

必ず出力を確認し、不要なライブ データ フィールドを削除してください。

既存のリソースを別のリージョンに移動する

AKS クラスターを、AKS でサポートされている別のリージョンに移動する必要がある場合があります。 もう一方のリージョンに新しいクラスターを作成し、その新しいクラスターにリソースとアプリケーションをデプロイすることをお勧めします。

AKS クラスターで実行されているサービスがある場合は、新しいリージョンのクラスターにそれらのサービスをインストールして構成する必要があります。

この記事では、次の移行の詳細について説明しました。

  • Azure Migrate によるアプリケーションのコンテナー化
  • Standard Load Balancer と Virtual Machine Scale Sets を使用する AKS
  • 既存の接続されている Azure サービス
  • 有効なクォータを確保する
  • 高可用性とビジネス継続性
  • ステートレス アプリケーションに関する考慮事項
  • ステートフル アプリケーションに関する考慮事項
  • クラスター構成のデプロイ