2017-03-21 22:20:38 +00:00
---
layout: "google"
page_title: "Google: google_container_node_pool"
sidebar_current: "docs-google-container-node-pool"
description: |-
Manages a GKE NodePool resource.
---
# google\_container\_node\_pool
2019-01-31 21:37:33 +00:00
Manages a node pool in a Google Kubernetes Engine (GKE) cluster separately from
the cluster control plane. For more information see [the official documentation ](https://cloud.google.com/container-engine/docs/node-pools )
and [the API reference ](https://cloud.google.com/container-engine/reference/rest/v1/projects.zones.clusters.nodePools ).
### Example Usage - using a separately managed node pool (recommended)
```hcl
resource "google_container_cluster" "primary" {
2019-03-13 16:32:46 +00:00
name = "my-gke-cluster"
location = "us-central1"
2019-01-31 21:37:33 +00:00
# We can't create a cluster with no node pool defined, but we want to only use
# separately managed node pools. So we create the smallest possible default
# node pool and immediately delete it.
remove_default_node_pool = true
initial_node_count = 1
}
resource "google_container_node_pool" "primary_preemptible_nodes" {
name = "my-node-pool"
2019-03-13 16:32:46 +00:00
location = "us-central1"
2019-01-31 21:37:33 +00:00
cluster = "${google_container_cluster.primary.name}"
node_count = 1
node_config {
preemptible = true
machine_type = "n1-standard-1"
oauth_scopes = [
"https://www.googleapis.com/auth/compute",
"https://www.googleapis.com/auth/devstorage.read_only",
"https://www.googleapis.com/auth/logging.write",
"https://www.googleapis.com/auth/monitoring",
]
}
}
```
### Example Usage - 2 node pools, 1 separately managed + the default node pool
2017-03-21 22:20:38 +00:00
2017-04-17 10:17:54 +00:00
```hcl
2017-03-21 22:20:38 +00:00
resource "google_container_node_pool" "np" {
2018-03-08 17:08:14 +00:00
name = "my-node-pool"
2019-03-13 16:32:46 +00:00
location = "us-central1-a"
2018-03-08 17:08:14 +00:00
cluster = "${google_container_cluster.primary.name}"
node_count = 3
2019-02-01 21:26:59 +00:00
timeouts {
create = "30m"
update = "20m"
}
2017-03-21 22:20:38 +00:00
}
resource "google_container_cluster" "primary" {
name = "marcellus-wallace"
2019-03-13 16:32:46 +00:00
location = "us-central1-a"
2017-03-21 22:20:38 +00:00
initial_node_count = 3
2019-03-13 16:32:46 +00:00
node_locations = [
2017-03-21 22:20:38 +00:00
"us-central1-c",
]
2019-01-31 21:37:33 +00:00
# Setting an empty username and password explicitly disables basic auth
2017-03-21 22:20:38 +00:00
master_auth {
2019-01-31 21:37:33 +00:00
username = ""
password = ""
2017-03-21 22:20:38 +00:00
}
node_config {
oauth_scopes = [
"https://www.googleapis.com/auth/compute",
"https://www.googleapis.com/auth/devstorage.read_only",
"https://www.googleapis.com/auth/logging.write",
"https://www.googleapis.com/auth/monitoring",
]
2018-03-08 17:08:14 +00:00
guest_accelerator {
type = "nvidia-tesla-k80"
count = 1
}
2017-03-21 22:20:38 +00:00
}
}
2018-03-08 17:08:14 +00:00
```
#1300 Supporting regional clusters for node pools (#1320)
This PR also switched us to using the beta API in all cases, and that had a side effect which is worth noting, note included here for posterity.
=====
The problem is, we add a GPU, and as per the docs, GKE adds a taint to
the node pool saying "don't schedule here unless you tolerate GPUs",
which is pretty sensible.
Terraform doesn't know about that, because it didn't ask for the taint
to be added. So after apply, on refresh, it sees the state of the world
(1 taint) and the state of the config (0 taints) and wants to set the
world equal to the config. This introduces a diff, which makes the test
fail - tests fail if there's a diff after they run.
Taints are a beta feature, though. :) And since the config doesn't
contain any taints, terraform didn't see any beta features in that node
pool ... so it used to send the request to the v1 API. And since the v1
API didn't return anything about taints (since they're a beta feature),
terraform happily checked the state of the world (0 taints I know about)
vs the config (0 taints), and all was well.
This PR makes every node pool refresh request hit the beta API. So now
terraform finds out about the taints (which were always there) and the
test fails (which it always should have done).
The solution is probably to write a little bit of code which suppresses
the report of the diff of any taint with value 'nvidia.com/gpu', but
only if GPUs are enabled. I think that's something that can be done.
2018-04-25 00:55:21 +00:00
2019-01-31 21:37:33 +00:00
## Argument Reference
#1300 Supporting regional clusters for node pools (#1320)
This PR also switched us to using the beta API in all cases, and that had a side effect which is worth noting, note included here for posterity.
=====
The problem is, we add a GPU, and as per the docs, GKE adds a taint to
the node pool saying "don't schedule here unless you tolerate GPUs",
which is pretty sensible.
Terraform doesn't know about that, because it didn't ask for the taint
to be added. So after apply, on refresh, it sees the state of the world
(1 taint) and the state of the config (0 taints) and wants to set the
world equal to the config. This introduces a diff, which makes the test
fail - tests fail if there's a diff after they run.
Taints are a beta feature, though. :) And since the config doesn't
contain any taints, terraform didn't see any beta features in that node
pool ... so it used to send the request to the v1 API. And since the v1
API didn't return anything about taints (since they're a beta feature),
terraform happily checked the state of the world (0 taints I know about)
vs the config (0 taints), and all was well.
This PR makes every node pool refresh request hit the beta API. So now
terraform finds out about the taints (which were always there) and the
test fails (which it always should have done).
The solution is probably to write a little bit of code which suppresses
the report of the diff of any taint with value 'nvidia.com/gpu', but
only if GPUs are enabled. I think that's something that can be done.
2018-04-25 00:55:21 +00:00
2019-01-31 21:37:33 +00:00
* `cluster` - (Required) The cluster to create the node pool for. Cluster must be present in `zone` provided for zonal clusters.
#1300 Supporting regional clusters for node pools (#1320)
This PR also switched us to using the beta API in all cases, and that had a side effect which is worth noting, note included here for posterity.
=====
The problem is, we add a GPU, and as per the docs, GKE adds a taint to
the node pool saying "don't schedule here unless you tolerate GPUs",
which is pretty sensible.
Terraform doesn't know about that, because it didn't ask for the taint
to be added. So after apply, on refresh, it sees the state of the world
(1 taint) and the state of the config (0 taints) and wants to set the
world equal to the config. This introduces a diff, which makes the test
fail - tests fail if there's a diff after they run.
Taints are a beta feature, though. :) And since the config doesn't
contain any taints, terraform didn't see any beta features in that node
pool ... so it used to send the request to the v1 API. And since the v1
API didn't return anything about taints (since they're a beta feature),
terraform happily checked the state of the world (0 taints I know about)
vs the config (0 taints), and all was well.
This PR makes every node pool refresh request hit the beta API. So now
terraform finds out about the taints (which were always there) and the
test fails (which it always should have done).
The solution is probably to write a little bit of code which suppresses
the report of the diff of any taint with value 'nvidia.com/gpu', but
only if GPUs are enabled. I think that's something that can be done.
2018-04-25 00:55:21 +00:00
2019-01-31 21:37:33 +00:00
- - -
2017-03-21 22:20:38 +00:00
2019-03-13 16:32:46 +00:00
* `location` - (Optional) The location (region or zone) in which the cluster
resides.
#1300 Supporting regional clusters for node pools (#1320)
This PR also switched us to using the beta API in all cases, and that had a side effect which is worth noting, note included here for posterity.
=====
The problem is, we add a GPU, and as per the docs, GKE adds a taint to
the node pool saying "don't schedule here unless you tolerate GPUs",
which is pretty sensible.
Terraform doesn't know about that, because it didn't ask for the taint
to be added. So after apply, on refresh, it sees the state of the world
(1 taint) and the state of the config (0 taints) and wants to set the
world equal to the config. This introduces a diff, which makes the test
fail - tests fail if there's a diff after they run.
Taints are a beta feature, though. :) And since the config doesn't
contain any taints, terraform didn't see any beta features in that node
pool ... so it used to send the request to the v1 API. And since the v1
API didn't return anything about taints (since they're a beta feature),
terraform happily checked the state of the world (0 taints I know about)
vs the config (0 taints), and all was well.
This PR makes every node pool refresh request hit the beta API. So now
terraform finds out about the taints (which were always there) and the
test fails (which it always should have done).
The solution is probably to write a little bit of code which suppresses
the report of the diff of any taint with value 'nvidia.com/gpu', but
only if GPUs are enabled. I think that's something that can be done.
2018-04-25 00:55:21 +00:00
2019-03-13 16:32:46 +00:00
* `zone` - (Optional, Deprecated) The zone in which the cluster resides. `zone`
has been deprecated in favor of `location` .
2017-03-21 22:20:38 +00:00
2019-03-13 16:32:46 +00:00
* `region` - (Optional, Deprecated) The region in which the cluster resides (for
regional clusters). `zone` has been deprecated in favor of `location` .
-> Note: You must specify a `location` for either cluster type or the
type-specific `region` for regional clusters / `zone` for zonal clusters.
2017-03-21 22:20:38 +00:00
- - -
2017-10-27 22:18:34 +00:00
* `autoscaling` - (Optional) Configuration required by cluster autoscaler to adjust
the size of the node pool to the current cluster usage. Structure is documented below.
2018-03-13 18:45:01 +00:00
* `initial_node_count` - (Optional) The initial node count for the pool. Changing this will force
recreation of the resource.
2017-03-21 22:20:38 +00:00
2017-11-21 20:56:29 +00:00
* `management` - (Optional) Node management configuration, wherein auto-repair and
auto-upgrade is configured. Structure is documented below.
2018-11-14 18:59:58 +00:00
* `max_pods_per_node` - (Optional, [Beta ](https://terraform.io/docs/providers/google/provider_versions.html )) The maximum number of pods per node in this node pool.
2018-09-13 00:49:26 +00:00
Note that this does not work on node pools which are "route-based" - that is, node
pools belonging to clusters that do not have IP Aliasing enabled.
2017-03-21 22:20:38 +00:00
* `name` - (Optional) The name of the node pool. If left blank, Terraform will
auto-generate a unique name.
2017-10-27 22:18:34 +00:00
* `node_config` - (Optional) The node configuration of the pool. See
2017-11-21 20:56:29 +00:00
[google_container_cluster ](container_cluster.html ) for schema.
2017-07-31 16:28:39 +00:00
2018-03-13 18:45:01 +00:00
* `node_count` - (Optional) The number of nodes per instance group. This field can be used to
update the number of nodes per instance group but should not be used alongside `autoscaling` .
2017-07-31 16:28:39 +00:00
2018-03-12 20:59:47 +00:00
* `project` - (Optional) The ID of the project in which to create the node pool. If blank,
2017-10-27 22:18:34 +00:00
the provider-configured project will be used.
2017-10-25 21:08:48 +00:00
2018-03-29 20:27:11 +00:00
* `version` - (Optional) The Kubernetes version for the nodes in this pool. Note that if this field
and `auto_upgrade` are both specified, they will fight each other for what the node version should
2019-03-06 23:12:33 +00:00
be, so setting both is highly discouraged. While a fuzzy version can be specified, it's
recommended that you specify explicit versions as Terraform will see spurious diffs
when fuzzy versions are used. See the `google_container_engine_versions` data source's
`version_prefix` field to approximate fuzzy versions in a Terraform-compatible way.
2018-03-29 20:27:11 +00:00
2017-07-26 20:21:51 +00:00
The `autoscaling` block supports:
2019-03-07 16:59:09 +00:00
* `min_node_count` - (Required) Minimum number of nodes in the NodePool. Must be >=0 and
2017-09-06 20:57:00 +00:00
< = `max_node_count` .
2017-07-26 20:21:51 +00:00
2017-09-06 20:57:00 +00:00
* `max_node_count` - (Required) Maximum number of nodes in the NodePool. Must be >= min_node_count.
2017-08-07 17:35:39 +00:00
2017-11-21 20:56:29 +00:00
The `management` block supports:
* `auto_repair` - (Optional) Whether the nodes will be automatically repaired.
* `auto_upgrade` - (Optional) Whether the nodes will be automatically upgraded.
2019-02-01 21:26:59 +00:00
< a id = "timeouts" > < / a >
## Timeouts
`google_container_node_pool` provides the following
[Timeouts ](/docs/configuration/resources.html#timeouts ) configuration options:
- `create` - (Default `30 minutes` ) Used for adding node pools
- `update` - (Default `10 minutes` ) Used for updates to node pools
- `delete` - (Default `10 minutes` ) Used for removing node pools.
2017-08-07 17:35:39 +00:00
## Import
2018-06-14 16:54:08 +00:00
Node pools can be imported using the `project` , `zone` , `cluster` and `name` . If
the project is omitted, the default provider value will be used. Examples:
2017-08-07 17:35:39 +00:00
```
2018-06-14 16:54:08 +00:00
$ terraform import google_container_node_pool.mainpool my-gcp-project/us-east1-a/my-cluster/main-pool
2017-08-07 17:35:39 +00:00
$ terraform import google_container_node_pool.mainpool us-east1-a/my-cluster/main-pool
2017-10-03 17:46:33 +00:00
```