Introduction

To figure out which CNI plugin a Kubernetes cluster is using, you usually need to inspect both the node filesystem and the cluster workloads running in kube-system. The plugin name is often visible in one of three places: the CNI config directory, the installed plugin binaries, or the daemonset or pods that deployed the networking layer.

Where CNI Configuration Usually Lives

On most Linux nodes, the default CNI paths are:

• config files in /etc/cni/net.d
• plugin binaries in /opt/cni/bin

Start by listing the config directory on a node:

sudo ls -la /etc/cni/net.d
sudo cat /etc/cni/net.d/*

You will often see a file whose contents clearly reveal the plugin, for example calico, flannel, cilium, or another plugin name in the JSON configuration.

A typical snippet might contain a field such as:

1{
2  "cniVersion": "0.3.1",
3  "name": "k8s-pod-network",
4  "type": "calico"
5}

The type field is usually the fastest clue.

Check the Installed Binaries Too

The config file tells Kubernetes which plugin to invoke, while the binary directory shows what is installed on the node:

sudo ls -la /opt/cni/bin

If you see binaries such as calico, flannel, cilium-cni, or bridge, that supports what the config files are telling you.

Keep in mind that multiple binaries may exist. The active plugin is determined by configuration, not simply by whatever happens to be present in the directory.

Use Kubernetes Itself for Clues

Many CNI plugins run daemonsets or other pods in the kube-system namespace. This is often the easiest place to look if you do not have direct node access.

kubectl get pods -n kube-system
kubectl get ds -n kube-system

Common examples:

• Calico often shows calico-node
• Flannel often shows kube-flannel-ds
• Cilium often shows cilium
• Weave often shows weave-net

This does not replace checking node config, but it is a strong signal.

Kubelet Flags Can Override Paths

The usual directories are defaults, not laws. Kubelet can be configured with custom CNI paths such as:

• '--cni-conf-dir'
• '--cni-bin-dir'

If /etc/cni/net.d looks empty or wrong, inspect the kubelet startup configuration on the node. Depending on the distro, this may be visible in a systemd unit, drop-in file, or a kubelet config file.

Example:

ps aux | grep kubelet
systemctl cat kubelet

Managed Kubernetes offerings may hide some of this from you, but self-managed clusters usually expose it directly.

What Managed Clusters Change

In managed Kubernetes platforms, you may still be using CNI, but the provider may install and manage the networking components for you. In those cases:

• the plugin may be provider-specific
• the node filesystem may be less accessible
• documentation for the managed service becomes part of the answer

Even there, kubectl get pods -n kube-system often still reveals what networking stack is deployed.

Troubleshooting Workflow

A practical sequence is:

1. look at kube-system daemonsets and pods
2. inspect /etc/cni/net.d on a node
3. inspect /opt/cni/bin
4. check kubelet flags if the default paths are empty or unexpected

That order usually gets you to the answer quickly.

Common Pitfalls

The biggest mistake is assuming the presence of a plugin binary means the cluster is using it. Kubernetes uses the plugin named in the active config, not every binary installed on disk.

Another issue is forgetting that multiple config files can exist. The selected file depends on how the runtime and kubelet are configured, so you need to inspect the actual contents carefully.

People also sometimes look only at pods and never at the node config. Pods tell you what was deployed, but node configuration tells you what is actually wired into the runtime.

Finally, do not assume every cluster uses the default CNI directories. Custom kubelet flags can move both config and binaries elsewhere.

Summary

• The default CNI config path is usually /etc/cni/net.d.
• The default CNI binary path is usually /opt/cni/bin.
• 'kubectl get pods and kubectl get ds -n kube-system often reveal the plugin name quickly.'
• The active plugin is determined by config, not just by installed binaries.
• If defaults do not match reality, inspect kubelet flags for custom CNI paths.