Comment puis-je résoudre un échec de mise à niveau avec mon cluster Amazon EKS ?

Lecture de 8 minute(s)
0

Il m'est impossible de mettre à jour mon cluster Amazon Elastic Kubernetes Service (Amazon EKS). Comment puis-je résoudre ce problème ?

Brève description

Pour résoudre un problème d'échec de mise à jour du cluster Amazon EKS, procédez comme suit :

  • Lorsque vous recevez le message d'erreur IPNotAvailable, vérifiez si le sous-réseau associé à votre cluster possède suffisamment d'adresses IP disponibles.
  • Lorsque vous recevez le message d'erreur SubnetNotFound, vérifiez si les sous-réseaux existent et sont correctement labelisés.
  • Lorsque vous recevez le message d'erreur SecurityGroupNotFound, vérifiez si les groupes de sécurité associés au cluster existent.
  • Lorsque vous recevez le message d'erreur EniLimitReached, augmentez le quota d'interface réseau Elastic pour le compte AWS.
  • Lorsque vous recevez le message d'erreur AccessDenied, vérifiez que vous disposez des autorisations correctes.
  • Lorsque vous recevez le message d'erreur OperationNotPermitted, vérifiez que la fonction du service Amazon EKS possède les autorisations appropriées.
  • Lorsque vous recevez le message d'erreur VPCidNotFound, vérifiez si le VPC associé au cluster existe.
  • Vérifiez si les ressources que vous avez utilisées pour créer le cluster ont été supprimées.
  • Pour les clusters créés avec eksctl, vérifiez si la pile AWS CloudFormation n'a pas réussi à revenir en arrière.
  • En cas d'erreur ResourceInUseException, attendez un certain temps avant de réessayer la mise à jour.
  • Pour les problèmes de flux backend transitoires, mettez à nouveau le cluster à jour.

Solution

Vérifiez si les sous-réseaux ont des adresses IP disponibles (IPNotAvailable)

Pour mettre à jour un cluster Amazon EKS, vous devez disposer de trois adresses IP disponibles pour chacun des sous-réseaux. Si vous ne disposez pas de suffisamment d'adresses IP disponibles, vous pouvez supprimer les interfaces réseau inutilisées au sein des sous-réseaux du cluster. La suppression d'une interface réseau libère l'adresse IP. Pour plus d'informations, consultez Supprimer une interface réseau.

Pour vérifier les adresses IP disponibles dans les sous-réseaux du cluster Amazon EKS :

1.    Ouvrez la console Amazon EKS dans la région dans laquelle vous avez créé votre cluster.

2.    Sélectionnez Clusters dans la barre latérale. Sélectionnez ensuite votre cluster Amazon EKS.

3.    Choisissez l'onglet Configuration.

4.    Choisissez l'onglet Réseaux.

5.    Dans la rubrique Sous-réseaux, sélectionnez un sous-réseau pour ouvrir la page Sous-réseaux.

6.    Sélectionnez un sous-réseau, puis cliquez sur l'onglet Détails.

7.    Recherchez les adresses IPv4 disponibles pour connaître le nombre d'adresses IP disponibles du sous-réseau.

Dans l'interface de ligne de commande AWS, exécutez les commandes suivantes :

1.    Obtenez les sous-réseaux associés au cluster :

$ aws eks describe-cluster --name cluster-name --region your-region

Remarque : renseignez le champ cluster-name en indiquant le nom de votre cluster et le champ your-region en indiquant votre région AWS.

Sortie :

...
   "subnetIds": [
                "subnet-6782e71e",
                "subnet-e7e761ac"
            ],
   ...

2.    Décrivez les sous-réseaux de la sortie précédente :

aws ec2 describe-subnets --subnet-ids subet-id --region your-region

Remarque : Remplacez subnet-id par l'ID de votre sous-réseau et your-region par votre région.

Sortie :

...
"AvailableIpAddressCount": 4089,
...

Si vous n'avez pas suffisamment d'adresses IP disponibles, vous pouvez définir la variable d'environnement dans le démon aws-node sur le paramètre WARM_IP_TARGET. Cela définit le nombre d'adresses IP secondaires que l'interface réseau de conteneurs (CNI) doit réserver pour les pods :

$ kubectl set env ds aws-node -n kube-system WARM_IP_TARGET=number

Remarque : renseignez le champ nombre en indiquant le nombre d'adresses IP que vous souhaitez réserver à partir des sous-réseaux.

Vous pouvez également utiliser la variable MINIMUM_IP_TARGET pour contrôler le nombre minimum d'adresses IP par nœud.

Il est recommandé d'utiliser certaines variables de configuration pour contrôler le nombre d'interfaces réseau et d'adresses IP gérées.

Vérifier si les sous-réseaux existent et sont correctement labelisés (SubnetNotFound)

Pour vérifier que vos sous-réseaux existent, exécutez la commande suivante :

aws ec2 describe-subnets --subnet-ids subet-id --region region

Remarque : renseignez le champID du sous-réseau en indiquant l'ID de votre sous-réseau et le champrégion en indiquant la région où se trouvent les sous-réseaux.

Si les sous-réseaux n'existent pas, le message d'erreur suivant s'affiche :

An error occurred (InvalidSubnetID.NotFound) when calling the DescribeSubnets operation: The subnet ID 'subnet-id' does not exist

Pour vérifier que les sous-réseaux sont correctement labelisés :

1.    Identifiez les sous-réseaux associés au cluster en suivant les étapes de la section Vérifiez si vous avez suffisamment d'adresses IP disponibles (IPNotAvailable).

2.    Ouvrez la console VPC.

3.    Sélectionnez Sous-réseaux dans la barre latérale.

4.    Sélectionnez les sous-réseaux qui doivent être associés au cluster et choisissez l'onglet Balises dans le volet Détails.

