Skip to main content
This guide walks you through creating a CoreWeave Kubernetes Service (CKS) cluster using the Cloud Console. Follow these steps to provision a new cluster, configure its network and authentication settings, and verify that it deploys successfully. This guide is intended for users who manage CKS clusters and want to use the Cloud Console UI rather than the API or infrastructure-as-code tools.

​
Create a cluster using the Cloud Console

To create a new CKS cluster using the Cloud Console, open the Cluster Dashboard. From here, you can create new CKS clusters, or view and manage deployed ones. If you don’t yet have any clusters, this dashboard is empty: A screenshot of the Cloud Console cluster dashboard, with no current clusters To begin creating a cluster, click the Create Cluster button.

​
1. Setup

Give your cluster a name. Reflect the location in the name so clusters stay organized at scale. Here are some guidelines:
  • Keep names short and put the location first so that they group together naturally in reports.
  • Use only lowercase letters, numbers, and hyphens to keep names compatible with URLs and automation.
  • Avoid mutable details like Kubernetes version, Node Pool sizes, or temporary attributes that may change.
Here are some example names to use as a starting point, where [short_name] is a concise descriptor of an environment, lifecycle, or workload:
  • use04a-[short_name], such as use04a-prod or use04a-staging
  • us-east-04a-[short_name], such as us-east-04a-prod or us-east-04a-staging
Select a Kubernetes version from the dropdown list of supported versions. CKS supports the latest three versions of Kubernetes. See Cluster Components for more information about supported versions. A screenshot of the first step to creating a cluster, labeled "Setup" Select whether you want your cluster to access the Kubernetes API through the internet.
CKS only supports public clusters as a self-service option. To set up a private cluster, contact CoreWeave Support.
To configure a custom Audit Policy for the cluster, select the Custom Audit Policy checkbox to open the Audit Policy YAML editor.
To learn more about cluster Audit Policies, see the official Kubernetes documentation.
A screenshot of the Audit Policy editing window Use this window to edit the Audit Policy configuration file directly. Click the Save button in the bottom right corner to save the Audit Policy and resume the cluster creation process. The Audit Policy uses the following default settings, which you can change as needed.
audit-policy.yaml
apiVersion: audit.k8s.io/v1 # This is required.
kind: Policy
# Don't generate audit events for all requests in RequestReceived stage.
omitStages:
  - "RequestReceived"
rules:
  # Log pod changes at RequestResponse level
  - level: RequestResponse
    resources:
      - group: ""
        # Resource "pods" doesn't match requests to any subresource of pods,
        # which is consistent with the RBAC policy.
        resources: ["pods"]
  # Log "pods/log", "pods/status" at Metadata level
  - level: Metadata
    resources:
      - group: ""
        resources: ["pods/log", "pods/status"]

  # Don't log requests to a configmap called "controller-leader"
  - level: None
    resources:
      - group: ""
        resources: ["configmaps"]
        resourceNames: ["controller-leader"]

  # Don't log watch requests by the "system:kube-proxy" on endpoints or services
  - level: None
    users: ["system:kube-proxy"]
    verbs: ["watch"]
    resources:
      - group: "" # core API group
        resources: ["endpoints", "services"]

  # Don't log authenticated requests to certain non-resource URL paths.
  - level: None
    userGroups: ["system:authenticated"]
    nonResourceURLs:
      - "/api*" # Wildcard matching.
      - "/version"

  # Log the request body of configmap changes in kube-system.
  - level: Request
    resources:
      - group: "" # core API group
        resources: ["configmaps"]
    # This rule only applies to resources in the "kube-system" namespace.
    # The empty string "" can be used to select non-namespaced resources.
    namespaces: ["kube-system"]

  # Log configmap and secret changes in all other namespaces at the Metadata level.
  - level: Metadata
    resources:
      - group: "" # core API group
        resources: ["secrets", "configmaps"]

  # Log all other resources in core and extensions at the Request level.
  - level: Request
    resources:
      - group: "" # core API group
      - group: "extensions" # Version of group should NOT be included.

  # A catch-all rule to log all other requests at the Metadata level.
  - level: Metadata
    # Long-running requests like watches that fall under this rule will not
    # generate an audit event in RequestReceived.
    omitStages:
      - "RequestReceived"

