Verificaciones previas

Las verificaciones de solicitud preliminar son una medida preventiva para ayudar a identificar problemas antes de que inicies una operación importante del clúster, como crear o actualizar clústeres. Cuando estas verificaciones se ejecutan automáticamente antes de una operación, no se realizan cambios en tus clústeres, a menos que todas las verificaciones de solicitud preliminar se aprueben. También puedes ejecutar verificaciones de solicitud preliminar según demanda.

En este documento, se describe cada verificación, en qué circunstancias se ejecuta automáticamente, cómo y cuándo ejecutarla de forma manual, y cómo interpretar los resultados.

En Google Distributed Cloud, puedes ejecutar comprobaciones de solicitud preliminar para diferentes situaciones:

• Google Distributed Cloud ejecuta comprobaciones de solicitud preliminar cuando creas o actualizas clústeres y recursos del grupo de nodos con bmctl. Si las verificaciones fallan, no se realizan cambios. También puedes evitar estas verificaciones o ejecutarlas de forma explícita.

• Google Distributed Cloud también ejecuta verificaciones de solicitud preliminar internas cuando un clúster híbrido o de administrador crea o actualiza recursos de Kubernetes en clústeres de usuario. Las verificaciones se ejecutan antes de que los cambios se apliquen en los clústeres de usuarios afectados. Si las verificaciones fallan, no se realizan cambios.

Recursos personalizados PreflightCheck

Cuando se ejecuta una verificación de solicitud preliminar, Google Distributed Cloud crea un recurso personalizado PreflightCheck. Los recursos personalizados de PreflightCheck son persistentes y proporcionan un registro de las actividades y los resultados de la verificación de solicitud preliminar al vuelo.

Para recuperar recursos personalizados de PreflightCheck, haz lo siguiente:

1. Obtén una lista de las verificaciones de solicitud preliminar que se ejecutaron para un clúster determinado:

   kubectl get preflightchecks --kubeconfig ADMIN_KUBECONFIG --namespace CLUSTER_NAMESPACE
   

   Reemplaza lo siguiente:

   • ADMIN_KUBECONFIG: la ruta del archivo kubeconfig del clúster de administrador
   • CLUSTER_NAMESPACE: el espacio de nombres del clúster.

   La respuesta muestra los recursos por espacio de nombres. Puedes ejecutar kubectl get preflightchecks en todos los espacios de nombres para obtener una lista completa. Para cada recurso, la respuesta muestra la antigüedad del recurso y si se aprobaron o no las verificaciones de solicitud preliminar al vuelo. En la siguiente respuesta de ejemplo, se muestran los recursos PreflightCheck del espacio de nombres cluster-test-admin001.

   NAMESPACE              NAME                                PASS    AGE
   cluster-test-admin001   test-admin001                      true    52d
   cluster-test-admin001   test-admin001jkm4q                 true    52d
   cluster-test-admin001   test-admin001k79t7                 true    6d20h
   cluster-test-admin001   upgrade-cluster-20231106-222746    true    6d20h
   

