Comprobaciones preparatorias

Las comprobaciones previas son una medida preventiva que ayuda a identificar problemas antes de iniciar una operación importante en un clúster, como crear o actualizar clústeres. Cuando estas comprobaciones se ejecutan automáticamente antes de una operación, no se realizan cambios en los clústeres a menos que todas las comprobaciones previas se superen. También puedes hacer comprobaciones previas bajo demanda.

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

En Google Distributed Cloud, puedes ejecutar comprobaciones previas para diferentes situaciones:

  • Google Distributed Cloud ejecuta comprobaciones previas cuando creas o actualizas clústeres y recursos de grupos de nodos con bmctl. Si las comprobaciones fallan, no se harán cambios. También puedes omitir estas comprobaciones o ejecutarlas explícitamente.

  • Google Distributed Cloud también ejecuta comprobaciones preliminares internas cuando un administrador o un clúster híbrido crea o actualiza recursos de Kubernetes en clústeres de usuarios. Las comprobaciones se realizan antes de que se apliquen los cambios a los clústeres de usuarios afectados. Si no se superan las comprobaciones, no se aplicará ningún cambio.

PreflightCheck recursos personalizados

Cuando se ejecuta una comprobación previa, Google Distributed Cloud crea un PreflightCheckrecurso personalizado. Los recursos personalizados de PreflightCheck son persistentes y proporcionan un registro de las actividades y los resultados de la comprobación previa.

Para recuperar PreflightCheckrecursos personalizados, sigue estos pasos:

  1. Obtén una lista de las comprobaciones preparatorias que se han realizado en un clúster determinado:

    kubectl get preflightchecks --kubeconfig ADMIN_KUBECONFIG --namespace CLUSTER_NAMESPACE

    Haz los cambios siguientes:

    • 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. En el caso de cada recurso, la respuesta muestra la antigüedad del recurso y si se han superado o no las comprobaciones previas. En el siguiente ejemplo de respuesta 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 PreflightCheck recurso personalizado específico:

    kubectl describe preflightchecks --kubeconfig ADMIN_KUBECONFIG --namespace CLUSTER_NAMESPACE

    Haz los cambios siguientes:

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

    La siguiente respuesta de comando de ejemplo muestra un recurso PreflightCheck de una comprobación previa correcta que se ha ejecutado 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 PreflightCheckrecurso personalizadoStatus anterior, la sección Status contiene la siguiente información:

    • En la sección Checks se muestran las comprobaciones previas individuales que se han realizado y si se han superado o no. En este ejemplo, se han realizado las siguientes comprobaciones:
      • 192.0.2.53 y 192.0.2.54: comprobaciones de nodos (configuración del SO, recursos y ajustes de software) de 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: Google Cloud comprobaciones de conectividad (acceso a Artifact Registry y a las APIs de Google) para máquinas con las direcciones IP 192.0.2.53 y 192.0.2.54.
      • Gcp: Google Cloud comprobaciones de conectividad del clúster.
      • Node - Network: comprobaciones de red (conectividad, operación de etcd, acceso a VIP y vinculación de puertos) del clúster.
      • Pod - Cidr: comprueba si las direcciones IP de los pods se solapan en 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 comprobaciones previas se han completado correctamente.

Registros de comprobación preparatoria

Cuando se ejecutan comprobaciones previas al vuelo 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 comprobación previa se generan en un directorio con el siguiente patrón de nomenclatura: preflight-TIMESTAMP.

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

  • Los registros de comprobación previa constan de los siguientes archivos:

    • Archivos de registro de las comprobaciones de máquinas de nodos, uno por cada nodo del clúster. El nombre de estos archivos de registro se asigna mediante la dirección IP del nodo. Por ejemplo, un nombre de archivo podría ser 192.0.2.53.

    • Archivos de registro de las comprobaciones de acceso, uno por cada nodo del clúster. Google Cloud El nombre de estos archivos de registro es la dirección IP del nodo. Por ejemplo, el nombre de un archivo podría ser 192.0.2.53-gcp.

    • Archivo de registro de las comprobaciones de acceso al clúster Google Cloud , llamado gcp.

    • Archivo de registro de las comprobaciones de redes de nodos, llamado node-network.

