Manage Node Pools - CoreWeave Docs

This page explains how to modify, delete, and inspect Node Pools in CKS. Use it when you need to scale workloads, update hardware configurations, or remove unused resources. You can modify Node Pools after creation, either by editing them in the Cloud Console, or by deploying an adjusted manifest with Kubernetes. To reboot Nodes in a Node Pool, see Reboot Nodes.

Modify a Node Pool using the Cloud Console

To modify a Node Pool using the Cloud Console, navigate to Node Pools.
All existing Node Pools are listed on the Node Pool dashboard, including the Node Pool containing Control Plane CPU Nodes:
To modify a deployed Node Pool, click the vertical dot menu to the right of the Node Pool, then click Edit to open the manifest editor:
After making the desired changes, click the Submit button.

Changes may take a moment to display on the Cloud Console. To learn more about the current status of the Node Pool, hover over the status in the dashboard.

Modify a Node Pool using Kubernetes

To modify a Node Pool, first edit the Node Pool manifest, then apply the changed manifest using kubectl. For example, take a Node Pool deployed with this manifest:

example-nodepool.yaml

apiVersion: compute.coreweave.com/v1alpha1
kind: NodePool
metadata:
  name: example-nodepool
spec:
  computeClass: default
  instanceType: gd-8xh100ib-i128
  autoscaling: false
  targetNodes: 10
  minNodes: 0
  maxNodes: 0

This manifest deploys a Node Pool with 10 Nodes. To change it to have only 5 Nodes, first adjust the manifest to change the targetNodes value to 5 as highlighted here:

example-nodepool.yaml

apiVersion: compute.coreweave.com/v1alpha1
kind: NodePool
metadata:
  name: example-nodepool
spec:
  computeClass: default
  instanceType: gd-8xh100ib-i128
  autoscaling: false
  targetNodes: 5
  minNodes: 0
  maxNodes: 0

To apply the changes, apply the updated manifest using kubectl:

Example command

kubectl apply -f example-nodepool.yaml

Once the manifest is applied, CKS adjusts the number of Nodes in the Node Pool accordingly.

Removing Nodes from a Node Pool can take some time.
See Scaling strategies to learn how CKS responds when the value of targetNodes changes.

Use `kubectl scale`

You can also use kubectl to adjust targetNodes without editing the manifest directly. For example, to set targetNodes for example-nodepool to 5 Nodes, run:

Example command

kubectl scale nodepool example-nodepool --replicas 5

Verify the updated Node Pool

To check the status of the modified Node Pool, target the Node Pool with kubectl get nodepool. For example:

Example command

kubectl get nodepool example-nodepool

This returns information about the current status of the targeted Node Pool, such as:

Example output

NAME               INSTANCE TYPE   TARGET   INPROGRESS   CURRENT   VALIDATED   CAPACITY     QUOTA   AGE
example-nodepool   gd-1xgh200      1                     1         Valid       Sufficient   Under   42h

Once the adjustment is complete, the value of CURRENT (the number of Nodes currently in the Node Pool) should match the value of TARGET (the number of Nodes desired in the Node Pool). To see further details about the Node Pool in YAML format, target the Node Pool with kubectl get nodepool -o yaml.

Example command

kubectl get nodepool example-nodepool -o yaml

If you need to reboot a Node or Node Pool, see Reboot Nodes.

View Node details

Standard kubectl get nodes output does not include CoreWeave-specific metadata such as instance type, reservation status, ncore version, and Node state. Use the CoreWeave Intelligent CLI (cwic) or a custom kubectl command to view these details.

Use CoreWeave Intelligent CLI

For installation and authentication instructions, see the CoreWeave Intelligent CLI repository. To list all Nodes in your cluster with CoreWeave-specific details, run:

cwic node get

This returns Node information including the instance type, reservation status, Node Pool, ncore version, and lifecycle state:

Example output

NAME      IP              TYPE               RESERVED   NODEPOOL           READY   ACTIVE   CORDON   RECONFIGURE   VERSION   STATE        PENDING STATE
g1f0000   10.176.222.21   gd-8xh100ib-i128   012345     example-nodepool   true    true     false    NotRequired   2.26.0    production   none
g400000   10.176.207.22   cd-hp-a96-genoa    012345     example-nodepool   true    true     false    NotRequired   2.26.0    production   none

