Wie kann ich die von meinem Application Load Balancer in Amazon EKS verwendeten Subnetze automatisch ermitteln?
Ich möchte automatisch die von meinem Application Load Balancer (ALB) in Amazon Elastic Kubernetes Service (Amazon EKS) verwendeten Subnetze ermitteln.
Kurzbeschreibung
Der Kubernetes Cloud Controller Manager (cloud-controller-manager) und der AWS Load Balancer Controller (aws-load-balancer-controller) fragen die Subnetze eines Clusters ab, um die Subnetze zu identifizieren, die der Application Load Balancer verwendet. Diese Abfrage verwendet den folgenden Tag als Filter:
kubernetes.io/cluster/cluster-name shared
Hinweis: Ersetzen Sie cluster-name durch den Namen Ihres Amazon-EKS-Clusters.
Damit der AWS Load Balancer Controller automatisch die Subnetze erkennt, die Ihr Application Load Balancer verwendet, kennzeichnen Sie Ihre Subnetze.
Behebung
Tags zu Subnetzen hinzufügen
Gehen Sie wie folgt vor, um Ihre Subnetze zu kennzeichnen:
-
Stellen Sie das AWS Load Balancer Controller Add-on für Ihren Amazon EKS Cluster bereit.
-
Stellen Sie sicher, dass der AWS Load Balancer Controller installiert ist:
kubectl get deployment -n kube-system aws-load-balancer-controller
Hinweis: Wenn die Bereitstellung in einem anderen Namespace erfolgt, ersetzen Sie -n kube-system durch den entsprechenden Namespace.
-
Erstellen Sie eine Kubernetes-Eingangsressource in Ihrem Cluster mit der folgenden Anmerkung:
annotations: kubernetes.io/ingress.class: alb
**Hinweis:**Der AWS Load Balancer Controller erstellt Load Balancers. Die Eingangsressource konfiguriert den Application Load Balancer für die Weiterleitung von HTTP(S)-Verkehr an verschiedene Pods innerhalb Ihres Clusters.
-
Fügen Sie entweder eine interne oder eine mit dem Internet verbundene Anmerkung hinzu, um anzugeben, wo der Eingang Ihren Load Balancer erstellen soll:
alb.ingress.kubernetes.io/scheme: internal -or- alb.ingress.kubernetes.io/scheme: internet-facing
Hinweis: Wählen Sie internal, um einen internen Load Balancer zu erstellen, oder internet-facing, um einen öffentlichen Load Balancer zu erstellen.
-
Verwenden Sie Tags, damit der AWS Load Balancer Controller einen Load Balancer erstellen kann, der Ihre Subnetze automatisch erkennt. Die Tags dürfen keine führenden oder nachfolgenden Leerzeichen haben. Zum Beispiel:
kubernetes.io/role/internal-elb Set to 1 or empty tag value for internal load balancers kubernetes.io/role/elb Set to 1 or empty tag value for internet-facing load balancers
Hinweis: Sie können Tags für die automatische Erkennung anstelle der manuellen Anmerkung alb.ingress.kubernetes.io/subnets verwenden.
Beispiel für ein Subnetz mit den richtigen Tags für einen Cluster mit internem Load Balancer:kubernetes.io/role/internal-elb 1
Beispiel für ein Subnetz mit den richtigen Tags für einen Cluster mit einem öffentlichen Load Balancer:
kubernetes.io/role/elb 1
Hinweis: Für Clusterversionen 1.18 und früher fügt Amazon EKS allen Subnetzen, die bei der Clustererstellung übergeben wurden, das folgende Tag hinzu. Das Tag wird nicht zu Clustern der Version 1.19 hinzugefügt. Wenn Sie das Tag verwenden und auf Cluster-Version 1.19 aktualisieren, müssen Sie das Tag nicht erneut hinzufügen. Das Tag bleibt in Ihrem Subnetz.
Sie können das folgende Tag verwenden, um zu steuern, wo ein Application Load Balancer bereitgestellt wird. Verwenden Sie für mehrere Cluster dieses Tag zusätzlich zu den erforderlichen Tags, um automatisch einen Application Load Balancer im EKS Cluster zuzuweisen:
kubernetes.io/cluster/$CLUSTER_NAME shared
-
Stellen Sie sicher, dass Ihre Subnetze die richtigen Tags haben:
aws ec2 describe-subnets --subnet-ids your-subnet-xxxxxxxxxxxxxxxxx
-
Stellen Sie eine Beispielanwendung bereit, um zu prüfen, ob der AWS Load Balancer Controller aufgrund des Eingangsobjekts einen Application Load Balancer erstellt.
kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/aws-load-balancer-controller/main/docs/examples/2048/2048_full.yaml
-
Vergewissern Sie sich, dass die Eingangsressource erstellt wird und einen zugehörigen Application Load Balancer hat:
kubectl get ingress/2048-ingress -n game-2048
Abhängig von den Anmerkungen (alb.ingress.kubernetes.io/scheme:), die Sie im Eingangsobjekt und in den Subnetzen definiert haben, wird entweder ein interner oder ein mit dem Internet verbundener Load Balancer erstellt.
Behebung häufig auftretender Tag-Fehler
Die folgenden Fehler treten häufig auf, wenn Sie Tags verwenden, um Subnetze automatisch zu erkennen.
Fehler „Berechtigungen verweigert“
Sie erhalten die folgende Fehlermeldung, wenn die AWS Identity and Access Management (IAM)-Rolle Ihres Kontos für den AWS Load Balancer Controller nicht über die erforderlichen Berechtigungen verfügt:
„{"level":"error","ts":1621443417.9175518,"logger":"controller","msg":"Reconciler error","controller":"ingress","name":" ingress-2048","namespace":" game-2048","error":"couldn't auto-discover subnets: UnauthorizedOperation: You are not authorized to perform this operation.\n\tstatus code: 403, request id: 72ee57ae-f804-4f81-b069-8b04114b67b0“}“
Gehen Sie wie folgt vor, um dieses Problem zu beheben:
-
Stellen Sie sicher, dass Ihr Dienstkonto mit dem AWS Load Balancer Controller verknüpft ist:
$ kubectl get deploy aws-load-balancer-controller -n kube-system -o yaml | grep -i serviceAccount
Sie erhalten eine Ausgabe wie die folgende:
serviceAccount: aws-load-balancer-controllerserviceAccountName: aws-load-balancer-controller
Hinweis: Wenn die Bereitstellung in einem anderen Namespace erfolgt, ersetzen Sie -n kube-system durch den entsprechenden Namespace.
-
Prüfen Sie, welche IAM-Rolle mit dem Dienstkonto verknüpft ist, das dem AWS Load Balancer Controller zugeordnet ist:
$ kubectl describe sa aws-load-balancer-controller -n kube-system | grep role-arn
Sie erhalten eine Ausgabe wie die folgende:
annotations: eks.amazonaws.com/role-arn: arn:aws:iam::xxxxxxxxxxx:role/eksctl-cluster18-addon-iamserviceaccount-kub-Role1-xxxxxxxxxxxxx
-
Erteilen Sie Ihrer IAM-Rolle alle relevanten Berechtigungen, z. B. ec2:DescribeAvailabilityZones. Weitere Informationen darüber, wie AWS Load Balancer Controller eine IAM-Rolle zur Ausführung von API-Aufrufen übernimmt, finden Sie unter IAM-Rollen für Dienstkonten. Eine Liste der relevanten Berechtigungen finden Sie in der IAM-JSON-Richtlinie auf der Webseite für den AWS Load Balancer Controller von GitHub.
Fehler bei der Erkennung eines einzelnen Subnetzes
Sie erhalten eine der folgenden Fehlermeldungen, wenn Ihr AWS Load Balancer Controller nicht mindestens ein Subnetz erkennt:
„{"level":"error","ts":1608229710.3212903,"logger":"controller","msg":"Reconciler error","controller":"ingress","name":"ingress-2048","namespace":"game-2048","error":"couldn't auto-discover subnets: unable to resolve at least one subnet"}“
Oder:
„kubebuilder/controller "msg"="Reconciler error" "error"="failed to build LoadBalancer configuration due to
retrieval of subnets failed to resolve 2 qualified subnets. Subnetze müssen das Tag kubernetes.io/cluster/\ u003ccluster name\u003e mit dem Wert shared oder owned und das Tag kubernetes.io/role/elb enthalten, das bedeutet, dass es für ALBs verwendet werden sollte. Außerdem müssen mindestens 2 Subnetze mit eindeutigen Availability Zones vorhanden sein, wie für ALBs notwendig. Markieren Sie entweder Subnetze, um diese Anforderung zu erfüllen, oder verwenden Sie die Subnetz-Anmerkung auf der Eingangsressource, um explizit anzugeben, welche Subnetze für die ALB-Erstellung verwendet werden sollen. Die Subnetze, die aufgelöst wurden, waren []“ „controller"="alb-ingress-controller“ „request"= {"Namespace“:"default“, "Name“:"2048-ingress "}“
Um dieses Problem zu beheben, fügen Sie die entsprechenden Tags in Ihren Subnetzen hinzu, damit der AWS Load Balancer Controller die automatische Erkennung verwenden kann, um einen Load Balancer zu erstellen:
Tags für private Subnetze:
kubernetes.io/role/internal-elb Set to 1 or empty tag value for internal load balancers
Tags für öffentliche Subnetze:
kubernetes.io/role/elb Set to 1 or empty tag value for internet-facing load balancers
Hinweis: Mit der Anmerkung alb.ingress.kubernetes.io/subnets können Sie Ihrem Load Balancer manuell Subnetze zuweisen.
Kennzeichnen Sie Ihre Subnetze mit dem folgenden Format ohne führende oder nachfolgende Leerzeichen:
Schlüssel: kubernetes.io/cluster/your-cluster-name
Wert: shared oder owned
Wenn Sie den AWS Load Balancer Controller Version 2.1.1 oder früher verwenden, müssen Sie Ihre Subnetze im vorstehenden Format kennzeichnen. Tagging ist für Versionen 2.1.2 oder höher optional.
In den folgenden Szenarien empfiehlt es sich, ein Subnetz zu kennzeichnen:
- Sie haben mehrere Cluster, die in derselben Virtual Private Cloud (VPC) ausgeführt werden.
- Sie haben mehrere AWS Services, die sich Subnetze in einer VPC teilen.
- Sie möchten mehr Kontrolle darüber haben, wo Load Balancer für jeden Cluster zugewiesen werden.
Fehler bei der Erkennung mehrerer Subnetze
Sie erhalten die folgende Fehlermeldung, wenn Ihr AWS Load Balancer Controller nicht zwei oder mehr qualifizierte Subnetze erkennt:
„{" level“ :"error“, "ts“ :"2024-08-12T 19:01:27 Z“, "msg“ :"Abgleichfehler“, "controller“ :"ingress“, "object“: {"name“ :"ingress-2048", "namespace“ :"game-2048"}, "namespace“ :"game-2048", "ingress-2048" ss-2048", "ReconcileID“ :"1234567", "error“ :"Subnetze konnten nicht automatisch erkannt werden: mindestens ein Subnetz konnte nicht aufgelöst werden (2 stimmen mit VPC und Tags überein):\ [ kubernetes.io/role/internal-elb], 2 haben weniger als 8 freie IPs) "}“
Gehen Sie wie folgt vor, um dieses Problem zu beheben:
- Vergewissern Sie sich, dass Sie mindestens zwei Subnetze in zwei verschiedenen Availability Zones haben. Dies ist eine Voraussetzung, um einen Application Load Balancer zu erstellen.
Hinweis: Sie können einen Network Load Balancer mit einem einzigen Subnetz erstellen. - Geben Sie für jedes Subnetz einen CIDR-Block mit mindestens einer /27-Bitmaske an (zum Beispiel: 10.0.0.0/27) und mindestens acht freie IP-Adressen.
- Vergewissern Sie sich, dass die Tags in den Subnetzen korrekt formatiert sind. Beispielsweise dürfen Tags keine führenden oder nachfolgenden Leerzeichen haben.
Ähnliche Videos
Relevanter Inhalt
- AWS OFFICIALAktualisiert vor 8 Monaten
- AWS OFFICIALAktualisiert vor 2 Jahren
- AWS OFFICIALAktualisiert vor 9 Monaten
- AWS OFFICIALAktualisiert vor 2 Jahren