ノードプールの追加と管理

このページでは、Google Kubernetes Engine（GKE）クラスタを実行するノードプールを追加して操作する方法を説明します。ノードプールの仕組みについては、ノードプールについてをご覧ください。

クラスタは、ノードの自動プロビジョニングなどのオペレーションを複数のノードプールで並行して実行できます。別のノードプールの作成、更新、削除が行われている間に、ノードプールを手動で作成、更新、削除できます。

ここで説明する手順は、GKE がノードを管理し、管理対象のノードプールがない Autopilot クラスタには適用されません。詳細については、Autopilot の概要をご覧ください。

始める前に

作業を始める前に、次のことを確認してください。

• Google Kubernetes Engine API を有効にする。
Google Kubernetes Engine API の有効化
• このタスクに Google Cloud CLI を使用する場合は、gcloud CLI をインストールして初期化する。すでに gcloud CLI をインストールしている場合は、gcloud components update を実行して最新のバージョンを取得する。

GKE の IAM サービス アカウントを設定する

GKE は、ノードに接続されている IAM サービス アカウントを使用して、ロギングやモニタリングなどのシステムタスクを実行します。少なくとも、これらのノード サービス アカウントには、プロジェクトに対する Kubernetes Engine デフォルト ノード サービス アカウント（roles/container.defaultNodeServiceAccount）ロールが必要です。デフォルトでは、GKE はプロジェクトで自動的に作成される Compute Engine のデフォルトのサービス アカウントをノード サービス アカウントとして使用します。

Compute Engine のデフォルト サービス アカウントに roles/container.defaultNodeServiceAccount ロールを付与する手順は次のとおりです。

Standard クラスタにノードプールを追加する

新しいノードプールを GKE Standard クラスタに追加するには、gcloud CLI、Google Cloud コンソール、または Terraform を使用します。GKE は、スケーリング要件に基づいてクラスタ内のノードプールを自動的に管理するノード自動プロビジョニングもサポートしています。

gcloud container node-pools create POOL_NAME \
    --cluster CLUSTER_NAME \
    --service-account SERVICE_ACCOUNT

