View a markdown version of this page

Restaurer un cluster Amazon EKS - AWS Backup
Sauvegardes Amazon EKS

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Restaurer un cluster Amazon EKS

Vous pouvez restaurer les sauvegardes du cluster EKS à l'aide de la AWS Backup console ou de l'interface de ligne de commande. Les sauvegardes EKS sont des points de restauration composites qui incluent à la fois l'état du cluster EKS et les sauvegardes de volumes persistantes.

AWS Backup prend en charge de multiples expériences de restauration, y compris des restaurations granulaires au niveau de l'espace de noms. Les restaurations ne sont pas destructives et n'écraseront aucun objet Kubernetes existant dans votre cluster EKS cible. Les restaurations n'écraseront pas non plus les versions Kubernetes du cluster EKS cible.

Les sauvegardes EKS doivent être restaurées sur un cluster EKS cible, c'est-à-dire un cluster Amazon EKS pré-provisionné. Dans le cadre du flux de restauration, vous pouvez choisir de créer un nouveau cluster EKS qui AWS Backup sera créé en votre nom.

Note

AWS Backup fournira un ensemble limité d'options pour créer un nouveau cluster EKS dans le cadre d'une restauration. Pour toutes les fonctionnalités de création de clusters EKS, les clients peuvent créer un nouveau cluster EKS à l'aide de la console EKS ou des API et le sélectionner comme cible de restauration.

Fonctionnalités de restauration pour Amazon EKS

Type de restauration Restaurer la cible Restaurer le comportement
Restauration d'un cluster existant Restaurez vers le cluster EKS source ou le cluster EKS existant Restaure toutes les ressources Kubernetes et les volumes persistants sur les clusters EKS existants. Toutes les restaurations ne sont pas destructives et les objets existants ne sont pas remplacés. Pour les objets ignorés, vous pouvez vous abonner aux notifications SNS
Restauration d'un nouveau cluster Crée un nouveau cluster Amazon EKS dans le cadre de votre restauration EKS Restore crée un nouveau cluster EKS et restaure toutes les ressources Kubernetes et les volumes persistants dans le cluster nouvellement créé
Restauration de l'espace de noms Cluster Amazon EKS existant Restaure uniquement les espaces de noms spécifiés, leurs ressources Kubernetes et les restaurations de stockage persistantes correspondantes ne sont pas destructives et les objets existants ne sont pas remplacés. Pour les objets ignorés, vous pouvez vous abonner aux notifications SNS
Restauration persistante du stockage Dépendant du stockage persistant Restaurez le stockage persistant individuel sous forme de restaurations autonomes. Consultez la section Restaurer le comportement d'Amazon EBS, Amazon S3 et Amazon EFS.

Autorisations

Les autorisations requises dépendent du type de restauration et de la destination cible.

  • AWS Backup de la politique gérée AWSBackupServiceRolePolicyForRestores contient les autorisations requises pour restaurer votre cluster Amazon EKS et le stockage persistant EBS et EFS.

  • Si votre cluster EKS contient un compartiment S3, ou si vous restaurez le point de restauration S3 de l'enfant seul, vous devrez vous assurer que les politiques ou autorisations suivantes sont attribuées à votre rôle AWSBackupServiceRolePolicyForS3Restore.

Considérations avant la restauration

