View a markdown version of this page

Vergleich der EKS-Fähigkeit für ACK mit der selbstverwalteten ACK - Amazon EKS
Unterschiede zum Upstream-ACKMigrationspfadController-Vorschau und automatische HeraufstufungNächste Schritte

Unterstützung für die Verbesserung dieser Seite beitragen

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Um zu diesem Benutzerhandbuch beizutragen, wählen Sie den GitHub Link Diese Seite bearbeiten unter, der sich im rechten Bereich jeder Seite befindet.

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Vergleich der EKS-Fähigkeit für ACK mit der selbstverwalteten ACK

Die EKS-Funktion für ACK bietet dieselbe Funktionalität wie selbstverwaltete ACK-Controller, bietet jedoch erhebliche betriebliche Vorteile. Einen allgemeinen Vergleich der EKS-Funktionen mit selbstverwalteten Lösungen finden Sie unter. Überlegungen zu den EKS-Fähigkeiten Dieses Thema konzentriert sich auf ACK-specific Unterschiede.

Unterschiede zum Upstream-ACK

Die EKS-Fähigkeit für ACK basiert auf Upstream-ACK-Controllern, unterscheidet sich jedoch in der IAM-Integration.

IAM-Funktionsrolle: Die Funktion verwendet eine dedizierte IAM-Rolle mit einer Vertrauensrichtlinie, die den capabilities.eks.amazonaws.com Service Principal zulässt, nicht IRSA (IAM-Rollen für Dienstkonten). Sie können IAM-Richtlinien direkt an die Capability-Rolle anhängen, ohne dass Sie Kubernetes-Dienstkonten erstellen oder mit Anmerkungen versehen oder OIDC-Anbieter konfigurieren müssen. Eine bewährte Methode für Anwendungsfälle in der Produktion ist die Konfiguration von Serviceberechtigungen mithilfe von. IAMRoleSelector Weitere Details finden Sie unter ACK-Berechtigungen konfigurieren.

Sitzungs-Tags: Die verwaltete Funktion legt automatisch Sitzungs-Tags für alle AWS API-Anfragen fest und ermöglicht so eine feingranulare Zugriffskontrolle und Prüfung. Zu den Stichwörtern gehören eks:eks-capability-arneks:kubernetes-namespace, und. eks:kubernetes-api-group Dies unterscheidet sich von selbstverwaltetem ACK, bei dem diese Tags nicht standardmäßig festgelegt werden. Einzelheiten ACK-Berechtigungen konfigurieren zur Verwendung von Sitzungs-Tags in IAM-Richtlinien finden Sie unter.

Ressourcen-Tags: Die Funktion wendet andere Standard-Tags auf AWS Ressourcen an als selbstverwaltetes ACK. Die Funktion verwendet Tags mit eks: Präfix (wieeks:kubernetes-namespace,eks:eks-capability-arn) anstelle der Tags, die vom selbstverwalteten services.k8s.aws/ ACK verwendet werden. Eine vollständige Liste der Standard-Ressourcen-Tags finden Sie unterACK-Überlegungen für EKS.

Ressourcenkompatibilität: Benutzerdefinierte ACK-Ressourcen funktionieren genauso wie Upstream-ACK, ohne dass Änderungen an Ihren ACK-Ressourcen-YAML-Dateien vorgenommen werden. Die Funktion verwendet dieselben Kubernetes-APIs und -CRDs, sodass Tools wie kubectl auf dieselbe Weise funktionieren. Die Funktion unterstützt nur Controller und Ressourcen, die im Upstream-ACK allgemein verfügbar sind (GA). Die Funktion umfasst keine Controller, die sich in der Upstream-Vorschauversion befinden. Der Status eines Controllers kann sich im Laufe der Zeit von der Vorschau- in den GA-Upstream-Status ändern, und die Funktion kann dann automatisch mit der Verwaltung beginnen. Wenn Sie zusammen mit der Funktion einen selbstverwalteten Preview-Controller ausführen, sollten Sie dies Controller-Vorschau und automatische Heraufstufung vor der Migration überprüfen.

Die vollständige ACK-Dokumentation und dienstspezifische Anleitungen finden Sie in der ACK-Dokumentation auf der ACK-Website.

Migrationspfad

