Support Multi-tenant for Kubernetes VIM

https://blueprints.launchpad.net/tacker/+spec/k8s-namespace

Problem description

ETSI NFV-SOL003 VNF Lifecycle Management for CNF on Kubernetes VIM is supported in Wallaby release such as Instantiate [1], Scale [2], and Heal [3], but its operations with specified namespace are not provided. This specification proposes VNF Lifecycle Management operations for CNF with specified namespace. Users should be a ServiceAccount which is bound to ClusterRoles as admin or to Roles as general users.

Proposed Change

The Instantiate operation in ETSI NFV-SOL003 VNF Lifecycle Management 2.6.1 [4] enable Users to specify the target namespace in the InstantiateVnfRequest to deploy CNF on Kubernetes VIM. additionalParams field provides new parameter namespace for the target namespace.

Note

A VNF instance should be in a single namespace. It’s possible to deploy plural Kubernetes resources as a VNF instance, but they should be managed in the same namespace.

The following changes are required in LCM operation for CNF:

  1. CNF Instantiate

    • Add namespace field to InstantiateVnfRequest.

    • Add logic to use specified namespace in Kubernetes InfraDriver.

    • Store specified namespace in Tacker DB.

    Note

    Namespaces are stored in both VnfResource.resource_name and VnfInstance.instantiatedVnfInfo.vnfcResourceInfo.metadata. This spec proposes aggregating them into VnfInstance.metadata for ease of managing namespaces in Tacker DB.

    Note

    The specified namespace should be described in the response of GET /vnf_instances/{vnfInstanceId}/.

  2. CNF Scale

    • Add logic to get stored namespace in VnfInstance table.

    Note

    Need to design how to manage namespace after instantiation. This may not be required.

  3. CNF Heal

    • Add logic to get stored namespace in VnfInstance table.

    Note

    Need to design how to manage namespace after instantiation. This may not be required.

  4. CNF Terminate

    • Add logic to get stored namespace in VnfInstance table.

CNF Instantiate with specified namespace

The diagram of CNF Instantiate with specified namespace is shown below:

                                +----------+
                                |          |
                                |  VNFD    |
                                |          |
                                +-+--------+
                                  |
                                +----------------+  +--------v-+ +------------------+
                                | CNF Definition |  |          | | Instantiation    |
                                | File           +-->   CSAR   | | Request with     |
                                |                |  |          | | additionalParams |
                                +----------------+  +------+---+ +--+---------------+
                                                           |        |
                                                           |        | 1. Request
                                                           |        |    with namespace
+------------------------------+                    +-----------------------------+
| CNF                          |                    |      |        |       VNFM  |
|                              |                    |   +--v--------v----+        |
|  +----------+  +----------+  |                    |   | TackerServer   |        |
|  | Pod      |  | Pod      |  |                    |   +------+---------+        |
|  |          |  |          |  |                    |          |                  |
|  +----------+  +----------+  |                    |   +---------------------+   |
+------------------------------+                    |   |      |              |   |
                                                    |   |  +-v-+----------+   |   |
+------------------------------+                    |   |  | VnflcmDriver |   |   |
| Kubernetes cluster VNF       |                    |   |  |              |   |   |
|                              |                    |   |  +-+-^----------+   |   |
|  +----------+  +----------+  |                    |   |    | | 3. Store     |   |
|  |    VM    |  |    VM    |  | 2. Set namespace   |   |    | |    namespace |   |
|  | +------+ |  | +------+ |  |    in K8s API call |   |  --v-+----------+   |   |
|  | |Worker| |  | |Master+<-------------------------------+ Kubernetes   |   |   |
|  | +------+ |  | +------+ |  |                    |   |  | InfraDriver  |   |   |
|  +----------+  +----------+  |                    |   |  +--------------+   |   |
|                              |                    |   |                     |   |
+------------------------------+                    |   |    Tacker Conductor |   |
                                                    |   |                     |   |
+------------------------------+                    |   +---------------------+   |
| Hardware Resources           |                    |                             |
+------------------------------+                    +-----------------------------+

  1. The specified namespace is sent in InstantiateVnfRequest.

  2. Kubernetes InfraDriver call K8s API with specified namespace.

  3. VnflcmDriver stores the namespace in Database.

Sample input parameters

A new attribute named namespace is added to additionalParams parameter in InstantiateVnfRequest defined in ETSI NFV-SOL003 v2.2.6 [4]. No change is required for the other parameters from existing CNF operation.

Attribute name

Parameter description

namespace

Namespace for Kubernetes API call. If absent, the namespace in the resource file is used.

Following is a sample:

{
  "flavourId": "simple",
  "additionalParams": {
    "lcm-kubernetes-def-files": [
      "Files/kubernetes/pod.yaml"
    ],
    "namespace": "namespaceA"
  },
  "vimConnectionInfo": [
    {
      "id": "8a3adb69-0784-43c7-833e-aab0b6ab4470",
      "vimId": "specified by response of vim list",
      "vimType": "kubernetes"
    }
  ]
}

Sequence of CNF Instantiate with specified namespace

The procedure consists of the following steps as illustrated above.

  1. Client sends instantiate request.

  2. Same as the steps in Wallaby release until the KubernetesInfraDriver is invoked.

  3. The KubernetesInfraDriver call Kubernetes API with specified namespace:

    1. The Kubernetes Client send request with the namespace in InstantiateVnfRequest.additionalParams. If namespace is not provided, one in Kubernetes resource file is used.

    2. KubernetesInfraDriver add the namespace to “vnf_resources” table in TackerDB.

      Note

      The namespace stored in the “vnf_resources” table is used in the Scale, Heal, and Terminate operations for CNF.

Data model impact

As mentioned above, stored namespaces in Tacker DB will be aggregated into VnfInstance.vnf_metadata by this implementation. Those fields will be changed as follows:

  • VnfResource.resource_name

    • This field contains namespace and resource name as comma separated value, but will store only resource name in this specification.

  • VnfInstance.instantiatedVnfInfo.vnfcResourceInfo.metadata

    • This field is not modified in this specification, but will no longer be referred from Tacker.

Note

The metadata field in vnf_instances table is defined as JSON. No change is required, but it’s worth to note that metadata field is implemented as vnf_metadata.

REST API impact

None

Security impact

None

Notifications impact

None

Other end user impact

None

Performance impact

None

Other deployer impact

None

Developer impact

None

Implementation

Assignee(s)

Primary assignee:

Yoshito Ito <yoshito.itou.dr@hco.ntt.co.jp>

Other contributors:

Tatsuhiro Furuya <tatu.furuya@fujitsu.com>

Yoshiyuki Katada <katada.yoshiyuk@fujitsu.com>

Ayumu Ueha <ueha.ayumu@fujitsu.com>

Liang Lu <lu.liang@fujitsu.com>

Work Items

  • Implement to support:

    • Specify the target namespace to deploy CNF on Kubernetes VIM when CNF instantiate.

    • Store specified namespace in Tacker DB when CNF instantiate.

    • Get specified namespace from Tacker DB and Use it when CNF scale and heal.

  • Add new unit and functional tests.

Dependencies

None

Testing

Unit and functional tests will be added to cover cases required in the spec.

Documentation Impact

User guide will be modified to explain to VNF Lifecycle Management operations for CNF with specified namespace.

References