几年前，你可以构建一个在虚拟机中运行应用程序的基础设施，其中一些裸机用于传统应用程序。随着基础设施的发展，虚拟机（VM）实现了更高水平的效率和敏捷性，但单靠虚拟机并不能完全满足敏捷应用部署的需求。它们继续作为运行许多应用程序的基础，但越来越多的开发人员关注容器的发展趋势，以更好地开发和部署应用程序——因为容器提供了更高级别的敏捷性和效率。
像Docker和Kubernetes这样的容器技术正在成为构建容器化应用程序的主要标准。它们帮助企业摆脱了限制开发敏捷性的复杂性。容器、容器基础设施和容器部署技术已经被证明是非常强大的抽象，可以应用于许多不同的用例。通过使用Kubernetes等技术，企业可以交付一个仅使用容器交付应用程序的云。
但是领先的私有云不仅仅是容器，容器并不适合所有的工作负载和用例。现在，大多数私有云基础设施都需要包含用于管理基础设施的裸机、用于传统应用程序的虚拟机以及用于较新应用程序的容器。支持、管理和协调这三种方法的能力是运营效率的关键。
OpenStack目前是构建私有云的最佳选择，它能够管理网络、存储和计算基础设施，支持来自一个控制平面的虚拟机、裸机和容器。虽然Kubernetes可以说是最受欢迎的容器编排器，并且已经改变了应用程序交付的方式，但它取决于可靠的云基础设施的可用性，而OpenStack为托管应用程序提供了最全面的开源基础设施。OpenStack的多租户云基础设施非常适合Kubernetes，拥有多个集成点、部署解决方案以及跨多个云联合的能力。
在本文中，我们将探讨容器如何在OpenStack中工作，查看各种用例，并提供让容器成为易于采用和使用的技术的OpenStack等开源项目的概述。
OpenStack中容器的总体视图
容器和OpenStack的交汇有三个主要场景。
第一个场景称为基础设施容器，允许运维者使用容器来改善云基础设施的部署、管理和运维。在这种情况下，容器设置在裸机基础设施上，并允许对主机资源进行特权访问。这种访问使它们能够直接利用计算、网络和存储资源，容器运行时通常不为用户所见。这些容器隔离了每个应用程序所依赖的复杂的依赖关系集，同时允许基础设施应用程序直接管理和操作底层系统资源。当要升级服务时，可以在不改变依赖关系的情况下处理升级。
新版本的OpenStack已经接受了这种基础设施容器模型，现在通常使用编排工具和容器化服务的组合来管理OpenStack部署的整个生命周期。基础设施容器使运维者能够使用容器编排技术来解决许多问题，特别是快速迭代/升级现有软件（包括OpenStack）。在容器中运行OpenStack有助于解决时间要求较高的挑战，包括为服务添加新组件，快速升级软件版本以及跨机器和数据中心快速滚动更新。这种方法将容器的敏捷性带入了OpenStack的部署和升级。
第二个场景是关于在云基础设施上托管容器化的应用程序框架。这可以包括Docker Swarm和Kubernetes等容器编排引擎（COE），或者更轻量级的容器专用服务和无服务器应用程序编程接口（API）。无论是在裸机还是虚拟机上，OpenStack社区都致力于确保可以在安全的、租户隔离的云主机上交付容器化应用程序。驱动程序促进了这种场景，这些驱动程序允许像Kubernetes这样的项目直接利用OpenStack API进行存储、负载均衡和身份识别。它还包括用于按需提供托管Kubernetes集群和应用程序容器的API。借助这些功能，开发团队可以编写新的容器化应用程序，并在OpenStack云中快速提供Kubernetes集群。这是一个完整的应用程序生命周期解决方案，提供开发、测试和调试代码所需的资源，并通过强大的自动化功能将应用程序部署到生产环境中。
在最后一个场景中，我们考虑了独立OpenStack和COE部署之间的交互，在本文特指Kubernetes集群。跨OpenStack和Kubernetes集群的API的一致性和互操作性是此场景成功的关键。例如，Kubernetes可以直接连接到OpenStack Cinder托管卷，使用OpenStack Keystone作为授权和身份验证后端，或者作为网络覆盖连接到OpenStack Neutron。反过来，OpenStack云可能与Neutron驱动共享相同的网络覆盖。第三种场景不太关注云服务的托管方式（无论是Kubernetes还是OpenStack），而是更多地关注独立的服务如何交互。
OpenStack容器集成点
在容器上部署OpenStack基础设施
正如介绍中指出的那样，随着容器的崛起，OpenStack的部署和管理发生了显着变化，因为容器带来了管理基础设施代码的新方法。以前的管理策略需要创建和维护重量级的“黄金”机器镜像，或者使用脆弱的状态维护配置管理系统。每种方法都有其复杂性和限制。进一步增加难度的是管理一系列服务，这些服务都需要各自的依赖关系，而这些依赖关系在每个发布中都会变化。如果没有某种形式的应用程序隔离，解决依赖关系变得很困难。
基础设施容器使新的OpenStack部署项目能够在两者之间取得平衡，同时很好地解决了依赖性问题。使用轻量级、独立、自包含且通常为无状态的应用程序容器，云运维者在部署复杂的控制平面时可获得极大的灵活性。结合容器运行时和编排引擎，基础设施容器使得快速部署、维护和升级复杂且高度可用的基础设施成为可能。
在构建OpenStack集群时，选择部署技术要考虑多个维度。运维者可以为其基本容器选择Linux Containers（LXC）或Docker，使用预先构建的或定制的应用程序容器，并选择用于编排的传统配置管理系统或像Kubernetes这样的更现代的方法。表1总结了现有的OpenStack部署项目及其基础技术。
在这些部署系统之下，是为OpenStack代码和支持服务构建一组容器的不同方法。OpenStack Ansible（OSA）和Kolla项目提供了自己的项目托管构建系统，而LOCI则侧重于构建项目应用程序容器，不考虑特定的编排系统。在高层面上，它们之间的差异是：
- OSA的独特之处在于它依赖于较低层次的LXC容器，并且具有用于创建LXC应用程序容器的自定义构建系统。
- Kolla构建系统生成Docker容器（每个服务都有一个容器），还有支持初始化和管理OpenStack部署的容器。Kolla容器具有高度可配置性，可选择基本操作系统、源或软件包安装，以及用于进一步定制的模板引擎。
- 构建OpenStack应用程序容器的最终选择是LOCI。LOCI也构建Docker容器，为每个项目提供一个容器。LOCI专注于快速生产紧凑和安全的容器，并期望它们被部署系统用为基础。
裸机基础设施——OpenStack和解决Bootstrap问题
每个云的基础中，都有一个承载基础设施服务的裸机服务器数据中心。即使是“无服务器计算”，也在数据中心硬件上的云上运行软件。如何引导硬件基础设施的问题是OpenStack软件有独特资格来解决的一个关键问题，它可以提供类似于云的裸机管理质量。
OpenStack Ironic提供裸机即服务。作为独立服务，它可以发现裸机节点，在管理数据库中对其进行编目，并管理整个服务器生命周期（包括注册、提供、维护和退役）。当用作OpenStack Nova的驱动程序并结合全套OpenStack服务时，它可以提供强大的类似云的服务来管理整个裸机基础设施。
这引出了一个问题：一个bootstrap OpenStack服务如何管理裸机基础设施？一个典型的解决方案是使用与前面章节中所述相同的基于容器的安装工具来创建种子安装。这个通常被称为“undercloud”的种子可以用来完全自动化裸机集群的管理，就好像它是一个虚拟化的云。
这带来了机会，不仅可以在裸机云上运行OpenStack虚拟化，而且还可以运行裸机Kubernetes安装（可以通过OpenStack服务充分利用身份、存储、网络和其他可用的云API）。
在OpenStack上交付基于容器的应用程序
基础设施容器和裸机基础设施都很重要，但是当大多数人想到容器时，他们想到的是应用程序容器。容器提供的隔离、封装和易维护性使其成为交付应用程序的理想解决方案。但是，容器仍然需要一个主机平台来为它们提供服务，无论是裸机、公有云还是私有云。
Kubernetes是一个交付应用程序的平台，可以与云API一起使用，从而实现关键基础设施的自动交付（如永久存储、负载均衡器、网络和动态分配计算节点）。OpenStack提供云基础设施，无论是作为本地私有云还是通过任何可用的公有或托管OpenStack云。
OpenStack是Kubernetes的首批上游云提供商之一，其活跃的开发团队维护着“Kubernetes / Cloud Provider OpenStack”插件。这个插件允许Kubernetes利用Cinder块存储、Neutron和Octavia Load Balancers，以及使用Nova直接管理计算资源。使用非常简单，只需将驱动程序部署到Kubernetes安装中，设置一个标志来加载驱动程序，并提供本地用户云凭证。
在OpenStack上安装Kubernetes和其他应用程序框架有许多解决方案。提供容器框架的最简单方法之一是使用Magnum——这是一个OpenStack项目，它提供了一个简单的API来部署完全受管理的、有多个应用程序平台（包括Kubernetes）选择的集群。这是一个依赖于OpenStack API和云提供商插件的Kubernetes部署系统的例子。例如，现在它被用在CERN的OpenStack现场云以及合作伙伴云上管理超过200个独立和联合的Kubernetes安装。如果你在首选OpenStack云中没有可用的Magnum API，你可以使用任何其他Kubernetes安装工具（例如kubeadm、Kubernetes Anywhere、Cross-Cloud或Kubespray）在OpenStack上安装和管理Kubernetes集群。因为每个用户都使用标准的Kubernetes，所以很容易启用云提供商接口来利用存储和负载均衡。
另一个OpenStack项目Zun提供了一个轻量级的容器服务API，用于管理单个容器，而无需管理服务器或集群。OpenStack托管的Kubernetes集群具有弹性，因为它可以直接通过Nova API向集群添加或删除云资源来动态调整大小。另外，Kubernetes可以作为OpenStack Zun的容器后端，将pod基础设施的管理转交给Zun。它提供了一个更轻量级和多租户容器服务API，用于运行容器而无需直接创建服务器。与Neutron和Cinder的直接集成被用于为单个容器提供网络和卷。
最后，Qinling项目提供了“Function as a Service”，旨在提供一个支持无服务器功能的平台，类似于Lambda、Azure Functions或Google Cloud Functions。它进一步抽象了容器的管理，允许用户通过事件驱动的、无需服务器的计算体验来加速开发（这种体验可按需伸缩）。Qinling支持不同的容器编排后端（如Kubernetes和Docker swarm）、各种流行的功能包存储后端（如本地存储和OpenStack Swift）。
Kata Containers——通过虚拟化保证应用安全
Kata Containers是一个新的开源项目。它是一个轻量级虚拟机的新颖实现，可无缝集成到容器生态系统中。Kata Containers与容器一样轻而快，并与容器管理层（包括Docker和Kubernetes等常用编排工具）集成，同时还提供了虚拟机的安全优势。Kata Containers符合开放容器倡议（OCI）标准——OpenStack基金会是其中的一个活跃成员。Kata Containers由OpenStack基金会托管，但它是OpenStack项目之外的独立项目，拥有自己的治理和社区。
转向容器带来了独特挑战，即在多租户环境中保护用户工作负载（有可信任和不可信任的工作负载）。Kata Containers使用硬件支持的隔离作为每个容器或pod中容器集合的边界。这种方法解决了传统容器架构中共享内核的安全问题。
Kata Containers非常适合基于事件的按需部署（如持续集成/持续交付）和更长时间运行的Web服务器应用程序。Kata还简化了从传统虚拟化环境向容器的过渡，因为它支持传统访客内核和设备通过功能。Kata Containers提供增强的安全性、可扩展性和更高的资源利用率，同时带来堆栈的整体简化。
并行的OpenStack和Kubernetes集成
选择开源平台的一个主要优势在于，跨平台标准部署的接口的稳定性。OpenStack基金会和CNCF都在为OpenStack云和Kubernetes集群维护互操作标准，确保库、应用程序和驱动程序可以在所有平台上运行，而不用管它们在哪里部署。这为并行集成创造了机会，允许OpenStack和Kubernetes利用彼此的资源。
Kubernetes社区中的OpenStack特别兴趣小组（SIG-OpenStack）维护Cloud Provider OpenStack插件。除了在OpenStack上运行Kubernetes的云提供商接口外，它还保留了几个驱动程序，允许Kubernetes利用单个OpenStack服务。这些驱动程序包括：
- 两个独立的Cinder驱动程序。Flex Volume驱动程序使用基于exec的模型与驱动程序进行交互，为容器编排系统使用标准接口的Container Storage Interface（CSI）驱动程序将任意存储系统暴露给其容器工作负载。通过支持70多种存储驱动程序，这些驱动程序可以通过一个Cinder API与大量经过测试的专有和开源存储设备连接。
- 基于webhook的Keystone认证和授权接口。每个模式、认证和授权，都可以彼此独立配置。虽然这项工作还在进行中，但该接口支持软多租户（使用OpenStack Keystone支持Kubernetes RBAC）。
OpenStack和Kubernetes都支持由多种驱动程序支持的高度动态网络模型。由于有这些标准网络接口，可以轻松构建具有强大网络集成的独立OpenStack和Kubernetes集群。在OpenStack中，Kuryr项目生成了一个Common Network Interface（CNI）驱动程序，可将Neutron网络提供给Docker和Kubernetes。另一方面，像Calico这样的项目提供Neutron驱动程序，通过标准的Neutron API提供对Kubernetes网络覆盖的直接访问。
