Contact: Frank Zdarsky
Overview
...
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:
- Implement
- They implement the Kubernetes community’s Cluster
- community’s Machine API, allowing
- 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 |
...