Come posso risolvere un controllo dell'integrità non riuscito per un bilanciatore del carico in Amazon EKS?

Breve descrizione

Per risolvere i problemi relativi al controllo dell'integrità del bilanciatore del carico in Amazon EKS, completa i passaggi nelle sezioni seguenti:

• Controlla lo stato del pod
• Controlla i selettori dei pod e delle etichette di servizio
• Controlla la presenza di endpoint mancanti
• Controlla la policy di traffico del servizio e i gruppi di sicurezza del cluster per Application Load Balancer
• Verifica che il tuo EKS sia configurato per targetPort
• Verifica che il tuo AWS Load Balancer Controller disponga delle autorizzazioni corrette
• Controlla le annotazioni in ingresso per eventuali problemi con Application Load Balancer
• Controlla le annotazioni del servizio Kubernetes per eventuali problemi con Network Load Balancer
• Testa manualmente un controllo dell'integrità
• Controlla le reti
• Riavvia il kube-proxy

Risoluzione

Controlla lo stato del pod

Controlla se il pod è in stato Running (In esecuzione) e i container nei pod sono pronti:

$ kubectl get pod -n YOUR_NAMESPACE

Nota: sostituisci YOUR_NAMESPACE con il tuo spazio dei nomi Kubernetes.

Output di esempio:

NAME                           READY   STATUS    RESTARTS   AGE
podname                        1/1     Running   0          16s

Nota: se il container dell'applicazione nel pod non è in esecuzione, il controllo dell'integrità del bilanciatore del carico non riceve risposta e fallisce.

Controlla i selettori dei pod e delle etichette di servizio

Per le etichette dei pod, esegui il seguente comando:

$ kubectl get pod -n YOUR_NAMESPACE --show-labels

Output di esempio:

NAME                           READY   STATUS    RESTARTS   AGE     LABELS
alb-instance-6cc5cd9b9-prnxw   1/1     Running   0          2d19h   app=alb-instance,pod-template-hash=6cc5cd9b9

Per verificare che il servizio Kubernetes stia utilizzando le etichette dei pod, esegui il comando seguente per verificare che il relativo 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 servizio Kubernetes e YOUR_NAMESPACE con il tuo spazio dei nomi Kubernetes.

Output di esempio:

{"app":"alb-instance"}

Controlla la presenza di endpoint mancanti

Il controller Kubernetes per il selettore di servizi esegue continuamente la scansione dei pod che corrispondono al relativo selettore e quindi invia gli aggiornamenti a un oggetto endpoint. Se è stata selezionata un'etichetta errata, non viene visualizzato nessun endpoint.

Esegui il seguente comando:

$ kubectl describe svc SERVICE_NAME -n YOUR_NAMESPACE

Output di esempio:

Name:                     alb-instance
Namespace:                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 l'endpoint:

$ kubectl get endpoints SERVICE_NAME -n YOUR_NAMESPACE

Output di esempio:

NAME           ENDPOINTS                                AGE
alb-instance   <none>                                   2d20h

Controlla la policy di traffico del servizio e i gruppi di sicurezza del cluster per eventuali problemi con Application Load Balancer

Le destinazioni non sicure nei gruppi di destinazione di Application Load Balancer si verificano per due motivi. O la policy di traffico del servizio, spec.externalTrafficPolicy, è impostata su Local (Locale) anziché su Cluster. Oppure ai gruppi di nodi in 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 policy di traffico sia configurata correttamente:

$ kubectl get svc SERVICE_NAME -n YOUR_NAMESPACE -o=jsonpath='{.spec.externalTrafficPolicy}{"\n"}'

Output di esempio:

Local

Modifica l'impostazione in Cluster:

$ kubectl edit svc SERVICE_NAME -n YOUR_NAMESPACE

Controlla i gruppi di sicurezza del cluster

1.    Apri la console di Amazon EC2.

2.    Seleziona l'istanza integra.

3.    Scegli la scheda Security (Sicurezza) e controlla le regole in ingresso del gruppo di sicurezza.

4.    Seleziona l'istanza non sicura.

5.    Scegli la scheda Security (Sicurezza) e controlla le regole in ingresso del gruppo di sicurezza.

Se il gruppo di sicurezza per ogni istanza è diverso, è necessario modificare la regola in ingresso di sicurezza nella console del gruppo di sicurezza:

1.    Dalla scheda Security (Sicurezza), seleziona l'ID del gruppo di sicurezza.

2.    Scegli il pulsante Edit inbound rules (Modifica le regole in entrata) per modificare le regole in ingresso.

3.    Aggiungi regole in entrata per consentire il traffico dagli altri gruppi di nodi nel cluster.

Verifica che il tuo servizio sia configurato per targetPort

targetPort deve corrispondere a containerPort nel pod a cui il servizio sta inviando 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'}"

Output di esempio:

alb-instance 8080 TCP