To list Nodes in a specific Node Pool, run:

cwic nodepool nodes get [NODEPOOL-NAME]

Use kubectl

To view CoreWeave-specific Node details with kubectl, add the following alias to your shell configuration:

alias nodes="kubectl get nodes -o=custom-columns=\"NAME:metadata.name,IP:status.addresses[?(@.type=='InternalIP')].address,TYPE:metadata.labels['node\.coreweave\.cloud\/type'],RESERVED:metadata.labels['node\.coreweave\.cloud\/reserved'],READY:status.conditions[?(@.type=='Ready')].status,CORDON:spec.unschedulable,VERSION:metadata.labels['node\.coreweave\.cloud\/version'],STATE:metadata.labels['node\.coreweave\.cloud\/state']\""

Then run:

nodes

Example output

NAME      IP              TYPE               RESERVED   READY   CORDON   VERSION   STATE
g1f0000   10.176.222.21   gd-8xh100ib-i128   012345     True    <none>   2.26.0    production
g400000   10.176.207.22   cd-gp-i64-erapids  012345     True    <none>   2.33.0    production

Target specific GPUs or CPUs

To ensure your workloads are scheduled on the correct hardware in a cluster with different GPU types, use a combination of Kubernetes resource requests and node affinities. CKS uses these native Kubernetes scheduling features, giving you maximum flexibility to allocate resources for your workloads:

label	Use case
`gpu.nvidia.com/class` or `gpu.nvidia.com/model`	Use when you want to select Nodes with a cloud-neutral label.
`node.coreweave.cloud/type`	Use when you want to select a CoreWeave specific instance type.
`node.coreweave.cloud/cpu`	Use when you want to select a specific CPU type.

These labels are mutually exclusive: use the GPU label only for selecting GPU types, and the CPU label only for selecting CPU types. A specific CPU type cannot be explicitly selected for GPU Nodes.

Example specs

Select one of the following example specs:

8xH100
8xB300
8xRTX Pro 6000

spec:
  containers:
  - name: example
    resources:
      requests:
        cpu: 120
        memory: 1800Gi
      limits:
        nvidia.com/gpu: 8

  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: node.coreweave.cloud/type
            operator: In
            values:
              - gd-8xh100ib-i128

spec:
  containers:
  - name: example
    resources:
      requests:
        cpu: 180
        memory: 3800Gi
      limits:
        nvidia.com/gpu: 8

  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: node.coreweave.cloud/type
            operator: In
            values:
              - b300-8x

spec:
  containers:
  - name: example
    resources:
      requests:
        cpu: 120
        memory: 900Gi
      limits:
        nvidia.com/gpu: 8

  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: node.coreweave.cloud/type
            operator: In
            values:
              - rtxp6000-8x

Kubernetes allows resources to be scheduled with requests and limits. When only limits are specified, the requests are set to the same amount as the limit.

Manage Node Pool configuration

CKS uses Node Pool configurations to boot Nodes into a desired state. Configurations contain information like the ncore (OS) image and GPU Driver version. Configurations are referenced by their unique identifier, which is called a nodeProfile. The sections below explain how CKS generates configurations, how to stage a pending configuration, and how to roll back to a previous one. To see a Node Pool’s active configuration, inspect the status.nodeProfile and the status.nodeConfigurationRevisions, which displays information for all the configurations that have been staged onto your Node Pool, including the active one.

example-nodepool.yaml

apiVersion: compute.coreweave.com/v1alpha1
kind: NodePool
metadata:
  name: example-nodepool
spec:
  instanceType: gd-8xh100ib-i128
  targetNodes: 1
status:
  currentNodes: 1
  nodeConfigurationRevisions:
  - activeNodes: 1
    createdAt: "2026-01-05T16:50:23Z"
    nodeProfile: tnt-v2-75e00e7d8b223b100521280041ba22f790591c98
    summary:
    - 'NCore Version: 2.26.0'
    - 'GPU Driver Version: 580.105.08-0ubuntu1'
    - 'K8s Version: v1.35'
  nodeProfile: tnt-v2-75e00e7d8b223b100521280041ba22f790591c98

