envoyproxy/envoy

Add additional health status to Endpoints

Open

#22.120 geöffnet am 12. Juli 2022

Auf GitHub ansehen
 (11 Kommentare) (0 Reaktionen) (0 zugewiesene Personen)C++ (5.373 Forks)batch import
area/load balancinghelp wanted

Repository-Metriken

Stars
 (27.997 Stars)
PR-Merge-Metriken
 (Durchschn. Merge 8T) (378 gemergte PRs in 30 T)

Beschreibung

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.

Contributor Guide

Research-Richtung
Beginnen Sie mit dem Lesen des referenzierten Issues (istio/istio#18367), um den Kontext des Sendens nicht bereiter Endpunkte zu verstehen. Untersuchen Sie dann die Health Status Enums in Envoys source/common/upstream/health checker base.h und die Panikschwellenlogik in source/common/upstream/load balancer impl.cc. Überprüfen Sie vorhandene Kommentare auf etwaige vorgeschlagene Designrichtungen. Das Ziel ist es, einen neuen HealthStatus 'UNREADY' hinzuzufügen und die Panikschwellenberechnung so zu ändern, dass diese Endpunkte ausgeschlossen werden. Berücksichtigen Sie auch die Interaktion mit Envoys Outlier Detection und der Upstream Konfiguration.
Tech Stack
cpp
Domain
backend
Issue Type
Funktion
SchwierigkeitGeschätzte Implementierungsschwierigkeit für neue Contributors, von 1 für sehr kleine Änderungen bis 5 für Expertenarbeit.
4
Geschätzte ZeitEin grober Zeitrahmen, um zu recherchieren, zu implementieren, zu testen und einen Pull Request vorzubereiten.
3-5 Tage
AktivitätsstatusWie verfügbar das Issue gerade wirkt: frisch, aktiv, stale, blockiert oder wartet auf Maintainer-Input.
Aktiv
KlarheitWie klar das Issue die erwartete Änderung, Akzeptanzkriterien und den nächsten Schritt erklärt.
Klar
Voraussetzungen
C++Load BalancingHealth Checking
EinsteigerfreundlichkeitEin Score von 1 bis 100, der schätzt, wie zugänglich dieses Issue für First-Time Contributors ist.
25