2. Recupera los detalles de un recurso personalizado PreflightCheck específico:

   kubectl describe preflightchecks --kubeconfig ADMIN_KUBECONFIG --namespace CLUSTER_NAMESPACE
   

   Reemplaza lo siguiente:

   • ADMIN_KUBECONFIG: la ruta del archivo kubeconfig del clúster de administrador
   • CLUSTER_NAMESPACE: el espacio de nombres del clúster.

   En la siguiente respuesta de comando de muestra, se muestra un recurso PreflightCheck para una verificación de solicitud preliminar al vuelo correcta que se ejecutó como parte de la creación del clúster:

   Name:         create-cluster-20230922-175006
   Namespace:    cluster-test-user001
   Labels:       <none>
   Annotations:  <none>
   API Version:  baremetal.cluster.gke.io/v1
   Kind:         PreflightCheck
   Metadata:
     Creation Timestamp:  2023-09-22T17:50:11Z
     Generation:          1
     Resource Version:    6502800
     UID:                 917daf64-963d-44b4-a1f9-c54972a39191
   Spec:
     Check Image Version:  latest
     Config YAML:          ---
   apiVersion: v1
   kind: Namespace
   metadata:
     name: cluster-test-user
   ---
   apiVersion: baremetal.cluster.gke.io/v1
   kind: Cluster
   metadata:
     name: test-user001
     namespace: cluster-test-user001
   spec:
     type: user
     profile: default
     anthosBareMetalVersion: 1.16.0
     gkeConnect:
       projectID: clusters-project
     controlPlane:
       nodePoolSpec:
         nodes:
         - address: 192.0.2.53
     ...
   ---
   apiVersion: baremetal.cluster.gke.io/v1
   kind: NodePool
   metadata:
     name: node-pool-1
     namespace: cluster-test-user001
   spec:
     clusterName: test-user001
     nodes:
     - address: 192.0.2.54
     ...
   Status:
     Checks:
       192.0.2.53:
         Job UID:  d0b5dc1f-9d39-4cc8-b3d2-0841212f7f8c
         Message:  
         Pass:     true
       192.0.2.53-gcp:
         Job UID:  b4d96ce5-0d4e-4e3c-97db-6317e0c15fc8
         Message:  
         Pass:     true
       192.0.2.54:
         Job UID:  b67cf195-3951-46ad-b91c-0d79025cfc0a
         Message:  
         Pass:     true
       192.0.2.54-gcp:
         Job UID:  aed509e2-4bf7-44c4-bfa0-8147ef8ea74e
         Message:  
         Pass:     true
       Gcp:
         Job UID:  ac479ac4-e1c4-4681-9f2b-5773069bf6ae
         Message:  
         Pass:     true
       Node - Network:
         Job UID:  8a57c4ee-ad17-4560-8809-b117c871ad5d
         Message:  
         Pass:     true
       Pod - Cidr:
         Message:  
         Pass:     true
     Cluster Spec:
       Anthos Bare Metal Version:  1.16.0
       Bypass Preflight Check:     false
       Cluster Network:
         Bundled Ingress:  true
         Pods:
           Cidr Blocks:
             10.0.0.0/16
         Services:
           Cidr Blocks:
             10.96.0.0/20
     ...
     Completion Time:                 2023-09-22T17:51:22Z
     Conditions:
       Last Transition Time:  2023-10-02T23:59:06Z
       Observed Generation:   1
       Reason:                Reconciling
       Status:                True
       Type:                  Reconciling
     Node Pool Specs:
       node-pool-1:
         Cluster Name:  test-user001
         Nodes:
           Address:         192.0.2.54
       ...
     Pass:                  true
     Start Time:            2023-09-22T17:50:32Z
   Events:                  <none>
   

   En el recurso personalizado PreflightCheck anterior, la sección Status contiene la siguiente información:

   • En la sección Checks, se enumeran las comprobaciones de solicitud preliminar individuales que se ejecutaron y si se aprobaron o no. En este ejemplo, se ejecutaron las siguientes verificaciones:
     • 192.0.2.53 y 192.0.2.54: Verificaciones de nodos (configuración del SO, recursos y parámetros de configuración de software) para máquinas con direcciones IP 192.0.2.53 y 192.0.2.54.
     • 192.0.2.53-gpc y 192.0.2.54-gcp: Verificaciones de conectividad de Google Cloud (acceso a Container Registry y a la API de Google) para máquinas con direcciones IP 192.0.2.53 y 192.0.2.54.
     • Gcp: Las verificaciones de conectividad de Google Cloud para el clúster
     • Node - Network: Verificaciones de red (conectividad, operación de etcd, acceso a VIP y vinculación de puertos) para el clúster.
     • Pod - Cidr: La dirección IP del Pod verifica si hay direcciones superpuestas para el clúster.
   • En la sección Cluster Spec, se muestra la configuración del clúster.
   • El campo Pass muestra true, lo que indica que las verificaciones de solicitud preliminar a la conexión se aprobaron de forma colectiva.

Registros de las comprobaciones de solicitud preliminar

Cuando se ejecutan las verificaciones de solicitud preliminar como resultado de un comando bmctl, como bmctl check preflight, Google Distributed Cloud crea archivos de registro. Esto es lo que se genera y dónde:

• Los registros de comprobaciones de solicitud preliminar se generan en un directorio con el siguiente patrón de nombre preflight-TIMESTAMP.

