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

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.

---