将 Kubernetes 类型的容器化 VNF 添加到 Tacker

问题描述

Kubernetes [1] 是云原生计算基金会的一部分，是一个容器编排项目。由于容器使用操作系统虚拟化而不是硬件虚拟化，因此基于容器的 VNF 比基于 VM 的 VNF 更轻量级。 在此规范中，我们建议支持使用 Kubernetes 类型作为容器的网络功能，这些功能将在 Kubernetes VIM 上部署。

提议的变更

Tacker 架构，使用 OpenStack 和 Kubernetes 作为 VIM

+--------------------------------------------------------------------+
|                                                                    |
|                            Tacker NFVO                             |
|                                                                    |
|                                                                    |
+---------------------------------+----------------------------------+
                                  |
+---------------------------------v----------------------------------+
|VNFM                                                                |
|        +---------------+                  +---------------+        |
|        |  Kubernetes   |                  |     Heat      |        |
|        | infra driver  |                  | infra driver  |        |
|        +------+--------+                  +--------+------+        |
|               |                                    |               |
+--------------------------------------------------------------------+
                |                                    |
+---------------v--------------+       +-------------v---------------+
|                              |       |                             |
|          Kubernetes VIM      |       |       OpenStack VIM         |
|                              |       |                             |
+------------------------------+       +-----------------------------+

+--------------------------------------------------------------------+
|                     Neutron network & kuryr-kubernetes             |
+--------------------------------------------------------------------+

在此计划中，我们将引入 VNFM 中的 Kubernetes 基础设施驱动程序，该驱动程序将用于管理 Kubernetes VIM 中的 c-VNF。 Kubernetes 基础设施驱动程序通过 Kubernetes python 客户端使用 Kubernetes API 来创建 Kubernetes 资源，如 Service、Deployment、ConfigMap、Horizontal Pod Autoscaling，这些资源将用作 C-VNF。 Kuryr-Kubernetes 也用于连接基于 VM 和基于容器的 VNF。

引入 TOSCA 到 Kubernetes 转换器

                               +-------------------+
                               |                   |
                        +------>   TOSCA Parser    |
                        |      |                   |
                        |      |                   |               +-------------------+
+-------------------+   |      +-------------------+        +------>    K8s service    |
|                   |   |                                   |      |      template     |
|       TOSCA       +---+                                   |      +-------------------+
|    VNF template   |   |                                   |
|                   |   |      +-------------------+        |
+-------------------+   |      |    TOSCA to K8S   |        |      +-------------------+
                        +------>     translator    +--------------->   K8s deployment  |
                               |      (Phase 1)    |        |      |     template      |
                               |                   |        |      +-------------------+
                               +----------+--------+        |
                                          |                 |
                                          |                 |      +-------------------+
                                          |                 +------>   K8s Configmap   |
                               +----------v--------+        |      |      template     |
                               |                   |        |      +-------------------+
                               |  Heat Traslator   |        |
                               | (Phase 2 - Future)|        |
                               |                   |        |      +-------------------+
                               +-------------------+        +------>    Horizon Pod    |
                                                                   |    Autoscaling    |
                                                                   +-------------------+

Tacker 将实现 TOSCA 到 K8S 转换器，以帮助从 TOSCA NFV 模板转换为 K8S 模板。 转换器的优点是统一的 VNF 模板，使用一种模板（TOSCA 模板），我们可以将其部署到多个环境。

我们计划分两个阶段进行转换器的工作

1. 阶段 1，TOSCA 到 K8S 转换器将首先应用于 Tacker。

2. 阶段 2，如果可能，Tacker 将“TOSCA 到 K8S”移动到 Heat Translator

TOSCA 到 K8S 转换器使用了 Kompose 项目的想法（https://github.com/kubernetes/kompose）

主要有两个部分

1. 加载器

用户可以在 tacker/vnfm/infra_drivers/kubernetes/k8s 的“translate_input.py”中找到 Loader 函数。 首先，Tacker 将 TOSCA VNF 模板加载到内存 TOSCA 对象中。 之后，将内存 TOSCA 对象映射到“ToscaKubeObject”对象。

2. 转换器

此函数在 tacker/vnfm/infra_drivers/kubernetes/k8s 的“translate_output.py”中描述。 translate_output.py 将 ToscaKubeObjects 转换为 Kubernetes 对象（目前，我们仅支持转换为 Deployment、Service、Horizon Pod Autoscaling - HPA 和 ConfigMap）。

                       +------------------+
                       |TOSCA NFV template|
                       +------------------+
                                |
                                |  TOSCA Parser
                                |
                   +------------v-------------+
                   |      In-memory TOSCA     |
Loader             |          object          |
                   +--------------------------+
                                |
                                |
                                |
                   +------------v--------------+
                   |      ToscaKubeObject      |
                   |                           |
                   +---------------------------+
                                |
