Comprobaciones del estado

Las comprobaciones de estado son una forma de probar y monitorizar el funcionamiento de tus clústeres. Las comprobaciones del estado se ejecutan por sí solas de forma periódica. También puedes usar bmctl para realizar comprobaciones de estado bajo demanda. En este documento se describe cada comprobación, en qué circunstancias se ejecuta automáticamente, cómo y cuándo ejecutarla manualmente, y cómo interpretar los resultados.

¿Qué se comprueba?

Hay dos categorías de comprobaciones de estado de Google Distributed Cloud:

  • Comprobaciones de máquinas de nodos

  • Comprobaciones en todo el clúster

En las siguientes secciones se indica qué se comprueba en cada categoría. Estas comprobaciones se usan tanto para las comprobaciones del estado periódicas como para las que se realizan bajo demanda.

Comprobaciones de máquinas de nodos

En esta sección se describe lo que evalúan las comprobaciones del estado de las máquinas de nodo. Estas comprobaciones confirman que las máquinas de los nodos están configuradas correctamente y que tienen suficientes recursos y conectividad para crear clústeres, actualizar clústeres y operar clústeres.

Estas comprobaciones corresponden a los recursos personalizados de Bare Metal HealthCheck llamados bm-system-NODE_IP_ADDRESS-machine (por ejemplo, bm-system-192.0.2.54-machine) que se ejecutan en el clúster de administración en el espacio de nombres del clúster. Para obtener más información sobre los recursos de comprobación del estado, consulta los HealthCheckrecursos personalizados.

Nota: Las comprobaciones de máquina comunes y las comprobaciones de máquina Google Cloud también se usan en las comprobaciones previas.

Las comprobaciones habituales de las máquinas consisten en lo siguiente:

  • Las máquinas del clúster usan un sistema operativo compatible.

  • La versión del SO es compatible.

  • El SO usa una versión del kernel compatible.

  • El kernel tiene habilitada la opción del compilador Just-in-Time (JIT) de BPF (CONFIG_BPF_JIT=y).

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

  • Los nodos cumplen los requisitos mínimos de CPU.

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

  • Los equipos de nodos cumplen los requisitos mínimos de memoria.

  • Los nodos cumplen los requisitos mínimos de almacenamiento en disco.

  • La sincronización de la hora está configurada en las máquinas de los nodos.

  • La ruta predeterminada para enrutar paquetes a la pasarela predeterminada está presente en los nodos.

  • El sistema de nombres de dominio (DNS) funciona correctamente (esta comprobación se omite si el clúster está configurado para ejecutarse detrás de un proxy).

  • Si el clúster está configurado para usar una réplica de registro, se puede acceder a ella.

Las comprobaciones de la máquina Google Cloud consisten en lo siguiente:

  • Se puede acceder a Artifact Registry, gcr.io (esta comprobación se omite si el clúster está configurado para usar un mirror del registro).

  • Se puede acceder a las APIs de Google.

Las comprobaciones del estado de las máquinas constan de lo siguiente:

  • kubelet está activo y en ejecución en máquinas de nodos.

  • containerd está activo y en ejecución en máquinas de nodos.

  • El estado del endpoint de comprobación del estado de Container Network Interface (CNI) es correcto.

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

Para obtener más información sobre los requisitos de los nodos, consulta los requisitos previos de los nodos del clúster.

Comprobaciones en todo el clúster

En esta sección se describe qué evalúan las comprobaciones de estado de un clúster.

Comprobaciones predeterminadas

Las comprobaciones predeterminadas del clúster, que se ejecutan automáticamente como parte de las comprobaciones periódicas del estado, también se pueden ejecutar bajo demanda como parte de las comprobaciones del estado del clúster. Estas comprobaciones aseguran que los recursos del clúster de Kubernetes estén configurados correctamente y funcionen bien.

Estas comprobaciones corresponden a los recursos personalizados de Bare Metal HealthCheckbm-system-default-*llamados resources que se ejecutan en el clúster de administración en el espacio de nombres del clúster. Para obtener más información sobre los recursos de comprobación del estado, consulta los HealthCheckrecursos personalizados.

Las comprobaciones de clúster predeterminadas auditan los siguientes tipos de recursos y condiciones:

  • DaemonSet

    • Las configuraciones son válidas
    • Los DaemonSets están en buen estado

  • Implementación

    • Las configuraciones son válidas
    • Las implementaciones están en buen estado

  • Nodo (todas las condiciones siguientes son condiciones de nodo)

    • Estado de preparación del nodo
    • Presión de disco de kubelet
    • Presión de memoria de kubelet
    • Presión del ID de proceso (PID) de kubelet
    • Frecuencia de reinicio de kubelet
    • kubelet está en buen estado
    • Disponibilidad de la red
    • Función containerd
    • Frecuencia de reinicio de containerd
    • Función Overlay2 de Docker
    • Frecuencia de reinicio de Docker
    • Frecuencia de eventos de anulación del registro de dispositivos de red
    • Bloqueos del kernel
    • KubeProxy está en buen estado
    • Sistema de archivos de solo lectura

  • Pod

    • Las configuraciones son válidas
    • Los pods están en buen estado
    • Los contenedores están en buen estado

  • PodDisruptionBudget (PDB)

    • Las configuraciones son válidas
    • Función de tiempo de ejecución de PDB
    • Los PDBs coinciden con los pods
    • Pods no gestionados por varios PDBs

  • Solicitudes de recursos

    • Los pods de los nodos de destino tienen definidas solicitudes de CPU y memoria
    • La media de solicitudes de recursos por nodo está dentro del límite registrado.

  • Servicio

    • Las configuraciones son válidas
    • Los servicios están en buen estado

  • StatefulSet

    • Las configuraciones son válidas
    • StatefulSet

Comprobaciones de red

Las siguientes comprobaciones de la red de nodos del clúster del lado del cliente se ejecutan automáticamente como parte de las comprobaciones de estado periódicas. Las comprobaciones de red no se pueden ejecutar bajo demanda. Estas comprobaciones se corresponden con los recursos personalizados de Bare Metal HealthCheck llamados bm-system-network, que se ejecutan en el clúster de administración en el espacio de nombres del clúster. Para obtener más información sobre los recursos de comprobación del estado, consulta HealthCheckrecursos personalizados.

  • Si el clúster usa el balanceo de carga agrupado, los nodos del grupo de nodos de balanceo de carga deben tener conectividad del protocolo de resolución de direcciones (ARP) de la capa 2. Se requiere ARP para la detección de VIP.

  • Los nodos del plano de control tienen los puertos 8443 y 8444 abiertos para que los use GKE Identity Service.

  • Los nodos del plano de control tienen los puertos 2382 y 2383 abiertos para que los use la instancia etcd-events.

