AKS 自動クラスターとマネージド システム ノード プールの移行

適用対象: ✔️ AKS 自動 ✔️ AKS Standard

この記事では、サポートされている マネージド システム ノード プール と AKS Standard 構成の間で AKS 自動クラスターを移行する方法について説明します。

サポートされる移行パス

マネージド システム ノード プールを使用することで、AKS はシステム ノード プールとシステム コンポーネントを自動的にプロビジョニング、スケーリング、アップグレードし、ワークロードから分離します。 AKS 自動クラスターは、ポッドの準備 SLA とアップタイム SLAによっても保証されています。 詳細については、「 マネージド システム ノード プールを使用した AKS 自動クラスターの概要」を参照してください。

マネージド システム ノード プールを含む AKS 自動クラスターから AKS Standard クラスターに移行する

移行のしくみ

マネージド システム ノード プールを含む AKS 自動クラスターは、AKS が自動的にプロビジョニング、スケーリング、アップグレードするシステム ノード プールでシステム コンポーネントを実行します。

AKS Automatic から AKS Standard に移行するには、次の大まかな手順を実行します。

1. 自己管理システム ノード プールを AKS 自動クラスターに追加します。
2. クラスター SKU を automatic から base に更新します。

SKU を更新すると、クラスターは AKS Standard クラスターとして実行され、追加して管理したシステム ノード プールでシステム コンポーネントが実行されます。

AKS Standard クラスターへの移行

1. az aks nodepool add コマンドを使用して、既存の AKS 自動クラスターに自己管理システム ノード プールを追加します。 移行後にシステム コンポーネントを実行できるように、ノード プール モードを System に設定します。

   az aks nodepool add \
       --resource-group "${RESOURCE_GROUP}" \
       --cluster-name "${RESOURCE_NAME}" \
       --name systempool \
       --mode System \
       --node-count 3
   

2. automatic コマンドを使用して、クラスター SKU を base から az aks update に更新します。

   az aks update \
       --resource-group "${RESOURCE_GROUP}" \
       --name "${RESOURCE_NAME}" \
       --sku base
   

移行を検証する

1. base コマンドを使用して、クラスターで az aks show SKU が使用されていることを確認します。

   az aks show \
       --resource-group "${RESOURCE_GROUP}" \
       --name "${RESOURCE_NAME}" \
       --query "sku" \
       --output table
   

2. System コマンドを使用して、クラスター上のノード プールを一覧表示して、セルフマネージド システム ノード プールが存在し、az aks nodepool list モードであることを確認します。

   az aks nodepool list \
       --resource-group "${RESOURCE_GROUP}" \
       --cluster-name "${RESOURCE_NAME}" \
       --query "[].{Name:name, Mode:mode, Count:count}" \
       --output table
   

マネージド システム ノード プールのない AKS 自動クラスターから、マネージド システム ノード プールを使用して AKS Automatic に移行する (プレビュー)

AKS 自動では、非管理対象システム ノード プールから、マネージド システム ノード プールが一般公開されているリージョンのマネージド システム ノード プールへのプレビュー移行がサポートされます。 この移行により、クラスターは automatic SKU に保持され、AKS システム コンポーネントは AKS によって管理されるシステム ノード プールに移動されます。

Prerequisites

• マネージド システム ノード プールのない既存の AKS 自動クラスター。
• Azure CLI バージョン 2.86.0 以降。 バージョンを見つけるには、 az --versionを実行します。 インストールまたはアップグレードが必要な場合は、Azure CLI のインストールを参照してください。
• 最新バージョンの aks-preview Azure CLI 拡張機能。
• サブスクリプションに登録されている Microsoft.ContainerService/NonHoboToHoboConversionPreview 機能フラグ。

NonHoboToHoboConversionPreview コマンドを使用して、az feature register機能フラグを登録します。

az feature register \
    --namespace Microsoft.ContainerService \
    --name NonHoboToHoboConversionPreview

az feature show コマンドを使用して、登録の状態を確認します。

az feature show \
    --namespace Microsoft.ContainerService \
    --name NonHoboToHoboConversionPreview \
    --query properties.state \
    --output tsv

続行する前に、コマンドが Registered を返すまで待ちます。 次に、 Microsoft.ContainerService リソース プロバイダーの登録を更新します。

