Wie behebe ich eine fehlgeschlagene Zustandsprüfung für einen Load Balancer in Amazon EKS?
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
Relevante Informationen
Wie behebe ich Probleme mit Service-Load-Balancern für Amazon EKS?
Relevanter Inhalt
- AWS OFFICIALAktualisiert vor 2 Jahren
- AWS OFFICIALAktualisiert vor einem Jahr
- AWS OFFICIALAktualisiert vor einem Jahr
- AWS OFFICIALAktualisiert vor einem Jahr