通过Kubernetes注释进行Traefik健康检查 [英] Traefik health checks via kubernetes annotation

问题描述

我想通过Kubernetes批注设置Traefik后端运行状况检查，但看起来像根据官方文档，Kubernetes Ingress 不支持该功能.

I want setup Traefik backend health check via Kubernetes annotation, but looks like Kubernetes Ingress does not support that functionality according to official documentation.

Traefik不支持Kubernetes Ingress功能的任何特殊原因吗?我想知道，因为 Mesos 支持后端的运行状况检查.

Is any particular reason why Traefik does not support that functionality for Kubernetes Ingress? I'm wondering because Mesos support health checks for a backend.

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

I know that in Kubernetes you can configure readiness/liveness probe for the pods, but I have leader/follower fashion service, so Traefik should route the traffic only to the leader.

UPD:

• 唯一的领导者可以接受来自Traefik的联系；追随者将拒绝连接.
• 我心目中有两项准备情况检查:
  • 服务已启动并正在运行，并已准备好被选为领导者(kubernetes准备情况调查)
  • 服务已启动并正在运行，并被提升为领导者(traefik运行状况检查)
  • The only leader can accept the connection from Traefik; a follower will refuse the connection.
  • I have two readiness checks in my mind:
    • Service is up and running, and ready to be elected as a leader (kubernetes readiness probe)
    • Service is up and running and promoted as a leader (traefik health check)

    推荐答案

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

    Traefik relies on Kubernetes to provide an indication of the health of the underlying pods to ascertain whether they are ready to provide service. Kubernetes exposes two mechanisms in a pod to communicate information to the orchestration layer:

    • 活动检查，以便在Pod中运行的进程已转换为中断状态时向Kubernetes提供指示.活动检查失败将导致Kubernetes破坏吊舱并重新创建吊舱.
    • 准备情况检查，以确定吊舱何时可以提供服务.准备就绪检查失败将导致端点控制器从其提供的任何服务的端点列表中删除该Pod.但是，它将保持运行状态.
    • Liveness checks to provide an indication to Kubernetes when the process(es) running in the pod have transitioned to a broken state. A failing liveness check will cause Kubernetes to destroy the pod and recreate it.
    • Readiness checks to determine when a pod is ready to provide service. A failing readiness check will cause the Endpoint Controller to remove the pod from the list of endpoints of any services it provides. However, it will remain running.

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

    In this instance, you would expose information to Traefik via a readiness check. Configure your pods with a readiness check which fails if they are in a state in which they should not receive any traffic. When the readiness state changes, Kubernetes will update the list of endpoints against any services which route traffic to the pod to add or remove the pod. Traefik will accordingly update its view of the world to add or remove the pod from the list of endpoints backing the Ingress.

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

    There is no reason for this model to be incompatible with your master/follower architecture, provided each pod can ascertain whether it is the master or follower and provide an appropriate indication in its readiness check. However, without taking special care, there will be races between the master/follower state changing and Kubernetes updating its endpoints, as readiness probes are only made periodically. I recommend assuming this will be the case and building-in logic to reject requests received by non-master pods.

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

    As a future consideration to increase robustness, you might split the ingress layer of your service from the business logic implementing the master/follower system, allowing all instances to communicate with Traefik and enqueue work for consideration by whatever is the "master" node at this point.

    这篇关于通过Kubernetes注释进行Traefik健康检查的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！