Docs

Cluster Console

What this screen is for

Cluster Console is direct access to your Kubernetes clusters from inside Fenwave: browse any resource kind, read a resource in full, and act on it.

It is the only Deploy surface that changes live cluster state directly, without going through an environment or a release. That makes it the most useful screen when something is wrong, and the one to treat with the most care.

Before you start

To do this You need
Open the console and browse resources cluster-console.read
Edit, clone, scale, restart, cordon, uncordon, drain cluster-console.write
Delete a resource cluster-console.delete
Open a terminal in a pod cluster-console.exec
Port-forward cluster-console.portforward
Read Secret contents cluster-console.secret.read
Act on a protected namespace or kind cluster-console.protected.override

Two of these are deliberately not implied by write:

  • cluster-console.exec is its own grant. A shell in a pod reaches past every other permission on the list, so holding write must never imply holding it.
  • cluster-console.secret.read is separate from reading resources, because seeing that a Secret exists and seeing what is in it are different things.

Which clusters you can see is decided per cluster by the backend, not by the menu. Two people who both hold cluster-console.read can legitimately see different clusters.

The UI is an affordance; the server decides

Buttons are hidden when you lack the permission, but every action is authorized again on the server. A hidden button is a convenience, not the control.

Opening it

  1. Deploy › Cluster Console in the sidebar.

Direct URL: /cluster-console. The audit log is at /cluster-console/audit.

The interface

📸 Screenshot Placeholder: Cluster Console listing pods. Mark: (1) the resource-kind rail, (2) the cluster selector, (3) the namespace selector, (4) the search and label filters, (5) the result count, (6) a row’s action menu.

# Control What it does When you’d use it
1 Resource-kind rail Chooses the kind you are browsing Always; collapsible for more room
2 Cluster selector Which cluster Always
3 Namespace selector One namespace, or All namespaces Narrowing a search
4 Search and Labels Free-text search, plus label selectors like app=web,tier=api Finding one thing among many
5 Result count How many of that kind matched Sanity-checking a filter
6 Action menu The actions available on that resource Acting

The actions

Action Needs Available on
Edit YAML write Any kind
Clone write Any kind — produces a manifest you edit before anything is sent
Scale write Scalable kinds
Restart write Restartable kinds
Cordon / Uncordon write Nodes — only the meaningful one of the pair is offered
Drain write Nodes
Terminal exec Pods
Delete delete Any kind

Guardrails

Two protections sit in front of every mutation, on the server:

  1. Protected namespaces and kinds. Configured namespaces and kinds refuse mutation entirely unless you hold cluster-console.protected.override. The error names which protection stopped you.
  2. Typed-name confirmation. Delete, Drain and Cordon require you to type the resource’s name exactly. A mismatch is refused. This exists because these three are the actions whose consequences are hardest to undo.

Walkthroughs

Find a resource

  1. Deploy › Cluster Console, pick the cluster.
  2. Choose the kind from the rail.
  3. Narrow with the namespace selector, then search or label selectors.
  4. Check the result count matches what you expect before acting on anything.

Edit a resource

Requires cluster-console.write.

  1. Find it, open the action menu, choose Edit YAML.
  2. Make the change and apply it.

Prefer Clone when you want a variant: it produces a manifest you edit before anything is sent, so a mistake costs nothing.

Delete a resource

Requires cluster-console.delete.

  1. Find it and choose Delete.
  2. Type the resource’s name exactly to confirm.

If the namespace or kind is protected, this is refused regardless of your delete permission. That is the guardrail working.

Open a terminal

Requires cluster-console.exec — separately from write.

Find the pod and choose Terminal. Everything you do in that shell runs with the pod’s identity, and it is recorded in the audit log.

Scenario

A pod is crash-looping in staging.

  1. Deploy › Cluster Console, select the staging cluster, choose Pods.
  2. Set the namespace, or search by name. Use a label selector such as app=web if you know the labels — it is faster than scrolling.
  3. Open the pod and read its status and events. Most crash loops name their own cause here: a failing probe, a missing config, an image that will not pull.
  4. Check the container’s resource limits against what it is using. A pod restarting on a cycle with no application error is usually being OOM-killed.
  5. Decide what kind of problem this is before acting:
    • Configuration — fix it at its source, in Environment Detail or DevOps Config, not by editing the live pod. An edit here is overwritten the next time the environment reconciles.
    • Transient — Restart the owning workload rather than deleting the pod.
    • Needs investigation from inside — Terminal, if you hold exec.
  6. If you edited anything live, go and make the same change at its source. Otherwise the next deployment silently reverts your fix and the problem returns looking new.

Step 5 is the whole scenario. Cluster Console makes it easy to fix the symptom in the cluster, and that fix lasts exactly until the next reconcile.

When it doesn’t work

Symptom Cause How to check Fix
Cluster Console is not in the submenu Missing cluster-console.read Access Explorer Ask for a role granting it
A colleague sees a cluster you cannot Cluster visibility is decided per cluster by the backend — Expected; ask for access to that cluster
Action menu is empty You hold read but no write, delete or exec Access Explorer Ask for the specific permission
Terminal absent although you can edit exec is a separate grant and is never implied by write Access Explorer Ask for cluster-console.exec explicitly
Secret contents are hidden secret.read is separate from reading resources Access Explorer Ask for cluster-console.secret.read
Action refused: “namespace/kind is protected” A guardrail, not a permission bug The error names the protection Needs cluster-console.protected.override — or, better, act somewhere safer
Confirmation rejected Delete, drain and cordon need the resource’s exact name typed The dialog Type the name exactly
Your edit disappeared The environment reconciled and overwrote it Environment Detail Make the change at its source
Button was visible but the action failed The server re-authorizes independently of the UI The error, then the audit log Trust the server’s answer

Next