ノードプールを作成してカスタマイズする

このページでは、GKE on AWS でノードプールを作成する方法と、構成ファイルを使用してノード構成をカスタマイズする方法について説明します。

ノードプールを作成するには、次のリソースを指定する必要があります。

• ノードプールの作成場所とする既存の AWS クラスタの名前
• ノードプール VM の IAM インスタンス プロファイル
• ノードプール VM が実行されるサブネット

ノードに SSH でアクセスする場合は、EC2 認証鍵ペアを作成できます。

このページは、クラウド インフラストラクチャの設定、モニタリング、管理を担当する IT 管理者とオペレーターを対象としています。 Google Cloud のコンテンツで使用されている一般的なロールとタスクの例の詳細については、一般的な GKE ユーザーのロールとタスクをご覧ください。

標準のノードプールを作成する

これらのリソースが使用可能になったら、次のコマンドを使用してノードプールを作成できます。

gcloud container aws node-pools create NODE_POOL_NAME \
    --cluster CLUSTER_NAME \
    --instance-type INSTANCE_TYPE \
    --root-volume-size ROOT_VOLUME_SIZE \
    --iam-instance-profile NODEPOOL_PROFILE \
    --node-version NODE_VERSION \
    --min-nodes MIN_NODES \
    --max-nodes MAX_NODES \
    --max-pods-per-node MAX_PODS_PER_NODE \
    --location GOOGLE_CLOUD_LOCATION \
    --subnet-id NODEPOOL_SUBNET \
    --ssh-ec2-key-pair SSH_KEY_PAIR_NAME \
    --config-encryption-kms-key-arn CONFIG_KMS_KEY_ARN \
    --tags "Name=CLUSTER_NAME-NODE_POOL_NAME"

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

• NODE_POOL_NAME: ノードプールに付ける名前
• CLUSTER_NAME: ノードプールを接続するクラスタの名前
• INSTANCE_TYPE: このノードプールに必要な AWS マシン インスタンス タイプ。例: m5.large
• ROOT_VOLUME_SIZE: 各ノードのルート ボリュームに必要なサイズ（GB）
• NODEPOOL_PROFILE: ノードプール VM の IAM インスタンス プロファイル。IAM インスタンス プロファイルを更新する方法について詳しくは、AWS IAM インスタンス プロファイルを更新するをご覧ください。
• NODE_VERSION: ノードプールの各ノードにインストールする Kubernetes のバージョン（例: "1.32.4-gke.200"）
• MIN_NODES: ノードプールに配置できるノードの最小数
• MAX_NODES: ノードプールに配置できるノードの最大数
• MAX_PODS_PER_NODE: プール内の任意の 1 つのノードで作成できる Pod の最大数
• GOOGLE_CLOUD_LOCATION: このノードプールを管理する Google Cloudロケーションの名前
• NODEPOOL_SUBNET: ノードプールが実行されるサブネットの ID。
  • クラスタの Pod / Service IP 範囲とノードプール サブネット ネットワークとの間に重複がないようにしてください。クラスタの Pod と Service の IP 範囲の選択について詳しくは、クラスタの CIDR 範囲を選択するをご覧ください。
  • このサブネットが VPC プライマリ CIDR ブロックの外部にある場合は、追加の手順が必要です。詳細については、セキュリティ グループをご覧ください。
• SSH_KEY_PAIR_NAME: SSH アクセス用に作成された AWS SSH 鍵ペアの名前（省略可）
• CONFIG_KMS_KEY_ARN: ユーザーデータを暗号化する AWS KMS 鍵の Amazon Resource Name（ARN）

存在する場合、--tags パラメータに指定したタグがノードプール内のすべてのノードに適用されます。この例では、プール内のすべてのノードに、ノードが属するクラスタとノードプールの名前でタグを付けます。

ノードシステム構成をカスタマイズする

ノードの構成はさまざまな方法でカスタマイズできます。たとえば、ノードプールを作成するときに、Pod の CPU 上限数などのパラメータを指定できます。

