View a markdown version of this page

Stellen Sie einen Amazon EKS-Cluster wieder her - AWS Backup
Amazon-EKS-Backups

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.

Stellen Sie einen Amazon EKS-Cluster wieder her

Sie können EKS-Cluster-Backups mithilfe der AWS Backup Konsole oder der CLI wiederherstellen. EKS-Backups sind zusammengesetzte Wiederherstellungspunkte, die sowohl EKS-Clusterstatus-Backups als auch persistente Volume-Backups enthalten.

AWS Backup unterstützt mehrere Wiederherstellungsvorgänge, einschließlich granularer Wiederherstellungen auf Namespace-Ebene. Wiederherstellungen sind zerstörungsfrei und überschreiben keine vorhandenen Kubernetes-Objekte in Ihrem EKS-Zielcluster. Bei Wiederherstellungen werden auch die Kubernetes-Versionen des EKS-Ziel-Clusters nicht überschrieben.

EKS-Backups müssen auf einem EKS-Ziel-Cluster wiederhergestellt werden, d. h. auf einem Amazon EKS-Cluster, der vorab bereitgestellt wurde. Im Rahmen des Wiederherstellungs-Workflows können Sie sich dafür entscheiden, einen neuen EKS-Cluster zu erstellen, der in Ihrem Namen erstellt AWS Backup wird.

Anmerkung

AWS Backup bietet eine begrenzte Anzahl von Optionen zum Erstellen eines neuen EKS-Clusters als Teil einer Wiederherstellung. Für alle Funktionen zur Erstellung von EKS-Clustern können Kunden mithilfe der EKS-Konsole oder der APIs einen neuen EKS-Cluster erstellen und diesen als Wiederherstellungsziel auswählen.

Wiederherstellungsfunktionen für Amazon EKS

Typ der Wiederherstellung Ziel wiederherstellen Verhalten wiederherstellen
Wiederherstellung vorhandener Cluster Wiederherstellung im Quell-EKS-Cluster oder im vorhandenen EKS-Cluster Stellt alle Kubernetes-Ressourcen und persistenten Volumes in vorhandenen EKS-Clustern wieder her. Alle Wiederherstellungen sind zerstörungsfrei und vorhandene Objekte werden nicht überschrieben. Für Objekte, die übersprungen werden, können Sie SNS-Benachrichtigungen abonnieren https://docs.aws.amazon.com/aws-backup/latest/devguide/backup-notifications.html
Neue Cluster-Wiederherstellung Erstellt im Rahmen Ihrer EKS-Wiederherstellung einen neuen Amazon EKS-Cluster Restore erstellt einen neuen EKS-Cluster und stellt alle Kubernetes-Ressourcen und persistenten Volumes im neu erstellten Cluster wieder her
Wiederherstellung des Namespaces Bestehender Amazon EKS-Cluster Stellt nur bestimmte Namespaces wieder her, ihre Kubernetes-Ressourcen und die entsprechenden persistenten Speicherwiederherstellungen sind zerstörungsfrei und vorhandene Objekte werden nicht überschrieben. Für Objekte, die übersprungen werden, können Sie SNS-Benachrichtigungen abonnieren
Dauerhafte Speicherwiederherstellung Abhängig von persistentem Speicher Stellen Sie einzelne persistente Speicher als eigenständige Wiederherstellungen wieder her. Siehe Wiederherstellungsverhalten von Amazon EBS, Amazon S3, Amazon EFS.

Berechtigungen

Die erforderlichen Berechtigungen hängen vom Wiederherstellungstyp und vom Zielziel ab.

  • AWS Backup Die verwaltete Richtlinie AWSBackupServiceRolePolicyForRestores enthält die erforderlichen Berechtigungen zur Wiederherstellung Ihres Amazon EKS-Clusters sowie Ihres persistenten EBS- und EFS-Speichers.

  • Wenn Ihr EKS-Cluster einen S3-Bucket enthält oder Sie nur den untergeordneten S3-Wiederherstellungspunkt wiederherstellen, müssen Sie sicherstellen, dass die folgenden Richtlinien oder Berechtigungen Ihrer Rolle AWSBackupServiceRolePolicyForS3Restore zugewiesen sind.

Überlegungen vor der Wiederherstellung

