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

Azure Kubernetes Service (AKS)

Azure Virtual Machines

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

Note

この記事は、Amazon EKS に詳しいプロフェッショナルの方が Azure Kubernetes Service (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」を参照してください。

Karpenter

Karpenter は、Kubernetes クラスター内のノードライフサイクル管理を強化するために設計されたオープンソースプロジェクトです。ポッドの特定のスケジューリングニーズに基づいてノードのプロビジョニングとプロビジョニング解除が自動化され、効率的なスケーリングとコストの最適化が可能になります。主な機能は次のとおりです。

リソースの制約により Kubernetes スケジューラがスケジュールできないポッドを監視します。
スケジュールできないポッドのスケジュール要件 (リソース要求、ノードセレクター、アフィニティ、容認など) を評価します。
これらのポッドの要件を満たす新しいノードをプロビジョニングします。
不要になったノードを削除します。

Karpenter では、テイント、ラベル、要件 (インスタンスの種類、ゾーンなど)、プロビジョニングされたリソースの合計に対する制限などのノードプロビジョニングに関する制約を使用して NodePools を定義します。ワークロードをデプロイするときは、リソース要求/制限、ノードセレクター、ノード/ポッドアフィニティ、容認、トポロジ分散制約など、ポッド仕様でさまざまなスケジュール制約を指定します。その後、Karpenter は、これらの仕様に基づいて適切なサイズのノードをプロビジョニングします。

Karpenter の発売前、Amazon EKS ユーザーは主に、Amazon EC2 Auto Scaling グループに依存し、クラスターのコンピューティング容量を動的に調整するために、Kubernetes Cluster Autoscaler (CAS) に依存していました。 Karpenter で得られる柔軟性と多様性を実現するために、多数のノードグループを作成する必要はありません。 Kubernetes クラスターオートスケーラーとは異なり、Karpenter は Kubernetes バージョンと密接に結合されておらず、AWS API と Kubernetes API の間をジャンプする必要はありません。

Karpenter は、インスタンスオーケストレーションの責任を 1 つのシステム内に統合します。これは、よりシンプルで、より安定しており、クラスター対応です。 Karpenter は、クラスターオートスケーラーによって提示されるいくつかの課題を克服するために、次の方法を簡単に提供するように設計されています。

ワークロードの要件に基づいてノードをプロビジョニングします。
柔軟な NodePool オプションを使用して、インスタンスの種類ごとに多様なノード構成を作成します。 Karpenter では、多数の特定のカスタムノードグループを管理する代わりに、1 つの柔軟な NodePool を使用して多様なワークロード容量を管理できます。
ノードをすばやく起動し、ポッドをスケジュールすることで、ポッドのスケジュールを大幅に改善します。

Karpenter の使用に関する情報とドキュメントについては、karpenter.sh サイトを参照してください。

Karpenter は、自動スケーリンググループ (ASG) とマネージドノードグループ (MNG) よりも、Kubernetes ネイティブ API に近いスケーリング管理を実現します。 ASG と MNG は、AWS ネイティブの抽象化であり、EC2 CPU 負荷などの AWS レベルのメトリックに基づいてスケーリングがトリガーされます。 Cluster Autoscaler Kubernetes の抽象化を AWS の抽象化にブリッジしますが、そのため、特定の可用性ゾーンのスケジュール設定など、柔軟性が失われます。

Karpenter は AWS 抽象化のレイヤーを削除して、柔軟性の一部を Kubernetes に直接取り込みます。 Karpenter は、高い、急激な需要、または多様なコンピューティング要件を持つワークロードを含むクラスターに最適です。 M NSG と ASG は、より静的で一貫性のあるワークロードを実行するクラスターに適しています。要件に応じて、動的に管理されるノードと静的に管理されるノードの組み合わせを使用できます。

Kata コンテナー

Kata Containers は、コンテナーの軽量な性質と仮想マシンのセキュリティ上の利点を組み合わせたセキュリティで保護されたコンテナーランタイムを提供するオープンソースプロジェクトです。ワークロード間で同じ Linux カーネルを共有する従来のコンテナーとは異なり、各コンテナーを異なるゲストオペレーティングシステムで起動することで、ワークロードの分離とセキュリティを強化する必要性に対処します。 Kata Containers は、OCI に準拠した仮想マシンでコンテナーを実行し、同じホストマシン上のコンテナー間で厳密な分離を提供します。 Kata コンテナー次の機能を提供します。

強化されたワークロード分離: 各コンテナーは独自の軽量 VM で実行され、ハードウェアレベルでの分離が保証されます。
セキュリティの向上: VM テクノロジを使用すると、セキュリティのレイヤーが追加され、コンテナーブレークアウトのリスクが軽減されます。
業界標準との互換性: Kata Containers は、OCI コンテナー形式や Kubernetes CRI インターフェイスなどの業界標準ツールと統合されます。
複数のアーキテクチャとハイパーバイザーのサポート: Kata Containers は AMD64 および ARM アーキテクチャをサポートし、Cloud-Hypervisor や Firecracker などのハイパーバイザーで使用できます。
簡単なデプロイと管理の: Kata Containers は、Kubernetes オーケストレーションシステムを活用することで、ワークロードの調整の複雑さを取り除きます。

AWS のお客様は、セキュリティで保護されたマルチテナントコンテナーと関数ベースのサービスを作成および管理するために Amazon によって開発されたオープンソース仮想化テクノロジである Firecrackerを使用するように、Amazon Elastic Kubernetes Service (EKS) クラスターを構成することで、AWS で kata Containers を設定して実行できます。 Firecracker を使用すると、お客様はマイクロ VM と呼ばれる軽量の仮想マシンにワークロードをデプロイできます。これにより、従来の仮想マシンに対するセキュリティとワークロードの分離が強化され、コンテナーの速度とリソース効率が向上します。 AWS EKS で Kata Containers を有効にするには、「Kata Containers を使用した Kubernetes ワークロードの分離とセキュリティの強化で説明されている一連の手動手順が必要です。

専用ホスト

Amazon Elastic Kubernetes Service (EKS) を使用してコンテナーをデプロイして実行する場合は、Amazon EC2 専用ホストで実行できます。ただし、この機能は自己管理ノードグループでのみ使用できる点に注意してください。つまり、お客様は、起動テンプレートを手動で作成し、自動スケーリンググループし、EKS クラスターに登録する必要があります。これらのリソースの作成プロセスは、一般的な EC2 自動スケーリングの場合と同じです。

AWS EKS を使用した EC2 専用ホストでのコンテナーの実行の詳細については、次のドキュメントを参照してください。

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 シリーズを選択してください。

ノードプールの作成

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

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

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

ノードプールの追加

以下のコード例は、Azure CLI コマンド az aks nodepool add を使用して、3 つのノードを含んだ mynodepool という名前のノードプールを、 myAKSCluster リソースグループ内の myResourceGroup という既存の 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 キャッシュに収まる必要があります。 Azure VM のドキュメントでは、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」を参照してください。

Azure Kubernetes Service (AKS) の Virtual Machines ノードプール

EKS のすべてのマネージドノードグループは、Amazon EKS によって管理される Amazon EC2 Auto Scaling グループによってサポートされます。この統合により、EKS はノードグループ内の EC2 インスタンスのプロビジョニングとスケーリングを自動的に処理できます。 Auto Scaling グループは複数の EC2 インスタンスタイプをサポートするように構成できますが、インスタンスタイプごとに作成またはスケーリングするノードの数を指定することはできません。代わりに、EKS は、ユーザーによって定義された目的の構成とポリシーに基づいてノードグループのスケーリングを管理します。これにより、ノードグループの管理プロセスが簡素化され、自動化される一方で、ワークロード要件に合った EC2 インスタンスの種類を柔軟に選択できます。ただし、AWS のお客様は、または AWS マネジメントコンソール eksctl、セルフマネージド Amazon Linux ノードを起動できます。

Virtual Machines ノードプールがされている場合、Azure Kubernetes Service (AKS) は各エージェントノードのプロビジョニングとブートストラップを管理します。仮想マシンスケールセットノードプールの場合、AKS は仮想マシンスケールセットのモデルを管理し、それを使用してノードプール内のすべてのエージェントノード間の一貫性を実現します。代わりに、Virtual Machines ノードプールを使用すると、個々のワークロードに最適な仮想マシンを使用してクラスターを調整し、仮想マシンのサイズごとに作成またはスケーリングするノードの数を指定できます。

ノードプールは一連の仮想マシンで構成され、さまざまな種類のワークロードをサポートするように指定されたサイズ (SKU) が異なります。これらの仮想マシンのサイズは、SKU と呼ばれ、特定の目的に合わせて最適化されたさまざまなファミリに分類されます。 VM SKU の詳細については、VM SKU の概要を参照してください。

複数の仮想マシンサイズのスケーリングを有効にするために、仮想マシンノードプールの種類では、ノードプールのスケーリング方法、特に仮想マシンのサイズと数の目的の一覧を構成する ScaleProfile が使用されます。 ManualScaleProfile は、目的の仮想マシンのサイズと数を指定するスケールプロファイルです。 ManualScaleProfileでは、1 つの仮想マシンサイズのみが許可されます。ノードプール内の仮想マシンサイズごとに個別の ManualScaleProfile を作成する必要があります。

新しい Virtual Machines ノードプールを作成するときは、ManualScaleProfileに少なくとも 1 つの ScaleProfile が必要です。 1 つの仮想マシンノードプールに対して複数の手動スケールプロファイルを作成できます。

Virtual Machines ノードプールの利点は次のとおりです。

柔軟性: ノードの仕様は、ワークロードとニーズに合わせて更新できます。
微調整された制御:単一ノードレベルの制御により、異なる仕様のノードを指定および混合して一貫性を向上させることができます。
効率: クラスターのノードフットプリントを減らし、運用要件を簡素化できます。

Virtual Machines ノードプールは、動的ワークロードと高可用性の要件に対してより優れたエクスペリエンスを提供します。これにより、1 つのノードプールに同じファミリの複数の仮想マシンを設定でき、構成した使用可能なリソースにワークロードが自動的にスケジュールされます。

次の表は、仮想マシンノードプールと標準のスケールセットノードプールを比較しています。

ノードプールの種類	資格
Virtual Machines ノードプール	ノードプール内のノードを追加、削除、または更新できます。仮想マシンの種類には、同じファミリタイプ (D シリーズ、A シリーズなど) の任意の仮想マシンを指定できます。
仮想マシンスケールセットベースのノードプール	ノードプール内の同じサイズと種類のノードを追加または削除できます。クラスターに新しい仮想マシンサイズを追加する場合は、新しいノードプールを作成する必要があります。

仮想マシンノードプールには、次の制限があります。

クラスターオートスケーラーはサポートされていません。
InfiniBand は使用できません。
Windows ノードプールはサポートされていません。
この機能は、Azure portal では使用できません。 Azure CLI または REST API 使用して、CRUD 操作を実行するか、プールを管理します。
ノードプールスナップショットはサポートされていません。
ノードプールで選択されているすべての VM サイズは、同じ仮想マシンファミリのサイズである必要があります。たとえば、N シリーズ仮想マシンの種類と、同じノードプール内の D シリーズ仮想マシンの種類を混在させることはできません。
仮想マシンノードプールでは、ノードプールごとに最大 5 つの異なる仮想マシンサイズを使用できます。

仮想ノード

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`	`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) でのアプリケーションの需要を満たすようにクラスターを自動的にスケーリング」を参照してください。

