我想通过 Kubernetes 注释设置 Traefik 后端运行状况检查，但根据官方文档，看起来 Kubernetes Ingress 不支持该功能。
Traefik 不支持 Kubernetes Ingress 的功能有什么特别的原因吗？我想知道，因为 Mesos 支持后端的运行状况检查。
我知道在 Kubernetes 中你可以为 pod 配置就绪/活动探测器，但我有领导者/追随者时尚服务，所以 Traefik 应该只将流量路由到领导者。
上级：
- 唯一的领导者可以接受来自Traefik的连接;追随者将拒绝连接。
- 我脑海中有两个准备情况检查：
- 服务已启动并运行，并准备当选为领导者(kubernetes 就绪性探测(
- 服务已启动并运行并提升为领导者(traefik 运行状况检查(
> Traefik 依靠 Kubernetes 来提供底层 Pod 运行状况的指示，以确定它们是否准备好提供服务。Kubernetes 在一个 Pod 中公开了两种机制，用于将信息传达给编排层：
- 活动性检查，以便在 Pod 中运行的进程转换为中断状态时向 Kubernetes 提供指示。失败的存活检查将导致 Kubernetes 销毁 pod 并重新创建它。
- 就绪情况检查以确定容器何时准备好提供服务。准备情况检查失败将导致终结点控制器从其提供的任何服务的终结点列表中删除容器。但是，它将继续运行。
在这种情况下，您将通过准备情况检查向 Traefik 公开信息。使用就绪情况检查配置 Pod，如果它们处于不应接收任何流量的状态，则检查将失败。当就绪状态发生变化时，Kubernetes 将针对将流量路由到 Pod 以添加或删除 Pod 的任何服务更新端点列表。Traefik 将相应地更新其世界视图，以在支持入口的端点列表中添加或删除 Pod。
此模型没有理由与您的主/从属架构不兼容，前提是每个 Pod 都可以确定它是主节点还是从属节点，并在其就绪情况检查中提供适当的指示。但是，如果不特别注意，主/追随者状态更改和 Kubernetes 更新其端点之间将会出现竞争，因为准备探测只是定期进行的。我建议假设情况是这样，并内置逻辑来拒绝非主 Pod 收到的请求。
作为提高健壮性的未来考虑因素，您可以将服务的入口层与实现主/从系统的业务逻辑分开，允许所有实例与 Traefik 通信并排队工作，以便此时的"主"节点考虑。