TripleO 服务容器健康检查¶

https://blueprints.launchpad.net/tripleo/+spec/container-healthchecks

OpenStack 部署涉及许多服务，分布在多个主机上。提供工具和 API 以尽可能轻松地监控这个大型分布式环境至关重要。Overcloud 中向容器化服务 [1] 的转变带来了许多机会，例如能够将服务与其相关的健康检查捆绑在一起，并提供标准的 API 来评估服务的健康状况。

[1]: https://blueprints.launchpad.net/tripleo/+spec/containerize-tripleo

问题描述¶

通常，最适合开发服务适当健康检查的人员是负责开发该服务的人员。不幸的是，设置监控的任务通常落入云操作员或某些中间方的手中。

我建议我们利用容器化服务提供的捆绑功能，并创建一个标准的 API，操作员可以通过该 API 评估服务的健康状况。这简化了操作员的工作，现在他们可以在无需了解每个服务的详细知识的情况下提供粒度化的服务监控，并且允许服务开发人员确保服务得到适当的监控。

提议的变更¶

概述¶

Docker 引擎（自版本 1.12 起），以及大多数更高级别的编排框架，都提供了一种标准机制来验证容器的健康状况。Docker 本身提供了 HEALTHCHECK 指令，而 Kubernetes 明确支持存活和就绪探测。这两种机制都通过在容器内执行定义的命令，并使用该执行的结果来确定容器是否“健康”来工作。

我建议我们通过以下方式明确地支持这些接口，在容器化的 TripleO 服务中

在每个容器中包含一个 /openstack/healthcheck 命令，该命令将检查容器化服务的健康状况，如果服务健康则以状态 0 退出，如果未健康则以状态 1 退出，并在 stdout 上提供一条消息，描述错误的性质。
在每个 Docker 镜像中包含适当的 HEALTHCHECK 指令，以利用该脚本
```
HEALTHCHECK CMD /openstack/healthcheck
```
如果 Kubernetes 成为 TripleO 部署过程的标准部分，我们可能可以使用相同的脚本来实现存活或就绪探测
```
livenessProbe:
  exec:
    command:
      - /openstack/healthcheck
```

替代方案¶

另一种选择是现状：服务不提供标准的健康检查 API，并且服务监控必须由云操作员单独配置。

安全影响¶

N/A

其他最终用户影响¶

用户可以显式运行健康检查脚本以立即评估服务的状态。

性能影响¶

本提案将导致 Overcloud 主机上任务的定期执行。在设计健康检查时，服务开发人员应选择适当的检查间隔，以使健康检查造成的运营开销最小。

其他部署者影响¶

N/A

开发人员影响¶

开发人员需要确定如何最好地评估服务的健康状况，并提供适当的脚本来执行此检查。

实现¶

负责人¶

N/A

工作项¶

N/A

依赖项¶

这需要我们实现 containerize-tripleo-overcloud 蓝图。

测试¶

TripleO CI 作业应更新为利用健康检查 API 来确定服务是否正常运行。

文档影响¶

任何描述将服务容器化到 TripleoO 的过程的文档都必须更新，以描述健康检查 API。

参考资料¶

N/A

TripleO 服务的容器健康检查