Soluciona problemas

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.

Ejecuta comandos de gkectl de forma detallada

-v5

Registra errores de gkectl en stderr

--alsologtostderr

Ubica los registros de gkectl en la estación de trabajo de administrador

Incluso si no pasas las marcas de depuración, puedes ver los registros de gkectl en el siguiente directorio de la estación de trabajo de administrador:

/home/ubuntu/.config/gke-on-prem/logs

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:

  1. 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

  2. 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]

Complemento de autenticación para Anthos

Falla en la ejecución de gkectl create-login-config

Problema 1:

Síntomas

Cuando ejecutas gkectl create-login-config, se produce el siguiente error:

Error getting clientconfig using [user_cluster_kubeconfig]
Causas posibles

Este error significa que el archivo kubeconfig que se pasó a gkectl create-login-config no es para un clúster de usuario o que la CRD de ClientConfig no apareció durante la creación del clúster.

Solución

Ejecuta el siguiente comando para ver si la CRD de ClientConfig está en el clúster:

$ kubectl --kubeconfig
  [user_cluster_kubeconfig] get clientconfig default -n kube-public

Problema 2:

Síntomas

Cuando ejecutas gkectl create-login-config, se produce el siguiente error:

error merging with file [merge_file] because [merge_file] contains a
  cluster with the same name as the one read from [kubeconfig]. Please write to
  a new output file
Causas posibles

Cada archivo de configuración de acceso debe contener nombres de clúster únicos. Si ves este error, entonces el archivo en el que escribes los datos del archivo de configuración de acceso contiene un nombre de clúster que ya existe en el archivo de destino.

Solución

Escribe en un archivo --output nuevo. Ten en cuenta lo siguiente:

  • Si no se proporciona --output, los datos del archivo de configuración de acceso se escribirán de forma predeterminada en un archivo llamado kubectl-anthos-config.yaml en el directorio actual.
  • Si --output ya existe, el comando intentará combinar el archivo de configuración de acceso nuevo con --output.

Falla en la ejecución de gcloud anthos auth login

Problema 1:

Síntomas

Falla la ejecución de login mediante el complemento de autenticación y el archivo de configuración de acceso en formato YAML que se generó.

Causas posibles

Es posible que haya un error en los detalles de configuración de OIDC.

Solución

Verifica el registro del cliente de OIDC con tu administrador.

Problema 2:

Síntomas

Cuando se configura un proxy para el tráfico HTTPS, la ejecución del comando gcloud anthos auth login falla y se muestra proxyconnect tcp en el mensaje de error. Un ejemplo del tipo de mensaje que puedes ver es proxyconnect tcp: tls: first record does not look like a TLS handshake.

Causas posibles

Es posible que haya un error en las opciones de configuración de las variables de entorno https_proxy o HTTPS_PROXY. Si se especifica https:// en las variables de entorno, las bibliotecas cliente HTTP de GoLang pueden fallar si el proxy está configurado para controlar conexiones HTTPS mediante otros protocolos, como SOCK5.

Solución

Modifica las variables de entorno https_proxy y HTTPS_PROXY para omitir el prefijo https://. En Windows, modifica las variables de entorno del sistema. Por ejemplo, cambia el valor de la variable de entorno https_proxy de https://webproxy.example.com:8000 a webproxy.example.com:8000.

Falla el uso de kubeconfig que generó gcloud anthos auth login para acceder al clúster

Síntomas

Error “No autorizado”

Si hay un error “No autorizado” cuando se usa el kubeconfig que gcloud anthos auth login generó para acceder al clúster, significa que el apiserver no puede autorizar al usuario.

Causas posibles
Faltan los RBAC adecuados, son incorrectos o hay un error en la configuración de OIDC para el clúster.
Solución
Intenta seguir estos pasos para resolver el problema:

  1. Analiza el id-token desde kubeconfig.

    En el archivo kubeconfig que generó el comando de acceso, copia el archivo id-token:

    kind: Config