Bevor Sie mit einer EKS-Wiederherstellung beginnen, sollten Sie Folgendes überprüfen. Wenn Sie ein EKS-Backup wiederherstellen, das konto- oder regionsübergreifend kopiert wurde, stellen Sie sicher, dass Sie diese Überlegungen vor der Wiederherstellung überprüfen, um Wiederherstellungsfehler zu vermeiden.

  1. IAM-Rollen: Bei der Wiederherstellung auf einem anderen Cluster die im Quellcluster verwendeten IAM-Rollen (z. B. Pod-Identität, IRSA). OIDC-Provider-Konfigurationen usw.) müssen im Konto bzw. in der Region als Zielcluster vorhanden sein.

  2. Stellen Sie die EKS-Version und -Kompatibilität sicher: Die API-Versionen der Objekte, die Sie wiederherstellen möchten, sollten dieselbe Version haben (oder ihr so nahe wie möglich kommen) und im neuen Cluster unterstützt werden. AWS Backup führt eine bestmögliche Wiederherstellung zwischen EKS-Versionen durch, obwohl bei der Wiederherstellung zwischen erheblich unterschiedlichen Versionen Kompatibilitätsprobleme auftreten können.

  3. Passende Speicherklassen: Stellen Sie bei Wiederherstellungen auf einem vorhandenen EKS-Cluster sicher, dass vor der Wiederherstellung die entsprechenden CSI-Speichertreiber-Add-Ons installiert sind

  4. S3-Buckets: Stellen Sie bei der Wiederherstellung eines EKS-Clusters mit S3-Buckets sicher, dass Ihr S3-Bucket versioniert ist und im Zielkonto oder in der Zielregion darauf zugegriffen werden kann.

  5. Image-Repository: Stellen Sie beim Wiederherstellen eines EKS-Clusters sicher, dass das Konto oder die Region des EKS-Zielclusters Zugriff auf die Images hat, auf die im Rahmen der Wiederherstellung verwiesen wird. Vergewissern Sie sich, dass Ihre Registry über die ausreichenden regionsübergreifenden /Account-Policy-Berechtigungen verfügt.

  6. Sicherheitsgruppen: Sicherheitsgruppen für ALB, Pod-Identitäten, EKS-Knotengruppen usw. sollten im Zielkonto und in der Zielregion vorab erstellt werden, wenn Sie im Rahmen Ihrer Wiederherstellung einen neuen EKS-Cluster erstellen

  7. EBS-Verfügbarkeitszonen und -Knoten: Die Availability Zones, in denen Sie Ihre EBS-Volumes wiederherstellen, sollten der Availability Zone eines vorhandenen EKS-Knotens zugeordnet werden

  8. Non-destructive Wiederherstellungen: Alle EKS-Wiederherstellungen sind zerstörungsfrei und überschreiben keine Kubernetes-Objekte der Zielwiederherstellung.

  9. EKS-Auditprotokolle aktivieren: Aktivieren Sie EKS-Auditprotokolle für zusätzliche Protokollierung und Problembehandlung vor der Wiederherstellung. Sie können auch SNS-Benachrichtigungen abonnieren, um Sie über übersprungene oder fehlgeschlagene Objekte bei der Wiederherstellung zu informieren.

  10. Neuer Wiederherstellungspuffer für die EKS-Clustererstellung: Wenn während der Wiederherstellung ein neuer EKS-Cluster erstellt AWS Backup wird, wird ein 15-Minuten-Puffer eingeführt, nachdem der EKS-Cluster einen verfügbaren Zustand erreicht hat, jedoch bevor zusätzliche EKS-Ressourcen erstellt werden. Dieser Puffer stellt sicher, dass alle zugrunde liegenden EKS-Komponenten vollständig initialisiert werden, bevor abhängige Ressourcen erstellt werden.

  11. Benutzerdaten in der Startvorlage: Wenn Sie eine Knotengruppe mithilfe einer Startvorlage erstellen, geben Sie dies nicht spec.cluster im Abschnitt „Benutzerdaten“ der Startvorlage an. Amazon EKS fügt automatisch die Cluster-Identitätsparameter (apiServerEndpointcertificateAuthority, undserviceIpv4Cidr) ein und führt sie mit allen zusätzlichen Konfigurationen zusammen, die in den Benutzerdaten definiert sind.

EKS-Konfigurationen

