stern is tailing the wrong cluster (wrong kubectl context)

stern has no cluster of its own - it reads your kubeconfig and tails whatever context is current, so a leftover prod context means prod logs in what you thought was a dev debug session. Check kubectl config current-context before tailing, pass stern --context [name] to pin it, or switch with kubectx first.

The error

(no error - stern silently uses the current kubectl context, so the logs are from the wrong cluster)

What to do

1. Check what stern will use:

kubectl config current-context

Expected: Prints the context stern follows.

2. Pin the context for this tail:

stern --context [name] [query] -n [namespace]

Expected: Logs come from the intended cluster.

3. Or switch first:

kubectx [name]
stern [query] -n [namespace]

Expected: Same result, and later commands follow too.

When this applies

• logs that do not match the cluster you meant
• multi-cluster debugging sessions
• after a kubectx switch you forgot about

When it does NOT apply

• stern failing to connect (kubeconfig problem)
• empty results on the right cluster (query/namespace problem)

Works with

stern 1.x

CI tails logs from the wrong cluster after a shared kubeconfig was mutated

Same shared-file cause. Give the job --context or its own KUBECONFIG.

Why it happens

stern is a kubeconfig client like kubectl: it resolves the current context and dials that API server. There is no per-invocation cluster unless you pass --context.

Edge cases

• --context must name a context in the kubeconfig stern reads (KUBECONFIG env or ~/.kube/config).
• Prompt tools that show the current context (kubectx in PS1) catch this before you tail.

Resolved from

gh:esysc/stern-ui (stern context parameter) - https://github.com/esysc/stern-ui