編集

Kubernetes のノードとノード プールの管理

Azure Kubernetes Service (AKS)
Azure Virtual Machines

Kubernetes アーキテクチャは、コントロール プレーンとノード プール内の少なくとも 1 つのノードという 2 つのレイヤーが基盤となっています。 この記事では、Amazon Elastic Kubernetes Service (Amazon EKS) と Azure Kubernetes Service (AKS) における管理エージェントまたはワーカー ノードの動作について説明し、両者を比較します。

注意

この記事は、Amazon EKS に詳しいプロフェッショナルの方を対象に、AKS についてわかりやすく説明した連載記事の一部です。

Amazon EKS と AKS ではどちらも、コントロール プレーン レイヤーをクラウド プラットフォームが提供、管理し、ノード レイヤーを顧客が管理することになります。 次の図は、AKS Kubernetes アーキテクチャのコントロール プレーンとノードの関係を示しています。

AKS アーキテクチャのコントロール プレーンとノードを示す図。

Amazon EKS のマネージド ノードグループ

Amazon EKS のマネージド ノードグループは、Amazon EKS クラスターの Amazon Elastic Compute Cloud (EC2) ワーカー ノードのプロビジョニングとライフサイクル管理を自動化します。 EKS クラスターのノードは、アマゾン ウェブ サービス (AWS) のユーザーが eksctl コマンドライン ユーティリティを使用して作成、更新、終了できます。 ノードを更新、終了すると、ノードの切断とドレインが自動的に行われるので、アプリケーションは引き続き利用できます。

すべてのマネージド ノードは、Amazon EKS が運用、管理する Amazon EC2 Auto Scaling グループの一部としてプロビジョニングされます。 ポッドの障害が発生したり、他のノードにポッドが再スケジュールされたりすると、クラスター内のワーカー ノード数が Kubernetes クラスター オートスケーラーによって自動的に調整されます。 各ノード グループは、リージョン内の複数の可用性ゾーンにまたがって動作するように構成できます。

Amazon EKS マネージド ノードの詳細については、「マネージド型ノードグループの作成」および「マネージド型ノードグループの更新」を参照してください。

Kubernetes ポッドを AWS Fargate で実行することもできます。 Fargate は、オンデマンドで適切なサイズのコンピューティング容量をコンテナーに提供するものです。 Amazon EKS で Fargate を使用する方法の詳細については、「AWS Fargate」を参照してください。

AKS のノードとノード プール

AKS クラスターを作成すると自動的にコントロール プレーンが作成、構成され、主要な Kubernetes サービスとアプリケーション ワークロードのオーケストレーションが提供されます。 Azure プラットフォームでは、AKS コントロール プレーンがマネージド Azure リソースとして無償で提供されます。 コントロール プレーンとそのリソースは、クラスターを作成したリージョンにのみ存在します。

ノードは、ワークロードとアプリケーションのホストであり、"エージェント ノード" または "ワーカー ノード" とも呼ばれます。 AKS では、AKS クラスターに接続されているエージェント ノードはすべてお客様が管理し、必要な料金を支払うことになります。

アプリケーションと関連サービスを実行するためには、AKS クラスターに少なくとも 1 つのノードが必要です。Kubernetes ノードのコンポーネントとコンテナー ランタイムを実行するための Azure 仮想マシン (VM) です。 各 AKS クラスターには、少なくとも 1 つのノードを含むシステム ノード プールが、少なくとも 1 つ含まれている必要があります。

AKS は、同じ構成のノードをグループ化し、AKS のワークロードを実行する VM の "ノード プール" にまとめます。 システム ノード プールは、CoreDNS などの重要なシステム ポッドをホストするという主要な目的を果たします。 ユーザー ノード プールは、ワークロード ポッドをホストするという主要な目的を果たします。 開発環境などで、AKS クラスター内のノード プールを 1 つだけにしたい場合、システム ノード プールでアプリケーション ポッドをスケジュールできます。

1 つの Kubernetes ノードを示す図。

また、複数のユーザー ノード プールを作成して異なるノードにワークロードを分離し、うるさい隣人の問題を回避したり、コンピューティングやストレージの需要が異なるアプリケーションをサポートしたりすることもできます。

