Learn Flannel - Integration with CNI Plugins

#Introduction

Flannel isn't one program that does everything. Behind the scenes there's a collection of CNI plugins working together, each with one responsibility. This episode opens that cabinet.

We will dissect the roles of bridge, portmap, bandwidth, and the flannel plugin, read the 10-flannel.conflist configuration, then explore the integration with Multus to bring multiple network interfaces to one Pod.

#The Role of the CNI Plugins

#Four Core Plugins

Every Pod Flannel creates goes through this plugin chain:

• flannel: the main plugin that reads subnet.env and determines the network configuration.
• bridge: creates the cni0 bridge and connects the Pod's veth to that bridge.
• portmap: translates a Pod's exposed ports to the host IP for external access.
• bandwidth: enforces per-Pod bandwidth limits via token bucket.

ls -la /opt/cni/bin/

The output of ls /opt/cni/bin/ shows plugin binaries such as bridge, portmap, bandwidth, flannel, and others. All these binaries are provided by containernetworking/plugins and mounted to the node by the Flannel DaemonSet.

#The /opt/cni/bin Directory

Kubelet calls plugins by the binary name in this directory. If one binary is missing, creating a Pod that needs that plugin will fail. This is why the Flannel DaemonSet ensures all binaries are available on every node whenever the DaemonSet is deployed.

#Flannel's CNI Configuration

#Reading 10-flannel.conflist

The CNI configuration file for Flannel is named 10-flannel.conflist and lives in /etc/cni/net.d. Kubelet uses this file as the Pod network definition:

{
  "name": "flannel",
  "cniVersion": "0.3.1",
  "plugins": [
    {
      "type": "flannel",
      "delegate": {
        "hairpinMode": true,
        "isDefaultGateway": true
      }
    },
    {
      "type": "portmap",
      "capabilities": {
        "portMappings": true
      }
    }
  ]
}

The first block uses the flannel plugin, which delegates bridge creation to the bridge plugin. The second block adds portmap for forwarding Pod ports.

cat /etc/cni/net.d/10-flannel.conflist

The cat /etc/cni/net.d/10-flannel.conflist command shows the same file on a node. You can see kubelet uses this configuration every time a new Pod is created.

#Plugin Order Matters

The order of plugins in the conflist determines the order of execution when a Pod is created and torn down. On teardown, the order is reversed. This is important to understand when modifying the conflist: don't let portmap execute before the main network is formed.

#Integration with Multus

#When You Need Multus

By default a Pod has one main network interface. Cases like DPDK, SR-IOV, or applications that need several networks at once require more than one interface. Multus bridges this by letting a Pod attach several secondary networks on top of the main one.

#NetworkAttachmentDefinition for Flannel

Flannel as the main network can be combined with Multus through a NetworkAttachmentDefinition:

apiVersion: k8s.cni.cncf.io/v1
kind: NetworkAttachmentDefinition
metadata:
  name: flannel-net
spec:
  config: '{
    "cniVersion": "0.3.1",
    "type": "flannel",
    "delegate": {
      "isDefaultGateway": true
    }
  }'

The definition above creates a flannel-net network that can be attached to Pods. An annotation on the Pod selects which network:

apiVersion: v1
kind: Pod
metadata:
  name: multi-net-pod
  annotations:
    k8s.v1.cni.cncf.io/networks: flannel-net
spec:
  containers:
    - name: app
      image: busybox

Notice this pattern: the main network is still handled by kubelet, while additional networks are managed by Multus based on annotations.

#Architecture Considerations

Adding Multus adds operational complexity. Make sure the need for multiple networks genuinely exists before adding this layer. For the majority of workloads, a single Flannel network is more than enough.

#Troubleshooting Plugins

#A Pod Fails to Be Created

The most common symptom when a plugin has a problem: a Pod stuck in the ContainerCreating state. Check its events:

kubectl describe pod <nama-pod> | tail -20

The output of kubectl describe pod shows the CNI error specifically, for example the bridge plugin not found or portmap failing to load. From that message, you can tell which plugin needs checking.

#A Plugin Not Installed

If the error mentions a binary that doesn't exist, check the CNI directory on the node:

kubectl -n kube-flannel get pods -l k8s-app=flannel -o wide

A healthy kube-flannel Pod ensures the plugins are available on the node. Restarting the DaemonSet usually fixes a node that lost its binaries due to an image update.

#Conclusion

Episode 11 opened the box of the CNI plugins behind Flannel: the roles of bridge, portmap, and bandwidth, the contents of 10-flannel.conflist, and the integration with Multus for multiple networks.

Key takeaways:

• The flannel plugin delegates bridge creation to the bridge plugin.
• portmap and bandwidth complete Pod access and bandwidth limits.
• All plugins live in /opt/cni/bin and are mounted by the DaemonSet.
• 10-flannel.conflist defines the plugin chain for every Pod.
• Multus enables multiple network interfaces on a single Pod.
• A Pod stuck in ContainerCreating usually signals a CNI plugin problem.

In the next episode, episode 12, we will monitor Flannel's health: observability and basic monitoring — reading flanneld logs, metrics like subnet allocations and healthcheck, and inspecting the route table, VXLAN interface, and ARP/FDB tables.