Problemas conocidos de GKE en VMware

En esta página, se enumeran todos los problemas conocidos de GKE en VMware. Para filtrar los problemas conocidos por versión o categoría del producto, selecciona los filtros que desees en los siguientes menús desplegables.

Selecciona la versión de GKE en VMware:

Selecciona la categoría del problema:

O bien, busca tu problema:

Categoría Versiones identificadas Problema y solución alternativa
update 1.15, 1.16, 1.28

Las dependencias de trident de Netapp interfieren en el controlador de CSI de vSphere

La instalación de multipathd en los nodos del clúster interfiere en el controlador de CSI de vSphere, lo que hace que las cargas de trabajo del usuario no se puedan iniciar.

Solución alternativa:

  • Inhabilitar multipathd
Actualizaciones 1.15, 1.16

Es posible que el webhook del clúster de administrador bloquee las actualizaciones cuando agregues los parámetros de configuración necesarios.

Si algunos parámetros de configuración necesarios están vacíos en el clúster de administrador porque se omitieron las validaciones, es posible que el webhook del clúster de administrador bloquee la adición de ellas. Por ejemplo, si el campo gkeConnect no se configuró en un clúster de administrador existente, agregarlo con el comando gkectl update admin puede recibir el siguiente mensaje de error:


admission webhook "vonpremadmincluster.onprem.cluster.gke.io" denied the request: connect: Required value: GKE connect is required for user clusters

Solución alternativa:

  • Para los clústeres de administrador 1.15, ejecuta el comando gkectl update admin con la marca --disable-admin-cluster-webhook. Por ejemplo: 
    
        gkectl update admin --config ADMIN_CLUSTER_CONFIG_FILE --kubeconfig ADMIN_CLUSTER_KUBECONFIG --disable-admin-cluster-webhook
  • Para los clústeres de administrador 1.16, ejecuta los comandos de gkectl update admin con la marca --force. Por ejemplo: 
    
        gkectl update admin --config ADMIN_CLUSTER_CONFIG_FILE --kubeconfig ADMIN_CLUSTER_KUBECONFIG --force
Configuración 1.15.0-1.15.10, 1.16.0-1.16.6, 1.28.0-1.28.200

El campo controlPlaneNodePort se establece de forma predeterminada en 30968 cuando la especificación de manualLB está vacía

Si usarás un balanceador de cargas manual (loadBalancer.kind está configurado como "ManualLB"), no deberías necesitar configurar la sección loadBalancer.manualLB en el archivo de configuración para un clúster de administrador de alta disponibilidad (HA) en las versiones 1.16 y posteriores. Sin embargo, cuando esta sección está vacía, GKE on VMware asigna valores predeterminados a todos los NodePorts, incluido manualLB.controlPlaneNodePort, lo que hace que la creación del clúster falle con el siguiente mensaje de error:


- Validation Category: Manual LB
  - [FAILURE] NodePort configuration: manualLB.controlPlaneNodePort must
   not be set when using HA admin cluster, got: 30968

Solución alternativa:

Especifica manualLB.controlPlaneNodePort: 0 en la configuración del clúster de administrador para el clúster de administrador con alta disponibilidad:


loadBalancer:
  ...
  kind: ManualLB
  manualLB:
    controlPlaneNodePort: 0
  ...
Almacenamiento 1.28.0-1.28.100

Falta nfs-common en la imagen de SO Ubuntu

Falta nfs-common en la imagen de SO Ubuntu, lo que puede causar problemas para los clientes que usan controladores que dependen de NFS, como NetApp.

Si el registro contiene una entrada como la siguiente después de actualizar a la versión 1.28, este problema te afectará: 

Warning FailedMount 63s (x8 over 2m28s) kubelet MountVolume.SetUp failed for volume "pvc-xxx-yyy-zzz" : rpc error: code = Internal desc = error mounting NFS volume 10.0.0.2:/trident_pvc_xxx-yyy-zzz on mountpoint /var/lib/kubelet/pods/aaa-bbb-ccc/volumes/kubernetes.io~csi/pvc-xxx-yyy-zzz/mount: exit status 32".

Solución alternativa:

Asegúrate de que tus nodos puedan descargar paquetes de Canonical.

Luego, aplica el siguiente DaemonSet a tu clúster para instalar nfs-common:


apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: install-nfs-common
  labels:
    name: install-nfs-common
  namespace: kube-system
spec:
  selector:
    matchLabels:
      name: install-nfs-common
  minReadySeconds: 0
  updateStrategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 100%
  template:
    metadata:
      labels:
        name: install-nfs-common
    spec:
      hostPID: true
      hostIPC: true
      hostNetwork: true
      initContainers:
      - name: install-nfs-common
        image: ubuntu
        imagePullPolicy: IfNotPresent
        securityContext:
          privileged: true
        command:
        - chroot
        - /host
        - bash
        - -c
        args:
        - |
          apt install -y nfs-common
        volumeMounts:
        - name: host
          mountPath: /host
      containers:
      - name: pause
        image: gcr.io/gke-on-prem-release/pause-amd64:3.1-gke.5
        imagePullPolicy: IfNotPresent
      volumes:
      - name: host
        hostPath:
          path: /
Almacenamiento 1.28.0-1.28.100

Falta el campo de política de almacenamiento en la plantilla de configuración del clúster de administrador

SPBM en los clústeres de administrador es compatible con las versiones 1.28.0 y posteriores. Sin embargo, falta el campo vCenter.storagePolicyName en la plantilla del archivo de configuración.

Solución alternativa:

Agrega el campo “vCenter.storagePolicyName” al archivo de configuración del clúster de administrador si deseas configurar la política de almacenamiento para el clúster de administrador. Consulta las instructions.
Registro y supervisión 1.28.0-1.28.100

La API de metadatos de Kubernetes no es compatible con VPC-SC

La API agregada recientemente, kubernetesmetadata.googleapis.com, no es compatible con VPC-SC. Esto hará que el agente de recopilación de metadatos no llegue a esta API en VPC-SC. Luego, faltarán las etiquetas de metadatos de métricas.

Solución alternativa:

Configura en el espacio de nombres “kube-system” la CR “stackdriver” configura el campo “featureGates.disableExperimentalMetadataAgent” como “true” mediante la ejecución del comando?

`kubectl -n kube-system patch stackdriver stackdriver -p '{"spec":{"featureGates":{"disableExperimentalMetadataAgent":true}}}'`

luego, ejecuta

`kubectl -n kube-system patch deployment stackdriver-operator -p '{"spec":{"template":{"spec":{"containers":[{"name":"stackdriver-operator","env":[{"name":"ENABLE_LEGACY_METADATA_AGENT","value":"true"}]}]}}}}'`

Revisiones y actualizaciones 1.15.0-1.15.7, 1.16.0-1.16.4, 1.28.0

El controlador de la API de clúster puede fallar cuando el clúster de administrador y cualquier clúster de usuario con ControlPlane V2 habilitado usan credenciales de vSphere diferentes.

Cuando un clúster de administrador y cualquier clúster de usuario con ControlPlane V2 habilitado usan credenciales de vSphere diferentes, p.ej., después de actualizar las credenciales de vSphere para el clúster de administrador, es posible que el clusterapi-controller no pueda conectarse a vCenter después del reinicio. Visualiza el registro del clusterapi-controller que se ejecuta en el espacio de nombres “kube-system” del clúster de administrador.


kubectl logs -f -l component=clusterapi-controllers -c vsphere-controller-manager \
    -n kube-system --kubeconfig KUBECONFIG
Si el registro contiene una entrada como la siguiente, entonces te afecta este problema: 

E1214 00:02:54.095668       1 machine_controller.go:165] Error checking existence of machine instance for machine object gke-admin-node-77f48c4f7f-s8wj2: Failed to check if machine gke-admin-node-77f48c4f7f-s8wj2 exists: failed to find datacenter "VSPHERE_DATACENTER": datacenter 'VSPHERE_DATACENTER' not found

Solución alternativa:

Actualiza las credenciales de vSphere para que el clúster de administrador y todos los clústeres de usuario con Controlplane V2 habilitado usen las mismas credenciales de vSphere.

Registro y supervisión 1.14

Gran cantidad de solicitudes de GRPC fallidas en Prometheus Alert Manager

Prometheus podría informar alertas similares al siguiente ejemplo:


Alert Name: cluster:gke-admin-test1: Etcd cluster kube-system/kube-etcd: 100% of requests for Watch failed on etcd instance etcd-test-xx-n001.

Para verificar si esta alerta es un falso positivo que se puede ignorar, completa los siguientes pasos:

  1. Verifica la métrica grpc_server_handled_total sin procesar con el grpc_method que se indica en el mensaje de alerta. En este ejemplo, comprueba la etiqueta grpc_code para Watch.

    Puedes verificar esta métrica mediante Cloud Monitoring con la siguiente consulta de MQL: 
    
fetch
    k8s_container | metric 'kubernetes.io/anthos/grpc_server_handled_total' | align rate(1m) | every 1m
  2. Las alertas para códigos distintos de OK se pueden ignorar de forma segura si el código no cumple con los siguientes requisitos: 
    
Unknown|FailedPrecondition|ResourceExhausted|Internal|Unavailable|DataLoss|DeadlineExceeded

Solución alternativa:

Si deseas configurar Prometheus para que ignore estas alertas de falsos positivos, revisa las siguientes opciones:

  1. Silencia la alerta desde la IU de Alert Manager.
  2. Si no puedes silenciar la alerta, sigue estos pasos para suprimir los falsos positivos:
    1. Reduce la escala del operador de supervisión a 0 réplicas para que las modificaciones puedan conservarse.
    2. Modifica el mapa de configuración prometheus-config y agrega grpc_method!="Watch" a la configuración de alertas etcdHighNumberOfFailedGRPCRequests como se muestra en el siguiente ejemplo:
      • Original: 
        
rate(grpc_server_handled_total{cluster="CLUSTER_NAME",grpc_code!="OK",job=~".*etcd.*"}[5m])
      • Modificado: 
        
rate(grpc_server_handled_total{cluster="CLUSTER_NAME",grpc_code=~"Unknown|FailedPrecondition|ResourceExhausted|Internal|Unavailable|DataLoss|DeadlineExceeded",grpc_method!="Watch",job=~".*etcd.*"}[5m])
        Reemplaza el siguiente CLUSTER_NAME por el nombre de tu clúster.
    3. Reinicia Prometheus y Alertmanager Statefulset para recoger la configuración nueva.
  3. Si el código corresponde a uno de los casos problemáticos, verifica el registro de etcd y el de kube-apiserver para depurar más.
Redes 1.16.0-1.16.2, 1.28.0

Se descartan las conexiones NAT de larga duración de salida

Las conexiones NAT de salida pueden interrumpirse después de 5 a 10 minutos de que se establezca una conexión si no hay tráfico.

Como la conntrack solo es importante en la dirección entrante (conexiones externas al clúster), este problema ocurre únicamente si la conexión no transmite información durante un tiempo y, luego, el destino transmite algo. Si el Pod de NAT de salida siempre crea una instancia de los mensajes, no se verá este problema.

Este problema ocurre porque la recolección de elementos no utilizados anetd quita de forma involuntaria las entradas de conntrack que el daemon cree que no se usaron. Recientemente, se integró una corrección ascendente en anetd para corregir el comportamiento.


Solución alternativa:

No hay una solución alternativa sencilla y no hemos visto problemas relacionados con este comportamiento en la versión 1.16. Si notas que las conexiones de larga duración disminuyeron debido a este problema, las soluciones alternativas serían usar una carga de trabajo en el mismo nodo que la dirección IP de salida o enviar mensajes de forma coherente en la conexión TCP.
Operación 1.14, 1.15, 1.16

El firmante CSR ignora spec.expirationSeconds cuando firma certificados.

Si creas una CertificateSigningRequest (CSR) con expirationSeconds configurado, se ignora el expirationSeconds.

Solución alternativa:

Si te afecta este problema, puedes actualizar el clúster de usuario si agregas disableNodeIDVerificationCSRSigning: true en el archivo de configuración del clúster de usuario y ejecutas el comando gkectl update cluster para actualizar el clúster con esta configuración.
Herramientas de redes, actualizaciones y actualizaciones 1.16.0-1.16.3

La validación del balanceador de cargas del clúster de usuario falla para disable_bundled_ingress

Si intentas inhabilitar el paquete de entrada para un clúster existente, el comando gkectl update cluster falla y muestra un error similar al siguiente ejemplo:


[FAILURE] Config: ingress IP is required in user cluster spec

Este error ocurre porque gkectl comprueba la dirección IP de entrada de un balanceador de cargas durante las comprobaciones preliminares. Aunque esta verificación no es necesaria cuando se inhabilita la entrada agrupada, la verificación preliminar gkectl falla cuando disableBundledIngress se establece en true.


Solución alternativa:

Usa el parámetro --skip-validation-load-balancer cuando actualices el clúster, como se muestra en el siguiente ejemplo:


gkectl update cluster \
  --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG  \
  --skip-validation-load-balancer

Para obtener más información, consulta cómo inhabilitar la entrada en paquetes en un clúster existente.
Revisiones y actualizaciones 1.13, 1.14, 1.15.0 a 1.15.6

Las actualizaciones del clúster de administrador fallan después de la rotación de la AC

Si rotas los certificados de la autoridad certificadora (AC) del clúster de administrador, los intentos posteriores de ejecutar el comando gkectl update admin fallarán. El error que se muestra es similar al siguiente:


failed to get last CARotationStage: configmaps "ca-rotation-stage" not found

Solución alternativa:

Si te afecta este problema, puedes actualizar el clúster de administrador mediante la marca --disable-update-from-checkpoint con el comando gkectl update admin:


gkectl update admin --config ADMIN_CONFIG_file \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --disable-update-from-checkpoint

Cuando usas la marca --disable-update-from-checkpoint, el comando de actualización no usa el archivo de punto de control como fuente de información durante la actualización del clúster. El archivo del punto de control se sigue actualizando para su uso futuro.
Almacenamiento 1.15.0-1.15.6, 1.16.0-1.16.2

La verificación preliminar de la carga de trabajo de CSI falla debido a una falla de inicio del Pod

Durante las comprobaciones preliminares, la verificación de validación de la carga de trabajo de CSI instala un Pod en el espacio de nombres default. El Pod de carga de trabajo de CSI valida que el controlador de CSI de vSphere esté instalado y pueda aprovisionar de volumen dinámico. Si este Pod no se inicia, la verificación de validación de la carga de trabajo de CSI falla.

Existen algunos problemas conocidos que pueden impedir que este Pod se inicie:

  • Si el Pod no tiene límites de recursos especificados, como en el caso de algunos clústeres que tienen instalados webhooks de admisión, el Pod no se inicia.
  • Si Anthos Service Mesh está instalado en el clúster con la inyección automática del archivo adicional de Istio habilitada en el espacio de nombres default, el Pod de carga de trabajo de CSI no se inicia.

Si el Pod de la carga de trabajo de CSI no se inicia, verás un error de tiempo de espera como el siguiente durante las validaciones de las comprobaciones preliminares:


- [FAILURE] CSI Workload: failure in CSIWorkload validation: failed to create writer Job to verify the write functionality using CSI: Job default/anthos-csi-workload-writer-<run-id> replicas are not in Succeeded phase: timed out waiting for the condition

Para ver si el error se debe a la falta de recursos del Pod configurados, ejecuta el siguiente comando para verificar el estado del trabajo anthos-csi-workload-writer-<run-id>:


kubectl describe job anthos-csi-workload-writer-<run-id>

Si los límites de recursos no están configurados correctamente para el Pod de carga de trabajo de CSI, el estado del trabajo contendrá un mensaje de error como el siguiente:


CPU and memory resource limits is invalid, as it are not defined for container: volume-tester

Si el Pod de carga de trabajo de CSI no se inicia debido a la inyección del archivo adicional de Istio, puedes inhabilitar de forma temporal la inyección automática del archivo adicional de Istio en el espacio de nombres default. Verifica las etiquetas del espacio de nombres y usa el siguiente comando para borrar la etiqueta que comienza con istio.io/rev:


kubectl label namespace default istio.io/rev-

Si el Pod está mal configurado, verifica de forma manual que el aprovisionamiento de volumen dinámico con el controlador de CSI de vSphere funcione:

  1. Crear una PVC que use la StorageClass standard-rwo.
  2. Crear un Pod que use el PVC
  3. Verifica que el Pod pueda leer y escribir datos en el volumen.
  4. Quita el Pod y el PVC después de verificar que el funcionamiento sea correcto.

Si el aprovisionamiento de volumen dinámico con el controlador de CSI de vSphere funciona, ejecuta gkectl diagnose o gkectl upgrade con la marca --skip-validation-csi-workload para omitir la verificación de la carga de trabajo de CSI.

Operación 1.16.0-1.16.2

Se agota el tiempo de espera de la actualización del clúster de usuario cuando la versión del clúster de administrador es 1.15

Cuando accedes a una estación de trabajo de administrador administrada por el usuario, es posible que el comando gkectl update cluster agote el tiempo de espera y no pueda actualizar el clúster de usuario. Esto sucede si la versión del clúster de administrador es 1.15 y ejecutas gkectl update admin antes de ejecutar gkectl update cluster. Cuando se produce este error, aparece el siguiente error cuando intentas actualizar el clúster: 


      Preflight check failed with failed to run server-side preflight checks: server-side preflight checks failed: timed out waiting for the condition
Preflight check failed with failed to run server-side preflight checks: server-side preflight checks failed: timed out waiting for the condition

Durante la actualización de un clúster de administrador 1.15, el validation-controller que activa las comprobaciones preliminares se quita del clúster. Si intentas actualizar el clúster de usuario, la comprobación preliminar se detiene hasta que se alcanza el tiempo de espera.

Solución alternativa:

  1. Ejecuta el siguiente comando para volver a implementar validation-controller: 
    
      gkectl prepare --kubeconfig ADMIN_KUBECONFIG --bundle-path BUNDLE_PATH --upgrade-platform
  2. Después de que se complete la preparación, vuelve a ejecutar gkectl update cluster para actualizar el clúster de usuario.
Operación 1.16.0-1.16.2

Se agota el tiempo de espera de la creación del clúster de usuario cuando la versión del clúster de administrador es 1.15

Cuando accedes a una estación de trabajo de administrador administrada por el usuario, es posible que el comando gkectl create cluster agote el tiempo de espera y no pueda crear el clúster de usuario. Esto sucede si la versión del clúster de administrador es 1.15. Cuando se produce este error, aparece el siguiente error cuando intentas crear el clúster: 


      Preflight check failed with failed to run server-side preflight checks: server-side preflight checks failed: timed out waiting for the condition
Preflight check failed with failed to run server-side preflight checks: server-side preflight checks failed: timed out waiting for the condition

Dado que validation-controller se agregó en la versión 1.16, cuando se usa el clúster de administrador 1.15, falta el validation-controller responsable de activar las comprobaciones preliminares. Por lo tanto, cuando se intenta crear un clúster de usuario, las comprobaciones preliminares permanecen en espera hasta que se alcanza el tiempo de espera.

Solución alternativa:

  1. Ejecuta el siguiente comando para implementar validation-controller: 
    
      gkectl prepare --kubeconfig ADMIN_KUBECONFIG --bundle-path BUNDLE_PATH --upgrade-platform
  2. Después de que se complete la preparación, vuelve a ejecutar gkectl create cluster para crear el clúster de usuario.
Revisiones y actualizaciones 1.16.0-1.16.2

La actualización o actualización del clúster de administrador falla si los proyectos o las ubicaciones de los servicios de complementos no coinciden entre sí

Cuando actualizas un clúster de administrador de la versión 1.15.x a la 1.16.x o agregas una configuración connect, stackdriver, cloudAuditLogging o gkeOnPremAPI cuando actualizas un clúster de administrador, es posible que el webhook del clúster de administrador rechace la operación. Es posible que se muestre uno de los siguientes mensajes de error:

  • "projects for connect, stackdriver and cloudAuditLogging must be the same when specified during cluster creation."
  • "locations for connect, gkeOnPremAPI, stackdriver and cloudAuditLogging must be in the same region when specified during cluster creation."
  • "locations for stackdriver and cloudAuditLogging must be the same when specified during cluster creation."

Una actualización de clúster de administrador requiere que onprem-admin-cluster-controller concilie el clúster de administrador en un clúster de tipo. Cuando se restablece el estado del clúster de administrador en el clúster de tipo, el webhook de clúster de administrador no puede distinguir si el objeto OnPremAdminCluster es para la creación de un clúster de administrador o para reanudar las operaciones de una actualización o actualización. Algunas validaciones de solo creación se invocan cuando se realiza una actualización de forma inesperada.


Solución alternativa:

Agrega la anotación onprem.cluster.gke.io/skip-project-location-sameness-validation: true al objeto OnPremAdminCluster:

  1. Edita el recurso del clúster onpremadminclusters: 
    
kubectl edit onpremadminclusters ADMIN_CLUSTER_NAME -n kube-system –kubeconfig ADMIN_CLUSTER_KUBECONFIG
    Reemplaza lo siguiente:
    • ADMIN_CLUSTER_NAME: Es el nombre del clúster de administrador.
    • ADMIN_CLUSTER_KUBECONFIG: Es la ruta de acceso del archivo kubeconfig del clúster de administrador.
  2. Agrega la anotación onprem.cluster.gke.io/skip-project-location-sameness-validation: true y guarda el recurso personalizado.
  3. Según el tipo de clústeres de administrador, completa uno de los siguientes pasos:
    • Para clústeres de administrador sin alta disponibilidad con un archivo de punto de control: agrega el parámetro disable-update-from-checkpoint en el comando de actualización o agrega el parámetro “disable-upgrade-from-checkpoint” al comando de actualización. Estos parámetros solo se necesitarán la próxima vez que ejecutes el comando update o upgrade:
      • 
gkectl update admin --config ADMIN_CONFIG_file --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
  --disable-update-from-checkpoint

      • 
gkectl upgrade admin --config ADMIN_CONFIG_file --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
  --disable-upgrade-from-checkpoint
    • Para los clústeres de administrador de alta disponibilidad o el archivo de punto de control está inhabilitado, actualiza el clúster de administrador como de costumbre. No se necesitan parámetros adicionales en los comandos de actualización.
Operación 1.16.0-1.16.2

No se puede borrar el clúster de usuario cuando se usa una estación de trabajo de administrador administrada por el usuario

Cuando accedes a una estación de trabajo de administrador administrada por el usuario, es posible que el comando gkectl delete cluster agote el tiempo de espera y no pueda borrar el clúster de usuario. Esto sucede si primero ejecutaste gkectl en la estación de trabajo administrada por el usuario para crear, actualizar o actualizar el clúster de usuario. Cuando se produce este error, aparece el siguiente error cuando intentas borrar el clúster: 


      failed to wait for user cluster management namespace "USER_CLUSTER_NAME-gke-onprem-mgmt"
      to be deleted: timed out waiting for the condition

Durante la eliminación, un clúster primero borra todos sus objetos. La eliminación de los objetos de validación (que se crearon durante la creación, actualización o actualización) se detiene en la fase de eliminación. Esto sucede porque un finalizador bloquea la eliminación del objeto, lo que provoca que la eliminación del clúster falle.

Solución alternativa:

  1. Obtén los nombres de todos los objetos Validation: 
    
         kubectl  --kubeconfig ADMIN_KUBECONFIG get validations \
           -n USER_CLUSTER_NAME-gke-onprem-mgmt
  2. Para cada objeto Validation, ejecuta el siguiente comando para quitar el finalizador del objeto Validation: 
    
      kubectl --kubeconfig ADMIN_KUBECONFIG patch validation/VALIDATION_OBJECT_NAME \
        -n USER_CLUSTER_NAME-gke-onprem-mgmt -p '{"metadata":{"finalizers":[]}}' --type=merge

    Después de quitar el finalizador de todos los objetos de Validation, estos se quitan y la operación de eliminación del clúster de usuario se completa de forma automática. No es necesario que realices ninguna acción adicional.

Redes 1.15, 1.16

El tráfico de la puerta de enlace NAT de salida al servidor externo falla

Si el Pod de origen y el Pod de puerta de enlace de NAT de salida están en dos nodos trabajadores diferentes, el tráfico del Pod de origen no puede llegar a ningún servicio externo. Si los Pods se encuentran en el mismo host, la conexión con el servicio o la aplicación externos se realiza de forma correcta.

Este problema se debe a que vSphere descarta paquetes VXLAN cuando está habilitada la agregación de túneles. Existe un problema conocido con NSX y VMware que solo envía tráfico agregado a puertos VXLAN conocidos (4789).


Solución alternativa:

Cambia el puerto VXLAN que usa Cilium a 4789:

  1. Edita el ConfigMap cilium-config: 
    
kubectl edit cm -n kube-system cilium-config --kubeconfig USER_CLUSTER_KUBECONFIG
  2. Agrega lo siguiente al ConfigMap cilium-config: 
    
tunnel-port: 4789
  3. Reinicia el DaemonSet anetd: 
    
kubectl rollout restart ds anetd -n kube-system --kubeconfig USER_CLUSTER_KUBECONFIG

Esta solución alternativa se revierte cada vez que se actualiza el clúster. Debes volver a configurarlo después de cada actualización. VMware debe resolver su problema en vSphere para obtener una solución permanente.
Actualizaciones 1.15.0-1.15.4

Falla la actualización de un clúster de administrador con la encriptación de Secrets siempre activa habilitada.

La actualización del clúster de administrador de 1.14.x a 1.15.x con la encriptación de secretos siempre activa habilitada falla debido a una discrepancia entre la clave de encriptación generada por el controlador y la clave que persiste en el disco de datos de la instancia principal de administrador. El resultado de gkectl upgrade admin contiene el siguiente mensaje de error: 


      E0926 14:42:21.796444   40110 console.go:93] Exit with error:
      E0926 14:42:21.796491   40110 console.go:93] Failed to upgrade the admin cluster: failed to create admin cluster: failed to wait for OnPremAdminCluster "admin-cluster-name" to become ready: failed to wait for OnPremAdminCluster "admin-cluster-name" to be ready: error: timed out waiting for the condition, message: failed to wait for OnPremAdminCluster "admin-cluster-name" to stay in ready status for duration "2m0s": OnPremAdminCluster "non-prod-admin" is not ready: ready condition is not true: CreateOrUpdateControlPlane: Creating or updating credentials for cluster control plane

