支持 Kubernetes 自定义资源用于 Cluster API Provider OpenStack

本规范描述了 Tacker 中 Kubernetes infra-driver 的增强，以支持将 Kubernetes 自定义资源 (CR) 作为 CNF 的 LCM 操作，以 Kubernetes Cluster API (CAPI) [1] 作为 CR 的示例。本文档的范围包括 CAPI 的 CR 的实例化、终止、扩展和更新，包括 CR 的 CNF。

https://blueprints.launchpad.net/tacker/+spec/support-k8s-cr

问题描述

Tacker 仅允许特定类型（又称 kind）的 Kubernetes 资源和 CR，目前尚未包含用户定义的符合 Kubernetes API 的 kind。然而，CR 已经被广泛用于指示 Kubernetes 管理的不仅仅是容器。例如，CAPI 允许用户通过定义一些 CR（例如 Cluster、Machine 等）来将 Kubernetes 集群作为 Kubernetes 资源进行管理，这些 CR 对应于构成 Kubernetes 集群的组件。通过支持 CAPI CR，Tacker 可以使用 Kubernetes infra-driver 创建 Kubernetes 集群，这比 Tacker 现有的管理驱动程序用于类似用例 [3], [4] 更加简单。

如上所述，Tacker 中受支持的有限资源可能会妨碍更好的实现。从这个意义上说，在 Kubernetes infra-driver 中添加用于处理 CR 的基本类和实用程序，有助于其他开发人员在未来扩展受支持的 CR，例如使用来自容器的 GPU 的一些先决条件（例如驱动程序、设备插件等）[2]。

提议的变更

本规范建议支持 CAPI 的 CR，包括增强 Kubernetes infra-driver 以处理 CR 的 LCM 操作。CAPI 是一组 CR，旨在为集群创建、配置和管理带来声明式、Kubernetes 风格的 API。以由 CR 组成的 CNF 的示例 CAPI，创建基本的实用程序和类，以便将来添加更多 CR。

为了实现这一点，必须实现以下项目。

• 包括 CR 的 CNF 实例化（以 Cluster API 为例）

• 包括 CR 的 CNF 终止（以 Cluster API 为例）

• 包括 CR 的 CNF 扩展（以 Cluster API 为例）

• 包括 CR 的 CNF 更新（以 Cluster API 为例）

• 带有 CAPI CR 清单的示例 VNF（即 CNF）包

• 更新用户文档

Kubernetes 自定义资源

自定义资源是 Kubernetes API 的扩展。此功能允许用户定义新的资源类型，超越 Kubernetes 的内置资源，例如 Pod、Service 和 Deployment。安装自定义资源后，用户可以使用 Kubernetes API 创建和访问其对象，就像他们对内置资源一样。

一些流行的项目自定义资源的示例包括

• Cluster API：Cluster、MachineDeployment、MachineSet、Machine 等

• Istio：VirtualService、DestinationRule 和 Gateway。

• Prometheus：ServiceMonitor

• Elasticsearch：Elasticsearch

• Kubernetes Operators：Kubernetes Operators 是一种在 Kubernetes 上自动化复杂应用程序部署和管理的方法。示例包括 Nvidia GPU operator、PostgreSQL operator 和 MongoDB operator。

通常，要使用自定义资源，用户必须将 CR 定义 (CRD) 和 CR 控制器安装到 Kubernetes 集群。

Cluster API

我们选择 CAPI 作为 Tacker 支持的第一个 CR，因为 Tacker 已经涵盖了类似的用例。Tacker 已经支持使用管理驱动程序部署 Kubernetes 集群。CAPI 允许用户通过定义一些 CR（例如 Cluster、Machine 等）来将 Kubernetes 集群作为 Kubernetes 资源进行管理，这些 CR 对应于构成 Kubernetes 集群的组件。因此，通过支持 CAPI CR，我们可以使用 Kubernetes infra-driver 创建 Kubernetes 集群。

CAPI 的特点如下

1. 管理集群和工作负载集群

   CAPI 本身也是 Kubernetes 资源，必须部署在集群上。因此，在使用 CAPI 时，有两种类型的集群：安装 CAPI 的集群和由 CAPI 创建的集群。在 CAPI 中，前者称为管理集群，后者称为工作负载集群。

