In che modo posso risolvere i problemi relativi ai destinatari non integri per i Network Load Balancer in Amazon EKS?
Desidero correggere i destinatari non integri per i Network Load Balancer nel mio Amazon Elastic Kubernetes Service (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.
Contenuto pertinente
- AWS UFFICIALEAggiornata 7 mesi fa
- AWS UFFICIALEAggiornata 2 anni fa