使用 Helm Chart 增强 CNF 操作¶
https://blueprints.launchpad.net/tacker/+spec/support-instantiationlevel-cnf
https://blueprints.launchpad.net/tacker/+spec/remove-cnf-restriction
问题描述¶
本规范重点在于增强 Tacker 的 Helm Chart 处理能力，如下所示。
使用 Helm Chart 部署 CNF 时，Pod 的初始数量应由
instantiationLevel参数确定。但是，当前 CNF 的 v1 LCM API 忽略此参数。 [1] 本规范支持使用instantiationLevel参数来确定 Pod 的初始数量。在当前实现中，只有 v1 API 支持使用 Helm Chart 实例化/终止 CNF。本规范建议在 v2 API 中支持使用 Helm Chart 进行 CNF 操作。
在根据“如何将 Helm 安装到 Kubernetes 集群并使用 Helm Chart 部署 CNF”构建 Kubernetes 集群的情况下，[1] Tacker 会自动配置 MasterNode 以使用 HelmChart，并将相关访问信息存储在 TackerDB 中。另一方面，在使用外部 Kubernetes 集群的情况下，需要在 Tacker DB 中手动设置访问信息。为了消除此限制，本规范增强了
openstack vim register命令和 API，以处理extra字段。注意
以下是手动将 MasterNode 的访问信息注册到 TackerDB 的示例。
$ mysql mysql> use tacker; mysql> update vims set extra=json_object('helm_info', '{"masternode_ip": ["129.152.76.187"], "masternode_username": "root", "masternode_password": "root"}') where id="355a5b1c-4b7b-410c-8e2c-9d099d1f14f1";
提议的变更¶
支持实例化级别¶
本规范建议添加从 instantiationLevelId 参数和 VNFD 中定义的 replica count 参数计算要实例化的 VNFC 数量的过程。
用于确定要启动的 Pod 数量的参数在 VNFD 中描述。
所需的参数如下所示。 [2]
topology_template.policies.instantiation_levels(类型：tosca.policies.nfv.InstantiationLevels)topology_template.policies.vdu1_initial_delta(类型：tosca.policies.nfv.VduInitialDelta)topology_template.policies.vdu1_scaling_aspect_deltas(类型：tosca.policies.nfv.VduScalingAspectDeltas)
Pod 数量的计算逻辑如下
提取在 instantiation_levels 中描述的
instantiationLevelId对应的scale_level值“要启动的 Pod 数量” =
vdu1_initial_delta+ (scale_level*vdu1_scaling_aspect_deltas)
下图显示了使用 Helm Chart 实例化 CNF。
+------+ +------------+
| VNFD | | Helm Chart |
| | | |
+-+----+ ++-----------+
| |
+-v-------v-+ +----------------------+
| | | Instantiate |
| CSAR | | VNF request with |
| | | instantiationLevelId |
+-----+-----+ +----------------+-----+
| |
+-----------------------+ +--------------+ |
| CNF with Helm Chart | 1. Request with | |
| | Helm Chart | |
| | (with instantiationLevelId) +-------------------------------+
| +------+ +------+ | | | | |
| | Pod | | Pod | | | +--v-------------------v--+ |
| | | | | <--------------------+ | | | |
| +------+ +------+ | | | | TackerServer | |
| | | | | | |
+-----------------------+ | | +------+------------------+ |
| | | |
+--------------------------------------------------------+ | +-------------------------+ |
| Kubernetes cluster VNF | | | | | TackerConductor | |
| | | | | | | |
| +-----------------------+ +-----------------------+ | | | +---v---------------+ | |
| | Worker | | Master | | | | | | VnflcmDriver | | |
| | | | | | | | | | (V1/V2) | | |
| | | | +--------------+--+ | | | | +---+---------------+ | |
| | | | | kubelet | | | | | | | |
| | | | +--------------^--+ | | | | +---v---------------+ | |
| | | | | | | | | | Kubernetes | | |
| | | | +--------------+--+ | | | | | InfraDriver | | |
| | | | | Helm | | | | | | | | |
| | | | +-----------------+ | | | | | +-------------+ | | |
| | | | | Helm cli <-------------------------------+ Helm client | | | |
| | | | +-----------------+ | | | | | +-------------+ | | |
| | | | | Helm Repository | | | | | | | | |
| | | | +-----------------+ | | 2. Send | | +-------------------+ | |
| | | | | | Helm Chart | | | |
| +-----------------------+ +-----------------------+ | files with | +-------------------------+ |
| | Helm cli | |
+--------------------------------------------------------+ via SSH +-------------------------------+
and deployment instructions
TackerServer 接收带有
instantiationLevelId参数的实例化 VNF 请求。KubernetesInfraDriver 从
InstantiationLevelId计算要启动的 Pod 数量，然后通过 SSH 发送带有 Helm cli 的 Helm Chart 文件。 KubernetesInfraDriver 发送部署指令。
以下时序图描述了使用 Helm Chart 实例化 CNF
Tacker-server 接收带有
instantiationLevelId参数的实例化 VNF 请求。Tacker-server 将实例化 VNF 请求发送到 Tacker-conductor。
Tacker-conductor 将实例化 VNF 请求发送到 VnfLcmDriver(V1/V2)
VnfLcmDriver(V1/V2) 向 KubernetesInfraDriver 发送请求以应用部署。
KubernetesInfraDriver 从 TackerDB 获取 VNFPackage 信息。
KubernetesInfraDriver 根据上述逻辑计算要启动的 Pod 数量。
KubernetesInfraDriver 从 TackerDB 获取 MasterNode 访问信息。
KubernetesInfraDriver 发送指令以使用 Helm Chart 部署 Pod，并将计算出的 Pod 数量作为参数。
KubernetesInfraDriver 从 MasterNode 获取清单信息。
KubernetesInfraDriver 将清单信息保存为 vnf_resource 到 TackerDB。
KubernetesInfraDriver 从 KubernetesDB 获取 Pod 信息。
KubernetesInfraDriver 将 Pod 信息保存到 TackerDB。
注意
仅在 v1 中执行将清单信息保存为 vnf_resource。v2 没有 vnf_resource 数据，因为它不是由 NFV 标准定义的 Tacker 的原始数据模型。
示例 VNFD 文件¶
VNFD 中描述了用于计算初始 Pod 数量的参数，例如 ETSI NFV-SOL001 [2] 定义的 tosca.policies.nfv.InstantiationLevels。
以下显示了一个示例 VNFD 文件。
tosca_definitions_version: tosca_simple_yaml_1_2
description: Sample CNF with helmchart
imports:
- etsi_nfv_sol001_common_types.yaml
- etsi_nfv_sol001_vnfd_types.yaml
- ipvlanpod1_vnfd_types.yaml
topology_template:
(Omit)
node_templates:
VNF:
type: company.provider.VNF
properties:
flavour_description: A flavour for single resources
VDU1:
type: tosca.nodes.nfv.Vdu.Compute
properties:
name: ipvlanpod-ipvlanpod1
description: kubernetes resource as VDU1
vdu_profile:
min_number_of_instances: 1
max_number_of_instances: 3
policies:
(Omit)
- vdu1_initial_delta:
type: tosca.policies.nfv.VduInitialDelta
properties:
initial_delta:
number_of_instances: 1
targets: [ VDU1 ]
- vdu1_scaling_aspect_deltas:
type: tosca.policies.nfv.VduScalingAspectDeltas
properties:
aspect: vdu1_aspect
deltas:
delta_1:
number_of_instances: 1
targets: [ VDU1 ]
- instantiation_levels:
type: tosca.policies.nfv.InstantiationLevels
properties:
levels:
instantiation_level_1:
description: Smallest size
scale_info:
vdu1_aspect:
scale_level: 0
instantiation_level_2:
description: Largest size
scale_info:
vdu1_aspect:
scale_level: 2
default_level: instantiation_level_1
示例请求参数¶
InstantiateVnfRequest 允许客户端为 v1 和 v2 API 指定以下公共参数。
属性名称 |
参数描述 |
|---|---|
instantiationLevelId |
设置运行 Pod 的实例化级别 |
使用 Helm chart 时，additionalParams.helm_replica_values 的值需要包含在 InstantiateVnfRequest 中。此参数指示 Helm chart 中描述的 Pod 数量参数的名称。客户端必须根据 LCM 中使用的 Helm chart 指定它。
以下显示了 v1 实例化的示例请求体
{
"flavourId": "simple",
"instantiationLevelId": "instantiation_level_1",
"additionalParams": {
"namespace": "default",
"use_helm": "true",
"using_helm_install_param": [
{
"exthelmchart": "false",
"helmreleasename": "vdu1",
"helmparameter": [
"key1=value1",
"key2=value2"
],
"helmchartfile_path": "Files/kubernetes/localhelm-0.1.0.tgz"
}
],
"helm_replica_values": {
"vdu1_aspect": "replicaCount"
}
"vdu_mapping": {
"VDU1": {
"kind": "Deployment",
"name": "vdu1-localhelm",
"helmreleasename": "vdu1"
}
}
},
"vimConnectionInfo": [
{
"id": "817954e4-c321-4a31-ae06-cedcc4ddb85c",
"vimId": "690edc6b-7581-48d8-9ac9-910c2c3d7c02",
"vimType": "kubernetes"
}
]
}
注意
v1 和 v2 在 vimConnectionInfo 数据类型之间存在差异。 vimConnectionInfo.id 仅存在于 v1 中。v2 vimConnectionInfo 是 map 结构，而不是包含 id 参数。
使用 Helm Chart 在 v2 API 中支持 CNF 实例化/终止¶
本规范建议在 V2 API 中支持 Helm chart。
注意
根据规范“支持 Kubernetes VIM 的 Helm Chart”，v1 API 已经支持使用 Helm Chart 进行 CNF 实例化/终止操作。 [3]
使用 Helm Chart 的 v2 API 架构¶
v2 API 架构与 v1 API 架构不同。在 v1 API 架构中，Helm 安装在 Kubernetes master 节点上，Tacker 通过 SSH 使用它。但是，此架构使身份验证过程复杂化。它要求 Tacker 管理两个身份验证点，即直接使用 API 的 Kubernetes 和 SSH 访问的主机。
为了解决此问题，v2 API 架构将 Helm 安装在 VNFM 内部。由于此更改将 VNFM 和 VIM 之间的接口统一为 Kubernetes API，因此简化了身份验证过程。
以下显示了每个架构。
- 使用 Helm Chart 的 v1 API 架构
该图在 上一节 中描述。
- 使用 Helm Chart 的 v2 API 架构
+------+ +------------+ | VNFD | | Helm chart | | | | | +-+----+ ++-----------+ | | +-v-------v-+ +-----------------+ | | | Instantiation | | CSAR | | Request with | | | | additionalParam | +-----+-----+ +-----------+-----+ | | +-----------------------+ | 1. Request with | | CNF with Helm chart | | Helm chart | | | +--------------------------------------------------+ | +------+ +------+ | | Tacker Host | | | | | Pod | | Pod | | | +--v-------------------v--+ | | | | | | <-------+ | | | | | +------+ +------+ | | | | TackerServer | | | | | | | | | +-----------------------+ | | +------+------------------+ | | | | | +-------------------------------------------+ | +-------------------------+ | | Kubernetes cluster VNF | | | | | TackerConductor | | | | | | | | | | | +----------+ +-----------------------+ | | | +---v---------------+ | | | | Worker | | Master | | | | | | VnflcmDriver | | | | | | | | | | | | | | | | | | | | | | | | | +---+---------------+ | | | | | | | | | | | | | | | | | | | | | | | +---v---------------+ | | | | | | | | | | 2. Operate Helm cli | | Kubernetes | | | | | | | +--------------+--+ | | | +--------------+--+ | | InfraDriver | | | | | | | | kube-apiserver <------------+ Helm | | | | | | | | | | | +-----------------+ | | | +-----------------+ | | +-v-----------+ | | | | | | | | | | | Helm cli <------+ Helm client | | | | | | | | | | | +-----------------+ | | +-------------+ | | | | | | | | | | | Helm Repository | | | | | | | | | | | | | +-----------------+ | +-------------------+ | | | | | | | | | | | | | +----------+ +-----------------------+ | | +-------------------------+ | | | | | +-------------------------------------------+ +--------------------------------------------------+
使用 Helm Chart 实例化 v2 API 的 CNF¶
v2 API 实现遵循 v1 API 实现，包括以下过程
检查参数
注册 Helm 仓库或发送 Helm Chart 文件
使用 Helm Chart 创建容器
获取资源信息并将 VnfInstance 更新到 TackerDB
使用 Helm Chart 终止 v2 API 的 CNF¶
v2 API 实现遵循 v1 API 实现，包括以下过程
使用 Helm Chart 删除容器
删除 Helm 仓库或删除 Helm Chart 文件
将 VnfInstance 更新到 TackerDB
支持 vimConnectionInfo.extra 字段¶
本规范建议添加以下功能。
支持带有配置文件 (vim config) 的 openstack vim register 命令，包括
extra参数。它处理 TackerDB 中的 extra 字段。在 v1 API 中使用 Helm chart 实例化 CNF 时，支持在 InstantiateVnfRequest.vimConnectionInfo 中指定的
extra参数。
Vim 配置示例¶
以下显示了一个示例配置文件 (vim config)，其中包含 openstack vim register 命令的 extra 参数。
auth_url: "https://192.168.121.47:6443"
bearer_token: "eyJhbGciOiJSUzI1NiIsImtpZCI6Ild2VTJCWDRMc2poR0hTSDhmNGMtMjRxdThkcUw4MlozbV9kcXNpRmg0bzQifQ.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJkZWZhdWx0Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZWNyZXQubmFtZSI6ImRlZmF1bHQtdG9rZW4tbjk2bDIiLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlcnZpY2UtYWNjb3VudC5uYW1lIjoiZGVmYXVsdCIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50LnVpZCI6IjFjODZmNzZjLWEwZTktNDBhNC05ZjcyLTMwMGY4YzJjYzY2MyIsInN1YiI6InN5c3RlbTpzZXJ2aWNlYWNjb3VudDpkZWZhdWx0OmRlZmF1bHQifQ.D0vcn61G9cdzQvruTisbhR3LLkMghj3fqQDs8KNgJifR_OpbgeLqHuHRxS-WA9yJ5pM8hmMNpyHi5_6BFVOnRnBTiNYgXwrVxBL7R62vXeeBeWlY_072SaDwutbXvCIXo4yl1MTqpWRl3YuoeAb_Js-HJA2gCavymTAFcESlt8EZDtp-AN4_QN1eIPGlQcWAfVrFP5xgIMpDZNFjWCS2n7TKNbXJ3U-vksZ8sBdBYqRtzmOHrJCI6KI85LmXKWCxo5KSsq54JsIj4iDjS-yL5MOQ-ClAVOAlnyMH-_EmkpO25LKhuYPCIUxSy6XddUv7-zR3-nNk9T9ifl5Rhy8B8w"
ssl_ca_cert: "None"
project_name: "default"
type: "kubernetes"
extra:
helm_info:
masternode_ip:
- "192.168.121.47"
masternode_username: "helm_user"
masternode_password: "helm_pass"
输入参数示例¶
以下显示了 v1 实例化包括 vimConnectionInfo.extra 的示例输入参数，用于 openstack vnflcm instantiate 命令。如 上一节 中所述，v1 和 v2 之间的区别在于 vimConnectionInfo。
{
"flavourId": "simple",
"additionalParams": {
"namespace": "default",
"use_helm": "true",
"using_helm_install_param": [
{
"exthelmchart": "false",
"helmreleasename": "vdu1",
"helmparameter": [
"key1=value1",
"key2=value2"
],
"helmchartfile_path": "Files/kubernetes/localhelm-0.1.0.tgz"
}
],
"helm_replica_values": {
"vdu1_aspect": "replicaCount"
}
"vdu_mapping": {
"VDU1": {
"kind": "Deployment",
"name": "vdu1-localhelm",
"helmreleasename": "vdu1"
}
}
},
"vimConnectionInfo": [
{
"id": "817954e4-c321-4a31-ae06-cedcc4ddb85c",
"vimId": "690edc6b-7581-48d8-9ac9-910c2c3d7c02",
"vimType": "kubernetes",
"extra": {
"helm_info": {
"masternode_ip": [
"192.168.121.47"
],
"masternode_username": "helm_user",
"masternode_password": "helm_pass"
}
}
}
]
}
数据模型影响¶
无
REST API 影响¶
无
安全影响¶
无
通知影响¶
无
其他最终用户影响¶
无
性能影响¶
无
其他部署者影响¶
无
开发人员影响¶
无
实现¶
负责人¶
- 主要负责人
- 其他贡献者
Hideki Matsuda <matsuda.hideki1@fujitsu.com>
Ayumu Ueha <ueha.ayumu@fujitsu.com>
Yoshiyuki Katada <katada.yoshiyuk@fujitsu.com>
新見雄介 <niimi.yusuke@fujitsu.com>
工作项¶
添加新的单元和功能测试。
依赖项¶
无
测试¶
将添加单元和功能测试，以涵盖本规范所需的案例。
文档影响¶
无