+------------------------------------------------------------+
                                |
                                |
                   +------------v--------------+
                   |  ConfigMap, Deployment,   |
Tranformer         |    Service, HPA           |
                   +---------------------------+
                                |
+------------------------------------------------------------+
                                |
                                |
                   +------------v--------------+
Outputter          |      output objects       |
                   |                           |
                   +---------------------------+

目前 Kubernetes 不支持多个网络，CP 和 VL 在转换为实际实体时未提及。 在实现中，我们将网络名称作为 Kubernetes 中 Service 对象的标签添加，例如：{“network_name”: “net_mgmt”}

1. ToscaKubeObject 的定义

ToscaKubeObject 包含 VDU 的基本结构。 它用于将 TOSCA 转换为 Kubernetes 模板，例如 Service、Deployment、Horizon Pod Autoscaling、ConfigMap。 我们选择 Deployment 以支持手动扩展/缩减并保证 Pod 的数量。 Service 帮助平衡 Deployment 中副本的流量。

class ToscaKubeObject(object):
  def __init__(self, name=None, namespace=None, mapping_ports=None,
               containers=None, network_name=None,
               mgmt_connection_point=False, scaling_object=None,
               service_type=None, labels=None):
    self._name = name
    self._namespace = namespace
    self._mapping_ports = mapping_ports
    self._containers = containers
    self._network_name = network_name
    self._mgmt_connection_point = mgmt_connection_point
    self._scaling_object = scaling_object
    self._service_type = service_type
    self._labels = labels

Tacker 中 VDU 的示例

VDU1:
  type: tosca.nodes.nfv.VDU.Tacker
  properties:
    namespace: default
    mapping_ports:
      - "80:8080"
      - "443:443"
    labels:
      - "app: webserver"
    service_type: ClusterIP
    vnfcs:
      web_server:
        properties:
          num_cpus: 0.5
          mem_size: 512 MB
          image: celebdor/kuryr-demo
          ports:
            - "8080"
          config: |
            param0: key1
            param1: key2

Tacker 将 VDU 的属性映射到 ToscaKubeObject，主要用于定义 Service、Deployment 及其容器

• name: 设置为“svc-” + VDU 名称 + 随机 uuid，例如“svc-VDU1-2k531”。 Tacker 将使用此名称设置所有 Kubernetes 对象以进行管理。

• namespace: Kubernetes 的命名空间，Service、Deployment、HPA、ConfigMap 对象将在其中部署。

• mapping_ports: Service Kubernetes 的已发布端口和目标端口（容器端口）。

• containers: 它定义了 Pod 中的 Container 对象。 请参阅“2. VnfcConfigurableProperties 的定义”了解如何建模每个容器。

• labels: 为所有 Kubernetes 对象设置标签作为选择器。 如果未提供标签，则将 {‘selector’: ‘service-VDU1’} 用作默认值。

• service_type: 为 Service 对象设置服务类型，例如“service_type: ClusterIP”。 目前，Tacker 仅支持 ClusterIP 和 NodePort。

• scaling_object: 用于将扩展策略映射到 Horizontal Pod Autoscaling。 有关更多详细信息，请参阅“3. 扩展策略的定义”。

• network_name: VDU 的网络，对于纯 Kubernetes，当使用 Kuryr-Kubernetes 启用 neutron 网络时使用。

2. VnfcConfigurableProperties 的定义

VnfcConfigurableProperties 的每个实例代表一个 Container。 为了解析此类型，Tacker 添加了新的“VDU.tosca.datatypes.nfv.VnfcConfigurableProperties”数据类型。 在下面的示例中，我们将两个 Container 定义为 VnfcConfigurableProperties，即 front_end 和 backend。

VDU1:
  type: tosca.nodes.nfv.VDU.Tacker
  properties:
    namespace: default
    mapping_ports:
      - "80:80"
      - "88:88"
    labels:
      - "app: rss-site"
    vnfcs:
      front_end:
        properties:
          num_cpus: 0.5
          mem_size: 512 MB
          image: nginx
          ports:
            - "80"
      rss_reader:
        properties:
          num_cpus: 0.5
          mem_size: 512 MB
          image: nickchase/rss-php-nginx:v1
          ports:
            - "88"

为了建模它，我们定义了类 Container。 在转换为 Kubernetes 对象时，它被转换为 Kubernetes 中每个 Deployment 对象中的 Container 对象。 Container 包含 Pod 内部容器的基本结构。

class Container(object):
  def __init__(self, name=None, num_cpus=None, mem_size=None, image=None,
               command=None, args=None, ports=None, config=None):
    self._name = name
    self._num_cpus = num_cpus
    self._mem_size = mem_size
    self._image = image
    self._command = command
    self._args = args
    self._ports = ports
    self._config = config

