In che modo è possibile risolvere i problemi relativi agli obiettivi non integri dei Network Load Balancer in Amazon EKS?

Breve descrizione

Di seguito sono riportati i motivi più comuni per cui gli obiettivi del Network Load Balancer non sono sani:

• Il controllo dello stato non è configurato correttamente.
• Si è verificata un'eccezione inaspettata dal pod.
• Un Network Load Balancer con ExternalTrafficPolicy impostato su locale con un DNS Amazon VPC personalizzato nel set di opzioni DHCP.

Risoluzione

Verifica se il gruppo target è un indirizzo IP o un'istanza

Esegui il comando seguente:

kubectl get service service_name -o yaml

**Nota:**Sostituisci service\ _name con il nome del tuo servizio.

Se l'annotazione service.beta.kubernetes.io/aws-load-balancer-nlb-target-type non è presente, il tipo di destinazione predefinito è un'istanza.

Verifica che il controllo dello stato sia configurato correttamente

Verifica quali annotazioni Elastic Load Balancing (ELB) sono configurate per il tuo servizio. Per ulteriori informazioni sulle annotazioni, consulta Service sul sito web di Kubernetes.

Esegui il comando seguente per ottenere un elenco di annotazioni:

kubectl get service service_name -o yaml

Esempio di output:

service.beta.kubernetes.io/aws-load-balancer-healthcheck-healthy-threshold: "2"# The number of successive successful health checks required for a backend to be considered healthy for traffic. Defaults to 2, must be between 2 and 10

service.beta.kubernetes.io/aws-load-balancer-healthcheck-unhealthy-threshold: "3"
# The number of unsuccessful health checks required for a backend to be considered unhealthy for traffic. Defaults to 6, must be between 2 and 10

service.beta.kubernetes.io/aws-load-balancer-healthcheck-interval: "20"
# The approximate interval, in seconds, between health checks of an individual instance. Defaults to 10, must be between 5 and 300

service.beta.kubernetes.io/aws-load-balancer-healthcheck-timeout: "5"
# The amount of time, in seconds, during which no response means a failed health check. This value must be less than the service.beta.kubernetes.io/aws-load-balancer-healthcheck-interval value. Defaults to 5, must be between 2 and 60

service.beta.kubernetes.io/aws-load-balancer-healthcheck-protocol: TCP
service.beta.kubernetes.io/aws-load-balancer-healthcheck-port: traffic-port
# can be integer or traffic-port

service.beta.kubernetes.io/aws-load-balancer-healthcheck-path: "/"
# health check path for HTTP(S) protocols

Se le annotazioni sono configurate in modo errato, le destinazioni possono non essere integre.

Avvia manualmente il controllo dello stato da una macchina host in esecuzione su Amazon VPC

Ad esempio, i tipi di destinazione, esegui il seguente comando curl con nodePort:

curl-ivk node_IP:NodePort

**Nota:**sostituisci il node\ _IP con l'indirizzo IP del tuo nodo.

Per i tipi di destinazione degli indirizzi IP, esegui il seguente comando curl:

curl -ivk pod_IP:pod_port

Nota: Sostituisci pod\ _IP con l'indirizzo IP del tuo pod. Sostituisci pod\ _port con il nome della porta su cui l'applicazione è in ascolto all'interno del contenitore.

Verifica la presenza di un'eccezione inaspettata dal pod

Tipo di destinazione dell'istanza

1. Controlla le specifiche del servizio per le annotazioni di configurazione del controllo dello stato corrente. Per un elenco completo, consulta le health check configuration annotations sul sito Web di GitHub:

   kubectl get service service_name -o yaml

2. Controlla se ci sono endpoint per verificare che ci siano dei pod dietro il servizio:

   kubectl get endpoints service_name -o yaml

3. Se non esistono endpoint per il servizio, controlla che le etichette dei pod e quelle del servizio corrispondano:

   kubectl describe servicekubectl describe pod pod_name or kubectl get pod --show-labels

   Nota: Sostituisci pod\ _name con il nome del tuo pod.

4. Controlla se i pod sono in stato di Esecuzione:

   kubectl get pod -o wide

5. Controlla lo stato dei pod per verificare che possano essere eseguiti senza riavvii:

   kubectl get pods -o wide

6. Se ci sono riavvii, raccogli i log del pod per determinarne la causa:

   kubectl logs pod_namekubectl logs pod_name --previous

7. Accedi a una macchina host in Amazon VPC dove puoi comunicare con il nodo. Quindi, usa il comando curl con NodePort per verificare se i pod restituiscono il codice di stato HTTP previsto:

   curl node_IP:NodePort

   Se il comando curl non restituisce il codice di stato HTTP previsto, i pod di backend non restituiscono il codice di stato HTTP previsto.

8. Usa la stessa macchina host per connetterti all'indirizzo IP del pod e controlla se il pod è configurato correttamente:

   curl pod_IP:pod_port

   Se il comando curl non ha restituito il codice di stato HTTP previsto, il pod non è configurato correttamente.

**Nota:**se la ExternalTrafficPolicy del servizio (dal sito Web Kubernetes) è impostata su Local, solo i nodi in cui sono in esecuzione i pod di backend del servizio vengono considerati obiettivi integri.

Tipo di destinazione dell'indirizzo IP

1. Controlla le specifiche del servizio per le annotazioni di configurazione del controllo dello stato corrente. Per un elenco, consulta le health check configuration annotations sul sito Web di GitHub.

   kubectl get service service_name -o yaml

2. Accedi a una macchina host in Amazon VPC e usa il comando curl per comunicare con l'indirizzo IP del pod:

   curl pod_IP:pod_port

   Se il comando curl non ha restituito il codice di stato HTTP previsto, il pod non è configurato correttamente.