ノードシステム構成を使用すると、ノードプールで Kubernetes ノード エージェント（kubelet）と低レベルの Linux カーネル構成（sysctl）に対してカスタム設定を指定できます。

kubelet エージェントを構成する

kubelet を使用してノード構成をカスタマイズするには、Google Cloud CLI または Terraform を使用します。

gcloud

ノードプールを作成するときに、Kubernetes ノード エージェント（kubelet）のカスタム設定を指定できます。たとえば、静的 CPU 管理ポリシーを使用するように kubelet を構成するには、次のコマンドを実行します。

  gcloud container aws node-pools create POOL_NAME \
       --cluster CLUSTER_NAME \
       --location=LOCATION \
       --kubelet_config_cpu_manager_policy=static

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

• POOL_NAME: ノードプールの名前
• CLUSTER_NAME: ノードプールの追加先とするクラスタの名前。
• LOCATION: クラスタのコンピューティング ゾーンまたはリージョン

上記のコマンドに追加できるすべてのフィールドについては、Kubelet 構成オプションをご覧ください。

Terraform

AWS 環境での Terraform の詳細については、Terraform ノードプール リファレンスをご覧ください。

1. variables.tf ファイルに次のブロックを追加して、Terraform 変数を設定します。

   variable "node_pool_kubelet_config_cpu_manager" {
     default     = "none"
   }
   
   variable "node_pool_kubelet_config_cpu_cfs_quota" {
     default     = "true"
   }
   
   variable "node_pool_kubelet_config_cpu_cfs_quota_period" {
     default     = "100ms"
   }
   
   variable "node_pool_kubelet_config_pod_pids_limit" {
     default     = -1
   }
   

2. Terraform 構成に次のブロックを追加します。

   resource "google_container_aws_node_pool" "NODE_POOL_RESOURCE_NAME" {
    provider           = google
    cluster            = CLUSTER_NAME
    name               = POOL_NAME
    subnet_id          = SUBNET_ID
    version            = CLUSTER_VERSION
    location           = CLUSTER_LOCATION
   
    kubelet_config {
      cpu_manager_policy = var.node_pool_kubelet_config_cpu_manager
      cpu_cfs_quota = var.node_pool_kubelet_config_cpu_cfs_quota
      cpu_cfs_quota_period = var.node_pool_kubelet_config_cpu_cfs_quota_period
      pod_pids_limit = var.node_pool_kubelet_config_pod_pids_limit
    }
   }
   

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

   • NODE_POOL_RESOURCE_NAME: Terraform テンプレートのノードプール リソースの名前。
   • CLUSTER_NAME: 既存のクラスタの名前。
   • POOL_NAME: カスタマイズするノードプールの名前。
   • SUBNET_ID: ノードプールに割り当てられたサブネット。
   • CLUSTER_VERSION: GKE on AWS クラスタのコントロール プレーンとノードのバージョン。
   • CLUSTER_LOCATION: クラスタの Compute Engine のリージョンまたはゾーン。

sysctl ユーティリティを構成します。

sysctl を使用してノードシステム構成をカスタマイズするには、メソッド awsClusters.awsNodePools.create に対する POST リクエストを作成します。この POST リクエストは、指定されたカスタマイズでノードプールを作成します。次の例では、busy_poll パラメータと busy_read パラメータがそれぞれ 5,000 マイクロ秒に構成されます。

POST https://ENDPOINT/v1/projects/PROJECT_ID/locations/GOOGLE_CLOUD_LOCATION/CLUSTER_NAME/awsNodePools

{
    "name": NODE_POOL_NAME,
    "version": CLUSTER_VERSION,
    "config": {
        "linuxNodeConfig": {
            "sysctls": {
                "net.core.busy_poll": "5000",
                "net.core.busy_read": "5000",
            }
        }
    }
}

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

