WEBVTT 00:00.970 --> 00:03.760 Hello and welcome to this lecture in this lecture 00:03.760 --> 00:11.810 We look at KubeConfig in Kubernetes so far we have seen how to generate a certificate for a user. 00:11.900 --> 00:17.840 We have seen how a client uses the certificate file and key to query the kubernetes Rest API for a 00:17.840 --> 00:18.890 list of pods 00:18.890 --> 00:24.350 using Curl. In this case my cluster is called my-kube-playground, 00:24.410 --> 00:30.740 so send a CURL request to the address of the kube-api server while passing in the pair of files along 00:30.740 --> 00:33.650 with the ca certificate as options. 00:33.650 --> 00:38.650 This is then validated by the API server to authenticate the user. 00:38.690 --> 00:42.370 Now how do you do that while using the kubectl command? 00:42.470 --> 00:49.460 You can specify the same information using the options server, client-key, client-certificate and certificate 00:49.460 --> 00:57.410 authority with the kubectl utililty. Obviously typing those in every time is a tedious task. So you 00:57.410 --> 01:05.030 move these information to a configuration file called as KubeConfig. And then specify this file as the 01:05.030 --> 01:13.450 kubeconfig optionin your command. By default the kubectl tool looks for a file named config under 01:13.510 --> 01:20.890 a directory .kube under the users home directory. So if you create the KubeConfig file there, you 01:20.890 --> 01:25.340 don’t have to specify the path to the file explicitly in the kubectl command. 01:26.020 --> 01:31.150 That’s the reason you haven’t been specifying any options for your kubectl commands so far. 01:32.300 --> 01:35.320 The kubeconfig file is in a specific format. 01:35.360 --> 01:45.560 Let’s take a look at that. The config file has 3 sections. Clusters, Users and Contexts. Clusters are 01:45.560 --> 01:48.410 the various kubernetes clusters that you need access to. 01:48.890 --> 01:55.700 So you have multiple clusters for development environment or testing environment or prod or for different 01:55.760 --> 02:03.840 organizations or on different cloud providers etc. All those go their users are the user accounts 02:03.930 --> 02:06.510 with which you have access to these clusters. 02:06.540 --> 02:14.250 For example the admin user. A Dev User, a prod user etc. These users may have different privileges 02:14.460 --> 02:23.050 on different clusters finally contexts marry these together context define which user account will be 02:23.050 --> 02:25.490 used to access which cluster. 02:25.600 --> 02:32.410 For example you could create a context named admin at production that will use the admin account to 02:32.410 --> 02:39.160 access a production cluster. Or I may want to access the cluster I have setup on Google with the devusers 02:39.190 --> 02:46.160 credentials to test deploying the application I built remember you're not creating any new users or 02:46.210 --> 02:50.100 configuring any kind of user access or authorization in the cluster. 02:50.240 --> 02:57.500 With this process you're using existing users with their existing privileges and defining what user 02:57.560 --> 03:00.620 you're going to use to access what cluster. 03:00.620 --> 03:06.350 That way you don’t have to specify the user certificates and server address in each and every kubectl 03:06.350 --> 03:06.790 command. 03:06.800 --> 03:09.570 You run. 03:09.610 --> 03:11.880 So how does it fit into our example. 03:12.100 --> 03:19.560 The server specification in our command goes into the cluster section the admin users keys and certificates 03:19.890 --> 03:28.030 goes into the users section. You then create a context that specifies to use the MyKubeAdmin user to 03:28.030 --> 03:33.670 access the MyKubePlayground cluster. Let’s look at a real KubeConfig file 03:33.670 --> 03:37.270 now. The kubeConfig is in a YAML format. 03:37.270 --> 03:43.220 It has apiVersion set to v1. The kind is config. And then it has 3 sections 03:43.240 --> 03:52.330 as we discussed. One for clusters, one for contexts and one for users. Each of these is in an array format. 03:52.430 --> 03:55.400 That way you can specify multiple clusters. 03:55.580 --> 03:59.900 users or contexts within the same file. Under clusters 03:59.900 --> 04:06.320 we add a new item for our kube-playground cluster. We name it mukubeplayground and specify the server 04:06.320 --> 04:08.670 address under the server field. 04:08.930 --> 04:13.130 It also requires the certificate of the Certificate Authority. 04:13.130 --> 04:19.250 We then add an entry into the users section to specify details of my kube admin user. Provide the 04:19.250 --> 04:21.760 location of the client’s certificate and key pair. 04:21.830 --> 04:26.780 So we have now defined the cluster and the user to access the cluster. 04:26.780 --> 04:32.740 Next we create an entry under the context section to link the two together we will name the context. 04:32.780 --> 04:36.260 my kube admin at my kube playground. 04:36.260 --> 04:43.260 We will then specify the same name we used for a cluster and user follow the same procedure to add all 04:43.260 --> 04:50.380 the clusters you daily access the user credentials you use to access them as well as the contacts once 04:50.380 --> 04:51.760 the file is ready. 04:51.760 --> 04:58.390 remember that you don’t have to create any object like you usually do for other kubernetes objects. 04:58.390 --> 05:04.500 The file is left as is and is read by the kubectl command and the required values are used. 05:05.610 --> 05:09.810 Now, how does kubectl know which context to chose from? 05:09.810 --> 05:14.400 We have defined three contexts here which one should it start with. 05:14.400 --> 05:20.580 You can specify the default context to use by adding a field current-context to the kubeconfig file. 05:21.030 --> 05:23.050 specify the name of the context you use. 05:23.070 --> 05:26.600 In this case kubectl will always use the context 05:26.640 --> 05:32.740 dev-user@google to access the google clusters using the dev-user’s credentials. 05:32.920 --> 05:37.840 There are command line options available within kubectl to view and modify the kubeconfig files. 05:38.440 --> 05:40.850 to view the current file being used. 05:40.960 --> 05:44.050 run the kubectl config view command. 05:44.080 --> 05:50.230 It lists the clusters, contexts and users as well as the current-context set. As we discussed 05:50.260 --> 05:51.190 earlier, 05:51.250 --> 05:56.650 if you do not specify which kubeconfig file to use, it ends up using the default file located in the 05:56.650 --> 05:59.620 folder .kube in users home directory. 06:00.250 --> 06:06.640 Alternatively you can specify a kubeconfig file by passing the kubeconfig option in the command line 06:06.760 --> 06:07.320 like this. 06:09.910 --> 06:15.900 We will move our custom config to the home directory so this becomes our default config file. 06:15.910 --> 06:18.100 So how do you update your current context. 06:19.030 --> 06:23.770 Say you have been using my-kube-admin user to access my-kube-playground. 06:23.860 --> 06:29.860 How do you change the context to use prod-user to access the production cluster? Run the kubectl 06:29.860 --> 06:30.550 config 06:30.550 --> 06:37.140 use-context command to change the current-context to the prod-user@production context. 06:37.180 --> 06:40.540 This can be seen in the current context field in the file. 06:40.540 --> 06:46.990 So yes the changes made by kubectl config command actually reflects in the file. 06:47.150 --> 06:51.110 You can make other changes in the file update or delete items in it. 06:51.110 --> 06:54.930 using other variations of the kubectl config command. 06:54.980 --> 06:57.240 Check them out when you get time. 06:57.370 --> 06:59.350 What about name spaces for example. 06:59.350 --> 07:03.870 Each cluster may be configured with multiple name spaces within it. 07:04.000 --> 07:07.870 Can you configure a context to switch to a particular namespace. 07:08.320 --> 07:14.110 Yes! The context section in the kubeconfig file can take additional field called namespace where you 07:14.110 --> 07:16.630 can specify a particular namespace. 07:16.630 --> 07:25.540 This way when you switch to that context you will automatically be in a specific namespace finally a 07:25.540 --> 07:27.410 word on certificates. 07:27.640 --> 07:32.830 You have seen path to certificate files mentioned in kubeconfig like this. 07:32.830 --> 07:40.450 Well, its better to use the full path like this. But remember there is also another way to specify the 07:40.450 --> 07:46.030 certificate credentials. Let’s look at the first one for instance where we configure the path to the 07:46.030 --> 07:47.660 Certificate Authority. 07:47.890 --> 07:55.460 We have the contents of the ca.crt file on the right. Instead of using the certificate-authority field and 07:55.460 --> 07:57.190 the path to the file. 07:57.190 --> 08:03.430 you may optionally use the certificate-authority-data field and provide the contents of the certificate 08:03.520 --> 08:06.660 itself. But not the file as is, 08:06.660 --> 08:12.230 Convert the contents to a base64 encoded format and then pass that in. 08:12.330 --> 08:19.530 Similarly if you see a file with the certificates data in the encoded format use the Base64 decode option 08:19.620 --> 08:21.060 to decode the certificate. 08:22.460 --> 08:24.350 Well that's it for this lecture. 08:24.350 --> 08:26.750 Head over to the practice exercises section. 08:26.750 --> 08:30.820 Practice working with kubeconfig files and troubleshooting issues.