本文由OpenStack基金会官方发布,来自基金会、用户、厂商的16位专家作者联合撰写,原文请访问:https://www.openstack.org/containers/whitepaper
想象一下,你的任务是从头开始构建整个私有云基础设施。预算有限 ,团队不大,被要求创造一个奇迹。
几年前,你可以构建一个在虚拟机中运行应用程序的基础设施,其中一些裸机用于传统应用程序。随着基础设施的发展,虚拟机(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网络覆盖的直接访问。
案例探究
OpenStack社区的许多成员正在为与容器相关的各种OpenStack项目贡献新代码,评估容器的含义和优势,以及在生产中使用容器来解决挑战和解锁新功能。本节重点介绍一些有意思的案例研究。
AT&T
AT&T是全球最大的电信公司之一,利用容器技术部署和管理OpenStack,依靠基础设施容器提高简单性和效率,目的是在容器化的OpenStack上构建5G基础设施。
为了实现目标,AT&T正在使用OpenStack-Helm项目在Kubernetes集群中编排基于LOCI的OpenStack镜像,同时也利用Kubernetes、Docker和核心OpenStack服务。他们还在使用Bandit、Tempest、Patrole和其他许多OpenStack项目。 AT&T还与社区合作推出一系列名为Airship的undercloud项目,该项目将提供从裸机到运行OpenStack工作负载的生产级Kubernetes的云。
AT&T发现容器化使自己能够将传统的部署类型活动转移到左侧,并使用CI / CD对其进行验证。Kubernetes还提供了大规模的可扩展性和弹性,以及允许OpenStack-Helm声明性地配置运维行为、注入配置并完成滚动升级和更新(而不影响租户工作负载)的钩子。
利用容器技术来部署和管理OpenStack不应该对租户产生太多明显的影响 ——除了它们将拥有更高弹性的平台,并且能够更频繁地获得云功能并且以最小的中断时间获得。AT&T运维团队将把他们的更多努力转向定义网站声明性配置,并让面向Kubernetes的自动化自行进行部署。
AT&T的目标是利用这种架构来支持虚拟网络功能。AT&T容器化网络云的初始用例将是新兴5G网络的VNF初始部署。OpenStack一直以来都非常适合AT&T聚焦于VNF的云用例。容器化只是一次演进,它允许AT&T以更可靠、快速、零接触的方式部署、管理和扩展其OpenStack基础设施。
在运维上,AT&T仍在测试这种方法,但已承诺在年底之前将5G服务投入生产。OpenStack和容器技术将成为这项服务的支柱,对于AT&T数百万用户而言,这一战略非常重要。部署5G服务将展示OpenStack和容器在大规模分布式生产环境中的相关性。
CERN
CERN让物理学家和工程师利用世界上最大、最复杂的科学仪器研究物质的基本成分——基本粒子而探索宇宙的基本结构。CERN云为物理学家提供科学计算的计算资源,分析来自大型强子对撞机和其他实验的数据。
CERN自2013年起开始在生产中运行OpenStack,现在正在为单个云中的虚拟机、裸机和容器提供服务。容器可以在虚拟机上运行,也可以裸机运行,具体取决于使用情况,它们全部通过OpenStack Magnum提供。可以选择不同的容器技术,包括Kubernetes、Docker Swarm和DC / OS。
CERN目前运行着在OpenStack之上的、通过Magnum提供的250个容器集群。
CERN的OpenStack云为用户提供自助服务访问,可以通过一些命令或通过Web GUI请求配置好的容器引擎。这允许用户快速利用这些技术,并且如果需要可以扩展到1000个节点。最佳实践配置包含在内置监控中,并集成在CERN存储和认证服务中。
要高效运行此资源池和无需额外运维人力即可对其进行伸缩,就需要采用一致的管理流程和工具。通过Magnum在OpenStack之上添加容器可以使服务能够使用之前开发的自动化,例如硬件修复过程和一致的授权模型,同时支持根据用户需求快速地重新分配资源。
CERN是一个公共资助的实验室,Kubernetes和OpenStack等开源解决方案提供了一个框架,让它可与其他组织合作并回馈社区。 CERN与许多供应商(如Rackspace和华为)通过CERN openlab框架合作,提供具有Magnum和联合等功能的大规模云。这些经验也通过OpenStack特别兴趣小组、Kubecon Europe等公开演讲和OpenStack in Production等博客共享。
在CERN,一些工作负载在Magnum提供的容器中运行,包括:
Reana /Recast。这些工具提供了执行高能物理中可重用工作流程的框架。容器能够将分析软件和数据打包在一个易于共享的单元中,并且易于扩展内部部署和使用外部资源。工作计划为基于Yadage Workflows(支持分析和数据保存活动)的Kubernetes作业。
Spark即服务。最近,Kubernetes被添加为Spark的资源管理器。Spark可以将驱动程序和执行程序作为pod生成,而Kubernetes负责调度和生命周期。 CERN IT部门的一个团队正在开发一项服务,让用户可以使用OpenStack Magnum按需创建Kubernetes集群,并在Kubernetes上部署Spark,以安全的方式提供与CERN专用文件系统和数据源的所有必需集成。使用很少的命令,用户可以有效地创建具有所需大小的Spark部署(仅在需要的时候),并且可以在运行的时候伸缩部署。
LHC实验检测器触发模拟LHC升级。LHC将在2020年左右进行亮度升级。CERN已经创建了大规模Kubernetes集群来模拟ATLAS实验的不同方法并验证设计,从而对Kubernetes和OpenStack组件进行了一些精细调整。
Gitlab Continuous Integration Runner。Gitlab使用户能够构建CI / CD作业并在共享或项目特定的runner上执行它们。CERN用户可以利用CERN容器服务来测试和构建软件,构建和发布容器镜像和文档,或设置管理整个应用生命周期的复杂管道,包括自动部署到不同的环境中。
联合Kubernetes和外部云。CERN使用联合的Kubernetes集群来支持多云操作。如Kubecon 2018所展示的,多个集群可跨使用不同技术的云无缝集成,包括AWS、GCE和OpenStack云(如CERN和T-Systems Open Telekom Cloud)。
将虚拟机、容器引擎和裸机集成到一个框架下,可以轻松查看使用情况记帐、所有权和配额。Kubernetes的Manila存储驱动程序允许透明地提供文件共享。 这既支持IT部门的容量规划,又支持实验资源协调员确定其工作组的优先级。 资源管理政策,例如工作人员离职时的重新分配或资源到期等,均采用一致的工作流程进行处理。
SK Telecom
韩国最大的电信运营商SK Telecom(SKT)一直在探索在Kubernetes上部署OpenStack的优化方法,目的是在2018年底之前将核心业务功能放到容器化OpenStack上。SKT利用Kolla和Openstack-Helm,部署由Kubespray自动完成。SKT将近100%的开发工作投入OpenStack-Helm,并与AT&T密切合作,以使OpenStack-Helm成功。
SKT还将其他工具整合到他们的OpenStack on Kubernetes工作中。对于日志记录、监控和报警,他们使用Prometheus和Elasticsearch、Fluent-bit和Kibana——这些都是OpenStack-Helm社区中的默认参考工具。SKT将所有这些整合成到一个称为TACO:SKT All Container OpenStack的单一封闭集成解决方案中。
SKT特别重视围绕Kubernetes上容器化的OpenStack的自动化持续集成/连续交付(CI / CD)管道。SKT的CI系统由Jenkins、Rally、Tempest、Docker Registry以及Jira和Bitbucket组成。SKT还开发了一个名为Cookiemonster的开源工具,这是一款弹性测试工具,用于Kubernetes部署,为CI管道执行弹性测试。
每次更改,SKT都会自动构建并测试OpenStack容器和Helm chart。每天,他们会自动安装具有三个控制节点和两个计算节点的高可用性OpenStack部署,从Tempest运行400个测试案例来验证服务,最后使用Cookiemonster和Rally运行弹性测试。完整的CI系统如下图所示:
SKT用Armada自动化部署——这是Airship的一个子项目,是由AT&T在社区中推出的新开放式基础设施项目。SKT正在与社区合作,根据其生产用途为项目提供增强功能。
在实际使用中,SKT已经看到了在Kubernetes上部署OpenStack的许多好处,包括:简单和容易的安装;集群自动修复;能够升级和更新OpenStack,而对正在运行的服务的影响最小;快速采用先进的发布;通过容器隔离完成对Python依赖关系的自动化管理;安全的秘密和配置管理;快速而灵活地推出集群更新。
SKT还在测试这种方法,但正在积极推进在生产环境中运行OpenStack-Helm部署。到今年年底,SKT将至少有三个生产集群,2019年将有第四个也是最大的集群群。这些用例包括:大数据平台(计划于2018年第四季度上线)、虚拟桌面基础设施平台(2018年第四季度生产就绪)、通用内部私有云(计划于2018年第三季度上线)、基于虚拟网络功能的电信网络基础设施(计划于2019年开放)。
SKT还试图通过使用容器化VNF并利用容器的自动修复和快速扩展功能来提高电信基础设施运维的自动化程度。为了允许基于虚拟机的VNF和容器化VNF进行交互,作为OpenStack虚拟网络解决方案的Simplified Overlay Network Architecture(SONA)将支持虚拟机和容器之间的通信。SONA使用Kuryr项目来集成OpenStack和Kubernetes,并使用软件定义的网络技术优化网络性能。
总的来说,SKT发现Kubernetes可以帮助解决部署和运维OpenStack的许多复杂问题。简化OpenStack为他们提供了强大的方法来为5G时代提供先进的基础设施创新。将重点放在Kubernetes上的Openstack,SKT显著提高了转向容器内微服务的能力,有望提供可以交付AI、物联网和机器学习的关键基础设施。
Superfluidity
Superfluidity项目由来自12个欧洲国家的18个合作伙伴组成。它旨在增强实时实例化服务的能力,在网络中的任何位置运行它们,并将它们透明地转移到不同的位置。SUPERFLUIDITY是一个Europoean Resaerch项目,试图通过利用和延伸众所周知的开源项目来构建5G网络的基础设施块。SUPERFLUIDITY将提供融合的基于云的5G概念,可实现移动边缘的创新用例,支持新业务模式,并降低投资和运营成本。
为了实现这些目标,项目联盟正在从传统的基于VM的应用程序转向云原生容器化的应用程序。Kuryr是OpenStack虚拟机、Kubernetes和OpenShift容器化服务之间的桥梁。
该项目利用ManageIQ(作为中央网络功能虚拟化编排器(NFVO)),用于应用程序部署和生命周期管理的Ansible,包括Heat、Neutron和Octavia在内的OpenStack服务,以及用于VM和容器集成的OpenShift Kubernetes。
通过利用从ManageIQ设备执行的Ansible playbook,SUPERFLUIDITY提供了部署应用程序的通用方法。这些应用程序反过来使用由OpenStack Heat模板和OpenShift模板提供的云编排功能。
该联盟在容器内部署5G云无线接入网络(CRAN)和移动边缘计算(MEC)组件。它还在分布式基础设施之上部署高吞吐量应用程序,如视频流。
应用交付向云原生方式的转变,允许我们快速和灵活地安装SUPERFLUIDITY。它可以实现从基于VM的应用程序和组件到容器的平稳过渡,并保持多用性,从而为某些特定应用程序启用VM。这些应用程序的例子有,单路输入/输出虚拟化(SRIOV)所需的特殊安全保护或网络加速。
在规模性能测试中,SUPERFLUIDITY能够以22个pod/秒的速度启动大约1000个pod(从创建到运行的时间)。在OpenStack管理的虚拟机上运行OpenShift(Kuryr扮演pod网络驱动程序的角色,以避免双重封装性能问题),可以实现这一卓越性能。
结论
在过去的几年中,随着容器成为开发人员和企业的重要工具,OpenStack已经利用其模块化设计和广阔的社区集成了许多层次的容器技术。 这表现在,各种机构和组织将容器和OpenStack投入生产,以及使用容器来交付新功能的项目数量增加。OpenStack基金会致力于确保新兴技术能够在OpenStack中得到整合和使用,而容器是这一承诺的重要例子。
要了解更多信息,请访问Containers Landing Page(https://www.openstack.org/containers/),你可以在其中找到本文档的副本以及几十个专注于OpenStack和容器集成的视频链接。Kubernetes SIG-OpenStack有Slack频道、邮件列表和每周会议,如果你直接参与构建Kubernetes和OpenStack集成的社区。
文章评论