Nell'output di esempio precedente, 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

AWS Load Balancer Controller deve disporre delle autorizzazioni corrette per aggiornare i gruppi di sicurezza per consentire il traffico dal bilanciatore del carico alle istanze o ai pod. Se il controller non dispone delle autorizzazioni corrette, vengono visualizzati degli errori.

Verifica la presenza di errori nei log di implementazione di AWS Load Balancer Controller:

$ kubectl logs deploy/aws-load-balancer-controller -n kube-system

Verifica la presenza di errori nei singoli log dei pod dei 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 Kubernetes.

Controlla le annotazioni in ingresso per eventuali problemi con Application Load Balancer

Per problemi con Application Load Balancer, controlla le annotazioni in 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.

Output di esempio:

Name:             alb-instance-ingress
Namespace:        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 in ingresso specifiche per il tuo caso d'uso, consulta Annotazioni in ingresso (dal sito Web Kubernetes).

Controlla le annotazioni del servizio Kubernetes per eventuali 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

Output di esempio:

Name:                     nlb-ip
Namespace:                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: prendi nota di APPLICATION_POD_IP. Ne avrai bisogno per eseguire un comando di controllo dell'integrità.

Per trovare le annotazioni del servizio Kubernetes specifiche per il tuo caso d'uso, consulta Annotazioni sui servizio (dal sito Web Kubernetes).

Testa manualmente un controllo dell'integrità

Controlla l'indirizzo IP del pod dell'applicazione:

$ kubectl get pod -n YOUR_NAMESPACE -o wide

Esegui un pod di test per testare manualmente un controllo dell'integrità all'interno del cluster per i controlli dell'integrità HTTP:

$ kubectl run -n YOUR_NAMESPACE troubleshoot -it --rm --image=amazonlinux -- /bin/bash

Per i controlli dell'integrità HTTP:

# curl -Iv APPLICATION_POD_IP/HEALTH_CHECK_PATH

Nota: sostituisci APPLICATION_POD_IP con l'IP del pod dell'applicazione e HEALTH_CHECK_PATH con il percorso di controllo dell'integrità del gruppo di destinazione ALB.

Comando di esempio:

# curl -Iv 192.168.81.137

Output di esempio:

* 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, significa che l'applicazione sta rispondendo correttamente sul percorso del controllo dell'integrità.

Se il codice di stato della risposta HTTP è 3xx o 4xx, è possibile modificare il percorso del controllo dell'integrità. La seguente annotazione può rispondere con 200 OK:

alb.ingress.kubernetes.io/healthcheck-path: /ping

-oppure-

Puoi utilizzare la seguente annotazione sulla risorsa in ingresso per aggiungere un intervallo di codici di stato della risposta al controllo dell'integrità eseguito correttamente:

alb.ingress.kubernetes.io/success-codes: 200-399

Per i controlli dell'integrità TCP, utilizza il seguente comando per installare il comando netcat:

# yum update -y && yum install -y nc

Testa i controlli dell'integrità TCP:

# nc -z -v APPLICATION_POD_IP CONTAINER_PORT_NUMBER

Nota: sostituisci APPLICATION_POD_IP con l'IP del pod dell'applicazione e CONTAINER_PORT_NUMBER con la porta del container.

Comando di esempio:

# nc -z -v 192.168.81.137 80

Output di esempio:

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 le reti

Per problemi di rete, verifica quanto segue:

• I gruppi di nodi multipli nel cluster EKS possono comunicare liberamente tra loro
• La lista di controllo degli accessi di rete (ACL di rete) associata alla sottorete in cui sono in esecuzione i pod consente il traffico proveniente dall'intervallo CIDR della sottorete del bilanciatore del carico
• L'ACL di rete associata alla sottorete del bilanciatore del carico dovrebbe consentire il traffico di ritorno sull'intervallo di porte effimere dalla sottorete in cui sono in esecuzione i pod
• La tabella di routing consente il traffico locale dall'interno dell'intervallo CIDR del VPC

Riavvia il kube-proxy

Se il kube-proxy in esecuzione su ciascun nodo non funziona correttamente, potrebbe non riuscire ad aggiornare le regole iptables per il servizio e gli endpoint. Riavvia il kube-proxy per forzarlo a ricontrollare e ad aggiornare le regole iptables:

kubectl rollout restart daemonset.apps/kube-proxy -n kube-system

Output di esempio:

daemonset.apps/kube-proxy restarted

Informazioni correlate

In che modo posso configurare un Application Load Balancer tramite AWS Load Balancer Controller su un gruppo di nodi Amazon EC2 in Amazon EKS?

Come faccio a risolvere i problemi del bilanciatore del carico del servizio per Amazon EKS?

Come posso assegnare un tag alle sottoreti di Amazon VPC in un cluster di Amazon EKS per l'individuazione automatica delle sottoreti per il bilanciatore del carico o il controller in ingresso?

---