az provider register --namespace Microsoft.ContainerService

aks-preview拡張機能をインストールまたは更新します。

az extension add --name aks-preview
az extension update --name aks-preview

AKS で管理される仮想ネットワーク クラスターを移行する

AKS マネージド ネットワークを使用する AKS 自動クラスターの場合は、--enable-hosted-system パラメーターを指定して az aks update コマンドを使用して、マネージド システム ノード プールに移行します。

az aks update \
    --resource-group "${RESOURCE_GROUP}" \
    --name "${RESOURCE_NAME}" \
    --enable-hosted-system

カスタム仮想ネットワーク クラスターを移行する

カスタム仮想ネットワークを使用する AKS 自動クラスターの場合は、 --system-node-subnet-id パラメーターを使用してマネージド システム ノード プールのサブネットを指定します。 システム ノード サブネットは次の手順を実行する必要があります。

• クラスターと同じ仮想ネットワークとリージョンに存在する。
• 少なくとも /26。
• 別のサービスに委任されません。
• ノード サブネットとは異なります。

--node-subnet-id パラメーターは省略可能です。 指定しない場合、AKS は既存のシステム ノード プール サブネットを使用します。

az aks update \
    --resource-group "${RESOURCE_GROUP}" \
    --name "${RESOURCE_NAME}" \
    --enable-hosted-system \
    --system-node-subnet-id "${SYSTEM_NODE_SUBNET_ID}" \
    --node-subnet-id "${NODE_SUBNET_ID}"

移行を検証する

az aks show コマンドを使用して、クラスターでマネージド システム ノード プールが使用されたことを確認します。

az aks show \
    --resource-group "${RESOURCE_GROUP}" \
    --name "${RESOURCE_NAME}" \
    --query hostedSystemProfile \
    --output json

次の出力例は、trueに設定された hostedSystemProfile.enabled プロパティを示しています。

{
  "enabled": true,
  "nodeSubnetId": "<node-subnet-resource-id>",
  "systemNodeSubnetId": "<system-node-subnet-resource-id>"
}

AKS Standard クラスターから、マネージド システム ノード プールを使用する AKS Automatic クラスターに移行する (プレビュー)

AKS では、AKS Standard (base SKU) クラスターから、マネージド システム ノード プールが一般公開されているリージョンのマネージド システム ノード プールを使用する AKS Automatic クラスターへのプレビュー移行がサポートされています。

移行するには、最初に AKS 自動構成に一致するように AKS Standard クラスターを構成してから、クラスター SKU を更新します。 ほとんどの作業は、クラスターを準備することです。 いくつかの設定は最初に構成されている他の設定に依存するため、次のセクションを順番に完了してください。

始める前の準備

• 既存の AKS Standard (base SKU) クラスター。 一般的な AKS 自動要件と制限事項については、「クイック スタート: Azure Kubernetes Service (AKS)自動クラスターの作成」および「マネージド システム ノード プールを使用した AKS 自動クラスターの概要」を参照してください。
• Azure CLI バージョン 2.86.0 以降と、aks-preview 拡張機能の最新バージョン。
• サブスクリプションに登録されている Microsoft.ContainerService/NonHoboToHoboConversionPreview 機能フラグ。 機能フラグを登録して拡張機能をインストールするには、「前提条件」の手順に従います。

クラスターの環境変数を設定してください:

export RESOURCE_GROUP="<resource-group>"
export RESOURCE_NAME="<cluster-name>"
export NODE_RESOURCE_GROUP=$(az aks show --resource-group "${RESOURCE_GROUP}" --name "${RESOURCE_NAME}" --query nodeResourceGroup --output tsv)

移行要件

SKU を更新する前に、クラスターが次の要件を満たしている必要があります。 一部の要件は、クラスターで AKS マネージド仮想ネットワークを使用するか、カスタム仮想ネットワークを使用するかによって異なります。 これらの設定は、Azure ポータル、Azure CLI、ARM テンプレート、またはその他のツールを使用して構成できます。 この記事の残りの部分では、Azure CLI の手順を、適用する順序で説明します。

移行を計画する

