Verificaciones previas

Las comprobaciones preliminares son una medida preventiva para ayudar a identificar problemas antes de iniciar una operación principal de clúster, como crear o actualizar clústeres. Cuando estas verificaciones se ejecutan de forma automática antes de una operación, no se realizan cambios en los clústeres, a menos que todas las comprobaciones preliminares sean exitosas. También puedes ejecutar verificaciones previas a pedido.

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

En GDCV para Bare Metal, puedes ejecutar comprobaciones preliminares para diferentes situaciones:

  • GDCV para Bare Metal ejecuta las comprobaciones preliminares cuando creas o actualizas clústeres y recursos de grupos de nodos con bmctl. Si fallan las verificaciones, no se realizan cambios. También puedes omitir estas verificaciones o ejecutarlas de manera explícita.

  • GDCV para Bare Metal también ejecuta comprobaciones preliminares internas cuando un clúster híbrido o de administrador crea o actualiza recursos de Kubernetes en los 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.

PreflightCheck recursos personalizados

Cuando se ejecuta una verificación previa, GDCV para Bare Metal crea un recurso personalizado PreflightCheck. Los recursos personalizados PreflightCheck son persistentes y proporcionan un registro de las actividades y resultados de las comprobaciones preliminares.

Para recuperar PreflightCheck recursos personalizados, haz lo siguiente:

  1. Obtén una lista de las comprobaciones preliminares 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 enumera 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 las comprobaciones preliminares se aprobaron. En la siguiente respuesta de muestra, se muestran los recursos PreflightCheck para el 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 del comando de muestra, se muestra un recurso PreflightCheck para una verificación preliminar exitosa 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 preliminares individuales que se ejecutaron y si se aprobaron o no. En este ejemplo, se ejecutan las siguientes verificaciones:
      • 192.0.2.53 y 192.0.2.54: comprobaciones de nodos (configuración del SO, recursos y configuración de software) de las 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 (Container Registry y acceso a la API de Google) para máquinas con direcciones IP 192.0.2.53 y 192.0.2.54
      • Gcp: Verificaciones de conectividad de Google Cloud para el clúster.
      • Node - Network: verificaciones de red (conectividad, operación etcd, acceso VIP y vinculación de puertos) del clúster
      • Pod - Cidr: La dirección IP del Pod verifica si hay direcciones superpuestas 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 preliminares se pasaron de forma colectiva.

Registros de comprobaciones preliminares

Cuando se ejecutan las comprobaciones preliminares como resultado de un comando bmctl, como bmctl check preflight, GDCV para Bare Metal crea archivos de registro. Esto es lo que se genera y dónde:

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

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

  • Los registros de las comprobaciones preliminares constan de los siguientes archivos:

    • Archivos de registro para las verificaciones de la máquina del nodo, 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 puede ser 192.0.2.53-gcp.

    • El archivo de registro de las verificaciones de acceso de Google Cloud del clúster, que se llama gcp.

    • Archivo de registro para las verificaciones de redes de nodos, que se llama node-network.

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

Verificaciones previas para la creación de clústeres

Cuando creas clústeres, GDCV para Bare Metal ejecuta de forma automática las comprobaciones preliminares antes de que se realice cualquier cambio.

¿Qué se revisa?

Las comprobaciones preliminares para la instalación comprueban lo siguiente:

  • Verificaciones de la máquina del nodo:

    • Las máquinas de clústeres 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 uncomplicated (UFW) está inhabilitado.

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

    • En Red Hat Enterprise Linux, el administrador de paquetes dnf está disponible.

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

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

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

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

    • La sincronización de tiempo se configura en las máquinas de los 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 CIDR del Pod no se superponen con las direcciones IP de las máquinas de nodo.

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

  • En Google Cloud, verifica cada nodo y el clúster:

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

    • Se puede acceder a las APIs de Google.

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

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

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

    • Los nodos pueden comunicarse en los puertos requeridos.

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

Cuando se aprueban todas las verificaciones, GDCV para Bare Metal crea el clúster. Si quieres obtener más información sobre los requisitos para crear clústeres, consulta Descripción general de los requisitos previos de la instalación.

Ejecuta comprobaciones preliminares a pedido para crear clústeres