Si falla una comprobación previa, estos archivos de registro pueden ayudarte a identificar y solucionar el problema.

Comprobaciones preparatorias para la creación de clústeres

Cuando crea clústeres, Google Distributed Cloud ejecuta automáticamente comprobaciones previas antes de que se apliquen los cambios.

¿Qué se comprueba?

Las comprobaciones preparatorias para la instalación verifican lo siguiente:

  • Comprobaciones de la máquina del nodo:

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

    • La versión del SO es compatible.

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

    • En Ubuntu, el cortafuegos Uncomplicated Firewall (UFW) está inhabilitado.

    • En Ubuntu, el gestor de paquetes apt funciona y los paquetes necesarios están disponibles.

    • En Red Hat Enterprise Linux, el gestor de paquetes dnf funciona y los paquetes necesarios están disponibles.

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

    • Los nodos cumplen los requisitos mínimos de CPU.

    • Los equipos de nodos cumplen los requisitos mínimos de memoria.

    • Los nodos cumplen los requisitos mínimos de almacenamiento en disco.

    • La sincronización de la hora está configurada en las máquinas de los nodos.

    • kubelet está activo y en ejecución en máquinas de nodos.

    • containerd está activo y en ejecución en máquinas de nodos.

    • La ruta predeterminada para enrutar paquetes a la pasarela 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, esta comprobación se omite.

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

    • Si el clúster está configurado para usar una réplica de registro, se puede acceder a ella.

  • Google Cloud comprobaciones de cada nodo y del clúster:

    • Artifact Registry, gcr.io, se comprueba la accesibilidad. Si el clúster está configurado para usar un mirror de registro, se omite esta comprobación.

    • Se puede acceder a las APIs de Google.

  • Comprobaciones de redes de nodos (varían en función de la configuración del balanceo de carga):

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

    • Se puede acceder a las IPs virtuales del balanceador de carga.

    • Los nodos pueden comunicarse en los puertos necesarios.

    • Se aprovisiona la instancia de eventos etcd y se cumplen los requisitos de puertos.

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

Realizar comprobaciones preparatorias bajo demanda para crear clústeres

También puedes ejecutar comprobaciones previas de forma independiente antes de crear un clúster. Esto puede ser útil, ya que las operaciones de clúster importantes, como la creación de clústeres, requieren mucho tiempo. Identificar y resolver los problemas por separado antes de iniciar una operación importante en el clúster puede ayudarte a programar.

Clústeres autogestionados

  • El siguiente comando valida el archivo de configuración del clúster especificado, pero no intenta crear el clúster en sí:

    bmctl check config --cluster CLUSTER_NAME

    Sustituye CLUSTER_NAME por el nombre del clúster asociado al archivo de configuración que estés comprobando.

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

    bmctl check preflight --cluster CLUSTER_NAME

    Sustituye CLUSTER_NAME por el nombre del clúster que quieres comprobar.

Clústeres de usuarios

  • El siguiente comando valida el archivo de configuración del clúster especificado, pero no intenta crear el clúster en sí:

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

    Haz los cambios siguientes:

    • CLUSTER_NAME: el nombre del clúster de usuarios que quieres comprobar.
    • ADMIN_KUBECONFIG: la ruta del archivo kubeconfig del clúster de administrador asociado.

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

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

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

Comprobaciones preparatorias para las actualizaciones de clústeres

Cuando actualizas clústeres, Google Distributed Cloud ejecuta automáticamente comprobaciones previas antes de que se apliquen los cambios.

¿Qué se comprueba?

