envoyproxy/envoy

Add additional health status to Endpoints

Open

#22 120 ouverte le 12 juil. 2022

Voir sur GitHub
 (11 commentaires) (0 réactions) (0 assignés)C++ (5 373 forks)batch import
area/load balancinghelp wanted

Métriques du dépôt

Stars
 (27 997 stars)
Métriques de merge PR
 (Merge moyen 8j) (378 PRs mergées en 30 j)

Description

When a controlplane has to send "Unready" k8s endpoints to Envoy, when Envoy runs in to panic mode, Envoy sends traffic to "Unready" endpoints. This breaks the Kubernetes contract that "Unready" endpoints should never receive traffic.

In Istio, we send "Unready" endpoints with "Unhealthy" status. So the panic threshold algorithm can not distinguish between "Unready" vs. "Unhealthy".

Please refer to https://github.com/istio/istio/issues/18367 for why we send "Unready" endpoints. This also needed for warmup duration (slow start mode) so that intermittent readiness failures (after the service is ready for the first time) does not cause spurious warmups.

The feature request is to add additional status for "UNREADY" endpoints, that load balancer can exclude while considering hosts during panic threshold scenarios.

Guide contributeur

Direction de recherche
Commencez par lire l'issue référencée (istio/istio#18367) pour comprendre le contexte de l'envoi des points de terminaison non prêts. Ensuite, examinez les énumérations d'état de santé dans source/common/upstream/health checker base.h d'Envoy et la logique du seuil de panique dans source/common/upstream/load balancer impl.cc. Vérifiez les commentaires existants pour toute proposition de direction de conception. L'objectif est d'ajouter un nouveau HealthStatus 'UNREADY' et de modifier le calcul du seuil de panique pour exclure ces points de terminaison. Considérez également l'interaction avec la détection d'anomalies d'Envoy et la configuration en amont.
Stack technique
cpp
Domaine
backend
Type d'issue
Fonctionnalité
DifficultéDifficulté estimée pour un nouveau contributeur, de 1 pour un très petit changement à 5 pour un travail expert.
4
Temps estiméFourchette de temps approximative pour investiguer, implémenter, tester et préparer une pull request.
3-5 jours
Statut d'activitéDisponibilité apparente de l'issue : fraîche, active, ancienne, bloquée ou en attente d'un mainteneur.
Active
ClartéClarté avec laquelle l'issue explique le changement attendu, les critères d'acceptation et la prochaine étape.
Claire
Prérequis
C++Load BalancingHealth Checking
Accessibilité débutantScore de 1 à 100 estimant l'accessibilité de cette issue pour un premier contributeur.
25