Kubernetes ノードとノード プールを管理する

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

注

この記事は、Amazon EKS に精通している専門家が Azure Kubernetes Service (AKS) を理解するのに役立つ一連の記事の一部です。

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

この図は、Azure マネージドとカスタマー マネージドの 2 つのセクションに分かれています。 Azure マネージド セクションには、API サーバー、スケジューラ、etcd (キー値ストア)、コントローラー マネージャーのコンポーネントを含むコントロール プレーンが含まれています。 API サーバーは、他の 3 つのコンポーネントに接続します。 カスタマー マネージド セクションには、kubelet、コンテナー ランタイム、kube-proxy、およびコンテナーというコンポーネントを持つノードが含まれています。 コントロール プレーンのスケジューラは kubelet に接続します。 Kubelet はコンテナー ランタイムに接続し、コンテナーに接続します。

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

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

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

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

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

Karpenter

Karpenter は、Kubernetes クラスター内のノード ライフサイクル管理を改善するのに役立つオープンソース プロジェクトです。 ポッドの特定のスケジューリング ニーズに基づいてノードのプロビジョニングとプロビジョニング解除が自動化され、スケーリングとコストの最適化が向上します。 次の主な関数には Karpenter を使用します。

• リソースの制約のために Kubernetes スケジューラがスケジュールできないポッドを監視します。

• スケジュール不可能なポッドのリソース要求、ノード セレクター、アフィニティ、容認などのスケジュール要件を評価します。

• スケジュールできないポッドの要件を満たす新しいノードを構成します。

• 不要になったらノードを削除します。

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

Karpenter の発売前、Amazon EKS ユーザーは主に Amazon EC2 自動スケーリング グループ と Kubernetes クラスター オートスケーラー に依存して、クラスターのコンピューティング容量を動的に調整していました。 Karpenter が提供する柔軟性と多様性を実現するために、多数のノード グループを作成する必要はありません。 Kubernetes クラスター オートスケーラーとは異なり、Karpenter は Kubernetes のバージョンへの依存度が低く、AWS API と Kubernetes API 間の移行は必要ありません。

Karpenter は、インスタンス オーケストレーションの責任を 1 つのシステム内に統合します。これは、よりシンプルで、より安定しており、クラスターに対応しています。 Karpenter は、次の簡単な方法を提供することで、クラスター オートスケーラーの課題を克服するのに役立ちます。

• ワークロードの要件に基づいてノードを構成します。

• 柔軟なノード プール オプションを使用して、インスタンスの種類ごとに多様なノード構成を作成します。 複数の特定のカスタム ノード グループを管理する代わりに、Karpenter を使用して、単一の柔軟なノード プールを使用して多様なワークロード容量を管理します。

• ノードをすばやく起動し、ポッドをスケジュールすることで、ポッドのスケジュールを大幅に改善します。

自動スケーリング グループとマネージド ノード グループと比較して、Karpenter はスケーリング管理を Kubernetes ネイティブ API とより緊密に統合します。 自動スケーリング グループとマネージド ノード グループは、AWS レベルのメトリック (EC2 CPU 負荷など) に基づいてスケーリングをトリガーする AWS ネイティブの抽象化です。 クラスター オートスケーラーは Kubernetes の抽象化を AWS の抽象化に結び付けていますが、特定の可用性ゾーンのスケジュール設定など、ある程度の柔軟性を犠牲にします。

Karpenter は、AWS 固有のコンポーネントを排除することでノード管理を簡素化します。これにより、Kubernetes 内で直接柔軟性が向上します。 高い、急激な需要、または多様なコンピューティング要件を持つワークロードを実行するクラスターには、Karpenter を使用します。 より静的で一貫性のあるワークロードを実行するクラスターには、マネージド ノード グループと自動スケーリング グループを使用します。 要件に応じて、動的に管理されるノードと静的に管理されるノードの組み合わせを使用できます。

Kata コンテナー

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

• ワークロードの分離の強化: 各コンテナーは、ハードウェア レベルでの分離を確保するために、独自の軽量 VM で実行されます。

• セキュリティの強化: VM テクノロジを使用すると、セキュリティが強化され、コンテナーブレークアウトのリスクが軽減されます。

• 業界標準との互換性: Kata Containers は、OCI コンテナー形式や Kubernetes コンテナー ランタイム インターフェイスなどの業界標準のツールと統合されます。

• 複数のアーキテクチャとハイパーバイザーのサポート: Kata Containers は AMD64 および ARM アーキテクチャをサポートしており、クラウド ハイパーバイザーや Firecracker などのハイパーバイザーで使用できます。

