通过Kubernetes注释进行Traefik健康检查

Question

我想通过Kubernetes批注设置Traefik后端运行状况检查，但是根据官方文档，Kubernetes Ingress似乎不支持该功能。

Traefik不支持Kubernetes Ingress功能的任何特殊原因吗？我想知道，因为Mesos支持后端的健康检查。

我知道您可以在Kubernetes中为Pod配置就绪/活跃度探针，但是我拥有领导者/跟随者时尚服务，因此Traefik应该将流量仅路由到领导者。

UPD：

• 唯一的领导者可以接受来自Traefik的联系；追随者将拒绝连接。
• 我心目中有两项准备情况检查：
  • 服务已启动并正在运行，并准备被选为领导者（kubernetes准备情况调查）
  • 服务已启动并正在运行，并被提升为领导者（traefik运行状况检查）

Answer 1

Traefik依靠Kubernetes来指示底层Pod的运行状况，以确定它们是否准备好提供服务。 Kubernetes在Pod中公开了两种将信息传递到业务流程层的机制：

• 活动检查，以便在Pod中运行的进程已转换为中断状态时向Kubernetes提供指示。活动检查失败将导致Kubernetes破坏并重新创建吊舱。
• 准备情况检查，以确定吊舱何时可以提供服务。准备就绪检查失败将导致端点控制器从其提供的任何服务的端点列表中删除该Pod。但是，它将继续运行。

在这种情况下，您将通过准备情况检查向Traefik公开信息。为Pod配置就绪检查，如果Pod处于不应接收任何流量的状态，则会失败。当就绪状态更改时，Kubernetes将针对将流量路由到Pod以添加或移除Pod的任何服务更新端点列表。 Traefik将相应地更新其世界观，以在支持Ingress的端点列表中添加或删除Pod。

该模型没有理由与您的主/从架构不兼容，只要每个Pod可以确定它是主/从属，并在准备就绪检查中提供适当的指示即可。但是，在没有特别注意的情况下，主/从状态更改与Kubernetes更新其终结点之间会出现竞赛，因为准备状态探测仅是定期进行的。我建议假设是这种情况，并采用内置逻辑来拒绝非主Pod收到的请求。

---

作为将来增强健壮性的考虑，您可以将服务的入口层与实现主/从系统的业务逻辑分开，从而允许所有实例与Traefik进行通信并将工作排队，由“主”负责。节点。