OpenRetriever Gap Analysis¶
| Project: | OpenRetriever, https://wiki.opnfv.org/display/openretriever |
|---|---|
| Editors: | Xuan Jia (China Mobile) |
| Authors: | Xuan Jia (China Mobile) |
| Abstract: | This document provides the users with top-down gap analysis regarding OpenRetriever feature requirements with OPNFV Installer, OpenStack Official Release and Kubernetes Official Release. |
OpenRetriever architecture options¶
1 Architecture options to support only containers on bare metal¶
To support containers on bare metal without the support of VM-s only a single VIM is needed. This architecture option is targeted by OpenRetriever in OPNFV Euphrates, and this architecture option is considered in the gap analyzis against OpenStack and Kubernetes. Examples: Kubernetes, OpenStack with Zun and Kuryr, which as a side effect also supports VM-s.
2 Architecture options to support containers and VM-s¶
There are different architecture options to support container based and VM based VNF-s in OPNFV. This section provides a list of these options with a brief description and examples. In the descriptions providing the same API means, that the same set of API-s are used (like the OpenStack API-s or the Kubernetes API), integrted networks mean, that the network connections of the workloads can be connected without leaving the domain of the VIM and shared hardware resources mean that it is possible to start a workload VM and a workload container on the same physical host.
2.1 Separate VIM-s¶
There is a separate VIM for VM-s and a separate for containers, they use different hardware pools, they provide different API-s and their networks are not integrated. Examples: A separate OpenStack instance for the VM-s and a separate Kubernetes instance for the containers.
2.2 Single VIM¶
One VIM supports both VM-s and containers using the same hardware pool, with the same API and with integrated networking solution. Examples: OpenStack with Zun and Kuryr or Kubernetes with Kubevirt, Virtlet or similar.
2.3 Combined VIM-s¶
There are two VIM-s from API perspective, but usually the VIM-s share hardware pools on some level. This option have suboptions.
2.3.1 Container VIM on VM VIM¶
A container VIM is deployed on top of resources managed by a VM VIM, they share the same hardware pool, but they have separate domains in the pool, they provide separate API-s and there are possibilities to integrate their networks. Example: A Kubernetes is deployed into VM-s or bare metal hosts into an OpenStack deployment optionally with Magnum. Kuryr integrates the networks on some level.
2.3.2 VM VIM on Container VIM¶
A VM VIM is deployed on top of resources managed by a container VIM, they do not share the same hardware pool, provide different API and do not have integrated networks. Example: Kolla Kubernetes or OpenStack Helm.
OpenRetriever Gap Analysis with OPNFV Installer¶
This section provides users with OpenRetriever gap analysis regarding feature requirement with OPNFV Installer in Danube Official Release. The following table lists the use cases / feature requirements of container integrated functionality, and its gap analysis with OPNFV Installer in Danube Official Release. OPNFV installer should support them.
| Use Case / Requirement | Supported in Danube | Notes |
|---|---|---|
| Use Openstack Magnum to install container environment | No | Magnum is supported in Openstack Official Release, but it’s not supported in OPNFV Installer. Magnum is the place where container can be installed in OPNFV. |
| Use Openstack Ironic to supervise bare metal machine | No | Container could be installed in bare metal machine. Ironic provides bare metal machine, work with Magnum together to setup a container environment, be installed in OPNFV. |
| Use Openstack Kuryr to provide network for container | No | Container has its own network solution. Container needs to connect with virtual machines, and Kuryr which use Neutron provides network service is the best choice now. |
OpenRetriever Gap Analysis with OpenStack¶
This section provides a gap analyzis between the targets of OpenRetriever for release Euphrates (E) or later and the features provided by OpenStack in release Ocata. As the OPNFV and OpenStack releases tend to change over time this analyzis is planned to be countinously updated. During the analyzis all OpenStack projects considered.
(Editors note: Maybe we should define a scope of OpenStack projects which is considered. All OpenStack projects can mean anything.)
The following table lists the use cases / feature requirements of container integrated functionality, and its gap analysis with OpenStack.
| Use Case / Requirement | Related OpenStack project | Notes | Status |
|---|---|---|---|
| Manage container and virtual machine lifecycle with the same NB API | Zun or nova-docker driver | Magnum can deploy a Container Orchestration Engine (COE), but does not provide any lifecycle management operations to the containers deployed in the COE. Zun provides lifecycle management support for the containers deployed in the COE via Nova API, but not all COE API operations are supported. nova-docker driver provided support for container lifecycle management without a COE (and Magnum), but it was deprecated due to lack of community support. A fork of the original nova-docker driver is maintained by the Zun team to provide support for the sandbox containers. Note: Support for this is not targeted in OPNFV release E. | Open |
| Container private registry to store container images | Swift, Cinder, Glance, Glare | Container images need a storage backed from where the COE can serve the registry. This backend should be accessible and should be supported by the COE. As a workaround it is possible to install a registry backend to a VM , but it is more optimal to use the possible backends already available in OpenStack, like Swift, Cinder, Glance or Glare. | Open |
| Kuryr needs to support MACVLAN and IPVLAN | Kuryr | Using MACVLAN or IPVLAN could provide better network performance. It is planned for Ocata. | Open |
| Kuryr Kubernetes integration is needed | Kuryr | It is done in the frame of OpenRetriever. | Targeted to OPNFV release E /OpenStack Ocata |
| HA support for Kuryr | Kuryr | Targeted to OPNFV release E /OpenStack Ocata | |
| HA support for Zun | Zun | Open |
OpenRetriever Gap Analysis with Kubernetes v1.5¶
This section provides users with OpenRetriever gap analysis regarding feature requirement with Kubernetes Official Release. The following table lists the use cases / feature requirements of container integrated functionality, and its gap analysis with Kubernetes Official Release.
| Use Case / Requirement | Supported in v1.5 | Notes |
|---|---|---|
| Manage conainter and virtual machine in the same platform. | No | There are some ways how Kubernetes could manage VM-s:
|
| Kubernetes support multiple networks. | No | As VNF needs at least three interfaces. Management,control plane, data plane. CNI already supports multiple interfaces in the API definition. |
| Kubernetes support NAT-less connections to a container | No | SIP/SDP and SCTP are not working with NAT-ed networks |
| Kubernetes scheduling support CPU binding，NUMA features | No | The kubernetes schedular don’t support these features |
| DPDK need to support CNI | No | DPDK is the technology to accelerate the data plane. Container need support it, the same with virtual machine. |
| SR-IOV can support CNI (Optional) | No | SR-IOV could let container get high performance |
