Wie behebe ich eine fehlgeschlagene Zustandsprüfung für einen Load Balancer in Amazon EKS?

Lesedauer: 8 Minute
0

Mein Load Balancer besteht bei der Zustandsprüfung in meinem Amazon Elastic Kubernetes Service (Amazon EKS) nicht.

Behebung

Führen Sie die Schritte in den folgenden Abschnitten aus, um Probleme mit der Zustandsprüfung mit dem Load Balancer in Amazon EKS zu beheben.

Status des Pod prüfen

Prüfen Sie, ob sich der Pod im Status Running befindet und die Container in den Pods bereit sind:

$ kubectl get pod -n YOUR_NAMESPACE

Hinweis: Ersetzen Sie YOUR_NAMESPACE durch Ihren Kubernetes-Namespace.

Beispielausgabe:

NAME                           READY   STATUS    RESTARTS   AGEpodname                        1/1     Running   0          16s

Wenn der Anwendungscontainer des Pods nicht im Status Running ist, wird die Load-Balancer-Zustandsprüfung nicht beantwortet und schlägt fehl.

Pod- und Dienst-Label-Selektoren überprüfen

Führen Sie für Pod-Labels den folgenden Befehl aus:

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

Beispielausgabe:

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

Um zu überprüfen, ob Ihr Kubernetes-Dienst die Pod-Labels verwendet, führen Sie den folgenden Befehl aus, um zu überprüfen, ob die Ausgabe mit den Pod-Labels übereinstimmt:

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

Hinweis: Ersetzen Sie **SERVICE_NAME ** durch Ihren Kubernetes-Dienst und YOUR_NAMESPACE durch Ihren Kubernetes-Namespace.

Beispielausgabe:

{"app":"alb-instance"}

Nach fehlenden Endpunkten suchen

Der Kubernetes-Controller für den Service Selektor sucht kontinuierlich nach Pods, die seinem Selektor entsprechen, und veröffentlicht dann Aktualisierungen an ein Endpunktobjekt. Wenn Sie ein falsches Label ausgewählt haben, wird kein Endpunkt angezeigt.

Führen Sie folgenden Befehl aus:

$ kubectl describe svc SERVICE_NAME -n YOUR_NAMESPACE

Beispielausgabe:

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>

Prüfen, ob ein Endpunkt fehlt:

$ kubectl get endpoints SERVICE_NAME -n YOUR_NAMESPACE

Beispielausgabe:

NAME           ENDPOINTS                                AGEalb-instance   <none>                                   2d20h

Die Dienstverkehrsrichtlinie und die Cluster-Sicherheitsgruppen auf Probleme mit Application Load Balancers überprüfen

Fehlerhafte Ziele in den Application-Load-Balancer-Zielgruppen treten aus zwei Gründen auf:

  • Die Dienstverkehrsrichtlinie spec.externalTrafficPolicy ist auf Local statt auf Cluster gesetzt.
  • Den Knotengruppen in einem Cluster sind verschiedene Cluster-Sicherheitsgruppen zugeordnet, und der Datenverkehr kann nicht ungehindert zwischen den Knotengruppen fließen.

Stellen Sie sicher, dass die Verkehrsrichtlinie korrekt konfiguriert ist:

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

Beispielausgabe:

Local

Ändern Sie die Einstellung auf Cluster:

$ kubectl edit svc SERVICE_NAME -n YOUR_NAMESPACE

Cluster-Sicherheitsgruppen überprüfen

Führen Sie die folgenden Schritte aus:

  1. Öffnen Sie die Amazon-EC2-Konsole.
  2. Wählen Sie die fehlerfreie Instance aus.
  3. Wählen Sie die Registerkarte Sicherheit und überprüfen Sie dann die Regeln für den Zugriff auf Sicherheitsgruppen.
  4. Wählen Sie die fehlerhafte Instance aus.
  5. Wählen Sie die Registerkarte Sicherheit und überprüfen Sie dann die Regeln für den Zugriff auf Sicherheitsgruppen.
    Wenn die Sicherheitsgruppe für jede Instance unterschiedlich ist, müssen Sie die Sicherheitseingangsregel in der Sicherheitsgruppenkonsole ändern:
    Wählen Sie auf der Registerkarte Sicherheit die Sicherheitsgruppen-ID aus.
    Wählen Sie Regeln für eingehenden Verkehr bearbeiten, um die Eingangsregeln zu ändern.
    Fügen Sie Regeln für eingehenden Datenverkehr hinzu, um den Datenverkehr von den anderen Knotengruppen im Cluster zuzulassen.

Sicherstellen, dass Ihr Dienst für targetPort konfiguriert ist

Ihr targetPort muss mit dem **containerPort ** in dem Pod übereinstimmen, an den der Dienst Datenverkehr sendet.

Führen Sie den folgenden Befehl aus, um zu überprüfen, wofür Ihr targetPort konfiguriert ist:

$ kubectl get svc  SERVICE_NAME -n YOUR_NAMESPACE -o=jsonpath="{.items[*]}{.metadata.name}{'\t'}{.spec.ports[].targetPort}{'\t'}{.spec.ports[].protocol}{'\n'}"

Beispielausgabe:

alb-instance    8080    TCP

In der Beispielausgabe ist der targetPort auf 8080 konfiguriert. Da der containerPort jedoch auf 80 gesetzt ist, müssen Sie den targetPort auf 80 konfigurieren.

Sicherstellen, dass Ihr AWS Load Balancer Controller über die richtigen Berechtigungen verfügt

Der AWS Load Balancer Controller muss über die richtigen Berechtigungen zum Aktualisieren von Sicherheitsgruppen verfügen, um den Datenverkehr vom Load Balancer zu Instances oder Pods zuzulassen. Wenn der Controller nicht über die richtigen Berechtigungen verfügt, erhalten Sie eine Fehlermeldung.

