Problemas conocidos de Google Distributed Cloud (solo software) para VMware

En esta página, se enumeran todos los problemas conocidos de Google Distributed Cloud en VMware. Esta página está destinada a administradores de TI y operadores que administran el ciclo de vida de la infraestructura tecnológica subyacente y responden a alertas y páginas cuando no se cumplen los objetivos de nivel de servicio (SLO) o fallan las aplicaciones. Para obtener más información sobre los roles comunes y las tareas de ejemplo a las que hacemos referencia en el contenido de Google Cloud , consulta Tareas y roles comunes de los usuarios de GKE Enterprise.

Si formas parte del Programa para desarrolladores de Google, guarda esta página para recibir notificaciones cuando se publique una nota de la versión relacionada con esta página. Para obtener más información, consulta Páginas guardadas.

Para filtrar los problemas conocidos por una versión o categoría de producto, selecciona los filtros que desees en los siguientes menús desplegables.

Selecciona tu versión de Google Distributed Cloud:

  • 1.31
  • 1.30
  • 1.29
  • 1.28
  • 1.16
  • 1.15
  • 1.14
  • 1.13
  • 1.12

Selecciona la categoría del problema:

  • Configuración
  • Instalación
  • Actualizaciones
  • Actualizaciones
  • Operación
  • Registro y supervisión
  • Redes
  • Seguridad
  • Almacenamiento
  • Sistema operativo
  • VMware
  • Identidad
  • Migración
  • Otro

También puedes buscar tu problema:

Categoría Versiones identificadas Problema y solución
Redes 1.29.0-1.29.1000 1.30.0-1.30.500, 1.31.0-1.31.100

Los pods de Istiod de la entrada agrupada no pueden estar listos si los recursos de gateway.networking.k8s.io están instalados en el clúster de usuario. El siguiente mensaje de error de ejemplo se puede encontrar en los registros del pod:

    failed to list *v1beta1.Gateway: gateways.gateway.networking.k8s.io is forbidden: User \"system:serviceaccount:gke-system:istiod-service-account\" cannot list resource \"gateways\" in API group \"gateway.networking.k8s.io\" at the cluster scope"

Solución alternativa:

Aplica el siguiente ClusterRole y ClusterRoleBinding a tu clúster de usuarios: 

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: istiod-gateway
rules:
- apiGroups:
  - 'gateway.networking.k8s.io'
  resources:
  - '*'
  verbs:
  - get
  - list
  - watch
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: istiod-gateway-binding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: istiod-gateway
subjects:
- kind: ServiceAccount
  name: istiod-service-account
  namespace: gke-system
Instalación 1.29.0-1.29.1000 1.30.0-1.30.500, 1.31.0-1.31.100

Si los nombres de host en el campo ipblocks contienen letras mayúsculas, es posible que los nodos del plano de control del clúster de administrador se reinicien una y otra vez.

Solución alternativa:

Usa solo nombres de host en minúscula.
Instalación y actualizaciones 1.30.0-1.30.500, 1.31.0-1.31.100

“Error” de Runtime: out of memory después de ejecutar gkeadm create o upgrade

Cuando crees o actualices estaciones de trabajo de administrador con comandos gkeadm, es posible que recibas un error de OOM cuando verifiques la imagen del SO descargada.

Por ejemplo: 

Downloading OS image
"gs://gke-on-prem-release/admin-appliance/1.30.400-gke.133/gke-on-prem-admin-appliance-vsphere-1.30.400-gke.133.ova"...

[==================================================>] 10.7GB/10.7GB

Image saved to
/anthos/gke-on-prem-admin-appliance-vsphere-1.30.400-gke.133.ova

Verifying image gke-on-prem-admin-appliance-vsphere-1.30.400-gke.133.ova...
|

runtime: out of memory

Solución alternativa:

  • Aumenta el tamaño de la memoria del SO en el que ejecutas el comando gkeadm.
    		•
    Actualizaciones 1.30.0-1.30.400

    La actualización del clúster de administrador sin alta disponibilidad se detuvo en Creating or updating cluster control plane workloads

    Cuando se actualiza un clúster de administrador sin HA, es posible que la actualización se detenga en Creating or updating cluster control plane workloads.

    Este problema ocurre si, en la VM principal del administrador, ip a | grep cali muestra un resultado no vacío.

    Por ejemplo: 

    ubuntu@abf8a975479b-qual-342-0afd1d9c ~ $ ip a | grep cali
4: cali2251589245f@if3:  mtu 1500 qdisc noqueue state UP group default

    Solución alternativa:

    1. Repara el administrador principal: 
      gkectl repair admin-master --kubeconfig=ADMIN_KUBECONFIG \
    --config=ADMIN_CONFIG_FILE \
    --skip-validation
    2. Selecciona la plantilla de VM 1.30 si ves una instrucción como la siguiente: 
      Please select the control plane VM template to be used for re-creating the
admin cluster's control plane VM.
    3. Reanuda la actualización: 
      gkectl upgrade admin --kubeconfig ADMIN_KUBECONFIG \
    --config ADMIN_CONFIG_FILE
    Configuración 1.31.0

    Campo isControlPlane redundante en el archivo de configuración del clúster en network.controlPlaneIPBlock

    Los archivos de configuración del clúster que genera gkectl create-config en 1.31.0 contienen un campo isControlPlane redundante en network.controlPlaneIPBlock:

        controlPlaneIPBlock:
    netmask: ""
    gateway: ""
    ips:
    - ip: ""
      hostname: ""
      isControlPlane: false
    - ip: ""
      hostname: ""
      isControlPlane: false
    - ip: ""
      hostname: ""
      isControlPlane: false

    Este campo no es necesario y se puede quitar de forma segura del archivo de configuración.

    Migración 1.29.0-1.29.800, 1.30.0-1.30.400, 1.31.0

    Cuando se migra un clúster de administrador que no es de alta disponibilidad y que usa MetalLB a HA, es posible que los nodos de complementos del administrador se bloqueen en un estado NotReady, lo que impide que se complete la migración.

    Este problema solo afecta a los clústeres de administrador configurados con MetalLB, en los que no está habilitada la reparación automática.

    Este problema se debe a una condición de carrera durante la migración en la que los amplificadores de MetalLB todavía usan el secreto metallb-memberlist anterior. Como resultado de la condición de carrera, la VIP del plano de control anterior se vuelve inaccesible, lo que hace que la migración se detenga.

    Solución alternativa:

    1. Borra el secreto metallb-memberlist existente: 
      kubectl --kubeconfig=ADMIN_KUBECONFIG -n kube-system \
    delete secret metallb-memberlist
    2. Reinicia la implementación de metallb-controller para que pueda generar el nuevo metallb-memberlist: 
      kubectl --kubeconfig=ADMIN_KUBECONFIG -n kube-system \
    rollout restart deployment metallb-controller
    3. Asegúrate de que se genere el nuevo metallb-memberlist: 
      kubectl --kubeconfig=ADMIN_KUBECONFIG -n kube-system \
    get secret metallb-memberlist
    4. Actualiza updateStrategy.rollingUpdate.maxUnavailable en el DaemonSet metallb-speaker de 1 a 100%.

      Este paso es obligatorio, ya que ciertos pods de DaemonSet se ejecutan en los nodos NotReady.

      kubectl --kubeconfig=ADMIN_KUBECONFIG -n kube-system \
    edit daemonset metallb-speaker
    5. Reinicia el DaemonSet metallb-speaker para que pueda detectar la nueva lista de miembros: 
      kubectl --kubeconfig=ADMIN_KUBECONFIG -n kube-system \
    rollout restart daemonset metallb-speaker

      Después de unos minutos, los nodos del complemento del administrador vuelven a ser Ready y la migración puede continuar.

    6. Si el comando gkectl inicial se agotó después de más de 3 horas, vuelve a ejecutar gkectl update para reanudar la migración fallida.
    Configuración y operación 1.12 y versiones posteriores, 1.13 y versiones posteriores, 1.14 y versiones posteriores, 1.15 y versiones posteriores, 1.16 y versiones posteriores, 1.28 y versiones posteriores, 1.29 y versiones posteriores, 1.30 y versiones posteriores

    La copia de seguridad del clúster para el clúster de administrador que no es de alta disponibilidad falla debido a nombres largos de almacén de datos y disco de datos.

    Cuando se intenta crear una copia de seguridad de un clúster de administrador que no tiene HA, la copia de seguridad falla debido a que la longitud combinada de los nombres de los datos y el almacenamiento supera la longitud máxima de caracteres.

    La longitud máxima de caracteres para un nombre de almacén de datos es de 80.
    La ruta de copia de seguridad de un clúster de administrador que no es de alta disponibilidad tiene la sintaxis de nombres "__". Por lo tanto, si el nombre concatenado supera la longitud máxima, no se podrá crear la carpeta de copia de seguridad.

    Solución alternativa:

    Cambia el nombre del almacén de datos o del disco de datos a uno más corto.
    Asegúrate de que la longitud combinada de los nombres del almacén de datos y del disco de datos no supere la longitud máxima de caracteres.
    Actualizaciones 1.28, 1.29 y 1.30

    Después de ejecutar el comando gkectl repair admin-master, es posible que un nodo del plano de control del administrador muestre una versión anterior a la esperada.

    Este problema se produce porque la plantilla de VM con copia de seguridad que se usa para la reparación del nodo del plano de control del administrador de HA no se actualiza en vCenter después de una actualización, ya que la plantilla de VM de copia de seguridad no se clonó durante la creación de la máquina si el nombre de la máquina no cambia.

    Solución alternativa:

    1. Obtén el nombre de la máquina que usa la versión anterior de Kubernetes: 
          kubectl get machine -o wide --kubeconfig=ADMIN_KUBECONFIG
    2. Quita la anotación onprem.cluster.gke.io/prevented-deletion: 
          kubectl edit machine MACHINE_NAME --kubeconfig=ADMIN_KUBECONFIG

      Guarda la edición.

    3. Ejecuta el siguiente comando para borrar la máquina: 
          kubectl delete machine MACHINE_NAME --kubeconfig=ADMIN_KUBECONFIG

      Se creará una máquina nueva con la versión correcta.
    Configuración 1.30.0

    Cuando se actualiza un clúster de usuarios o un grupo de nodos con Terraform, es posible que Terraform intente establecer los campos vCenter en valores vacíos.

    Este problema puede ocurrir si el clúster no se creó originalmente con Terraform.

    Solución alternativa:

    Para evitar la actualización inesperada, asegúrate de que sea segura antes de ejecutar terraform apply, como se describe a continuación:

    1. Ejecuta terraform plan
    2. En el resultado, verifica si los campos vCenter están configurados como nil.
    3. Si algún campo vCenter se establece en un valor vacío, en la configuración de Terraform, agrega vcenter a la lista ignore_changes siguiendo la documentación de Terraform. Esto evita que se actualicen estos campos.
    4. Vuelve a ejecutar terraform plan y verifica el resultado para confirmar que la actualización sea como se espera.
    Actualizaciones 1.13, 1.14, 1.15 y 1.16

    Después de que se creen, actualicen o se actualicen los nodos del plano de control de los clústeres de usuario de kubeception, se reiniciarán uno por uno durante la primera operación del clúster de administrador cuando se cree o se actualice a una de las versiones afectadas. En el caso de los clústeres de kubeception con 3 nodos del plano de control, esto no debería generar un tiempo de inactividad del plano de control, y el único impacto es que la operación del clúster de administrador demora más.

    Instalación, actualizaciones y revisiones 1.31

    En la versión 1.31 de Google Distributed Cloud, es posible que obtengas errores cuando intentes crear recursos personalizados, como clústeres (todos los tipos) y cargas de trabajo. El problema se debe a un cambio drástico que se introdujo en Kubernetes 1.31 que impide que el campo caBundle en una definición de recursos personalizados pase de un estado válido a uno no válido. Para obtener más información sobre el cambio, consulta el registro de cambios de Kubernetes 1.31.

    Antes de Kubernetes 1.31, el campo caBundle a menudo se establecía en un valor provisional de \n, ya que, en versiones anteriores de Kubernetes, el servidor de la API no permitía contenido de paquete de AC vacío. Usar \n era una solución alternativa razonable para evitar confusiones, ya que cert-manager suele actualizar caBundle más adelante.

    Si el caBundle se corrigió una vez de un estado no válido a uno válido, no debería haber problemas. Sin embargo, si la definición del recurso personalizado se reconcilia con \n (o con otro valor no válido), es posible que se muestre el siguiente error:

    ...Invalid value: []byte{0x5c, 0x6e}: unable to load root certificates: unable to parse bytes as PEM block]

    Solución alternativa

    Si tienes una definición de recursos personalizados en la que caBundle está configurado en un valor no válido, puedes quitar el campo caBundle por completo de forma segura. Esto debería resolver el problema.
    SO 1.31

    Cuando se actualiza un clúster que usa la imagen del SO de Container Optimized OS (COS) a la versión 1.31, el comando cloud-init status falla, aunque cloud-init finalizó sin errores.

    Solución alternativa:

    Ejecuta el siguiente comando para verificar el estado de cloud-init:

        systemctl show -p Result cloud-final.service

    Si el resultado es similar al siguiente, significa que cloud-init finalizó correctamente:

        Result=success
    Actualizaciones 1.28

    Cuando se actualiza un clúster a la versión 1.28, el comando gkectl prepare falla cuando se ejecutan las verificaciones previas al vuelo de la estación de trabajo de administrador si el tamaño del disco de la estación de trabajo de administrador es inferior a 100 GB. En este caso, el comando muestra un mensaje de error similar al siguiente:

        Workstation Hardware: Workstation hardware requirements are not satisfied

    En la versión 1.28, el requisito previo de tamaño de disco de la estación de trabajo del administrador aumentó de 50 GB a 100 GB.

    Solución alternativa:

    1. Revierte la estación de trabajo de administrador.
    2. Actualiza el archivo de configuración de la estación de trabajo de administrador para aumentar el tamaño del disco a, al menos, 100 GB.
    3. Actualiza la estación de trabajo del administrador.
    Actualizaciones 1.30

    El comando gkectl upgrade muestra un error incorrecto sobre el almacenamiento de NetApp. El mensaje de error es similar al siguiente: 

        detected unsupported drivers:
      csi.trident.netapp.io

    Solución alternativa:

    Ejecuta gkectl upgrade con la marca `--skip-pre-upgrade-checks`.
    Actualizaciones 1.28+

    Cuando inhabilitas el ingreso agrupado quitando el campo loadBalancer.vips.ingressVIP del archivo de configuración del clúster, un error en la verificación previa al vuelo de MetalLB hace que la actualización del clúster falle con el mensaje de error "invalid user ingress vip: invalid IP".

    Solución alternativa:

    Debes ignorar este mensaje de error.
    Omite la verificación previa al vuelo con uno de los siguientes métodos:

    • Agrega la marca --skip-validation-load-balancer al comando gkectl update cluster.
    • Anota el objeto onpremusercluster con onprem.cluster.gke.io/server-side-preflight-skip: skip-validation-load-balancer.
      • .
    VMware, actualizaciones 1.16

    Durante una actualización de clúster, es posible que los objetos de máquina se bloqueen en la fase "Creando" y no se vinculen a los objetos de nodo debido a que falta una regla de grupo antiafinidad (AAG) en vCenter.

    Si describes los objetos de máquinas problemáticos, puedes ver mensajes recurrentes, como “Se completó la tarea de reconfiguración de la regla de DRS “task-xxxx”.

        kubectl --kubeconfig KUBECONFIG describe machine MACHINE_OBJECT_NAME

    Solución alternativa:

    Inhabilita el parámetro de configuración del grupo de antiafinidad en la configuración del clúster de administrador y en la configuración del clúster de usuario, y activa el comando de actualización forzosa para desbloquear la actualización del clúster:

        gkectl update admin --config ADMIN_CLUSTER_CONFIG_FILE --kubeconfig ADMIN_CLUSTER_KUBECONFIG --force
    
        gkectl update cluster --config USER_CLUSTER_CONFIG_FILE --kubeconfig USER_CLUSTER_KUBECONFIG --force
    Migración 1.29 y 1.30

    Cuando se migra un clúster de usuarios a Controlplane V2, si se habilitó la encriptación de secretos siempre activa, el proceso de migración no controla correctamente la clave de encriptación de secretos. Debido a este problema, el nuevo clúster de ControlPlane V2 no puede desencriptar los secretos. Si el resultado del siguiente comando no está vacío, significa que la encriptación de Secrets siempre activa se habilitó en algún momento y que el clúster se ve afectado por este problema:

        kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
      get onpremusercluster USER_CLUSTER_NAME \
      -n USER_CLUSTER_NAME-gke-onprem-mgmt \
      -o jsonpath={.spec.secretsEncryption}

    Si ya iniciaste la migración y esta falla, comunícate con Google para obtener asistencia. De lo contrario, antes de la migración, inhabilita la encriptación de secretos siempre activa y desencripta los secretos.

    Migración 1.29.0-1.29.600, 1.30.0-1.30.100

    Si el clúster de administrador habilitó la encriptación de secretos siempre activa en la versión 1.14 o anterior, y actualizó desde las versiones anteriores a las versiones afectadas 1.29 y 1.30, cuando se migra el clúster de administrador de no HA a HA, el proceso de migración no controla correctamente la clave de encriptación de secretos. Debido a este problema, el nuevo clúster de administrador de HA no puede desencriptar secretos.

    Para verificar si el clúster podría estar usando la clave con formato anterior, haz lo siguiente:

        kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get secret -n kube-system admin-master-component-options -o jsonpath='{.data.data}' | base64 -d | grep -oP '"GeneratedKeys":\[.*?\]'

    Si el resultado muestra la clave vacía como la siguiente, significa que el clúster se verá afectado por este problema:

        "GeneratedKeys":[{"KeyVersion":"1","Key":""}]

    Si ya iniciaste la migración y esta falla, comunícate con Google para obtener asistencia.

    De lo contrario, antes de iniciar la migración, rota la clave de encriptación.
    Actualizaciones 1.16, 1.28, 1.29 y 1.30

    Cuando se actualiza la estación de trabajo de administrador con el comando gkeadm upgrade admin-workstation, el archivo credential.yaml se vuelve a generar de forma incorrecta. Los campos de nombre de usuario y contraseña están vacíos. Además, la clave privateRegistry contiene un error tipográfico.

    La misma falta de ortografía de la clave privateRegistry también está en el archivo admin-cluster.yaml.
    Dado que el archivo credential.yaml se vuelve a generar durante el proceso de actualización del clúster de administrador, el error tipográfico está presente incluso si lo corregiste anteriormente.

    Solución alternativa:

    • Actualiza el nombre de la clave de registro privada en credential.yaml para que coincida con el privateRegistry.credentials.fileRef.entry en admin-cluster.yaml.
    • Actualiza el nombre de usuario y la contraseña del registro privado en credential.yaml.
    Actualizaciones 1.16+

    Cuando se actualiza un clúster de usuario, la operación de conciliación previa a la actualización puede tardar más que el tiempo de espera definido, lo que genera un error de actualización. El mensaje de error es similar al siguiente:

    Failed to reconcile the user cluster before upgrade: the pre-upgrade reconcile failed, error message:
