kubectl config get-contexts

When to Use kubectl config get-contexts

kubectl config get-contexts is your go-to command for listing all configured contexts in the kubeconfig. It shows which context is active and maps each context to its cluster, user, and default namespace.

Reading the Output

The command produces a table with five columns:

CURRENT   NAME         CLUSTER         AUTHINFO        NAMESPACE
*         production   prod-cluster    prod-admin      default
          staging      stg-cluster     stg-developer   staging
          minikube     minikube        minikube

• CURRENT: An asterisk marks the active context.
• NAME: The context name you use with use-context.
• CLUSTER: The cluster entry this context references.
• AUTHINFO: The user/credential entry.
• NAMESPACE: The default namespace (blank means default).

Scripting with get-contexts

For automation, the -o name flag is invaluable:

# Iterate over all contexts
for ctx in $(kubectl config get-contexts -o name); do
  echo "=== $ctx ==="
  kubectl get nodes --context="$ctx" 2>/dev/null || echo "Unreachable"
done

You can also combine with --no-headers for more precise parsing:

# Get the cluster name for a specific context
kubectl config get-contexts staging --no-headers | awk '{print $3}'

Finding the Current Context

While kubectl config current-context gives you just the name, get-contexts provides the full picture including which cluster and user the current context references:

# Quick: just the name
kubectl config current-context
# Output: production

# Detailed: cluster, user, and namespace
kubectl config get-contexts $(kubectl config current-context)

Comparing Multiple kubeconfig Files

When using multiple kubeconfig files, get-contexts shows the merged view:

# Set multiple kubeconfig files
export KUBECONFIG=~/.kube/config:~/.kube/team-config

# See all contexts from both files
kubectl config get-contexts

This helps identify duplicates or conflicts. If two files define a context with the same name, the first file in the KUBECONFIG path wins.

Verifying Context Configuration

Before switching to a context, verify it has the expected configuration:

# Check what cluster and user a context maps to
kubectl config get-contexts my-context

# If the namespace column is empty, it defaults to "default"
# Set it explicitly if needed
kubectl config set-context my-context --namespace=my-app

Practical Patterns

A common shell function to select contexts interactively:

# Add to .bashrc or .zshrc
kctx() {
  local ctx
  ctx=$(kubectl config get-contexts -o name | fzf --prompt="Select context: ")
  if [ -n "$ctx" ]; then
    kubectl config use-context "$ctx"
  fi
}

For teams using naming conventions, you can filter contexts:

# Show only production contexts
kubectl config get-contexts -o name | grep prod

# Show only contexts for a specific cloud provider
kubectl config get-contexts -o name | grep gke

Context Hygiene

Over time, kubeconfig files accumulate stale contexts pointing to decommissioned clusters. Regular cleanup improves usability:

# List all contexts
kubectl config get-contexts -o name

# Test each context
for ctx in $(kubectl config get-contexts -o name); do
  kubectl cluster-info --context="$ctx" &>/dev/null && echo "$ctx: OK" || echo "$ctx: UNREACHABLE"
done

# Remove stale contexts
kubectl config delete-context old-cluster

Keeping your kubeconfig clean reduces the risk of accidentally deploying to a wrong or stale cluster.