La ejecución de kubectl get secrets -A --kubeconfig KUBECONFIG` falla con el siguiente error: 


      Internal error occurred: unable to transform key "/registry/secrets/anthos-identity-service/ais-secret": rpc error: code = Internal desc = failed to decrypt: unknown jwk

Solución alternativa

Si tienes una copia de seguridad del clúster de administrador, sigue estos pasos para solucionar el error de actualización:

  1. Inhabilita secretsEncryption en el archivo de configuración del clúster de administrador y actualiza el clúster con el siguiente comando: 
    
gkectl update admin --config ADMIN_CLUSTER_CONFIG_FILE --kubeconfig KUBECONFIG
  2. Cuando se cree la nueva VM principal de administrador, establece una conexión SSH a la VM principal de administrador y reemplaza la clave nueva en el disco de datos por la anterior de la copia de seguridad. La clave se encuentra en /opt/data/gke-k8s-kms-plugin/generatedkeys, en la instancia principal del administrador.
  3. Actualiza el manifiesto del Pod estático de kms-plugin.yaml en /etc/kubernetes/manifests para actualizar el --kek-id de modo que coincida con el campo kid en la clave de encriptación original.
  4. Reinicia el Pod estático de kms-plugin. Para ello, mueve /etc/kubernetes/manifests/kms-plugin.yaml a otro directorio y, luego, vuelve a moverlo.
  5. Vuelve a ejecutar gkectl upgrade admin para reanudar la actualización del administrador.

Evita los errores de actualización

Si aún no lo hiciste, te recomendamos que no lo hagas a la versión 1.15.0 a 1.15.4. Si debes actualizar a una versión afectada, sigue estos pasos antes de actualizar el clúster de administrador:

  1. Crea una copia de seguridad del clúster de administrador.
  2. Inhabilita secretsEncryption en el archivo de configuración del clúster de administrador y actualiza el clúster con el siguiente comando: 
    
gkectl update admin --config ADMIN_CLUSTER_CONFIG_FILE --kubeconfig KUBECONFIG
  3. Actualiza el clúster de administrador.
  4. Vuelve a habilitar la encriptación de Secrets siempre activos.
Almacenamiento 1,11 a 1,16

Errores de disco y fallas de conexión cuando se usa el seguimiento de bloques modificados (CBT)

GKE en VMware no admite el seguimiento de bloques modificados (CBT) en los discos. Algunos software de copia de seguridad usan la función de CBT para realizar un seguimiento del estado del disco y realizar copias de seguridad, lo que hace que el disco no pueda conectarse a una VM que ejecute GKE en VMware. Para obtener más información, consulta el artículo de la base de conocimiento de VMware.


Solución alternativa:

No crees una copia de seguridad de las VMs de GKE en VMware, ya que el software de copia de seguridad de terceros puede hacer que la CBT se habilite en sus discos. No es necesario crear una copia de seguridad de estas VMs.

No habilites la CBT en el nodo, ya que este cambio no se conservará entre actualizaciones ni actualizaciones.

Si ya tienes discos con CBT habilitado, sigue los pasos de Resolución que se indican en el artículo de la base de conocimiento de VMware para inhabilitar la CBT en el disco de primera clase.
Almacenamiento 1.14, 1.15, 1.16

Corrupción de datos en NFSv3 cuando se realizan agregaciones paralelas a un archivo compartido desde varios hosts.

Si usas arrays de almacenamiento de Nutanix para proporcionar recursos compartidos NFSv3 a tus hosts, es posible que experimentes daños en los datos o que los Pods no puedan ejecutarse de forma correcta. Este problema se debe a un problema de compatibilidad conocido entre ciertas versiones de VMware y Nutanix. Para obtener más información, consulta el artículo asociado de la base de conocimiento de VMware.


Solución alternativa:

El artículo de la base de conocimiento de VMware está desactualizado porque no hay una resolución actual. Para resolver este problema, actualiza a la versión más reciente de ESXi en tus hosts y a la versión más reciente de Nutanix en tus arreglos de almacenamiento.
Sistema operativo 1.13.10, 1.14.6, 1.15.3

La versión no coincide entre kubelet y el plano de control de Kubernetes

Para algunas versiones de GKE on VMware, el kubelet que se ejecuta en los nodos usa una versión diferente que el plano de control de Kubernetes. Hay una discrepancia porque el objeto binario de kubelet precargado en la imagen de SO usa una versión diferente.

En la siguiente tabla, se enumeran las discrepancias de versiones identificadas:

Versión de GKE en VMware Versión de kubelet Versión de Kubernetes
1.13.10 Versión 1.24.11-gke.1200 v1.24.14-gke.2100
1.14.6 v1.25.8-gke.1500 v1.25.10-gke.1200
1.15.3 v1.26.2-gke.1001 v1.26.5-gke.2100

Solución alternativa:

No necesita realizar ninguna acción. La incoherencia solo ocurre entre las versiones de parche de Kubernetes y no se generaron problemas por este sesgo de versión.

Revisiones y actualizaciones 1.15.0-1.15.4

La actualización o actualización de un clúster de administrador con una versión de AC superior a 1 falla

Cuando un clúster de administrador tiene una versión de autoridad certificadora (AC) superior a 1, una actualización falla debido a la validación de la versión de AC en el webhook. El resultado de la actualización o actualización de gkectl contiene el siguiente mensaje de error: 


    CAVersion must start from 1

Solución alternativa:

  • Reduce el escalamiento vertical de la implementación de auto-resize-controller en el clúster de administrador para inhabilitar el cambio automático de tamaño de los nodos. Esto es necesario porque un campo nuevo ingresado en el recurso personalizado del clúster de administrador en la versión 1.15 puede causar un error de puntero nulo en auto-resize-controller. 
    
 kubectl scale deployment auto-resize-controller -n kube-system --replicas=0 --kubeconfig KUBECONFIG
  • Ejecuta los comandos gkectl con la marca --disable-admin-cluster-webhook.Por ejemplo: 
    
        gkectl upgrade admin --config ADMIN_CLUSTER_CONFIG_FILE --kubeconfig KUBECONFIG --disable-admin-cluster-webhook
Operación 1.13, 1.14.0-1.14.8, 1.15.0-1.15.4, 1.16.0-1.16.1

Se detuvo la eliminación del clúster de V2 que no tiene el plano de control de alta disponibilidad hasta que se agote el tiempo de espera

Cuando se borra un clúster de Controlplane V2 que no tiene alta disponibilidad, se detiene en la eliminación del nodo hasta que se agota el tiempo de espera.

Solución alternativa:

Si el clúster contiene un StatefulSet con datos críticos, comunícate con comunícate con Atención al cliente de Cloud para resolver este problema.

De lo contrario, sigue estos pasos:

  • Borra todas las VMs del clúster de vSphere. Puedes borrar las VM a través de la IU de vSphere o ejecutar el siguiente comando: 
    
      govc vm.destroy
    .
  • Vuelve a forzar la eliminación del clúster: 
    
     gkectl delete cluster --cluster USER_CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG --force

Almacenamiento 1.15.0+, 1.16.0+

Las tareas constantes del volumen de adjunto de CNS aparecen cada minuto para los PVC/PV en el árbol después de actualizar a la versión 1.15 o posterior.

Cuando un clúster contiene volúmenes persistentes de vSphere en un árbol (por ejemplo, PVC creados con la StorageClass standard), observarás tareas com.vmware.cns.tasks.attachvolume que se activan cada minuto desde vCenter.


Solución alternativa:

Edita el configMap de la función de CSI de vSphere y establece list-volumes como falso:


     kubectl edit configmap internal-feature-states.csi.vsphere.vmware.com -n kube-system --kubeconfig KUBECONFIG

Reinicia los Pods del controlador de CSI de vSphere:


     kubectl rollout restart vsphere-csi-controller -n kube-system --kubeconfig KUBECONFIG
Almacenamiento 1.16.0

Falsas advertencias sobre PVC

Cuando un clúster contiene volúmenes persistentes de vSphere en un árbol, los comandos gkectl diagnose y gkectl upgrade pueden generar advertencias falsas en contra de sus reclamaciones de volumen persistente (PVC) cuando validan la configuración de almacenamiento del clúster. El mensaje de advertencia se ve de la siguiente manera: 


    CSIPrerequisites pvc/pvc-name: PersistentVolumeClaim pvc-name bounds to an in-tree vSphere volume created before CSI migration enabled, but it doesn't have the annotation pv.kubernetes.io/migrated-to set to csi.vsphere.vmware.com after CSI migration is enabled

Solución alternativa:

Ejecuta el siguiente comando para verificar las anotaciones de un PVC con la advertencia anterior:


    kubectl get pvc PVC_NAME -n PVC_NAMESPACE -oyaml --kubeconfig KUBECONFIG

Si el campo annotations del resultado contiene lo siguiente, puedes ignorar la advertencia de forma segura:


      pv.kubernetes.io/bind-completed: "yes"
      pv.kubernetes.io/bound-by-controller: "yes"
      volume.beta.kubernetes.io/storage-provisioner: csi.vsphere.vmware.com
Revisiones y actualizaciones 1.15.0+, 1.16.0+

La rotación de claves de la cuenta de servicio falla cuando se vencen varias claves

Si tu clúster no usa un registro privado, y las claves de la cuenta de servicio de acceso a los componentes y de supervisión de Logging (o registro de Connect) caducan, cuando rotas las claves de la cuenta de servicio, gkectl update credentials falla y muestra un error similar al siguiente: 


Error: reconciliation failed: failed to update platform: ...

Solución alternativa:

Primero, rota la clave de la cuenta de servicio de acceso a los componentes. Aunque se muestra el mismo mensaje de error, deberías poder rotar las otras claves después de la rotación de claves de la cuenta de servicio de acceso al componente.

Si aún no se realiza correctamente la actualización, comunícate con Atención al cliente de Cloud para resolver el problema.
Actualizaciones 1.16.0-1.16.5

1.15 La máquina principal de usuario encuentra una recreación inesperada cuando el controlador del clúster de usuario se actualiza a la versión 1.16.

Durante la actualización del clúster de usuario, después de que el controlador del clúster de usuario se actualice a la versión 1.16, si tienes otros 1.15 clústeres de usuario administrados por el mismo clúster de administrador, es posible que la máquina de la instancia principal de usuario se vuelva a crear de forma inesperada.

Hay un error en el controlador del clúster de usuario 1.16 que puede activar la recreación de la máquina de la instancia principal del usuario 1.15.

La solución alternativa depende de cómo encuentres este problema.

Solución para actualizar el clúster de usuario con la consola de Google Cloud:

Opción 1: Usa una versión 1.16.6 o posterior de GKE en VMware con la solución.

Opción 2: Sigue estos pasos:

  1. Usa el siguiente comando para agregar manualmente la anotación rerun: 
    
kubectl edit onpremuserclusters USER_CLUSTER_NAME -n USER_CLUSTER_NAME-gke-onprem-mgmt --kubeconfig ADMIN_KUBECONFIG

    Esta es la anotación de nueva ejecución:

    
onprem.cluster.gke.io/server-side-preflight-rerun: true
  2. Supervisa el progreso de la actualización revisando el campo status de OnPremUserCluster.

Solución alternativa para actualizar el clúster de usuario con tu propia estación de trabajo de administrador:

Opción 1: Usa una versión 1.16.6 o posterior de GKE en VMware con la solución.

Opción 2: Sigue estos pasos:

  1. Agrega el archivo de información de compilación /etc/cloud/build.info con el siguiente contenido. Esto hace que las comprobaciones preliminares se ejecuten de forma local en la estación de trabajo de administrador en lugar del servidor. 
    
gke_on_prem_version: GKE_ON_PREM_VERSION
    Por ejemplo: 
    
gke_on_prem_version: 1.16.0-gke.669
  2. Vuelve a ejecutar el comando de actualización.
  3. Cuando se complete la actualización, borra el archivo build.info.
Crear 1.16.0-1.16.5, 1.28.0-1.28.100

La comprobación preliminar falla cuando el nombre de host no está en el archivo de bloqueo de IP.

Si no especificas un nombre de host para cada dirección IP en el archivo de bloqueo de IP durante la creación del clúster, la verificación preliminar falla y muestra el siguiente mensaje de error: 


multiple VMs found by DNS name  in xxx datacenter. Anthos Onprem doesn't support duplicate hostname in the same vCenter and you may want to rename/delete the existing VM.`

Hay un error en la comprobación preliminar que supone que el nombre de host vacío está duplicado.

Solución alternativa:

Opción 1: Usa una versión con la corrección.

Opción 2: Para omitir esta verificación preliminar, agrega la marca --skip-validation-net-config.

Opción 3: Especifica un nombre de host único para cada dirección IP en el archivo de bloque de IP.
Revisiones y actualizaciones 1.16.0

No se pudo crear el nodo del plano de control

Durante una actualización o actualización de un clúster de administrador, una condición de carrera puede provocar que el administrador del controlador en la nube de vSphere borre de forma inesperada un nuevo nodo del plano de control. Esto hace que el clusterapi-controller quede atascado a la espera de que se cree el nodo y, incluso, se agote el tiempo de espera de la actualización o la actualización. En este caso, el resultado del comando de actualización o actualización gkectl es similar al siguiente:


    controlplane 'default/gke-admin-hfzdg' is not ready: condition "Ready": condition is not ready with reason "MachineInitializing", message "Wait for the control plane machine "gke-admin-hfzdg-6598459f9zb647c8-0\" to be rebooted"...

Si deseas identificar el síntoma, ejecuta el siguiente comando para acceder al administrador de Cloud Controller de vSphere en el clúster de administrador:


    kubectl get pods --kubeconfig ADMIN_KUBECONFIG -n kube-system | grep vsphere-cloud-controller-manager
    kubectl logs -f vsphere-cloud-controller-manager-POD_NAME_SUFFIX --kubeconfig ADMIN_KUBECONFIG -n kube-system

A continuación, se muestra un ejemplo de mensaje de error del comando anterior:


    node name: 81ff17e25ec6-qual-335-1500f723 has a different uuid. Skip deleting this node from cache.

Solución alternativa:

  1. Reinicia la máquina con errores para volver a crear el objeto de nodo borrado.
  2. Establece una conexión SSH a cada nodo del plano de control y reinicia el Pod estático del administrador del controlador de nube de vSphere: 
    
      sudo crictl ps | grep vsphere-cloud-controller-manager | awk '{print $1}'
      sudo crictl stop PREVIOUS_COMMAND_OUTPUT
  3. Vuelve a ejecutar el comando de actualización o actualización.
Operación 1.16

El nombre de host duplicado en el mismo centro de datos provoca errores de actualización o creación del clúster.

La actualización de un clúster 1.15 o la creación de un clúster 1.16 con IP estáticas falla si hay nombres de host duplicados en el mismo centro de datos. Este error se produce porque el administrador de Cloud Controller de vSphere no puede agregar una IP externa ni un ID de proveedor al objeto del nodo. Esto hace que se agote el tiempo de espera de la creación o actualización del clúster.

Para identificar el problema, obtén los registros del Pod del administrador del controlador de nube de vSphere del clúster. El comando que uses depende del tipo de clúster, de la siguiente manera:

  • Clúster de administrador: 
    
      kubectl get pods --kubeconfig ADMIN_KUBECONFIG -n kube-system | grep vsphere-cloud-controller-manager
      kubectl logs -f vsphere-cloud-controller-manager-POD_NAME_SUFFIX --kubeconfig ADMIN_KUBECONFIG -n kube-system
  • Clúster de usuario (kubeception): 
    
      kubectl get pods --kubeconfig ADMIN_KUBECONFIG -n USER_CLUSTER_NAME | grep vsphere-cloud-controller-manager
      kubectl logs -f vsphere-cloud-controller-manager-POD_NAME_SUFFIX --kubeconfig ADMIN_KUBECONFIG -n USER_CLUSTER_NAME
  • Clúster de usuario: (Plano de control V2): 
    
      kubectl get pods --kubeconfig USER_KUBECONFIG -n kube-system | grep vsphere-cloud-controller-manager
      kubectl logs -f vsphere-cloud-controller-manager-POD_NAME_SUFFIX --kubeconfig USER_KUBECONFIG -n kube-system

A continuación, se muestra un ejemplo de mensaje de error:


    I1003 17:17:46.769676       1 search.go:152] Finding node admin-vm-2 in vc=vcsa-53598.e5c235a1.asia-northeast1.gve.goog and datacenter=Datacenter
    E1003 17:17:46.771717       1 datacenter.go:111] Multiple vms found VM by DNS Name. DNS Name: admin-vm-2

Comprueba si el nombre de host está duplicado en el centro de datos:

Puedes usar el siguiente enfoque para verificar si el nombre de host está duplicado y, si es necesario, aplicar una solución alternativa. 

          export GOVC_DATACENTER=GOVC_DATACENTER
          export GOVC_URL=GOVC_URL
          export GOVC_USERNAME=GOVC_USERNAME
          export GOVC_PASSWORD=GOVC_PASSWORD
          export GOVC_INSECURE=true
          govc find . -type m -guest.hostName HOSTNAME
Comandos y resultado de ejemplo: 

          export GOVC_DATACENTER=mtv-lifecycle-vc01
          export GOVC_URL=https://mtv-lifecycle-vc01.anthos/sdk
          export GOVC_USERNAME=xxx
          export GOVC_PASSWORD=yyy
          export GOVC_INSECURE=true
          govc find . -type m -guest.hostName f8c3cd333432-lifecycle-337-xxxxxxxz
          ./vm/gke-admin-node-6b7788cd76-wkt8g
          ./vm/gke-admin-node-6b7788cd76-99sg2
          ./vm/gke-admin-master-5m2jb

La solución alternativa que sigas dependerá de la operación que falló.

Solución para las actualizaciones:

Usa la solución alternativa para el tipo de clúster aplicable.

  • Clúster de usuario:
    1. Actualiza el nombre de host de la máquina afectada en user-ip-block.yaml a un nombre único y activa una actualización forzada:
      
          gkectl update cluster --kubeconfig ADMIN_KUBECONFIG --config NEW_USER_CLUSTER_CONFIG --force
    2. Volver a ejecutar gkectl upgrade cluster
  • Clúster de administrador:
    1. Actualiza el nombre de host de la máquina afectada en admin-ip-block.yaml a un nombre único y activa una actualización forzada:
      
          gkectl update admin --kubeconfig ADMIN_KUBECONFIG --config NEW_ADMIN_CLUSTER_CONFIG --force --skip-cluster-ready-check
    2. Si se trata de un clúster de administrador que no tiene alta disponibilidad y descubres que la VM principal de administrador usa un nombre de host duplicado, también debes hacer lo siguiente:
      Obtener el nombre de la máquina principal de administrador 
      
          kubectl get machine --kubeconfig ADMIN_KUBECONFIG -owide -A
      Actualiza el objeto de la máquina de la instancia principal del administrador
      Nota: El valor NEW_ADMIN_MASTER_HOSTNAME debe ser el mismo que configuraste en admin-ip-block.yaml en el paso 1.
      
          kubectl patch machine ADMIN_MASTER_MACHINE_NAME --kubeconfig ADMIN_KUBECONFIG --type='json' -p '[{"op": "replace", "path": "/spec/providerSpec/value/networkSpec/address/hostname", "value":"NEW_ADMIN_MASTER_HOSTNAME"}]'
      Verifica que el nombre de host esté actualizado en el objeto de máquina de la instancia principal de administrador:
      
          kubectl get machine ADMIN_MASTER_MACHINE_NAME --kubeconfig ADMIN_KUBECONFIG -oyaml
          kubectl get machine ADMIN_MASTER_MACHINE_NAME --kubeconfig ADMIN_KUBECONFIG -o jsonpath='{.spec.providerSpec.value.networkSpec.address.hostname}'
    3. Vuelve a ejecutar la actualización del clúster de administrador con el punto de control inhabilitado:
      
          gkectl upgrade admin --kubeconfig ADMIN_KUBECONFIG --config ADMIN_CLUSTER_CONFIG --disable-upgrade-from-checkpoint

Solución para las instalaciones:

Usa la solución alternativa para el tipo de clúster aplicable.
Operación 1.16.0, 1.16.1, 1.16.2, 1.16.3

$ y ` no son compatibles con el nombre de usuario o la contraseña de vSphere

Las siguientes operaciones fallan cuando el nombre de usuario o la contraseña de vSphere contienen $ o `:

  • Actualiza un clúster de usuario de la versión 1.15 con el plano de control V2 habilitado a la versión 1.16
  • Actualiza un clúster de administrador con alta disponibilidad (HA) de 1.15 a 1.16
  • Crea un clúster de usuario 1.16 con el plano de control V2 habilitado
  • Crea un clúster de administrador de HA 1.16

Usa una versión 1.16.4 o superior de GKE en VMware con la solución o realiza la siguiente solución alternativa. La solución alternativa que sigas dependerá de la operación que falló.

Solución para las actualizaciones:

  1. Cambia el nombre de usuario o la contraseña de vCenter en el lado de vCenter para quitar $ y `.
  2. Actualiza el nombre de usuario o la contraseña de vCenter en el archivo de configuración de credenciales.
  3. Activar una actualización forzada del clúster
    • Clúster de usuario: 
      
        gkectl update cluster --kubeconfig ADMIN_KUBECONFIG --config USER_CLUSTER_CONFIG --force
    • Clúster de administrador: 
      
        gkectl update admin --kubeconfig ADMIN_KUBECONFIG --config ADMIN_CLUSTER_CONFIG --force --skip-cluster-ready-check

Solución para las instalaciones:

  1. Cambia el nombre de usuario o la contraseña de vCenter en el lado de vCenter para quitar $ y `.
  2. Actualiza el nombre de usuario o la contraseña de vCenter en el archivo de configuración de credenciales.
  3. Usa la solución alternativa para el tipo de clúster aplicable.
Almacenamiento 1.11+, 1.12+, 1.13+, 1.14+, 1.15+, 1.16

Error de creación de PVC después de que el nodo se vuelve a crear con el mismo nombre

Después de que se borra un nodo y, luego, se vuelve a crear con el mismo nombre, existe una leve posibilidad de que la creación de una PersistentVolumeClaim (PVC) posterior falle con un error como el siguiente:


    The object 'vim.VirtualMachine:vm-988369' has already been deleted or has not been completely created

Esto se debe a una condición de carrera en la que el controlador de CSI de vSphere no borra una máquina que se quitó de su caché.


Solución alternativa:

Reinicia los Pods del controlador de CSI de vSphere:


    kubectl rollout restart vsphere-csi-controller -n kube-system --kubeconfig KUBECONFIG
Operación 1.16.0

El comando de reparación de gkectl en admin-master muestra el error de kubeconfig de kubeconfig.

Cuando ejecutas el comando gkectl repair admin-master en un clúster de administrador de alta disponibilidad, gkectl muestra el siguiente mensaje de error: 


  Exit with error: Failed to repair: failed to select the template: failed to get cluster name from kubeconfig, please contact Google support. failed to decode kubeconfig data: yaml: unmarshal errors:
    line 3: cannot unmarshal !!seq into map[string]*api.Cluster
    line 8: cannot unmarshal !!seq into map[string]*api.Context

Solución alternativa:

Agrega la marca --admin-master-vm-template= al comando y proporciona la plantilla de VM de la máquina que se reparará: 


  gkectl repair admin-master --kubeconfig=ADMIN_CLUSTER_KUBECONFIG \
      --config ADMIN_CLUSTER_CONFIG_FILE \
      --admin-master-vm-template=/DATA_CENTER/vm/VM_TEMPLATE_NAME

Para encontrar la plantilla de VM de la máquina, sigue estos pasos:

  1. Ve a la página Hosts and Clusters en el cliente de vSphere.
  2. Haz clic en Plantillas de VM y filtra por el nombre del clúster de administrador.

    Deberías ver las tres plantillas de VM para el clúster de administrador.

  3. Copia el nombre de la plantilla de VM que coincide con el nombre de la máquina que estás reparando y usa el nombre de la plantilla en el comando de reparación.

  gkectl repair admin-master \
      --config=/home/ubuntu/admin-cluster.yaml \
      --kubeconfig=/home/ubuntu/kubeconfig \
      --admin-master-vm-template=/atl-qual-vc07/vm/gke-admin-98g94-zx...7vx-0-tmpl
Redes 1.10.0+, 1.11.0+, 1.12.0+, 1.13.0+, 1.14.0-1.14.7, 1.15.0-1.15.3 y 1.16.0

La VM de Seesaw no funciona debido a que hay poco espacio en el disco

Si usas Seesaw como el tipo de balanceador de cargas para el clúster y ves que una VM de Seesaw no funciona o no se inicia, es posible que veas el siguiente mensaje de error en la consola de vSphere:


    GRUB_FORCE_PARTUUID set, initrdless boot failed. Attempting with initrd

Este error indica que hay poco espacio en el disco en la VM porque el bit fluido que se ejecuta en la VM de Seesaw no está configurado con la rotación del registro correcta.


Solución alternativa:

Ubica los archivos de registro que consumen la mayor parte del espacio en el disco con du -sh -- /var/lib/docker/containers/* | sort -rh. Limpia el archivo de registro de mayor tamaño y reinicia la VM.

Nota: Si la VM es completamente inaccesible, conecta el disco a una VM que funcione (p.ej., una estación de trabajo de administrador), quita el archivo del disco conectado y, luego, vuelve a conectar el disco en la VM original de Seesaw.

Para evitar que el problema vuelva a ocurrir, conéctate a la VM y modifica el archivo /etc/systemd/system/docker.fluent-bit.service. Agrega --log-opt max-size=10m --log-opt max-file=5 en el comando de Docker y, luego, ejecuta systemctl restart docker.fluent-bit.service.
Operación 1.13, 1.14.0-1.14.6, 1.15

Error de la clave pública SSH del administrador después de la actualización o actualización del clúster de administrador

Cuando intentas actualizar (gkectl upgrade admin) o actualizar (gkectl update admin) un clúster de administrador que no es de alta disponibilidad con el punto de control habilitado, es posible que la actualización o la actualización fallen con errores como los siguientes: 


Checking admin cluster certificates...FAILURE
    Reason: 20 admin cluster certificates error(s).
Unhealthy Resources:
    AdminMaster clusterCA bundle: failed to get clusterCA bundle on admin master, command [ssh -o IdentitiesOnly=yes -i admin-ssh-key -o StrictHostKeyChecking=no -o ConnectTimeout=30 ubuntu@AdminMasterIP -- sudo cat /etc/kubernetes/pki/ca-bundle.crt] failed with error: exit status 255, stderr: Authorized uses only. All activity may be monitored and reported.
    ubuntu@AdminMasterIP: Permission denied (publickey).


failed to ssh AdminMasterIP, failed with error: exit status 255, stderr: Authorized uses only. All activity may be monitored and reported.
    ubuntu@AdminMasterIP: Permission denied (publickey)


error dialing ubuntu@AdminMasterIP: failed to establish an authenticated SSH connection: ssh: handshake failed: ssh: unable to authenticate, attempted methods [none publickey]...


Solución alternativa:

Si no puedes actualizar a una versión de parche de GKE en VMware con la corrección, comunícate con el equipo de Atención al cliente de Google para obtener ayuda.
Actualizaciones 1.13.0-1.13.9, 1.14.0-1.14.6, 1.15.1-1.15.2

La actualización de un clúster de administrador inscrito en la API de GKE On-Prem podría fallar

Cuando un clúster de administrador está inscrito en la API de GKE On-Prem, la actualización del clúster de administrador a las versiones afectadas podría fallar porque no se pudo actualizar la membresía de la flota. Cuando se produce este error, aparece el siguiente error cuando intentas actualizar el clúster:


    failed to register cluster: failed to apply Hub Membership: Membership API request failed: rpc error: code = InvalidArgument desc = InvalidFieldError for field endpoint.on_prem_cluster.resource_link: field cannot be updated

Un clúster de administrador se inscribe en la API cuando inscribes el clúster de forma explícita o cuando actualizas un clúster de usuario con un cliente de la API de GKE On-Prem.


Solución alternativa:

Da de baja el clúster de administrador: 

    gcloud alpha container vmware admin-clusters unenroll ADMIN_CLUSTER_NAME --project CLUSTER_PROJECT --location=CLUSTER_LOCATION --allow-missing
y reanuda la actualización del clúster de administrador. Es posible que veas temporalmente el error “no se pudo registrar el clúster” inactivo. Después de un tiempo, debería actualizarse automáticamente.
Revisiones y actualizaciones 1.13.0-1.13.9, 1.14.0-1.14.4, 1.15.0

Cuando un clúster de administrador está inscrito en la API de GKE On-Prem, su anotación de vínculo de recursos se aplica al recurso personalizado OnPremAdminCluster, que no se conserva durante las actualizaciones posteriores del clúster de administrador debido a que se usó una clave de anotación incorrecta. Esto puede hacer que el clúster de administrador se vuelva a inscribir en la API de GKE On-Prem por error.

Un clúster de administrador se inscribe en la API cuando inscribes el clúster de forma explícita o cuando actualizas un clúster de usuario con un cliente de la API de GKE On-Prem.


Solución alternativa:

Da de baja el clúster de administrador: 

    gcloud alpha container vmware admin-clusters unenroll ADMIN_CLUSTER_NAME --project CLUSTER_PROJECT --location=CLUSTER_LOCATION --allow-missing
y vuelve a inscribir el clúster de administrador.
Redes 1.15.0-1.15.2

No se reconoce orderPolicy de CoreDNS

OrderPolicy no se reconoce como un parámetro y no se usa. En su lugar, GKE en VMware siempre usa Random.

Este problema ocurre porque no se actualizó la plantilla de CoreDNS, lo que hace que se ignore orderPolicy.


Solución alternativa:

Actualiza la plantilla de CoreDNS y aplica la corrección. Esta solución persiste hasta que se actualiza.

  1. Edita la plantilla existente: 
    
kubectl edit cm -n kube-system coredns-template
    Reemplaza el contenido de la plantilla con lo siguiente: 
    
coredns-template: |-
  .:53 {
    errors
    health {
      lameduck 5s
    }
    ready
    kubernetes cluster.local in-addr.arpa ip6.arpa {
      pods insecure
      fallthrough in-addr.arpa ip6.arpa
    }
{{- if .PrivateGoogleAccess }}
    import zones/private.Corefile
{{- end }}
{{- if .RestrictedGoogleAccess }}
    import zones/restricted.Corefile
{{- end }}
    prometheus :9153
    forward . {{ .UpstreamNameservers }} {
      max_concurrent 1000
      {{- if ne .OrderPolicy "" }}
      policy {{ .OrderPolicy }}
      {{- end }}
    }
    cache 30
{{- if .DefaultDomainQueryLogging }}
    log
{{- end }}
    loop
    reload
    loadbalance
}{{ range $i, $stubdomain := .StubDomains }}
{{ $stubdomain.Domain }}:53 {
  errors
{{- if $stubdomain.QueryLogging }}
  log
{{- end }}
  cache 30
  forward . {{ $stubdomain.Nameservers }} {
    max_concurrent 1000
    {{- if ne $.OrderPolicy "" }}
    policy {{ $.OrderPolicy }}
    {{- end }}
  }
}
{{- end }}
Revisiones y actualizaciones 1.10, 1.11, 1.12, 1.13.0-1.13.7, 1.14.0-1.14.3

El estado de OnPremAdminCluster es incoherente entre el punto de control y la CR real

Ciertas condiciones de carrera podrían hacer que el estado OnPremAdminCluster sea inconsistente entre el punto de control y la CR real. Si ocurre el problema, podrías encontrar el siguiente error cuando actualices el clúster de administrador después de hacerlo:


Exit with error:
E0321 10:20:53.515562  961695 console.go:93] Failed to update the admin cluster: OnPremAdminCluster "gke-admin-rj8jr" is in the middle of a create/upgrade ("" -> "1.15.0-gke.123"), which must be completed before it can be updated
Failed to update the admin cluster: OnPremAdminCluster "gke-admin-rj8jr" is in the middle of a create/upgrade ("" -> "1.15.0-gke.123"), which must be completed before it can be updated
Para solucionar este problema, deberás editar el punto de control o inhabilitarlo para la actualización o actualización. Comunícate con nuestro equipo de asistencia al cliente para que continúe con la solución alternativa.
Operación 1.13.0-1.13.9, 1.14.0-1.14.5, 1.15.0-1.15.1

El proceso de conciliación cambia los certificados de administrador en los clústeres de administrador

GKE en VMware cambia los certificados de administrador en los planos de control del clúster de administrador con cada proceso de conciliación, como durante una actualización del clúster. Este comportamiento aumenta la posibilidad de obtener certificados no válidos para tu clúster de administrador, en especial, para los clústeres de la versión 1.15.

Si te afecta este problema, es posible que encuentres problemas como los siguientes:

  • Los certificados no válidos pueden provocar que se agote el tiempo de espera de los siguientes comandos y muestren errores:
    • gkectl create admin
    • gkectl upgrade amdin
    • gkectl update admin

    Estos comandos pueden mostrar errores de autorización como los siguientes:

    
Failed to reconcile admin cluster: unable to populate admin clients: failed to get admin controller runtime client: Unauthorized
  • Los registros de kube-apiserver del clúster de administrador pueden contener errores como los siguientes: 
    
Unable to authenticate the request" err="[x509: certificate has expired or is not yet valid...

Solución alternativa:

Actualiza a una versión de GKE en VMware con la corrección: 1.13.10+, 1.14.6+, 1.15.2+. Si no puedes realizar la actualización, comunícate con Atención al cliente de Cloud para resolver este problema.
Herramientas de redes, operación 1.10, 1.11, 1.12, 1.13, 1.14

Componentes de Anthos Network Gateway expulsados o pendientes debido a que falta la clase de prioridad

Los Pods de puerta de enlace de red en kube-system pueden mostrar un estado de Pending o Evicted, como se muestra en el siguiente resultado de ejemplo abreviado:


$ kubectl -n kube-system get pods | grep ang-node
ang-node-bjkkc     2/2     Running     0     5d2h
ang-node-mw8cq     0/2     Evicted     0     6m5s
ang-node-zsmq7     0/2     Pending     0     7h

Estos errores indican eventos de expulsión o una imposibilidad de programar Pods debido a los recursos del nodo. Como los Pods de la puerta de enlace de red de Anthos no tienen PriorityClass, tienen la misma prioridad predeterminada que otras cargas de trabajo. Cuando los nodos tienen recursos limitados, los Pods de la puerta de enlace de red pueden expulsarse. Este comportamiento es particularmente malo para el DaemonSet ang-node, ya que esos Pods deben programarse en un nodo específico y no se pueden migrar.


Solución alternativa:

Actualiza a la versión 1.15 o posterior.

Como solución a corto plazo, puedes asignar una PriorityClass de forma manual a los componentes de la puerta de enlace de red de Anthos. El controlador de GKE en VMware reemplaza estos cambios manuales durante un proceso de conciliación, como durante una actualización de clúster.

  • Asigna la PriorityClass system-cluster-critical a las implementaciones del controlador de clúster ang-controller-manager y autoscaler.
  • Asigna la PriorityClass system-node-critical al DaemonSet del nodo ang-daemon.
Revisiones y actualizaciones 1.12, 1.13, 1.14, 1.15.0 a 1.15.2

La actualización del clúster de administrador falla después de registrar el clúster con gcloud.

Después de usar gcloud para registrar un clúster de administrador con la sección gkeConnect no vacía, es posible que veas el siguiente error cuando intentes actualizar el clúster:


failed to register cluster: failed to apply Hub Mem\
bership: Membership API request failed: rpc error: code = InvalidArgument desc = InvalidFieldError for field endpoint.o\
n_prem_cluster.admin_cluster: field cannot be updated

Borra el espacio de nombres gke-connect: 


kubectl delete ns gke-connect --kubeconfig=ADMIN_KUBECONFIG
Obtén el nombre del clúster de administrador: 

kubectl get onpremadmincluster -n kube-system --kubeconfig=ADMIN_KUBECONFIG
Borra la membresía de la flota: 

gcloud container fleet memberships delete ADMIN_CLUSTER_NAME
y reanuda la actualización del clúster de administrador.
Operación 1.13.0-1.13.8, 1.14.0-1.14.5, 1.15.0-1.15.1

gkectl diagnose snapshot --log-since no puede limitar el período de los comandos de journalctl que se ejecutan en los nodos del clúster.

Esto no afecta la funcionalidad de tomar una instantánea del clúster, ya que esta todavía incluye todos los registros que se recopilan de forma predeterminada mediante la ejecución de journalctl en los nodos del clúster. Por lo tanto, no se pierde la información de depuración.
Instalación, actualizaciones y actualizaciones 1.9+, 1.10+, 1.11+, 1.12+

gkectl prepare windows falla

gkectl prepare windows no puede instalar Docker en las versiones de GKE en VMware anteriores a la 1.13 porque MicrosoftDockerProvider está obsoleto.


Solución alternativa:

La idea general para solucionar este problema es actualizar a GKE on VMware 1.13 y usar gkectl 1.13 para crear una plantilla de VM de Windows y, luego, crear grupos de nodos de Windows. Hay dos opciones para acceder a GKE en VMware 1.13 desde tu versión actual, como se muestra a continuación.

Nota: Tenemos opciones para solucionar este problema en tu versión actual sin necesidad de actualizar a la versión 1.13, pero necesitarán más pasos manuales. Comunícate con nuestro equipo de asistencia al cliente si deseas considerar esta opción.


Opción 1: Actualización Azul-verde

Puedes crear un clúster nuevo mediante la versión 1.13+ de GKE on VMware con grupos de nodos de Windows y migrar tus cargas de trabajo al clúster nuevo y, luego, eliminar el clúster actual. Se recomienda usar la versión secundaria más reciente de GKE en VMware.

Nota: Esto requerirá recursos adicionales para aprovisionar el clúster nuevo, pero disminuirá el tiempo de inactividad y las interrupciones para las cargas de trabajo existentes.


Opción 2: Borra los grupos de nodos de Windows y vuelve a agregarlos cuando actualices a GKE on VMware 1.13

Nota: Para esta opción, las cargas de trabajo de Windows no podrán ejecutarse hasta que el clúster se actualice a la versión 1.13 y se vuelvan a agregar los grupos de nodos de Windows.

  1. Borra los grupos de nodos de Windows existentes. Para ello, quita la configuración de los grupos de nodos de Windows del archivo user-cluster.yaml y, luego, ejecuta el siguiente comando: 
    
gkectl update cluster --kubeconfig=ADMIN_KUBECONFIG --config USER_CLUSTER_CONFIG_FILE
  2. Actualiza los clústeres de administrador y usuario solo de Linux a 1.12 según la guía de actualización del usuario para la versión secundaria de destino correspondiente.
  3. (Asegúrate de realizar este paso antes de actualizar a la versión 1.13). Asegúrate de que enableWindowsDataplaneV2: true esté configurado en la CR de OnPremUserCluster; de lo contrario, el clúster seguirá usando Docker para los grupos de nodos de Windows, que no será compatible con la plantilla de VM de Windows 1.13 recién creada que no tenga instalado Docker. Si no se configuró o si se establece como falsa, actualiza tu clúster para que se configure como verdadero en user-cluster.yaml y, luego, ejecuta lo siguiente: 
    
gkectl update cluster --kubeconfig=ADMIN_KUBECONFIG --config USER_CLUSTER_CONFIG_FILE
  4. Actualiza los clústeres de administrador y usuario exclusivos de Linux a 1.13 según la guía de actualización del usuario.
  5. Prepara la plantilla de VM de Windows con la versión 1.13 de gkectl: 
    
gkectl prepare windows --base-vm-template BASE_WINDOWS_VM_TEMPLATE_NAME --bundle-path 1.13_BUNDLE_PATH --kubeconfig=ADMIN_KUBECONFIG
  6. Vuelve a agregar la configuración del grupo de nodos de Windows a user-cluster.yaml con el campo OSImage configurado en la plantilla de VM de Windows recién creada.
  7. Actualiza el clúster para agregar grupos de nodos de Windows 
    
gkectl update cluster --kubeconfig=ADMIN_KUBECONFIG --config USER_CLUSTER_CONFIG_FILE
Instalación, actualizaciones y actualizaciones 1.13.0-1.13.9, 1.14.0-1.14.5, 1.15.0-1.15.1

La configuración de RootDistanceMaxSec no se aplica a ubuntu nodos

Se usará el valor predeterminado de 5 segundos para RootDistanceMaxSec en los nodos, en lugar de 20 segundos, que debería ser la configuración esperada. Si verificas el registro de inicio del nodo mediante una conexión SSH a la VM, que se encuentra en “/var/log/startup.log”, encontrarás el siguiente error:


+ has_systemd_unit systemd-timesyncd
/opt/bin/master.sh: line 635: has_systemd_unit: command not found

Si usas un RootDistanceMaxSec de 5 segundos, es posible que el reloj del sistema no esté sincronizado con el servidor NTP cuando la variación del reloj es superior a 5 segundos.


Solución alternativa:

Aplica el siguiente DaemonSet en tu clúster para configurar RootDistanceMaxSec:


apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: change-root-distance
  namespace: kube-system
spec:
  selector:
    matchLabels:
      app: change-root-distance
  template:
    metadata:
      labels:
        app: change-root-distance
    spec:
      hostIPC: true
      hostPID: true
      tolerations:
      # Make sure pods gets scheduled on all nodes.
      - effect: NoSchedule
        operator: Exists
      - effect: NoExecute
        operator: Exists
      containers:
      - name: change-root-distance
        image: ubuntu
        command: ["chroot", "/host", "bash", "-c"]
        args:
        - |
          while true; do
            conf_file="/etc/systemd/timesyncd.conf.d/90-gke.conf"
            if [ -f $conf_file ] && $(grep -q "RootDistanceMaxSec=20" $conf_file); then
              echo "timesyncd has the expected RootDistanceMaxSec, skip update"
            else
              echo "updating timesyncd config to RootDistanceMaxSec=20"
              mkdir -p /etc/systemd/timesyncd.conf.d
              cat > $conf_file << EOF
          [Time]
          RootDistanceMaxSec=20
          EOF
              systemctl restart systemd-timesyncd
            fi
            sleep 600
          done
        volumeMounts:
        - name: host
          mountPath: /host
        securityContext:
          privileged: true
      volumes:
      - name: host
        hostPath:
          path: /
Revisiones y actualizaciones 1.12.0-1.12.6, 1.13.0-1.13.6, 1.14.0-1.14.2

gkectl update admin falla debido a que el campo osImageType está vacío

Cuando uses la versión 1.13 gkectl para actualizar un clúster de administrador de la versión 1.12, es posible que veas el siguiente error:


Failed to update the admin cluster: updating OS image type in admin cluster
is not supported in "1.12.x-gke.x"

Cuando uses gkectl update admin para los clústeres de la versión 1.13 o 1.14, es posible que veas el siguiente mensaje en la respuesta:


Exit with error:
Failed to update the cluster: the update contains multiple changes. Please
update only one feature at a time

Si verificas el registro gkectl, es posible que veas que los múltiples cambios incluyen la configuración de osImageType de una string vacía a ubuntu_containerd.

Estos errores de actualización se deben al reabastecimiento incorrecto del campo osImageType en la configuración del clúster de administrador desde que se introdujo en la versión 1.9.


Solución alternativa:

Actualiza a una versión de GKE en VMware con la solución. Si no es posible realizar la actualización, comunícate con Atención al cliente de Cloud para resolver este problema.
Instalación, seguridad 1.13, 1.14, 1.15, 1.16

La SNI no funciona en clústeres de usuario con el plano de control V2

La capacidad de proporcionar un certificado de entrega adicional para el servidor de la API de Kubernetes de un clúster de usuario con authentication.sni no funciona cuando el plano de control V2 está habilitado ( enableControlplaneV2: true).


Solución alternativa:

Hasta que haya un parche de GKE en VMware disponible con la corrección, si necesitas usar SNI, inhabilita el plano de control V2 (enableControlplaneV2: false).
Instalación 1.0-1.11, 1.12, 1.13.0-1.13.9, 1.14.0-1.14.5, 1.15.0-1.15.1

$ en el nombre de usuario de registro privado provoca un error de inicio de la máquina del plano de control del administrador

La máquina del plano de control del administrador no se inicia cuando el nombre de usuario del registro privado contiene $. Cuando verifiques el /var/log/startup.log en la máquina del plano de control del administrador, verás el siguiente error: 


++ REGISTRY_CA_CERT=xxx
++ REGISTRY_SERVER=xxx
/etc/startup/startup.conf: line 7: anthos: unbound variable

Solución alternativa:

Usa un nombre de usuario de registro privado sin $ o usa una versión de GKE en VMware con la corrección.
Revisiones y actualizaciones 1.12.0-1.12.4

Advertencias de falsos positivos sobre cambios no admitidos durante la actualización del clúster de administrador

Cuando actualices los clústeres de administrador, verás las siguientes advertencias de falsos positivos en el registro, por lo que puedes ignorarlas. 


    console.go:47] detected unsupported changes: &v1alpha1.OnPremAdminCluster{
      ...
      - 		CARotation:        &v1alpha1.CARotationConfig{Generated: &v1alpha1.CARotationGenerated{CAVersion: 1}},
      + 		CARotation:        nil,
      ...
    }
Revisiones y actualizaciones 1.13.0-1.13.9, 1.14.0-1.14.5, 1.15.0-1.15.1

No se pudo actualizar el clúster de usuario después de la rotación de claves de firma de KSA

Después de rotar las claves de firma KSA y, luego, actualizar un clúster de usuario, gkectl update puede fallar y mostrar el siguiente mensaje de error: 


Failed to apply OnPremUserCluster 'USER_CLUSTER_NAME-gke-onprem-mgmt/USER_CLUSTER_NAME':
admission webhook "vonpremusercluster.onprem.cluster.gke.io" denied the request:
requests must not decrement *v1alpha1.KSASigningKeyRotationConfig Version, old version: 2, new version: 1"


Solución alternativa:

Vuelve a cambiar la versión de la clave de firma KSA a 1, pero conserva los datos más recientes de la clave:
  1. Verifica el secreto del clúster de administrador en el espacio de nombres USER_CLUSTER_NAME y obtén el nombre del secreto ksa-signed-key: 
    
kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME get secrets | grep ksa-signing-key
  2. Copia el secreto ksa-signed-key y asigna el nombre service-account-cert al secreto copiado: 
    
kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME get secret KSA-KEY-SECRET-NAME -oyaml | \
sed 's/ name: .*/ name: service-account-cert/' | \
kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME apply -f -
  3. Borra el secreto ksa-signed-key anterior: 
    
kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME delete secret KSA-KEY-SECRET-NAME
  4. Actualiza el campo data.data en ksa-signed-key-rotation-stage configmap a '{"tokenVersion":1,"privateKeyVersion":1,"publicKeyVersions":[1]}': 
    
kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME \
edit configmap ksa-signing-key-rotation-stage
  5. Inhabilita el webhook de validación para editar la información de la versión en el recurso personalizado OnPremUserCluster: 
    
kubectl --kubeconfig=ADMIN_KUBECONFIG patch validatingwebhookconfiguration onprem-user-cluster-controller -p '
webhooks:
- name: vonpremnodepool.onprem.cluster.gke.io
  rules:
  - apiGroups:
    - onprem.cluster.gke.io
    apiVersions:
    - v1alpha1
    operations:
    - CREATE
    resources:
    - onpremnodepools
- name: vonpremusercluster.onprem.cluster.gke.io
  rules:
  - apiGroups:
    - onprem.cluster.gke.io
    apiVersions:
    - v1alpha1
    operations:
    - CREATE
    resources:
    - onpremuserclusters
'
  6. Actualiza el campo spec.ksaSigningKeyRotation.generated.ksaSigningKeyRotation a 1 en tu recurso personalizado OnPremUserCluster: 
    
kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME-gke-onprem-mgmt \
edit onpremusercluster USER_CLUSTER_NAME
  7. Espera hasta que el clúster de usuario de destino esté listo. Puedes verificar el estado de la siguiente manera: 
    
kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME-gke-onprem-mgmt \
get onpremusercluster
  8. Restablece el webhook de validación del clúster de usuario: 
    
kubectl --kubeconfig=ADMIN_KUBECONFIG patch validatingwebhookconfiguration onprem-user-cluster-controller -p '
webhooks:
- name: vonpremnodepool.onprem.cluster.gke.io
  rules:
  - apiGroups:
    - onprem.cluster.gke.io
    apiVersions:
    - v1alpha1
    operations:
    - CREATE
    - UPDATE
    resources:
    - onpremnodepools
- name: vonpremusercluster.onprem.cluster.gke.io
  rules:
  - apiGroups:
    - onprem.cluster.gke.io
    apiVersions:
    - v1alpha1
    operations:
    - CREATE
    - UPDATE
    resources:
    - onpremuserclusters
'
  9. Evita otra rotación de claves de firma de KSA hasta que el clúster se actualice a la versión con la corrección.
Operación 1.13.1+, 1.14, 1. 1.16

Los servidores virtuales de BIG-IP de F5 no se limpian cuando Terraform borra los clústeres de usuario.

Cuando usas Terraform para borrar un clúster de usuario con un balanceador de cargas de BIG-IP de F5, los servidores virtuales de BIG-IP de F5 no se quitan después de la eliminación del clúster.


Solución alternativa:

Para quitar los recursos de F5, sigue los pasos para limpiar una partición F5 del clúster de usuario.
Instalación, actualizaciones y actualizaciones 1.13.8, 1.14.4

tipo clúster extrae imágenes de contenedor de docker.io

Si creas un clúster de administrador versión 1.13.8 o 1.14.4, o actualizas un clúster de administrador a la versión 1.13.8 o 1.14.4, el clúster de tipo extrae las siguientes imágenes de contenedor desde docker.io:

  • docker.io/kindest/kindnetd
  • docker.io/kindest/local-path-provisioner
  • docker.io/kindest/local-path-helper

    • Si no se puede acceder a docker.io desde tu estación de trabajo de administrador, la creación o actualización del clúster de administrador no muestra el tipo de clúster. Cuando ejecutas el siguiente comando en la estación de trabajo de administrador, se muestran los contenedores correspondientes pendientes con ErrImagePull:

    
docker exec gkectl-control-plane kubectl get pods -A

    La respuesta contiene entradas como las siguientes:

    
...
kube-system         kindnet-xlhmr                             0/1
    ErrImagePull  0    3m12s
...
local-path-storage  local-path-provisioner-86666ffff6-zzqtp   0/1
    Pending       0    3m12s
...

    Estas imágenes de contenedor deben cargarse previamente en la imagen del contenedor del clúster de tipo. Sin embargo, el tipo v0.18.0 tiene un problema con las imágenes de contenedor precargadas, que hace que se extraigan de Internet por error.


    Solución alternativa:

    Ejecuta los siguientes comandos en la estación de trabajo de administrador mientras el clúster de administrador está pendiente de creación o actualización:

    
docker exec gkectl-control-plane ctr -n k8s.io images tag docker.io/kindest/kindnetd:v20230330-48f316cd@sha256:c19d6362a6a928139820761475a38c24c0cf84d507b9ddf414a078cf627497af docker.io/kindest/kindnetd:v20230330-48f316cd
docker exec gkectl-control-plane ctr -n k8s.io images tag docker.io/kindest/kindnetd:v20230330-48f316cd@sha256:c19d6362a6a928139820761475a38c24c0cf84d507b9ddf414a078cf627497af docker.io/kindest/kindnetd@sha256:c19d6362a6a928139820761475a38c24c0cf84d507b9ddf414a078cf627497af

docker exec gkectl-control-plane ctr -n k8s.io images tag docker.io/kindest/local-path-helper:v20230330-48f316cd@sha256:135203f2441f916fb13dad1561d27f60a6f11f50ec288b01a7d2ee9947c36270 docker.io/kindest/local-path-helper:v20230330-48f316cd
docker exec gkectl-control-plane ctr -n k8s.io images tag docker.io/kindest/local-path-helper:v20230330-48f316cd@sha256:135203f2441f916fb13dad1561d27f60a6f11f50ec288b01a7d2ee9947c36270 docker.io/kindest/local-path-helper@sha256:135203f2441f916fb13dad1561d27f60a6f11f50ec288b01a7d2ee9947c36270

docker exec gkectl-control-plane ctr -n k8s.io images tag docker.io/kindest/local-path-provisioner:v0.0.23-kind.0@sha256:f2d0a02831ff3a03cf51343226670d5060623b43a4cfc4808bd0875b2c4b9501 docker.io/kindest/local-path-provisioner:v0.0.23-kind.0
docker exec gkectl-control-plane ctr -n k8s.io images tag docker.io/kindest/local-path-provisioner:v0.0.23-kind.0@sha256:f2d0a02831ff3a03cf51343226670d5060623b43a4cfc4808bd0875b2c4b9501 docker.io/kindest/local-path-provisioner@sha256:f2d0a02831ff3a03cf51343226670d5060623b43a4cfc4808bd0875b2c4b9501
    Operación 1.13.0-1.13.7, 1.14.0-1.14.4, 1.15.0

    La conmutación por error no se realiza correctamente en el clúster de usuario y el clúster de administrador del plano de control de HA cuando la red filtra las solicitudes de GARP duplicadas.

    Si las VMs del clúster están conectadas con un interruptor que filtra las solicitudes de GARP (ARP injustificados) duplicadas, la elección del líder de keepalived podría encontrar una condición de carrera, lo que provoca que algunos nodos tengan entradas incorrectas en la tabla de ARP.

    Los nodos afectados pueden ping la VIP del plano de control, pero se agotará el tiempo de espera de una conexión TCP a la VIP del plano de control.


    Solución alternativa:

    Ejecuta el siguiente comando en cada nodo del plano de control del clúster afectado: 
    
    iptables -I FORWARD -i ens192 --destination CONTROL_PLANE_VIP -j DROP
    Actualizaciones 1.13.0-1.13.7, 1.14.0-1.14.4, 1.15.0

    vsphere-csi-controller debe reiniciarse después de la rotación del certificado de vCenter

    vsphere-csi-controller debe actualizar su secreto de vCenter después de la rotación del certificado de vCenter. Sin embargo, el sistema actual no reinicia correctamente los Pods de vsphere-csi-controller, lo que provoca que vsphere-csi-controller falle después de la rotación.

    Solución alternativa:

    En el caso de los clústeres creados en la versión 1.13 y posteriores, sigue las instrucciones que se indican a continuación para reiniciar vsphere-csi-controller 

    
kubectl --kubeconfig=ADMIN_KUBECONFIG rollout restart deployment vsphere-csi-controller -n kube-system
    Instalación 1.10.3-1.10.7, 1.11, 1.12, 1.13.0-1.13.1

    La creación del clúster de administrador no falla en los errores de registro del clúster.

    Incluso cuando el registro del clúster falla durante la creación del clúster de administrador, el comando gkectl create admin no falla en el error y puede completarse con éxito. En otras palabras, la creación del clúster de administrador podría “tener éxito” sin registrarse en una flota.

    Para identificar el síntoma, puedes buscar los siguientes mensajes de error en el registro de “gkectl create admin”: 
    
