Skip to main content
Ankra lets you open an interactive terminal directly into any running pod container from the dashboard. Choose your shell, select the target container, and debug issues without leaving the browser.

​
Opening a Terminal

1

Navigate to a Pod

Go to Clusters → [Your Cluster] → Kubernetes → Workloads → Pods and select a running pod.
2

Open the Terminal Tab

Click the Terminal tab in the pod detail view.
3

Select Container and Shell

If the pod has multiple containers, select the target container from the dropdown. Choose your preferred shell (/bin/sh, /bin/bash, /bin/zsh, or /bin/ash).
4

Connect

Click Connect to start the terminal session. You’ll see a green “Connected” indicator when the session is active.

​
From the CLI

The same terminal is available from the shell you are already in, through the platform - no kubeconfig and no port-forward:
The local terminal is put in raw mode, so every keystroke (Ctrl-C included) reaches the remote shell and window resizes follow your terminal; leave with exit or Ctrl-D. A pod with one container needs nothing more; one with several takes --container. The command needs kubernetes.exec on the cluster, and the session is recorded and audited exactly like a portal one (see Recorded sessions). ankra cluster debug create --attach uses it to drop straight into a freshly created debug pod.

​
One-off commands

To run a single command rather than open a shell - a psql -c check, a curl from inside the pod, reading a config file - use ankra cluster exec. It runs the command, streams its output, and exits with the command’s own exit code, so a script or CI job can branch on it:
Everything after -- is passed to the container exactly as given: no shell re-parses it, so quote once for your local shell and not again. For pipes, globs or variables, run a shell explicitly: -- sh -c 'env | grep ^APP_'. (ankra cluster terminal --shell names a shell binary and cannot carry arguments; exec is the way to run a command.) The command runs without a TTY. When it ran, ankra cluster exec exits with its exit code; otherwise with the CLI’s usual codes (6 for a refused credential, 7 without kubernetes.exec, 1 when the command could not be started, for example because the binary does not exist in the image). exec goes through the same platform relay as the terminal: it needs kubernetes.exec on the cluster, and each run is recorded with an open_pod_terminal audit row whose details carry the exact command (command: [...]) instead of a shell. It needs a cluster agent recent enough to run one-off commands; an older agent is refused with the version it needs and nothing is run - upgrade it with ankra cluster agent upgrade.

​
Features

​
Supported Shells

If the container uses an Alpine-based image, use /bin/sh or /bin/ash. Bash is not included in Alpine by default.

​
Recorded sessions

Every terminal session opened through Ankra is recorded, and so is every ankra cluster exec. Opening a shell writes an open_pod_terminal row to the audit log naming who opened it, into which container, with which shell (or, for exec, the command it ran); while the session runs, everything typed and everything the container answered is stored with it, up to 4 MiB per session (longer sessions are marked truncated). Anyone with audit.read can open the row in the organisation audit log or a cluster’s Audit tab and see the session’s facts - duration, how it ended, how much was recorded - and replay the recorded output into a read-only terminal, with the typed input listed beside it. From the CLI, ankra org terminal-session <session-id> --transcript prints the same recording.
A recording contains whatever the shell printed, secrets included. Transcript access is gated on audit.read; the transcript itself never travels inside the audit row.
If the recording store is unavailable when a session opens, the session still opens and the audit row says recording_unavailable; a session whose recording failed part-way through is marked as degraded. Transcripts are kept for 90 days by default, then pruned: the session’s facts - who, where, when, how it ended, how much was recorded - stay with the audit row, and the replay says the transcript was pruned and when, rather than showing an empty recording.

​
No shell in the image?

A distroless image has nothing to attach to. Spin up a debug pod instead: a pod that impersonates this one - same service account, node, volumes and environment - under an image that has the tools you need.

​
Requirements

  • The cluster agent must be running and connected (cluster state: online).
  • The pod must be in a running state. Terminal is not available for deleted or terminated pods.
  • The selected shell must be available inside the container image.

​
Troubleshooting