Wenn Sie das zusammengesetzte Amazon wiederherstellen AWS Backup, wählen Sie den Wiederherstellungstyp und das Zielziel. Sie können wählen, ob Sie die Wiederherstellung auf dem EKS-Quell-Cluster, einem vorhandenen EKS-Cluster durchführen oder einen neuen EKS-Cluster als Wiederherstellungsziel erstellen möchten. Für neue EKS-Cluster können Sie wählen, ob Sie dieselben vorhandenen Infrastruktureinstellungen (z. B. VPC, Subnetze) wie für den gesicherten Cluster verwenden oder neue konfigurieren möchten. AWS Backup ist für eine zerstörungsfreie Wiederherstellung konzipiert, bei der vorhandene Ressourcen nicht überschrieben werden.

Für Namespace-Wiederherstellungen können Sie bis zu 5 Namespaces angeben, die selektiv wiederhergestellt werden sollen. Nur Ressourcen im Namespace-Bereich werden wiederhergestellt, während Cluster-Ressourcen mit Ausnahme der zugehörigen persistenten Volumes ausgeschlossen sind.

Als erweiterte Einstellung können Sie sich dafür entscheiden, die Wiederherstellungsreihenfolge der Kubernetes-Objekte zu ändern. Standardmäßig AWS Backup werden alle Kubernetes-Objekte in der folgenden Reihenfolge wiederhergestellt:

Kubernetes-Ressourcen für Cluster

  1. Benutzerdefinierte Ressourcendefinitionen

  2. Namespaces (der Namespace selbst, nicht die Ressourcen in diesem Namespace)

  3. StorageClasses

  4. PersistentVolumes

Kubernetes-Ressourcen für Namespaces

  1. PersistentVolumeClaims

  2. Secrets

  3. ConfigMaps

  4. ServiceAccounts

  5. LimitRanges

  6. Pods

  7. ReplicaSets

Persistente Speicherkonfigurationen

Im Rahmen der kombinierten Amazon EKS-Backup-Wiederherstellung besteht der zweite Schritt darin, Ihre Konfigurationen für persistenten Speicher zu konfigurieren. Dies hängt vom persistenten Speicher ab, der als Teil Ihres EKS-Clusters gesichert wird.

Für Amazon EBS-Snapshots müssen Sie eine Availability Zone angeben, in der das Amazon EBS-Volume wiederhergestellt und erstellt wird. AWS Backup versucht dann, den EKS-Pod in derselben Availability Zone wie ausgewählt zu erstellen, sodass Ihr Volume im Rahmen der Wiederherstellung wieder in Ihren EKS-Cluster eingebunden werden kann.

Im Rahmen der Wiederherstellung mountet AWS Backup es Ihre Amazon EBS-Volumes und Amazon S3-Buckets erneut in Ihrem wiederhergestellten EKS-Cluster. Amazon EFS-Dateisysteme werden mit zufälligen Präfixen wiederhergestellt und erfordern nach der Wiederherstellung eine manuelle Erstellung eines Zugriffspunkts, um sie erneut in Ihrem EKS-Cluster bereitzustellen. AWS Backup erstellt keine Access Points oder Mount-Ziele in Ihrem Namen. Weitere Informationen zu Access Points und Mount-Zielen finden Sie hier.

Amazon EKS-Wiederherstellungsverfahren

Gehen Sie wie folgt vor, um Amazon EKS-Backups mithilfe der AWS Backup Konsole wiederherzustellen, oder AWS CLI:

