Manage and monitor clusters in RisingWave Console

Observe an attached RisingWave CR and perform approved replica, resource, and image operations in Console v0.8.0.

After connecting an existing cluster, Console can use its endpoints for SQL, Meta, metrics, and operational tools. If an administrator also attaches its Operator-managed CR, Console v0.8.0 can show CR state and perform narrowly delegated changes.

The clusters page

The page lists saved clusters, their configured RisingWave versions and metrics stores, and available actions. A saved connection is configuration; confirm live health and running version before operational changes.

Observe an attached CR

Observation requires a trusted target and get on the single named RisingWave CR. It does not require Pod, Secret, Event, PVC, workload, or namespace-wide list access. See incremental Kubernetes permissions.

For an attached CR, the cluster page can show Operator-reported information, including:

• Running and Target state,
• configured image and reported version,
• component groups and their replicas and CPU/memory settings,
• the storage and TLS summaries exposed by v0.8.0.

Configured target state can differ from running state while the Operator reconciles changes.

View read-only YAML

Select View YAML to open a read-only Monaco view with folding, search, line numbers, and copy support. It uses the same named-CR get grant and does not read Pods or Secrets.

The view is an allowlisted projection of supported CR fields. It is not the complete raw CR, an export or restore backup, or a manifest to pass to kubectl apply. Sensitive and arbitrary content is omitted. Console v0.8.0 does not add arbitrary YAML editing, Secret inspection, namespace or Operator administration, or a Pod/PVC console.

Delegate CR operations

Delegated changes require all of the following:

• the named-CR observer grant remains applied,
• patch is approved for that same named CR,
• get is approved for the exact SQL and Meta Services,
• the CR is attached and matches its saved UID,
• the Console user is an authorized administrator.

In v0.8.0, writes use a same-cluster target and internal SQL and Meta Services whose namespace-qualified addresses and controller owner references are verified against the attached CR UID. Use service.namespace.svc or service.namespace.svc.cluster.local; a short Service name is not accepted for delegated identity verification, even when Console and RisingWave share a namespace. Configured SQL TLS is supported. Remote targets, external proxy or load-balancer endpoint mappings, and HTTPS Meta endpoints are not supported for delegated writes in this release.

These profiles do not need Operator, CRD, cert-manager, Secret, or workload lifecycle privileges. The existing RisingWave Operator reconciles the edited CR.

Common operation sequence

For each supported change:

1. Select the operation and the actual component group.
2. Edit only the requested value.
3. Review the before-and-after preview.
4. Confirm the operation.
5. Inspect the operation result and Operator progress.
6. Verify the actual service and application behavior independently.

Scale a component group

For example, select a frontend or compute group currently configured with 1 replica, set it to 2, preview the change, and confirm it. Choose the real group name shown in your CR. Topology suitability, including Meta scaling decisions, remains the administrator’s responsibility.

Change one CPU or memory field

For example, change one compute group’s CPU request from 500m to 750m. Console preserves unrelated group and template fields. A request is scheduler reservation, while a limit is an enforcement ceiling; neither is measured utilization. Changing a request or limit can cause an Operator-driven Pod rollout.

Change the RisingWave image

As a procedural example, change risingwavelabs/risingwave:v2.8.2 to risingwavelabs/risingwave:v2.8.3, preview, and confirm. This example is not a blanket compatibility or production-upgrade recommendation. Select a supported upgrade path, prepare required backups, and check workload compatibility.

After rollout, verify the actual running version. Then open Clusters > Edit and explicitly synchronize Registered RisingWave version before using version-selected tools. Updating the CR image does not silently update that saved setting.

Concurrency and operation results

Console v0.8.0 uses conditional JSON Patch for delegated operations:

• It checks the attached CR UID and captured resourceVersion atomically, modifies only the selected supported field, and preserves unrelated group and template fields.
• At execution, it rechecks authorization, target scope, binding and Service identity, deletion state, and operation preconditions. A successful preview is not a permanent grant.
• If any CR change occurs after preview, including a status-only resourceVersion change, refresh and review a new preview. Do not retry the stale request.

These operations do not use the earlier server-side-apply handover design. Historical SSA field ownership is not an additional UI gate; do not use --force-conflicts, edit managedFields, or look for a Console force toggle.

One active operation per attached RisingWave CR prevents overlapping Console operations on that CR. An accepted Kubernetes patch is not rollout success. Console observes Operator progress and health, but SQL and Meta availability and business or streaming correctness need separate checks.

A GitOps or platform controller can change the value again later; Console does not continuously counter-write it. Coordinate the authoritative configuration source instead of broadening RBAC.

For an uncertain outcome, inspect the CR and workloads independently before any new operation. The audited manual-close action changes only the Console operation record; it does not retry, repair, or undo a Kubernetes write.

Operational tools

Run risectl

Registered RisingWave version selects the requested CLI version. Console first looks for an exact cached binary and can fall back to the highest cached patch version in the same major/minor series. When downloads are allowed, a failed exact-version download can also fall back to an available release in that series. For example, a cluster registered as v2.8.2 can use v2.8.5. This selection is not a compatibility guarantee for every CLI and database combination.

Ordinary v0.8.0 images do not preinstall risectl; air-gap images cache v2.8.5 and v3.0.1. See Air-gapped deployment for the directory layout.

Use Risectl > Check CLI to inspect the executable’s reported version. This does not verify cluster reachability, Meta health, or command compatibility. Run a permitted read-only Meta command for the end-to-end check.

Manage RisingWave metadata snapshots

Create Snapshot and optional scheduled snapshot settings operate on RisingWave cluster metadata where supported. A RisingWave metadata snapshot is not a backup of Console’s PostgreSQL metadata and is not, by itself, a complete application-data recovery plan. Back up each system according to its own recovery procedure.

Collect diagnostics

Use Collect Diagnostic or the supported scheduled diagnostic settings to gather troubleshooting information. Treat the resulting data according to your organization’s access and retention policy.

Troubleshooting

Symptom	Check
Target does not appear	Target configuration, organization assignment, namespace allowlist, and the Console rollout.
Exact-name observation is denied	Named-CR get, target identity, namespace, and CR name.
Find connected CR fails	Exact SQL and Meta Service get, controller owner references, and endpoint mapping. Exact-name observation can still work.
Preview works but execution is denied	Current Console authorization, named-CR patch, target scope, attachment, and execution-time preconditions.
Service mapping cannot be verified	Use namespace-qualified same-cluster internal Service addresses and confirm their controller owner references match the attached CR UID. An unqualified address is not an RBAC failure.
CR is being deleted	Observation can continue while the CR exists and remains readable, but delegated changes are disabled.
CR is missing, inaccessible, or UID-replaced	Do not treat it as the previously observed object. Bind a same-name replacement as a new identity and review a new preview.
Rollout remains pending or fails	Inspect Operator status, Kubernetes scheduling and image pulls, then verify SQL and Meta separately. An accepted patch is not rollout success.
Operation outcome is uncertain	Inspect the CR and workloads externally before acting. Manual close updates only Console’s record.
Meta command fails after initial connection	Check every advertised leader and member address, not only the first Service endpoint.