failed to wait for reconcile to complete: error: timed out waiting for the condition,
message: Cluster reconcile hasn't finished yet, please fix that before
rerun the upgrade.

    El tiempo de espera para la operación de conciliación previa a la actualización es de 5 minutos más 1 minuto por grupo de nodos en el clúster de usuario.

    Solución alternativa:

    Asegúrate de que el comando gkectl diagnose cluster se apruebe sin errores.
    Para omitir la operación de conciliación previa a la actualización, agrega la marca --skip-reconcile-before-preflight al comando gkectl upgrade cluster. Por ejemplo:

    gkectl upgrade cluster --skip-reconcile-before-preflight --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
--config USER_CLUSTER_CONFIG_FILE
    Actualizaciones 1.16, 1.28.0-1.28.800, 1.29.0-1.29.400, 1.30.0

    Cuando actualizas el campo dataplaneV2.forwardMode del clúster de usuarios con gkectl update cluster, el cambio solo se actualiza en el ConfigMap. El DaemonSet anetd no detectará el cambio de configuración hasta que se reinicie y no se aplicarán tus cambios.

    Solución alternativa:

    Cuando se complete el comando gkectl update cluster, verás el resultado de Done updating the user cluster. Después de ver ese mensaje, ejecuta el siguiente comando para reiniciar el DaemonSet de anetd y detectar el cambio de configuración:

    kubectl --kubeconfig USER_CLUSTER_KUBECONFIG rollout restart daemonset anetd

    Verifica la preparación del DaemonSet después del reinicio:

    kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get daemonset anetd

    En el resultado del comando anterior, verifica que el número de la columna DESIRED coincida con el número de la columna READY.
    Actualizaciones 1.16

    Durante una actualización de un clúster de usuario de la versión 1.16 a la 1.28, se crea una copia de seguridad del clúster de administrador. El proceso de copia de seguridad del clúster de administrador muestra el mensaje de error “etcdctl: command not found”. La actualización del clúster de usuario se realiza correctamente y el clúster de administrador permanece en buen estado. El único problema es que no se crea una copia de seguridad del archivo de metadatos del clúster de administrador.

    La causa del problema es que el objeto binario etcdctl se agregó en la versión 1.28 y no está disponible en los nodos 1.16.

    La copia de seguridad del clúster de administrador implica varios pasos, como tomar una instantánea de etcd y, luego, escribir el archivo de metadatos del clúster de administrador. La copia de seguridad de etcd aún se realiza correctamente porque etcdctl aún se puede activar después de una ejecución en el Pod de etcd. Sin embargo, la escritura del archivo de metadatos falla, ya que aún depende de que el objeto binario etcdctl se instale en el nodo. Sin embargo, la copia de seguridad del archivo de metadatos no es un bloqueador para crear una copia de seguridad, por lo que el proceso de copia de seguridad se realiza correctamente, al igual que la actualización del clúster de usuarios.

    Solución alternativa:

    Si deseas crear una copia de seguridad del archivo de metadatos, sigue las instrucciones de Crea una copia de seguridad de un clúster de administrador y restablécelo con gkectl para activar una copia de seguridad independiente del clúster de administrador con la versión de gkectl que coincida con la versión de tu clúster de administrador.
    Instalación 1.16-1.29

    Cuando se crea un clúster de usuario configurado para el balanceo de cargas manual, se produce una falla de gkectl check-config que indica que el valor de ingressHTTPNodePort debe ser de al menos 30,000, incluso cuando se inhabilita el Ingress agrupado.

    Este problema se produce independientemente de si los campos ingressHTTPNodePort y ingressHTTPSNodePort están configurados o se dejan en blanco.

    Solución alternativa:

    Para solucionar este problema, ignora el resultado que muestra gkectl check-config. Para inhabilitar el Ingress agrupado, consulta Inhabilita el Ingress agrupado.
    Actualizaciones 1.29.0

    El problema con PodDisruptionBudget (PDB) ocurre cuando se usan clústeres de administrador de alta disponibilidad (HA) y hay 0 o 1 nodos de clúster de administrador sin un rol después de la migración. Para verificar si hay objetos de nodos sin un rol, ejecuta el siguiente comando:

    kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get nodes -o wide

    Si hay dos o más objetos de nodo sin un rol después de la migración, el PDB no está mal configurado.

    Síntomas:

    El resultado de admin cluster diagnose incluye la siguiente información:

    Checking all poddisruptionbudgets...FAILURE
  Reason: 1 pod disruption budget error(s).
  Unhealthy Resources:
  PodDisruptionBudget metrics-server: gke-managed-metrics-server/metrics-server might be configured incorrectly: the total replicas(1) should be larger than spec.MinAvailable(1).

    Solución alternativa:

    Ejecuta el siguiente comando para borrar el PDB:

    kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG delete pdb metrics-server -n gke-managed-metrics-server
    Instalación, actualizaciones y revisiones 1.28.0-1.28.600,1.29.0-1.29.100

    En condiciones de carrera excepcionales, una secuencia de instalación incorrecta del webhook de la autorización binaria y el pod gke-connect puede provocar que la creación del clúster de usuarios se detenga debido a que un nodo no alcanza un estado listo. En los casos afectados, la creación de clústeres de usuarios puede detenerse debido a que un nodo no alcanza un estado listo. Si esto ocurre, se mostrará el siguiente mensaje:

         Node pool is not ready: ready condition is not true: CreateOrUpdateNodePool: 2/3 replicas are ready

    Solución alternativa:

    1. Quita la configuración de la autorización binaria de tu archivo de configuración. Para obtener instrucciones de configuración, consulta la guía de instalación del día 2 de la Autorización binaria para GKE en VMware.
    2. Para desbloquear un nodo no en buen estado durante el proceso de creación de clúster actual, quita temporalmente la configuración del webhook de Autorización binaria en el clúster de usuario con el siguiente comando. 
              kubectl --kubeconfig USER_KUBECONFIG delete ValidatingWebhookConfiguration binauthz-validating-webhook-configuration
      Una vez que se complete el proceso de inicio, puedes volver a agregar la siguiente configuración de webhook. 
      apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
metadata:
  name: binauthz-validating-webhook-configuration
webhooks:
- name: "binaryauthorization.googleapis.com"
  namespaceSelector:
    matchExpressions:
    - key: control-plane
      operator: DoesNotExist
  objectSelector:
    matchExpressions:
    - key: "image-policy.k8s.io/break-glass"
      operator: NotIn
      values: ["true"]
  rules:
  - apiGroups:
    - ""
    apiVersions:
    - v1
    operations:
    - CREATE
    - UPDATE
    resources:
    - pods
    - pods/ephemeralcontainers
  admissionReviewVersions:
  - "v1beta1"
  clientConfig:
    service:
      name: binauthz
      namespace: binauthz-system
      path: /binauthz
    # CA Bundle will be updated by the cert rotator.
    caBundle: Cg==
  timeoutSeconds: 10
  # Fail Open
  failurePolicy: "Ignore"
  sideEffects: None
    Actualizaciones 1.16, 1.28 y 1.29

    Durante una actualización del clúster de usuario, es posible que la operación de actualización se bloquee si el objeto de máquina reflejado en el clúster de usuario contiene un deletionTimestamp. Se muestra el siguiente mensaje de error si la actualización está bloqueada:

        machine is still in the process of being drained and subsequently removed

    Este problema puede ocurrir si anteriormente intentaste reparar el nodo del plano de control del usuario ejecutando gkectl delete machine en la máquina reflejada en el clúster de usuarios.

    Solución alternativa:

    1. Obtén el objeto de máquina reflejado y guárdalo en un archivo local para crear una copia de seguridad.
    2. Ejecuta el siguiente comando para borrar el finalizador de la máquina reflejada y espera a que se borre del clúster de usuarios. 
          kubectl --kubeconfig ADMIN_KUBECONFIG patch machine/MACHINE_OBJECT_NAME -n USER_CLUSTER_NAME-gke-onprem-mgmt -p '{"metadata":{"finalizers":[]}}' --type=merge
    3. Sigue los pasos que se indican en Nodo del plano de control del clúster de usuarios de Controlplane V2 para activar la reparación de nodos en los nodos del plano de control, de modo que se vuelva a sincronizar la especificación correcta de la máquina de origen en el clúster de usuarios.
    4. Vuelve a ejecutar gkectl upgrade cluster para reanudar la actualización.
    Configuración e instalación 1.15, 1.16, 1.28 y 1.29

    En el caso del clúster de administrador de alta disponibilidad o del clúster de usuario de ControlPlane V2, la VIP del plano de control debe estar en la misma subred que los otros nodos del clúster. De lo contrario, la creación del clúster falla porque kubelet no puede comunicarse con el servidor de la API con la VIP del plano de control.

    Solución alternativa:

    Antes de crear el clúster, asegúrate de que la VIP del plano de control esté configurada en la misma subred que los otros nodos del clúster.
    Instalación, actualizaciones 1.29.0 - 1.29.100

    La creación o actualización del clúster falla con un error en los pods de CSI de vSphere que indica que el nombre de usuario de vCenter no es válido. Esto ocurre porque el nombre de usuario que se usó no es un nombre de dominio completamente calificado. Mensaje de error en el pod vsphere-csi-controller como el siguiente:

        GetCnsconfig failed with err: username is invalid, make sure it is a fully qualified domain username

    Este problema solo ocurre en la versión 1.29 y versiones posteriores, ya que se agregó una validación al controlador de CSI de vSphere para aplicar el uso de nombres de usuario de dominio completamente calificados.

    Solución alternativa:

    Usa un nombre de dominio completamente calificado para el nombre de usuario de vCenter en el archivo de configuración de credenciales. Por ejemplo, en lugar de usar "nombredeusuario1", usa "nombredeusuario1@example.com".
    Actualizaciones 1.28.0 - 1.28.500

    Cuando se actualiza un clúster de administrador de la versión 1.16 a la 1.28, es posible que el inicio de la nueva máquina maestra de administrador no genere el certificado del plano de control. El problema se debe a cambios en la forma en que se generan los certificados para el servidor de la API de Kubernetes en la versión 1.28 y versiones posteriores. El problema se reproduce en los clústeres creados en las versiones 1.10 y anteriores que se actualizaron a la versión 1.16 y el certificado de entidad final no se rotó antes de la actualización.

    Para determinar si el error de actualización del clúster de administrador se debe a este problema, sigue estos pasos:

    1. Conéctate a la máquina principal de administrador con SSH.
    2. Abre /var/log/startup.log y busca un error como el siguiente:
    Error adding extensions from section apiserver_ext