Generate Node Pool configurations

CKS generates Node Pool configurations based on the Node Pool spec. If you modify the following fields in your Node Pool spec, CKS generates a new configuration for you:

With the default nodeConfigurationUpdateStrategy.type OnSpecUpdate, the resulting nodeProfile is automatically staged onto your NodePool as the default nodeProfile and staged onto your Nodes. Existing Nodes may need a reconfigure reboot for the configuration updates to take effect. Additionally, when updates are available for your Node Pool, such as a newer ncore image, CKS generates a new pending configuration for you. The new configuration does not take effect until you stage it. See the Stage Node Pool Configurations section for an example.

Stage Node Pool configurations

How a new configuration is applied depends on what triggered it and your nodeConfigurationUpdateStrategy.type:

Strategy	Behavior
Manual	Updates require user intervention to stage onto NodePool. Updates can be inspected in the `pendingNodeConfigurations` and applied with `cwic`.
OnSpecUpdate	Updates are staged automatically only if triggered by a direct change to the NodePool spec (for example, modifying the GPU driver version).
Always	Updates are staged automatically for both user-initiated spec changes and any available upstream updates.

To stage a pending configuration, see the CoreWeave Intelligent CLI section below for more details. Any pending CKS-initiated changes are automatically applied when you make a user-initiated change to your Node Pool spec. The example below shows a Node Pool with a CKS-initiated pending configuration that requires manual acceptance.

example-nodepool.yaml

apiVersion: compute.coreweave.com/v1alpha1
kind: NodePool
metadata:
  name: example-nodepool
spec:
  instanceType: gd-8xh100ib-i128
  nodeConfigurationUpdateStrategy:
    type: Manual
  targetNodes: 1
status:
  currentNodes: 1
  nodeConfigurationRevisions:
  - activeNodes: 1
    createdAt: "2026-01-05T16:50:23Z"
    nodeProfile: tnt-v2-75e00e7d8b223b100521280041ba22f790591c98
    summary:
    - 'NCore Version: 2.26.0'
    - 'GPU Driver Version: 580.105.08-0ubuntu1'
    - 'K8s Version: v1.35'
  nodeProfile: tnt-v2-75e00e7d8b223b100521280041ba22f790591c98
  # This pending configuration must be manually applied to take effect
  pendingNodeConfiguration:
    createdAt: "2026-01-08T14:00:33Z"
    nodeProfile: tnt-v2-8f8ce337708c526919218d747756ae655afe1cda
    summary:
    - 'NCore Version: 2.27.0'
    - 'GPU Driver Version: 580.105.08-0ubuntu1'
    - 'K8s Version: v1.35'

Before staging the configuration (CKS-initiated change), inspect the features in the pendingNodeConfiguration. Staging the configuration sets it as the active status.nodeProfile and tracks it in the nodeConfigurationRevisions. Once a new configuration is applied to the Node Pool, new Nodes boot into the desired configuration. Existing Nodes in your Node Pool may need a reconfigure reboot to pick up the new configuration. For more information, see CoreWeave Intelligent CLI.

User-initiated updates

With OnSpecUpdate set as your nodeConfigurationUpdateStrategy, when you initiate an update to your Node Pool, the resulting new configuration is automatically staged and applied. For example, if you modify the image or gpu fields in your Node Pool spec, that is a user-initiated update. Additionally, any Nodes already in the Node Pool are staged with the auto-applied NodeProfile. These user-initiated Node Pool configuration updates are automatically staged and applied regardless of which tools you use to update your Node Pool (including kubectl, Cloud Console, GitOps or cwic). The example below shows a Node Pool that has been configured properly and shows an automatically staged configuration:

example-nodepool.yaml

apiVersion: compute.coreweave.com/v1alpha1
kind: NodePool
metadata:
  name: example-nodepool
spec:
  instanceType: gd-8xh100ib-i128
  nodeConfigurationUpdateStrategy:
    type: OnSpecUpdate
  targetNodes: 1
  gpu:
    version: "570"