Avant de commencer une tâche de restauration EKS, vérifiez les points suivants. Si vous restaurez une sauvegarde EKS qui a été copiée d'un compte ou d'une région à l'autre, assurez-vous de vérifier ces points avant toute restauration afin d'éviter tout échec de restauration.

  1. Rôles IAM  : lors de la restauration sur un autre cluster, les rôles IAM utilisés dans le cluster source (tels que Pod identity, IRSA). Les configurations du fournisseur OIDC, etc.) doivent être présents dans le compte/la région en tant que cluster de destination.

  2. Assurez-vous de la version et de la compatibilité d'EKS  : les versions d'API des objets que vous souhaitez restaurer doivent être identiques (ou aussi proches que possible) et prises en charge dans le nouveau cluster. AWS Backup effectuera de son mieux pour effectuer une restauration entre les versions d'EKS, bien que des problèmes de compatibilité puissent survenir lors de la restauration entre des versions sensiblement différentes.

  3. Classes de stockage correspondantes  : pour les restaurations sur un cluster EKS existant, assurez-vous que les modules complémentaires du pilote de stockage CSI appropriés sont installés avant la restauration

  4. Compartiments S3  : lors de la restauration d'un cluster EKS avec des compartiments S3, assurez-vous que votre compartiment S3 est versionné et accessible dans le compte ou la région de destination.

  5. Référentiel d'images  : lors de la restauration d'un cluster EKS, assurez-vous que le compte ou la région du cluster EKS de destination a accès aux images référencées dans le cadre de la restauration. Vérifiez que votre registre dispose des autorisations nécessaires entre les régions et les règles de compte.

  6. Groupes de sécurité  : les groupes de sécurité doivent être pré-créés pour ALB, Pod Identities, EKS Node Groups, etc. dans le compte et la région cibles si vous créez un nouveau cluster EKS dans le cadre de votre restauration

  7. Zones de disponibilité et nœuds EBS  : les zones de disponibilité dans lesquelles vous restaurez vos volumes EBS doivent être mappées à la zone de disponibilité d'un nœud EKS existant

  8. Non-destructive restaurations  : toutes les restaurations EKS seront non destructives et n'écraseront pas les objets Kubernetes de la restauration cible.

  9. Activer les journaux d'audit EKS  : activez les journaux d'audit EKS pour une journalisation et un dépannage supplémentaires avant la restauration. Vous pouvez également vous abonner aux notifications SNS pour signaler les objets ignorés ou ayant échoué lors de la restauration.

  10. Tampon de restauration pour la création d'un nouveau cluster EKS  : lors de la création d'un nouveau cluster EKS pendant la restauration, AWS Backup introduit une mémoire tampon de 15 minutes une fois que le cluster EKS atteint un état disponible, mais avant de créer des ressources EKS supplémentaires. Ce tampon garantit que tous les composants EKS sous-jacents sont entièrement initialisés avant la création de ressources dépendantes.

  11. Données utilisateur dans le modèle de lancement  : lorsque vous créez un groupe de nœuds à l'aide d'un modèle de lancement, ne le spécifiez pas spec.cluster dans la section des données utilisateur du modèle de lancement. Amazon EKS injecte automatiquement les paramètres d'identité du cluster (apiServerEndpointcertificateAuthority, etserviceIpv4Cidr) et les fusionne avec toutes les configurations supplémentaires définies dans les données utilisateur.

Configurations EKS

Lorsque vous restaurez l'Amazon composite AWS Backup, vous choisissez le type de restauration et la destination cible. Vous pouvez choisir de restaurer le cluster EKS source, un cluster EKS existant ou de créer un nouveau cluster EKS comme cible de restauration. Pour les nouveaux clusters EKS, vous pouvez choisir d'utiliser les mêmes paramètres d'infrastructure existants (par exemple, VPC, sous-réseaux) que le cluster sauvegardé ou d'en configurer de nouveaux. AWS Backup est conçu pour effectuer une restauration non destructive qui ne remplace pas les ressources existantes.

Pour les restaurations d'espaces de noms, vous pouvez spécifier jusqu'à 5 espaces de noms à restaurer de manière sélective. Seules les ressources limitées à l'espace de noms sont restaurées, tandis que les ressources à l'échelle du cluster sont exclues, à l'exception des volumes persistants associés.

En tant que paramètre avancé, vous pouvez choisir de modifier l'ordre de restauration des objets Kubernetes. Par défaut, AWS Backup restaurera tous les objets Kubernetes dans l'ordre suivant :

Ressources Kubernetes à portée de cluster

  1. Définitions de ressources personnalisées

  2. Espaces de noms (l'espace de noms lui-même, pas les ressources qu'il contient)

  3. StorageClasses

  4. PersistentVolumes

Ressources Kubernetes à portée de namespace

  1. PersistentVolumeClaims

  2. Secrets

  3. ConfigMaps

  4. ServiceAccounts

  5. LimitRanges

  6. Gousses

  7. ReplicaSets

Configurations de stockage persistantes

Dans le cadre de la restauration de la sauvegarde composite Amazon EKS, la deuxième étape consistera à configurer vos configurations de stockage persistant. Cela varie en fonction du stockage persistant sauvegardé dans le cadre de votre cluster EKS.

Pour les instantanés Amazon EBS, vous devez fournir une zone de disponibilité dans laquelle le volume Amazon EBS sera restauré et créé. AWS Backup tentera ensuite de créer le pod EKS dans la même zone de disponibilité que celle sélectionnée afin que votre volume puisse être remonté sur votre cluster EKS dans le cadre de la restauration.

