想象一下，你的任务是从头开始构建整个私有云基础设施。你的预算有限，带领一个小而专的团队，而且被要求创造奇迹。
几年前，你会构建一个基础设施，包含在虚拟机中运行的应用程序，以及一些用于遗留应用程序的裸机。随着基础设施的发展，虚拟机（VM）可以实现更高的效率和灵活性，但仅靠虚拟机并不能完全满足敏捷的应用程序部署方法的需求。它们继续作为运行许多应用程序的基础，但越来越多的开发人员正在寻求容器的新兴趋势，以进行前沿的应用程序开发和部署——因为容器提供了更高的灵活性和效率。
Docker和Kubernetes等容器技术正在成为构建容器化应用的领先标准。它们帮助组织消除了限制开发灵活性的复杂性。容器、容器基础设施和容器部署技术已被证明是非常强大的抽象，可应用于许多不同的用例。使用Kubernetes等技术，组织可以提供仅使用容器进行应用程序交付的云。
但是，领先的私有云不仅仅是容器，容器也不适合所有工作负载和用例。如今，大多数私有云基础设施都需要包含用于管理基础设施的裸机、用于遗留应用程序的虚拟机以及用于新应用程序的容器。支持、管理和协调这三种方法的能力是运营效率的关键所在。
OpenStack是目前构建私有云的最佳选择，具有管理网络、存储和计算基础设施的能力，支持来自一个控制平面的虚拟机、裸机和容器。虽然Kubernetes可以说是最受欢迎的容器编排器并且已经改变了应用程序的交付，但它取决于是否有可靠的云基础设施，而OpenStack为托管应用程序提供了最全面的开源基础设施。OpenStack的多租户云基础设施非常适合Kubernetes，拥有多个集成点、部署解决方案和跨多个云联合的能力。
在本文中，我们将探讨容器如何在OpenStack中工作，检查各种用例，并提供OpenStack等开源项目的概述——这有助于使容器成为易于采用和利用的技术。
I. OpenStack中容器的高级视图
容器和OpenStack的交汇有三种主要场景。
第一种场景称为基础设施容器，允许运维人员以改进云基础设施部署、管理和运维的方式利用容器。在此场景中，容器在裸机基础设施上设置，并允许对主机资源进行特权访问。此访问权限允许它们直接利用容器运行时通常试图不让用户感知的计算、网络和存储资源。容器隔离了每个应用程序所依赖的复杂依赖关系，同时仍允许基础设施应用程序直接管理和操作底层系统资源。当需要升级服务时，可以在不改变依赖关系的情况下处理升级，从而不破坏共址服务。
新版本的OpenStack已经采用了这种基础设施容器模型，现在通过组合编排工具和容器化服务来管理OpenStack部署的整个生命周期是正常的。基础设施容器使运维人员能够使用容器编排技术来解决许多问题，尤其是在快速迭代/升级现有软件（包括OpenStack）的过程中。在容器内运行OpenStack有助于运维人员解决Day 2的挑战，包括为服务添加新组件、快速升级软件版本以及跨机器和数据中心快速滚动更新。这种方法将容器的敏捷性好处带给了OpenStack的部署和升级。
第二种场景涉及在云基础设施上托管容器化应用程序框架。包括像Docker Swarm和Kubernetes这样的Container Orchestration Engines（COE），或者更轻量级的容器专用服务和无服务器API。无论是在裸机还是虚拟机上，OpenStack社区都致力于确保在安全、租户隔离的云主机上提供容器化应用程序。驱动程序推动了这种场景，这些驱动程序允许像Kubernetes这样的项目直接利用OpenStack API进行存储、负载均衡和身份识别。它还包括用于按需配置托管Kubernetes集群和应用程序容器的API。借助这些功能，开发团队可以编写新的容器化应用程序，并在OpenStack云上快速配置Kubernetes集群。它是一个完整的应用程序生命周期解决方案，提供开发、测试和调试代码所需的资源，并具有强大的自动化功能，可将应用程序部署到生产环境中。
在最后一种场景中，我们考虑了独立OpenStack和COE部署之间的交互，而本文特别考虑了Kubernetes集群。跨OpenStack和Kubernetes集群的API的一致性和互操作性是此方案成功的主要原因。例如，Kubernetes可以直接连接到OpenStack Cinder托管卷，使用OpenStack Keystone作为授权和身份验证后端，或者连接到OpenStack Neutron作为OpenStack Kuryr的网络覆盖。相反，OpenStack云可能与Kubernetes集群共享相同的网络覆盖，其中包含用于Calico等项目的Neutron驱动程序。第三种场景不太关注如何托管云服务（无论是Kubernetes还是OpenStack），而是更关注独立服务如何交互。
II . 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服务套件结合使用时，它为管理整个裸机基础设施提供了强大的类似云的服务。
这提出了一个问题：引导OpenStack服务如何管理裸机基础设施？典型的解决方案是使用上一节中描述的基于容器的安装工具创建种子安装。这种种子通常被称为“undercloud”，可用于完全自动化裸机集群的管理，就像它是虚拟化云一样。
这不仅可以在裸机云上运行OpenStack虚拟化，还可以运行裸机Kubernetes安装，从而利用OpenStack服务提供的身份、存储、网络和其他云API。 。
在OpenStack上提供基于容器的应用程序
基础设施容器和裸机基础设施很重要，但当大多数人想到容器时，他们会想到应用容器。容器提供的隔离、包装和易维护性使其成为交付应用的理想解决方案。但是，无论是裸机、公有云还是私有云，容器仍然需要主机平台来提供服务。
Kubernetes是一个提供最适合云API的应用程序的平台，可以自动交付关键基础设施，如永久存储、负载均衡器、网络和计算节点的动态分配。OpenStack提供云基础设施，可以是本地私有云，也可以是任何公有或托管的OpenStack云。
OpenStack是Kubernetes的第一个上游云提供商之一，拥有一个活跃的开发团队，负责维护“Kubernetes / Cloud Provider OpenStack”插件。该插件允许Kubernetes利用Cinder块存储、Neutron和Octavia负载均衡器，并使用Nova直接管理计算资源。使用provider就像将驱动程序部署到Kubernetes安装，设置标志以加载驱动程序并提供本地用户云凭证一样简单。
有许多解决方案可以在OpenStack上安装Kubernetes和其他应用程序框架。提供容器框架的最简单方法之一是使用Magnum——这是一个OpenStack项目，提供一个简单的API来部署完全托管的集群（有多个应用程序平台可以，包括Kubernetes）。这是Kubernetes部署系统的一个例子，它依赖于OpenStack API和云提供程序插件。例如，现在它被用于在CERN的OpenStack现场云以及合作伙伴云上，管理200多个独立和联合的Kubernetes安装。如果你在首选的OpenStack云中没有可用的Magnum API，则可以使用任何其他Kubernetes安装工具（如kubeadm、Kubernetes Anywhere、Cross-Cloud或Kubespray）在OpenStack上安装和管理Kubernetes集群。由于每个都使用标准Kubernetes，因此很容易使云provider接口能够利用存储和负载均衡。
另一个OpenStack项目Zun提供了一个轻量级的容器服务API，用于管理单个容器，而无需管理服务器或集群。OpenStack托管的Kubernetes集群具有弹性，因为可以通过Nova API直接向集群添加或删除云资源来动态调整大小。或者，Kubernetes可以作为OpenStack Zun的容器后端，将pod基础设施的管理权转交给Zun。它为运行容器提供了轻量级和多租户容器服务API，无需直接创建服务器。与Neutron和Cinder的直接集成用于为各个容器提供网络和卷。
最后，Qinling项目提供“功能即服务”，旨在提供支持无服务器功能的平台，类似于Lambda、Azure Functions和Google Cloud Functions。它进一步抽象了容器的管理，并允许用户通过按需扩展的事件驱动、无服务器计算体验来加速开发。Qinling支持不同的容器编排后端（如Kubernetes和Docker swarm）、各种流行的功能包存储后端（如本地存储和OpenStack Swift）。
原文链接：
https://www.openstack.org/containers/leveraging-containers-and-openstack/
获取更多开源云技术资讯&大咖交流&免费活动，欢迎添加开源云中文社区小助手，备注开源云！