801B3213B57F0000:error:1100007B:X509 V3 routines:v2i_AUTHORITY_KEYID:unable to get issuer keyid:../crypto/x509/v3_akid.c:177:
801B3213B57F0000:error:11000080:X509 V3 routines:X509V3_EXT_nconf_int:error in extension:../crypto/x509/v3_conf.c:48:section=apiserver_ext, name=authorityKeyIdentifier, value=keyid>

    Solución alternativa:

    1. Conéctate a la máquina principal del administrador con SSH. Para obtener más información, consulta Usa SSH para conectarte a un nodo del clúster de administración.
    2. Crea una copia /etc/startup/pki-yaml.sh y asígnale el nombre /etc/startup/pki-yaml-copy.sh.
    3. Editar /etc/startup/pki-yaml-copy.sh. Busca authorityKeyIdentifier=keyidset y cámbialo a authorityKeyIdentifier=keyid,issuer en las secciones de las siguientes extensiones: apiserver_ext, client_ext, etcd_server_ext y kubelet_server_ext. Por ejemplo: 
            [ apiserver_ext ]
      keyUsage = critical, digitalSignature, keyEncipherment
      extendedKeyUsage=serverAuth
      basicConstraints = critical,CA:false
      authorityKeyIdentifier = keyid,issuer
      subjectAltName = @apiserver_alt_names
    4. Guarda los cambios en /etc/startup/pki-yaml-copy.sh.
    5. Con un editor de texto, abre /opt/bin/master.sh, busca y reemplaza todas las instancias de /etc/startup/pki-yaml.sh por /etc/startup/pki-yaml-copy.sh y, luego, guarda los cambios.
    6. Ejecuta /opt/bin/master.sh para generar el certificado y completar el inicio de la máquina.
    7. Vuelve a ejecutar gkectl upgrade admin para actualizar el clúster de administrador.
    8. Después de que se complete la actualización, rota el certificado final para los clústeres de administrador y de usuario, como se describe en Inicia la rotación.
    9. Una vez que se complete la rotación de certificados, realiza las mismas modificaciones en /etc/startup/pki-yaml-copy.sh que hiciste anteriormente y ejecuta /opt/bin/master.sh.
    Configuración 1.29.0

    Cuando ejecutas gkectl para crear, actualizar o actualizar un clúster que ya tiene habilitado Dataplane V2, se muestra el siguiente mensaje de advertencia incorrecto:

    WARNING: Your user cluster is currently running our original architecture with
[DataPlaneV1(calico)]. To enable new and advanced features we strongly recommend
to update it to the newer architecture with [DataPlaneV2] once our migration
tool is available.

    Hay un error en gkectl que hace que siempre muestre esta advertencia, siempre que no se use dataplaneV2.forwardMode, incluso si ya configuraste enableDataplaneV2: true en el archivo de configuración del clúster.

    Solución alternativa:

    Puedes ignorar esta advertencia.
    Configuración 1.28.0-1.28.400, 1.29.0

    Cuando creas un clúster de administrador de alta disponibilidad, la verificación previa muestra el siguiente mensaje de error incorrecto:

    - Validation Category: Network Configuration
    - [FAILURE] CIDR, VIP and static IP (availability and overlapping): needed
    at least X+1 IP addresses for admin cluster with X nodes

    El requisito es incorrecto para los clústeres de administrador de HA 1.28 y versiones posteriores, ya que ya no tienen nodos de complementos. Además, como las 3 IPs de los nodos del plano de control del clúster de administrador se especifican en la sección network.controlPlaneIPBlock del archivo de configuración del clúster de administrador, las IPs del archivo de bloque de IP solo son necesarias para los nodos del plano de control del clúster de usuario de kubeception.

    Solución alternativa:

    Para omitir la verificación previa incorrecta en una versión no corregida, agrega --skip-validation-net-config al comando gkectl.
    Operación 1.29.0-1.29.100

    Si migraste de un clúster de administrador sin HA a un clúster de administrador con HA, el agente de Connect en el clúster de administrador pierde la conexión con gkeconnect.googleapis.com con el error "No se pudo verificar la firma de JWT". Esto se debe a que, durante la migración, se cambia la clave de firma de KSA, por lo que se necesita un nuevo registro para actualizar los JWK de OIDC.

    Solución alternativa:

    Para volver a conectar el clúster de administrador a Google Cloud, sigue estos pasos para activar un nuevo registro:

    Primero, obtén el nombre de la implementación de gke-connect:

    kubectl --kubeconfig KUBECONFIG get deployment -n gke-connect

    Borra la implementación gke-connect:

    kubectl --kubeconfig KUBECONFIG delete deployment GKE_CONNECT_DEPLOYMENT -n gke-connect

    Activa una conciliación forzada para el onprem-admin-cluster-controller. Para ello, agrega una anotación "force-reconcile" a tu CR de onpremadmincluster:

    kubectl --kubeconfig KUBECONFIG patch onpremadmincluster ADMIN_CLUSTER_NAME -n kube-system --type merge -p '
metadata:
  annotations:
    onprem.cluster.gke.io/force-reconcile: "true"