ポッドのサンドボックス化

AKS のお客様は、フルマネージドの方法で AKS Kata Containers を簡単にセットアップして実行できます。これは、コンテナーアプリケーションとコンテナーホストの共有カーネルとコンピューティングリソースの間に分離境界を作成する機能である Pod Sandboxingを使用して実現されます。

AKS には、コンテナーアプリケーションとコンテナーホストの共有カーネルとコンピューティングリソース (CPU、メモリ、ネットワークなど) の間の分離境界を提供する、ポッドサンドボックスと呼ばれるメカニズムが含まれています。ポッドサンドボックスは、他のセキュリティ対策またはデータ保護制御を補完して、テナントワークロードが機密情報をセキュリティで保護し、Payment Card Industry Data Security Standard (PCI DSS)、国際標準化機構 (ISO) 27001、医療保険の移植性とアカウンタビリティ法 (HIPAA) などの規制、業界、またはガバナンスのコンプライアンス要件を満たすのに役立ちます。

アプリケーションを個別のクラスターまたはノードプールにデプロイすることで、さまざまなチームまたは顧客のテナントワークロードを強く分離できます。複数のクラスターとノードプールを使用すると、多くの組織や SaaS ソリューションの分離要件に適している場合がありますが、共有 VM ノードプールを持つ単一のクラスターの方が効率的なシナリオがあります。たとえば、信頼されていないポッドと信頼されたポッドを同じノードで実行する場合や、同じノードに DaemonSet と特権コンテナーを併置して、ローカル通信と機能のグループ化を高速化する場合に、1 つのクラスターを使用できます。ポッドサンドボックスは、これらのワークロードを別々のクラスターまたはノードプールで実行しなくても、同じクラスターノード上のテナントアプリケーションを厳密に分離するのに役立ちます。その他の方法では、コードを再コンパイルしたり、他の互換性の問題を引き起こしたりする必要がありますが、AKS のポッドサンドボックスでは、強化されたセキュリティ VM 境界内で変更されていない任意のコンテナーを実行できます。

