Wie behebe ich fehlerhafte Ziele für Network Load Balancer in Amazon EKS?

Letzte Aktualisierung: 06.01.2022

Ich möchte fehlerhafte Ziele für Network Load Balancer in meinem Amazon Elastic Kubernetes Service (Amazon EKS) auflösen.

Kurzbeschreibung

Im Folgenden sind häufige Gründe aufgeführt, warum die Ziele für Ihren Network Load Balancer fehlerhaft sind:

  • Die Zustandsprüfung ist falsch konfiguriert. Um dieses Problem zu beheben, starten Sie die Integritätsprüfung manuell von einem Host-Computer aus, der in der Amazon Virtual Private Cloud (Amazon VPC) ausgeführt wird.
  • Es gibt eine unerwartete Ausnahme vom Pod. Um dieses Problem zu beheben, befolgen Sie die Schritte zur Fehlerbehebung im Lösungsabschnitt Prüfen, ob eine unerwartete Ausnahme vom Pod vorliegt.
  • Ein Network Load Balancer mit der externalTrafficPolicy ist auf Lokal festgelegt (von der Kubernetes-Website), wobei ein benutzerdefiniertes Amazon-VPC-DNS in den DHCP-Optionen festgelegt ist. Um dieses Problem zu beheben, patchen Sie kube-proxy mit dem Flag zum Überschreiben des Hostnamens.

Hinweis: Sie können feststellen, ob der Zielgruppentyp eine IP-Adresse oder Instance ist, indem Sie prüfen, ob die Service-Anmerkung service.beta.kubernetes.io/aws-load-balancer-nlb-target-type vorhanden ist.

Auflösung

Prüfen Sie, ob es sich bei der Zielgruppe um eine IP-Adresse oder Instance handelt

Führen Sie den folgenden Befehl aus:

kubectl get service service_name -o yaml

Hinweis: Ersetzen Sie service_name durch den Namen Ihres Services. Wenn die Anmerkung service.beta.kubernetes.io/aws-load-balancer-nlb-target nicht vorhanden ist, ist der Standardzieltyp eine Instance.

Stellen Sie sicher, dass die Zustandsprüfung korrekt konfiguriert ist

Prüfen Sie, welche Anmerkungen von Elastic Load Balancing (ELB) (aus der Kubernetes-Website) für Ihren Service konfiguriert sind:

`kubectl get service service_name -o yaml`

Beispielausgabe:

service.beta.kubernetes.io/aws-load-balancer-healthcheck-healthy-threshold: "2"
# The number of successive successful health checks required for a backend to be considered healthy for traffic. Defaults to 2, must be between 2 and 10

service.beta.kubernetes.io/aws-load-balancer-healthcheck-unhealthy-threshold: "3"
# The number of unsuccessful health checks required for a backend to be considered unhealthy for traffic. Defaults to 6, must be between 2 and 10

service.beta.kubernetes.io/aws-load-balancer-healthcheck-interval: "20"
# The approximate interval, in seconds, between health checks of an individual instance. Defaults to 10, must be between 5 and 300

service.beta.kubernetes.io/aws-load-balancer-healthcheck-timeout: "5"
# The amount of time, in seconds, during which no response means a failed health check. This value must be less than the service.beta.kubernetes.io/aws-load-balancer-healthcheck-interval value. Defaults to 5, must be between 2 and 60

service.beta.kubernetes.io/aws-load-balancer-healthcheck-protocol: TCP
service.beta.kubernetes.io/aws-load-balancer-healthcheck-port: traffic-port
# can be integer or traffic-port

service.beta.kubernetes.io/aws-load-balancer-healthcheck-path
# health check path.

Wenn die vorhergehenden Anmerkungen falsch konfiguriert sind, können die Ziele fehlerhaft sein.

Starten Sie die Zustandsprüfung manuell von einem Host-Computer aus, der in der Amazon VPC ausgeführt wird

Führen Sie zum Beispiel Zieltypen den folgenden curl-Befehl mit NodePort aus:

curl-ivk node_IP:NodePort

Hinweis: Ersetzen Sie node_IP durch die IP-Adresse Ihres Knotens.

Führen Sie für Zieltypen von IP-Adressen den folgenden curl-Befehl aus:

curl -ivk pod_IP:pod_port

Hinweis: Ersetzen Sie pod_IP durch die IP-Adresse Ihres Pods und pod_port durch den Port Ihres Pods.

Prüfen Sie, ob es eine unerwartete Ausnahme vom Pod gibt

Instance-Zieltyp

In der Service-Spezifikation finden Sie die aktuellen Anmerkungen zur Konfiguration der Zustandsprüfung (von der GitHub-Website):

