Setting one up
No endpoint, no credentials — a console names a cluster you have already added, and bookmarks its command.
A console configures nothing
Every other connection type asks for a URL and a secret. This one asks for neither.
A console names a Kubernetes cluster you have already added and runs through it: the same API server URL, the same authentication (bearer token, client certificate or EKS signing), the same TLS. So the add form is a cluster picker, a name, and a default namespace — picking a cluster seeds the last two.
The consequences are the point:
- rotating the cluster’s credentials later needs no change here;
- there is no second copy of a secret to store, resolve or delete — the connection saves only which cluster it points at;
- because requests go through the cluster’s own HTTP client, they appear in the app’s network console like every other call the app makes.
When the cluster goes away
A console borrows another connection, so that connection can disappear underneath it. When it does, the panel subtitle reads “Cluster no longer configured” and the screen asks you to re-point it — rather than failing with an obscure error somewhere deeper.
Bookmarking the command
The app-bar bookmark saves the console’s current command. The command is the bookmark’s identity, so re-saving the same one updates it in place rather than piling up duplicates, and opening a bookmark seeds the console with that command ready to run.
Long commands are exactly what is tedious to rebuild on a phone — which makes this the one bookmark type that saves you the most typing.
Back to kubectl console.