システム ノード プールとユーザー ノード プールの各エージェント ノードは、Azure Virtual Machine Scale Sets の構成要素としてプロビジョニングされた VM であり、AKS クラスターによって管理されます。 詳細については、「ノードとノード プール」を参照してください。

初期のワーカー ノード数とサイズ は、AKS クラスターを作成するとき、または既存の AKS クラスターに新しいノードやノード プールを追加するときに定義できます。 VM サイズを指定しなかった場合、Windows ノード プールの場合は Standard_D2s_v3 が、Linux ノード プールの場合は Standard_DS2_v2 が既定のサイズになります。

重要

ノード内の呼び出しやプラットフォーム サービスとの通信における待ち時間を改善するには、高速ネットワークをサポートする VM シリーズを選択してください。

ノード プールの作成

新しい AKS クラスターまたは既存の AKS クラスターにノード プールを追加するには、Azure portal、Azure CLI、AKS REST API のいずれかを使用するか、Bicep、Azure Resource Manager (ARM) テンプレート、Terraform などの Infrastructure as Code (IaC) ツールを使用します。 既存の AKS クラスターにノード プールを追加する方法の詳細については、「Azure Kubernetes Service (AKS) のクラスターで複数のノード プールを作成および管理する」を参照してください。

新しいノード プールを作成すると、関連する仮想マシン スケール セットがノード リソース グループ、つまり AKS クラスターに使用されるすべてのインフラストラクチャ リソースを含んだ Azure リソース グループに作成されます。 これらのリソースには、Kubernetes ノード、仮想ネットワーク リソース、マネージド ID、ストレージが含まれます。

既定では、ノード リソース グループには MC_<resourcegroupname>_<clustername>_<location> のような名前が付いています。 ノード リソース グループは、クラスターを削除すると AKS によって自動的に削除されるため、クラスターのライフサイクルを共有するリソースに使用を限定してください。

ノード プールの追加

以下のコード例は、Azure CLI コマンド az aks nodepool add を使用して、3 つのノードを含んだ mynodepool という名前のノード プールを、myResourceGroup リソース グループ内の myAKSCluster という既存の AKS クラスターに追加しています。

az aks nodepool add \
      --resource-group myResourceGroup \
      --cluster-name myAKSCluster \
      --node-vm-size Standard_D8ds_v4 \
      --name mynodepool \
      --node-count 3

スポット ノード プール

スポット ノード プールは、スポット仮想マシン スケール セットによってサポートされるノード プールです。 AKS クラスターのノードにスポット仮想マシンを使用すると、活用されていない Azure の容量を利用できるため、コストが大幅に削減されます。 活用されていない容量のうち利用できる容量は、ノード サイズ、リージョン、時間帯などの多くの要因によって異なります。

スポット ノード プールをデプロイすると、使用可能な容量が存在する場合、Azure ではスポット ノードが割り当てられます。 ただし、スポット ノードのための SLA は存在しません。 スポット ノード プールをサポートするスポット スケール セットは 1 つの障害ドメインにデプロイされ、高可用性の保証は提供されません。 その容量が Azure で再び必要になると、Azure インフラストラクチャによってスポット ノードが削除されますが、通知は、早くても削除の 30 秒前となります。 スポット ノード プールをクラスターの既定のノード プールにすることはできないので注意してください。 スポット ノード プールはセカンダリ プールとしてのみ使用できます。

スポット ノードは、中断、早期終了、または削除に対処できるワークロードを意図したものです。 たとえば、バッチ処理ジョブ、開発、テスト環境、サイズの大きな計算ワークロードは、スポット ノード プールにスケジュールするうってつけの候補です。 詳細については、スポット インスタンスの制限事項を参照してください。

次の az aks nodepool add コマンドは、自動スケーリングを有効にして既存のクラスターにスポット ノード プールを追加するものです。

  az aks nodepool add \
      --resource-group myResourceGroup \
      --cluster-name myAKSCluster \
      --name myspotnodepool \
      --node-vm-size Standard_D8ds_v4 \
      --priority Spot \
      --eviction-policy Delete \
      --spot-max-price -1 \
      --enable-cluster-autoscaler \
      --min-count 1 \
      --max-count 3 \
      --no-wait

