[[["容易理解","easyToUnderstand","thumb-up"],["確實解決了我的問題","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["難以理解","hardToUnderstand","thumb-down"],["資訊或程式碼範例有誤","incorrectInformationOrSampleCode","thumb-down"],["缺少我需要的資訊/範例","missingTheInformationSamplesINeed","thumb-down"],["翻譯問題","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["上次更新時間:2025-07-31 (世界標準時間)。"],[],[],null,["# About node pools\n\n[Standard](/kubernetes-engine/docs/concepts/choose-cluster-mode)\n\n*** ** * ** ***\n\nThis page explains how node pools work in Google Kubernetes Engine (GKE). A *node\npool* is a group of [nodes](/kubernetes-engine/docs/concepts/cluster-architecture#nodes) within a cluster that all have the same\nconfiguration. In GKE Standard mode, you can choose from\na number of options for your node pools to meet your workload needs. If you\nchoose to use Autopilot, you don't need to configure node pools:\nGKE manages the nodes for you.\n\nTo learn more about creating Standard mode clusters, see [Create a\nregional cluster](/kubernetes-engine/docs/how-to/creating-a-regional-cluster)\nand [Create a zonal\ncluster](/kubernetes-engine/docs/how-to/creating-a-zonal-cluster). To learn how\nto manage node pools in existing Standard clusters, see [Adding and\nmanaging node pools](/kubernetes-engine/docs/how-to/node-pools).\n\nOverview\n--------\n\nA node pool is a group of [nodes](/kubernetes-engine/docs/concepts/cluster-architecture#nodes) within a cluster that all have the same\nconfiguration. Node pools use a [NodeConfig](/kubernetes-engine/docs/reference/rest/v1/NodeConfig) specification. Each node in the\npool has a Kubernetes node label, `cloud.google.com/gke-nodepool`, which has the\nnode pool's name as its value.\n\nWhen you create a Standard mode [cluster](/kubernetes-engine/docs/concepts/cluster-architecture), the number of nodes and type\nof nodes that you specify are used to create the first node pool of the cluster.\nBy default, this first node pool (known as the *default node pool* ) consists of\nthree nodes in each of the cluster's compute zones, with the default [node\nimage](/kubernetes-engine/docs/concepts/node-images) `cos_containerd`, and a general-purpose [machine\ntype](/compute/docs/machine-types). You can specify a variety of properties for\nthe node pool, depending on your workload requirements. For example, you might\ncreate a node pool in your cluster with [local SSDs](/kubernetes-engine/docs/concepts/local-ssd), a [minimum CPU platform](/kubernetes-engine/docs/how-to/min-cpu-platform),\n[Spot VMs](/kubernetes-engine/docs/concepts/spot-vms), a different node\nimage, different [machine types](/compute/docs/machine-types), or a more efficient [virtual network\ninterface](/kubernetes-engine/docs/how-to/using-gvnic).\n\nYou can then add additional node pools of different sizes and types to your\ncluster. All nodes in any given node pool are identical to one another.\n\nCustom node pools are useful when you need to schedule Pods that require more\nresources than others, such as more memory or more local disk space. If you need\nmore control of where Pods are scheduled, you can use [node taints](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/).\n\nYou can [create, upgrade, and delete node\npools](/kubernetes-engine/docs/how-to/node-pools) individually without affecting\nthe whole cluster. You cannot configure a single node in a node pool; any\nconfiguration changes affect all nodes in the node pool.\n\nYou can resize node pools in a cluster by [adding or removing\nnodes](/kubernetes-engine/docs/how-to/node-pools#resizing_a_node_pool).\n\nBy default, all new node pools run the same version of Kubernetes as the control\nplane. Existing node pools can be [manually upgraded](/kubernetes-engine/docs/how-to/upgrading-a-container-cluster#manually_upgrading_your_nodes) or [automatically\nupgraded](/kubernetes-engine/docs/concepts/node-auto-upgrade). You can also run multiple Kubernetes node versions on each node pool\nin your cluster, update each node pool independently, and target different node\npools for specific deployments.\n\nDeploying Services to specific node pools\n-----------------------------------------\n\nWhen you define a\n[Service](https://kubernetes.io/docs/concepts/services-networking/service/), you\ncan indirectly control which node pool it is deployed into. The node pool is\n*not* dependent on the configuration of the Service, but on the configuration of\nthe [Pod](/kubernetes-engine/docs/concepts/pod).\n\n- You can explicitly deploy a Pod to a specific node pool by setting a\n [`nodeSelector`](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/)\n in the Pod manifest. This forces a Pod to run only on nodes in that node pool.\n For an example see, [Deploying a Pod to a specific node\n pool](/kubernetes-engine/docs/how-to/node-pools#deploy).\n\n- You can [specify resource requests for the\n containers](https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/).\n The Pod only runs on nodes that satisfy the resource requests. For example,\n if the Pod definition includes a container that requires four CPUs, the\n Service does not select Pods running on nodes with two CPUs.\n\nNodes in multi-zonal clusters\n-----------------------------\n\nIf you created a\n[multi-zonal](/kubernetes-engine/docs/concepts/types-of-clusters#multi-zonal_clusters) cluster, all\nof the node pools are replicated to those zones automatically. Any new node pool\nis automatically created in those zones. Similarly, any deletions delete those\nnode pools from the additional zones as well.\n\nNote that because of this multiplicative effect, this may consume more of your\nproject's [quota](/kubernetes-engine/quotas) for a specific region when creating\nnode pools.\n\nDeleting node pools\n-------------------\n\nWhen you [delete a node\npool](/kubernetes-engine/docs/how-to/node-pools#deleting_a_node_pool),\nGKE drains all the nodes in the node pool, deleting and\nrescheduling all Pods. The draining process involves GKE deleting\nPods on each node in the node pool. Each node in a node pool is drained by\ndeleting Pods with an allotted graceful termination period of `MAX_POD`.\n`MAX_POD` is the maximum\n[`terminationGracePeriodSeconds`](https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination)\nset on the Pods scheduled on the node, with a cap of one hour.\n[`PodDisruptionBudget`](https://kubernetes.io/docs/tasks/run-application/configure-pdb/)\nsettings are not honored during node pool deletion.\n\nIf the Pods have specific node selectors, the Pods might remain in an\nunschedulable condition if no other node in the cluster satisfies the criteria.\n\nWhen a cluster is deleted, GKE does not follow this process of\ngracefully terminating the nodes by draining them. If the workloads running on a\ncluster must be gracefully terminated, use [`kubectl\ndrain`](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#drain)\nto clean up the workloads before you delete the cluster.\n\nTo delete a node pool, see [Delete a node\npool](/kubernetes-engine/docs/how-to/node-pools#deleting_a_node_pool).\n\nWhat's next\n-----------\n\n- [Learn about the cluster architecture in\n GKE](/kubernetes-engine/docs/concepts/cluster-architecture).\n - [Learn how to add and manage node pools](/kubernetes-engine/docs/how-to/node-pools).\n- [Learn how to auto-provision\n nodes](/kubernetes-engine/docs/how-to/node-auto-provisioning)."]]