Versión 1.6. Esta versión es compatible como se describe en la política de asistencia de la versión de Anthos, y ofrece los últimos parches y actualizaciones de vulnerabilidades de seguridad, exposiciones y problemas que afectan a los clústeres de Anthos en equipos físicos. Para obtener más detalles, consulta las notas de la versión 1.6. Esta no es la versión más reciente. Para obtener una lista completa de cada versión secundaria y de parche en orden cronológico, consulta las notas de la versión combinadas.

Versiones disponibles:  1.7  |  1.6

Información sobre las comprobaciones previas

En los clústeres de Anthos en equipos físicos, puedes ejecutar comprobaciones previas en diferentes situaciones:

  • Los clústeres de Anthos en equipos físicos ejecutan verificaciones de comprobación previa cuando creas o actualizas clústeres independientes, híbridos o de grupos de nodos con bmctl. Si las verificaciones fallan, no se realizan cambios. También puedes omitir estas verificaciones.
  • Puedes ejecutar un conjunto limitado de comprobación previa antes de crear clústeres de usuario desde un clúster híbrido o administrador con el comando de kubectl.
  • Los clústeres de Anthos en equipos físicos también ejecutan verificaciones previas de comprobación previa cuando aplicas recursos de Kubernetes a clústeres de usuarios desde un clúster híbrido o administrador. 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. También puedes omitir estas verificaciones o ejecutarlas de forma explícita.

Comprobaciones previas cuando verificas clústeres mediante bmctl

Cuando creas clústeres de administrador, híbridos o independientes con el comando bmctl, los clústeres de Anthos en equipos físicos ejecuta comprobaciones de comprobación previa de forma automática antes de que se realicen cambios.

Cuando se aprueben las verificaciones, los clústeres de Anthos en equipos físicos crearán los clústeres.

Cómo ignorar los resultados de las comprobaciones previas

Si deseas omitir estas verificaciones previas automatizadas, puedes usar la marca opcional --force en el comando.

Ejecuta comprobaciones previas de manera independiente

También puedes ejecutar verificaciones previas por sí solas antes de crear un clúster. Esto puede ayudar a ahorrar tiempo, ya que garantiza que los recursos de tu máquina y nodo aprueben las verificaciones.

  • 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

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

    bmctl check cluster --cluster CLUSTER_NAME

Ten en cuenta que no puedes crear clústeres de usuarios con bmctl (y hay una comprobación previa para evitar esto).

Comprobaciones previas para la creación de clústeres de usuarios

Los clústeres de usuario se crean a partir de un administrador o clúster híbrido existente, y usas kubectl para ejecutar las comprobaciones previas. Según los resultados de estas comprobaciones, puedes determinar si hay errores y corregirlos antes de la creación del clúster de usuarios.

Una vez que se crea y ejecuta un clúster híbrido o administrador, puedes usar kubectl para ejecutar verificaciones de comprobaciones previas antes de crear un clúster de usuarios.

  1. Crea un archivo de configuración de clúster de usuario con los pasos de Crea clústeres de usuario en una configuración de varios clústeres

  2. Crea un espacio de nombres para el clúster de usuario nuevo. Por ejemplo, para crear un clúster de usuarios nuevo llamado user1, puedes crear un espacio de nombres llamado cluster-user1. Este es el comando kubectl para crear el espacio de nombres, en el que ADMIN_KUBECONFIG especifica la ruta al archivo kubeconfig del clúster de administrador:

    kubectl --kubeconfig ADMIN_KUBECONFIG create namespace cluster-user1
    

  3. Sube el archivo de claves privadas SSH al espacio de nombres nuevo como un secreto para establecer tus credenciales. Aquí se muestra el comando de muestra, en el que ADMIN_KUBECONFIG especifica la ruta al archivo kubeconfig del clúster de administrador y SSH_PRIVATE_KEY_FILE_PATH especifica la ruta al archivo de claves privadas SSH:

    kubectl --kubeconfig ADMIN_KUBECONFIG create secret generic ssh-key -n cluster-user1 --from-file=id_rsa=SSH_PRIVATE_KEY_FILE_PATH
    

  4. Crea un nuevo archivo YAML de verificación previa con la siguiente estructura. En el campo configYAML, ingresa el contenido de texto del archivo de configuración de clúster del usuario que creaste en el paso 1:

    apiVersion: baremetal.cluster.gke.io/v1
    kind: PreflightCheck
    metadata:
    generateName: preflightcheck-
    namespace: cluster-user1
    spec:
    configYAML: |
    # insert user cluster config file content here.
    
  5. El siguiente comando kubectl ejecuta la verificación de comprobación previa para el clúster del usuario, en la que ADMIN_KUBECONFIG especifica la ruta al archivo kubeconfig del clúster de administración y USER_CLUSTER_PREFLIGHT_CHECK_CONFIG especifica la ruta al archivo YAML que creaste en el paso anterior:

    kubectl --kubeconfig ADMIN_KUBECONFIG create -f USER_CLUSTER_PREFLIGHT_CHECK_CONFIG
    
    Por ejemplo, para un clúster de administrador llamado cluster1 y un archivo de configuración de verificación previa del clúster de usuario llamado user1-preflight.yaml, el comando es el siguiente:
    kubectl --kubeconfig bmctl-workspace/cluster1/cluster1-kubeconfig create -f user1-preflight.yaml
    
    El sistema muestra el siguiente mensaje, con el ID de trabajo de la verificación previa:
    preflightcheck.baremetal.cluster.gke.io/preflightcheck-g7hfo4 created

  6. Consulta el estado del trabajo de verificación previa con el comando kubectl:

    kubectl --kubeconfig bmctl-workspace/cluster1/cluster1-kubeconfig -n cluster-user1 get preflightchecks preflightcheck-g7hfo4
    