AKS でのポッドのサンドボックス化は、AKS スタック用の Azure Linux コンテナーホスト上で実行 Kata Containers に基づいて、ハードウェアで強制された分離を提供します。 AKS 上の Kata コンテナーは、セキュリティ強化された Azure ハイパーバイザー上に構築されています。親 VM ノードからのリソースを利用する、入れ子になった軽量の Kata VM を介してポッドごとの分離を実現します。このモデルでは、各 Kata ポッドは、入れ子になった Kata ゲスト VM に独自のカーネルを取得します。このモデルを使用して、親 VM でコンテナーの実行を続けながら、多数の Kata コンテナーを 1 つのゲスト VM に配置します。このモデルは、共有 AKS クラスターで強力な分離境界を提供します。

詳細については、以下を参照してください。

AKS を使用したポッドサンドボックスの
ポッドサンドボックスのための AKS での Kata VM 分離コンテナーののサポート

Azure 専用ホスト

Azure Dedicated Host は、1 つの Azure サブスクリプション専用の物理サーバーを提供し、物理サーバーレベルでハードウェアを分離するサービスです。これらの専用ホストは、リージョン、可用性ゾーン、および障害ドメイン内にプロビジョニングでき、VM をプロビジョニングされたホストに直接配置できます。

AKS で Azure Dedicated Host を使用するには、次のような利点があります。