• 簡単なデプロイと管理: Kata Containers は Kubernetes オーケストレーション システムを使用するため、ワークロードオーケストレーションを簡略化します。

AWS で Kata Containers を設定して実行するには、Firecracker を使用するように Amazon EKS クラスターを構成します。 Firecracker は、セキュリティで保護されたマルチテナント コンテナー ベースおよび関数ベースのサービスを作成および管理するのに役立つ、Amazon のオープンソース仮想化テクノロジです。 Firecracker を使用して、マイクロ VM と呼ばれる軽量 VM にワークロード をデプロイし、従来の VM と比較してセキュリティとワークロードの分離を強化します。 マイクロ VM は、コンテナーの速度とリソース効率も向上します。 AWS EKS で Kata Containers を実行する手順に従います。

専用ホスト

Amazon EKS を使用してコンテナーをデプロイして実行する場合は、Amazon EC2 専用ホストでコンテナーを実行できます。 ただし、この機能は自己管理ノード グループでのみ使用できます。 そのため、 起動テンプレート と 自動スケーリング グループを手動で作成する必要があります。 その後、専用ホスト、起動テンプレート、自動スケーリング グループを EKS クラスターに登録します。 これらのリソースを作成するには、一般的な EC2 自動スケーリングと同じ方法を使用します。

AWS EKS を使用して EC2 専用ホストでコンテナーを実行する方法の詳細については、次のリソースを参照してください。

• Amazon EKS ノード
• 専用ホストの制限
• 専用ホストを割り当てる
• 専用ホスト予約を購入する
• 自動配置

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

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

ノードは、ワークロードとアプリケーションのホストであり、"エージェント ノード" または "ワーカー ノード" とも呼ばれます。 AKS では、AKS クラスターに接続されているエージェント ノードを完全に管理して支払います。

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

AKS は、同じ構成のノードを、AKS ワークロードを実行する VM のノード プールに結合します。 システム ノード プールを使用して、CoreDNS などの重要なシステム ポッドをホストします。 ユーザー ノード プールを使用してワークロード ポッドをホストします。 開発環境など、AKS クラスターにノード プールが 1 つだけ必要な場合は、システム ノード プールでアプリケーション ポッドをスケジュールできます。

Azure VM には、kubelet、コンテナー ランタイム、kube-proxy、コンテナーの 4 つのコンポーネントが含まれています。 Azure 仮想ネットワークは、kube-proxy コンポーネントに接続する Azure 仮想ネットワーク インターフェイスに接続します。 Kubelet はコンテナー ランタイムに接続し、コンテナー ランタイムはコンテナーに接続します。 Azure ディスク ストレージと Azure Files はコンテナーを指します。

また、複数のユーザー ノード プールを作成して、異なるノード上の異なるワークロードを分離することもできます。 この方法は 、ノイズの多い近隣の問題 を防ぐのに役立ち、コンピューティングまたはストレージの需要が異なるアプリケーションをサポートします。

システムまたはユーザー ノード プール内のすべてのエージェント ノードは、基本的に VM です。 Azure Virtual Machine Scale Sets によって VM が構成され、AKS クラスターによって VM が管理されます。 詳細については、「 ノード プール」を参照してください。

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

重要

内部ノード呼び出しとプラットフォーム サービスとの通信の待機時間を短縮するには、 高速ネットワークをサポートする VM シリーズを選択します。

ノード プールを作成する

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

既定では、ノード リソース グループには MC_<resourcegroupname>_<clustername>_<location> のような名前が付いています。 AKS は、クラスターを削除すると、ノード リソース グループを自動的に削除します。 このリソース グループは、クラスターのライフサイクルを共有するリソースにのみ使用する必要があります。

詳細については、「 AKS でのクラスターのノード プールの作成」を参照してください。

ノード プールを追加する

ノード プールを新規または既存の AKS クラスターに追加するには、Azure portal、 Azure CLI、または AKS REST API を使用します。 Bicep、Azure Resource Manager テンプレート、Terraform などのコードとしてのインフラストラクチャ (IaC) ツールを使用することもできます。

次のコード例では、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 クラスター内のノードにスポット VM を使用して、未使用の Azure 容量を低コストで利用します。 使用可能な未使用容量の量は、ノードのサイズ、リージョン、時刻などの要因によって異なります。

スポット ノード プールをデプロイすると、容量が使用可能な場合、Azure によってスポット ノードが割り当てられます。 ただし、スポット ノードにはサービス レベル アグリーメント (SLA) がありません。 スポット ノード プールをサポートするスポット スケール セットは、単一の障害ドメインにデプロイされ、高可用性の保証を提供しません。 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

