Azure Kubernetes Service (AKS) に移行する

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

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

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

注意

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

• Velero (Kubernetes 1.7 以降が必要)
• Azure Kube CLI 拡張機能

開始する前に

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

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

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

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

• ASP.NET アプリケーションのコンテナ化と AKS への移行。
• Java Web アプリケーションのコンテナ化と AKS への移行。

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

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

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

• 複数のノード プール、
• 可用性ゾーン、
• 認可された IP 範囲、
• クラスター オートスケーラー、
• AKS 用 Azure Policy、
• その他の新機能 (リリースされたとき)。

仮想マシン (VM) 可用性セットを利用する AKS クラスターでは、このような機能の多くがサポートされていません。

Load Balancer (Standard) と Virtual Machine Scale Sets を利用する AKS クラスターを作成する

Azure CLI

次の例では、仮想マシン スケール セットを利用し、単一ノード プールを持つ 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 \
       --generate-ssh-keys
   

Terraform

次のコードでは、Terraform を使用して、自動スケーリングを有効にし、特定のネットワーク設定を使用して、Azure にリソース グループと Kubernetes クラスターを作成します。

Note

この記事のサンプル コードは、Azure Terraform GitHub リポジトリにあります。 Terraform の現在および以前のバージョンのテスト結果を含むログ ファイルを表示できます。

Terraform を使用して Azure リソースを管理する方法を示すその他の記事とサンプル コードを参照してください

1. サンプル Terraform コードをテストして実行するディレクトリを作成し、それを現在のディレクトリにします。

2. main.tf という名前のファイルを作成し、次のコードを挿入します。

   resource "random_pet" "rg_name" {
     prefix = var.resource_group_name_prefix
   }
   
   resource "azurerm_resource_group" "rg" {
     location = var.resource_group_location
     name     = random_pet.rg_name.id
   }
   
   resource "random_string" "aks_cluster_name" {
     length  = 12
     special = false
   }
   
   resource "azurerm_kubernetes_cluster" "aks_cluster" {
     name                = random_string.aks_cluster_name.result
     location            = azurerm_resource_group.rg.location
     resource_group_name = azurerm_resource_group.rg.name
     dns_prefix          = "myakscluster"
   
     default_node_pool {
       type                = "VirtualMachineScaleSets"
       name                = "default"
       node_count          = 1
       max_count           = 3
       min_count           = 1
       vm_size             = "Standard_DS2_v2"
       enable_auto_scaling = true
       upgrade_settings {
         drain_timeout_in_minutes      = 90
         max_surge                     = "10%"
         node_soak_duration_in_minutes = 0
       }
     }
   
     network_profile {
       network_plugin    = "azure"
       load_balancer_sku = "standard"
     }
   
     identity {
       type = "SystemAssigned"
     }
   
     tags = {
       Environment = "Production"
     }
   }
   

3. outputs.tf という名前のファイルを作成し、次のコードを挿入します。

   output "resource_group_name" {
     value = azurerm_resource_group.rg.name
   }
   
   output "aks_cluster_name" {
     value = azurerm_kubernetes_cluster.aks_cluster.name
   }
   

4. providers.tf という名前のファイルを作成し、次のコードを挿入します。

   terraform {
     required_providers {
       azurerm = {
         source  = "hashicorp/azurerm"
         version = "~>3.0"
       }
       random = {
         source  = "hashicorp/random"
         version = "~>3.0"
       }
     }
   }
   
   provider "azurerm" {
     features {}
   }
   

5. variables.tf という名前のファイルを作成し、次のコードを挿入します。

   variable "resource_group_location" {
     type        = string
     default     = "eastus"
     description = "Location of the resource group."
   }
   
   variable "resource_group_name_prefix" {
     type        = string
     default     = "rg"
     description = "Prefix of the resource group name that's combined with a random ID so name is unique in your Azure subscription."
   }
   

6. Terraform を初期化します。

   terraform init を実行して、Terraform のデプロイを初期化します。 このコマンドによって、Azure リソースを管理するために必要な Azure プロバイダーがダウンロードされます。

   terraform init -upgrade
   

   重要なポイント:

   • -upgrade パラメーターは、必要なプロバイダー プラグインを、構成のバージョン制約に準拠する最新バージョンにアップグレードします。

7. Terraform 実行プランを作成します。

   terraform plan を実行して、実行プランを作成します。

   terraform plan -out main.tfplan
   

   重要なポイント:

   • terraform plan コマンドは、実行プランを作成しますが、実行はしません。 代わりに、構成ファイルに指定された構成を作成するために必要なアクションを決定します。 このパターンを使用すると、実際のリソースに変更を加える前に、実行プランが自分の想定と一致しているかどうかを確認できます。
   • 省略可能な -out パラメーターを使用すると、プランの出力ファイルを指定できます。 -out パラメーターを使用すると、レビューしたプランが適用内容とまったく同じであることが確実になります。

8. Terraform 実行プランを適用します。

   terraform apply を実行して、クラウド インフラストラクチャに実行プランを適用します。

   terraform apply main.tfplan
   

   重要なポイント:

   • terraform apply コマンドの例は、以前に terraform plan -out main.tfplan が実行されたことを前提としています。
   • -out パラメーターに別のファイル名を指定した場合は、terraform apply の呼び出しで同じファイル名を使用します。
   • -out パラメーターを使用しなかった場合は、パラメーターを指定せずに terraform apply を呼び出します。

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

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

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

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

移行中にその他の 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 クラスターのトラフィックをルーティングするには、Azure Front Door という選択肢もあります。 Azure Front Door を使用すると、高可用性のために最高クラスのパフォーマンスと即時グローバル フェールオーバーを最適化することで、Web トラフィックのグローバル ルーティングを定義、管理、監視することができます。

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

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

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

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

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

• Azure Files を使用する場合は、ファイル共有をボリュームとして新しいクラスターにマウントできます。 静的 Azure Files をボリュームとしてマウントするに関するページを参照してください。
• Azure Managed Disks を使用するときは、どの VM にも接続されていない場合にのみ、ディスクをマウントできます。 静的 Azure Disk をボリュームとしてマウントするに関するページを参照してください。
• どちらの方法も機能しない場合は、バックアップと復元のオプションを使用できます。 Azure での Veleroに関するページを参照してください。

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 クラスター間でボリュームを移行するのに役立ちます。

• Azure CLI ディスク コピー拡張機能は、リソース グループ間および Azure リージョン間でディスクをコピーおよび変換します。
• Azure Kube CLI 拡張機能は、ACS Kubernetes ボリュームを列挙し、それらを AKS クラスターに移行します。

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

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

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

kubectl get deployment -o yaml > deployments.yaml

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

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

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

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

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

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