在生产环境中的OpenStack上运行Kubernetes集群

Posted 2021-04-02 开源云中文社区

Kubernetes为开放混合云提供动力

开发人员专注于创建和改进软件。为了帮助他们取得成功，Kubernetes集群可以提供正确的工具和接口，而不管基础设施是内部的还是公共云。

运行Kubernetes的基础设施可以分为4类：裸金属主机、传统虚拟化环境中的虚拟机、私有云基础设施、公共云基础设施。

正确地支持开发人员和他们的应用程序需要在这些基础设施上提供一致的用户体验。

在本文中，我们将重点讨论私有云基础设施，特别是OpenStack。

为什么在OpenStack上使用Kubernetes

像Kubernetes这样的容器平台是工作负载驱动的，底层基础设施不应该扮演很小的角色，因为正在运行和开发的应用程序是主要的焦点。

Kubernetes和OpenStack深度集成。这种集成是多年来在两个平台上开发的结果，其中计算、存储和网络资源由Kubernetes集群从OpenStack使用。

由于Kubernetes使用API来使用这些资源，OpenStack使得集成变得一致和可预测。OpenStack，本身是跨数据中心这些资源的抽象层，它允许用户以一致的方式使用计算、存储和网络资源，Kubernetes是其中一个。

OpenStack是为数据中心的大规模而设计的，它允许运行在OpenStack上的Kubernetes集群根据需要进行扩展。

集成点

如上所述，OpenShift和OpenStack之间的三个主要集成点是计算、存储和网络。这些资源中的每一个都是通过API通过集成点使用的，如下所示：

如你所见，我们甚至可以在OpenStack管理的裸金属节点上部署Kubernetes集群，就像管理OpenStack虚拟实例一样。

其中一些集成点优化了在Kubernetes上运行的容器应用程序的性能。例如，Kuryr是一个专门为与OpenStack集成而设计的Kubernetes容器网络接口。我们已经看到，使用Kuryr作为CNI时，网络性能提高了9倍。

架构

当涉及到使用OpenStack和Kubernetes设计私有云时，你需要做出许多决策。红帽定义了一个参考架构。

战略与愿景

红帽有大量OpenStack用户正在运行Kubernetes或正在利用容器化应用程序开发策略。为了继续支持这些用户，红帽致力于以不同的方式不断改进这种集成。用户体验是一个重要的方面。红帽希望让尽可能多的用户能够在OpenStack集群上使用Kubernetes。OpenShift安装程序能够动态创建集群所需的所有OpenStack资源，它在提供易于安装和使用的Kubernetes集群方面发挥了关键作用。这方面的改进包括解决新的用例和简化安装工作流程。

另一个重要领域是使用OpenStack提供的裸金属机节点部署Kubernetes集群的能力。为Kubernetes使用裸金属是一个非常流行的选择。

最后，我们看到了OpenStack在电信行业的巨大发展势头，它带来了新的用例，比如运行Kubernetes的无线接入网应用程序（RAN）和边缘计算。

OpenStack上Kubernetes的网络部署选项

在OpenStack上部署Kubernetes有两个主要接口的网络CNI/插件选项，以避免双重封装（覆盖）：Kuryr CNI和Neutron租户网络、Kubernetes SDN和Neutron Provider Networks。

multus CNI上的Openshift 4.x二级接口通常使用Neutron Provider网络来实现到pods的直接L2网络。

与Kuryr CNI一起部署

在使用Kuryr CNI时，OpenStack为Kubernetes pods实现了网络策略和负载均衡服务。Kuryr CNI与Neutron API通信以建立安全组和Octavia负载均衡器。

Kuryr CNI支持ML2/OVS或ML2/OVN Neutron插件，通过使用OpenStack自助服务租户网络和OpenStack租户网络来避免覆盖的双重封装。Kuryr CNI使用VLAN中继来标记/取消标记传入和传出的Kubernetes pod流量。

带有ML2/OVN的Kuryr具有多个管理和性能优势：

——东西交通采用OVN Geneve覆盖分布式路由，无需通过中央网关路由器。

——南北交通与默认分布式虚拟路由（DVR）使用浮动IP（分布式NAT）。无需集中式Neutron路由器。