スポット ノード プールの詳細については、Azure Kubernetes Service (AKS) クラスターにスポット ノード プールを追加する方法に関する記事を参照してください。

エフェメラル OS ディスク

既定では、VM を別のホストに再配置する必要がある場合にデータの損失を防ぐために、Azure によって VM のオペレーティング システム (OS) ディスクが Azure Storage に自動的にレプリケートされます。 ただし、コンテナーはローカルの状態を永続化するようには設計されていないため、OS ディスクをストレージに保持しても、AKS の価値は限定的です。 ノードのプロビジョニングが遅い、読み取り/書き込みの待ち時間が長いなどの欠点があります。

これに対し、エフェメラル OS ディスクは、一時ディスクのようにホスト コンピューターにのみ格納され、読み取り/書き込みの待ち時間が短く、ノードのスケーリングとクラスターのアップグレードも高速です。 一時ディスクと同様に、エフェメラル OS ディスクは VM の価格に含まれているため、別途ストレージ コストは発生しません。

重要

OS 用にマネージド ディスクを明示的に要求しないと、AKS は、指定されたノード プール構成で可能であれば、既定でエフェメラル OS を使います。

エフェメラル OS を使用する場合、OS ディスクは VM キャッシュに収まる必要があります。 VM キャッシュ サイズは、Azure VM のドキュメントの IO スループットの横に、GiB 単位のキャッシュ サイズとしてかっこ囲みで記載されています。

たとえば、AKS の既定である Standard_DS2_v2 VM サイズは、OS ディスクの既定サイズが 100 GB で、エフェメラル OS をサポートしますが、キャッシュ サイズは 86 GB しかありません。 明示的に指定しない場合、この構成は既定でマネージド ディスクになります。 このサイズのエフェメラル OS を明示的に要求した場合、検証エラーが返されます。

OS ディスクが 60 GB の同じ Standard_DS2_v2 VM を要求した場合、既定でエフェメラル OS になります。 要求した 60 GB の OS サイズは、最大 86 GB のキャッシュ サイズよりも小さいためです。

OS ディスクが 100 GB の Standard_D8s_v3 はエフェメラル OS をサポートし、200 GB のキャッシュ領域を備えています。 ユーザーが OS ディスクの種類を指定しなかった場合、ノード プールには既定でエフェメラル OS が適用されます。

以下の az aks nodepool add コマンドは、エフェメラル OS ディスクが使用された既存のクラスターに新しいノード プールを追加する方法を示したものです。 --node-osdisk-type パラメーターによって OS ディスクの種類が Ephemeral に設定され、--node-osdisk-size パラメーターによって OS ディスクのサイズが定義されています。

  az aks nodepool add \
      --resource-group myResourceGroup \
      --cluster-name myAKSCluster \
      --name mynewnodepool \
      --node-vm-size Standard_D8ds_v4 \
      --node-osdisk-type Ephemeral \
      --node-osdisk-size 48

エフェメラル OS ディスクの詳細については、「エフェメラル OS」を参照してください。

仮想ノード

AKS クラスターでアプリケーション ワークロードをすばやくスケーリングするには、仮想ノードを使用します。 仮想ノードを使用するとポッドの迅速なプロビジョニングが可能となり、支払いも、実行時間に相当する 1 秒あたりの料金のみとなります。 クラスター オートスケーラーによって新しいワーカー ノードがデプロイされて追加のポッド レプリカが実行されるのを待つ必要はありません。 仮想ノードは、Linux のポッドとノードでのみサポートされます。 AKS 用の仮想ノード アドオンは、オープン ソースの Virtual Kubelet プロジェクトに基づいています。

仮想ノードの機能は Azure Container Instances に依存します。 仮想ノードの詳細については、「Azure Kubernetes Service (AKS) クラスターを作成し、仮想ノードを使用できるように構成する」を参照してください。

テイント、ラベル、タグ

