En esta página, se muestra cómo investigar problemas relacionados con la creación y actualización de clústeres en Google Distributed Cloud (solo software) para VMware.
Si necesitas asistencia adicional, comunícate con Atención al cliente de Cloud.Problemas de instalación
Las siguientes secciones pueden ayudarte a solucionar problemas con la instalación de Google Distributed Cloud.
Usa el clúster de arranque para depurar problemas
Durante la instalación, Google Distributed Cloud crea un clúster de arranque temporal. Después de una instalación exitosa, Google Distributed Cloud borra el clúster de arranque, por lo que solo tienes el clúster de administrador y el de usuario. Por lo general, no deberías tener motivos para interactuar con el clúster de arranque. Sin embargo, si tienes problemas durante la instalación, puedes usar los registros del clúster de arranque para depurar el problema.
Si pasas --cleanup-external-cluster=false a gkectl create cluster, el clúster de arranque no se borrará y podrás usarlo para depurar problemas de instalación.
Examina los registros del clúster de arranque
Busca los nombres de Pods que se ejecutan en el espacio de nombres
kube-system:kubectl --kubeconfig /home/ubuntu/.kube/kind-config-gkectl get pods -n kube-systemVisualiza los registros de un Pod:
kubectl --kubeconfig /home/ubuntu/.kube/kind-config-gkectl -n kube-system get logs POD_NAMEReemplaza
POD_NAMEpor el nombre del Pod que deseas visualizar.Para obtener los registros directamente del clúster de arranque, ejecuta el siguiente comando durante la creación, la actualización y el aumento de nivel del clúster:
docker exec -it gkectl-control-plane bashEste comando abre una terminal dentro del contenedor de
gkectl-control-planeque se ejecuta en el clúster de arranque.Para inspeccionar los registros
kubeletycontainerd, usa los siguientes comandos y busca errores o advertencias en el resultado:systemctl status -l kubelet journalctl --utc -u kubelet systemctl status -l containerd journalctl --utc -u containerd
Examina la instantánea del clúster de arranque
Si intentas crear o actualizar un clúster de administrador y esa operación falla, Google Distributed Cloud toma una instantánea externa del clúster de arranque.
Esta instantánea del clúster de arranque es similar a la instantánea tomada mediante la ejecución del comando gkectl diagnose snapshot en el clúster de administrador, pero el proceso se activa automáticamente. La instantánea del clúster de arranque contiene información importante de depuración para el proceso de creación y actualización del clúster de administrador. Puedes
proporcionar esta instantánea a Atención al cliente de Cloud si
es necesario.
La instantánea externa incluye registros de Pod de onprem-admin-cluster-controller que puedes ver para depurar problemas de creación o actualización del clúster. Los registros se almacenan en un archivo separado, por ejemplo:
kubectl_logs_onprem-admin-cluster-controller-6767f6597-nws8g_ \
--container_onprem-admin-cluster-controller_ \
--kubeconfig_.home.ubuntu..kube.kind-config-gkectl_\
--namespace_kube-system
La VM no se inicia después de que se inicia el plano de control de administrador
Si una VM no se inicia después de que comienza el plano de control del administrador, puedes investigar el problema mediante la inspección de los registros del Pod de controladores de la API de clúster en el clúster de administrador.
Busca el nombre del Pod de controladores de la API de clúster:
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG --namespace kube-system \ get pods | grep clusterapi-controllersVer registros de
vsphere-controller-manager. Comienza por especificar el Pod, pero no el contenedor:kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG --namespace kube-system \ logs POD_NAMEEl resultado te indica que debes especificar un contenedor y que proporciona los nombres de los contenedores en el Pod. Por ejemplo:
... a container name must be specified ..., choose one of: [clusterapi-controller-manager vsphere-controller-manager rbac-proxy]
Elige un contenedor y consulta sus registros:
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG --namespace kube-system \ logs POD_NAME --container CONTAINER_NAME
Hay una cantidad suficiente de direcciones IP asignadas, pero la máquina no se registra con el clúster
Este problema puede ocurrir si hay un conflicto de direcciones IP. Por ejemplo, se usa una dirección IP que especificaste para una máquina en un balanceador de cargas.
Para resolver este problema, actualiza tu archivo de bloque de IP del clúster a fin de que las direcciones de la máquina no entren en conflicto con las direcciones especificadas en el archivo de configuración del clúster o con tu archivo de bloque de IP de Seesaw.
No se borra el clúster de Kind
Cuando creas un clúster de administrador, se crea un clúster kind (también llamado clúster de arranque) como parte del proceso. Cuando se completa la operación del clúster de administrador, el clúster de kind se borra automáticamente.
Si ves el mensaje de error Failed to delete the kind cluster, puedes realizar los siguientes pasos en tu estación de trabajo de administrador para borrar manualmente el clúster kind:
Obtén el ID del contenedor
kind:docker inspect --format="{{.Id}}" gkectl-control-planeObtén el ID del proceso
containerd-shim:sudo ps awx | grep containerd-shim | grep CONTAINER_ID | awk '{print $1}'Finaliza el proceso:
sudo kill -9 PROCESS_ID
Problemas de actualización del clúster
En las siguientes secciones, se proporcionan sugerencias para resolver los problemas que podrías encontrar durante una actualización de clúster.
Revierte un grupo de nodos después de una actualización
Si actualizas un clúster de usuario y, luego, descubres un problema con los nodos del clúster, puedes revertir los grupos de nodos seleccionados a la versión anterior.
La reversión de grupos de nodos seleccionados es compatible con los grupos de nodos de Ubuntu y COS, pero no con los de Windows.
La versión de un grupo de nodos puede ser la misma o una versión secundaria anterior a la versión del plano de control del clúster de usuario. Por ejemplo, si el plano de control está en la versión 1.14, los grupos de nodos pueden estar en la versión 1.14 o 1.13.
Visualiza las versiones disponibles del grupo de nodos
Supongamos que recientemente actualizaste el clúster de usuario los nodos trabajadores y el plano de control de la versión 1.13.1-gke.35 a la versión 1.14.0 y descubres un problema con los nodos trabajadores actualizados. Por lo tanto, decides revertir uno o más grupos de nodos a la versión que ejecutabas anteriormente: 1.13.1-gke.35. Antes de comenzar la reversión, debes verificar que la versión anterior esté disponible para la reversión.
Para ver las versiones disponibles, ejecuta el siguiente comando:
gkectl version --cluster-name USER_CLUSTER_NAME \
--kubeconfig ADMIN_CLUSTER_KUBECONFIG
El resultado muestra la versión actual y la versión anterior de cada grupo de nodos. Por ejemplo:
user cluster version: 1.14.0-gke.x
node pools:
- pool-1:
- version: 1.14.0-gke.x
- previous version: 1.13.1-gke.35
- pool-2:
- version: 1.14.0-gke.x
- previous version: 1.13.1-gke.35
available node pool versions:
- 1.13.1-gke.35
- 1.14.0-gke.x
Revierte la versión del grupo de nodos
Puedes revertir la versión de un grupo de nodos a la vez o revertir varios grupos de nodos en un solo paso.
Para revertir una versión de un grupo de nodos, sigue estos pasos:
En el archivo de configuración del clúster de usuario, en uno o más grupos de nodos, configura el valor de
gkeOnPremVersionen la versión anterior. En el siguiente ejemplo, se muestra cómo revertir a la versión 1.13.1-gke.35:nodePools: - name: pool-1 cpus: 4 memoryMB: 8192 replicas: 3 gkeOnPremVersion: 1.13.1-gke.35 ...Actualiza el clúster para revertir los grupos de nodos:
gkectl update cluster --config USER_CLUSTER_CONFIG \ --kubeconfig ADMIN_CLUSTER_KUBECONFIGVerifica que la reversión se haya realizado correctamente:
gkectl version --cluster-name USER_CLUSTER_NAME \ --kubeconfig ADMIN_CLUSTER_KUBECONFIGEn el siguiente resultado, se muestra que
pool-1se revirtió a la versión 1.13.1-gke.35.user cluster version: 1.14.0-gke.x node pools: - pool-1: - version: 1.13.1-gke.35 - previous version: 1.14.0-gke.x - pool-2: - version: 1.14.0-gke.x - previous version: 1.13.1-gke.35 available node pool versions: - 1.13.1-gke.35 - 1.14.0-gke.x
Actualiza a una nueva versión de parche
Puedes actualizar todos los grupos de nodos y el plano de control a una nueva versión de parche. Esto puede ser útil si regresaste a una versión anterior y quieres actualizar a una versión que incluya una solución.
Para actualizar a una versión nueva, completa los siguientes pasos:
Realiza los siguientes cambios en el archivo de configuración del clúster de usuario:
Establece el valor de
gkeOnPremVersionen una nueva versión de parche. En este ejemplo, se usa 1.14.1-gke.x.Para cada grupo de nodos, quita el campo
gkeOnPremVersiono configúralo en la cadena vacía. Cuando no se especifica una versión para un grupo de nodos, la versión predeterminada del grupo de nodos es la versión especificada para el clúster.Estos cambios son similares al siguiente ejemplo:
gkeOnPremVersion: 1.14.1-gke.x nodePools: - name: pool-1 cpus: 4 memoryMB: 8192 replicas: 3 gkeOnPremVersion: "" - name: pool-2 cpus: 8 memoryMB: 8192 replicas: 2 gkeOnPremVersion: ""
Ejecuta
gkectl prepareygkectl upgrade clustercomo se describe en Actualiza Google Distributed Cloud.Verifica la versión del clúster nuevo y consulta las versiones que están disponibles para la reversión:
gkectl version --cluster-name USER_CLUSTER_NAME \ --kubeconfig ADMIN_CLUSTER_KUBECONFIGEl resultado es similar a este:
user cluster version: 1.14.1-gke.y node pools: - pool-1: - version: 1.14.1-gke.y - previous version: 1.13.1-gke.35 - pool-2: - version: 1.14.1-gke.y - previous version: 1.13.1-gke.35 available node pool versions: - 1.13.1-gke.35 - 1.14.0-gke.x - 1.14.1-gke.y ```
Las verificaciones de estado se ejecutan de forma automática cuando falla la actualización del clúster
Si intentas actualizar un clúster de administrador o de usuario, y esa operación falla, Google Distributed Cloud ejecuta automáticamente el comando gkectl diagnose cluster en el clúster.
Para omitir el diagnóstico automático, pasa la marca --skip-diagnose-cluster a gkectl upgrade.
El proceso de actualización se atasca
En segundo plano, Google Distributed Cloud usa el comando drain de Kubernetes durante una actualización. Un Deployment puede bloquear este procedimiento drain con una sola réplica que tenga un PodDisruptionBudget (PDB) creado para él con minAvailable: 1.
A partir de la versión 1.13 de Google Distributed Cloud, puedes verificar las fallas a través de los eventos de Pods de Kubernetes.
Busca los nombres de las máquinas:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get machines --all-namespacesVerifica si hay errores con el comando
kubectl describe machine:kubectl --kubeconfig USER_CLUSTER_KUBECONFIG describe machine MACHINE_NAMEEl resultado es similar a este:
Events: Type Reason Age From Message ---- ------ ---- ---- ------- Warning PodEvictionTooLong 3m49s machine-controller Waiting too long(12m10.284294321s) for pod(default/test-deployment-669b85c4cc-z8pz7) eviction.Opcional: Para obtener un análisis más detallado del estado de los objetos de máquina, ejecuta
gkectl diagnose cluster.El resultado es similar a este:
... Checking machineset...SUCCESS Checking machine objects...FAILURE Reason: 1 machine objects error(s). Unhealthy Resources: Pod test-deployment-669b85c4cc-7zjpq: Pod cannot be evicted successfully. There is 1 related PDB. ... Checking all poddisruptionbudgets...FAILURE Reason: 1 pod disruption budget error(s). Unhealthy Resources: PodDisruptionBudget test-pdb: default/test-pdb might be configured incorrectly, the total replicas(3) should be larger than spec.MinAvailable(3). ... Some validation results were FAILURE or UNKNOWN. Check report above.
Para resolver este problema, guarda el PDB y quítalo del clúster antes de intentar la actualización. Luego, puedes volver a agregar el PDB después de que se complete la actualización.
Quita los cambios no admitidos para desbloquear la actualización
Cuando se actualizan los clústeres a la versión 1.16 o versiones anteriores, los cambios en la mayoría de los campos se ignoran de forma silenciosa durante la actualización, lo que significa que estos cambios no se aplican durante ni después de la actualización.
Cuando actualizamos los clústeres de usuarios a la versión 1.28 o versiones posteriores, validamos todos los cambios que se realizaron en el archivo de configuración y mostramos un error para los cambios no compatibles, en lugar de ignorarlos. Esta función solo es para clústeres de usuarios. Cuando se actualizan los clústeres de administrador, los cambios en la mayoría de los campos se ignoran de forma silenciosa y no surten efecto después de la actualización.
Por ejemplo, si intentas inhabilitar la reparación automática de nodos cuando actualizas un clúster de usuario a la versión 1.28, la actualización falla con el siguiente mensaje de error:
failed to generate desired create config: failed to generate desired OnPremUserCluster from seed config: failed to apply validating webhook to OnPremUserCluster: the following changes on immutable fields are forbidden during upgrade: (diff: -before, +after):
v1alpha1.OnPremUserClusterSpec{
... // 20 identical fields
UsageMetering: nil,
CloudAuditLogging: &{ProjectID: "syllogi-partner-testing", ClusterLocation: "us-central1", ServiceAccountKey: &{KubernetesSecret: &{Name: "user-cluster-creds", KeyName: "cloud-audit-logging-service-account-key"}}},
- AutoRepair: &v1alpha1.AutoRepairConfig{Enabled: true},
+ AutoRepair: &v1alpha1.AutoRepairConfig{},
CARotation: &{Generated: &{CAVersion: 1}},
KSASigningKeyRotation: &{Generated: &{KSASigningKeyVersion: 1}},
... // 8 identical fields
}
Si necesitas omitir este error, puedes usar las siguientes soluciones alternativas:
- Revierte el cambio que intentaste realizar y, luego, vuelve a ejecutar la actualización. Por ejemplo, en la situación anterior, revertirías los cambios realizados en la configuración de
AutoRepairy, luego, volverías a ejecutargkectl upgrade. - Como alternativa, puedes generar archivos de configuración que coincidan con el estado actual del clúster. Para ello, ejecuta
gkectl get-config, actualiza los camposgkeOnPremVersiondel clúster y los grupos de nodos en el archivo de configuración y, luego, vuelve a ejecutargkectl upgrade.
Depura problemas de BIG-IP de F5 con el archivo kubeconfig interno
Después de una instalación, Google Distributed Cloud genera un archivo kubeconfig llamado internal-cluster-kubeconfig-debug en el directorio principal de la estación de trabajo de administrador. Este archivo kubeconfig es idéntico a tu archivo kubeconfig del clúster de administrador, excepto que apunta directamente al nodo del plano de control del clúster de administrador, en el que se ejecuta el servidor de API de Kubernetes. Puedes usar el archivo internal-cluster-kubeconfig-debug para depurar los problemas de BIG-IP de F5.
Cómo depurar problemas con vSphere
Puedes usar govc para investigar problemas con vSphere. Por ejemplo, puedes confirmar los permisos y el acceso de tus cuentas de usuario de vCenter y recopilar registros de vSphere.
Vuelve a crear el archivo kubeconfig del clúster de usuario faltante
Te recomendamos volver a crear un archivo kubeconfig de clúster de usuario en las siguientes situaciones:
- Si intentas crear un clúster de usuario y la operación de creación falla, y deseas tener su archivo de
kubeconfigen el clúster de usuario. - Si falta el archivo
kubeconfigdel clúster de usuario, por ejemplo, después de borrarse.
Para generar un nuevo archivo kubeconfig para tu clúster de usuarios, sigue estos pasos:
Define las variables de entorno:
Comienza por configurar las siguientes variables de entorno con los valores apropiados:
USER_CONTROLPLANEVIP=USER_CONTROLPLANEVIP USER_CLUSTER_NAME=USER_CLUSTER_NAME ADMIN_CLUSTER_KUBECONFIG=PATH_TO_ADMIN_KUBECONFIG KUBECONFIG_SECRET_NAME=$(kubectl --kubeconfig $ADMIN_CLUSTER_KUBECONFIG get secrets -n $USER_CLUSTER_NAME | grep ^admin | cut -d' ' -f1 | head -n 1)Reemplaza lo siguiente:
ADMIN_CLUSTER_KUBECONFIG: La ruta de acceso del archivokubeconfigdel clúster de administrador.USER_CONTROLPLANEVIP: Es elcontrolPlaneVIPdel clúster de usuario. Se puede recuperar desde el archivo de manifiesto del clúster de usuarios.
Genera el archivo kubeconfig:
Ejecuta el siguiente comando para crear el nuevo archivo kubeconfig:
kubectl --kubeconfig $ADMIN_CLUSTER_KUBECONFIG get secrets $KUBECONFIG_SECRET_NAME \ -n $USER_CLUSTER_NAME -o jsonpath='{.data.admin\.conf}' | base64 -d | \ sed -r "s/ kube-apiserver.*local\./${USER_CONTROLPLANEVIP}/" \ > USER_CLUSTER_KUBECONFIGReemplaza lo siguiente:
USER_CLUSTER_KUBECONFIG: Es el nombre del nuevo archivokubeconfigde tu clúster de usuario.
¿Qué sigue?
- Si necesitas asistencia adicional, comunícate con Atención al cliente de Cloud.