Your k3s cluster has been running for a while. Flannel handles the networking. Pods communicate, services resolve correctly, and everything just works. So why would you change it?
Most Container Network Interface (CNI) comparison guides never answer that question. They’re written for someone setting up a brand-new cluster, or for an x86 data center where kernel versions are predictable and hardware resources are plentiful. Neither assumption reflects the reality of most ARM homelabs.
Choosing a CNI affects resource usage, security capabilities, observability, and how much operational complexity you take on. It’s also one of the few Kubernetes infrastructure decisions that’s much easier to make before your cluster is running than after it’s already hosting workloads.
This article compares the three most practical CNI options for a k3s ARM homelab: Flannel, Cilium, and Calico. Rather than treating every feature equally, it focuses on the things that actually matter on ARM hardware: support quality, kernel requirements, resource overhead, networking capabilities, and the real cost of switching.
This is a decision guide, not an installation tutorial. By the end, you’ll know when sticking with Flannel is the right choice, when Calico offers a meaningful upgrade, and when Cilium’s advanced features justify the additional complexity.
The Comparison Criteria
Rather than comparing every feature each CNI offers, this guide focuses on the six factors that matter most when choosing a networking solution for a k3s ARM homelab:
- ARM64 support quality: Official multi-architecture images, active maintenance, and long-term reliability on ARM hardware.
- Kernel version requirements: Especially important for eBPF-based CNIs, where kernel capabilities directly affect compatibility and available features.
- Resource overhead: CPU and memory usage per node, since lightweight clusters have far less headroom than typical server deployments.
- Networking capabilities: Support for NetworkPolicy, encryption, and observability, along with the practical value of those features in a homelab.
- Deployment and operational complexity: How easy each CNI is to deploy, configure, and maintain on k3s.
- Project maturity and community activity: Active development, documentation quality, and the likelihood of receiving timely updates and long-term support.
These criteria provide the framework for the comparison that follows, helping separate features that are genuinely useful from those that simply add complexity.
Flannel: The Baseline
k3s ships Flannel by default for a reason. It’s lightweight, requires virtually no configuration, and focuses on doing one job well: providing reliable pod networking with minimal overhead. For most ARM homelabs, that’s exactly what you want.
Flannel is also actively maintained and publishes official multi-architecture images, including linux/arm64, making it a well-supported choice for ARM-based clusters.
From a resource perspective, Flannel remains the leanest option in this comparison. Benchmarks consistently place its memory and CPU overhead well below both Calico and Cilium, making it an excellent fit for resource-constrained ARM clusters.
Here’s where many comparisons get it wrong: they’ll tell you Flannel doesn’t support NetworkPolicy. That’s true for Flannel itself, but it’s incomplete in the context of k3s.
A default k3s installation bundles an embedded NetworkPolicy controller based on kube-router’s netpol library, allowing standard Kubernetes NetworkPolicy resources to work even when Flannel is the active CNI.
Where Flannel falls short is in more advanced networking capabilities. It doesn’t provide an extended policy model like Calico, built-in flow observability like Cilium’s Hubble, or native pod-level encryption. While its WireGuard-native backend can encrypt traffic between nodes, it isn’t designed as a complete networking and security platform.
For most self-hosted ARM clusters, those limitations simply aren’t a problem. If your workloads don’t require advanced network policies, detailed traffic visibility, or service-to-service encryption, Flannel remains the simplest, lightest, and most practical choice.
If you’re setting up a new cluster, our complete k3s setup guide covers the default Flannel deployment.
Cilium
Cilium takes a fundamentally different approach from Flannel. Instead of relying on traditional Linux networking, it uses an eBPF-based dataplane to deliver advanced networking features, including full Kubernetes NetworkPolicy enforcement, Layer 7 policies, Hubble for flow-level observability, and transparent encryption. It’s the most feature-rich CNI in this comparison.
ARM64 has been a first-class platform for Cilium for several years. Official multi-architecture images and binaries are published with every release, making it a fully supported option for modern ARM-based clusters.
The most important requirement isn’t the hardware. It’s the kernel. Cilium recommends Linux kernel 5.10 or later for full eBPF functionality. Ubuntu 22.04 LTS ships with the 5.15 GA kernel on ARM64, so a standard installation comfortably meets that requirement. If you’re running stock Ubuntu Server on your cluster, kernel compatibility is unlikely to be a concern.
Things become less predictable if you’re using vendor-modified SBC images or heavily customized kernels. Most ARM64 issues reported by the community are related to missing kernel features or custom kernel configurations rather than problems with Cilium itself. Before deploying Cilium, it’s worth confirming that your distribution provides the required eBPF capabilities.
The trade-off for Cilium’s feature set is resource usage. Community benchmarks consistently place it above both Flannel and Calico, with memory overhead varying significantly depending on enabled components such as Hubble and the Layer 7 proxy. On a resource-constrained ARM cluster, those extra services can consume a noticeable amount of RAM.
Choose Cilium if you need advanced network policies, detailed traffic visibility, or built-in encryption between workloads. If your priority is a lightweight cluster that requires minimal tuning and maintenance, Flannel remains the better fit.
Calico
One of the biggest sources of confusion in CNI comparisons is treating Calico as a single networking solution. In reality, it offers two different dataplanes with distinct trade-offs. For most ARM homelabs, the standard dataplane is the one worth considering.
Standard mode (iptables/nftables)
Standard mode is Calico’s default and most widely deployed option. It officially supports ARM64 alongside x86-64, ppc64le, and s390x, making it a well-supported choice for ARM-based clusters.
Unlike Cilium, Calico’s standard dataplane doesn’t rely on eBPF. While current system requirements recommend Linux kernel 5.10 or later, that reflects the list of supported distributions rather than a technical requirement of the dataplane itself. For Ubuntu 22.04 and other modern ARM distributions, kernel compatibility is generally not a concern.
Resource usage is also much closer to Flannel than Cilium. Community benchmarks consistently place Calico’s standard mode among the lighter-weight options, making it a practical choice for resource-constrained clusters.
Where Calico stands out is its policy engine. In addition to standard Kubernetes NetworkPolicy, it provides features such as GlobalNetworkPolicy, policy tiers, and FQDN-based rules. Since k3s already provides basic NetworkPolicy support alongside Flannel, Calico’s real advantage isn’t simply adding policies, it’s offering a far more powerful and flexible policy model.
If advanced network policies are the feature you’re missing, Calico’s standard mode is the most practical upgrade path.
eBPF mode
Calico also includes an eBPF dataplane as an alternative to its standard implementation. Like Cilium, it requires a modern Linux kernel with eBPF support, with current documentation recommending kernel 5.10 or later and newer kernels providing the best experience.
ARM64 is officially supported, but the eBPF dataplane has a much smaller deployment base than Calico’s standard mode. Unless you specifically want eBPF performance characteristics while staying within the Calico ecosystem, the standard dataplane is the better choice for most homelab deployments.
Switching Cost: What Replacing a CNI Actually Involves
Before deciding whether to replace Flannel, it’s important to understand the cost of switching. Unlike many Kubernetes components, changing the Container Network Interface (CNI) on an existing k3s cluster is not a supported in-place upgrade.
According to the k3s maintainers, the CNI should be chosen when the cluster is created. While it’s technically possible to replace Flannel with another CNI, doing so requires disabling Flannel, restarting k3s on every node, and installing the replacement CNI before workloads can run again. The process is disruptive and isn’t considered an officially supported migration path.
If your cluster is already hosting applications, expect downtime and plan the migration carefully. The benefits of switching should outweigh the operational cost, especially if your current setup is working well.
On the other hand, if you’re building a new cluster, there is no switching cost at all. That’s the ideal time to choose the CNI that best matches your long-term requirements, rather than replacing it later.
Decision Matrix
| Criterion | Flannel | Cilium | Calico (Standard) |
| ARM64 support | Official ARM64 support | Official ARM64 support | Official ARM64 support |
| Kernel requirements | No special requirements | Linux kernel 5.10+ recommended | Linux kernel 5.10+ recommended (no eBPF dependency) |
| Resource overhead | Lowest | High | Low, close to Flannel |
| NetworkPolicy | Standard Kubernetes NetworkPolicy (via k3s) | Full Kubernetes and Layer 7 policies | Kubernetes NetworkPolicy plus advanced Calico policies |
| Encryption | Optional WireGuard between nodes | Built-in WireGuard or IPsec encryption | Optional WireGuard between nodes |
| Observability | None built in | Hubble observability | Flow logs and metrics |
| Setup complexity | None (default in k3s) | Moderate | Moderate |
| Community activity | Mature and actively maintained | Mature and actively maintained | Mature and actively maintained |
| Pick this if… | CNI |
| You want the simplest, lightest, and lowest-maintenance networking for a typical k3s homelab | Flannel |
| You need advanced network policies without the complexity of an eBPF-based dataplane | Calico (Standard) |
| You need deep network observability, Layer 7 policies, or built-in workload encryption and your kernel meets the requirements | Cilium |
Should You Switch From Flannel?
For most k3s ARM homelabs, probably not. If your cluster is stable, your workloads can already communicate, and standard Kubernetes NetworkPolicy is enough for your needs, Flannel remains an excellent choice. It’s lightweight, actively maintained, and continues to deliver the best balance of simplicity and performance for most self-hosted deployments.
If you need more advanced network policies, Calico’s standard dataplane is the most practical upgrade. It provides a much richer policy model without introducing the additional complexity and kernel dependencies that come with an eBPF-based dataplane.
If detailed network observability, Layer 7 policies, or built-in workload encryption are requirements, Cilium is the strongest option. Just make sure your kernel meets the recommended requirements before making the switch.
Finally, consider when you’re making the decision. If your cluster is already running workloads, the operational cost of replacing the CNI may outweigh the benefits of new features. If you’re building a new cluster, however, there’s no migration cost, making it the ideal time to choose the CNI that best fits your long-term needs.
Related Articles
- K3s on Turing Pi 2.5: Persistent Storage and Load Balancing on ARM: Learn how to add persistent storage, load balancing, and production-ready networking to your k3s cluster.
- Ansible on Turing Pi 2.5: ARM Cluster Automation: Automate cluster provisioning, application deployments, and ongoing maintenance across multiple ARM nodes.
- ARM Compute Module Buyer’s Guide 2026: Compare today’s leading ARM compute modules to choose the right hardware for your next homelab or edge computing project.
- Expose Self-Hosted Services with Cloudflare Tunnel on ARM64: Securely publish services running on your k3s cluster without opening inbound ports or managing a reverse proxy.
FAQ
What CNI does k3s use by default?
k3s uses Flannel as its default Container Network Interface (CNI), with the VXLAN backend enabled unless you configure another option. It also includes an embedded NetworkPolicy controller based on kube-router, allowing standard Kubernetes NetworkPolicy resources to work out of the box.
Does Cilium work on ARM64?
Yes. Cilium fully supports ARM64 and publishes official multi-architecture images with every release. The primary requirement isn’t the hardware but the kernel, with Linux 5.10 or later recommended for full eBPF functionality.
What is the difference between Flannel and Calico?
Flannel focuses on lightweight pod networking with minimal resource usage, while Calico adds a powerful policy engine and advanced networking capabilities. If you need features such as GlobalNetworkPolicy, policy tiers, or FQDN-based rules, Calico is the more capable option.
Does Flannel support NetworkPolicy on k3s?
Not by itself. However, a default k3s installation includes an embedded NetworkPolicy controller based on kube-router, allowing standard Kubernetes NetworkPolicy resources to work alongside Flannel. On Kubernetes distributions without that controller, Flannel alone doesn’t enforce NetworkPolicy.
How do I replace Flannel with Cilium or Calico on a running k3s cluster?
Replacing the CNI on an existing k3s cluster is disruptive and isn’t considered an officially supported in-place migration. It requires disabling Flannel, restarting k3s on every node, and installing the replacement CNI before workloads can run again. Refer to the official k3s networking documentation before attempting the migration.
Which CNI has the lowest resource overhead on ARM?
Flannel has the smallest resource footprint of the three, making it the best choice for lightweight ARM clusters. Calico’s standard dataplane comes next, while Cilium typically uses the most CPU and memory because of its advanced networking and observability features.
Do I need to change my CNI if I’m just running a homelab?
Probably not. If your cluster is stable and you’re not missing features such as advanced network policies, workload encryption, or deep traffic observability, Flannel remains an excellent choice. Most homelab users won’t see enough benefit from switching to justify the additional complexity.