Sie können von einer selbstverwalteten ACK- zur verwalteten Funktion migrieren, ohne dass Ihre AWS Ressourcen beeinträchtigt werden. Die Migration hängt von der Wahl des Kubernetes-Marktführers ab: Der selbstverwaltete Controller und die Fähigkeit konkurrieren um denselben Leasingvertrag, sodass immer nur einer von ihnen eine bestimmte Ressource abgleicht. Damit das funktioniert, müssen sich beide einen Leasingvertrag im gleichen Namespace teilen. Die Funktion nimmt einem laufenden selbstverwalteten Controller nicht zwangsweise das Leasing ab. Sie können also steuern, wann die Übergabe erfolgt, indem Sie den selbstverwalteten Controller herunterskalieren.

Wichtig

Bevor Sie beginnen, gewähren Sie der IAM-Funktionsrolle Berechtigungen, die den Berechtigungen entsprechen, die Ihre selbstverwalteten Controller heute verwenden. Die Funktion authentifiziert sich mit einer dedizierten Capability Role über den capabilities.eks.amazonaws.com Service Principal und nicht über den Mechanismus, den Ihre selbstverwalteten Controller heute verwenden, wie IRSA oder EKS Pod Identity (siehe). ACK-Berechtigungen konfigurieren Wenn für die Capability Role Berechtigungen fehlen, übernimmt die Funktion Ihre Ressourcen. Sie kann sie dann nicht abgleichen und Fehler werden protokolliertAccessDenied.

Führen Sie die folgenden Schritte aus, um zu migrieren. Die Schritte verwenden den S3-Controller (ack-s3-controller) als Beispiel. Wiederholen Sie diese Schritte für jeden selbstverwalteten ACK-Controller, den Sie zu der Funktion migrieren möchten, und ersetzen Sie dabei den entsprechenden Controller-Namen und das Helm-Diagramm.

Anmerkung

Der Betrieb eines selbstverwalteten Controllers zusammen mit der Funktion ist als temporärer Zustand während der Migration gedacht, nicht als langfristige Konfiguration. Während beide laufen, kann eine Unterbrechung auf der einen Seite (z. B. eine Bereitstellung von Funktionen oder ein Upgrade des selbstverwalteten Controllers) dazu führen, dass das Leasing aufgehoben wird und die andere Seite es in Anspruch nimmt, sodass unerwartet zwischen den beiden Parteien gewechselt wird. Schließen Sie die Migration für jeden Controller ab, anstatt ihn auf unbestimmte Zeit zusammen mit der Funktion selbst verwalten zu lassen.

  1. Aktivieren Sie die Wahl des Leaders auf Ihrem selbstverwalteten ACK-Controller und übertragen Sie das Leasing auf: kube-system

    helm upgrade --install ack-s3-controller \
  oci://public.ecr.aws/aws-controllers-k8s/s3-chart \
  --namespace ack-system \
  --set leaderElection.enabled=true \
  --set leaderElection.namespace=kube-system

    Sie müssen beide Werte festlegen. In den ACK-Helm-Diagrammen wird das --leader-election-namespace Flag nur angewendet, wenn leaderElection.enabled es isttrue, und die Wahl des Anführers ist standardmäßig deaktiviert. Eine Einstellung leaderElection.namespace allein hat keine Wirkung. Der Controller läuft ohne Lease weiter, und beide Controller stimmen dieselben Ressourcen gleichzeitig ab, nachdem die Funktion erstellt wurde. Dies gilt für jedes ACK Service Controller-Diagramm, nicht nur für S3.

    Dadurch wird das Leasing des Controllers nach verschobenkube-system, sodass die verwalteten Funktionen mit dem Controller koordiniert werden können.

  2. Erstellen Sie die ACK-Funktion auf Ihrem Cluster (sieheErstellen Sie eine ACK-Fähigkeit). Die Funktion wird gestartet und kämpft um das Leasing, aber der selbstverwaltete Controller hält sie immer noch. Ihr selbstverwalteter Controller gleicht ständig Ihre Ressourcen ab, und die Fähigkeit wartet auf die Führung, anstatt eine Übernahme zu erzwingen.

  3. Wenn Sie bereit sind, mit der Migration zu beginnen, skalieren Sie den selbstverwalteten Controller so weit, dass keine Replikate mehr vorhanden sind. Dadurch wird der Leasingvertrag freigegeben, sodass der Mitarbeiter die Führung übernehmen und die Abstimmung übernehmen kann:

    kubectl scale deployment ack-s3-controller \
  --namespace ack-system --replicas=0

    Nachdem Sie den selbstverwalteten Controller herunterskaliert haben, übernimmt die Funktion den Leasingvertrag und beginnt in der Regel innerhalb kurzer Zeit mit der Abstimmung. Wenn Sie den selbstverwalteten Controller nach oben skalieren, wird ihm das Leasing nicht zurückgegeben, da die Funktion weiterhin gültig ist und das Leasing verlängert wird. Um den Abgleich an den selbstverwalteten Controller zurückzugeben, skalieren Sie ihn wieder auf mindestens ein Replikat und löschen Sie dann die ACK-Funktion. Nachdem Sie die Funktion gelöscht haben, erwirbt der selbstverwaltete Controller das Leasing erneut und setzt den Abgleich fort.

    Bei der Einführung verwendet die Funktion ihre eigenen Standard-Ressourcen-Tags (mit eks: Präfix) anstelle der vom selbstverwalteten ACK verwendeten services.k8s.aws/ Tags (siehe). ACK-Überlegungen für EKS Rechnen Sie mit einem einmaligen Satz von API-Aufrufen für das Taggen Ihrer verwendeten Ressourcen und aktualisieren Sie alle Tools für die Kostenzuweisung oder die Richtlinien, die das Tag-Präfix eingeben. services.k8s.aws/

  4. Stellen Sie sicher, dass die Funktion funktionsfähig ist und den Abgleich Ihrer Ressourcen übernommen hat. Vergewissern Sie sich, dass die Ressourcen einen Synced Zustand von melden True und dass die Funktion keine AccessDenied Fehler protokolliert.

  5. Nachdem Sie bestätigt haben, dass die Funktion Ihre Ressourcen korrekt verwaltet, entfernen Sie den selbstverwalteten Controller:

    helm uninstall ack-s3-controller --namespace ack-system

