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

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

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

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 つだけにしたい場合、システム ノード プールでアプリケーション ポッドをスケジュールできます。

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

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

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

ノード プールの作成

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 という名前のノード プールを、 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 を使用する場合、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」を参照してください。

仮想ノード

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 にデプロイするサブネットです。
• 仮想ノード仮想ネットワーク は、仮想ノードのサブネットを含む仮想ネットワークです。

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

既存のクラスターでクラスター オートスケーラーを再度有効にするには、--enable-cluster-autoscaler、--min-count、および --max-count パラメーターを指定した az aks nodepool update を使用します。

個々のノード プールについてクラスター オートスケーラーを使用する方法について詳しくは、「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 に使用されるノードの最大数は、プール内のノードの数を超えることはありません。

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

使用可能なアップグレードを確認するには、 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 バージョンをアップグレードする方法について詳しくは、次の記事を参照してください。

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

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

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 によって保守されています。 当初の寄稿者は以下のとおりです。

プリンシパルの作成者:

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

その他の共同作成者:

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

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

次のステップ

• AKS for Amazon EKS プロフェッショナル
• Kubernetes の ID およびアクセス管理
• Kubernetes の監視とログ記録
• Kubernetes へのネットワーク アクセスをセキュリティで保護する
• Kubernetes クラスターのストレージ オプション
• Kubernetes のコスト管理
• クラスターのガバナンス
• Azure Kubernetes Service (AKS) ソリューションの体験
• Azure Kubernetes Service (AKS) Day-2 Operations ガイド
• エッジ コンピューティングのオプションで Kubernetes を選択する
• Azure Kubernetes Service 向け GitOps

関連リソース

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