Dans le cadre de la restauration, vos volumes Amazon EBS et vos compartiments Amazon S3 AWS Backup seront remontés sur votre cluster EKS restauré. Les systèmes de fichiers Amazon EFS sont restaurés avec des préfixes aléatoires et nécessitent la création manuelle d'un point d'accès après la restauration pour être remontés sur votre cluster EKS. AWS Backup ne crée pas de points d'accès et ne monte pas de cibles en votre nom. Reportez-vous aux instructions fournies ici pour les points d'accès et les cibles de montage.

Procédure de restauration Amazon EKS

Suivez ces étapes pour restaurer les sauvegardes Amazon EKS à l'aide de la AWS Backup console ou AWS CLI :

Console
Pour restaurer votre cluster Amazon EKS

  1. Ouvrez la AWS Backup console à l'adresse https://console.aws.amazon.com/backup.

  2. Dans le panneau de navigation, choisissez Backup vaults (Coffres-forts de sauvegarde).

  3. Choisissez le coffre de sauvegarde qui contient votre sauvegarde Amazon EKS, puis sélectionnez le point de restauration de votre sauvegarde Amazon EKS.

  4. Choisissez Restore (Restaurer).

  5. Dans le volet des options de restauration, choisissez votre type de restauration :

    • Restaurer l'intégralité du cluster EKS  : restaure l'intégralité du point de restauration composite Amazon EKS

    • Sélectionnez les espaces de noms à restaurer - Restaure jusqu'à cinq espaces de noms spécifiques

  6. Configurez la destination cible :

    • Pour restaurer un cluster, choisissez de créer un nouveau cluster ou d'utiliser un cluster existant

    • Pour les nouveaux clusters, spécifiez le nom du cluster, la version de Kubernetes, la configuration VPC, les rôles IAM, les sous-réseaux, les groupes de sécurité supplémentaires, les paramètres des groupes de nœuds, les profils Fargate et les rôles IAM d'identité des pods

    • Pour les clusters existants, sélectionnez le cluster cible dans la liste déroulante

    • Pour la restauration de l'espace de noms, spécifiez le cluster cible et les noms de l'espace de noms

  7. Vous pouvez éventuellement configurer les paramètres avancés pour un ordre de restauration personnalisé pour les ressources Kubernetes.

  8. Choisissez le rôle de restauration IAM pour la tâche. Si vous n'utilisez pas le rôle par défaut, assurez-vous que le rôle sélectionné inclut l'PassRole autorisation iam :.

    Note

    Si le gestionnaire de rôles est activé dans votre compte, il AWS Backup sélectionne le rôle de service par défaut pour vous et une option Personnaliser est disponible. Pour plus d’informations, consultez Création de rôles IAM dans le Guide de l’utilisateur IAM.

  9. Choisissez Restore backup.

AWS CLI

Utilisez la aws backup start-restore-job commande avec les EKS-specific métadonnées Amazon.

Les métadonnées requises dépendent de votre type de restauration. Toutes les opérations de restauration nécessitent le clusterName paramètre.

Restaurez les points de restauration Amazon EKS via AWS CLI

Utiliser StartRestoreJob. Vous pouvez spécifier les métadonnées suivantes lors des restaurations Amazon EKS :

Métadonnées obligatoires :

  • clusterName- Nom du cluster à restaurer