kubectl get service service_name -o yaml

Prüfen Sie, ob Endpunkte vorhanden sind, um zu überprüfen, ob sich Pods hinter dem Service befinden:

kubectl get endpoints service_name -o yaml

Wenn für den Service keine Endpunkte vorhanden sind, überprüfen Sie, ob die Pod-Markierung und Service-Markierungen übereinstimmen:

kubectl describe service
kubectl describe pod pod_name or kubectl get pod --show-labels

Hinweis: Ersetze pod_name durch den Namen deines Pods.

Prüfen Sie, ob sich die Pods im Status Ausführen befinden:

kubectl get pod -o wide

Überprüfen Sie den Status der Pods, um sicherzustellen, dass die Pods ohne Neustarts ausgeführt werden:

kubectl get pods -o wide

Wenn es Neustarts gibt, sammeln Sie die Pod-Protokolle, um die Ursache zu ermitteln:

kubectl logs pod_name
kubectl logs pod_name --previous

Melden Sie sich in der Amazon VPC bei einem Host-Computer an, wo Sie mit dem Knoten kommunizieren können.

Verwenden Sie den curl-Befehl mit NodePort, um zu überprüfen, ob die Pods den erwarteten HTTP-Statuscode zurückgeben:

curl node_IP:NodePort

Wenn der curl-Befehl nicht den erwarteten HTTP-Statuscode zurückgegeben hat, geben die Backend-Pods auch nicht den erwarteten HTTP-Statuscode zurück.

Verwenden Sie denselben Host-Computer, um eine Verbindung zur IP-Adresse des Pods herzustellen und zu überprüfen, ob der Pod richtig konfiguriert ist:

curl pod_IP:pod_port

Wenn der curl-Befehl nicht den erwarteten HTTP-Statuscode zurückgegeben hat, ist der Pod nicht richtig konfiguriert.

Hinweis: Wenn die externalTrafficPolicy des Services (von der Kubernetes-Website) auf Lokal festgelegt ist, werden nur die Knoten, auf denen die Backend-Pods des Services ausgeführt werden, als fehlerfreie Ziele angesehen.

Zieltyp der IP-Adresse

In der Service-Spezifikation finden Sie die aktuellen Anmerkungen zur Konfiguration der Zustandsprüfung (von der GitHub-Website):

kubectl get service service_name -o yaml

Melden Sie sich in der Amazon VPC bei einem Host-Computer an und verwenden Sie den curl-Befehl, um mit der IP-Adresse des Pods zu kommunizieren:

curl pod_IP:pod_port

Wenn der curl-Befehl nicht den erwarteten HTTP-Statuscode zurückgegeben hat, ist der Pod nicht richtig konfiguriert.

Patchen Sie den Kube-Proxy mit dem Flag zum Überschreiben

Ändern Sie den kube-proxy-Daemonset-Spezifikationsbefehl, args und env, mit:

---
spec:
  template:
    spec:
      containers:
      - name: kube-proxy
        command: [ "/bin/sh" ]
        args:
        - -c
        - |
          kube-proxy --v=2 --hostname-override=$(NODE_NAME) --config=/var/lib/kube-proxy-config/config
        env:
        - name: NODE_NAME
          valueFrom:
            fieldRef:
              apiVersion: v1
              fieldPath: spec.nodeName

Wenn zum Beispiel externalTrafficPolicy auf Cluster oder Lokal festgelegt ist, ist die standardmäßige Eingangseinstellung der Knotensicherheitsgruppe für NodePort 0.0.0.0/0. Wenn externalTrafficPolicy auf Lokal festgelegt ist, wird eine zusätzliche Zustandsprüfung NodePort konfiguriert, um CIDR-IP-Adressbereiche für Subnetze zuzulassen.

Um die Quell-IP-Adresse in der Knotensicherheitsgruppe für NodePort zu steuern, fügen Sie loadBalancerSourceRanges in der Spezifikation hinzu und schließen die Bereiche ein:

spec:
loadBalancerSourceRanges:
- "143.231.0.0/16"
- "xx.yy.zz.zz/24"

Hinweis: Wenn die .spec.loadBalancerSourceRanges nicht festgelegt ist, erlaubt Kubernetes Datenverkehr von 0.0.0.0/0 zu den Knotensicherheitsgruppen. Wenn die Knoten über öffentliche IP-Adressen verfügen, kann Datenverkehr ohne Network Load Balancer auch jede Instance in den geänderten Sicherheitsgruppen erreichen.


War dieser Artikel hilfreich?


Benötigen Sie Hilfe zur Fakturierung oder technischen Support?