Introduction

The YAML equivalent of kubectl run ... -i --tty ... is a Pod manifest with stdin: true and tty: true set on the container. In practice, you also usually want restartPolicy: Never, because interactive shells and debug pods are rarely meant to restart forever.

Basic translation

Imperative command:

kubectl run my-shell --image=ubuntu -i --tty -- /bin/bash

YAML equivalent:

1apiVersion: v1
2kind: Pod
3metadata:
4  name: my-shell
5spec:
6  restartPolicy: Never
7  containers:
8    - name: my-shell
9      image: ubuntu
10      command: ["/bin/bash"]
11      stdin: true
12      tty: true

Here:

• 'stdin: true corresponds to -i'
• 'tty: true corresponds to --tty'
• 'command corresponds to the command after --'

Then create and attach:

kubectl apply -f interactive-pod.yaml
kubectl attach -it my-shell

Why restartPolicy: Never matters

Interactive debug pods are usually short-lived. If you omit restartPolicy: Never, the container may restart after you exit the shell, which is often not what you intended.

That makes the pod feel "haunted" because it comes back instead of finishing cleanly.

For one-off interactive work, Never is the usual declarative equivalent of the imperative debug intent.

Reattach versus exec

After the pod exists, you have two different actions:

• 'kubectl attach reconnects to the main container process'
• 'kubectl exec -it starts a new command inside the running container'

For example:

kubectl exec -it my-shell -- /bin/bash

This is useful if the original shell exited or if you prefer launching a fresh interactive shell session.

Generate YAML from the command first if needed

If you want a quick starting point, Kubernetes can generate the YAML skeleton for you:

kubectl run my-shell --image=ubuntu -i --tty --dry-run=client -o yaml -- /bin/bash

That is often the fastest way to avoid forgetting fields. You can save the output, edit it, and then version-control the result.

Cleaning up the interactive pod

Because this pattern is often used for debugging, cleanup matters too. When you are done, remove the pod explicitly so it does not linger in the namespace:

kubectl delete pod my-shell

That is one of the main differences between a quick terminal session and a declarative manifest stored in version control. YAML makes the pod reproducible, but it also means you should be deliberate about lifecycle and cleanup.

Add other fields normally

Once you have the interactive pod skeleton, you can extend it with the normal Pod spec fields:

• environment variables
• volume mounts
• service account
• namespace
• resource limits

Example with environment variables:

1apiVersion: v1
2kind: Pod
3metadata:
4  name: debug-pod
5spec:
6  restartPolicy: Never
7  containers:
8    - name: debug-pod
9      image: alpine
10      command: ["sh"]
11      stdin: true
12      tty: true
13      env:
14        - name: DEBUG
15          value: "true"

The interactive settings are just two booleans in a normal Pod definition.

Common Pitfalls

The biggest mistake is setting only tty: true without stdin: true. A TTY alone does not make the container interactive in the same way as the imperative command.

Another mistake is forgetting restartPolicy: Never for a shell-style pod. Kubernetes may restart it after you exit, which is usually confusing for debugging.

Developers also sometimes attach to an image that does not actually contain /bin/bash or /bin/sh. Minimal images may not have an interactive shell at all.

Finally, do not forget that kubectl run is imperative convenience. YAML is the durable representation if you want the pod definition reviewed, reused, or stored in version control.

Summary

• The YAML equivalent of kubectl run -i --tty is stdin: true plus tty: true.
• Use restartPolicy: Never for interactive debug pods.
• Put the intended shell or command in the container command field.
• Use kubectl attach to reconnect or kubectl exec -it to start a new shell.
• Generate a starting manifest with --dry-run=client -o yaml if you want a quick template.