Verificaciones previas

Las verificaciones de solicitud preliminar te permiten identificar problemas antes de realizar operaciones importantes del clúster, como crear o actualizar clústeres. Cuando las verificaciones se ejecutan automáticamente antes de una operación, Google Distributed Cloud bloquea las modificaciones del clúster hasta que se aprueben todas las validaciones. También puedes ejecutar verificaciones según demanda o evitarlas durante los flujos de trabajo de administración de clústeres.

Google Distributed Cloud ejecuta estas validaciones cuando creas o actualizas clústeres y grupos de nodos con bmctl. También ejecuta verificaciones internas cuando un clúster de administrador o híbrido actualiza recursos en clústeres de usuario. Si alguna verificación falla, no se aplican cambios a tus clústeres.

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 los 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.

    En la respuesta, se enumeran 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 de 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 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: Son 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: Google Cloud Verificaciones de conectividad (acceso a Artifact Registry y a la API de Google) para máquinas con direcciones IP 192.0.2.53 y 192.0.2.54.
      • Gcp: Google Cloud verificaciones de conectividad para el clúster.
      • Node - Network: Son las verificaciones de red (conectividad, operación etcd, acceso a VIP y vinculación de puertos) para el clúster.
      • Pod - Cidr: Verifica si hay direcciones IP de Pods 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 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 al clúster Google Cloud , que se llama gcp.

    • Es el archivo de registro para las verificaciones de redes de nodos, que se llama 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 nodo:

    • 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.

    • Las máquinas de nodo están configuradas para usar cgroupsv2. La verificación falla si se detecta
      cgroupsv1.

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

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

    • Para Red Hat Enterprise Linux, el administrador de paquetes dnf está operativo y los paquetes requeridos están disponibles.

    • 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 hora se configura en las máquinas de nodo.

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

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

    • 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 ella.

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

    • Artifact Registry, gcr.io, se verifica la accesibilidad. 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 de nodos (varían 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 de etcd se aprovisiona y se cumplen los requisitos de puerto.

Cuando se aprueban todas las verificaciones, Google Distributed Cloud crea 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 la 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, llevan 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.

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 que está asociado con el archivo de configuración que estás verificando.

  • 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 estás verificando.

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 estás verificando.
    • ADMIN_KUBECONFIG: la ruta del archivo kubeconfig del clúster de administrador

  • Con el siguiente comando, se 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 nodo:

    • 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.

    • Las máquinas de los nodos están configuradas para usar cgroupsv2. La verificación falla si se detecta cgroupsv1.

    • En Ubuntu, el Uncomplicated Firewall (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 hora se configura en las máquinas de nodo.

    • 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 ella.

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

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

    • Artifact Registry, gcr.io, se verifica la accesibilidad. 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 máquinas:

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

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

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

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

    • Los certificados de kubeadm no vencieron.

  • Verificaciones de redes de nodos (varían 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 de etcd se aprovisiona y se cumplen los requisitos de puerto.

Cuando se aprueban todas las verificaciones, Google Distributed Cloud actualiza 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:

  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 del clúster que muestra el campo bypassPreflightCheck establecido en 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.36.200-gke.118
...

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 bmctl para que ejecute las verificaciones desde la imagen de parche más reciente de tu 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 estás verificando.

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?