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

Letzte Aktualisierung: 13.12.2021

Meine Load Balancer besteht die Zustandsprüfung in meinem Amazon Elastic Kubernetes Service (Amazon EKS) weiterhin nicht.

Kurzbeschreibung

Um Probleme bei der Zustandsprüfung mit der Load Balancer in Ihrem Amazon EKS zu beheben, führen Sie die Schritte in den folgenden Abschnitten aus:

  • Pod-Status prüfen
  • Pod- und Service-Label-Selektoren prüfen
  • Nach fehlenden Endpunkten suchen
  • Richtlinie für den Service-Datenverkehr und die Cluster-Sicherheitsgruppen für Application Load Balancer prüfen
  • Überprüfen, ob Ihr EKS für targetPort konfiguriert ist
  • Überprüfen, dass Ihr AWS-Load-Balancer-Controller über die richtigen Berechtigungen verfügt
  • Zugangsanmerkungen auf Probleme mit Application Load Balancern prüfen
  • Anmerkungen des Kubernetes-Dienstes auf Probleme mit Network Load Balancern prüfen
  • Einen Zustandsprüfung manuell testen
  • Netzwerk prüfen
  • Kube-Proxy neu starten

Auflösung

Pod-Status prüfen

Prüfen Sie, ob sich der Pod im Status Wird ausgeführt 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   AGE
podname                        1/1     Running   0          16s

Hinweis: Wenn der Anwendungs-Container im Pod nicht ausgeführt wird, wird die Zustandsprüfung der Load Balancer nicht beantwortet und schlägt fehl.

Pod- und Service-Label-Selektoren prü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     LABELS
alb-instance-6cc5cd9b9-prnxw   1/1     Running   0          2d19h   app=alb-instance,pod-template-hash=6cc5cd9b9

Um zu überprüfen, ob Ihr Kubernetes-Service die Pod-Labels verwendet, führen Sie den folgenden Befehl aus, um zu überprüfen, dass 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-Service 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 einem Endpunktobjekt. Wenn Sie ein falsches Label ausgewählt haben, wird kein Endpunkt angezeigt.

Führen Sie den folgenden Befehl aus:

$ kubectl describe svc SERVICE_NAME -n YOUR_NAMESPACE

Beispielausgabe:

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>

Prüfen Sie, ob der Endpunkt fehlt:

$ kubectl get endpoints SERVICE_NAME -n YOUR_NAMESPACE

Beispielausgabe:

NAME           ENDPOINTS                                AGE
alb-instance   <none>                                   2d20h

Überprüfen Sie die Richtlinie für den Dienstverkehr und die Cluster-Sicherheitsgruppen auf Probleme mit Application Load Balancern

Falsche Ziele in den Zielgruppen des Application Load Balancers treten aus zwei Gründen auf. Entweder ist die Dienstverkehr-Richtlinie, spec.externalTrafficPolicy, auf Local statt auf Cluster festgelegt. oder den Knotengruppen in einem Cluster sind verschiedene Cluster-Sicherheitsgruppen zugeordnet, und der Datenverkehr kann nicht frei 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

Überprüfen der Cluster-Sicherheitsgruppen

1.    Öffnen Sie die Amazon-EC2-Konsole.

2.    Wählen Sie die fehlerfreie Instanz aus.

3.    Wählen Sie die Registerkarte Sicherheit und überprüfen Sie die Zugangsregeln der Sicherheitsgruppen.

4.    Wählen Sie die fehlerhafte Instanz aus.

5.    Wählen Sie die Registerkarte Sicherheit und überprüfen Sie die Zugangsregeln der Sicherheitsgruppen.

Wenn die Sicherheitsgruppe für jede Instanz unterschiedlich ist, müssen Sie die Sicherheitszugangsregel in der Sicherheitsgruppenkonsole ändern:

1.    Wählen Sie auf der Registerkarte Sicherheit die Sicherheitsgruppen-ID aus.

2.    Wählen Sie die Schaltfläche Eingehende Regeln bearbeiten, um Zugangsregeln zu ändern.

3.    Fügen Sie eingehende Regeln hinzu, um Datenverkehr von den anderen Knotengruppen im Cluster zu erlauben.

Stellen Sie sicher, dass Ihr Dienst für targetPort konfiguriert ist

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