ハードウェアの分離により、他の VM が専用ホスト上に配置されることがなくなります。これにより、テナントワークロードに対して分離層が追加されます。専用ホストは同じデータセンターにデプロイされ、他の非分離ホストと同じネットワークと基になるストレージインフラストラクチャを共有します。
Azure Dedicated Host では、Azure プラットフォームが開始するメンテナンスイベントを制御できます。メンテナンス期間を選択すると、サービスへの影響を軽減し、テナントワークロードの可用性とプライバシーを確保できます。

Azure Dedicated Host は、SaaS プロバイダーがテナントアプリケーションが機密情報をセキュリティで保護するための規制、業界、ガバナンスのコンプライアンス要件を確実に満たすのに役立ちます。詳細については、「AKS クラスターへの Azure 専用ホストの追加」を参照してください。

Karpenter

Karpenter は、Kubernetes 用に構築されたオープンソースのノードライフサイクル管理プロジェクトです。 Kubernetes クラスターに Karpenter を追加すると、そのクラスターでワークロードを実行する効率とコストを向上させることができます。 Karpenter は、Kubernetes スケジューラがスケジュール不可能としてマークするポッドを監視します。また、ポッドの要件を満たすことができるノードを動的にプロビジョニングおよび管理します。

Karpenter では、マネージドクラスターでのノードプロビジョニングとワークロードの配置をきめ細かく制御できます。この制御により、リソースの割り当てを最適化し、各テナントのアプリケーション間の分離を確保し、運用コストを削減することで、マルチテナント性が向上します。 AKS でマルチテナントソリューションを構築する場合、Karpenter には、さまざまなテナントをサポートするためのさまざまなアプリケーション要件を管理するのに役立つ便利な機能が用意されています。たとえば、GPU 最適化ノードプールで実行するテナントのアプリケーションや、メモリ最適化ノードプールで実行するアプリケーションが必要な場合があります。アプリケーションでストレージの待機時間を短くする必要がある場合は、Karpenter を使用して、ストレージ層とアプリケーション層を併置できるように、ポッドに特定の可用性ゾーンで実行されるノードが必要であることを示すことができます。