5.    Vérifiez que chaque sous-réseau possède les bonnes balises :

Key - kubernetes.io/cluster/cluster-name

Remarque : la balise précédente est ajoutée uniquement aux versions 1.18 ou antérieures du cluster Amazon EKS. Pour les clusters créés avec Kubernetes version 1.19 et versions ultérieures, la balise n'est pas obligatoire. Remplacez cluster name par le nom de votre cluster.

La valeur de la balise peut être partagée ou détenue.

Si vous avez un plan de support, contactez l'équipe de support pour mettre à jour vos sous-réseaux Amazon EKS.

Vérifiez que les groupes de sécurité associés au cluster existent (SecurityGroupNotFound)

Pour identifier les groupes de sécurité associés au cluster :

1.    Ouvrez la console Amazon EKS dans la région dans laquelle vous avez créé votre cluster.

2.    Sélectionnez le cluster.

3.    Choisissez l'onglet Configuration.

4.    Choisissez l'onglet Réseaux.

5.    Sélectionnez les groupes de sécurité répertoriés dans la rubrique Groupe de sécurité du cluster et Groupes de sécurité supplémentaires.

Si le groupe de sécurité existe, la console s'ouvre et affiche ses détails.

À partir d'AWS CLI :

1.    Obtenir les groupes de sécurité associés au cluster :

$ aws eks describe-cluster --name cluster-name --region your-region

Remarque : Remplacez le cluster-name par le nom de votre cluster et la région par votre région.

Sortie :

...
"securityGroupIds": [
    "sg-xxxxxxxx"
]
...

2.    Décrivez le groupe de sécurité de la sortie précédente :

$ aws ec2 describe-security-groups --group-ids security-group-id --region your-region

Remarque : Remplacez security-group-id par l'ID de votre groupe de sécurité et your-region par votre région.

Augmenter le quota d'interface réseau Elastic pour le compte AWS (EniLimitReached)

Si vous avez atteint votre quota d'interface réseau, vous pouvez supprimer les interfaces réseau inutilisées ou demander une augmentation de limite .

Si vos interfaces réseau sont attachées à un cluster, supprimez le cluster pour supprimer l'interface réseau. Si vos interfaces réseau sont attachées à des composants master inutilisés, supprimez le groupe Auto Scaling pour les groupes de nœuds autogérés. Pour les groupes de nœuds gérés, supprimez le groupe de nœuds de la console Amazon EKS. Pour déplacer des charges de travail d'un groupe de nœuds vers un autre,consultez la section Migration vers un nouveau groupe de nœuds.

Vérifiez que vous disposez des autorisations appropriées (AccessDenied)

1.    Ouvrez la console IAM.

2.    Dans le panneau de navigation, sélectionnez Rôles ou Utilisateurs.

3.    Sélectionnez le rôle ou l'utilisateur.

4.    Vérifiez que le rôle ou l'utilisateur IAM dispose des autorisations appropriées.

Vérifiez que la fonction du service possède les autorisations appropriées (OperationNotPermitted)

1.    Ouvrez la console IAM.

2.    Dans le panneau de navigation, sélectionnez Rôles.

3.    Filtrez pour AWSServiceRoleForAmazoneks et sélectionnez le rôle.

4.    Vérifiez que la politique AmazoneksServiceRolePolicy est attachée au rôle.

Si tel n'est pas le cas, consultez la section Ajout d'autorisations d'identité IAM.

Vérifiez que le VPC associé au cluster existe (VPCNotFound)

1.    Ouvrez la console Amazon EKS dans la région dans laquelle vous avez créé votre cluster.

2.    Sélectionnez le cluster.

3.    Choisissez l'onglet Configuration.

4.    Choisissez l'onglet Réseaux.

5.    Sélectionnez le lien ID du VPC pour voir si le VPC existe.

Si le VPC n'existe pas, vous devez créer un nouveau cluster.

Vérifiez que les ressources associées au cluster ont été supprimées

Si vous avez créé le cluster sur la console Amazon EKS et que les sous-réseaux utilisés pour créer le cluster ont été supprimés, le cluster ne peut pas être mis à jour. Vous devez recréer le cluster et déplacer les charges de travail de l'ancien cluster vers le nouveau. Si vous avez un plan de support, contactez l'équipe de support pour mettre à jour vos sous-réseaux Amazon EKS.

Vérifiez que la pile AWS CloudFormation n'a pas réussi à revenir en arrière (eksctl)

Si la restauration de la pile CloudFormation échoue, consultez la section Comment puis-je mettre à jour ma pile CloudFormation si elle est bloquée dans l'état UPDATE_ROLLBACK_FAILED ?

Attendez un certain temps avant de relancer la mise à jour du plan de contrôle (ResourceInUseException)

Cette erreur se produit si une action automatique du plan de contrôle Amazon EKS, telle qu'une mise à jour de la version de la plateforme, est en cours lorsque vous lancez une mise à jour. Amazon EKS détecte et remplace automatiquement les instances de plan de contrôle défectueuses, et fournit des mises à niveau de version automatisées et des correctifs correspondants. Attendez la fin de l'action automatique avant de lancer à nouveau la mise à jour du plan de contrôle.

Remarque : Votre temps d'attente dépend du début de la mise à jour automatique. Si vous ne savez pas quand l'action automatique sera résolue, attendez une heure avant de réessayer la mise à jour du plan de contrôle.

Mettez à jour à nouveau le cluster

Les problèmes transitoires peuvent entraîner l'instabilité des flux du backend. Si les étapes de dépannage précédentes ne concernent pas votre problème, essayez à nouveau de mettre à jour le cluster.


AWS OFFICIEL
AWS OFFICIELA mis à jour il y a un an