Azure Kubernetes Service (AKS) に移行する

[アーティクル]
11/01/2024

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 を使用できます。

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

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

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

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

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

Azure CLI
Terraform

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

az group create コマンドを使用して、リソースグループを作成します。
```
az group create --name myResourceGroup --location eastus
```

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 を使用して、自動スケーリングを有効にし、特定のネットワーク設定を使用して、Azure にリソースグループと Kubernetes クラスターを作成します。

Note

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

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

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

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"
  }
}

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

output "resource_group_name" {
  value = azurerm_resource_group.rg.name
}

output "aks_cluster_name" {
  value = azurerm_kubernetes_cluster.aks_cluster.name
}

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

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

provider "azurerm" {
  features {}
}

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."
}

Terraform を初期化します。

terraform init を実行して、Terraform のデプロイを初期化します。このコマンドによって、Azure リソースを管理するために必要な Azure プロバイダーがダウンロードされます。
```
terraform init -upgrade
```
重要なポイント:
- -upgrade パラメーターは、必要なプロバイダープラグインを、構成のバージョン制約に準拠する最新バージョンにアップグレードします。
Terraform 実行プランを作成します。

terraform plan を実行して、実行プランを作成します。
```
terraform plan -out main.tfplan
```
重要なポイント:
- terraform plan コマンドは、実行プランを作成しますが、実行はしません。代わりに、構成ファイルに指定された構成を作成するために必要なアクションを決定します。このパターンを使用すると、実際のリソースに変更を加える前に、実行プランが自分の想定と一致しているかどうかを確認できます。
- 省略可能な -out パラメーターを使用すると、プランの出力ファイルを指定できます。 -out パラメーターを使用すると、レビューしたプランが適用内容とまったく同じであることが確実になります。
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 エンドポイントから別のリージョンのエンドポイントにネットワークトラフィックを送信します。

Traffic Manager を使用する AKS

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

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

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

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

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

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

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

Azure Files

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

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

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

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

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

永続ボリュームの移行

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

アプリケーションの書き込みを停止します。
- この手順は省略可能であり、ダウンタイムが必要になります。
ディスクのスナップショットを作成します。
スナップショットから新しいマネージドディスクを作成します。
AKS に永続ボリュームを作成します。
PersistentVolumeClaims (静的プロビジョニング) ではなく既存のボリュームを使用するようにポッドの指定を更新します。
アプリケーションを AKS にデプロイします。
アプリケーションが正常に動作していることを確認します。
ライブトラフィックを新しい 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 サービス
有効なクォータの確保
高可用性とビジネス継続性
ステートレスアプリケーションに関する考慮事項
ステートフルアプリケーションに関する考慮事項
クラスター構成のデプロイ

次の方法で共有

Azure Kubernetes Service (AKS) に移行する

開始する前に

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

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

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

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

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

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

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

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

Azure Files

永続ボリュームの移行

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

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

その他のリソース

次の方法で共有

Azure Kubernetes Service (AKS) に移行する

開始する前に

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

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

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

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

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

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

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

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

Azure Files

永続ボリュームの移行

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

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

その他のリソース

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

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