Wie behebe ich Probleme, wenn ich den AWS Load Balancer Controller verwende, um einen Load Balancer zu erstellen?

Kurzbeschreibung

Der AWS Load Balancer Controller verwaltet Elastic Load Balancing für einen Amazon Elastic Kubernetes Service (Amazon EKS)-Cluster.

Der Controller stellt die folgenden Ressourcen zur Verfügung:

• Einen Application Load Balancer, wenn du einen Kubernetes-Ingress erstellst.
• Einen Network Load Balancer, wenn du einen Kubernetes-Service vom Typ LoadBalancer erstellst.
  Hinweis: Mit AWS Load Balancer Controller Version 2.3.0 oder höher kannst du einen Network Load Balancer entweder mit dem Instance- oder IP-Zieltyp erstellen.

Lösung

Stelle sicher, dass du alle Voraussetzungen für die Installation und Verwendung von AWS Load Balancer Controller erfüllst

Eine Liste der ersten Maßnahmen, die du ergreifen musst, findest du unter Voraussetzungen.

Führe den folgenden Befehl aus, um zu überprüfen, ob du den AWS Load Balancer Controller erfolgreich bereitgestellt hast:

kubectl get deployment -n kube-system aws-load-balancer-controller

Hinweis: Es hat sich bewährt, Version 2.4.4 oder höher zu verwenden.

Beispielausgabe:

NAME                           READY   UP-TO-DATE   AVAILABLE   AGE
aws-load-balancer-controller   2/2     2            2           84s

Wenn du einen Application Load Balancer verwendest, überprüfe, ob du über mindestens zwei Subnetze in verschiedenen Availability Zones verfügst. Ein Network Load Balancer muss über mindestens ein Subnetz verfügen. Die Subnetze müssen über mindestens acht verfügbare IP-Adressen verfügen. Weitere Informationen findest du unter Erstellen einer Virtual Private Cloud (VPC).

In bestimmten Szenarien musst du das folgende Tag verwenden:

• Schlüssel: „kubernetes.io/cluster/cluster-name“
• Wert: „shared“ oder „owned“

Application Load Balancers

In den folgenden Szenarien musst du eine Sicherheitsgruppe markieren:

• Du verwendest mehrere Sicherheitsgruppen, die an einen Worker-Knoten angefügt sind.
• Du verwendest Version v2.1.1 des AWS Load Balancer Controllers oder eine frühere Version.

Network Load Balancers

Wenn du Version 2.1.1 des AWS Load Balancer Controllers oder eine frühere Version verwendest, musst du den Subnetzen Tags hinzufügen. 

Wenn du in den Service- oder Ingress-Anmerkungen keine Subnetz-IDs angegeben hast, stelle sicher, dass die Subnetze über die erforderlichen Tags für die automatische Subnetzerkennung verfügen. Weitere Informationen findest du unter Subnet auto discovery (Automatische Subnetzerkennung) auf der GitHub-Website.

Verwende für private Subnetze die folgenden Tags:

• Schlüssel: „kubernetes.io/role/internal-elb“
• Wert: „1“

Verwende für öffentliche Subnetze die folgenden Tags:

• Schlüssel: „kubernetes.io/role/elb“
• Wert: „1“

Überprüfen der Anmerkungen des Ingress- oder Serviceobjekts

Stelle sicher, dass die Anmerkungen auf dem Serviceobjekt oder Ingress-Objekt korrekt sind.

Hinweis: Ersetze in den folgenden Befehlen SERVICE-NAME, INGRESS-NAME und NAMESPACE durch deine Werte.

Führe den folgenden Befehl aus, um das Serviceobjekt anzuzeigen:

kubectl describe service SERVICE-NAME -n NAMESPACE

Führe den folgenden Befehl aus, um das Ingress-Objekt anzuzeigen:

kubectl describe ingress INGRESS-NAME -n NAMESPACE

Führe den folgenden Befehl aus, um das Serviceobjekt zu bearbeiten:

kubectl edit service SERVICE-NAME -n NAMESPACE

Führe den folgenden Befehl aus, um das Ingress-Objekt zu bearbeiten:

kubectl edit ingress INGRESS-NAME -n NAMESPACE

Andere Anmerkungen verwenden Standardwerte. Eine Liste der Anmerkungen, die AWS Load Balancer Controller für Application Load Balancer unterstützt, findest du unter Ingress annotations (Ingress-Anmerkungen) auf der GitHub-Website. Eine Liste der unterstützten Anmerkungen für Network Load Balancer findest du unter Service annotations (Serviceanmerkungen) auf der GitHub-Website.