…
users:
- name: …
  user:
    auth-provider:
      config:
        id-token: [id-token]
        …

    Sigue los pasos para instalar jwt-cli y ejecuta lo siguiente:

    $ jwt [id-token]

  2. Verifica la configuración de OIDC

    En la sección oidc completada en config.yaml, que se usó en la creación del clúster, se encuentran los campos group y username, que se usan para establecer las marcas --oidc-group-claim y --oidc-username-claim en el apiserver. Cuando se presenta el apiserver con el token, buscará esa reclamación de grupo y de nombre de usuario y verificará que el grupo o usuario correspondiente tenga los permisos correctos.

    Verifica que las reclamaciones establecidas para group y user en la sección oidc de config.yaml estén presentes en el id-token.

  3. Verifica los RBAC que se aplicaron.

    Verifica que haya un RBAC con los permisos correctos para el usuario que especifica la reclamación de nombre de usuario o uno de los grupos enumerados en la reclamación de grupo del paso anterior. El nombre del usuario o grupo en el RBAC debe tener el prefijo usernameprefix o groupprefix que se proporcionó en la sección oidc de config.yaml.

    Ten en cuenta que si usernameprefix se dejó en blanco y username es un valor distinto de email, el prefijo será issuerurl# de forma predeterminada. Para inhabilitar los prefijos de nombre de usuario, usernameprefix debe establecerse como - .

    Para obtener más información sobre los prefijos de usuarios y grupos, consulta Propaga la especificación oidc.

    Ten en cuenta que, por el momento, el servidor de la API de Kubernetes trata una barra inversa como un carácter de escape. Por lo tanto, si el nombre del usuario o grupo contiene \\, el servidor de la API lo leerá como una sola \ cuando analice el id_token. Es por eso que el RBAC aplicado a este usuario o grupo debe contener solo una barra inversa o es posible que se produzca un error Unauthorized.

    Ejemplo:

    config.yaml:

    oidc:
    issuerurl:
    …
    username: "unique_name"
    usernameprefix: "-"
    group: "group"
    groupprefix: "oidc:"
    ...

    id_token: 

    {
  ...
  "email": "cluster-developer@example.com",
  "unique_name": "EXAMPLE\\cluster-developer",
  "group": [
    "Domain Users",
    "EXAMPLE\\developers"
],
  ...
}

    Los siguientes RBAC otorgarían a este usuario permisos de administrador de clústeres (ten en cuenta que hay una sola barra en el campo de nombre en lugar de una barra doble):

    Group RBAC:

    apiVersion:
kind:
metadata:
   name: example-binding
subjects:
-  kind: Group
   name: "oidc:EXAMPLE\developers"
   apiGroup: rbac.authorization.k8s.io
   roleRef:
     kind: ClusterRole
     name: pod-reader
     apiGroup: rbac.authorization.k8s.io

    User RBAC:

    apiVersion:
kind:
metadata:
   name: example-binding
subjects:
-  kind: User
               name: "EXAMPLE\cluster-developer"
               apiGroup: rbac.authorization.k8s.io
           roleRef:
           kind: ClusterRole
               name: pod-reader
               apiGroup: rbac.authorization.k8s.io

  4. Verifica los registros del servidor de la API

    Si el complemento de OIDC configurado en kube apiserver no se inicia de forma correcta, el servidor de la API mostrará un error “No autorizado” cuando se presente con el id-token. Para ver si hubo algún problema con el complemento OIDC en el servidor de la API, ejecuta lo siguiente: 

    $ kubectl
      --kubeconfig=[admin_cluster_kubeconfig] logs statefulset/kube-apiserver -n
      [user_cluster_name]
Síntomas

No se pudo establecer una conexión con el servidor: obtén el certificado {DISCOVERY_ENDPOINT}: x509 firmado por una autoridad desconocida

Causas posibles

El token de actualización de kubeconfig caducó.

Solución

Ejecuta el comando login de nuevo.

Acceso a la consola de Google Cloud

Los siguientes son errores comunes que pueden ocurrir cuando usas la consola de Google Cloud para el acceso:

Acceso que redirecciona a la página con el error “No se encuentra la URL”

Síntomas

La consola de Google Cloud no puede acceder al proveedor de identidad de GKE On-Prem.

Causas posibles

La consola de Google Cloud no puede acceder al proveedor de identidad de GKE On-Prem.

Solución

