Soluciona problemas de creación y actualización de clústeres

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).log y el archivo está vinculado con un symlink con el archivo logs/gkectl-$(date).log en el directorio local en el que ejecutas gkectl.

  • Para gkeadm, el archivo de registro predeterminado es logs/gkeadm-$(date).log en el directorio local en el que ejecutas gkeadm.

  • El nivel de verbosidad -v5 predeterminado 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.

  1. 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-controllers
    
  2. Ver registros de vsphere-controller-manager. Comienza por especificar el Pod, pero no el contenedor:

    kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG --namespace kube-system \
        logs POD_NAME
    

    El 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:

  1. Obtén el ID del contenedor kind:

    docker inspect --format="{{.Id}}" gkectl-control-plane
    
  2. Obtén el ID de proceso containerd-shim:

    sudo ps awx | grep containerd-shim | grep CONTAINER_ID | awk '{print $1}'
    
  3. 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.

  1. 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
    
  2. Visualiza los registros de un Pod:

    kubectl --kubeconfig /home/ubuntu/.kube/kind-config-gkectl -n kube-system get logs POD_NAME
    
  3. 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
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

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
Por ejemplo, el siguiente resultado muestra que 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 gkeOnPremVersion en la nueva versión del parche: 1.14.1-gke.x en este ejemplo.

  • Para cada grupo de nodos, quita el campo gkeOnPremVersion o 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
Resultado de ejemplo:
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:

  1. 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
    
  2. Describe una MachineDeployment para ver sus registros:

    kubectl --kubeconfig USER_CLUSTER_KUBECONFIG describe machinedeployment MACHINE_DEPLOYMENT_NAME
  3. 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.

  1. Busca los nombres de las máquinas:

    kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get machines --all-namespaces
    
  2. 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 AutoRepair y, luego, volverías a ejecutar gkectl 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 campos gkeOnPremVersion para el clúster y los grupos de nodos en el archivo de configuración y, luego, volver a ejecutar gkectl 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.