Dieser Ansatz ermöglicht es beiden Controllern, während der Migration sicher nebeneinander zu existieren. Bei der verwalteten Funktion werden Ressourcen verwendet, die zuvor von selbstverwalteten Controllern verwaltet wurden, nachdem Sie das Leasing freigegeben haben, sodass ein kontinuierlicher Abgleich ohne Konflikte gewährleistet ist.

Controller-Vorschau und automatische Heraufstufung

Die Funktion unterstützt nur Controller, die im Upstream-ACK GA sind. Ein Controller, der sich heute in der Vorschauversion befindet, kann später auf GA Upstream hochgestuft werden. In diesem Fall beginnt die Funktion, diesen Controller automatisch zu verwalten, ohne dass Sie etwas unternehmen müssen.

Dies stellt ein Risiko dar, wenn Sie einen selbstverwalteten Preview-Controller auf einem Cluster ausführen, der die Funktion auch für andere Controller nutzt. Sie könnten den Vorschau-Controller als einzelnes Replikat mit deaktivierter Leiterwahl ausführen, da es keinen anderen Controller gibt, mit dem Sie koordinieren können. Wenn dieser Controller zum GA-Controller heraufgestuft wird, beginnt die Funktion, ihn zu verwalten. Zu diesem Zeitpunkt arbeiten zwei Abgleicher mit denselben Ressourcen, ohne dass ein gemeinsamer Leasingvertrag zu deren Koordinierung besteht. Das Ergebnis ist derselbe Konflikt mit doppelter Versöhnung, den die Migrationsmaßnahmen verhindern sollen. Beide Abgleicher geben konkurrierende AWS API-Aufrufe aus und schreiben widersprüchliche Aktualisierungen des benutzerdefinierten Ressourcenstatus.

Um dies zu vermeiden, bevor Sie neben der Funktion einen selbstverwalteten Preview-Controller ausführen, gehen Sie wie folgt vor:

  • Aktiviere die Wahl des Leaders auf dem selbstverwalteten Preview-Controller und verweise auf kube-system dessen Leasing. Verwende leaderElection.enabled=true dabei dieselben leaderElection.namespace=kube-system Einstellungen wie in den Migrationsschritten. Auf diese Weise wird sichergestellt, dass, wenn der Controller befördert wird und die Funktion ihn übernimmt, die beiden über einen gemeinsamen Leasingvertrag koordinieren, anstatt sich parallel abzugleichen.

  • Verfolgen Sie den Upstream-GA-Status aller Preview-Controller, von denen Sie abhängig sind, und planen Sie, sie entsprechend dem Migrationspfad zu migrieren, wenn sie heraufgestuft werden. Sie können den aktuellen Status jedes Controllers auf der ACK-Services-Seite auf der ACK-Website überprüfen.

Nächste Schritte