ノード プールを作成するとき、そのノード プールに Kubernetes のテイントとラベル、Azure のタグを追加できます。 テイント、ラベル、タグを追加すると、そのノード プール内のすべてのノードにそのテイント、ラベル、タグが追加されます。

テイントを使用してノード プールを作成するには、az aks nodepool add コマンドに --node-taints パラメーターを指定して実行してください。 ノード プール内のノードにラベルを付けるには、次のコードに示したように、--labels パラメーターを使用して一連のラベルを指定します。

  az aks nodepool add \
      --resource-group myResourceGroup \
      --cluster-name myAKSCluster \
      --name mynodepool \
      --node-vm-size Standard_NC6 \
      --node-taints sku=gpu:NoSchedule \
      --labels dept=IT costcenter=9999

詳細については、「テイント、ラベル、またはタグをノード プールに指定する」を参照してください。

予約済みのシステム ラベル

Amazon EKS は、キャパシティ タイプを指定する eks.amazonaws.com/capacityType など、マネージド ノード グループ内のすべてのノードに対し、自動化された Kubernetes ラベルを追加します。 また、エージェント ノードには、システム ラベルが AKS によって自動的に追加されます。

次のプレフィックスは、AKS が使用するために予約されており、どのノードにも使用できません。

  • kubernetes.azure.com/
  • kubernetes.io/

その他の予約済みプレフィックスについては、Kubernetes の既知のラベル、注釈、テイントに関するページを参照してください。

以下の表に記載したラベルは AKS 用に予約されており、いずれのノードにも使用できません。 表内の「仮想ノードの使用」列は、仮想ノードでラベルがサポートされているかどうかを示します。

「仮想ノードの使用」列の意味は次のとおりです。

  • 該当なしは、ホストの変更が必要となるプロパティであるために、仮想ノードには適用されないことを意味します。
  • 同じは、仮想ノード プールに想定される値が、標準的なノード プールと同じであることを意味します。
  • Virtual は VM SKU の値に置き換えてください。仮想ノードのポッドでは、基になる VM は一切公開されません。
  • "仮想ノードのバージョン" とは、仮想 Kubelet-ACI コネクタ リリースの現在のバージョンを指します。
  • 仮想ノードのサブネット名は、仮想ノードのポッドを Azure Container Instances にデプロイするサブネットです。
  • 仮想ノード仮想ネットワークは、仮想ノードのサブネットを含む仮想ネットワークです。
Label 値 例、オプション 仮想ノードの使用
kubernetes.azure.com/agentpool <agent pool name> nodepool1 同じ
kubernetes.io/arch amd64 runtime.GOARCH 該当なし
kubernetes.io/os <OS Type> Linux または Windows Linux
node.kubernetes.io/instance-type <VM size> Standard_NC6 Virtual
topology.kubernetes.io/region <Azure region> westus2 同じ
topology.kubernetes.io/zone <Azure zone> 0 同じ
kubernetes.azure.com/cluster <MC_RgName> MC_aks_myAKSCluster_westus2 同じ
kubernetes.azure.com/mode <mode> User または System User
kubernetes.azure.com/role エージェント Agent 同じ
kubernetes.azure.com/scalesetpriority <scale set priority> Spot または Regular 該当なし
kubernetes.io/hostname <hostname> aks-nodepool-00000000-vmss000000 同じ
kubernetes.azure.com/storageprofile <OS disk storage profile> Managed 該当なし
kubernetes.azure.com/storagetier <OS disk storage tier> Premium_LRS 該当なし
kubernetes.azure.com/instance-sku <SKU family> Standard_N Virtual
kubernetes.azure.com/node-image-version <VHD version> AKSUbuntu-1804-2020.03.05 仮想ノードのバージョン
kubernetes.azure.com/subnet <nodepool subnet name> subnetName 仮想ノードのサブネット名
kubernetes.azure.com/vnet <nodepool virtual network name> vnetName 仮想ノード仮想ネットワーク
kubernetes.azure.com/ppg <nodepool ppg name> ppgName 該当なし
kubernetes.azure.com/encrypted-set <nodepool encrypted-set name> encrypted-set-name 該当なし
kubernetes.azure.com/accelerator <accelerator> Nvidia 該当なし
kubernetes.azure.com/fips_enabled <fips enabled> True 該当なし
kubernetes.azure.com/os-sku <os/sku> OS SKU の作成と更新に関する記事を参照 Linux SKU