AKS では、Karpenter を使用して AKS クラスターでノードの自動プロビジョニングを有効にします。ほとんどのユーザーは、ノードの自動プロビジョニングモードを使用して、Karpenter をマネージドアドオンとして有効にする必要があります。詳細については、「ノードの自動プロビジョニングを参照してください。より高度なカスタマイズが必要な場合は、Karpenter をセルフホストすることを選択できます。詳細については、AKS Karpenter プロバイダーのを参照してください。

機密 VM

コンフィデンシャルコンピューティングは、ソフトウェアまたはハードウェア支援による分離と暗号化を通じて使用中にデータを保護することを目的としたセキュリティ対策です。このテクノロジにより、従来のアプローチにセキュリティレイヤーが追加され、保存データと転送中のデータが保護されます。

AWS プラットフォームは、EC2 インスタンスおよび Amazon Elastic Kubernetes Service (EKS)で利用できる Nitro Enclavesを介したコンフィデンシャルコンピューティングをサポートしています。詳細については、Amazon のドキュメントこちらの記事を参照してください。さらに、Amazon EC2 インスタンスでは、AMD SEV-SNP がサポートされます。この GitHub リポジトリは、AMD SEV-SNP サポートを EKS 用の Amazon Machine Image (AMI) をビルドしてデプロイするための成果物を提供します。

一方、Azure は、AKS クラスター内の厳密な分離、プライバシー、およびセキュリティの要件を満たすために、機密 VM を顧客に提供します。これらの機密 VM は、ハードウェアベースの信頼された実行環境を利用します。具体的には、Azure 機密 VM は AMD Secure Encrypted Virtualization - Secure Nested Paging (SEV-SNP) テクノロジを利用します。このテクノロジにより、ハイパーバイザーやその他のホスト管理コードによる VM のメモリと状態へのアクセスが拒否されます。これにより、オペレーターアクセスに対する防御と保護のレイヤーが追加されます。詳細については、AKS クラスターで機密 VM を使用するに関するドキュメントと、Azure の機密 VM のの概要を参照してください。

Federal Information Process Standards (FIPS)

FIPS 140-3 は、情報技術製品およびシステムにおける暗号モジュールの最小セキュリティ要件を定義する米国政府の標準です。 AKS ノードプールの FIPS コンプライアンス有効にすると、テナントワークロードの分離、プライバシー、セキュリティを強化できます。 FIPS コンプライアンス、暗号化、ハッシュ、およびその他のセキュリティ関連の操作に検証済みの暗号化モジュールを確実に使用できます。 FIPS 対応の AKS ノードプールを使用すると、堅牢な暗号アルゴリズムとメカニズムを採用することで、規制および業界のコンプライアンス要件を満たすことができます。 Azure には、AKS ノードプールに対して FIPS を有効にする方法に関するドキュメントが用意されています。これにより、マルチテナント AKS 環境のセキュリティ体制を強化できます。詳細については、「AKS ノードプールの FIPS を有効にする」を参照してください。

