Verificaciones de estado

Las verificaciones de estado son una forma de probar y supervisar el funcionamiento de tus clústeres existentes. Las verificaciones de estado se ejecutan por sí solas de forma periódica. También puedes usar bmctl para ejecutar verificaciones de estado según demanda. 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.

¿Qué se verifica?

Existen dos categorías de verificaciones de estado de Google Distributed Cloud:

  • Verificaciones de la máquina de nodo

  • Verificaciones en todo el clúster

En las siguientes secciones, se describe lo que se verifica en cada categoría. Estas verificaciones se usan para las verificaciones de estado periódicas y a pedido.

Verificaciones de la máquina de nodo

En esta sección, se describe lo que evalúan las verificaciones de estado para las máquinas de nodos. Estas verificaciones confirman que las máquinas de nodos estén configuradas correctamente y que tengan suficientes recursos y conectividad para la creación, las actualizaciones y el funcionamiento del clúster.

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

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

Las verificaciones comunes de la máquina incluyen lo siguiente:

  • 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 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 firewall sin complicaciones (UFW) está inhabilitado.

  • Las máquinas de nodos cumplen con los requisitos mínimos de CPU.

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

  • Las máquinas de nodos cumplen con los requisitos mínimos de memoria.

  • Las máquinas de nodos cumplen con los requisitos mínimos de almacenamiento en disco.

  • La sincronización de tiempo está configurada en las máquinas de nodos.

  • 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 (esta verificació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 duplicación de registro, se puede acceder a ella.

Las verificaciones de la máquina Google Cloud constan de lo siguiente:

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

  • Se puede acceder a las APIs de Google.

Las verificaciones de estado de la máquina constan de lo siguiente:

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

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

  • 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.
Para obtener más información sobre los requisitos de la máquina del nodo, consulta Requisitos previos de la máquina del nodo del clúster.

Verificaciones en todo el clúster

En esta sección, se describe lo que evalúan las verificaciones de estado de un clúster.

Verificaciones predeterminadas

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

Estas verificaciones corresponden a los recursos personalizados de HealthCheck de Bare Metal denominados recursos de bm-system-default-* que se ejecutan en el clúster de administrador en el espacio de nombres del clúster. Para obtener más información sobre los recursos de verificación de estado, consulta HealthCheckrecursos personalizados.

Las verificaciones predeterminadas del clúster 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 (las siguientes son todas las 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 de containerd
    • Frecuencia de reinicio de containerd
    • Función Overlay2 de Docker
    • Frecuencia de reinicio de Docker
    • Frecuencia de eventos de cancelación de registro de dispositivos de red
    • Interbloqueos 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 PDB coinciden con los Pods
    • Pods no administrados por varios PDB

  • Solicitudes de recursos

    • Los Pods en los nodos de destino tienen establecidos los requisitos de CPU y memoria.
    • El promedio 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

Verificaciones de red

Las siguientes verificaciones de red de nodos del clúster del cliente se ejecutan automáticamente como parte de las verificaciones de estado periódicas. Las verificaciones de red no se pueden ejecutar según demanda. Estas verificaciones corresponden a los recursos personalizados de HealthCheck de Bare Metal llamados bm-system-network que se ejecutan en el clúster de administrador en el espacio de nombres del clúster. Para obtener más información sobre los recursos de verificación de estado, consulta Recursos personalizados de HealthCheck.

  • Si el clúster usa el balanceo de cargas en paquetes, los nodos del grupo de nodos de balanceo de cargas deben tener conectividad del protocolo de resolución de direcciones (ARP) de capa 2. Se requiere ARP para el descubrimiento 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 de etcd-events.

Para obtener información sobre los protocolos y el uso de puertos de tus clústeres, consulta Requisitos de red. Las verificaciones de red para una verificación previa difieren de las verificaciones de estado de la red. Para obtener una lista de las verificaciones de red de una verificación previa, consulta Verificaciones previas para la creación de clústeres o Verificaciones previas para la actualización de clústeres.

Kubernetes

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

Estas verificaciones corresponden a los recursos personalizados de HealthCheck de Bare Metal denominados recursos de bm-system-kubernetes que se ejecutan en el clúster de administrador en el espacio de nombres del clúster. Para obtener más información sobre los recursos de verificación de estado, consulta HealthCheckrecursos personalizados.

  • El servidor de la API funciona correctamente.

  • El operador anetd está configurado correctamente.

  • Todos los nodos del plano de control están operativos.

  • 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 verificaciones de complementos se ejecutan automáticamente como parte de las verificaciones previas y de estado periódicas, y se pueden ejecutar bajo demanda. Esta verificación de estado no muestra un error si falta alguno de los complementos enumerados. La verificación solo devuelve errores si los complementos existen y tienen errores en el momento de la ejecución del comando.

Estas verificaciones corresponden a los recursos personalizados de HealthCheck de Bare Metal denominados recursos de bm-system-add-ons* que se ejecutan en el clúster de administrador en el espacio de nombres del clúster. Para obtener más información sobre los recursos de verificación de estado, consulta HealthCheckrecursos personalizados.

  • Los componentes de Stackdriver de Cloud Logging y el agente de Connect funcionan correctamente:

    • stackdriver-log-aggregator

    • stackdriver-log-forwarder

    • stackdriver-metadata-agent

    • stackdriver-prometheus-k8

    • gke-connect-agent

  • Los recursos administrados por Google Distributed Cloud no muestran cambios manuales (retraso de configuración):

    • No se actualizaron los valores de los campos

    • No se agregaron ni quitaron campos opcionales.

    • No se borraron los recursos

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

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

Recursos personalizados HealthCheck

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

  • Recursos personalizados HealthCheck de Bare Metal (API Version: baremetal.cluster.gke.io/v1): Estos recursos proporcionan detalles sobre las verificaciones 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 son responsables de crear trabajos y trabajos cron de verificación de estado. Estos recursos se actualizan constantemente con los resultados más recientes.

  • Recursos personalizados HealthCheck de Anthos (API Version: anthos.gke.io/v1): Estos recursos se usan para informar las métricas de verificació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 con el mejor esfuerzo. Si una actualización falla debido a un problema, como un error de red transitorio, se ignora la falla.

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

Verificaciones de estado de Bare Metal Verificaciones 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ítico

Tipo: máquina

Nombre: bm-system-NODE_IP_ADDRESS-machine

Tipo: máquina

Nombre: bm-system-NODE_IP_ADDRESS-machine

Crítico

Tipo: network

Nombre: bm-system-network

Tipo: network

Nombre: bm-system-network

Crítico

Tipo: kubernetes

Nombre: bm-system-kubernetes

Tipo: kubernetes

Nombre: bm-system-kubernetes

Crítico

Tipo: Complementos

Nombre: bm-system-add-ons

Tipo: Complementos

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

Nombre: bm-system-add-ons-configdrift

Opcional

Para recuperar el estado de HealthCheck, haz lo siguiente:

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

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

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

    En el siguiente ejemplo, se muestran las verificaciones de estado que se ejecutan periódicamente y si se aprobaron cuando se ejecutaron por última vez:

    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 verificación de estado específica, usa kubectl describe:

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

    Reemplaza lo siguiente:

    • HEALTHCHECK_NAME: el nombre de la verificación de 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 aprobó o no el último trabajo de verificación de estado.
    • Checks: Contiene información sobre el trabajo de verificación de estado más reciente.
    • Failures: Contiene información sobre el trabajo con errores más reciente.
    • Periodic: Contiene información, como la última vez que se programó y se instrumentó un trabajo de verificación de estado.

    La siguiente muestra de HealthCheck es para una verificación de la máquina exitosa:

    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 es para una verificació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 las verificaciones de estado de las métricas, usa el siguiente comando:

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

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

    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

Trabajos cron de verificación de estado

En el caso de las verificaciones de estado periódicas, cada recurso personalizado HealthCheck de metal desnudo tiene un CronJob correspondiente con el mismo nombre. Este CronJob es responsable de programar la verificación de estado correspondiente para que se ejecute en intervalos establecidos. El CronJob también incluye un contenedor ansible-runner que ejecuta la verificación de estado estableciendo una conexión de shell seguro (SSH) a los nodos.

Para recuperar información sobre los trabajos cron, haz lo siguiente:

  1. Obtén una lista de los trabajos cron que se ejecutaron para un clúster determinado:

    kubectl get cronjobs \
    --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 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 del trabajo de verificación de estado en la sintaxis de programación. Por ejemplo, el trabajo bm-system-kubernetes se ejecuta 17 minutos después de la hora (17) cada hora (*/1) de cada día (* * *). Los intervalos de tiempo para las verificaciones de estado periódicas no se pueden editar, pero es útil para solucionar problemas saber cuándo se supone que se deben ejecutar.

  2. Para recuperar detalles de un recurso personalizado CronJob específico, haz lo siguiente:

    kubectl describe cronjob CRONJOB_NAME \
    --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 el siguiente ejemplo, se muestra un CronJob exitoso:

    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 verificaciones de estado

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

Visualiza registros de forma local

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

  1. Obtén Pods y busca el Pod de verificación de estado específico que te interesa:

    kubectl get pods \
    --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 muestra, se muestran algunos Pods de verificación de 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. Recupera los registros del Pod:

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

    Reemplaza lo siguiente:

    • POD_NAME: Es el nombre del Pod de verificación de 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 de un registro de Pod para una verificación de estado de la máquina del nodo exitosa:

    ...
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 verificación de estado de la máquina del nodo que falló. En el ejemplo, se muestra que falló la verificación de kubelet (check_kubelet_pass), 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 registros en Cloud Logging

Los registros de verificación de estado se transmiten a Cloud Logging y se pueden ver en el Explorador de registros. Las verificaciones de estado periódicas se clasifican como Pods en los registros de la consola.

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

    Ir al Explorador de registros

  2. En el campo Consulta, ingresa 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 verificaciones de estado de la máquina del nodo.

A continuación, se incluye una lista de consultas para las verificaciones de estado periódicas:

  • Predeterminado

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

  • Máquina de nodo

    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.*"

Verificaciones de estado periódicas

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

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

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

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

    Reemplaza lo siguiente:

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

    • CLUSTER_NAMESPACE: Es el espacio de nombres del clúster de destino de la verificació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 para healthchecks.baremetal.cluster.gke.io indica si la última verificación de estado se aprobó (true) o falló (false).

Para obtener más información sobre cómo verificar el estado de las verificaciones de estado periódicas, consulta los recursos personalizados de HealthCheck y los registros de verificaciones de estado.

Inhabilita las verificaciones de estado periódicas

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

Para inhabilitar las verificaciones de estado periódicas, haz lo siguiente:

  1. Edita el archivo de configuración del clúster, agrega el campo periodicHealthCheck.enable a la especificación del clúster y establece su valor en 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. Actualiza el clúster ejecutando el siguiente comando:

    bmctl update cluster -c CLUSTER_NAME \
    --kubeconfig ADMIN_KUBECONFIG

    Reemplaza lo siguiente:

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

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

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

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

    Reemplaza lo siguiente:

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

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

Vuelve a habilitar las verificaciones de estado periódicas

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

Para volver a habilitar las verificaciones de estado periódicas, haz lo siguiente:

  1. Edita el archivo de configuración del clúster, agrega el campo periodicHealthCheck.enable a la especificación del clúster y establece su valor en 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. Actualiza el clúster ejecutando el siguiente comando:

    bmctl update cluster -c CLUSTER_NAME \
    --kubeconfig ADMIN_KUBECONFIG

    Reemplaza lo siguiente:

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

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

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

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

    Reemplaza lo siguiente:

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

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

    Es posible que los recursos tarden unos minutos en aparecer.

Verificaciones de estado según demanda

En las siguientes secciones, se describen las verificaciones de estado que puedes ejecutar a pedido con bmctl check. Cuando usas bmctl check para ejecutar verificaciones de estado, se aplican las siguientes reglas:

  • Cuando verifiques un clúster de usuario con un comando bmctl check, especifica la ruta de acceso del archivo kubeconfig para el 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 en tu estación de trabajo de administrador (de forma predeterminada, bmctl-workspace/CLUSTER_NAME/log).

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

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

Complementos

Verifica que los complementos de Kubernetes especificados para el clúster especificado estén operativos.

  • Para verificar los complementos de un clúster, haz lo siguiente:

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

    Reemplaza lo siguiente:

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

Para obtener una lista de lo que se verifica, consulta Complementos en la sección Qué se verifica de este documento.

Esta verificación genera archivos de registro en un directorio check-addons-TIMESTAMP en la carpeta de registro del clúster en 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 verificación de estado.

Clúster

Verifica todos los nodos del clúster, las redes de nodos, Kubernetes y los complementos del clúster especificado. 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 verificar el estado de un clúster, haz lo siguiente:

    bmctl check cluster --cluster CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG

    Reemplaza lo siguiente:

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

Para obtener una lista de lo que se verifica, consulta las siguientes secciones en la sección Qué se verifica de este documento:

Esta verificación genera archivos de registro en un directorio check-cluster-TIMESTAMP en la carpeta de registro del clúster en 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 verificación de estado.

Configuración

Verifica el archivo de configuración del clúster. Esta verificació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 propósito de este comando es determinar si algún parámetro de configuración es incorrecto, falta o tiene errores de sintaxis. 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 verificar un archivo de configuración del clúster, haz lo siguiente:

    bmctl check config --cluster CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG

    Reemplaza lo siguiente:

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

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

Esta verificación genera archivos de registro en un directorio check-config-TIMESTAMP en la carpeta de registro del clúster en 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 verificación de estado.

Conectividad a Google Cloud

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

  • Para verificar el acceso del clúster a los recursos Google Cloud necesarios, haz lo siguiente:

    bmctl check gcp --cluster CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG

    Reemplaza lo siguiente:

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

Esta verificación genera archivos de registro en un directorio check-gcp-TIMESTAMP en la carpeta de registro del clúster en 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 verificación de estado.

Kubernetes

Comprueba el estado de los operadores críticos de Kubernetes que se ejecutan en el plano de control. Esta verificación confirma que los operadores críticos funcionan correctamente y que sus pods no fallan. Esta verificación de estado no muestra un error si falta alguno de los componentes del plano de control: solo muestra errores si los componentes existen y tienen errores en el momento de la ejecución del comando.

  • Para verificar el estado de los componentes de Kubernetes en tu clúster, haz lo siguiente:

    bmctl check kubernetes --cluster CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG

    Reemplaza lo siguiente:

    • CLUSTER_NAME: Es el nombre del clúster que contiene los nodos que verificas.
    • ADMIN_KUBECONFIG: la ruta del archivo kubeconfig del clúster de administrador

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

Esta verificación genera archivos de registro en un directorio check-kubernetes-TIMESTAMP en la carpeta de registros del clúster en 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 verificación de estado.

Nodos

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

  • Para verificar el estado de las máquinas de nodos en tu clúster, haz lo siguiente:

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

    Reemplaza lo siguiente:

    • CLUSTER_NAME: Es el nombre del clúster que contiene los nodos que verificas.
    • NODE_IP_ADDRESSES: Es una lista separada por comas de las direcciones IP de las máquinas de los nodos.
    • ADMIN_KUBECONFIG: la ruta del archivo kubeconfig del clúster de administrador

Para obtener una lista de lo que se verifica, consulta Verificaciones de la máquina del nodo en la sección Qué se verifica de este documento.

Esta verificación genera archivos de registro para cada máquina de nodo del clúster en un directorio check-nodes-TIMESTAMP en la carpeta de registros del clúster en 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 verificaciones de estado.

Verificación previa

Para obtener información sobre el uso de bmctl para ejecutar verificaciones previas, consulta Ejecuta verificaciones previas a pedido para la creación de clústeres y Ejecuta verificaciones previas a demanda para las actualizaciones de clústeres.

Verificación previa de tiempo de ejecución de VM

La solicitud preliminar del entorno de ejecución de VM en GDC valida un conjunto de requisitos previos de la máquina del nodo antes de usar el entorno de ejecución de VM en GDC y las VMs. Si falla la verificación previa del entorno de ejecución de VM en GDC, se bloquea la creación de la VM. Cuando spec.enabled se establece en true en el recurso personalizado VMRuntime, la verificación previa del entorno de ejecución de VM 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 Verificación previa del entorno de ejecución de VM en GDC.

Ejecuta las verificaciones de estado más recientes

Las verificaciones de estado (y las verificaciones previas) se actualizan a medida que se identifican los problemas conocidos. Para indicarle a bmctl que ejecute las verificaciones desde la imagen de 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

Reemplaza CLUSTER_NAME por el nombre del clúster que deseas verificar.

Esto puede ayudarte a detectar cualquier problema conocido identificado recientemente sin actualizar primero tu clúster.

También puedes realizar las verificaciones previas más recientes antes de instalar o actualizar un clúster. Para obtener más información, consulta Ejecuta las verificaciones previas más recientes.

Detección de desvío de la configuración

Cuando se ejecuta la verificación de estado de complementos, entre otras cosas, se verifican los cambios inesperados en los recursos administrados por Google Distributed Cloud. Específicamente, la verificación evalúa los manifiestos de estos recursos para determinar si entidades externas realizaron cambios. Estas verificaciones pueden ayudar a advertir sobre cambios involuntarios que podrían ser perjudiciales para el estado del clúster. También proporcionan información valiosa para solucionar problemas.

Qué manifiestos se verifican

Con algunas excepciones, la verificación de estado de los complementos revisa todos los recursos administrados por Google Distributed Cloud para tus clústeres. Son recursos que instala y administra el software de Google Distributed Cloud. Existen cientos de estos recursos y la mayoría de sus manifiestos se verifican para detectar la desviación de configuración. Los manifiestos son para todo tipo de recursos, incluidos, entre otros, los siguientes:

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

Qué manifiestos no se verifican

Por diseño, excluimos algunos manifiestos de la revisión. Ignoramos ciertos tipos de recursos, como los certificados, los secretos y las cuentas de servicio, por motivos de privacidad y seguridad. La verificación de complementos también ignora algunos recursos y campos de recursos, ya que esperamos que se modifiquen y no queremos que los cambios activen errores de desviación de configuración. Por ejemplo, la verificación ignora los campos replicas en las implementaciones, ya que el escalador automático podría modificar este valor.

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

En general, te recomendamos que no realices cambios en los recursos administrados por Google Distributed Cloud ni ignores los cambios que se realicen en ellos. Sin embargo, sabemos que, a veces, los recursos requieren modificaciones para abordar requisitos de casos únicos o solucionar problemas. Por este motivo, proporcionamos un ConfigMap ignore-config-drift para cada clúster de tu flota. Usas estos ConfigMaps para especificar recursos y campos de recursos específicos que se excluirán de la evaluación.

Google Distributed Cloud crea un ConfigMap ignore-config-drift para cada clúster. Estos ConfigMaps se encuentran en el clúster de administración (híbrido o de administrador) en el espacio de nombres del clúster correspondiente. Por ejemplo, si tienes un clúster de administrador (admin-one) que administra dos clústeres de usuario (user-one y user-two), puedes encontrar el ConfigMap ignore-config-drift para el 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, haz lo siguiente:

  1. Agrega un campo data.ignore-resources al ConfigMap ignore-config-drift.

    Este campo toma un array de cadenas JSON, en el que cada cadena especifica un recurso y, de manera opcional, campos específicos en el recurso.

  2. Especifica el recurso y, de manera opcional, los campos específicos que se deben ignorar como un objeto JSON en el array de cadenas:

    El objeto JSON para 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"
  ]
}

    Reemplaza lo siguiente:

    • RESOURCE_VERSION: (Opcional) Es el valor de apiVersion para el recurso.

    • RESOURCE_KIND: Es el valor de kind para el recurso (opcional).

    • RESOURCE_NAMESPACE: Es el valor de metadata.namespace para el recurso (opcional).

    • RESOURCE_NAME: (Opcional) Es el valor de metadata.name para el recurso.

    • FIELD_NAME: Especifica un array de campos de recursos que se ignorarán (opcional). Si no especificas ningún campo, la verificación de complementos ignorará todos los cambios en el recurso.

    Cada uno de los campos del objeto JSON es opcional, por lo que se permiten diversas permutaciones. Puedes excluir categorías completas de recursos o ser muy preciso y excluir campos específicos de un recurso en particular.

    Por ejemplo, si quieres que la verificación de complementos ignore los cambios solo en la sección command de la Deployment de ais en tu clúster de administrador, el código JSON podría verse de la siguiente manera:

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

    Agregarías este objeto JSON a ignore-resources en el ConfigMap config-drift-ignore como un valor de cadena en un array, 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 parámetro de configuración de ConfigMap de ejemplo te permite agregar, quitar o editar campos de command en la Deployment ais sin activar ningún error de desviación de configuración. Sin embargo, la verificación de complementos sigue detectando las ediciones en los campos fuera de la sección command en la Deployment y las informa como desviación de la configuración.

    Si deseas excluir todas las implementaciones, el valor de ignore-resources podría verse de la siguiente manera:

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

    Dado que ignore-resources acepta un array de cadenas JSON, puedes especificar varios patrones de exclusión. Si estás solucionando problemas o experimentando con tus clústeres y no quieres activar 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 desviación puede ser útil.

¿Qué sigue?

Para obtener más información, consulta lo siguiente:

Si necesitas asistencia adicional, comunícate con Atención al cliente de Cloud. También puedes consultar Cómo 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 compatibles