Windows ノード プール

AKS では、Azure CNI ネットワーク プラグインを通じて、Windows Server コンテナー ノード プールを作成したり使用したりできます。 必要なサブネット範囲とネットワークに関する考慮事項については、Azure CNI ネットワークの構成に関するページを参照してください。

以下の az aks nodepool add コマンドは、Windows Server コンテナーを実行するノード プールを追加するものです。

  az aks nodepool add \
      --resource-group myResourceGroup \
      --cluster-name myAKSCluster \
      --name mywindowsnodepool \
      --node-vm-size Standard_D8ds_v4 \
      --os-type Windows \
      --node-count 1

前のコマンドでは、AKS クラスター仮想ネットワーク内の既定のサブネットを使用しています。 Windows ノード プールを含む AKS クラスターを構築する方法について詳しくは、AKS に Windows Server コンテナーを作成する方法に関する記事を参照してください。

ノード プールに関する考慮事項

ノード プールおよび複数ノード プールを作成、管理する際は、次の考慮事項と制限事項があります。

  • AKS ノード プールには、クォータ、VM サイズの制限、利用可能なリージョンが適用されます。

  • システム プールには、少なくとも 1 つのノードが含まれている必要があります。 別のシステム ノード プールが AKS クラスター内にあり、それが代わりをする場合、システム ノード プールは削除できます。 ユーザー ノード プールには、0 個以上のノードを含めることができます。

  • VM を作成した後にノード プールの VM サイズを変更することはできません。

  • 複数ノード プールの場合、AKS クラスターは Standard SKU ロード バランサーを使用する必要があります。 Basic SKU ロード バランサーでは、複数ノード プールはサポートされていません。

  • すべてのクラスター ノード プールは同じ仮想ネットワーク内に存在すること、また、どのノード プールに割り当てられたサブネットもすべて同じ仮想ネットワーク内に存在することが必要です。

  • クラスターの作成時に複数ノード プールを作成する場合、すべてのノード プールの Kubernetes バージョンがコントロール プレーンのバージョンと一致している必要があります。 バージョンは、ノード プールごとの操作を使用してクラスターがプロビジョニングされた後で更新できます。

ノード プールのスケーリング

お使いのアプリケーションのワークロードの変化に伴い、ノード プール内のノード数を変更しなければならなくなる場合があります。 ノード数を手動で増減させるには、az aks nodepool scale コマンドを使用します。 次の例では、mynodepool 内のノード数を 5 にスケーリングしています。

az aks nodepool scale \
    --resource-group myResourceGroup \
    --cluster-name myAKSCluster \
    --name mynodepool \
    --node-count 5

クラスター オートスケーラーを使用してノード プールを自動的にスケーリングする

AKS では、クラスター オートスケーラーを使用してノード プールを自動的にスケーリングできます。 各ノード プールでこの機能を有効にし、ノードの最小数と最大数を定義します。

以下の az aks nodepool add コマンドは、mynodepool という新しいノード プールを既存のクラスターに追加します。 --enable-cluster-autoscaler パラメーターで新しいノード プールのクラスター オートスケーラーを有効にし、--min-count と --max-count パラメーターでプール内のノードの最小数と最大数を指定します。

  az aks nodepool add \
  --resource-group myResourceGroup \
  --cluster-name myAKSCluster \
  --name mynewnodepool \
  --node-vm-size Standard_D8ds_v4 \
  --enable-cluster-autoscaler \
  --min-count 1 \
  --max-count 5

以下の az aks nodepool update コマンドは、mynewnodepool ノード プールの最小ノード数を 1 から 3 に更新します。

  az aks nodepool update \
  --resource-group myResourceGroup \
  --cluster-name myAKSCluster \
  --name mynewnodepool \
  --update-cluster-autoscaler \
  --min-count 1 \
  --max-count 3