status:
  currentNodes: 1
  nodeConfigurationRevisions:
  - activeNodes: 1
    createdAt: "2026-01-05T16:50:23Z"
    nodeProfile: tnt-v2-75e00e7d8b223b100521280041ba22f790591c98
    summary:
    - 'NCore Version: 2.26.0'
    - 'GPU Driver Version: 580.105.08-0ubuntu1'
    - 'K8s Version: v1.35'
  nodeProfile: tnt-v2-75e00e7d8b223b100521280041ba22f790591c98

GitOps

Using GitOps tools such as ArgoCD is the primary way to manage your Node Pool configuration in environments where you do not have a kubeconfig or the correct permissions. Since user-initiated updates to the Node Pool configuration are auto-staged with the default OnSpecUpdate strategy, you don’t need to take any further action when updating your Node Pool configuration with GitOps aside from reconfigure rebooting existing Nodes. Below is an example git diff of the minimum required YAML updates to set GPU version to 570:

+# In git - user changes GPU version
spec:
+  gpu:
+    version: "570"
-    version: "560"
+# GitOps operation syncs → spec changes → nodeProfile staged automatically
+# Purely declarative -- what is merged in Git is the spec

Cloud Console

Similar to kubectl and GitOps workflows, you can make updates to the Node Pool manifest in the Cloud Console. Doing so automatically stages a new Node Profile on the status.nodeProfile field and stages any existing Nodes in the Node Pool. New Nodes boot into this newly staged Node Profile. The following example shows a GPU update being made to the Node Pool:

Screenshot showing the Node Pool edit page with a GPU version change.

CoreWeave Intelligent CLI

Use the CoreWeave Intelligent CLI (cwic) to stage a pending configuration. After staging the configuration, only newly created Nodes use the configuration. You need to initiate a reconfigure reboot on the existing Nodes in the Node Pool to Apply Node Pool updates. The following steps walk through how to stage a pending configuration.

To see which Node Pools have a pending configuration:

cwic nodepool get [NODEPOOL-NAME]

NODEPOOL_NAME: Replace with the name of your Node Pool.

The PENDING CONFIG column lists the Node Pools with a new configuration that you can stage to the Node Pool:

NAME               INSTANCE TYPE      TARGET   QUEUED   INPROGRESS   CURRENT   PENDING CONFIG   STAGED NODES   REQUIRING RECONFIG
example-nodepool   gd-8xl40-i128      1        0        0            1         true             false          0/1

Stage the new Node Pool configuration:
Example command
```
cwic nodepool upgrade [NODEPOOL-NAME]
```
- NODEPOOL-NAME: Replace with the name of your Node Pool.
You can see the new Node Profile updates and confirm whether to proceed with staging them.
To determine which existing Nodes in the Node Pool need the new configuration:
Example command
```
cwic nodepool nodes get [NODEPOOL-NAME] [-r|--requiring-reconfiguration]
```
- NODEPOOL-NAME: Replace with the name of your Node Pool.
Example output (see the RECONFIGURE column)
```
NAME      IP               TYPE               RESERVED   NODEPOOL            READY   ACTIVE   CORDON   RECONFIGURE   VERSION   STATE        PENDING STATE
node-0    10.x.y.z         gd-8xh100ib-i128   org123     example-nodepool    true    true     false    Required      2.26.0    production   none
```
In this example, node-0 needs to be rebooted with a reconfiguration reboot to have the new Node Profile applied. See Applying Node Pool Configuration Updates for more information how to perform a reconfigure reboot.

Roll back to a previous Node configuration

You can roll back to a previous configuration. All configurations that were previously applied to the Node Pool are enumerated in the nodeConfigurationRevisions for your reference. If you want to manually roll back a configuration, you must set your nodeConfigurationUpdateStrategy to Manual so that it does not get overwritten by a new auto-staged configuration. With the CoreWeave Intelligent CLI (cwic) rollback command, you can omit the nodeProfile identifier to perform a simple rollback to the previous configuration, or you can specify a nodeProfile to roll back to an exact configuration.

Example command

cwic nodepool rollback [NODEPOOL-NAME] [NODEPROFILE]

NODEPOOL-NAME: Replace with the name of your Node Pool.
NODEPROFILE: Replace with the Node Profile you want to roll back to.