Application Load Balancer

In Kubernetes-Versionen vor 1.18 verwendeten Ingress-Klassen die Anmerkung kubernetes.io/ingress.class, die auf den Namen des Ingress-Controllers verweist. Ingress-Klassen in allen späteren Versionen von Kubernetes verwenden die Anmerkung ingressClassName, die auf die Ingress-Klassenressource verweist.

Weitere Informationen findest du unter Deprecated kubernetes.io/ingress.class annotation (Veraltete Anmerkung kubernetes.io/ingress.class) auf der GitHub-Website.

Network Load Balancer

Verwende die folgenden Anmerkungen:

• Verwende bei IP-Zielen service.beta.kubernetes.io/aws-load-balancer-type: "external" und service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: "ip".
• Verwende bei Instance-Zielen service.beta.kubernetes.io/aws-load-balancer-type: "external" und service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: "instance".

Problembehandlung, wenn du den Load Balancer vom Ingress- oder Service-Typ in Amazon EKS erstellst

Du erhältst den Fehler „AccessDenied“

Du erhältst die folgende Fehlermeldung:

„Failed deploy model due to AccessDenied“

Dieser Fehler tritt auf, weil sich die elasticloadbalancing:AddTags-Berechtigung zum Erstellen von Ressourcen geändert hat. Um das Problem zu beheben, füge an die AWSLoadBalancerController-Rolle die neueste AWS Identity and Access Management (IAM)-Richtlinie an. Die neueste Richtlinie findest du unter IAM policy JSON (IAM-Richtlinien-JSON) auf der GitHub-Website.

Weitere Informationen findest du unter IAM-Rolle mithilfe von eksctl erstellen.

Der Load Balancer wird in der Availability Zone nicht unterstützt

Wenn du ein Subnetz in einer eingeschränkten Availability Zone angibst, erhältst du möglicherweise eine Fehlermeldung, die der folgenden ähnelt:

„Load balancers with type 'network' are not supported in availability-zone-name“

Um dieses Problem zu beheben, gib ein Subnetz in einer anderen Availability Zone an, das nicht eingeschränkt ist. Verwende dann den zonenübergreifenden Lastenausgleich, um den Datenverkehr auf Ziele in der eingeschränkten Availability Zone zu verteilen.

Um verschiedene Subnetze zu verwenden, füge das Tag kubernetes.io/role/internal-elb=1 für Subnetze hinzu, mit denen du einen internen Network Load Balancer erstellst. Weitere Informationen findest du unter Einen Network Load Balancer markieren.

Oder füge die folgende Anmerkung hinzu, um die Subnetze in der Service-Manifestdatei anzugeben:

service.beta.kubernetes.io/aws-load-balancer-subnets: subnet-xxxx, mySubnet

Hinweis: Ersetze subnet-xxxx durch deine Subnetz-ID und mySubnet durch deinen Subnetznamen.

Du kannst die automatische Erkennung nicht für Subnetze verwenden

Wenn du die Subnetze nicht für die automatische Erkennung markierst, wird möglicherweise die folgende Fehlermeldung angezeigt:

„couldn't auto-discover subnets: unable to resolve at least one subnet“

Der AWS Load Balancer Controller erkennt standardmäßig automatisch Netzwerk-Subnetze. Für Application Load Balancer benötigst du mindestens zwei Subnetze in verschiedenen Availability Zones. Ein Network Load Balancer benötigt nur ein Subnetz.

Damit die automatische Erkennung funktioniert, musst du die entsprechenden Tags auf die Subnetze anwenden. Der Controller wählt ein Subnetz aus jeder Availability Zone aus. Wenn eine Availability Zone mehrere markierte Subnetze hat, wählt der Controller anhand alphabetischer Subnetz-IDs nur eines aus.

Weitere Informationen zu den erforderlichen Subnetz-Tags für private und öffentliche Subnetze findest du unter Subnet auto discovery (Automatische Subnetzerkennung) auf der GitHub-Website.

Es gibt ein Problem mit der Konfiguration des Zertifikatsmanagers oder des Webhooks

Wenn die Webhook-Validierung fehlschlägt, erhältst du möglicherweise die folgende Fehlermeldung:

„Internal error occurred: failed calling webhook "vingress.elbv2.k8s.aws": Post "https://aws-load-balancer-webhook-service.kube-system.svc:443/validate-networking-v1beta1-ingress?timeout=10s": x509: certificate has expired or is not yet valid“

