Versions Compared

Key

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

...

This will eliminate the need of having multiple VM based Kubernetes clusters for different tenants or the need to assign different compute nodes for each tenant, which should improve the resource utilization of the environment.


Case Attributes 

Description 

Informational 

Type 

New  

  

Blueprint Family - Proposed   Name 

ICN 

  

Use Case 

uCPE Edge Computing

  

Blueprint proposed Name 

Multi-Tenant Secure Cloud Native Platform 

  

Initial POD Cost (capex) 

Same as ICN, no additional cost. 

  

Scale & Type 

Same as ICN. Minimum of 4 Xeon Servers + 1 Xeon server as bootstrap node.

  

Applications 

Telco trusted workloads and customer untrusted workloads.  

E.g. SDEWAN, EDGX Foundry

  

Power Restrictions 

Same as ICN. 

  

Infrastructure orchestration 

Bare Metal Provisioning

Kubernetes provisioning :  KuD.

Centralized provisioning :  Cluster-API + Provisioning controller (Explore Regional controller)

Containerd for runc and Kata containers.

Virtlet for VMs​.

Service Orchestration : EMCO

MEC framework: OpenNESS

Site orchestrator :  Kubernetes upstream 

Traffic Orchestration within a cluster: ISTIO

Traffic orchestration with external entities : ISTIO-ingress

Knative for function orchestration

  

SDN 

OVN, Multus, Flannel 

  

Workload Type 

Containers, VMs and functions.

Manageability of Bare-metal containers for trusted workloads and Kata Containers (VM based) for untrusted workloads. 

  

Additional Details 

Kata Containers should be deployable across existing Kubernetes clusters using containerd/cri. 

Kubernetes RuntimeClass (from k8s v1.14) and PodOverhead (from k8s v1.16) are features that allow Kata Containers to be selected, managed and monitored with existing Kubernetes tools. 

Kata Containers will not work when used with docker-shim runtime interface. 

 



View file
nameAkraino ICN Multitenant Secure Cloud Native Platform.pptx
height250