詳細については、「 スポット ノード プールを AKS クラスターに追加する」を参照してください。

エフェメラル OS ディスク

既定では、Azure は VM OS ディスクを Azure Storage に自動的にレプリケートします。 この方法では、VM を別のホストに再配置する必要がある場合に、データ損失を防ぐことができます。 ただし、コンテナーはローカル状態を保持するように設計されていないため、AZURE Storage に OS ディスクを格納すると、AKS の利点は限られます。 この方法により、ノードのプロビジョニングが遅くなり、読み取りと書き込みの待機時間が長くなる可能性があります。

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

重要

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

エフェメラル OS を使用する場合、OS ディスクは VM キャッシュに収まる必要があります。 Azure VM のドキュメントでは、入力/出力 (I/O) スループットの横にあるかっこで囲まれた VM キャッシュ サイズが、キャッシュ サイズ (ギビバイト単位) として示されています。

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

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

100 GB の OS ディスクを使用する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 ディスクを参照してください。

AKS の Azure Virtual Machines ノード プール

EKS 内のすべてのマネージド ノード グループは、Amazon EKS が管理する Amazon EC2 自動スケーリング グループによってサポートされます。 この統合により、EKS はノード グループ内の EC2 インスタンスを自動的に構成およびスケーリングできます。

複数の EC2 インスタンスの種類をサポートするように自動スケーリング グループを構成できますが、インスタンスの種類ごとに作成またはスケーリングするノードの数を指定することはできません。 代わりに、EKS は目的の構成とポリシーに基づいてノード グループのスケーリングを管理します。 この方法では、ノード グループの管理プロセスが簡略化され、自動化されるため、ワークロードの要件に合った EC2 インスタンスの種類を選択できます。 コマンドラインツールまたは AWS マネジメントコンソールを使用して、eksctlを起動することもできます。

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

ノード プールは、サイズが異なる一連の VM で構成されます。 各 VM では、異なる種類のワークロードがサポートされています。 これらの VM サイズは SKU と呼ばれ、特定の目的に合わせて最適化されたさまざまなファミリに分類されます。 詳細については、 Azure の VM サイズに関するページを参照してください。

複数の VM サイズのスケーリングを有効にするには、Virtual Machines ノード プールの種類で ScaleProfileを使用します。 このプロファイルでは、目的の VM サイズと数を指定して、ノード プールのスケーリング方法を構成します。 ManualScaleProfileは、目的の VM サイズと数を指定するスケール プロファイルです。 ManualScaleProfileで許可される VM サイズは 1 つだけです。 ノード プール内の VM サイズごとに個別の ManualScaleProfile を作成する必要があります。

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

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

• 柔軟性： ワークロードとニーズに合わせてノード仕様を更新できます。

• 微調整されたコントロール: 単一ノード レベルのコントロールは、異なる仕様のノードを指定して結合し、一貫性を高めるのに役立ちます。

• 効率： 運用要件を簡素化するために、クラスターのノード フットプリントを減らすことができます。

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

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

ノード プールの種類	能力
仮想マシン ノード プール	ノード プール内のノードを追加、削除、または更新できます。 VM の種類には、D シリーズや A シリーズなど、同じファミリ タイプの任意の VM を使用できます。
Virtual Machine Scale Sets ノード プール	ノード プール内の同じサイズと種類のノードを追加または削除できます。 クラスターに新しい VM サイズを追加する場合は、新しいノード プールを作成する必要があります。

Virtual Machines ノード プールには、次の制限があります。

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

仮想ノード

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

仮想ノードの機能は Azure Container Instances に依存します。 詳細については、「 仮想ノードを使用するように 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 で使用するために予約されており、ノードには使用できないラベルの一覧です。 この表の 仮想ノード使用状況 列は、仮想ノードがラベルをサポートするかどうかを指定します。

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

• N/A は、ホストを変更する必要があるため、このプロパティは仮想ノードには適用されません。
• 同じ とは、仮想ノード プールと標準ノード プールで想定される値が同じであることを意味します。
• 仮想ノード ポッドが基になる VM を公開しないため、VM SKU の値は仮想に置き換えられます。
• "仮想ノードのバージョン" とは、 仮想 Kubelet-ACI コネクタ リリースの現在のバージョンを指します。
• 仮想ノード サブネット名 は、コンテナー インスタンスに仮想ノード ポッドをデプロイするサブネットです。
• 仮想ノード仮想ネットワーク は、仮想ノードのサブネットを含む仮想ネットワークです。