2. 提供程序

   CAPI 由许多称为 Providers 的 CR 及其控制器组成。其中，基础设施提供程序尤其独特。有许多提供程序，每个提供程序都支持不同的云平台。例如，CAPI Provider OpenStack (CAPO) 用于在 OpenStack 上构建 Kubernetes 集群。基础设施提供程序的作用是为 Kubernetes 集群准备节点（在大多数情况下，创建 VM）并在这些节点上安装/配置 Kubernetes 组件（例如 etcd、kube-api server）。

下图显示了 CAPI 操作的概述。

官方支持的提供程序（即云平台）[5] 是

• AWS

• Azure

• Azure Stack HCI

• BYOH

• CloudStack

• CoxEdge

• DigitalOcean

• Equinix Metal (formerly Packet)

• GCP

• Hetzner

• IBM Cloud

• KubeKey

• KubeVirt

• MAAS

• Metal3

• Microvm

• Nested

• Nutanix

• OCI

• OpenStack

• Outscale

• Sidero

• Tinkerbell

• vcluster

• Virtink

• VMware Cloud Director

• vSphere

其中，我们选择 OpenStack（即 CAPO）作为第一步。这仅仅是因为它更容易测试并且与管理驱动程序支持的先前用例相匹配。

用于 CAPI 的 Kubernetes Infra-driver 增强

在本节中，我们描述了 Kubernetes Infra-driver 的增强，以使用 CAPI 创建 Kubernetes 集群。如上一节所述，我们需要创建两种 Kubernetes 集群：i) 管理集群和 ii) 工作负载集群。我们首先解释创建这两个 Kubernetes 集群的步骤，然后我们还描述了工作负载集群的扩展和更改当前 VNF 包操作。

创建管理集群

下图显示了使用支持 CAPI CR 的 Kubernetes infra-driver 创建管理集群的概述。由于 CAPI 本身由 Kubernetes 资源组成，因此创建管理集群可以与实例化 CNF 相同的操作。

1. 请求创建 CNF

   用户请求使用包含 CAPI CRD 的 VNF 包创建 CNF。

2. 请求实例化 VNF

   用户请求使用实例化参数实例化 VNF。

3. 调用 Kubernetes API

   Kubernetes infra-driver 调用 Kubernetes API 以创建一组 CAPI CR 作为 CNF。

4. 创建一组 CAPI 的 CR

   Kubernetes Control Plane 根据 VNF 包的内容创建一组 CR。

在 CR 成功部署后，CAPI 在 Kubernetes VIM 上可用（即 Kubernetes VIM 成为管理集群）。

创建工作负载集群

下图显示了使用支持 CAPO CR 的 Kubernetes infra-driver 创建工作负载集群的概述。由于 CAPI 将 Kubernetes 集群定义为 Kubernetes 资源，因此创建工作负载集群可以与实例化 CNF 相同的操作。

1. 请求创建 VNF

   用户请求使用包含 CAPI CRD 的 VNF 包创建 VNF。

2. 请求实例化 VNF

   用户请求使用实例化参数实例化 VNF。

3. 调用 Kubernetes API

   Kubernetes infra-driver 调用 Kubernetes API 以创建一组 CAPI CR 作为 CNF。

4. 创建 Cluster 资源

   Kubernetes Control Plane 创建 Cluster 资源。通常，还会创建几个子资源，这些子资源在图中被省略了。

5. 创建工作负载集群

   CAPI 根据 VNF 包的内容创建工作负载集群。

6. 执行管理驱动程序

   vnflcm 驱动程序执行 VNF 包中包含的管理驱动程序。

7. 获取工作负载集群的凭据

   管理驱动程序获取工作负载集群的凭据，这些凭据由 CAPI 自动存储为管理集群上的 Secret。

8. 发送凭据

   管理驱动程序根据预配置的 URL 将获取的凭据发送到 Web 服务器。Web 服务器必须由用户管理以接收凭据。

注意

为了将工作负载集群用作 VIM，用户必须使用管理驱动程序发送的凭据注册 VIM。

扩展工作负载集群

下图显示了使用支持 CAPO CR 的 Kubernetes infra-driver 扩展工作负载集群的概述。