• Este directorio de verificación de solicitud preliminar se crea en el directorio log del clúster en el espacio de trabajo bmctl. De forma predeterminada, la ruta de acceso del directorio log es bmctl-workspace/CLUSTER_NAME/log.

• Los registros de verificación de solicitud preliminar consisten en los siguientes archivos:

  • Archivos de registro para las verificaciones de máquinas de nodos, uno para cada nodo del clúster. Estos archivos de registro se nombran con la dirección IP del nodo. Por ejemplo, un nombre de archivo podría ser 192.0.2.53.

  • Archivos de registro para las verificaciones de acceso de Google Cloud, uno para cada nodo del clúster Estos archivos de registro se nombran con la dirección IP del nodo. Por ejemplo, un nombre de archivo podría ser 192.0.2.53-gcp.

  • Es el archivo de registro de las verificaciones de acceso de Google Cloud del clúster, que se denomina gcp.

  • Archivo de registro para las verificaciones de red del nodo, que se denomina node-network.

Si una verificación de solicitud preliminar falla, estos archivos de registro pueden ayudarte a identificar y solucionar el problema.

Comprobaciones de solicitud preliminar para la creación de clústeres

Cuando creas clústeres, Google Distributed Cloud ejecuta automáticamente verificaciones de solicitud preliminar antes de que se realicen cambios.

¿Qué se verifica?

Las verificaciones de solicitud preliminar a la instalación verifican lo siguiente:

• Verificaciones de la máquina de nodos:

  • Las máquinas del clúster usan un sistema operativo (SO) compatible.

  • La versión del SO es compatible.

  • El SO usa una versión de kernel compatible.

  • En Ubuntu, el firewall sin complicaciones (UFW) está inhabilitado.

  • En Ubuntu, el administrador de paquetes apt es operativo y los paquetes necesarios están disponibles.

  • En Red Hat Enterprise Linux, el administrador de paquetes dnf es operativo y los paquetes necesarios están disponibles.

  • En Red Hat Enterprise Linux, Podman no está instalado.

  • Las máquinas de nodos cumplen con los requisitos mínimos de CPU.

  • Las máquinas de nodos cumplen con los requisitos mínimos de memoria.

  • Las máquinas de nodos cumplen con los requisitos mínimos de almacenamiento en disco.

  • La sincronización de tiempo se configura en las máquinas de nodos.

  • kubelet está activo y se ejecuta en máquinas de nodos.

  • containerd está activo y se ejecuta en máquinas de nodos.

  • La ruta predeterminada para enrutar paquetes a la puerta de enlace predeterminada está presente en los nodos.

  • El sistema de nombres de dominio (DNS) funciona correctamente. Si el clúster está configurado para ejecutarse detrás de un proxy, se omite esta verificación.

  • Los CIDRs de los Pods no se superponen con las direcciones IP de las máquinas de los nodos.

  • Si el clúster está configurado para usar una duplicación de registro, se puede acceder a esta.

• Google Cloud verifica lo siguiente para cada nodo y el clúster:

  • Se verifica la accesibilidad de Container Registry, gcr.io. Si el clúster está configurado para usar un espejo de registro, se omite esta verificación.

  • Se puede acceder a las APIs de Google.

• Verificaciones de red del nodo (varía según la configuración del balanceo de cargas):

  • Se puede acceder a la VIP del servidor de la API de Kubernetes.

  • Se puede acceder a las VIP del balanceador de cargas.

  • Los nodos pueden comunicarse en los puertos requeridos.

  • La instancia de eventos etcd se aprovisionó y se cumplen los requisitos de puerto.

Cuando se aprueben todas las verificaciones, Google Distributed Cloud creará el clúster. Para obtener más información sobre los requisitos para crear clústeres, consulta Descripción general de los requisitos previos de instalación.

Ejecuta verificaciones de solicitud preliminar a pedido para la creación de clústeres

También puedes ejecutar verificaciones de solicitud preliminar con  antes de crear un clúster. Hacerlo puede ser beneficioso, ya que las operaciones principales del clúster, como la creación del clúster, requieren mucho tiempo. Identificar y resolver los problemas por separado antes de iniciar una operación importante del clúster puede ayudarte con la programación.

