Skip to main content
You need to see what is really running in a cluster, and fix it, without switching kubectl contexts or handing out kubeconfigs. Every cluster connected to Ankra has a Kubernetes menu in its sidebar that lists the resources the Ankra Agent reports, and lets you act on them within your organisation permissions. This page covers what Ankra adds on top of the Kubernetes objects and where each one lives in the menu. For what a Deployment or a PersistentVolume is, see the Kubernetes documentation.

​
Where Everything Is

Open a cluster, then Kubernetes in the cluster sidebar. Most resources sit one submenu deeper: Network Policies and Pod Disruption Budgets are under RBAC, not Networking or Workloads. Endpoints, LimitRanges, CSINodes and VolumeAttachments have no menu entry; read them with the CLI, which takes any kind:

​
What Every Resource Page Adds

Lists filter by namespace and name, and you can select several rows and delete them in one go. Click a resource to open its page. Across resource types you get:
  • Manifest - the live YAML. Click Edit, change it, then Apply to send the change to the cluster.
  • Events - on Deployments, StatefulSets, DaemonSets, ReplicaSets, HorizontalPodAutoscalers, Pods and Services, the Kubernetes events for that object. The cluster-wide list is Kubernetes → Events.
  • Resource Map - on ConfigMaps, Secrets and Services, a graph of the workloads and other objects connected to it.
  • Security - on Deployments, StatefulSets, DaemonSets, ReplicaSets and Pods, the vulnerability scan results for that workload. See Cluster Security.
  • Managed by Ankra - a badge on anything a Stack deployed, naming its stack and manifest or add-on, with its sync status, such as Synced or Out of Sync. Change such a resource in its Stack, not on the resource page: the Stack is the source of truth.
  • Freshness - each page shows when its data was last updated, and a banner says when the agent is disconnected and you are looking at cached data. A resource deleted from the cluster keeps its page, marked as deleted.
  • AI - press ⌘+J (Ctrl+J) on any resource page and the AI Assistant starts with that resource as its context. Where AI Insights has flagged the resource, a banner offers Ask AI.

​
Workloads

Kubernetes → Workloads. Deployments, StatefulSets and DaemonSets have a Restart button for a rolling restart, next to Delete. Their pages have Overview, Pods, Events, Manifest and Security tabs; CronJobs list the Jobs they created. A pod page has Overview, Logs, Terminal, Metrics, Events, Volumes, Manifest and Security tabs, each with a single-key shortcut. The pod-level tools have their own guides:
  • Logs - stream and search container logs, or search across the cluster.
  • Pod Terminal - a recorded shell in a running container.
  • Debug Pods - a pod that impersonates this one under an image with the tools you need.
  • Cluster Metrics - CPU and memory for nodes and pods.

​
Networking

Kubernetes → Networking holds Services, Ingresses and Ingress Classes. A Service page has a Pods tab listing the pods its selector matches, which is the quickest way to see why a Service has no backends, and a Resource Map linking it to its pods, Ingresses and Network Policies. An Ingress page lists each rule with its host, path and backend Service. Clusters Ankra creates can include a networking stack at create time: Traefik as the ingress controller, cert-manager and a Let’s Encrypt issuer. Network Policies are under Kubernetes → RBAC; Cluster Security scores how tightly they are scoped.

​
Storage

Kubernetes → Storage holds Persistent Volumes, Persistent Volume Claims, Storage Classes and CSI Drivers. The Persistent Volumes list shows each volume’s Reclaim Policy, and the Storage Classes list shows each class’s Reclaim Policy and whether it allows volume expansion.
Changing a Stack can delete volume data. Removing a manifest from a Stack, or renaming one, makes Ankra delete the objects in it, PersistentVolumeClaims included. With a Delete reclaim policy, the default for most CSI drivers, the disk behind the claim is destroyed too. Read Protect Persistent Data Before Changing a Stack before you rename or remove a manifest that holds a namespace or a claim.

​
Configs

Kubernetes → Configs holds ConfigMaps and Secrets. Both pages have a Resource Map showing which workloads mount or read the object. A Secret opens with its key names only; the values stay hidden. To see them, click Reveal values on the Secret’s Data card. That needs the kubernetes.secrets_reveal permission, which the owner, admin and operator roles hold, and each reveal is written to the audit log. After a reveal, click the eye icon next to a key to show its decoded value, or the copy icon to copy it, and Hide values when you are done. Without the permission the card says so instead of offering the button. The Manifest tab shows the Secret with value digests until you reveal it, and can only be edited after a reveal, so a save never writes digests over the real values. A digest (hmac-sha256: and 32 characters) changes when its value changes. It is keyed per cluster with a key only the platform holds, so it cannot be used to check a guessed value, and the same value on two clusters shows two different digests. From the terminal, ankra cluster get secrets shows the same thing: key names, and each value as a sha256: digest followed by 12 hex characters. To read one Secret’s values, name it, give its namespace and add --reveal:
--reveal needs the same kubernetes.secrets_reveal permission, and each reveal is written to the audit log like one from the console. It reads exactly one Secret, so it is refused on a listing: without a name, with -A or with -l. Values under data stay base64-encoded, as kubectl prints them. The command exits 7 when your role lacks the permission, 3 when the Secret does not exist, and 1 when the platform cannot read live values, for example because the cluster is not connected. To keep secrets out of plain text in Git, see SOPS Secrets. For values shared across clusters and stacks, use Variables instead of hand-edited ConfigMaps.

​
RBAC

Kubernetes → RBAC shows the Kubernetes RBAC objects inside the cluster: Roles and Cluster Roles (with a Rules tab), their bindings, Service Accounts, plus Network Policies and Pod Disruption Budgets. This is not where you give a teammate access. Ankra has its own access control:
  • Roles & Access decides what each member can do in Ankra, per organisation, cluster or cluster group.
  • Cluster Access grants a member kubectl access to a cluster. Ankra turns each grant into a RoleBinding or ClusterRoleBinding, which then appears in this menu.

​
Namespaces, Events, CRDs and Helm Releases

  • Namespaces - a namespace page adds Workloads and Metrics tabs for everything in it.
  • Events - every Kubernetes event in the cluster, in one list.
  • CRDs - every CustomResourceDefinition, and the custom resources of each one.
  • Helm Releases - every Helm release, with Overview, Values, Manifest, Notes, History and Resources tabs. For a release you installed yourself you can edit its values and apply a Helm upgrade, Roll back to an earlier revision, or uninstall it. For a release an Ankra add-on owns these are disabled, because the add-on would re-apply its own version; change it from the add-on instead. See the Add-on catalog. Passwords, tokens and keys in a release stay hidden: in its values, in the Secrets it renders and in its notes, each one shows as a [REDACTED:...] placeholder. To see them, click Reveal values on the Values tab. That needs the kubernetes.secrets_reveal permission, and each reveal is written to the audit log. The values can only be edited after a reveal, so an upgrade never writes a placeholder over a real password; an upgrade that still carries one is refused.

​
Nodes

Kubernetes → Nodes shows the Kubernetes Node objects, with Overview, Pods, Metrics and Manifest tabs for each node. See Kubernetes Nodes. To add, remove or resize the machines themselves, use Nodes in the cluster sidebar, described in Cluster Nodes.

​
Next Steps

Start from a problem: open the failing workload under Kubernetes → Workloads, check its Events tab, then its pod’s Logs. If the cause is still unclear, press ⌘+J and ask the AI Assistant about the resource you are on.