ホストベースの暗号化

EKS では、アーキテクチャで次の機能を利用してデータセキュリティを強化している可能性があります。

Amazon EBS Encryption: EKS ワーカーノードにアタッチされている Amazon Elastic Block Store (EBS) ボリュームで保存データを暗号化できます。
AWS Key Management Service (KMS): AWS KMS を使用して暗号化キーを管理し、保存データの暗号化を適用できます。シークレットの暗号化を有効にした場合は、独自の AWS KMS キーを使用して Kubernetes シークレットを暗号化できます。詳細については、既存のクラスターでの AWS KMS を使用した Kubernetes シークレットの暗号化を参照してください。
Amazon S3 Server-Side 暗号化 : EKS アプリケーションが Amazon S3 と対話する場合は、S3 バケットのサーバー側暗号化を有効にして保存データを保護できます。

AKS のホストベースの暗号化により、テナントのワークロードの分離、プライバシー、セキュリティがさらに強化されます。ホストベースの暗号化を有効にすると、AKS は基になるホストマシン上の保存データを暗号化します。これにより、機密性の高いテナント情報が承認されていないアクセスから保護されます。一時ディスクとエフェメラル OS ディスクは、エンドツーエンド暗号化を有効にすると、プラットフォームマネージドキーを使用して保存時に暗号化されます。

AKS では、OS ディスクとデータディスクでは、プラットフォームマネージドキーを使用したサーバー側暗号化が既定で使用されます。これらのディスクのキャッシュは、プラットフォームマネージドキーを使用して保存時に暗号化されます。エンベロープ暗号化 (ラッピングとも呼ばれます) を使用して、データ保護キーを暗号化する独自の キー暗号化キー を指定できます。 OS ディスクとデータディスクのキャッシュも、指定した BYOK を介して暗号化されます。

ホストベースの暗号化により、マルチテナント環境のセキュリティレイヤーが追加されます。 OS およびデータディスクキャッシュ内の各テナントのデータは、選択したディスク暗号化の種類に応じて、カスタマーマネージドキーまたはプラットフォームマネージドキーを使用して保存時に暗号化されます。詳細については、以下を参照してください。

更新とアップグレード

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 にまたがるノードプールに関する特別な考慮事項」を参照してください。

共同作成者

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

プリンシパルの作成者:

Paolo Salvatori | プリンシパルシステムエンジニア

その他の共同作成者:

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

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

次の方法で共有

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

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

Karpenter

Kata コンテナー

専用ホスト

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

ノードプールの作成

ノードプールの追加

スポットノードプール

エフェメラル OS ディスク

Azure Kubernetes Service (AKS) の Virtual Machines ノードプール

仮想ノード

テイント、ラベル、タグ

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

Windows ノードプール

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

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

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

ポッドのサンドボックス化

Azure 専用ホスト

Karpenter

機密 VM

Federal Information Process Standards (FIPS)

ホストベースの暗号化

更新とアップグレード

Kubernetes のアップグレード

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

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

共同作成者

次のステップ

フィードバック

その他のリソース

次の方法で共有

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

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

Karpenter

Kata コンテナー

専用ホスト

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

ノード プールの作成

ノード プールの追加

スポット ノード プール

エフェメラル OS ディスク

Azure Kubernetes Service (AKS) の Virtual Machines ノード プール

仮想ノード

テイント、ラベル、タグ

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

Windows ノード プール

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

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

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

ポッドのサンドボックス化

Azure 専用ホスト

Karpenter

機密 VM

Federal Information Process Standards (FIPS)

ホストベースの暗号化

更新とアップグレード

Kubernetes のアップグレード

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

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

共同作成者

次のステップ

関連リソース

フィードバック

その他のリソース

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

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

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

ノードプールの作成

ノードプールの追加

スポットノードプール

Azure Kubernetes Service (AKS) の Virtual Machines ノードプール

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

Windows ノードプール

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

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

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

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