Azure Kubernetes Service (AKS) に移行する

  • [アーティクル]

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

このドキュメントでは、次のシナリオをサポートできます。

移行するときは、ターゲットの Kubernetes のバージョンが AKS に対して確実にサポート対象期間内であるようにします。 古いバージョンはサポート対象範囲内ではない場合があり、AKS でサポートされるバージョンのアップグレードが必要になります。 詳細については、AKS でサポートされる Kubernetes のバージョンに関するページを参照してください。

新しいバージョンの Kubernetes に移行する場合は、「Kubernetes のバージョンとバージョン スキュー サポート ポリシー」を確認してください。

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

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

  • 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 クラスターでは、これらの機能の多くがサポートされません。

次の例では、仮想マシン (VM) スケール セットによってサポートされる 1 つのノード プールを使用して、AKS クラスターを作成します。 クラスターは次のようになります。

  • Standard Load Balancer を使用します。
  • クラスターのノード プール上でクラスター オートスケーラーを有効にします。
  • 最小 1 つ、最大 3 つのノードを設定します。
# First create a resource group
az group create --name myResourceGroup --location eastus

# Now create the AKS cluster and enable the cluster autoscaler
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 クラスターの前面に配置された Load Balancer をポイントするように DNS を更新して、トラフィックをリダイレクトすることをお勧めします。

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

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

Traffic Manager を使用する AKS

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 つの移行方法は、次の手順です。

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

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

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