...
- 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.:
| |
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 |
...
| View file | ||||
|---|---|---|---|---|
|
Meetings
Minutes
...