Contact: Frank Zdarsky
The KNI-Edge Family unites edge computing blueprints sharing the following characteristics:
Implement the Kubernetes community’s Cluster 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.
Attributes | Description | Informational |
|---|---|---|
Type | New |
|
Blueprint Family - Proposed Name | Kubernetes-Native Infrastructure for Edge (KNI-Edge) |
|
Use Case(s) | various, e.g.:
|
|
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:
|
|
Power Restrictions | (depends on blueprint) |
|
Preferred Infrastructure Orchestration | End-to-end Service Orchestration: depends on use csae; e.g. ONAP |
|
Additional Details |
Minutes