KodeCloud CKAD KubeConfig

Understanding kubeconfig file¶

Kubectl uses kubeconfig to authenticate the user to the cluster.
- There is no file called kubeconfig however, any file that is used to configure access to a Kubernetes cluster is referred as kubeconfig.
To authenticate with the cluster the user has to use client certificate and client key.
- Using client key and client certificate is one way of authentication into the cluster.
- Other authentication mechanisms
Accessing the k8s api-server using client certificate and client key by making a curl request

curl https://my-kube-playground:6443/api/v1/pods \
    --key admin.key
    --cert admin.crt
    --cacert ca.crt

We can specify the same information using the kubectl command

kubectl get pods
    --server my-kube-playground:6443
    --certificate-authority ca.crt
    --client-key admin.key
    --client-certificate admin.crt

Typing these in every time is a tedious task so we move it to a kubeconfig file and then specify it while running the commands
- k get pods --kubeconfig config

Order of lookup for the kubeconfig file

First the --kubeconfig specified with the kubectl command is given preference. Example: k get pods --kubeconfig <location>
kubectl then looks for the kubeconfig file path in the environment variable KUBECONFIG.
If it DOESN'T find it or if the environment variable is empty then it falls back to ~/.kube/config.

We can combine multiple kubeconfig files without literally combining them using :.
- export KUBECONFIG=~/.kube/config:~/.kube/config2

DON'T use "" in the above export statement since ~ are NOT expanded by "".

'' don't expand anything.

The kubeconfig file is in a specific format.
It contains 3 sections: Clusters, Users & Contexts
- Context defines which user account will be used to access which cluster.
- Context is used to define the relationship between user and the cluster.
Sample kubeconfig file
Similarly we can add other clusters
Contexts need not be of the format <user>@<cluster> they can be simple words also. It is up to us what we want to name them.

How does kubectl know which context to choose from?

We can specify the default context by adding it in the kubeconfig file under current-context.
current-context: <name-of-context>

View the current kubeconfig file: k config view
- If we don't specify which file we want to use it will end up using the kubeconfig at the default location.
Viewing a specific kubeconfig file: k config view --kubeconfig=myconfig
We can change the current context using:
- k config use-context <context>

Changes made by the kubectl actually reflects in the kubeconfig file.

We can change contexts, add users, add contexts and so on.

In each cluster we may have different namespaces.
We can configure a context to switch to a particular namespace.
- The context section in the kubeconfig file can take additional field called namespace.
- So when we switch to that context we will automatically be in that namespace.
Whenever we are adding client key, client certificate or the cluster certificate in the config file then we should specify the full path of the certificate.
Optionally we can directly specify the contents of certificate in the kubeconfig file after base64 encoding it.
- For correctly base64 encoding a certificate use base64 -w 0.

Last updated: 2023-05-23