ラベル	価値	例またはオプション	仮想ノードの使用
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 Container Networking Interface ネットワーク プラグインを使用して Windows Server コンテナー ノード プールを作成して使用できます。 必要なサブネット範囲とネットワークに関する考慮事項を計画するには、「 Azure Container Networking Interface の構成」を参照してください。

次の 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 パラメーターを指定します。

個々のノード プールでクラスター オートスケーラーを使用する方法の詳細については、「 AKS でのクラスター オートスケーラーの使用」を参照してください。

ポッド サンドボックス

フル マネージド ソリューションとして AKS で Kata Containers を簡単に設定して実行するには、 ポッド サンドボックスを使用します。 ポッド サンドボックスは、コンテナー アプリケーションと共有カーネルとコンテナー ホストのコンピューティング リソース (CPU、メモリ、ネットワークなど) との間に分離境界を作成する AKS 機能です。

ポッドサンドボックスは、テナントワークロードが機密情報をセキュリティで保護し、規制、業界、またはガバナンスのコンプライアンス要件を満たすのに役立つ、他のセキュリティ対策またはデータ保護制御を補完します。 これらの要件には、Payment Card Industry Data Security Standard (PCI DSS)、国際標準化機構 (ISO) 27001、医療保険の携行性とアカウンタビリティに関する法律 (HIPAA) が含まれます。

別のクラスターまたはノード プールにアプリケーションをデプロイして、さまざまなチームまたは顧客のテナント ワークロードを分離します。 組織またはサービスとしてのソフトウェア (SaaS) ソリューションで必要な場合は、複数のクラスターとノード プールを使用できます。 ただし、一部のシナリオでは、共有 VM ノード プールを持つ単一のクラスターの利点があります。 たとえば、単一のクラスターを使用して、信頼されていないポッドと信頼されたポッドを同じノード上で実行したり、同じノードに DaemonSet と特権コンテナーを併置して、ローカル通信と機能グループ化を高速化したりできます。

ポッドサンドボックスは、これらのワークロードを個別のクラスターまたはノード プールで実行しなくても、同じクラスター ノード上のテナント アプリケーションを分離するのに役立ちます。 その他の方法では、コードを再コンパイルする必要がある場合や、他の互換性の問題が発生する可能性があります。 AKS のポッド サンドボックスは、強化されたセキュリティ VM 境界内で変更されていないコンテナーを実行できます。

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

詳細については、「 ポッド サンドボックスの AKS での Kata VM 分離コンテナーのサポート」を参照してください。

Azure 専用ホスト

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

AKS で専用ホストを使用して、次の利点を提供します。

• ハードウェアの分離により、他の VM が専用ホスト上に配置されることがなくなります。これにより、テナント ワークロードに対して分離層が追加されます。 専用ホストは同じデータセンターにデプロイされ、他の非絶縁ホストと同じネットワークと基になるストレージ インフラストラクチャを共有します。

• 専用ホストでは、Azure プラットフォームが開始するメンテナンス イベントを制御できます。 メンテナンス期間を選択すると、サービスへの影響を軽減し、テナント ワークロードの可用性とプライバシーを確保できます。

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

Karpenter

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

Karpenter では、マネージド クラスターでのノード プロビジョニングとワークロードの配置をきめ細かく制御できます。 この制御により、リソースの割り当てが最適化され、各テナントのアプリケーション間の分離が確保され、運用コストが削減され、マルチテナントが向上します。 AKS でマルチテナント ソリューションを構築する場合、Karpenter には、さまざまなテナントをサポートするためのさまざまなアプリケーション要件を管理するのに役立つ便利な機能が用意されています。

たとえば、GPU 最適化ノード プールで実行するテナントのアプリケーションや、メモリ最適化ノード プールで実行するアプリケーションが必要な場合があります。 アプリケーションでストレージの待機時間を短くする必要がある場合は、Karpenter を使用して、ポッドに特定の可用性ゾーンで実行されるノードが必要であることを示すことができます。 その後、ストレージ層とアプリケーション層を併置できます。

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

機密仮想マシン

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

AWS プラットフォームでは、EC2 インスタンスと Amazon EKS で利用できるNitro エンクレーブを介したコンフィデンシャル コンピューティングがサポートされています。 Amazon EC2 インスタンスでは、 AMD Secure Encrypted Virtualization Secure Nested Paging (SEV-SNP) もサポートされています。 ランタイム構成証明 GitHub リポジトリは、AMD SEV-SNP サポートを使用して EKS 用 Amazon Machine Image をビルドしてデプロイするための成果物を提供します。

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

