超融合容器¶

日期:: 2017-09-01 22:00
标签:: 容器、超融合、性能

减少基础设施主机上的容器数量。

为了降低我们的部署时间和跨板资源消耗。本规范旨在移除那些在规模上对架构几乎没有好处的单一用途容器。

此更改将服务分组，从而减少容器数量。这不会混合服务类别，因此无需担心不同服务之间因未知软件包或未知工作负载而相互污染。我们只是希望最小化我们拥有的容器类型并简化操作。通过融合容器，我们减少了容器部署过程和服务的设置中至少 10 个步骤。从操作层面来看，我们减少了运营团队管理任何规模云的负担。

问题描述¶

当我们开始这个项目时，我们怀着最好的意图，为我们的系统布局和容器编排创建一种伪微服务模型。虽然这在今天有效，但它确实在资源利用方面创建了许多不必要的容器。

提议的变更¶

将env.d目录中找到的容器组尽可能地融合到一个容器中。我们完成这项工作所需的大部分更改已经提交。在某些情况下，我们需要“撤销更改”才能将本规范的核心功能引入主分支，但完成初始融合工作所需的开发工作很少。

完成融合工作后，我们计划开发一套 playbook，允许部署者运行一组“选择加入”的任务，这些任务将在必要时清理容器和服务。位于负载均衡器后面的服务需要更新。如果环境使用我们支持的软件 LB（HAProxy），则负载均衡器的更新将由提供的“选择加入”playbook覆盖。 “选择加入”playbook需要被编纂、测试和记录。如果决定将超融合工作 cherry-pick 到稳定分支，则新的 playbook 首先需要存在并在我们的定期 gate 中进行测试。我们预计 playbook 对常规部署者工作流程不会产生影响。

备选方案¶

我们可以保持一切不变，这会带来我们当前拥有的资源需求，并了解鉴于 OpenStack 服务（现有和新增）都在不断扩展，所需资源将会增长。

Playbook/Role 影响¶

至少会添加一个新 playbook，允许部署者清理运行时和清单中旧的容器类型（如果他们决定这样做）。清理 playbook 将是“选择加入”的，并且不会成为我们正常的自动化部署过程的一部分。

升级影响¶

此更改不会产生升级影响，因为任何现有的部署都已经具有清单中所有必需的关联。服务在此更改后将继续正常运行。另一方面，全新的部署将拥有更少的容器来管理，从而减少资源需求，同时确保我们保留今天拥有的主机、网络和进程隔离。

我们将创建一组 playbook 来清理升级后可能存在的某些冗余容器，但是执行此 playbook 将是“选择加入”的。

安全影响¶

在此规范中安全性不是问题，但是减少容器数量将减少我们已经拥有的潜在攻击面。

性能影响¶

超融合容器将减少物理主机上的资源消耗。减少运行 OpenStack 云所需的资源将提高 playbook 和整个系统的性能。

最终用户影响¶

N/A

部署者影响¶

部署者在长时间运行云时将拥有更少的容器来管理和关注。

在升级场景中，部署者可以选择“选择加入”超融合设置。默认情况下，此更改不会对正在运行的部署产生任何服务影响。

开发人员影响¶

N/A

依赖项¶

如果我们要测试“选择加入”清理 playbook，我们需要一个定期的升级 gate 作业。 playbook 将由升级 gate 作业执行，并将发布结果到 ML/channel，以便 OSA 开发团队收到失败通知。

实现¶

负责人¶

主要负责人: Kevin Carter (IRC: cloudnull) Major Hayden (IRC: mhayden)

工作项¶

将容器融合到更少的组中
创建“选择加入”容器减少 playbook
记录新的 playbook

测试¶

此补丁的核心功能将在每次提交时进行测试。
如果满足升级测试依赖项，我们可以在定期 gate 中创建一个代码路径并测试“选择加入”清理 playbook。

文档影响¶

将为创建的“选择加入”容器清理 playbook 创建文档。

参考资料¶

N/A

超融合容器