用于公共地址的虚拟IP¶
包含您的 Launchpad 蓝图的 URL
https://blueprints.launchpad.net/tripleo/+specs/tripleo-juno-virtual-public-ips
当前的公共IP功能旨在指定云可以被访问的端点。这通常是需要高可用性的场景。
将公共IP设为虚拟IP，而不是绑定到单个机器的本地地址，一旦我们将控制平面扩展到多台机器，应该可以提高集群服务的可用性。
问题描述¶
目前，我们所有的OpenStack服务都在一个虚拟IP上监听端口。
这意味着我们正在将RabbitMQ、MySQL以及可能其他仅用于集群内部的服务暴露给外部世界，而我们真正想要的是将公共服务暴露给外部世界，并且不暴露仅用于集群内部的服务器。部署者（有理由地）没有将我们的所有服务VIP暴露给外部世界，这导致他们必须在 a) 不支持外部可见端点、b) 所有服务都容易受到攻击或 c) 手动跟踪涉及的端口并随着我们的发展不断追赶之间做出选择。
提议的变更¶
从用户提供的网络创建一个第二个虚拟IP。将应该公开访问的API端点的附加副本绑定到该虚拟IP。我们仍然需要以内部方式呈现它们（仍然通过haproxy和控制虚拟IP），以便没有公共连接的服务器（例如hypervisor）仍然可以使用API（尽管它们可能需要在主机文件中覆盖IP地址 - 我们已经为此提供了设施）。
原则上，第二个虚拟IP可以位于专用的以太网卡上，也可以位于共享卡上的VLAN上。现在，让我们要求管理员指定keepalived应该在其上配置共享IP的接口 - 无论是 br-ctlplane、vlan25 还是 eth2。由于网络拓扑可能独立，keepalive quorum检查需要在指定的接口上进行，即使这会消耗外部IP地址。
用户必须能够指定与今天相同的基础云网络，以便不会使小型安装变得不可能 - 要求两个不同的网络对于小型组织来说可能很困难。使用相同的网络并不意味着使用相同的IP地址 - 专用的IP地址仍然有用，可以提供更好的测试信心，并且还可以对集群进行简单的外部防火墙配置。
替代方案¶
我们无法为公共端点实现高可用性 - 这实际上是不可能的。
我们无法实现公共端点，而是记录如何通过边界网关防火墙和NAT将流量转发到端点。这只是将问题转移到我们未部署的基础设施上，使其更难部署。
安全影响¶
通过此更改，我们的安全状况得到了改善，因为我们有可能开始将集群内部虚拟IP防火墙配置为仅允许已知节点连接。除此之外，我们的安全状况已经得到改善，因为我们从一开始就绑定到特定的IP地址，这使得打开新的IP地址实际上不会暴露核心服务（除了ssh）。
其他最终用户影响¶
最终用户需要能够找到新的虚拟IP。这应该通过我们现有的机制直接实现。
性能影响¶
预计没有。
其他部署者影响¶
部署者需要在他们的基础云ctlplane网络（小型安装）或他们的公共网络（大型/生产安装）上提供额外的IP地址。
开发人员影响¶
无预期。
实现¶
负责人¶
- 主要负责人
毫无生机 (哈哈哈)
- 其他贡献者
无。
工作项¶
将keepalived.conf泛化为支持多个VRRP接口。
添加支持将多个IP绑定到haproxy配置。
在incubator和/或heat模板中添加逻辑以请求第二个虚拟IP。
更改heat模板以将公共服务绑定到公共虚拟IP。
可能需要调整setup-endpoints以配合，但先前的支持应该足够。
这些不在本次范围之内，但使用它们是必要的 - 我打算将它们放在Dan的网络改造规范的讨论中。
在我们的heat模板中添加可选支持，以使用两个网卡启动机器，而不仅仅是一个 - 这样，当它是物理接口时，我们就可以拥有公共接口的IP地址。我们可能会发现Nova/Ironic/Neutron中存在需要解决的排序/枚举问题。
在我们的heat模板中添加可选支持，以静态分配来自neutron的端口并将其传递到控制平面，以便我们在使用VLAN时使用。
依赖项¶
无。
测试¶
这将默认启用，因此我们的默认CI路径将对其进行测试。
此外，我们将在即将到来的VLAN测试作业中使用它，这将使我们确信它在网络被分区时也能正常工作。
文档影响¶
添加到手册是主要的事情。
参考资料¶
无