クラスター オートスケーラーを無効にするには、az aks nodepool update に --disable-cluster-autoscaler パラメーターを渡します。

  az aks nodepool update \
  --resource-group myResourceGroup \
  --cluster-name myAKSCluster \
  --name mynodepool \
  --disable-cluster-autoscaler

既存のクラスターのクラスター オートスケーラーを再度有効にするには、az aks nodepool update に --enable-cluster-autoscaler、--min-count、--max-count パラメーターを指定して実行します。

個々のノード プールについてクラスター オートスケーラーを使用する方法について詳しくは、「Azure Kubernetes Service (AKS) でのアプリケーションの需要を満たすようにクラスターを自動的にスケーリング」を参照してください。

更新とアップグレード

Azure の VM ホスティング プラットフォームは、信頼性、パフォーマンス、セキュリティを改善するために定期的に更新されます。 ホスティング環境のソフトウェア コンポーネントの修正から、ネットワーク コンポーネントのアップグレード、ハードウェアの使用停止まで、更新は広い範囲に及びます。 Azure における VM の更新方法について詳しくは、「Azure での仮想マシンのメンテナンス」を参照してください。

通常、VM ホスティング インフラストラクチャが更新されても、ホストされている VM、たとえば既存の AKS クラスターのエージェント ノードに影響はありません。 ホストされている VM に影響する更新については、再起動を必要とするケースが最小限で済むよう、ホストの更新中は VM が一時停止されるか、既に更新済みのホストに VM がライブ移行されます。

更新に再起動が伴う場合は、都合のよいときに更新を開始できるよう、Azure から通知と時間帯が提供されます。 ホスト マシンのセルフ メンテナンス期間は、緊急の更新でない限り、通常は 35 日間です。

計画メンテナンスを使用して VM を更新したり、計画メンテナンスの通知を管理したりするには、Azure CLI、PowerShell、Azure portal のいずれかを使用します。 計画メンテナンスでは、クラスターの自動アップグレードを使用しているかどうかが検出され、メンテナンス期間中にアップグレードが自動的にスケジュールされます。 計画メンテナンスについて詳しくは、「az aks maintenanceconfiguration」コマンドおよび「計画メンテナンスを使用して Azure Kubernetes Service (AKS) クラスターのメンテナンス期間をスケジュールする」を参照してください。

Kubernetes のアップグレード

AKS クラスター ライフサイクルには、最新の Kubernetes バージョンへの定期的なアップグレードが含まれます。 最新のセキュリティ リリースと機能を入手するには、アップグレードを適用することが重要です。 既存のノード プール VM の Kubernetes バージョンをアップグレードするには、ノードの切断とドレインを行い、それらを更新された Kubernetes ディスク イメージに基づく新しいノードに置き換える必要があります。

AKS は、既定で、1 つの追加ノードを使用してサージ操作するようにアップグレードを構成します。 max-surge 設定の既定値である 1 は、ワークロードの中断を最小限に抑えるために、別途ノードを作成し、それより古いバージョンのノードを置き換えたうえで、既存のアプリケーションの切断またはドレインを行います。 ノード プールごとに max-surge 値をカスタマイズすることで、アップグレード速度とアップグレード中断のトレードオフを考慮することができます。 max-surge 値を大きくすることでアップグレード プロセスはより速く完了しますが、max-surge に大きな値を設定するとアップグレード プロセス中に中断が発生する可能性があります。

たとえば、max-surge 値が 100% の場合、ノード数が 2 倍になり、可能な限り最速のアップグレード プロセスが提供されますが、ノード プール内のすべてのノードが同時にドレインされます。 このように高い値はテスト用途では問題ありませんが、運用ノード プールの場合は、max-surge の設定を 33% にした方がいいでしょう。

max-surge の値には、整数とパーセンテージのどちらでも使用できます。 たとえば、整数 5 は、サージする 5 つの追加ノードを示します。 max-surge のパーセント値は、最小値 1% と最大値 100% で、最も近いノード数に切り上げられます。 値 50% は、プール内の現在のノード数の半分のサージ値を示します。

