Vergleich der EKS-Funktionen für ACK mit selbstverwaltetem ACK - Amazon EKS
Unterschiede zu Upstream-ACKMigrationspfadNä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 auf, 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-Funktionen für ACK mit selbstverwaltetem ACK

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

Unterschiede zu Upstream-ACK

Die EKS-Funktion für ACK basiert auf vorgelagerten ACK-Controllern, unterscheidet sich jedoch in der IAM-Integration.

IAM-Fähigkeitsrolle: Die Funktion verwendet eine dedizierte IAM-Rolle mit einer Vertrauensrichtlinie, die den capabilities.eks.amazonaws.com Dienstprinzipal und nicht IRSA (IAM-Rollen für Dienstkonten) zulässt. Sie können IAM-Richtlinien direkt an die Capability Role anhängen, ohne Kubernetes-Dienstkonten erstellen oder mit Anmerkungen versehen oder OIDC-Anbieter konfigurieren zu 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.

Ressourcenkompatibilität: Benutzerdefinierte ACK-Ressourcen funktionieren genauso wie Upstream-ACK-Ressourcen, ohne dass Ihre ACK-Ressourcen-YAML-Dateien geändert werden. Die Funktion verwendet dasselbe Kubernetes APIs und CRDs daher kubectl funktionieren Tools wie auf die gleiche Weise. Alle GA-Controller und Ressourcen aus dem Upstream-ACK werden unterstützt.

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

Migrationspfad

Sie können ohne Ausfallzeiten vom selbstverwalteten ACK zur verwalteten Funktion migrieren:

  1. Aktualisieren Sie Ihren selbstverwalteten ACK-Controller so, dass er ihn kube-system für Leasingverträge zur Wahl von Führungskräften verwenden kann, zum Beispiel:

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

    Dadurch wird der Leasingvertrag des Controllers auf diesen kube-system übertragen, sodass sich die verwaltete Kapazität darauf abstimmen kann.

  2. Erstellen Sie die ACK-Fähigkeit auf Ihrem Cluster (sieheErstellen Sie eine ACK-Fähigkeit)

  3. Die verwaltete Funktion erkennt vorhandene, von ACK verwaltete AWS Ressourcen und übernimmt den Abgleich

  4. Skalieren Sie selbstverwaltete Controller-Bereitstellungen schrittweise oder entfernen Sie sie:

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

Dieser Ansatz ermöglicht eine sichere Koexistenz beider Controller während der Migration. Die verwaltete Funktion übernimmt automatisch Ressourcen, die zuvor von selbstverwalteten Controllern verwaltet wurden, und gewährleistet so einen kontinuierlichen Abgleich ohne Konflikte.

Nächste Schritte