Learn Flannel - Configuration & Environment

#Introduction

Flannel is famous for its simplicity, and that simplicity shows in its configuration: one main JSON file plus a few flags. But "few options" doesn't mean "unimportant". Choosing the wrong interface, MTU, or VNI can make the network perform poorly or fail completely.

Episode 9 dissects every flanneld configuration option: flags and environment, net-conf.json, host interface selection, and MTU and VNI tuning.

#Configuring flanneld

#Flags and Environment

flanneld accepts configuration through command-line flags and the net-conf.json file. In a DaemonSet installation, these flags appear in the container args:

containers:
  - name: kube-flannel
    image: docker.io/flannel/flannel:v0.28.8
    args:
      - --ip-masq
      - --kube-subnet-mgr
    env:
      - name: POD_NAME
        valueFrom:
          fieldRef:
            fieldPath: metadata.name

The --kube-subnet-mgr flag selects the Kubernetes API datastore, and --ip-masq enables masquerade. The POD_NAME variable is needed by flanneld to identify itself when managing leases.

kubectl get ds -n kube-flannel kube-flannel-ds -o yaml | grep -A5 args

The output of kubectl get ds -n kube-flannel kube-flannel-ds shows the flags your cluster is currently using.

#net-conf.json: The Main Source of Decisions

All the major decisions still live in net-conf.json: the network pool, subnet length, and backend. This file is mounted from the ConfigMap and read by flanneld at startup. Changing the ConfigMap then restarting the DaemonSet is the standard way to apply changes.

net-conf.json: |
  {
    "Network": "10.244.0.0/16",
    "SubnetLen": 24,
    "Backend": {
      "Type": "vxlan"
    }
  }

The SubnetLen field determines the per-node subnet size. A value of 24 means /24 per node, suitable for clusters up to 256 nodes.

#Choosing the Right Host Interface

#The Problem of the Wrong Interface

On a node with many interfaces, for example eth0, eth1, and docker0, flanneld can pick the wrong one. If it picks docker0 as the VXLAN path, cross-node traffic fails because docker0 doesn't lead to other host networks. The symptom is classic: Pods on the same node can reach each other, but cross-node traffic never succeeds.

#The Solution: --iface or the Iface Field

To force the interface choice, use the --iface flag or the Iface field in net-conf.json:

net-conf.json: |
  {
    "Network": "10.244.0.0/16",
    "Backend": {
      "Type": "vxlan"
    },
    "Iface": "eth0"
  }

The flanneld --iface eth0 command can also be used as a flag. Choose the interface that actually leads to other host networks, usually the one kubelet uses to communicate.

#Checking the Interface in Use

Verify flanneld's choice from the VXLAN interface that was created:

ip -d link show flannel.1

The local column in the output of ip -d link show flannel.1 shows the host IP flanneld selected as the encapsulation source. Make sure it's the right IP.

#MTU and VNI Tuning

#Setting the MTU

By default flanneld computes the MTU automatically from the host interface minus the backend overhead. For VXLAN, the overhead is 50 bytes. If the host uses jumbo frames, for example MTU 9000, flannel.1 automatically becomes 8950. The MTU field in net-conf.json can force a specific value when your network has restrictions.

net-conf.json: |
  {
    "Network": "10.244.0.0/16",
    "MTU": 1450,
    "Backend": {
      "Type": "vxlan"
    }
  }

Correct MTU calculation will be covered thoroughly in episode 16.

#Choosing the VNI

The VNI distinguishes one VXLAN network from another on the same segment. The default of 1 is almost always sufficient, but if you use another VXLAN on the same host, raise the VNI to avoid a conflict. Make sure the value is consistent across all nodes.

#Enabling IP Masquerade

#When Masquerade Is Needed

Masquerade is needed when Pods must access the internet or services outside the Pod subnet. Without masquerade, outbound packets use a Pod IP that isn't routable, and return traffic gets lost. The --ip-masq flag enables it.

cat /run/flannel/subnet.env | grep FLANNEL_IPMASQ

If FLANNEL_IPMASQ is true from cat /run/flannel/subnet.env, masquerade is running. For a purely internal network with no outbound access needs, masquerade can be turned off to save one layer of processing.

#Conclusion

Episode 9 equipped you with full control over Flannel's configuration: flanneld flags and environment, the contents of net-conf.json, host interface selection via Iface, and MTU and VNI tuning.

Key takeaways:

• --kube-subnet-mgr selects the Kubernetes API datastore; --ip-masq enables masquerade.
• net-conf.json controls Network, SubnetLen, MTU, and Backend.
• The wrong host interface is a classic cause of cross-node failures.
• Use the Iface field or --iface flag to force the interface choice.
• MTU is computed automatically, but can be forced via the MTU field.
• The default VNI is 1; raise it if the host uses another VXLAN.

In the next episode, episode 10, we will scale up: multi-node deployment and scaling — building a three-node kubeadm cluster, verifying routing and the overlay, understanding failure domains, and assessing Flannel's scale limits and when to switch to a more advanced CNI.