Comprender las comprobaciones previas

Esta página está destinada a los operadores de infraestructura o administradores de la plataforma.

En el modo privado de Anthos, puedes ejecutar comprobaciones previas para diferentes situaciones:

El modo privado de Anthos ejecuta comprobaciones previas cuando creas o actualizas clústeres de administrador o de usuario y recursos de grupos de nodos con actl. Si las verificaciones fallan, no se realizan cambios. También puedes omitir estas verificaciones.
El modo privado de Anthos ejecuta verificaciones previas internas cuando aplicas recursos de Kubernetes a los clústeres de usuarios desde un clúster de 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 `actl`

Cuando creas clústeres de administrador o de usuario con el comando actl, el modo privado de Anthos ejecuta automáticamente verificaciones previas antes de que se realicen cambios.

Cuando se aprueben las verificaciones, el modo privado de Anthos creará los clústeres.

Ignora 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 forma 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 este comando, se comprueba si las máquinas y la red están listas para la creación del clúster:

actl clusters baremetal check preflight CLUSTER_NAME

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

Los clústeres de usuario se crean a partir de un clúster de administrador existente. El modo privado de Anthos ejecuta automáticamente verificaciones previas antes de realizar cambios. También puedes ejecutar verificaciones previas con kubectl antes de crear un clúster.

Crea un archivo de configuración de clúster de usuario con el archivo de configuración de usuario de muestra.
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
```
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
```
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.
```
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 una configuración de verificación previa del clúster de usuario llamada user1-preflight.yaml, el comando es el siguiente:
```
kubectl --kubeconfig ADMIN_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
```

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

kubectl --kubeconfig ADMIN_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

El modo privado de Anthos también realiza verificaciones previas internas cuando aplicas recursos de Kubernetes de Cluster a un clúster de administrador existente. Si alguna verificación falla, el modo privado de Anthos no realizará ningún cambio en los nodos relacionados, a menos que omitas las verificaciones de forma específica.

Omite las verificaciones previas cuando apliques recursos de Kubernetes

Para ignorar las verificaciones previas cuando se aplican recursos de Cluster a un clúster de administrador existente, debes establecer el campo BypassPreflightCheck en true en el recurso 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: 1.9.3
....

Vuelve a habilitar las comprobaciones previas

Puedes activar de manera explícita una nueva ronda de verificaciones previas para que el modo privado de Anthos pueda actualizar o crear clústeres nuevos después de que la verificación anterior se realice correctamente.

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

Emite el comando kubectl para ejecutar la verificació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 al archivo YAML de la verificación previa que creaste antes:
```
kubectl --kubeconfig ADMIN_KUBECONFIG create -f CLUSTER_PREFLIGHT_CHECK_CONFIG
```
Por ejemplo, para una configuración de verificación previa del clúster de usuario llamada user1-preflight.yaml, el comando es el siguiente:
```
kubectl --kubeconfig ADMIN_KUBECONFIG create -f user1-preflight.yaml
```
Los sistemas responden con el ID de tarea de la verificación previa:
```
preflightcheck.baremetal.cluster.gke.io/preflightcheck-g7hfo4 created
```

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

kubectl --kubeconfig ADMIN_KUBECONFIG -n cluster-cluster1 get preflightchecks preflightcheck-g7hfo4

Una vez que el trabajo de verificación previa finalizó de forma correcta, el modo privado de Anthos crea el clúster y sus recursos.

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

El modo privado de Anthos verifica una variedad de condiciones de sistema operativo, software y máquina cuando se ejecutan verificaciones previas.

Para obtener información más detallada, consulta los Requisitos.

Verificaciones previas de autenticación

Para fines de autenticación, las verificaciones previas comprueban la configuración de OpenID Connect (OIDC) a fin de evitar aplicar un perfil de OIDC incorrecto.

Estas verificaciones incluyen hacer ping en el extremo de OIDC mediante el mecanismo de descubrimiento de OIDC en /.well-known/openid-configuration.

¿Qué sigue?

Crear clústeres de usuario