Comment résoudre les problèmes liés à la configuration de Cluster Autoscaler sur un cluster Amazon EKS ?

Brève description

Assurez-vous de vérifier les points suivants avant de commencer :

• Vous avez installé ou mis à jour eksctl vers la dernière version.
• Remplacez les valeurs d'espace réservé dans les extraits de code par vos propres valeurs.

Remarque : la variable --region n'est pas toujours utilisée dans les commandes, car la valeur par défaut de votre région AWS est utilisée. Vérifiez la valeur par défaut en exécutant la commande de configuration de l'interface de la ligne de commande AWS (AWS CLI). Si vous devez modifier la région AWS, utilisez l'indicateur --region.

Remarque : si vous recevez des erreurs lors de l'exécution des commandes d'AWS CLI, vérifiez que vous exécutez une version récente d'AWS CLI.

Résolution

Le pod Cluster Autoscaler est dans l'état CrashLoopBackOff

Vérifiez l'état du pod Cluster Autoscaler en exécutant la commande suivante :

kubectl get pods -n kube-system | grep cluster-autoscaler

Voici un exemple de pod Cluster Autoscaler dont l'état est CrashLoopBackOff :

NAME                            READY   STATUS             RESTARTS      AGE
cluster-autoscaler-xxxx-xxxxx   0/1     CrashLoopBackOff   3 (20s ago)   99s

Consultez les journaux du pod Cluster Autoscaler en exécutant la commande suivante :

kubectl logs -f -n kube-system -l app=cluster-autoscaler

Si les journaux indiquent qu'il existe des problèmes d'autorisations AWS Identity and Access Management (IAM), procédez comme suit :

• Vérifiez qu'un fournisseur OIDC est associé au cluster Amazon EKS.
• Vérifiez que le compte de service Cluster Autoscaler est annoté avec le rôle IAM.
• Vérifiez que la politique IAM correcte est associée au rôle IAM précédent.
• Vérifiez que la relation de confiance est correctement configurée.

Remarque : voici un exemple de journal signalant des problèmes d'autorisations IAM :

Failed to create AWS Manager: cannot autodiscover ASGs: AccessDenied: User: xxx is not authorized to perform: autoscaling: DescribeTags because no identity-based policy allows the autoscaling:DescribeTags action status code: 403, request id: xxxxxxxx

Important : assurez-vous de vérifier toutes les commandes de l'AWS CLI données et de remplacer toutes les instances d'exemples de chaînes par vos valeurs. Par exemple, remplacez example-cluster par votre cluster.

Vérifiez qu'un fournisseur OIDC est associé au cluster EKS

1.    Vérifiez que vous disposez d'un fournisseur IAM OpenID Connect (OIDC) existant pour votre cluster en exécutant la commande suivante :

oidc_id=$(aws eks describe-cluster --name example-cluster --query "cluster.identity.oidc.issuer" --output text | cut -d '/' -f 5)

2.    Vérifiez qu'un fournisseur IAM OIDC avec l'ID de votre cluster figure déjà sur votre compte en exécutant la commande suivante :

aws iam list-open-id-connect-providers | grep $oidc_id | cut -d "/" -f4

Remarque : si la sortie est renvoyée, cela signifie que vous disposez déjà d'un fournisseur IAM OIDC pour votre cluster et vous pouvez ignorer l'étape suivante. Si aucune sortie n'est renvoyée, vous devez créer un fournisseur IAM OIDC pour votre cluster à l'étape suivante.

3.    Créez un fournisseur d'identité IAM OIDC pour votre cluster en exécutant la commande suivante :

eksctl utils associate-iam-oidc-provider --cluster example-cluster --approve

Vérifiez que le compte de service Cluster Autoscaler est annoté avec le rôle IAM

Vérifiez que le compte de service est annoté avec le rôle IAM en exécutant la commande suivante :

kubectl get serviceaccount cluster-autoscaler -n kube-system -o yaml

Le résultat attendu est le suivant :

apiVersion: v1
kind: ServiceAccount
metadata:
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::012345678912:role/<cluster_auto_scaler_iam_role>
  name: cluster-autoscaler
  namespace: kube-system