Failed to register admin cluster

    También puedes verificar si puedes encontrar el clúster entre los clústeres registrados en la consola de Cloud.

    Solución alternativa:

    En el caso de los clústeres creados en la versión 1.12 y posteriores, sigue las instrucciones para volver a intentar el registro del clúster de administrador después de la creación del clúster. Para los clústeres creados en versiones anteriores,

    1. Agrega un par clave-valor falso, como "foo: bar", a tu archivo de claves de SA del registro de conexión
    2. Ejecuta gkectl update admin para volver a registrar el clúster de administrador.

    Actualizaciones 1.10, 1.11, 1.12, 1.13.0 a 1.13.1

    Es posible que se omita el registro nuevo del clúster de administrador durante la actualización del clúster de administrador

    Si se agota el tiempo de espera de los nodos del plano de control del usuario durante la actualización del clúster de administrador, este no se volverá a registrar con la versión actualizada del agente de conexión.


    Solución alternativa:

    Verifica si el clúster se muestra entre clústeres registrados. Como paso opcional, accede al clúster después de configurar la autenticación. Si el clúster sigue registrado, puedes omitir las siguientes instrucciones para reintentar el registro. En el caso de los clústeres actualizados a la versión 1.12 y posteriores, sigue las instrucciones para volver a intentar el registro del clúster de administrador después de su creación. Para los clústeres actualizados a versiones anteriores, haz lo siguiente:
    1. Agrega un par clave-valor falso, como "foo: bar", a tu archivo de claves de SA del registro de conexión
    2. Ejecuta gkectl update admin para volver a registrar el clúster de administrador.

    Configuración 1.15.0

    Mensaje de error falso sobre vCenter.dataDisk

    En el caso de un clúster de administrador de alta disponibilidad, gkectl prepare muestra este mensaje de error falso:

    
vCenter.dataDisk must be present in the AdminCluster spec

    Solución alternativa:

    Puedes ignorar este mensaje de error.
    VMware 1.15.0

    La creación del grupo de nodos falla debido a reglas de afinidad redundantes de VM-host

    Durante la creación de un grupo de nodos que usa afinidad de host de VM, una condición de carrera puede provocar la creación de varias reglas de afinidad de host de VM con el mismo nombre. Esto puede provocar que falle la creación del grupo de nodos.


    Solución alternativa:

    Quita las reglas redundantes antiguas para poder continuar con la creación del grupo de nodos. Estas reglas se denominan [USER_CLUSTER_NAME]-[HASH].
    Operación 1.15.0

    Es posible que gkectl repair admin-master falle debido a failed to delete the admin master node object and reboot the admin master VM

    El comando gkectl repair admin-master puede fallar debido a una condición de carrera con el siguiente error. 

    
Failed to repair: failed to delete the admin master node object and reboot the admin master VM


    Solución alternativa:

    Este comando es idempotente. Se puede volver a ejecutar de forma segura hasta que el comando tenga éxito.
    Revisiones y actualizaciones 1.15.0

    Los Pods permanecen en el estado Error después de la recreación o actualización de un nodo del plano de control.

    Después de volver a crear o actualizar un nodo del plano de control, es posible que ciertos Pods queden en el estado Failed debido a una falla del predicado de NodeAffinity. Estos Pods con errores no afectan las operaciones ni el estado normales del clúster.


    Solución alternativa:

    Puedes ignorar los Pods con errores o borrarlos de forma manual.
    Seguridad y configuración 1.15.0-1.15.1

    OnPremUserCluster no está listo debido a las credenciales de registro privado

    Si usas credenciales preparadas y un registro privado, pero no configuraste credenciales preparadas para tu registro privado, es posible que OnPremUserCluster no esté listo y veas el siguiente mensaje de error: 

    
failed to check secret reference for private registry …


    Solución alternativa:

    Prepara las credenciales de registro privado para el clúster de usuario según las instrucciones en Configura las credenciales preparadas.

    Revisiones y actualizaciones 1.15.0

    gkectl upgrade admin falla con StorageClass standard sets the parameter diskformat which is invalid for CSI Migration

    Durante gkectl upgrade admin, la verificación previa del almacenamiento para la migración de CSI verifica que las StorageClasses no tengan parámetros que se ignoren después de la migración de CSI. Por ejemplo, si hay una StorageClass con el parámetro diskformat, gkectl upgrade admin marca la StorageClass y, luego, informa una falla en la validación de la solicitud preliminar. Los clústeres de administrador creados en GKE en VMware 1.10 y antes tienen una StorageClass con diskformat: thin, que fallará esta validación; sin embargo, esta StorageClass seguirá funcionando bien después de la migración de CSI. Estas fallas se deben interpretar como advertencias.

    Para obtener más información, consulta la sección del parámetro StorageClass en Migra volúmenes de vSphere de árbol al complemento de Container Storage de vSphere.


    Solución alternativa:

    Después de confirmar que tu clúster tiene una StorageClass con parámetros ignorados después de la migración de CSI, ejecuta gkectl upgrade admin con la marca --skip-validation-cluster-health.
    Almacenamiento 1.15, 1.16

    Los volúmenes de vSphere migrados mediante el sistema de archivos de Windows no se pueden usar con el controlador de CSI de vSphere

    En ciertas condiciones, los discos se pueden conectar como de solo lectura a los nodos de Windows. Esto hace que el volumen correspondiente sea de solo lectura dentro de un Pod. Es más probable que este problema ocurra cuando un conjunto nuevo de nodos reemplaza uno anterior (por ejemplo, una actualización del clúster o del grupo de nodos). Es posible que las cargas de trabajo con estado que antes funcionaban bien no puedan escribir en sus volúmenes en el nuevo conjunto de nodos.


    Solución alternativa:

    1. Obtén el UID del Pod que no puede escribir en su volumen: 
      
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get pod \
    POD_NAME --namespace POD_NAMESPACE \
    -o=jsonpath='{.metadata.uid}{"\n"}'
    2. Usa PersistentVolumeClaim para obtener su nombre: 
      
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get pvc \
    PVC_NAME --namespace POD_NAMESPACE \
    -o jsonpath='{.spec.volumeName}{"\n"}'
    3. Determina el nombre del nodo en el que se ejecuta el Pod: 
      
kubectl --kubeconfig USER_CLUSTER_KUBECONFIGget pods \
    --namespace POD_NAMESPACE \
    -o jsonpath='{.spec.nodeName}{"\n"}'
    4. Obtén acceso de PowerShell al nodo, ya sea a través de SSH o de la interfaz web de vSphere.
    5. Establece las variables de entorno: 
      
PS C:\Users\administrator> pvname=PV_NAME
PS C:\Users\administrator> podid=POD_UID
    6. Identifica el número de disco del disco asociado con el PersistentVolume: 
      
PS C:\Users\administrator> disknum=(Get-Partition -Volume (Get-Volume -UniqueId ("\\?\"+(Get-Item (Get-Item
"C:\var\lib\kubelet\pods\$podid\volumes\kubernetes.io~csi\$pvname\mount").Target).Target))).DiskNumber
    7. Verifica que el disco sea readonly: 
      
PS C:\Users\administrator> (Get-Disk -Number $disknum).IsReadonly
      El resultado debería ser True.
    8. Establece readonly en false. 
      
PS C:\Users\administrator> Set-Disk -Number $disknum -IsReadonly $false
PS C:\Users\administrator> (Get-Disk -Number $disknum).IsReadonly
    9. Borra el Pod para que se reinicie: 
      
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG delete pod POD_NAME \
    --namespace POD_NAMESPACE
    10. El Pod debe programarse en el mismo nodo. Sin embargo, en caso de que el Pod se programe en un nodo nuevo, es posible que debas repetir los pasos anteriores en el nodo nuevo.

    Revisiones y actualizaciones 1.12, 1.13.0-1.13.7, 1.14.0-1.14.4

    vsphere-csi-secret no se actualiza después del gkectl update credentials vsphere --admin-cluster

    Si actualizas las credenciales de vSphere para un clúster de administrador después de actualizar las credenciales del clúster, es posible que vsphere-csi-secret en el espacio de nombres kube-system en el clúster de administrador aún use la credencial anterior.


    Solución alternativa:

    1. Obtén el nombre del secreto vsphere-csi-secret: 
      
kubectl --kubeconfig=ADMIN_KUBECONFIG -n=kube-system get secrets | grep vsphere-csi-secret
    2. Actualiza los datos del secreto vsphere-csi-secret que obtuviste en el paso anterior: 
      
kubectl --kubeconfig=ADMIN_KUBECONFIG -n=kube-system patch secret CSI_SECRET_NAME -p \
  "{\"data\":{\"config\":\"$( \
    kubectl --kubeconfig=ADMIN_KUBECONFIG -n=kube-system get secrets CSI_SECRET_NAME -ojsonpath='{.data.config}' \
      | base64 -d \
      | sed -e '/user/c user = \"VSPHERE_USERNAME_TO_BE_UPDATED\"' \
      | sed -e '/password/c password = \"VSPHERE_PASSWORD_TO_BE_UPDATED\"' \
      | base64 -w 0 \
    )\"}}"
    3. Reinicia vsphere-csi-controller: 
      
kubectl --kubeconfig=ADMIN_KUBECONFIG -n=kube-system rollout restart deployment vsphere-csi-controller
    4. Puedes hacer un seguimiento del estado del lanzamiento con los siguientes métodos: 
      
kubectl --kubeconfig=ADMIN_KUBECONFIG -n=kube-system rollout status deployment vsphere-csi-controller
      Después de que la implementación se haya lanzado de forma correcta, el controlador debe usar el vsphere-csi-secret actualizado.
    Revisiones y actualizaciones 1.10, 1.11, 1.12.0-1.12.6, 1.13.0-1.13.6, 1.14.0-1.14.2

    Bucle de falla audit-proxy cuando se habilitan los registros de auditoría de Cloud con gkectl update cluster

    audit-proxy puede fallar en un bucle debido a un --cluster-name vacío. Este comportamiento se debe a un error en la lógica de actualización, en el que el nombre del clúster no se propaga al manifiesto del contenedor o Pod del proxy de auditoría.


    Solución alternativa:

    Para un clúster de usuario del plano de control v2 con enableControlplaneV2: true, conéctate a la máquina del plano de control del usuario con SSH y actualiza /etc/kubernetes/manifests/audit-proxy.yaml con --cluster_name=USER_CLUSTER_NAME.

    En un clúster de usuario del plano de control v1, edita el contenedor audit-proxy en el StatefulSet de kube-apiserver para agregar --cluster_name=USER_CLUSTER_NAME:

    
kubectl edit statefulset kube-apiserver -n USER_CLUSTER_NAME --kubeconfig=ADMIN_CLUSTER_KUBECONFIG
    Revisiones y actualizaciones 1.11, 1.12, 1.13.0-1.13.5, 1.14.0-1.14.1

    Una reimplementación adicional del plano de control justo después del gkectl upgrade cluster

    Inmediatamente después de gkectl upgrade cluster, es posible que los Pods del plano de control se vuelvan a implementar. El estado del clúster de gkectl list clusters cambia de RUNNING A RECONCILING. Es posible que se agote el tiempo de espera de las solicitudes al clúster de usuario.

    Este comportamiento se debe a que la rotación del certificado del plano de control ocurre automáticamente después de gkectl upgrade cluster.

    Este problema solo ocurre con los clústeres de usuario que NO usan la versión 2 del plano de control.


    Solución alternativa:

    Espera a que el estado del clúster vuelva a cambiar a RUNNING en gkectl list clusters o actualiza a versiones con la corrección: 1.13.6+, 1.14.2+ o 1.15+.
    Revisiones y actualizaciones 1.12.7

    Se quitó la versión errónea 1.12.7-gke.19

    GKE en VMware 1.12.7-gke.19 es una versión no válida y no debes usarla. Se quitaron los artefactos del bucket de Cloud Storage.

    Solución alternativa:

    En su lugar, usa la versión 1.12.7-gke.20.
    Revisiones y actualizaciones 1.12.0+, 1.13.0-1.13.7, 1.14.0-1.14.3

    gke-connect-agent continúa usando la imagen más antigua después de que se actualiza la credencial de registro

    Si actualizas la credencial de registro con uno de los siguientes métodos:

    • gkectl update credentials componentaccess si no usas el registro privado
    • gkectl update credentials privateregistry si usas el registro privado

    Es posible que gke-connect-agent continúe usando la imagen antigua o que los Pods gke-connect-agent no se puedan extraer debido a ImagePullBackOff.

    Este problema se solucionará en las versiones 1.13.8, 1.14.4 y posteriores de GKE on VMware.


    Solución alternativa:

    Opción 1: Vuelve a implementar gke-connect-agent de forma manual:

    1. Borra el espacio de nombres gke-connect: 
      
kubectl --kubeconfig=KUBECONFIG delete namespace gke-connect
    2. Vuelve a implementar gke-connect-agent con la clave de la cuenta de servicio de registro original (no es necesario actualizar la clave):

      Para el clúster de administrador: 
      
gkectl update credentials register --kubeconfig=ADMIN_CLUSTER_KUBECONFIG --config ADMIN_CLUSTER_CONFIG_FILE --admin-cluster
      Para el clúster de usuario: 
      
gkectl update credentials register --kubeconfig=ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG_FILE

    Opción 2: Puedes cambiar de forma manual los datos del secreto de extracción de imagen regcred que usa la implementación de gke-connect-agent:

    
kubectl --kubeconfig=KUBECONFIG -n=gke-connect patch secrets regcred -p "{\"data\":{\".dockerconfigjson\":\"$(kubectl --kubeconfig=KUBECONFIG -n=kube-system get secrets private-registry-creds -ojsonpath='{.data.\.dockerconfigjson}')\"}}"

    Opción 3: Puedes agregar el secreto de extracción de imagen predeterminado para tu clúster en la implementación gke-connect-agent de la siguiente manera:

    1. Copia el secreto predeterminado en el espacio de nombres gke-connect: 
      
kubectl --kubeconfig=KUBECONFIG -n=kube-system get secret private-registry-creds -oyaml | sed 's/ namespace: .*/ namespace: gke-connect/' | kubectl --kubeconfig=KUBECONFIG -n=gke-connect apply -f -
    2. Obtén el nombre de implementación de gke-connect-agent: 
      
kubectl --kubeconfig=KUBECONFIG -n=gke-connect get deployment | grep gke-connect-agent
    3. Agrega el secreto predeterminado a la implementación de gke-connect-agent: 
      
kubectl --kubeconfig=KUBECONFIG -n=gke-connect patch deployment DEPLOYMENT_NAME -p '{"spec":{"template":{"spec":{"imagePullSecrets": [{"name": "private-registry-creds"}, {"name": "regcred"}]}}}}'
    Instalación 1.13, 1.14

    Se produjo un error al verificar la configuración del balanceo de cargas manual.

    Cuando valides la configuración antes de crear un clúster con un balanceador de cargas manual ejecutando gkectl check-config, el comando fallará y mostrará los siguientes mensajes de error.

    
 - Validation Category: Manual LB    Running validation check for "Network
configuration"...panic: runtime error: invalid memory address or nil pointer
dereference

    Solución alternativa:

    Opción 1: Puedes usar las versiones del parche 1.13.7 y 1.14.4 que incluirán la corrección.

    Opción 2: También puedes ejecutar el mismo comando para validar la configuración, pero omitir la validación del balanceador de cargas.

    
gkectl check-config --skip-validation-load-balancer
    Operación 1.0, 1.1, 1.2, 1.3, 1.4, 1.5, 1.6, 1.7, 1.8, 1.9, 1.10, 1.11, 1.12, 1.13 y 1.14

    etcd ver hambre

    Los clústeres que ejecutan la versión de etcd 3.4.13 o versiones anteriores pueden experimentar limitaciones de reloj y supervisión de recursos no operativos, lo que puede generar los siguientes problemas:

    • Se interrumpe la programación del Pod
    • No se pueden registrar los nodos
    • kubelet no observa cambios en el Pod

    Estos problemas pueden hacer que el clúster no funcione.

    Este problema se solucionó en las versiones 1.12.7, 1.13.6, 1.14.3 y posteriores de GKE en VMware. Estas versiones más recientes usan la versión de etcd 3.4.21. Este problema afecta a todas las versiones anteriores de GKE en VMware.

    Solución alternativa

    Si no puedes actualizar de inmediato, puedes mitigar el riesgo de falla del clúster si reduces la cantidad de nodos en tu clúster. Quita los nodos hasta que la métrica etcd_network_client_grpc_sent_bytes_total sea inferior a 300 MBps.

    Para ver esta métrica en el Explorador de métricas, sigue estos pasos:

    1. Ve al Explorador de métricas en la consola de Google Cloud:

      Ir al Explorador de métricas

    2. Selecciona la pestaña Configuración.
    3. Expande Seleccionar una métrica, ingresa Kubernetes Container en la barra de filtros y, luego, utiliza los submenús para seleccionar la métrica:
      1. En el menú Recursos activos, selecciona Contenedor de Kubernetes.
      2. En el menú Categorías de métricas activas, selecciona Anthos.
      3. En el menú Métricas activas, selecciona etcd_network_client_grpc_sent_bytes_total.
      4. Haz clic en Aplicar.
    Revisiones y actualizaciones 1.10, 1.11, 1.12, 1.13 y 1.14

    GKE Identity Service puede generar latencias del plano de control

    Cuando se reinician o actualizan los clústeres, GKE Identity Service puede sobrecargarse por el tráfico compuesto por tokens JWT vencidos que se reenvían desde kube-apiserver hacia GKE Identity Service a través del webhook de autenticación. Aunque GKE Identity Service no tiene un bucle de fallas, deja de responder y deja de entregar solicitudes adicionales. En última instancia, este problema genera latencias más altas del plano de control.

    Este problema se corrigió en las siguientes versiones de GKE on VMware:

    • 1.12.6+
    • 1.13.6+
    • 1.14.2+

    Para determinar si este problema te afecta, sigue estos pasos:

    1. Verifica si se puede acceder al extremo de GKE Identity Service de forma externa: 
      
curl -s -o /dev/null -w "%{http_code}" \
    -X POST https://CLUSTER_ENDPOINT/api/v1/namespaces/anthos-identity-service/services/https:ais:https/proxy/authenticate -d '{}'

      Reemplaza CLUSTER_ENDPOINT por la VIP del plano de control y el puerto del balanceador de cargas del plano de control para tu clúster (por ejemplo, 172.16.20.50:443).

      Si te afecta este problema, el comando mostrará un código de estado 400. Si se agota el tiempo de espera de la solicitud, reinicia el Pod ais y vuelve a ejecutar el comando curl para ver si se resuelve el problema. Si obtienes un código de estado de 000, significa que el problema se resolvió y terminó. Si aún recibes un código de estado 400, el servidor HTTP de GKE Identity Service no se inicia. En este caso, continúa.

    2. Verifica los registros de GKE Identity Service y kube-apiserver:
      1. Verifica el registro del servicio de identidad de GKE: 
        
kubectl logs -f -l k8s-app=ais -n anthos-identity-service \
    --kubeconfig KUBECONFIG

        Si el registro contiene una entrada como la siguiente, entonces te afecta este problema:

        
I0811 22:32:03.583448      32 authentication_plugin.cc:295] Stopping OIDC authentication for ???. Unable to verify the OIDC ID token: JWT verification failed: The JWT does not appear to be from this identity provider. To match this provider, the 'aud' claim must contain one of the following audiences:
      2. Verifica los registros kube-apiserver de los clústeres:

        En los siguientes comandos, KUBE_APISERVER_POD es el nombre del Pod kube-apiserver en el clúster determinado.

        Clúster de administrador:

        
kubectl --kubeconfig ADMIN_KUBECONFIG logs \
    -n kube-system KUBE_APISERVER_POD kube-apiserver

        Clúster de usuario:

        
kubectl --kubeconfig ADMIN_KUBECONFIG logs \
    -n USER_CLUSTER_NAME KUBE_APISERVER_POD kube-apiserver

        Si los registros kube-apiserver contienen entradas como las siguientes, este problema te afectará:

        
E0811 22:30:22.656085       1 webhook.go:127] Failed to make webhook authenticator request: error trying to reach service: net/http: TLS handshake timeout
E0811 22:30:22.656266       1 authentication.go:63] "Unable to authenticate the request" err="[invalid bearer token, error trying to reach service: net/http: TLS handshake timeout]"

    Solución alternativa

    Si no puedes actualizar tus clústeres de inmediato para obtener la solución, puedes identificar y reiniciar los Pods infractores como solución alternativa:

    1. Aumenta el nivel de verbosidad del servicio de identidad de GKE a 9: 
      
kubectl patch deployment ais -n anthos-identity-service --type=json \
    -p='[{"op": "add", "path": "/spec/template/spec/containers/0/args/-", \
    "value":"--vmodule=cloud/identity/hybrid/charon/*=9"}]' \
    --kubeconfig KUBECONFIG
    2. Revisa el registro de GKE Identity Service para el contexto del token no válido: 
      
kubectl logs -f -l k8s-app=ais -n anthos-identity-service \
    --kubeconfig KUBECONFIG
    3. Para obtener la carga útil del token asociada con cada contexto de token no válido, analiza cada secreto de cuenta de servicio relacionado con el siguiente comando: 
      
kubectl -n kube-system get secret SA_SECRET \
    --kubeconfig KUBECONFIG \
    -o jsonpath='{.data.token}' | base64 --decode
    4. Para decodificar el token y ver el nombre del pod de origen y el espacio de nombres, copia el token al depurador en jwt.io.
    5. Reinicia los Pods identificados a partir de los tokens.
    Operación 1.8, 1.9, 1.10

    El aumento del uso de memoria de los Pods de mantenimiento de etcd

    Los Pods de mantenimiento de etcd que usan la imagen etcddefrag:gke_master_etcddefrag_20210211.00_p0 se ven afectados. El contenedor “etcddefrag” abre una nueva conexión al servidor de etcd durante cada ciclo de desfragmentación y las conexiones antiguas no se limpian.


    Solución alternativa:

    Opción 1: Actualiza a la versión más reciente del parche de 1.8 a 1.11, que contiene la corrección.

    Opción 2: Si usas una versión de parche anterior a 1.9.6 y 1.10.3, debes reducir verticalmente la escala del Pod de mantenimiento de etcd para los clústeres de administrador y de usuario:

    
kubectl scale --replicas 0 deployment/gke-master-etcd-maintenance -n USER_CLUSTER_NAME --kubeconfig ADMIN_CLUSTER_KUBECONFIG
kubectl scale --replicas 0 deployment/gke-master-etcd-maintenance -n kube-system --kubeconfig ADMIN_CLUSTER_KUBECONFIG
    Operación 1.9, 1.10, 1.11, 1.12, 1.13

    Pasar las verificaciones de estado de los Pods del plano de control del clúster de usuario

    Tanto el controlador de estado del clúster como el comando gkectl diagnose cluster realizan un conjunto de verificaciones de estado, incluidas las verificaciones de estado de los Pods en los espacios de nombres. Sin embargo, comienzan a omitir por error los Pods del plano de control del usuario. Si usas el modo del plano de control v2, esto no afectará tu clúster.


    Solución alternativa:

    Esto no afectará ninguna carga de trabajo ni administración de clústeres. Si quieres verificar el estado de los Pods del plano de control, puedes ejecutar los siguientes comandos:

    
kubectl get pods -owide -n USER_CLUSTER_NAME --kubeconfig ADMIN_CLUSTER_KUBECONFIG
    Revisiones y actualizaciones 1.6+, 1.7+

    Las actualizaciones del clúster de administrador 1.6 y 1.7 pueden verse afectadas por el redireccionamiento k8s.gcr.io -> registry.k8s.io

    Kubernetes redirecciona el tráfico de k8s.gcr.io a registry.k8s.io el 20/3/2023. En GKE on VMware 1.6.x y 1.7.x, las actualizaciones del clúster de administrador usan la imagen de contenedor k8s.gcr.io/pause:3.2. Si usas un proxy para la estación de trabajo de administrador y el proxy no permite registry.k8s.io y la imagen de contenedor k8s.gcr.io/pause:3.2 no se almacena en caché de forma local, las actualizaciones del clúster de administrador fallarán cuando se extraiga la imagen de contenedor.


    Solución alternativa:

    Agrega registry.k8s.io a la lista de entidades permitidas del proxy para la estación de trabajo de administrador.
    Redes 1.10, 1.11, 1.12.0-1.12.6, 1.13.0-1.13.6, 1.14.0-1.14.2

    Falla de validación de Seesaw en la creación del balanceador de cargas

    gkectl create loadbalancer falla y muestra el siguiente mensaje de error:

    
- Validation Category: Seesaw LB - [FAILURE] Seesaw validation: xxx cluster lb health check failed: LB"xxx.xxx.xxx.xxx" is not healthy: Get "http://xxx.xxx.xxx.xxx:xxx/healthz": dial tcpxxx.xxx.xxx.xxx:xxx: connect: no route to host

    Esto se debe a que el archivo del grupo de sube y baja ya existe. Además, la comprobación preliminar intenta validar un balanceador de cargas de sube y baja inexistente.

    Solución alternativa:

    Quita el archivo del grupo de sube y baja existente de este clúster. El nombre de archivo es seesaw-for-gke-admin.yaml para el clúster de administrador y seesaw-for-{CLUSTER_NAME}.yaml para un clúster de usuario.
    Redes 1.14

    Tiempos de espera de la aplicación causados por errores de inserción de tablas de conntrack

    La versión 1.14 de GKE en VMware es susceptible a fallas de inserción de tablas en el seguimiento de conexiones de netfilter (conntrack) cuando se usan imágenes del sistema operativo Ubuntu o COS. Las fallas de inserción generan tiempos de espera aleatorios de la aplicación y pueden ocurrir incluso cuando la tabla conntrack tiene espacio para entradas nuevas. Las fallas se producen por cambios en el kernel 5.15 y versiones posteriores que restringen las inserciones de tablas en función de la longitud de la cadena.

    Para ver si te afecta este problema, puedes verificar las estadísticas del sistema de seguimiento de conexiones de kernel en cada nodo con el siguiente comando:

    
sudo conntrack -S

    La respuesta es similar a la que se muestra a continuación:

    
cpu=0       found=0 invalid=4 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 clash_resolve=0 chaintoolong=0
cpu=1       found=0 invalid=0 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 clash_resolve=0 chaintoolong=0
cpu=2       found=0 invalid=16 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 clash_resolve=0 chaintoolong=0
cpu=3       found=0 invalid=13 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 clash_resolve=0 chaintoolong=0
cpu=4       found=0 invalid=9 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 clash_resolve=0 chaintoolong=0
cpu=5       found=0 invalid=1 insert=0 insert_failed=0 drop=0 early_drop=0 error=519 search_restart=0 clash_resolve=126 chaintoolong=0
...

    Si un valor chaintoolong en la respuesta es un número distinto de cero, este problema te afectará.

    Solución alternativa

    La mitigación a corto plazo consiste en aumentar el tamaño de la tabla de hash de netfiler (nf_conntrack_buckets) y la tabla de seguimiento de conexión de netfilter (nf_conntrack_max). Usa los siguientes comandos en cada nodo del clúster para aumentar el tamaño de las tablas:

    
