envoyproxy/envoy

Add additional health status to Endpoints

Open

#22.120 aberto em 12 de jul. de 2022

Ver no GitHub
 (11 comments) (0 reactions) (0 assignees)C++ (5.373 forks)batch import
area/load balancinghelp wanted

Métricas do repositório

Stars
 (27.997 stars)
Métricas de merge de PR
 (Mesclagem média 8d) (378 fundiu PRs em 30d)

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.

Guia do colaborador

Direção de pesquisa
Comece lendo a issue referenciada (istio/istio#18367) para entender o contexto do envio de endpoints não prontos. Em seguida, examine os enums de status de saúde em source/common/upstream/health checker base.h do Envoy e a lógica do limite de pânico em source/common/upstream/load balancer impl.cc. Verifique os comentários existentes para quaisquer direções de design propostas. O objetivo é adicionar um novo HealthStatus 'UNREADY' e modificar o cálculo do limite de pânico para excluir esses endpoints. Considere também a interação com a detecção de outliers do Envoy e a configuração upstream.
Pilha de tecnologia
cpp
Domain
backend
Tipo Issue
Funcionalidade
DifficultyDificuldade de implementação estimada para um novo contribuidor, de 1 para alterações muito pequenas a 5 para trabalho de nível especializado.
4
Tempo estimadoUm intervalo de tempo aproximado para um colaborador experiente investigar, implementar, testar e preparar um pull request.
3-5 dias
Status da atividadeQuão disponível o issue aparece agora: novo, ativo, obsoleto, bloqueado ou aguardando entrada do mantenedor.
Ativo
ClarityCom que clareza o issue explica a mudança esperada, os critérios de aceitação e a próxima etapa.
Claro
Prerequisites
C++Load BalancingHealth Checking
Simpatia para novatosUma pontuação de 1 a 100 que estima o quão acessível este issue é para colaboradores iniciantes.
25