También puedes ejecutar comprobaciones preliminares de forma independiente, antes de crear un clúster. Hacerlo puede ser beneficioso, ya que las operaciones de clúster principales, como la creación de clústeres, consumen mucho tiempo. Identificar y resolver los problemas por separado antes de iniciar una operación de clúster importante puede ayudarte con la programación.

Clústeres autoadministrados

  • 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

    Reemplaza CLUSTER_NAME por el nombre del clúster asociado con el archivo de configuración que estás verificando.

  • Este comando verifica si las máquinas y la red están listas para la creación de clústeres:

    bmctl check preflight --cluster CLUSTER_NAME

    Reemplaza CLUSTER_NAME por el nombre del clúster que estás verificando.

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

    Reemplaza lo siguiente:

    • CLUSTER_NAME: Es el nombre del clúster de usuario que estás verificando.
    • ADMIN_KUBECONFIG: Es la ruta de acceso del archivo kubeconfig del clúster de administrador asociado.

  • El siguiente comando verifica si las máquinas y la red están listas para la creación de clústeres:

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

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

Verificaciones previas para actualizaciones de clústeres

Cuando actualizas los clústeres, GDCV para Bare Metal ejecuta de forma automática las comprobaciones preliminares antes de realizar cualquier cambio.

¿Qué se revisa?

Las comprobaciones preliminares para las actualizaciones del clúster comprueban lo siguiente:

  • Verificaciones de la máquina del nodo:

    • Las máquinas de clústeres 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 uncomplicated (UFW) está inhabilitado.

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

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

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

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

    • La sincronización de tiempo se configura en las máquinas de los 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 podrá acceder a ella.

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

  • En Google Cloud, verifica cada nodo y el clúster:

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

    • Se puede acceder a las APIs de Google.

  • Verificaciones de la máquina:

    • 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 la interfaz de red de contenedor (CNI) está en buen estado.

    • Los CIDR del Pod no se superponen con las direcciones IP de las máquinas de nodo.

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

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

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

    • Los nodos pueden comunicarse en los puertos requeridos.

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

Cuando se aprueban todas las verificaciones, GDCV para Bare Metal actualiza el clúster. Si quieres obtener más información sobre la actualización de clústeres, consulta Prácticas recomendadas de GDCV para actualizaciones de clústeres de Bare Metal y Ciclo de vida y etapas de las actualizaciones de clústeres.

Ejecuta comprobaciones preliminares a pedido para actualizaciones de clústeres

El comando bmctl check preflight te permite ejecutar una verificación previa antes de actualizar el clúster. A fin de comprobar si los clústeres están listos para una actualización, ejecuta el siguiente comando de comprobación previa antes de comenzar 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 a fin de verificar si los clústeres están listos para una actualización y ejecutar una verificación previa:

    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 verificació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.

Comprobación previas interna en clústeres existentes

GDCV para Bare Metal realiza comprobaciones preliminares internas de forma automática cuando aplicas recursos de Kubernetes a un clúster existente. Si falla alguna de las verificaciones, el GDCV para Bare Metal no cambia ninguno de los nodos relacionados, a menos que omites las verificaciones de forma explícita.

Omite las verificaciones previas cuando apliques recursos de Kubernetes

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

Este es 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.28.400-gke.77
...

Ejecuta las comprobaciones preliminares y las verificaciones de estado más recientes

Cuando usas bmctl para ejecutar comprobaciones preliminares o de estado, puedes agregar la marca --check-image-version latest al comando a fin de realizar las verificaciones desde la versión más reciente del parche GDCV para Bare Metal. Esto puede ayudarte a identificar problemas conocidos sin crear o actualizar primero tu clúster.

  • A fin de usar la lista más reciente de verificaciones a fin de determinar si tus máquinas y redes están listas para la creación de clústeres, haz lo siguiente:

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

    Reemplaza CLUSTER_NAME por el nombre del clúster que estás verificando.

También puedes realizar las últimas verificaciones de estado de un clúster activo para determinar si está en buen estado.

  • Para realizar las verificaciones de estado más actualizadas en un clúster activo, haz lo siguiente:

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

    Reemplaza CLUSTER_NAME por el nombre del clúster que estás verificando.

Ignora los resultados de las comprobaciones previas

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

¿Qué sigue?