——通过使用OVN ACLs有状态和无状态防火墙的OpenStack安全组的网络策略（即将推出）。

——基于Octavia-OVN驱动的东西分布式负载均衡。

Neutron Provider Networks部署

某些情况下，企业数据中心有特殊要求，如：

——不支持VXLAN或Geneve等覆盖网络。

——出于安全原因，不支持带有NAT的浮动IP。

——所有流量都需要通过外部防火墙或VPN服务（如F5）才能转发。

——为了裸金属部署或性能要求，外部流量不应通过Neutron网关路由器。

——将L2网络直接连接到pod以实现更快的外部连接。

在这些情况下，目标是直接连接到外部网络并使用物理基础设施来路由流量。OpenStack Neutron Provider Networks提供对管理的外部网络的访问。

现在有了Kubernetes对bring your own external connectivity的支持，OpenStack Neutron Provider Networks可以用来连接到管理的外部网络：

——不再需要带有NAT的浮动IP。

——因为双重封装不再是问题，没有必要使用Kuryr。

——OpenStack Neutron仍然可以为安全组提供网络策略，但大多数其他服务，包括路由和负载均衡，都将由Kubernetes提供。

——Kubernetes还添加了创建自己的外部负载均衡器的选项，以支持F5、OpenStack Octavia或Kubernetes Ingress等外部负载均衡器。

在上面的例子中，podA可以通过Kubernetes租户网络管理的覆盖层与podC通信，但是通过VLAN 101提供商网络（11.1.1.0/24）路由，外部机架顶部（ToR）路由器作为默认网关（11.1.1.1）。

存在一些限制，Kubernetes In tree Cloud Provider for OpenStack使用Terraform，这使得很难使用需要启用管理权限和元数据服务的Provider Networks。随着Kubernetes转向OpenStack的out-of-tree云提供商，这些限制将被克服。

Kubernetes得益于OpenStack安全性和负载均衡服务的改进

在下面的主题中，我们将讨论OpenStack服务中的关键改进，这些改进对Kubernetes用例是有益的。

Octavia OVN驱动的负载均衡

当使用ML2/OVN插件在pods（东西负载均衡器）之间使用Kuryr CNI部署Kubernetes服务时，此选项可用。OVN负载均衡器不仅降低了Amphora VM的CPU资源开销，而且避免了网络延迟，因为OVN负载均衡器在节点本身是可用的。

在下面的示例中，Web Service app1 podA需要通过Octavia负载均衡器服务连接到podB上的DB服务app2。第一种选择是通过Octavia Amphora驱动程序，该驱动程序需要为每个租户生成Amphora VM，并且流量需要遍历额外的跃点，这会增加网络延迟并消耗额外的CPU资源。第二个选项使用OVN负载均衡，每个节点本身都可以使用OVS连接跟踪。

但是Octavia OVN Provider Driver有一些限制，例如：

——它只支持L4（TCP/UDP）负载均衡（没有L7 HTTP负载均衡功能）。

——不支持运行状况监控。

使用OVN ACL（安全组）的多层应用程序提高性能

在Kubernetes中，pod是短暂的。随着pod的不断添加和删除，OpenStack OVN逻辑交换机（网络）和端口也随之添加和删除。Kubernetes网络策略，作为OpenStack安全组翻译成OVN ACL，需要不断更新。因此，存在恒定的计算开销，CPU总是忙于处理中心OVN数据库和工作节点上的逻辑规则或OVN ACL。

在处理OVN ACL时，OVN添加了几个关键功能，以提高CPU效率并将中央节点和工作节点的延迟减少50%以上：

——OVN增量处理跟踪规则更改，只有受影响的节点需要重新计算规则。

在本例中，租户X的多层应用程序的web服务器不能直接连接到后端数据库（DB）服务器，但必须首先通过业务应用程序（BA）逻辑。

outport == @pg_DB-uuid && ip4 && ip4.src == $pg_BA-uuid_ip4

电信用例，特别是5G

