清理容器健康检查¶
https://blueprints.launchpad.net/tripleo/+spec/clean-container-healthchecks
我们不依赖于 容器健康检查 的结果来执行基础设施中的任何操作。 它们耗费时间和资源，并且其维护大多是随机的。我们至少可以删除那些没有命中实际 API 健康检查端点的健康检查。
此提案在 Xena PTG 会议 上进行了讨论
问题描述¶
自从我们将服务迁移到容器，首先使用 docker 引擎，然后使用 podman，容器健康检查已被实施和使用。
虽然健康检查的想法本身没有坏处，但我们（TripleO）实施和使用它们的方式大多是错误的
健康检查失败时不会采取任何操作
有些（大多数）实际上并没有检查服务是否正常工作，而只是检查服务容器是否正在运行
例如 healthcheck_port、healthcheck_listen、healthcheck_socket 以及大多数调用 healthcheck_curl 的脚本，大多只是确保服务正在运行——而我们已经在容器“运行”（良好）、“重启”（不好）或“退出”（带有非 0 代码 - 坏）时获得了这些信息。
此外，podman 实现健康检查的方式依赖于 systemd 及其瞬态服务和 定时器。 基本上，对于每个容器，都会创建一个新的 systemd 单元并注入，以及一个新的定时器——这意味着 systemd 调用 podman。 这对于主机来说并不是很好，特别是那些由于其使用而负载较重的主机。
提议的变更¶
概述¶
需要对当前的健康检查进行深度清理，例如 healthcheck_socket、healthcheck_port 和 healthcheck_curl，这些健康检查没有调用实际的 API 健康检查端点。 此列表并非详尽无遗。
这将大大减少“podman”调用的数量，从而减少资源问题，并提供更好的理解，当我们列出进程或服务时。
如果 Operator 想要获取一些状态信息，他们可以利用现有的验证
openstack tripleo validator run --validation service-status
此验证可以直接从 Undercloud 启动，并将为每个 OC 节点收集远程状态，然后提供清晰的摘要。
如果它具有所需的信息（主要是清单），则此验证也可以从第三方监控实例启动。
替代方案¶
我们可以实现多种替代方案，甚至作为逐步解决方案，但其中任何一种可能都需要它们自己的规范和讨论
用实际的服务健康检查替换列出的健康检查¶
这样做可以更好地了解堆栈的健康状况，但不会解决 podman 调用问题（因此资源消耗和相关问题）。 这样的健康检查可以从外部工具启动，例如基于主机 cron，或实际服务。
从外部工具调用健康检查¶
这样做可以防止我们当前看到的“podman exec”调用的潜在资源问题，同时允许对结果进行集中处理，从而提供更好的方式来获取指标和统计数据。
保持现状¶
因为我们必须列出这个，但有迹象表明这不是正确的事情（因此当前的规范）。
安全影响¶
没有实际的安全影响。 更少的服务/调用可能会导致更小的攻击面，并且可以防止某些拒绝服务情况。
升级影响¶
没有升级影响。
其他最终用户影响¶
最终用户无法访问健康检查——这更多的是给操作员的。
性能影响¶
系统压力会更小，这可以改善当前有关性能和稳定性的情况。
其他部署者影响¶
如果我们将操作员视为部署者，则没有“部署者影响”。
对于后者，有一个直接影响：podman ps 将无法再显示健康状态，或者至少不能显示没有此类检查的容器的健康状态。
但是操作员可以使用服务状态验证代替——此验证甚至可以提供更多信息，因为它考虑了失败的容器，而 podman ps 在没有适当选项的情况下不显示，即使有了它，过滤起来也不容易。
开发人员影响¶
为了改进健康检查，特别是对于 API 端点，服务开发人员需要在应用程序中实施特定的测试。
一旦存在、工作且可靠，他们就可以将其推送到任何可用的健康检查工具——无论是嵌入式容器健康检查，还是如第三步所述的专用服务。
实现¶
负责人¶
- 主要负责人
cjeanner
工作项¶
清理现有的健康检查，如果它们没有调用实际的端点，则在 tripleo-heat-templates 中禁用它们
确保此更改不会降低堆栈的稳定性，并与验证框架团队正确记录“服务状态”验证
第二项工作更多的是长期经验数据——我们目前没有实际数据，除了 Launchpad issue 指出问题可能是由健康检查的启动方式引起的。
可能的未来工作项¶
与 CloudOps（指标团队）启动关于专用健康检查服务以及如何在 TripleO 中正确集成它的讨论
启动跨团队工作，为需要健康检查的服务提供实际的健康检查端点
这些只是为了演进而存在的。 需要适当的规范来构建工作。
依赖项¶
对于第 1 步和第 2 步，不需要实际的依赖项。
测试¶
测试需要不同的东西
适当的指标，以确保没有负面影响——并且任何影响都可以衡量
适当的保证，删除健康检查不会以负面方式影响服务
对验证进行适当的测试，特别是“服务状态”，以确保它足够可靠，可以在某个时候被视为替代方案
文档影响¶
需要更新关于整体健康检查主题的文档。
