支持 v2 LCM API 中的 CNF 扩展

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

本文档增强了 v2 版本的 Scale API,以支持 CNF。

问题描述

Yoga 版本支持 ETSI NFV SOL002 v3.3.1 [1] 和 SOL003 v3.3.1 [2] 中定义的 VNF 生命周期管理 (LCM) 操作。它还支持使用 v2 API(例如实例化 API、终止 API 和更改当前 VNF 包 API)进行 CNF 生命周期管理。

然而,v2 Scale API 目前尚未支持 CNF。在 v2 LCM API 中支持 CNF 可以使 Tacker 成为更强大的通用 VNFM。

提议的变更

本规范增强了以下 API 以支持 CNF。

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

CNF 扩展的定义

v2 CNF 扩展的定义与 v1 CNF 扩展的定义相同。

在使用 Kubernetes VIM 的情况下,VDU 被映射到 ReplicaSet、Deployment、DaemonSet 或 StatefulSet,而 VNFC 是一个 Pod。扩展操作会更改 VDU 资源的副本数量,Kubernetes 控制器会自动创建或删除 Pod。

以下 Kubernetes 资源类型支持更新副本数量:

  • ReplicaSet

  • Deployment

  • StatefulSet

注意

DaemonSet 也可以映射到 VDU,但由于它没有副本属性,因此不支持扩展操作。

注意

在缩减规模时,分配的 PersistentVolumeClaim (PVC) 和 PersistentVolume (PV) 会保留。同样,在扩展规模时,如果 Pod 的 spec 部分包含 PVC,则用户需要在操作之前预置所需的 PVC 和 PV。此先决条件与 v1 API 相同。

扩展 VNF 的流程

除了 InfraDriver(KubernetesDriver)处理之外,当前实现没有变化。

../../_images/0158.png

该过程包括以下步骤,如图所示

先决条件:VNF 实例处于“INSTANTIATED”状态。

  1. 客户端向 VNFM 发送扩展 VNF 实例的 POST 请求。

  2. VNFM 向端点(例如客户端)发送带有“STARTING”状态的 VNF 生命周期管理操作发生通知,以指示生命周期管理操作的开始。

  3. VNFM 通过将 Scale VNF 请求中包含的“number_of_steps”乘以 VNFD 中包含的“number_of_instances”来计算要扩展的 Pod 数量。

  4. VNFM 和 NFVO 交换授权信息。

  5. VNFM 向端点(例如客户端)发送带有“PROCESSING”状态的 VNF 生命周期管理操作发生通知,以指示生命周期管理操作的处理。

  6. MgmtDriver 根据 MgmtDriver 脚本执行预操作。

  7. 总 Pod 数量通过 VnfInstance.instantiatedVnfInfo.vnfcResourceInfo 获取的当前资源以及 grant.addResources grant.removeResources 获取的扩展 Pod 计算得出。

  8. KubernetesDriver 向 Kubernetes 发送带有目标 VDU 的增量或减量“replicas”的 Update 请求。

  9. KubernetesDriver 向 Kubernetes 发送 Read 请求以检查资源的状态。

  10. MgmtDriver 根据 MgmtDriver 脚本执行后操作。

  11. VNFM 向端点(例如客户端)发送带有“COMPLETED”状态或“FAILED_TEMP”状态的 VNF 生命周期管理操作发生通知,以指示生命周期管理操作的结果。

后置条件:VNF 实例仍处于“INSTANTIATED”状态,并且 VNF 已扩展。

注意

使用 OpenStack VIM 的 VNF 的 v2 缩减规模操作会从最后一个注册的 VNFC 开始删除。但是,使用 Kubernetes VIM 的 CNF 的缩减规模操作无法控制删除顺序,因为 Kubernetes 的功能限制。

注意

Tacker 不支持 ETSI NFV SOL001 [4] 中定义的非均匀增量。因此,可以设置与“number_of_instances”对应的均匀增量,并且无论 scale_level 如何,“number_of_instances”都是相同的。

Kubernetes API 支持

KubernetesDriver 调用以下 API 来获取当前副本数量并更新目标资源的副本数量:

API 组

类型

API 方法

apps (AppsV1Api)

读取

read_namespaced_replica_set_scale

read_namespaced_deployment_scale

read_namespaced_stateful_set_scale

更新

patch_namespaced_replica_set_scale

patch_namespaced_deployment_scale

patch_namespaced_stateful_set_scale

Read API 的参数是 namenamespace

Update API 的参数是 namenamespacebody。Body 设置为 Read API 中返回的值的“spec.replicas”的更新值。

“spec.replicas”的数量计算如下:

  • 缩减规模:update_replicas = current_replicas - scaling_step * number_of_steps

  • 扩展规模:update_replicas = current_replicas + scaling_step * number_of_steps

计算中使用的参数定义如下:

  • current_replicas:属于目标 VDU 的 VnfInstance.instantiatedVnfInfo.vnfcResourceInfo 的数量,通过 VnfInstance.instantiatedVnfInfo.vnfcResourceInfo.vduId 判断

  • scaling_step:VNFD 中 scalingAspect 中定义的“number_of_instances”

  • number_of_steps:ScaleVnfRequest 中给定的参数

数据模型影响

REST API 影响

安全影响

通知影响

其他最终用户影响

性能影响

其他部署者影响

开发人员影响

实现

负责人

野口宏文 <hirofumi.noguchi.rs@hco.ntt.co.jp>

工作项

  • 在 Tacker-conductor 上运行的 Implement KubernetesDriver 进程。

  • 添加新的单元和功能测试。

  • 更新 Tacker 用户指南。

依赖项

  • 扩展操作

    依赖于 spec “增强 NFV SOL_v3 LCM 操作” [3]

测试

将为使用 Kubernetes VIM 的 v2 CNF 扩展操作添加单元和功能测试用例。

文档影响

将在 Tacker 用户指南中添加关于 v2 扩展操作的描述。

参考资料