Towards CNI v2.0
summary
CNI 1.0 released and maintainers identify five concrete problems: the exec‑per‑RPC binary model creates security and packaging pain, there is no network status API, configs as files are awkward at scale, hardware/device support is under‑specified, and shared resource lifecycle (bridges) is unsafe. Proposed fixes include network and container lifecycle verbs (init/check/destroy), offering gRPC demons with exec fallback implemented in libcni, and a plan to manage networks via CRI so kubelet can reconcile declarative cluster network config and enable multiple interfaces.
AI-written summary · about
chapters (20)
- 0:00Introduction
- 1:37CNI overview
- 5:55Binary execution
- 8:02Network status
- 8:40Configuration management
- 10:24Devices and hardware
- 11:51Setup and tear down
- 13:45CNI is not Kubernetes
- 14:17Demons
- 14:54Second System Effect
- 15:51CNI 20 Success
- 16:50Life Cycle Improvements
- 17:40Network Life Cycle
- 18:30Container Lifecycle
- 20:08Demonization
- 22:11Kubernetes
- 24:06Network Configuration Management
- 24:49Network Configuration in Kubernetes
- 25:48Community effort
- 26:03Outro
related talks
33mOverview of CNI 1.0.0 and preview of CNI 2.0
37mIntroduction to CNI, the Container Network Interface Project
31mMayday! CNI Overboard!
39mDeep Dive: CNI
35mCNI Intro
37mKubernetes and the CNI: Where We Are and What's Next - Casey Callendrello, CoreOS
32mDemystifying CNI Writing a CNI from Scratch
31mEverything You Ever Wanted to Know About CNIs (Container Network Interface) and ...