lowFoundationSymptom-first#kubectl#namespace#context

kubectl: Error from server (NotFound) — wrong context or namespace

Error from server (NotFound): pods not found

Likely source:configuration

Focused incident mode — strips away everything but this runbook.

Symptoms

  • Error from server (NotFound): pods not found
  • Resources visible in the UI but not via CLI
  • Commands work for some namespaces but not others

Evidence to grab

Collect these artifacts before you change anything — they prove (or rule out) each cause.

  • Current context

    kubectl config current-context

  • Context namespace

    kubectl config view --minify --output jsonpath='{.contexts[0].context.namespace}'

Diagnostic flow

Run the steps in order, marking each claim confirmed or refuted. The evidence you gather feeds the ranked causes below.

Guided decision tree is ready.

Steps with commands, expected output, and pass/fail branches.

Ranked root causes

Evidence checklist

  • NotFound for a resource you can see in another namespace
  • kubectl config view shows a different namespace than expected

Confirm before fixing

kubectl config view --minify --output jsonpath='{.contexts[0].context.namespace}'
READ

Read the default namespace

Fix

kubectl config set-context --current --namespace=<correct-namespace>
CHANGE

Persist the right namespace for the context

Expected: Context "<ctx>" modified.

Resolution runbook

Apply from top to bottom after the cause is confirmed. Review every command before running it — risk tags are shown on each.

1
kubectl config current-context
READ

Confirm the cluster

2
kubectl config get-contexts
READ

Find the intended context

3
kubectl config use-context <correct-context>
CHANGE

Switch to it

4
kubectl config set-context --current --namespace=<namespace>
CHANGE

Set the default namespace

5
kubectl get pods -n <namespace>
READ

Verify the fix

Prevention

  • Use kubectx/kubens and show cluster+namespace in the shell prompt (kube-ps1).
  • Never rely on a default namespace in scripts — pass -n explicitly.
  • Guard prod cluster access with kubectx confirmation prompts or RBAC restrictions.

Related runbooks

Same stack, same failure family — worth a skim.

Pods stuck in Pending state — unschedulablehigh

kubectl get pods shows Pending for minutes

KubernetesIntermediate3 causes
Open runbook

Commands marked READ CHANGE DESTRUCTIVE — never run DESTRUCTIVE commands against production data you cannot restore. Copy → verify → execute.