Métadonnées facultatives :

  • newCluster- (true/false) Si nous devions créer un nouveau cluster EKS lors de la restauration. Si NewCluster a la valeur « true », les champs de métadonnées suivants s'appliquent :

    • eksClusterVersion- Version K8s souhaitée du cluster si vous souhaitez augmenter la version du cluster lors de la restauration

    • clusterRole- L'ARN du rôle IAM à associer au cluster EKS créé

    • encryptionConfigProviderKeyArn- Spécifiez l'ARN de la clé KMS pour chiffrer le cluster de destination. Il peut s'agir de la clé KMS du cluster source ou d'une autre clé KMS. Une clé KMS différente doit être fournie lors de la restauration entre régions ou entre comptes. Omettez complètement ces métadonnées si le cluster source n'est pas chiffré.

    • clusterVpcConfig- VPC/Networking configuration pour le cluster EKS créé. Ce champ comporte les champs imbriqués suivants :

      • vpcId- Le VPC associé à votre cluster

      • subnetIds [Required]- Les sous-réseaux associés à votre cluster

      • securityGroupIds [Required]- Les groupes de sécurité supplémentaires associés à votre cluster

    • nodeGroups- Les groupes de nœuds gérés à créer sur le cluster EKS. Le NodeGroups serveur à restaurer doit comporter tous les mêmes groupes de nœuds depuis la sauvegarde et avoir le nœud correspondantGroupId.

      • nodeGroupId [Required]- L'ID du groupe de nœuds

      • subnetIds [Required]- Les sous-réseaux qui ont été spécifiés pour le groupe Auto Scaling associé à votre groupe de nœuds

      • instanceTypes- Si le groupe de nœuds n'a pas été déployé avec un modèle de lancement, il s'agit du type d'instance associé au groupe de nœuds

      • nodeRole [Required]- Le rôle IAM associé à votre groupe de nœuds

      • securityGroupIds- Les identifiants des groupes de sécurité autorisés à accéder aux nœuds par SSH

      • remoteAccessEc2SshKey- Le nom de la clé SSH Amazon EC2 qui permet d'accéder à la communication SSH avec les nœuds du groupe de nœuds géré

      • launchTemplateId- Spécifiez l'ID du modèle de lancement pour créer le groupe de nœuds. Il peut s'agir de l'ID du modèle de lancement du cluster source ou d'un autre ID de modèle de lancement. Si le modèle de lancement du cluster source contient un point de terminaison codé en dur qui pointe vers le cluster source lui-même, vous devez fournir un identifiant de modèle de lancement différent. Omettez complètement ces métadonnées si le cluster source n'utilise pas de modèle de lancement.

      • launchTemplateVersion- Version du modèle de lancement associée à l'ID du modèle de lancement spécifié.

    • fargateProfiles- Les profils Fargate à créer sur le cluster EKS. Les profils Fargate à restaurer doivent avoir tous les mêmes profils Fargate depuis la sauvegarde et porter le même nom.

      • name [Required]- Le nom du profil Fargate

      • subnetIds- Les identifiants des sous-réseaux dans lesquels lancer un Pod

      • podExecutionRoleArn [Required]- L'ARN du rôle IAM du rôle d'exécution du Pod à utiliser pour un Pod qui correspond aux sélecteurs du profil Fargate

    • podIdentityAssociations- Les associations d'identité des pods à créer sur le cluster EKS

      • associationId- L'identifiant de l'association Pod Identity

      • roleArn- L'ARN du rôle IAM pour la Pod Identity Association

  • kubernetesRestoreOrder- Remplacez l'ordre dans lequel les manifestes Kubernetes sont restaurés. Cet ordre aura priorité sur l'ordre de restauration du service par défaut. Cela suit le format : group/version /kind ou version/kind

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

  • namespaceLevelRestore- (true/false) Si vous souhaitez effectuer une restauration au niveau de l'espace de noms

  • namespaces- Une liste d'espaces de noms à restaurer si l'espace de noms LevelRestore est « vrai ». Peut fournir jusqu'à 5 espaces de noms à restaurer.

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

  • restoreKubernetesManifestsOnly- (true/false) Si vous souhaitez uniquement restaurer les fichiers manifestes de Kubernetes et aucun système de stockage persistant (EBS, S3, EFS, etc.)

  • nestedRestoreJobs- Restaurez la configuration des métadonnées de tous les points de restauration imbriqués pour les systèmes PersistentVolume de stockage dans le point de restauration composite. Voici une carte de RecoveryPointArn : RestoreMetadata de ce point de restauration

Restaurer vers un cluster existant 

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"

Restaurez des espaces de noms spécifiques sur un cluster existant : 

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"

Restaurez les volumes persistants imbriqués sur un cluster existant : 

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"

Restaurer vers un nouveau cluster 

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"

Après avoir démarré la tâche de restauration, utilisez describe-restore-job pour suivre la progression :

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

Vous pouvez vous abonner à des événements de notification pour les objets échoués ou ignorés à restaurer. Pour plus d'informations, consultez la section Options de notification avec AWS Backup.

Messages d'état de restauration d'Amazon EKS

Lorsqu'une tâche de restauration est terminée, les messages d'état suivants peuvent s'afficher. Le tableau présente les scénarios possibles et les valeurs de statut de poste correspondantes :

