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

9 minuti di lettura
0

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:

  1. Apri la console Amazon EC2.
  2. Seleziona l'istanza integra.
  3. Scegli la scheda Sicurezza, quindi controlla le regole di ingresso del gruppo di sicurezza.
  4. Seleziona l'istanza non integra.
  5. 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

Come posso configurare un Application Load Balancer utilizzando AWS Load Balancer Controller su un gruppo di nodi Amazon EC2 in Amazon EKS?

Come posso risolvere i problemi relativi ai sistemi di bilanciamento del carico creati dal controller di servizio Kubernetes in Amazon EKS?

How do I automatically discover the subnets that my Application Load Balancer uses in Amazon EKS?

AWS UFFICIALE
AWS UFFICIALEAggiornata 9 mesi fa