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.
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 relacionados con la instalación de Google Distributed Cloud.
Usa el clúster de arranque para depurar problemas
Durante la instalación, GKE en VMware crea un clúster de arranque temporal. Después de una instalación exitosa, GKE en VMware borra el clúster de arranque, y te deja 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 que te ayuden a depurar el problema.
Si pasas --cleanup-external-cluster=false a gkectl create cluster, el clúster de arranque no se borra y puedes usar el clúster de arranque 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 ver.Para obtener los registros del clúster de arranque directamente, ejecuta el siguiente comando durante la creación, actualización y actualización del clúster:
docker exec -it gkectl-control-plane bashEste comando abre una terminal dentro del contenedor
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 la 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 que se tomó cuando se ejecuta el 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 de depuración importante 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 Pods de onprem-admin-cluster-controller que puedes ver para depurar problemas de creación o actualización de clústeres. 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 del administrador
Si una VM no se inicia después de que se inicia el plano de control de 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. Para comenzar, especifica 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 el archivo de bloques de IP del clúster de modo 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 en el archivo de bloques de IP de Seesaw.
Problemas de actualización del clúster
En las siguientes secciones, se proporcionan sugerencias para resolver problemas que pueden surgir durante una actualización del 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 los grupos de nodos seleccionados es compatible con los grupos de nodos de Ubuntu y COS, pero no con los grupos de nodos de Windows.
La versión de un grupo de nodos puede ser igual o 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.
Consulta las versiones disponibles de los grupos de nodos
Supongamos que hace poco actualizaste los nodos trabajadores y el plano de control del clúster de usuario 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 estabas ejecutando: 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 anterior para 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
Revertir la versión del grupo de nodos
Puedes revertir la versión de un grupo de nodos de a un grupo de nodos a la vez o puedes revertir varios grupos de nodos en un solo paso.
Para revertir una versión del grupo de nodos, completa los siguientes pasos:
En el archivo de configuración del clúster de usuario, en uno o más grupos de nodos, establece 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 del parche
Puedes actualizar todos los grupos de nodos y el plano de control a una versión nueva del parche. Esto podría ser útil si volviste a una versión anterior y quieres actualizarla a una que incluya una solución.
Para actualizar a una nueva versión, 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 versión nueva del parche. En este ejemplo, se usa 1.14.1-gke.x.Para cada grupo de nodos, quita el campo
gkeOnPremVersiono configúralo en la string vacía. Cuando no se especifica ninguna versión para un grupo de nodos, su versión predeterminada es la que se especificó para el clúster.Estos cambios se ven 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 nueva del clúster y consulta las versiones disponibles para revertir:
gkectl version --cluster-name USER_CLUSTER_NAME \ --kubeconfig ADMIN_CLUSTER_KUBECONFIGEl resultado es similar al siguiente:
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 la operación falla, Google Distributed Cloud ejecuta de forma automática 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 con solo una réplica que tiene un PodDisruptionBudget (PDB) creado para él puede bloquear este procedimiento de drain con minAvailable: 1.
A partir de la versión 1.13 de Google Distributed Cloud, puedes verificar fallas a través de los eventos de Pods de Kubernetes.
Encuentra 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 al siguiente:
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 la máquina, ejecuta
gkectl diagnose cluster.El resultado es similar al siguiente:
... 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 una vez que se complete la actualización.
Quita los cambios no admitidos para desbloquear la actualización
Cuando actualizas clústeres a la versión 1.16 o a versiones anteriores, los cambios en la mayoría de los campos se ignoran en silencio durante la actualización, lo que significa que estos cambios no se aplican durante y después de la actualización.
Cuando se actualizan los clústeres de usuario a la versión 1.28 o posteriores, validamos todos los cambios realizados en el archivo de configuración y se muestra un error para los cambios no compatibles, en lugar de solo ignorarlos. Esta función solo está disponible para los clústeres de usuario. Cuando actualizas clústeres de administrador, los cambios en la mayoría de los campos se ignoran de forma silenciosa y no se aplicarán 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, existen las siguientes soluciones:
- Revierte el cambio que intentas hacer 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 mediante la ejecución de
gkectl get-config, actualizar los camposgkeOnPremVersiondel clúster y los grupos de nodos en el archivo de configuración y, luego, volver a ejecutargkectl upgrade.
Depura los problemas de BIG-IP de F5 con el archivo kubeconfig interno
Después de una instalación, GKE en VMware genera un archivo kubeconfig llamado internal-cluster-kubeconfig-debug en el directorio principal de tu 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.
Depura problemas con vSphere
Puedes usar govc para investigar problemas con vSphere. Por ejemplo, puedes confirmar los permisos y el acceso de las cuentas de usuario de vCenter, y puedes recopilar registros de vSphere.
Vuelve a crear el archivo kubeconfig del clúster de usuario faltante
Se recomienda 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 clúster de usuario
kubeconfig. - Si falta el archivo
kubeconfigdel clúster de usuario, por ejemplo, después de borrarlo.
Ejecuta el siguiente comando para volver a crear el archivo kubeconfig del clúster de usuario:
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get secrets -n admin \
-o jsonpath='{.data.admin\.conf}' | base64 -d > USER_CLUSTER_KUBECONFIG
Reemplaza lo siguiente:
USER_CLUSTER_KUBECONFIG: Es el nombre del archivokubeconfignuevo del clúster de usuario.ADMIN_CLUSTER_KUBECONFIG: Es la ruta de acceso del archivokubeconfigdel clúster de administrador.
¿Qué sigue?
- Si necesitas asistencia adicional, comunícate con Atención al cliente de Cloud.