Suchen Sie in den Bereitstellungsprotokollen des AWS Load Balancer Controllers nach Fehlern:

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

Suchen Sie in den einzelnen Controller-Pod-Protokollen nach Fehlern:

$ kubectl logs CONTROLLER_POD_NAME -n YOUR_NAMESPACE

Hinweis: Ersetzen Sie CONTROLLER_POD_NAME durch Ihren Controller-Pod-Namen und YOUR_NAMESPACE durch Ihren Kubernetes-Namespace.

Die Eingangsanmerkungen auf Probleme mit Application Load Balancers überprüfen

Bei Problemen mit dem Application Load Balancer überprüfen Sie die Kubernetes-Eingangsanmerkungen:

$ kubectl describe ing INGRESS_NAME -n YOUR_NAMESPACE

Hinweis: Ersetzen Sie INGRESS_NAME durch den Namen Ihres Kubernetes-Eingangs und YOUR_NAMESPACE durch Ihren Kubernetes-Namespace.

Beispielausgabe:

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

Informationen zu Eingangsanmerkungen, die für Ihren Anwendungsfall spezifisch sind, finden Sie unter Ingress Annotations auf der Kubernetes Website.

Die Anmerkungen zu Kubernetes Service auf Probleme mit Network Load Balancern überprüfen

Bei Problemen mit dem Network Load Balancer überprüfen Sie die Anmerkungen zu Kubernetes Service:

$ kubectl describe svc SERVICE_NAME -n YOUR_NAMESPACE

Beispielausgabe:

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>

Hinweis: Notieren Sie sich den Wert von APPLICATION_POD_IP, um in einem späteren Schritt einen Zustandsprüfungsbefehl auszuführen.

Informationen zu Kubernetes Service, die für Ihren Anwendungsfall spezifisch sind, finden Sie unter Service Annotations auf der Kubernetes Website.

Eine manuelle Zustandsprüfung durchführen

Überprüfen Sie die IP-Adresse Ihres Anwendungs-Pods:

$ kubectl get pod -n YOUR_NAMESPACE -o wide

Führen Sie einen Test-Pod aus, um eine Zustandsprüfung innerhalb des Clusters manuell durchzuführen:

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

Führen Sie dann die HTTP-Zustandsprüfung durch:

# curl -Iv APPLICATION_POD_IP/HEALTH_CHECK_PATH

Hinweis: Ersetzen Sie APPLICATION_POD_IP durch die IP-Adresse Ihres Anwendungs-Pods und HEALTH_CHECK_PATH durch den Zustandsprüfungspfad der Application-Load-Balancer-Zielgruppe.

Beispielbefehl:

# curl -Iv 192.168.81.137

Beispielausgabe:

* 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

Überprüfen Sie den HTTP-Antwortstatuscode. Wenn der Antwortstatuscode 200 OK lautet, reagiert Ihre Anwendung korrekt auf den Zustandsprüfungspfad.

Wenn der HTTP-Antwortstatuscode 3xx oder 4xx lautet, ändern Sie Ihren Zustandsprüfungspfad. Die folgende Anmerkung antwortet mit 200 OK:

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

Oder:

Verwenden Sie die folgende Anmerkung zur Eingangsressource, um einen Statuscodebereich für eine erfolgreiche Zustandsprüfung hinzuzufügen:

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

Verwenden Sie für TCP-Zustandsprüfungen den folgenden Befehl, um den Befehl netcat zu installieren:

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

Testen Sie die TCP-Zustandsprüfungen:

# nc -z -v APPLICATION_POD_IP CONTAINER_PORT_NUMBER

Hinweis: Ersetzen Sie APPLICATION_POD_IP durch Ihre Anwendungs-Pod-IP-Adresse und CONTAINER_PORT_NUMBER durch Ihren Container-Port.

Beispielbefehl:

# nc -z -v 192.168.81.137 80

Beispielausgabe:

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.

Netzwerk überprüfen

Überprüfen Sie bei Netzwerkproblemen Folgendes:

  • Die verschiedenen Knotengruppen im EKS-Cluster können frei miteinander kommunizieren.
  • Die Netzwerk-Zugriffssteuerungsliste (Netzwerk-ACL), die dem Subnetz zugeordnet ist, in dem Ihre Pods ausgeführt werden, lässt Datenverkehr aus dem CIDR-Bereich des Load Balancer-Subnetzes zu.
  • Die Netzwerk-ACL, die Ihrem Load-Balancer-Subnetz zugeordnet ist, ermöglicht den Rückverkehr über den kurzlebigen Portbereich des Subnetzes, in dem die Pods ausgeführt werden.
  • Die Routing-Tabelle ermöglicht lokalen Verkehr innerhalb des VPC-CIDR-Bereichs.

Den Kube-Proxy neu starten

Wenn der Kube-Proxy, der auf jedem Knoten ausgeführt wird, nicht richtig funktioniert, kann der Kube-Proxy die Iptables-Regeln für den Dienst und die Endpunkte möglicherweise nicht aktualisieren. Starten Sie den Kube-Proxy neu, um ihn zu zwingen, die Iptables-Regeln erneut zu überprüfen und zu aktualisieren:

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

Beispielausgabe:

daemonset.apps/kube-proxy restarted

Ähnliche Informationen

Wie richte ich einen Application Load Balancer mithilfe des AWS Load Balancer Controllers auf einer Amazon-EC2-Knotengruppe in Amazon EKS ein?

Wie behebe ich Probleme mit Load Balancern, die vom Kubernetes-Servicecontroller in Amazon EKS erstellt wurden?

Wie kann ich die von meinem Application Load Balancer in Amazon EKS verwendeten Subnetze automatisch ermitteln?