Para obtener información sobre los protocolos y el uso de puertos de tus clústeres, consulta los requisitos de red. Las comprobaciones de red de una comprobación previa son diferentes de las comprobaciones del estado de la red. Para ver una lista de las comprobaciones de red de una comprobación de solicitudes preparatorias, consulta Comprobaciones de solicitudes preparatorias para la creación de clústeres o Comprobaciones de solicitudes preparatorias para las actualizaciones de clústeres.

Kubernetes

Las comprobaciones de Kubernetes, que se ejecutan automáticamente como parte de las comprobaciones de estado previas y periódicas, también se pueden ejecutar bajo demanda. Estas comprobaciones de estado no devuelven un error si falta alguno de los componentes del plano de control que se indican. La comprobación solo devuelve errores si los componentes existen y tienen errores en el momento de la ejecución del comando.

Estas comprobaciones corresponden a los recursos personalizados de Bare Metal HealthCheckbm-system-kubernetesllamados resources que se ejecutan en el clúster de administración en el espacio de nombres del clúster. Para obtener más información sobre los recursos de comprobación del estado, consulta los HealthCheckrecursos personalizados.

  • El servidor de la API funciona correctamente.

  • El operador anetd está configurado correctamente.

  • Todos los nodos del plano de control funcionan correctamente.

  • Los siguientes componentes del plano de control funcionan correctamente:

    • anthos-cluster-operator

    • controller-manager

    • cluster-api-provider

    • ais

    • capi-kubeadm-bootstrap-system

    • cert-manager

    • kube-dns

Complementos

Las comprobaciones de complementos se ejecutan automáticamente como parte de las comprobaciones previas y de las comprobaciones periódicas del estado, y se pueden ejecutar a petición. Esta comprobación del estado no devuelve ningún error si falta alguno de los complementos de la lista. La comprobación solo devuelve errores si los complementos existen y tienen errores en el momento de la ejecución del comando.

Estas comprobaciones corresponden a los recursos personalizados de Bare Metal HealthCheckbm-system-add-ons*que se ejecutan en el clúster de administración en el espacio de nombres del clúster. Para obtener más información sobre los recursos de comprobación del estado, consulta los HealthCheckrecursos personalizados.

  • Los componentes de Stackdriver de Cloud Logging y el agente de conexión funcionan correctamente:

    • stackdriver-log-aggregator

    • stackdriver-log-forwarder

    • stackdriver-metadata-agent

    • stackdriver-prometheus-k8

    • gke-connect-agent

  • Los recursos gestionados por Google Distributed Cloud no muestran cambios manuales (desviación de la configuración):

    • Los valores de los campos no se han actualizado

    • No se han añadido ni quitado campos opcionales

    • No se han eliminado los recursos

Si la comprobación de estado detecta una desviación de la configuración, el valor Status.Pass del recurso personalizado bm-system-add-ons Bare Metal HealthCheck se define como false. El campo Description de la sección Failures contiene detalles sobre los recursos que han cambiado, incluida la siguiente información:

  • Version: la versión de la API del recurso.
  • Kind: el esquema del objeto, como Deployment, del recurso.
  • Namespace: el espacio de nombres en el que se encuentra el recurso.
  • Name: el nombre del recurso.
  • Diff: comparación en formato de cadena de las diferencias entre el manifiesto del recurso registrado y el manifiesto del recurso modificado.

HealthCheck recursos personalizados

Cuando se ejecuta una comprobación del estado, Google Distributed Cloud crea un recurso personalizado HealthCheck. Los recursos personalizados HealthCheck son persistentes y proporcionan un registro estructurado de las actividades y los resultados de las comprobaciones del estado. Hay dos categorías de HeathCheckrecursos personalizados:

  • Recursos personalizados de Bare Metal HealthCheck (API Version: baremetal.cluster.gke.io/v1): estos recursos proporcionan detalles sobre las comprobaciones de estado periódicas. Estos recursos se encuentran en el clúster de administrador en los espacios de nombres del clúster. Los recursos de Bare Metal HealthCheck se encargan de crear tareas cron y tareas de comprobación de estado. Estos recursos se actualizan constantemente con los resultados más recientes.

  • Recursos personalizados de Anthos HealthCheck (API Version: anthos.gke.io/v1): estos recursos se usan para registrar métricas de comprobación de estado. Estos recursos se encuentran en el espacio de nombres kube-system de cada clúster. Las actualizaciones de estos recursos se realizan de la mejor forma posible. Si una actualización falla debido a un problema, como un error de red transitorio, se ignora el fallo.

En la siguiente tabla se enumeran los tipos de recursos que se crean para cada categoría:HealthCheck

Comprobaciones de estado de Bare Metal Comprobaciones de estado de Anthos Gravedad

Tipo: predeterminado

Nombre: bm-system-default-daemonset

Nombre: bm-system-default-deployment

Nombre: bm-system-default-node

Nombre: bm-system-default-pod

Nombre: bm-system-default-poddisruptionbudget

Nombre: bm-system-default-resource

Nombre: bm-system-default-service

Nombre: bm-system-default-statefulset

Tipo: predeterminado

Nombre: bm-system-default-daemonset

Nombre: bm-system-default-deployment

Nombre: bm-system-default-node

Nombre: bm-system-default-pod

Nombre: bm-system-default-poddisruptionbudget

Nombre: bm-system-default-resource

Nombre: bm-system-default-service

Nombre: bm-system-default-statefulset

 Crítica

Tipo: machine

Nombre: bm-system-NODE_IP_ADDRESS-machine

Tipo: machine

Nombre: bm-system-NODE_IP_ADDRESS-machine

Crítica

Tipo: network

Nombre: bm-system-network

Tipo: network

Nombre: bm-system-network

Crítica

Tipo: kubernetes

Nombre: bm-system-kubernetes

Tipo: kubernetes

Nombre: bm-system-kubernetes

Crítica

Tipo: complementos

Nombre: bm-system-add-ons

Tipo: complementos

Nombre: bm-system-add-ons-add-ons

Nombre: bm-system-add-ons-configdrift

Opcional

