Learn Flannel - Latest Stable Features (v0.28.x)

#Introduction

Technology that stops evolving gets left behind. Flannel proves the opposite: past a decade old, it still releases regularly with improvements that preserve its simplicity while following new standards.

Episode 20 covers Flannel v0.28.x: backend refinements, the iptables and nftables traffic managers, build security, and an in-depth look at CVE-2026-32241, a reminder of how important patch upgrades are.

#What's New in v0.28.x

#Backend Refinements

The v0.28.x releases smooth out the backends you already know. The fixes focus on reliability: more stable lease synchronization, better handling of edge cases when nodes join and leave, and fixes on the route path in the VXLAN and host-gw backends. No big breaking changes, in line with Flannel's philosophy.

#The iptables and nftables Traffic Managers

One of the most significant advances is the introduction of an nftables-based traffic manager as an alternative to iptables. As discussed in episode 7, the TrafficManager value in net-conf.json determines which engine is used:

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

With nftables, Flannel follows the evolution of Linux netfilter. The default value and migration behavior can be found in each release's documentation.

#Build Security

The latest releases also pay attention to the build chain: images are built on patched bases, dependencies are updated, and the build process is validated to reduce the attack surface. These changes are invisible in the cluster but matter for long-term health.

#CVE-2026-32241

#Command Injection in the Extension Backend

CVE-2026-32241 is a command injection vulnerability found in Flannel's extension backend. It allows unvalidated arguments from the configuration to be executed as commands by the flanneld process. The impact can be severe: code execution on any node running flanneld.

kubectl get ds -n kube-flannel kube-flannel-ds -o jsonpath='{.spec.template.spec.containers[0].image}'

The output of kubectl get ds -n kube-flannel kube-flannel-ds shows the image your cluster is using. Compare its tag with the patched versions.

#The Importance of Patch Upgrades

The right response to a CVE is not panic but discipline: upgrade to a patched version right away, and temporarily avoid using the extension backend. The DaemonSet upgrade can be done safely because flanneld performs a rolling update:

kubectl set image ds/kube-flannel-ds -n kube-flannel kube-flannel=docker.io/flannel/flannel:v0.28.8
kubectl rollout status ds/kube-flannel-ds -n kube-flannel

The kubectl rollout status command above makes sure all nodes finish the upgrade before it is considered complete.

#Checking and Upgrading

#A Version-Verification Routine

Make version checks a routine: verify the image in the DaemonSet, compare it with the latest release, and note the relevant changes. Release information is available on Flannel's GitHub releases page.

kubectl -n kube-flannel get pods -l k8s-app=flannel -o custom-columns=NODE:.spec.nodeName,IMAGE:.spec.containers[0].image

The output above shows the image running on each node. All nodes must use the same version; otherwise, some node is being left behind.

#A Calm Upgrade Strategy

Always test upgrades in staging first, as discussed in episode 18. After staging is verified, only then move to production. With GitOps, the whole process is recorded and can be rolled back at any time.

#Following Release Progress

#Flannel's Release Rhythm

Flannel releases regularly with meaningful version numbers: minor fixes in the third digit, features and fixes in the second. Understanding this rhythm helps teams plan when to upgrade and how much risk each release carries.

kubectl -n kube-flannel get ds kube-flannel-ds -o yaml | grep image:

The output of kubectl -n kube-flannel get ds shows the image in use. Compare it with the latest release announced on the releases page.

#Reading the Release Notes

Before upgrading, read the release notes: what was fixed, what changed, and whether migration steps are required. This reading habit prevents surprises during upgrades, especially for changes to backends or configuration.

#Building an Upgrade Calendar

Set a realistic upgrade schedule — for example, applying the latest patch release within two weeks after a stable release is verified. This calendar keeps the cluster safe from vulnerabilities like CVE-2026-32241 without sacrificing stability.

#Conclusion

Episode 20 closed the chapter on the latest releases: backend refinements and the nftables traffic manager in v0.28.x, better build security, and upgrade discipline as the answer to CVE-2026-32241.

Key takeaways:

• v0.28.x smooths out the backends with a focus on reliability and lease synchronization.
• The nftables TrafficManager is a modern alternative to iptables.
• Build security is strengthened through patched base images.
• CVE-2026-32241 is a command injection in the extension backend.
• Upgrade to a patched version and avoid the extension until it is validated.
• Verify the image version across all nodes routinely.

In the next episode, episode 21, we will assemble every lesson: production-ready architecture — choosing a backend, tuning the MTU, pairing a policy engine, an upgrade strategy, a GitOps pipeline, observability, node sizing, and an incident runbook for running Flannel in production.