En las secciones siguientes, se describen los problemas que puedes encontrar cuando usas GKE On-Prem y cómo resolverlos.
Antes de comenzar
Revisa las siguientes secciones antes de comenzar a solucionar problemas.
Diagnostica problemas de clústeres mediante gkectl
Usa los comandos gkectl diagnose
para identificar los problemas de clústeres y compartir la información de un clúster con Google. Consulta Diagnostica problemas de clústeres.
Comportamiento de registro predeterminado
Para gkectl
y gkeadm
, basta con usar la configuración de registro predeterminada:
-
De forma predeterminada, las entradas de registro se guardan de la siguiente manera:
-
Para
gkectl
, el archivo de registro predeterminado es/home/ubuntu/.config/gke-on-prem/logs/gkectl-$(date).log
y el archivo está vinculado con un symlink con el archivologs/gkectl-$(date).log
en el directorio local en el que ejecutasgkectl
. -
Para
gkeadm
, el archivo de registro predeterminado eslogs/gkeadm-$(date).log
en el directorio local en el que ejecutasgkeadm
.
-
Para
- Todas las entradas de registro se guardan en el archivo de registro, incluso si no se imprimen en la terminal (cuando
--alsologtostderr
esfalse
). - El nivel de verbosidad
-v5
(predeterminado) cubre todas las entradas de registro que necesita el equipo de asistencia al cliente. - El archivo de registro también contiene el comando ejecutado y el mensaje de error.
Recomendamos que envíes el archivo de registro al equipo de asistencia al cliente cuando necesites ayuda.
Especifica una ubicación no predeterminada para el archivo de registro
A fin de especificar una ubicación no predeterminada para el archivo de registro gkectl
, usa la marca --log_file
. El archivo de registro que especifiques no se vinculará con un symlink con el directorio local.
A fin de especificar una ubicación no predeterminada para el archivo de registro gkeadm
, usa la marca --log_file
.
Ubica los registros de la API de clúster en el clúster de administrador
Si una VM no se inicia después de que se inicia el plano de control de administrador, puedes intentar depurarla mediante la inspección de los registros de los controladores de la API de clúster en el clúster de administrador:
Encuentra el nombre del Pod de controladores de la API de clúster en el espacio de nombres
kube-system
, en el que [ADMIN_CLUSTER_KUBECONFIG] es la ruta de acceso al archivo kubeconfig del clúster de administrador:kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] -n kube-system get pods | grep clusterapi-controllers
Abre los registros del Pod, en los que [POD_NAME] es el nombre del Pod. De manera opcional, usa
grep
o una herramienta similar para buscar errores:kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] -n kube-system logs [POD_NAME] vsphere-controller-manager
Instalación
Depura los problemas de BIG-IP de F5 mediante el kubeconfig del nodo del plano de control del clúster de administrador
Después de una instalación, GKE On-Prem 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 al kubeconfig de tu 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 plano de control de administrador. Puedes usar el archivo internal-cluster-kubeconfig-debug
para depurar los problemas de BIG-IP de F5.
La validación de gkectl check-config
falla: No se pueden encontrar las particiones de BIG-IP de F5
- Síntomas
La validación falla porque las particiones de BIG-IP de F5 no se pueden encontrar, aunque existen.
- Causas posibles
Un problema con la API de BIG-IP de F5 puede causar que la validación falle.
- Solución
Vuelve a ejecutar
gkectl check-config
.
gkectl prepare --validate-attestations
falla: No se puede validar la certificación de la compilación
- Síntomas
La ejecución de
gkectl prepare
con la marca opcional--validate-attestations
muestra el siguiente error:could not validate build attestation for gcr.io/gke-on-prem-release/.../...: VIOLATES_POLICY
- Causas posibles
Es posible que no exista una certificación para las imágenes afectadas.
- Solución
Vuelve a descargar y a implementar el OVA de la estación de trabajo de administrador, como se indica en Crea una estación de trabajo de administrador. Si el problema persiste, comunícate con Google para obtener asistencia.
Depura mediante los registros del clúster de arranque
Durante la instalación, GKE On-Prem crea un clúster de arranque temporal. Después de una instalación exitosa, GKE On-Prem 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 ningún motivo para interactuar con este clúster.
Si algo sale mal durante una instalación y pasaste --cleanup-external-cluster=false
a gkectl create cluster
, es posible que te resulte útil depurar mediante los registros del clúster de arranque. Puedes buscar el pod y, luego, obtener sus registros:
kubectl --kubeconfig /home/ubuntu/.kube/kind-config-gkectl get pods -n kube-system
kubectl --kubeconfig /home/ubuntu/.kube/kind-config-gkectl -n kube-system get logs [POD_NAME]
Estación de trabajo de administrador
openssl
no puede validar el OVA de la estación de trabajo de administrador
- Síntomas
Si ejecutas
openssl dgst
en el archivo OVA de la estación de trabajo de administrador, no se muestra el mensajeVerified OK
.- Causas posibles
Hay un problema en el archivo OVA que impide que la validación se realice con éxito.
- Solución
Vuelve a descargar y a implementar el OVA de la estación de trabajo de administrador, como se indica en Descarga el OVA de la estación de trabajo de administrador. Si el problema persiste, comunícate con Google para obtener asistencia.
Connect
No se puede registrar un clúster de usuario
Si tienes problemas para registrar los clústeres de usuario, comunícate con Google a fin de obtener asistencia.
El registro del clúster que se creó durante la etapa Alfa se anuló
Consulta Registra un clúster de usuario en la documentación de Connect.
También puedes elegir borrar y volver a crear el clúster.
Actualizaciones
Información sobre el tiempo de inactividad durante las actualizaciones
Recurso | Descripción |
---|---|
Clúster de administrador | Cuando un clúster de administrador está inactivo, los planos de control y las cargas de trabajo en los clústeres de usuario continúan ejecutándose, a menos que se vean afectados por una falla que causó el tiempo de inactividad. |
Plano de control del clúster de usuario | Por lo general, no es probable que se produzcan tiempos de inactividad perceptibles en los planos de control del clúster de usuario. Sin embargo, las conexiones de larga duración al servidor de la API de Kubernetes podrían fallar y tendrían que restablecerse. En esos casos, el emisor de la API debe volver a intentarlo hasta que se establezca una conexión. En el peor de los casos, puede haber hasta un minuto de tiempo de inactividad durante una actualización. |
Nodos del clúster de usuario | Si una actualización requiere un cambio en los nodos del clúster de usuario, GKE On-Prem los vuelve a crear de forma progresiva y reprograma los Pods que se ejecutan en estos nodos. Puedes evitar el impacto en tus cargas de trabajo; para ello, configura PodDisruptionBudgets y reglas de antiafinidad adecuados. |
Cambia el tamaño de los clústeres de usuario
El cambio de tamaño de un clúster de usuario falla
- Síntomas
Una operación de cambio de tamaño en un clúster de usuario falla.
- Causas posibles
Varios factores pueden hacer que las operaciones de cambio de tamaño fallen.
- Solución
Si falla el cambio de tamaño, sigue estos pasos:
Verifica el estado del MachineDeployment del clúster para ver si hay eventos o mensajes de error:
kubectl describe machinedeployments [MACHINE_DEPLOYMENT_NAME]
Verifica si hay errores en las máquinas recién creadas:
kubectl describe machine [MACHINE_NAME]
Error: “No se pueden asignar direcciones”
- Síntomas
Después de cambiar el tamaño de un clúster de usuario,
kubectl describe machine [MACHINE_NAME]
muestra el siguiente error:Events: Type Reason Age From Message ---- ------ ---- ---- ------- Warning Failed 9s (x13 over 56s) machineipam-controller ipam: no addresses can be allocated
- Causas posibles
No hay suficientes direcciones IP disponibles para el clúster de usuario.
- Solución
Asigna más direcciones IP al clúster. Luego, borra la máquina afectada:
kubectl delete machine [MACHINE_NAME]
Si el clúster se configura de forma correcta, se creará una máquina de reemplazo con una dirección IP.
Hay una cantidad suficiente de direcciones IP asignadas, pero la máquina no se registra con el clúster
- Síntomas
La red tiene suficientes direcciones asignadas, pero la máquina aún no se logra registrar con el clúster de usuario.
- Causas posibles
Puede haber un conflicto de IP. Es posible que otra máquina o tu balanceador de cargas tome la IP.
- Solución
Verifica que no se haya tomado la dirección IP de la máquina afectada. Si hay un conflicto, debes resolverlo en tu entorno.
Varios
Límite de sesiones del proveedor de vSphere de Terraform
GKE On-Prem usa el proveedor de vSphere de Terraform para abrir las VM en tu entorno de vSphere. El límite de sesiones del proveedor es de 1,000 sesiones. La implementación actual no cierra las sesiones activas después de su uso. Es posible que experimentes errores 503 si tienes demasiadas sesiones en ejecución.
Las sesiones se cierran de forma automática después de 300 segundos.
- Síntomas
Si tienes demasiadas sesiones en ejecución, es posible que encuentres el siguiente error:
Error connecting to CIS REST endpoint: Login failed: body: {"type":"com.vmware.vapi.std.errors.service_unavailable","value": {"messages":[{"args":["1000","1000"],"default_message":"Sessions count is limited to 1000. Existing sessions are 1000.", "id":"com.vmware.vapi.endpoint.failedToLoginMaxSessionCountReached"}]}}, status: 503 Service Unavailable
- Causas posibles
Hay demasiadas sesiones de proveedor de Terraform en ejecución en el entorno.
- Solución
Por el momento, esto funciona según lo previsto. Las sesiones se cierran de forma automática después de 300 segundos. Para obtener más información, consulta el problema n.º 618 de GitHub.
Usa un proxy para Docker: oauth2: cannot fetch token
- Síntomas
Mientras uses un proxy, verás el siguiente error:
oauth2: cannot fetch token: Post https://oauth2.googleapis.com/token: proxyconnect tcp: tls: oversized record received with length 20527
- Causas posibles
Es posible que hayas proporcionado un proxy HTTPS en lugar de HTTP.
- Solución
En tu configuración de Docker, cambia la dirección del proxy por
http://
en lugar dehttps://
.
Verifica que las licencias sean válidas
Recuerda verificar que tus licencias sean válidas, en especial si usas licencias de prueba. Es posible que encuentres fallas inesperadas si tus licencias de F5, host de ESXi o vCenter vencieron.