Para consultar el estado de HealthCheck, sigue estos pasos:

  1. Para leer los resultados de las comprobaciones de estado periódicas, puedes obtener los recursos personalizados asociados:

    kubectl get healthchecks.baremetal.cluster.gke.io \
    --kubeconfig ADMIN_KUBECONFIG \
    --all-namespaces

    Sustituye ADMIN_KUBECONFIG por la ruta del archivo kubeconfig del clúster de administrador.

    En el siguiente ejemplo se muestran las comprobaciones de estado que se ejecutan periódicamente y si se han superado en la última ejecución:

    NAMESPACE               NAME                               PASS    AGE
cluster-test-admin001   bm-system-192.0.2.52-machine       true    11d
cluster-test-admin001   bm-system-add-ons                  true    11d
cluster-test-admin001   bm-system-kubernetes               true    11d
cluster-test-admin001   bm-system-network                  true    11d
cluster-test-user001    bm-system-192.0.2.53-machine       true    56d
cluster-test-user001    bm-system-192.0.2.54-machine       true    56d
cluster-test-user001    bm-system-add-ons                  true    56d
cluster-test-user001    bm-system-kubernetes               true    56d
cluster-test-user001    bm-system-network                  true    56d

  2. Para leer los detalles de una comprobación de estado específica, usa kubectl describe:

    kubectl describe healthchecks.baremetal.cluster.gke.io HEALTHCHECK_NAME \
    --kubeconfig ADMIN_KUBECONFIG \
    --namespace CLUSTER_NAMESPACE

    Haz los cambios siguientes:

    • HEALTHCHECK_NAME: el nombre de la comprobación del estado.
    • ADMIN_KUBECONFIG: la ruta del archivo kubeconfig del clúster de administrador.
    • CLUSTER_NAMESPACE: el espacio de nombres del clúster.

    Cuando revises el recurso, la sección Status: contendrá los siguientes campos importantes:

    • Pass: indica si se ha superado o no la última comprobación del estado.
    • Checks: contiene información sobre el trabajo de comprobación del estado más reciente.
    • Failures: contiene información sobre el último trabajo fallido.
    • Periodic: contiene información como la última vez que se programó y se instrumentó un trabajo de comprobación del estado.

    El siguiente ejemplo de HealthCheck corresponde a una comprobación correcta de la máquina:

    Name:         bm-system-192.0.2.54-machine
Namespace:    cluster-test-user001
Labels:       baremetal.cluster.gke.io/periodic-health-check=true
              machine=192.0.2.54
              type=machine
Annotations:  <none>
API Version:  baremetal.cluster.gke.io/v1
Kind:         HealthCheck
Metadata:
  Creation Timestamp:  2023-09-22T18:03:27Z
  ...
Spec:
  Anthos Bare Metal Version:  1.16.0
  Cluster Name:               nuc-user001
  Interval In Seconds:        3600
  Node Addresses:
    192.168.1.54
  Type:  machine
Status:
  Check Image Version:  1.16.0-gke.26
  Checks:
    192.168.1.54:
      Job UID:  345b74a6-ce8c-4300-a2ab-30769ea7f855
      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
  ...
  Conditions:
    Last Transition Time:  2023-11-22T17:53:18Z
    Observed Generation:   1
    Reason:                LastPeriodicHealthCheckFinished
    Status:                False
    Type:                  Reconciling
  Node Pool Specs:
    node-pool-1:
      Cluster Name:  nuc-user001
    ...
  Pass:                  true
  Periodic:
    Last Schedule Time:                    2023-11-22T17:53:18Z
    Last Successful Instrumentation Time:  2023-11-22T17:53:18Z
  Start Time:                              2023-09-22T18:03:28Z
Events:
  Type    Reason                  Age                  From                    Message
  ----    ------                  ----                 ----                    -------
  Normal  HealthCheckJobFinished  6m4s (x2 over 6m4s)  healthcheck-controller  health check job bm-system-192.0.2.54-machine-28344593 finished

    El siguiente ejemplo de HealthCheck corresponde a una comprobación de máquina fallida:

    Name:         bm-system-192.0.2.57-machine
Namespace:    cluster-user-cluster1
...
API Version:  baremetal.cluster.gke.io/v1
Kind:         HealthCheck
...
Status:
  Checks:
    192.0.2.57:
      Job UID:  492af995-3bd5-4441-a950-f4272cb84c83
      Message:  following checks failed, ['check_kubelet_pass']
      Pass:     false
  Failures:
    Category:     AnsibleJobFailed
    Description:  Job: machine-health-check.
    Details:       Target: 1192.0.2.57. View logs with: [kubectl logs -n cluster-user-test bm-system-192.0.2.57-machine-28303170-qgmhn].
    Reason:       following checks failed, ['check_kubelet_pass']
  Pass:                  false
  Periodic:
    Last Schedule Time:                    2023-10-24T23:04:21Z
    Last Successful Instrumentation Time:  2023-10-24T23:31:30Z
  ...

  3. Para obtener una lista de comprobaciones de estado de las métricas, usa el siguiente comando:

    kubectl get healthchecks.anthos.gke.io \
    --kubeconfig CLUSTER_KUBECONFIG \
    --namespace kube-system

    Sustituye CLUSTER_KUBECONFIG por la ruta del archivo kubeconfig del clúster de destino.

    En el siguiente ejemplo se muestra el formato de la respuesta:

    NAMESPACE     NAME                                            COMPONENT   NAMESPACE   STATUS    LAST_COMPLETED
kube-system   bm-system-add-ons-add-ons                                               Healthy   48m
kube-system   bm-system-add-ons-configdrift                                           Healthy   48m
kube-system   bm-system-default-daemonset                                             Healthy   52m
kube-system   bm-system-default-deployment                                            Healthy   52m
kube-system   bm-system-default-node                                                  Healthy   52m
kube-system   bm-system-default-pod                                                   Healthy   52m
kube-system   bm-system-default-poddisruptionbudget                                   Healthy   52m
kube-system   bm-system-default-resource                                              Healthy   52m
kube-system   bm-system-default-service                                               Healthy   52m
kube-system   bm-system-default-statefulset                                           Healthy   57m
kube-system   bm-system-kubernetes                                                    Healthy   57m
kube-system   bm-system-network                                                       Healthy   32m
kube-system   component-status-controller-manager                                     Healthy   5s
kube-system   component-status-etcd-0                                                 Healthy   5s
kube-system   component-status-etcd-1                                                 Healthy   5s
kube-system   component-status-scheduler                                              Healthy   5s

Tareas cron de comprobación del estado