Vérifiez que la politique IAM correcte est associée au rôle IAM précédent

Pour un exemple, consultez ce qui suit :

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "VisualEditor0",
      "Effect": "Allow",
      "Action": [
        "autoscaling:DescribeAutoScalingInstances",
        "autoscaling:SetDesiredCapacity",
        "autoscaling:DescribeAutoScalingGroups",
        "autoscaling:DescribeTags",
        "autoscaling:DescribeLaunchConfigurations",
        "ec2:DescribeLaunchTemplateVersions",
        "ec2:DescribeInstanceTypes",
        "autoscaling:TerminateInstanceInAutoScalingGroup"
      ],
      "Resource": "*"
    }
  ]
}

Vérifiez que la relation de confiance est correctement configurée

Pour un exemple, consultez ce qui suit :

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::<example_awsaccountid>:oidc-provider/oidc.eks.<example_region>.amazonaws.com/id/<example_oidcid>"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "oidc.eks.<example_region>.amazonaws.com/id/<example_oidcid>:aud": "sts.amazonaws.com",
          "oidc.eks.<example_region>.amazonaws.com/id/<example_oidcid>:sub": "system:serviceaccount:kube-system:cluster-autoscaler"
        }
      }
    }
  ]
}

Redémarrez le pod Cluster Autoscaler chaque fois qu'une modification est apportée au rôle du compte de service ou à la politique IAM.

Si les journaux indiquent des problèmes de réseau (par exemple, un délai d'attente d'E/S), procédez comme suit :

Remarque : voici un exemple de journal indiquant les problèmes de réseau :

Failed to create AWS Manager: cannot autodiscover ASGs: WebIdentityErr: failed to retrieve credentials caused by: RequestError: send request failed caused by: Post https://sts.region.amazonaws.com/: dial tcp: i/o timeout

1.    Vérifiez que le cluster Amazon EKS est configuré avec la configuration de mise en réseau requise. Vérifiez que le sous-réseau du composant master dispose d'une table de routage capable d'acheminer le trafic vers les points de terminaison suivants, que ce soit sur des points de terminaison mondiaux ou régionaux :

• Amazon Elastic Compute Cloud (Amazon EC2)
• AWS Auto Scaling
• Service de jetons de sécurité AWS (AWS STS)

2.    Assurez-vous que la liste de contrôle d'accès au réseau (ACL réseau) du sous-réseau ou que le groupe de sécurité du composant master ne bloquent pas le trafic communiquant avec ces points de terminaison.

3.    Si le cluster Amazon EKS est privé, vérifiez la configuration des points de terminaison Amazon Virtual Private Cloud (VPC) concernés. Par exemple, Amazon EC2, AWS Auto Scaling et AWS STS.

Remarque : le groupe de sécurité de chaque point de terminaison d'un VPC est requis pour autoriser le groupe de sécurité du composant master Amazon EKS. Il est également nécessaire d'autoriser le bloc CIDR du VPC Amazon EKS sur le port 443 sur le trafic entrant.

Cluster Autoscaler n'augmente pas ou ne réduit pas la taille des nœuds

Si votre Cluster Autoscaler n'augmente ni ne réduit la taille des nœuds, vérifiez les points suivants :

• Consultez les journaux du pod Cluster Autoscaler.
• Vérifiez le balisage des groupes Auto Scaling pour le Cluster Autoscaler.
• Vérifiez la configuration du manifeste de déploiement.
• Vérifiez le nombre actuel de nœuds.
• Vérifiez la demande de ressources du pod.
• Vérifiez la configuration de rejet du nœud dans le groupe de nœuds.
• Vérifiez si le nœud est annoté avec scale-down-disable.

Consulter les journaux du pod Cluster Autoscaler

Pour consulter les journaux des pods et identifier les raisons pour lesquelles votre Cluster Autoscaler n'augmente ni ne réduit la taille des nœuds, exécutez la commande suivante :

kubectl logs -f -n kube-system -l app=cluster-autoscaler

Vérifiez si le pod dans le statut Pending (En attente) contient des règles de planification, telles que la règle d'affinité, en exécutant la commande describe pod suivante :

kubectl describe pod <example_podname> -n <example_namespace>

