使用 MgmtDriver 支持部署 Kubernetes 集群¶
https://blueprints.launchpad.net/tacker/+spec/cnf-support-with-etsi-nfv-specs
本规范描述了 Tacker 中针对容器网络功能 (CNF) 的 VNF 生命周期管理增强。
问题描述¶
Tacker 中的 Kubernetes 基础设施驱动程序可以在预安装的 Kubernetes 集群上部署 CNF [1]。本规范提出了一种在 Kubernetes 集群不存在时部署 CNF 的方法。该过程将包括 VM 实例化、在新 VM 上安装 Kubernetes 集群，以及在新 Kubernetes 集群上部署 CNF。
提议的变更¶
需要进行以下更改
CNF 实例化过程将分为两个 VNF 实例。我们将这两个实例分别称为 VNF-A 和 VNF-B。
VNF-A：创建 VM 并设置 Kubernetes 集群。
VNF-B：在 VNF-A 内部的 Kubernetes 集群上部署 CNF。
VNF 实例化请求中提供的 VIM 类型和 additionalParams 参数将是此多阶段部署过程的重要组成部分。
VNF-A：创建 VM 并设置 Kubernetes 集群¶
作为 Kubernetes 集群，需要支持两种架构。
“Kubernetes with Kube-adm”所需的附加信息。
注意
Kubernetes v1.16.0和Kubernetes python客户端v11.0支持Kubernetes VIM。
VNF-A：创建 VM 并设置 Kubernetes 集群 (Kuryr-Kubernetes)¶
Kuryr-Kubernetes 提供了一个 CNI，使 Service 资源能够与 Neutron 端口和 LBaaS 协同工作。当用户通过 Pod 创建 Service 时，CNI 会要求 Neutron 在 LBaaS 上创建和分配端口。这有助于用户将他们的应用程序暴露到公共网络。
下图显示了创建 VM 并设置 Kubernetes 集群
+---------+ +---------+
| Cluster | | |
| Install | | VNFD |
| Script | | |
+-------+-+ +-+-------+
| |
+--------------+ v v +---------------+
| LCM operation| +----------+ | Instantiation |
| User Data |------>| | | Request with |
+--------------+ | CSAR | | Additional |
+-----------+ +--->| | | Params |
| Heat | | +----+-----+ +-+-------------+
| Template |--+ | |
| (Base HOT)| | |
+-----------+ +-----+----------+--------------+
| v v VNFM |
| +-------------------+ |
| | TackerServer | |
| +-------+-----------+ |
| | |
| v |
2. Kubernetes Cluster | +----------------------+ |
Installation | | +-------------+ | |
+-------------+------------------------+--+----| MgmtDriver | | |
| | | | +-------------+ | |
+-------|-------------|------------+ | | | |
| | | | | | | |
| +----|------+ +---|-------+ | | | | |
| | v | | v | | | | +-------------+ | |
| | +------+ | | +------+ | | 1. Create | | |OpenStack | | |
| | |Worker| | | |Master| |<---------------+--+----|Infra Driver | | |
| | +------+ | | +------+ | | VMs | | +-------------+ | |
| | VM | | VM | | | | | |
| +-----------+ +-----------+ | | | | |
+----------------------------------+ | | Tacker Conductor| |
+----------------------------------+ | +----------------------+ |
| Hardware Resources | | |
+----------------------------------+ +-------------------------------+
该图显示了本规范提案的相关组件以及以下处理的概述
OpenStackInfraDriver 创建新的 VM。
MgmtDriver 通过
instantiate_end安装 Kubernetes 集群。MgmtDriver 使用 shell 脚本在 Master-node 和 Worker-node 上安装 Kubernetes。
MgmtDriver 向 tacker 注册 Kubernetes VIM。
MgmtDriver 将 Kubernetes 集群 VIM 信息附加到 VimConnectionInfo。
以下是 Kuryr-Kubernetes 集群连接公共网络的拓扑
+-----------+
| |
| External |
| Network |
| |
+-----------+
|
+-----------+
| |
| LBaaS |
| |
+-----------+
|
+-------------------------------------------------+
|VNF-A | |
|(Kubernetes Cluster)| |
| | Kubernetes Service Network |
| | |
| |Cluster IP |
| +-----*-----+ |
| | | |
| | Service | |
| | | |
| +-----------+ |
| | |
| | Kubernetes Pod Network |
| +-----+-----+ |
| | | |
| +-----------------------------+ |
| | | | | |
| | +---*---+ +---*---+ | |
| | | Pod | | Pod | | |
| | +-------+ +-------+ | |
| | VNF-B (e.g. Deployments) | |
| +-----------------------------+ |
+-------------------------------------------------+
以下序列图描述了所涉及的组件以及使用 MgmtDriver 操作安装 Kubernetes 集群的流程
该过程由上述序列中说明的以下步骤组成。
客户端发送“instantiate”作为 POST 请求。
基本上与规范 etsi-nfv-sol-rest-api-for-VNF-deployment 的“2) VNF 实例实例化流程”章节中描述的序列相同，但 MgmtDriver 除外。
以下流程在
instantiate_end中执行。MgmtDriver从Heat获取新的VM信息。
MgmtDriver 通过 shell 脚本在新节点上安装 Kubernetes。
MgmtDriver 通过调用 shell 脚本安装 etcd 集群。
MgmtDriver 向 tacker 注册 Kubernetes VIM。
MgmtDriver 将 Kubernetes 集群 VIM 信息附加到 VimConnectionInfo。
带有 UserData 的 Kuryr-Kubernetes VNFD¶
VM 将使用 CSAR 中提供的 Heat 模板进行部署，如 LCM-operation-with-user-data 规范中所述。原因是 Kubernetes 集群将使用 Kuryr-Kubernetes 进行设置。集群安装需要一些基本的网络实体，例如路由器和负载均衡器。
注意
不支持使用 TOSCA 部署 Kuryr-Kubernetes，因为虽然 TOSCA v1.2 有定义，但 heat-translator 不支持 LoadBalancer。Router 定义在 TOSCA v1.2 中不存在。假定利用基于用户数据的实例化和基本 HOT。
注意
尽管 VM 资源信息将来可以包含在 VNFD 中，但这超出了本规范的范围。
CSAR 包的以下组件将用于 VM 实例化
VNFD
VNFD 将不包含任何 VM 资源信息，例如 VDU、连接点、虚拟链接，因为 VM 的所有必需组件都将在 heat 模板 (Base HOT) 中指定。
为了在通过 Base HOT 实例化 VM 后执行脚本来安装 Kubernetes 集群，应在 VNFD 中描述
Tosca.interfaces.nfv.Vnflcm。根据 ETSI SOL001 [2] 第 6.7 节，可以定义instantiate_end资源以启用结尾。输入参数由实例化参数中的additionalParams提供。
注意
启用 Tosca.interfaces.nfv.Vnflcm 的逻辑将通过 MgmtDriver [3] 实现。在本规范中，范围是实现 MgmtDriver 来安装 Kubernetes 集群。
Heat 模板 (Base HOT)
heat 模板将包含用于实例化 VM 和网络实体（例如路由器、负载均衡器）的资源信息。它将按 LCM-operation-with-user-data 规范中的提及使用。
LCM 操作用户数据
它将包含一个 python 模块，用于处理 BaseHOT 目录中提供的 heat 模板所需的参数。它将按 LCM-operation-with-user-data 规范中的提及使用。
VNFD 需要具有 instantiate_end 定义，示例如下
node_templates:
VNF:
type: tacker.sample.VNF
properties:
flavour_description: A simple flavour
interfaces:
Vnflcm:
instantiate: []
# inputs:
# key_1: value_1
# additional_parameters:
# type: MyCompany.datatypes.nfv.VnfInstantiateAdditionalParameters
instantiate_start: []
instantiate_end:
implementation: mgmt-drivers-kubernetes
artifacts:
mgmt-drivers-kubernetes:
description: Management driver for Kubernetes cluster
type: tosca.artifacts.Implementation.Python
file: /.../mgmt_drivers/kubernetes_mgmt.py
# data_types:
# MyCompany.datatypes.nfv.VnfInstantiateAdditionalParameters:
# derived_from: tosca.datatypes.nfv.VnfOperationAdditionalParameters
# properties:
# key_1:
# type: string
# required: true
以下是VNF实例化请求POST /vnflcm/v1/vnf_instances/{vnfInstanceId}/instantiate中提供的body示例
{
"flavourId": "cluster_install",
"additionalParams": {
"lcm-operation-user-data": "UserData/base_user_data.py",
"lcm-operation-user-data-class": "BaseUserData",
"input_params":""
},
"vimConnectionInfo": [
{
"id": "8a3adb69-0784-43c7-833e-aab0b6ab4470",
"vimId": "7dc3c839-bf15-45ac-8dff-fc5b95c2940e",
"vimType": "openstack"
}
]
}
注意
输入参数的详细信息请参阅“Kubernetes 集群安装”部分
Kubernetes 集群安装¶
本规范提出了一种在上一阶段部署的 VM 上配置 Kubernetes 集群的方法。集群将使用 MgmtDriver 调用 mgmt_call() 方法进行配置。配置可以作为 shell 脚本或 python 脚本实现。调用作为 VNF 中维护 VM 部署的 ansible 脚本可以是一种替代设计。脚本还负责返回集群访问信息。集群访问信息将作为 VIM 连接信息存储在数据库中。
注意
VNFM 将直接从 VNF 包访问工件。Add-artifacts-support-for-VNF-package 规范中指定的 API 将在将来使用。
注意
由于 MgmtDriver 仍在开发中，MgmtDriver 和安装脚本的序列将来可能会发生变化。请将它们仅作为参考。
VNF LCM 驱动程序中所需的更改将在 ActionDriver 的规范中实现。
脚本将以脚本路径和集群设置所需的参数作为参数。该函数将以以下格式返回集群访问信息。
{
"server" : "https://123.124.64.6:8443",
"username" : "some-username",
"password" : "some-password"
}
管理驱动程序将把此信息映射到 vim_connection_info，如下所示。它将存储在 vnf_instances 表的 vim_connection_info 列中。
存储在数据库中的 vim_connection_info 记录示例
{
"vim_type": "kubernetes",
"access_info": {
"auth_url":"http://123.124.64.6:8443",
"username": "some-username",
"password": "some-password"
},
"interface_info": {
}
}
Kubernetes 集群安装需要以下参数
Kuryr Kubernetes
Pod 的安全组 ID
Pod 的子网 ID
项目 ID
k8s 服务子网 ID
LBaaS ID
待办事项：列表不完整。需要确定所有必需的参数。
“additionalParams”中提供的实际参数如下
每个 VM 的信息
此 VM 的集群角色（工作/主）
ssh 登录信息
username
password
k8s 集群信息
k8s API 集群子网
k8s pod 子网
代理信息
http_proxy
https_proxy
no_proxy
k8s VIM 名称
这些参数将从请求正文中的“additionalParams”中解析，如上所述。并将通过脚本运行选项解析到脚本中。
注意
用于 ssh 访问和 Kubernetes 集群的 IP 地址将通过检查上面实例化过程创建的堆栈资源从 heat-client 获取。由于需要在 heat 客户端中指定 master 和 worker VM，master/worker 的资源名称应遵循 masterNode/workerNode。
注意
将向用户提供一个示例 heat-template。
在 instantiate_end 阶段，将调用 MgmtDriver 在目标 VM 上执行用户脚本。此功能将包含在 mgmt_drivers/kubernetes_mgmt.py 中
通过 python SSH 客户端访问目标 VM
将用户脚本复制到目标 VM
执行用户脚本并通过可选参数传递参数
注意
将向用户提供一个示例 Kubernetes 安装脚本。
VNF-A：创建 VM 并设置 Kubernetes 集群 (Kube-adm)¶
描述“Kubernetes with Kube-adm”所需的附加信息。
下图显示了创建 VM 并设置 Kubernetes 集群
+---------+ +---------+
| Cluster | | |
| Install | | VNFD |
| Script | | |
+-------+-+ +-+-------+
| |
v v +---------------+
+----------+ | Instantiation |
| | | Request with |
| CSAR | | Additional |
| | | Params |
+----+-----+ +-+-------------+
| |
| |
+-----+----------+--------------+
| v v VNFM |
| +-------------------+ |
| | TackerServer | |
| +-------+-----------+ |
| | |
| v |
2. Kubernetes Cluster | +----------------------+ |
Installation | | +-------------+ | |
+-------------+------------------------+--+----| MgmtDriver | | |
| | | | +-------------+ | |
+-------|-------------|------------+ | | | |
| | | | | | | |
| +----|------+ +---|-------+ | | | | |
| | v | | v | | | | +-------------+ | |
| | +------+ | | +------+ | | 1. Create | | |OpenStack | | |
| | |Worker| | | |Master| |<---------------+--+----|Infra Driver | | |
| | +------+ | | +------+ | | VMs | | +-------------+ | |
| | VM | | VM | | | | | |
| +-----------+ +-----------+ | | | | |
+----------------------------------+ | | Tacker Conductor| |
+----------------------------------+ | +----------------------+ |
| Hardware Resources | | |
+----------------------------------+ +-------------------------------+
该图显示了本规范提案的相关组件以及以下处理的概述
OpenStackInfraDriver 创建新的 VM。
MgmtDriver 通过
instantiate_end安装 Kubernetes 集群。MgmtDriver 使用 shell 脚本在 Master-node 和 Worker-node 上安装 Kubernetes。
MgmtDriver 向 tacker 注册 Kubernetes VIM。
MgmtDriver 将 Kubernetes 集群 VIM 信息附加到 VimConnectionInfo。
以下是 Kube-adm 集群连接公共网络的拓扑
对于 Kube-adm，用户需要与另一个 SDN 控制器协作才能连接公共网络
+-----------+
| |
| External |
| Network |
| |
+-----------+
|
+------------+
| | +------------+
| External | | SDN |
| Load +-+ Controller |
| Balancer | | |
+------------+ +------------+
|
+-------------------------------------------------+
|VNF-A | |
|(Kubernetes Cluster)| |
| | Kubernetes Service Network |
| | |
| |Cluster IP |
| +-----*-----+ |
| | | |
| | Service | |
| | | |
| +-----------+ |
| | |
| | Kubernetes Pod Network |
| +-----+-----+ |
| | | |
| +-----------------------------+ |
| | | | | |
| | +---*---+ +---*---+ | |
| | | Pod | | Pod | | |
| | +-------+ +-------+ | |
| | VNF-B (e.g. Deployments) | |
| +-----------------------------+ |
+- -----------------------------------------------+
以下序列图描述了所涉及的组件以及使用 MgmtDriver 操作安装 Kubernetes 集群的流程
该过程由上述序列中说明的以下步骤组成。
客户端发送“instantiate”作为 POST 请求。
基本上与规范 etsi-nfv-sol-rest-api-for-VNF-deployment 的“2) VNF 实例实例化流程”章节中描述的序列相同，但 MgmtDriver 除外。
以下流程在
instantiate_end中执行。MgmtDriver从Heat获取新的VM信息。
MgmtDriver 通过 shell 脚本在新节点上安装 Kubernetes。
MgmtDriver 从 Kubernetes 集群获取认证信息。
MgmtDriver 向 tacker 注册 Kubernetes VIM。
MgmtDriver 将 Kubernetes 集群 VIM 信息附加到 VimConnectionInfo。
带有 TOSCA 模板的 Kube-adm VNFD¶
在 Kube-adm 中，LCM 操作用户数据将不使用，因为 Kube-adm 中的 VM 不使用 Openstack 资源。VM 信息可以包含在 VNFD 文件中，并在接口的 Vnflcm 中包含 instantiated_end 部分。以下是一个包含 1 个主节点和 1 个工作节点的 VNFD 文件示例
tosca_definitions_version: tosca_simple_yaml_1_2
description: Deployment flavour for MgmtDriver for k8s cluster
imports:
- etsi_nfv_sol001_common_types.yaml
- etsi_nfv_sol001_vnfd_types.yaml
topology_template:
inputs:
id:
type: string
vendor:
type: string
version:
type: version
descriptor_id:
type: string
descriptor_version:
type: string
provider:
type: string
product_name:
type: string
software_version:
type: string
vnfm_info:
type: list
entry_schema:
type: string
flavour_id:
type: string
flavour_description:
type: string
substitution_mappings:
node_type: Company.Tacker.KubernetesCluster
properties:
flavour_id: cluster_install
node_templates:
VNF:
type: company.provider.VNF
properties:
flavour_description: A simple flavour
interfaces:
Vnflcm:
instantiate: []
instantiate_start: []
instantiate_end:
implementation: mgmt-drivers-kubernetes
artifacts:
mgmt-drivers-kubernetes:
description: Management driver for Kubernetes cluster
type: tosca.artifacts.Implementation.Python
file: /.../mgmt_drivers/kubernetes_mgmt.py]
masterNode:
type: tosca.nodes.nfv.Vdu.Compute
properties:
name: masterNode
description: masterNode
vdu_profile:
min_number_of_instances: 1
max_number_of_instances: 1
workerNode:
type: tosca.nodes.nfv.Vdu.Compute
properties:
name: workerNode
description: workerNode
vdu_profile:
min_number_of_instances: 1
max_number_of_instances: 1
masterNodeInternalCP:
type: tosca.nodes.nfv.VduCp
properties:
layer_protocols: [ ipv4 ]
order: 0
requirements:
- virtual_binding: masterNode
- virtual_link: internalVL
masterNodeExternalCP:
type: tosca.nodes.nfv.VduCp
properties:
layer_protocols: [ ipv4 ]
order: 1
requirements:
- virtual_binding: masterNode
# - virtual_link: # the target node is determined in the NSD
workerNodeInternalCP:
type: tosca.nodes.nfv.VduCp
properties:
layer_protocols: [ ipv4 ]
order: 2
requirements:
- virtual_binding: workerNode
- virtual_link: internalVL
workerNodeExternalCP:
type: tosca.nodes.nfv.VduCp
properties:
layer_protocols: [ ipv4 ]
order: 3
requirements:
- virtual_binding: workerNode
# - virtual_link: # the target node is determined in the NSD
internalVL:
type: tosca.nodes.nfv.VnfVirtualLink
properties:
connectivity_type:
layer_protocols: [ ipv4 ]
description: Internal Virtual link in the VNF(for k8s cluster)
vl_profile:
virtual_link_protocol_data:
- associated_layer_protocol: ipv4
l3_protocol_data:
ip_version: ipv4
cidr: 10.10.0.0/24
注意
主节点/工作节点的名称应以 master/worker 开头，以便从 heat 客户端指定 IP 地址。
以下是VNF实例化请求POST /vnflcm/v1/vnf_instances/{vnfInstanceId}/instantiate中提供的body示例
{
"flavourId": "cluster_install",
"additionalParams": {
"input_params":""
},
"vimConnectionInfo": [
{
"id": "8a3adb69-0784-43c7-833e-aab0b6ab4470",
"vimId": "7dc3c839-bf15-45ac-8dff-fc5b95c2940e",
"vimType": "openstack"
}
]
}
注意
input_params 的详细信息将在下面的“Kubernetes 集群安装”部分讨论
Kubernetes 集群安装¶
本规范提出了一种在上一阶段部署的 VM 上配置 Kubernetes 集群的方法。集群将使用 MgmtDriver 调用 mgmt_call() 方法进行配置。配置可以作为 shell 脚本或 python 脚本实现。调用作为 VNF 中维护 VM 部署的 ansible 脚本可以是一种替代设计。脚本还负责返回集群访问信息。集群访问信息将作为 VIM 连接信息存储在数据库中。
注意
VNFM 将直接从 VNF 包访问工件。Add-artifacts-support-for-VNF-package 规范中指定的 API 将在将来使用。
注意
由于 MgmtDriver 仍在开发中，MgmtDriver 和安装脚本的序列将来可能会发生变化。请将它们仅作为参考。
VNF LCM 驱动程序中所需的更改将在 ActionDriver 的规范中实现。
脚本将以脚本路径和集群设置所需的参数作为参数。该函数将以以下格式返回集群访问信息。
{
"server" : "https://123.124.64.6:8443",
"username" : "some-username",
"password" : "some-password"
}
管理驱动程序将把此信息映射到 vim_connection_info，如下所示。它将存储在 vnf_instances 表的 vim_connection_info 列中。
在 Kube-adm Kubernetes 集群部署期间，Kube-adm 将生成一个 ca 证书和一个证书密钥，并将在对 Kube-adm Kubernetes 集群的 https 请求中使用。证书和密钥也将存储在 vnf_instance 表中的 vimConnectionInfo 中，并在将 Kubernetes 集群 VIM 信息附加到 Tacker DB 期间带有识别令牌。
存储在数据库中的 vim_connection_info 记录示例
{
"vim_type": "kubernetes",
"access_info": {
"auth_url":"http://123.124.64.6:8443",
"username": "some-username",
"password": "some-password",
"bearer_token": "value of bearer token",
"ssl_ca_cert_hash": "hash value of ssl ca certification",
"certificate_key": "value of certificate key"
},
"interface_info": {
}
}
此外，Kubernetes VIM 信息也将添加到 tackerDB 中的 Vim 表中。与 openstack VIM 相比，Kubernetes VIM 在 vim_auth 表中将具有额外的属性。
存储在数据库中的 VimAuth 记录示例
{
"vim_id": "id of Kubernetes VIM",
"auth_url": "ip address of Kubernetes cluster"
"vim_project": {}
"auth_cred": {
"username": "username",
"password": "password",
"bearer_token": "value of bearer_token",
"ssl_ca_cert_hash": "hash value of ssl ca certification",
"certificate_key": "value of certificate key"
}
}
注意
Username/password 和 bearer_token 在这里不是必需属性，但至少其中之一应该存在。Ssl_ca_cert_hash 和 certificate_key 在这里对于 https 请求和加入工作节点是必需的。
注意
在 Kube-adm 中，有 3 种用户认证方式可用。请参阅 auth-of-kube-adm。在 tacker 中，将支持基本认证/Bearer Token。对于 bearer token 的生成，将支持服务账户令牌方法而不是静态令牌文件方法。
注意
在 Kube-adm 安装期间，将自动生成一个服务账户令牌。但是此令牌没有 pod 操作的权限。因此，安装脚本将生成一个新的服务账户令牌并将其存储在 tacker DB 中。
Kubernetes 集群安装需要以下参数
Kube-adm
k8s API 集群 IP
k8s API 集群子网
k8s pod 子网
待办事项：列表不完整。需要确定所有必需的参数。
“additionalParams”中提供的实际参数如下
每个 VM 的信息
此 VM 的集群角色（工作/主）
ssh 登录信息
username
password
k8s 集群信息
k8s API 集群子网
k8s pod 子网
代理信息
http_proxy
https_proxy
no_proxy
k8s VIM 名称
这些参数将从请求正文中的“additionalParams”中解析，如上所述。并将通过脚本运行选项解析到脚本中。
注意
用于 ssh 访问和 Kubernetes 集群的 IP 地址将通过检查上面实例化过程创建的堆栈资源从 heat-client 获取。由于需要在 heat 客户端中指定 master 和 worker VM，master/worker 的资源名称应遵循 masterNode/workerNode。
注意
将向用户提供一个示例 heat-template。
在 instantiate_end 阶段，将调用 MgmtDriver 在目标 VM 上执行用户脚本。此功能将包含在 mgmt_drivers/kubernetes_mgmt.py 中
通过 python ssh 客户端访问目标 VM
将用户脚本复制到目标 VM
执行用户脚本并通过可选参数传递参数
注意
将向用户提供一个示例 Kubernetes 安装脚本。
VNF-A：VNF-A 的终止¶
VNF-B 需要在 VNF-A 之前终止，详情请参阅 VNF-B 的终止。
此外，VNF-A 终止期间需要删除 vim 连接信息。与实例化相同，此逻辑将通过 MgmtDriver 在 vnflcm 的 terminate_end 阶段执行。
以下序列图描述了所涉及的组件以及使用 MgmtDriver 操作终止 Kubernetes 集群的流程
该过程包括以下步骤，如图所示
客户端发送“terminate”作为 POST 请求。
基本上与规范 etsi-nfv-sol-rest-api-for-VNF-deployment 的“4) VNF 实例终止流程”章节中描述的序列相同，但 MgmtDriver 除外。
在
terminate_end中执行以下过程。删除 Tacker DB 中 Kubernetes 集群的 VIM 信息。
清除存储在 VNF 实例的 vim_connection_info 中的旧 Kubernetes 集群信息。
VNFD 需要具有 terminate_end 定义，示例如下
node_templates:
VNF:
type: tacker.sample.VNF
properties:
flavour_description: A simple flavour
interfaces:
Vnflcm:
instantiate_start: []
instantiate_end:
implementation: mgmt-drivers-kubernetes
terminate_start: []
terminate_end:
implementation: mgmt-drivers-kubernetes
artifacts:
mgmt-drivers-kubernetes:
description: Management driver for Kubernetes cluster
type: tosca.artifacts.Implementation.Python
file: /.../mgmt_drivers/kubernetes_mgmt.py
VNF-B：在 VNF-A 内部的 Kubernetes 集群上部署 CNF¶
以下展示了如何将 CNF 部署到 VNF-A 中的 Kubernetes 集群。
VNF-B：CNF 实例化¶
CNF 实例化需要一个类型为 kubernetes 的 VIM。如上文所述，VNF-A 中创建的 Kubernetes 集群的访问信息将存在于 vnf_instances 表的 vim_connection_info 列中。
用户将调用 GET /vnflcm/v1/vnf_instances/{vnfInstanceId} API，并使用响应中的 vimConnectionInfo 手动注册一个类型为 kubernetes 的 VIM。CNF 实例化将按照 Container-Network-Function 规范中的规定完成。因此，此步骤不需要设计更改。
下图显示了 CNF (VNF-B) 将如何部署在 VNF-A 中创建的 Kubernetes 集群上
+----------+
| |
| VNFD |
| |
+-+--------+
|
v
+----------+ +-------------------+
+---------------+ | | | Instantiation |
| CNF Definition| | CSAR | | Request with |
| File +-----------> | | | Additional Params |
+---------------+ +------+---+ +---+---------------+
| |
+---------------------------------+
| v v VNFM |
+ - - - - - - - - - - - - - - - - - - - -+ | +----------------+ |
: VNF-B : | | TackerServer | |
: +------------------------------+ : | +----------------+ |
: | +----------+ +----------+ | : | | |
: | | App | | App | | : | +------------------------+ |
: | +----------+ +----------+ | : | | v | |
: | +----------+ +----------+ | : | | +---------------+ | |
: | |Container | |Container | | <-------------+ Kubernetes | | |
: | +----------+ +----------+ | : | | | Infra Driver | | |
: +------------------------------+ : | | +---------------+ | |
+ - - - - - - - - - - - - - - - - - - - -+ | | ^ | |
| | | | |
+ - - - - - - - - - - - - - - - - - - - -+ | | +-------+-------+ | |
: VNF-A : | | | VNF LCM | | |
: +------------------------------+ : | | | Driver | | |
: | Kubernetes cluster | : | | +---------------+ | |
: | +----------+ +----------+ | : | | | |
: | | +------+ | | +------+ | | : | | | |
: | | |Worker| | | |Master| | | : | | +---------------+ | |
: | | +------+ | | +------+ | | : | | | OpenStack | | |
: | | VM | | VM | | : | | | Infra Driver | | |
: | +----------+ +----------+ | : | | +---------------+ | |
: +------------------------------+ : | | | |
+ - - - - - - - - - - - - - - - - - - - -+ | | Tacker Conductor | |
| | | |
+------------------------------+ | +------------------------+ |
| Hardware Resources | | |
+------------------------------+ +---------------------------------+
VNF-B 对 VNF-A 依赖性的影响¶
由于 CNF-B 将部署在 VNF-A 中创建的 Kubernetes 集群上，因此在 VNF-A 上执行的操作将影响 VNF-B。
VNF-A 的终止¶
这将销毁 VNF-B，并且 VNF-B 正在处理的数据将变得不一致。因此，VNF-B 必须在 VNF-A 之前优雅地终止。自动执行此类终止序列超出了本规范的范围，因此所需序列将在用户指南中描述。
VNF-A 的修复¶
VNF LCM 序列的修复用例会终止现有 VM 并生成新的替换 VM。运行 Kubernetes 集群的主节点或工作节点的 VM 的终止可能会破坏 VNF-B。因此，在对 VNF-A 执行修复操作之前，可能需要优雅地终止 VNF-B 或迁移 Pod。所需序列将在用户指南中描述。
数据模型影响¶
无
REST API 影响¶
无
安全影响¶
无
通知影响¶
无
其他最终用户影响¶
无
性能影响¶
无
其他部署者影响¶
无
开发人员影响¶
无
实现¶
负责人¶
- 主要负责人
- 其他贡献者
Nitin Uikey <nitin.uikey@nttdata.com>
Tushar Patil <tushar.vitthal.patil@gmail.com>
Prashant Bhole <prashant.bhole@nttdata.com>
Ayumu Ueha <ueha.ayumu@fujitsu.com>
工作项¶
实现管理驱动程序以支持
Kubernetes 集群配置
存储和删除 Kubernetes VIM 连接信息
提供一个由 MgmtDriver 执行的示例脚本，用于安装和/或配置 Kubernetes 集群
添加新的单元和功能测试。
依赖项¶
无
测试¶
将添加单元和功能测试，以涵盖规范所需的用例。
文档影响¶
将添加完整的用户指南，以解释 VM 内部 Kubernetes 集群上的 CNF 实例化。
VNF 终止过程将在用户指南中描述。