Führen Sie den folgenden Befehl aus, um zu überprüfen, worauf Ihr targetPort eingestellt 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 vorherigen Beispielausgabe ist der targetPort auf 8080 eingestellt. Da der containerPort jedoch auf 80 festgelegt ist, müssen Sie den targetPort auf 80 einstellen.

Überprüfen, 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 Datenverkehr vom Load Balancer zu Instances oder Pods zu erlauben. Wenn der Controller nicht über die richtigen Berechtigungen verfügt, erhalten Sie Fehlermeldungen.

Prüfen Sie die Bereitstellungsprotokolle von AWS Load Balancer Controller auf Fehler:

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

Prüfen Sie die einzelnen Controller-Pod-Protokolle auf Fehler:

$ 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.

Zugangsanmerkungen auf Probleme mit Application Load Balancern prüfen

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

$ kubectl describe ing INGRESS_NAME -n YOUR_NAMESPACE

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

Beispielausgabe:

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

Informationen zu Zugangsanmerkungen, die für Ihren Anwendungsfall spezifisch sind, finden Sie unter Zugangsanmerkungen (von der Kubernetes-Website).

Anmerkungen des Kubernetes-Dienstes auf Probleme mit Network Load Balancern prüfen

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

$ kubectl describe svc SERVICE_NAME -n YOUR_NAMESPACE

Beispielausgabe:

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>

Hinweis: Beachten Sie die APPLICATION_POD_IP. Sie benötigen sie, um einen Befehl zur Zustandsprüfung auszuführen.

Kubernetes-Service-Anmerkungen, die für Ihren Anwendungsfall spezifisch sind, finden Sie unter Service-Anmerkungen (von der Kubernetes-Website).

Einen Zustandsprüfung manuell testen

Prüfen Sie die Pod-IP-Adresse Ihrer Anwendung:

$ kubectl get pod -n YOUR_NAMESPACE -o wide

Führen Sie einen Test-Pod aus, um im Cluster manuell eine Zustandsprüfung auf HTTP-Zustandsprüfungen durchzuführen:

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

Für HTTP-Zustandsprüfungen:

# curl -Iv APPLICATION_POD_IP/HEALTH_CHECK_PATH

Hinweis: Ersetzen Sie APPLICATION_POD_IP durch Ihre Anwendungs-Pod-IP und HEALTH_CHECK_PATH durch den Zustandsprüfpfad der ALB-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

Prüfen Sie den Statuscode der HTTP-Antwort. Wenn der Statuscode der Antwort 200 OK lautet, bedeutet dies, dass Ihre Anwendung auf dem Zustandsprüfpfad korrekt reagiert.

Wenn der Statuscode der HTTP-Antwort 3xx oder 4xx lautet, können Sie den Zustandsprüfpfad ändern. Die folgende Anmerkung kann mit 200 OK antworten:

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

-oder-

Sie können die folgende Anmerkung für die Zugangsressource verwenden, um einen Statuscodebereich für eine erfolgreiche Antwort auf die 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 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 prüfen

Bei Netzwerkproblemen überprüfen Sie Folgendes:

  • Die mehreren Knotengruppen im EKS-Cluster können frei miteinander kommunizieren
  • Die Netzwerk-Zugriffskontrollliste (Netzwerk-ACL), die mit dem Subnetz verknüpft ist, in dem Ihre Pods ausgeführt werden, erlaubt Datenverkehr aus dem CIDR-Bereich des Load-Balancer-Subnetzes
  • Die Netzwerk-ACL, die mit Ihrem Load-Balancer-Subnetz verknüpft ist, sollte gegenläufigen Datenverkehr über den ephemeren Portbereich aus dem Subnetz erlauben, in dem die Pods ausgeführt werden
  • Die Routing-Tabelle erlaubt lokalen Datenverkehr aus dem VPC-CIDR-Bereich

Kube-Proxy neu starten

Wenn sich der Kube-Proxy, der auf jedem Knoten ausgeführt wird, nicht korrekt verhält, kann er die iptables-Regeln für den Service und die Endpunkte möglicherweise nicht aktualisieren. Starten Sie den Kube-Proxy neu, damit er die iptables-Regeln erneut überprüft und aktualisiert:

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

Beispielausgabe:

daemonset.apps/kube-proxy restarted

War dieser Artikel hilfreich?


Benötigen Sie Hilfe zur Fakturierung oder technischen Support?