• ENDPOINT: 実際の Google Cloud サービス エンドポイント。
• PROJECT_ID: 実際の Google Cloud プロジェクト ID。
• GOOGLE_CLOUD_LOCATION: クラスタのGoogle Cloud ロケーション。
• CLUSTER_NAME: ノードプールの追加先とするクラスタの名前。
• NODE_POOL_NAME: ノードプールの名前
• CLUSTER_VERSION: クラスタのバージョン番号（1.31.0-gke.500 など）。

上記の JSON リクエストに追加できるすべての Key-Value ペアについては、Sysctl 構成オプションをご覧ください。

kubelet エージェントの構成オプション

次の表に、変更可能な kubelet オプションを示します。

Kubelet 構成の設定	制限事項	デフォルト設定	説明
kubelet_config_cpu_manager_policy	値は none または static にする必要があります。	"none"	この設定は、kubelet の CPU Manager ポリシーを制御します。デフォルト値は none で、デフォルトの CPU アフィニティ スキームになります。OS スケジューラによって自動的に実行される範囲を超えるアフィニティはありません。 この値を static に設定すると、整数演算の CPU リクエストを含む保証型 QoS クラスの Pod に CPU の排他的使用を割り当てることができます。
kubelet_config_cpu_cfs_quota	値は true または false にする必要があります。	true	この設定では、Pod の CPU 上限が適用されます。この値を false に設定すると、Pod の CPU 制限は無視されます。 Pod が CPU の制限を受ける可能性がある特定のシナリオでは、CPU 制限を無視することが望ましい場合があります。cpuCFSQuota を無効にすると、誤った Pod が想定よりも多くの CPU リソースを消費するリスクがあります。
kubelet_config_cpu_cfs_quota_period	値は期間とする必要があります。	"100ms"	この設定では、CPU の CFS 割り当て期間値 cpu.cfs_period_us を設定します。この値は、cgroup による CPU リソースへのアクセス頻度を指定します。このオプションを使用すると、CPU スロットルの動作を調整できます。
kubelet_config_pod_pids_limit	値は 1024～4194304 の範囲で指定してください。	-1	この設定は、各 Pod が使用できるプロセス ID（PID）の最大数を設定します。デフォルト値に設定すると、基盤となるマシンのサイズに基づいて PID の上限が自動的に調整されます。

sysctl ユーティリティの構成オプション

システムのパフォーマンスを調整するには、次の属性を変更します。

• net.core.busy_poll
• net.core.busy_read
• net.core.netdev_max_backlog
• net.core.rmem_max
• net.core.wmem_default
• net.core.wmem_max
• net.core.optmem_max
• net.core.somaxconn
• net.ipv4.tcp_rmem
• net.ipv4.tcp_wmem
• net.ipv4.tcp_tw_reuse
• net.ipv6.conf.all.disable_ipv6
• net.ipv6.conf.default.disable_ipv6
• vm.max_map_count

Spot インスタンスのノードプール

プレビュー版

このプロダクトまたは機能は、 サービス固有の規約の対象となります。 pre-GA のプロダクトと機能は「現状のまま」で提供されるものであり、サポートが制限されることがあります。 詳細については、リリース ステージの説明をご覧ください。

GKE on AWS では、プレビュー機能として AWS Spot インスタンス ノードプールがサポートされています。Spot インスタンス ノードプールは、AWS で使用可能な低コストの Amazon EC2 Spot インスタンスのプールです。

Spot インスタンスを使用すると、柔軟性を備え、ステートレスでフォールト トレラントなアプリケーションの費用を削減できます。ただし、柔軟性に欠けるワークロードやステートフルなワークロード、フォールト トレラントでないワークロードやインスタンス ノード間で密結合されたワークロードには適していません。EC2 が容量を元に戻す必要がある場合、Amazon EC2 によって Spot インスタンスが中断される可能性があります。そのため、Spot マーケットの変動によって影響を受ける可能性があります。ワークロードで保証された容量が必要であり、利用できない期間を許容できない場合は、Spot インスタンス ノードプールではなく、標準ノードプールを選択します。