Si el trabajo de verificación de comprobación previa falla, verifica su estado y, luego, verifica los registros detallados del trabajo para ver qué verificación falló. Corrige los problemas mencionados en los trabajos según corresponda y vuelve a ejecutar las verificaciones.

Comprobación previas interna en clústeres existentes

Los clústeres de Anthos en equipos físicos también realizan verificaciones previas cuando aplicas recursos de Kubernetes a un clúster híbrido o de administrador existente. Si alguna de las verificaciones falla, los clústeres de Anthos en equipos físicos no realizarán ningún cambio en los nodos relacionados, a menos que hayas omitido las verificaciones específicamente.

Omite las verificaciones previas cuando apliques recursos de Kubernetes

Para ignorar las verificaciones previas internas cuando aplicas recursos a los clústeres existentes, debes establecer el campo BypassPreflightCheck en true en el archivo YAML del clúster.

Este es un fragmento de un archivo YAML de configuración del clúster en el que se muestra el campo bypassPreflightCheck configurado como true.

# Sample cluster config to bypass preflight check errors:

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: v1.6.2
....

Vuelve a habilitar las verificaciones previas

Puedes activar de manera explícita una nueva ronda de verificaciones previas para que los clústeres de Anthos en equipos físicos puedan actualizar o crear clústeres nuevos después de que la verificación previa se realice correctamente.

  1. Crea un nuevo archivo YAML de comprobación previa con el siguiente contenido. Completa los campos namespace y clusterName con el nombre del clúster que crearás:

    apiVersion: baremetal.cluster.gke.io/v1
    kind: PreflightCheck
    metadata:
    generateName: preflightcheck-
    namespace: CLUSTER_NAMESPACE
    spec:
    clusterName: CLUSTER_NAME
    

  2. Emite el comando kubectl para ejecutar la verificación de comprobación previa del clúster, en la que ADMIN_KUBECONFIG especifica la ruta al archivo kubeconfig del clúster de administrador, y CLUSTER_PREFLIGHT_CHECK_CONFIG especifica la ruta la verificación previa del archivo YAML que creaste antes en el paso 1 de verificaciones previas a la verificación para los clústeres de usuarios:

    kubectl --kubeconfig ADMIN_KUBECONFIG create -f CLUSTER_PREFLIGHT_CHECK_CONFIG
    
    Por ejemplo, para un clúster de administrador llamado cluster1 y un archivo de configuración de verificación previa del clúster de usuario llamado user1-preflight.yaml, el comando es el siguiente:
    kubectl --kubeconfig bmctl-workspace/cluster1/cluster1-kubeconfig create -f user1-preflight.yaml
    
    Los sistemas responden con el ID de trabajo de la verificación previa:
    preflightcheck.baremetal.cluster.gke.io/preflightcheck-g7hfo4 created
    

  3. Consulta el ID de estado del trabajo de verificación previa con el comando kubectl:

    kubectl --kubeconfig bmctl-workspace/cluster1/cluster1-kubeconfig -n cluster-cluster1 get preflightchecks preflightcheck-g7hfo4
    

Una vez que el trabajo de verificación previa finalizó correctamente, los clústeres de Anthos en equipos físicos crean el clúster y sus recursos.

Detalles de la comprobación previa de la instalación

Los clústeres de Anthos en equipos físicos ejecutan una variedad de condiciones previas de sistema operativo, software y máquina cuando se ejecutan verificaciones previas.

Para obtener información más detallada, consulta Descripción general de los requisitos previos de instalación.