支持 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)处理之外,当前实现没有变化。
该过程包括以下步骤,如图所示
先决条件:VNF 实例处于“INSTANTIATED”状态。
客户端向 VNFM 发送扩展 VNF 实例的 POST 请求。
VNFM 向端点(例如客户端)发送带有“STARTING”状态的 VNF 生命周期管理操作发生通知,以指示生命周期管理操作的开始。
VNFM 通过将 Scale VNF 请求中包含的“number_of_steps”乘以 VNFD 中包含的“number_of_instances”来计算要扩展的 Pod 数量。
VNFM 和 NFVO 交换授权信息。
VNFM 向端点(例如客户端)发送带有“PROCESSING”状态的 VNF 生命周期管理操作发生通知,以指示生命周期管理操作的处理。
MgmtDriver 根据 MgmtDriver 脚本执行预操作。
总 Pod 数量通过
VnfInstance.instantiatedVnfInfo.vnfcResourceInfo获取的当前资源以及grant.addResources 和 grant.removeResources获取的扩展 Pod 计算得出。KubernetesDriver 向 Kubernetes 发送带有目标 VDU 的增量或减量“replicas”的 Update 请求。
KubernetesDriver 向 Kubernetes 发送 Read 请求以检查资源的状态。
MgmtDriver 根据 MgmtDriver 脚本执行后操作。
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 的参数是 name 和 namespace。
Update API 的参数是 name、namespace 和 body。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 影响¶
无
安全影响¶
无
通知影响¶
无
其他最终用户影响¶
无
性能影响¶
无
其他部署者影响¶
无
开发人员影响¶
无
实现¶
负责人¶
工作项¶
在 Tacker-conductor 上运行的 Implement KubernetesDriver 进程。
添加新的单元和功能测试。
更新 Tacker 用户指南。
依赖项¶
扩展操作
依赖于 spec “增强 NFV SOL_v3 LCM 操作” [3]。
测试¶
将为使用 Kubernetes VIM 的 v2 CNF 扩展操作添加单元和功能测试用例。
文档影响¶
将在 Tacker 用户指南中添加关于 v2 扩展操作的描述。