Mainstream Container SDN Technologies and Microservice Practice Analysis

About SDN and Containers

SDN (Software Defined Networking) abstracts network deployment and scaling through software, allowing flexible control of network resources. The article introduces SDN’s relationship with containers and sets the stage for analyzing three open‑source SDN solutions.

Open‑source SDN Solutions Around Containers

Docker’s native networking relies on a simple Linux bridge and iptables NAT, which causes IP changes, complex routing, and performance overhead when containers are migrated.

Flannel is a CoreOS‑designed overlay network for Kubernetes. Its control plane watches etcd for IP allocations, while the data plane creates a VXLAN device on each host to encapsulate L2 packets for transport across the physical network.

Calico treats each host’s protocol stack as a router and connects containers as endpoints, using BGP to distribute routing information. It operates purely at L3, providing high performance and isolation but requiring a flat L2 underlay and potentially stressing BGP tables at large scale.

Weave combines aspects of Flannel and Calico: it runs a custom router on each host, builds a fully‑meshed control plane, and uses a VXLAN‑based overlay for data forwarding. It also provides built‑in DNS for service discovery, though its isolation is limited to subnet‑level.

Summary of the Three Solutions

Flannel works well for single‑tenant container inter‑connectivity but needs additional components for service discovery and load balancing.

Calico offers strong performance and isolation but may be intrusive to the physical network and adds BGP overhead.

Weave includes DNS‑based service discovery and combines overlay tunneling with routing, yet its isolation is coarse.

Qiniu's Specific Practice

Business Requirements – support heterogeneous underlying networks, enable container migration, provide built‑in service discovery and load balancing, and offer flexible isolation.

Forwarding Plane – uses Open vSwitch (OVS) with VXLAN tunnels as an L2 overlay, offloading VXLAN processing to NIC hardware to achieve near‑full bandwidth utilization.

Control Plane – adopts OpenFlow for centralized flow rule management. OVS forwards unknown packets to a controller, which installs appropriate flow entries; multiple controllers provide high availability.

Service Discovery and Load Balancing – defines Container, Pod, Service, and Security Group objects. Service IPs map to backend Pods, enabling IP‑level load balancing without extra traffic overhead. The implementation proxies Service traffic locally on each host.

Security Groups – logical groups of Services with flexible access control; services can be exported between groups while restricting other interactions.

Case Study 1 – Qiniu File Processing (FOP) Architecture Evolution

The original architecture tightly coupled entry points with worker clusters, leading to static configuration, mixed control and data traffic, and poor scalability. Introducing a Discovery component, decoupling entry from workers, and adding Agents for heartbeat and caching improved flexibility and load distribution.

After migrating to the container platform, Agents became lightweight services, Discovery was replaced by the platform’s built‑in service discovery, and workload scaling became automatic.

Case Study 2 – User‑Defined File Processing (UFOP) Architecture Evolution

UFOP initially used Docker containers with strict network isolation, allowing only inbound traffic from the entry point. Post‑migration, flexible security groups provided per‑user isolation, and users could define multiple Services with full port space, enhancing functionality and scalability.