sysctl -w net.netfilter.nf_conntrack_buckets=TABLE_SIZE
sysctl -w net.netfilter.nf_conntrack_max=TABLE_SIZE

    Reemplaza TABLE_SIZE por un tamaño nuevo en bytes. El valor predeterminado del tamaño de la tabla es 262144. Te sugerimos que establezcas un valor igual a 65,536 veces la cantidad de núcleos del nodo. Por ejemplo, si tu nodo tiene ocho núcleos, establece el tamaño de la tabla en 524288.
    Redes 1.13.0-1.13.2

    Bucle de falla calico-typha o anetd-operator en nodos de Windows con plano de control v2

    Con el plano de control v2 o un modelo de instalación nuevo, es posible que calico-typha o anetd-operator se programen para nodos de Windows y entren en un bucle de fallas.

    El motivo es que las dos implementaciones toleran todos los taints, incluido el taint de nodo de Windows.


    Solución alternativa:

    Actualiza a 1.13.3 o una versión posterior, o ejecuta los siguientes comandos para editar la implementación “calico-typha” o “anetd-operator”:

    
    # If dataplane v2 is not used.
    kubectl edit deployment -n kube-system calico-typha --kubeconfig USER_CLUSTER_KUBECONFIG
    # If dataplane v2 is used.
    kubectl edit deployment -n kube-system anetd-operator --kubeconfig USER_CLUSTER_KUBECONFIG

    Quita el siguiente elemento spec.template.spec.tolerations:

    
    - effect: NoSchedule
      operator: Exists
    - effect: NoExecute
      operator: Exists

    Y agrega la siguiente tolerancia:

    
    - key: node-role.kubernetes.io/master
      operator: Exists
    Configuración 1.14.0-1.14.2

    No se puede cargar el archivo de credenciales del registro privado del clúster de usuario

    Es posible que no puedas crear un clúster de usuario si especificas la sección privateRegistry con la credencial fileRef. La solicitud preliminar puede fallar con el siguiente mensaje: 

    
[FAILURE] Docker registry access: Failed to login.


    Solución alternativa:

    • Si no pretendías especificar el campo o si desea usar la misma credencial de registro privado que el clúster de administrador, puede quitar o comentar la sección privateRegistry en el archivo de configuración del clúster de usuario.
    • Si deseas usar una credencial de registro privado específica para el clúster de usuario, puedes especificar de forma temporal la sección privateRegistry de la siguiente manera: 
      
privateRegistry:
  address: PRIVATE_REGISTRY_ADDRESS
  credentials:
    username: PRIVATE_REGISTRY_USERNAME
    password: PRIVATE_REGISTRY_PASSWORD
  caCertPath: PRIVATE_REGISTRY_CACERT_PATH
      (NOTA: Esta es solo una solución temporal y estos campos ya están obsoletos; considera usar el archivo de credenciales cuando actualices a la versión 1.14.3 o posterior).

    Operaciones 1.10+

    Anthos Service Mesh y otras mallas de servicios no son compatibles con Dataplane v2

    Dataplane V2 se encarga del balanceo de cargas y crea un socket de kernel en lugar de una DNAT basada en paquetes. Esto significa que Anthos Service Mesh no puede realizar la inspección de paquetes, ya que se omite el Pod y nunca usa IPTables.

    Esto se manifiesta en el modo gratuito kube-proxy por pérdida de conectividad o enrutamiento de tráfico incorrecto para los servicios con Anthos Service Mesh, ya que el archivo adicional no puede realizar la inspección de paquetes.

    Este problema está presente en todas las versiones de GKE en Bare Metal 1.10; sin embargo, algunas versiones más recientes de 1.10 (1.10.2 y versiones posteriores) tienen una solución alternativa.


    Solución alternativa:

    Actualiza a la versión 1.11 para obtener compatibilidad total o ejecuta la versión 1.10.2 o posterior:

    
    kubectl edit cm -n kube-system cilium-config --kubeconfig USER_CLUSTER_KUBECONFIG

    Agrega bpf-lb-sock-hostns-only: true al configmap y, luego, reinicia el daemonset anetd:

    
      kubectl rollout restart ds anetd -n kube-system --kubeconfig USER_CLUSTER_KUBECONFIG

    Almacenamiento 1.12+, 1.13.3

    Es posible que kube-controller-manager desconecte los volúmenes persistentes de manera forzosa después de 6 minutos

    Es posible que kube-controller-manager se agote el tiempo de espera cuando se desconectan los PV o PVC después de 6 minutos y que se desconectan de manera forzosa los PV o PVC. En los registros detallados de kube-controller-manager, se muestran eventos similares a los siguientes:

    
$ cat kubectl_logs_kube-controller-manager-xxxx | grep "DetachVolume started" | grep expired

kubectl_logs_kube-controller-manager-gke-admin-master-4mgvr_--container_kube-controller-manager_--kubeconfig_kubeconfig_--request-timeout_30s_--namespace_kube-system_--timestamps:2023-01-05T16:29:25.883577880Z W0105 16:29:25.883446       1 reconciler.go:224] attacherDetacher.DetachVolume started for volume "pvc-8bb4780b-ba8e-45f4-a95b-19397a66ce16" (UniqueName: "kubernetes.io/csi/csi.vsphere.vmware.com^126f913b-4029-4055-91f7-beee75d5d34a") on node "sandbox-corp-ant-antho-0223092-03-u-tm04-ml5m8-7d66645cf-t5q8f"
This volume is not safe to detach, but maxWaitForUnmountDuration 6m0s expired, force detaching

    Para verificar el problema, accede al nodo y ejecuta los siguientes comandos:

    
# See all the mounting points with disks
lsblk -f

# See some ext4 errors
sudo dmesg -T

    En el registro de kubelet, se muestran errores como los siguientes:

    
Error: GetDeviceMountRefs check failed for volume "pvc-8bb4780b-ba8e-45f4-a95b-19397a66ce16" (UniqueName: "kubernetes.io/csi/csi.vsphere.vmware.com^126f913b-4029-4055-91f7-beee75d5d34a") on node "sandbox-corp-ant-antho-0223092-03-u-tm04-ml5m8-7d66645cf-t5q8f" :
the device mount path "/var/lib/kubelet/plugins/kubernetes.io/csi/pv/pvc-8bb4780b-ba8e-45f4-a95b-19397a66ce16/globalmount" is still mounted by other references [/var/lib/kubelet/plugins/kubernetes.io/csi/pv/pvc-8bb4780b-ba8e-45f4-a95b-19397a66ce16/globalmount

    Solución alternativa:

    Conéctate al nodo afectado mediante SSH y reinicia el nodo.
    Revisiones y actualizaciones 1.12+, 1.13+, 1.14+

    La actualización del clúster se detiene si se usa un controlador de CSI de terceros

    Es posible que no puedas actualizar un clúster si usas un controlador de CSI de terceros. El comando gkectl cluster diagnose puede mostrar el siguiente error: 

    
"virtual disk "kubernetes.io/csi/csi.netapp.io^pvc-27a1625f-29e3-4e4f-9cd1-a45237cc472c" IS NOT attached to machine "cluster-pool-855f694cc-cjk5c" but IS listed in the Node.Status"


    Solución alternativa:

    Realiza la actualización con la opción --skip-validation-all.
    Operación 1.10+, 1.11+, 1.12+, 1.13+, 1.14+

    gkectl repair admin-master crea la VM de la instancia principal de administrador sin actualizar la versión de hardware de la VM.

    Es posible que el nodo de la instancia principal de administrador creado a través de gkectl repair admin-master use una versión de hardware de VM anterior a la esperada. Cuando ocurra el problema, verás el error en el informe gkectl diagnose cluster. 

    
CSIPrerequisites [VM Hardware]: The current VM hardware versions are lower than vmx-15 which is unexpected. Please contact Anthos support to resolve this issue.


    Solución alternativa:

    Apaga el nodo de la instancia principal del administrador, sigue https://kb.vmware.com/s/article/1003746 para actualizarlo a la versión esperada descrita en el mensaje de error y, luego, inícialo.
    Sistema operativo 1.10+, 1.11+, 1.12+, 1.13+, 1.14+, 1.15+, 1.16+

    La VM libera la asignación de tiempo de DHCP al momento del apagado o reinicio de forma inesperada, lo que puede provocar cambios de IP.

    En systemd v244, systemd-networkd tiene un cambio de comportamiento predeterminado en la configuración de KeepConfiguration. Antes de este cambio, las VM no enviaban un mensaje de actualización de asignación de tiempo de DHCP al servidor DHCP cuando se apagaba o se reiniciaba. Después de este cambio, las VM envían el mensaje y muestran las IP al servidor de DHCP. Como resultado, es posible que la IP liberada se reasigne a una VM diferente o que se asigne una IP diferente a la VM, lo que genera un conflicto de IP (a nivel de Kubernetes, no a nivel de vSphere) o un cambio de IP en las VMs, lo que puede provocar fallas en los clústeres de varias maneras.

    Por ejemplo, es posible que veas los siguientes síntomas.

    • La IU de vCenter muestra que ninguna VM usa la misma IP, pero kubectl get nodes -o wide muestra nodos con IP duplicadas. 
      
NAME   STATUS    AGE  VERSION          INTERNAL-IP    EXTERNAL-IP    OS-IMAGE            KERNEL-VERSION    CONTAINER-RUNTIME
node1  Ready     28h  v1.22.8-gke.204  10.180.85.130  10.180.85.130  Ubuntu 20.04.4 LTS  5.4.0-1049-gkeop  containerd://1.5.13
node2  NotReady  71d  v1.22.8-gke.204  10.180.85.130  10.180.85.130  Ubuntu 20.04.4 LTS  5.4.0-1049-gkeop  containerd://1.5.13
    • No se pueden iniciar los nodos nuevos debido a calico-node error 
      
2023-01-19T22:07:08.817410035Z 2023-01-19 22:07:08.817 [WARNING][9] startup/startup.go 1135: Calico node 'node1' is already using the IPv4 address 10.180.85.130.
2023-01-19T22:07:08.817514332Z 2023-01-19 22:07:08.817 [INFO][9] startup/startup.go 354: Clearing out-of-date IPv4 address from this node IP="10.180.85.130/24"
2023-01-19T22:07:08.825614667Z 2023-01-19 22:07:08.825 [WARNING][9] startup/startup.go 1347: Terminating
2023-01-19T22:07:08.828218856Z Calico node failed to start


    Solución alternativa:

    Implementa el siguiente DaemonSet en el clúster para revertir el cambio de comportamiento predeterminado de systemd-networkd. Las VM que ejecutan este DaemonSet no liberarán las IP al servidor DHCP cuando se apaguen o reinicien. El servidor DHCP liberará automáticamente las IP cuando venzan las asignaciones de tiempo. 

    
      apiVersion: apps/v1
      kind: DaemonSet
      metadata:
        name: set-dhcp-on-stop
      spec:
        selector:
          matchLabels:
            name: set-dhcp-on-stop
        template:
          metadata:
            labels:
              name: set-dhcp-on-stop
          spec:
            hostIPC: true
            hostPID: true
            hostNetwork: true
            containers:
            - name: set-dhcp-on-stop
              image: ubuntu
              tty: true
              command:
              - /bin/bash
              - -c
              - |
                set -x
                date
                while true; do
                  export CONFIG=/host/run/systemd/network/10-netplan-ens192.network;
                  grep KeepConfiguration=dhcp-on-stop "${CONFIG}" > /dev/null
                  if (( $? != 0 )) ; then
                    echo "Setting KeepConfiguration=dhcp-on-stop"
                    sed -i '/\[Network\]/a KeepConfiguration=dhcp-on-stop' "${CONFIG}"
                    cat "${CONFIG}"
                    chroot /host systemctl restart systemd-networkd
                  else
                    echo "KeepConfiguration=dhcp-on-stop has already been set"
                  fi;
                  sleep 3600
                done
              volumeMounts:
              - name: host
                mountPath: /host
              resources:
                requests:
                  memory: "10Mi"
                  cpu: "5m"
              securityContext:
                privileged: true
            volumes:
            - name: host
              hostPath:
                path: /
            tolerations:
            - operator: Exists
              effect: NoExecute
            - operator: Exists
              effect: NoSchedule

    Operaciones, actualizaciones y actualizaciones 1.12.0-1.12.5, 1.13.0-1.13.5, 1.14.0-1.14.1

    La clave de la cuenta de servicio de acceso a los componentes se borró después de que se actualizara el clúster de administrador desde la versión 1.11.x

    Este problema solo afectará a los clústeres de administrador que se actualicen desde la versión 1.11.x y no afectará a los clústeres de administrador que se creen recientemente después de la 1.12.

    Después de actualizar un clúster de la versión 1.11.x a la 1.12.x, el campo component-access-sa-key en el secreto admin-cluster-creds se limpiará y quedará vacío. Para verificar esto, ejecuta el siguiente comando: 

    
kubectl --kubeconfig ADMIN_KUBECONFIG -n kube-system get secret admin-cluster-creds -o yaml | grep 'component-access-sa-key'
    Si ves que el resultado está vacío, significa que se limpió la clave.

    Después de borrar la clave de la cuenta de servicio de acceso a los componentes, fallará la instalación de clústeres de usuario nuevos o la actualización de los clústeres de usuario existentes. A continuación, se enumeran algunos mensajes de error que pueden surgir:

    • Falla de la comprobación preliminar de validación lenta con el siguiente mensaje de error: "Failed to create the test VMs: failed to get service account key: service account is not configured."
    • La preparación de gkectl prepare no pudo completarse con el siguiente mensaje de error: "Failed to prepare OS images: dialing: unexpected end of JSON input"
    • Si actualizas un clúster de usuario 1.13 con la consola de Google Cloud o gcloud CLI, cuando ejecutes gkectl update admin --enable-preview-user-cluster-central-upgrade para implementar el controlador de plataforma de actualización, el comando fallará y mostrará el siguiente mensaje: "failed to download bundle to disk: dialing: unexpected end of JSON input" (Puedes ver este mensaje en el campo status en el resultado de kubectl --kubeconfig ADMIN_KUBECONFIG -n kube-system get onprembundle -oyaml).


    Solución alternativa:

    Ejecuta el siguiente comando para volver a agregar la clave de la cuenta de servicio de acceso a los componentes al secreto de forma manual: 

    
kubectl --kubeconfig ADMIN_KUBECONFIG -n kube-system get secret admin-cluster-creds -ojson | jq --arg casa "$(cat COMPONENT_ACESS_SERVICE_ACOOUNT_KEY_PATH | base64 -w 0)" '.data["component-access-sa-key"]=$casa' | kubectl --kubeconfig ADMIN_KUBECONFIG apply -f -
    Operación 1.13.0+, 1.14.0+

    El escalador automático del clúster no funciona cuando el plano de control V2 está habilitado.

    En el caso de los clústeres de usuario creados con Controlplane V2 o un modelo de instalación nuevo, los grupos de nodos con el ajuste de escala automático habilitado siempre usan su autoscaling.minReplicas en el archivo user-cluster.yaml. El registro del Pod del escalador automático del clúster también muestra que no están en buen estado. 

    
  > kubectl --kubeconfig $USER_CLUSTER_KUBECONFIG -n kube-system \
  logs $CLUSTER_AUTOSCALER_POD --container_cluster-autoscaler
 TIMESTAMP  1 gkeonprem_provider.go:73] error getting onpremusercluster ready status: Expected to get a onpremusercluster with id foo-user-cluster-gke-onprem-mgmt/foo-user-cluster
 TIMESTAMP 1 static_autoscaler.go:298] Failed to get node infos for groups: Expected to get a onpremusercluster with id foo-user-cluster-gke-onprem-mgmt/foo-user-cluster
    Para encontrar el Pod del escalador automático del clúster, ejecuta los siguientes comandos. 
    
  > kubectl --kubeconfig $USER_CLUSTER_KUBECONFIG -n kube-system \
   get pods | grep cluster-autoscaler
cluster-autoscaler-5857c74586-txx2c                          4648017n    48076Ki    30s


    Solución alternativa:

    Inhabilita el ajuste de escala automático en todos los grupos de nodos con “gkectl update cluster” hasta actualizar a una versión con la corrección
    Instalación 1.12.0-1.12.4, 1.13.0-1.13.3, 1.14.0

    No se permite CIDR en el archivo de bloque de IP

    Cuando los usuarios usan CIDR en el archivo de bloque de IP, la validación de la configuración fallará y mostrará el siguiente error: 

    
- Validation Category: Config Check
    - [FAILURE] Config: AddressBlock for admin cluster spec is invalid: invalid IP:
172.16.20.12/30


    Solución alternativa:

    Incluye direcciones IP individuales en el archivo de bloqueo de IP hasta que actualices a una versión con la corrección: 1.12.5, 1.13.4, 1.14.1 o posterior.
    Revisiones y actualizaciones 1.14.0-1.14.1

    La actualización del tipo de imagen de SO en admin-cluster.yaml no espera a que se vuelvan a crear las máquinas del plano de control del usuario.

    Cuando actualizas el tipo de imagen de SO del plano de control en admin-cluster.yaml y si el clúster de usuario correspondiente se creó mediante Controlplane V2, es posible que las máquinas del plano de control del usuario no terminen de volver a crearse cuando finalice el comando gkectl.


    Solución alternativa:

    Cuando finalice la actualización, sigue esperando a que las máquinas del plano de control del usuario también terminen su recreación. Para ello, supervisa los tipos de imagen del SO del nodo con kubectl --kubeconfig USER_KUBECONFIG get nodes -owide. P.ej., si se actualiza de Ubuntu a COS, debemos esperar a que todas las máquinas del plano de control cambien por completo de Ubuntu a COS, incluso después de que se complete el comando de actualización.

    Operación 1.10, 1.11, 1.12, 1.13, 1.14.0

    Errores de creación o eliminación de Pods debido a un problema del token de autenticación de la cuenta de servicio de la CNI Calico

    Un problema con Calico en GKE en VMware 1.14.0 hace que la creación y eliminación de Pods falle con el siguiente mensaje de error en el resultado de kubectl describe pods:

    
  error getting ClusterInformation: connection is unauthorized: Unauthorized

    Este problema solo se observa 24 horas después de que se crea el clúster o se actualiza a la versión 1.14 con Calico.

    Los clústeres de administrador siempre usan Calico, mientras que para el clúster de usuario hay un campo de configuración “enableDataPlaneV2” en user-cluster.yaml, si ese campo está configurado como “false” o no se especifica, significa que usas Calico en el clúster de usuario.

    El contenedor install-cni de los nodos crea un kubeconfig con un token válido por 24 horas. El Pod calico-node debe renovar este token de forma periódica. El Pod calico-node no puede renovar el token porque no tiene acceso al directorio que contiene el archivo kubeconfig en el nodo.


    Solución alternativa:

    Este problema se corrigió en la versión 1.14.1 de GKE on VMware. Actualiza a esta versión o a una posterior.

    Si no puedes actualizar de inmediato, aplica el siguiente parche en el DaemonSet calico-node en el clúster de administrador y de usuario:

    
  kubectl -n kube-system get daemonset calico-node \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG -o json \
    | jq '.spec.template.spec.containers[0].volumeMounts += [{"name":"cni-net-dir","mountPath":"/host/etc/cni/net.d"}]' \
    | kubectl apply --kubeconfig ADMIN_CLUSTER_KUBECONFIG -f -

  kubectl -n kube-system get daemonset calico-node \
    --kubeconfig USER_CLUSTER_KUBECONFIG -o json \
    | jq '.spec.template.spec.containers[0].volumeMounts += [{"name":"cni-net-dir","mountPath":"/host/etc/cni/net.d"}]' \
    | kubectl apply --kubeconfig USER_CLUSTER_KUBECONFIG -f -
    Reemplaza lo siguiente:
    • ADMIN_CLUSTER_KUBECONFIG: Es la ruta de acceso del archivo kubeconfig del clúster de administrador.
    • USER_CLUSTER_CONFIG_FILE: Es la ruta de acceso del archivo de configuración del clúster de usuario.
    Instalación 1.12.0-1.12.4, 1.13.0-1.13.3, 1.14.0

    La validación del bloque de IP falla cuando se usa CIDR

    La creación del clúster falla a pesar de que el usuario tiene la configuración adecuada. El usuario ve que la creación falla debido a que el clúster no tiene suficientes IP.


    Solución alternativa:

    Divide los CIDR en varios bloques de CIDR más pequeños, como 10.0.0.0/30, se convierte en 10.0.0.0/31, 10.0.0.2/31. Siempre que haya N + 1 CIDR, donde N es la cantidad de nodos en el clúster, esto debería ser suficiente.

    operación, actualizaciones y actualizaciones 1.11.0 – 1.11.1, 1.10.0 – 1.10.4, 1.9.0 – 1.9.6

    La copia de seguridad del clúster de administrador no incluye la configuración y las claves de encriptación de Secrets siempre activos

    Cuando se habilita la función de encriptación de Secrets siempre activa junto con la copia de seguridad del clúster, la copia de seguridad del clúster de administrador no incluye las claves de encriptación y la configuración requeridas por la función de encriptación de Secrets siempre activos. Como resultado, la reparación de la instancia principal de administrador con esta copia de seguridad mediante gkectl repair admin-master --restore-from-backup genera el siguiente error: 

    
Validating admin master VM xxx ...
Waiting for kube-apiserver to be accessible via LB VIP (timeout "8m0s")...  ERROR
Failed to access kube-apiserver via LB VIP. Trying to fix the problem by rebooting the admin master
Waiting for kube-apiserver to be accessible via LB VIP (timeout "13m0s")...  ERROR
Failed to access kube-apiserver via LB VIP. Trying to fix the problem by rebooting the admin master
Waiting for kube-apiserver to be accessible via LB VIP (timeout "18m0s")...  ERROR
Failed to access kube-apiserver via LB VIP. Trying to fix the problem by rebooting the admin master

    operación, actualizaciones y actualizaciones 1.10+

    Vuelve a crear la VM de la instancia principal de administrador con un nuevo disco de arranque (p.ej., gkectl repair admin-master) fallará si la función de encriptación de Secrets siempre activa se habilita con el comando “gkectl update”.

    Si la función de encriptación de secretos siempre activa no está habilitada durante la creación del clúster, pero se habilita más adelante con la operación gkectl update, gkectl repair admin-master no puede reparar el nodo del plano de control del clúster de administrador. Se recomienda que la función de encriptación de Secrets siempre activada esté habilitada durante la creación del clúster. No existe una mitigación actual.

    Revisiones y actualizaciones 1.10

    Si actualizas el primer clúster de usuario de 1.9 a 1.10, se vuelven a crear los nodos en otros clústeres de usuario.

    La actualización del primer clúster de usuario de 1.9 a 1.10 podría volver a crear nodos en otros clústeres de usuario en el mismo clúster de administrador. La recreación se realiza de forma progresiva.

    Se quitó disk_label de MachineTemplate.spec.template.spec.providerSpec.machineVariables, lo que activó una actualización en todos los MachineDeployment de forma inesperada.


    Solución alternativa:
    Revisiones y actualizaciones 1.10.0

    Docker se reinicia con frecuencia después de la actualización del clúster

    Actualizar el clúster de usuario a la versión 1.10.0 puede hacer que Docker se reinicie con frecuencia.

    Para detectar este problema, ejecuta kubectl describe node NODE_NAME --kubeconfig USER_CLUSTER_KUBECONFIG

    Una condición del nodo mostrará si el Docker se reinicia con frecuencia. Este es un resultado de ejemplo:

    
Normal   FrequentDockerRestart    41m (x2 over 141m)     systemd-monitor  Node condition FrequentDockerRestart is now: True, reason: FrequentDockerRestart

    Para comprender la causa raíz, debes establecer una conexión SSH al nodo que tiene el síntoma y ejecutar comandos como sudo journalctl --utc -u docker o sudo journalctl -x.


    Solución alternativa:
    Revisiones y actualizaciones 1.11, 1.12

    Los componentes de GMP de implementación propia no se conservan después de actualizar a la versión 1.12

    Si usas una versión de GKE on VMware anterior a la 1.12 y configuraste de forma manual los componentes de Prometheus administrado por Google (GMP) en el espacio de nombres gmp-system para tu clúster, estos no se conservan cuando actualizas a la versión 1.12.x.

    A partir de la versión 1.12, los componentes de GMP en el espacio de nombres gmp-system y los CRD se administran con el objeto stackdriver, con la marca enableGMPForApplications establecida en false de forma predeterminada. Si implementas componentes de GMP de forma manual en el espacio de nombres antes de actualizar a la versión 1.12, stackdriver borrará los recursos.


    Solución alternativa:
    Operación 1.11, 1.12, 1.13.0 – 1.13.1

    Faltan objetos ClusterAPI en la situación de system de la instantánea del clúster

    En la situación system, la instantánea del clúster no incluye ningún recurso en el espacio de nombres default.

    Sin embargo, algunos recursos de Kubernetes, como los objetos de la API de clúster que se encuentran en este espacio de nombres, contienen información útil de depuración. La instantánea del clúster debería incluirlos.


    Solución alternativa:

    Puedes ejecutar manualmente los siguientes comandos para recopilar la información de depuración.

    
export KUBECONFIG=USER_CLUSTER_KUBECONFIG
kubectl get clusters.cluster.k8s.io -o yaml
kubectl get controlplanes.cluster.k8s.io -o yaml
kubectl get machineclasses.cluster.k8s.io -o yaml
kubectl get machinedeployments.cluster.k8s.io -o yaml
kubectl get machines.cluster.k8s.io -o yaml
kubectl get machinesets.cluster.k8s.io -o yaml
kubectl get services -o yaml
kubectl describe clusters.cluster.k8s.io
kubectl describe controlplanes.cluster.k8s.io
kubectl describe machineclasses.cluster.k8s.io
kubectl describe machinedeployments.cluster.k8s.io
kubectl describe machines.cluster.k8s.io
kubectl describe machinesets.cluster.k8s.io
kubectl describe services
    Donde:

    USER_CLUSTER_KUBECONFIG es el archivo kubeconfig del clúster de usuario.
    Revisiones y actualizaciones 1.11.0-1.11.4, 1.12.0-1.12.3, 1.13.0-1.13.1

    La eliminación del clúster de usuario se detuvo en el desvío de nodos para la configuración de vSAN

    Cuando borras, actualizas o actualizas un clúster de usuario, el vaciado de nodos puede detenerse en las siguientes situaciones:

    • El clúster de administrador usa el controlador de CSI de vSphere en la vSAN desde la versión 1.12.x.
    • No hay objetos PVC/PV creados por complementos de vSphere en el árbol en el clúster de administrador y de usuario.

    Para identificar el síntoma, ejecuta el siguiente comando:

    
kubectl logs clusterapi-controllers-POD_NAME_SUFFIX  --kubeconfig ADMIN_KUBECONFIG -n USER_CLUSTER_NAMESPACE

    A continuación, se muestra un ejemplo de mensaje de error del comando anterior:

    