Tacker 将 VnfcConfigurableProperties 的每个实例映射到 Pod Kubernetes 中的 Container 对象。

• name: 容器的名称，例如 front_end、rss_reader

• num_cpus: 为每个 Container 指定 CPU 资源（num_cpus 可以是整数或带有小数点的浮点数，例如 1,3,0.5,1.25，并且不允许精度小于 1m）

• mem_size: 指定内存（RAM）资源（例如 200 KiB、MiB、GiB、KB、MB、GB）

• image: 容器的镜像

• ports: 容器暴露的端口

• command: 例如 [‘/bin/sh’, ‘echo’]

• args: 例如 [‘hello’]

• config: 设置变量的值，例如

config: |
  param0: key1
  param1: key2

所有配置都将转换为 Kubernetes 中的 ConfigMap 对象。

3. 扩展策略的定义

Tacker 将扩展策略映射到 ScalingObject 类。 在转换为 Kubernetes 对象时，它描述为 Horizon Pod Autoscaling。 我们可以查看 ScalingObject 和扩展策略之间的映射关系如下。

class ScalingObject(object):
  def __init__(self, scaling_name=None, min_replicas=None, max_replicas=None,
               scale_target_name=None, target_cpu_utilization_percentage=None):
    self._scaling_name = scaling_name
    self._min_replicas = min_replicas
    self._max_replicas = max_replicas
    self._scale_target_name = scale_target_name
    self._target_cpu_utilization_percentage = target_cpu_utilization_percentage


policies:
  - SP1:
    type: tosca.policies.tacker.Scaling
    targets: [VDU1]
    properties:
      min_instances: 1
      max_instances: 3
      target_cpu_utilization_percentage: 40

将来，我们将升级到 ScalingV2 以支持比 CPU 利用率更多的警报指标。

4. Tacker 中的 C-VNF 模型

此 C-VNF 模型由上述三个部分组成。

                       VNF
                       +----------------------------------------------------------------------+
                       |                                                                      |
                       |           VDU2                                                       |
                       |           +---------------------------------------------------+      |
                       |      VDU1 |                                                   |      |
                       |      +-----------------------------------------------------+  |      |
                       |      |                                                     |  |      |
                       |      |                           +---------------------+   |  |      |
+---------------+      |      |    +---------------+     +--------------------+ |   |  |      |
|               |      |      |    |               |     |                    | |   |  |      |
|    Peer NF    +------+      |    |      K8S      +-----+    Deployment,     | |   |  |      |
|               |      |      |    |    Service    |     | HPA, ConfigMap, etc| |   |  |      |
+---------------+      |      |    |               |     |                    +-+   |  |      |
                       |      |    +---------------+     +--------------------+     +--+      |
                       |      |                                                     |         |
                       |      +-----------------------------------------------------+         |
                       |                                                                      |
                       |                                                                      |
                       +----------------------------------------------------------------------+

这张图片描述了 Kubernetes VIM 中的 C-VNF 模型 [2]。 在此图中，一个 VNF 包含两个 VDU：VDU1 和 VDU2（VNF 可以有多个 VDU）。 每个 VDU，我们将其映射到 Kubernetes 中的 Service、Deployment、Horizon Pod Autoscaling 和 ConfigMap 对象。 1 个 VDU 中的所有组件，都使用相同的名称（例如 svc-VDU1-24k41da）进行管理。

我们支持通过 Deployment 的扩展副本功能手动扩展 VDU，并通过 Horizon Pod Autoscaling 自动扩展。 Service 对象代表 Deployment 中的所有 Pod，其功能是将请求平衡到后端 Pod。

备选方案

数据模型影响

待定

REST API 影响

待定

安全影响

通知影响

其他最终用户影响

性能影响

其他部署者影响

开发人员影响

实现

主要负责人

Hoang Phuoc <phuoc.hc@dcn.ssu.ac.kr> Digambar Patil <digambarpat@gmail.com>

联合作者

Janki Chhatbar <jchhatba@redhat.com> Digambar Patil <digambarpat@gmail.com> Hyunsik Yang <yangun@dcn.ssu.ac.kr>

工作项

1. 在 Tacker 仓库中引入 K8s python 库

2. 实现转换器将 TOSCA 转换为 k8s 模板

3. 在 VNFM 中添加支持以管理容器化 VNF

依赖项

Kubenetes python 库

测试

是

文档影响

是的。 我们必须描述如何使用容器化 VNF

参考资料

[1]

https://kubernetes.ac.cn/

[2]

http://www.etsi.org/deliver/etsi_gs/NFV-SWA/001_099/001/01.01.01_60/gs_NFV-SWA001v010101p.pdf