Scénario Statut de la tâche Exemple de message
Tous les objets ont été restaurés avec succès TERMINÉ —
Un ou plusieurs objets n'ont pas pu être restaurés TERMINÉ « Un ou plusieurs objets Kubernetes n'ont pas pu être restaurés. Pour être averti de ces échecs, activez les notifications d'événements SNS. »
La restauration n'a pas pu être terminée ÉCHEC (détails de l'erreur)

Objets ignorés lors de la restauration

Les objets Kubernetes suivants sont restaurés dans les meilleurs délais. S'ils ne parviennent pas à être restaurés, ils sont déplacés vers la liste ignorée. Ces objets sont gérés par le système et recréés par Kubernetes ou Amazon EKS :

  • FlowSchemas avec l'apf.kubernetes.io/autoupdate-spec: "true"annotation

  • PriorityLevelConfigurations avec l'apf.kubernetes.io/autoupdate-spec: "true"annotation

  • Le eks-exempt FlowSchema (EKS-managed, fait référence à l'exempté protégé PriorityLevelConfiguration)

  • Le kubernetes service dans l'defaultespace de noms (point de terminaison du serveur API)

  • Le kube-dns service dans l'espace de kube-system noms (CoreDNS)

Les objets Kubernetes suivants sont toujours ignorés lors d'une restauration. Ces objets incluent l'infrastructure des nœuds et les composants réseau. Ils font référence à l'état spécifique du cluster. Les contrôleurs Kubernetes recréent automatiquement ces objets lorsque des nœuds et des services deviennent actifs dans le cluster cible. Si vous restaurez ces objets à partir d'une sauvegarde, ils peuvent provoquer des conflits ou des erreurs. Ces conflits se produisent parce que les objets restaurés font référence à des ressources qui n'existent pas sur le cluster cible.

  • Points de terminaison (v1/endpoints) : points de terminaison du réseau qui définissent les adresses IP des services. Le contrôleur Endpoints les gère automatiquement en fonction des sélecteurs de service.

  • EndpointSlices (discovery.k8s.io/v1/endpointslices) - Le EndpointSlice contrôleur gère automatiquement ces objets.

  • IPAddresses (networking.k8s.io/v1/ipaddresses) : le réseau Kubernetes gère ces allocations IP internes au cluster.

  • CSINodes (storage.k8s.io/v1/csinodes) - Le kubelet crée automatiquement ces objets lorsque les pilotes CSI s'enregistrent sur un nœud.

  • VolumeAttachments (storage.k8s.io/v1/volumeattachments) - Le attach/detach contrôleur crée automatiquement ces objets lorsque les pods nécessitent des volumes.

Les objets qui existent déjà sur le cluster cible sont également ignorés. Les restaurations EKS ne sont pas destructives : les objets existants ne sont jamais remplacés ni supprimés.

Pour recevoir des notifications concernant des objets ignorés ou ayant échoué lors de la restauration, abonnez-vous aux notifications d'événements SNS. Pour plus d'informations, consultez la section Options de notification avec AWS Backup.

Considérations relatives à l'OIDC et à l'IRSA pour la restauration entre clusters

Lors de la restauration d'une sauvegarde Amazon EKS sur un cluster différent de la source, les objets Kubernetes faisant référence à IAM Roles for Service Accounts (IRSA) conservent le point de terminaison du fournisseur OIDC du cluster source. Ces références existent dans les annotations des comptes de service et les politiques de confiance IAM. AWS Backup ne les met pas automatiquement à jour lors de la restauration.

Si vos charges de travail utilisent IRSA, une restauration inter-clusters nécessite :

  • Un fournisseur OIDC doit être configuré pour le cluster de destination.

  • Tous les rôles IAM référencés par les comptes de service Kubernetes doivent voir leurs politiques de confiance mises à jour pour inclure le point de terminaison du fournisseur OIDC du cluster de destination.

  • Les annotations du compte de service (eks.amazonaws.com/role-arn) feront toujours référence aux rôles d'origine. Vérifiez qu'ils correspondent à des rôles valides dans le compte de destination.

Si ces dépendances ne sont pas satisfaites, les pods n'assumeront pas les rôles IAM après la restauration, et les tâches de restauration peuvent signaler des échecs lors de la validation.

Recommandation  : pour les charges de travail qui nécessitent une portabilité de restauration entre clusters ou entre comptes, nous recommandons d'utiliser EKS Pod Identity au lieu d'IRSA. EKS Pod Identity ne dépend pas de fournisseurs OIDC spécifiques au cluster et simplifie les scénarios de restauration entre clusters.