Para las comprobaciones de estado periódicas, cada recurso personalizado de HealthCheck de hardware desnudo tiene un CronJob correspondiente con el mismo nombre. Este CronJob se encarga de programar la comprobación del estado correspondiente para que se ejecute a intervalos definidos. El CronJob también incluye un contenedor ansible-runner que ejecuta la comprobación de estado estableciendo una conexión Secure Shell (SSH) con los nodos.

Para obtener información sobre las tareas cron, sigue estos pasos:

  1. Obtén una lista de las tareas cron que se han ejecutado en un clúster determinado:

    kubectl get cronjobs \
    --kubeconfig ADMIN_KUBECONFIG \
    --namespace CLUSTER_NAMESPACE

    Haz los cambios siguientes:

    • ADMIN_KUBECONFIG: la ruta del archivo kubeconfig del clúster de administrador.
    • CLUSTER_NAMESPACE: el espacio de nombres del clúster.

    En el siguiente ejemplo se muestra una respuesta típica:

    NAMESPACE           NAME                           SCHEDULE       SUSPEND   ACTIVE   LAST SCHEDULE   AGE
cluster-test-admin   bm-system-10.200.0.3-machine   17 */1 * * *   False     0        11m             25d
cluster-test-admin   bm-system-add-ons              25 */1 * * *   False     0        3m16s           25d
cluster-test-admin   bm-system-kubernetes           16 */1 * * *   False     0        12m             25d
cluster-test-admin   bm-system-network              41 */1 * * *   False     0        47m             25d

    Los valores de la columna SCHEDULE indican la programación de cada ejecución de la tarea de comprobación del estado en sintaxis de programación. Por ejemplo, el trabajo bm-system-kubernetes se ejecuta 17 minutos después de cada hora (17) cada hora (*/1) de cada día (* * *). Los intervalos de tiempo de las comprobaciones de estado periódicas no se pueden editar, pero es útil saber cuándo se supone que se deben ejecutar para solucionar problemas.

  2. Recuperar los detalles de un CronJob recurso personalizado específico:

    kubectl describe cronjob CRONJOB_NAME \
    --kubeconfig ADMIN_KUBECONFIG \
    --namespace CLUSTER_NAMESPACE

    Haz los cambios siguientes:

    • ADMIN_KUBECONFIG: la ruta del archivo kubeconfig del clúster de administrador.
    • CLUSTER_NAMESPACE: el espacio de nombres del clúster.

    En el siguiente ejemplo se muestra una CronJob correcta:

    Name:                          bm-system-network
Namespace:                     cluster-test-admin
Labels:                        AnthosBareMetalVersion=1.16.1
                               baremetal.cluster.gke.io/check-name=bm-system-network
                               baremetal.cluster.gke.io/periodic-health-check=true
                               controller-uid=2247b728-f3f5-49c2-86df-9e5ae9505613
                               type=network
Annotations:                   target: node-network
Schedule:                      41 */1 * * *
Concurrency Policy:            Forbid
Suspend:                       False
Successful Job History Limit:  1
Failed Job History Limit:      1
Starting Deadline Seconds:     <unset>
Selector:                      <unset>
Parallelism:                   <unset>
Completions:                   1
Active Deadline Seconds:       3600s
Pod Template:
  Labels:           baremetal.cluster.gke.io/check-name=bm-system-network
  Annotations:      target: node-network
  Service Account:  ansible-runner
  Containers:
  ansible-runner:
    Image:      gcr.io/anthos-baremetal-release/ansible-runner:1.16.1-gke.5
    Port:       <none>
    Host Port:  <none>
    Command:
      cluster
    Args:
      -execute-command=network-health-check
      -login-user=root
      -controlPlaneLBPort=443
    Environment:  <none>
    Mounts:
      /data/configs from inventory-config-volume (ro)
      /etc/ssh-key from ssh-key-volume (ro)
  Volumes:
  inventory-config-volume:
    Type:      ConfigMap (a volume populated by a ConfigMap)
    Name:      bm-system-network-inventory-bm-system-ne724a7cc3584de0635099
    Optional:  false
  ssh-key-volume:
    Type:            Secret (a volume populated by a Secret)
    SecretName:      ssh-key
    Optional:        false
Last Schedule Time:  Tue, 14 Nov 2023 18:41:00 +0000
Active Jobs:         <none>
Events:
  Type    Reason            Age   From                Message
  ----    ------            ----  ----                -------
  Normal  SuccessfulCreate  48m   cronjob-controller  Created job bm-system-network-28333121
  Normal  SawCompletedJob   47m   cronjob-controller  Saw completed job: bm-system-network-28333121, status: Complete
  Normal  SuccessfulDelete  47m   cronjob-controller  Deleted job bm-system-network-28333061

Registros de comprobación del estado

Cuando se ejecutan las comprobaciones del estado, se generan registros. Tanto si ejecutas comprobaciones del estado con bmctl como si se ejecutan automáticamente como parte de comprobaciones periódicas, los registros se envían a Cloud Logging. Cuando ejecutas comprobaciones de estado a petición, se crean archivos de registro en una carpeta con marca de tiempo en el directorio log/ de la carpeta de tu clúster en tu estación de trabajo de administrador. Por ejemplo, si ejecutas el comando bmctl check kubernetes en un clúster llamado test-cluster, encontrarás los registros en un directorio como bmctl-workspace/test-cluster/log/check-kubernetes-20231103-165923.

Ver registros de forma local

Puedes usar kubectl para ver los registros de las comprobaciones del estado periódicas:

  1. Obtén pods y busca el pod de comprobación de estado que te interese:

    kubectl get pods \
    --kubeconfig ADMIN_KUBECONFIG \
    --namespace CLUSTER_NAMESPACE

    Haz los cambios siguientes:

    • 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 ejemplo se muestran algunos pods de comprobación del estado:

    NAME                                                              READY   STATUS      RESTARTS   AGE
