Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.


  • They implement the Kubernetes community’s Machine API, allowing users to declaratively configure and consistently deploy and lifecycle manage Kubernetes clusters no matter whether on-prem or on public cloud, on VMs or on bare metal, at the edge or at the core.
  • Leverage the community’s Operator Framework for automated and secure lifecycle management of applications in the edge computing stack. Operators allow applications to be lifecycle managed as Kubernetes resources, in event-driven manner, and fully RBAC-controlled. They may provide more than deployment and upgrade actions for an application, e.g. auto-reblancing/scaling, analytics, and usage metering, and may be created from Helm Charts, using Ansible or Go.
  • Optimize for Kubernetes-native container workloads, but allow mixing in VM-based workloads via KubeVirt as needed.

Image RemovedImage Added

Family Template






Blueprint Family - Proposed Name

Kubernetes-Native Infrastructure for Edge (KNI-Edge)

Use Case(s)

various, e.g.:

  • Provider Access Edge (Far/Near), MEC

  • Industrial Automation

  • Enterprise Edge

  • ...

Blueprint Proposed

various; initially:

Initial POD Cost (CAPEX)

(depends on blueprint)


1 to hundreds of nodes, 1 to thousands of sites.


any type of workloads:

  • containerized or VM-based

  • real-time, ultra-low latency or high-throughput

  • NFV, IoT, AI/ML, Serverless, ...

Power Restrictions

(depends on blueprint)

Preferred Infrastructure Orchestration

End-to-end Service Orchestration: depends on use csae; e.g. ONAP
App Lifecycle Management: Kubernetes Operators
Cluster Lifecycle Management: Kubernetes Cluster API/Controlleroperator
Container Platform: Kubernetes (OKD)
Container Runtime: CRI-O w/compatible backends
VM Runtime: KubeVirt
OS: CentOS, CentOS-rt, or CoreOS

Additional Details