Te sugerimos seguir estos pasos para intentar resolver el problema:

  1. Configura useHTTPProxy en true.

    Si no se puede acceder al IDP a través de la Internet pública, deberás habilitar el proxy HTTP de OIDC para acceder mediante la consola de Google Cloud. En la sección oidc de config.yaml, usehttpproxy debe establecerse en true. Si ya creaste un clúster y quieres activar el proxy, puedes editar la CRD de ClientConfig directamente. Ejecuta $ kubectl edit clientconfig default -n kube-public y cambia useHTTPProxy por true.

  2. useHTTPProxy ya está establecido en true

    Si el proxy HTTP está habilitado y sigue apareciendo este error, es posible que se haya generado un problema mientras se iniciaba el proxy. Para obtener los registros del proxy, ejecuta $ kubectl logs deployment/clientconfig-operator -n kube-system. Ten en cuenta que, incluso si tu IDP tiene una CA conocida, se debe proporcionar el campo capath en la sección oidc de config.yaml para iniciar el proxy HTTP.

  3. Solicitudes de IDP de consentimiento

    Si el servidor de autorización solicita el consentimiento y no incluiste el extraparam prompt=consent, es posible que veas este error. Ejecuta $ kubectl edit clientconfig default -n kube-public, agrega prompt=consent a extraparams e intenta acceder de nuevo.

  4. Los RBAC están mal configurados

    Si aún no lo hiciste, intenta autenticar con el complemento de autenticación para Anthos. Si también ves un error de autorización cuando accedes con el complemento, sigue los pasos para solucionar problemas a fin de resolver el problema del complemento y vuelve a acceder a través de la consola de Google Cloud.

  5. Intenta salir y volver a acceder

    En algunos casos, si se cambia la configuración del servicio de almacenamiento, es posible que debas salir de forma explícita. Ve a la página de detalles del clúster, haz clic en Salir y vuelve a acceder.

Estación de trabajo de administrador

Se muestra el error AccessDeniedException mientras se descarga el OVA

Síntomas

Si intentas descargar el OVA y la firma de la estación de trabajo de administrador, se muestra el siguiente error:

AccessDeniedException: 403 whitelisted-service-account@project.iam.gserviceaccount.com does not have storage.objects.list access to gke-on-prem-release
Causas posibles

Tu cuenta de servicio incluida en la lista de anunciantes permitidos no está activada.

Solución

Asegúrate de haber activado tu cuenta de servicio incluida en la lista de anunciantes permitidos. Si el problema persiste, comunícate con Google para obtener asistencia.

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 mensaje Verified 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.

Storage

No se puede conectar el volumen

Síntomas

El resultado de gkectl diagnose cluster se parece al siguiente ejemplo:

Checking cluster object...PASS
Checking machine objects...PASS
Checking control plane pods...PASS
Checking gke-connect pods...PASS
Checking kube-system pods...PASS
Checking gke-system pods...PASS
Checking storage...FAIL
    PersistentVolume pvc-776459c3-d350-11e9-9db8-e297f465bc84: virtual disk "[datastore_nfs] kubevols/kubernetes-dynamic-pvc-776459c3-d350-11e9-9db8-e297f465bc84.vmdk" IS attached to machine "gsl-test-user-9b46dbf9b-9wdj7" but IS NOT listed in the Node.Status
1 storage errors

Uno o más Pods están atascados en el estado ContainerCreating con una advertencia como la que se muestra a continuación:

Events:
  Type     Reason              Age               From                     Message
  ----     ------              ----              ----                     -------
  Warning  FailedAttachVolume  6s (x6 over 31s)  attachdetach-controller  AttachVolume.Attach failed for volume "pvc-776459c3-d350-11e9-9db8-e297f465bc84" : Failed to add disk 'scsi0:6'.

Causas posibles

Si un disco virtual está conectado a la máquina virtual incorrecta, puede deberse al problema n.º 32727 en Kubernetes 1.12.

Solución

Si un disco virtual está conectado a la máquina virtual incorrecta, es posible que debas desconectarlo de forma manual:

  1. Desvía el nodo. Consulta Safely drain a node (Desvío seguro de un nodo). Te recomendamos incluir las marcas --ignore-daemonsets y --delete-local-data en tu comando kubectl drain.
  2. Apaga la VM.
  3. Edita el archivo de configuración de hardware de la VM en vCenter para quitar el volumen.
  4. Enciende la VM.
  5. Desacordona el nodo.

Se perdió el volumen

Síntomas

El resultado de gkectl diagnose cluster se parece al siguiente ejemplo:

