Chapter 2
Flannel: Architecture and Design Principles
Step behind the curtain of one of the most pervasive overlay network solutions for Kubernetes. In this chapter, we systematically unravel Flannel's underlying architecture, design philosophies, and implementation nuances. Gain a profound understanding of its modular components, backend strategies, and the orchestration of IP addresses that enable seamless pod connectivity across distributed cloud-native clusters. For architects and engineers intent on making informed, resilient network decisions, Flannel's internal blueprint offers invaluable strategic insights.
2.1 Origins and Purpose of Flannel
The inception of Flannel is closely intertwined with the rapid ascendancy of container orchestration platforms, particularly Kubernetes, which revolutionized deployment and management of distributed applications in cloud environments. As Kubernetes matured, its fundamental architectural requirement for seamless pod-to-pod networking across diversified, often heterogeneous infrastructure surfaced as a primary challenge. The need for a networking solution that could fulfill Kubernetes' high expectations for simplicity, scalability, and performance laid the foundation for Flannel's creation.
Historically, early container networking relied heavily on shared host network namespaces or manual network configurations that limited portability and isolated containerized workloads. Kubernetes, designed to treat each pod as a logically separate unit with its own network identity, necessitated an abstraction layer to facilitate a flat network fabric where pods could communicate transparently regardless of their physical or virtual host location. The problem was more than mere connectivity; it encompassed address management, routing, and encapsulation in a dynamic environment where pods can be created, moved, or destroyed frequently.
At Kubernetes' launch, native network solutions were not yet standardized or widely available, prompting a surge of community-driven projects. Against this backdrop, Flannel emerged as an overlay network initially developed by CoreOS, aiming to provide a straightforward yet reliable mechanism for pod networking. The primary motivation behind Flannel's design was to abstract the complexity of underlying network infrastructure by creating a virtual network that assigns each host a subnet, thereby enabling pods on different hosts to communicate over an encapsulated layer.
Flannel operationalizes this concept through a per-host subnet allocator and the encapsulation of packets using protocols such as VXLAN or UDP. This approach masks disparities in the physical network topology, removing the necessity for native Layer 3 routing configurations on the host network and minimizing the operational overhead. Consequently, Flannel aligns with Kubernetes' principle of a flat, cluster-wide network space where every pod is reachable with a unique IP address, facilitating transparent service discovery and load balancing.
Another critical driver behind Flannel was the need for simplicity and minimalism to accelerate adoption. Unlike complex software-defined networking (SDN) solutions that often entail sophisticated control planes and steep learning curves, Flannel adopted a lightweight control plane architecture with a focus on ease of configuration and stability. It supports multiple backend mechanisms for packet delivery, including VXLAN, host-gw, and AWS VPC routing, offering flexibility to adapt to diverse deployment scenarios, whether on-premises or in the cloud.
As a result, Flannel's evolution has maintained fidelity to the cloud-native networking principles of declarative configuration, interoperability, and resilience. By decoupling the network overlay from Kubernetes' core components, Flannel has successfully facilitated an ecosystem where network plugins can evolve independently yet cohesively support Kubernetes' network model. Moreover, its compatibility with the Container Network Interface (CNI) specification ensures seamless integration and extensibility within the broader container orchestration landscape.
The project's continuous development addressed emerging demands such as improved performance through optimized encapsulation, support for different network backends catering to specific infrastructure requirements, and enhanced observability and debugging capabilities. Flannel's transparent network abstraction also supported multi-cloud and hybrid-cloud deployments, an increasingly vital need as organizations distributed workloads across heterogeneous infrastructure while preserving application portability.
In summary, Flannel originated from the vital need for a practical, scalable solution to Kubernetes' network connectivity challenges. It embodies a strategic blend of simplicity, robustness, and adaptability to realize Kubernetes' vision of a flat pod network. Its design directly addresses dynamic pod lifecycle events and heterogeneous underlying infrastructures, reflecting pragmatic engineering choices within the cloud-native ecosystem. Over time, Flannel has become a foundational network fabric that simplifies container networking complexity and remains integral to tailored Kubernetes deployments worldwide.
2.2 Logical Architecture of Flannel
Flannel operates as a network fabric for containerized environments, providing a virtual overlay network that abstracts the underlying physical network complexities. Its logical architecture is composed of several core components, each entrusted with specific responsibilities to orchestrate seamless communication between hosts in a cluster. The primary elements include the flanneld daemon, the subnet manager, and the backend interface. Together, these components collaborate to establish and maintain a scalable, consistent overlay network.
The flanneld daemon functions as the primary agent running on every host within the cluster. It serves as the orchestrator of local network configuration and a conduit for communication with the distributed key-value store, which acts as Flannel's source of truth. Flanneld's responsibilities encompass acquiring a unique subnet for the host, monitoring configuration changes, and managing the overlay network interface. By interfacing with the key-value store, flanneld ensures decentralized coordination without reliance on a single point of failure.
Central to subnet allocation is the subnet manager, a logical construct embedded within flanneld. Its purpose is to divide the comprehensive cluster-wide network CIDR block into smaller, non-overlapping subnets. Each subnet is assigned to an individual host, enabling autonomous IP address management within that host's domain. The subnet manager safeguards against address conflicts by performing atomic updates in the key-value store and monitors subnet assignment statuses. This mechanism sustains cluster-wide IP uniqueness and avoids routing ambiguities.
The configuration structure in Flannel is hierarchically organized with the key-value store at the apex. It stores crucial network parameters such as the global network range, backend selection, and host subnet mappings. Consistency in configuration is paramount, as all running flanneld daemons periodically synchronize their state from this centralized repository. This design facilitates dynamic reconfiguration and scalability: new nodes retrieve the current cluster state upon initialization, while existing nodes adapt promptly to changes.
At the heart of data plane abstraction lies the backend interface. Flannel supports multiple backend implementations, each translating the overlay networking logic into concrete packet forwarding mechanisms. Examples include VXLAN, host-gw, and UDP backends, among others. The backend interface abstracts initialization, packet encapsulation, route management, and teardown operations. It is responsible for establishing tunnels or routing paths that preserve the illusion of a flat, contiguous subnet space across disparate physical networks. This modularity allows Flannel to adapt to various infrastructural constraints and performance requirements without altering its core control plane logic.
The interaction between these components unfolds as follows: Upon startup, flanneld contacts the key-value store and invokes the subnet manager to request a subnet assignment. Once allocated, flanneld spawns the selected backend, configuring the host's network interfaces according to the backend's specifications. The daemon participates in continuous monitoring of the network configuration stored in the key-value store, propagating updates to the backend interface whenever topology or parameter changes occur.
Internally, communication between flanneld and the backend interface transpires via a well-defined API, which decouples control plane logic from data plane mechanics. This interface comprises methods to program routing tables, establish encapsulation tunnels, and manage peer connectivity to remote hosts. The backend is responsible for local packet processing, including encapsulating container traffic for transmission over the overlay and decapsulating ingress traffic from other nodes. It also manages failure detection and recovery...
