Warum ist der Status meines Worker-Knotens „fehlerhaft“, wenn ich den NGINX Ingress Controller mit Amazon EKS verwende?
Ich verwende den NGINX Ingress Controller, um die Ingress-Ressource verfügbar zu machen. Meine Worker-Knoten von Amazon Elastic Kubernetes Service (Amazon EKS) verwenden den Network Load Balancer jedoch nicht.
Kurzbeschreibung
Um die Client-IP zu erhalten, setzt der NGINX Ingress Controller die Option spec.ExternalTrafficPolicy auf Lokal. Außerdem leitet es Anfragen nur an fehlerfreie Worker-Knoten weiter.
Gehen Sie in den folgenden Schritten vor, um den Status Ihrer Worker-Knoten zu beheben und Ihre Verkehrsrichtlinie zu aktualisieren.
Hinweis: Es ist nicht erforderlich, die Cluster-IP-Adresse oder die Client-IP-Adresse beizubehalten.
Lösung
Zustandsstatus Ihres Worker-Knotens prüfen
Hinweis: Die folgenden Beispiele verwenden den NGINX Ingress Controller v1.5.1, der auf EKS Cluster v1.23 läuft.
1. Erstellen Sie die erforderlichen Ressourcen für den NGINX Ingress Controller (von der Kubernetes-Website) in Ihrem Cluster:
$ kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.5.1/deploy/static/provider/aws/deploy.yaml
Standardmäßig erstellt der NGINX Ingress Controller den Kubernetes-Dienst ingress-nginx-Controller mit der Option .spec.ExternalTrafficPolicy auf Lokal (von der GitHub-Website).
2. Prüfen Sie, ob die Richtlinie für externen Datenverkehr (von der Kubernetes-Website) auf Lokal festgelegt ist:
$ kubectl -n ingress-nginx describe svc ingress-nginx-controller
Sie erhalten eine Ausgabe, die der folgenden ähnelt:
Name: ingress-nginx-controller Namespace: ingress-nginx Labels: app.kubernetes.io/component=controller app.kubernetes.io/instance=ingress-nginx app.kubernetes.io/managed-by=Helm app.kubernetes.io/name=ingress-nginx app.kubernetes.io/version=1.0.2 helm.sh/chart=ingress-nginx-4.0.3 Annotations: service.beta.kubernetes.io/aws-load-balancer-backend-protocol: tcp service.beta.kubernetes.io/aws-load-balancer-cross-zone-load-balancing-enabled: true service.beta.kubernetes.io/aws-load-balancer-type: nlb Selector: app.kubernetes.io/component=controller,app.kubernetes.io/instance=ingress-nginx,app.kubernetes.io/name=ingress-nginx Type: LoadBalancer IP Families: <none> IP: 10.100.115.226 IPs: 10.100.115.226 LoadBalancer Ingress: a02245e77404f4707a725d0b977425aa-5b97f717658e49b9.elb.eu-west-1.amazonaws.com Port: http 80/TCP TargetPort: http/TCP NodePort: http 31748/TCP Endpoints: 192.168.43.203:80 Port: https 443/TCP TargetPort: https/TCP NodePort: https 30045/TCP Endpoints: 192.168.43.203:443 Session Affinity: None External Traffic Policy: Local HealthCheck NodePort: 30424 Events: <none>
Hinweis: Die Einstellung Lokal verwirft Pakete, die an Kubernetes-Knoten gesendet werden und muss keine Instances des NGINX Ingress Controllers ausführen. Weisen Sie NGINX-Pods (von der Kubernetes-Website) den Knoten zu, für die Sie den NGINX Ingress Controller planen möchten.
3. Überprüfen Sie den iptables-Befehl, der die DROP-Regeln auf den Knoten einrichtet, auf denen keine Instances des NGINX Ingress Controllers ausgeführt werden:
$ sudo iptables-save | grep -i "no local endpoints" -A KUBE-XLB-CG5I4G2RS3ZVWGLK -m comment --comment "ingress-nginx/ingress-nginx-controller:http has no local endpoints " -j KUBE-MARK-DROP -A KUBE-XLB-EDNDUDH2C75GIR6O -m comment --comment "ingress-nginx/ingress-nginx-controller:https has no local endpoints " -j KUBE-MARK-DROP
Richtlinienoption festlegen
Aktualisieren Sie die Option spec.externalTrafficPolicy auf Cluster:
$ kubectl -n ingress-nginx patch service ingress-nginx-controller -p '{"spec":{"externalTrafficPolicy":"Cluster"}}' service/ingress-nginx-controller patched
Standardmäßig führen NodePort-Services die Übersetzung der Quell-IP-Adresse durch (von der Kubernetes-Website). Für NGINX bedeutet dies, dass die Quell-IP-Adresse einer HTTP-Anforderung immer die IP-Adresse des Kubernetes-Knotens ist, der die Anforderung erhalten hat. Wenn Sie externalTrafficPolicy (.spec.ExternalTrafficPolicy) in der **ingress-nginx-**Servicespezifikation auf Cluster setzen, behält der eingehende Datenverkehr die Quell-IP-Adresse nicht bei. Weitere Informationen finden Sie unter Beibehaltung der Quell-IP-Adresse des Clients (auf der Kubernetes-Website).

Relevanter Inhalt
- AWS OFFICIALAktualisiert vor 2 Jahren
- AWS OFFICIALAktualisiert vor einem Jahr
- Wie stelle ich externen Zugriff auf mehrere Kubernetes-Services in meinem Amazon EKS-Cluster bereit?AWS OFFICIALAktualisiert vor 3 Jahren