'

    La idea es que onprem-admin-cluster-controller siempre vuelva a implementar la implementación de gke-connect y vuelva a registrar el clúster si no encuentra una implementación de gke-connect existente disponible.

    Después de la solución alternativa (es posible que el controlador tarde unos minutos en completar la conciliación), puedes verificar que el error 400 "No se pudo verificar la firma del JWT" ya no aparezca en los registros de gke-connect-agent:

    kubectl --kubeconfig KUBECONFIG logs GKE_CONNECT_POD_NAME -n gke-connect
    Instalación, sistema operativo 1.28.0-1.28.500, 1.29.0

    Google Distributed Cloud especifica una subred dedicada, --bip=169.254.123.1/24, para la IP del puente de Docker en la configuración de Docker para evitar reservar la subred 172.17.0.1/16 predeterminada. Sin embargo, en las versiones 1.28.0-1.28.500 y 1.29.0, el servicio de Docker no se reiniciaba después de que Google Distributed Cloud personalizaba la configuración de Docker debido a una regresión en la imagen del SO COS. Como resultado, Docker elige el 172.17.0.1/16 predeterminado como su subred de dirección IP de puente. Esto podría causar un conflicto de dirección 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 reiniciar el servicio de Docker:

    sudo systemctl restart docker

    Verifica que Docker elija la dirección IP del puente correcta:

    ip a | grep docker0

    Esta solución no persiste en las recreaciones de VM. Debes volver a aplicar esta solución alternativa cada vez que se vuelvan a crear VMs.
    update 1.28.0-1.28.400, 1.29.0-1.29.100

    Los objetos binarios CNI estándar bridge, ipvlan, vlan, macvlan, dhcp, tuning, host-local, ptp, portmap no se incluyen en las imágenes del SO de las versiones afectadas. El plano de datos v2 no usa estos objetos binarios de CNI, pero se pueden usar para interfaces de red adicionales en la función de varias interfaces de red.

    La interfaz de red múltiple con estos complementos de CNI no funcionará.

    Solución alternativa:

    Actualiza a la versión con la corrección si usas esta función.
    update 1.15, 1.16 y 1.28

    La instalación de multipathd en los nodos del clúster interfiere con 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 y 1.16

    Si algunas configuraciones obligatorias están vacías en el clúster de administrador porque se omitieron las validaciones, es posible que el webhook del clúster de administrador bloquee su adición. Por ejemplo, si el campo gkeConnect no se configuró en un clúster de administrador existente, agregarlo con el comando gkectl update admin podría generar 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 de 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 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

    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, Google Distributed Cloud 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 de HA:

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

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

    Si el registro contiene una entrada como la siguiente después de actualizar a la versión 1.28, significa que te afecta este problema: 
    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.

    A continuación, 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

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

    Solución alternativa:

    Agrega el campo "vCenter.storagePolicyName" en el 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 instrucciones.
    Registro y supervisión 1.28.0-1.28.100

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

    Solución alternativa:

    Ejecuta el comando para establecer en el espacio de nombres "kube-system" el CR "stackdriver" en el campo "featureGates.disableExperimentalMetadataAgent" en "true"

    "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"}]}]}}}}'`

    Actualizaciones 1.15.0-1.15.7, 1.16.0-1.16.4, 1.28.0

    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 clusterapi-controller no se conecte a vCenter después del reinicio. Consulta el registro de 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, significa que 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 usuarios con Controlplane V2 habilitado usen las mismas credenciales de vSphere.

    Registro y supervisión 1.14

    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. Compara la métrica grpc_server_handled_total sin procesar con la grpc_method que se proporciona en el mensaje de alerta. En este ejemplo, verifica la etiqueta grpc_code para Watch.

      Puedes verificar esta métrica con 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. Se puede ignorar de forma segura una alerta en todos los códigos que no sean OK si el código no es uno de los siguientes: 
      Unknown|FailedPrecondition|ResourceExhausted|Internal|Unavailable|DataLoss|DeadlineExceeded

    Solución alternativa:

    Para configurar Prometheus de modo que ignore estas alertas falsas positivas, revisa las siguientes opciones:

    1. Silencia la alerta desde la IU del Administrador de alertas.
    2. Si no puedes silenciar la alerta, revisa los siguientes pasos para suprimir los falsos positivos:
      1. Reduce el operador de supervisión a 0 réplicas para que las modificaciones puedan persistir.
      2. Modifica el configmap 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 el Statefulset de Prometheus y Alertmanager para recoger la configuración nueva.
    3. Si el código se encuentra en uno de los casos problemáticos, verifica el registro de etcd y el registro de kube-apiserver para depurar más.
    Redes 1.16.0-1.16.2, 1.28.0

    Es posible que las conexiones de NAT de salida se descarten después de 5 a 10 minutos de establecida una conexión si no hay tráfico.

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

    Este problema se produce porque la recolección de basura de anetd quita, de forma inadvertida, entradas de conntrack que el daemon considera que no se usan. Recientemente, se integró una corrección upstream en anetd para corregir el comportamiento.


    Solución alternativa:

    No hay una solución alternativa fácil, y no hemos visto problemas en la versión 1.16 debido a este comportamiento. Si observas que se desconectan las conexiones de larga duración debido a este problema, las soluciones 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 y 1.16

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

    Solución alternativa:

    Si este problema te afecta, puedes actualizar tu clúster de usuarios. Para ello, agrega disableNodeIDVerificationCSRSigning: true al archivo de configuración del clúster de usuarios y ejecuta el comando gkectl update cluster para actualizar el clúster con esta configuración.
    Herramientas de redes, actualizaciones 1.16.0-1.16.3

    Si intentas inhabilitar el Ingress agrupado para un clúster existente, el comando gkectl update cluster falla con un error similar al siguiente ejemplo:

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

    Este error se produce porque gkectl busca una dirección IP de entrada del balanceador de cargas durante las verificaciones previas al vuelo. Aunque esta verificación no es obligatoria cuando se inhabilita la entrada agrupada, la verificación previa de 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 el acceso integrado para un clúster existente.
    Actualizaciones 1.13, 1.14, 1.15.0-1.15.6

    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 este problema te afecta, puedes actualizar tu clúster de administrador con la marca --disable-update-from-checkpoint y 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 de punto de control se actualiza para usarlo en el futuro.
    Almacenamiento 1.15.0-1.15.6, 1.16.0-1.16.2

    Durante las verificaciones previas al vuelo, la verificación de validación de cargas de trabajo de CSI instala un Pod en el espacio de nombres default. El pod de cargas de trabajo de CSI valida que el controlador de CSI de vSphere esté instalado y pueda realizar el aprovisionamiento dinámico de volúmenes. Si este pod no se inicia, fallará la verificación de validación de la carga de trabajo de CSI.

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

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

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

    - [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 la falla se debe a la falta de recursos de 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 se configuran correctamente para el pod de carga de trabajo de CSI, el estado del trabajo contiene 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 inserción de sidecar de Istio, puedes inhabilitar temporalmente la inserción automática de sidecar 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 manualmente que el aprovisionamiento dinámico de volúmenes con el controlador de CSI de vSphere funcione:

    1. Crea una PVC que use la StorageClass standard-rwo.
    2. Crea un pod que use la PVC.
    3. Verifica que el pod pueda leer o escribir datos en el volumen.
    4. Quita el Pod y el PVC después de verificar que funcionen correctamente.

    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

    Cuando accedes a una estación de trabajo de administrador administrada por el usuario, es posible que el comando gkectl update cluster se agote y no actualice 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 esta falla, verás el siguiente error cuando intentes 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, se quita del clúster el validation-controller que activa las comprobaciones preliminares. Si luego intentas actualizar el clúster de usuario, la verificación previa se bloquea 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. Una vez que se complete la preparación, vuelve a ejecutar gkectl update cluster para actualizar el clúster de usuarios.
    Operación 1.16.0-1.16.2

    Cuando accedes a una estación de trabajo de administrador administrada por el usuario, es posible que el comando gkectl create cluster se agote y no se cree el clúster de usuario. Esto sucede si la versión del clúster de administrador es 1.15. Cuando se produce esta falla, verás el siguiente error cuando intentes 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

    Como se agregó validation-controller en la versión 1.16, cuando se usa el clúster de administrador 1.15, falta el validation-controller que es responsable de activar las verificaciones previas. Por lo tanto, cuando se intenta crear un clúster de usuarios, las verificaciones previas se bloquean 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. Una vez que se complete la preparación, vuelve a ejecutar gkectl create cluster para crear el clúster de usuario.
    Actualizaciones 1.16.0-1.16.2

    Cuando actualizas un clúster de administrador de la versión 1.15.x a la 1.16.x, o cuando agregas una configuración de connect, stackdriver, cloudAuditLogging o gkeOnPremAPI cuando actualizas un clúster de administrador, el webhook del clúster de administrador podría rechazar 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 reconcilie 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 del 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 operaciones para una actualización. Algunas validaciones de solo creación se invocan cuando se actualizan y actualizan 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 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 que no tienen alta disponibilidad y tienen un archivo de punto de control: Agrega el parámetro disable-update-from-checkpoint en el comando de actualización o el parámetro "disable-upgrade-from-checkpoint" en el comando de actualización. Estos parámetros solo son necesarios 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
      • En el caso de los clústeres de administrador de alta disponibilidad o si el archivo de punto de control está inhabilitado: Actualiza o mejora el clúster de administrador como de costumbre. No se necesitan parámetros adicionales en los comandos de actualización o actualización.
    Operación 1.16.0-1.16.2

    Cuando accedes a una estación de trabajo de administrador administrada por el usuario, es posible que el comando gkectl delete cluster se agote y no borre 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 mejorar el clúster de usuario. Cuando se produce esta falla, verás el siguiente error cuando intentes 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 mejora) se bloquea en la fase de eliminación. Esto sucede porque un finalizador bloquea la eliminación del objeto, lo que hace que falle la eliminación del clúster.

    Solución alternativa:

    1. Obtén los nombres de todos los objetos de validación: 
               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 validación, se quitan los objetos y se completa automáticamente la operación de eliminación del clúster de usuarios. No es necesario que realices ninguna acción adicional.

    Redes 1.15 y 1.16

    Si el Pod de origen y el Pod de puerta de enlace de NAT de salida están en dos nodos de trabajo 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 al servicio o la aplicación externos se realiza correctamente.

    Este problema se debe a que vSphere descarta paquetes VXLAN cuando se habilita la agregación de túneles. Existe un problema conocido con NSX y VMware que solo envía tráfico agregado en 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 reconfigurarlo después de cada actualización. VMware debe resolver el problema en vSphere para obtener una solución permanente.
    Actualizaciones 1.15.0-1.15.4

    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 principal del 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 maestra de administrador, accede a ella a través de SSH y reemplaza la clave nueva del disco de datos por la anterior de la copia de seguridad. La clave se encuentra en /opt/data/gke-k8s-kms-plugin/generatedkeys en el administrador principal.
    3. Actualiza el manifiesto de Pod estático kms-plugin.yaml en /etc/kubernetes/manifests para actualizar el --kek-id para que coincida con el campo kid en la clave de encriptación original.
    4. Para reiniciar el Pod estático kms-plugin, mueve el /etc/kubernetes/manifests/kms-plugin.yaml a otro directorio y, luego, vuelve a moverlo.
    5. Para reanudar la actualización del administrador, vuelve a ejecutar gkectl upgrade admin.

    Cómo evitar que se produzca un error de actualización

    Si aún no lo hiciste, te recomendamos que no actualices a las versiones 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 secretos siempre activa.
    Almacenamiento 1.11-1.16

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


    Solución alternativa:

    No crees copias de seguridad de las VMs de Google Distributed Cloud, ya que el software de copia de seguridad de terceros podría habilitar la CBT en sus discos. No es necesario crear una copia de seguridad de estas VMs.

    No habilites CBT en el nodo, ya que este cambio no persistirá en las actualizaciones.

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

    Si usas arrays de almacenamiento de Nutanix para proporcionar recursos compartidos de NFSv3 a tus hosts, es posible que experimentes daños en los datos o que los pods no se ejecuten correctamente. 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 de la base de conocimiento de VMware asociado.


    Solución alternativa:

    El artículo de la base de conocimiento de VMware está desactualizado y señala que 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 arrays de almacenamiento.
    Sistema operativo 1.13.10, 1.14.6, 1.15.3

    En algunas versiones de Google Distributed Cloud, el kubelet que se ejecuta en los nodos usa una versión diferente a la del plano de control de Kubernetes. Hay una discrepancia porque el objeto binario de kubelet precargado en la imagen del SO usa una versión diferente.

    En la siguiente tabla, se enumeran las discrepancias de versión identificadas:

    Versión de Google Distributed Cloud Versión de kubelet Versión de Kubernetes
    1.13.10 v1.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 se requiere ninguna acción. La incoherencia solo se produce entre las versiones de parches de Kubernetes, y esta discrepancia de versión no causó ningún problema.

    Actualizaciones 1.15.0-1.15.4

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

        CAVersion must start from 1

    Solución alternativa:

    • Reduce la implementación de auto-resize-controller en el clúster de administrador para inhabilitar el cambio de tamaño automático de los nodos. Esto es necesario porque un campo nuevo que se introdujo en el recurso personalizado del clúster de administrador en la versión 1.15 puede causar un error de puntero nulo en el 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

    Cuando se borra un clúster de Controlplane V2 sin alta disponibilidad, se queda atascado en la eliminación de nodos 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 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 VMs 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 y versiones posteriores, 1.16.0 y versiones posteriores

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


    Solución alternativa:

    Edita el configMap de la función CSI de vSphere y establece list-volumes en 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 deployment vsphere-csi-controller -n kube-system --kubeconfig KUBECONFIG
    Almacenamiento 1.16.0

    Cuando un clúster contiene volúmenes persistentes de vSphere en el árbol, los comandos gkectl diagnose y gkectl upgrade pueden generar advertencias falsas sobre sus reclamaciones de volumen persistente (PVC) cuando se valida 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 una PVC con la advertencia anterior:

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

    Si el campo annotations en el 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
    Actualizaciones 1.15.0 y versiones posteriores, 1.16.0 y versiones posteriores

    Si tu clúster no usa un registro privado y las claves de la cuenta de servicio de acceso a los componentes y de la cuenta de servicio de supervisión de registros (o registro de Connect) están vencidas, cuando rotas las claves de la cuenta de servicio, gkectl update credentials falla con 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 muestre 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 de componentes.

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

    Durante una actualización de un 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 clústeres de usuario de la versión 1.15 administrados por el mismo clúster de administrador, es posible que se vuelva a crear de forma inesperada la máquina principal del usuario.

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

    La solución que implementes dependerá de cómo encuentres este problema.

    Sigue estos pasos para solucionar el problema cuando actualices el clúster de usuarios con la consola de Google Cloud:

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

    Opción 2: Sigue estos pasos:

    1. Agrega la anotación de la ejecución repetida de forma manual con el siguiente comando: 
      kubectl edit onpremuserclusters USER_CLUSTER_NAME -n USER_CLUSTER_NAME-gke-onprem-mgmt --kubeconfig ADMIN_KUBECONFIG

      La anotación de la repetición es la siguiente:

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

    Solución alternativa para actualizar el clúster de usuarios 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 correcció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 previas se ejecuten de forma local en la estación de trabajo de administrador en lugar de en el 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. Una vez que se complete la actualización, borra el archivo build.info.
    Crear 1.16.0-1.16.5, 1.28.0-1.28.100

    Durante la creación del clúster, si no especificas un nombre de host para cada dirección IP en el archivo de bloque de IP, la verificación previa falla con 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 verificación previa al vuelo que supone que el nombre de host vacío es un duplicado.

    Solución alternativa:

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

    Opción 2: Agrega la marca --skip-validation-net-config para omitir esta verificación de solicitud preliminar.

    Opción 3: Especifica un nombre de host único para cada dirección IP en el archivo de bloqueo de IP.
    Actualizaciones 1.16

    En el caso de un clúster de administrador sin alta disponibilidad y un clúster de usuario del plano de control v1, cuando actualizas el clúster de administrador, la recreación de la máquina principal del clúster de administrador puede ocurrir al mismo tiempo que el reinicio de la máquina principal del clúster de usuario, lo que puede generar una condición de carrera. Esto hace que los pods del plano de control del clúster de usuario no puedan comunicarse con el plano de control del clúster de administrador, lo que genera problemas de conexión de volumen para kube-etcd y kube-apiserver en el plano de control del clúster de usuario.

    Para verificar el problema, ejecuta los siguientes comandos para el pod afectado:

    kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG --namespace USER_CLUSTER_NAME describe pod IMPACTED_POD_NAME
     Verás los eventos de la siguiente manera: 
    Events:
  Type     Reason       Age                  From               Message
  ----     ------       ----                 ----               -------
  Warning  FailedMount  101s                 kubelet            Unable to attach or mount volumes: unmounted volumes=[kube-audit], unattached volumes=[], failed to process volumes=[]: timed out waiting for the condition
  Warning  FailedMount  86s (x2 over 3m28s)  kubelet            MountVolume.SetUp failed for volume "pvc-77cd0635-57c2-4392-b191-463a45c503cb" : rpc error: code = FailedPrecondition desc = volume ID: "bd313c62-d29b-4ecd-aeda-216648b0f7dc" does not appear staged to "/var/lib/kubelet/plugins/kubernetes.io/csi/csi.vsphere.vmware.com/92435c96eca83817e70ceb8ab994707257059734826fedf0c0228db6a1929024/globalmount"

    Solución alternativa:

    1. Establece una conexión SSH en el nodo del plano de control del usuario. Como se trata de un clúster de usuario del plano de control v1, el nodo del plano de control del usuario está en el clúster de administrador.
    2. Reinicia kubelet con el siguiente comando: 
          sudo systemctl restart kubelet
      Después del reinicio, el kubelet puede reconstruir el montaje global de etapa correctamente.
    Actualizaciones 1.16.0

    Durante una actualización de un clúster de administrador, una condición de carrera puede hacer que el administrador de controlador de nube de vSphere borre de forma inesperada un nodo de plano de control nuevo. Esto hace que clusterapi-controller se bloquee esperando que se cree el nodo y, en algún momento, se agote el tiempo de espera de la actualización. En este caso, el resultado del comando de 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"...

    Para identificar el síntoma, ejecuta el siguiente comando para acceder al administrador del controlador de nube 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

    Este es un mensaje de error de ejemplo 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 del 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.
    Operación 1.16

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

    Para identificar el problema, obtén los registros del pod del administrador de controlador de nube de vSphere del clúster. El comando que uses depende del tipo de clúster, como se indica a continuación:

    • 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 usuarios (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 usuarios: (Controlplane 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

    Este es 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

    Verifica 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 resultados 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 que implementes dependerá de la operación que falló.

    Solución alternativa para las actualizaciones:

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

    • Clúster de usuarios:
      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. Vuelve 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 sin HA y descubres que la VM principal del administrador usa un nombre de host duplicado, también debes hacer lo siguiente:
        Obtén el nombre de la máquina principal del administrador 
                  kubectl get machine --kubeconfig ADMIN_KUBECONFIG -owide -A
        Actualiza el objeto de máquina principal del administrador
        Nota: El valor de 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 se actualice en el objeto de máquina principal del 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 alternativa para las instalaciones:

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

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

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

    Usa una versión 1.16.4 o posterior de Google Distributed Cloud con la corrección o realiza la siguiente solución alternativa. La solución que implementes dependerá de la operación que falló.

    Solución alternativa para las actualizaciones:

    1. Cambia el nombre de usuario o la contraseña 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. Activa 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 alternativa para las instalaciones:

    1. Cambia el nombre de usuario o la contraseña 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 para el tipo de clúster aplicable.
    Almacenamiento 1.11 y versiones posteriores, 1.12 y versiones posteriores, 1.13 y versiones posteriores, 1.14 y versiones posteriores, 1.15 y versiones posteriores, 1.16

    Después de borrar un nodo y volver a crearlo con el mismo nombre, existe una pequeña posibilidad de que una creación posterior de PersistentVolumeClaim (PVC) 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 quitada de su caché.


    Solución alternativa:

    Reinicia los pods del controlador de CSI de vSphere:

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

    Cuando ejecutas el comando gkectl repair admin-master en un clúster de administrador de HA, 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 la VM de la máquina, haz lo siguiente:

    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 coincida 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 y versiones posteriores, 1.11.0 y versiones posteriores, 1.12.0 y versiones posteriores, 1.13.0 y versiones posteriores, 1.14.0 a 1.14.7, 1.15.0 a 1.15.3 y 1.16.0

    Si usas Seesaw como el tipo de balanceador de cargas de tu clúster y ves que una VM de Seesaw está inactiva 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 el espacio en el disco es bajo en la VM porque el fluent-bit que se ejecuta en la VM de Seesaw no está configurado con la rotación de registro correcta.


    Solución alternativa:

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

    Nota: Si no se puede acceder a la VM, conecta el disco a una VM que funcione (p.ej., una estación de trabajo del administrador), quita el archivo del disco conectado y, luego, vuelve a conectarlo a la VM de Seesaw original.

    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 al comando de Docker y, luego, ejecuta systemctl restart docker.fluent-bit.service.
    Operación 1.13, 1.14.0-1.14.6 y 1.15

    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 falle 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 con parches de Google Distributed Cloud con la corrección, comunícate con 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

    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 esta falla, verás el siguiente error cuando intentes 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 lo inscribes 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 inactivo “No se pudo registrar el clúster”. Después de un tiempo, debería actualizarse automáticamente.
    Actualizaciones 1.13.0-1.13.9, 1.14.0-1.14.4, 1.15.0

    Cuando un clúster de administrador se inscribe en la API de GKE On-Prem, su anotación de vinculación 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 usa la clave de anotación incorrecta. Esto puede hacer que el clúster de administrador se inscriba nuevamente en la API de GKE On-Prem por error.

    Un clúster de administrador se inscribe en la API cuando lo inscribes 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

    OrderPolicy no se reconoce como un parámetro y no se usa. En su lugar, Google Distributed Cloud siempre usa Random.

    Este problema se produce 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 corrección persiste hasta que se realiza una actualización.

    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 }}
    Actualizaciones 1.10, 1.11, 1.12, 1.13.0-1.13.7, 1.14.0-1.14.3

    Ciertas condiciones de carrera podrían hacer que el estado de OnPremAdminCluster sea incoherente entre el punto de control y la CR real. Cuando se produce el problema, es posible que encuentres el siguiente error cuando actualices el clúster de administrador después de actualizarlo:

    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 o inhabilitar el punto de control para la actualización. Comunícate con nuestro equipo de asistencia al cliente para continuar con la solución.
    Operación 1.13.0-1.13.9, 1.14.0-1.14.5, 1.15.0-1.15.1

    Google Distributed Cloud 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 tengas problemas como los siguientes:

    • Los certificados no válidos pueden hacer que se agote el tiempo de espera de los siguientes comandos y que se 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
    • Es posible que los registros de kube-apiserver de tu clúster de administrador contengan 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 Google Distributed Cloud con la corrección: 1.13.10 o versiones posteriores, 1.14.6 o versiones posteriores, 1.15.2 o versiones posteriores. Si no puedes actualizar, comunícate con el equipo de Atención al cliente de Cloud para resolver este problema.
    Redes, operación 1.10, 1.11, 1.12, 1.13 y 1.14

    Es posible que los Pods de puerta de enlace de red en kube-system muestren un estado de Pending o Evicted, como se muestra en el siguiente resultado de ejemplo condensado:

    $ 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 la imposibilidad de programar Pods debido a los recursos del nodo. Como los pods de Anthos Network Gateway no tienen PriorityClass, tienen la misma prioridad predeterminada que otras cargas de trabajo. Cuando los nodos tienen recursos limitados, es posible que se expulsen los pods de la puerta de enlace de red. 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 una posterior.

    Como solución a corto plazo, puedes asignar manualmente un PriorityClass a los componentes de la puerta de enlace de red de Anthos. El controlador de Google Distributed Cloud 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ústeres ang-controller-manager y autoscaler.
    • Asigna la PriorityClass system-node-critical al DaemonSet del nodo ang-daemon.
    Actualizaciones 1.12, 1.13, 1.14, 1.15.0-1.15.2

    Después de usar gcloud para registrar un clúster de administrador con una 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 reanudar 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 limita el período para los comandos 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 la instantánea aún incluye todos los registros que se recopilan de forma predeterminada cuando se ejecuta journalctl en los nodos del clúster. Por lo tanto, no se pierde información de depuración.
    Instalación, actualizaciones 1.9+, 1.10+, 1.11+ y 1.12+

    gkectl prepare windows no instala Docker en versiones de Google Distributed Cloud anteriores a la 1.13 porque MicrosoftDockerProvider dejó de estar disponible.


    Solución alternativa:

    La idea general para solucionar este problema es actualizar a Google Distributed Cloud 1.13 y usar gkectl 1.13 para crear una plantilla de VM de Windows y, luego, crear grupos de nodos de Windows. Existen dos opciones para acceder a Google Distributed Cloud 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 1.13, pero se necesitarán más pasos manuales. Comunícate con nuestro equipo de asistencia si deseas considerar esta opción.


    Opción 1: Actualización azul-verde

    Puedes crear un clúster nuevo con la versión 1.13 o posterior de Google Distributed Cloud con grupos de nodos de Windows, migrar tus cargas de trabajo al clúster nuevo y, luego, desmantelar el clúster actual. Se recomienda usar la versión menor más reciente de Google Distributed Cloud.

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


    Opción 2: Borra los grupos de nodos de Windows y vuelve a agregarlos cuando realices la actualización a Google Distributed Cloud 1.13.

    Nota: Con 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. Para borrar los grupos de nodos de Windows existentes, 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 exclusivos de Linux a la versión 1.12 siguiendo la guía de usuario de actualización de la versión secundaria objetivo 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 OnPremUserCluster CR. De lo contrario, el clúster seguirá usando grupos de nodos de Docker para Windows, que no serán compatibles con la plantilla de VM de Windows 1.13 recién creada que no tiene Docker instalado. Si no está configurado o se establece como falso, actualiza el clúster para establecerlo 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 la versión 1.13 siguiendo la guía de usuario de actualización.
    5. Prepara la plantilla de VM de Windows con gkectl 1.13: 
      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 1.13.0-1.13.9, 1.14.0-1.14.5, 1.15.0-1.15.1

    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 a través de SSH en la VM, que se encuentra en "/var/log/startup.log", puedes encontrar el siguiente error:

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

    El uso de un RootDistanceMaxSec de 5 segundos puede hacer que el reloj del sistema no esté sincronizado con el servidor NTP cuando la deriva del reloj sea mayor que 5 segundos.


    Solución alternativa:

    Aplica el siguiente DaemonSet a 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: /
    Actualizaciones 1.12.0-1.12.6, 1.13.0-1.13.6, 1.14.0-1.14.2

    Cuando usas gkectl de la versión 1.13 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 usas gkectl update admin para 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 revisas el registro de gkectl, es posible que veas que los múltiples cambios incluyen configurar osImageType de una cadena 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 Google Distributed Cloud con la corrección. Si no es posible realizar la actualización, comunícate con Atención al cliente de Cloud para resolver este problema.
    Instalación y seguridad 1.13, 1.14, 1.15 y 1.16

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


    Solución alternativa:

    Hasta que haya un parche de Google Distributed Cloud disponible con la corrección, si necesitas usar SNI, inhabilita Controlplane 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

    La máquina del plano de control del administrador no se inicia cuando el nombre de usuario del registro privado contiene $. Cuando verificas el /var/log/startup.log en la máquina del plano de control del administrador, ves 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 Google Distributed Cloud con la corrección.
    Actualizaciones 1.12.0-1.12.4

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

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

    Después de rotar las claves de firma de KSA y, luego, actualizar un clúster de usuario, es posible que gkectl update falle con 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 de KSA a 1, pero conserva los datos de clave más recientes:
    1. Verifica el secreto en el clúster de administrador en el espacio de nombres USER_CLUSTER_NAME y obtén el nombre del secreto de la clave de firma de ksa: 
      kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME get secrets | grep ksa-signing-key
    2. Copia el secreto ksa-signing-key y asígnale el nombre service-account-cert: 
      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 de ksa-signing-key anterior: 
      kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME delete secret KSA-KEY-SECRET-NAME
    4. Actualiza el campo data.data en el configmap ksa-signing-key-rotation-stage 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 a que el clúster de usuarios de destino esté listo. Para verificar el estado, haz lo siguiente: 
      kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME-gke-onprem-mgmt \