Console
So stellen Sie Ihren Amazon EKS-Cluster wieder her

  1. Öffnen Sie die AWS Backup Konsole unter https://console.aws.amazon.com/backup.

  2. Wählen Sie im Navigationsbereich Backup vaults (Sicherungstresore) aus.

  3. Wählen Sie den Backup-Tresor, der Ihr Amazon EKS-Backup enthält, und wählen Sie dann den Wiederherstellungspunkt für Ihr Amazon EKS-Backup aus.

  4. Wählen Sie Restore (Wiederherstellen) aus.

  5. Wählen Sie im Bereich mit den Wiederherstellungsoptionen Ihren Wiederherstellungstyp aus:

    • Vollständigen EKS-Cluster wiederherstellen — Stellt den gesamten zusammengesetzten Amazon EKS-Wiederherstellungspunkt wieder her

    • Wählen Sie die wiederherzustellenden Namespaces aus — Stellt bis zu fünf bestimmte Namespaces wieder her

  6. Konfigurieren Sie das Zielziel:

    • Wählen Sie für die Cluster-Wiederherstellung, ob Sie einen neuen Cluster erstellen oder einen vorhandenen Cluster verwenden möchten

    • Geben Sie für neue Cluster den Clusternamen, die Kubernetes-Version, die VPC-Konfiguration, IAM-Rollen, Subnetze, zusätzliche Sicherheitsgruppen, Knotengruppeneinstellungen, Fargate-Profile und Pod-Identity-IAM-Rollen an

    • Wählen Sie für bestehende Cluster den Zielcluster aus der Dropdownliste aus

    • Geben Sie für die Namespace-Wiederherstellung den Zielcluster und die Namespace-Namen an

  7. Konfigurieren Sie optional erweiterte Einstellungen für die benutzerdefinierte Wiederherstellungsreihenfolge für Kubernetes-Ressourcen.

  8. Wählen Sie die IAM-Wiederherstellungsrolle für den Job aus. Wenn Sie nicht die Standardrolle verwenden, stellen Sie sicher, dass die ausgewählte Rolle die iam: PassRole -Berechtigung enthält.

  9. Wählen Sie Restore backup aus.

AWS CLI

Verwenden Sie den aws backup start-restore-job Befehl mit EKS-specific Amazon-Metadaten.

Die erforderlichen Metadaten hängen von Ihrem Wiederherstellungstyp ab. Für alle Wiederherstellungsvorgänge ist der clusterName Parameter erforderlich.

Stellen Sie Amazon EKS-Wiederherstellungspunkte wieder her über AWS CLI

Verwenden StartRestoreJob. Sie können bei Amazon EKS-Wiederherstellungen die folgenden Metadaten angeben:

Obligatorische Metadaten:

  • clusterName— Name des Clusters, auf dem wiederhergestellt werden soll