アップグレード中、max-surge 値には、最小値を 1 とし、最大値をノード プール内のノード数とする値を指定することができます。 より大きな値を設定することもできますが、max-surge に使用されるノードの最大数は、プール内のノードの数を超えることはありません。

重要

アップグレード操作の場合、ノードのサージには、要求した max-surge カウントを満たせるだけのサブスクリプション クォータが必要です。 たとえば、クラスターに 5 つのノード プールがあり、そのそれぞれに 4 つのノードが含まれる場合、合計で 20 個のノードがあります。 各ノード プールの max-surge 値が 50% の場合、アップグレードを完了するには、別途 10 ノード (2 ノード × 5 プール) のコンピューティングおよび IP クォータが必要です。

Azure Container Networking Interface (CNI) を使用する場合は、AKS の CNI 要件を満たすのに十分な IP がサブネット内にあることを確認してください。

ノード プールのアップグレード

使用可能なアップグレードを確認するには、az aks get-upgrades を使用します。

az aks get-upgrades --resource-group <myResourceGroup> --name <myAKSCluster>

ノード プールの状態を確認するには、az aks nodepool list を使用します。

  az aks nodepool list -g <myResourceGroup> --cluster-name <myAKSCluster>

次のコマンドでは、az aks nodepool upgrade を使用して単一ノード プールをアップグレードします。

  az aks nodepool upgrade \
      --resource-group <myResourceGroup> \
      --cluster-name <myAKSCluster> \
      --name <mynodepool> \
      --kubernetes-version <KUBERNETES_VERSION>

クラスターのコントロール プレーンとノード プールを対象に Kubernetes バージョンをアップグレードする方法について詳しくは、次の記事を参照してください。

アップグレードの考慮事項

AKS クラスターの Kubernetes バージョンをアップグレードする際は、これらのベスト プラクティスと考慮事項に注意してください。

  • AKS クラスター内のノード プールは、すべて同じ Kubernetes のバージョンにアップグレードするのがベストです。 az aks upgrade の既定の動作では、すべてのノード プールとコントロール プレーンがアップグレードされます。

  • クラスターを手動でアップグレードするか、クラスターに自動アップグレード チャネルを設定します。 計画メンテナンスを使用して VM にパッチを適用している場合、指定したメンテナンス期間中も自動アップグレードが開始されます。 詳細については、「Azure Kubernetes Service (AKS) クラスターのアップグレード」をご覧ください。

  • az aks upgrade コマンドに --control-plane-only フラグを指定した場合、アップグレードされるのはクラスターのコントロール プレーンのみで、クラスター内の関連付けられているノード プールは一切変更されません。 個々のノード プールをアップグレードするには、az aks nodepool upgrade コマンドでターゲット ノード プールと Kubernetes バージョンを指定してください。

  • AKS クラスターのアップグレードで、ノードの切断とドレインがトリガーされます。 使用可能なコンピューティング クォータが少ない場合は、アップグレードが失敗する可能性があります。 クォータの引き上げの詳細については、「リージョンの vCPU クォータの増加」を参照してください。

  • max-surge パラメーターは、整数またはパーセンテージを使用して、必要に応じた値を構成します。 運用環境のノード プールの場合は、max-surge の設定に 33% を使用します。 詳細については、「ノード サージ アップグレードのカスタマイズ」を参照してください。

  • CNI ネットワークを使用する AKS クラスターをアップグレードする場合、max-surge 設定によって別途作成されるノード用の空きプライベート IP アドレスがサブネットにあることを確認してください。 詳細については、「Azure Kubernetes サービス (AKS) で Azure CNI ネットワークを構成する」を参照してください。

  • クラスター ノード プールがリージョン内の複数の可用性ゾーンにまたがる場合、アップグレード プロセスによって一時的にゾーン構成が不均衡になる可能性があります。 詳細については、「複数の Availability Zones にまたがるノード プールに関する特別な考慮事項」を参照してください。

ノードの仮想ネットワーク