Creating node pool POOL_NAME...done.
Created [https://container.googleapis.com/v1/projects/PROJECT_ID/zones/us-central1/clusters/CLUSTER_NAME/nodePools/POOL_NAME].
NAME: POOL_NAME
MACHINE_TYPE: e2-medium
DISK_SIZE_GB: 100
NODE_VERSION: 1.21.5-gke.1302

gcloud container node-pools list --cluster CLUSTER_NAME

resource "google_container_node_pool" "default" {
  name    = "gke-standard-regional-node-pool"
  cluster = google_container_cluster.default.name

  node_config {
    service_account = google_service_account.default.email
  }
}

Standard クラスタ内のノードプールを表示する

gcloud container node-pools list --cluster CLUSTER_NAME

gcloud container node-pools describe POOL_NAME \
    --cluster CLUSTER_NAME

ノードプールをスケーリングする

ノードプールをスケールアップまたはスケールダウンして、パフォーマンスと費用を最適化できます。GKE Standard ノードプールを使用すると、ノードプール内のノード数を変更してノードプールを水平方向にスケーリングできます。また、ノードのマシン属性構成を変更してノードプールを垂直方向にスケーリングできます。

ノード数を変更して水平方向にスケーリングする

gcloud container clusters resize CLUSTER_NAME \
    --node-pool POOL_NAME \
    --num-nodes NUM_NODES

ノードマシンの属性を変更して垂直方向にスケーリングする

ノードプールの構成済みのマシンタイプ、ディスクタイプ、ディスクサイズを変更できます。

これらのマシン属性を編集すると、GKE はノードプールに構成されたアップグレード戦略を使用して、ノードを新しい構成に更新します。Blue/Green アップグレード戦略を構成すると、移行の失敗時に元のノードをロールバックできるようにしながら、元のノードから新しいノードにワークロードを移行できます。ノードプールのアップグレード設定を調べて、構成した戦略が必要なノードの更新方法と一致していることを確認します。

次のコマンドで、ハイライト表示されているマシン属性の少なくとも 1 つを更新します。

gcloud container node-pools update POOL_NAME \
    --cluster CLUSTER_NAME \
    --machine-type MACHINE_TYPE \
    --disk-type DISK_TYPE \
    --disk-size DISK_SIZE

変更しないマシン属性のフラグは省略します。ただし、少なくとも 1 つのマシン属性フラグを使用する必要があります。そうしないと、コマンドが失敗します。

次のように置き換えます。

• POOL_NAME: サイズを変更するノードプールの名前。
• CLUSTER_NAME: サイズを変更するクラスタの名前。
• MACHINE_TYPE: ノードに使用するマシンのタイプ。詳細については、gcloud container node-pools update をご覧ください。
• DISK_TYPE: ノード VM ブートディスクのタイプ。pd-standard、pd-ssd、pd-balanced のいずれかにする必要があります。
• DISK_SIZE: ノード VM ブートディスクのサイズ（GB）。デフォルトは 100 GB です。

この変更を行うにはノードを再作成する必要があります。これにより、実行中のワークロードが中断する可能性があります。この特定の変更について詳しくは、メンテナンス ポリシーを尊重せずにノードのアップグレード戦略を使用してノードを再作成する手動変更の表で対応する行をご覧ください。ノードの更新の詳細については、ノードの更新による中断の計画をご覧ください。

ノードプールをアップグレードする

デフォルトでは、クラスタのノードで自動アップグレードが有効になっています。ノードの自動アップグレードにより、クラスタのコントロール プレーンとノードのバージョンが同期されており、Kubernetes バージョン スキュー ポリシーに準拠していることが保証されます。これにより、コントロール プレーンはコントロール プレーンの 2 つ前までのマイナー バージョンのノードと互換性が保証されています。たとえば、Kubernetes 1.29 コントロール プレーンは Kubernetes 1.27 ノードと互換性があります。

GKE ノードプールのアップグレードでは、サージ アップグレードと Blue/Green アップグレードの 2 つの構成可能なアップグレード戦略を選択できます。

クラスタ環境のニーズに最適な戦略を選択し、戦略を調整するパラメータを使用します。

ノードのアップグレードの仕組み

ノードがアップグレードされている間、GKE は新しい Pod のスケジュールを停止し、実行中の Pod を他のノードにスケジュールします。これは、ノードプールで機能を有効または無効にする場合など、ノードの再作成を行う他のイベントも同様です。

ノードの自動アップグレード中または手動アップグレード中、PodDisruptionBudgets（PDB）と Pod の停止猶予期間は最大 1 時間使用されます。ノードで実行中の Pod を 1 時間後に新しいノードにスケジュールできない場合でも、GKE はアップグレードを開始します。maxUnavailable フィールドを 0 または 0% に設定するか、minAvailable フィールドを 100% またはレプリカ数に設定して、すべてのレプリカを常に使用できるように PDB を構成している場合でも、この動作は適用されます。これらのシナリオではすべて、ノードの削除が行われるように、1 時間後に Pod が削除されます。

アップグレードは、すべてのノードが再作成され、クラスタが望ましい状態になったときにはじめて完了します。新しくアップグレードされたノードがコントロール プレーンに登録されると、GKE ではノードがスケジューリング可能であるとマークされます。

新しいノード インスタンスでは、目的の Kubernetes バージョンと次のものが実行されます。

• ノードイメージ
• kubelet
• kube-proxy

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

手動でアップグレードできるノードプールのバージョンは、コントロール プレーンと同じバージョンか、引き続き使用可能でコントロール プレーンと互換性のある以前のバージョンです。複数のノードプールを同時に手動でアップグレードできますが、GKE が自動で一度にアップグレードするノードプールは 1 つだけです。

ノードプールを手動でアップグレードすると、kubectl を使用して個々のノードに追加したラベルが削除されます。これを回避するには、ノードプールにラベルを適用します。

ノードプールを手動でアップグレードする前に、次の条件を検討してください。

• ノードプールをアップグレードすると、そのノードプールで実行中のワークロードが中断される可能性があります。これを回避するには、目的のバージョンで新しいノードプールを作成しワークロードを移行します。移行後、古いノードプールは削除できます。
• エラー状態の Ingress でノードプールをアップグレードすると、インスタンス グループは同期しません。この問題を回避するには、まず、kubectl get ing コマンドでステータスを確認します。インスタンス グループが同期されていない場合は、Ingress の作成に使用したマニフェストを再適用して問題を回避します。

ノードプールは、Google Cloud コンソールか Google Cloud CLI を使用して、コントロール プレーンと互換性のあるバージョンに手動でアップグレードできます。

gcloud container clusters upgrade CLUSTER_NAME \
  --node-pool=NODE_POOL_NAME

gcloud container clusters upgrade CLUSTER_NAME \
  --node-pool=NODE_POOL_NAME \
  --cluster-version VERSION

Pod を特定のノードプールにデプロイする

Pod マニフェストで nodeSelector を使用すると、Pod を特定のノードプールに明示的にデプロイできます。nodeSelector は、ラベルが一致するノードに Pod のスケジュールを設定します。

すべての GKE ノードプールには、cloud.google.com/gke-nodepool: POOL_NAME という形式のラベルがあります。次の例に示すように、このラベルを Pod の nodeSelector フィールドに追加します。

apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:
    env: test
spec:
  containers:
  - name: nginx
    image: nginx
    imagePullPolicy: IfNotPresent
  nodeSelector:
    cloud.google.com/gke-nodepool: POOL_NAME

詳細は、ノードに Pod を割り当てるをご覧ください。

ノードセレクタの代わりに、ノード アフィニティを使用できます。Pod が制約を満たそうと試みる一方で、制約を満たせない場合でも Pod のスケジュールが設定される「ソフト」ルールを適用したい場合は、ノード アフィニティを使用します。詳細は、ノード アフィニティをご覧ください。コンテナのリソース リクエストを指定することもできます。

ノードプールをダウングレードする

たとえば、ノードプールのアップグレードの失敗の可能性を軽減するために、ノードプールをダウングレードできます。ノードプールをダウングレードする前に、制限事項を確認してください。

1. ダウングレード後に GKE によってノードプールが自動的にアップグレードされないようにするには、メンテナンスの除外をクラスタに設定します。
2. ノードプールをダウングレードするには、ノードプールを手動でアップグレードするの手順に沿って、以前のバージョンを指定します。

ノードプールを削除する

ノードプールを削除すると、PodDisruptionBudget の設定に関係なく、ノードと実行中のワークロードがすべて削除されます。ノードセレクタの操作など、ワークロードへの影響の詳細については、ノードプールの削除をご覧ください。

gcloud container node-pools delete POOL_NAME \
    --cluster CLUSTER_NAME

ノードを別のマシンタイプに移行する

マシンタイプ間でワークロードを移動するさまざまな方法（新しいマシンタイプに移行する方法など）については、ノードを別のマシンタイプに移行するをご覧ください。

ノードプール間でワークロードを移行する

ワークロードをあるノードプールから別のノードプールに移行するには、ノードプール間でワークロードを移行するをご覧ください。たとえば、既存のノードプールを新しいノードプールに置き換え、ワークロードが既存のノードから新しいノードに確実に移動するようにするには、次の操作を行います。

トラブルシューティング

トラブルシューティングについては、Standard ノードプールのトラブルシューティングとノード登録のトラブルシューティングをご覧ください。

次のステップ

• ノードプールの仕組みについて読む。
• ノードプールの自動プロビジョニングについて学習する
• GKE が異常なノードを自動的に修復する方法について学習する。
• ノードシステム構成を使用して kubelet と sysctl を構成する方法を学習する。