bm-system-10.200.0.4-machine-28353626-lzx46                       0/1     Completed   0          12m
bm-system-10.200.0.5-machine-28353611-8vjw2                       0/1     Completed   0          27m
bm-system-add-ons-28353614-gxt8f                                  0/1     Completed   0          24m
bm-system-check-kernel-gce-user001-02fd2ac273bc18f008192e177x2c   0/1     Completed   0          75m
bm-system-cplb-init-10.200.0.4-822aa080-7a2cdd71a351c780bf8chxk   0/1     Completed   0          74m
bm-system-cplb-update-10.200.0.4-822aa082147dbd5220b0326905lbtj   0/1     Completed   0          67m
bm-system-gcp-check-create-cluster-202311025828f3c13d12f65k2xfj   0/1     Completed   0          77m
bm-system-kubernetes-28353604-4tc54                               0/1     Completed   0          34m
bm-system-kubernetes-check-bm-system-kub140f257ddccb73e32c2mjzn   0/1     Completed   0          63m
bm-system-machine-gcp-check-10.200.0.4-6629a970165889accb45mq9z   0/1     Completed   0          77m
...
bm-system-network-28353597-cbwk7                                  0/1     Completed   0          41m
bm-system-network-health-check-gce-user05e0d78097af3003dc8xzlbd   0/1     Completed   0          76m
bm-system-network-preflight-check-create275a0fdda700cb2b44b264c   0/1     Completed   0          77m

  2. Obtén los registros de pods:

    kubectl logs POD_NAME  \
    --kubeconfig ADMIN_KUBECONFIG \
    --namespace CLUSTER_NAMESPACE

    Haz los cambios siguientes:

    • POD_NAME: el nombre del pod de comprobación del estado.
    • ADMIN_KUBECONFIG: la ruta del archivo kubeconfig del clúster de administrador.
    • CLUSTER_NAMESPACE: el espacio de nombres del clúster.

    En el siguiente ejemplo se muestra parte del registro de un pod correspondiente a una comprobación del estado de una máquina de nodo correcta:

    ...
TASK [Summarize health check] **************************************************
Wednesday 29 November 2023  00:26:22 +0000 (0:00:00.419)       0:00:19.780 ****
ok: [10.200.0.4] => {
    "results": {
        "check_cgroup_pass": "passed",
        "check_cni_pass": "passed",
        "check_containerd_pass": "passed",
        "check_cpu_pass": "passed",
        "check_default_route": "passed",
        "check_disks_pass": "passed",
        "check_dns_pass": "passed",
        "check_docker_pass": "passed",
        "check_gcr_pass": "passed",
        "check_googleapis_pass": "passed",
        "check_kernel_version_pass": "passed",
        "check_kubelet_pass": "passed",
        "check_memory_pass": "passed",
        "check_pod_cidr_intersect_pass": "passed",
        "check_registry_mirror_reachability_pass": "passed",
        "check_time_sync_pass": "passed",
        "check_ubuntu_1804_kernel_version": "passed",
        "check_ufw_pass": "passed",
        "check_vcpu_pass": "passed"
    }
}
...

    En el siguiente ejemplo se muestra parte del registro de un pod de comprobación del estado de un nodo que ha fallado. En el ejemplo se muestra que la comprobación kubelet (check_kubelet_pass) ha fallado, lo que indica que kubelet no se está ejecutando en este nodo.

    ...
TASK [Reach a final verdict] ***************************************************
Thursday 02 November 2023  17:30:19 +0000 (0:00:00.172)       0:00:17.218 *****
fatal: [10.200.0.17]: FAILED! => {"changed": false, "msg": "following checks failed, ['check_kubelet_pass']"}
...

Ver los registros en Cloud Logging

Los registros de comprobación del estado se envían a Cloud Logging y se pueden ver en el Explorador de registros. Las comprobaciones de estado periódicas se clasifican como pods en los registros de la consola.

  1. En la Google Cloud consola, ve a la página Explorador de registros del menú Logging.

    Ir a Explorador de registros

  2. En el campo Consulta, introduce la siguiente consulta básica:

    resource.type="k8s_container"
resource.labels.pod_name=~"bm-system.*-machine.*"

  3. En la ventana Resultados de la consulta se muestran los registros de las comprobaciones del estado de la máquina de nodos.

Aquí tienes una lista de consultas para comprobaciones periódicas del estado:

  • Predeterminado

    resource.type="k8s_container"
resource.labels.pod_name=~"bm-system.default-*"

  • Máquina de nodos

    resource.type="k8s_container"
resource.labels.pod_name=~"bm-system.*-machine.*"

  • Red

    resource.type="k8s_container"
resource.labels.pod_name=~"bm-system-network.*"

  • Kubernetes

    resource.type="k8s_container"
resource.labels.pod_name=~"bm-system-kubernetes.*"

  • Complementos

    resource.type="k8s_container"
resource.labels.pod_name=~"bm-system-add-ons.*"

Comprobaciones periódicas del estado

De forma predeterminada, las comprobaciones de estado periódicas se ejecutan cada hora y comprueban los siguientes componentes del clúster:

Para comprobar el estado del clúster, consulta los recursos personalizados de Bare Metal HealthCheck (healthchecks.baremetal.cluster.gke.io) en el clúster de administrador. Las comprobaciones de red, Kubernetes y complementos son comprobaciones a nivel de clúster, por lo que hay un solo recurso para cada comprobación. Se ejecuta una comprobación de la máquina en cada nodo del clúster de destino, por lo que hay un recurso para cada nodo.

  • Para enumerar los recursos de HealthCheck de un clúster determinado, ejecuta el siguiente comando:

    kubectl get healthchecks.baremetal.cluster.gke.io \
    --kubeconfig=ADMIN_KUBECONFIG \
    --namespace=CLUSTER_NAMESPACE

    Haz los cambios siguientes:

    • ADMIN_KUBECONFIG: la ruta del archivo kubeconfig del clúster de administrador.

    • CLUSTER_NAMESPACE: el espacio de nombres del clúster de destino de la comprobación de estado.

    En la siguiente respuesta de ejemplo se muestra el formato:

    NAMESPACE               NAME                               PASS    AGE
cluster-test-user001    bm-system-192.0.2.53-machine       true    56d
cluster-test-user001    bm-system-192.0.2.54-machine       true    56d
cluster-test-user001    bm-system-add-ons                  true    56d
cluster-test-user001    bm-system-kubernetes               true    56d
cluster-test-user001    bm-system-network                  true    56d

    El campo Pass de healthchecks.baremetal.cluster.gke.io indica si la última comprobación del estado se ha realizado correctamente (true) o no (false).

Para obtener más información sobre cómo comprobar el estado de las comprobaciones de estado periódicas, consulta los HealthCheckrecursos personalizados y los registros de comprobación del estado.

Inhabilitar comprobaciones de estado periódicas

Las comprobaciones de estado periódicas están habilitadas de forma predeterminada en todos los clústeres. Puedes inhabilitar las comprobaciones de estado periódicas de un clúster configurando el campo periodicHealthCheck.enable en false en el recurso Cluster.

