Learn Flannel - Multi-cluster & Advanced Topology

#Introduction

You've mastered a single Flannel cluster. Now a natural question arises: what about more than one cluster? What about more complicated network topologies? This episode answers them.

We will discuss the cross-cluster overlay and its limitations, combining nodes with different backends, and advanced topologies such as IPv6 dual-stack and restricting subnet allocation.

#Building a Cross-Cluster Overlay

#What You Can and Cannot Do

Flannel builds a network within a single cluster: leases are managed from a single datastore, and routes are synchronized between nodes in the same cluster. A cross-cluster overlay is not a built-in Flannel feature. To connect Pods across clusters, you must build the bridge yourself, for example with a tool such as Submariner or a routing layer on top.

ip route | grep flannel

The output of ip route | grep flannel only shows subnets within one cluster. Another cluster's subnets will not appear without additional integration effort.

#Common Multi-cluster Patterns

The most common pattern: each cluster uses a different CIDR, and traffic between clusters passes through a gateway or VPN mesh built on top of the host network. Remember the lesson from episode 15: two clusters using the same CIDR cannot be connected without route conflicts.

#Mixed Backends

#A Limited Combination

Flannel defines one backend for the whole cluster. Ideally all nodes use the same backend because every node reads the same kube-flannel-cfg ConfigMap. Combining nodes with different backends — say some VXLAN and some host-gw — is not reasonably supported and will produce inconsistent routes.

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

The kubectl -n kube-flannel get pods command shows the flanneld Pod on every node. Because they all read the same configuration, the backend in use is identical across all nodes.

#When to Consider Mixed Backends

The only approach that comes close to a mixed backend is DirectRouting: nodes on the same subnet use a direct route, the rest use VXLAN. That is not a true mixed backend, but it delivers a similar effect with official support.

#Advanced Topologies

#IPv6 and Dual-stack

Modern Kubernetes supports dual-stack, and Flannel can run with IPv6. net-conf.json needs to define an IPv6 network alongside the IPv4 network:

net-conf.json: |
  {
    "Network": "10.244.0.0/16",
    "EnableIPv6": true,
    "IPv6Network": "fd00::/48",
    "Backend": {
      "Type": "vxlan"
    }
  }

With EnableIPv6: true and IPv6Network filled in, flanneld manages two networks at once. Understand that IPv6 support adds a synchronization layer that must be monitored.

#Restricting Subnet Allocation

Sometimes you want to limit how many nodes can join, or steer the subnet allocation. The SubnetMin and SubnetMax fields limit the range of subnets that can be allocated:

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

The configuration above restricts allocation to the 10.244.0.0 subnet only, useful for setups that need tight control over the address space.

#Verifying Advanced Topologies

#Checking the IPv6 Routes

To make sure dual-stack is running, check the IPv6 routes on a node:

ip -6 route | grep flannel

The output of ip -6 route | grep flannel shows IPv6 routes between nodes if dual-stack is active. If it is empty even though IPv6 is configured, there is a synchronization problem to track down.

#Documentation as the Key

Advanced topologies are hard to understand without documentation. Record each cluster's CIDR, the backend in use, and the IPv6 configuration in your infrastructure repository. This will save a lot of time when troubleshooting later.

#Conclusion

Episode 17 expanded Flannel's horizons: understanding that a cross-cluster overlay is not a built-in feature, that mixed backends are not officially supported, and that advanced topologies such as dual-stack and subnet restrictions are possible through net-conf.json.

Key takeaways:

• A cross-cluster overlay is not a built-in Flannel feature.
• Each cluster must use a unique CIDR to be integrable.
• Mixed backends are not supported; all nodes use the same backend.
• DirectRouting is the official approach that resembles a mixed backend.
• IPv6 dual-stack is enabled through EnableIPv6 and IPv6Network.
• SubnetMin and SubnetMax control the range of allocated subnets.

In the next episode, episode 18, we will manage Flannel as code: GitOps and deployment as code — managing manifests and Helm values through Argo CD or Flux, applying versioning and a review flow, and a safe, staged deployment strategy.