La herramienta de gkectl tiene dos comandos para solucionar problemas con clústeres: gkectl diagnose cluster y gkectl diagnose snapshot. Los comandos funcionan con clústeres de administrador y de usuario. En este documento, se muestra cómo usar el comando gkectl diagnose para diagnosticar problemas en tus clústeres.
Si quieres obtener más información sobre cómo usar el comando gkectl diagnose snapshot para
crear instantáneas que puedan ayudar a Atención al cliente de Cloud a diagnosticar problemas, consulta
Crea instantáneas para diagnosticar clústeres.
gkectl diagnose cluster
Con este comando, se realizan verificaciones de estado en el clúster y se informan los errores. El comando ejecuta verificaciones de estado en los siguientes componentes:
- vCenter
- Credencial
- DRS
- Grupos antiafinidad
- Red
- Versión
- Centro de datos
- Datastore
- ResourcePool
- Carpeta
- Red
- Balanceador de cargas (F5, Seesaw o manual)
- Clúster de usuario y grupos de nodos
- Objetos de clúster
- Preparación del servidor de Konnectivity del clúster de usuario
- Objetos de máquina y los nodos de clústeres correspondientes
- Pods en los espacios de nombres
kube-systemygke-system - Plano de control
- Volúmenes persistentes de vSphere en el clúster
- Indicadores de CPU virtual del clúster de usuario y administrador y contención de memoria
- Alarmas preconfiguradas de uso de CPU del host y de uso de memoria de ESXi del clúster de usuario y administrador
- Hora del día (TOD)
- Política de red de nodos para un clúster con Dataplane V2 habilitado
- Estado general del agente de nodo de Dataplane V2
Diagnostica un clúster de administrador
Para diagnosticar un clúster de administrador, especifica la ruta al clúster de administrador:
gkectl diagnose cluster --kubeconfig=ADMIN_CLUSTER_KUBECONFIG
Reemplaza ADMIN_CLUSTER_KUBECONFIG por la ruta de acceso del archivo kubeconfig del clúster de administrador.
El comando gkectl diagnose cluster muestra el siguiente resultado de ejemplo:
Preparing for the diagnose tool...
Diagnosing the cluster......DONE
- Validation Category: Admin Cluster Connectivity
Checking VMs TOD (availability)...SUCCESS
Checking Konnectivity Server (readiness)...SUCCESS
- Validation Category: Admin Cluster F5 BIG-IP
Checking f5 (credentials, partition)...SUCCESS
- Validation Category: Admin Cluster VCenter
Checking Credentials...SUCCESS
Checking DRS enabled...SUCCESS
Checking Hosts for AntiAffinityGroups...SUCCESS
Checking Version...SUCCESS
Checking Datacenter...SUCCESS
Checking Datastore...SUCCESS
Checking Resource pool...SUCCESS
Checking Folder...SUCCESS
Checking Network...SUCCESS
- Validation Category: Admin Cluster
Checking cluster object...SUCCESS
Checking machine deployment...SUCCESS
Checking machineset...SUCCESS
Checking machine objects...SUCCESS
Checking kube-system pods...SUCCESS
Checking anthos-identity-service pods...SUCCESS
Checking storage...SUCCESS
Checking resource...SUCCESS
Checking virtual machine resource contention...SUCCESS
Checking host resource contention...SUCCESS
All validation results were SUCCESS.
Cluster is healthy!
Si hay un problema con una dirección IP virtual (VIP) en el clúster de destino, usa la marca --config para proporcionar el archivo de configuración del clúster de administrador a fin de brindar más información de depuración.
gkectl diagnose cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config CLUSTER_CONFIG
Reemplaza CLUSTER_CONFIG por la ruta de acceso del archivo de configuración del clúster de administrador o de usuario.
En el siguiente resultado de ejemplo, se muestra que el comando gkectl diagnose cluster ahora puede conectarse de forma correcta al clúster y verificar si hay problemas:
Failed to access the api server via LB VIP "...": ...
Try to use the admin master IP instead of problematic VIP...
Reading config with version "[CONFIG_VERSION]"
Finding the admin master VM...
Fetching the VMs in the resource pool "[RESOURCE_POOL_NAME]"...
Found the "[ADMIN_MASTER_VM_NAME]" is the admin master VM.
Diagnosing admin|user cluster "[TARGET_CLUSTER_NAME]"...
...
Diagnostica un clúster de usuario
Para diagnosticar un clúster de usuario, debes especificar su nombre. Si necesitas obtener el nombre de un clúster de usuario, ejecuta el siguiente comando:
kubectl get cluster --kubeconfig=USER_CLUSTER_KUBECONFIG
Reemplaza USER_CLUSTER_KUBECONFIG por la ruta de acceso del archivo kubeconfig del clúster de usuario.
Especifica el nombre del clúster de usuario junto con el archivo de configuración de la siguiente manera:
gkectl diagnose cluster --kubeconfig=ADMIN_CLUSTER_KUBECONFIG \
--cluster-name=USER_CLUSTER_NAME
Reemplaza USER_CLUSTER_NAME por el nombre del clúster de usuario.
El comando gkectl diagnose cluster muestra el siguiente resultado de ejemplo:
Preparing for the diagnose tool...
Diagnosing the cluster......DONE
Diagnose result is saved successfully in <DIAGNOSE_REPORT_JSON_FILE>
- Validation Category: User Cluster Connectivity
Checking Node Network Policy...SUCCESS
Checking VMs TOD (availability)...SUCCESS
Checking Dataplane-V2...Success
- Validation Category: User Cluster F5 BIG-IP
Checking f5 (credentials, partition)...SUCCESS
- Validation Category: User Cluster VCenter
Checking Credentials...SUCCESS
Checking DRS enabled...SUCCESS
Checking Hosts for AntiAffinityGroups...SUCCESS
Checking VSphere CSI Driver...SUCCESS
Checking Version...SUCCESS
Checking Datacenter...SUCCESS
Checking Datastore...SUCCESS
Checking Resource pool...SUCCESS
Checking Folder...SUCCESS
Checking Network...SUCCESS
- Validation Category: User Cluster
Checking user cluster and node pools...SUCCESS
Checking cluster object...SUCCESS
Checking machine deployment...SUCCESS
Checking machineset...SUCCESS
Checking machine objects...SUCCESS
Checking control plane pods...SUCCESS
Checking kube-system pods...SUCCESS
Checking gke-system pods...SUCCESS
Checking gke-connect pods...SUCCESS
Checeking anthos-identity-service pods...SUCCESS
Checking storage...SUCCESS
Checking resource...SUCCESS
Checking virtual machine resource contention...SUCCESS
Checking host resource contention...SUCCESS
All validation results were SUCCESS.
Cluster is healthy!
Diagnostica el estado de la máquina virtual
Si surge un problema con la creación de una máquina virtual, ejecuta gkectl diagnose cluster para obtener un diagnóstico del estado de la máquina virtual.
El resultado es similar al siguiente:
- Validation Category: Cluster Healthiness
Checking cluster object...SUCCESS
Checking machine deployment...SUCCESS
Checking machineset...SUCCESS
Checking machine objects...SUCCESS
Checking machine VMs...FAILURE
Reason: 1 machine VMs error(s).
Unhealthy Resources:
Machine [NODE_NAME]: The VM's UUID "420fbe5c-4c8b-705a-8a05-ec636406f60" does not match the machine object's providerID "420fbe5c-4c8b-705a-8a05-ec636406f60e".
Debug Information:
null
...
Exit with error:
Cluster is unhealthy!
Run gkectl diagnose cluster automatically in gkectl diagnose snapshot
Public page https://cloud.google.com/anthos/clusters/docs/on-prem/latest/diagnose#overview_diagnose_snapshot
Solución de problemas
En la siguiente tabla, se describen algunas soluciones posibles para los problemas de ejecución del comando gkectl diagnose cluster:
| Problema | Causas posibles | Solución |
|---|---|---|
| No se puede acceder al servidor de la API de Kubernetes, ya sea para el clúster de administrador o los clústeres de usuario. | Revisa los grafos de latencia de memoria OOB (listo para usar) del estado de la máquina virtual, que idealmente deben tener una latencia de memoria cercana a cero. La contención de memoria también puede aumentar la contención de la CPU, y los gráficos de preparación de la CPU pueden tener un aumento repentino, ya que habrá un intercambio involucrado. | Aumenta la memoria física. A fin de ver otras opciones, consulta las sugerencias para solucionar problemas de VMware. |
| Se agota el tiempo de espera de la creación del grupo de nodos. | Latencia alta de lectura y escritura de VMDK. Verifica el estado de VM de OOB para la latencia de lectura y escritura del disco virtual. Según VMware, una latencia total superior a 20 ms indica un problema. | Consulta soluciones de VMware para problemas de rendimiento del disco. |
BundleUnexpectedDiff error
El recurso de la API de clúster de Kubernetes administrado por un paquete de GKE en VMware puede modificarse de forma accidental, lo que puede causar fallas en los componentes del sistema, o bien actualizar o actualizar el clúster.
En GKE on VMware versión 1.13 y posteriores, onprem-user-cluster-controller verifica de forma periódica el estado de los objetos y, luego, informa cualquier diferencia inesperada del estado deseado a través de registros y eventos. Estos objetos incluyen el plano de control del clúster de usuario y los complementos, como Services y DaemonSets.
En el siguiente resultado de ejemplo, se muestra un evento de diferencia inesperado:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning BundleUnexpectedDiff 13m onpremusercluster/ci-bundle-diff Detected unexpected difference of user control plane objects: [ConfigMap/istio], please check onprem-user-cluster-controller logs for more details.
En el siguiente resultado de ejemplo, se muestran los registros que genera onprem-user-cluster-controller:
2022-08-06T02:54:42.701352295Z W0806 02:54:42.701252 1 update.go:206] Detected unexpected difference of user addon object(ConfigMap/istio), Diff: map[string]string{
2022-08-06T02:54:42.701376406Z - "mesh": (
2022-08-06T02:54:42.701381190Z - """
2022-08-06T02:54:42.701385438Z - defaultConfig:
2022-08-06T02:54:42.701389350Z - discoveryAddress: istiod.gke-system.svc:15012
...
2022-08-06T02:54:42.701449954Z - """
2022-08-06T02:54:42.701453099Z - ),
2022-08-06T02:54:42.701456286Z - "meshNetworks": "networks: {}",
2022-08-06T02:54:42.701459304Z + "test-key": "test-data",
2022-08-06T02:54:42.701462434Z }
Los eventos y registros no bloquearán la operación del clúster. Los objetos que tienen diferencias inesperadas con respecto al estado deseado se reemplazan en la próxima actualización del clúster.