Support CNF Scale in v2 LCM API

https://blueprints.launchpad.net/tacker/+spec/support-nfv-solv3-scale-vnf

This specification enhances version 2 (v2) of Scale API for supporting CNF.

Problem description

Yoga release supported VNF Lifecycle Management (LCM) operations defined in ETSI NFV SOL002 v3.3.1 [1] and SOL003 v3.3.1 [2]. It also supported CNF Lifecycle Management with v2 APIs such as Instantiate API, Terminate API, and ChangeCurrentVnfPackage API.

However, v2 Scale API has not supported CNF yet. Supporting CNF in v2 LCM API makes Tacker more powerful generic VNFM.

Proposed change

This specification enhances the following API to support CNF.

  • Scale VNF (POST /v2/vnf_instances/{vnfInstanceId}/scale)

Definition of CNF scaling

The definition of v2 CNF scaling is the same as the v1 CNF scaling.

In case of using Kubernetes VIM, the VDUs are mapped to ReplicaSet, Deployment, DaemonSet, or StatefulSet, and a VNFC is a Pod. The scale operation changes the number of replicas for the VDU resource and Kubernetes controller automatically creates or deletes Pods.

The following Kubernetes resource kinds support Updating the number of replicas.

  • ReplicaSet

  • Deployment

  • StatefulSet

Note

DaemonSet can be also mapped to VDU but it’s not supported in the scale operation because it doesn’t have the replicas property.

Note

When scale-in, the assigned PersistentVolumeClaim (PVC) and PersistentVolume (PV) are left. Also, when scale-out, users need to provision the required PVC and PV before the operation if the Pod has a spec section for PVC. This prerequisite is the same as the v1 API.

Flow of Scale VNF

There is no change from the current implementation except for InfraDriver (KubernetesDriver) processing.

../../_images/0158.png

The procedure consists of the following steps as illustrated in above sequence:

Precondition: VNF instance in “INSTANTIATED” state.

  1. Client sends VNFM a POST request for the Scale VNF Instance.

  2. VNFM sends endpoints such as Client a VNF lifecycle management operation occurrence notification with the “STARTING” state to indicate the start occurrence of the lifecycle management operation.

  3. VNFM calculates the number of Pods to scale by multiplying “number_of_steps” contained in Scale VNF request and “number_of_instances” contained in VNFD.

  4. VNFM and NFVO exchange granting information.

  5. VNFM sends endpoints such as Client a VNF lifecycle management operation occurrence notification with the “PROCESSING” state to indicate the processing occurrence of the lifecycle management operation.

  6. MgmtDriver executes preamble operation according to a MgmtDriver script.

  7. The total number of Pods is calculated by current resources obtained by VnfInstance.instantiatedVnfInfo.vnfcResourceInfo and scaled Pods obtained by grant.addResources and grant.removeResources.

  8. KubernetesDriver sends Kubernetes a Update request with the incremented or decremented “replicas” for the target VDU.

  9. KubernetesDriver sends Kubernetes a Read request to check the status of resources.

  10. MgmtDriver executes postamble operation according to a MgmtDriver script.

  11. VNFM sends endpoints such as Client a VNF lifecycle management operation occurrence notification with the “COMPLETED” state or “FAILED_TEMP” state to indicate the result of the lifecycle management operation.

Postcondition: VNF instance is still in “INSTANTIATED” state and VNF has been scaled.

Note

V2 Scale-in operation for VNF using OpenStack VIM deletes VNFC from the last registered one. However, Scale-in operation for CNF using Kubernetes VIM cannot control the order of deletion due to Kubernetes’s functionality.

Note

Tacker does not support non-uniform deltas defined in ETSI NFV SOL001 [4]. Therefore, uniform delta corresponding to “number_of_instances” can be set and “number_of_instances” is the same regardless of scale_level.

Kubernetes API support

KubernetesDriver calls following API to get current number of replicas and updates the number replicas of target resource.

API Group

Type

API method

apps (AppsV1Api)

Read

read_namespaced_replica_set_scale

read_namespaced_deployment_scale

read_namespaced_stateful_set_scale

Update

patch_namespaced_replica_set_scale

patch_namespaced_deployment_scale

patch_namespaced_stateful_set_scale

The arguments of Read API are name and namespace.

The arguments of Update API are name, namespace, and body. The body is set to be the updated value of “spec.replicas” with the returned value in Read API.

The number of “spec.replicas” is calculated as follows:

  • Scale-in: update_replicas = current_replicas - scaling_step * number_of_steps

  • Scale-out: update_replicas = current_replicas + scaling_step * number_of_steps

The parameters used in the calculation are defined below:

  • current_replicas: the number of VnfInstance.instantiatedVnfInfo.vnfcResourceInfo belonging to the target VDU, which is judged by VnfInstance.instantiatedVnfInfo.vnfcResourceInfo.vduId

  • scaling_step: “number_of_instances” in scalingAspect defined in VNFD

  • number_of_steps: Parameter given in ScaleVnfRequest

Data model impact

None

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)

Hirofumi Noguchi <hirofumi.noguchi.rs@hco.ntt.co.jp>

Work Items

  • Implement KubernetesDriver processes running on Tacker-conductor.

  • Add new unit and functional tests.

  • Update the Tacker user guide.

Dependencies

  • Scale operation

    Depends on spec “Enhance NFV SOL_v3 LCM operation” [3].

Testing

Unit and functional test cases will be added for v2 CNF scale operations using Kubernetes VIM.

Documentation Impact

Description about v2 scale operations will be added to the Tacker user guide.

References