View a markdown version of this page

Einen Amazon EKS-Cluster wiederherstellen - AWS Backup

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.

Einen Amazon EKS-Cluster wiederherstellen

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

AWS Backup unterstützt mehrere Wiederherstellungen, 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-Zielclusters nicht überschrieben.

EKS-Backups müssen auf einem EKS-Ziel-Cluster wiederhergestellt werden, d. h. auf einem Amazon EKS-Cluster, der vorab bereitgestellt wurde. Als Teil 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 für die Erstellung 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

Art der Wiederherstellung Ziel wiederherstellen Verhalten wiederherstellen
Wiederherstellung vorhandener Cluster Stellen Sie die Wiederherstellung auf dem Quell-EKS-Cluster oder dem vorhandenen EKS-Cluster her Stellt alle Kubernetes-Ressourcen und persistenten Volumes in vorhandenen EKS-Clustern wieder her. Alle Wiederherstellungen sind zerstörungsfrei und bestehende Objekte werden nicht überschrieben. Für Objekte, die übersprungen werden, können Sie SNS-Benachrichtigungen abonnieren
Neue Cluster-Wiederherstellung Erstellt einen neuen Amazon EKS-Cluster als Teil Ihrer EKS-Wiederherstellung Restore erstellt einen neuen EKS-Cluster und stellt alle Kubernetes-Ressourcen und persistenten Volumes im neu erstellten Cluster wieder her
Namespace-Wiederherstellung Bestehender Amazon EKS-Cluster Stellt nur bestimmte Namespaces wieder her, deren Kubernetes-Ressourcen und entsprechende persistente Speicherwiederherstellungen sind zerstörungsfrei und bestehende Objekte werden nicht überschrieben. Für Objekte, die übersprungen werden, können Sie SNS-Benachrichtigungen abonnieren
Dauerhafte Wiederherstellung des Speichers 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 AWSBackupServiceRolePolicyForRestoresenthält die erforderlichen Berechtigungen zur Wiederherstellung Ihres Amazon EKS-Clusters und des 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 Ihrer Rolle AWSBackupServiceRolePolicyForS3Restoredie folgenden Richtlinien oder Berechtigungen zugewiesen sind.

Überlegungen vor der Wiederherstellung

Bevor Sie mit einem EKS-Wiederherstellungsauftrag 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-Anbieterkonfigurationen usw. müssen im Konto/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 (oder so nah wie möglich) haben und im neuen Cluster unterstützt werden. AWS Backup führt nach besten Kräften eine Wiederherstellung zwischen EKS-Versionen durch, obwohl Kompatibilitätsprobleme auftreten können, wenn zwischen stark unterschiedlichen Versionen wiederhergestellt wird.

  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-Ziel-Clusters Zugriff auf die Images hat, auf die im Rahmen der Wiederherstellung verwiesen wird. Vergewissern Sie sich, dass Ihre Registrierung über ausreichende regionsübergreifende /kontoübergreifende Richtlinienberechtigungen verfügt.

  6. Sicherheitsgruppen: Sicherheitsgruppen sollten für ALB, Pod Identities, EKS Node Groups usw. im Zielkonto und in der Region 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-Audit-Logs aktivieren: Aktivieren Sie EKS-Audit-Logs für zusätzliche Protokollierung und Fehlerbehebung 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 Status erreicht hat, aber 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.

EKS-Konfigurationen

Wenn Sie das zusammengesetzte Amazon wiederherstellen AWS Backup, wählen Sie den Wiederherstellungstyp und das Zielziel aus. Sie können wählen, ob Sie auf dem Quell-EKS-Cluster, einem vorhandenen EKS-Cluster oder einem neuen EKS-Cluster als Wiederherstellungsziel wiederherstellen möchten. Für neue EKS-Cluster können Sie wählen, ob Sie dieselben vorhandenen Infrastruktureinstellungen (z. B. VPC, Subnetze) wie der gesicherte Cluster verwenden oder neue konfigurieren möchten. AWS Backup ist darauf ausgelegt, eine zerstörungsfreie Wiederherstellung durchzuführen, 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 Ressourcen im Clusterbereich mit Ausnahme verwandter persistenter Volumes ausgeschlossen sind.

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

Kubernetes-Ressourcen mit Clusterbereich

  1. Benutzerdefinierte Ressourcendefinitionen

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

  3. StorageClasses

  4. PersistentVolumes

Kubernetes-Ressourcen mit Namespace-Gültigkeitsbereich

  1. PersistentVolumeClaims

  2. Secrets

  3. ConfigMaps

  4. ServiceAccounts

  5. LimitRanges

  6. Pods

  7. ReplicaSets

Persistente Speicherkonfigurationen

Im Rahmen der zusammengesetzten Amazon EKS-Backup-Wiederherstellung besteht der zweite Schritt darin, Ihre Persistent Storage-Konfigurationen zu konfigurieren. Dies hängt vom persistenten Speicher ab, der als Teil Ihres EKS-Clusters gesichert wurde.

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 AWS Backup werden Ihre Amazon EBS-Volumes und Amazon S3 S3-Buckets erneut in Ihren wiederhergestellten EKS-Cluster eingebunden. Amazon EFS-Dateisysteme stellen auf zufällige Präfixe wieder her und erfordern nach der Wiederherstellung die manuelle Erstellung eines Access Points, um sie erneut in Ihren EKS-Cluster einzubinden. AWS Backup erstellt keine Access Points oder Mount-Ziele in Ihrem Namen. Informationen zu Zugriffspunkten 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 Wiederherstellungsoptionen Ihren Wiederherstellungstyp aus:

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

    • Wählen Sie die wiederherzustellenden Namespaces aus — Stellt bis zu fünf spezifische 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 sollen. Wenn newCluster „true“ ist, gelten die folgenden Metadatenfelder:

    • eksClusterVersion- Gewünschte K8s-Version des Clusters, wenn die Clusterversion 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 bereitgestellt 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 hat 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 dem Zeitpunkt der Sicherung dieselben Knotengruppen und die entsprechenden Knoten vorhanden seinGroupId.

      • nodeGroupId [Required]- Die ID der Knotengruppe

      • subnetIds [Required]- Die Subnetze, die für die Auto Scaling 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 EC2-SSH-Schlüsselname, der Zugriff auf 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 Quellcluster oder eine andere Startvorlagen-ID sein. Wenn die Startvorlage des Quellclusters einen hartcodierten 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 Quellcluster keine Startvorlage verwendet.

      • launchTemplateVersion— Version der Startvorlage, 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 dieselben Fargate-Profile aus der Backup-Zeit haben und einen passenden Namen haben.

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

      • subnetIds- Die IDs der Subnetze, in denen 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 Identity Association

      • roleArn- Die IAM-Rolle 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 für die Servicewiederherstellung. 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 Namespaces für die Wiederherstellung 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 Wiederherstellungspunkte für die PersistentVolume Speichersysteme im zusammengesetzten Wiederherstellungspunkt wieder her. Dies ist eine Abbildung von RecoveryPointArn: dieses RestoreMetadata Wiederherstellungspunkts

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 einem neuen 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-Wiederherstellungsstatusmeldungen

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

Szenario Aufgabenstatus Beispielnachricht
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

  • Die 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)

Objekte, die bereits auf dem Zielcluster existieren, 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 bei der Wiederherstellung zu erhalten. Weitere Informationen finden Sie unter Benachrichtigungsoptionen mit. AWS Backup