When you perform a rollback, your active status.nodeProfile is set to the desired configuration. Any new Nodes delivered to your Node Pool boot into the rolled-back configuration, and existing Nodes in your cluster may require a reconfigure reboot to pick up the configuration. See the section above for more details.

The nodeConfigurationRevisions is subject to garbage collection. For any given Node Pool, at most 5 inactive configurations are tracked and available for rollback. If there are 6 or more inactive configurations, CKS removes them starting from the oldest.

Manually update `ncore` image

To request support with updating your ncore images, complete the following steps:

Check the ncore versions on your Nodes by using grep and ncore-image. Replace [NODE-ID] with your Node ID:

kubectl describe node [NODE-ID] | grep ncore-image

This returns the ncore image tag and type, for example:

node.coreweave.cloud/ncore-image-tag=2.24.1
node.coreweave.cloud/ncore-image-type=ofed-5.8-3.0.7.0

To see the ncore image for all Nodes in a given Node Pool, replace [NODE-POOL-NAME] with the name of your Node Pool:

kubectl get nodes -l compute.coreweave.com/node-pool=[NODE-POOL-NAME] \
-o go-template='{{range .items}}{{.metadata.name}}{{"\t"}}{{"ncore-image-"}}{{index .metadata.labels "node.coreweave.cloud/ncore-image-tag"}}{{"-"}}{{index .metadata.labels "node.coreweave.cloud/ncore-image-type"}}{{"\n"}}{{end}}'

After getting your ncore image versions, contact Support to request a reboot of your Nodes to upgrade your ncore images. Before contacting Support, identify the specific ncore image you want to update to. This enables Support to monitor and confirm that Nodes have upgraded successfully. See the following instructions for contacting support: Contact Support.

Delete a Node Pool using the Cloud Console

To delete a Node Pool using the Cloud Console, navigate to Node Pools.
Click the vertical dot menu beside the Node Pool to delete, then click Delete to open the confirmation modal.

Screenshot showing the modal for deleting Node Pools

Enter the name of the Node Pool to confirm deletion. The dashboard updates immediately, removing the deleted Node Pool from the list.

Delete a Node Pool using Kubernetes

To delete a Node Pool using Kubernetes, delete the Node Pool resource directly using kubectl:

kubectl delete nodepool example-nodepool

Deleting the nodepool resource first removes all Nodes associated with the Node Pool from the cluster, then deletes the Node Pool resource itself.

To avoid data loss when removing Node Pools, first ensure nothing is running in the Node Pool before deleting it. CKS does not wait for workloads to complete before removing Nodes.

Next steps

Reboot Nodes to reboot Nodes manually.
Apply Node Pool updates to apply Node Pool updates by queuing a reconfigure reboot.
Connect to a Node to troubleshoot issues with a Node.

CoreWeave Kubernetes Service

Documentation Index

​Modify a Node Pool using the Cloud Console

​Modify a Node Pool using Kubernetes

​Use kubectl scale

​Verify the updated Node Pool

​View Node details

​Use CoreWeave Intelligent CLI

​Use kubectl

​Target specific GPUs or CPUs

​Example specs

​Manage Node Pool configuration

​Generate Node Pool configurations

​Stage Node Pool configurations

​User-initiated updates

​GitOps

​Cloud Console

​CoreWeave Intelligent CLI

​Roll back to a previous Node configuration

​Manually update ncore image

​Delete a Node Pool using the Cloud Console

​Delete a Node Pool using Kubernetes

​Next steps

Modify a Node Pool using the Cloud Console

Modify a Node Pool using Kubernetes

Use `kubectl scale`

Verify the updated Node Pool

View Node details

Use CoreWeave Intelligent CLI

Use kubectl

Target specific GPUs or CPUs

Example specs

Manage Node Pool configuration

Generate Node Pool configurations

Stage Node Pool configurations

User-initiated updates

GitOps

Cloud Console

CoreWeave Intelligent CLI

Roll back to a previous Node configuration

Manually update `ncore` image

Delete a Node Pool using the Cloud Console

Delete a Node Pool using Kubernetes

Next steps