WEBVTT 00:01.090 --> 00:07.600 Hello and welcome to this lecture in this lecture we see how we can view certificates in an existing 00:07.600 --> 00:13.070 cluster. So you join a new team to help them manage their kubernetes environment. 00:13.120 --> 00:19.180 Your new administrator to this team is being told that there are multiple issues related to certificates 00:19.200 --> 00:25.840 in the environment so you're asked to perform a health check of all the certificates in the entire cluster. 00:25.840 --> 00:31.350 What do you do first of all it's important to know how the cluster was set up. 00:31.360 --> 00:35.980 There are different solutions available of deploying a kubernetes cluster and they use different 00:35.980 --> 00:42.760 methods to generate and manage certificates. If you were to deploy a kubernetes cluster from scratch 00:42.940 --> 00:48.610 you generate all the certificates by yourself as we did in the previous lecture or else if you were 00:48.610 --> 00:54.730 to rely on an automated provisioning tool like kubeadm, it takes care of automatically generating 00:54.730 --> 01:01.610 and configuring the cluster for you while you deploy all the components as native services on the nodes 01:01.700 --> 01:06.020 in the hard way, the kubeadm tool deploys these as PODs. 01:06.050 --> 01:11.600 So it's important to know where to look at to view the right information in this lecture. 01:11.600 --> 01:16.020 we are going to look at a cluster provisioned by kubeadm as an example. 01:16.190 --> 01:17.930 In order to perform a health check. 01:17.990 --> 01:22.140 Start by identifying all the certificates used in the system. 01:22.280 --> 01:27.690 I have created a sample Excel spreadsheet for you. Check out the resources link at the end of this lecture 01:27.710 --> 01:36.380 to access it so the idea is to create a list of certificate files used their pods the names configured 01:36.380 --> 01:37.100 on them. 01:37.280 --> 01:43.700 The astronaut names configured if any the organisation the certificate account belongs to the issue 01:43.700 --> 01:46.720 of the certificate and the expiration date on the certificate. 01:47.570 --> 01:49.110 So how do you get these. 01:49.370 --> 01:54.980 Start with the certificate files used. For this, in an environment setup by kube-adm 01:55.100 --> 02:02.330 look for the kube-apiserver definition file under /etc/kubernetes/manifests folder. 02:03.320 --> 02:09.920 The command used to start the api server has information about all the certificates. Identify 02:09.930 --> 02:14.880 the certificate file used for each purpose and note it down next. 02:14.950 --> 02:20.160 take each certificate and look inside it to find more details about that certificate. 02:20.160 --> 02:27.910 For example, we will start with the apiserver certificate file. Run the openssl x509 command 02:28.060 --> 02:33.420 and provide the certificate file as input to decode the certificate and view details. 02:33.730 --> 02:37.210 Start with a name on the certificate under the subject section. 02:37.210 --> 02:44.350 In this case its kube-apiserver. Then the alternative names. The kube-api server has many, 02:44.380 --> 02:50.590 so you must ensure all of them are there and then check the validity section of the certificate to identify 02:50.590 --> 02:54.760 the expiry date and then the issuer of the certificate. 02:54.760 --> 02:58.200 This should be the CA who issued the certificate. Kubeadm 02:58.210 --> 03:05.620 names the kubernetes CA as kubernetes itself. Follow the same procedure to identify information 03:05.680 --> 03:11.190 about all the other certificates things to look for check to make sure you have the right names the 03:11.230 --> 03:16.780 right alternate names make sure the certificates are part of the correct organization and most importantly 03:16.910 --> 03:21.760 you are issued by the right issuer and that the certificates are not expired. 03:22.240 --> 03:27.970 The certificate requirements are listed in detail in the Kubernetes Documentation page. Check the 03:27.970 --> 03:34.640 references section for the link when you run into issues you want to start looking at logs if you set 03:34.640 --> 03:41.190 up the cluster from scratch by yourself and the services are configured as native services in the OS 03:41.670 --> 03:47.670 you want to start looking at the service logs using the operating systems logging functionality in case 03:47.670 --> 03:53.520 you setup the cluster with kubeadm, then the various components are deployed as PODs. So you can look 03:53.520 --> 04:01.190 at the logs using kubectl logs command followed by the pod name. Sometimes if the core components 04:01.220 --> 04:08.900 such as the kubernetes api server or the etcd server are down, the kubectl commands wont function. In that case 04:09.230 --> 04:15.380 you have to go one level down to docker to fetch the logs. List all the containers using the docker 04:15.460 --> 04:21.430 ps –a command. And then view the logs using docker logs command followed by the container ID. 04:22.680 --> 04:24.450 well that's it for this lecture. 04:24.450 --> 04:29.970 Head over to the practice test and practice viewing information about existing cluster.