E0920 20:27:43.086567 1 machine_controller.go:250] Error deleting machine object [MACHINE]; Failed to delete machine [MACHINE]: failed to detach disks from VM "[MACHINE]": failed to convert disk path "kubevols" to UUID path: failed to convert full path "ds:///vmfs/volumes/vsan:[UUID]/kubevols": ServerFaultCode: A general system error occurred: Invalid fault

    kubevols es el directorio predeterminado para el controlador en árbol de vSphere. Cuando no se crean objetos PVC/PV, es posible que encuentres un error que indica que el vaciado de nodos se bloquea cuando se encuentra kubevols, ya que la implementación actual supone que kubevols siempre existe.


    Solución alternativa:

    Crea el directorio kubevols en el almacén de datos donde se crea el nodo. Esto se define en el campo vCenter.datastore de los archivos user-cluster.yaml o admin-cluster.yaml.
    Configuración 1.7, 1.8, 1.9, 1.10, 1.11, 1.12, 1.13, 1.14

    Cluster Autoscaler clusterrolebinding y clusterrole se borran después de borrar un clúster de usuario.

    Cuando se borra el clúster de usuario, también se borran los clusterrole y clusterrolebinding correspondientes para el escalador automático del clúster. Esto afecta a todos los demás clústeres de usuario en el mismo clúster de administrador con el escalador automático de clúster habilitado. Esto se debe a que se usan los mismos clusterrole y clusterrolebinding para todos los Pods del escalador automático de clúster dentro del mismo clúster de administrador.

    Estos son los síntomas:

    • Registros cluster-autoscaler
      • 
kubectl logs --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n kube-system \
cluster-autoscaler
      En el ejemplo anterior, ADMIN_CLUSTER_KUBECONFIG es el archivo kubeconfig del clúster de administrador. Este es un ejemplo de los mensajes de error que puedes ver: 
      
2023-03-26T10:45:44.866600973Z W0326 10:45:44.866463       1 reflector.go:424] k8s.io/client-go/dynamic/dynamicinformer/informer.go:91: failed to list *unstructured.Unstructured: onpremuserclusters.onprem.cluster.gke.io is forbidden: User "..." cannot list resource "onpremuserclusters" in API group "onprem.cluster.gke.io" at the cluster scope
2023-03-26T10:45:44.866646815Z E0326 10:45:44.866494       1 reflector.go:140] k8s.io/client-go/dynamic/dynamicinformer/informer.go:91: Failed to watch *unstructured.Unstructured: failed to list *unstructured.Unstructured: onpremuserclusters.onprem.cluster.gke.io is forbidden: User "..." cannot list resource "onpremuserclusters" in API group "onprem.cluster.gke.io" at the cluster scope

    Solución alternativa:

    Configuración 1.7, 1.8, 1.9, 1.10, 1.11, 1.12, 1.13

    Los clústeres de administrador cluster-health-controller y vsphere-metrics-exporter no funcionan después de borrar el clúster de usuario.

    Cuando se borra el clúster de usuario, también se borra el clusterrole correspondiente, lo que hace que la reparación automática y el exportador de métricas de vSphere no funcionen.

    Estos son los síntomas:

    • Registros cluster-health-controller
      • 
kubectl logs --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n kube-system \
cluster-health-controller
      En el ejemplo anterior, ADMIN_CLUSTER_KUBECONFIG es el archivo kubeconfig del clúster de administrador. Este es un ejemplo de los mensajes de error que puedes ver: 
      
error retrieving resource lock default/onprem-cluster-health-leader-election: configmaps "onprem-cluster-health-leader-election" is forbidden: User "system:serviceaccount:kube-system:cluster-health-controller" cannot get resource "configmaps" in API group "" in the namespace "default": RBAC: clusterrole.rbac.authorization.k8s.io "cluster-health-controller-role" not found
    • Registros vsphere-metrics-exporter
      • 
kubectl logs --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n kube-system \
vsphere-metrics-exporter
      En el ejemplo anterior, ADMIN_CLUSTER_KUBECONFIG es el archivo kubeconfig del clúster de administrador. Este es un ejemplo de los mensajes de error que puedes ver: 
      
vsphere-metrics-exporter/cmd/vsphere-metrics-exporter/main.go:68: Failed to watch *v1alpha1.Cluster: failed to list *v1alpha1.Cluster: clusters.cluster.k8s.io is forbidden: User "system:serviceaccount:kube-system:vsphere-metrics-exporter" cannot list resource "clusters" in API group "cluster.k8s.io" in the namespace "default"

    Solución alternativa:

    Configuración 1.12.1-1.12.3, 1.13.0-1.13.2

    gkectl check-config falla en la validación de la imagen de SO

    Un problema conocido que podría fallar el gkectl check-config sin ejecutar gkectl prepare. Esto es confuso, ya que sugerimos ejecutar el comando antes de ejecutar gkectl prepare.

    El síntoma es que el comando gkectl check-config fallará y mostrará el siguiente mensaje de error:

    
Validator result: {Status:FAILURE Reason:os images [OS_IMAGE_NAME] don't exist, please run `gkectl prepare` to upload os images. UnhealthyResources:[]}

    Solución alternativa:

    Opción 1: ejecuta gkectl prepare para subir las imágenes de SO que faltan.

    Opción 2: Usa gkectl check-config --skip-validation-os-images para omitir la validación de las imágenes de SO.
    Revisiones y actualizaciones 1.11, 1.12, 1.13

    gkectl update admin/cluster falla en la actualización de los grupos antiafinidades

    Es un problema conocido que podría fallar el gkectl update admin/cluster cuando se actualiza anti affinity groups.

    El síntoma es que el comando gkectl update fallará y mostrará el siguiente mensaje de error:

    
Waiting for machines to be re-deployed...  ERROR
Exit with error:
Failed to update the cluster: timed out waiting for the condition

    Solución alternativa:
    Instalación, actualizaciones y actualizaciones 1.13.0-1.13.8, 1.14.0-1.14.4, 1.15.0

    Los nodos no se registran si el nombre de host configurado contiene un punto.

    El registro de nodos falla durante la creación, actualización, actualización y reparación automática del nodo, cuando ipMode.type es static y el nombre de host configurado en el archivo de bloque de IP contiene uno o más puntos. En este caso, las solicitudes de firma de certificados (CSR) para un nodo no se aprueban de forma automática.

    Para ver las CSR pendientes de un nodo, ejecuta el siguiente comando:

    
kubectl get csr -A -o wide

    Revisa los siguientes registros en busca de mensajes de error:

    • Visualiza los registros del clúster de administrador del contenedor clusterapi-controller-manager en el Pod clusterapi-controllers: 
      
kubectl logs clusterapi-controllers-POD_NAME \
    -c clusterapi-controller-manager -n kube-system \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG
    • Para ver los mismos registros en el clúster de usuario, ejecuta el siguiente comando: 
      
kubectl logs clusterapi-controllers-POD_NAME \
    -c clusterapi-controller-manager -n USER_CLUSTER_NAME \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG
      En el ejemplo anterior, se ilustra lo siguiente:
      • ADMIN_CLUSTER_KUBECONFIG es el archivo kubeconfig del clúster de administrador.
      • USER_CLUSTER_NAME es el nombre del clúster de usuario.
      A continuación, se muestra un ejemplo de mensajes de error que pueden aparecer: "msg"="failed to validate token id" "error"="failed to find machine for node node-worker-vm-1" "validate"="csr-5jpx9"
    • Visualiza los registros kubelet en el nodo problemático: 
      
journalctl --u kubelet
      Este es un ejemplo de mensajes de error que puedes ver: "Error getting node" err="node \"node-worker-vm-1\" not found"

    Si especificas un nombre de dominio en el campo de nombre de host de un archivo de bloqueo de IP, se ignorará cualquier carácter después del primer punto. Por ejemplo, si especificas el nombre de host como bob-vm-1.bank.plc, el nombre de host de la VM y el nombre del nodo se establecerán en bob-vm-1.

    Cuando la verificación de ID de nodo está habilitada, el responsable de aprobación del CSR compara el nombre del nodo con el nombre de host en la especificación de Machine y no logra conciliar el nombre. El responsable de aprobación rechaza la CSR y no se puede iniciar el nodo.


    Solución alternativa:

    Clúster de usuario

    Para inhabilitar la verificación del ID de los nodos, sigue estos pasos:

    1. Agrega los siguientes campos en el archivo de configuración del clúster de usuario: 
      
disableNodeIDVerification: true
disableNodeIDVerificationCSRSigning: true
    2. Guarda el archivo y actualiza el clúster de usuario mediante la ejecución del siguiente comando: 
      
gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config USER_CLUSTER_CONFIG_FILE
      Reemplaza lo siguiente:
      • ADMIN_CLUSTER_KUBECONFIG: Es la ruta de acceso del archivo kubeconfig del clúster de administrador.
      • USER_CLUSTER_CONFIG_FILE: Es la ruta de acceso del archivo de configuración del clúster de usuario.

    Clúster de administrador

    1. Abre el recurso personalizado OnPremAdminCluster para editarlo: 
      
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    edit onpremadmincluster -n kube-system
    2. Agrega la siguiente anotación al recurso personalizado: 
      
features.onprem.cluster.gke.io/disable-node-id-verification: enabled
    3. Edita el manifiesto kube-controller-manager en el plano de control del clúster de administrador:
      1. Establece una conexión SSH al nodo del plano de control del clúster de administrador.
      2. Abre el manifiesto kube-controller-manager para editarlo: 
        
sudo vi /etc/kubernetes/manifests/kube-controller-manager.yaml
      3. Busca la lista de controllers: 
        
--controllers=*,bootstrapsigner,tokencleaner,-csrapproving,-csrsigning
      4. Actualiza esta sección como se muestra a continuación: 
        
--controllers=*,bootstrapsigner,tokencleaner
    4. Abre el controlador de API del clúster de implementación para editarlo: 
      
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    edit deployment clusterapi-controllers -n kube-system
    5. Cambia los valores de node-id-verification-enabled y node-id-verification-csr-signing-enabled a false: 
      
--node-id-verification-enabled=false
--node-id-verification-csr-signing-enabled=false
    Instalación, actualizaciones y actualizaciones 1.11.0-1.11.4

    Error de inicio de la máquina del plano de control del administrador causada por un paquete de certificados de registro privado

    La creación o actualización del clúster de administrador se detiene en el siguiente registro para siempre y, por último, se agota el tiempo de espera:

    
Waiting for Machine gke-admin-master-xxxx to become ready...

    El registro del controlador de API de clúster en la instantánea del clúster externo incluye el siguiente registro:

    
Invalid value 'XXXX' specified for property startup-data

    A continuación, se muestra una ruta de archivo de ejemplo para el registro del controlador de API de clúster:

    
kubectlCommands/kubectl_logs_clusterapi-controllers-c4fbb45f-6q6g6_--container_vsphere-controller-manager_--kubeconfig_.home.ubuntu..kube.kind-config-gkectl_--request-timeout_30s_--namespace_kube-system_--timestamps
    
    VMware has a 64k vApp property size limit. In the identified versions,
    the data passed via vApp property is close to the limit. When the private
    registry certificate contains a certificate bundle, it may cause the final
    data to exceed the 64k limit.
    
    
    Workaround:
    
    
    Only include the required certificates in the private registry
    certificate file configured in privateRegistry.caCertPath in
    the admin cluster config file.
    
    
    Or upgrade to a version with the fix when available.
    Redes 1.10, 1.11.0-1.11.3, 1.12.0-1.12.2, 1.13.0

    NetworkGatewayNodes se marcó como en mal estado debido a un conflicto de actualización de estado simultánea

    En networkgatewaygroups.status.nodes, algunos nodos cambian entre NotHealthy y Up.

    Los registros del Pod ang-daemon que se ejecuta en ese nodo revelan errores repetidos: 

    
2022-09-16T21:50:59.696Z ERROR ANGd Failed to report status {"angNode": "kube-system/my-node", "error": "updating Node CR status: sending Node CR update: Operation cannot be fulfilled on networkgatewaynodes.networking.gke.io \"my-node\": the object has been modified; please apply your changes to the latest version and try again"}

    El estado NotHealthy evita que el controlador asigne IP flotantes adicionales al nodo. Esto puede generar una mayor carga en otros nodos o una falta de redundancia para la alta disponibilidad.

    De lo contrario, la actividad de Dataplane no se verá afectada.

    La contención en el objeto networkgatewaygroup hace que algunas actualizaciones de estado fallen debido a una falla en el manejo de reintentos. Si fallan demasiadas actualizaciones de estado, ang-controller-manager ve que el nodo superó el límite de tiempo de señal de monitoreo de funcionamiento y marca el nodo como NotHealthy.

    La falla en el manejo de reintentos se corrigió en versiones posteriores.


    Solución alternativa:

    Realiza la actualización a una versión fija cuando esté disponible.
    Revisiones y actualizaciones 1.12.0-1.12.2, 1.13.0

    La condición de carrera bloquea la eliminación de los objetos de la máquina durante la actualización y la actualización

    Un problema conocido que podría hacer que la actualización del clúster se detenga mientras espera a que se borre el objeto de máquina anterior. Esto se debe a que el finalizador no se puede quitar del objeto de máquina. Esto afecta cualquier operación de actualización progresiva de los grupos de nodos.

    El síntoma es que se agota el tiempo de espera del comando gkectl y se muestra el siguiente mensaje de error:

    
E0821 18:28:02.546121   61942 console.go:87] Exit with error:
E0821 18:28:02.546184   61942 console.go:87] error: timed out waiting for the condition, message: Node pool "pool-1" is not ready: ready condition is not true: CreateOrUpdateNodePool: 1/3 replicas are updated
Check the status of OnPremUserCluster 'cluster-1-gke-onprem-mgmt/cluster-1' and the logs of pod 'kube-system/onprem-user-cluster-controller' for more detailed debugging information.

    En los registros de Pods clusterapi-controller, los errores son como los siguientes:

    
$ kubectl logs clusterapi-controllers-[POD_NAME_SUFFIX] -n cluster-1
    -c vsphere-controller-manager --kubeconfig [ADMIN_KUBECONFIG]
    | grep "Error removing finalizer from machine object"
[...]
E0821 23:19:45.114993       1 machine_controller.go:269] Error removing finalizer from machine object cluster-1-pool-7cbc496597-t5d5p; Operation cannot be fulfilled on machines.cluster.k8s.io "cluster-1-pool-7cbc496597-t5d5p": the object has been modified; please apply your changes to the latest version and try again

    El error se repite en la misma máquina durante varios minutos para ejecuciones correctas, incluso sin este problema. La mayoría de las veces, puede ser rápido, pero en algunos casos excepcionales puede detenerse en esta condición de carrera durante varias horas.

    El problema es que la VM subyacente ya se borra en vCenter, pero el objeto de máquina correspondiente no se puede quitar, que se bloquea cuando se quita el finalizador debido a actualizaciones muy frecuentes de otros controladores. Esto puede provocar que el comando gkectl agote el tiempo de espera, pero el controlador sigue conciliando el clúster para que el proceso de actualización o actualización se complete.


    Solución alternativa:

    Preparamos varias opciones de mitigación diferentes para este problema, que dependen de tu entorno y tus requisitos.

    • Opción 1: Espera a que la actualización se complete por sí sola.

      Según el análisis y la reproducción en tu entorno, la actualización puede finalizar por sí sola sin ninguna intervención manual. La salvedad de esta opción es que no se conoce el tiempo que tardará la eliminación del finalizador en cada objeto de máquina. Puede ejecutarse de inmediato si se tiene suerte, o bien podría durar varias horas si la conciliación del controlador del conjunto de máquinas es demasiado rápida y el controlador de la máquina nunca tiene la oportunidad de quitar el finalizador entre las conciliaciones.

      Lo bueno es que esta opción no necesita ninguna acción de tu parte y las cargas de trabajo no se interrumpirán. Solo necesita más tiempo para que se complete la actualización.
    • Opción 2: Aplica la anotación de reparación automática a todos los objetos de máquina antiguos.

      El controlador del conjunto de máquinas filtrará las máquinas que tienen la marca de tiempo de eliminación y anotación de reparación automática que no son cero, y no seguirá emitiendo llamadas de eliminación en esas máquinas, esto puede ayudar a evitar la condición de carrera.

      La desventaja es que los Pods de las máquinas se borrarán directamente en lugar de expulsados, lo que significa que no respetará la configuración de PDB y podría causar tiempo de inactividad para tus cargas de trabajo.

      El comando para obtener todos los nombres de máquina es el siguiente: 
      
kubectl --kubeconfig CLUSTER_KUBECONFIG get machines
      Este es el comando para aplicar la anotación de reparación automática en cada máquina: 
      
kubectl annotate --kubeconfig CLUSTER_KUBECONFIG \
    machine MACHINE_NAME \
    onprem.cluster.gke.io/repair-machine=true

    Si encuentras este problema y la actualización o la actualización aún no se puede completar después de un tiempo prolongado, comunícate con nuestro equipo de asistencia al cliente para obtener información sobre las mitigaciones.
    Instalación, actualizaciones y actualizaciones 1.10.2, 1.11, 1.12, 1.13

    Falla de la solicitud preliminar de validación de imagen de SO de gkectl

    El comando gkectl prepare falló con:

    
- Validation Category: OS Images
    - [FAILURE] Admin cluster OS images exist: os images [os_image_name] don't exist, please run `gkectl prepare` to upload os images.

    Las comprobaciones preliminares de gkectl prepare incluían una validación incorrecta.


    Solución alternativa:

    Ejecuta el mismo comando con una marca adicional --skip-validation-os-images.
    Instalación 1.7, 1.8, 1.9, 1.10, 1.11, 1.12, 1.13

    La URL de vCenter con el prefijo https:// o http:// puede causar un error de inicio del clúster

    No se pudo crear el clúster de administrador con lo siguiente:

    