Nota: Las verificaciones de solicitud preliminar se actualizan a medida que se identifican los problemas conocidos. Para dirigir a bmctl a que ejecute las verificaciones desde la imagen de parche más reciente de la versión menor instalada, usa la marca de opción --check-image-version latest. Para obtener más información, consulta Ejecuta las verificaciones de solicitud preliminar más recientes.

Clústeres autoadministrados

• Con el siguiente comando, se valida el archivo de configuración de clústeres especificado, pero no se intenta crear el clúster:

  bmctl check config --cluster CLUSTER_NAME
  

  Reemplaza CLUSTER_NAME por el nombre del clúster asociado con el archivo de configuración que verificas.

• Este comando comprueba si las máquinas y la red están listas para la creación del clúster:

  bmctl check preflight --cluster CLUSTER_NAME
  

  Reemplaza CLUSTER_NAME por el nombre del clúster que deseas verificar.

Clústeres de usuarios

• Con el siguiente comando, se valida el archivo de configuración de clústeres especificado, pero no se intenta crear el clúster:

  bmctl check config --cluster CLUSTER_NAME --admin-kubeconfig ADMIN_KUBECONFIG
  

  Reemplaza lo siguiente:

  • CLUSTER_NAME: Es el nombre del clúster de usuario que verificas.
  • ADMIN_KUBECONFIG: la ruta del archivo kubeconfig del clúster de administrador

• El siguiente comando comprueba si las máquinas y la red están listas para la creación del clúster:

  bmctl check preflight --cluster CLUSTER_NAME --admin-kubeconfig ADMIN_KUBECONFIG
  

bmctl admite el uso de --kubeconfig como un alias para la marca --admin-kubeconfig.

Comprobaciones de solicitud preliminar para la actualización de clústeres

Cuando actualizas clústeres, Google Distributed Cloud ejecuta automáticamente verificaciones de solicitud preliminar antes de que se realicen cambios.

¿Qué se verifica?

Las verificaciones de solicitud preliminar para las actualizaciones de clústeres verifican lo siguiente:

• Verificaciones de la máquina de nodos:

  • Las máquinas del clúster usan un sistema operativo (SO) compatible.

  • La versión del SO es compatible.

  • El SO usa una versión de kernel compatible.

  • En Ubuntu, el firewall sin complicaciones (UFW) está inhabilitado.

  • Las máquinas de nodos cumplen con los requisitos mínimos de CPU.

  • Las máquinas de nodos tienen más del 20% de los recursos de CPU disponibles.

  • Las máquinas de nodos cumplen con los requisitos mínimos de memoria.

  • Las máquinas de nodos cumplen con los requisitos mínimos de almacenamiento en disco.

  • La sincronización de tiempo se configura en las máquinas de nodos.

  • La ruta predeterminada para enrutar paquetes a la puerta de enlace predeterminada está presente en los nodos.

  • El sistema de nombres de dominio (DNS) funciona correctamente. Si el clúster está configurado para ejecutarse detrás de un proxy, se omite esta verificación.

  • Si el clúster está configurado para usar una duplicación de registro, se puede acceder a esta.

  * No hay nodos del plano de control ni del balanceador de cargas en modo de mantenimiento.

• Google Cloud verifica lo siguiente para cada nodo y el clúster:

  • Se verifica la accesibilidad de Container Registry, gcr.io. Si el clúster está configurado para usar un espejo de registro, se omite esta verificación.

  • Se puede acceder a las APIs de Google.

• Verificaciones de máquinas:

  • kubelet está activo y se ejecuta en máquinas de nodos.

  • containerd está activo y se ejecuta en máquinas de nodos.

  • El estado del extremo de estado de la interfaz de red de contenedor (CNI) es bueno.

  • Los CIDRs de los Pods no se superponen con las direcciones IP de las máquinas de los nodos.

• Verificaciones de red del nodo (varía según la configuración del balanceo de cargas):

  • Se puede acceder a la VIP del servidor de la API de Kubernetes.

  • Se puede acceder a las VIP del balanceador de cargas.

  • Los nodos pueden comunicarse en los puertos requeridos.

  • La instancia de eventos etcd se aprovisionó y se cumplen los requisitos de puerto.

Nota: En las máquinas de nodo del clúster, si el ejecutable de Docker está presente en la variable de entorno PATH, pero el servicio de Docker no está activo, la verificación de comprobación de solicitud preliminar falla. Puedes quitar Docker o habilitar el servicio de Docker.