5G正在推动云原生网络功能，这意味着在4G环境下，迄今为止实现的虚拟机网络功能现在有望在裸金属上作为容器运行。然而，并不是所有的网络功能都将被容器化。现有的4G VNF不计划采用容器化。在这种情况下，运行4G和5G的选择是什么，是不是意味着由OpenStack编排的虚拟机和由Kubernetes编排的容器？

一个可能的答案是有两个相互连接的集群：一个OpenStack和一个Kubernetes，但是，这不允许在同一集群上混合虚拟机和容器。例如，使用Kubevirt也可以在Kubernetes之上运行虚拟机，但是对于通过OpenStack API编排的现有虚拟机，编排层需要通过Kubernetes Operator重新实现。最后，在OpenStack VMs中运行Kubernetes为Kubernetes集群及其编排的容器提供了私有云的所有好处——首先从底层硬件抽象Kubernetes，这是虚拟化最明显的好处。然后，容器和VMs之间的网络互连由Neutron负责，这是OpenStack的内置功能。这对于CNF开发非常方便，因为每个开发人员都可以获得自己的Kubernetes集群集，并在不需要访问专用物理服务器的情况下试验各种网络配置（大多数CNF开发人员必须与整个团队共享裸金属服务器）。最后，容器的数据平面性能与裸金属相同，我们在2019年丹佛开放基础设施峰会（Denver Open Infrastructure Summit）上现场演示了这一点：容器是不是比虚拟机更快值得商榷，但对于企业用例是可测量的，这一点在DPDK应用程序中从未出现过。由于使用了巨大的页，代码路径在裸金属和虚拟机上完全相同，因为巨大的页允许避免TLB丢失。由于DPDK应用程序不使用中断，因此在数据包的代码路径上没有超调用（中断在VMs中实现为超调用）。

电信应用程序是在一组输入和输出接口之间处理数据包的“网络功能”。在裸金属上运行时，这些应用程序访问网卡或网卡虚拟功能（SR-IOV VFs）。电信应用程序可以按照OpenStack虚拟机中的设计运行，因为虚拟机公开半虚拟化网卡（OVS-DPDK端口），或者允许访问裸金属网卡或KVM公开的网卡虚拟功能。在所有情况下，网卡都是VM中的PCI设备，这个PCI设备对应于一个Neutron端口。

在上面的例子中，Kubernetes集群需要连接到3个网络：需要将Kubernetes集群连接到3个不同的Neutron网络，并且需要在每个网络上连接多个pod。

以下是我们的工作流程：

启动一个OpenStack VM，根据需要使用多个Neutron端口来连接3个网络上的所有pod：将使用一个用overlay的管理接口，每个pod一个Neutron端口用于FRONTHAUL和MIDHAUL网络。每个Neutron端口都作为PCI设备在VM中，因此我们“只”需要为这些PCI设备配置适当的CNI（管理接口上的主CNI，以及所有其他设备的SR-IOV设备插件）。

此解决方案允许将任何Neutron端口号与任何中子端口类型关联到pod：它可以是OVS-ML2或OVN-ML2端口，基于OVS TC Flower硬件卸载，或OVS-DPDK，它可以是SR-IOV，也可以是任何SDN插件Neutron端口。

Neutron网络和Kubernetes CRs之间的映射是通过解析虚拟机元数据来实现的，通常可以通过nova config drive获得。

结论

OpenStack在成为Kubernetes工作负载的健壮和稳定平台方面取得了长足的进步，它为裸金属节点、虚拟机和容器应用程序提供了共享的基础设施和服务。我们现在有了几个用例的部署参考架构，包括示例、可定制的选项、建议和限制。

OpenStack上的Kubernetes提供了基于需求的灵活部署选择：

——具有大量东西流量的企业用例可以使用Kuryr CNI部署（具有改进的租户网络性能和高效的OpenStack负载均衡和网络策略）。

——电信/NFV用例（主要是南北流量）可以使用OpenStack provider networks，SR-IOV、OVS-DPDK的快速数据路径选项，硬件卸载选项（SmartNICs和FPGAs）部署具有裸金属性能的Kubernetes pods。

原文链接：

https://superuser.openstack.org/articles/run-your-kubernetes-cluster-on-openstack-in-production/