1. 请求扩展 VNF

   用户请求扩展 VNF

2. 调用 Kubernetes API

   Kubernetes infra-driver 调用 Kubernetes API 以更改表示工作负载集群中 worker 节点数量的参数，该参数必须是 replicas。

3. 更改 worker 节点数量的参数

   Kubernetes Control Plane 中的 CAPI 根据 API 调用更改 worker 节点数量的参数。

4. 更改 worker 节点数量

   CAPI 根据 Cluster 资源更改 worker 节点数量。

更新工作负载集群

下图显示了使用支持 CAPO CR 的 Kubernetes infra-driver 更新工作负载集群的概述。与其他 Kubernetes 资源类似，CAPI 的 CR（例如 Cluster）可以通过应用更新的清单来更新。此操作可以通过 Tacker 中的更改当前 VNF 包来覆盖。

1. 请求更新 VNF

   用户请求更改当前的 VNF 包

2. 调用 Kubernetes API

   Kubernetes infra-driver 调用 Kubernetes API 以覆盖 Cluster 资源。

3. 更改 worker 节点数量的参数

   Kubernetes Control Plane 中的 CAPI 根据 API 调用更改 Cluster 资源。

4. 更改 worker 节点数量

   CAPI 根据 Cluster 资源更改 worker 节点。

备选方案

无。

数据模型影响

无。

REST API 影响

无。

安全影响

无。

但是，我们必须小心管理创建的工作负载集群的凭据。CAPI 将这些凭据存储为管理集群的 Secret。因此，除非管理集群的安全性受到破坏，否则凭据是安全的。此类安全管理不在 Tacker 的范围内。

通知影响

无。

其他最终用户影响

无。

性能影响

无。

其他部署者影响

• 使用此功能的部署者可能需要创建一个服务器来接收工作负载集群的凭据，并且可能需要创建脚本来将这些凭据注册为 VIM。

• 使用此功能的部署者可能需要准备包含适当 CAPI CR 和集群定义的 VNF 包。

开发人员影响

• VNF 包开发人员需要包含管理驱动程序以获取工作负载集群的凭据或替代脚本来执行相同的操作。

• VNF 包开发人员可能需要根据 CAPI 的更新来更新包。

• VNF 包开发人员可能需要修复由 CAPI 引起的包中的错误。

• Tacker 开发人员可能需要修复由 CAPI 引起的 Kubernetes infra-driver 中的错误。

• 开发人员需要小心更改 Tacker 的组件，尤其是在他们希望支持 Kubernetes infra-driver 中的其他 CR 时，以便它符合本文档的实施情况。

实现

负责人

主要负责人

• Reina Yoshitani <yoshitanir@intellilink.co.jp>

其他贡献者

• Shun Higuchi <higuchis@intellilink.co.jp>

• Hiromu Asahina (hiromu) <hiromu.asahina@ntt.com> <hiromu.a5a@gmail.com>

工作项

• 包括 CR 的 CNF 实例化（以 Cluster API 为例）

• 包括 CR 的 CNF 终止（以 Cluster API 为例）

• 包括 CR 的 CNF 扩展（以 Cluster API 为例）

• 包括 CR 的 CNF 更新（以 Cluster API 为例）

• 带有 CAPI CR 清单的示例 VNF（即 CNF）包

• 更新用户文档

依赖项

• Kubernetes v1.25.0 或更高版本

测试

我们可以通过添加 CR 的测试用例来增强 Kubernetes VIM 的现有功能测试。这些 CR 不一定必须是 CAPI，因为本文档的主要范围是支持 CR。

文档影响

需要解释增强的 Kubernetes infra-driver 的用例。

参考资料

[1]

https://cluster-api.sigs.k8s.io/

[2]

https://docs.nvda.net.cn/datacenter/cloud-native/gpu-operator/getting-started.html#install-nvidia-gpu-operator

[3]

https://docs.openstack.org/tacker/latest/user/mgmt_driver_deploy_k8s_usage_guide.html

[4]

https://docs.openstack.org/tacker/latest/user/mgmt_driver_deploy_k8s_kubespary_usage_guide.html

[5]

https://cluster-api.sigs.k8s.io/reference/providers.html