Learn Flannel - Setup & Installation

#Introduction

In episode 2 you understood Flannel's architecture. Now it's time to practice: install Flannel on a real cluster. Flannel installation is famously easy, and this episode will prove it.

Episode 3 guides you through the two official installation paths: the kube-flannel.yml manifest for the direct kubectl approach, and the flannel/flannel Helm chart for a more structured approach. After that we verify the results from three sides: the DaemonSet, the network interface, and connectivity between nodes.

#Installing via the Official Manifest

#Getting to Know kube-flannel.yml

The official kube-flannel.yml manifest contains the ServiceAccount, ConfigMap, and DaemonSet that deploy flanneld to every node. This manifest is a single file and can be applied directly without additional configuration.

kubectl apply -f https://github.com/flannel-io/flannel/releases/latest/download/kube-flannel.yml

The kubectl apply -f kube-flannel.yml command above pulls the latest version directly from the official Flannel release. Make sure your cluster is ready as prepared in episode 0, especially the --pod-network-cidr=10.244.0.0/16 requirement.

#The Correct Installation Order

Installation order matters with kubeadm: Flannel must be installed after kubeadm init but before nodes fully join, or as soon as possible after the control plane is up. On a single-node cluster, remove the control plane taint first so Pods can be scheduled:

kubectl taint nodes --all node-role.kubernetes.io/control-plane-

After that, wait for all kube-flannel Pods to reach the Running state before deploying any workload.

#Installing via the Helm Chart

#Adding the Repository and Installing

For teams that already use Helm to manage their entire stack, Flannel provides an official chart in the flannel repository:

helm repo add flannel https://flannel-io.github.io/flannel/
helm repo update
helm install flannel flannel/flannel --namespace kube-flannel --create-namespace

The helm install flannel flannel/flannel command deploys the same components as the manifest, but with values that can be overridden. This is more convenient for configuration that needs to be adjusted per cluster.

#Common Value Overrides

The most commonly overridden values are the pod CIDR, the image tag, and the backend. For example, to use the host-gw backend:

helm install flannel flannel/flannel \
  --namespace kube-flannel --create-namespace \
  --set net-conf.json.backend.type=host-gw

Hmm, the chart's values structure can differ between versions. The safest way is to inspect the chart values before overriding. What's certain is that the net-conf value will be passed to the same ConfigMap as in the manifest installation.

#Verifying the Installation

#Check the kube-flannel DaemonSet

After installation, verification starts with the DaemonSet:

kubectl get ds -n kube-flannel
kubectl get pods -n kube-flannel -o wide

The kubectl get ds -n kube-flannel command should show kube-flannel-ds with a ready count equal to the number of nodes. Each kube-flannel Pod in the Running state means flanneld is active on that node.

#Check the flannel.1 Interface

The next step is verification at the host level. Go into one of the nodes and make sure the VXLAN interface is created:

ip -d link show flannel.1

If the flannel.1 interface appears with the type vxlan, the default backend is active. You can also check the MTU that was computed automatically from here.

#Check Pod Connectivity Between Nodes

The last and most important verification: make sure Pods on different nodes can reach each other. Deploy a workload with several replicas, then test from one of the Pods:

kubectl create deployment nginx --image=nginx --replicas=2
kubectl get pods -o wide
kubectl exec -it <pod-1> -- curl <ip-pod-2>

If the nginx response is received, the Flannel overlay network works. We will dissect the details of the packet flow inside this overlay in episode 4.

#Adjusting the CIDR in an Existing Cluster

#Modifying the ConfigMap

A cluster that already stands with a different CIDR, for example 192.168.0.0/16, needs its net-conf.json adjusted. Here's how: edit the ConfigMap then restart the DaemonSet:

kubectl -n kube-flannel edit cm kube-flannel-cfg
kubectl rollout restart ds/kube-flannel-ds -n kube-flannel

Change the Network field to the Pod CIDR your cluster uses. The kubectl rollout restart ds/kube-flannel-ds command makes each node take a new lease from the adjusted pool.

#Conclusion

Episode 3 took you from zero to a cluster with live networking: installing Flannel via the manifest or Helm, verifying the DaemonSet and interface, then proving cross-node connectivity.

Key takeaways:

• The kube-flannel.yml manifest is the most direct installation path.
• The flannel/flannel Helm chart gives you value control for a structured setup.
• Verification starts with the DaemonSet, then the flannel.1 interface, then Pod connectivity.
• kube-flannel Pods Running on all nodes mean flanneld is active everywhere.
• A cluster with a different CIDR needs a net-conf.json edit and a DaemonSet restart.
• Change the CIDR before large workloads are deployed to avoid surprises.

In the next episode, episode 4, we will dissect the default VXLAN backend — how UDP encapsulation works on port 4789, the flannel.1 interface and FDB learning, VNI and port configuration, and the limitations of the 50-byte MTU overhead. This is the heart of the Flannel overlay network.