Research question: Are there Kubernetes-native projects analogous to Ze (a Linux-host-level Network OS with native BGP) that "turn a cluster into a network device" using operators and CRDs?
Short answer: Yes, but exact analogs are rare. Most projects use Kubernetes as a deployment platform for network functions rather than making the cluster itself a network device.
- CRD → operator → FRR daemon per-node. Kubernetes is the sole config interface.
- Key CRD:
FRRConfiguration(BGP peers, VRFs, routes),BGPSessionState(status) - BGP impl: delegates to FRR (C, production-grade)
- Maturity: experimental; integrated into OpenShift 4.16+
- Ze parallel: Ze owns its BGP impl; FRR-K8s wraps an external daemon via CRDs
- GoBGP embedded in agent; CRDs map directly to BGP speaker config
- Key CRDs:
CiliumBGPClusterConfig,CiliumBGPPeerConfig,CiliumBGPAdvertisement,CiliumLoadBalancerIPPool - BGP impl: GoBGP (pure Go, embedded — architecturally closest to Ze's own-impl model)
- Maturity: production, widely deployed (Cilium 1.15+)
- Ze parallel: both own the BGP implementation in Go; Cilium's "config" is CRDs, Ze's is YANG
| Project | CRDs | BGP impl | Notes |
|---|---|---|---|
| MetalLB | BGPPeer, BGPAdvertisement |
FRR or native | LB-focused; FRR-K8s is its decoupled extraction |
| Calico | BGPConfiguration, BGPPeer |
BIRD (delegates) | Full-featured but CNI-primary |
| kube-router | Annotations (not CRDs) | GoBGP | Simpler; some deprecation signals |
- Ligato — Go framework for Cloud-Native Network Functions with a plugin architecture (closest to Ze's plugin model), but functions are workloads, not the cluster itself
- Network Service Mesh (CNCF sandbox) — L2/L3 service chaining via CRDs
- F5 BIG-IP Next — carrier-grade VNFs as K8s workloads
These are not Kubernetes-native, but represent the class of system Ze belongs to — Linux-based network OSes that manage routing, switching, and network services at the host or appliance level.
- Debian-derived open-source network OS; community fork of Vyatta (Brocade → AT&T)
- BGP impl: FRR (inheriting from Quagga lineage); config via hierarchical CLI + commit model
- Config model: structured "config tree" saved as plain text; migratable across versions via migration scripts — analogous to Ze's YANG tree but without formal schema enforcement
- Kubernetes relevance: primarily deployed alongside clusters as a router/gateway, not inside them; no native CRD/operator interface — configuration is SSH + CLI or Ansible/Terraform
- Commercial tier: VyOS LTS releases sold by Sentrium; community rolling release is free
- Ze parallel: closest peer in the "Linux-as-router" space; Ze's YANG model and plugin system are more rigorous; VyOS's commit/rollback model is a production analog to Ze's reactor pattern
| Dimension | Ze | Cilium BGP CP | VyOS |
|---|---|---|---|
| Config model | YANG files → tree → reactor | Kubernetes CRDs → operator | Hierarchical CLI → config tree |
| BGP impl | Own (Go) | GoBGP (embedded) | FRR (C, via Quagga lineage) |
| CLI | SSH-accessible network OS CLI | kubectl | SSH VyOS CLI (Vyatta-style) |
| Plugin system | init() registration, JSON events |
Cilium agent plugins | None (feature branches/PRs) |
| Target | Standalone network device / router | Kubernetes cluster BGP speaker | Appliance / VM router/gateway |
| Wire model | Buffer-first, zero-copy, pool dedup | GoBGP internal | FRR internal |
| K8s integration | Native | Native (is the CNI) | External (adjacency, not embedded) |
No single established term. In use:
- "BGP Control Plane on Kubernetes" — what Cilium and FRR-K8s call themselves
- "CNF (Cloud-Native Network Function)" — CNCF-standardized for network functions as workloads
- "Network-as-Code on Kubernetes" — conceptual, not official
CNCF has a CNF Certification Program (beta 2025) for validating cloud-native network functions.