Para inhabilitar las comprobaciones de estado periódicas, sigue estos pasos:

  1. Edita el archivo de configuración del clúster y añade el campo periodicHealthCheck.enable a la especificación del clúster y asigna el valor false:

    apiVersion: v1
kind: Namespace
metadata:
  name: cluster-user-basic
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: user-basic
  namespace: cluster-user-basic
spec:
  type: user
  profile: default
  ...
  periodicHealthCheck:
    enable: false
  ...

  2. Para actualizar el clúster, ejecuta el siguiente comando:

    bmctl update cluster -c CLUSTER_NAME \
    --kubeconfig ADMIN_KUBECONFIG

    Haz los cambios siguientes:

    • CLUSTER_NAME: el nombre del clúster que quieras actualizar.

    • ADMIN_KUBECONFIG: la ruta del archivo kubeconfig del clúster de administrador.

  3. Para verificar que las comprobaciones de estado periódicas se han inhabilitado, ejecuta el siguiente comando para confirmar que se han eliminado los recursos healthchecks.baremetal.cluster.gke.io correspondientes:

    kubectl get healthchecks.baremetal.cluster.gke.io \
    --kubeconfig=ADMIN_KUBECONFIG \
    --namespace=CLUSTER_NAMESPACE

    Haz los cambios siguientes:

    • ADMIN_KUBECONFIG: la ruta del archivo kubeconfig del clúster de administrador.

    • CLUSTER_NAMESPACE: el espacio de nombres del clúster de destino de la comprobación de estado.

Volver a habilitar las comprobaciones del estado periódicas

Las comprobaciones de estado periódicas están habilitadas de forma predeterminada en todos los clústeres. Si has inhabilitado las comprobaciones de estado periódicas, puedes volver a habilitarlas configurando el campo periodicHealthCheck.enable en true en el recurso Cluster.

Para volver a habilitar las comprobaciones de estado periódicas, sigue estos pasos:

  1. Edita el archivo de configuración del clúster y añade el campo periodicHealthCheck.enable a la especificación del clúster y asigna el valor true:

    apiVersion: v1
kind: Namespace
metadata:
  name: cluster-user-basic
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: user-basic
  namespace: cluster-user-basic
spec:
  type: user
  profile: default
  ...
  periodicHealthCheck:
    enable: true
  ...

  2. Para actualizar el clúster, ejecuta el siguiente comando:

    bmctl update cluster -c CLUSTER_NAME \
    --kubeconfig ADMIN_KUBECONFIG

    Haz los cambios siguientes:

    • CLUSTER_NAME: el nombre del clúster que quieras actualizar.

    • ADMIN_KUBECONFIG: la ruta del archivo kubeconfig del clúster de administrador.

  3. Para verificar que las comprobaciones de estado periódicas están habilitadas, ejecuta el siguiente comando para confirmar que los recursos healthchecks.baremetal.cluster.gke.io correspondientes están presentes:

    kubectl get healthchecks.baremetal.cluster.gke.io --kubeconfig=ADMIN_KUBECONFIG \
    --namespace=CLUSTER_NAMESPACE

    Haz los cambios siguientes:

    • ADMIN_KUBECONFIG: la ruta del archivo kubeconfig del clúster de administrador.

    • CLUSTER_NAMESPACE: el espacio de nombres del clúster de destino de la comprobación de estado.

    Los recursos pueden tardar un par de minutos en aparecer.

Comprobaciones del estado bajo demanda

En las siguientes secciones se describen las comprobaciones del estado que puedes ejecutar bajo demanda con bmctl check. Cuando usas bmctl check para ejecutar comprobaciones del estado, se aplican las siguientes reglas:

  • Cuando compruebas un clúster de usuario con un comando bmctl check, especifica la ruta del archivo kubeconfig del clúster de administrador con la marca --kubeconfig.

  • Los registros se generan en un directorio con marca de tiempo en la carpeta de registros del clúster de tu estación de trabajo de administrador (de forma predeterminada, bmctl-workspace/CLUSTER_NAME/log).

  • Los registros de comprobación del estado también se envían a Cloud Logging. Para obtener más información sobre los registros, consulta Registros de comprobación del estado.

Para obtener más información sobre otras opciones de los comandos bmctl, consulta la referencia de comandos bmctl.

Complementos

Comprueba que los complementos de Kubernetes especificados para el clúster indicado funcionen.

  • Para comprobar los complementos de un clúster, sigue estos pasos:

    bmctl check add-ons --cluster CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG

    Haz los cambios siguientes:

    • CLUSTER_NAME: el nombre del clúster que quieres consultar.
    • ADMIN_KUBECONFIG: la ruta del archivo kubeconfig del clúster de administrador.

Para ver una lista de lo que se comprueba, consulta la sección Complementos de este documento.

Esta comprobación genera archivos de registro en un directorio check-addons-TIMESTAMP de la carpeta de registros del clúster de tu estación de trabajo de administrador. Los registros también se envían a Cloud Logging. Para obtener más información sobre los registros, consulta Registros de comprobación del estado.

Clúster

Comprueba todos los nodos del clúster, la red de nodos, Kubernetes y los complementos del clúster especificado. Tú proporcionas el nombre del clúster y bmctl busca el archivo de configuración del clúster en bmctl-workspace/CLUSTER_NAME/CLUSTER_NAME.yaml de forma predeterminada.

  • Para comprobar el estado de un clúster, sigue estos pasos:

    bmctl check cluster --cluster CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG

    Haz los cambios siguientes:

    • CLUSTER_NAME: el nombre del clúster que quieres consultar.
    • ADMIN_KUBECONFIG: la ruta del archivo kubeconfig del clúster de administrador.

Para ver una lista de los elementos que se comprueban, consulta las siguientes secciones de la sección "Qué se comprueba" de este documento:

Esta comprobación genera archivos de registro en un directorio check-cluster-TIMESTAMP de la carpeta de registros del clúster de tu estación de trabajo de administrador. Los registros también se envían a Cloud Logging. Para obtener más información sobre los registros, consulta Registros de comprobación del estado.

Configuración

Comprueba el archivo de configuración del clúster. Esta comprobación espera que hayas generado el archivo de configuración y lo hayas editado para especificar los detalles de configuración del clúster. El objetivo de este comando es determinar si alguna opción de configuración es incorrecta, falta o tiene algún error de sintaxis. Tú proporcionas el nombre del clúster y bmctl busca el archivo de configuración del clúster en bmctl-workspace/CLUSTER_NAME/CLUSTER_NAME.yaml de forma predeterminada.

  • Para comprobar un archivo de configuración de clúster, sigue estos pasos:

    bmctl check config --cluster CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG

    Haz los cambios siguientes:

    • CLUSTER_NAME: el nombre del clúster que quieres consultar.
    • ADMIN_KUBECONFIG: la ruta del archivo kubeconfig del clúster de administrador.

