[KNI]

[K8s Network Interface]

M. Zappa [Michael.Zappa@Microsoft.com]

SIG-Network Chair, CNI/containerd Maintainer

[K]ubernetes [N]etworking re[I]MAGINED

Agenda

• What
• Current Architecture
• KNI Architecture
• Network Runtime/API
• Flow
• Ecosystem
• Benefits
• Demo
• Links
• Questions

What

​

• Foundational gRPC Network API specific for Kubernetes
• Revisit past decisions for location of pod network setup/teardown
• CNI is orchestrator agnostic and k8s doesn’t know about CNI, k8s doesn’t know about CNI
• Only IP Addresses are used from CNI result
• CNI 2.0 has been talked about to be closer to k8s
• Approaching 8 years old
• Need for better integration with cloud, network hardware, …
• Networking is Pod level not Container level
• Standardize common practices
• Requiring “eth0”
• Running as a daemon
• Pod to Pod
• Tim mentioned ‘KNI’ back in Sept 2016 (here) :-P
• Ability to pass all information to the network runtime to prevent the ‘round trip’ issue
• ‘Round trip’ is where the CNI plugin/daemon reaches out to the apiserver
• Consolidates networking to a single location vs scattered through the entire CNCF ecosystem

​

Current Architecture

KNI Architecture

Embedded

Standalone

Network Runtime/API

• gRPC Interface
• Daemon
• Embedded in container runtime
• Independent process
• Kubelet = KNI Client
• Network Runtime = KNI Server
• Simple or Advanced as required

Possible high level architecture

Benefits

• Full control of k8s networking
• Backwards compatible with CNI
• Reduced layers of involvement for networking
• No need for container/oci runtime to do networking
• Uniform approach to virtualized/non-virtualized runtimes (runc vs kata)
• Pluggable network model
• Integrated with cloud/On-premise networks
• Status
• Availability
• Extensible and flexible networking (increases innovation)
• Eliminate NAT
• ECMP Anycast Routing
• Integration with BGP or TOR
• Multiple networks
• Virtual Routers
• Decouples pod and node network setup

• Ability to verify and update networks
• Reduces changes to Core Kubernetes
• KNI itself is a low impact/risk change
• Fits nicely in with Gateway API/NetPol/5G/DRA/Multi-Network
• Clear roles and responsibilities
• Separates networking from container runtime
• Loading configuration is implementation detail
• No more exec’ing plugin (if desired, also an implementation detail)
• Whatever language you prefer! Rust, Go, …

Flow

Ecosystem

KNI not just an interface, it’s an ecosystem

Many opportunities when you have a K8s Network API

CRD’s

Demo

Standalone MVP

1. Pod Attach
2. Pod Detach
3. Query Pod Network
4. Query Node Networks

Embedded MVP

• Coming soon!
• containerd with KNI server

• Using kind
• Script will Replace
• kubelet
• KNI client
• containerd
• CNI Disabled
• Script will Add
• KNI Server aka Network Runtime
• Implementation: CNI

Links

Proposal:

Network Runtime/KNI [DRAFT] - Google Docs

Code:

1. MikeZappa87/kubernetes at poc/kni (github.com)
2. https://github.com/MikeZappa87/kni-network-runtime
3. https://github.com/MikeZappa87/kni-api
4. MikeZappa87/containerd at feature/KNI-v2 (github.com)
5. MikeZappa87/kni-demo (github.com)
6. MikeZappa87/cri-o at feature/knipoc (github.com) [WIP - Don’t use or just finish it for me. 95% done]

Summary

• KNI is a gRPC interface
• Flexible/Makes k8s networking completely pluggable/customizable
• The container runtime is not involved with k8s networking
• The CRI/KNI grpc requests are synchronous and not parallelized
• kubelet=KNI client
• Network runtime=KNI server
• Simple or as advanced as needed
• Running daemon
• Reduces changes to Core k8s

Questions?

This was fun. :-)

Special Thanks

1. Pete White
2. Doug Smith
3. Antonio Ojea
4. Dan Winship
5. Tim Hockin
6. Tomofumi Hayashi
7. Shane Utt
8. Philip Klatte
9. Dan Finneran
10. Henry Wang
11. Lionel Jouin