En esta página, se muestra cómo investigar problemas relacionados con la creación, actualización y cambio de tamaño de clústeres en clústeres de Anthos alojados en VMware (GKE On-Prem).
Comportamiento de registro predeterminado de gkectl y gkeadm
Para gkectl y gkeadm, basta con usar la configuración de registro predeterminada:
Para
gkectl, el archivo de registro predeterminado es/home/ubuntu/.config/gke-on-prem/logs/gkectl-$(date).logy el archivo está vinculado con un symlink con el archivologs/gkectl-$(date).logen el directorio local en el que ejecutasgkectl.Para
gkeadm, el archivo de registro predeterminado eslogs/gkeadm-$(date).logen el directorio local en el que ejecutasgkeadm.El nivel de verbosidad
-v5predeterminado cubre todas las entradas de registro que necesita el equipo de asistencia al cliente.El archivo de registro incluye el comando que se ejecutó y el mensaje de error.
Recomendamos que envíes el archivo de registro al equipo de asistencia al cliente cuando necesites ayuda.
Especifica ubicaciones no predeterminadas para archivos 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 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
Usa govc para resolver 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.
Depura mediante los registros del clúster de arranque
Durante la instalación, los clústeres de Anthos alojados en VMware crean un clúster de arranque temporal. Después de una instalación correcta, los clústeres de Anthos alojados en VMware borran 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.
Si pasas --cleanup-external-cluster=false a gkectl create cluster, el clúster de arranque no se borrará y podrás usar sus registros para depurar problemas de instalación.
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-system
Visualiza los registros de un Pod:
kubectl --kubeconfig /home/ubuntu/.kube/kind-config-gkectl -n kube-system get logs POD_NAME
Depura problemas de BIG-IP de F5 mediante el archivo kubeconfig interno
Después de una instalación, los clústeres de Anthos alojados en VMware generan un archivo kubeconfig en el directorio principal de la estación de trabajo de administrador, llamado internal-cluster-kubeconfig-debug. 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.
El cambio de tamaño de un clúster de usuario falla
Si un cambio de tamaño de un clúster de usuario falla, haz lo siguiente:
Busca los nombres de las MachineDeployments y las máquinas:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get machinedeployments --all-namespaces kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get machines --all-namespaces
Describe una MachineDeployment para ver sus registros:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG describe machinedeployment MACHINE_DEPLOYMENT_NAME
Verifica si hay errores en máquinas recién creadas:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG describe machine MACHINE_NAME
No se pueden asignar direcciones para cambiar el tamaño de un clúster
Este problema ocurre si no hay suficientes direcciones IP disponibles para cambiar el tamaño de un clúster de usuarios.
kubectl describe machine muestra el siguiente error:
Events: Type Reason Age From Message ---- ------ ---- ---- ------- Warning Failed 9s (x13 over 56s) machineipam-controller ipam: no addresses can be allocated
Para resolver este problema, asigna más direcciones IP para el clúster. Luego, borra la máquina afectada:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG delete machine MACHINE_NAME
Los clústeres de Anthos alojados en VMware crean una máquina nueva y le asignan una de las direcciones IP recién disponibles.
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.
La instantánea se crea automáticamente cuando falla la creación o actualización del clúster de administrador
Si intentas crear o actualizar un clúster de administrador y esa operación falla, los clústeres de Anthos alojados en VMware toman una instantánea externa del clúster de arranque, que es un clúster transitorio que se usa para crear o actualizar el clúster de administrador. Aunque 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, en su lugar se activa de forma automática. Esta 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 la Asistencia de Google Cloud, si es necesario.
El proceso de actualización se atasca
Los clústeres de Anthos alojados en VMware, en segundo plano, usan 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.
En ese caso, 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.
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 algunas situaciones:
- Si intentas crear un clúster de usuario y la operación de creación falla, y deseas tener su archivo de kubeconfig en el clúster de usuario.
- Si falta el archivo kubeconfig del clúster de usuario, por ejemplo, después de borrarse.
Ejecuta estos comandos para volver a crear el archivo kubeconfig del clúster de usuario:
KUBECONFIG_SECRET_NAME=$(kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get secrets -n USER_CLUSTER_NAME | grep admin-kubeconfig | cut -d' ' -f1)
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get secrets -n USER_CLUSTER_NAME $KUBECONFIG_SECRET_NAME \
-o jsonpath='{.data.kubeconfig\.conf}' | base64 -d | sed -r "s/kube-apiserver.*local\./USER_CLUSTER_VIP/" > new_user_kubeconfig
Reemplaza lo siguiente:
- USER_CLUSTER_VIP: El valor de la VIP principal del usuario
- USER_CLUSTER_NAME: El nombre del clúster de usuario.
- ADMIN_CLUSTER_KUBECONFIG: La ruta de acceso del archivo kubeconfig del clúster de administrador.