Hello and welcome to this lecture in this lecture
We look at KubeConfig in Kubernetes so far we have seen how to generate a certificate for a user.
We have seen how a client uses the certificate file and key to query the kubernetes Rest API for a
list of pods
using Curl. In this case my cluster is called my-kube-playground,
so send a CURL request to the address of the kube-api server while passing in the pair of files along
with the ca certificate as options.
This is then validated by the API server to authenticate the user.
Now how do you do that while using the kubectl command?
You can specify the same information using the options server, client-key, client-certificate and certificate
authority with the kubectl utililty. Obviously typing those in every time is a tedious task. So you
move these information to a configuration file called as KubeConfig. And then specify this file as the
kubeconfig optionin your command. By default the kubectl tool looks for a file named config under
a directory .kube under the users home directory. So if you create the KubeConfig file there, you
don’t have to specify the path to the file explicitly in the kubectl command.
That’s the reason you haven’t been specifying any options for your kubectl commands so far.
The kubeconfig file is in a specific format.
Let’s take a look at that. The config file has 3 sections. Clusters, Users and Contexts. Clusters are
the various kubernetes clusters that you need access to.
So you have multiple clusters for development environment or testing environment or prod or for different
organizations or on different cloud providers etc. All those go their users are the user accounts
with which you have access to these clusters.
For example the admin user. A Dev User, a prod user etc. These users may have different privileges
on different clusters finally contexts marry these together context define which user account will be
used to access which cluster.
For example you could create a context named admin at production that will use the admin account to
access a production cluster. Or I may want to access the cluster I have setup on Google with the devusers
credentials to test deploying the application I built remember you're not creating any new users or
configuring any kind of user access or authorization in the cluster.
With this process you're using existing users with their existing privileges and defining what user
you're going to use to access what cluster.
That way you don’t have to specify the user certificates and server address in each and every kubectl
command.
You run.
So how does it fit into our example.
The server specification in our command goes into the cluster section the admin users keys and certificates
goes into the users section. You then create a context that specifies to use the MyKubeAdmin user to
access the MyKubePlayground cluster. Let’s look at a real KubeConfig file
now. The kubeConfig is in a YAML format.
It has apiVersion set to v1. The kind is config. And then it has 3 sections
as we discussed. One for clusters, one for contexts and one for users. Each of these is in an array format.
That way you can specify multiple clusters.
users or contexts within the same file. Under clusters
we add a new item for our kube-playground cluster. We name it mukubeplayground and specify the server
address under the server field.
It also requires the certificate of the Certificate Authority.
We then add an entry into the users section to specify details of my kube admin user. Provide the
location of the client’s certificate and key pair.
So we have now defined the cluster and the user to access the cluster.
Next we create an entry under the context section to link the two together we will name the context.
my kube admin at my kube playground.
We will then specify the same name we used for a cluster and user follow the same procedure to add all
the clusters you daily access the user credentials you use to access them as well as the contacts once
the file is ready.
remember that you don’t have to create any object like you usually do for other kubernetes objects.
The file is left as is and is read by the kubectl command and the required values are used.
Now, how does kubectl know which context to chose from?
We have defined three contexts here which one should it start with.
You can specify the default context to use by adding a field current-context to the kubeconfig file.
specify the name of the context you use.
In this case kubectl will always use the context
dev-user@google to access the google clusters using the dev-user’s credentials.
There are command line options available within kubectl to view and modify the kubeconfig files.
to view the current file being used.
run the kubectl config view command.
It lists the clusters, contexts and users as well as the current-context set. As we discussed
earlier,
if you do not specify which kubeconfig file to use, it ends up using the default file located in the
folder .kube in users home directory.
Alternatively you can specify a kubeconfig file by passing the kubeconfig option in the command line
like this.
We will move our custom config to the home directory so this becomes our default config file.
So how do you update your current context.
Say you have been using my-kube-admin user to access my-kube-playground.
How do you change the context to use prod-user to access the production cluster? Run the kubectl
config
use-context command to change the current-context to the prod-user@production context.
This can be seen in the current context field in the file.
So yes the changes made by kubectl config command actually reflects in the file.
You can make other changes in the file update or delete items in it.
using other variations of the kubectl config command.
Check them out when you get time.
What about name spaces for example.
Each cluster may be configured with multiple name spaces within it.
Can you configure a context to switch to a particular namespace.
Yes! The context section in the kubeconfig file can take additional field called namespace where you
can specify a particular namespace.
This way when you switch to that context you will automatically be in a specific namespace finally a
word on certificates.
You have seen path to certificate files mentioned in kubeconfig like this.
Well, its better to use the full path like this. But remember there is also another way to specify the
certificate credentials. Let’s look at the first one for instance where we configure the path to the
Certificate Authority.
We have the contents of the ca.crt file on the right. Instead of using the certificate-authority field and
the path to the file.
you may optionally use the certificate-authority-data field and provide the contents of the certificate
itself. But not the file as is,
Convert the contents to a base64 encoded format and then pass that in.
Similarly if you see a file with the certificates data in the encoded format use the Base64 decode option
to decode the certificate.
Well that's it for this lecture.
Head over to the practice exercises section.
Practice working with kubeconfig files and troubleshooting issues.