1. クラスターで AKS で管理される仮想ネットワークとカスタム仮想ネットワークのどちらを使用するかを決定します。 次のコマンドが仮想ネットワーク名を返す場合、クラスターは AKS で管理される仮想ネットワークを使用します。 何も返されない場合、クラスターはカスタム仮想ネットワークを使用します。

   az network vnet list --resource-group "${NODE_RESOURCE_GROUP}" --query "[].name" --output tsv
   

   この記事のいくつかの手順は、仮想ネットワークの種類によって異なります。

2. クラスターの現在のネットワーク プラグイン、アウトバウンドの種類、ロード バランサー SKU、ノード リソース グループの制限レベルを確認します。

   az aks show \
       --resource-group "${RESOURCE_GROUP}" \
       --name "${RESOURCE_NAME}" \
       --query "{networkPlugin:networkProfile.networkPlugin, networkPluginMode:networkProfile.networkPluginMode, outboundType:networkProfile.outboundType, loadBalancerSku:networkProfile.loadBalancerSku, nrgRestrictionLevel:nodeResourceGroupProfile.restrictionLevel}" \
       --output table
   

   • ネットワーク プラグイン: overlay で、プラグイン モードは azure である必要があります。 クラスターでオーバーレイなしで kubenet または Azure CNI を使用している場合は、続行する前に Azure CNI Overlay に更新してください。 詳細については、「IPAM モードを Azure CNI Overlay に更新する」を参照してください。
   • ロード バランサー SKU: standardである必要があります。 クラスターで引き続き basicを使用している場合は、az aks update --load-balancer-sku standard に更新します。
   • ノード リソース グループの制限レベル: AKS で管理される仮想ネットワークの場合は、ノード リソース グループにサブネットを作成する必要があります。 制限レベルが ReadOnly の場合は、続行する前に Unrestricted に設定してください。 後の手順でもう一度固定します。

3. 実行中のワークロードまたはアクセスを中断する変更を確認し、メンテナンス期間を計画します。

   • 送信の種類を変更すると、クラスターのエグレス IP アドレスが変更されます。 クラスターからのトラフィックを許可するファイアウォール規則を更新します。
   • API Server VNet 統合を有効にすると、API サーバーの IP アドレスが変更され、クラスターの再起動が必要になります。 この変更は恒久的なものです。
   • ネットワーク データプレーン、OS SKU、SSH アクセス設定を変更すると、ノードが再イメージ化されます。
   • ローカル アカウントを無効にすると、静的 kubeconfig 資格情報が削除されます。 無効にする前に、Microsoft Entra ID と Azure RBAC ロール経由でアクセス権があること (たとえば Azure Kubernetes Service RBAC Cluster Admin) を確認してください。
   • この移行により、ベースラインポッドセキュリティ標準を使用して Enforce モードでデプロイセーフガードが有効になります。 準拠していないデプロイは拒否されます。 名前空間は除外できますが、クラスター全体のレベルを Warnに切り替えることはできません。 移行する前にワークロードを確認してください。 詳細については、「展開セーフガードの使用」を参照してください。

クラスター ネットワークを準備する

1. 送信の種類: AKS で管理される仮想ネットワークの場合、送信の種類はマネージド NAT ゲートウェイである必要があります。 loadBalancer送信方向の種類はサポートされていません。 必要に応じて、送信タイプを更新してください。

   az aks update \
       --resource-group "${RESOURCE_GROUP}" \
       --name "${RESOURCE_NAME}" \
       --outbound-type managedNATGateway \
       --outbound-type-sku StandardV2
   

   カスタム仮想ネットワークの場合、任意のアウトバウンドの種類がサポートされており、変更は必要ありません。 詳細については、「 クラスターの作成後に outboundType を更新する」を参照してください。

2. クラスター ID: AKS で管理される仮想ネットワークの場合は、クラスターのシステム割り当てマネージド ID を保持します。 カスタム仮想ネットワークの場合、クラスターでは、仮想ネットワークの Network Contributor ロールを持つユーザー割り当てマネージド ID を使用する必要があります。 必要に応じて、識別情報を割り当てます。

   az aks update \
       --resource-group "${RESOURCE_GROUP}" \
       --name "${RESOURCE_NAME}" \
       --enable-managed-identity \
       --assign-identity "${IDENTITY_RESOURCE_ID}" \
       --yes
   

   IDENTITY_RESOURCE_IDを、ユーザー割り当てマネージド ID のリソース ID に置き換えます。 詳細については、「ユーザー割り当てマネージド ID の使用」を参照してください。