連邦情報処理規格

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

ホストベースの暗号化

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

• Amazon Elastic Block Store (EBS) 暗号化: EKS ワーカー ノードにアタッチされている Amazon EBS ボリュームの保存データを暗号化できます。

• AWS Key Management Service (KMS):AWS KMS を使用して暗号化キーを管理し、保存データの暗号化を適用できます。 シークレットの暗号化を有効にした場合は、独自の AWS KMS キーを使用して Kubernetes シークレットを暗号化できます。 詳細については、既存のクラスター での AWS KMS を使用した Kubernetes シークレットの暗号化を参照してください。

• Amazon S3 サーバー側の暗号化: EKS アプリケーションが Amazon S3 と対話する場合は、S3 バケットのサーバー側暗号化を有効にして、保存データを保護できます。

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

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

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

• AKS でのホストベースの暗号化
• AKSでAzureディスクを使用してBYOKを行う
• Azure ディスク ストレージのサーバー側暗号化

更新とアップグレード

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

VM ホスティング インフラストラクチャの更新は、通常、既存の AKS クラスターのエージェント ノードなど、ホストされている VM には影響しません。 ホストされている VM に影響を与える更新プログラムの場合、Azure では、ホストの更新中に VM を一時停止するか、VM を既に更新済みのホストにライブ 移行することで、再起動が必要なケースを最小限に抑えます。

更新で再起動が必要な場合、Azure は更新を開始できる通知と時間枠を提供します。 ホスト マシンのセルフ メンテナンス期間は、緊急の更新でない限り、通常は 35 日間です。

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

Kubernetes のアップグレード

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

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

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

AKS は、 max-surge 値に対して整数とパーセンテージの両方の値を受け入れます。 たとえば、整数 5 は、サージする 5 つの追加ノードを示します。 max-surgeのパーセント値を1%から100%に設定でき、最も近いノード数に切り上げられます。 値 50% は、プール内の現在のノード数の半分のサージ値を示します。

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

重要

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

Azure Container Networking Interface を使用する場合は、 AKS の要件を満たすのに十分な 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>

詳細については、次のリソースを参照してください。

• AKS ノード イメージのアップグレード
• 複数のノード プールを使用するでクラスターのコントロール プレーンをアップグレードする

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

AKS クラスターで Kubernetes バージョンをアップグレードする場合は、次のベスト プラクティスを検討してください。

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

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

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

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

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

• Azure Container Networking Interface ネットワークを使用する AKS クラスターをアップグレードする場合は、 max-surge 設定で作成される追加のノードに使用できるプライベート IP アドレスがサブネットに十分にあることを確認します。 詳細については、「 AKS で Azure Container Networking Interface ネットワークを構成する」を参照してください。

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

貢献者

Microsoft では、この記事を保持しています。 次の共同作成者がこの記事を書きました。

主要な著者:

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

その他の共同作成者:

• Laura Nicolas | シニア ソフトウェア エンジニア
• チャド・キットテル |プリンシパル ソフトウェア エンジニア - Azure パターンとプラクティス
• Ed Price | シニア コンテンツ プログラム マネージャー
• Theano Petersen | テクニカル ライター

公開されていない LinkedIn プロフィールを見るには、LinkedIn にサインインしてください。

次のステップ

• AKS クラスターのベスト プラクティス
• パブリック DNS ゾーンを使用してプライベート AKS クラスターを作成する
• Terraform と Azure DevOps を使用してプライベート AKS クラスターを作成する
• Azure NAT ゲートウェイと Azure Application Gateway を使用してパブリックまたはプライベートの AKS クラスターを作成する
• プライベート AKS クラスターでプライベート エンドポイントを使用する
• Application Gateway イングレス コントローラーを使用して AKS クラスターを作成する
• トレーニング: Kubernetes の概要
• トレーニング: Azure での Kubernetes の概要
• トレーニング: Kubernetes でのアプリケーションの開発とデプロイ
• トレーニング: AKS でコンピューティング コストを最適化する

関連リソース

• Amazon EKS 専門家のための AKS
• Kubernetes の ID およびアクセス管理
• Kubernetes の監視とログ記録
• Kubernetes へのネットワーク アクセスをセキュリティで保護する
• Kubernetes クラスターのストレージ オプション
• Kubernetes のコスト管理
• クラスターのガバナンス
• AKS ソリューションの体験
• AKS の 2 日目の運用ガイド
• エッジ コンピューティングのオプションで Kubernetes を選択する
• AKS 用 GitOps