Consultez la section events (événements) dans la sortie. Cette section fournit des informations sur les raisons pour lesquelles le statut d'un pod est en attente.

Remarque : Cluster Autoscaler respecte nodeSelector et requiredDuringSchedulingIgnoredDuringExecution dans nodeAffinity, en supposant que vous ayez étiqueté vos groupes de nœuds en conséquence. Dansle cas où un pod ne peut pas être planifié avec nodeSelector ou requiredDuringSchedulingIgnoredDuringExecution, Cluster Autoscaler ne prend en compte que les groupes de nœuds qui répondent à ces exigences pour l'expansion. Modifiez les règles de planification définies sur les pods ou les nœuds en conséquence afin qu'un pod soit planifié sur un nœud.

Vérifier le balisage des groupes Auto Scaling pour le Cluster Autoscaler

Le groupe Auto Scaling correspondant au groupe de nœuds doit être balisé pour que le Cluster Autoscaler détecte le groupe Auto Scaling comme suit :

Balise 1 :

• clé : k8s.io/cluster-autoscaler/example-cluster
• valeur : owned (possédé)

Balise 2 :

• clé : k8s.io/cluster-autoscaler/enabled
• Valeur : true (vrai)

Vérifier la configuration du manifeste de déploiement

Pour vérifier la configuration du manifeste de déploiement de Cluster Autoscaler, exécutez la commande suivante :

kubectl -n kube-system edit deployment.apps/cluster-autoscaler

Vérifiez que le manifeste est configuré avec le bon argument node-group-auto-discovery comme suit :

containers:
- command
   ./cluster-autoscaler
   --v=4
   --stderrthreshold=info
   --cloud-provider=aws
   --skip-nodes-with-local-storage=false
   --expander=least-waste
   --node-group-auto-discovery=asg:tag=k8s.io/cluster-autoscaler/enabled,k8s.io/cluster-autoscaler/example-cluster
   --balance-similar-node-groups
   --skip-nodes-with-system-pods=false

Vérifier le nombre actuel de nœuds

Pour vérifier si le nombre actuel de nœuds a atteint les valeurs minimales ou maximales du groupe de nœuds géré, exécutez la commande suivante :

aws eks describe-nodegroup --cluster-name <example-cluster> --nodegroup-name <example-nodegroup>

Si les valeurs minimales ou maximales sont atteintes, modifiez-les en fonction des nouvelles exigences de charge de travail.

Vérifier la demande de ressources du pod

Pour vérifier si la demande de ressource du pod ne peut pas être satisfaite par les types d'instances de nœuds actuels, exécutez la commande suivante :

kubectl -n <example_namespace> get pod <example_podname> -o yaml | grep resources -A6

Pour que la demande de ressources soit satisfaite, modifiez les demandes de ressources du pod ou créez un groupe de nœuds. Lorsque vous créez un groupe de nœuds, assurez-vous que le type d'instance des nœuds peut répondre aux besoins en ressources pour les pods.

Vérifier la configuration de rejet du nœud dans le groupe de nœuds

Vérifiez si les rejets sont configurées pour le nœud et si le pod peut les tolérer en exécutant la commande suivante :

kubectl describe node <example_nodename> | grep taint -A2

Si les rejets sont configurées, supprimez ceux qui sont définis sur le nœud. Si le pod ne tolère pas les rejets, définissez des tolérances sur le pod afin que le pod puisse être programmé sur le nœud présentant les rejets.

Vérifier si le nœud est annoté avec scale-down-disable

Pour vérifier que le nœud est annoté avec scale-down-disable, exécutez la commande suivante :

kubectl describe node <example_nodename> | grep scale-down-disable

Le résultat attendu est le suivant :

cluster-autoscaler.kubernetes.io/scale-down-disabled: true

Si scale-down-disable est défini sur true (vrai), supprimez l'annotation pour que la taille du nœud puisse être réduite en exécutant la commande suivante :

kubectl annotate node <example_nodename> cluster-autoscaler.kubernetes.io/scale-down-disabled-

Pour plus d'informations sur la résolution des problèmes, veuillez consulter les Questions fréquentes (FAQ) sur Cluster Autoscaler sur le site web de GitHub.

---