3. API サーバー サブネット: ノードと同じ仮想ネットワーク内に API サーバー用の専用サブネットを作成します。 サブネットは、ノード サブネットとは別で、少なくとも /28であり、Microsoft.ContainerService/managedClustersに委任されている必要があります。

   AKS で管理される仮想ネットワークの場合は、ノード リソース グループ内の仮想ネットワークにサブネットを作成してください。

   export VNET_NAME=$(az network vnet list --resource-group "${NODE_RESOURCE_GROUP}" --query "[0].name" --output tsv)
   
   export APISERVER_SUBNET_ID=$(az network vnet subnet create \
       --resource-group "${NODE_RESOURCE_GROUP}" \
       --vnet-name "${VNET_NAME}" \
       --name apiserver-subnet \
       --address-prefixes "<unused-address-range>" \
       --delegations Microsoft.ContainerService/managedClusters \
       --query id --output tsv)
   

   カスタム仮想ネットワークの場合は、代わりに独自の仮想ネットワークにサブネットを作成し、APISERVER_SUBNET_ID にそのリソース ID を設定します。

4. API Server VNet 統合: 作成したサブネットとの API Server VNet 統合を有効にし、クラスターを再起動します。

   az aks update \
       --resource-group "${RESOURCE_GROUP}" \
       --name "${RESOURCE_NAME}" \
       --enable-apiserver-vnet-integration \
       --apiserver-subnet-id "${APISERVER_SUBNET_ID}"
   
   az aks stop --resource-group "${RESOURCE_GROUP}" --name "${RESOURCE_NAME}"
   az aks start --resource-group "${RESOURCE_GROUP}" --name "${RESOURCE_NAME}"
   

   詳細については、「既存の AKS Standard クラスターを API Server VNet 統合に変換する」を参照してください。

5. ネットワーク データプレーン: ネットワーク データプレーンを Cilium に更新します。 このコマンドでは、ネットワーク ポリシーも Cilium に設定されます。

   az aks update \
       --resource-group "${RESOURCE_GROUP}" \
       --name "${RESOURCE_NAME}" \
       --network-dataplane cilium
   

   詳細については、「Azure CNI Powered by Cilium」を参照してください。

システム ノード プールとノード プロビジョニングを準備する

1. エフェメラル OS ディスク: システム ノード プールでは、エフェメラル OS ディスクを使用する必要があります。 現在の OS ディスクの種類を確認します。

   az aks nodepool list \
       --resource-group "${RESOURCE_GROUP}" \
       --cluster-name "${RESOURCE_NAME}" \
       --query "[?mode=='System'].{name:name, osDiskType:osDiskType}" \
       --output table
   

   既存のノード プールの OS ディスクの種類を変更することはできません。 システム ノード プールでManaged OS ディスクが使用されている場合は、--mode System --node-osdisk-type Ephemeral --os-sku AzureLinux --ssh-access disabledし、システム ワークロードをそれに移動してから、古いノード プールを削除します。 その後、次の手順をスキップできます。

2. OS SKU と SSH アクセス: Azure Linux を使用するようにシステム ノード プールを更新し、SSH アクセスを無効にします。

   az aks nodepool update \
       --resource-group "${RESOURCE_GROUP}" \
       --cluster-name "${RESOURCE_NAME}" \
       --name "<system-node-pool-name>" \
       --os-sku AzureLinux \
       --ssh-access disabled \
       --yes
   

   このコマンドは、ノード プールを再イメージ化します。 ノード プールに他の変更を加える前に、完了するまで待ちます。 詳細については、「Azure Linux コンテナー ホストの使用」および「AKS クラスター ノードでの SSH アクセスの管理」を参照してください。

3. ノード プロビジョニング モード: 自動ノード プロビジョニング モードを有効にします。

   az aks update \
       --resource-group "${RESOURCE_GROUP}" \
       --name "${RESOURCE_NAME}" \
       --node-provisioning-mode Auto
   

   自動モードを有効にした後は、最初にすべての自動プロビジョニングされたノードを削除しないと、手動モードに戻すことはできません。 詳細については、「ノードの自動プロビジョニング」を参照してください。

必要な機能とアドオンを有効にする

