Introduction

Yes, you can pipe standard input into a container in a Kubernetes pod. The usual tool is kubectl exec -i, where the -i flag keeps standard input open and forwards the piped data into the command running inside the container.

The key detail is that you are not piping data into the pod abstractly. You are piping data into a specific process started by kubectl exec inside a specific container.

Use kubectl exec -i

A common pattern is to stream data into a shell command inside the container.

echo 'hello from stdin' | kubectl exec -i my-pod -- sh -c 'cat > /tmp/input.txt'

Here is what happens:

• 'echo writes to standard input'
• 'kubectl exec -i forwards that input into the container'
• 'cat inside the container reads from stdin and writes to a file'

If the pod has more than one container, specify the target container explicitly.

cat local.txt | kubectl exec -i my-pod -c app -- sh -c 'cat > /tmp/remote.txt'

Pipe into Programs, Not Only Files

You are not limited to writing a file. Any program inside the container that reads standard input can receive the stream.

printf 'line1\nline2\n' | kubectl exec -i my-pod -- python3 -c 'import sys; print(sys.stdin.read())'

That makes stdin piping useful for debugging, feeding scripts, or testing batch input behavior.

Understand When This Is the Wrong Tool

If your real goal is simply to copy a file into the container, kubectl cp may be clearer than streaming stdin.

kubectl cp local.txt my-pod:/tmp/local.txt

Use stdin piping when:

• the target command expects streamed input
• you want shell composition with pipelines
• you are testing interactive or batch-processing behavior

Use kubectl cp when you just need to transfer a file and nothing more.

The Target Command Must Actually Read Stdin

Piping works only if the command inside the container consumes standard input. Commands that ignore stdin will simply exit or do nothing useful. That is why examples usually use cat, python, sh, or another program that explicitly reads from the stream. If the application inside the container expects input on a socket, an HTTP endpoint, or a mounted file, stdin piping is the wrong interface.

TTY Is Different from Stdin

Developers sometimes confuse -i with -t. The -i flag keeps stdin attached. The -t flag allocates a pseudo-terminal. For simple piping, -i is usually the important one.

Adding -t to a pipeline can actually complicate output because terminals change buffering and formatting behavior. Use it only when the target program really expects a TTY.

Common Pitfalls

• Forgetting -i, which causes the command inside the container to receive no stdin stream.
• Omitting -c in multi-container pods and writing to the wrong container.
• Using stdin piping when kubectl cp would be simpler.
• Adding -t unnecessarily and getting odd terminal behavior in a pipeline.
• Assuming the pod spec must expose a special stdin setting for ordinary kubectl exec -i workflows.

Summary

• Pipe stdin into a container with kubectl exec -i.
• The input is forwarded to the command you run inside the container.
• Use -c to select the right container in multi-container pods.
• Prefer kubectl cp if you only need file transfer.
• Think in terms of piping data into a process, not into the pod as an abstract object.