Este comando comprueba la sintaxis YAML del archivo de configuración del clúster, elGoogle Cloud acceso y los permisos de la cuenta de servicio especificada en el archivo de configuración del clúster.

Esta comprobación genera archivos de registro en un directorio check-config-TIMESTAMP de la carpeta de registros del clúster de tu estación de trabajo de administrador. Los registros también se envían a Cloud Logging. Para obtener más información sobre los registros, consulta Registros de comprobación del estado.

Conectividad con Google Cloud

Comprueba que todas las máquinas de los nodos del clúster puedan acceder a Artifact Registry (gcr.io) y al endpoint de las APIs de Google (googleapis.com).

  • Para comprobar el acceso del clúster a los recursos necesarios, Google Cloud sigue estos pasos:

    bmctl check gcp --cluster CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG

    Haz los cambios siguientes:

    • CLUSTER_NAME: el nombre del clúster que quieres consultar.
    • ADMIN_KUBECONFIG: la ruta del archivo kubeconfig del clúster de administrador.

Esta comprobación genera archivos de registro en un directorio check-gcp-TIMESTAMP de la carpeta de registros del clúster de tu estación de trabajo de administrador. Los registros también se envían a Cloud Logging. Para obtener más información sobre los registros, consulta Registros de comprobación del estado.

Kubernetes

Comprueba el estado de los operadores de Kubernetes críticos que se ejecutan en el plano de control. Esta comprobación verifica que los operadores críticos funcionan correctamente y que sus pods no fallan. Esta comprobación del estado no devuelve un error si falta alguno de los componentes del plano de control. Solo devuelve errores si los componentes existen y tienen errores en el momento de la ejecución de los comandos.

  • Para comprobar el estado de los componentes de Kubernetes de tu clúster, sigue estos pasos:

    bmctl check kubernetes --cluster CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG

    Haz los cambios siguientes:

    • CLUSTER_NAME: el nombre del clúster que contiene los nodos que estás comprobando.
    • ADMIN_KUBECONFIG: la ruta del archivo kubeconfig del clúster de administrador.

Para ver una lista de lo que se comprueba, consulta Kubernetes en la sección Qué se comprueba de este documento.

Esta comprobación genera archivos de registro en un directorio check-kubernetes-TIMESTAMP de la carpeta de registros del clúster de tu estación de trabajo de administrador. Los registros también se envían a Cloud Logging. Para obtener más información sobre los registros, consulta Registros de comprobación del estado.

Nodos

Comprueba las máquinas de los nodos del clúster para confirmar que están configuradas correctamente y que tienen suficientes recursos y conectividad para las actualizaciones y el funcionamiento del clúster.

  • Para comprobar el estado de las máquinas de nodos de tu clúster, sigue estos pasos:

    bmctl check nodes --cluster CLUSTER_NAME --addresses NODE_IP_ADDRESSES --kubeconfig ADMIN_KUBECONFIG

    Haz los cambios siguientes:

    • CLUSTER_NAME: el nombre del clúster que contiene los nodos que estás comprobando.
    • NODE_IP_ADDRESSES: lista de direcciones IP separadas por comas de los equipos de los nodos.
    • ADMIN_KUBECONFIG: la ruta del archivo kubeconfig del clúster de administrador.

Para ver una lista de los elementos que se comprueban, consulta Comprobaciones de máquinas de nodos en la sección "Qué se comprueba" de este documento.

Esta comprobación genera archivos de registro para cada máquina de nodo de clúster en un directorio check-nodes-TIMESTAMP de la carpeta de registro del clúster de tu estación de trabajo de administrador. Los registros también se envían a Cloud Logging. Para obtener más información sobre los registros, consulta Registros de comprobación del estado.

Solicitud preparatoria

Para obtener información sobre cómo usar bmctl para ejecutar comprobaciones de solicitudes preparatorias, consulta los artículos Ejecutar comprobaciones de solicitudes preparatorias bajo demanda para crear clústeres y Ejecutar comprobaciones de solicitudes preparatorias bajo demanda para actualizar clústeres.

Comprobación preparatoria del tiempo de ejecución de la VM

La comprobación previa del entorno de ejecución de máquinas virtuales en GDC valida un conjunto de requisitos previos de las máquinas de los nodos antes de usar el entorno de ejecución de máquinas virtuales en GDC y las máquinas virtuales. Si falla la comprobación previa del tiempo de ejecución de máquinas virtuales en GDC, se bloqueará la creación de la máquina virtual. Cuando spec.enabled se define como true en el recurso personalizado VMRuntime, la comprobación previa de VM Runtime en GDC se ejecuta automáticamente.

apiVersion: vm.cluster.gke.io/v1
kind: VMRuntime
metadata:
  name: vmruntime
spec:
  enabled: true
...

Para obtener más información, consulta el artículo sobre la comprobación de solicitudes preparatorias del tiempo de ejecución de máquinas virtuales en GDC.

Ejecutar las comprobaciones de estado más recientes

Las comprobaciones del estado (y las previas) se actualizan a medida que se identifican problemas conocidos. Para indicar a bmctl que ejecute las comprobaciones desde la imagen del parche más reciente de la versión secundaria instalada, usa la marca de opción --check-image-version latest:

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

Sustituye CLUSTER_NAME por el nombre del clúster que quieras comprobar.

De esta forma, puedes detectar cualquier problema conocido que se haya identificado recientemente sin tener que actualizar primero tu clúster.

También puedes realizar las últimas comprobaciones previas antes de instalar o actualizar un clúster. Para obtener más información, consulta Ejecutar las comprobaciones de solicitudes preparatorias más recientes.

Detección de deriva de configuración

Cuando se ejecuta la comprobación del estado de los complementos, se comprueban, entre otras cosas, los cambios inesperados en los recursos gestionados por Google Distributed Cloud. En concreto, la comprobación evalúa los manifiestos de estos recursos para determinar si entidades externas han realizado cambios. Estas comprobaciones pueden ayudar a predecir cambios inadvertidos que podrían ser perjudiciales para el estado del clúster. También proporcionan información valiosa para solucionar problemas.

Qué manifiestos se comprueban