Exit with error:
Failed to create root cluster: unable to apply admin base bundle to external cluster: error: timed out waiting for the condition, message:
Failed to apply external bundle components: failed to apply bundle objects from admin-vsphere-credentials-secret 1.x.y-gke.z to cluster external: Secret "vsphere-dynamic-credentials" is invalid:
[data[https://xxx.xxx.xxx.username]: Invalid value: "https://xxx.xxx.xxx.username": a valid config key must consist of alphanumeric characters, '-', '_' or '.'
(e.g. 'key.name', or 'KEY_NAME', or 'key-name', regex used for validation is '[-._a-zA-Z0-9]+'), data[https://xxx.xxx.xxx.password]:
Invalid value: "https://xxx.xxx.xxx.password": a valid config key must consist of alphanumeric characters, '-', '_' or '.'
(e.g. 'key.name', or 'KEY_NAME', or 'key-name', regex used for validation is '[-._a-zA-Z0-9]+')]

    La URL se usa como parte de una clave secreta, que no admite “/” ni “:”.


    Solución alternativa:

    Quita el prefijo https:// o http:// del campo vCenter.Address en el archivo YAML de configuración del clúster de administrador o del clúster de usuario.
    Instalación, actualizaciones y actualizaciones 1.10, 1.11, 1.12, 1.13

    gkectl prepare de pánico el util.CheckFileExists

    gkectl prepare puede generar un problema de pánico con el siguiente seguimiento de pila:

    
panic: runtime error: invalid memory address or nil pointer dereference [signal SIGSEGV: segmentation violation code=0x1 addr=0x18 pc=0xde0dfa]

goroutine 1 [running]:
gke-internal.googlesource.com/syllogi/cluster-management/pkg/util.CheckFileExists(0xc001602210, 0x2b, 0xc001602210, 0x2b) pkg/util/util.go:226 +0x9a
gke-internal.googlesource.com/syllogi/cluster-management/gkectl/pkg/config/util.SetCertsForPrivateRegistry(0xc000053d70, 0x10, 0xc000f06f00, 0x4b4, 0x1, 0xc00015b400)gkectl/pkg/config/util/utils.go:75 +0x85
...

    El problema es que gkectl prepare creó el directorio del certificado de registro privado con un permiso incorrecto.


    Solución alternativa:

    Para solucionar este problema, ejecuta los siguientes comandos en la estación de trabajo de administrador:

    
sudo mkdir -p /etc/docker/certs.d/PRIVATE_REGISTRY_ADDRESS
sudo chmod 0755 /etc/docker/certs.d/PRIVATE_REGISTRY_ADDRESS
    Revisiones y actualizaciones 1.10, 1.11, 1.12, 1.13

    gkectl repair admin-master y la actualización reanudable de administrador no funcionan en conjunto

    Después de un intento fallido de actualización del clúster de administrador, no ejecutes gkectl repair admin-master. Si lo haces, es posible que fallen los intentos posteriores de actualización del administrador, como fallas en el encendido de la instancia principal del administrador o que no se puede acceder a la VM.


    Solución alternativa:

    Si ya te has encontrado con esta situación de error, comunícate con el equipo de asistencia.
    Revisiones y actualizaciones 1.10, 1.11

    La reanudación de la actualización del clúster de administrador puede hacer que falte la plantilla de VM del plano de control del administrador

    Si la máquina del plano de control de administrador no se vuelve a crear después de un intento de actualización del clúster de administrador reanudado, se borrará la plantilla de VM del plano de control de administrador. La plantilla de VM del plano de control del administrador es la plantilla de la instancia principal de administrador que se usa para recuperar la máquina del plano de control con gkectl repair admin-master.


    Solución alternativa:

    La plantilla de VM del plano de control de administrador se volverá a generar durante la próxima actualización del clúster de administrador.
    Sistema operativo 1.12, 1.13

    cgroup v2 podría afectar las cargas de trabajo

    En la versión 1.12.0, cgroup v2 (unificado) está habilitado de forma predeterminada para los nodos de Container Optimized OS (COS). Esto podría causar inestabilidad en tus cargas de trabajo en un clúster de COS.


    Solución alternativa:

    Cambiamos a cgroup v1 (hybrid) en la versión 1.12.1. Si usas nodos COS, te recomendamos que actualices a la versión 1.12.1 apenas se lance.
    Identidad 1.10, 1.11, 1.12, 1.13

    Recurso personalizado de ClientConfig

    gkectl update revierte cualquier cambio manual que hayas realizado en el recurso personalizado ClientConfig.


    Solución alternativa:

    Te recomendamos que crees una copia de seguridad del recurso ClientConfig después de cada cambio manual.
    Instalación 1.10, 1.11, 1.12, 1.13

    La validación de gkectl check-config falla: no se pueden encontrar las particiones de BIG-IP de F5

    La validación falla porque las particiones de BIG-IP de F5 no se pueden encontrar, aunque existan.

    Un problema con la API de BIG-IP de F5 puede causar que la validación falle.


    Solución alternativa:

    Vuelve a ejecutar gkectl check-config.
    Instalación 1.12

    No se pudo instalar el clúster de usuario debido al problema de la elección de líder de cert-manager/ca-injector.

    Es posible que veas una falla de instalación debido a cert-manager-cainjector en el bucle de fallas cuando apiserver/etcd es lento:

    
# These are logs from `cert-manager-cainjector`, from the command
# `kubectl --kubeconfig USER_CLUSTER_KUBECONFIG -n kube-system
  cert-manager-cainjector-xxx`

I0923 16:19:27.911174       1 leaderelection.go:278] failed to renew lease kube-system/cert-manager-cainjector-leader-election: timed out waiting for the condition

E0923 16:19:27.911110       1 leaderelection.go:321] error retrieving resource lock kube-system/cert-manager-cainjector-leader-election-core:
  Get "https://10.96.0.1:443/api/v1/namespaces/kube-system/configmaps/cert-manager-cainjector-leader-election-core": context deadline exceeded

I0923 16:19:27.911593       1 leaderelection.go:278] failed to renew lease kube-system/cert-manager-cainjector-leader-election-core: timed out waiting for the condition

E0923 16:19:27.911629       1 start.go:163] cert-manager/ca-injector "msg"="error running core-only manager" "error"="leader election lost"

    Solución alternativa:
    VMware 1.10, 1.11, 1.12, 1.13

    Reinicia o actualiza vCenter para versiones anteriores a 7.0U2

    Si vCenter, para versiones anteriores a 7.0U2, se reinicia, después de una actualización o de otro modo, el nombre de la red en la información de la VM de vCenter es incorrecto y hace que la máquina tenga un estado Unavailable. Esto, eventualmente, hace que los nodos se reparen de forma automática para crear otros nuevos.

    Error relacionado de govmomi.


    Solución alternativa:

    La solución alternativa la proporciona la asistencia de VMware:

    1. El problema se solucionó en vCenter 7.0U2 y versiones posteriores.
    2. Para versiones anteriores, haz clic con el botón derecho en el host y selecciona Conexión > Desconectar. Luego, vuelve a conectarte, lo que fuerza una actualización del grupo de puertos de la VM.
    Sistema operativo 1.10, 1.11, 1.12, 1.13

    Conexión SSH cerrada por host remoto

    Para GKE on VMware versión 1.7.2 y superior, las imágenes del SO Ubuntu se endurecen con CIS L1 Server Benchmark.

    Para cumplir con la regla de CIS “5.2.16 Asegúrate de que el intervalo de tiempo de espera de inactividad de SSH esté configurado”, /etc/ssh/sshd_config tiene la siguiente configuración:

    
ClientAliveInterval 300
ClientAliveCountMax 0

    El propósito de esta configuración es finalizar una sesión de cliente después de 5 minutos de tiempo de inactividad. Sin embargo, el valor ClientAliveCountMax 0 causa un comportamiento inesperado. Cuando utilizas la sesión SSH en la estación de trabajo de administrador o en un nodo del clúster, la conexión SSH puede desconectarse incluso si el cliente SSH no está inactivo, como cuando se ejecuta un comando lento, y el comando podría finalizar con el siguiente mensaje:

    
Connection to [IP] closed by remote host.
Connection to [IP] closed.

    Solución alternativa:

    Tienes varias opciones:

    • Usa nohup para evitar que el comando se finalice cuando se desconecte la conexión SSH. 
      
nohup gkectl upgrade admin --config admin-cluster.yaml \
    --kubeconfig kubeconfig
    • Actualiza sshd_config para usar un valor de ClientAliveCountMax distinto de cero. La regla de CIS recomienda usar un valor inferior a 3: 
      
sudo sed -i 's/ClientAliveCountMax 0/ClientAliveCountMax 1/g' \
    /etc/ssh/sshd_config
sudo systemctl restart sshd

    Asegúrate de volver a conectar tu sesión SSH.
    Instalación 1.10, 1.11, 1.12, 1.13

    Instalación de cert-manager en conflicto

    En las versiones 1.13, monitoring-operator instalará cert-manager en el espacio de nombres cert-manager. Si por ciertos motivos necesitas instalar tu propio cert-manager, sigue estas instrucciones para evitar conflictos:

    Solo necesitas aplicar esta solución una vez para cada clúster, y los cambios se conservarán durante la actualización del clúster.

    Nota: Un síntoma común de la instalación de tu propio cert-manager es que la versión o imagen de cert-manager (por ejemplo, v1.7.2) puede revertir a su versión anterior. Esto se debe a que monitoring-operator intenta conciliar cert-manager y revertir la versión en el proceso.

    Solución alternativa:

    Cómo evitar conflictos durante la actualización

    1. Desinstala tu versión de cert-manager. Si definiste tus propios recursos, puedes crear una copia de seguridad de ellos.
    2. Realiza la actualización.
    3. Sigue las instrucciones que se indican a continuación para restablecer tu propio cert-manager.

    Restablece tu propio cert-manager en los clústeres de usuario

    • Escala el Deployment monitoring-operator a 0: 
      
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    -n USER_CLUSTER_NAME \
    scale deployment monitoring-operator --replicas=0
    • Escala a 0 las implementaciones de cert-manager que administra monitoring-operator: 
      
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    -n cert-manager scale deployment cert-manager --replicas=0
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    -n cert-manager scale deployment cert-manager-cainjector\
    --replicas=0
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    -n cert-manager scale deployment cert-manager-webhook --replicas=0
    • Vuelve a instalar tu versión de cert-manager. Restablece tus recursos personalizados si lo hiciste.
    • Puedes omitir este paso si usas la instalación predeterminada de cert-manager o si estás seguro de que tu cert-manager está instalado en el espacio de nombres cert-manager. De lo contrario, copia el certificado metrics-ca cert-manager.io/v1 y los recursos de la entidad emisora metrics-pki.cluster.local de cert-manager al espacio de nombres de recursos del clúster de tu cert-manager instalado. 
      
relevant_fields='
{
  apiVersion: .apiVersion,
  kind: .kind,
  metadata: {
    name: .metadata.name,
    namespace: "YOUR_INSTALLED_CERT_MANAGER_NAMESPACE"
  },
  spec: .spec
}
'
f1=$(mktemp)
f2=$(mktemp)
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    get issuer -n cert-manager metrics-pki.cluster.local -o json \
    | jq "${relevant_fields}" > $f1
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    get certificate -n cert-manager metrics-ca -o json \
    | jq "${relevant_fields}" > $f2
kubectl apply --kubeconfig USER_CLUSTER_KUBECONFIG -f $f1
kubectl apply --kubeconfig USER_CLUSTER_KUBECONFIG -f $f2

    Restablece tu propio cert-manager en los clústeres de administrador

    En general, no deberías tener que volver a instalar cert-manager en los clústeres de administrador, ya que estos solo ejecutan GKE en las cargas de trabajo del plano de control de VMware. En los casos excepcionales en que también necesites instalar tu propio cert-manager en clústeres de administrador, sigue las siguientes instrucciones para evitar conflictos. Ten en cuenta que, si eres cliente de Apigee y solo necesitas cert-manager para Apigee, no necesitas ejecutar los comandos del clúster de administrador.

    • Escala la implementación de monitoring-operator a 0. 
      
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    -n kube-system scale deployment monitoring-operator --replicas=0
    • Escala a 0 las implementaciones de cert-manager que administra monitoring-operator. 
      
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    -n cert-manager scale deployment cert-manager \
    --replicas=0

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
     -n cert-manager scale deployment cert-manager-cainjector \
     --replicas=0

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    -n cert-manager scale deployment cert-manager-webhook \
    --replicas=0
    • Vuelve a instalar tu versión de cert-manager. Restablece tus recursos personalizados si lo hiciste.
    • Puedes omitir este paso si usas la instalación predeterminada de cert-manager o si estás seguro de que tu cert-manager está instalado en el espacio de nombres cert-manager. De lo contrario, copia el certificado metrics-ca cert-manager.io/v1 y los recursos de la entidad emisora metrics-pki.cluster.local de cert-manager al espacio de nombres de recursos del clúster de tu cert-manager instalado. 
      
relevant_fields='
{
  apiVersion: .apiVersion,
  kind: .kind,
  metadata: {
    name: .metadata.name,
    namespace: "YOUR_INSTALLED_CERT_MANAGER_NAMESPACE"
  },
  spec: .spec
}
'
f3=$(mktemp)
f4=$(mktemp)
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \n
    get issuer -n cert-manager metrics-pki.cluster.local -o json \
    | jq "${relevant_fields}" > $f3
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    get certificate -n cert-manager metrics-ca -o json \
    | jq "${relevant_fields}" > $f4
kubectl apply --kubeconfig ADMIN_CLUSTER_KUBECONFIG -f $f3
kubectl apply --kubeconfig ADMIN_CLUSTER_KUBECONFIG -f $f4
    Sistema operativo 1.10, 1.11, 1.12, 1.13

    Falsos positivos en el análisis de vulnerabilidades de Docker, containerd y runc

    Docker, containerd y runc en las imágenes del SO Ubuntu que se envían con GKE en VMware se fijan a versiones especiales mediante PPA de Ubuntu. Esto garantiza que GKE on VMware califique cualquier cambio en el entorno de ejecución del contenedor antes de cada lanzamiento.

    Sin embargo, el rastreador de CVE de Ubuntu no conoce las versiones especiales, que se usa como feed de vulnerabilidades por varias herramientas de análisis de CVE. Por lo tanto, verás falsos positivos en los resultados del análisis de vulnerabilidades de Docker, containerd y runc.

    Por ejemplo, es posible que veas los siguientes falsos positivos de los resultados del análisis de CVE. Estas CVE ya se corrigieron en las versiones de parche más recientes de GKE on VMware.

    Consulta las notas de la versión] para obtener información sobre las correcciones de CVE.


    Solución alternativa:

    Canonical está al tanto de este problema, y se hace un seguimiento de su solución en https://github.com/canonical/sec-cvescan/issues/73.
    Revisiones y actualizaciones 1.10, 1.11, 1.12, 1.13

    Es posible que la conexión de red entre el clúster de administrador y el de usuario no esté disponible por un período breve durante la actualización del clúster sin alta disponibilidad.

    Si actualizas clústeres que no son de alta disponibilidad de 1.9 a 1.10, es posible que notes que kubectl exec, kubectl log y webhook con los clústeres de usuario pueden no estar disponibles por un corto tiempo. Este tiempo de inactividad puede ser de hasta un minuto. Esto sucede porque kube‐apiserver controla la solicitud entrante (kubectl exec, kubectl log y webhook) para el clúster de usuario. El usuario kube-apiserver es un conjunto con estado. En un clúster sin alta disponibilidad, solo hay una réplica para el Statefulset. Por lo tanto, durante la actualización, es posible que el kube-apiserver anterior no esté disponible, mientras que el nuevo kube-apiserver aún no está listo.


    Solución alternativa:

    Este tiempo de inactividad solo ocurre durante el proceso de actualización. Si deseas un tiempo de inactividad más breve durante la actualización, te recomendamos que cambies a clústeres con alta disponibilidad.
    Instalación, actualizaciones y actualizaciones 1.10, 1.11, 1.12, 1.13

    La verificación de preparación de Konnectivity falló en el diagnóstico del clúster de alta disponibilidad después de la creación o actualización del clúster.

    Si estás creando o actualizando un clúster de HA y notas que la verificación de preparación de la konnectivity falló en el diagnóstico del clúster, en la mayoría de los casos, esto no afectará la funcionalidad de GKE en VMware (kubectl exec, kubectl log y webhook). Esto sucede porque, a veces, una o dos de las réplicas de conectividad pueden no estar listas para un período debido a redes inestables o a otros problemas.


    Solución alternativa:

    La conectividad se recuperará sola. Espera entre 30 minutos y 1 hora y vuelve a ejecutar el diagnóstico del clúster.
    Sistema operativo 1.7, 1.8, 1.9, 1.10, 1.11

    /etc/cron.daily/aide Problema de aumento de memoria y CPU

    A partir de la versión 1.7.2 de GKE en VMware, las imágenes del SO Ubuntu se endurecen con CIS L1 Server Benchmark.

    Como resultado, la secuencia de comandos cron /etc/cron.daily/aide se instaló para que se programe una verificación de aide a fin de garantizar que se siga la regla CIS L1 Server “1.4.2 Asegúrate de que la integridad del sistema de archivos se verifique con regularidad”.

    El trabajo cron se ejecuta todos los días a las 6:25 a.m. UTC. Según la cantidad de archivos en el sistema de archivos, es posible que experimentes aumentos repentinos en el uso de CPU y memoria en ese período causados por este proceso aide.


    Solución alternativa:

    Si los aumentos afectan tu carga de trabajo, puedes inhabilitar el trabajo cron diario:

    
sudo chmod -x /etc/cron.daily/aide
    Redes 1.10, 1.11, 1.12, 1.13

    Los balanceadores de cargas y las reglas de firewall distribuidas con estado de NSX-T interactúan de forma impredecible

    Cuando se implementa GKE en VMware versión 1.9 o posterior, si la implementación tiene el balanceador de cargas en paquetes de Seesaw en un entorno que usa reglas de firewall distribuidas con estado NSX-T, es posible que stackdriver-operator no cree un ConfigMap gke-metrics-agent-conf y haga que los Pods gke-connect-agent estén en un bucle de fallas.

    El problema subyacente es que las reglas de firewall distribuidas por NSX-T con estado finalizan la conexión de un cliente al servidor de la API del clúster de usuario a través del balanceador de cargas de Seesaw, ya que usa flujos de conexión asimétrica. Los problemas de integración con las reglas de firewall distribuidas de NSX-T afectan a todas las versiones de GKE on VMware que usan Seesaw. Es posible que veas problemas de conexión similares en tus propias aplicaciones cuando creen objetos grandes de Kubernetes con tamaños superiores a 32,000.


    Solución alternativa:

    Sigue estas instrucciones para inhabilitar las reglas de firewall distribuidas de NSX-T o usar reglas de firewall distribuidas sin estado para las VMs de Seesaw.

    Si tus clústeres usan un balanceador de cargas manual, sigue estas instrucciones para configurar tu balanceador de cargas y restablecer las conexiones de clientes cuando detecte una falla en un nodo de backend. Sin esta configuración, los clientes del servidor de la API de Kubernetes podrían dejar de responder durante varios minutos cuando una instancia de servidor falle.
    Registro y supervisión 1.10, 1.11, 1.12, 1.13, 1.14, 1.15

    Facturación de supervisión inesperada

    Para las versiones de GKE on VMware 1.10 a 1.15, algunos clientes encontraron una facturación inesperadamente alta para Metrics volume en la página Facturación. Este problema te afecta solo cuando se cumplen todas las siguientes circunstancias:

    • El registro y la supervisión de la aplicación está habilitado (enableStackdriverForApplications=true)
    • Los Pods de la aplicación tienen la anotación prometheus.io/scrap=true. (la instalación de Anthos Service Mesh también puede agregar esta anotación).

    Para confirmar si te afecta este problema, enumera tus métricas definidas por el usuario. Si observas la facturación de métricas no deseadas con el prefijo de nombre external.googleapis.com/prometheus y también ves enableStackdriverForApplications configurado como verdadero en la respuesta de kubectl -n kube-system get stackdriver stackdriver -o yaml, este problema se aplica a ti.


    Solución alternativa

    Si te afecta este problema, te recomendamos que actualices tus clústeres a la versión 1.12 o una posterior, dejes de usar la marca enableStackdriverForApplications y cambies a la nueva solución de supervisión de aplicaciones managed-service-for-prometheus que ya no dependa de la anotación prometheus.io/scrap=true. Con la nueva solución, también puedes controlar la recopilación de registros y métricas por separado para tus aplicaciones, con las marcas enableCloudLoggingForApplications y enableGMPForApplications, respectivamente.

    Para dejar de usar la marca enableStackdriverForApplications, abre el objeto `stackdriver` para editar:

    
kubectl --kubeconfig=USER_CLUSTER_KUBECONFIG --namespace kube-system edit stackdriver stackdriver

    Quita la línea enableStackdriverForApplications: true, guarda el editor y ciérralo.

    Si no puedes salir de la recopilación de métricas basadas en anotaciones, sigue estos pasos:

    1. Busca los Pods y los Services de origen que tienen las métricas facturadas no deseadas. 
      
kubectl --kubeconfig KUBECONFIG \
  get pods -A -o yaml | grep 'prometheus.io/scrape: "true"'
kubectl --kubeconfig KUBECONFIG get \
  services -A -o yaml | grep 'prometheus.io/scrape: "true"'
    2. Quita la anotación prometheus.io/scrap=true del Pod o Service. Si Anthos Service Mesh agrega la anotación, considera configurar Anthos Service Mesh sin la opción de Prometheus o desactivar la función de combinación de métricas de Istio.
    Instalación 1.11, 1.12, 1.13

    El instalador falla cuando se crea el disco de datos de vSphere

    El instalador de GKE on VMware puede fallar si los roles personalizados están vinculados al nivel de permisos incorrecto.

    Cuando la vinculación de función es incorrecta, se bloquea la creación de un disco de datos de vSphere con govc y se crea el disco con un tamaño igual a 0. Para solucionar el problema, debes vincular la función personalizada a nivel de vSphere vCenter (raíz).


    Solución alternativa:

    Si deseas vincular la función personalizada en el nivel de DC (o de versiones anteriores), también debes vincular la función de solo lectura al usuario en el nivel raíz de vCenter.

    Para obtener más información sobre la creación de funciones, consulta Privilegios de la cuenta de usuario de vCenter.
    Registro y supervisión 1.9.0-1.9.4, 1.10.0-1.10.1

    Alto tráfico de red en monitoring.googleapis.com

    Es posible que veas un alto tráfico de red a monitoring.googleapis.com, incluso en un clúster nuevo que no tiene cargas de trabajo del usuario.

    Este problema afecta a las versiones 1.10.0-1.10.1 y 1.9.0-1.9.4. Este problema se solucionó en las versiones 1.10.2 y 1.9.5.


    Solución alternativa:
    Registro y supervisión 1.10, 1.11

    gke-metrics-agent tiene errores frecuentes de CrashLoopBackOff

    Para GKE en VMware versión 1.10 y posteriores, “gke-metrics-agent” DaemonSet tiene errores frecuentes de CrashLoopBackOff cuando “enableStackdriverForApplications” se configura como “true” en el objeto “stackdriver”.


    Solución alternativa:

    Para mitigar este problema, inhabilita la recopilación de métricas de la aplicación mediante la ejecución de los siguientes comandos. Estos comandos no inhabilitarán la recopilación de registros de la aplicación.

    1. Para evitar que se reviertan los siguientes cambios, reduce verticalmente la escala de stackdriver-operator: 
      
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    --namespace kube-system scale deploy stackdriver-operator \
    --replicas=0
      Reemplaza USER_CLUSTER_KUBECONFIG por la ruta de acceso del archivo kubeconfig del clúster de usuario.
    2. Abre el ConfigMap gke-metrics-agent-conf para editar: 
      
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    --namespace kube-system edit configmap gke-metrics-agent-conf
    3. En services.pipelines, marca como comentario toda la sección metrics/app-metrics: 
      
services:
  pipelines:
    #metrics/app-metrics:
    #  exporters:
    #  - googlecloud/app-metrics
    #  processors:
    #  - resource
    #  - metric_to_resource
    #  - infer_resource
    #  - disk_buffer/app-metrics
    #  receivers:
    #  - prometheus/app-metrics
    metrics/metrics:
      exporters:
      - googlecloud/metrics
      processors:
      - resource
      - metric_to_resource
      - infer_resource
      - disk_buffer/metrics
      receivers:
      - prometheus/metrics
    4. Cierra la sesión de edición.
    5. Reinicia el DaemonSet gke-metrics-agent: 
      
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    --namespace kube-system rollout restart daemonset gke-metrics-agent
    Registro y supervisión 1.11, 1.12, 1.13

    Reemplaza métricas obsoletas en el panel

    Si se usan métricas obsoletas en los paneles listos para usar, verás algunos gráficos vacíos. Para encontrar métricas obsoletas en los paneles de Monitoring, ejecuta los siguientes comandos:

    
gcloud monitoring dashboards list > all-dashboard.json

# find deprecated metrics
cat all-dashboard.json | grep -E \
  'kube_daemonset_updated_number_scheduled\
    |kube_node_status_allocatable_cpu_cores\
    |kube_node_status_allocatable_pods\
    |kube_node_status_capacity_cpu_cores'

    Las siguientes métricas obsoletas deben migrarse a sus reemplazos.

    ObsoletoReemplazo
    kube_daemonset_updated_number_scheduled kube_daemonset_status_updated_number_scheduled
    kube_node_status_allocatable_cpu_cores
    kube_node_status_allocatable_memory_bytes
    kube_node_status_allocatable_pods    		 kube_node_status_allocatable
    kube_node_status_capacity_cpu_cores
    kube_node_status_capacity_memory_bytes
    kube_node_status_capacity_pods    		 kube_node_status_capacity
    kube_hpa_status_current_replicas kube_horizontalpodautoscaler_status_current_replicas

    Solución alternativa:

    Para reemplazar las métricas obsoletas

    1. Borra el “estado del nodo de GKE On-Prem” en el panel de Google Cloud Monitoring. Vuelve a instalar el “estado del nodo de GKE On-Prem” según estas instrucciones.
    2. Borra el “Uso de nodos de GKE On-Prem” en el panel de Google Cloud Monitoring. Vuelve a instalar “Uso de nodos de GKE On-Prem” según estas instrucciones.
    3. Borra el “estado de la VM de vSphere de GKE On-Prem” en el panel de Google Cloud Monitoring. Vuelve a instalar “Estado de la VM de vSphere de GKE On-Prem” siguiendo estas instrucciones.

      4. Esta baja se debe a la actualización del agente de kube-state-metrics de la versión 1.9 a la versión 2.4, que es necesaria para Kubernetes 1.22. Puedes reemplazar todas las métricas kube-state-metrics obsoletas, que tienen el prefijo kube_, en tus paneles personalizados o políticas de alertas.
    Registro y supervisión 1.10, 1.11, 1.12, 1.13

    Datos de métricas desconocidos en Cloud Monitoring

    Para GKE on VMware versión 1.10 y posteriores, los datos de los clústeres en Cloud Monitoring pueden contener entradas de métricas de resumen irrelevantes, como las siguientes:

    
Unknown metric: kubernetes.io/anthos/go_gc_duration_seconds_summary_percentile

    Otros tipos de métricas que pueden tener métricas de resumen irrelevantes incluyen

    :
    • apiserver_admission_step_admission_duration_seconds_summary
    • go_gc_duration_seconds
    • scheduler_scheduling_duration_seconds
    • gkeconnect_http_request_duration_seconds_summary
    • alertmanager_nflog_snapshot_duration_seconds_summary

    Si bien estas métricas de tipo de resumen se encuentran en la lista de métricas, por el momento no son compatibles con gke-metrics-agent.
    Registro y supervisión 1.10, 1.11, 1.12, 1.13

    Faltan métricas en algunos nodos

    Es posible que falten las siguientes métricas en algunos nodos, pero no en todos:

    • kubernetes.io/anthos/container_memory_working_set_bytes
    • kubernetes.io/anthos/container_cpu_usage_seconds_total
    • kubernetes.io/anthos/container_network_receive_bytes_total

    Solución alternativa:

    Para solucionar este problema, sigue estos pasos como solución alternativa. Para [versión 1.9.5+, 1.10.2+, 1.11.0]: aumenta la CPU para gke-metrics-agent siguiendo los pasos 1 a 4.

    1. Abre tu recurso stackdriver para editarlo: 
      
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    --namespace kube-system edit stackdriver stackdriver
    2. Para aumentar la solicitud de CPU de gke-metrics-agent de 10m a 50m, el límite de CPU de 100m a 200m agrega la siguiente sección resourceAttrOverride al manifiesto de stackdriver : 
      
spec:
  resourceAttrOverride:
    gke-metrics-agent/gke-metrics-agent:
      limits:
        cpu: 100m
        memory: 4608Mi
      requests:
        cpu: 10m
        memory: 200Mi
      El recurso editado debe ser similar al siguiente: 
      
spec:
  anthosDistribution: on-prem
  clusterLocation: us-west1-a
  clusterName: my-cluster
  enableStackdriverForApplications: true
  gcpServiceAccountSecretName: ...
  optimizedMetrics: true
  portable: true
  projectID: my-project-191923
  proxyConfigSecretName: ...
  resourceAttrOverride:
    gke-metrics-agent/gke-metrics-agent:
      limits:
        cpu: 200m
        memory: 4608Mi
      requests:
        cpu: 50m
        memory: 200Mi
    3. Guarda los cambios y cierra el editor de texto.
    4. Para verificar que los cambios se aplicaron, ejecuta el siguiente comando: 
      
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    --namespace kube-system get daemonset gke-metrics-agent -o yaml \
    | grep "cpu: 50m"
      El comando encuentra cpu: 50m si tus ediciones se aplicaron.
    Registro y supervisión 1.11.0-1.11.2, 1.12.0

    Faltan las métricas de programador y controlador-administrador en el clúster de administrador

    Si el clúster de administrador se ve afectado por este problema, faltan las métricas del programador y del controlador y administrador. Por ejemplo, faltan estas dos métricas

    
# scheduler metric example
scheduler_pending_pods
# controller-manager metric example
replicaset_controller_rate_limiter_use

    Solución alternativa:

    Actualiza a v1.11.3+, v1.12.1+ o v1.13+.
    1.11.0-1.11.2, 1.12.0

    Faltan métricas de programador y controlador-administrador en el clúster de usuario

    Si este problema afecta al clúster de usuario, faltan las métricas del programador y del controlador y administrador. Por ejemplo, faltan estas dos métricas:

    
# scheduler metric example
scheduler_pending_pods
# controller-manager metric example
replicaset_controller_rate_limiter_use

    Solución alternativa:

    Este problema se solucionó en GKE on VMware 1.13.0 y versiones posteriores. Actualiza el clúster a una versión que incluya la solución.
    Instalación, actualizaciones y actualizaciones 1.10, 1.11, 1.12, 1.13

    No se pudo registrar el clúster de administrador durante la creación

    Si creas un clúster de administrador para la versión 1.9.x o 1.10.0, y si este no se puede registrar con la especificación gkeConnect proporcionada durante su creación, verás el siguiente error.

    
Failed to create root cluster: failed to register admin cluster: failed to register cluster: failed to apply Hub Membership: Membership API request failed: rpc error:  ode = PermissionDenied desc = Permission 'gkehub.memberships.get' denied on PROJECT_PATH

    Podrás seguir usando este clúster de administrador, pero obtendrás el siguiente error si luego intentas actualizar el clúster de administrador a la versión 1.10.y.

    
failed to migrate to first admin trust chain: failed to parse current version "": invalid version: "" failed to migrate to first admin trust chain: failed to parse current version "": invalid version: ""

    Solución alternativa:
    Identidad 1.10, 1.11, 1.12, 1.13

    El uso de GKE Identity Service puede hacer que el agente de Connect se reinicie de forma impredecible

    Si usas la función de GKE Identity Service para administrar GKE Identity Service ClientConfig, es posible que el agente de Connect se reinicie de forma inesperada.


    Solución alternativa:

    Si tuviste este problema con un clúster existente, puedes realizar una de las siguientes acciones:

    • Inhabilitar GKE Identity Service Si inhabilitas GKE Identity Service, no se quitará el objeto binario implementado de GKE Identity Service ni se quitará ClientConfig de GKE Identity Service. Para inhabilitar GKE Identity Service, ejecuta este comando: 
      
gcloud container fleet identity-service disable \
    --project PROJECT_ID
      Reemplaza PROJECT_ID por el ID del proyecto host de la flota del clúster.
    • Actualiza el clúster a la versión 1.9.3 o posterior, o a la versión 1.10.1 o posterior para actualizar la versión del agente de Connect.
    Redes 1.10, 1.11, 1.12, 1.13

    Cisco ACI no funciona con el retorno directo del servidor (DSR)

    Seesaw se ejecuta en modo DSR y, de forma predeterminada, no funciona en Cisco ACI debido al aprendizaje de IP del plano de datos.


    Solución alternativa:

    Una posible solución alternativa es inhabilitar el aprendizaje de IP. Para ello, agrega la dirección IP de Seesaw como una IP virtual L4-L7 en el Controlador de infraestructura de la política de aplicaciones (APIC) de Cisco.

    Puedes configurar la opción de IP virtual de las capas L4-L7 en Usuario > Perfiles de aplicación > EPG de aplicaciones o uSeg EPGs. No inhabilitar el aprendizaje de IP provocará oscilaciones en el extremo de IP entre diferentes ubicaciones en la estructura de la API de Cisco.
    VMware 1.10, 1.11, 1.12, 1.13

    Problemas con la actualización 3 de vSphere 7.0

    Hace poco, VMware identificó problemas críticos en las siguientes versiones de vSphere 7.0 actualización 3:

    • Actualización 3 de vSphere ESXi 7.0 (compilación 18644231)
    • Actualización 3a de vSphere ESXi 7.0 (compilación 18825058)
    • Actualización 3b de vSphere ESXi 7.0 (compilación 18905247)
    • Actualización 3b de vSphere vCenter 7.0 (compilación 18901211)

    Solución alternativa:

    Desde entonces, VMware quitó estas versiones. Debes actualizar ESXi y los vCenter Servers a una versión más reciente.
    Sistema operativo 1.10, 1.11, 1.12, 1.13

    No se pudo activar el Volume emptyDir como exec en el Pod que se ejecuta en los nodos COS

    Para los pods que se ejecutan en nodos que usan imágenes de Container-Optimized OS (COS), no puedes activar el volumen emptyDir como exec. Se activa como noexec y aparecerá el siguiente error: exec user process caused: permission denied. Por ejemplo, verás este mensaje de error si implementas el siguiente Pod de prueba:

    
apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: null
  labels:
    run: test
  name: test
spec:
  containers:
  - args:
    - sleep
    - "5000"
    image: gcr.io/google-containers/busybox:latest
    name: test
    volumeMounts:
      - name: test-volume
        mountPath: /test-volume
    resources:
      limits:
        cpu: 200m
        memory: 512Mi
  dnsPolicy: ClusterFirst
  restartPolicy: Always
  volumes:
    - emptyDir: {}
      name: test-volume

    Y en el Pod de prueba, si ejecutas mount | grep test-volume, se mostrará la opción noexec:

    
/dev/sda1 on /test-volume type ext4 (rw,nosuid,nodev,noexec,relatime,commit=30)

    Solución alternativa:
    Revisiones y actualizaciones 1.10, 1.11, 1.12, 1.13

    La actualización de la réplica del grupo de nodos del clúster no funciona después de que se inhabilita el ajuste de escala automático en el grupo de nodos

    Las réplicas del grupo de nodos no se actualizan una vez que se habilita el ajuste de escala automático y se inhabilita en un grupo de nodos.


    Solución alternativa:

    Se quitan las anotaciones cluster.x-k8s.io/cluster-api-autoscaler-node-group-max-size y cluster.x-k8s.io/cluster-api-autoscaler-node-group-min-size de la implementación de máquina del grupo de nodos correspondiente.
    Registro y supervisión 1.11, 1.12, 1.13

    En los paneles de supervisión de Windows, se muestran datos de clústeres de Linux

    A partir de la versión 1.11, en los paneles de supervisión listos para usar, el panel de estado del Pod de Windows y el panel de estado de los nodos de Windows también muestran datos de los clústeres de Linux. Esto se debe a que las métricas del nodo y del Pod de Windows también se exponen en los clústeres de Linux.
    Registro y supervisión 1.10, 1.11, 1.12

    stackdriver-log-forwarder en la constante CrashLoopBackOff

    Para GKE on VMware versión 1.10, 1.11 y 1.12, stackdriver-log-forwarder DaemonSet puede tener errores CrashLoopBackOff cuando hay registros almacenados en búfer que no funcionan en el disco.


    Solución alternativa:

    Para mitigar este problema, tendremos que limpiar los registros almacenados en búfer en el nodo.

    1. Para evitar un comportamiento inesperado, reduce verticalmente la escala de stackdriver-log-forwarder: 
      
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    -n kube-system patch daemonset stackdriver-log-forwarder -p '{"spec": {"template": {"spec": {"nodeSelector": {"non-existing": "true"}}}}}'
      Reemplaza USER_CLUSTER_KUBECONFIG por la ruta de acceso del archivo kubeconfig del clúster de usuario.
    2. Implementa el DaemonSet de limpieza para limpiar los fragmentos rotos: 
      
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    -n kube-system -f - << EOF
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluent-bit-cleanup
  namespace: kube-system
spec:
  selector:
    matchLabels:
      app: fluent-bit-cleanup
  template:
    metadata:
      labels:
        app: fluent-bit-cleanup
    spec:
      containers:
      - name: fluent-bit-cleanup
        image: debian:10-slim
        command: ["bash", "-c"]
        args:
        - |
          rm -rf /var/log/fluent-bit-buffers/
          echo "Fluent Bit local buffer is cleaned up."
          sleep 3600
        volumeMounts:
        - name: varlog
          mountPath: /var/log
        securityContext:
          privileged: true
      tolerations:
      - key: "CriticalAddonsOnly"
        operator: "Exists"
      - key: node-role.kubernetes.io/master
        effect: NoSchedule
      - key: node-role.gke.io/observability
        effect: NoSchedule
      volumes:
      - name: varlog
        hostPath:
          path: /var/log
EOF
    3. Para asegurarte de que el DaemonSet de limpieza limpió todos los fragmentos, puedes ejecutar los siguientes comandos. El resultado de los dos comandos debe ser igual a la cantidad de nodos en el clúster: 
      
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
  logs -n kube-system -l app=fluent-bit-cleanup | grep "cleaned up" | wc -l

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
  -n kube-system get pods -l app=fluent-bit-cleanup --no-headers | wc -l
    4. Borra el DaemonSet de limpieza: 
      
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
  -n kube-system delete ds fluent-bit-cleanup
    5. Reanudar stackdriver-log-forwarder: 
      
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
  -n kube-system patch daemonset stackdriver-log-forwarder --type json -p='[{"op": "remove", "path": "/spec/template/spec/nodeSelector/non-existing"}]'
    Registro y supervisión 1.10, 1.11, 1.12, 1.13, 1.14, 1.15, 1.16

    stackdriver-log-forwarder no envía registros a Cloud Logging

    Si no ves registros en Cloud Logging de tus clústeres y observas el siguiente error en tus registros: 

    
2023-06-02T10:53:40.444017427Z [2023/06/02 10:53:40] [error] [input chunk] chunk 1-1685703077.747168499.flb would exceed total limit size in plugin stackdriver.0
2023-06-02T10:53:40.444028047Z [2023/06/02 10:53:40] [error] [input chunk] no available chunk
    Es probable que la frecuencia de entrada de registros supere el límite del agente de Logging, lo que hace que stackdriver-log-forwarder no envíe registros. Este problema ocurre en todas las versiones de GKE en VMware.

    Solución alternativa:

    Para mitigar este problema, debes aumentar el límite de recursos en el agente de Logging.

    1. Abre tu recurso stackdriver para editarlo: 
      
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    --namespace kube-system edit stackdriver stackdriver
    2. Si deseas aumentar la solicitud de CPU para stackdriver-log-forwarder, agrega la siguiente sección resourceAttrOverride al manifiesto stackdriver : 
      
spec:
  resourceAttrOverride:
    stackdriver-log-forwarder/stackdriver-log-forwarder:
      limits:
        cpu: 1200m
        memory: 600Mi
      requests:
        cpu: 600m
        memory: 600Mi
      El recurso editado debe ser similar al siguiente: 
      
spec:
  anthosDistribution: on-prem
  clusterLocation: us-west1-a
  clusterName: my-cluster
  enableStackdriverForApplications: true
  gcpServiceAccountSecretName: ...
  optimizedMetrics: true
  portable: true
  projectID: my-project-191923
  proxyConfigSecretName: ...
  resourceAttrOverride:
    stackdriver-log-forwarder/stackdriver-log-forwarder:
      limits:
        cpu: 1200m
        memory: 600Mi
      requests:
        cpu: 600m
        memory: 600Mi
    3. Guarda los cambios y cierra el editor de texto.
    4. Para verificar que los cambios se aplicaron, ejecuta el siguiente comando: 
      
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    --namespace kube-system get daemonset stackdriver-log-forwarder -o yaml \
    | grep "cpu: 1200m"
      El comando encuentra cpu: 1200m si tus ediciones se aplicaron.
    Seguridad 1.13

    El servicio de Kubelet no estará disponible temporalmente después de NodeReady

    hay un período breve en el que el nodo estará listo, pero el certificado del servidor de Kubelet no lo estará. kubectl exec y kubectl logs no están disponibles durante estas decenas de segundos. Esto se debe a que el nuevo responsable de aprobación del certificado de servidor tarda en ver las IP válidas actualizadas del nodo.

    Este problema solo afecta al certificado del servidor de kubelet; no afectará la programación del Pod.
    Revisiones y actualizaciones 1.12

    La actualización parcial del clúster de administrador no bloquea la actualización posterior del clúster de usuario

    La actualización del clúster de usuario falló con lo siguiente:

    
.LBKind in body is required (Check the status of OnPremUserCluster 'cl-stg-gdl-gke-onprem-mgmt/cl-stg-gdl' and the logs of pod 'kube-system/onprem-user-cluster-controller' for more detailed debugging information.

    El clúster de administrador no está completamente actualizado y la versión de estado sigue siendo 1.10. La actualización del clúster de usuario a la versión 1.12 no se bloqueará con ninguna verificación preliminar y fallará con un problema de sesgo de versiones.


    Solución alternativa:

    Completa la actualización del clúster de administrador a la versión 1.11 primero y, luego, actualiza el clúster de usuario a la versión 1.12.
    Almacenamiento 1.10.0-1.10.5, 1.11.0-1.11.2, 1.12.0

    Datastore informa de forma incorrecta que no hay suficiente espacio libre

    El comando gkectl diagnose cluster falló con: 

    
Checking VSphere Datastore FreeSpace...FAILURE
    Reason: vCenter datastore: [DATASTORE_NAME] insufficient FreeSpace, requires at least [NUMBER] GB

    La validación del espacio libre del almacén de datos no se debe usar para los grupos de nodos del clúster existentes y se agregó en gkectl diagnose cluster por error.


    Solución alternativa:

    Puedes ignorar el mensaje de error, o bien omitir la validación con --skip-validation-infra.
    Operación, Herramientas de redes 1.11, 1.12.0 a 1.12.1

    No se puede agregar un clúster de usuario nuevo cuando el clúster de administrador usa el balanceador de cargas de MetalLB

    Es posible que no puedas agregar un clúster de usuario nuevo si el clúster de administrador está configurado con un balanceador de cargas de MetalLB.

    Es posible que el proceso de eliminación del clúster de usuario se detenga por algún motivo que dé como resultado una invalidación del ConfigMap de MatalLB. No se podrá agregar un clúster de usuario nuevo en este estado.


    Solución alternativa:

    Puedes forzar la eliminación del clúster de usuario.
    Instalación, sistema operativo 1.10, 1.11, 1.12, 1.13

    Errores cuando se usa Container-Optimized OS (COS) para el clúster de usuario

    Si osImageType usa cos para el clúster de administrador y cuando se ejecuta gkectl check-config después de la creación del clúster de administrador y antes de la creación del clúster de usuario, fallará en los siguientes casos: 

    
Failed to create the test VMs: VM failed to get IP addresses on the network.

    De forma predeterminada, la VM de prueba creada para el clúster de usuario check-config usa el mismo osImageType del clúster de administrador y, por el momento, la VM de prueba aún no es compatible con COS.


    Solución alternativa:

    Para evitar la comprobación previa lenta que crea la VM de prueba, usa gkectl check-config --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG --fast.
    Registro y supervisión 1.12.0-1.12.1

    Grafana en el clúster de administrador no puede acceder a los clústeres de usuario

    Este problema afecta a los clientes que usan Grafana en el clúster de administrador para supervisar los clústeres de usuario en las versiones 1.12.0 y 1.12.1 de GKE en VMware. Proviene de una discrepancia de los certificados de cliente pushprox en los clústeres de usuario y de la lista de entidades permitidas del servidor pushprox en el clúster de administrador. El síntoma es un cliente pushprox en los clústeres de usuario que imprimen registros de errores como los siguientes:

    
level=error ts=2022-08-02T13:34:49.41999813Z caller=client.go:166 msg="Error reading request:" err="invalid method \"RBAC:\""

    Solución alternativa:
    Otro 1.11.3

    gkectl repair admin-master no proporciona la plantilla de VM que se usará para la recuperación

    El comando gkectl repair admin-master falló con: 

    
Failed to repair: failed to select the template: no VM templates is available for repairing the admin master (check if the admin cluster version >= 1.4.0 or contact support

    gkectl repair admin-master no puede recuperar la plantilla de VM que se usará para reparar la VM del plano de control de administrador si su nombre termina con los caracteres t, m, p o l.


    Solución alternativa:

    Vuelve a ejecutar el comando con --skip-validation.
    Registro y supervisión 1.11, 1.12, 1.13, 1.14, 1.15, 1.16

    Se produjo un error en el registro de auditoría de Cloud debido a que se denegó el permiso

    Los Registros de auditoría de Cloud necesitan una configuración de permisos especial que, por el momento, solo se realiza de forma automática para los clústeres de usuario a través de GKE Hub. Se recomienda tener al menos un clúster de usuario que use el mismo ID del proyecto y la misma cuenta de servicio con el clúster de administrador para los Registros de auditoría de Cloud, de modo que el clúster de administrador tenga el permiso necesario.

    Sin embargo, en los casos en los que el clúster de administrador usa un ID del proyecto o una cuenta de servicio diferentes a los de cualquier clúster de usuario, los registros de auditoría del clúster de administrador no se insertarían en Google Cloud. El síntoma es una serie de errores Permission Denied en el Pod audit-proxy del clúster de administrador.

    Solución alternativa:
    Operaciones, seguridad 1.11

    Verificando gkectl diagnose fallas en los certificados

    Si tu estación de trabajo no tiene acceso a los nodos trabajadores del clúster de usuario, experimentará las siguientes fallas cuando ejecute gkectl diagnose:

    
Checking user cluster certificates...FAILURE
    Reason: 3 user cluster certificates error(s).
    Unhealthy Resources:
    Node kubelet CA and certificate on node xxx: failed to verify kubelet certificate on node xxx: dial tcp xxx.xxx.xxx.xxx:10250: connect: connection timed out
    Node kubelet CA and certificate on node xxx: failed to verify kubelet certificate on node xxx: dial tcp xxx.xxx.xxx.xxx:10250: connect: connection timed out
    Node kubelet CA and certificate on node xxx: failed to verify kubelet certificate on node xxx: dial tcp xxx.xxx.xxx.xxx:10250: connect: connection timed out

    Si tu estación de trabajo no tiene acceso a los nodos trabajadores del clúster de administrador o a los nodos trabajadores del clúster de administrador, obtendrá las siguientes fallas cuando ejecute gkectl diagnose:

    
Checking admin cluster certificates...FAILURE
    Reason: 3 admin cluster certificates error(s).
    Unhealthy Resources:
    Node kubelet CA and certificate on node xxx: failed to verify kubelet certificate on node xxx: dial tcp xxx.xxx.xxx.xxx:10250: connect: connection timed out
    Node kubelet CA and certificate on node xxx: failed to verify kubelet certificate on node xxx: dial tcp xxx.xxx.xxx.xxx:10250: connect: connection timed out
    Node kubelet CA and certificate on node xxx: failed to verify kubelet certificate on node xxx: dial tcp xxx.xxx.xxx.xxx:10250: connect: connection timed out

    Solución alternativa:

    Si es seguro ignorar estos mensajes,
    Sistema operativo 1.8, 1.9, 1.10, 1.11, 1.12, 1.13

    /var/log/audit/ está llenando el espacio en el disco de las VMs

    /var/log/audit/ está lleno de registros de auditoría. Para verificar el uso del disco, ejecuta sudo du -h -d 1 /var/log/audit.

    Algunos comandos gkectl en la estación de trabajo de administrador, por ejemplo, gkectl diagnose snapshot, contribuyen al uso del espacio en disco.

    A partir de GKE en VMware v1.8, la imagen de Ubuntu se endurece con la comparativa de CIS para el nivel 2. Y una de las reglas de cumplimiento, “4.1.2.2”, garantiza que los registros de auditoría no se borren de forma automática", que garantiza el parámetro de configuración auditd max_log_file_action = keep_logs. Esto da como resultado todas las reglas de auditoría que se mantienen en el disco.


    Solución alternativa:
    Redes 1.10, 1.11.0-1.11.3, 1.12.0-1.12.2, 1.13.0

    NetworkGatewayGroup La IP flotante está en conflicto con la dirección del nodo

    Los usuarios no pueden crear ni actualizar objetos NetworkGatewayGroup debido al siguiente error de validación de webhook:

    
[1] admission webhook "vnetworkgatewaygroup.kb.io" denied the request: NetworkGatewayGroup.networking.gke.io "default" is invalid: [Spec.FloatingIPs: Invalid value: "10.0.0.100": IP address conflicts with node address with name: "my-node-name"

    En las versiones afectadas, el kubelet puede vincularse de forma errónea a una dirección IP flotante asignada al nodo e informarla como una dirección de nodo en node.status.addresses. El webhook de validación verifica las direcciones IP flotantes de NetworkGatewayGroup con respecto a todos los node.status.addresses del clúster y lo considera un conflicto.


    Solución alternativa:

    En el mismo clúster en el que falla la creación o actualización de objetos NetworkGatewayGroup, inhabilita temporalmente el webhook de validación de ANG y envía el cambio:

    1. Guarda la configuración del webhook para que se pueda restablecer al final: 
      
kubectl -n kube-system get validatingwebhookconfiguration \
    ang-validating-webhook-configuration -o yaml > webhook-config.yaml
    2. Edita la configuración del webhook: 
      
kubectl -n kube-system edit validatingwebhookconfiguration \
    ang-validating-webhook-configuration
    3. Quita el elemento vnetworkgatewaygroup.kb.io de la lista de configuración de webhook y cierra para aplicar los cambios.
    4. Crea o edita el objeto NetworkGatewayGroup.
    5. Vuelve a aplicar la configuración original del webhook: 
      
kubectl -n kube-system apply -f webhook-config.yaml
    Instalación, actualizaciones y actualizaciones 1.10.0-1.10.2

    Crea o actualiza el tiempo de espera del clúster de administrador

    Durante un intento de actualización del clúster de administrador, es posible que la VM del plano de control de administrador se detenga durante la creación. La VM del plano de control del administrador entra en un bucle de espera infinito durante el inicio y verás el siguiente error de bucle infinito en el archivo /var/log/cloud-init-output.log:

    
+ echo 'waiting network configuration is applied'
waiting network configuration is applied
++ get-public-ip
+++ ip addr show dev ens192 scope global
+++ head -n 1
+++ grep -v 192.168.231.1
+++ grep -Eo 'inet ([0-9]{1,3}\.){3}[0-9]{1,3}'
+++ awk '{print $2}'
++ echo
+ '[' -n '' ']'
+ sleep 1
+ echo 'waiting network configuration is applied'
waiting network configuration is applied
++ get-public-ip
+++ ip addr show dev ens192 scope global
+++ grep -Eo 'inet ([0-9]{1,3}\.){3}[0-9]{1,3}'
+++ awk '{print $2}'
+++ grep -v 192.168.231.1
+++ head -n 1
++ echo
+ '[' -n '' ']'
+ sleep 1

    Esto se debe a que cuando GKE en VMware intenta obtener la dirección IP del nodo en la secuencia de comandos de inicio, usa grep -v ADMIN_CONTROL_PLANE_VIP para omitir la VIP del plano de control del clúster de administrador, que también se puede asignar a la NIC. Sin embargo, el comando también omite cualquier dirección IP que tenga un prefijo de la VIP del plano de control, lo que hace que la secuencia de comandos de inicio se bloquee.

    Por ejemplo, supongamos que la VIP del plano de control del clúster de administrador es 192.168.1.25. Si la dirección IP de la VM del plano de control del clúster de administrador tiene el mismo prefijo, por ejemplo,192.168.1.254, la VM del plano de control se detendrá durante la creación. Este problema también se puede generar si la dirección de emisión tiene el mismo prefijo que la VIP del plano de control, por ejemplo, 192.168.1.255.


    Solución alternativa:

    • Si el motivo del tiempo de espera de creación del clúster de administrador se debe a la dirección IP de transmisión, ejecuta el siguiente comando en la VM del plano de control del clúster de administrador: 
      
ip addr add ${ADMIN_CONTROL_PLANE_NODE_IP}/32 dev ens192
      De esta manera, se creará una línea sin una dirección de emisión y se desbloqueará el proceso de inicio. Después de desbloquear la secuencia de comandos de inicio, ejecuta el siguiente comando para quitar esta línea agregada: 
      
ip addr del ${ADMIN_CONTROL_PLANE_NODE_IP}/32 dev ens192
    • Sin embargo, si el tiempo de espera de la creación del clúster de administrador se debe a la dirección IP de la VM del plano de control, no podrás desbloquear la secuencia de comandos de inicio. Cambia a una dirección IP diferente y vuelve a crearla o actualízala a la versión 1.10.3 o posterior.
    Sistema operativo, actualizaciones y actualizaciones 1.10.0-1.10.2

    El estado del clúster de administrador que usa la imagen de COS se perderá tras la actualización del clúster de administrador o la reparación de la instancia principal de administrador.

    DataDisk no se puede activar correctamente en el nodo de la instancia principal del clúster de administrador cuando se usa la imagen de COS y el estado del clúster de administrador que usa la imagen de COS se perderá cuando se actualice el clúster de administrador o se repare la instancia principal de administrador. (el clúster de administrador que usa la imagen de COS es una función de versión preliminar)


    Solución alternativa:

    Vuelve a crear el clúster de administrador con osImageType configurado como ubuntu_containerd

    Después de crear el clúster de administrador con osImageType configurado como cos, toma la clave SSH del clúster de administrador y establece una conexión SSH al nodo principal de administrador. El resultado de df -h contiene /dev/sdb1 98G 209M 93G 1% /opt/data. Y lsblk resultado contiene -sdb1 8:17 0 100G 0 part /opt/data
    Sistema operativo 1.10

    Búsqueda de DNS con error resuelto por el sistema en dominios .local

    En la versión 1.10.0 de GKE en VMware, las resoluciones de nombres en Ubuntu se enrutan a la escucha local resuelta por el sistema en 127.0.0.53 de forma predeterminada. Esto se debe a que, en la imagen de Ubuntu 20.04 que se usa en la versión 1.10.0, /etc/resolv.conf está vinculado mediante un symlink a /run/systemd/resolve/stub-resolv.conf, que apunta al stub de DNS de localhost 127.0.0.53.

    Como resultado, la resolución de nombres de DNS de localhost niega a verificar los servidores DNS ascendentes (especificados en /run/systemd/resolve/resolv.conf) en busca de nombres con el sufijo .local, a menos que los nombres se especifiquen como dominios de búsqueda.

    Esto hace que las búsquedas de nombres de .local fallen. Por ejemplo, durante el inicio del nodo, kubelet no puede extraer imágenes de un registro privado con el sufijo .local. Especificar una dirección de vCenter con un sufijo .local no funcionará en una estación de trabajo de administrador.


    Solución alternativa:

    Puedes evitar este problema para los nodos del clúster si especificas el campo searchDomainsForDNS en el archivo de configuración del clúster de administrador y el archivo de configuración del clúster de usuario para incluir los dominios.

    Por el momento, gkectl update aún no admite la actualización del campo searchDomainsForDNS.

    Por lo tanto, si no configuraste este campo antes de la creación del clúster, debes establecer una conexión SSH a los nodos y omitir el stub local resuelto por el sistema. Para ello, cambia el symlink de /etc/resolv.conf de /run/systemd/resolve/stub-resolv.conf (que contiene el stub local 127.0.0.53) a /run/systemd/resolve/resolv.conf (que apunta al DNS ascendente real): 

    
sudo ln -sf /run/systemd/resolve/resolv.conf /etc/resolv.conf

    En cuanto a la estación de trabajo de administrador, gkeadm no admite la especificación de dominios de búsqueda, por lo que debes solucionar este problema con este paso manual.

    Esta solución no se mantiene después de las recreaciones de VM. Debes volver a aplicar esta solución alternativa cada vez que se vuelvan a crear VMs.
    Instalación, sistema operativo 1.10

    La IP del puente de Docker usa 172.17.0.1/16 en lugar de 169.254.123.1/24

    GKE en VMware especifica una subred dedicada para la dirección IP del puente de Docker que usa --bip=169.254.123.1/24, de modo que no reservará la subred 172.17.0.1/16 predeterminada. Sin embargo, en la versión 1.10.0, hay un error en la imagen de SO Ubuntu que hizo que se ignorara la configuración personalizada de Docker.

    Como resultado, Docker elige el valor predeterminado 172.17.0.1/16 como su subred de dirección IP de puente. Esto puede causar un conflicto de direcciones IP si ya tienes una carga de trabajo en ejecución dentro de ese rango de direcciones IP.


    Solución alternativa:

    Para solucionar este problema, debes cambiar el nombre del siguiente archivo de configuración systemd por Docker y, luego, reiniciar el servicio:

    
sudo mv /etc/systemd/system/docker.service.d/50-cloudimg-settings.cfg \
    /etc/systemd/system/docker.service.d/50-cloudimg-settings.conf

sudo systemctl daemon-reload

sudo systemctl restart docker

    Verifica que Docker elija la dirección IP del puente correcta:

    
ip a | grep docker0

    Esta solución no se mantiene después de las recreaciones de VM. Debes aplicar esta solución alternativa cada vez que se vuelvan a crear VMs.
    Revisiones y actualizaciones 1.11

    Actualización a la versión 1.11 bloqueada por Stackdriver Readiness

    En la versión 1.11.0 de GKE on VMware, existen cambios en la definición de recursos personalizados relacionados con el registro y la supervisión:

    • El nombre del grupo del recurso personalizado stackdriver cambió de addons.sigs.k8s.io a addons.gke.io.
    • El nombre del grupo de los recursos personalizados monitoring y metricsserver cambió de addons.k8s.io a addons.gke.io.
    • Las especificaciones de los recursos anteriores comenzarán a validarse según su esquema. En particular, la especificación resourceAttrOverride y storageSizeOverride en el recurso personalizado stackdriver debe tener el tipo de cadena en los valores de las solicitudes y los límites de tamaño de CPU, memoria y almacenamiento.

    Se realizan los cambios en los nombres de los grupos para cumplir con las actualizaciones de CustomResourceDefinition en Kubernetes 1.22.

    No es necesario que realices ninguna acción si no tienes una lógica adicional que aplique o edite los recursos personalizados afectados. El proceso de actualización de GKE en VMware se encargará de la migración de los recursos afectados y mantendrá las especificaciones existentes después del cambio del nombre del grupo.

    Sin embargo, si ejecutas cualquier lógica que aplique o edite los recursos afectados, se requiere atención especial. En primer lugar, se les debe hacer referencia con el nuevo nombre de grupo en tu archivo de manifiesto. Por ejemplo:

    
apiVersion: addons.gke.io/v1alpha1  ## instead of `addons.sigs.k8s.io/v1alpha1`
kind: Stackdriver

    En segundo lugar, asegúrate de que los valores de especificación resourceAttrOverride y storageSizeOverride sean de tipo string. Por ejemplo:

    
spec:
  resourceAttrOverride:
    stackdriver-log-forwarder/stackdriver-log-forwarder
      limits:
        cpu: 1000m # or "1"
        # cpu: 1 # integer value like this would not work
        memory: 3000Mi

    De lo contrario, las aplicaciones y ediciones no tendrán efecto y pueden generar un estado inesperado en los componentes de registro y supervisión. Estos son algunos de los síntomas posibles:

    • Registros de errores de conciliación en onprem-user-cluster-controller, por ejemplo: 
      
potential reconciliation error: Apply bundle components failed, requeue after 10s, error: failed to apply addon components: failed to apply bundle objects from stackdriver-operator-addon 1.11.2-gke.53 to cluster my-cluster: failed to create typed live object: .spec.resourceAttrOverride.stackdriver-log-forwarder/stackdriver-log-forwarder.limits.cpu: expected string, got &value.valueUnstructured{Value:1}
    • Error en kubectl edit stackdriver stackdriver, por ejemplo: 
      
Error from server (NotFound): stackdrivers.addons.gke.io "stackdriver" not found

    Si encuentras los errores anteriores, significa que un tipo no compatible con la especificación de CR de Stackdriver ya estaba presente antes de la actualización. Como solución alternativa, puedes editar manualmente la CR de Stackdriver bajo el nombre anterior del grupo kubectl edit stackdrivers.addons.sigs.k8s.io stackdriver y hacer lo siguiente:

    1. cambiar las solicitudes y los límites de recursos al tipo de cadena;
    2. Quita cualquier anotación addons.gke.io/migrated-and-deprecated: true si está presente.
    Luego, reanuda o reinicia el proceso de actualización.

    Sistema operativo 1.7, 1.8, 1.9, 1.10, 1.11, 1.12, 1.13, 1.14, 1.15, 1.16

    Las VMs de COS no muestran ninguna dirección IP cuando se mueven mediante un cierre incorrecto del host.

    Cuando se produce un error en el servidor ESXi y se habilita la función HA de vCenter para el servidor, todas las VM del servidor ESXi defectuoso activan el mecanismo de vMotion y se trasladan a otro servidor ESXi normal. Las VM de COS migradas perderían sus IP.

    Solución alternativa:

    Reiniciar la VM
    Redes todas las versiones anteriores a 1.14.7, 1.15.0 a 1.15.3, 1.16.0

    La respuesta de GARP enviada por Seesaw no establece el IP objetivo

    El GARP (ARP gratuito) periódico que envía Seesaw cada 20 s no establece la IP objetivo en el encabezado del ARP. Es posible que algunas redes no acepten esos paquetes (como Cisco ACI). Puede provocar un mayor tiempo de inactividad del servicio después de que se recupera un cerebro dividido (debido a la caída de paquetes VRRP).

    Solución alternativa:

    Activa una conmutación por error de Seeaw mediante la ejecución de sudo seesaw -c failover en cualquiera de las VMs de Seesaw. Esto debería restablecer el tráfico.
    Sistema operativo 1.16, 1.28.0 a 28.200

    Kubelet está lleno de registros que indican que “/etc/kubernetes/manifests” no existe en los nodos trabajadores

    El parámetro "staticPodPath" se configuró de forma incorrecta para los nodos trabajadores

    Solución alternativa:

    Crea manualmente la carpeta “/etc/kubernetes/manifests”
    Si necesitas asistencia adicional, comunícate con Atención al cliente de Cloud.