Config File [verified]: Kubectl

kubectl config use-context dev-context kubectl get pods # talks to minikube kubectl config use-context prod-context kubectl get pods # talks to production You rarely edit the YAML directly. Instead, use these built-in commands. View Your Current Setup # Show merged kubeconfig settings kubectl config view See current context only kubectl config current-context List all contexts kubectl config get-contexts Switch Contexts kubectl config use-context <context-name> Set a Default Namespace for a Context kubectl config set-context --current --namespace=my-app Add a New Cluster Manually kubectl config set-cluster my-cluster \ --server=https://1.2.3.4:6443 \ --certificate-authority=/path/to/ca.crt Add a New User kubectl config set-credentials my-user \ --client-certificate=/path/to/client.crt \ --client-key=/path/to/client.key Create a Context kubectl config set-context my-context \ --cluster=my-cluster \ --user=my-user \ --namespace=my-ns Advanced: Merging Multiple Kubeconfig Files One powerful feature is merging multiple config files. Set the KUBECONFIG environment variable with a list of files (colon-separated on Linux/Mac, semicolon on Windows):

export KUBECONFIG=~/.kube/config:~/workspace/project/kubeconfig kubectl config view kubectl merges them automatically, and the that defines a given cluster/user/context takes precedence. The current-context is taken from the first file that defines it. kubectl config file

If you use Kubernetes daily, you’ve almost certainly run a command like kubectl get pods or kubectl apply -f deployment.yaml . But have you ever stopped to ask: How does kubectl know which cluster to talk to, which user to authenticate as, and which namespace to use by default? kubectl config use-context dev-context kubectl get pods #

To persist the merged config into your default file: Set the KUBECONFIG environment variable with a list