Optionale Metadaten:

  • newCluster- (true/false) Wenn wir während der Wiederherstellung einen neuen EKS-Cluster erstellen sollten. Wenn newCluster „true“ ist, gelten die folgenden Metadatenfelder:

    • eksClusterVersion- Gewünschte K8s-Version des Clusters, wenn die Cluster-Version während der Wiederherstellung erhöht werden soll

    • clusterRole- Der IAM-Rollen-ARN, der an den erstellten EKS-Cluster angehängt werden soll

    • encryptionConfigProviderKeyArn- Geben Sie den KMS-Schlüssel-ARN an, um den Zielcluster zu verschlüsseln. Dies kann entweder der KMS-Schlüssel aus dem Quellcluster oder ein anderer KMS-Schlüssel sein. Bei der regionsübergreifenden oder kontoübergreifenden Wiederherstellung muss ein anderer KMS-Schlüssel angegeben werden. Lassen Sie diese Metadaten vollständig weg, wenn der Quellcluster nicht verschlüsselt ist.

    • clusterVpcConfig- VPC/Networking Konfiguration für den erstellten EKS-Cluster. Dieses Feld enthält die folgenden verschachtelten Felder:

      • vpcId— Die mit Ihrem Cluster verknüpfte VPC

      • subnetIds [Required]- Die mit Ihrem Cluster verknüpften Subnetze

      • securityGroupIds [Required]- Die zusätzlichen Sicherheitsgruppen, die Ihrem Cluster zugeordnet sind

    • nodeGroups- Die verwalteten Knotengruppen, die auf dem EKS-Cluster erstellt werden sollen. NodeGroups Für die Wiederherstellung müssen alle Knotengruppen aus der Backup-Zeit und ein passender Knoten vorhanden seinGroupId.

      • nodeGroupId [Required]- Die ID der Knotengruppe

      • subnetIds [Required]- Die Subnetze, die für die Auto Scaling-Gruppe angegeben wurden, die Ihrer Knotengruppe zugeordnet ist

      • instanceTypes- Wenn die Knotengruppe nicht mit einer Startvorlage bereitgestellt wurde, ist dies der Instanztyp, der der Knotengruppe zugeordnet ist

      • nodeRole [Required]— Die Ihrer Knotengruppe zugeordnete IAM-Rolle

      • securityGroupIds— Die Sicherheitsgruppen-IDs, denen SSH-Zugriff auf die Knoten gewährt wird

      • remoteAccessEc2SshKey— Der Amazon EC2-SSH-Schlüsselname, der den Zugriff für die SSH-Kommunikation mit den Knoten in der verwalteten Knotengruppe ermöglicht

      • launchTemplateId— Geben Sie die Startvorlagen-ID an, um die Knotengruppe zu erstellen. Dies kann entweder die Startvorlagen-ID aus dem Quell-Cluster oder eine andere Startvorlagen-ID sein. Wenn die Startvorlage des Quellclusters einen fest codierten Endpunkt enthält, der auf den Quellcluster selbst verweist, müssen Sie eine andere Startvorlagen-ID angeben. Lassen Sie diese Metadaten vollständig weg, wenn der Quell-Cluster keine Startvorlage verwendet.

      • launchTemplateVersion— Starten Sie die Vorlagenversion, die der angegebenen Startvorlagen-ID zugeordnet ist.

    • fargateProfiles- Die Fargate-Profile, die auf dem EKS-Cluster erstellt werden sollen. Die Fargate-Profile für die Wiederherstellung müssen zum Zeitpunkt der Sicherung dieselben Fargate-Profile haben und einen passenden Namen haben.

      • name [Required]- Der Name des Fargate-Profils

      • subnetIds- Die IDs der Subnetze, in die ein Pod gestartet werden soll

      • podExecutionRoleArn [Required]— Der IAM-Rollen-ARN der Pod-Ausführungsrolle, der für einen Pod verwendet werden soll, der den Selektoren im Fargate-Profil entspricht

    • podIdentityAssociations— Die Pod-Identitätszuordnungen, die auf dem EKS-Cluster erstellt werden sollen

      • associationId— Die ID der Pod-Identitätszuordnung

      • roleArn— Der IAM-Rollen-ARN für die Pod Identity Association

  • kubernetesRestoreOrder— Überschreibt die Reihenfolge, in der die Kubernetes-Manifeste wiederhergestellt werden. Diese Reihenfolge hat Vorrang vor der Standardreihenfolge zur Wiederherstellung von Diensten. Dies folgt dem Format: group/version /kind oder version/kind

    Bsp.: ["v1/persistentvolumes","v1/pods","customresource/v2/custom"]

  • namespaceLevelRestore- (true/false) Wenn Sie eine Wiederherstellung auf Namespace-Ebene durchführen möchten

  • namespaces- Eine Liste von Namespaces, die wiederhergestellt werden sollen, wenn der Namespace LevelRestore „true“ ist. Kann bis zu 5 wiederherzustellende Namespaces bereitstellen.

    Bsp.: ["ns-1","ns-2","ns-3","ns-4","ns-5"]

  • restoreKubernetesManifestsOnly- (true/false) Wenn Sie nur die Kubernetes-Manifestdateien und keine persistenten Speichersysteme (EBS, S3, EFS usw.) wiederherstellen möchten

  • nestedRestoreJobs- Stellen Sie die Metadatenkonfiguration aller verschachtelten Recovery Points für die PersistentVolume Speichersysteme im Composite-Recovery Point wieder her. Dies ist eine Karte RestoreMetadata von RecoveryPointArn: diesem Recovery Point

Auf vorhandenem Cluster wiederherstellen 

aws backup start-restore-job \
    --recovery-point-arn "arn:aws:backup:us-west-2:123456789012:recovery-point:composite:eks/my-cluster-20240115" \
    --iam-role-arn "arn:aws:iam::123456789012:role/AWSBackupDefaultServiceRole" \
    --metadata '{"clusterName":"existing-cluster","newCluster":"false"}' \
    --resource-type "EKS"

Stellen Sie bestimmte Namespaces in einem vorhandenen Cluster wieder her: 

aws backup start-restore-job \
    --recovery-point-arn "arn:aws:backup:us-west-2:123456789012:recovery-point:composite:eks/my-cluster-20240115" \
    --iam-role-arn "arn:aws:iam::123456789012:role/AWSBackupDefaultServiceRole" \
    --metadata '{"clusterName":"existing-cluster","newCluster":"false","namespaceLevelRestore":"true","namespaces":"[\"ns-1\",\"ns-2\",\"ns-3\",\"ns-4\",\"ns-5\"]"}' \
    --resource-type "EKS"

Stellen Sie verschachtelte persistente Volumes in einem vorhandenen Cluster wieder her: 