GKE on AWS で使用されている割り当て方式では、中断のリスクを最小限に抑えるため、最も高いキャパシティで空き容量のある Spot インスタンス プールを選択することに重点を置いています。この方法は、画像やメディアのレンダリングやディープ ラーニングなど、中断のコストが高いワークロードに特にメリットがあります。具体的には、capacityOptimized 割り振り戦略が実装されています（Spot インスタンスの割り振り戦略を参照）。

Spot ノードプールを作成する

Spot インスタンスのノードプールを作成するには、次のコマンドを実行します。

gcloud container aws node-pools create NODE_POOL_NAME \
    --cluster CLUSTER_NAME \
    --spot-instance-types INSTANCE_TYPE_LIST \
    --root-volume-size ROOT_VOLUME_SIZE \
    --iam-instance-profile NODEPOOL_PROFILE \
    --node-version NODE_VERSION \
    --min-nodes MIN_NODES \
    --max-nodes MAX_NODES \
    --max-pods-per-node MAX_PODS_PER_NODE \
    --location GOOGLE_CLOUD_LOCATION \
    --subnet-id NODEPOOL_SUBNET \
    --ssh-ec2-key-pair SSH_KEY_PAIR_NAME \
    --config-encryption-kms-key-arn CONFIG_KMS_KEY_ARN \
    --tags "Name=CLUSTER_NAME-NODE_POOL_NAME"

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

• NODE_POOL_NAME: このノードプールに割り当てる名前。
• CLUSTER_NAME: このノードプールを接続するクラスタの名前。
• INSTANCE_TYPE_LIST: AWS EC2 インスタンス タイプのカンマ区切りリスト。ノードプールは、これらのインスタンス タイプで Spot インスタンスをプロビジョニングします。インスタンス タイプは、同じ CPU アーキテクチャ、同じ数の CPU、同じ量のメモリを備えている必要があります。例: c6g.large,c6gd.large,c6gn.large,c7g.large,t4g.medium。CPU とメモリの構成が同じインスタンス タイプは、Amazon EC2 インスタンス セレクタ ツールで確認できます。
• ROOT_VOLUME_SIZE: 各ノードのルート ボリュームに必要なサイズ（GB）
• NODEPOOL_PROFILE: ノードプール VM の IAM インスタンス プロファイル
• NODE_VERSION: ノードプールの各ノードにインストールする Kubernetes のバージョン（例: "1.32.4-gke.200"）
• MIN_NODES: ノードプールに配置できるノードの最小数
• MAX_NODES: ノードプールに配置できるノードの最大数
• MAX_PODS_PER_NODE: プール内の任意の 1 つのノードで作成できる Pod の最大数
• GOOGLE_CLOUD_LOCATION: このノードプールを管理する Google Cloudロケーションの名前
• NODEPOOL_SUBNET: ノードプールが実行されるサブネットの ID。
  • クラスタの Pod / Service IP 範囲とノードプール サブネット ネットワークとの間に重複がないようにしてください。クラスタの Pod と Service の IP 範囲の選択について詳しくは、クラスタの CIDR 範囲を選択するをご覧ください。
  • このサブネットが VPC プライマリ CIDR ブロックの外部にある場合は、追加の手順が必要です。詳細については、セキュリティ グループをご覧ください。
• SSH_KEY_PAIR_NAME: SSH アクセス用に作成された AWS SSH 鍵ペアの名前（省略可）
• CONFIG_KMS_KEY_ARN: ユーザーデータを暗号化する AWS KMS 鍵の Amazon Resource Name（ARN）

INSTANCE_TYPE_LIST フィールドにインスタンス タイプの数を指定することをおすすめします。ノードプールが 1 つのインスタンス タイプのみで構成されており、そのインスタンス タイプが目的のアベイラビリティ ゾーンで利用できない場合、ノードプールが新しいノードをプロビジョニングできないため、このベスト プラクティスは重要です。これはアプリケーションの可用性に影響する可能性があり、サービスが中断する可能性があります。

spot-instance-types フィールドは instance-type フィールドと相互に排他的です。両方を指定することはできません。どちらか一方のフィールドを指定する必要があります。