Skip to main content
In this lesson you’ll learn how to inspect kubeconfig files, switch contexts, make a custom kubeconfig the default, and diagnose a common client-certificate mismatch that prevents kubectl from authenticating.

​
Locate the default kubeconfig

Find the current home directory and inspect the default kubeconfig (usually $HOME/.kube/config):
Quick summary from the default kubeconfig:
  • Clusters defined: 1
  • Users defined: 1
  • Contexts defined: 1
A split-screen screenshot: the left side shows a quiz question asking "How many clusters are defined in the default kubeconfig file?" with multiple-choice answers, and the right side shows a terminal displaying the contents of a ~/.kube/config file (clusters, contexts, users) including a "kubernetes" cluster entry.
The value in current-context is the name of the context in use. The context lists which cluster and which user to use — the “user” entry is a reference name, not necessarily the actual system username.

​
Inspect a custom kubeconfig file

Here is an example custom kubeconfig stored at /root/my-kube-config. It contains multiple clusters, contexts, and users:
From the file above you can extract the following:

​
Switch context using a specific kubeconfig file

To switch to a context defined in a non-default kubeconfig file without affecting your default config, include the --kubeconfig flag:
You can confirm the change by viewing that kubeconfig or running kubectl commands with --kubeconfig /root/my-kube-config.

​
Make the custom kubeconfig the default

If you’d prefer not to pass --kubeconfig every time, replace your default kubeconfig with the custom file:
After moving the file, kubectl will use it by default. Example output of kubectl config view:

​
Diagnose and fix an authentication error (client-certificate mismatch)

With the current context set to research, running a kubectl command may produce an error indicating kubectl cannot read the client certificate referenced in the kubeconfig:
Investigate the actual files on disk:
Root cause: the kubeconfig references /etc/kubernetes/pki/users/dev-user/developer-user.crt and /etc/kubernetes/pki/users/dev-user/developer-user.key, but the files present are named dev-user.crt and dev-user.key. Update the kubeconfig to point to the correct certificate and key.
The kubectl config set-credentials command modifies the kubeconfig file kubectl is currently using (typically $HOME/.kube/config). Back up that file before making changes.
Recommended fix — update the dev-user credential entry to reference the correct certificate and key:
Re-run the kubectl command to verify access:
After correcting the client-certificate and client-key file paths in the kubeconfig, kubectl can authenticate as dev-user and access the cluster.

​
Quick reference

Watch Video