aws backup start-restore-job \
    --recovery-point-arn "arn:aws:backup:us-west-2:123456789012:recovery-point:composite:eks/my-cluster-20240115" \
    --iam-role-arn "arn:aws:iam::123456789012:role/AWSBackupDefaultServiceRole" \
    --metadata '{"clusterName":"existing-cluster","newCluster":"false","namespaceLevelRestore":"true","nestedrestorejobs":"{\"arn:aws:ec2:us-west-2::snapshot/snap-abc123\":\"{\\\"AvailabilityZone\\\":\\\"us-west-2a\\\"}\",\"arn:aws:backup:us-west-2:123456789012:recovery-point:fa71a304-2555-4c37-8128-f154b9578032\":\"{\\\"DestinationBucketName\\\":\\\"bucket-name\\\"}\"}"}' \
    --resource-type "EKS"

Auf neuem Cluster wiederherstellen 

aws backup start-restore-job \
    --recovery-point-arn "arn:aws:backup:us-west-2:123456789012:recovery-point:composite:eks/my-cluster-20240115" \
    --iam-role-arn "arn:aws:iam::123456789012:role/AWSBackupDefaultServiceRole" \
    --metadata '{"clusterName":"new-cluster","newCluster":"true","clusterRole":"arn:aws:iam::123456789012:role/EKSClusterRole","eksClusterVersion":"1.33","encryptionConfigProviderKeyArn":"arn:aws:kms:us-west-2:123456789012:key/ecb2b326-784d-4ec0-8d07-20ab826b5a13","clusterVpcConfig":"{\"vpcId\":\"vpc-1234\",\"subnetIds\":[\"subnet-1\",\"subnet-2\",\"subnet-3\"],\"securityGroupIds\":[\"sg-123\"]}","nodeGroups":"[{\"nodeGroupId\":\"nodegroup-1\",\"subnetIds\":[\"subnet-1\",\"subnet-2\",\"subnet-3\"],\"nodeRole\":\"arn:aws:iam::123456789012:role/EKSNodeGroupRole\",\"instanceTypes\":[\"t3.small\"],\"launchTemplateId\":\"lt-0b13949aae3f2b867\",\"launchTemplateVersion\":\"1\"}]","fargateProfiles":"[{\"name\":\"fargate-profile-1\",\"subnetIds\":[\"subnet-1\",\"subnet-2\",\"subnet-3\"],\"podExecutionRoleArn\":\"arn:aws:iam::123456789012:role/EKSFargateProfileRole\"}]"}' \
    --resource-type "EKS"

Verwenden Sie nach dem Start des Wiederherstellungsauftrags Folgendes, describe-restore-job um den Fortschritt zu überwachen:

aws backup describe-restore-job --restore-job-id restore-job-id

Sie können Benachrichtigungsereignisse für fehlgeschlagene und übersprungene Objekte zur Wiederherstellung abonnieren. Weitere Informationen finden Sie unter Benachrichtigungsoptionen mit AWS Backup.

Amazon EKS-Statusmeldungen zur Wiederherstellung

Wenn ein Wiederherstellungsauftrag abgeschlossen ist, werden möglicherweise die folgenden Statusmeldungen angezeigt. Die Tabelle zeigt die möglichen Szenarien und die entsprechenden Jobstatuswerte:

Szenario Aufgabenstatus Beispiel für eine Nachricht
Alle Objekte wurden erfolgreich wiederhergestellt COMPLETED —
Ein oder mehrere Objekte konnten nicht wiederhergestellt werden COMPLETED „Ein oder mehrere Kubernetes-Objekte konnten nicht wiederhergestellt werden. Um über diese Fehler informiert zu werden, aktivieren Sie SNS-Ereignisbenachrichtigungen.“
Die Wiederherstellung konnte nicht abgeschlossen werden FEHLGESCHLAGEN (Fehlerdetails)

Objekte wurden bei der Wiederherstellung übersprungen

Die folgenden Kubernetes-Objekte werden nach bestem Wissen wiederhergestellt. Wenn sie nicht wiederhergestellt werden können, werden sie in die Liste der übersprungenen Objekte verschoben. Diese Objekte werden vom System verwaltet und von Kubernetes oder Amazon EKS neu erstellt:

  • FlowSchemas mit der Anmerkung apf.kubernetes.io/autoupdate-spec: "true"

  • PriorityLevelConfigurations mit der apf.kubernetes.io/autoupdate-spec: "true" Anmerkung

  • Das eks-exempt FlowSchema (EKS-managed, verweist auf die geschützte Ausnahme PriorityLevelConfiguration)

  • Der kubernetes Dienst im default Namespace (API-Serverendpunkt)

  • Der kube-dns Service im kube-system Namespace (CoreDNS)