get onpremusercluster
    8. Restablece el webhook de validación para el 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 la clave 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

    Cuando usas Terraform para borrar un clúster de usuarios con un balanceador de cargas BIG-IP de F5, los servidores virtuales 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 la partición F5 de un clúster de usuario

    Instalación, actualizaciones 1.13.8 y 1.14.4

    Si creas un clúster de administrador de la versión 1.13.8 o 1.14.4, o bien 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 de 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 clúster de tipo. Si 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 estar precargadas en la imagen del contenedor del clúster de tipo. Sin embargo, kind v0.18.0 tiene un problema con las imágenes de contenedor precargadas, lo 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

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

    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 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 hace que vsphere-csi-controller falle después de la rotación.

    Solución alternativa:

    Para los clústeres creados en la versión 1.13 y versiones 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

    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 tener éxito. En otras palabras, la creación del clúster de administrador podría "tener éxito" sin estar registrado 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:

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

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

    Actualizaciones 1.10, 1.11, 1.12, 1.13.0-1.13.1

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


    Solución alternativa:

    Verifica si el clúster aparece entre los clústeres registrados. Como paso opcional, accede al clúster después de configurar la autenticación. Si el clúster aún está registrado, puedes omitir las siguientes instrucciones para volver a intentar el registro. Para los clústeres actualizados a la versión 1.12 y versiones posteriores, sigue las instrucciones para volver a intentar el registro del clúster de administrador después de crearlo. 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 de connect-register.
    2. Ejecuta gkectl update admin para volver a registrar el clúster de administrador.

    Configuración 1.15.0

    En el caso de un clúster de administrador con 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

    Durante la creación de un grupo de nodos que usa afinidad de VM-host, una condición de carrera puede provocar que se creen varias reglas de afinidad de VM-host con el mismo nombre. Esto puede provocar que no se pueda crear el grupo de nodos.


    Solución alternativa:

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

    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 se ejecute correctamente.
    Actualizaciones 1.15.0

    Después de volver a crear o actualizar un nodo del plano de control, es posible que ciertos Pods permanezcan en el estado Failed debido a una falla del predicado NodeAffinity. Estos pods con errores no afectan el estado ni las operaciones 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

    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 que veas el siguiente mensaje de error: 

    failed to check secret reference for private registry …


    Solución alternativa:

    Prepara las credenciales de registro privadas para el clúster de usuario según las instrucciones que se indican en Configura credenciales preparadas.

    Actualizaciones 1.15.0

    Durante gkectl upgrade admin, la verificación de solicitud preliminar de almacenamiento para la migración de CSI verifica que los StorageClass 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, entonces gkectl upgrade admin marca la StorageClass y informa un error en la validación previa al vuelo. Los clústeres de administrador creados en Google Distributed Cloud 1.10 y versiones anteriores tienen una StorageClass con diskformat: thin, que fallará en esta validación. Sin embargo, esta StorageClass seguirá funcionando bien después de la migración de CSI. En cambio, estas fallas deben interpretarse como advertencias.

    Para obtener más información, consulta la sección del parámetro StorageClass en Cómo migrar volúmenes de vSphere en el árbol al complemento de almacenamiento de contenedores de vSphere.


    Solución alternativa:

    Después de confirmar que tu clúster tiene un 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 y 1.16

    En ciertas condiciones, los discos se pueden conectar como de solo lectura a nodos de Windows. Esto hace que el volumen correspondiente sea de solo lectura dentro de un pod. Es más probable que este problema se produzca cuando un conjunto de nodos nuevo reemplace un conjunto de nodos antiguo (por ejemplo, una actualización de clúster o de grupo de nodos). Es posible que las cargas de trabajo con estado que funcionaban bien antes 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 el PersistentVolumeClaim para obtener el nombre del PersistentVolume: 
      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 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 se debe programar 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.

    Actualizaciones 1.12, 1.13.0-1.13.7, 1.14.0-1.14.4

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

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


    Solución alternativa:

    1. Obtén el nombre del Secret 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 las siguientes opciones: 
      kubectl --kubeconfig=ADMIN_KUBECONFIG -n=kube-system rollout status deployment vsphere-csi-controller
       Después de que se implemente la implementación correctamente, el controlador debe usar el vsphere-csi-secret actualizado.
    Actualizaciones 1.10, 1.11, 1.12.0-1.12.6, 1.13.0-1.13.6, 1.14.0-1.14.2

    Es posible que audit-proxy entre en un bucle de falla 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 pod o contenedor de proxy de auditoría.


    Solución alternativa:

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

    Para un clúster de usuario de Controlplane v1, edita el contenedor audit-proxy en el statefulset kube-apiserver para agregar --cluster_name=USER_CLUSTER_NAME:

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

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

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

    Este problema solo ocurre en los clústeres de usuarios que NO usan el plano de control v2.


    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 o versiones posteriores, 1.14.2 o versiones posteriores, o 1.15 o versiones posteriores.
    Actualizaciones 1.12.7

    Google Distributed Cloud 1.12.7-gke.19 es una versión no válida y no debes usarla. Los artefactos se quitaron del bucket de Cloud Storage.

    Solución alternativa:

    En su lugar, usa la versión 1.12.7-gke.20.
    Actualizaciones 1.12.0 y versiones posteriores, 1.13.0 a 1.13.7, 1.14.0 a 1.14.3

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

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

    Es posible que gke-connect-agent siga usando la imagen más antigua o que los pods de gke-connect-agent no se puedan recuperar debido a ImagePullBackOff.

    Este problema se solucionará en las versiones 1.13.8, 1.14.4 y posteriores de Google Distributed Cloud.


    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 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 usuarios: 
      gkectl update credentials register --kubeconfig=ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG_FILE

    Opción 2: Puedes cambiar manualmente los datos del secreto de extracción de imágenes 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 imágenes predeterminado para tu clúster en la implementación de 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 la implementación gke-connect-agent: 
      kubectl --kubeconfig=KUBECONFIG -n=gke-connect get deployment | grep gke-connect-agent
    3. Agrega el Secret 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 y 1.14

    Cuando valides la configuración antes de crear un clúster con el balanceador de cargas manual ejecutando gkectl check-config, el comando fallará con 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 de 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

    Es posible que los clústeres que ejecutan etcd versión 3.4.13 o anterior experimenten una falta de supervisión y supervisión de recursos no operativos, lo que puede provocar los siguientes problemas:

    • Se interrumpe la programación de pods
    • Los nodos no se pueden registrar
    • kubelet no observa los cambios en el pod

    Estos problemas pueden hacer que el clúster deje de funcionar.

    Este problema se solucionó en las versiones 1.12.7, 1.13.6, 1.14.3 y posteriores de Google Distributed Cloud. Estas versiones más recientes usan la versión 3.4.21 de etcd. Todas las versiones anteriores de Google Distributed Cloud se ven afectadas por este problema.

    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 él. 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, usa 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, elige Anthos.
      3. En el menú Métricas activas, selecciona etcd_network_client_grpc_sent_bytes_total.
      4. Haz clic en Aplicar.
    Actualizaciones 1.10, 1.11, 1.12, 1.13 y 1.14

    Cuando se reinician o actualizan los clústeres, GKE Identity Service puede verse sometido a una gran cantidad de tráfico que consiste en tokens JWT vencidos que se reenvían desde kube-apiserver a GKE Identity Service a través del webhook de autenticación. Aunque GKE Identity Service no entra en un bucle de falla, deja de responder y deja de entregar más solicitudes. Este problema genera latencias más altas del plano de control.

    Este problema se solucionó en las siguientes versiones de Google Distributed Cloud:

    • 1.12.6 y versiones posteriores
    • 1.13.6+
    • 1.14.2 y versiones posteriores

    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 de tu clúster (por ejemplo, 172.16.20.50:443).

      Si este problema te afecta, el comando muestra 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 000, significa que el problema se resolvió y que puedes continuar. Si sigues recibiendo 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 de GKE Identity Service: 
        kubectl logs -f -l k8s-app=ais -n anthos-identity-service \
    --kubeconfig KUBECONFIG

        Si el registro contiene una entrada como la siguiente, significa que 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 de kube-apiserver de tus 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 de kube-apiserver contienen entradas como las siguientes, significa que te afecta este problema:

        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 corregir el problema, puedes identificar y reiniciar los pods afectados como solución alternativa:

    1. Aumenta el nivel de verbosidad de GKE Identity Service 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. Verifica el registro de GKE Identity Service en busca del contexto de 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 y el espacio de nombres del pod de origen, cópialo en el depurador en jwt.io.
    5. Reinicia los pods identificados a partir de los tokens.
    Operación 1.9, 1.10, 1.11, 1.12 y 1.13

    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 todos los espacios de nombres. Sin embargo, comienza a omitir los pods del plano de control del usuario por error. Si usas el modo de plano de control v2, esto no afectará a tu clúster.


    Solución alternativa:

    Esto no afectará la administración de cargas de trabajo ni de clústeres. Si deseas 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
    Redes 1.10, 1.11, 1.12.0-1.12.6, 1.13.0-1.13.6, 1.14.0-1.14.2

    gkectl create loadbalancer falla con 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 Seesaw ya existe. Y la verificación previa intenta validar un balanceador de cargas de balancín inexistente.

    Solución alternativa:

    Quita el archivo de grupo de Seesaw existente para este clúster. El nombre del 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

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

    Para ver si este problema te afecta, puedes verificar las estadísticas del sistema de seguimiento de conexiones en el 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, te verás afectado por este problema.

    Solución alternativa

    La mitigación a corto plazo consiste en aumentar el tamaño de la tabla de hash de netfilter (nf_conntrack_buckets) y de la tabla de seguimiento de conexiones 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 el nuevo tamaño 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

    Con Controlplane V2 habilitado, es posible que calico-typha o anetd-operator se programen en nodos de Windows y entren en un bucle de falla.

    El motivo es que las dos implementaciones toleran todas las contaminaciones, incluida la contaminación del nodo de Windows.


    Solución alternativa:

    Actualiza a la versión 1.13.3 o posterior, o bien ejecuta los siguientes comandos para editar la implementación de "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 spec.template.spec.tolerations:

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

    Agrega la siguiente tolerancia:

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

    Es posible que no puedas crear un clúster de usuarios si especificas la sección privateRegistry con la credencial fileRef. Es posible que la verificación previa falle con el siguiente mensaje: 

    [FAILURE] Docker registry access: Failed to login.


    Solución alternativa:

    • Si no tenías la intención de especificar el campo o deseas usar la misma credencial de registro privado que el clúster de administrador, simplemente puedes 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 tu clúster de usuario, puedes especificar temporalmente 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 una posterior).

    Almacenamiento 1.12 y versiones posteriores, 1.13.3

    Es posible que kube-controller-manager se agote cuando se desconecten los PV o PVC después de 6 minutos y los desconecte de manera forzosa. Los registros detallados de kube-controller-manager 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 con SSH y reinícialo.
    Actualizaciones 1.12+, 1.13+ y 1.14+

    Es posible que no puedas actualizar un clúster si usas un controlador de CSI de terceros. El comando gkectl cluster diagnose podría 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+ y 1.14+

    Es posible que el nodo principal de administrador creado a través de gkectl repair admin-master use una versión de hardware de VM inferior a la esperada. Cuando ocurra el problema, verás el error del 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 principal de administrador, sigue las instrucciones que se indican en https://kb.vmware.com/s/article/1003746 para actualizar el nodo a la versión esperada que se describe en el mensaje de error y, luego, inícialo.
    Sistema operativo 1.10+, 1.11+, 1.12+, 1.13+, 1.14+, 1.15+ y 1.16+

    En systemd v244, systemd-networkd tiene un cambio de comportamiento predeterminado en la configuración de KeepConfiguration. Antes de este cambio, las VMs no enviaban un mensaje de liberación de la concesión de tiempo de DHCP al servidor de DHCP durante el cierre o el reinicio. Después de este cambio, las VMs envían ese mensaje y muestran las IP al servidor 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 de vSphere) o un cambio de IP en las VMs, lo que puede dañar 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
    • Los nodos nuevos no se inician debido a un error de calico-node. 
      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 VMs que ejecutan este DaemonSet no liberarán las IP al servidor DHCP durante el cierre o el reinicio. El servidor DHCP liberará las direcciones IP automáticamente cuando venza el plazo de arrendamiento. 

          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

    Operación, actualizaciones 1.12.0-1.12.5, 1.13.0-1.13.5, 1.14.0-1.14.1

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

    Después de actualizar un clúster de 1.11.x a 1.12.x, el campo component-access-sa-key en el secreto admin-cluster-creds se borrará. Para verificarlo, ejecuta el siguiente comando: 

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

    Después de borrar la clave de la cuenta de servicio de acceso de componentes, no se podrán instalar clústeres de usuarios nuevos ni actualizar los existentes. A continuación, se muestran algunos mensajes de error que podrías encontrar:

    • Falla de validación previa lenta con el mensaje de error: "Failed to create the test VMs: failed to get service account key: service account is not configured."
    • La preparación por gkectl prepare falló y mostró el siguiente mensaje de error: "Failed to prepare OS images: dialing: unexpected end of JSON input"
    • Si actualizas un clúster de usuarios de 1.13 con la consola de Google Cloud o la CLI de gcloud, cuando ejecutas gkectl update admin --enable-preview-user-cluster-central-upgrade para implementar el controlador de plataforma de actualización, el comando falla con el 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 del componente 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 y versiones posteriores, 1.14.0 y versiones posteriores

    En el caso de los clústeres de usuario creados con Controlplane V2 habilitado, los grupos de nodos con ajuste de escala automático habilitado siempre usan su autoscaling.minReplicas en user-cluster.yaml. El registro del pod de cluster-autoscaler muestra un error similar al siguiente: 

      > 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 de 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 que actualices 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

    Cuando los usuarios usan CIDR en el archivo de bloque de IP, la validación de configuración fallará con 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 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 versiones posteriores.
    Actualizaciones 1.14.0-1.14.1

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


    Solución alternativa:

    Después de que finalice la actualización, sigue esperando a que las máquinas del plano de control del usuario también terminen de volver a crearse. Para ello, supervisa los tipos de imágenes del SO del nodo con kubectl --kubeconfig USER_KUBECONFIG get nodes -owide. p.ej., si actualizamos 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 y 1.14.0

    Un problema con Calico en Google Distributed Cloud 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 se establece en "false" o no se especifica, significa que estás usando Calico en el clúster de usuario.

    El contenedor install-cni de los nodos crea un kubeconfig con un token que es válido durante 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 solucionó en la versión 1.14.1 de Google Distributed Cloud. Actualiza a esta versión o a una posterior.

    Si no puedes actualizar de inmediato, aplica el siguiente parche en el DaemonSet calico-node de tu 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 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 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 porque el clúster no tiene suficientes IP.


    Solución alternativa:

    Divide los CIDR en varios bloques CIDR más pequeños, por ejemplo, 10.0.0.0/30 se convierte en 10.0.0.0/31, 10.0.0.2/31. Esto debería ser suficiente, siempre y cuando haya N+1 CIDR, donde N es la cantidad de nodos del clúster.

    Actualizaciones 1.11 y 1.12

    Si usas una versión de Google Distributed Cloud anterior a la 1.12 y configuraste manualmente los componentes de Prometheus administrado por Google (GMP) en el espacio de nombres gmp-system para tu clúster, los componentes no se conservarán cuando actualices 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 las CRD se administran mediante 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

    En el caso de 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 Cluster que se encuentran en este espacio de nombres, contienen información de depuración útil. La instantánea del clúster debería incluirlos.


    Solución alternativa:

    Puedes ejecutar los siguientes comandos de forma manual 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.
    Actualizaciones 1.11.0-1.11.4, 1.12.0-1.12.3, 1.13.0-1.13.1

    Cuando borras, actualizas o mejoras un clúster de usuario, es posible que el drenaje de nodos se bloquee en las siguientes situaciones:

    • El clúster de administrador usa el controlador CSI de vSphere en 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 ni 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

    Este es un mensaje de error de ejemplo 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 el árbol de vSphere. Cuando no se crean objetos PVC o PV, es posible que se produzca un error que haga que el drenaje de nodos no encuentre 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 y 1.14

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

    Los síntomas son los siguientes:

    • Registros cluster-autoscaler
      • kubectl logs --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n kube-system \
