Kubernetes-Native Infrastructure (KNI) Blueprint Family

Owned by Frank Zdarsky
Last updated: Sept 10, 2022 by xinhui li
2 min read

Overview

Blueprints in the Kubernetes-Native Infrastructure Blueprint Family leverage the best-practices and tools from the Kubernetes community to declaratively manage edge computing stacks at scale and with a consistent, uniform user experience from the infrastructure up to the services and from developer environments to production environments on bare metal or on public cloud.

All blueprints in this family share the following characteristics:

  • 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.

Family Template

Attributes

Description

Informational

Type

New


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)


Scale

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


Applications

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 operator
Container Platform: Kubernetes (OKD)
Container Runtime: CRI-O w/compatible backends
VM Runtime: KubeVirt
OS: CentOS, CentOS-rt, or CoreOS


Additional Details



Blueprints in this Family

Points of contact

Documents

Proposal Presentation