Check Kubernetes context and namespace locally

01

1. Create an isolated kubeconfig

Save the following JSON as kube-demo.json in a new working folder. JSON is also valid YAML for this configuration. The two documentation-only IP addresses and empty user entry make this a local selection exercise, not usable cluster credentials.

Every command below passes --kubeconfig explicitly. Nothing is merged into your normal kubeconfig, and there is no need to change KUBECONFIG or your active production context.

{
  "apiVersion": "v1",
  "kind": "Config",
  "clusters": [
    {
      "name": "lab-a",
      "cluster": {
        "server": "https://192.0.2.10:6443"
      }
    },
    {
      "name": "lab-b",
      "cluster": {
        "server": "https://192.0.2.20:6443"
      }
    }
  ],
  "users": [
    {
      "name": "lab-observer",
      "user": {}
    }
  ],
  "contexts": [
    {
      "name": "demo-a",
      "context": {
        "cluster": "lab-a",
        "user": "lab-observer",
        "namespace": "preview-a"
      }
    },
    {
      "name": "demo-b",
      "context": {
        "cluster": "lab-b",
        "user": "lab-observer",
        "namespace": "preview-b"
      }
    }
  ],
  "current-context": "demo-a"
}

02

2. Inspect the current selection

List the contexts and print the current one. The expected current context in the file is demo-a, which pairs lab-a with namespace preview-a. A context binds a cluster, a user and optionally a namespace.

These config subcommands inspect the file locally. Do not replace them with get pods simply to check the spelling of a context; that would add a separate API request and an authentication requirement.

kubectl --kubeconfig ./kube-demo.json config get-contexts
kubectl --kubeconfig ./kube-demo.json config current-context

03

3. Preview a different target explicitly

Use --context demo-b with a minified view to inspect only that context’s target. Expect namespace preview-b and endpoint https://192.0.2.20:6443 in the result. Inspect the cluster reference as well as the display name.

Do not add --raw to a real kubeconfig preview for convenience: it can reveal credential material. This lab has no credentials, and the default view is sufficient for the target check.

kubectl --kubeconfig ./kube-demo.json --context demo-b \
  config view --minify -o json

04

4. Confirm that the current context did not change

Run current-context again. It should still print demo-a. An explicit --context on one command selects that invocation’s target; it does not act like config use-context.

This distinction is useful in scripts and incident work: pass the intended context and namespace on the actual cluster command rather than silently depending on a previous terminal session’s selection.

kubectl --kubeconfig ./kube-demo.json config current-context

05

5. Plan the next check separately

For a real environment, review a trusted kubeconfig and confirm the endpoint, identity reference and namespace before proceeding. Then verify connectivity and permissions through your approved access workflow.

A kubeconfig can contain authentication mechanisms that run external programs during cluster access. Trust the file and any referenced tooling. This local demonstration does not validate credentials or authorize a deployment, and the example endpoints should not be used for network tests.

06

Verification boundary

The editorial run used kubectl 1.36.1 to resolve both demo contexts from this file. It checked their distinct cluster endpoints and namespaces, verified demo-a remained current and compared file hashes before and after. No cluster API, user credentials or existing kubeconfig was used.