Checking cluster object...PASS
Checking machine objects...PASS
Checking control plane pods...PASS
Checking gke-connect pods...PASS
Checking kube-system pods...PASS
Checking gke-system pods...PASS
Checking storage...FAIL
    PersistentVolume pvc-52161704-d350-11e9-9db8-e297f465bc84: virtual disk "[datastore_nfs] kubevols/kubernetes-dynamic-pvc-52161704-d350-11e9-9db8-e297f465bc84.vmdk" IS NOT found
1 storage errors

Uno o más Pods están atascados en el estado ContainerCreating con una advertencia como la que se muestra a continuación:

Events:
  Type     Reason              Age                   From                                    Message
  ----     ------              ----                  ----                                    -------
  Warning  FailedAttachVolume  71s (x28 over 42m)    attachdetach-controller                 AttachVolume.Attach failed for volume "pvc-52161704-d350-11e9-9db8-e297f465bc84" : File []/vmfs/volumes/43416d29-03095e58/kubevols/
  kubernetes-dynamic-pvc-52161704-d350-11e9-9db8-e297f465bc84.vmdk was not found

Causas posibles

Si ves un error “no encontrado” relacionado con tu archivo VMDK, es probable que el disco virtual se haya borrado de forma permanente. Esto puede suceder si un operador borra de forma manual un disco virtual o la máquina virtual a la que está conectado. Para evitar esto, administra tus máquinas virtuales como se describe en Cambia el tamaño de un clúster de usuario y Actualiza clústeres.

Solución

Si se borró un disco virtual de manera permanente, es posible que tengas que limpiar de forma manual los recursos relacionados de Kubernetes:

  1. Ejecuta kubectl delete pvc [PVC_NAME]. para borrar el PVC que hizo referencia al PV.
  2. Ejecuta kubectl delete pod [POD_NAME]. para borrar el Pod que hizo referencia al PVC.
  3. Repite el paso 2. (Sí, de verdad. Consulta el problema 74374 de Kubernetes).

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 mediante la configuración adecuada de los PodDisruptionBudgets y las reglas de antiafinidad.

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:

  1. Verifica el estado del MachineDeployment del clúster para ver si hay eventos o mensajes de error:

    kubectl describe machinedeployments [MACHINE_DEPLOYMENT_NAME]

  2. 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.

vSphere

Realiza una depuración con govc

Si tienes problemas específicos de vSphere, puedes usar govc para solucionarlos. Por ejemplo, puedes confirmar con facilidad los permisos y el acceso de tus cuentas de usuario de vCenter y recopilar registros de vSphere.

Camba el certificado de vCenter

Si ejecutas vCenter Server en modo de evaluación o de configuración predeterminado y tiene un certificado TLS generado, este certificado puede cambiar con el tiempo. Si cambió, debes informar a tus clústeres en ejecución sobre el certificado nuevo:

  1. Recupera el certificado nuevo de vCenter y guárdalo en un archivo:

    true | openssl s_client -connect [VCENTER_IP_ADDRESS]:443 -showcerts 2>/dev/null | sed -ne '/-BEGIN/,/-END/p' > vcenter.pem

  2. Ahora puedes borrar el ConfigMap que contiene el certificado de vSphere y vCenter de cada clúster y crear un ConfigMap con el certificado nuevo. Por ejemplo:

    kubectl --kubeconfig kubeconfig delete configmap vsphere-ca-certificate -n kube-system
    kubectl --kubeconfig kubeconfig delete configmap vsphere-ca-certificate -n user-cluster1
    kubectl --kubeconfig kubeconfig create configmap -n user-cluster1 --dry-run vsphere-ca-certificate --from-file=ca.crt=vcenter.pem  -o yaml  | kubectl --kubeconfig kubeconfig apply -f -
    kubectl --kubeconfig kubeconfig create configmap -n kube-system --dry-run vsphere-ca-certificate --from-file=ca.crt=vcenter.pem  -o yaml  | kubectl --kubeconfig kubeconfig apply -f -

  3. Borra el Pod clusterapi-controllers de cada clúster. Cuando el Pod se reinicia, comienza a usar el certificado nuevo. Por ejemplo:

    kubectl --kubeconfig kubeconfig -n kube-system get pods
    kubectl --kubeconfig kubeconfig -n kube-system delete pod clusterapi-controllers-...

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 de https://.

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.