cluster-autoscaler
       donde ADMIN_CLUSTER_KUBECONFIG es el archivo kubeconfig del clúster de administrador. A continuación, se muestra un ejemplo de los mensajes de error que podrías 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:

    Verifica si faltan el rol de clúster y el vínculo de roles de clúster en el clúster de administrador 

    • kubectl get clusterrolebindings --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n kube-system | grep cluster-autoscaler
       
    • kubectl get clusterrole --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n kube-system | grep cluster-autoscaler

    Aplica el siguiente clusterrole y clusterrolebinding al clúster de administrador si faltan. Agrega los sujetos de la cuenta de servicio a la vinculación de roles de clúster para cada clúster de usuario.

    • apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: cluster-autoscaler
rules:
- apiGroups: ["cluster.k8s.io"]
  resources: ["clusters"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["cluster.k8s.io"]
  resources: ["machinesets","machinedeployments", "machinedeployments/scale","machines"]
  verbs: ["get", "list", "watch", "update", "patch"]
- apiGroups: ["onprem.cluster.gke.io"]
  resources: ["onpremuserclusters"]
  verbs: ["get", "list", "watch"]
- apiGroups:
  - coordination.k8s.io
  resources:
  - leases
  resourceNames: ["cluster-autoscaler"]
  verbs:
  - get
  - list
  - watch
  - create
  - update
  - patch
- apiGroups:
  - ""
  resources:
  - nodes
  verbs: ["get", "list", "watch", "update", "patch"]
- apiGroups:
  - ""
  resources:
  - pods
  verbs: ["get", "list", "watch"]
- apiGroups:
  - ""
  resources:
  - pods/eviction
  verbs: ["create"]
# read-only access to cluster state
- apiGroups: [""]
  resources: ["services", "replicationcontrollers", "persistentvolumes", "persistentvolumeclaims"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["apps"]
  resources: ["daemonsets", "replicasets"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["apps"]
  resources: ["statefulsets"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["batch"]
  resources: ["jobs"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["policy"]
  resources: ["poddisruptionbudgets"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["storage.k8s.io"]
  resources: ["storageclasses", "csinodes"]
  verbs: ["get", "list", "watch"]
# misc access
- apiGroups: [""]
  resources: ["events"]
  verbs: ["create", "update", "patch"]
- apiGroups: [""]
  resources: ["configmaps"]
  verbs: ["create"]
- apiGroups: [""]
  resources: ["configmaps"]
  resourceNames: ["cluster-autoscaler-status"]
  verbs: ["get", "update", "patch", "delete"]
       
    • apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  labels:
    k8s-app: cluster-autoscaler
  name: cluster-autoscaler
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-autoscaler
subjects:
  - kind: ServiceAccount
  name: cluster-autoscaler
  namespace:  NAMESPACE_OF_USER_CLUSTER_1 
  - kind: ServiceAccount
  name: cluster-autoscaler
  namespace:  NAMESPACE_OF_USER_CLUSTER_2 
  ...
    Configuración 1.7, 1.8, 1.9, 1.10, 1.11, 1.12 y 1.13

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

    Los síntomas son los siguientes:

    • Registros cluster-health-controller
      • kubectl logs --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n kube-system \
cluster-health-controller
       donde ADMIN_CLUSTER_KUBECONFIG es el archivo kubeconfig del clúster de administrador. A continuación, se muestra un ejemplo de los mensajes de error que podrías 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
       donde ADMIN_CLUSTER_KUBECONFIG es el archivo kubeconfig del clúster de administrador. A continuación, se muestra un ejemplo de los mensajes de error que podrías 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:

    Aplica el siguiente YAML al clúster de administrador.

    • Para vsphere-metrics-exporter
      • kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: vsphere-metrics-exporter
rules:
  - apiGroups:
      - cluster.k8s.io
    resources:
      - clusters
    verbs: [get, list, watch]
  - apiGroups:
      - ""
    resources:
      - nodes
    verbs: [get, list, watch]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  labels:
    k8s-app: vsphere-metrics-exporter
  name: vsphere-metrics-exporter
  namespace: kube-system
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: vsphere-metrics-exporter
subjects:
  - kind: ServiceAccount
    name: vsphere-metrics-exporter
    namespace: kube-system
    • Para cluster-health-controller
      • apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: cluster-health-controller-role
rules:
- apiGroups:
  - "*"
  resources:
  - "*"
  verbs:
  - "*"
    Configuración 1.12.1-1.12.3, 1.13.0-1.13.2

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

    El síntoma es que el comando gkectl check-config fallará con 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 del SO faltantes.

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

    Un problema conocido que podría fallar en gkectl update admin/cluster cuando se actualiza anti affinity groups

    El síntoma es que el comando gkectl update fallará con 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:

    Para que se aplique la actualización, las máquinas deben volver a crearse after la actualización fallida.

    Para actualizar el clúster de administrador, se deben volver a crear los nodos principales de usuario y de complementos de administrador

    Para actualizar el clúster de usuario, se deben volver a crear los nodos de trabajo del usuario

    Para volver a crear nodos de trabajo del usuario

    Opción 1
    En la versión 1.11 de la documentación, sigue las instrucciones para actualizar un grupo de nodos y cambia la CPU o la memoria para activar una recreación continua de los nodos.

    Opción 2
    Usa kubectl delete para volver a crear las máquinas de a una a la vez.

    kubectl delete machines MACHINE_NAME --kubeconfig USER_KUBECONFIG

    Para volver a crear nodos principales de usuarios

    Opción 1
    En la versión 1.11 de la documentación, sigue las instrucciones para cambiar el tamaño del plano de control y cambia la CPU o la memoria para activar una recreación continua de los nodos.

    Opción 2
    Usa kubectl delete para volver a crear las máquinas de a una a la vez.

    kubectl delete machines MACHINE_NAME --kubeconfig ADMIN_KUBECONFIG

    Para volver a crear nodos de complementos de administrador

    Usa kubectl delete para volver a crear las máquinas de a una

    kubectl delete machines MACHINE_NAME --kubeconfig ADMIN_KUBECONFIG
    Instalación, actualizaciones 1.13.0-1.13.8, 1.14.0-1.14.4, 1.15.0

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

    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 en el 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 usuarios, ejecuta el siguiente comando: 
      kubectl logs clusterapi-controllers-POD_NAME \
    -c clusterapi-controller-manager -n USER_CLUSTER_NAME \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG
       donde:
      • ADMIN_CLUSTER_KUBECONFIG es el archivo kubeconfig del clúster de administrador.
      • USER_CLUSTER_NAME es el nombre del clúster de usuario.
      Este es un ejemplo de los mensajes de error que podrías ver: "msg"="failed to validate token id" "error"="failed to find machine for node node-worker-vm-1" "validate"="csr-5jpx9"
    • Consulta los registros de kubelet en el nodo problemático: 
      journalctl --u kubelet
       Este es un ejemplo de los mensajes de error que podrías 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 bloque de IP, se ignorarán los caracteres que sigan al primer punto. Por ejemplo, si especificas el nombre de host como bob-vm-1.bank.plc, el nombre de host y el nombre del nodo de la VM se establecerán como bob-vm-1.

    Cuando la verificación de ID de nodo está habilitada, el revisor de CSR compara el nombre del nodo con el nombre de host en las especificaciones de la máquina y no logra conciliar el nombre. El revisor rechaza la CSR, y el nodo no se inicializa.


    Solución alternativa:

    Clúster de usuarios

    Para inhabilitar la verificación del ID del nodo, completa los siguientes 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 ejecuta el siguiente comando para actualizar el clúster de usuario: 
      gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config USER_CLUSTER_CONFIG_FILE
       Reemplaza lo siguiente:
      • ADMIN_CLUSTER_KUBECONFIG: Es la ruta 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 la API de clúster de Deployment 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
    Networking 1.10, 1.11.0-1.11.3, 1.12.0-1.12.2, 1.13.0

    In networkgatewaygroups.status.nodes, some nodes switch between NotHealthy and Up.

    Logs for the ang-daemon Pod running on that node reveal repeated errors: 

    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 IPs flotantes adicionales al nodo. Esto puede generar una carga más alta en otros nodos o una falta de redundancia para la alta disponibilidad.

    De lo contrario, la actividad del plano de datos no se ve afectada.

    La contención en el objeto networkgatewaygroup hace que algunas actualizaciones de estado fallen debido a un error en el manejo de reintentos. Si fallan demasiadas actualizaciones de estado, ang-controller-manager considera que el nodo superó el límite de tiempo de la señal de actividad y lo marca como NotHealthy.

    El error en el manejo de reintentos se corrigió en versiones posteriores.


    Solución alternativa:

    Actualiza a una versión corregida cuando esté disponible.
    Actualizaciones 1.12.0-1.12.2, 1.13.0

    Un problema conocido que podría hacer que la actualización del clúster se bloquee esperando 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 a cualquier operación de actualización progresiva de los grupos de nodos.

    El síntoma es que el comando gkectl se agota con 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 del Pod 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 las ejecuciones correctas, incluso sin este problema. La mayoría de las veces, puede pasar rápidamente, pero en algunos casos excepcionales, puede quedar atascado en esta condición de carrera durante varias horas.

    El problema es que la VM subyacente ya se borró en vCenter, pero no se puede quitar el objeto de máquina correspondiente, que está atascado en la eliminación del finalizador debido a actualizaciones muy frecuentes de otros controladores. Esto puede hacer que el comando gkectl se agote, pero el controlador sigue conciliando el clúster para que el proceso de actualización se complete.


    Solución alternativa:

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

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

      En función del análisis y la reproducción en tu entorno, la actualización puede terminar por sí sola sin ninguna intervención manual. La salvedad de esta opción es que no se sabe cuánto tiempo llevará la eliminación del finalizador para cada objeto de máquina. Puede completarse de inmediato si tienes suerte, o bien puede durar varias horas si la conciliación del controlador de conjuntos de máquinas es demasiado rápida y el controlador de máquinas nunca tiene la oportunidad de quitar el finalizador entre las reconciliaciones.

      La ventaja de esta opción es que no necesitas realizar ninguna acción y las cargas de trabajo no se verán interrumpidas. 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 de conjuntos de máquinas filtrará las máquinas que tengan la anotación de reparación automática y la marca de tiempo de eliminación que no sean 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 desalojarse, lo que significa que no respetarán la configuración del PDB, lo que podría causar un tiempo de inactividad para tus cargas de trabajo.

      El comando para obtener todos los nombres de las máquinas: 
      kubectl --kubeconfig CLUSTER_KUBECONFIG get machines
       El comando para aplicar la anotación de reparación automática para 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 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 medidas de mitigación.
    Instalación, actualizaciones 1.10.2, 1.11, 1.12 y 1.13

    El comando gkectl prepare falló con lo siguiente:

    - 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 verificaciones previas 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 y 1.13

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

    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 1.10, 1.11, 1.12 y 1.13

    gkectl prepare puede entrar en 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 de certificados del 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
    Actualizaciones 1.10, 1.11, 1.12 y 1.13

    Después de un intento de actualización de clúster de administrador con errores, no ejecutes gkectl repair admin-master. De lo contrario, es posible que los intentos de actualización posteriores del administrador fallan con problemas, como fallas en el encendido del administrador principal o la imposibilidad de acceder a la VM.


    Solución alternativa:

    Si ya te encontraste con esta situación de falla, comunícate con el equipo de asistencia.
    Sistema operativo 1.12 y 1.13

    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:

    Volvimos a cgroup v1 (híbrido) en la versión 1.12.1. Si usas nodos de COS, te recomendamos que actualices a la versión 1.12.1 en cuanto se lance.
    Identidad 1.10, 1.11, 1.12 y 1.13

    gkectl update revierte los cambios manuales que realizaste al 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 y 1.13

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

    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

    Es posible que veas un error de instalación debido a cert-manager-cainjector en bloqueo, 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:

    Ejecuta los siguientes comandos para mitigar el problema.

    Primero, reduce verticalmente la escala de monitoring-operator para que no revierta los cambios en la implementación de cert-manager:

    kubectl --kubeconfig USER_CLUSTER_KUBECONFIG -n kube-system \
    scale deployment monitoring-operator --replicas=0

    Edita la implementación de cert-manager-cainjector para inhabilitar la elección de líder, ya que solo tenemos una réplica en ejecución. No es necesario para una sola réplica:

    # Add a command line flag for cainjector: `--leader-elect=false`
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG edit \
    -n kube-system deployment cert-manager-cainjector

    El fragmento YAML relevante para la implementación de cert-manager-cainjector debería verse como el siguiente ejemplo:

    ...
apiVersion: apps/v1
kind: Deployment
metadata:
  name: cert-manager-cainjector
  namespace: kube-system
...
spec:
  ...
  template:
    ...
    spec:
      ...
      containers:
      - name: cert-manager
        image: "gcr.io/gke-on-prem-staging/cert-manager-cainjector:v1.0.3-gke.0"
        args:
        ...
        - --leader-elect=false
...

    Mantén las réplicas de monitoring-operator en 0 como mitigación hasta que finalice la instalación. De lo contrario, revertirá el cambio.

    Una vez que finalice la instalación y el clúster esté en funcionamiento, activa monitoring-operator para las operaciones del día 2:

    kubectl --kubeconfig USER_CLUSTER_KUBECONFIG -n kube-system \
    scale deployment monitoring-operator --replicas=1

    Los cambios se revertirán después de cada actualización. Realiza los mismos pasos una vez más para mitigar el problema hasta que se solucione en una versión futura.
    VMware 1.10, 1.11, 1.12 y 1.13

    Si vCenter, en versiones anteriores a 7.0U2, se reinicia después de una actualización o de otra manera, el nombre de red en la información de VM de vCenter es incorrecto y hace que la máquina esté en un estado Unavailable. Finalmente, esto hace que los nodos se reparen automáticamente 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 corrigió en las versiones 7.0U2 y posteriores de vCenter.
    2. En versiones anteriores, haz clic con el botón derecho en el host y, luego, selecciona Connection > Disconnect. A continuación, vuelve a conectarte, lo que forzará una actualización del grupo de puertos de la VM.
    Sistema operativo 1.10, 1.11, 1.12 y 1.13

    Para la versión 1.7.2 de Google Distributed Cloud y versiones posteriores, las imágenes del SO de Ubuntu se endurecen con la comparativa del servidor L1 de CIS.

    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 genera un comportamiento inesperado. Cuando uses la sesión SSH en la estación de trabajo de administrador o un nodo del clúster, la conexión SSH podría desconectarse, incluso si tu cliente SSH no está inactivo, como cuando se ejecuta un comando lento, y tu comando podría finalizar con el siguiente mensaje:

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

    Solución alternativa:

    Para hacerlo, tienes las alternativas siguientes:

    • Usa nohup para evitar que el comando se finalice cuando te desconectes de SSH. 
      nohup gkectl upgrade admin --config admin-cluster.yaml \
    --kubeconfig kubeconfig
    • Actualiza sshd_config para usar un valor 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 de SSH.
    Instalación 1.10, 1.11, 1.12 y 1.13

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

    Solo debes 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 instalar 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 el cert-manager y revertir la versión en el proceso.

    Solución alternativa:

    <pEvita conflictos durante la actualización

    1. Desinstala tu versión de cert-manager. Si definiste tus propios recursos, te recomendamos que crees una copia de seguridad de ellos.
    2. Realiza la actualización.
    3. Sigue las siguientes instrucciones para restablecer tu cert-manager.

    Cómo restablecer tu propio cert-manager en clústeres de usuario

    • Escala la implementación de monitoring-operator a 0: 
      kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    -n USER_CLUSTER_NAME \
    scale deployment monitoring-operator --replicas=0
    • Escala las implementaciones de cert-manager administradas por monitoring-operator a 0: 
      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. Restaura tus recursos personalizados si los tienes.
    • Puedes omitir este paso si usas la instalación predeterminada de cert-manager o si tienes la certeza de que 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 de metrics-pki.cluster.local de cert-manager al espacio de nombres del recurso 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

    Cómo restablecer tu propio cert-manager en clústeres de administrador

    En general, no deberías necesitar volver a instalar cert-manager en los clústeres de administrador, ya que estos solo ejecutan cargas de trabajo del plano de control de Google Distributed Cloud. En los casos excepcionales en los 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 las implementaciones de cert-manager administradas por monitoring-operator a 0. 
      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. Restaura tus recursos personalizados si los tienes.
    • Puedes omitir este paso si usas la instalación predeterminada de cert-manager o si tienes la certeza de que 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 de metrics-pki.cluster.local de cert-manager al espacio de nombres del recurso 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
    </p
    Sistema operativo 1.10, 1.11, 1.12 y 1.13

    Docker, containerd y runc en las imágenes del SO de Ubuntu enviadas con Google Distributed Cloud se fijan a versiones especiales mediante PPA de Ubuntu. Esto garantiza que Google Distributed Cloud califique los cambios en el entorno de ejecución del contenedor antes de cada actualización.

    Sin embargo, las versiones especiales no son conocidas para la Herramienta de seguimiento de CVE de Ubuntu, que se usa como feed de vulnerabilidad en 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 en los resultados del análisis de CVE. Estos CVE ya se corrigen en las versiones de parche más recientes de Google Distributed Cloud.

    Consulta las notas de la versión para conocer las correcciones de CVE.


    Solución alternativa:

    Canonical está al tanto de este problema, y la corrección se rastrea en https://github.com/canonical/sec-cvescan/issues/73.
    Actualizaciones 1.10, 1.11, 1.12 y 1.13

    Si actualizas clústeres sin alta disponibilidad de la versión 1.9 a la 1.10, es posible que notes que kubectl exec, kubectl log y el webhook en los clústeres de usuario no están disponibles por un período breve. Este tiempo de inactividad puede durar hasta un minuto. Esto sucede porque kube-apiserver maneja la solicitud entrante (kubectl exec, kubectl log y webhook) para el clúster de usuario. El usuario kube-apiserver es un Statefulset. En un clúster sin alta disponibilidad, solo hay una réplica para el Statefulset. Por lo tanto, durante la actualización, existe la posibilidad de que el kube-apiserver antiguo no esté disponible mientras 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 tener un tiempo de inactividad más breve durante la actualización, te recomendamos cambiar a clústeres de HA.
    Instalación, actualizaciones 1.10, 1.11, 1.12 y 1.13

    Si creas o actualizas un clúster de HA y notas que la verificación de preparación de la conectividad falló en el diagnóstico de clústeres, en la mayoría de los casos no afectará la funcionalidad de Google Distributed Cloud (kubectl exec, kubectl log y webhook). Esto sucede porque, a veces, una o dos de las réplicas de conectividad pueden no estar listas durante un período debido a herramientas de 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.
    Redes 1.10, 1.11, 1.12 y 1.13

    Cuando implementas la versión 1.9 o posterior de Google Distributed Cloud, cuando la implementación tiene el balanceador de cargas en paquetes de Seesaw en un entorno que usa reglas de firewall distribuido con estado de NSX-T, stackdriver-operator podría no crear un ConfigMap gke-metrics-agent-conf y provocar que los Pods gke-connect-agent entren en un bucle de fallas.

    El problema subyacente es que las reglas de firewall distribuido con estado de NSX-T 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 porque Seesaw usa flujos de conexión asimétricos. Los problemas de integración con las reglas de firewall distribuido de NSX-T afectan a todas las versiones de Google Distributed Cloud 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 de más de 32,000.


    Solución alternativa:

    En la versión 1.13 de la documentación, sigue estas instrucciones para inhabilitar las reglas de firewall distribuido de NSX-T o usar reglas de firewall distribuido sin estado en las VMs de Seesaw.

    Si tus clústeres usan un balanceador de cargas manual, sigue estas instrucciones para configurar tu balanceador de cargas a fin de restablecer las conexiones de clientes cuando detecte una falla del 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 falla una instancia del servidor.
    Registro y supervisión 1.10, 1.11, 1.12, 1.13, 1.14 y 1.15

    En el caso de las versiones 1.10 a 1.15 de Google Distributed Cloud, algunos clientes observaron una facturación inesperadamente alta para Metrics volume en la página Facturación. Este problema te afecta solo cuando se aplican todas las siguientes circunstancias:

    • El registro y la supervisión de la aplicación están habilitados (enableStackdriverForApplications=true)
    • Los Pods de la aplicación tienen la anotación prometheus.io/scrap=true. (La instalación de Cloud 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 ves una facturación por métricas no deseadas con el prefijo de nombre external.googleapis.com/prometheus y también ves enableStackdriverForApplications establecido como verdadero en la respuesta de kubectl -n kube-system get stackdriver stackdriver -o yaml, entonces este problema se aplica a tu caso.


    Solución alternativa

    Si este problema te afecta, 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 depende 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 editarlo:

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

    Quita la línea enableStackdriverForApplications: true, guarda y cierra el editor.

    Si no puedes cambiar de la recopilación de métricas basada 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 Cloud Service Mesh agrega la anotación, considera configurar Cloud 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 y 1.13

    El instalador de Google Distributed Cloud puede fallar si los roles personalizados están vinculados a un nivel de permisos incorrecto.

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


    Solución alternativa:

    Si deseas vincular el rol personalizado en el nivel de DC (o inferior a la raíz), también debes vincular el rol de solo lectura al usuario en el nivel raíz de vCenter.

    Para obtener más información sobre la creación de roles, consulta privilegios de la cuenta de usuario de vCenter.
    Registro y supervisión 1.11, 1.12 y 1.13

    Si se usan métricas obsoletas en tus 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 se deben migrar 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, sigue estos pasos:

    1. Borra el “estado del nodo de GKE On-Prem” en el panel de Google Cloud Monitoring. Vuelve a instalar el “estado de los nodos 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 el “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 el “Estado de la VM de vSphere de GKE On-Prem” según estas instrucciones.

      4. Esta baja se debe a la actualización del agente kube-state-metrics de la versión 1.9 a la 2.4, que es obligatoria 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 y 1.13

    En el caso de Google Distributed Cloud versión 1.10 y versiones 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

    Entre otros tipos de métricas que pueden tener métricas de resumen irrelevantes, se incluyen los siguientes:

    :
    • 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 están en la lista de métricas, no son compatibles con gke-metrics-agent en este momento.
    Registro y supervisión 1.10, 1.11, 1.12 y 1.13

    Es posible que te 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]: Para aumentar la CPU de gke-metrics-agent, sigue los pasos del 1 al 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 stackdriver : 
      spec:
  resourceAttrOverride:
    gke-metrics-agent/gke-metrics-agent:
      limits:
        cpu: 100m
        memory: 4608Mi
      requests:
        cpu: 10m
        memory: 200Mi
       El recurso editado debería verse 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

    Si tu clúster de administrador se ve afectado por este problema, faltan las métricas del programador y del administrador de controladores. 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 la versión 1.11.3 o posterior, 1.12.1 o posterior, o 1.13 o posterior.
    1.11.0-1.11.2, 1.12.0

    Si tu clúster de usuario se ve afectado por este problema, faltan las métricas del programador y del administrador de controladores. 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 la versión 1.13.0 y posteriores de Google Distributed Cloud. Actualiza el clúster a una versión con la corrección.
    Instalación, actualizaciones 1.10, 1.11, 1.12 y 1.13

    Si creas un clúster de administrador para la versión 1.9.x o 1.10.0, y si el clúster de administrador no se registra con la especificación gkeConnect proporcionada durante su creación, recibirá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

    Aún podrás usar este clúster de administrador, pero recibirás el siguiente error si luego intentas actualizarlo 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:

    Si se produce este error, sigue estos pasos para solucionar el problema de registro del clúster. Después de realizar esta corrección, puedes actualizar tu clúster de administrador.

    1. Ejecuta gkectl update admin para registrar el clúster de administrador con la clave de cuenta de servicio correcta.
    2. Crea una cuenta de servicio dedicada para aplicar parches al recurso personalizado OnPremAdminCluster. 
      export KUBECONFIG=ADMIN_CLUSTER_KUBECONFIG

# Create Service Account modify-admin
kubectl apply -f - <<EOF
apiVersion: v1
kind: ServiceAccount
metadata:
  name: modify-admin
  namespace: kube-system
EOF

# Create ClusterRole
kubectl apply -f - <<EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  creationTimestamp: null
  name: modify-admin-role
rules:
- apiGroups:
  - "onprem.cluster.gke.io"
  resources:
  - "onpremadminclusters/status"
  verbs:
  - "patch"
EOF

# Create ClusterRoleBinding for binding the permissions to the modify-admin SA

kubectl apply -f - <<EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  creationTimestamp: null
  name: modify-admin-rolebinding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: modify-admin-role
subjects:
- kind: ServiceAccount
  name: modify-admin
  namespace: kube-system
EOF
       Reemplaza ADMIN_CLUSTER_KUBECONFIG por la ruta de acceso del archivo kubeconfig del clúster de administrador.
    3. Ejecuta estos comandos para actualizar el recurso personalizado OnPremAdminCluster. 
      export KUBECONFIG=ADMIN_CLUSTER_KUBECONFIG

SERVICE_ACCOUNT=modify-admin

SECRET=$(kubectl get serviceaccount ${SERVICE_ACCOUNT} \
    -n kube-system -o json \
    | jq -Mr '.secrets[].name | select(contains("token"))')

TOKEN=$(kubectl get secret ${SECRET} -n kube-system -o json \
    | jq -Mr '.data.token' | base64 -d)

kubectl get secret ${SECRET} -n kube-system -o json \
    | jq -Mr '.data["ca.crt"]' \
    | base64 -d > /tmp/ca.crt

APISERVER=https://$(kubectl -n default get endpoints kubernetes \
    --no-headers | awk '{ print $2 }')

# Find out the admin cluster name and gkeOnPremVersion from the OnPremAdminCluster CR
ADMIN_CLUSTER_NAME=$(kubectl get onpremadmincluster -n kube-system \
    --no-headers | awk '{ print $1 }')
GKE_ON_PREM_VERSION=$(kubectl get onpremadmincluster \
    -n kube-system $ADMIN_CLUSTER_NAME \
    -o=jsonpath='{.spec.gkeOnPremVersion}')

# Create the Status field and set the gkeOnPremVersion in OnPremAdminCluster CR
curl -H "Accept: application/json" \
    --header "Authorization: Bearer $TOKEN" -XPATCH \
    -H "Content-Type: application/merge-patch+json" \
    --cacert /tmp/ca.crt \
    --data '{"status": {"gkeOnPremVersion": "'$GKE_ON_PREM_VERSION'"}}' \
    $APISERVER/apis/onprem.cluster.gke.io/v1alpha1/namespaces/kube-system/onpremadminclusters/$ADMIN_CLUSTER_NAME/status
    4. Intenta actualizar el clúster de administrador de nuevo con la marca --disable-upgrade-from-checkpoint. 
      gkectl upgrade admin --config ADMIN_CLUSTER_CONFIG \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --disable-upgrade-from-checkpoint
       Reemplaza ADMIN_CLUSTER_CONFIG por la ruta de acceso del archivo de configuración del clúster de administrador.
    Identidad 1.10, 1.11, 1.12 y 1.13

    Si usas la función 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 tienes este problema con un clúster existente, puedes realizar una de las siguientes acciones:

    • Inhabilita GKE Identity Service. Si inhabilitas GKE Identity Service, no se quitará el objeto binario de GKE Identity Service implementado ni el 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 y 1.13

    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 es inhabilitar el aprendizaje de IP agregando la dirección IP de Seesaw como una IP virtual de L4-L7 en el controlador de infraestructura de política de aplicación (APIC) de Cisco.

    Para configurar la opción de IP virtual de L4-L7, ve a Usuario > Perfiles de aplicaciones > EPG de aplicación o EPG de uSeg. Si no se inhabilita el aprendizaje de IP, el extremo de IP oscilará entre diferentes ubicaciones en la estructura de la API de Cisco.
    VMware 1.10, 1.11, 1.12 y 1.13

    Recientemente, VMware identificó problemas críticos con las siguientes versiones de vSphere 7.0 Update 3:

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

    Solución alternativa:

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

    En el caso de 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 recibirás 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:

    Aplica un recurso de DaemonSet, por ejemplo:

    apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fix-cos-noexec
  namespace: kube-system
spec:
  selector:
    matchLabels:
      app: fix-cos-noexec
  template:
    metadata:
      labels:
        app: fix-cos-noexec
    spec:
      hostIPC: true
      hostPID: true
      containers:
      - name: fix-cos-noexec
        image: ubuntu
        command: ["chroot", "/host", "bash", "-c"]
        args:
        - |
          set -ex
          while true; do
            if ! $(nsenter -a -t 1 findmnt -l | grep -qe "^/var/lib/kubelet\s"); then
              echo "remounting /var/lib/kubelet with exec"
              nsenter -a -t 1 mount --bind /var/lib/kubelet /var/lib/kubelet
              nsenter -a -t 1 mount -o remount,exec /var/lib/kubelet
            fi
            sleep 3600
          done
        volumeMounts:
        - name: host
          mountPath: /host
        securityContext:
          privileged: true
      volumes:
      - name: host
        hostPath:
          path: /
    Actualizaciones 1.10, 1.11, 1.12 y 1.13

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


    Solución alternativa:

    Quita 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 la máquina del grupo de nodos correspondiente.
    Registro y supervisión 1.11, 1.12 y 1.13

    A partir de la versión 1.11, en los paneles de supervisión listos para usar, el panel de estado de los Pods 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

    En el caso de Google Distributed Cloud versión 1.10, 1.11 y 1.12, es posible que el DaemonSet stackdriver-log-forwarder tenga errores CrashLoopBackOff cuando haya registros con búfer dañados en el disco.


    Solución alternativa:

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

    1. Para evitar el 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 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 haya limpiado todos los fragmentos, puedes ejecutar los siguientes comandos. El resultado de los dos comandos debe ser igual al número de nodo 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 y 1.16

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

    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 tasa de entrada de registros supere el límite del agente de registro, lo que hace que stackdriver-log-forwarder no envíe registros. Este problema ocurre en todas las versiones de Google Distributed Cloud.

    Solución alternativa:

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

    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 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 debería verse 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

    Hay un período breve en el que el nodo está listo, pero el certificado del servidor de kubelet no está listo. kubectl exec y kubectl logs no están disponibles durante estas decenas de segundos. Esto se debe a que el nuevo validador de certificados del servidor tarda un tiempo en ver las IP válidas actualizadas del nodo.

    Este problema solo afecta al certificado del servidor de Kubelet, no afectará la programación de pods.
    Actualizaciones 1.12

    No se pudo actualizar el clúster de usuario con el siguiente error:

    .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 se actualizó por completo, y la versión de estado sigue siendo 1.10. Ninguna verificación previa bloqueará la actualización del clúster de usuarios a la versión 1.12, y fallará con el problema de sesgo de versión.


    Solución alternativa:

    Completa el proceso para actualizar primero el clúster de administrador a la versión 1.11 y, luego, actualizar 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

    El comando gkectl diagnose cluster falló con lo siguiente: 

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

    La validación del espacio libre de Datastore no debe usarse para los grupos de nodos de clústeres existentes y se agregó en gkectl diagnose cluster por error.


    Solución alternativa:

    Puedes ignorar el mensaje de error o omitir la validación con --skip-validation-infra.
    Operaciones, herramientas de redes 1.11, 1.12.0-1.12.1

    Es posible que no puedas agregar un clúster de usuario nuevo si tu clúster de administrador está configurado con una configuración de balanceador de cargas MetalLB.

    Es posible que el proceso de eliminación del clúster de usuarios se bloquee por algún motivo, lo que provocará que se invalide el ConfigMap de MetalLB. No será posible agregar un clúster de usuarios nuevo en este estado.


    Solución alternativa:

    Puedes borrar de forma forzosa tu clúster de usuarios.
    Instalación, sistema operativo 1.10, 1.11, 1.12 y 1.13

    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 usuarios, fallaría en lo siguiente: 

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

    La VM de prueba creada para el clúster de usuario check-config usa, de forma predeterminada, el mismo osImageType del clúster de administrador y, actualmente, 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

    Este problema afecta a los clientes que usan Grafana en el clúster de administrador para supervisar clústeres de usuario en las versiones 1.12.0 y 1.12.1 de Google Distributed Cloud. Se produce por una discrepancia entre los certificados de pushprox-client en los clústeres de usuario y la lista de entidades permitidas en el servidor pushprox del clúster de administrador. El síntoma es que pushprox-client en los clústeres de usuarios imprime registros de errores como el siguiente:

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

    Solución alternativa:

    sigue estos pasos:

    1. Reduce la implementación del operador de supervisión en el espacio de nombres de kube-system del clúster de administrador. 
      kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --namespace kube-system scale deploy monitoring-operator \
    --replicas=0
    2. Edita el ConfigMap pushprox-server-rbac-proxy-config en el espacio de nombres de kube-system del clúster de administrador. 
      kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --namespace kube-system edit cm pushprox-server-rbac-proxy-config
       Busca la línea principals para el objeto de escucha external-pushprox-server-auth-proxy y corrige el principal_name para todos los clústeres de usuario quitando la substring kube-system de pushprox-client.metrics-consumers.kube-system.cluster.. La configuración nueva debería verse de la siguiente manera: 
      permissions:
- or_rules:
    rules:
    - header: { name: ":path", exact_match: "/poll" }
    - header: { name: ":path", exact_match: "/push" }
principals: [{"authenticated":{"principal_name":{"exact":"pushprox-client.metrics-consumers.kube-system.cluster.local"}}},{"authenticated":{"principal_name":{"exact":"pushprox-client.metrics-consumers.kube-system.cluster."}}},{"authenticated":{"principal_name":{"exact":"pushprox-client.metrics-consumers.cluster."}}}]
    3. Reinicia la implementación de pushprox-server en el clúster de administrador y la implementación de pushprox-client en los clústeres de usuarios afectados: 
      kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG --namespace kube-system rollout restart deploy pushprox-server
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG --namespace kube-system rollout restart deploy pushprox-client
    4. Los pasos anteriores deberían resolver el problema. Una vez que el clúster se actualice a la versión 1.12.2 y versiones posteriores, en la que se solucione el problema, escala el operador de supervisión de kube-system del clúster de administrador para que pueda volver a administrar la canalización. 
      kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG --namespace kube-system scale deploy monitoring-operator --replicas=1
    Registro y supervisión 1.11, 1.12, 1.13, 1.14, 1.15 y 1.16

    Los registros de auditoría de Cloud necesitan una configuración de permisos especial que, en la actualidad, solo se realiza automáticamente 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 de proyecto y la misma cuenta de servicio con el clúster de administrador para los registros de auditoría de Cloud, de manera que el clúster de administrador tenga el permiso requerido.

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

    Solución alternativa:

    Para resolver este problema, interactúa con la función cloudauditlogging de Hub a fin de configurar el permiso:

    1. Primero, verifica las cuentas de servicio existentes permitidas para los registros de auditoría de Cloud en tu proyecto: 
      curl -H "Authorization: Bearer $(gcloud auth print-access-token)" \
    https://gkehub.googleapis.com/v1alpha/projects/PROJECT_ID/locations/global/features/cloudauditlogging
    2. Según la respuesta, realiza una de las siguientes acciones:
      • Si recibiste un error 404 Not_found, significa que no hay una cuenta de servicio incluida en la lista de entidades permitidas para este ID del proyecto. Para incluir una cuenta de servicio en la lista de entidades permitidas, habilita la función cloudauditlogging de Hub: 
        curl -X POST -H "Authorization: Bearer $(gcloud auth print-access-token)" \
    -H "Content-Type: application/json" \
    https://gkehub.googleapis.com/v1alpha/projects/PROJECT_ID/locations/global/features?feature_id=cloudauditlogging -d \
    '{"spec":{"cloudauditlogging":{"allowlistedServiceAccounts":["SERVICE_ACCOUNT_EMAIL"]}}}'
      • Si recibiste una especificación de función que contiene "lifecycleState": "ENABLED" con "code": "OK" y una lista de cuentas de servicio en allowlistedServiceAccounts, significa que hay cuentas de servicio existentes permitidas para este proyecto. Puedes usar una cuenta de servicio de esta lista en tu clúster o agregar una cuenta de servicio nueva a la lista de entidades permitidas: 
        curl -X PATCH -H "Authorization: Bearer $(gcloud auth print-access-token)" \
    -H "Content-Type: application/json" \
    https://gkehub.googleapis.com/v1alpha/projects/PROJECT_ID/locations/global/features/cloudauditlogging?update_mask=spec.cloudauditlogging.allowlistedServiceAccounts -d \
    '{"spec":{"cloudauditlogging":{"allowlistedServiceAccounts":["SERVICE_ACCOUNT_EMAIL"]}}}'
      • Si recibiste una especificación de función que contiene "lifecycleState": "ENABLED" con "code": "FAILED", significa que la configuración de permisos no se realizó correctamente. Intenta solucionar los problemas en el campo description de la respuesta o crea una copia de seguridad de la lista de anunciantes permitidos actuales, borra la función de Hub cloudauditlogging y vuelve a habilitarla siguiendo el paso 1 de esta sección otra vez. Para borrar la función cloudauditlogging de Hub, haz lo siguiente: 
        curl -X DELETE -H "Authorization: Bearer $(gcloud auth print-access-token)" \
    https://gkehub.googleapis.com/v1alpha/projects/PROJECT_ID/locations/global/features/cloudauditlogging

    En los comandos anteriores:
    Sistema operativo 1.8, 1.9, 1.10, 1.11, 1.12 y 1.13

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

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

    A partir de la versión 1.8 de Google Distributed Cloud, la imagen de Ubuntu se endurece con la comparativa de nivel 2 de CIS. Además, una de las reglas de cumplimiento, “4.1.2.2 Ensure audit logs are not automatically deleted”, garantiza la configuración de auditd max_log_file_action = keep_logs. Esto hace que todas las reglas de auditoría se conserven en el disco.


    Solución alternativa:

    Estación de trabajo de administrador

    En la estación de trabajo del administrador, puedes cambiar manualmente la configuración de auditd para rotar los registros automáticamente y, luego, reiniciar el servicio auditd:

    sed -i 's/max_log_file_action = keep_logs/max_log_file_action = rotate/g' /etc/audit/auditd.conf
sed -i 's/num_logs = .*/num_logs = 250/g' /etc/audit/auditd.conf
systemctl restart auditd

    La configuración anterior haría que auditd rote automáticamente sus registros una vez que haya generado más de 250 archivos (cada uno con un tamaño de 8 M).

    Nodos del clúster

    En el caso de los nodos del clúster, actualiza a la versión 1.11.5 o posterior, 1.12.4 o posterior, 1.13.2 o posterior o 1.14 o posterior. Si aún no puedes actualizar a esas versiones, aplica el siguiente DaemonSet a tu clúster:

    apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: change-auditd-log-action
  namespace: kube-system
spec:
  selector:
    matchLabels:
      app: change-auditd-log-action
  template:
    metadata:
      labels:
        app: change-auditd-log-action
    spec:
      hostIPC: true
      hostPID: true
      containers:
      - name: update-audit-rule
        image: ubuntu
        command: ["chroot", "/host", "bash", "-c"]
        args:
        - |
          while true; do
            if $(grep -q "max_log_file_action = keep_logs" /etc/audit/auditd.conf); then
              echo "updating auditd max_log_file_action to rotate with a max of 250 files"
              sed -i 's/max_log_file_action = keep_logs/max_log_file_action = rotate/g' /etc/audit/auditd.conf
              sed -i 's/num_logs = .*/num_logs = 250/g' /etc/audit/auditd.conf
              echo "restarting auditd"
              systemctl restart auditd
            else
              echo "auditd setting is expected, skip update"
            fi
            sleep 600
          done
        volumeMounts:
        - name: host
          mountPath: /host
        securityContext:
          privileged: true
      volumes:
      - name: host
        hostPath:
          path: /

    Ten en cuenta que realizar este cambio de configuración de auditd infringiría la regla del nivel 2 de CIS “4.1.2.2 Ensure audit logs are not automatically deleted”.
    Redes 1.10, 1.11.0-1.11.3, 1.12.0-1.12.2, 1.13.0

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

    [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, kubelet puede vincularse erróneamente a una dirección IP flotante asignada al nodo y, luego, informarla como una dirección de nodo en node.status.addresses. El webhook de validación verifica las direcciones IP flotantes NetworkGatewayGroup en comparación con todas las 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 del webhook y ciérrala para aplicar los cambios.
    4. Crea o edita tu objeto NetworkGatewayGroup.
    5. Vuelve a aplicar la configuración original del webhook: 
      kubectl -n kube-system apply -f webhook-config.yaml
    Redes Todas las versiones anteriores a 1.14.7, 1.15.0-1.15.3 y 1.16.0

    El GARP periódico (ARP injustificado) que envía Seesaw cada 20 s no establece la IP de destino en el encabezado ARP. Es posible que algunas redes no acepten esos paquetes (como Cisco ACI). Puede provocar un tiempo de inactividad del servicio más prolongado después de que se recupere un cerebro dividido (debido a la pérdida de paquetes de VRRP).

    Solución alternativa:

    Ejecuta sudo seesaw -c failover en cualquiera de las VMs de Seesaw para activar una conmutación por error de Seesaw. Esto debería restablecer el tráfico.
    Sistema operativo 1.16, 1.28.0-1.28.200

    Se configuró "staticPodPath" por error 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.