容器网络功能 (CNF) 与 VNFM 和 CISM¶
https://blueprints.launchpad.net/tacker/+spec/cnf-support-with-etsi-nfv-specs
本规范描述了 Tacker 中容器网络功能生命周期管理的增强。
问题描述¶
基于容器的虚拟化是操作系统级别的虚拟化，而虚拟机 (VM) 是基于 hypervisor 的虚拟化。基于容器的虚拟化的优点是它对内存和 CPU 的消耗更轻。它们更易于部署、迁移和链式化。Kubernetes 是最广泛使用的容器编排平台，具有内置的可扩展性和高可用性功能。
Tacker 具有 Kubernetes 基础设施驱动程序，可以使用 VNFD 中提供的 TOSCA 定义实例化 CNF。它支持有限数量的 Kubernetes 对象。此外，它也不符合 VNF LCM API。本规范旨在添加对其他 Kubernetes 对象和 VNF LCM API 的支持。当前的 ETSI SOL 标准没有指定如何在 VNFD 中包含 CNF 定义。因此，本规范提出了一种额外的从 CSAR 包提供的工件中读取 Kubernetes 对象文件作为 CNF 定义的方法。
注意
虽然未来将支持基于 VNFD 的 CNF 定义，但它们不在本规范的范围内。
预计 NFVO 将使用规范 add-artifact-support-for-vnf-package 中提到的 API 对 CSAR 包提供的工件进行验证。NFVO 中的此类更改将是未来的工作。在本规范中，验证将在 VNFM 中执行。
提议的变更¶
本规范假定 CNF 部署在预安装的 Kubernetes 集群上。Kubernetes 基础设施驱动程序需要以下更改
从 additionalParams 中指定的工件加载 Kubernetes 对象文件。
支持 Kubernetes 资源种类支持 中指定的其他 Kubernetes 对象。
通过实现来自
VnfAbstractDriver的其他方法来支持 VNF LCM API。pre_instantiation_vnf
instantiate_vnf
post_vnf_instantiation
以下框图显示了涉及在预安装的 Kubernetes 集群上实例化 CNF 的组件
+----------------------+
+--------------------------+ | NFVO |
| Instantiated CNF | | |
| | +----------------------+
| +------+ +------+ | +----------------------+
| | App | | App | | | VNFM |
| +------+ +------+ | | +-------------+ |
| +---------+ +---------+ | | |Infra driver | |
| |Container| |Container| | | +----+--------+ |
| +---------+ +---------+ | | | |
+--------------------------+ +-------+--------------+
+-------+--------------+
+--------------------------+ | v VIM |
|+---------+ +---------+ | | +----------+ |
|| CIS | | CIS |<+----+--+ CISM | |
|+---------+ +---------+ | | +----------+ |
| | +----------------------+
| Pre-installed |
| Kubernetes cluster |
+--------------------------+
在这种情况下，容器基础设施服务管理 (CISM) 嵌入在 VIM 中。基础设施驱动程序将使用 CISM 在预安装的 Kubernetes 集群上实例化 CNF。容器基础设施服务 (CIS) 可以在裸机或 VM 上运行。
下图显示了在预安装的 Kubernetes 集群上实例化 CNF
+------------+
| VNFD |
+----+-------+ +---------------+
| | Instantiation |
+-----------+ +----v-------+ | Request with |
|CNF +-----> | | | additional |
|Definition | | CSAR | | Params |
+-----------+ +--------+---+ +-+-------------+
| |
| |
+-----------+-----------+-----------+
| v v |
| +----------------------+ |
| | Tacker-server | |
| +-----+----------------+ |
| | |
| v |
| +------------------------------+ |
Instantiate CNF | | +--------------+ | |
+-------------+------------------------+-+--+ Kubernetes | | |
| | | | | Infra Driver | | |
v v | | +--------------+ | |
+------------+ +-----------+ | | | |
| Container | | Container | | | | |
+------------+ +-----------+ | | | |
+---------------------------+ | | | |
| Pre-installed | | | Tacker conductor | |
| Kubernetes cluster | | +------------------------------+ |
+---------------------------+ +-----------------------------------+
该图显示 Kubernetes 驱动程序将使用 YAML 格式的 Kubernetes 对象文件作为 CNF 定义在预安装的集群上实例化 CNF。VNFD 不包含任何资源信息，例如 VDU、连接点、虚拟链路，因为 CNF 的所有必需组件都将指定在 Kubernetes 对象文件中。VNFD 将仅用于标识 CNF 的风味。
示例 VNFD 文件
tosca_definitions_version: tosca_simple_yaml_1_2
description: Deployment flavour for Kubernetes Cluster with
"pre_installed" flavour ID
imports:
- etsi_nfv_sol001_common_types.yaml
- etsi_nfv_sol001_vnfd_types.yaml
topology_template:
inputs:
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: pre_installed
node_templates:
VNF:
type: Company.Tacker.Kubernetes
properties:
flavour_description: The pre_installed flavour
示例 Kubernetes 对象文件
注意
作为 CNF 定义文件的 Kubernetes 对象文件可以包含 Kubernetes 资源种类支持 部分中提到的 Kubernetes 对象的定义。示例包含 Deployment 的定义。
apiVersion: apps/v1
kind: Deployment
metadata:
name: curry-test001
namespace: curryns
spec:
replicas: 2
selector:
matchLabels:
app: webserver
template:
metadata:
labels:
app: webserver
scaling_name: SP1
spec:
containers:
- env:
- name: param0
valueFrom:
configMapKeyRef:
key: param0
name: curry-test001
- name: param1
valueFrom:
configMapKeyRef:
key: param1
name: curry-test001
image: celebdor/kuryr-demo
imagePullPolicy: IfNotPresent
name: web-server
ports:
- containerPort: 8080
resources:
limits:
cpu: 500m
memory: 512M
requests:
cpu: 500m
memory: 512M
volumeMounts:
- name: curry-claim-volume
mountPath: /data
volumes:
- name: curry-claim-volume
persistentVolumeClaim:
claimName: curry-pv-claim
terminationGracePeriodSeconds: 0
注册 VIM¶
在 CNF 实例化之前，需要注册类型为 kubernetes 的 VIM。VIM 注册过程将保持不变。以下示例 vim-config.yaml 提供了注册 Kubernetes 类型 VIM 的必要信息。
auth_url: "https://172.20.20.10:6443"
username: "admin"
password: "admin"
project_name: "default"
ssl_ca_cert: None
type: "kubernetes"
此 VIM 可用于 CNF 的实例化请求。如果请求中未指定 VIM，则用户必须确保默认 VIM 的类型为 kubernetes。
CNF 实例化¶
以下是实例化请求的示例
{
"flavourId": "pre_installed",
"additionalParams": {
"lcm-kubernetes-def-files": [
"Files/kubernetes/sample1.yaml",
"Files/kubernetes/sample2.yaml"
]
},
"vimConnectionInfo": [
{
"id": "8a3adb69-0784-43c7-833e-aab0b6ab4470",
"vimId": "7dc3c839-bf15-45ac-8dff-fc5b95c2940e",
"vimType": "kubernetes"
}
]
}
Kubernetes 驱动程序需要进行更改，以引入一种从 CSAR 包提供的工件中加载 CNF 定义的额外方法。这些工件将是一个或多个 YAML 文件。此类 Kubernetes 对象 YAML 工件文件的列表将在实例化请求的 additionalParams 中的 lcm-kubernetes-def-files 参数中提供。Kubernetes 驱动程序的 create() 方法将查找此参数并加载 Kubernetes 对象。规范 add-artifact-support-for-vnf-package 引入的表 vnf_artifacts 将用于验证工件。列表中指定的文件顺序需要保持，因为这些文件中指定的对象可能存在依赖关系。
以下序列图描述了涉及的组件和 CNF 实例化的流程
create()方法将获取实例化请求和 VNF 包路径作为参数。它将查找 additionalParams 中的lcm-kubernetes-def-files以决定从哪里获取 Kubernetes 对象文件。本规范侧重于存在此参数的情况。下一个序列图显示了
create()方法的详细信息。TODO：根据讨论，已决定不会将有关容器、pod 等资源的信息存储在
vnfc_resource_info中，因为很难将此类对象直接映射到现有的 vnfc_resource_info 结构。此决定的含义是，当用户查询 VNF 实例时，此类资源的信息将不会显示。目前仍在讨论决定在哪里存储有关 CNF 创建的资源的信息。
以下序列图显示了 Kubernetes 基础设施驱动程序中 create() 方法的运行方式
从 Kubernetes 对象 YAML 文件中提取的定义将被转换为 Kubernetes 模型对象 [1]。将添加 KubernetesUtils 模块进行转换。
Kubernetes 模型对象将传递给 Kubernetes 客户端 API [2] 以部署对象。Kubernetes 客户端的 API 将根据对象的
kind调用。考虑到它们的依赖关系，对象部署的顺序将很重要。参考 Kubernetes API 组支持部署对象的的信息将用于准备部署名称。部署名称将作为 instance_id 返回，以保持与 VNF LCM API 的兼容性。
以下图表显示了 CNF 将如何部署
+-----------+ +------------------+
| | |Kubernetes object |
| VNFD | |YAML file |
| | | |
+--------+--+ +---+--------------+
| |
| |
|<-------+
|
+---------+ +--v--------+ +-----------+ +------------+ +----------+ +----------+
|Command/ | | VNFM |No | Parse k8s | | Kubernetes | |Kubernetes| |Kubernetes|
|REST Api +---->| +---->| object +---->| Object +---->|Python +---->| |
| | |Is CNF def | | YAML files| ^ | | |Client | | |
+---------+ |VNFD Based?| +-----------+ | +------------+ +----------+ +----------+
+--+--------+ |
| +-----------+ |
|Yes | Parse | |
+----->| TOSCA CNF +----------+
| definition|
| from VNFD |
+-----------+
This case is out
of scope of this
spec
实例化过程将通过命令或 REST API 调用调用。
VNFM 将根据实例化请求中的 additionalParams 处理 VNFD 和 Kubernetes 对象文件。
VNFD 将仅包含风味定义。
将从 Kubernetes 对象 YAML 文件中提供的定义创建 Kubernetes 模型对象 [1]。
kubernetes-client 将在 Kubernetes 集群上实例化对象。
CNF 终止¶
以下序列图显示了 CNF 终止的流程。
Kubernetes 驱动程序的当前实现处理有限的对象，例如 Service、Deployment、HorizontalPodAutoscaler 等。由于本规范引入了 Kubernetes 资源种类支持 中提到的更多对象，因此 delete() API 的实现需要删除这些对象。
Kubernetes API 组支持¶
当前的 Kubernetes 基础设施驱动程序支持以下 API 组
AutoscalingV1Api
CoreApi
CoreV1Api
ExtensionsV1beta1Api
本规范建议添加对以下 API 组的支持
AppsV1Api
ApiregistrationV1Api
AuthenticationV1Api
AuthorizationV1Api
BatchV1Api
CoordinationV1Api
NetworkingV1Api
RbacAuthorizationV1Api
SchedulingV1Api
StorageV1Api
Kubernetes 资源种类支持¶
在本规范中，我们将支持 Kubernetes v1.16.0 和 Kubernetes python 客户端 v11.0。将支持以下 Kubernetes API。
API 组
core(CoreV1Api)API
版本
Container
v1
Pod
v1
Service
v1
ConfigMap
v1
Secret
v1
PersistentVolumeClaim
v1
Volume
v1
LimitRange
v1
PodTemplate
v1
Bindings
v1
ComponentStatus
v1
Namespace
v1
Node
v1
PersistentVolume
v1
ResourceQuota
v1
ServiceAccount
v1
API 组
apiregistration.k8s.io(ApiregistrationV1Api)API
版本
APIService
v1
API 组
apps(AppsV1Api)API
版本
DaemonSet
v1
Deployment
v1
ReplicaSet
v1
StatefulSet
v1
ControllerRevision
v1
API 组
authentication.k8s.io(AuthenticationV1Api)API
版本
TokenReview
v1
API 组
authorization.k8s.io(AuthorizationV1Api)API
版本
LocalSubjectAccessReview
v1
SelfSubjectAccessReview
v1
SelfSubjectRulesReview
v1
SubjectAccessReview
v1
API 组
autoscaling(AutoscalingV1Api)API
版本
HorizontalPodAutoscaler
v1
API 组
batch(BatchV1Api)API
版本
Job
v1
API 组
coordination.k8s.io(CoordinationV1Api)API
版本
Lease
v1
API 组
networking.k8s.io(NetworkingV1Api)API
版本
NetworkPolicy
v1
API 组
rbac.authorization.k8s.io(RbacAuthorizationV1Api)API
版本
ClusterRole
v1
ClusterRoleBinding
v1
角色
v1
RoleBinding
v1
API 组
scheduling.k8s.io(SchedulingV1Api)API
版本
PriorityClass
v1
API 组
storage.k8s.io(StorageV1Api)API
版本
StorageClass
v1
VolumeAttachment
v1
数据模型影响¶
表名：vnf_instantiated_info
列名 |
旧数据类型 |
新数据类型 |
|---|---|---|
instance_id |
VARCHAR(255) |
TEXT |
Kubernetes 驱动程序返回的实例 ID 将是一个包含部署名称的字符串。它可以超过 255 个字符。因此，我们建议将 vnf_instantiated_info 表的 instance_id 字段的数据类型从 VARCHAR(255) 更改为 TEXT。
表名：vnf_resources
列名 |
旧数据类型 |
新数据类型 |
|---|---|---|
resource_name |
VARCHAR(255) |
TEXT |
REST API 影响¶
无
安全影响¶
无
通知影响¶
无
其他最终用户影响¶
无
性能影响¶
无
其他部署者影响¶
无
开发人员影响¶
无
实现¶
负责人¶
- 主要负责人
- 其他贡献者
Nitin Uikey <nitin.uikey@nttdata.com>
Tushar Patil <tushar.vitthal.patil@gmail.com>
Prashant Bhole <prashant.bhole@nttdata.com>
工作项¶
Kubernetes 基础设施驱动程序将被修改为实现
VNF LCM 兼容性
从工件提供的定义中实例化 CNF
支持其他 Kubernetes 对象
添加新的单元和功能测试。
依赖项¶
无
测试¶
将添加单元和功能测试，以涵盖规范所需的用例。
TODO：由于假设 Kubernetes 集群将预先安装，门禁作业需要获取有关现有集群的信息并创建 kubernetes VIM。
文档影响¶
将添加完整的用户指南，以解释从 VNF LCM API 的角度来看 CNF 实例化和终止。