1. クラスター層を Standard に更新し、Azure Policy および Azure Key Vault シークレット プロバイダー アドオンを有効にし、シークレット ローテーションを有効にします。

   az aks update --resource-group "${RESOURCE_GROUP}" --name "${RESOURCE_NAME}" --tier standard
   
   az aks enable-addons \
       --resource-group "${RESOURCE_GROUP}" \
       --name "${RESOURCE_NAME}" \
       --addons azure-policy,azure-keyvault-secrets-provider \
       --enable-secret-rotation
   

2. 残りの必要な機能を有効にする：

   az aks update \
       --resource-group "${RESOURCE_GROUP}" \
       --name "${RESOURCE_NAME}" \
       --auto-upgrade-channel stable \
       --node-os-upgrade-channel NodeImage \
       --enable-workload-identity \
       --enable-oidc-issuer \
       --enable-aad \
       --enable-azure-rbac \
       --disable-local-accounts \
       --enable-image-cleaner \
       --enable-vpa \
       --enable-keda \
       --yes
   

ノード リソース グループをロックダウンする

ノード リソース グループの制限レベルを ReadOnlyに設定します。 前に作成した API サーバー サブネットを含め、ノード リソース グループ内のリソースに対する変更がロックダウンによってブロックされるため、この手順を最後に実行します。

az aks update \
    --resource-group "${RESOURCE_GROUP}" \
    --name "${RESOURCE_NAME}" \
    --nrg-lockdown-restriction-level ReadOnly

詳細については、「ノード リソース グループのロックダウン」を参照してください。

クラスターを AKS Automatic に移行する

要件がまだ満たされていない場合、移行コマンドは失敗し、検出された満たされていない要件が一覧表示されます。 一部のチェックは、以前のチェックが成功した後にのみ実行されるため、一覧の項目に対処し、成功するまでコマンドをもう一度実行してください。

AKS で管理される仮想ネットワーク

az aks update \
    --resource-group "${RESOURCE_GROUP}" \
    --name "${RESOURCE_NAME}" \
    --sku automatic \
    --enable-hosted-system

カスタム仮想ネットワーク

--system-node-subnet-id パラメーターを使用して、マネージド システム ノード プールのサブネットを指定してください。 サブネットの要件については、「 既存の AKS 自動クラスターをマネージド システム ノード プールに移行する」を参照してください。 --node-subnet-id パラメーターは省略可能です。 指定しない場合、AKS は既存のシステム ノード プール サブネットを使用します。

az aks update \
    --resource-group "${RESOURCE_GROUP}" \
    --name "${RESOURCE_NAME}" \
    --sku automatic \
    --enable-hosted-system \
    --system-node-subnet-id "${SYSTEM_NODE_SUBNET_ID}" \
    --node-subnet-id "${NODE_SUBNET_ID}"

移行を検証する

1. クラスターで automatic SKU と Standard レベルが使用されていること、および更新が正常に完了したことを確認します。

   az aks show \
       --resource-group "${RESOURCE_GROUP}" \
       --name "${RESOURCE_NAME}" \
       --query "{sku:sku, provisioningState:provisioningState}" \
       --output json
   

   sku.nameがAutomatic、sku.tierがStandard、provisioningStateがSucceededされていることを確認します。

2. クラスターでマネージド システム ノード プールを使用していることを確認します。

   az aks show \
       --resource-group "${RESOURCE_GROUP}" \
       --name "${RESOURCE_NAME}" \
       --query hostedSystemProfile \
       --output json
   

   hostedSystemProfile.enabledがtrueされていることを確認します。 カスタム仮想ネットワークの場合は、systemNodeSubnetId と nodeSubnetId にサブネット リソース ID が表示されます。 AKS で管理される仮想ネットワークの場合、これらの値は null です。

3. クラスターの認証情報を取得し、すべてのノードがReadyであることを確認します。

   az aks get-credentials --resource-group "${RESOURCE_GROUP}" --name "${RESOURCE_NAME}"
   kubectl get nodes -o wide
   

障害時の動作

移行でマネージド システム プール インフラストラクチャをプロビジョニングできない場合 (たとえば、リージョンの容量の制約のため)、AKS は既存のシステム ノード プールとユーザー ノード プールを移行前の状態で保持します。