Verificaciones previas

Las comprobaciones preliminares son una medida preventiva para ayudar a identificar problemas antes de iniciar una operación de clúster importante, 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 se aprueben. También puedes ejecutar comprobaciones preliminares a pedido.

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 preliminares para diferentes situaciones:

  • Google Distributed Cloud ejecuta comprobaciones preliminares 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 omitir estas verificaciones o ejecutarlas de manera explícita.

  • Google Distributed Cloud también ejecuta comprobaciones internas previas cuando un administrador o clúster híbrido 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.

PreflightCheck recursos personalizados

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

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.

    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 las comprobaciones preliminares se aprobaron o no. En la siguiente respuesta de ejemplo, 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 PreflightCheck personalizado 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 comprobació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 ejecutaron las siguientes verificaciones:
      • 192.0.2.53 y 192.0.2.54: Verificaciones de nodos (configuración del SO, recursos y 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: Comprobaciones de conectividad de Google Cloud (acceso a Container Registry y la API de Google) para máquinas con direcciones IP 192.0.2.53 y 192.0.2.54.
      • Gcp: Son las 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) para el 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 aprobaron de forma colectiva.

Registros de comprobaciones preliminares

Cuando las comprobaciones preliminares se ejecutan 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 preliminares se generan en un directorio con el siguiente patrón de nombres preflight-TIMESTAMP.

  • Este directorio de comprobación previa se crea en el directorio log del 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 comprobación previa 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 según 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. A estos archivos de registro se les asigna un nombre según la dirección IP del nodo. Por ejemplo, un nombre de archivo podría ser 192.0.2.53-gcp.

    • Archivo de registro para las verificaciones de acceso de Google Cloud al clúster, que se llama gcp.

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

Si falla una comprobació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, Google Distributed Cloud ejecuta de forma automática las comprobaciones preliminares antes de que se realicen cambios.

¿Qué elementos están marcados?

Verificaciones previas para la instalación verifica lo siguiente:

  • Verificaciones de la máquina de 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 no complicado (UFW) está inhabilitado.

    • En Ubuntu, se puede operar el administrador de paquetes apt, y hay paquetes necesarios disponibles.

    • En Red Hat Enterprise Linux, se puede operar el administrador de paquetes dnf, y los paquetes necesarios 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 tiempo se configura en las máquinas de nodo.

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

    • containerd está activo y se está ejecutando en 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 CIDR del Pod no se superponen con las direcciones IP de la máquina del nodo.

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

  • 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 del registro, se omite esta verificación.

    • Las APIs de Google son accesibles.

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

    • La VIP para el servidor de la API de Kubernetes es accesible.

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

    • Los nodos se pueden comunicar en los puertos requeridos.

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

Cuando se aprueban todas las verificaciones, Google Distributed Cloud crea el clúster. Si deseas 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 la creación del clúster

También puedes ejecutar comprobaciones preliminares de forma independiente, antes de crear un clúster. Esto puede ser beneficioso porque las operaciones de clústeres importantes, como la creación de clústeres, requieren mucho tiempo. Identificar y resolver los problemas por separado antes de comenzar 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 al archivo de configuración que verificas.

  • Este comando verifica 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

  • 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 del clúster:

    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, Google Distributed Cloud ejecuta automáticamente las comprobaciones preliminares antes de que se realicen cambios.

¿Qué elementos están marcados?

Las comprobaciones preliminares de las actualizaciones del clúster verifican lo siguiente:

  • Verificaciones de la máquina de 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 no complicado (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 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 esta.

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

  • 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 del registro, se omite esta verificación.

    • Las APIs de Google son accesibles.

  • Verificaciones de la máquina:

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

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

    • El estado del extremo de estado de la interfaz de red del contenedor (CNI) está en buen estado.

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

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

    • La VIP para el servidor de la API de Kubernetes es accesible.

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

    • Los nodos se pueden comunicar en los puertos requeridos.

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

Cuando se aprueban todas las verificaciones, Google Distributed Cloud actualiza el clúster. Si quieres 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 los clústeres.

Ejecuta comprobaciones preliminares a pedido para las actualizaciones del clúster

El comando bmctl check preflight te permite ejecutar una comprobación preliminar antes de actualizar el clúster. Puedes comprobar si los clústeres están listos para una actualización mediante la ejecución del siguiente comando de verificació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 a fin de comprobar si los clústeres están listos para una actualización y ejecuta 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 comprobación preliminar con este comando para probar la actualización de un clúster, se crea un recurso personalizado PreflightCheck en el clúster de administrador.

Comprobación previas interna en clústeres existentes

Google Distributed Cloud realiza comprobaciones internas de manera automática cuando aplicas recursos de Kubernetes a un clúster existente. Si falla alguna de las verificaciones, Google Distributed Cloud no cambia ninguno de los nodos relacionados, a menos que omitas 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 los clústeres existentes, debes configurar el campo BypassPreflightCheck como true en el archivo de configuración del clúster.

A continuación, se incluye una parte de un archivo de configuración de clúster en el que se 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.29.100-gke.251
...

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

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

  • Si deseas usar la lista de verificaciones más reciente para determinar si tus máquinas y redes están listas para la creación del clúster, haz lo siguiente:

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

    Reemplaza CLUSTER_NAME por el nombre del clúster que verificas.

También puedes realizar las verificaciones de estado más recientes 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 verificas.

Ignora los resultados de las comprobaciones previas

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

¿Qué sigue?