Skip to main content
Use this page when a RisingWave cluster is already running. Console v0.8.0 separates three workflows:
  • Connect endpoints to use SQL, Meta, metrics, and operational tools. This needs no Kubernetes CR grant.
  • Attach an existing CR to observe an Operator-managed cluster. This needs a registered Kubernetes target and named-object access.
  • Create a managed cluster through Environments. This installs and manages infrastructure and requires broader permissions.
Connecting or attaching does not install RisingWave or the RisingWave Operator.

​
Prerequisites

Console must reach the endpoints you configure: For endpoint-only connections, use names that resolve from the Console pod. Meta commands can return leader or member addresses after the initial connection, so those advertised addresses must also resolve and be reachable. Find connected CR and delegated operations have a stricter identity check: SQL and Meta Service addresses must include the namespace, even when Console and RisingWave share a namespace. Use service.namespace.svc or service.namespace.svc.cluster.local, for example rw-prod-frontend.risingwave-prod.svc:4566 and http://rw-prod-meta.risingwave-prod.svc:5690.

​
Add a cluster connection

  1. Open Clusters and select Connect Cluster.
  2. Enter a unique Name.
  3. Configure the SQL Endpoint, Meta RPC Endpoint, and Meta HTTP Endpoint.
  4. Select the Registered RisingWave version. Console uses this requested version for version-selected risectl and metadata-backup tooling. It is not a live version check, an installation action, or a database upgrade. A custom value does not guarantee that its binary is installed or downloadable.
  5. Select a Metrics Store, or select None. None means that no metrics store is linked; it neither installs monitoring nor disables SQL or risectl.
  6. Select Test Endpoints, review the result, and then select Connect Cluster.
A connection test checks the endpoints covered by that action. Database credentials are tested when you add a database connection. A successful cluster test does not certify every SQL credential, every Meta command, advertised Meta addresses, or ongoing service health. The saved endpoint and version values are configuration, not a guarantee that the cluster remains healthy or that the registered version still matches the running version.

​
Attach an Operator-managed CR for observation

Attaching is optional. Endpoint-only connections continue to work without Kubernetes management grants.
A platform administrator must first register a trusted Kubernetes target for the actual Console organization and allow the CR namespace. The target identity needs get on the named RisingWave CR. For the same-cluster path, that identity is Console’s pod ServiceAccount and the Role and RoleBinding are in the RisingWave namespace. A Console organization administrator performs the attachment. Console authorization and Kubernetes RBAC are separate layers.
See Grant Kubernetes permissions incrementally for the canonical target configuration, permission table, and downloadable RBAC samples.

​
Find and attach the CR

  1. Open the cluster details Overview and find RisingWave configuration.
  2. Select the registered Platform target and an allowed Namespace.
  3. Choose one method:
    • Select Find connected CR when the SQL and Meta endpoints use namespace-qualified internal Kubernetes Service addresses. The target identity needs get on those exact Services in addition to get on the named CR. Console follows controller owner references and checks CR identity; it does not list CR or Service collections and is not a namespace browser.
    • Enter the exact CR name, then select Preview, when discovery is unavailable. A platform administrator can provide the namespace and name. This path also supports observation through an appropriately registered remote target.
  4. Review the target, namespace, CR identity, endpoints, and attestation preview, then select the confirmation checkbox.
  5. Select Bind for observation.
The same named-object rule applies whether Console and RisingWave share a namespace or not. The RoleBinding subject must name the Console pod’s actual ServiceAccount and its namespace. Administrator attestation records the observation decision. It does not by itself prove that SQL and Meta endpoints belong to the CR, grant mutation, or replace the Service and UID checks performed for delegated operations.

​
Attachment lifecycle

  • Applying RBAC does not add v0.8.0 APIs or UI to an older image and does not register a target. RBAC additions normally need no Console restart; target or image changes require a normal Console rollout.
  • Disconnect CR removes only Console’s CR binding. It does not delete the CR or the database cluster.
  • If bound SQL or Meta endpoints change, disconnect and bind again so the new identity can be reviewed. Do not rely on an old binding for new endpoints.
  • A CR being deleted can remain observable while it still exists and Console retains read access. Delegated changes are disabled during deletion. A missing, inaccessible, or UID-replaced CR cannot be treated as the previously observed object. Bind a recreated CR as a new identity.
  • An in-cluster ServiceAccount grant does not authorize a remote identity. Remote observation needs separately registered credentials.

​
Endpoint examples

Meta RPC and HTTP can use different ports on the same Service. Service names are deployment-specific. Short Kubernetes names can work for endpoint-only connections, but v0.8.0 does not accept them for Find connected CR or delegated identity verification.

​
Edit or delete a connection

To change SQL or Meta endpoints on a bound connection, first select Disconnect CR. Then open Clusters > Edit, update the endpoints, select Test Endpoints, save, and bind again to confirm the new CR identity. Changes to SQL TLS settings, the registered version, or the metrics store do not require disconnecting the CR when the endpoint values remain unchanged. To remove a connection, select its delete icon and confirm. This deletes only Console’s record; it does not stop or delete RisingWave. Select Disconnect CR first if the UI requires it. Continue with Manage and monitor clusters or Use SQL Console.

​
Troubleshooting