Dieser Fehler tritt auf, wenn es Probleme mit den Zertifikaten gibt, die AWS Certificate Manager (ACM) für die Webhooks verwaltet.

Um dieses Problem zu beheben, überprüfe, ob die Certificate-Manager-Pods ausgeführt werden.

Führe den folgenden Befehl aus, um den Pod-Status abzurufen:

kubectl describe pod your-pod-name -n your-namespace

Führe den folgenden Befehl aus, um Protokolle zu sammeln:

kubectl logs your-pod-name -n your-namespace

Hinweis: Ersetze in den vorherigen Befehlen your-pod-name durch den Namen deines Pods und your-namespace durch den Namen deines Namespace.

Die Erstellung der Zielgruppenbindung ist fehlgeschlagen

Wenn die Erstellung der Zielgruppenbindung fehlschlägt, erhältst du möglicherweise die folgende Fehlermeldung:

„Warning FailedDeployModel 11m (x2 over 39m) ingress Failed deploy model due to Internal error occurred: failed calling webhook "vtargetgroupbinding.elbv2.k8s.aws": failed to call webhook: Post "https://aws-load-balancer-webhook-service.kube-system.svc:443/validate-elbv2-k8s-aws-v1beta1-targetgroupbinding?timeout=10s": context deadline exceeded“

Dieser Fehler tritt auf, wenn Sicherheitsgruppen-Einschränkungen den Zugriff auf den Webhook-Service blockieren. Der Service verwendet standardmäßig Port 9443.

Ändere die Konten-Sicherheitsgruppe, um dieses Problem zu beheben. Erlaube eingehenden Datenverkehr von der Sicherheitsgruppe der Steuerebene auf Port 9443. Weitere Informationen findest du unter Controller configuration options (Controller-Konfigurationsoptionen) auf der GitHub-Website.

AssumeRoleWithWebIdentity ist für die Knotenrolle fehlgeschlagen

Wenn die Knotenrolle nicht die Rolle, die du im Servicekonto angegeben hast, übernehmen kann, wird möglicherweise die folgende Fehlermeldung angezeigt:

„WebIdentityErr: failed to retrieve credentials\ncaused by: AccessDenied: Not authorized to perform sts:AssumeRoleWithWebIdentity\n\tstatus code: 403, request id: c6241a7d-d8a8-452c-bb67-bf1ff9bab0c0“

Dieser Fehler tritt auf, weil du die IAM-Rollen für Service-Konten (IRSA) falsch konfiguriert hast.

Um dieses Problem zu beheben, verwende die richtige Rolle im Service-Konto und definiere eine Vertrauensrichtlinie für die Rolle.

Weitere Informationen findest du unter Warum erhalte ich den Fehler „WebIdentityErr“, wenn ich den AWS Load Balancer Controller in Amazon EKS verwende? und Wie behebe ich Fehler bei einem OIDC-Anbieter und IRSA in Amazon EKS?

Die Daten in den Controller-Pod-Protokollen sind unzureichend

Wenn du mehr Debug-Informationen benötigst, als die Standard-Controller-Pod-Protokolle bieten, füge der Controller-Pod-Konfiguration das Flag --log-level debug hinzu.

Weitere Informationen findest du unter Controller command line flags (Controller-Befehlszeilen-Flags) auf der GitHub-Website.

Weitere Informationen findest du in den Protokollen des AWS-Load-Balancer-Controller-Pods

Führe den folgenden Befehl aus, um die Protokolle des AWS Load Balancer Controllers zu überprüfen:

kubectl logs -n kube-system deployment.apps/aws-load-balancer-controller

Wenn es ein Problem gibt, wird ein „Reconciler-Fehler“ angezeigt. Du erhältst außerdem eine detaillierte Fehlermeldung, die angibt, warum ein Ingress-Objekt oder ein Load-Balancer-Service nicht erstellt oder aktualisiert werden kann.

Das Problem kann aus den folgenden Gründen auftreten:

• Wenn der Fehler auftritt, wenn der Controller versucht, AWS-API-Aufrufe zu tätigen, liegt ein Berechtigungs- oder Konnektivitätsproblem vor. Überprüfe die IAM-Berechtigungen des Controllers. Stelle dann sicher, dass Sicherheitsgruppen oder Netzwerk-Zugriffssteuerungslisten (Netzwerk-ACLs) ausgehende Verbindungen nicht explizit verweigern.
• Wenn der Fehler in der Konfiguration des Objekts auftritt, hast du die Ingress- oder Service-Spezifikation oder die Anmerkungen falsch konfiguriert. Lies die Anmerkungen zum Application Load Balancer oder Network Load Balancer auf der GitHub-Website.

