Comment fonctionne le démarrage d'un cluster EKS Anywhere ?

Résolution

Le cluster bootstrap

Lorsque vous créez un cluster autonome initial ou un cluster de gestion, Amazon EKS Anywhere crée également un cluster d'amorçage. Il s'agit d'un cluster Kubernetes in Docker (KinD) temporaire à nœud unique créé sur une machine administrative distincte pour faciliter la création de votre cluster principal.

EKS Anywhere crée un cluster d'amorçage sur la machine d'administration qui héberge les opérateurs CAPI et CAPX. Pour créer le cluster d'amorçage, EKS Anywhere doit suivre les étapes suivantes :

• Extraire l'image du nœud KinD
• Préparez le nœud
• Rédigez la configuration
• Démarrez le plan de contrôle
• Installez le CNI
• Installation de la StorageClass sur le cluster à nœud unique basé sur KinD

Création de clusters

Lorsque le cluster d'amorçage est en cours d'exécution et correctement configuré sur la machine d'administration, la création du cluster cible commence. EKS Anywhere utilise kubectl pour appliquer une configuration de cluster cible selon le processus suivant :

1.    Une fois que etcd, le plan de contrôle et les nœuds de travail sont prêts, le cluster cible reçoit sa configuration réseau.

2.    Le cluster cible reçoit l'installation de sa classe de stockage par défaut.

3.    Les fournisseurs CAPI sont configurés sur le cluster cible. Cela permet au cluster cible de contrôler et d'exécuter les composants dont il a besoin pour se gérer lui-même.

4.    Une fois l'interface CAPI exécutée sur le cluster cible, les objets CAPI sont déplacés du cluster d'amorçage vers le service CAPI du cluster cible. Cela se produit en interne avec la commande clusterctl.

5.    Le cluster cible reçoit des CRD Kubernetes et d'autres modules complémentaires spécifiques à EKS Anywhere.

6.    La configuration du cluster est enregistrée.

Le processus d'amorçage crée un fichier YAML qui se trouve dans CLUSTER_NAME/generated/CLUSTER_NAME-eks-a-cluster.yaml.

Lorsque le boostrapping réussit, ce fichier YAML est déplacé vers CLUSTER_NAME/CLUSTER_NAME-eks-a-cluster.yaml

De même, Kubeconfig passe de CLUSTER_NAME/generated/CLUSTER_NAME.kind.kubeconfig à CLUSTER_NAME/CLUSTER_NAME-eks-a-cluster.kubeconfig.

Lorsque etcd, le plan de contrôle et les nœuds de travail sont prêts, le cluster de charge de travail reçoit sa configuration réseau. Lorsque le cluster est actif et que le service CAPI s'exécute sur le nouveau cluster, le cluster d'amorçage n'est plus nécessaire. Le service supprime ensuite le cluster d'amorçage.

Flux de travail liés

Au cours du processus d'amorçage, EKS Anywhere utilise la logique suivante dans ses flux de travail pour la création, la mise à niveau et la suppression du cluster cible.

Création de clusters

Pour le flux de travail complet du package lors de la création du cluster, consultez create.go sur GitHub. Au cours de ce flux de travail, EKS Anywhere utilise la logique suivante :

• Configurations et validations
  Remarque : Si cette étape échoue, cela signifie que les prévols ont échoué ou que le registre n'est pas correctement configuré.
• Création d'un nouveau cluster d'amorçage
  Création d'un nouveau cluster KinD
  Configuration de pré-installation spécifique au fournisseur sur le cluster bootstrap
  Installer les fournisseurs d'API de cluster sur un cluster bootstrap
  Post-configuration spécifique au fournisseur
• Création d'un nouveau cluster de charge de travail
  Attendez que l'etcd externe soit prêt
  Attendez que le plan de contrôle soit disponible
  Attendre la génération de kubeconfig pour la charge de travail
  Installation de la mise en réseau du cluster sur la charge de travail
  Installer les contrôles de santé de la machine sur le cluster d'amorçage
  Attendez que le plan de commande et les machines de travail soient prêts
• Installer des ressources sur la gestion
• Installation de la tâche relative aux composants eks-a
• Installation du gestionnaire Git ops
• Déplacer la gestion des clusters
• Écrire ClusterConfig
• Supprimer le cluster bootstrap
• Installation de packages sélectionnés

Mise à niveau du cluster

Pour le flux de travail complet du package lors de la mise à niveau d'un cluster, consultez upgrade.go sur GitHub. Au cours de ce flux de travail, EKS Anywhere utilise la logique suivante :

• Configurations et validations
• Mettre à jour les secrets
• Vérifier que les composants CAPI etcd existent
• Mettre à niveau les composants principaux
• Vérifiez la mise à niveau requise
• Pause eks-a reconciliation
• Création du cluster bootstrap
• Installez CAPI
• Déplacer la gestion vers le cluster bootstrap
• Déplacer la gestion vers le cluster de charge de travail
• Mettre à niveau le cluster de charge de travail
• Supprimer le cluster bootstrap
• Mettre à jour le cluster de charge de travail et les ressources Git
• Reprendre la réconciliation eks-a
• Écrire ClusterConfig

Suppression du cluster

Pour le flux de travail complet du package lors de la suppression d'un cluster, consultez delete.go sur GitHub. Au cours de ce flux de travail, EKS Anywhere utilise la logique suivante :

• Configurations et validations
• Création d'un cluster de gestion
• Installez CAPI
• Déplacer la gestion des clusters
• Supprimer le cluster de charge de travail
• Nettoyez le référentiel Git
• Supprimer les ressources du package
• Supprimer le cluster de gestion

Erreurs lors de la création du cluster

Si vous rencontrez des problèmes ou des erreurs, recherchez les journaux dans la machine d'administration et dans le capc-controller-manager. Consultez les journaux du gestionnaire capc-controller-manager avec kubectl dans l'espace de noms capc-system. Pour un dépannage plus approfondi, vérifiez l'état des objets CAPI de votre cluster, situés dans l'espace de noms eksa-system.

Vous pouvez également trouver des informations connexes sur les erreurs dans les journaux d'autres gestionnaires CAPI, tels que capi-kubeadm-bootstrap-controller, capi-kubeadm-control-plane-controller et capi-controller-manager. Ces gestionnaires travaillent ensemble et vous pouvez les localiser dans leur propre espace de noms à l'aide de la commande kubectl get pods -A. Pour plus d'informations, consultez le guide de dépannage d'EKS Anywhere.

Pour un script permettant de corriger les erreurs de linting pendant le processus d'amorçage, consultez bootstrapper.go sur GitHub.

Informations connexes

Démarrage rapide de KinD (sur le site Web de KinD)

Processus de création de clusters