Kubernetes CNI 插件之Fabric

CNI（Container Networking Interface）是容器运行时和网络实现之间的接口。它允许不同的项目，如 Tungsten Fabric，提供 CNI 插件的实现，并使用它们来管理 Kubernetes 集群中的网络。在这篇博文中，您将学习如何使用 Tungsten Fabric 作为 Kubernetes CNI 插件来确保容器和裸机之间的网络连接。您还将看到一个使用 TF CNI 插件将 Kubernetes 集群嵌套部署到 OpenStack VM 中的示例。

CNI 接口本身非常简单。它必须实现的最重要的操作是 ADD 和 DEL。顾名思义，ADD 的作用是将容器添加到网络中，而 DEL 的作用是将容器从网络中删除。就这样。但是这些功能执行了吗？ 

首先要做的事情：kubelet 是在集群中的每个节点上运行的 Kubernetes 守护程序。当用户创建一个新的 Pod 时，Kubernetes API 服务器会命令一个运行在该 Pod 被调度的节点上的 kubelet 来创建 Pod。然后 kubelet 将为 pod 创建一个网络命名空间，并通过运行所谓的“暂停”容器来分配它。该容器的作用之一是维护网络命名空间，该命名空间将在 pod 中的所有容器之间共享。这就是为什么 pod 内的容器可以使用环回接口相互“对话”的原因。然后，对于 pod 中定义的每个容器，kubelet 都会调用 CNI 插件。 

但是它怎么知道如何使用每个插件呢？首先，它在预定义的目录（ 默认为 /etc/cni/net.d ）中查找 CNI 配置文件。当使用 Tungsten Fabric 时，kubelet 会找到这样的文件：

{
    "cniVersion": "0.3.1",
    "contrail" : {
        "cluster-name"  : "<CLUSTER-NAME>",
        "meta-plugin"   : "<CNI-META-PLUGIN>",
        "vrouter-ip"    : "<VROUTER-IP>",
        "vrouter-port"  : <VROUTER-PORT>,
        "config-dir"    : "/var/lib/contrail/ports/vm",
        "poll-timeout"  : <POLL-TIMEOUT>,
        "poll-retries"  : <POLL-RETRIES>,
        "log-file"      : "/var/log/contrail/cni/opencontrail.log",
        "log-level"     : "<LOG-LEVEL>"
    },
    "name": "contrail-k8s-cni",
    "type": "contrail-k8s-cni"
  }

该文件和其他参数一起指定了 CNI 插件的名称和 vRouter 代理的 IP (vrouter-ip) 和端口 (vrouter-port)。通过查看这个文件，kubelet 知道它应该使用名为“contrail-k8s-cni”的 CNI 插件二进制文件。它在预定义的目录（ 默认为 /opt/cni/bin ）中查找它，当它想要创建一个新容器时，使用通过环境变量传递的命令 ADD 以及其他参数（例如：pod 网络的路径）执行它命名空间、容器 ID 和容器网络接口名称。Contrail-k8s-cni 二进制文件（您可以 在此处找到其源代码）将读取这些参数并向 vRouter 代理发送适当的请求。

 图 1. 使用 Kubernetes 进行 Tungsten Fabric 计算 

vRouter Agent 的工作是为容器创建实际的接口。但是它怎么知道如何配置一个接口呢？正如您在上图中所见，它从 Tungsten Fabric Control 获取所有这些信息。那么，Tungsten Fabric Control 是如何知道所有 pod、它们的命名空间等的呢？这就是 Tungsten Fabric Kube Manager（您可以 在此处找到它的源代码）的用武之地。它是一项单独的服务，与其他 Tungsten Fabric SDN 控制器组件一起启动。可以在下图的左下角看到。

Kubemanager 的作用是监听 Kubernetes API 服务器事件，例如：pod 创建、命名空间创建、服务创建、删除。它监听这些事件，处理它们，然后在 Tungsten Fabric Config API 中创建、修改或删除适当的对象。然后，Tungsten Fabric Control 将找到这些对象并将有关它们的信息提供给 vRouter 代理。然后 vRouter 代理最终可以为容器创建正确配置的接口。这就是 Tungsten Fabric 可以作为 Kubernetes CNI 插件工作的方式。

由于 Tungsten Fabric 和 Kubernetes 是集成的，基于容器的工作负载可以与虚拟机或裸机服务器工作负载相结合。此外，这些环境之间的连接规则都可以在一个地方进行管理。

Tungsten Fabric 嵌套部署

从网络的角度来看，虚拟机和容器对于 Tungsten Fabric 来说几乎是一回事，因此将它们结合起来的部署是可能的。此外，除了 Kubernetes，Tungsten Fabric 还可以与 OpenStack 集成。多亏了这一点，这两个平台可以结合起来。假设我们已经使用 Tungsten Fabric 部署了 OpenStack，但我们想使用容器部署一些工作负载。使用 Tungsten Fabric，我们可以创建所谓的嵌套部署——OpenStack 计算虚拟机，其上部署了 Kubernetes 集群，Tungsten Fabric 作为 CNI 插件。 

不需要部署所有 Tungsten 组件，因为它们中的大多数已经在运行并控制 OpenStack 网络。但是，在嵌套 Kubernetes 集群中的一个节点上，最好是 Kubernetes 主节点，我们必须启动 Tungsten Fabric Kube Manager（如上所述）。它将连接到嵌套集群中的 Kubernetes API 服务器和使用 OpenStack 部署的 Tungsten Fabric Config Api 服务器。 

最后，Tungsten Fabric CNI 插件及其配置文件必须存在于每个嵌套的 Kubernetes 计算节点上。请注意，Tungsten Fabric vRouter 和 vRouter Agent 都不需要部署在嵌套的 Kubernetes 节点上，因为这些组件已经在 OpenStack 计算节点上运行，并且 Tungsten Fabric CNI 插件可以直接向它们发送请求。

图 3. OpenStack 上的 Kubernetes 与 Tungsten Fabric 网络 （放大） 

        与 Tungsten Fabric 集成的 Kubernetes 集群的嵌套部署是开始部署基于容器的工作负载的一种简单方法，特别是对于一直使用 OpenStack 管理其虚拟机的企业而言。网络管理员可以使用他们的 Tungsten Fabric 专业知识，而不必掌握新的工具和概念。

翻译链接：Tungsten Fabric as a Kubernetes CNI plugin - Tungsten Fabric