Die folgenden Kubernetes-Objekte werden bei einer Wiederherstellung immer übersprungen. Zu diesen Objekten gehören die Knoteninfrastruktur und Netzwerkkomponenten. Sie verweisen auf den clusterspezifischen Zustand. Kubernetes-Controller erstellen diese Objekte automatisch neu, wenn Knoten und Dienste im Zielcluster aktiv werden. Wenn Sie diese Objekte aus einem Backup wiederherstellen, können sie zu Konflikten oder Fehlern führen. Diese Konflikte treten auf, weil die wiederhergestellten Objekte auf Ressourcen verweisen, die auf dem Zielcluster nicht vorhanden sind.

  • Endpoints (v1/endpoints) — Netzwerkendpunkte, die IP-Adressen für Dienste definieren. Der Endpoints Controller verwaltet diese automatisch auf der Grundlage von Service Selectors.

  • EndpointSlices (discovery.k8s.io/v1/endpointslices) - Der EndpointSlice Controller verwaltet diese Objekte automatisch.

  • IPAddresses (networking.k8s.io/v1/ipaddresses) — Das Kubernetes-Netzwerk verwaltet diese clusterinternen IP-Zuweisungen.

  • csiNodes (storage.k8s.io/v1/csinodes) — Das Kubelet erstellt diese Objekte automatisch, wenn sich CSI-Treiber auf einem Knoten registrieren.

  • VolumeAttachments (storage.k8s.io/v1/volumeattachments) - Der attach/detach Controller erstellt diese Objekte automatisch, wenn Pods Volumes benötigen.

Objekte, die bereits auf dem Zielcluster vorhanden sind, werden ebenfalls übersprungen. EKS-Wiederherstellungen sind zerstörungsfrei — vorhandene Objekte werden niemals überschrieben oder gelöscht.

Abonnieren Sie SNS-Ereignisbenachrichtigungen, um Benachrichtigungen über übersprungene oder fehlgeschlagene Objekte während der Wiederherstellung zu erhalten. Weitere Informationen finden Sie unter Benachrichtigungsoptionen mit. AWS Backup

Überlegungen zu OIDC und IRSA für die clusterübergreifende Wiederherstellung

Bei der Wiederherstellung eines Amazon EKS-Backups auf einem anderen Cluster als dem Quell-Cluster behalten Kubernetes-Objekte, die auf IAM Roles for Service Accounts (IRSA) verweisen, den OIDC-Provider-Endpunkt des Quell-Clusters bei. Diese Verweise sind in Anmerkungen zu Dienstkonten und IAM-Vertrauensrichtlinien enthalten. AWS Backup aktualisiert sie während der Wiederherstellung nicht automatisch.

Wenn Ihre Workloads IRSA verwenden, ist für eine clusterübergreifende Wiederherstellung Folgendes erforderlich:

  • Für den Zielcluster muss ein OIDC-Anbieter konfiguriert sein.

  • Für alle IAM-Rollen, auf die von Kubernetes-Dienstkonten verwiesen wird, müssen die Vertrauensrichtlinien aktualisiert werden, sodass sie den OIDC-Provider-Endpunkt des Zielclusters enthalten.

  • Anmerkungen zu Dienstkonten (eks.amazonaws.com/role-arn) verweisen weiterhin auf die ursprünglichen Rollen. Stellen Sie sicher, dass diese den gültigen Rollen im Zielkonto entsprechen.

Wenn diese Abhängigkeiten nicht erfüllt werden, können Pods nach der Wiederherstellung keine IAM-Rollen übernehmen, und bei Wiederherstellungsaufträgen werden möglicherweise Fehler bei der Überprüfung gemeldet.

Empfehlung: Für Workloads, die cluster- oder kontoübergreifende Übertragbarkeit der Wiederherstellung erfordern, empfehlen wir die Verwendung von EKS Pod Identity anstelle von IRSA. EKS Pod Identity ist nicht von clusterspezifischen OIDC-Anbietern abhängig und vereinfacht clusterübergreifende Wiederherstellungsszenarien.