Wenn keiner der Controller-Pods Protokolle anzeigt, führe den folgenden Befehl aus, um dich zu vergewissern, dass die Controller-Pods ausgeführt werden:

kubectl get deployment -n kube-system aws-load-balancer-controller

Upgrade auf eine unterstützte Controller-Version

Wenn du eine Version des AWS Load Balancer Controllers verwendest, die nicht mehr unterstützt wird, kannst du kein Upgrade auf eine neuere Version durchführen. Stattdessen musst du den vorhandenen Controller entfernen und dann die neueste Version installieren.

Verwendung des AWS Load Balancer Controllers anstelle des Legacy-Cloud-Anbieters

Kubernetes umfasst einen Legacy-Cloud-Anbieter für AWS, der Classic Load Balancer bereitstellen kann. Wenn du den AWS Load Balancer Controller nicht installierst, verwendet Kubernetes den Legacy-Cloud-Anbieter. Es hat sich jedoch bewährt, den AWS Load Balancer Controller zu verwenden.

AWS Load Balancer Controller Version 2.5 und höher sind die Standard-Controller für Kubernetes-Serviceressourcen mit dem  Typ LoadBalancer. Sie erstellen für jeden Service einen Network Load Balancer. Die neuesten Versionen implementieren auch einen mutierenden Webhook für Services. Sie setzen für den neuen Typ LoadBalancer services das Feld spec.loadBalancerClass auf service.k8s.aws/nlb.

Führe den folgenden Befehl aus, um ein Upgrade auf AWS Load Balancer Controller durchzuführen:

helm upgrade aws-load-balancer-controller eks/aws-load-balancer-controller -n kube-system --set clusterName=CLUSTER-NAME --set serviceAccount.create=false --set serviceAccount.name=aws-load-balancer-controller --set enableServiceMutatorWebhook=false

Hinweis: Ersetze ** CLUSTER-NAME ** durch den Namen deines Clusters.

Wenn du den Legacy-Cloud-Anbieter verwenden musst, setze den Helm-Chart-Wert enableServiceMutatorWebhook auf false, damit keine neuen Classic Load Balancer bereitgestellt werden. Nur die vorhandenen Classic Load Balancer funktionieren weiterhin.

Stelle sicher, dass du ein Fargate-Profil für den Namespace erstellt hast, in dem sich das Ingress- oder Serviceobjekt befindet

Wenn Ziel-Pods auf AWS Fargate ausgeführt werden, musst du den IP-Zieltyp angeben. Führe den folgenden Befehl aus, um zu überprüfen, ob du über ein Fargate-Profil für den Namespace verfügst, in dem sich das Ingress- oder Serviceobjekt befindet:

eksctl get fargateprofile --cluster CLUSTER-NAME -o yaml

Hinweis: Ersetze ** CLUSTER-NAME ** durch den Namen deines Clusters.

Führe den folgenden Befehl aus, um ein Fargate-Profil zu erstellen:

eksctl create fargateprofile --cluster CLUSTER-NAME --region REGION --name FARGATE-PROFILE-NAME --namespace NAMESPACE

Hinweis: Ersetze CLUSTER-NAME, REGION, FARGATE-PROFILE-NAME und NAMESPACE durch deine Werte.

Vergewissere dich, dass du die Anforderungen für das Routing des Datenverkehrs erfüllst

Um sicherzustellen, dass du alle Anforderungen erfüllst, findest du weitere Informationen unter Voraussetzungen für Application Load Balancer und Voraussetzungen für Network Load Balancer. Wenn du beispielsweise einen Application Load Balancer verwendest, muss das Service-Objekt den NodePort oder LoadBalancer angeben, um den Instance-Datenverkehrsmodus zu verwenden.

Amazon EKS fügt der Sicherheitsgruppe des Knotens die folgenden Regeln hinzu:

• Eine Regel für den eingehenden Client-Datenverkehr
• Eine Regel für eingehenden Datenverkehr für jedes Load-Balancer-Subnetz in der VPC für jeden Network Load Balancer, den du für Zustandsprüfungen erstellst

Wenn die von Amazon EKS hinzugefügten Regeln dazu führen, dass die Sicherheitsgruppe die maximale Anzahl an Regeln überschreitet, schlägt die Load-Balancer-Bereitstellung möglicherweise fehl.