Come posso risolvere un controllo dell'integrità non riuscito per un sistema di bilanciamento del carico in Amazon EKS?
Il mio load balancer non supera il controllo dello stato nel mio Amazon Elastic Kubernetes Service (Amazon EKS).
Risoluzione
Per risolvere i problemi di controllo dell'integrità con il sistema di bilanciamento del carico in Amazon EKS, completa i passaggi nelle seguenti sezioni.
Controlla lo stato del pod
Controlla se il pod è in stato In esecuzione e i contenitori nei pod sono pronti:
$ kubectl get pod -n YOUR_NAMESPACE
Nota: Sostituisci YOUR_NAMESPACE con il tuo namespace Kubernetes.
Esempio di output:
NAME READY STATUS RESTARTS AGEpodname 1/1 Running 0 16s
Se il contenitore dell'applicazione nello stato del pod non è In esecuzione, il controllo dello stato del load balancer non riceve risposta e fallisce.
Controlla i selettori del pod e delle etichette di servizio
Per le etichette dei pod, esegui il comando seguente:
$ kubectl get pod -n YOUR_NAMESPACE --show-labels
Esempio di output:
NAME READY STATUS RESTARTS AGE LABELSalb-instance-6cc5cd9b9-prnxw 1/1 Running 0 2d19h app=alb-instance,pod-template-hash=6cc5cd9b9
Per verificare che il tuo servizio Kubernetes utilizzi le etichette dei pod, esegui il seguente comando per verificare che l'output corrisponda alle etichette dei pod:
$ kubectl get svc SERVICE_NAME -n YOUR_NAMESPACE -o=jsonpath='{.spec.selector}{"\n"}'
Nota: Sostituisci SERVICE\ _NAME con il tuo Kubernetes Service e YOUR_NAMESPACE con il tuo spazio dei nomi Kubernetes.
Esempio di output:
{"app":"alb-instance"}
Verifica la presenza di endpoint mancanti
Il controller Kubernetes per il selettore di servizi cerca continuamente i pod che corrispondono al suo selettore e quindi pubblica gli aggiornamenti su un oggetto endpoint. Se hai selezionato un'etichetta errata, non viene visualizzato alcun endpoint.
Esegui il comando seguente:
$ kubectl describe svc SERVICE_NAME -n YOUR_NAMESPACE
Esempio di output:
Name: alb-instanceNamespace: default Labels: <none> Annotations: <none> Selector: app=alb-instance-1 Type: NodePort IP Family Policy: SingleStack IP Families: IPv4 IP: 10.100.44.151 IPs: 10.100.44.151 Port: http 80/TCP TargetPort: 80/TCP NodePort: http 32663/TCP Endpoints: <none> Session Affinity: None External Traffic Policy: Cluster Events: <none>
Controlla se manca un endpoint:
$ kubectl get endpoints SERVICE_NAME -n YOUR_NAMESPACE
Esempio di output:
NAME ENDPOINTS AGEalb-instance <none> 2d20h
Controlla la politica sul traffico del servizio e i gruppi di sicurezza del cluster per eventuali problemi con Application Load Balancer
Gli obiettivi non integri nei gruppi target di Application Load Balancer si verificano per due motivi:
- La politica sul traffico del servizio, spec.externalTrafficPolicy è impostata su Locale anziché su Cluster.
- Ai gruppi di nodi di un cluster sono associati diversi gruppi di sicurezza del cluster e il traffico non può fluire liberamente tra i gruppi di nodi.
Verifica che la politica sul traffico sia configurata correttamente:
$ kubectl get svc SERVICE_NAME -n YOUR_NAMESPACE -o=jsonpath='{.spec.externalTrafficPolicy}{"\n"}'
Esempio di output:
Local
Cambia l'impostazione in Cluster:
$ kubectl edit svc SERVICE_NAME -n YOUR_NAMESPACE
Controlla i gruppi di sicurezza del cluster
Completa i seguenti passaggi:
- Apri la console Amazon EC2.
- Seleziona l'istanza integra.
- Scegli la scheda Sicurezza, quindi controlla le regole di ingresso del gruppo di sicurezza.
- Seleziona l'istanza non integra.
- Scegli la scheda Sicurezza, quindi controlla le regole di ingresso del gruppo di sicurezza.
Se il gruppo di sicurezza per ogni istanza è diverso, è necessario modificare la regola di ingresso di sicurezza nella console del gruppo di sicurezza:
Dalla scheda Sicurezza, seleziona l'ID del gruppo di sicurezza.
Scegli Modifica regole in entrata per modificare le regole di ingresso.
Aggiungi regole in entrata per consentire il traffico dagli altri gruppi di nodi nel cluster.
Verifica che il tuo servizio sia configurato per targetPort
Il tuo targetPort deve corrispondere al containerPort nel pod a cui il servizio invia il traffico.
Per verificare su cosa è configurato targetPort, esegui il comando seguente:
$ kubectl get svc SERVICE_NAME -n YOUR_NAMESPACE -o=jsonpath="{.items[*]}{.metadata.name}{'\t'}{.spec.ports[].targetPort}{'\t'}{.spec.ports[].protocol}{'\n'}"
Esempio di output:
alb-instance 8080 TCP
Nell'output di esempio, targetPort è configurato su 8080. Tuttavia, poiché containerPort è impostato su 80, è necessario configurare targetPort su 80.
Verifica che il tuo AWS Load Balancer Controller disponga delle autorizzazioni corrette
L'AWS Load Balancer Controller deve disporre delle autorizzazioni corrette per aggiornare i gruppi di sicurezza per consentire il traffico dal load balancer alle istanze o ai pod. Se il controller non dispone delle autorizzazioni corrette, riceverai degli errori.
Verifica la presenza di errori nei log di distribuzione di AWS Load Balancer Controller:
$ kubectl logs deploy/aws-load-balancer-controller -n kube-system
Verifica la presenza di errori nei log dei singoli controller:
$ kubectl logs CONTROLLER_POD_NAME -n YOUR_NAMESPACE
Nota: Sostituisci CONTROLLER_POD_NAME con il nome del pod del controller e YOUR_NAMESPACE con il tuo spazio dei nomi di Kubernetes.
Controlla le annotazioni in ingresso per eventuali problemi con Application Load Balancer
Per problemi con Application Load Balancer, controlla le annotazioni di ingresso di Kubernetes:
$ kubectl describe ing INGRESS_NAME -n YOUR_NAMESPACE
Nota: Sostituisci INGRESS_NAME con il nome del tuo ingresso Kubernetes e YOUR_NAMESPACE con il tuo spazio dei nomi Kubernetes.
Esempio di output:
Name: alb-instance-ingressNamespace: default Address: k8s-default-albinsta-fcb010af73-2014729787.ap-southeast-2.elb.amazonaws.com Default backend: alb-instance:80 (192.168.81.137:8080) Rules: Host Path Backends ---- ---- -------- awssite.cyou / alb-instance:80 (192.168.81.137:8080) Annotations: alb.ingress.kubernetes.io/scheme: internet-facing kubernetes.io/ingress.class: alb Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal SuccessfullyReconciled 25m (x7 over 2d21h) ingress Successfully reconciled
Per trovare le annotazioni di ingresso specifiche per il tuo caso d'uso, consulta le annotazioni d'ingresso sul sito web di Kubernetes.
Controlla le annotazioni del servizio Kubernetes per problemi con Network Load Balancer
Per problemi con Network Load Balancer, controlla le annotazioni del servizio Kubernetes:
$ kubectl describe svc SERVICE_NAME -n YOUR_NAMESPACE
Esempio di output:
Name: nlb-ipNamespace: default Labels: <none> Annotations: service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: ip service.beta.kubernetes.io/aws-load-balancer-scheme: internet-facing service.beta.kubernetes.io/aws-load-balancer-type: external Selector: app=nlb-ip Type: LoadBalancer IP Family Policy: SingleStack IP Families: IPv4 IP: 10.100.161.91 IPs: 10.100.161.91 LoadBalancer Ingress: k8s-default-nlbip-fff2442e46-ae4f8cf4a182dc4d.elb.ap-southeast-2.amazonaws.com Port: http 80/TCP TargetPort: 80/TCP NodePort: http 31806/TCP Endpoints: 192.168.93.144:80 Session Affinity: None External Traffic Policy: Cluster Events: <none>
Nota: Nota il valore di APPLICATION_POD_IP per eseguire un comando di controllo dello stato in un passaggio successivo.
Per trovare le annotazioni del servizio Kubernetes specifiche per il tuo caso d'uso, consulta Annotazioni del servizio sul sito web di Kubernetes.
Verifica manualmente un controllo dell'integrità
Controlla l'indirizzo IP del pod dell'applicazione:
$ kubectl get pod -n YOUR_NAMESPACE -o wide
Esegui un test pod per testare manualmente un controllo dello stato all'interno del cluster:
$ kubectl run -n YOUR_NAMESPACE troubleshoot -it --rm --image=amazonlinux -- /bin/bash
Quindi, esegui il controllo dello stato HTTP:
# curl -Iv APPLICATION_POD_IP/HEALTH_CHECK_PATH
Nota: Sostituisci APPLICATION_POD_IP con l'indirizzo IP del tuo application pod e HEALTH_CHECK_PATH con il percorso di controllo dell'integrità del gruppo target di Application Load Balancer.
Comando di esempio:
# curl -Iv 192.168.81.137
Esempio di output:
* Trying 192.168.81.137:80...* Connected to 192.168.81.137 (192.168.81.137) port 80 (#0) > HEAD / HTTP/1.1 > Host: 192.168.81.137 > User-Agent: curl/7.78.0 > Accept: */* > * Mark bundle as not supporting multiuse < HTTP/1.1 200 OK HTTP/1.1 200 OK < Server: nginx/1.21.3 Server: nginx/1.21.3 < Date: Tue, 26 Oct 2021 05:10:17 GMT Date: Tue, 26 Oct 2021 05:10:17 GMT < Content-Type: text/html Content-Type: text/html < Content-Length: 615 Content-Length: 615 < Last-Modified: Tue, 07 Sep 2021 15:21:03 GMT Last-Modified: Tue, 07 Sep 2021 15:21:03 GMT < Connection: keep-alive Connection: keep-alive < ETag: "6137835f-267" ETag: "6137835f-267" < Accept-Ranges: bytes Accept-Ranges: bytes < * Connection #0 to host 192.168.81.137 left intact
Controlla il codice di stato della risposta HTTP. Se il codice di stato della risposta è 200 OK, l'applicazione risponde correttamente al percorso di controllo dello stato di integrità.
Se il codice di stato della risposta HTTP è 3xx o 4xx, modifica il percorso di controllo dello stato di salute. La seguente annotazione risponde con 200 OK:
alb.ingress.kubernetes.io/healthcheck-path: /ping
-or-
Utilizza la seguente annotazione sulla risorsa di ingresso per aggiungere un intervallo di codici di stato della risposta al controllo dello stato di salute riuscito:
alb.ingress.kubernetes.io/success-codes: 200-399
Per i controlli di integrità del TCP, utilizzare il seguente comando per installare il comando netcat:
# yum update -y && yum install -y nc
Prova i controlli di integrità del TCP:
# nc -z -v APPLICATION_POD_IP CONTAINER_PORT_NUMBER
Nota: Sostituisci APPLICATION_POD_IP con l'indirizzo IP del pod dell'applicazione e CONTAINER_PORT_NUMBER con la porta del contenitore.
Comando di esempio:
# nc -z -v 192.168.81.137 80
Esempio di output:
Ncat: Version 7.50 ( https://nmap.org/ncat ) Ncat: Connected to 192.168.81.137:80.Ncat: 0 bytes sent, 0 bytes received in 0.01 seconds.
Controlla la rete
Per problemi di rete, verifica quanto segue:
- I gruppi di nodi multipli del cluster EKS possono comunicare liberamente tra loro.
- L'elenco di controllo degli accessi alla rete (ACL di rete) associato alla sottorete in cui vengono eseguiti i pod consente il traffico proveniente dall'intervallo CIDR della sottorete del load balancer.
- L'ACL di rete associato alla sottorete del load balancer consente il traffico di ritorno sull'intervallo di porte temporaneo dalla sottorete in cui vengono eseguiti i pod.
- La tabella di routing consente il traffico locale all'interno dell'intervallo CIDR del VPC.
Riavvia il kube-proxy
Se il kube-proxy in esecuzione su ogni nodo non funziona correttamente, il kube-proxy potrebbe non riuscire ad aggiornare le regole iptables per il servizio e gli endpoint. Riavvia il kube-proxy per forzarlo a ricontrollare e aggiornare le regole di iptables:
kubectl rollout restart daemonset.apps/kube-proxy -n kube-system
Esempio di output:
daemonset.apps/kube-proxy restarted
Informazioni correlate
How do I automatically discover the subnets that my Application Load Balancer uses in Amazon EKS?
Contenuto pertinente
- AWS UFFICIALEAggiornata 4 anni fa