¿Cómo funciona el proceso de arranque del clúster de EKS Anywhere?

Resolución

El clúster de arranque

Al crear un clúster independiente inicial o uno de administración, Amazon EKS Anywhere también crea un clúster de arranque. Se trata de un clúster temporal de Kubernetes in Docker (KinD) de un solo nodo que se crea en un Equipo administrador independiente para facilitar la creación del clúster principal.

EKS Anywhere crea un clúster de arranque en el equipo administrador que aloja los operadores CAPI y CAPX. Para crear el clúster de arranque, EKS Anywhere tiene que completar los siguientes pasos:

• Extraer la imagen del nodo KinD
• Preparar el nodo
• Escribir la configuración
• Iniciar el plano de control
• Instalar la CNI
• Instalar StorageClass en el clúster de un solo nodo basado en KinD

Creación del clúster

Cuando el clúster de arranque se ejecuta y está configurado correctamente en el equipo administrador, comienza la creación del clúster de destino. EKS Anywhere usa kubectl para aplicar una configuración de clúster de destino en el siguiente proceso:

1.    Una vez que etcd, el plano de control y los nodos de trabajo estén listos, el clúster de destino recibirá su configuración de red.

2.    El clúster de destino recibe la instalación de su clase de almacenamiento predeterminada.

3.    Los proveedores de CAPI se configuran en el clúster de destino. Esto permite que el clúster de destino controle y ejecute los componentes que necesita para administrarse por sí mismo.

4.    Una vez que CAPI se ejecuta en el clúster de destino, los objetos CAPI se mueven del clúster de arranque al servicio CAPI del clúster de destino. Esto ocurre internamente con el comando clusterctl.

5.    El clúster de destino recibe los CRD de Kubernetes y otros complementos específicos de EKS Anywhere.

6.    Se guarda la configuración del clúster.

El proceso de arranque crea un archivo YAML que está ubicado en CLUSTER_NAME/generated/CLUSTER_NAME-eks-a-cluster.yaml.

Cuando el arranque se ejecuta correctamente, el archivo YAML se mueve a CLUSTER_NAME/CLUSTER_NAME-eks-a-cluster.yaml.

Del mismo modo, Kubeconfig pasa de CLUSTER_NAME/generated/CLUSTER_NAME.kind.kubeconfig a CLUSTER_NAME/CLUSTER_NAME-eks-a-cluster.kubeconfig.

Cuando etcd, el plano de control y los nodos de trabajo están listos, el clúster de carga de trabajo recibe su configuración de red. Cuando el clúster está activo y el servicio CAPI se ejecuta en el nuevo clúster, el clúster de arranque deja de ser necesario. A continuación, el servicio elimina el clúster de arranque.

Flujos de trabajo del paquete

Durante el proceso de arranque, EKS Anywhere usa la siguiente lógica en sus flujos de trabajo para crear, actualizar y eliminar el clúster de destino.

Creación de clústeres

Para ver el flujo de trabajo completo del paquete durante la creación de un clúster, consulte create.go en GitHub. Durante este flujo de trabajo, EKS Anywhere usa la siguiente lógica:

• Configuraciones y validaciones
  Nota: Si se produce un error en este paso, significa que las comprobaciones previas han fallado o que el registro no está configurado correctamente.
• Creación de un nuevo clúster de arranque
  Creación de un nuevo clúster de KinD
  Pre-capi-install-setup específica del proveedor en el clúster de arranque
  Instalación de los proveedores de cluster-api en el clúster de arranque
  Configuración posterior específica del proveedor
• Creación de un nuevo clúster de carga de trabajo
  Esperar a que el etcd externo esté listo
  Esperar a que el plano de control esté disponible
  Esperar a que se genere kubeconfig de la carga de trabajo
  Instalación de red en el clúster de carga de trabajo
  Instalación de las comprobaciones de estado del equipo en el clúster de arranque
  Esperar a que el plano de control y los equipos de trabajo estén listos
• Instalación de los recursos de administración
• Instalación de la tarea de componentes eks-a
• Instalación del administrador de operaciones de Git
• Traslado de la administración de clúster
• Escribir ClusterConfig
• Eliminación del clúster de arranque
• Instalación de los paquetes seleccionados

Actualización de clústeres

Para ver el flujo de trabajo completo del paquete durante la actualización de un clúster, consulte upgrade.go en GitHub. Durante este flujo de trabajo, EKS Anywhere usa la siguiente lógica:

• Configuraciones y validaciones
• Actualización de secretos
• Verificación de que existan los componentes CAPI de etcd
• Actualización de los componentes principales
• Verificación de la actualización necesaria
• Pausa de la conciliación de eks-a
• Creación del clúster de arranque
• Instalación de CAPI
• Traslado de la administración al clúster de arranque
• Traslado de la administración al clúster de carga de trabajo
• Actualización del clúster de carga de trabajo
• Eliminación del clúster de arranque
• Actualización del clúster de carga de trabajo y los recursos de Git
• Reanudación de la conciliación de eks-a
• Escribir ClusterConfig

Eliminación de clústeres

Para ver el flujo de trabajo completo del paquete durante la eliminación de un clúster, consulte delete.go en GitHub. Durante este flujo de trabajo, EKS Anywhere usa la siguiente lógica:

• Configuraciones y validaciones
• Creación de un clúster de administración
• Instalación de CAPI
• Traslado de la administración de clúster
• Eliminación del clúster de carga de trabajo
• Limpieza del repositorio de Git
• Eliminación de los recursos del paquete
• Eliminación del clúster de administración

Errores durante la creación de clústeres

Si surgen problemas o errores, busque los registros en el equipo administrador y en capc-controller-manager. Vea los registros de capc-controller-manager con kubectl en el espacio de nombres capc-system. Para obtener más información sobre la resolución de problemas, compruebe el estado de los objetos CAPI de su clúster, que se encuentran en el espacio de nombres eksa-system.

También puede encontrar información relacionada sobre los errores en los registros de otros administradores de CAPI, como capi-kubeadm-bootstrap-controller, capi-kubeadm-control-plane-controller y capi-controller-manager. Estos administradores trabajan juntos y puede localizar cada uno en su propio espacio de nombres con el comando get pods -A de kubectl. Para obtener más información, consulte la guía de resolución de problemas de EKS Anywhere.

Para ver un script que corrija los errores de linting durante el proceso de arranque, consulte bootstrapper.go en GitHub.

Información relacionada

KinD quick start (en el sitio web de KinD)

Cluster creation workflow