En esta página, se muestra cómo investigar problemas con la creación, la actualización y el cambio de tamaño de clústeres en clústeres de Anthos alojados en VMware (GKE en VMware).
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
No se borra el clúster de tipos
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 kind se borra de forma automática.
Si ves el mensaje de error Failed to delete the kind cluster, puedes realizar los siguientes pasos en la estación de trabajo de administrador para borrar el clúster kind de forma manual:
Obtén el ID del contenedor
kind:docker inspect --format="{{.Id}}" gkectl-control-planeObtén el ID de proceso
containerd-shim:sudo ps awx | grep containerd-shim | grep CONTAINER_ID | awk '{print $1}'Cierra el proceso:
sudo kill -9 PROCESS_ID
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 borra y puedes usar los registros del clúster de arranque 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
Para obtener los registros del clúster de arranque directamente, puedes ejecutar el siguiente comando durante la creación, actualización y actualización del clúster:
docker exec -it gkectl-control-plane bash
El comando abre una terminal dentro del contenedor gkectl-control-plane que se ejecuta en el clúster de arranque.
Para inspeccionar los registros de kubelet y containerd, 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
Revierte un grupo de nodos después de una actualización
Si actualizas un clúster de usuario y, luego, descubres un problema con sus nodos, 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 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.
Consulta las versiones disponibles de los grupos de nodos
Supongamos que actualizaste el plano de control y los nodos trabajadores del clúster de usuario de la versión 1.13.1-gke.35 a la 1.14.0 hace poco 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 antes: 1.13.1-gke.35.
Verifica que la versión anterior esté disponible para la reversión:
gkectl version --cluster-name USER_CLUSTER_NAME --kubeconfig ADMIN_CLUSTER_KUBECONFIG
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 grupos de nodos
Puedes revertir un grupo de nodos a la vez o varios en un solo paso.
En el archivo de configuración del clúster de usuario, en uno o más grupos de nodos, establece el valor de gkeOnPremVersion en la versión anterior: 1.13.1-gke.35 en este ejemplo:
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_KUBECONFIG
Verifica que la reversión:
gkectl version --cluster-name USER_CLUSTER_NAME --kubeconfig ADMIN_CLUSTER_KUBECONFIG
pool-1 se 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
Cómo actualizar a una nueva versión del parche
Supongamos que el problema se corrigió en una nueva versión del parche, como la 1.14.1. Ahora puedes actualizar todos los grupos de nodos y el plano de control a la nueva versión del parche.
En el archivo de configuración del clúster de usuario, haz lo siguiente:
Establece el valor de
gkeOnPremVersionen la nueva versión del parche: 1.14.1-gke.x en este ejemplo.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, la versión de este se establece de forma predeterminada en la versión especificada para el clúster.
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 prepare y gkectl upgrade cluster como se describe en Actualiza clústeres de Anthos alojados en VMware.
Verifica la versión nueva del clúster y observa las versiones que ahora están disponibles para la reversión:
gkectl version --cluster-name USER_CLUSTER_NAME --kubeconfig ADMIN_CLUSTER_KUBECONFIG
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
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.
La instantánea externa incluye registros de Pods de onprem-admin-cluster-controller que puedes ver para depurar problemas de creación de clústeres o de actualización. 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
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, los clústeres de Anthos alojados en VMware ejecutan 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
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 los clústeres de Anthos alojados en VMware versión 1.13, puedes verificar las fallas a través de los eventos de Pod de Kubernetes.
Busca los nombres de las máquinas:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get machines --all-namespaces
Verifica si hay errores con el comando
kubectl describe machine:kubectl --kubeconfig USER_CLUSTER_KUBECONFIG describe machine MACHINE_NAME
Este es un resultado de ejemplo:
Events: Type Reason Age From Message ---- ------ ---- ---- ------- Warning PodEvictionTooLong 3m49s machine-controller Waiting too long(12m10.284294321s) for pod(default/test-deployment-669b85c4cc-z8pz7) eviction.
Para obtener un análisis más detallado del estado de los objetos de máquina, ejecuta gkectl diagnose cluster:
...
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.
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.
A continuación, se muestra un resultado de ejemplo:
- 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
Consulta Diagnostica problemas de clústeres para obtener más informació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 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 archivo kubeconfig nuevo para el clúster de usuario.
- ADMIN_CLUSTER_KUBECONFIG: Es la ruta de acceso del archivo kubeconfig del clúster de administrador.
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 ni después de la actualización.
Cuando se actualizan los clústeres de usuario a la versión 1.28 o a versiones posteriores, validamos todos los cambios realizados en el archivo de configuración y mostramos un error para los cambios no compatibles, en lugar de solo ignorarlos. 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 fallará y mostrará 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 alternativas:
- 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 camposgkeOnPremVersionpara el clúster y los grupos de nodos en el archivo de configuración y, luego, volver a ejecutargkectl upgrade.
Se producen errores del comando gkectl cuando se usan los Controles del servicio de VPC.
Si usas los Controles del servicio de VPC, es posible que veas errores cuando ejecutes algunos comandos de gkectl, como "Validation Category: GCP - [UNKNOWN] GCP
service: [Stackdriver] could not get GCP services". Para evitar estos errores, agrega el parámetro --skip-validation-gcp a tus comandos.