Use context: kubectl config use-context k8s-c1-H
Ssh into the controlplane node with ssh cluster1-controlplane1
. Check how the controlplane components kubelet, kube-apiserver, kube-scheduler, kube-controller-manager and etcd are started/installed on the controlplane node. Also find out the name of the DNS application and how it’s started/installed on the controlplane node.
Write your findings into file /opt/course/8/controlplane-components.txt
. The file should be structured like:
1 2 3 4 5 6 7 8 9 10 |
# /opt/course/8/controlplane-components.txt kubelet: [TYPE] kube-apiserver: [TYPE] kube-scheduler: [TYPE] kube-controller-manager: [TYPE] etcd: [TYPE] dns: [TYPE] [NAME] |
Choices of [TYPE]
are: not-installed
, process
, static-pod
, pod
Investigating Control Plane Components in a Kubernetes Cluster
Understanding how control plane components are managed in a Kubernetes cluster is essential for effective troubleshooting and maintenance. In this guide, we’ll explore how to identify and investigate the control plane components, such as kubelet, etcd, and coredns, in a running Kubernetes cluster.
Step 1: Checking the Kubelet Process
We begin by logging into the control plane node and checking for the kubelet process. This can be done using SSH and the ps
command:
1 2 3 4 5 6 7 |
➜ ssh cluster1-controlplane1 root@cluster1-controlplane1:~# ps aux | grep kubelet |
This command will display the kubelet process running on the node.
Step 2: Identifying Systemd Services
Next, we’ll check which Kubernetes components are managed via systemd by searching the /usr/lib/systemd
directory:
1 2 3 4 5 6 7 8 9 10 |
➜ root@cluster1-controlplane1:~# find /usr/lib/systemd | grep kube /usr/lib/systemd/system/kubelet.service /usr/lib/systemd/system/kubelet.service.d /usr/lib/systemd/system/kubelet.service.d/10-kubeadm.conf ➜ root@cluster1-controlplane1:~# find /usr/lib/systemd | grep etcd |
This output shows that the kubelet service is controlled via systemd. However, no other services, like etcd, are managed this way.
Step 3: Investigating Static Pods
Since the cluster seems to have been set up using kubeadm, the core control plane components are likely running as static Pods. We can confirm this by checking the default manifest directory:
1 2 3 4 5 6 7 8 9 10 |
➜ root@cluster1-controlplane1:~# find /etc/kubernetes/manifests/ /etc/kubernetes/manifests/ /etc/kubernetes/manifests/kube-controller-manager.yaml /etc/kubernetes/manifests/etcd.yaml /etc/kubernetes/manifests/kube-apiserver.yaml /etc/kubernetes/manifests/kube-scheduler.yaml |
This directory contains YAML files for the kube-controller-manager, etcd, kube-apiserver, and kube-scheduler, indicating they are configured as static Pods.
Step 4: Checking Running Pods in kube-system Namespace
To see all the Pods running on the control plane node, use the following command:
1 2 3 4 5 6 7 8 9 10 11 12 13 |
➜ root@cluster1-controlplane1:~# kubectl -n kube-system get pod -o wide | grep controlplane1 coredns-5644d7b6d9-c4f68 1/1 Running ... cluster1-controlplane1 coredns-5644d7b6d9-t84sc 1/1 Running ... cluster1-controlplane1 etcd-cluster1-controlplane1 1/1 Running ... cluster1-controlplane1 kube-apiserver-cluster1-controlplane1 1/1 Running ... cluster1-controlplane1 kube-controller-manager-cluster1-controlplane1 1/1 Running ... cluster1-controlplane1 kube-proxy-q955p 1/1 Running ... cluster1-controlplane1 kube-scheduler-cluster1-controlplane1 1/1 Running ... cluster1-controlplane1 weave-net-mwj47 2/2 Running ... cluster1-controlplane1 |
This command shows the 5 main static Pods running on the control plane node.
Step 5: Investigating the DNS Component
The DNS component in this cluster seems to be coredns. To determine how it is controlled, we can check the DaemonSets and Deployments in the kube-system namespace:
1 2 3 4 5 6 7 8 9 10 11 12 |
➜ root@cluster1-controlplane1$ kubectl -n kube-system get ds NAME DESIRED CURRENT ... NODE SELECTOR AGE kube-proxy 3 3 ... kubernetes.io/os=linux 155m weave-net 3 3 ... <none> 155m ➜ root@cluster1-controlplane1$ kubectl -n kube-system get deploy NAME READY UP-TO-DATE AVAILABLE AGE coredns 2/2 2 2 155m |
The coredns component is managed via a Deployment.
Step 6: Summarizing the Findings
We can summarize our findings in a text file as follows:
1 2 3 4 5 6 7 8 9 10 11 |
# /opt/course/8/controlplane-components.txt kubelet: process kube-apiserver: static-pod kube-scheduler: static-pod kube-controller-manager: static-pod etcd: static-pod dns: pod coredns |
This file shows the management method for each control plane component, helping you understand how the cluster is set up.
By following these steps, you can effectively investigate the control plane components of a Kubernetes cluster, identify how they are managed, and be better prepared to troubleshoot any issues that arise.