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

In 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:
Click the vertical dot menu to the right of the Node Pool, then click Edit to open the manifest editor:
After you make your changes, click the Submit button.

CKS applies the updated configuration to the Node Pool.

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 the following 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 in the following example:

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

After you apply the manifest, CKS adjusts the number of Nodes in the Node Pool to match.

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 to 5 in example-nodepool, run:

Example command

kubectl scale nodepool example-nodepool --replicas 5

kubectl scale writes to targetNodes and is not compatible with Node Pools that use targetRacks (rack-based instance types such as GB200 and GB300). To scale a rack-based Node Pool, edit the manifest and update targetRacks directly, then apply with kubectl apply.

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

After the adjustment completes, 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 doesn’t 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. The following sections describe both approaches.

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

Enable Node Pool prefill

Prefill is opt in and off by default. You can enable prefill on new and existing Node Pools when creating or editing the Kubernetes manifest. For an overview of Node Pool prefill, see Node Pool prefill.

Prefill is available for all instance types except rack-scale instances, for example, gb200, gb300, which are managed at the rack level rather than at the Node level.

Prefill has two implementation requirements:

Autoscaling must be disabled. Set autoscaling: false. You cannot enable prefill and autoscaling on the same Node Pool.
The Node Pool must use computeClass: default. Prefill is not supported on Spot Node Pools.

Add a prefill block under spec in the Node Pool manifest. For example:

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
  prefill:
    enabled: true
    timeout: "24h"
    maxNodes: 3

timeout: Maximum timeout is 24 hours. Default is 24 hours.
maxNodes: Can be between 1 and 4. Default is 3.

Apply the change by editing the manifest and running kubectl apply -f example-nodepool.yaml. For an overview of prefill behavior and Node conditions, see Node Pool prefill. For full field details, see the Node Pool reference.

Target specific GPUs or CPUs

To ensure CKS schedules your workloads on the correct hardware in a cluster with different GPU types, use a combination of Kubernetes resource requests and node affinities. CKS uses these built-in Kubernetes scheduling features so you can 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 to select GPU types, and the CPU label only to select CPU types. You can’t explicitly select a specific CPU type 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 lets you schedule resources with requests and limits. When you specify only limits, Kubernetes sets the requests 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. A unique identifier called a nodeProfile references each configuration. The following sections describe 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 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, CKS automatically stages the resulting nodeProfile onto your NodePool as the default nodeProfile and onto your Nodes. Existing Nodes may need a reconfigure reboot for the configuration updates to take effect. When updates are available for your Node Pool, such as a newer ncore image, CKS also generates a new pending configuration for you. The new configuration doesn’t take effect until you stage it. See the Stage Node Pool Configurations section for an example.

Stage Node Pool configurations

How CKS applies a new configuration depends on what triggered it and your nodeConfigurationUpdateStrategy.type:

Strategy	Behavior
Manual	Updates require user intervention to stage onto the NodePool. You can inspect updates in `pendingNodeConfigurations` and apply them with the CoreWeave Intelligent CLI.
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 CoreWeave Intelligent CLI. CKS automatically applies any pending CKS-initiated changes when you make a user-initiated change to your Node Pool spec. The following example 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. After CKS applies a new configuration 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, CKS automatically stages and applies the resulting new configuration. For example, if you modify the image or gpu fields in your Node Pool spec, that’s a user-initiated update. CKS also stages any Nodes already in the Node Pool with the auto-applied NodeProfile. CKS automatically stages and applies these user-initiated Node Pool configuration updates regardless of which tools you use to update your Node Pool (including kubectl, Cloud Console, GitOps or cwic). The following example shows a properly configured Node Pool with 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

GitOps tools such as ArgoCD are the primary way to manage your Node Pool configuration in environments where you don’t have a kubeconfig or the correct permissions. Because CKS auto-stages user-initiated updates to the Node Pool configuration with the default OnSpecUpdate strategy, you don’t need to take any further action when you update your Node Pool configuration with GitOps aside from reconfigure rebooting existing Nodes. The following example shows a git diff of the minimum required YAML updates to set the GPU version to 570:

spec:
+  gpu:
+    version: "570"
-    version: "560"

This workflow is purely declarative: what you merge in Git is the spec. When the GitOps operation syncs, the spec changes and CKS stages the new Node Profile automatically.

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 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 you stage 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 a reconfiguration reboot to apply the new Node Profile. For more information on how to perform a reconfigure reboot, see Apply Node Pool updates.

Roll back to a previous Node configuration

You can roll back to a previous configuration. The nodeConfigurationRevisions enumerates all configurations previously applied to the Node Pool for your reference. If you want to manually roll back a configuration, you must set your nodeConfigurationUpdateStrategy to Manual so that a new auto-staged configuration doesn’t overwrite it. With the CoreWeave Intelligent CLI (cwic) rollback command, you can omit the nodeProfile identifier to roll back 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, CKS sets your active status.nodeProfile 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 Stage Node Pool configurations for more details.

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

Manually update `ncore` image

In environments where automated configuration updates aren’t available, you can request a manual ncore image update from CoreWeave Support. To request support with updating your ncore images, complete the following steps:

Check the ncore versions on your Nodes 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 you get your ncore image versions, contact Support to request a reboot of your Nodes to upgrade your ncore images. Before you contact Support, identify the specific ncore image you want to update to. This lets Support monitor and confirm that Nodes upgrade successfully. For instructions on contacting support, see Contact Support.

Delete a Node Pool using the Cloud Console

In 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 you delete it. CKS doesn’t 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.

​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

​Enable Node Pool prefill

​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`

Enable Node Pool prefill

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