Con algunas excepciones, la comprobación del estado de los complementos revisa todos los recursos gestionados por Google Distributed Cloud de tus clústeres. Se trata de recursos que instala y administra el software de Google Distributed Cloud. Hay cientos de estos recursos y la mayoría de sus manifiestos se comprueban para detectar desviaciones de configuración. Los manifiestos son para todo tipo de recursos, incluidos, entre otros, los siguientes:

  • ClusterRoles
  • ClusterRoleBindings
  • CustomResourceDefinitions
  • DaemonSets
  • Despliegues
  • HorizontalPodAutoscalers
  • Emisores
  • MetricsServers
  • MutatingWebhookConfigurations
  • Espacios de nombres
  • Redes
  • NetworkLoggings
  • PodDisruptionBudgets
  • Proveedores
  • Roles
  • RoleBindings
  • Servicios
  • StorageClasses
  • ValidatingWebhookConfigurations

Qué archivos de manifiesto no se comprueban

Por diseño, excluimos algunos manifiestos de la revisión. Por motivos de privacidad y seguridad, ignoramos determinados tipos de recursos, como certificados, secretos y cuentas de servicio. La comprobación de complementos también ignora algunos recursos y campos de recursos, ya que esperamos que se modifiquen y no queremos que los cambios provoquen errores de desviación de configuración. Por ejemplo, la comprobación ignora los campos replicas de las implementaciones, ya que el escalador automático puede modificar este valor.

Cómo excluir manifiestos o partes de manifiestos adicionales de la revisión

En general, te recomendamos que no hagas cambios en los recursos gestionados por Google Distributed Cloud ni ignores los cambios que se hagan en ellos. Sin embargo, sabemos que, en ocasiones, los recursos requieren modificaciones para abordar requisitos específicos o solucionar problemas. Por este motivo, proporcionamos un ignore-config-drift ConfigMap para cada clúster de tu flota. Estos ConfigMaps se usan para especificar los recursos y los campos de recursos concretos que se deben excluir de la evaluación.

Google Distributed Cloud crea un ignore-config-drift ConfigMap para cada clúster. Estos ConfigMaps se encuentran en el clúster de gestión (administrador o híbrido) en el espacio de nombres del clúster correspondiente. Por ejemplo, si tienes un clúster de administrador (admin-one) que gestiona dos clústeres de usuario (user-one y user-two), puedes encontrar el objeto ConfigMap ignore-config-drift del clúster user-one en el clúster admin-one, en el espacio de nombres cluster-user-one.

Para excluir un recurso o campos de recursos de la revisión, sigue estos pasos:

  1. Añade un campo data.ignore-resources al ConfigMap ignore-config-drift.

    Este campo acepta una matriz de cadenas JSON, en la que cada cadena especifica un recurso y, opcionalmente, campos específicos del recurso.

  2. Especifique el recurso y, opcionalmente, los campos concretos que quiera ignorar como objeto JSON en la matriz de cadenas:

    El objeto JSON de un recurso y sus campos tiene la siguiente estructura:

    {
  "Version": "RESOURCE_VERSION",
  "Kind": "RESOURCE_KIND",
  "Namespace": "RESOURCE_NAMESPACE",
  "Name": "RESOURCE_NAME",
  "Fields": [
    "FIELD_1_NAME",
    "FIELD_2_NAME",
    ...
    "FIELD_N_NAME"
  ]
}

    Haz los cambios siguientes:

    • RESOURCE_VERSION: (opcional) el valor apiVersion del recurso.

    • RESOURCE_KIND: (opcional) el valor kind del recurso.

    • RESOURCE_NAMESPACE: (opcional) el valor metadata.namespace del recurso.

    • RESOURCE_NAME: (opcional) el valor metadata.name del recurso.

    • FIELD_NAME: (opcional) especifica una matriz de campos de recursos que se deben ignorar. Si no especifica ningún campo, la comprobación de complementos ignora todos los cambios realizados en el recurso.

    Todos los campos del objeto JSON son opcionales, por lo que se permiten varias permutaciones. Puedes excluir categorías completas de recursos o ser muy preciso y excluir campos específicos de un recurso concreto.

    Por ejemplo, si quieres que la comprobación de complementos ignore los cambios realizados solo en la sección commandais de la implementación de tu clúster de administrador, el JSON podría tener el siguiente aspecto:

    {
  "Version": "apps/v1",
  "Kind": "Deployment",
  "Namespace": "anthos-identity-service",
  "Name": "ais",
  "Fields": [
    "command"
  ]
}

    Añadirías este objeto JSON a ignore-resources en el config-drift-ignore ConfigMap como un valor de cadena en una matriz, tal como se muestra en el siguiente ejemplo:

    apiVersion: v1
kind: ConfigMap
metadata:
  creationTimestamp: "2024-09-24T00:39:45Z"
  name: config-drift-ignore
  namespace: cluster-example-admin
  ownerReferences:
  - apiVersion: baremetal.cluster.gke.io/v1
    kind: Cluster
    name: example-admin
  ...
data:
  ignore-resources: '[{"Version":"apps/v1","Kind":"Deployment","Namespace":"anthos-identity-service","Name":"ais","Fields":["command"]}]'
  ...

    Este ajuste de ConfigMap te permite añadir, quitar o editar campos command en la implementación ais sin que se produzcan errores de deriva de configuración. Sin embargo, los cambios en los campos que no estén en la sección command de la implementación seguirán detectándose en la comprobación de complementos y se informarán como desviación de la configuración.

    Si quiere excluir todos los despliegues, el valor ignore-resources podría ser el siguiente:

    ...
data:
  ignore-resources: '[{"Kind":"Deployment"}]'
...

    Como ignore-resources acepta una matriz de cadenas JSON, puedes especificar varios patrones de exclusión. Si estás solucionando problemas o experimentando con tus clústeres y no quieres que se produzcan errores de desviación de configuración, esta flexibilidad para excluir tanto recursos muy específicos como campos de recursos o categorías más amplias de recursos de la detección de desviaciones puede ser útil.

Siguientes pasos

Para obtener más información, consulta las siguientes secciones:

Si necesitas más ayuda, ponte en contacto con el servicio de atención al cliente de Cloud. También puedes consultar la sección Obtener asistencia para obtener más información sobre los recursos de asistencia, incluidos los siguientes:

  • Requisitos para abrir un caso de asistencia.
  • Herramientas para ayudarte a solucionar problemas, como la configuración de tu entorno, los registros y las métricas.
  • Componentes admitidos.