Las comprobaciones preparatorias de las actualizaciones de clústeres verifican lo siguiente:

  • Comprobaciones de la máquina del nodo:

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

    • La versión del SO es compatible.

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

    • En Ubuntu, el cortafuegos Uncomplicated Firewall (UFW) está inhabilitado.

    • Los nodos cumplen los requisitos mínimos de CPU.

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

    • Los equipos de nodos cumplen los requisitos mínimos de memoria.

    • Los nodos cumplen los requisitos mínimos de almacenamiento en disco.

    • La sincronización de la hora está configurada en las máquinas de los nodos.

    • La ruta predeterminada para enrutar paquetes a la pasarela 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, esta comprobación se omite.

    • Si el clúster está configurado para usar una réplica de registro, se puede acceder a ella.

    • Ningún nodo del plano de control ni del balanceador de carga está en modo de mantenimiento.

  • Google Cloud comprobaciones de cada nodo y del clúster:

    • Artifact Registry, gcr.io, se comprueba la accesibilidad. Si el clúster está configurado para usar un mirror de registro, se omite esta comprobación.

    • Se puede acceder a las APIs de Google.

  • Comprobaciones de la máquina:

    • kubelet está activo y en ejecución en máquinas de nodos.

    • containerd está activo y en ejecución en máquinas de nodos.

    • El estado del endpoint de comprobación del estado de Container Network Interface (CNI) es correcto.

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

    • Los certificados de kubeadm no han caducado.

  • Comprobaciones de redes de nodos (varían en función de la configuración del balanceo de carga):

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

    • Se puede acceder a las IPs virtuales del balanceador de carga.

    • Los nodos pueden comunicarse en los puertos necesarios.

    • Se aprovisiona la instancia de eventos etcd y se cumplen los requisitos de puertos.

Cuando se superan todas las comprobaciones, Google Distributed Cloud actualiza el clúster. Para obtener más información sobre cómo actualizar clústeres, consulta las prácticas recomendadas para actualizar clústeres de Google Distributed Cloud y el ciclo de vida y las fases de las actualizaciones de clústeres.

Realizar comprobaciones preparatorias a petición para actualizar clústeres

El comando bmctl check preflight te permite ejecutar una comprobación previa antes de actualizar tu clúster. Para comprobar si los clústeres están listos para actualizarse, ejecuta el siguiente comando de comprobación previa antes de iniciar la actualización:

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

  2. Usa el siguiente comando para comprobar si los clústeres están listos para una actualización y ejecuta una comprobación previa:

    bmctl check preflight --cluster CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG

    Haz los cambios siguientes:

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

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

Comprobaciones preparatorias internas en clústeres

Google Distributed Cloud realiza comprobaciones preliminares internas automáticamente cuando aplicas recursos de Kubernetes a un clúster. Si falla alguna comprobación, Google Distributed Cloud no cambiará ninguno de los nodos relacionados a menos que omitas las comprobaciones explícitamente.

Omitir las comprobaciones preparatorias al aplicar recursos de Kubernetes

Para ignorar las comprobaciones previas internas al aplicar recursos a clústeres, debes definir el campo BypassPreflightCheck como true en el archivo de configuración del clúster.

A continuación, se muestra una parte de un archivo de configuración de clúster en la que el campo bypassPreflightCheck tiene el valor 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.33.100-gke.89
...

Realizar las comprobaciones preparatorias más recientes

Las comprobaciones previas (y las comprobaciones del estado) se actualizan a medida que se identifican problemas conocidos. Para indicar a bmctl que ejecute las comprobaciones desde la imagen del 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

Sustituye CLUSTER_NAME por el nombre del clúster que quieras comprobar.

De esta forma, podrás detectar cualquier problema conocido que se haya identificado recientemente sin tener que crear o actualizar tu clúster.

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

Ignorar los resultados de las comprobaciones preparatorias automatizadas

Si ejecutas comprobaciones previas a la puesta en marcha a petición antes de crear o actualizar clústeres, puedes omitir las comprobaciones previas a la puesta en marcha automatizadas. Para omitir las comprobaciones previas automáticas, usa la marca opcional --force al ejecutar bmctl create cluster o bmctl upgrade cluster.

Siguientes pasos