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 on demand. 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 nodos
Verificaciones en todo el clúster
En las siguientes secciones, se describe lo que se verifica para cada categoría. Estas verificaciones se usan para las verificaciones de estado periódicas y a pedido.
Verificaciones de la máquina de nodos
En esta sección, se describe lo que se evalúa en las verificaciones de estado de las máquinas de nodos. Estas verificaciones confirman que las máquinas de nodos están configuradas correctamente y que tienen recursos y conectividad suficientes para la creación, las actualizaciones y el funcionamiento del clúster.
Estas verificaciones corresponden a los recursos personalizados de HealthCheck de Bare Metal con el nombre 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 Recursos personalizados de HealthCheck.
Las verificaciones de máquinas comunes consisten en 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 de kernel compatible.
El kernel tiene habilitada la opción del compilador BPF Just In Time (JIT) (
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 se configura 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) es funcional (se omite esta verificación 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 esta.
Las verificaciones de Google Cloud de máquinas consisten en lo siguiente:
Se puede acceder a Container Registry,
gcr.io(se omite esta verificación si el clúster está configurado para usar un espejo de registro).Se puede acceder a las APIs de Google.
Las verificaciones de estado de la máquina consisten en lo siguiente:
kubeletestá activo y se ejecuta en máquinas de nodos.containerdestá activo y se ejecuta en máquinas de nodos.El estado del extremo de estado de la interfaz de red de contenedor (CNI) es bueno.
Los CIDRs de los Pods no se superponen con las direcciones IP de las máquinas de los nodos.
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 de red
Las siguientes verificaciones de red del nodo 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 a pedido. Estas verificaciones corresponden a los recursos personalizados HealthCheck de Bare Metal con el nombre 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 con el protocolo de resolución de direcciones (ARP) de capa 2. El ARP es obligatorio 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 de Google Distributed Cloud, 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 HealthCheck de Bare Metal, denominados recursos 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 Recursos personalizados de HealthCheck.
El servidor de la API está funcionando.
El operador
anetdestá configurado correctamente.Todos los nodos del plano de control son operativos.
Los siguientes componentes del plano de control funcionan correctamente:
anthos-cluster-operatorcontroller-managercluster-api-provideraiscapi-kubeadm-bootstrap-systemcert-managerkube-dns
Complementos
Las verificaciones de complementos se ejecutan automáticamente como parte de las verificaciones previas y las verificaciones de estado periódicas, y se pueden ejecutar a pedido. Esta verificación de estado no muestra un error si falta alguno de los complementos enumerados. La verificación solo muestra errores si los complementos existen y tienen errores en el momento de la ejecución del comando.
Estas verificaciones corresponden a recursos personalizados HealthCheck de Bare Metal con el nombre 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 Recursos personalizados de HealthCheck.
Los componentes de Stackdriver de Cloud Logging y el agente de Connect son operativos:
stackdriver-log-aggregatorstackdriver-log-forwarderstackdriver-metadata-agentstackdriver-prometheus-k8gke-connect-agent
Los recursos administrados por Google Distributed Cloud no muestran cambios manuales (retraso de configuración):
Los valores de los campos no se actualizaron
No se agregaron ni quitaron campos opcionales
Los recursos no se borraron
Si la verificación de estado detecta una deriva de configuración, el valor Status.Pass del recurso personalizado HealthCheck de Bare Metal bm-system-add-ons 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 del recurso.Kind: Es el esquema de objetos, comoDeployment, 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 de 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
HealthCheckde 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 recursosHealthCheckde Bare Metal son responsables de crear trabajos y trabajos de cron de verificación de estado. Estos recursos se actualizan constantemente con los resultados más recientes.Recursos personalizados
HealthCheckde Anthos (API Version: anthos.gke.io/v1): Estos recursos se usan para informar métricas de verificación de estado. Estos recursos se encuentran en el espacio de nombreskube-systemde cada clúster. Las actualizaciones de estos recursos se realizan según 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 GKE Enterprise | Gravedad |
|---|---|---|
|
Tipo: máquina
Nombre: |
Tipo: máquina
Nombre: |
Crítico |
|
Tipo: red
Nombre: |
Tipo: red
Nombre: |
Crítico |
|
Tipo: kubernetes
Nombre: |
Tipo: kubernetes
Nombre: |
Crítico |
|
Tipo: complementos
Nombre: |
Tipo: complementos
Nombre:
Nombre: |
Opcional |
Para recuperar el estado de HealthCheck, haz lo siguiente:
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-namespacesReemplaza
ADMIN_KUBECONFIGpor 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 las verificaciones se aprobaron la última vez que se ejecutaron:
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 56dPara 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_NAMESPACEReemplaza lo siguiente:
HEALTHCHECK_NAME: el nombre de la verificación de estado.ADMIN_KUBECONFIG: la ruta del archivo kubeconfig del clúster de administradorCLUSTER_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 aplicó instrumentación a un trabajo de verificación de estado.
El siguiente ejemplo de
HealthCheckes para una verificación de máquina correcta: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 finishedEl siguiente ejemplo de
HealthCheckes para una verificación de máquina que falló: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 ...Para obtener una lista de verificaciones de estado de las métricas, usa el siguiente comando:
kubectl get healthchecks.anthos.gke.io --kubeconfig CLUSTER_KUBECONFIG --namespace kube-systemReemplaza
CLUSTER_KUBECONFIGpor 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-10.200.0.3-machine Healthy 56m kube-system bm-system-add-ons-add-ons Healthy 48m kube-system bm-system-add-ons-configdrift Healthy 48m kube-system bm-system-kubernetes Healthy 57m kube-system bm-system-kubernetes-1.16.1-non-periodic Healthy 25d kube-system bm-system-network Healthy 32m kube-system check-kubernetes-20231114-190445-non-periodic Healthy 3h6m 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 la verificación de estado
Para las verificaciones de estado periódicas, cada recurso personalizado HealthCheck de bare metal 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. CronJob también incluye un contenedor ansible-runner que ejecuta la verificación de estado estableciendo una conexión de shell segura (SSH) a los nodos.
Para recuperar información sobre los trabajos cron, sigue estos pasos:
Obtén una lista de los trabajos cron que se ejecutaron para un clúster determinado:
kubectl get cronjobs --kubeconfig ADMIN_KUBECONFIG --namespace CLUSTER_NAMESPACEReemplaza lo siguiente:
ADMIN_KUBECONFIG: la ruta del archivo kubeconfig del clúster de administradorCLUSTER_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 25dLos valores de la columna
SCHEDULEindican el programa de cada trabajo de verificación de estado que se ejecuta en la sintaxis de programación. Por ejemplo, la tareabm-system-kubernetesse ejecuta a los 17 minutos después de la hora (17) cada hora (*/1) de todos los días (* * *). 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 deben ejecutar.Recupera los detalles de un recurso personalizado
CronJobespecífico:kubectl describe cronjob CRONJOB_NAME --kubeconfig ADMIN_KUBECONFIG --namespace CLUSTER_NAMESPACEReemplaza lo siguiente:
ADMIN_KUBECONFIG: la ruta del archivo kubeconfig del clúster de administradorCLUSTER_NAMESPACE: el espacio de nombres del clúster.
En el siguiente ejemplo, se muestra un
CronJobcorrecto: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 la verificación de estado
Cuando se ejecutan las verificaciones de estado, se generan registros. Ya sea que ejecutes verificaciones de estado con bmctl o se ejecuten automáticamente como parte de verificaciones de estado periódicas, los registros se envían a Cloud Logging. Cuando ejecutas verificaciones de estado a pedido, los archivos de registro se crean en una carpeta con marca de tiempo 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:
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_NAMESPACEReemplaza lo siguiente:
ADMIN_KUBECONFIG: la ruta del archivo kubeconfig del clúster de administradorCLUSTER_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 77mRecupera los registros del Pod:
kubectl logs POD_NAME --kubeconfig ADMIN_KUBECONFIG --namespace CLUSTER_NAMESPACEReemplaza 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 administradorCLUSTER_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ó. El ejemplo muestra que la verificación de
kubelet(check_kubelet_pass) falló, lo que indica quekubeletno se ejecuta 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.
En la consola de Google Cloud, ve a la página Explorador de registros en el menú de Logging.
En el campo Consulta, ingresa la siguiente consulta básica:
resource.type="k8s_container" resource.labels.pod_name=~"bm-system.*-machine.*"En la ventana Resultados de la consulta, se muestran los registros de las verificaciones de estado de la máquina del nodo.
Esta es una lista de consultas para verificaciones de estado periódicas:
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:
Para verificar 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 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 máquinas para cada nodo del clúster de destino, por lo que hay un recurso para cada nodo.
Para enumerar los recursos
HealthCheckde Bare Metal de un clúster determinado, ejecuta el siguiente comando:kubectl get healthchecks.baremetal.cluster.gke.io --kubeconfig=ADMIN_KUBECONFIG \ --namespace=CLUSTER_NAMESPACEReemplaza lo siguiente:
ADMIN_KUBECONFIG: la ruta del archivo kubeconfig del clúster de administradorCLUSTER_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 56dEl campo
Passparahealthchecks.baremetal.cluster.gke.ioindica si la última verificación de estado se aprobó (true) o no (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 verificación 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. Para inhabilitar las verificaciones de estado periódicas de un clúster, establece el campo periodicHealthCheck.enable en false en el recurso del clúster.
Para inhabilitar las verificaciones de estado periódicas, haz lo siguiente:
Edita el archivo de configuración del clúster y agrega el campo
periodicHealthCheck.enablea la especificación del clúster y establece su valor enfalse: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 ...Ejecuta el comando
bmctl updatepara actualizar el clúster:bmctl update cluster -c CLUSTER_NAME --kubeconfig=ADMIN_KUBECONFIGReemplaza 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
Para verificar que se inhabilitaron las verificaciones de estado periódicas, ejecuta el siguiente comando para confirmar que se borraron los recursos
healthchecks.baremetal.cluster.gke.iocorrespondientes:kubectl get healthchecks.baremetal.cluster.gke.io --kubeconfig=ADMIN_KUBECONFIG \ --namespace=CLUSTER_NAMESPACEReemplaza lo siguiente:
ADMIN_KUBECONFIG: la ruta del archivo kubeconfig del clúster de administradorCLUSTER_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 como true en el recurso del clúster.
Para volver a habilitar las verificaciones de estado periódicas, haz lo siguiente:
Edita el archivo de configuración del clúster y agrega el campo
periodicHealthCheck.enablea la especificación del clúster y establece su valor entrue: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 ...Ejecuta el comando
bmctl updatepara actualizar el clúster:bmctl update cluster -c CLUSTER_NAME --kubeconfig=ADMIN_KUBECONFIGReemplaza 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
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.iocorrespondiente estén presentes:kubectl get healthchecks.baremetal.cluster.gke.io --kubeconfig=ADMIN_KUBECONFIG \ --namespace=CLUSTER_NAMESPACEReemplaza lo siguiente:
ADMIN_KUBECONFIG: la ruta del archivo kubeconfig del clúster de administradorCLUSTER_NAMESPACE: Es el espacio de nombres del clúster de destino de la verificación de estado.
Los recursos pueden tardar unos minutos en aparecer.
Verificaciones de estado on demand
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 del clúster de administrador con la marca--kubeconfig.Los registros se generan en un directorio con marca de tiempo en la carpeta de registro del clúster en tu estación de trabajo de administrador (
bmctl-workspace/CLUSTER_NAME/logde forma predeterminada).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 la verificación de estado.
Para obtener más información sobre otras opciones de los comandos bmctl, consulta la referencia de comandos de bmctl.
Complementos
Verifica que los complementos de Kubernetes especificados para el clúster especificado sean operativos.
Para verificar los complementos de un clúster, haz lo siguiente:
bmctl check add-ons --cluster CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIGReemplaza 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 marca, consulta Complementos en la sección Qué se marca de este documento.
Esta verificación genera archivos de registro en un directorio check-addons-TIMESTAMP en 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 la 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_KUBECONFIGReemplaza 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 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 la verificación de estado.
Configuración
Verifica el archivo de configuración del clúster. Esta verificación supone que generaste el archivo de configuración y lo editaste para especificar los detalles de configuración de tu 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 de clúster, haz lo siguiente:
bmctl check config --cluster CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIGReemplaza 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 a Google Cloud y los permisos de la cuenta de servicio especificada en el archivo de configuración del clúster.
Esta verificación genera archivos de registro en un directorio check-config-TIMESTAMP en 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 la verificación de estado.
Conectividad a Google Cloud
Verifica que todas las máquinas de nodos del clúster puedan acceder a Container Registry (gcr.io) y al extremo de las APIs de Google (googleapis.com).
Para verificar el acceso del clúster a los recursos de Google Cloud necesarios, haz lo siguiente:
bmctl check gcp --cluster CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIGReemplaza 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 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 la verificación de estado.
Kubernetes
Verifica el estado de los operadores de Kubernetes críticos que se ejecutan en el plano de control. Esta verificación verifica que los operadores críticos funcionen correctamente y que sus pods no fallen. 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_KUBECONFIGReemplaza 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 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 la verificación de estado.
Nodos
Verifica las máquinas de los nodos del clúster para confirmar que estén configuradas correctamente y que tengan recursos y conectividad suficientes 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_KUBECONFIGReemplaza 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 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 máquinas de nodos 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 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 la verificación 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 verificación preiva del entorno de ejecución de VM en Google Distributed Cloud valida un conjunto de requisitos previos de la máquina del nodo antes de usar el entorno de ejecución de VM en Google Distributed Cloud y las VMs. Si falla la verificación preiva del entorno de ejecución de VM en Google Distributed Cloud, se bloquea la creación de VMs. Cuando spec.enabled se establece en true en el recurso personalizado VMRuntime, la verificación preiva del entorno de ejecución de VM en Google Distributed Cloud 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 preiva del entorno de ejecución de VM en Google Distributed Cloud.
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 dirigir a bmctl a 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.