Pod Terminal for Kubernetes in Your Browser

Open a pod terminal on any running Kubernetes container from the browser or the CLI. Pick the container and shell, with no kubeconfig or port-forward.

A pod terminal is an interactive shell inside a running Kubernetes container, the same thing kubectl exec -it gives you. In Ankra you open one from the pod’s Terminal tab in the browser, or with ankra cluster terminal from your own shell, with no kubeconfig and no port-forward.

Choose your shell, select the target container, and debug issues without leaving the browser. Every session is recorded in the audit log.

---

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:

ankra cluster terminal api-6d8f9c7b5-x2kq9 --namespace payments
ankra cluster terminal api-6d8f9c7b5-x2kq9 --namespace payments --container sidecar --shell /bin/bash

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:

ankra cluster exec cnpg-cluster-1 -n cnpg-database -c postgres -- psql -U postgres -d appdb -Atc 'select count(*) from users'
ankra cluster exec api-6d8f9c7b5-x2kq9 -n payments -- curl -sf localhost:8080/healthz
ankra cluster exec cnpg-cluster-1 -n cnpg-database -c postgres --stdin -- psql -U postgres -d appdb < query.sql

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.)

Option	Effect
-c, --container	The container to run in; needed only when the pod has several
--stdin	Forward your input to the command; it sees end-of-file when your input ends. Without it the command gets no input
-o json / -o yaml	Print one {exit_code, stdout, stderr, stdout_truncated, stderr_truncated} document when the command ends instead of streaming (each stream capped at 8 MiB)

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

Feature	Description
Multi-container support	Select any container in a pod, including init containers and sidecars
Shell selection	Choose between /bin/sh, /bin/bash, /bin/zsh, and /bin/ash
Auto-resize	Terminal automatically adjusts to your browser window size
Connection status	Clear visual indicator showing disconnected, connecting, connected, or error states
Reconnect	Quickly reconnect after a disconnection without leaving the page

---

Supported Shells

Shell	Path	Notes
sh	/bin/sh	Available in virtually all containers (default)
bash	/bin/bash	Available in most full Linux-based images
zsh	/bin/zsh	Available if installed in the container
ash	/bin/ash	Common in Alpine-based images

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

Issue	Solution
”Connection error” on connect	Verify the cluster agent is online and the pod is still running
Shell exits immediately	The selected shell may not exist in the container. Try /bin/sh
Terminal appears blank	Resize the browser window or click Reconnect
Session ends unexpectedly	The pod may have been restarted or deleted. Check pod status