- Which container runtime endpoint is configured for kubelet?
- Where are the CNI plugin binaries stored?
- Which of the candidate plugins is not present on the host?
- Which CNI plugin is configured for the cluster?
- Which CNI plugin binary will kubelet invoke after creating a container and its namespaces?
1) Inspect the kubelet service to find the container runtime endpoint
Locate the kubelet process and inspect its command-line flags. Preferps aux (not ps -aux) to follow best practice.
unix:///var/run/containerd/containerd.sock (i.e., containerd).
The kubelet flag
--container-runtime-endpoint points to the CRI socket that kubelet uses to communicate with the container runtime. In this environment kubelet is configured to use containerd via unix:///var/run/containerd/containerd.sock.2) Path containing all CNI plugin binaries
On many distributions the standard path for CNI plugin binaries is/opt/cni/bin. List the directory to see which plugins are installed:
/opt/cni/bin
3) Which plugin from the candidate list is not available on the host?
From thels output above, common plugins such as vlan, bridge, dhcp, flannel, and portmap are present. The vendor-specific cisco plugin is not present in /opt/cni/bin.
Answer: cisco (not available)
4) Which CNI plugin is configured for this Kubernetes cluster?
Check the CNI configuration directory to find the active config or conflist:flannel as the primary plugin, with portmap as a delegate plugin.
5) Which binary will be run by kubelet after a container and its namespaces are created?
CNI conflists define the plugin execution order. Kubelet (through the CNI library) invokes the plugin binaries from the binaries directory (/opt/cni/bin) in the same order they appear in the conflist.
Answer: /opt/cni/bin/flannel will be executed first, followed by /opt/cni/bin/portmap.