Cuando se aprueben todas las verificaciones, Google Distributed Cloud actualizará el clúster. Para obtener más información sobre la actualización de clústeres, consulta Prácticas recomendadas para las actualizaciones de clústeres de Google Distributed Cloud y Ciclo de vida y etapas de las actualizaciones de clústeres.

Ejecuta verificaciones de solicitud preliminar a pedido para las actualizaciones de clústeres

El comando bmctl check preflight te permite ejecutar una verificación de solicitud preliminar antes de actualizar tu clúster. Para verificar si los clústeres están listos para una actualización, ejecuta el siguiente comando de verificación de solicitud preliminar antes de comenzar la actualización:

Nota: Las verificaciones de solicitud preliminar se actualizan a medida que se identifican los problemas conocidos. Para dirigir a bmctl a que ejecute las verificaciones desde la imagen de parche más reciente de la versión menor instalada, usa la marca de opción --check-image-version latest. Para obtener más información, consulta Ejecuta las verificaciones de solicitud preliminar más recientes.

1. Actualiza la versión del clúster (anthosBareMetalVersion) en el archivo de configuración del clúster.

2. Usa el siguiente comando para verificar si los clústeres están listos para una actualización y ejecutar una verificación de solicitud preliminar:

   bmctl check preflight --cluster CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG
   

   Reemplaza lo siguiente:

   • CLUSTER_NAME: el nombre del clúster que se actualizará
   • ADMIN_KUBECONFIG es la ruta al archivo kubeconfig del clúster de administrador.

   Cuando creas la comprobación de solicitud preliminar con este comando para probar una actualización de clúster, se crea un recurso personalizado de PreflightCheck en el clúster de administrador.

Comprobación de solicitud preliminar interna en clústeres existentes

Google Distributed Cloud realiza verificaciones de solicitud preliminar internas automáticamente cuando aplicas recursos de Kubernetes a un clúster existente. Si alguna verificación falla, Google Distributed Cloud no cambia ninguno de los nodos relacionados, a menos que omitas las verificaciones de forma explícita.

Omite las verificaciones de solicitud preliminar cuando apliques recursos de Kubernetes

Para ignorar las verificaciones de solicitud preliminar internas cuando aplicas recursos a los clústeres existentes, debes establecer el campo BypassPreflightCheck en true en el archivo de configuración del clúster.

Esta es una parte de un archivo de configuración de clúster que muestra el campo bypassPreflightCheck configurado como true:

apiVersion: v1
kind: Namespace
metadata:
  name: cluster-user1
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: user1
  namespace: cluster-user1
spec:
  type: user
  bypassPreflightCheck: true
  # Anthos cluster version.
  anthosBareMetalVersion: 1.30.100-gke.96
...

Ejecuta las verificaciones de solicitud preliminar más recientes

Las verificaciones de solicitud preliminar (y las verificaciones de estado) se actualizan a medida que se identifican los problemas conocidos. Para dirigir a bmctl a que ejecute las verificaciones desde la imagen de parche más reciente de la versión secundaria instalada, usa la marca de opción --check-image-version latest:

bmctl check preflight --cluster CLUSTER_NAME --check-image-version latest

Reemplaza CLUSTER_NAME por el nombre del clúster que deseas verificar.

Esto puede ayudarte a detectar cualquier problema conocido identificado recientemente sin crear o actualizar primero tu clúster.

También puedes realizar las verificaciones de estado más recientes de un clúster activo para determinar si funciona correctamente. Para obtener más información, consulta Ejecuta las verificaciones de estado más recientes.

Ignora los resultados de las comprobaciones previas

Si ejecutas verificaciones previas a pedido antes de crear o actualizar clústeres, puedes omitir las verificaciones de solicitud preliminar automatizadas. Para omitir las verificaciones de solicitud preliminar automatizadas, usa la marca opcional --force cuando ejecutes bmctl create cluster o bmctl upgrade cluster.

¿Qué sigue?

• Verificaciones de estado

• Detector de problemas del nodo

• Verifica la conectividad del clúster con nettest

• Crea instantáneas para ayudar a diagnosticar problemas de clústeres