In che modo posso risolvere i problemi relativi ai destinatari non integri per i Network Load Balancer in Amazon EKS?

Breve descrizione

Di seguito sono riportati i motivi più comuni per cui i destinatari del Network Load Balancer non sono integri:

• Il controllo dell'integrità non è configurato correttamente. Per risolvere questo problema, avvia manualmente il controllo dell'integrità da un computer host in esecuzione su Amazon Virtual Private Cloud (Amazon VPC).
• C'è un'eccezione imprevista dal pod. Per risolvere questo problema, segui i passaggi per la risoluzione dei problemi in Verifica se c'è un'eccezione imprevista dal pod, nella sezione Risoluzione.
• Un Network Load Balancer con ExternalTrafficPolicy è impostato su Locale (nel sito Web di Kubernetes), con un DNS Amazon VPC personalizzato sulle opzioni DHCP impostate. Per risolvere questo problema, applicare una patch a kube-proxy con il flag di override del nome host.

N.B.: è possibile determinare se il tipo di gruppo di destinazione è un indirizzo IP o un'istanza verificando se l'annotazione del servizio service.beta.kubernetes.io/aws-load-balancer-nlb-target-type esiste.

Risoluzione

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

Esegui il seguente comando:

kubectl get service service_name -o yaml

N.B.: 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 se il controllo dell’integrità sia configurato correttamente

Verifica quali annotazioni di Elastic Load Balancing (ELB) (nel sito Web Kubernetes) sono configurate per il tuo servizio:

`kubectl get service service_name -o yaml`

Output di esempio:

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.

Se le annotazioni precedenti sono configurate in modo errato, i destinatari potrebbero non essere integri.

Avvia manualmente il controllo dell’integrità da un computer host in esecuzione nell'Amazon VPC

Per i tipi di destinatari di istanza, esegui il seguente comando curl con NodePort:

curl-ivk node_IP:NodePort

N.B.: sostituisci 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

N.B.: sostituisci il valore Pod_IP con l'indirizzo IP del tuo pod e pod_port con la porta del tuo pod.

Controlla se c'è un'eccezione imprevista dal pod

Tipo di destinatario di istanza

Controlla le specifiche del servizio per le annotazioni di configurazione del controllo dell'integrità attuali (dal sito web GitHub):

kubectl get service service_name -o yaml

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

kubectl get endpoints service_name -o yaml

Se non esistono endpoint per il servizio, verificare che le etichette del pod e le etichette di servizio corrispondano:

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

N.B.: sostituisci il valore pod_name con il nome del tuo pod.

Controlla se i pod sono in stato In esecuzione:

kubectl get pod -o wide

Controlla lo stato dei pod per verificare che i pod siano in esecuzione senza alcun riavvio:

kubectl get pods -o wide

Se ci sono riavvii, raccogli i registri dei pod per determinarne la causa:

kubectl logs pod_name
kubectl logs pod_name --previous

Accedi a una macchina host in Amazon VPC in cui è possibile comunicare con il nodo.

Utilizza 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 ha restituito il codice di stato HTTP previsto, anche i pod di back-end non restituiscono il codice di stato HTTP previsto.

Usa la stessa macchina host per connetterti all'indirizzo IP del pod e controllare 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.

N.B.: se ExternalTrafficPolicy del servizio (nel sito Web Kubernetes) è impostato su Locale, solo i nodi in cui sono in esecuzione i pod di backend del servizio vengono visti come target integri.

Tipo di destinazione dell'indirizzo IP

Controlla le specifiche del servizio per le annotazioni di configurazione del controllo dell'integrità attuali (dal sito web GitHub):

kubectl get service service_name -o yaml

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.

Applica una patch kube-proxy con il flag di riscrittura del nome host

Modifica il comando di specifica daemonset kube-proxy, args ed env con:

---
spec:
  template:
    spec:
      containers:
      - name: kube-proxy
        command: [ "/bin/sh" ]
        args:
        - -c
        - |
          kube-proxy --v=2 --hostname-override=$(NODE_NAME) --config=/var/lib/kube-proxy-config/config
        env:
        - name: NODE_NAME
          valueFrom:
            fieldRef:
              apiVersion: v1
              fieldPath: spec.nodeName

Ad esempio i tipi di destinatario, se externalTrafficPolicy è impostato su Cluster o Local, l'impostazione di ingresso predefinita del gruppo di sicurezza del nodo per il valore NodePort è 0.0.0.0/0. Inoltre, quandoexternalTrafficPolicy è impostato su Locale, viene configurato un ulteriore controllo dell'integrità NodePort per consentire gli intervalli di indirizzi IP CIDR della sottorete.

Per controllare l'indirizzo IP di origine nel gruppo di sicurezza del nodo per NodePort, aggiungi loadBalancerSourceRanges nella specifica e includi gli intervalli:

spec:
loadBalancerSourceRanges:
- "143.231.0.0/16"
- "xx.yy.zz.zz/24"

N.B.: se il valore .spec.loadBalancerSourceRanges non è impostato, Kubernetes consente il traffico da 0.0.0.0/0 ai gruppi di sicurezza del nodo. Se i nodi hanno indirizzi IP pubblici, anche il traffico non Network Load Balancer può raggiungere tutte le istanze nei gruppi di sicurezza modificati.

---