Stay up to date with the latest from the Knowledge Center. See all new Knowledge Center articles published in the last month, and re:Post's top contributors.
Wie behebe ich eine fehlgeschlagene Zustandsprüfung für einen Load Balancer in Amazon EKS?
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:
- Öffnen Sie die Amazon-EC2-Konsole.
- Wählen Sie die fehlerfreie Instance aus.
- Wählen Sie die Registerkarte Sicherheit und überprüfen Sie dann die Regeln für den Zugriff auf Sicherheitsgruppen.
- Wählen Sie die fehlerhafte Instance aus.
- 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
Relevanter Inhalt
- AWS OFFICIALAktualisiert vor einem Jahr