Extension interfaces (CRI, CNI, CSI)

Exam tasks: 1.7 (understand extension interfaces: CNI, CSI, CRI and so on)

The decision: which plugin owns this behaviour (running containers, giving Pods an IP, attaching a volume), and where on the node or in the API do you look to inspect or fix it?

What plugs in whereCopy Anchor Link

All three are out-of-tree: the vendor ships the plugin, Kubernetes ships only the interface. That's why swapping the runtime, network or storage doesn't need a new Kubernetes build.

CRI: the container runtimeCopy Anchor Link

• The kubelet's containerRuntimeEndpoint (in /var/lib/kubelet/config.yaml) points at the runtime socket. kubeadm detects it at init and join, or takes --cri-socket.
• crictl speaks CRI directly, so it works with any runtime. It's your tool when the API server is down.

sudo crictl ps -a                 # containers, including exited ones
sudo crictl pods                  # Pod sandboxes
sudo crictl logs <container-id>
sudo crictl images
cat /etc/crictl.yaml              # runtime-endpoint: unix:///run/containerd/containerd.sock

• A RuntimeClass picks a different OCI handler configured in the runtime (for example gVisor or Kata for sandboxed workloads). Pods opt in with spec.runtimeClassName.

apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
  name: sandboxed
handler: runsc        # must match a handler name in the containerd config

CNI: Pod networkingCopy Anchor Link

• When a Pod sandbox starts, the runtime reads the lowest-sorted config file in /etc/cni/net.d/ and runs the plugin binaries from /opt/cni/bin/ it names. The plugin creates the interface and allocates the IP.
• Most plugins run a DaemonSet that writes that config and the binaries onto each node, plus an agent that programs routes, tunnels or eBPF.
• Until a config exists, the node reports NetworkReady=false and stays NotReady.

ls /etc/cni/net.d/                         # which plugin wrote config
k get pods -n kube-system -o wide | grep -Ei 'calico|cilium|flannel'
k get ds -A                                # the CNI agent DaemonSet

CSI: storage driversCopy Anchor Link

• Controller plugin (a Deployment or StatefulSet) with sidecars: external-provisioner creates volumes for PVCs, external-attacher handles VolumeAttachments, external-resizer and external-snapshotter do expansion and snapshots.
• Node plugin (a DaemonSet) with node-driver-registrar, which registers the driver's socket with the kubelet. The kubelet calls it to stage and mount volumes into Pods.
• A StorageClass's provisioner field is the CSI driver name, for example ebs.csi.aws.com or a name your driver publishes.

k get csidrivers                   # installed drivers and their capabilities
k get csinodes                     # which drivers registered on which node
k get volumeattachments            # attach state per PV and node
k get sc                           # provisioner column = CSI driver name

Other extension pointsCopy Anchor Link

ScenariosCopy Anchor Link

DrillCopy Anchor Link

kubectl config use-context cka-ext

Answer these about the cluster and write each answer on its own line in /opt/answers/plugins.txt: (1) the CRI socket path the kubelet on node ext-w1 uses, (2) the CNI plugin installed, (3) the provisioner of the default StorageClass.

ssh ext-w1
sudo grep containerRuntimeEndpoint /var/lib/kubelet/config.yaml
# or: ps -ef | grep [k]ubelet  (look for --container-runtime-endpoint)
ls /etc/cni/net.d/
exit

k get pods -n kube-system -o wide | grep -Ei 'calico|cilium|flannel|weave'
k get sc       # the (default) row, PROVISIONER column

cat > /opt/answers/plugins.txt <<'EOF'
unix:///run/containerd/containerd.sock
cilium
csi.hostpath.example.io
EOF
cat /opt/answers/plugins.txt

Further readingCopy Anchor Link

• Container runtimes
• Network plugins
• CSI volumes
• Debugging Kubernetes nodes with crictl