新しいクラスターを作成したり、既存のクラスターに新しいノード プールを追加したりするときは、そのクラスターの仮想ネットワーク内にあるサブネットのリソース ID を指定し、そこにエージェント ノードをデプロイすることになります。 ワークロードでは、クラスターのノードを論理的に分離するために個別のノード プールに分割することが必要になる場合があります。 この分離は、別々のサブネットを用意し、それぞれを個々のノード プール専用にすることで実現できます。 ノード プールの VM にはそれぞれ、関連付けられているサブネットからプライベート IP アドレスが割り当てられます。

AKS では、次の 2 つのネットワーク プラグインがサポートされています。

  • Kubenet は、Linux 用の基本的でシンプルなネットワーク プラグインです。 kubenet を使用すると、ノードには Azure 仮想ネットワーク サブネットからプライベート IP アドレスが割り当てられます。 ポッドの IP アドレスは、論理的に異なるアドレス空間から取得されます。 送信元トラフィックの IP アドレスがネットワーク アドレス変換 (NAT) を介してノードのプライマリ IP アドレスに変換されることで、ポッドは Azure 仮想ネットワーク上のリソースに到達することができます。 この方法では、ポッドで使用するためにネットワーク空間で予約する必要がある IP アドレスの数が減ります。

  • Azure Container Networking Interface (CNI) は、直接呼び出してアクセスするための IP アドレスを各ポッドに提供します。 これらの IP アドレスは、ネットワーク空間全体で一意である必要があります。 各ノードには、サポートされるポッドの最大数に対する構成パラメーターがあります。 ノードごとにそれと同じ数の IP アドレスが、そのノードに対して予約されます。 この方法では詳細な計画が必要であり、IP アドレスが不足するか、アプリケーション需要の拡大に伴い、より大きなサブネットでのクラスターの再構築が必要になります。

    新しいクラスターを作成するか、Azure CNI を使用するクラスターに新しいノード プールを追加する場合は、ノード用とポッド用の 2 つの独立したサブネットのリソース ID を指定できます。 詳細については、「動的 IP 割り当てと拡張サブネット サポート」を参照してください。

動的 IP 割り当て

Azure CNI を使用するポッドには、それをホストするノード プールのサブネットからプライベート IP アドレスが割り当てられます。 Azure CNI の動的 IP 割り当ては、ノード プールがホストしているサブネットとは別のサブネットからのプライベート IP アドレスをポッドに割り当てる機能です。 この機能には次のような利点があります。

  • ポッドには、そのサブネットから動的に IP が割り当てられます。 すべてのノードで IP が静的に割り当てられる従来の CNI ソリューションと比べて、動的割り当ての方が IP の使用効率が高くなります。

  • ノードとポッドのサブネットを別々にスケーリングして共有できます。 同じ仮想ネットワークにデプロイされた複数のノード プールまたはクラスターで 1 つのポッド サブネットを共有できます。 ノード プール用に個別のポッド サブネットを構成することもできます。

  • ポッドには仮想ネットワークのプライベート IP が割り当てられるため、その仮想ネットワーク内にある他のクラスターのポッドやリソースに直接接続することができます。 この機能は、きわめて大規模なクラスターに対して、より良いパフォーマンスをサポートします。

  • サブネットがポッドごとに異なる場合は、ノードのポリシーとは異なる仮想ネットワーク ポリシーをポッドに対して構成できます。 ポリシーを分けることで、ノードではなくポッドに対してのみインターネット接続を許可したり、NAT Gateway を使用してノード プール内のポッドのソース IP を修正したり、ネットワーク セキュリティ グループ (NSG) を使用してノード プール間のトラフィックをフィルター処理したりと、さまざまな方法で便利なシナリオを実現できます。

  • Network Policy と Calico Kubernetes ネットワーク ポリシーはどちらも、動的 IP 割り当てに対応しています。

共同作成者

この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。

プリンシパルの作成者:

その他の共同作成者:

  • Laura Nicolas | シニア ソフトウェア エンジニア
  • Chad Kittel | プリンシパル ソフトウェア エンジニア
  • Ed Price | シニア コンテンツ プログラム マネージャー
  • Theano Petersen | テクニカル ライター

パブリックでない LinkedIn プロファイルを表示するには、LinkedIn にサインインします。

次のステップ