​
2. Network

Configure the network settings for the cluster. On the Network configuration page, first select the Super Region where you want to deploy the cluster. Then, select the Zone.
Zone availability is subject to capacity.
A screenshot of the second step to creating a cluster, labeled "Zone"

​
Select a VPC

If you already created a VPC to use with this cluster, select the same Zone where you deployed that VPC. Otherwise, you can either use a default VPC that CoreWeave creates for you during this process, or create a new custom VPC. You can still customize default VPCs from this page by clicking the Customize option beside the Create a default VPC radio button. A screenshot of the default VPC customization window This opens a configuration screen, where you can adjust the available VPC prefixes and Host Prefixes as needed. This screen also shows the default Host Prefix assigned to the default VPC. A screenshot of the default VPC customization window
Each Zone has its own default prefixes, which populate default VPCs. You can change these. Refer to Regions to see each Zone’s default prefixes.

​
3. Auth

The Auth screen is where you configure how the cluster handles authentication and authorization. All settings on this screen are optional: you can add an authentication webhook, an authorization webhook, and OIDC, or skip them all and click the Next button to continue without changes. When you select any of these options, additional configuration fields appear. A screenshot of Step 3 of cluster configuration, auth settings

​
Add an authentication webhook

When you select the Add an authentication webhook checkbox, the Server and Certificate Authority fields appear. To configure the webhook, you must provide a URL in the Server input field, and can optionally include a Certificate Authority.
To learn more about Webhook authentication in Kubernetes, see the official Kubernetes documentation.

​
Add an authorization webhook

When you select the Add an authorization webhook checkbox, the Server and Certificate Authority fields appear. To configure the webhook, you must provide a URL in the Server input field.
To learn more about Webhook authorization in Kubernetes, see the official Kubernetes documentation.

​
Enable OIDC

To enable OIDC, the Issuer URL and Client ID fields are required. All other fields are optional.
To learn more about OIDC for Kubernetes, see the official Kubernetes documentation.

​
Certificate Authority

Each of the authentication and authorization options provides an optional Certificate Authority checkbox. Selecting this checkbox opens a YAML editor where you can enter a Certificate Authority X.509 certificate.

​
4. Deploy

The final step of cluster creation provides an overview of all options selected during the creation process. After reviewing and confirming the cluster’s configuration, click the Submit button to deploy the new cluster. A screenshot of the final step to creating a cluster, labeled "Deploy" Your cluster appears on the cluster dashboard with the status Creating. When a cluster is ready, its status changes to Healthy. If configuration or deployment issues occur, the cluster’s status changes to Unhealthy.

​
View details of deployed clusters

To view more information about a deployed cluster, click the vertical ellipses menu beside the cluster name and select View Details. This opens the cluster’s current configuration in JSON, along with information about the cluster’s age, location, name, associated API endpoint, and current state. To return to the dashboard, close this panel. A screenshot of a UI element showing how to reveal the current config for the cluster

​
Cluster statuses

A screenshot of the Cloud Console cluster creation dashboard The cards at the top of the cluster dashboard provide information about the status of your current clusters.
The cluster’s status refers to the status of the cluster’s Control Plane. A CKS cluster with a Healthy status can still be provisioning in-cluster resources. These resources include required Control Plane Node Pools and required applications such as CNI and DNS configurations. See Cluster Components for more information.
NameDescription
QuotaDisplays the number of CKS clusters your organization has deployed over the maximum limit of clusters defined by the organization’s quota. Represented as count/quota. If you haven’t yet created any clusters, or you have no quota assigned, the status shown is No Quota.
HealthyDisplays the number of healthy clusters deployed. In a healthy cluster, all Control Plane elements, servers, and Pods are in a Healthy state. The cluster is stable and responsive, and can manage workloads.
UnhealthyDisplays the number of unhealthy clusters. A cluster can become Unhealthy for many reasons, including Control Plane issues, unresponsive Nodes, failing Pods, network failures, or storage problems.

​
Do not install the NVIDIA GPU Operator on CKS clusters

CoreWeave manages the NVIDIA GPU Operator on your behalf. Do not install the NVIDIA GPU Operator on CKS clusters. Doing so conflicts with the platform-managed deployment and is not supported.
Last modified on June 10, 2026