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á dirigida a administradores y operadores de TI que gestionan 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 (SLOs) o las aplicaciones fallan. Para obtener más información sobre los roles habituales y las tareas de ejemplo a las que hacemos referencia en el contenido, consulta Roles y tareas habituales de los usuarios de GKE. Google Cloud

Si formas parte del Programa para Desarrolladores de Google, guarda esta página para recibir notificaciones cuando se publiquen notas de la versión relacionadas con ella. Para obtener más información, consulta el artículo Páginas guardadas.

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

Selecciona tu versión de Google Distributed Cloud:

Seleccione la categoría del problema:

También puedes buscar tu problema:

Categoría Versión(es) identificada(s) Problema y solución alternativa
Actualizaciones 1.32.0-1.32.600, 1.33.0-1.33.100

Si usas gkectl update para actualizar un clúster de usuarios que no es de alta disponibilidad (no HA) a un clúster avanzado con un plano de control de alta disponibilidad, se produce un error y se muestra el siguiente mensaje:

Failed to generate diff summary: failed to get desired onprem user cluster and node pools from seed config with dry-run webhooks:
failed to apply validating webhook to OnPremUserCluster:
masterNode.replcias: Forbidden: the field must not be mutated, diff (-before, +after): int64(- 1,+ 3)

Solución alternativa:

Usa el comando gkectl upgrade para actualizar el clúster de usuarios no de alta disponibilidad a un clúster avanzado de alta disponibilidad.
Actualizaciones 1.30 y 1.31

Los pods de Windows permanecen en estado Pending después de la migración a ControlPlaneV2 debido a un certificado TLS no válido

Durante una operación de actualización de Google Distributed Cloud que incluya una migración de ControlPlaneV2 de la versión 1.30.x a la 1.31.x, es posible que no se puedan programar los pods de Windows y que permanezcan en el estado Pending. Este problema se manifiesta como un error de validación del certificado TLS del webhook de admisión de mutación windows-webhook. El problema se produce porque el nombre alternativo del sujeto (SAN) del certificado conserva incorrectamente un valor válido para la antigua arquitectura de Kubeception en lugar de regenerarse para el nuevo endpoint kube-system.svc.

Es posible que veas el siguiente mensaje de error: failed calling webhook "windows.webhooks.gke.io": failed to call webhook: Post "https://windows-webhook.kube-system.svc:443/pod?timeout=10s": tls: failed to verify certificate: x509. Esta situación puede producirse si el proceso de migración de ControlPlaneV2 copia el contenido de etcd, lo que provoca que se transfiera el certificado antiguo sin que se regenere correctamente. Es importante tener en cuenta que los grupos de nodos de Windows son una función obsoleta y no estarán disponibles en Google Distributed Cloud 1.33 ni en versiones posteriores.

Solución alternativa:

  1. Copia de seguridad del secreto user-component-options en el espacio de nombres del clúster del usuario:

        kubectl get secret user-component-options -n USER_CLUSTER_NAME -oyaml > backup.yaml

  2. Elimina el secreto user-component-options:

        kubectl delete secret user-component-options -n USER_CLUSTER_NAME

  3. Edita el recurso onpremusercluster para activar la conciliación añadiendo la anotación onprem.cluster.gke.io/reconcile: "true":

        kubectl edit onpremusercluster USER_CLUSTER_NAME -n USER_CLUSTER_MGMT_NAMESPACE

Sustituye USER_CLUSTER_NAME por el nombre de tu clúster de usuario.
Mejoras y actualizaciones 1.32.0-1.32.500, 1.33.0

La actualización a un clúster avanzado falla si stackdriver no está configurado

Al actualizar un clúster no avanzado a un clúster avanzado, es posible que el proceso deje de responder si stackdriver no está habilitado.

Solución alternativa:

  • Si el clúster aún no se ha actualizado, debes seguir los pasos para habilitar stackdriver:
    1. Añade la sección stackdriver a tu archivo de configuración del clúster.
    2. Ejecuta gkectl update para habilitar stackdriver.
  • Si ya se está llevando a cabo una actualización, sigue estos pasos:
    1. Edita el secreto user-cluster-creds en el espacio de nombres USER_CLUSTER_NAME-gke-onprem-mgmt con el siguiente comando: 
      kubectl --kubeconfig ADMIN_KUBECONFIG \
  patch secret user-cluster-creds \
  -n USER_CLUSTER_NAME-gke-onprem-mgmt \
  --type merge -p "{\"data\":{\"stackdriver-service-account-key\":\"$(cat STACKDRIVER_SERVICE_ACCOUNT_KEY_FILE | base64 | tr -d '\n')\"}}"
    2. Actualiza el recurso personalizado OnPremUserCluster con el campo stackdriver. Debes usar el mismo proyecto con la misma ubicación del proyecto y la misma clave de cuenta de servicio que cloudauditlogging si has habilitado la función. 
      kubectl --kubeconfig ADMIN_KUBECONFIG \
    patch onpremusercluster USER_CLUSTER_NAME \
    -n USER_CLUSTER_NAME-gke-onprem-mgmt --type merge -p '
    spec:
      stackdriver:
        clusterLocation: PROJECT_LOCATION
        providerID: PROJECT_ID
        serviceAccountKey:
          kubernetesSecret:
            keyName: stackdriver-service-account-key
            name: user-cluster-creds
'
    3. Añade la sección stackdriver al archivo de configuración del clúster para mantener la coherencia.
Actualizaciones 1.29, 1.30, 1.31, 1.32 y versiones posteriores

Los pods no pueden conectarse al servidor de la API de Kubernetes con Dataplane V2 y políticas de red restrictivas

En los clústeres que usan la arquitectura de la versión 2 del plano de control (CPv2), que es la predeterminada en la versión 1.29 y posteriores, y la versión 2 del plano de datos, es posible que los pods no puedan conectarse al servidor de la API de Kubernetes (kubernetes.default.svc.cluster.local). Este problema suele deberse a la presencia de políticas de red, especialmente las que tienen reglas de denegación de salida predeterminadas. Entre los síntomas se incluyen los siguientes:

  • Los intentos de conexión TCP a la dirección IP del clúster o a las direcciones IP del nodo del servidor de la API dan como resultado un mensaje Connection reset by peer.
  • Errores de handshake de TLS al conectarse al servidor de la API.
  • Al ejecutar el comando cilium monitor -t drop en el nodo afectado, se pueden ver los paquetes destinados a las direcciones IP del nodo del plano de control y al puerto del servidor de la API (normalmente, 6443) que se han descartado.

Causa

Este problema surge de una interacción entre Dataplane V2 (basado en Cilium) y las políticas de red de Kubernetes en la arquitectura de CPv2, donde los componentes del plano de control se ejecutan en nodos del clúster de usuario. La configuración predeterminada de Cilium no interpreta correctamente las reglas ipBlock de las políticas de red que están diseñadas para permitir el tráfico a las IPs de los nodos de los miembros del plano de control. Este problema está relacionado con un problema de Cilium upstream (cilium#20550).

Solución alternativa:

En las versiones 1.29, 1.30 y 1.31, evita usar políticas de red de salida restrictivas que puedan bloquear el tráfico a los nodos del plano de control. Si necesitas una política de denegación predeterminada, puede que tengas que añadir una regla de permiso general para todo el tráfico de salida. Por ejemplo, no especifiques ninguna regla "to" en la sección de salida para permitir todo el tráfico de salida. Esta solución es menos segura y puede que no sea adecuada para todos los entornos.

En el resto de las versiones, habilita una configuración de Cilium para que las IPs de los nodos coincidan correctamente con los campos ipBlock de la política de red. Para que coincidan las IPs de los nodos en los campos de ipBlockPolítica de red, haz lo siguiente:

  1. Edita el cilium-config ConfigMap: 
    kubectl edit configmap -n kube-system cilium-config
  2. Añade o modifica la sección de datos para incluir policy-cidr-match-mode: nodes: 
    data:
      policy-cidr-match-mode: nodes
  3. Para aplicar el cambio de configuración, reinicia el DaemonSet anetd: 
    kubectl rollout restart ds anetd -n kube-system
  4. Asegúrate de tener una política de red que permita explícitamente el tráfico de salida de tus pods a las IPs de los nodos del plano de control en el puerto del servidor de la API. Identifica las direcciones IP de los nodos del plano de control del clúster de usuario ejecutando kubectl get svc kubernetes. La salida es similar a la siguiente: 
        apiVersion: networking.k8s.io/v1
    kind: NetworkPolicy
    metadata:
      name: allow-egress-to-kube-apiserver
      namespace: NAMESPACE_NAME
    spec:
      podSelector: {} 
      policyTypes:
      - Egress
      egress:
      - to:
        - ipBlock:
            cidr: CP_NODE_IP_1/32
        - ipBlock:
            cidr: CP_NODE_IP_2/32
        ports:
        - protocol: TCP
          port: 6443 # Kubernetes API Server port on the node
Instalación 1.30.200-gke.101

El pod del agente gke-connect se queda en estado Pending durante la creación del clúster de usuarios

Durante la creación del clúster de usuarios, el pod del agente gke-connect puede quedarse bloqueado en el estado Pending, lo que impide que el clúster se cree por completo. Este problema se produce porque el pod del agente gke-connect intenta programarse antes de que los nodos de trabajo estén disponibles, lo que provoca un bloqueo.

Este problema se produce cuando falla la creación inicial del clúster de usuario debido a errores de validación previa al vuelo y se hace un intento posterior de crear el clúster sin eliminar primero los recursos creados parcialmente. En el siguiente intento de creación del clúster, el pod del agente gke-connect se bloquea debido a taints no tolerados en los nodos del plano de control, tal como se indica en un error similar al siguiente:

    0/3 nodes are available: 3 node(s) had untolerated taint {node-role.kubernetes.io/control-plane: }`.

Solución alternativa:

Si no se puede crear un clúster de usuario debido a errores de validación previa, elimina los recursos del clúster que se hayan creado parcialmente antes de intentar crear el clúster de nuevo con las configuraciones corregidas. De esta forma, se asegura de que el flujo de trabajo de creación se lleve a cabo correctamente, incluida la creación de grupos de nodos, antes de que se implemente el pod del agente gke-connect.
Actualizar 1.16 y versiones anteriores, 1.28.0-1.28.1100, 1.29.0-1.29.700 y 1.30.0-1.30.200

Después de inhabilitar el encriptado de secretos siempre activo con gkectl update cluster, los secretos se siguen almacenando en etcd con encriptado. Este problema solo se aplica a los clústeres de usuario de kubeception. Si tu clúster usa Controlplane V2, no te afecta este problema.

Para comprobar si los secretos siguen cifrados, ejecuta el siguiente comando, que recupera el secreto default/private-registry-creds almacenado en etcd:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    exec -it -n USER_CLUSTER_NAME kube-etcd-0 -c kube-etcd -- \
    /bin/sh -ec "export ETCDCTL_API=3; etcdctl \
    --endpoints=https://127.0.0.1:2379 \
    --cacert=/etcd.local.config/certificates/etcdCA.crt \
    --cert=/etcd.local.config/certificates/etcd.crt \
    --key=/etcd.local.config/certificates/etcd.key \
    get /registry/secrets/default/private-registry-creds" | hexdump -C

Si el secreto se almacena con cifrado, el resultado será el siguiente:

00000000  2f 72 65 67 69 73 74 72  79 2f 73 65 63 72 65 74  |/registry/secret|
00000010  73 2f 64 65 66 61 75 6c  74 2f 70 72 69 76 61 74  |s/default/privat|
00000020  65 2d 72 65 67 69 73 74  72 79 2d 63 72 65 64 73  |e-registry-creds|
00000030  0d 0a 6b 38 73 3a 65 6e  63 3a 6b 6d 73 3a 76 31  |..k8s:enc:kms:v1|
00000040  3a 67 65 6e 65 72 61 74  65 64 2d 6b 65 79 2d 6b  |:generated-key-k|
00000050  6d 73 2d 70 6c 75 67 69  6e 2d 31 3a 00 89 65 79  |ms-plugin-1:..ey|
00000060  4a 68 62 47 63 69 4f 69  4a 6b 61 58 49 69 4c 43  |JhbGciOiJkaXIiLC|
...

Si la clave secreta no se almacena con cifrado, el resultado será similar al siguiente:

00000000  2f 72 65 67 69 73 74 72  79 2f 73 65 63 72 65 74  |/registry/secret|
00000010  73 2f 64 65 66 61 75 6c  74 2f 70 72 69 76 61 74  |s/default/privat|
00000020  65 2d 72 65 67 69 73 74  72 79 2d 63 72 65 64 73  |e-registry-creds|
00000030  0d 0a 6b 38 73 00 0d 0a  0c 0d 0a 02 76 31 12 06  |..k8s.......v1..|
00000040  53 65 63 72 65 74 12 83  47 0d 0a b0 2d 0d 0a 16  |Secret..G...-...|
00000050  70 72 69 76 61 74 65 2d  72 65 67 69 73 74 72 79  |private-registry|
00000060  2d 63 72 65 64 73 12 00  1a 07 64 65 66 61 75 6c  |-creds....defaul|
...

Solución alternativa:

  1. Para hacer una actualización continua de un DaemonSet específico, sigue estos pasos: 
        kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
      rollout restart statefulsets kube-apiserver \
      -n USER_CLUSTER_NAME
  2. Obtén los manifiestos de todos los secretos del clúster de usuario en formato YAML: 
        kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
      get secrets -A -o yaml > SECRETS_MANIFEST.yaml
  3. Vuelve a aplicar todos los secretos del clúster de usuario para que se almacenen en etcd como texto sin formato: 
        kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
      apply -f SECRETS_MANIFEST.yaml

Configuración 1.29, 1.30 y 1.31

En el archivo de configuración del clúster de usuarios, user-cluster.yaml, generado por el comando gkectl get-config, falta el campo hostgroups en la sección nodePools. El comando gkectl get-config genera el archivo user-cluster.yaml a partir del contenido del recurso personalizado OnPremUserCluster. Sin embargo, el campo nodePools[i].vsphere.hostgroups existe en el recurso personalizado OnPremNodePool y no se copia en el archivo user-cluster.yaml cuando ejecutas gkectl get-config.

Solución

Para solucionar este problema, añada manualmente el campo nodePools[i].vsphere.hostgroups al archivo user-cluster.yaml. El archivo editado debería ser similar al siguiente ejemplo:

apiVersion: v1
kind: UserCluster
...
nodePools:
- name: "worker-pool-1"
  enableLoadBalancer: true
  replicas: 3
  vsphere:
    hostgroups:
    - "hostgroup-1"
...

Puedes usar el archivo de configuración de clúster de usuarios editado para actualizar tu clúster de usuarios sin que se produzcan errores y el campo hostgroups se conserva.
Redes 1.29.0-1.29.1000 1.30.0-1.30.500, 1.31.0-1.31.100

Los pods de Istiod del ingress empaquetado no pueden estar listos si se instalan recursos gateway.networking.k8s.io en el clúster de usuario. El siguiente mensaje de error se puede encontrar en los registros de pods:

    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 los siguientes ClusterRole y ClusterRoleBinding a tu clúster de usuario: 

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 del 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úsculas.
Instalación y actualizaciones 1.30.0-1.30.500, 1.31.0-1.31.100

Runtime: out of memory "error" después de ejecutar gkeadm create o upgrade

Al crear o actualizar estaciones de trabajo de administrador con comandos gkeadm, , es posible que se produzca un error de falta de memoria al verificar 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 bloquea en Creating or updating cluster control plane workloads

    Al actualizar un clúster de administrador que no es de alta disponibilidad, la actualización puede quedarse bloqueada en el paso Creating or updating cluster control plane workloads.

    Este problema se produce si, en la VM maestra de administrador, ip a | grep cali devuelve 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 clúster maestro de administrador: 
      gkectl repair admin-master --kubeconfig=ADMIN_KUBECONFIG \
    --config=ADMIN_CONFIG_FILE \
    --skip-validation
    2. Selecciona la plantilla de VM 1.30 si ves una petición como la del siguiente ejemplo: 
      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 de clúster generados por gkectl create-config en la versión 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 del archivo de configuración sin problemas.

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

    Al migrar un clúster de administrador que no es de alta disponibilidad y que usa MetalLB a alta disponibilidad, es posible que los nodos del complemento de administrador se queden en el 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 altavoces de MetalLB siguen usando el antiguo secreto metallb-memberlist. Como resultado de la condición de carrera, la antigua IP virtual del plano de control deja de ser accesible, lo que provoca que la migración se detenga.

    Solución alternativa:

    1. Elimina el secreto metallb-memberlist: 
      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. Comprueba que se haya generado 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 algunos 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 recoger la nueva lista de miembros: 
      kubectl --kubeconfig=ADMIN_KUBECONFIG -n kube-system \
    rollout restart daemonset metallb-speaker

      Al cabo de unos minutos, los nodos del complemento de administrador vuelven a estar Ready y la migración puede continuar.

    6. Si el comando gkectl inicial ha agotado el tiempo de espera después de más de 3 horas, vuelve a ejecutar gkectl update para reanudar la migración fallida.
    Configuración y funcionamiento 1.12+, 1.13+, 1.14+, 1.15+, 1.16+, 1.28+, 1.29+, 1.30+

    La copia de seguridad del clúster de un clúster de administrador que no es de alta disponibilidad falla debido a que los nombres del almacén de datos y del disco de datos son demasiado largos

    Al intentar crear una copia de seguridad de un clúster de administrador que no es de alta disponibilidad, se produce un error porque la longitud combinada de los nombres del almacén de datos y del disco de datos supera la longitud máxima de caracteres.

    La longitud máxima de un nombre de almacén de datos es de 80 caracteres.
    La ruta de copia de seguridad de un clúster de administrador que no es de alta disponibilidad tiene la sintaxis de nomenclatura "__". 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 por 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 de administrador muestre una versión anterior a la esperada.

    Este problema se produce porque la plantilla de VM de copia de seguridad que se usa para reparar el nodo de plano de control de administrador de alta disponibilidad 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. Averigua el nombre del equipo 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 eliminar la máquina: 
          kubectl delete machine MACHINE_NAME --kubeconfig=ADMIN_KUBECONFIG

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

    Al actualizar un clúster de usuario o un grupo de nodos con Terraform, es posible que Terraform intente asignar valores vacíos a los campos vCenter.

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

    Solución alternativa:

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

    1. Ejecutar terraform plan
    2. En la salida, comprueba si los campos vCenter están configurados como nil.
    3. Si algún campo vCenter tiene un valor vacío, en la configuración de Terraform, añade vcenter a la lista ignore_changes siguiendo la documentación de Terraform. De esta forma, no se podrán actualizar estos campos.
    4. Vuelve a ejecutar terraform plan y comprueba el resultado para confirmar que la actualización es la esperada.
    Actualizaciones 1.13, 1.14, 1.15, 1.16

    Una vez que se hayan creado, actualizado o actualizado a una versión superior los nodos del plano de control de los clústeres de usuario de kubeception, se reiniciarán uno a uno durante la primera operación del clúster de administrador, cuando este se cree o se actualice a una de las versiones afectadas. En los clústeres de kubeception con 3 nodos de plano de control, esto no debería provocar un tiempo de inactividad del plano de control y el único impacto es que la operación del clúster de administrador tarda más.

    Instalación, actualizaciones y mejoras 1.31

    En la versión 1.31 de Google Distributed Cloud, es posible que se produzcan errores al intentar crear recursos personalizados, como clústeres (de todos los tipos) y cargas de trabajo. El problema se debe a un cambio radical introducido en Kubernetes 1.31 que impide que el campo caBundle de una definición de recurso personalizado 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 se solía definir con el valor provisional \n, ya que en versiones anteriores de Kubernetes el servidor de la API no permitía que el contenido del paquete de CA estuviera 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 ha corregido 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 (u otro valor no válido), puede que se produzca el siguiente error:

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

    Solución

    Si tiene una definición de recurso personalizada en la que caBundle tiene un valor no válido, puede quitar el campo caBundle por completo sin ningún problema. Debería solucionarse el problema.
    SO 1.31

    Al actualizar a la versión 1.31 un clúster que usa la imagen de sistema operativo Container-Optimized OS (COS), el comando cloud-init status falla aunque cloud-init se haya completado sin errores.

    Solución alternativa:

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

        systemctl show -p Result cloud-final.service

    Si el resultado es similar al siguiente, significa que cloud-init ha finalizado correctamente:

        Result=success
    Actualizaciones 1,28

    Al actualizar un clúster a la versión 1.28, el comando gkectl prepare falla al ejecutar las comprobaciones previas 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 del tamaño del disco de la estación de trabajo de administrador se ha aumentado de 50 GB a 100 GB.

    Solución alternativa:

    1. Restaurar 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 100 GB como mínimo.
    3. Actualiza la estación de trabajo de administrador.
    Actualizaciones 1.30

    El comando gkectl upgrade devuelve un error incorrecto sobre la clase de 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`.
    Identidad todas las versiones

    Después de rotar los certificados de la autoridad de certificación (CA) en un clúster de usuario, el campo spec.certificateAuthorityData del ClientConfig contiene un certificado de CA no válido, lo que impide la autenticación en el clúster.

    Solución alternativa:

    Antes de la siguiente autenticación de la CLI de gcloud, actualiza manualmente el campo spec.certificateAuthorityData del archivo ClientConfig con el certificado de AC correcto.

    1. Copia el certificado de AC del clúster del campo certificate-authority-data del archivo kubeconfig del clúster de administrador.
    2. Edita el ClientConfig y pega el certificado de la AC en el campo spec.certificateAuthorityData. 
          kubectl edit clientconfig default -n kube-public --kubeconfig USER_CLUSTER_KUBECONFIG
    Actualizaciones 1.28+

    Si inhabilitas el acceso de entrada agrupado quitando el campo loadBalancer.vips.ingressVIP del archivo de configuración del clúster, un error en la comprobación previa de MetalLB provocará que la actualización del clúster falle y se muestre el mensaje de error "invalid user ingress vip: invalid IP" (VIP de acceso de entrada de usuario no válido: IP no válida).

    Solución alternativa:

    Ignora el mensaje de error.
    Omita la comprobación previa con uno de los siguientes métodos:

    • Añade 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 queden bloqueados en la fase `Creating` y no se puedan vincular a los objetos de nodo debido a que falta una regla de grupo antiafinidad (AAG) en vCenter.

    Si describes los objetos de la máquina que dan problemas, puedes ver mensajes recurrentes como "Reconfigure DRS rule task "task-xxxx" complete" ("Reconfigurar la tarea de la regla DRS "tarea-xxxx" completada").

        kubectl --kubeconfig KUBECONFIG describe machine MACHINE_OBJECT_NAME

    Solución alternativa:

    Inhabilita el ajuste de grupo antiafinidad tanto en la configuración del clúster de administrador como en la configuración del clúster de usuario y activa el comando de actualización forzada 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

    Al migrar un clúster de usuario a Controlplane V2, si se ha habilitado alguna vez el cifrado de secretos siempre activo, el proceso de migración no gestiona correctamente la clave de cifrado de secretos. Debido a este problema, el nuevo clúster Controlplane V2 no puede descifrar secretos. Si la salida del siguiente comando no está vacía, significa que el cifrado de secretos siempre activo se ha habilitado en algún momento y que el clúster se ha visto 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 has iniciado la migración y esta falla, ponte en contacto con Google para obtener asistencia. De lo contrario, antes de la migración, inhabilita el cifrado de secretos siempre activo y descifra los secretos.

    Migración 1.29.0-1.29.600, 1.30.0-1.30.100

    Si el clúster de administración tiene habilitada la cifrado de secretos siempre activo en la versión 1.14 o anterior, y se ha actualizado desde versiones antiguas hasta las versiones 1.29 y 1.30 afectadas, al migrar el clúster de administración de no de alta disponibilidad a de alta disponibilidad, el proceso de migración no gestiona correctamente la clave de cifrado de secretos. Debido a este problema, el nuevo clúster de administración de alta disponibilidad no puede descifrar los secretos.

    Para comprobar si el clúster podría estar usando la clave con el formato antiguo, sigue estos pasos:

        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 en el siguiente ejemplo, significa que el clúster se verá afectado por este problema:

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

    Si ya has iniciado la migración y esta falla, ponte en contacto con Google para obtener asistencia.

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

    Al actualizar 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 ortográfico.

    La misma falta de ortografía de la clave privateRegistry también se encuentra en el archivo admin-cluster.yaml.
    Como el archivo credential.yaml se vuelve a generar durante el proceso de actualización del clúster de administrador, la errata sigue ahí aunque la hayas corregido antes.

    Solución alternativa:

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

    Al actualizar un clúster de usuarios, es posible que la operación de conciliación previa a la actualización tarde más que el tiempo de espera definido, lo que provocará un error en la actualización. El mensaje de error tiene este aspecto:

    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 de la operación de conciliación previa a la actualización es de 5 minutos más 1 minuto por cada grupo de nodos del clúster de usuario.

    Solución alternativa:

    Asegúrate de que el comando gkectl diagnose cluster se ejecute sin errores.
    Omite la operación de conciliación previa a la actualización añadiendo 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 ConfigMap. El DaemonSet anetd no detectará el cambio de configuración hasta que se reinicie, por lo que los cambios no se aplicarán.

    Solución alternativa:

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

    kubectl --kubeconfig USER_CLUSTER_KUBECONFIG rollout restart daemonset anetd

    Comprueba si el DaemonSet está listo después de reiniciar:

    kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get daemonset anetd

    En el resultado del comando anterior, comprueba 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 usuarios de la versión 1.16 a la 1.28, se crea una copia de seguridad del clúster de administradores. 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 usuarios se realiza correctamente y el clúster de administradores mantiene un estado correcto. El único problema es que no se ha creado una copia de seguridad del archivo de metadatos del clúster de administrador.

    El problema se debe a que el archivo binario etcdctl se añadió en la versión 1.28 y no está disponible en los nodos de la versión 1.16.

    La copia de seguridad del clúster de administrador implica varios pasos, como crear una instantánea de etcd y, a continuación, escribir el archivo de metadatos del clúster de administrador. La copia de seguridad de etcd se sigue realizando correctamente porque etcdctl se puede seguir activando después de ejecutar un comando en el pod de etcd. Sin embargo, la escritura del archivo de metadatos falla porque sigue dependiendo de que el archivo binario etcdctl esté instalado en el nodo. Sin embargo, la copia de seguridad del archivo de metadatos no impide que se cree una copia de seguridad, por lo que el proceso se completa correctamente, al igual que la actualización del clúster de usuario.

    Solución alternativa:

    Si quieres crear una copia de seguridad del archivo de metadatos, sigue los pasos de Crear y restaurar una copia de seguridad de un clúster de administrador 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

    Al crear un clúster de usuarios configurado para el balanceo de carga manual, se produce un error gkectl check-config que indica que el valor ingressHTTPNodePort debe ser al menos 30.000, incluso cuando el ingress agrupado está inhabilitado.

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

    Solución alternativa:

    Para solucionar este problema, ignore el resultado devuelto por gkectl check-config. Para inhabilitar la entrada agrupada, consulta Inhabilitar la entrada agrupada.
    Actualizaciones 1.29.0

    El problema con PodDisruptionBudget (PDB) se produce cuando se usan clústeres de administrador de alta disponibilidad y hay 0 o 1 nodo de clúster de administrador sin un rol después de la migración. Para comprobar si hay objetos de nodo 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, significa que PDB no está configurado incorrectamente.

    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 eliminar el PDB:

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

    En raras condiciones de carrera, una secuencia de instalación incorrecta del webhook de Autorización binaria y del pod gke-connect puede provocar que la creación del clúster de usuario se detenga porque un nodo no alcanza el estado preparado. En los casos afectados, la creación de clústeres de usuarios puede detenerse porque un nodo no alcanza el estado de preparado. 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. Elimina la configuración de 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 en mal estado durante el proceso de creación del clúster actual, elimina temporalmente la configuración del webhook de autorización binaria en el clúster de usuarios con el siguiente comando. 
              kubectl --kubeconfig USER_KUBECONFIG delete ValidatingWebhookConfiguration binauthz-validating-webhook-configuration
      Una vez que se haya completado el proceso de arranque, puedes volver a añadir 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 la actualización de un clúster de usuarios, la operación de actualización puede quedarse bloqueada si el objeto de máquina reflejado del clúster de usuarios contiene un deletionTimestamp. Si la actualización se queda bloqueada, se muestra el siguiente mensaje de error:

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

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

    Solución alternativa:

    1. Obtén el objeto de la máquina reflejada y guárdalo en un archivo local para hacer una copia de seguridad.
    2. Ejecuta el siguiente comando para eliminar el finalizador de la máquina reflejada y espera a que se elimine del clúster de usuario. 
          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 de plano de control del clúster de usuarios de Controlplane V2 para activar la reparación de nodos en los nodos de plano de control, de forma que la especificación de la máquina de origen correcta se vuelva a sincronizar en el clúster de usuarios.
    4. Vuelve a ejecutar gkectl upgrade cluster para reanudar la actualización
    Configuración, instalación 1.15, 1.16, 1.28 y 1.29

    En el caso de los clústeres de administrador de alta disponibilidad o los clústeres de usuario de ControlPlane V2, el VIP del plano de control debe estar en la misma subred que los demás nodos del clúster. De lo contrario, se producirá un error al crear el clúster porque kubelet no podrá comunicarse con el servidor de la API mediante el VIP del plano de control.

    Solución alternativa:

    Antes de crear el clúster, asegúrate de que el VIP del plano de control esté configurado en la misma subred que los demás nodos del clúster.
    Instalación, actualizaciones y mejoras 1.29.0 - 1.29.100

    La creación o actualización del clúster falla y se produce 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 utilizado no es un nombre de dominio completo. Mensaje de error en el pod vsphere-csi-controller, como se muestra a continuación:

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

    Este problema solo se produce en la versión 1.29 y posteriores, ya que se ha añadido una validación al controlador de CSI para vSphere para exigir el uso de nombres de usuario de dominio completos.

    Solución alternativa:

    Usa un nombre de dominio completo para el nombre de usuario de vCenter en el archivo de configuración de las credenciales. Por ejemplo, en lugar de usar "nombredeusuario1", usa "nombredeusuario1@example.com".
    Mejoras y actualizaciones 1.28.0 - 1.28.500

    Al actualizar un clúster de administrador de la versión 1.16 a la 1.28, es posible que no se pueda generar el certificado del plano de control durante el arranque de la nueva máquina principal del administrador. El problema se debe a los 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 posteriores. El problema se reproduce en clústeres creados en versiones 1.10 y anteriores que se han actualizado a la versión 1.16 y el certificado de hoja no se ha rotado 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 maestra de administrador que ha fallado mediante 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 maestra de administrador mediante SSH. Para obtener más información, consulta Conectarse a un nodo de clúster de administrador mediante SSH.
    2. Haz una copia /etc/startup/pki-yaml.sh y llámala /etc/startup/pki-yaml-copy.sh.
    3. Editar /etc/startup/pki-yaml-copy.sh. Busca authorityKeyIdentifier=keyidset y cámbialo por 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. En un editor de texto, abre /opt/bin/master.sh, busca y sustituye todas las instancias de /etc/startup/pki-yaml.sh por /etc/startup/pki-yaml-copy.sh y, a continuación, 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. Una vez que se haya completado la actualización, rota el certificado de hoja de los clústeres de administrador y de usuario, tal como se describe en Iniciar la rotación.
    9. Una vez que se haya completado la rotación del certificado, haz los mismos cambios en /etc/startup/pki-yaml-copy.sh que hiciste anteriormente y ejecuta /opt/bin/master.sh.
    Configuración 1.29.0

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

    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 se muestre esta advertencia mientras no se utilice dataplaneV2.forwardMode, aunque ya hayas definido enableDataplaneV2: true en el archivo de configuración de tu 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 comprobació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 administración de alta disponibilidad de la versión 1.28 y posteriores, ya que ya no tienen nodos complementarios. Además, como las IPs de los nodos del plano de control del clúster de administración 3 se especifican en la sección network.controlPlaneIPBlock del archivo de configuración del clúster de administración, las IPs del archivo de bloque de IPs solo son necesarias para los nodos del plano de control del clúster de usuario de kubeception.

    Solución alternativa:

    Para saltar la comprobación previa incorrecta en una versión no fija, añade --skip-validation-net-config al comando gkectl.
    Operación 1.29.0-1.29.100

    Si has migrado de un clúster de administrador sin alta disponibilidad a un clúster de administrador con alta disponibilidad, el agente de Connect del clúster de administrador perderá la conexión con gkeconnect.googleapis.com y se mostrará el error "Failed to verify JWT signature" (No se ha podido verificar la firma JWT). Esto se debe a que, durante la migración, se cambia la clave de firma de KSA, por lo que es necesario volver a registrarse para actualizar los JWKs 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 gke-connectnombre del despliegue:

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

    Elimina la implementación de gke-connect:

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

    Fuerza una conciliación para el onprem-admin-cluster-controller añadiendo una anotación "force-reconcile" a tu onpremadmincluster CR:

    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 desplegar la implementación de gke-connect y vuelva a registrar el clúster si no encuentra ninguna implementación de gke-connect disponible.

    Después de aplicar la solución alternativa (el controlador puede tardar unos minutos en completar la conciliación), puedes comprobar que el error 400 "Failed to verify JWT signature" (No se ha podido verificar la firma JWT) ya no aparece 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 de puente de Docker en la configuración de Docker para evitar que se reserve 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 Docker no se reiniciaba después de que Google Distributed Cloud personalizara la configuración de Docker debido a una regresión en la imagen del SO COS. Por lo tanto, Docker elige 172.17.0.1/16 como subred de la dirección IP de su puente. Esto puede provocar un conflicto de direcciones IP si ya tienes una carga de trabajo en ejecución dentro de ese intervalo 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 de puente correcta:

    ip a | grep docker0

    Esta solución no se mantiene al volver a crear las VMs. Debes volver a aplicar esta solución alternativa cada vez que se vuelvan a crear las VMs.
    update 1.28.0-1.28.400, 1.29.0-1.29.100

    Los archivos 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. Estos archivos binarios de CNI no se usan en el plano de datos v2, pero se pueden usar para interfaces de red adicionales en la función de varias interfaces de red.

    No se puede usar una interfaz de red con varios complementos CNI.

    Solución alternativa:

    Si usas esta función, actualiza a la versión que incluye la correcció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 provoca que no se puedan iniciar las cargas de trabajo de los usuarios.

    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 han omitido las validaciones, es posible que el webhook del clúster de administrador impida que se añadan. Por ejemplo, si el campo gkeConnect no se ha definido en un clúster de administrador, al añadirlo con el comando gkectl update admin, puede que aparezca 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
    En ocasiones, puede haber un problema con la comunicación entre el servidor de la API de Kubernetes y el webhook. Cuando esto ocurra, es posible que veas el siguiente mensaje de error: 
    failed to apply OnPremAdminCluster 'kube-system/gke-admin-btncc': Internal error occurred: failed calling webhook "monpremadmincluster.onprem.cluster.gke.io": failed to call webhook: Post "https://onprem-admin-cluster-controller.kube-system.svc:443/mutate-onprem-cluster-gke-io-v1alpha1-onpremadmincluster?timeout=10s": dial tcp 10.96.55.208:443: connect: connection refused

    Solución alternativa:

    Si se produce alguno de estos errores, utiliza una de las siguientes soluciones alternativas, en función de tu versión:
    • En los clústeres de administración 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
    • En los clústeres de administración 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 vas a usar un balanceador de carga manual (loadBalancer.kind está definido como "ManualLB"), no deberías tener que configurar la sección loadBalancer.manualLB del archivo de configuración para un clúster de administrador de alta disponibilidad 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 provoca que la creación del clúster falle y se muestre 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 alta disponibilidad:

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

    nfs-common no está en la imagen del SO Ubuntu, lo que puede causar problemas a los clientes que usen 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 este problema te afecta: 
    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:

    Añade el campo `vCenter.storagePolicyName` al archivo de configuración del clúster de administrador si quieres configurar la política de almacenamiento del clúster de administrador. Consulta las instrucciones.
    Almacenamiento de registros y monitorización 1.28.0-1.28.100

    La API kubernetesmetadata.googleapis.com, que se ha añadido recientemente, no admite VPC-SC. Esto provocará que el agente de recogida de metadatos no pueda acceder a esta API en VPC-SC. Por lo tanto, faltarán las etiquetas de metadatos de las métricas.

    Solución alternativa:

    En el espacio de nombres `kube-system`, asigna el valor `true` al campo `featureGates.disableExperimentalMetadataAgent` del CR `stackdriver` ejecutando el comando

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

    y, a continuación, 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"}]}]}}}}'`

    Mejoras y 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, por ejemplo, después de actualizar las credenciales de vSphere del clúster de administrador, es posible que clusterapi-controller no pueda conectarse a vCenter después de reiniciar. Consulta el registro de `clusterapi-controller` que se ejecuta en el espacio de nombres `kube-system` del clúster de administración.

    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 este problema te afecta: 
    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.

    Almacenamiento de registros y monitorización 1,14

    Prometheus puede informar de 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 comprobar si esta alerta es un falso positivo que se puede ignorar, sigue estos pasos:

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

      Puedes consultar esta métrica con Cloud Monitoring mediante la siguiente consulta de MQL: 
      fetch
    k8s_container | metric 'kubernetes.io/anthos/grpc_server_handled_total' | align rate(1m) | every 1m
    2. Puedes ignorar con seguridad las alertas de 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 forma que ignore estas alertas falsas positivas, consulta las siguientes opciones:

    1. Silenciar la alerta desde la interfaz de usuario del Gestor de alertas.
    2. Si no puedes silenciar la alerta, sigue estos pasos para suprimir los falsos positivos:
      1. Reduce el tamaño del operador de monitorización a 0 réplicas para que los cambios se conserven.
      2. Modifica el mapa de configuración prometheus-config y añade grpc_method!="Watch" a la configuración de alertas etcdHighNumberOfFailedGRPCRequests, tal 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])
           Sustituye lo siguiente CLUSTER_NAME por el nombre de tu clúster.
      3. Reinicia el StatefulSet de Prometheus y Alertmanager para aplicar la nueva configuración.
    3. Si el código se incluye en uno de los casos problemáticos, consulta el registro de etcd y el registro de kube-apiserver para depurar más.
    Redes 1.16.0-1.16.2, 1.28.0

    Las conexiones NAT de salida se pueden eliminar entre 5 y 10 minutos después de que se haya establecido 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 se produce si la conexión no transmite ninguna información durante un tiempo y, a continuación, el lado de destino transmite algo. Si el pod con NAT de salida siempre crea instancias de mensajería, este problema no se producirá.

    Este problema se produce porque la recogida de elementos no utilizados de anetd elimina por error entradas de conntrack que el daemon considera que no se usan. Hace poco, se integró una corrección upstream en anetd para corregir el comportamiento.


    Solución alternativa:

    No hay ninguna solución sencilla y no hemos detectado ningún problema en la versión 1.16 con este comportamiento. Si observas que las conexiones de larga duración se han interrumpido debido a este problema, puedes usar una carga de trabajo en el mismo nodo que la dirección IP de salida o enviar mensajes de forma constante en la conexión TCP.
    Operación 1.14, 1.15 y 1.16

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

    Solución alternativa:

    Si te afecta este problema, puedes actualizar tu clúster de usuarios añadiendo disableNodeIDVerificationCSRSigning: true al archivo de configuración del clúster de usuarios y ejecutando el comando gkectl update cluster para actualizar el clúster con esta configuración.
    Redes, actualizaciones y mejoras 1.16.0-1.16.3

    Si intentas inhabilitar el ingreso agrupado en un clúster que ya existe, el comando gkectl update cluster fallará y se mostrará 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 carga durante las comprobaciones previas. Aunque esta comprobación no es obligatoria al inhabilitar el acceso agrupado, la comprobación preparatoria gkectl falla cuando disableBundledIngress se establece en true.


    Solución alternativa:

    Usa el parámetro --skip-validation-load-balancer cuando actualices el clúster, tal 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 agrupado en un clúster.
    Mejoras y actualizaciones 1.13, 1.14, 1.15.0-1.15.6

    Si rotas los certificados de la autoridad de certificación (CA) del clúster de administrador, los intentos posteriores de ejecutar el comando gkectl update admin fallarán. El error devuelto es similar al siguiente:

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

    Solución alternativa:

    Si te afecta este problema, puedes actualizar 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 datos fiable durante la actualización del clúster. El archivo de punto de control se sigue actualizando para que puedas usarlo en el futuro.
    Almacenamiento 1.15.0-1.15.6, 1.16.0-1.16.2

    Durante las comprobaciones preparatorias, la comprobación de validación de la carga de trabajo de CSI instala un pod en el espacio de nombres default. El pod de carga de trabajo de CSI valida que el controlador de CSI de vSphere esté instalado y pueda realizar el aprovisionamiento dinámico de volúmenes. Si este pod no se inicia, la comprobación de validación de la carga de trabajo de CSI falla.

    Hay algunos problemas conocidos que pueden impedir que se inicie este pod:

    • Si el pod no tiene límites de recursos especificados, como ocurre en algunos clústeres con webhooks de admisión instalados, el pod no se inicia.
    • Si Cloud Service Mesh está instalado en el clúster y la inyección automática de sidecar de Istio está habilitada en el espacio de nombres default, el pod de carga de trabajo de CSI no se inicia.

    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 comprobar si el error se debe a la falta de recursos de Pod, ejecuta el siguiente comando para consultar 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 han definido 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 inyección de sidecar de Istio, puedes inhabilitar temporalmente la inyección automática de sidecar de Istio en el espacio de nombres default. Comprueba las etiquetas del espacio de nombres y usa el siguiente comando para eliminar la etiqueta que empieza por istio.io/rev:

    kubectl label namespace default istio.io/rev-

    Si el pod está mal configurado, comprueba manualmente que el aprovisionamiento dinámico de volúmenes con el controlador de CSI para vSphere funciona:

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

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

    Operación 1.16.0-1.16.2

    Cuando inicias sesión en una estación de trabajo de administrador gestionada por el usuario, es posible que el comando gkectl update cluster se agote y no se actualice el clúster de usuarios. Esto ocurre si la versión del clúster de administrador es la 1.15 y ejecutas gkectl update admin antes de ejecutar gkectl update cluster. Cuando se produce este error, aparece el siguiente mensaje al intentar 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 elimina del clúster el validation-controller que activa las comprobaciones previas. Si intentas actualizar el clúster de usuarios, la comprobación previa se quedará bloqueada hasta que se alcance 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 completada 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 inicias sesión en una estación de trabajo de administrador gestionada por el usuario, es posible que el comando gkectl create cluster se agote y no se cree el clúster de usuarios. Esto ocurre si la versión del clúster de administradores es la 1.15. Cuando se produce este error, aparece el siguiente mensaje al intentar 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 el validation-controller se añadió en la versión 1.16, al usar la versión 1.15 del clúster de administrador, falta el validation-controller responsable de activar las comprobaciones previas. Por lo tanto, al intentar crear un clúster de usuarios, las comprobaciones previas se quedan en espera hasta que se agota el tiempo de espera.

    Solución alternativa:

    1. Ejecuta el siguiente comando para implementar el validation-controller: 
            gkectl prepare --kubeconfig ADMIN_KUBECONFIG --bundle-path BUNDLE_PATH --upgrade-platform
    2. Una vez que se haya completado la preparación, vuelve a ejecutar gkectl create cluster para crear el clúster de usuarios.
    Mejoras y 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 añades una configuración de connect, stackdriver, cloudAuditLogging o gkeOnPremAPI al actualizar un clúster de administrador, es posible que el webhook del clúster de administrador rechace la operación. Es posible que se muestre uno de los siguientes mensajes de error:

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

    Para actualizar un clúster de administradores, se necesita el onprem-admin-cluster-controller para conciliar el clúster de administradores en un clúster de tipo. Cuando se restaura 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 crear un clúster de administrador o para reanudar las operaciones de una actualización. Algunas validaciones de solo creación se invocan al actualizar y cambiar a una versión superior de forma inesperada.


    Solución alternativa:

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

    1. Edita el recurso de clúster onpremadminclusters: 
      kubectl edit onpremadminclusters ADMIN_CLUSTER_NAME -n kube-system –kubeconfig ADMIN_CLUSTER_KUBECONFIG
       Sustituye lo siguiente:
      • ADMIN_CLUSTER_NAME: el nombre del clúster de administrador.
      • ADMIN_CLUSTER_KUBECONFIG: la ruta del archivo kubeconfig del clúster de administrador.
    2. Añade la anotación onprem.cluster.gke.io/skip-project-location-sameness-validation: true y guarda el recurso personalizado.
    3. En función del tipo de clústeres de administrador, sigue uno de estos pasos:
      • En el caso de los clústeres de administración que no tienen alta disponibilidad y que tienen un archivo de punto de control, añade el parámetro disable-update-from-checkpoint al comando de actualización o el parámetro `disable-upgrade-from-checkpoint` al 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
      • Si el clúster de administración de alta disponibilidad o el archivo de punto de control están inhabilitados: actualiza o mejora el clúster de administración como de costumbre. No se necesitan parámetros adicionales en los comandos de actualización.
    Operación 1.16.0-1.16.2

    Cuando inicias sesión en una estación de trabajo de administrador gestionada por el usuario, es posible que el comando gkectl delete cluster se agote y no se pueda eliminar el clúster de usuarios. Esto ocurre si primero has ejecutado gkectl en la estación de trabajo gestionada por el usuario para crear, actualizar o actualizar el clúster de usuarios. Cuando se produce este error, aparece el siguiente mensaje al intentar eliminar 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 elimina primero todos sus objetos. La eliminación de los objetos de validación (que se crearon durante la creación, la actualización o la mejora) se queda bloqueada en la fase de eliminación. Esto ocurre porque un finalizador bloquea la eliminación del objeto, lo que provoca que falle la eliminación del clúster.

    Solución alternativa:

    1. Obtén los nombres de todos los objetos Validation: 
               kubectl  --kubeconfig ADMIN_KUBECONFIG get validations \
           -n USER_CLUSTER_NAME-gke-onprem-mgmt
    2. En 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 eliminar el finalizador de todos los objetos Validation, los objetos se eliminan y la operación de eliminación del clúster de usuario se completa automáticamente. No es necesario que hagas nada más.

    Redes 1.15 y 1.16

    Si el pod de origen y el pod de la pasarela NAT de salida están en dos nodos de trabajo diferentes, el tráfico del pod de origen no podrá acceder a ningún servicio externo. Si los pods están ubicados 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 la agregación de túneles está habilitada. Hay 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 cilium-config ConfigMap: 
      kubectl edit cm -n kube-system cilium-config --kubeconfig USER_CLUSTER_KUBECONFIG
    2. Añade lo siguiente al cilium-config ConfigMap: 
      tunnel-port: 4789
    3. Reinicia el DaemonSet anetd: 
      kubectl rollout restart ds anetd -n kube-system --kubeconfig USER_CLUSTER_KUBECONFIG

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

    La actualización del clúster de administrador de la versión 1.14.x a la 1.15.x con el cifrado de secretos siempre activo falla debido a una discrepancia entre la clave de cifrado generada por el controlador y la clave que se conserva en el disco de datos maestro del administrador. La salida 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 y se produce 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

    Si tienes una copia de seguridad del clúster de administrador, sigue estos pasos para solucionar el problema de la 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, conéctate a ella por SSH y sustituye la clave nueva del disco de datos por la antigua de la copia de seguridad. La clave se encuentra en /opt/data/gke-k8s-kms-plugin/generatedkeys en el administrador principal.
    3. Actualiza el archivo de manifiesto de Pod estático kms-plugin.yaml en /etc/kubernetes/manifests para actualizar --kek-id de forma que coincida con el campo kid de la clave de cifrado original.
    4. Reinicia el pod estático kms-plugin moviendo el /etc/kubernetes/manifests/kms-plugin.yaml a otro directorio y, a continuación, vuelve a moverlo.
    5. Reanuda la actualización de administrador ejecutando gkectl upgrade admin de nuevo.

    Evitar que falle la actualización

    Si aún no has actualizado, te recomendamos que no lo hagas a la versión 1.15.0-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 el cifrado de secretos siempre activo.
    Almacenamiento 1.11-1.16

    Google Distributed Cloud no admite el seguimiento de bloques modificados (CBT) en discos. Algunos software de copias de seguridad usan la función CBT para monitorizar el estado del disco y realizar copias de seguridad, lo que provoca que el disco no pueda conectarse a una máquina virtual que ejecute Google Distributed Cloud. Para obtener más información, consulta el artículo de la base de conocimientos de VMware.


    Solución alternativa:

    No hagas copias de seguridad de las máquinas virtuales de Google Distributed Cloud, ya que el software de copias de seguridad de terceros puede habilitar CBT en sus discos. No es necesario crear copias de seguridad de estas VMs.

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

    Si ya tienes discos con CBT habilitado, sigue los pasos de la sección Resolución del artículo de la base de conocimientos 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 se produzcan daños en los datos o que los pods no se ejecuten correctamente. Este problema se debe a un problema de compatibilidad conocido entre determinadas versiones de VMware y versiones de Nutanix. Para obtener más información, consulta el artículo de la base de conocimientos de VMware asociado.


    Solución alternativa:

    El artículo de la base de conocimientos de VMware está obsoleto, ya que indica que no hay ninguna resolución actual. Para resolver este problema, actualice a la versión más reciente de ESXi en sus hosts y a la versión más reciente de Nutanix en sus 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 archivo binario kubelet precargado en la imagen del SO usa una versión diferente.

    En la siguiente tabla se enumeran las versiones que no coinciden:

    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 es necesario hacer nada. La incoherencia solo se produce entre las versiones de parche de Kubernetes y no se ha producido ningún problema debido a esta diferencia de versiones.

    Mejoras y actualizaciones 1.15.0-1.15.4

    Cuando un clúster de administrador tiene una versión de autoridad de certificación (CA) superior a 1, se produce un error en la actualización o la mejora debido a la validación de la versión de la CA en el webhook. El resultado de gkectl upgrade/update contiene el siguiente mensaje de error: 

        CAVersion must start from 1

    Solución alternativa:

    • Reduce la escala de 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 nuevo campo introducido en el recurso personalizado del clúster de administrador en la versión 1.15 puede provocar un error de puntero nulo en auto-resize-controller. 
       kubectl scale deployment auto-resize-controller -n kube-system --replicas=0 --kubeconfig KUBECONFIG
    • Ejecuta comandos de 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 elimina un clúster de Controlplane V2 que no es de alta disponibilidad, se queda bloqueado 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, ponte en contacto con Cloud Customer Care para resolver este problema.

    Si no es así, sigue estos pasos:

    • Elimina todas las VMs del clúster de vSphere. Puedes eliminar las máquinas virtuales a través de la interfaz de usuario de vSphere o ejecutar el siguiente comando: 
            govc vm.destroy
      .
    • Vuelve a eliminar el clúster por la fuerza: 
           gkectl delete cluster --cluster USER_CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG --force

    Almacenamiento 1.15.0+, 1.16.0+

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


    Solución alternativa:

    Edita el archivo configMap de la función CSI de vSphere y define list-volumes como false:

         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 integrados, los comandos gkectl diagnose y gkectl upgrade pueden generar advertencias falsas sobre sus reclamaciones de volumen persistente (PVC) al validar la configuración de almacenamiento del clúster. El mensaje de advertencia tiene el siguiente aspecto: 

        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 comprobar las anotaciones de un PVC con la advertencia anterior:

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

    Si el campo annotations de la salida contiene lo siguiente, puede ignorar la advertencia:

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

    Si tu clúster no usa un registro privado y las claves de la cuenta de servicio de acceso a componentes y las claves de la cuenta de servicio de registro y monitorización (o de conexión y registro) han caducado, cuando rotes las claves de la cuenta de servicio, gkectl update credentials fallará y mostrará 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 componentes. Aunque se muestre el mismo mensaje de error, deberías poder rotar las otras claves después de rotar la clave de la cuenta de servicio de acceso a componentes.

    Si la actualización sigue sin completarse correctamente, póngase en contacto con el equipo de Asistencia de Google Cloud para resolver el problema.
    Actualizaciones 1.16.0-1.16.5

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

    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 alternativa que apliques dependerá de cómo se produzca el problema.

    Solución alternativa para actualizar el clúster de usuarios mediante la consola: Google Cloud

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

    Opción 2: Sigue estos pasos:

    1. Añade manualmente la anotación de repetición con el siguiente comando: 
      kubectl edit onpremuserclusters USER_CLUSTER_NAME -n USER_CLUSTER_NAME-gke-onprem-mgmt --kubeconfig ADMIN_KUBECONFIG

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

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

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

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

    Opción 2: Sigue estos pasos:

    1. Añade el archivo de información de compilación /etc/cloud/build.info con el siguiente contenido. De esta forma, las comprobaciones previas se ejecutan de forma local en tu 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 haya completado la actualización, elimina 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 del archivo de bloque de IPs, la comprobación previa fallará y se mostrará el siguiente mensaje de error: 

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

    Hay un error en la comprobación de solicitudes preparatorias que considera que un nombre de host vacío es un duplicado.

    Solución alternativa:

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

    Opción 2: Saltar esta comprobación previa añadiendo la marca --skip-validation-net-config.

    Opción 3: Especificar un nombre de host único para cada dirección IP del archivo de bloque de IPs.
    Mejoras y actualizaciones 1.16

    En el caso de un clúster de administradores que no sea de alta disponibilidad y un clúster de usuarios con plano de control v1, cuando actualices el clúster de administradores, es posible que la recreación de la máquina principal del clúster de administradores se produzca al mismo tiempo que el reinicio de la máquina principal del clúster de usuarios, lo que puede provocar una condición de carrera. Esto provoca que los pods del plano de control del clúster de usuarios no puedan comunicarse con el plano de control del clúster de administrador, lo que causa problemas de conexión de volúmenes para kube-etcd y kube-apiserver en el plano de control del clúster de usuarios.

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

    kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG --namespace USER_CLUSTER_NAME describe pod IMPACTED_POD_NAME
     Verá eventos como los siguientes: 
    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. Conéctate mediante SSH al nodo de plano de control de usuario, ya que se trata de un clúster de usuario de la versión 1 del plano de control, el nodo de plano de control de usuario está en el clúster de administrador.
    2. Reinicia el kubelet con el siguiente comando: 
          sudo systemctl restart kubelet
      Después de reiniciar, kubelet puede reconstruir correctamente el montaje global de la fase.
    Mejoras y actualizaciones 1.16.0

    Durante una actualización de un clúster de administrador, puede que se produzca una condición de carrera que provoque que el gestor de controladores de nube de vSphere elimine inesperadamente un nuevo nodo del plano de control. Esto provoca que el controlador de la API de clústeres se quede bloqueado esperando a que se cree el nodo y, finalmente, la actualización se agote. En este caso, el resultado del comando gkectl upgrade/update 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 comando que aparece a continuación para obtener el registro del gestor de controladores 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 el equipo en el que se ha producido un error para volver a crear el objeto de nodo eliminado.
    2. Accede a cada nodo del plano de control mediante SSH y reinicia el pod estático del gestor de controladores 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

    Si hay nombres de host duplicados en el mismo centro de datos, no se podrá actualizar un clúster 1.15 ni crear un clúster 1.16 con IPs estáticas. Este error se produce porque el gestor de controladores de nube de vSphere no puede añadir una IP externa ni un ID de proveedor al objeto de nodo. Esto provoca que se agote el tiempo de espera de la actualización o la creación del clúster.

    Para identificar el problema, obtén los registros del pod del gestor de controladores de nube de vSphere del clúster. El comando que utilices dependerá 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 con enableControlplaneV2 false: 
            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 con enableControlplaneV2 true: 
            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 mensaje de error de ejemplo:

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

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

    Puedes usar el siguiente método para comprobar si el nombre de host está duplicado y buscar una solución alternativa si es necesario. 
              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
    Ejemplos de comandos y resultados: 
              export GOVC_DATACENTER=mtv-lifecycle-vc01
          export GOVC_URL=https://mtv-lifecycle-vc01.anthos/sdk
          export GOVC_USERNAME=xxx
          export GOVC_PASSWORD=yyy
          export GOVC_INSECURE=true
          govc find . -type m -guest.hostName f8c3cd333432-lifecycle-337-xxxxxxxz
          ./vm/gke-admin-node-6b7788cd76-wkt8g
          ./vm/gke-admin-node-6b7788cd76-99sg2
          ./vm/gke-admin-master-5m2jb

    La solución alternativa que apliques dependerá de la operación que haya fallado.

    Solución alternativa para las actualizaciones:

    Aplica la solución alternativa para el tipo de clúster correspondiente.

    • Clúster de usuarios:
      1. Actualiza el nombre de host del equipo afectado en user-ip-block.yaml con un nombre único y activa una actualización forzada:
                  gkectl update cluster --kubeconfig ADMIN_KUBECONFIG --config NEW_USER_CLUSTER_CONFIG --force
      2. Volver a ejecutar gkectl upgrade cluster
    • Clúster de administrador:
      1. Actualiza el nombre de host del equipo afectado en admin-ip-block.yaml con un nombre único y activa una actualización forzada:
                  gkectl update admin --kubeconfig ADMIN_KUBECONFIG --config NEW_ADMIN_CLUSTER_CONFIG --force --skip-cluster-ready-check
      2. Si se trata de un clúster de administrador que no es de alta disponibilidad y detectas que la VM del administrador principal usa un nombre de host duplicado, también debes hacer lo siguiente:
        Obtener el nombre de la máquina del administrador principal 
                  kubectl get machine --kubeconfig ADMIN_KUBECONFIG -owide -A
        Actualiza el objeto de la máquina maestra de administrador
        Nota: El valor de NEW_ADMIN_MASTER_HOSTNAME debe ser el mismo que el que definiste 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 haya actualizado en el objeto de la máquina maestra de administrador:
                  kubectl get machine ADMIN_MASTER_MACHINE_NAME --kubeconfig ADMIN_KUBECONFIG -oyaml
          kubectl get machine ADMIN_MASTER_MACHINE_NAME --kubeconfig ADMIN_KUBECONFIG -o jsonpath='{.spec.providerSpec.value.networkSpec.address.hostname}'
      3. Vuelve a ejecutar la actualización del clúster de administrador con el punto de control inhabilitado:
                  gkectl upgrade admin --kubeconfig ADMIN_KUBECONFIG --config ADMIN_CLUSTER_CONFIG --disable-upgrade-from-checkpoint

    Solución para las instalaciones:

    Aplica la solución alternativa para el tipo de clúster correspondiente.
    Operación 1.16.0, 1.16.1, 1.16.2 y 1.16.3

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

    • Actualizar un clúster de usuarios 1.15 con Controlplane V2 habilitado a la versión 1.16
    • Actualizar un clúster de administradores de alta disponibilidad (HA) de la versión 1.15 a la 1.16
    • Crear un clúster de usuarios 1.16 con Controlplane V2 habilitado
    • Crear un clúster de administrador de alta disponibilidad de la versión 1.16

    Usa una versión 1.16.4 o posterior de Google Distributed Cloud con la corrección o sigue la solución alternativa que se indica a continuación. La solución alternativa que apliques dependerá de la operación que haya fallado.

    Solución alternativa para las actualizaciones:

    1. Cambia el nombre de usuario o la contraseña de vCenter en 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 usuarios: 
                gkectl update cluster --kubeconfig ADMIN_KUBECONFIG --config USER_CLUSTER_CONFIG --force
      • Clúster de administrador: 
                gkectl update admin --kubeconfig ADMIN_KUBECONFIG --config ADMIN_CLUSTER_CONFIG --force --skip-cluster-ready-check

    Solución para las instalaciones:

    1. Cambia el nombre de usuario o la contraseña de vCenter en 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. Aplica la solución alternativa para el tipo de clúster correspondiente.
    Almacenamiento 1.11+, 1.12+, 1.13+, 1.14+, 1.15+, 1.16

    Si se elimina un nodo y, después, se vuelve a crear con el mismo nombre, es posible que se produzca un error al crear un PersistentVolumeClaim (PVC) posterior, 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 CSI de vSphere no elimina una máquina eliminada 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 alta disponibilidad, gkectl devuelve 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:

    Añade la marca --admin-master-vm-template= al comando y proporciona la plantilla de VM de la máquina que quieras reparar: 

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

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

    1. Ve a la página Hosts and Clusters (Hosts y clústeres) 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 del clúster de administrador.

    3. Copia el nombre de la plantilla de VM que coincida con el nombre de la máquina que vas a reparar y usa el nombre de la plantilla en el comando de reparación.
      gkectl repair admin-master \
      --config=/home/ubuntu/admin-cluster.yaml \
      --kubeconfig=/home/ubuntu/kubeconfig \
      --admin-master-vm-template=/atl-qual-vc07/vm/gke-admin-98g94-zx...7vx-0-tmpl
    Redes 1.10.0+, 1.11.0+, 1.12.0+, 1.13.0+, 1.14.0-1.14.7, 1.15.0-1.15.3, 1.16.0

    Si usas Seesaw como tipo de balanceador de carga de tu clúster y ves que una máquina virtual de Seesaw está inactiva o no se puede iniciar, 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 disco de la VM es bajo porque fluent-bit que se ejecuta en la VM de Seesaw no está configurado con la rotación de registros correcta.


    Solución alternativa:

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

    Nota: Si no puedes acceder a la VM, adjunta el disco a una VM que funcione (por ejemplo, una estación de trabajo de administrador), elimina el archivo del disco adjunto y vuelve a adjuntar el disco a la VM de Seesaw original.

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

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

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


    Solución alternativa:

    Si no puedes actualizar a una versión de parche de Google Distributed Cloud con la corrección, ponte en contacto con el equipo de Asistencia 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 se registra en la API de GKE On-Prem, es posible que no se pueda actualizar a las versiones afectadas porque no se puede actualizar la pertenencia a la flota. Cuando se produce este error, aparece el siguiente mensaje al intentar 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 registra en la API cuando lo registras explícitamente 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 `failed to register cluster`. Al cabo de un rato, debería actualizarse automáticamente.
    Mejoras y actualizaciones 1.13.0-1.13.9, 1.14.0-1.14.4, 1.15.0

    Cuando un clúster de administrador se registra en la API de GKE On-Prem, su anotación de enlace de recurso 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 provocar que el clúster de administrador se vuelva a registrar en la API de GKE On-Prem por error.

    Un clúster de administrador se registra en la API cuando lo registras explícitamente 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 registrar el clúster de administrador.
    Redes 1.15.0-1.15.2

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

    Este problema se produce porque la plantilla CoreDNS no se ha actualizado, lo que provoca que se ignore orderPolicy.


    Solución alternativa:

    Actualiza la plantilla CoreDNS y aplica la corrección. Esta corrección se mantendrá hasta que se realice una actualización.

    1. Edita la plantilla: 
      kubectl edit cm -n kube-system coredns-template
       Sustituye el contenido de la plantilla por 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 }}
    Mejoras y actualizaciones 1.10, 1.11, 1.12, 1.13.0-1.13.7, 1.14.0-1.14.3

    Determinadas condiciones de carrera podrían provocar que el estado OnPremAdminCluster no sea coherente entre el punto de control y el CR real. Cuando se produce el problema, puede aparecer el siguiente error al actualizar el clúster de administrador después de haberlo actualizado:

    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, tendrás que editar el punto de control o inhabilitarlo para la actualización. Ponte en contacto con nuestro equipo de Asistencia para continuar con la solución alternativa.
    Operación 1.13.0-1.13.9, 1.14.0-1.14.5, 1.15.0-1.15.1

    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, especialmente en el caso de 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 provocar que se agote el tiempo de espera de los siguientes comandos y que devuelvan errores:
      • gkectl create admin
      • gkectl upgrade amdin
      • gkectl update admin

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

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

    Solución alternativa:

    Actualiza a una versión de Google Distributed Cloud que incluya la corrección: 1.13.10+, 1.14.6+ o 1.15.2+. Si no puedes actualizar, ponte en contacto con Atención al cliente de Cloud para resolver este problema.
    Redes, Operación 1.10, 1.11, 1.12, 1.13 y 1.14

    Los pods de la puerta de enlace de red de kube-system pueden mostrar el estado Pending o Evicted, como se muestra en el siguiente ejemplo de salida condensada:

    $ 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 desalojo o que no se han podido programar pods debido a los recursos de los nodos. 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 pasarela de red. Este comportamiento es especialmente perjudicial para ang-node DaemonSet, ya que esos pods deben programarse en un nodo específico y no 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 Anthos Network Gateway. El controlador de Google Distributed Cloud sobrescribe estos cambios manuales durante un proceso de conciliación, como durante una actualización del clúster.

    • Asigna el system-cluster-critical PriorityClass a las implementaciones de controlador de clúster ang-controller-manager y autoscaler.
    • Asigna el system-node-critical PriorityClass al DaemonSet del nodo ang-daemon.
    Mejoras y 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 al intentar 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

    Elimina 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
     Elimina la suscripción a la flota: 
    gcloud container fleet memberships delete ADMIN_CLUSTER_NAME
     y reanuda la actualización del clúster de administrador.
    Operación 1.13.0-1.13.8, 1.14.0-1.14.5, 1.15.0-1.15.1

    gkectl diagnose snapshot --log-since no limita el periodo de tiempo de los comandos journalctl que se ejecutan en los nodos del clúster

    Esto no afecta a la función de crear una instantánea del clúster, ya que la instantánea sigue incluyendo todos los registros que se recogen de forma predeterminada al ejecutar journalctl en los nodos del clúster. Por lo tanto, no se pierde información de depuración.
    Instalación, actualizaciones y mejoras 1.9+, 1.10+, 1.11+, 1.12+

    gkectl prepare windows no puede instalar Docker en versiones de Google Distributed Cloud anteriores a la 1.13 porque MicrosoftDockerProvider está obsoleto.


    Solución alternativa:

    La idea general para solucionar este problema es actualizar a Google Distributed Cloud 1.13 y usar la versión 1.13 gkectl para crear una plantilla de VM de Windows y, a continuación, crear grupos de nodos de Windows. Como se muestra a continuación, hay dos opciones para pasar a Google Distributed Cloud 1.13 desde su versión actual.

    Nota: Tenemos opciones para solucionar este problema en tu versión actual sin necesidad de actualizar a la versión 1.13, pero se requerirán más pasos manuales. Ponte en contacto con nuestro equipo de Asistencia si quieres considerar esta opción.


    Opción 1: actualización azul-verde

    Puedes crear un clúster con la versión 1.13 o posterior de Google Distributed Cloud que tenga grupos de nodos de Windows, migrar tus cargas de trabajo al nuevo clúster y, a continuación, eliminar el clúster actual. Te recomendamos que uses la versión secundaria más reciente de Google Distributed Cloud.

    Nota: Se necesitarán recursos adicionales para aprovisionar el nuevo clúster, pero habrá menos tiempo de inactividad y menos interrupciones para las cargas de trabajo actuales.


    Opción 2: Eliminar los grupos de nodos de Windows y volver a añadirlos al actualizar 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 añadir los grupos de nodos de Windows.

    1. Elimina los grupos de nodos de Windows que haya quitando la configuración de los grupos de nodos de Windows del archivo user-cluster.yaml y, a continuación, ejecuta el siguiente comando: 
      gkectl update cluster --kubeconfig=ADMIN_KUBECONFIG --config USER_CLUSTER_CONFIG_FILE
    2. Actualiza los clústeres de administrador y de usuario solo de Linux a la versión 1.12 siguiendo la guía de actualización de la versión secundaria de destino correspondiente.
    3. (Asegúrate de realizar este paso antes de actualizar a la versión 1.13). Asegúrate de que enableWindowsDataplaneV2: true esté configurado en el CR OnPremUserCluster. De lo contrario, el clúster seguirá usando los 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 tenga Docker instalado. Si no se ha configurado o se ha definido como "false", actualiza el clúster para asignarle el valor "true" en user-cluster.yaml y, a continuación, ejecuta el siguiente comando: 
      gkectl update cluster --kubeconfig=ADMIN_KUBECONFIG --config USER_CLUSTER_CONFIG_FILE
    4. Actualiza los clústeres de administrador y usuario solo de Linux a la versión 1.13 siguiendo la guía 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 añadir la configuración del grupo de nodos de Windows a user-cluster.yaml con el campo OSImage definido en la plantilla de VM de Windows recién creada.
    7. Actualizar el clúster para añadir grupos de nodos de Windows 
      gkectl update cluster --kubeconfig=ADMIN_KUBECONFIG --config USER_CLUSTER_CONFIG_FILE
    Instalación, actualizaciones y mejoras 1.13.0-1.13.9, 1.14.0-1.14.5, 1.15.0-1.15.1

    En los nodos se usará el valor predeterminado de 5 segundos para RootDistanceMaxSec en lugar de 20 segundos, que debería ser la configuración esperada. Si compruebas el registro de inicio del nodo conectándote a la VM mediante SSH, que se encuentra en `/var/log/startup.log`, verás el siguiente error:

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

    Si se usa un RootDistanceMaxSec de 5 segundos, es posible que el reloj del sistema no se sincronice con el servidor NTP cuando la desviación del reloj sea superior a 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: /
    Mejoras y actualizaciones 1.12.0-1.12.6, 1.13.0-1.13.6, 1.14.0-1.14.2

    Cuando usas la versión 1.13 gkectl para actualizar un clúster de administrador de la versión 1.12, puede 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 consulta el registro gkectl, puede que vea que los varios cambios incluyen la configuración de osImageType de una cadena vacía a ubuntu_containerd.

    Estos errores de actualización se deben a un relleno incorrecto del campo osImageType en la configuración del clúster de administrador, ya que se introdujo en la versión 1.9.


    Solución alternativa:

    Actualiza a una versión de Google Distributed Cloud que incluya la corrección. Si no puedes actualizar, ponte en contacto con el equipo de Asistencia de Google Cloud para resolver el problema.
    Instalación, seguridad 1.13, 1.14, 1.15, 1.16

    La opción de proporcionar un certificado de servicio adicional para el servidor de la API de Kubernetes de un clúster de usuario con authentication.sni no funciona cuando Controlplane V2 está habilitado ( enableControlplaneV2: true).


    Solución alternativa:

    Hasta que esté disponible un parche de Google Distributed Cloud 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 de administrador no se inicia cuando el nombre de usuario del registro privado contiene $. Al comprobar el /var/log/startup.log en el equipo del plano de control de administrador, aparece 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.
    Mejoras y 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,
      ...
    }
    Mejoras y 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, posteriormente, actualizar un clúster de usuarios, gkectl update puede fallar y mostrar el siguiente mensaje de error: 

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


    Solución alternativa:

    Cambia la versión de tu clave de firma de KSA a la versión 1, pero conserva los datos de la clave más reciente:
    1. Comprueba el secreto en el clúster de administrador en el espacio de nombres USER_CLUSTER_NAME y obtén el nombre del secreto ksa-signing-key: 
      kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME get secrets | grep ksa-signing-key
    2. Copia el secreto de ksa-signing-key y asigna el nombre service-account-cert al secreto copiado: 
      kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME get secret KSA-KEY-SECRET-NAME -oyaml | \
sed 's/ name: .*/ name: service-account-cert/' | \
kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME apply -f -
    3. Elimina el secreto 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 mapa de configuración 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 comprobar el estado, puedes hacer lo siguiente: 
      kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME-gke-onprem-mgmt \
get onpremusercluster
    8. Restaura el webhook de validación del clúster de usuarios: 
      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. No vuelvas a rotar 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 eliminar un clúster de usuario con un balanceador de carga de F5 BIG-IP, los servidores virtuales de F5 BIG-IP no se eliminan después de eliminar el clúster.


    Solución alternativa:

    Para quitar los recursos de F5, sigue los pasos para limpiar una partición de F5 de un clúster de usuarios

    Instalación, actualizaciones y mejoras 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 actualizas un clúster de administrador a la versión 1.13.8 o 1.14.4, el clúster de tipo extraerá 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, se producirá un error al crear o actualizar el clúster de administradores, ya que no se podrá iniciar el clúster de tipo. Si ejecutas el siguiente comando en la estación de trabajo del administrador, se mostrarán 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 precargarse en la imagen del contenedor del clúster de Kind. Sin embargo, la versión 0.18.0 de kind tiene un problema con las imágenes de contenedor precargadas, lo que provoca que se extraigan de Internet por error.


    Solución alternativa:

    Ejecuta los siguientes comandos en la estación de trabajo de administrador mientras tu 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 switch que filtra las solicitudes GARP (ARP gratuito) duplicadas, es posible que la elección del líder de keepalived se encuentre con una condición de carrera, lo que provoca que algunos nodos tengan entradas incorrectas en la tabla ARP.

    Los nodos afectados pueden ping la IP virtual del plano de control, pero se agotará el tiempo de espera de una conexión TCP a la IP virtual 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
    Mejoras y 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 provoca que vsphere-csi-controller falle después de la rotación.

    Solución alternativa:

    En los clústeres creados con la versión 1.13 o 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

    Aunque se produzca un error en el registro de clústeres durante la creación del clúster de administrador, el comando gkectl create admin no falla y puede completarse correctamente. Es decir, la creación del clúster de administrador podría completarse correctamente sin registrarse en una flota.

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

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

    Solución alternativa:

    En el caso de los clústeres creados en la versión 1.12 o posterior, siga las instrucciones para volver a intentar registrar el clúster de administrador después de crear el clúster. En el caso de los clústeres creados con versiones anteriores,

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

    Mejoras y 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:

    Comprueba si el clúster aparece entre los clústeres registrados. Como paso opcional, inicia sesión en el clúster después de configurar la autenticación. Si el clúster sigue registrado, puedes saltarte las siguientes instrucciones para volver a intentar el registro. En el caso de los clústeres actualizados a la versión 1.12 o posterior, sigue las instrucciones para volver a intentar registrar el clúster de administrador después de crear el clúster. En los clústeres actualizados a versiones anteriores,
    1. Añade un par clave-valor falso, como "foo: bar", al archivo de clave de SA connect-register.
    2. Ejecuta gkectl update admin para volver a registrar el clúster de administrador.

    Configuración 1.15.0

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

    vCenter.dataDisk must be present in the AdminCluster spec

    Solución alternativa:

    Puedes ignorar este mensaje de error.
    VMware 1.15.0

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


    Solución alternativa:

    Elimina las reglas antiguas redundantes para que se pueda crear el 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. Puede volver a ejecutarse de forma segura hasta que el comando se complete correctamente.
    Mejoras y actualizaciones 1.15.0

    Después de volver a crear o actualizar un nodo del plano de control, es posible que algunos pods se queden en el estado Failed debido a un error en el predicado NodeAffinity. Estos pods fallidos no afectan al estado ni a las operaciones normales del clúster.


    Solución alternativa:

    Puedes ignorar los pods fallidos o eliminarlos manualmente.
    Seguridad y configuración 1.15.0-1.15.1

    Si usas credenciales preparadas y un registro privado, pero no has configurado las 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 del registro privado para el clúster de usuario siguiendo las instrucciones de Configurar credenciales preparadas.

    Mejoras y actualizaciones 1.15.0

    Durante gkectl upgrade admin, la comprobación previa del almacenamiento para la migración de CSI verifica que las StorageClasses no tengan parámetros que se ignoren después de la migración de CSI. Por ejemplo, si hay un StorageClass con el parámetro diskformat, gkectl upgrade admin marca el StorageClass e informa de un error en la validación previa. Los clústeres de administrador creados en Google Distributed Cloud 1.10 y versiones anteriores tienen un StorageClass con diskformat: thin que no superará esta validación, pero este StorageClass seguirá funcionando correctamente después de la migración de CSI. Estos errores deben interpretarse como advertencias.

    Para obtener más información, consulta la sección del parámetro StorageClass en el artículo Migrar volúmenes de vSphere In-Tree 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 determinadas condiciones, los discos se pueden adjuntar como de solo lectura a los nodos de Windows. De este modo, el volumen correspondiente será de solo lectura dentro de un pod. Es más probable que se produzca este problema cuando un nuevo conjunto de nodos sustituye a un conjunto antiguo (por ejemplo, al actualizar un clúster o un grupo de nodos). Es posible que las cargas de trabajo con estado que funcionaban correctamente no puedan escribir en sus volúmenes en el nuevo conjunto de nodos.


    Solución alternativa:

    1. Obtén el UID del pod que no puede escribir en su volumen: 
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get pod \
    POD_NAME --namespace POD_NAMESPACE \
    -o=jsonpath='{.metadata.uid}{"\n"}'
    2. Usa PersistentVolumeClaim para obtener el nombre de 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 está ejecutando el pod: 
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIGget pods \
    --namespace POD_NAMESPACE \
    -o jsonpath='{.spec.nodeName}{"\n"}'
    4. Obtén acceso a PowerShell al nodo a través de SSH o de la interfaz web de vSphere.
    5. Define las variables de entorno: 
      PS C:\Users\administrator> pvname=PV_NAME
PS C:\Users\administrator> podid=POD_UID
    6. Identifica el número del disco asociado al 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. Comprueba que el disco sea readonly: 
      PS C:\Users\administrator> (Get-Disk -Number $disknum).IsReadonly
       El resultado debe ser True.
    8. Asigna el valor false a readonly. 
      PS C:\Users\administrator> Set-Disk -Number $disknum -IsReadonly $false
PS C:\Users\administrator> (Get-Disk -Number $disknum).IsReadonly
    9. Elimina el Pod para que se reinicie: 
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG delete pod POD_NAME \
    --namespace POD_NAMESPACE
    10. El pod debe programarse en el mismo nodo. Sin embargo, si el pod se programa en un nuevo nodo, es posible que tengas que repetir los pasos anteriores en el nuevo nodo.

    Mejoras y 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 actualiza las credenciales de vSphere de un clúster de administrador siguiendo los pasos para actualizar las credenciales del clúster, es posible que vsphere-csi-secret en el espacio de nombres kube-system del clúster de administrador siga usando las credenciales antiguas.


    Solución alternativa:

    1. Obtén el nombre del secreto vsphere-csi-secret: 
      kubectl --kubeconfig=ADMIN_KUBECONFIG -n=kube-system get secrets | grep vsphere-csi-secret
    2. Actualiza los datos del secreto vsphere-csi-secret que has obtenido 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. Reiniciar 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 lo siguiente: 
      kubectl --kubeconfig=ADMIN_KUBECONFIG -n=kube-system rollout status deployment vsphere-csi-controller
       Una vez que se haya implementado correctamente, el controlador debería usar el vsphere-csi-secret actualizado.
    Mejoras y actualizaciones 1.10, 1.11, 1.12.0-1.12.6, 1.13.0-1.13.6 y 1.14.0-1.14.2

    audit-proxy puede entrar en un bucle de fallos debido a que --cluster-name está 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 del contenedor audit-proxy.


    Solución alternativa:

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

    En el caso de un clúster de usuarios de plano de control v1, edita el contenedor audit-proxy en el conjunto con estado kube-apiserver para añadir --cluster_name=USER_CLUSTER_NAME:

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

    Justo 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 ha cambiado de RUNNING a RECONCILING. Es posible que las solicitudes al clúster de usuario agoten el tiempo de espera.

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

    Este problema solo se produce en los clústeres de usuarios que NO usan la versión 2 del plano de control.


    Solución alternativa:

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

    Google Distributed Cloud 1.12.7-gke.19 es una versión incorrecta y no deberías usarla. Los artefactos se han eliminado del segmento de Cloud Storage.

    Solución alternativa:

    Usa la versión 1.12.7-gke.20.
    Mejoras y actualizaciones 1.12.0+, 1.13.0-1.13.7, 1.14.0-1.14.3

    Si actualiza la credencial del registro mediante uno de los siguientes métodos:

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

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

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


    Solución alternativa:

    Opción 1: volver a implementar gke-connect-agent manualmente:

    1. Elimina 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):

      En 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 añadir el secreto de extracción de imágenes predeterminado de tu clúster en la implementación de gke-connect-agent de la siguiente forma:

    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 gke-connect-agentnombre del despliegue: 
      kubectl --kubeconfig=KUBECONFIG -n=gke-connect get deployment | grep gke-connect-agent
    3. Añade el secreto predeterminado al despliegue 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

    Si valida la configuración antes de crear un clúster con balanceador de carga manual ejecutando gkectl check-config, el comando fallará y se mostrarán 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 carga.

    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

    Los clústeres que ejecuten la versión 3.4.13 de etcd o una anterior pueden sufrir falta de recursos de monitorización y que estos no funcionen, lo que puede provocar los siguientes problemas:

    • La programación de pódcasts se interrumpe
    • Los nodos no se pueden registrar
    • kubelet no observa los cambios en los pods

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

    Este problema se ha solucionado en las versiones 1.12.7, 1.13.6 y 1.14.3 de Google Distributed Cloud, así como en las versiones posteriores. 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

    Si no puedes actualizarlo inmediatamente, puedes reducir el riesgo de que falle el clúster disminuyendo el número de nodos del clúster. Elimina 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, haz lo siguiente:

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

      Ir a Explorador de métricas

    2. Seleccione la pestaña Configuración.
    3. Despliegue Seleccionar una métrica, introduzca Kubernetes Container en la barra de filtros y, a continuación, use los submenús para seleccionar la métrica:
      1. En el menú Recursos activos, selecciona Contenedor de Kubernetes.
      2. En el menú Categorías de métricas activas, selecciona Anthos.
      3. En el menú Métricas activas, selecciona etcd_network_client_grpc_sent_bytes_total.
      4. Haz clic en Aplicar.
    Mejoras y 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 desbordado por el tráfico que consiste en tokens JWT caducados reenviados 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 fallos, deja de responder y de atender más solicitudes. Este problema provoca latencias más altas en el plano de control.

    Este problema se ha solucionado en las siguientes versiones de Google Distributed Cloud:

    • 1.12.6+
    • 1.13.6+
    • 1.14.2+

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

    1. Comprueba si se puede acceder al endpoint de Identity Service for GKE 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 '{}'

      Sustituye CLUSTER_ENDPOINT por la IP virtual del plano de control y el puerto del balanceador de carga del plano de control de tu clúster (por ejemplo, 172.16.20.50:443).

      Si te afecta este problema, el comando devolverá un código de estado 400. Si la solicitud agota el tiempo de espera, reinicia el ais pod y vuelve a ejecutar el comando curl para ver si se soluciona el problema. Si recibes el código de estado 000, significa que el problema se ha resuelto y ya puedes dejar de hacer cambios. Si sigues recibiendo un código de estado 400, significa que el servidor HTTP de Identity Service para GKE no se está iniciando. En ese caso, continúa.

    2. Consulta los registros de GKE Identity Service y kube-apiserver:
      1. Consulta 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 este problema te afecta:

        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. Consulta 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 indicado.

        Clúster de administrador:

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

        Clúster de usuarios:

        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 este problema te afecta:

        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

    Si no puedes actualizar tus clústeres inmediatamente para obtener la corrección, puedes identificar y reiniciar los pods que causan el problema como solución alternativa:

    1. Aumenta el nivel de detalle de Identity Service de GKE a 9: 
      kubectl patch deployment ais -n anthos-identity-service --type=json \
    -p='[{"op": "add", "path": "/spec/template/spec/containers/0/args/-", \
    "value":"--vmodule=cloud/identity/hybrid/charon/*=9"}]' \
    --kubeconfig KUBECONFIG
    2. Consulta el registro de Identity Service for GKE para ver el contexto del token no válido: 
      kubectl logs -f -l k8s-app=ais -n anthos-identity-service \
    --kubeconfig KUBECONFIG
    3. Para obtener la carga útil del token asociada a 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, copia el token en el depurador de jwt.io.
    5. Reinicia los pods identificados a partir de los tokens.
    Operación 1.8, 1.9 y 1.10

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


    Solución alternativa:

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

    Opción 2: Si usas una versión de parche anterior a la 1.9.6 y la 1.10.3, debes reducir la escala del pod etcd-maintenance del clúster de administrador y del clúster de usuario:

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

    Tanto el controlador de estado del clúster como el comando gkectl diagnose cluster realizan un conjunto de comprobaciones del estado, incluidas las comprobaciones del estado de los pods en todos los espacios de nombres. Sin embargo, empiezan a omitir los pods del plano de control de 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á a ninguna carga de trabajo ni a la gestión de clústeres. Si quieres comprobar 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
    Mejoras y actualizaciones 1.6+, 1.7+

    Las actualizaciones de clústeres de administrador de las versiones 1.6 y 1.7 pueden verse afectadas por la redirección de k8s.gcr.io a registry.k8s.io

    Kubernetes redirigió el tráfico de k8s.gcr.io a registry.k8s.io el 20/3/2023. En Google Distributed Cloud 1.6.x y 1.7.x, las actualizaciones del clúster de administrador usan la imagen de contenedor k8s.gcr.io/pause:3.2. Si usas un proxy para tu estación de trabajo de administrador y el proxy no permite registry.k8s.io y la imagen de contenedor k8s.gcr.io/pause:3.2 no está almacenada en caché localmente, las actualizaciones del clúster de administrador fallarán al extraer la imagen de contenedor.


    Solución alternativa:

    Añade registry.k8s.io a la lista de permitidos del proxy de tu estación de trabajo de administrador.
    Redes 1.10, 1.11, 1.12.0-1.12.6, 1.13.0-1.13.6 y 1.14.0-1.14.2

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

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

    Esto se debe a que el archivo de grupo de balancín ya existe. La comprobación previa al vuelo intenta validar un balanceador de carga de seesaw que no existe.

    Solución alternativa:

    Elimina el archivo de grupo de balancín de 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 el clúster de usuario.
    Redes 1,14

    La versión 1.14 de Google Distributed Cloud es vulnerable a los fallos de inserción de la tabla de seguimiento de conexiones (conntrack) de netfilter cuando se usan imágenes del sistema operativo Ubuntu o COS. Los errores de inserción provocan que se agote el tiempo de espera de la aplicación de forma aleatoria y pueden producirse incluso cuando la tabla conntrack tiene espacio para nuevas entradas. Los errores se deben a cambios en el kernel 5.15 y versiones posteriores, que restringen las inserciones de tablas en función de la longitud de la cadena.

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

    sudo conntrack -S

    La respuesta tiene este aspecto:

    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 el valor de chaintoolong de la respuesta es un número distinto de cero, significa que te afecta este problema.

    Solución

    La medida de mitigación a corto plazo consiste en aumentar el tamaño de la tabla 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

    Sustituye TABLE_SIZE por el nuevo tamaño en bytes. El valor predeterminado del tamaño de la tabla es 262144. Te recomendamos que asignes un valor igual a 65.536 veces el número de núcleos del nodo. Por ejemplo, si tu nodo tiene ocho núcleos, define el tamaño de la tabla en 524288.
    Redes 1.13.0-1.13.2

    Si Controlplane V2 está habilitado, calico-typha o anetd-operator se pueden programar en nodos de Windows y entrar en un bucle de fallos.

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


    Solución alternativa:

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

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

    Añade 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 comprobación previa falle y se muestre el siguiente mensaje: 

    [FAILURE] Docker registry access: Failed to login.


    Solución alternativa:

    • Si no tenías intención de especificar el campo o quieres usar la misma credencial de registro privado que el clúster de administrador, puedes eliminar o comentar la sección privateRegistry en el archivo de configuración del clúster de usuario.
    • Si quieres usar una credencial de registro privado específica para tu clúster de usuario, puedes especificar temporalmente la sección privateRegistry de esta forma: 
      privateRegistry:
  address: PRIVATE_REGISTRY_ADDRESS
  credentials:
    username: PRIVATE_REGISTRY_USERNAME
    password: PRIVATE_REGISTRY_PASSWORD
  caCertPath: PRIVATE_REGISTRY_CACERT_PATH
       (NOTE Esta es solo una solución temporal y estos campos ya están obsoletos. Te recomendamos que uses el archivo de credenciales al actualizar a la versión 1.14.3 o posterior).

    Operaciones 1.10+

    Dataplane V2 se encarga del balanceo de carga y crea un socket de kernel en lugar de una DNAT basada en paquetes. Esto significa que Cloud Service Mesh no puede inspeccionar paquetes, ya que el pod se omite y nunca usa IPTables.

    En el modo libre de kube-proxy, esto se manifiesta con la pérdida de conectividad o el enrutamiento incorrecto del tráfico de los servicios con Cloud Service Mesh, ya que el sidecar no puede inspeccionar los paquetes.

    Este problema se produce en todas las versiones de Google Distributed Cloud 1.10, pero algunas versiones más recientes de 1.10 (1.10.2 o posteriores) tienen una solución alternativa.


    Solución alternativa:

    Actualiza a la versión 1.11 para disfrutar de una compatibilidad total o, si tienes la versión 1.10.2 o una posterior, ejecuta el siguiente comando:

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

    Añade bpf-lb-sock-hostns-only: true al mapa de configuración y, a continuación, reinicia el conjunto de demonios anetd:

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

    Almacenamiento 1.12+, 1.13.3

    kube-controller-manager puede agotar el tiempo de espera al separar PV/PVCs después de 6 minutos y separar los PV/PVCs de forma forzada. Registros detallados de kube-controller-manager que 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, inicia sesión en el nodo y ejecuta los siguientes comandos:

    # See all the mounting points with disks
lsblk -f

# See some ext4 errors
sudo dmesg -T

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

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

    Solución alternativa:

    Conéctate al nodo afectado mediante SSH y reinícialo.
    Mejoras y actualizaciones 1.12+, 1.13+, 1.14+

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

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


    Solución alternativa:

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

    El nodo maestro de administrador creado mediante gkectl repair admin-master puede usar una versión de hardware de VM inferior a la esperada. Cuando se produzca el problema, verás el error en el informe gkectl diagnose cluster. 

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


    Solución alternativa:

    Apaga el nodo maestro de administrador, sigue las instrucciones de 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, a continuación, inicia el nodo.
    Sistema operativo 1.10+, 1.11+, 1.12+, 1.13+, 1.14+, 1.15+, 1.16+, 1.28+, 1.29+, 1.30+, 1.31+, 1.32+

    En systemd v244, systemd-networkd tiene un cambio en el comportamiento predeterminado en la configuración de KeepConfiguration. Antes de este cambio, las máquinas virtuales no enviaban un mensaje de liberación de concesión de DHCP al servidor DHCP al apagarse o reiniciarse. Tras este cambio, las máquinas virtuales envían un mensaje de este tipo y devuelven las IPs al servidor DHCP. Por lo tanto, la IP liberada se puede reasignar a otra VM o se puede asignar otra IP a la VM, lo que provoca 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 formas.

    Por ejemplo, puedes observar los siguientes síntomas.

    • La interfaz de usuario de vCenter muestra que ninguna VM usa la misma IP, pero kubectl get nodes -o wide devuelve nodos con IPs 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 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:

    Despliega el siguiente DaemonSet en el clúster para revertir el cambio de comportamiento predeterminado de systemd-networkd. Las VMs que ejecuten este DaemonSet no liberarán las IPs al servidor DHCP al apagarse o reiniciarse. El servidor DHCP liberará las IPs automáticamente cuando caduquen las concesiones. 

          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, Mejoras y 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 que se creen después de la versión 1.12.

    Después de actualizar un clúster de la versión 1.11.x a la 1.12.x, el campo component-access-sa-key del secreto admin-cluster-creds se borrará y quedará vacío. Para comprobarlo, 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 la clave se ha borrado.

    Una vez que se haya eliminado la clave de cuenta de servicio de acceso a componentes, no se podrán instalar clústeres de usuario nuevos ni actualizar los que ya haya. A continuación se enumeran algunos de los mensajes de error que pueden aparecer:

    • Fallo de comprobación previa de validación lenta. Mensaje de error: "Failed to create the test VMs: failed to get service account key: service account is not configured."
    • No se ha podido preparar el archivo gkectl prepare. Mensaje de error: "Failed to prepare OS images: dialing: unexpected end of JSON input"
    • Si actualizas un clúster de usuario de la versión 1.13 mediante la consola o la CLI de gcloud, cuando ejecutes gkectl update admin --enable-preview-user-cluster-central-upgrade para implementar el controlador de plataforma actualizado, el comando fallará y se mostrará el mensaje: "failed to download bundle to disk: dialing: unexpected end of JSON input" (puedes ver este mensaje en el campo status en la salida de kubectl --kubeconfig ADMIN_KUBECONFIG -n kube-system get onprembundle -oyaml). Google Cloud


    Solución alternativa:

    Vuelve a añadir manualmente la clave de la cuenta de servicio de acceso al componente al secreto ejecutando el siguiente comando: 

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

    Operación 1.13.0+, 1.14.0+

    En el caso de los clústeres de usuario creados con Controlplane V2 habilitado, los grupos de nodos con autoescalado habilitado siempre usan su autoscaling.minReplicas en user-cluster.yaml. El registro del pod 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 de autoescalado de clústeres, 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 autoescalado 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 la notación CIDR en el archivo de bloqueo de IP, la validación de la configuración falla y se muestra 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:

    Incluya IPs individuales en el archivo de bloqueo de IPs hasta que actualice a una versión con la corrección: 1.12.5, 1.13.4, 1.14.1 o posterior.
    Mejoras y actualizaciones 1.14.0-1.14.1

    Cuando Updating control plane OS image type en admin-cluster.yaml y si su clúster de usuario correspondiente se creó con enableControlplaneV2 definido como true, es posible que las máquinas del plano de control de usuario no completen su recreación cuando finalice el comando gkectl.


    Solución alternativa:

    Una vez que se haya completado la actualización, sigue esperando a que las máquinas del plano de control de usuario también terminen de recrearse. Para ello, monitoriza sus tipos de imagen del SO de los nodos con kubectl --kubeconfig USER_KUBECONFIG get nodes -owide. Por ejemplo, si se actualiza de Ubuntu a COS, debemos esperar a que todos los equipos 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 provoca que la creación y la eliminación de pods fallen con el siguiente mensaje de error en la salida de kubectl describe pods:

      error getting ClusterInformation: connection is unauthorized: Unauthorized

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

    Los clústeres de administrador siempre usan Calico, mientras que, en el caso de los clústeres de usuario, hay un campo de configuración `enableDataPlaneV2` en user-cluster.yaml. Si ese campo tiene el valor `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 archivo kubeconfig con un token que es válido durante 24 horas. El pod calico-node debe renovar este token periódicamente. 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 actualizarlo de inmediato, aplica el siguiente parche en el calico-node DaemonSet 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 -
    Sustituye lo siguiente:
    • ADMIN_CLUSTER_KUBECONFIG: la ruta del archivo kubeconfig del clúster de administrador.
    • USER_CLUSTER_CONFIG_FILE: la ruta del archivo de configuración de tu clúster de usuarios.
    Instalación 1.12.0-1.12.4, 1.13.0-1.13.3, 1.14.0

    No se puede crear el clúster aunque el usuario tenga la configuración adecuada. El usuario ve que la creación falla porque el clúster no tiene suficientes IPs.


    Solución alternativa:

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

    Operación, Mejoras y Actualizaciones 1.11.0 - 1.11.1, 1.10.0 - 1.10.4, 1.9.0 - 1.9.6

    Si la función de encriptado de secretos siempre activo está habilitada junto con la copia de seguridad del clúster, la copia de seguridad del clúster de administrador no incluirá las claves de encriptado ni la configuración que requiere la función de encriptado de secretos siempre activo. Por lo tanto, al reparar el administrador principal con esta copia de seguridad mediante gkectl repair admin-master --restore-from-backup, se produce el siguiente error: 

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

    Operación, Mejoras y Actualizaciones 1.10+

    Si la función de cifrado de secretos siempre activo no está habilitada al crear el clúster, pero se habilita más adelante mediante la operación gkectl update, gkectl repair admin-master no puede reparar el nodo del plano de control del clúster de administrador. Se recomienda habilitar la función de encriptado de secretos siempre activo al crear el clúster. No hay ninguna medida de mitigación.

    Mejoras y actualizaciones 1.10

    Si actualizas el primer clúster de usuario de la versión 1.9 a la 1.10, es posible que se vuelvan a crear nodos en otros clústeres de usuario del mismo clúster de administrador. La recreación se realiza de forma continua.

    Se ha retirado disk_label de MachineTemplate.spec.template.spec.providerSpec.machineVariables, lo que ha provocado una actualización inesperada en todos los MachineDeployment.


    Solución alternativa:
    Mejoras y actualizaciones 1.10.0

    Si actualizas un clúster de usuarios a la versión 1.10.0, es posible que Docker se reinicie con frecuencia.

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

    Una condición de nodo mostrará si el reinicio de Docker es frecuente. Aquí tienes un ejemplo de resultado:

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

    Para determinar la causa raíz, debes conectarte mediante SSH al nodo que presenta el síntoma y ejecutar comandos como sudo journalctl --utc -u docker o sudo journalctl -x.


    Solución alternativa:
    Mejoras y actualizaciones 1.11 y 1.12

    Si utilizas una versión de Google Distributed Cloud anterior a la 1.12 y has configurado manualmente los componentes de Prometheus gestionado por Google (GMP) en el espacio de nombres gmp-system de 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 del espacio de nombres gmp-system y los CRDs los gestiona el objeto stackdriver, con la marca enableGMPForApplications definida como false de forma predeterminada. Si implementas manualmente componentes de GMP en el espacio de nombres antes de actualizar a la versión 1.12, stackdriver eliminará los recursos.


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

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

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


    Solución alternativa:

    Puedes ejecutar manualmente los siguientes comandos para recoger 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 usuarios.
    Mejoras y actualizaciones 1.11.0-1.11.4, 1.12.0-1.12.3, 1.13.0-1.13.1

    Cuando se elimina, actualiza o cambia a un plan superior un clúster de usuarios, el drenaje de nodos puede quedarse bloqueado en los siguientes casos:

    • El clúster de administrador ha estado usando el controlador de CSI para vSphere en vSAN desde la versión 1.12.x.
    • Los complementos de vSphere insertados no crean objetos PVC/PV en el clúster de administrador ni en el 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 del controlador insertado de vSphere. Si no se han creado objetos PVC o PV, puede que se produzca un error que impida que se complete el drenaje de nodos al buscar kubevols, ya que la implementación actual presupone que kubevols siempre existe.


    Solución alternativa:

    Crea el directorio kubevols en el almacén de datos donde se crea el nodo. 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 elimina un clúster de usuarios, también se eliminan los clusterrole y clusterrolebinding correspondientes de escalado automático de clústeres. Esto afecta a todos los demás clústeres de usuarios del mismo clúster de administrador en los que esté habilitada la herramienta de ajuste automático de escala de clústeres. Esto se debe a que se usan el mismo rol de clúster y el mismo enlace de rol de clúster para todos los pods de la herramienta de escalado automático de clústeres del mismo clúster de administrador.

    Los síntomas son los siguientes:

    • Registros de 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. Aquí tienes un ejemplo de los mensajes de error que pueden aparecer: 
      2023-03-26T10:45:44.866600973Z W0326 10:45:44.866463       1 reflector.go:424] k8s.io/client-go/dynamic/dynamicinformer/informer.go:91: failed to list *unstructured.Unstructured: onpremuserclusters.onprem.cluster.gke.io is forbidden: User "..." cannot list resource "onpremuserclusters" in API group "onprem.cluster.gke.io" at the cluster scope
2023-03-26T10:45:44.866646815Z E0326 10:45:44.866494       1 reflector.go:140] k8s.io/client-go/dynamic/dynamicinformer/informer.go:91: Failed to watch *unstructured.Unstructured: failed to list *unstructured.Unstructured: onpremuserclusters.onprem.cluster.gke.io is forbidden: User "..." cannot list resource "onpremuserclusters" in API group "onprem.cluster.gke.io" at the cluster scope

    Solución alternativa:

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

    Al eliminar un clúster de usuario, también se elimina el clusterrole correspondiente, lo que provoca que la reparación automática y el exportador de métricas de vSphere no funcionen.

    Los síntomas son los siguientes:

    • Registros de 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. Aquí tienes un ejemplo de los mensajes de error que pueden aparecer: 
      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 de 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. Aquí tienes un ejemplo de los mensajes de error que pueden aparecer: 
      vsphere-metrics-exporter/cmd/vsphere-metrics-exporter/main.go:68: Failed to watch *v1alpha1.Cluster: failed to list *v1alpha1.Cluster: clusters.cluster.k8s.io is forbidden: User "system:serviceaccount:kube-system:vsphere-metrics-exporter" cannot list resource "clusters" in API group "cluster.k8s.io" in the namespace "default"

    Solución alternativa:

    Configuración 1.12.1-1.12.3, 1.13.0-1.13.2

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

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

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

    Solución alternativa:

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

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

    Un problema conocido que podía provocar un error en gkectl update admin/cluster al actualizar anti affinity groups.

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

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

    Solución alternativa:
    Instalación, actualizaciones y mejoras 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 de nodos cuando ipMode.type es static y el nombre de host configurado en el archivo de bloque de IPs contiene uno o más puntos. En este caso, las solicitudes de firma de certificado (CSR) de un nodo no se aprueban automáticamente.

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

    kubectl get csr -A -o wide

    Comprueba si hay mensajes de error en los siguientes registros:

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

    Si especifica un nombre de dominio en el campo de nombre de host de un archivo de bloque de IP, se ignorarán los caracteres que haya después del primer punto. Por ejemplo, si especificas el nombre de host como bob-vm-1.bank.plc, el nombre de host de la VM y el nombre del nodo se definirán como bob-vm-1.

    Cuando la verificación del ID de nodo está habilitada, el aprobador de CSR compara el nombre del nodo con el nombre de host de la especificación de la máquina y no puede conciliar el nombre. El aprobador rechaza la CSR y el nodo no puede iniciarse.


    Solución alternativa:

    Clúster de usuarios

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

    1. Añade los siguientes campos al archivo de configuración de tu clúster de usuarios: 
      disableNodeIDVerification: true
disableNodeIDVerificationCSRSigning: true
    2. Guarda el archivo y actualiza el clúster de usuario ejecutando el siguiente comando: 
      gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config USER_CLUSTER_CONFIG_FILE
       Sustituye lo siguiente:
      • ADMIN_CLUSTER_KUBECONFIG: la ruta del archivo kubeconfig del clúster de administrador.
      • USER_CLUSTER_CONFIG_FILE: la ruta del archivo de configuración de tu clúster de usuarios.

    Clúster de administrador

    1. Abre el recurso personalizado OnPremAdminCluster para editarlo: 
      kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    edit onpremadmincluster -n kube-system
    2. Añade 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. Conéctate mediante 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 Deployment Cluster 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 por false: 
      --node-id-verification-enabled=false
--node-id-verification-csr-signing-enabled=false
    Instalación, actualizaciones y mejoras 1.11.0-1.11.4

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

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

    En la versión 1.11 de la documentación, el registro del controlador de la API de clúster en la captura de clúster externo incluye el siguiente registro:

    Invalid value 'XXXX' specified for property startup-data

    A continuación, se muestra un ejemplo de ruta de archivo del registro del controlador de la API Cluster:

    kubectlCommands/kubectl_logs_clusterapi-controllers-c4fbb45f-6q6g6_--container_vsphere-controller-manager_--kubeconfig_.home.ubuntu..kube.kind-config-gkectl_--request-timeout_30s_--namespace_kube-system_--timestamps
    
    VMware has a 64k vApp property size limit. In the identified versions,
    the data passed via vApp property is close to the limit. When the private
    registry certificate contains a certificate bundle, it may cause the final
    data to exceed the 64k limit.
    
    
    Workaround:
    
    
    Only include the required certificates in the private registry
    certificate file configured in privateRegistry.caCertPath in
    the admin cluster config file.
    
    
    Or upgrade to a version with the fix when available.
    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 impide que el controlador asigne IPs flotantes adicionales al nodo. Esto puede provocar una mayor carga en otros nodos o una falta de redundancia para conseguir una alta disponibilidad.

    Por lo demás, la actividad del plano de datos no se ve afectada.

    La contención en el objeto networkgatewaygroup provoca que algunas actualizaciones de estado fallen debido a un error en la gestión de reintentos. Si fallan demasiadas actualizaciones de estado, ang-controller-manager considera que el nodo ha superado el límite de tiempo de latido y lo marca como NotHealthy.

    El fallo en la gestión de reintentos se ha corregido en versiones posteriores.


    Solución alternativa:

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

    Un problema conocido que podría provocar que la actualización del clúster se quede bloqueada mientras espera a que se elimine el objeto de la máquina antigua. Esto se debe a que el finalizador no se puede quitar del objeto de la máquina. Esto afecta a cualquier operación de actualización gradual de grupos de nodos.

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

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

    En los registros de pods de clusterapi-controller, los errores son como los que se muestran a continuación:

    $ 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 en ejecuciones correctas, incluso sin este problema. La mayoría de las veces, el proceso se completa rápidamente, pero en algunos casos excepcionales puede quedarse bloqueado en esta condición de carrera durante varias horas.

    El problema es que la VM subyacente ya se ha eliminado en vCenter, pero el objeto de máquina correspondiente no se puede eliminar, que está bloqueado en la eliminación del finalizador debido a las actualizaciones muy frecuentes de otros controladores. Esto puede provocar que el comando gkectl agote el tiempo de espera, pero el controlador sigue conciliando el clúster, por lo que el proceso de actualización se completa.


    Solución alternativa:

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

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

      Según el análisis y la reproducción en tu entorno, la actualización puede completarse por sí sola sin ninguna intervención manual. El inconveniente de esta opción es que no se sabe cuánto tiempo tardará en completarse la eliminación del finalizador de cada objeto de máquina. Puede completarse inmediatamente si tienes suerte o durar varias horas si la conciliación del controlador de conjunto de máquinas es demasiado rápida y el controlador de máquinas nunca tiene la oportunidad de eliminar el finalizador entre las conciliaciones.

      Lo bueno es que no tienes que hacer nada y las cargas de trabajo no se verán interrumpidas. Solo necesita más tiempo para completar la actualización.
    • Opción 2: Aplica la anotación de reparación automática a todos los objetos de la máquina antigua.

      El controlador de conjunto 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 distinta de cero, y no seguirá emitiendo llamadas de eliminación en esas máquinas, lo que puede ayudar a evitar la condición de carrera.

      La desventaja es que los pods de las máquinas se eliminarán directamente en lugar de expulsarse, lo que significa que no se respetará la configuración de PDB. Esto podría provocar un tiempo de inactividad en tus cargas de trabajo.

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

    Si te encuentras con este problema y la actualización o la mejora no se pueden completar después de un tiempo prolongado, ponte en contacto con nuestro equipo de Asistencia para obtener soluciones.
    Instalación, actualizaciones y mejoras 1.10.2, 1.11, 1.12 y 1.13

    El comando gkectl prepare ha fallado con el siguiente error:

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

    Las comprobaciones 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 ha podido crear el clúster de administrador:

    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 administración o del clúster de usuario.
    Instalación, actualizaciones y mejoras 1.10, 1.11, 1.12 y 1.13

    gkectl prepare puede fallar con el siguiente stacktrace:

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

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

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


    Solución alternativa:

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

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

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


    Solución alternativa:

    Si ya te has encontrado con este error, ponte en contacto con el equipo de Asistencia.
    Mejoras y actualizaciones 1.10 y 1.11

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


    Solución alternativa:

    La plantilla de máquina virtual del plano de control del administrador se volverá a generar durante la próxima actualización del clúster del administrador.
    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 provocar 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 publique.
    Identidad 1.10, 1.11, 1.12 y 1.13

    gkectl update revierte los cambios manuales que hayas hecho en el recurso personalizado ClientConfig.


    Solución alternativa:

    Te recomendamos que hagas 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 no se encuentran las particiones de F5 BIG-IP, aunque existan.

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


    Solución alternativa:

    Prueba a ejecutar gkectl check-config de nuevo.
    Instalación 1.12

    Es posible que se produzca un error de instalación debido a que cert-manager-cainjector está en un bucle de fallos cuando el apiserver o etcd va lento:

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

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

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

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

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

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

    Si se reinicia vCenter en versiones anteriores a la 7.0U2, después de una actualización o por cualquier otro motivo, el nombre de la red en la información de la máquina virtual de vCenter será incorrecto y la máquina estará en estado Unavailable. Esto lleva a que los nodos se reparen automáticamente para crear otros nuevos.

    Error relacionado con govmomi.


    Solución alternativa:

    Esta solución alternativa la proporciona el equipo de asistencia de VMware:

    1. El problema se ha solucionado en las versiones 7.0U2 y posteriores de vCenter.
    2. En versiones anteriores, haz clic con el botón derecho en el host y, a continuación, selecciona Conexión > Desconectar. A continuación, vuelve a conectarte para forzar una actualización del grupo de puertos de la máquina virtual.
    Sistema operativo 1.10, 1.11, 1.12 y 1.13

    En Google Distributed Cloud versión 1.7.2 y posteriores, las imágenes del SO Ubuntu se han reforzado con CIS L1 Server Benchmark.

    Para cumplir la regla 5.2.16 de CIS "Ensure SSH Idle Timeout Interval is configured", /etc/ssh/sshd_config tiene los siguientes ajustes:

    ClientAliveInterval 300
ClientAliveCountMax 0

    El objetivo de estos ajustes es finalizar una sesión de cliente después de 5 minutos de inactividad. Sin embargo, el valor de ClientAliveCountMax 0 provoca un comportamiento inesperado. Cuando usas la sesión de SSH en la estación de trabajo del administrador o en un nodo de clúster, la conexión SSH puede desconectarse aunque el cliente de SSH no esté inactivo, por ejemplo, al ejecutar un comando que requiere mucho tiempo. En ese caso, el comando podría finalizarse con el siguiente mensaje:

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

    Solución alternativa:

    A continuación, dispones de las siguientes opciones:

    • Usa nohup para evitar que tu comando se termine al desconectarse por 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 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 algún motivo, necesitas instalar tu propio cert-manager, sigue estas instrucciones para evitar conflictos:

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

    Nota: Uno de los síntomas habituales de instalar tu propio cert-manager es que la versión o la imagen de cert-manager (por ejemplo, v1.7.2) puede volver a una versión anterior. Esto se debe a que monitoring-operator intenta conciliar la cert-manager y revierte la versión durante el proceso.

    Solución alternativa:

    <pEvitar conflictos durante la actualización

    1. Desinstala tu versión de cert-manager. Si has definido tus propios recursos, puede que quieras crear una copia de seguridad de ellos.
    2. Realiza la actualización.
    3. Sigue las instrucciones que se indican a continuación para restaurar tu propia cert-manager.

    Restaurar tu propio cert-manager en clústeres de usuarios

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

    Restaurar tu propio cert-manager en clústeres de administrador

    Por lo general, no es necesario 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 estas instrucciones para evitar conflictos. Ten en cuenta que, si eres cliente de Apigee y solo necesitas cert-manager para Apigee, no tienes que ejecutar los comandos del clúster de administrador.

    • Escala el despliegue de monitoring-operator a 0. 
      kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    -n kube-system scale deployment monitoring-operator --replicas=0
    • Escala a 0 los despliegues de cert-manager gestionados por monitoring-operator. 
      kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    -n cert-manager scale deployment cert-manager \
    --replicas=0

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

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

    Las versiones de Docker, containerd y runc de las imágenes del SO Ubuntu enviadas con Google Distributed Cloud se fijan en versiones especiales mediante Ubuntu PPA. De esta forma, nos aseguramos de que Google Distributed Cloud valide cualquier cambio en el tiempo de ejecución del contenedor antes de cada lanzamiento.

    Sin embargo, el Ubuntu CVE Tracker, que utilizan varias herramientas de análisis de CVE como fuentes de vulnerabilidades, no conoce las versiones especiales. 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 CVEs. Estas CVEs ya se han corregido en las versiones de parche más recientes de Google Distributed Cloud.

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


    Solución alternativa:

    Canonical es consciente de este problema y se está monitorizando la solución en https://github.com/canonical/sec-cvescan/issues/73.
    Mejoras y actualizaciones 1.10, 1.11, 1.12 y 1.13

    Si actualizas clústeres que no son de alta disponibilidad de la versión 1.9 a la 1.10, es posible que observes que kubectl exec, kubectl log y el webhook de los clústeres de usuarios no estén disponibles durante un breve periodo. Este tiempo de inactividad puede durar hasta un minuto. Esto ocurre porque kube-apiserver gestiona la solicitud entrante (kubectl exec, kubectl log y webhook) del clúster de usuario. El usuario kube-apiserver es un StatefulSet. En un clúster que no es de alta disponibilidad, solo hay una réplica del StatefulSet. Por lo tanto, durante la actualización, es posible que el antiguo kube-apiserver no esté disponible mientras que el nuevo kube-apiserver aún no esté listo.


    Solución alternativa:

    Este tiempo de inactividad solo se produce durante el proceso de actualización. Si quieres que el tiempo de inactividad durante la actualización sea menor, te recomendamos que cambies a clústeres de alta disponibilidad.
    Instalación, actualizaciones y mejoras 1.10, 1.11, 1.12 y 1.13

    Si estás creando o actualizando un clúster de alta disponibilidad y observas que la comprobación de disponibilidad de konnectivity ha fallado en el diagnóstico del clúster, en la mayoría de los casos no afectará a la funcionalidad de Google Distributed Cloud (kubectl exec, kubectl log y webhook). Esto ocurre porque, a veces, una o dos réplicas de konnectivity pueden no estar listas durante un periodo debido a una red inestable u otros problemas.


    Solución alternativa:

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

    A partir de la versión 1.7.2 de Google Distributed Cloud, las imágenes del SO Ubuntu se han reforzado con el benchmark de servidor de nivel 1 de CIS.

    Como resultado, se ha instalado la secuencia de comandos cron /etc/cron.daily/aide para que se programe una comprobación aide con el fin de asegurar que se sigue la regla "1.4.2 Ensure filesystem integrity is regularly checked" (Asegurar que la integridad del sistema de archivos se comprueba periódicamente) del servidor CIS L1.

    La tarea cron se ejecuta a diario a las 6:25 (UTC). En función del número de archivos del sistema de archivos, es posible que experimentes picos de uso de CPU y memoria en ese momento, causados por este proceso aide.


    Solución alternativa:

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

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

    Al implementar Google Distributed Cloud versión 1.9 o posterior, si la implementación tiene el balanceador de carga empaquetado de Seesaw en un entorno que usa reglas de firewall distribuidas con estado de NSX-T, es posible que stackdriver-operator no pueda crear gke-metrics-agent-conf ConfigMap y que los pods de gke-connect-agent entren en un bucle de fallos.

    El problema subyacente es que las reglas del cortafuegos distribuido con reconocimiento del estado de NSX-T terminan la conexión de un cliente al servidor de la API del clúster de usuario a través del balanceador de carga Seesaw, ya que 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 observes problemas de conexión similares en tus aplicaciones cuando creen objetos de Kubernetes grandes cuyo tamaño sea superior a 32 KB.


    Solución alternativa:

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

    Si tus clústeres usan un balanceador de carga manual, sigue estas instrucciones para configurar el balanceador de carga de forma que restablezca las conexiones de los clientes cuando detecte un fallo en un nodo de backend. Sin esta configuración, es posible que los clientes del servidor de la API de Kubernetes dejen de responder durante varios minutos cuando una instancia del servidor deje de funcionar.
    Almacenamiento de registros y monitorización 1.10, 1.11, 1.12, 1.13, 1.14 y 1.15

    En las versiones de Google Distributed Cloud de la 1.10 a la 1.15, algunos clientes han detectado una facturación inesperadamente alta de Metrics volume en la página Facturación. Este problema solo te afecta si se dan todas las circunstancias siguientes:

    • El almacenamiento de registros y la monitorización de aplicaciones están habilitados (enableStackdriverForApplications=true)
    • Los pods de aplicaciones tienen la anotación prometheus.io/scrap=true. (Al instalar Cloud Service Mesh, también se puede añadir esta anotación).

    Para confirmar si te afecta este problema, consulta tus métricas definidas por el usuario. Si ve que se le factura por métricas no deseadas con el prefijo de nombre external.googleapis.com/prometheus y también ve que enableStackdriverForApplications tiene el valor "true" en la respuesta de kubectl -n kube-system get stackdriver stackdriver -o yaml, significa que este problema le afecta.


    Solución

    Si te afecta este problema, te recomendamos que actualices tus clústeres a la versión 1.12 o a una posterior, que dejes de usar la marca enableStackdriverForApplications y que cambies a la nueva solución de monitorizació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 puede controlar la recogida de registros y métricas por separado para sus 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

    Elimina la línea enableStackdriverForApplications: true, guarda los cambios y cierra el editor.

    Si no puede dejar de usar la recogida de métricas basada en anotaciones, siga estos pasos:

    1. Busca los pods y servicios de origen que tengan 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. Elimina la anotación prometheus.io/scrap=true del Pod o del Service. Si la anotación la añade la malla de servicios de Cloud, considera la posibilidad de configurar la malla de servicios de Cloud sin la opción de Prometheus o de 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 se vinculan en el nivel de permisos incorrecto.

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


    Solución alternativa:

    Si quiere vincular el rol personalizado a nivel de DC (o a un nivel inferior al raíz), también debe vincular el rol de solo lectura al usuario a nivel de vCenter raíz.

    Para obtener más información sobre la creación de roles, consulta Privilegios de las cuentas de usuario de vCenter.
    Almacenamiento de registros y monitorización 1.9.0-1.9.4, 1.10.0-1.10.1

    Es posible que observe un tráfico de red elevado hacia monitoring.googleapis.com, incluso en un clúster nuevo que no tenga cargas de trabajo de usuario.

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


    Solución alternativa:
    Almacenamiento de registros y monitorización 1.10 y 1.11

    En Google Distributed Cloud versión 1.10 y posteriores, el DaemonSet `gke-metrics-agent` tiene errores frecuentes de CrashLoopBackOff cuando `enableStackdriverForApplications` se define como `true` en el objeto `stackdriver`.


    Solución alternativa:

    Para mitigar este problema, inhabilita la recogida de métricas de aplicaciones ejecutando los siguientes comandos. Estos comandos no inhabilitarán la recogida de registros de aplicaciones.

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

    Si se usan métricas obsoletas en tus paneles de control preconfigurados, verás algunos gráficos vacíos. Para encontrar métricas obsoletas en los paneles de control 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 métricas obsoletas que se indican a continuación deben migrarse a las métricas que las sustituyen.

    ObsoletoSustitución
    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 sustituir las métricas obsoletas

    1. Elimina "Estado del nodo de GKE On-Prem" en el panel de control de Google Cloud Monitoring. Vuelve a instalar "Estado del nodo de GKE On-Prem" siguiendo estas instrucciones.
    2. Elimina "Utilización de nodos de GKE On-Prem" en el panel de control de Google Cloud Monitoring. Vuelve a instalar "Utilización de nodos de GKE On-Prem" siguiendo estas instrucciones.
    3. Elimina "GKE on-prem vSphere vm health" (Estado de la VM de GKE On-Prem en vSphere) en el panel de control de Google Cloud Monitoring. Reinstala "GKE on-prem vSphere vm health" siguiendo estas instrucciones.

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

    En Google Distributed Cloud versión 1.10 y posteriores, los datos de los clústeres de Cloud Monitoring pueden contener entradas de métricas de resumen irrelevantes, como las siguientes:

    Unknown metric: kubernetes.io/anthos/go_gc_duration_seconds_summary_percentile

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

    :
    • apiserver_admission_step_admission_duration_seconds_summary
    • go_gc_duration_seconds
    • scheduler_scheduling_duration_seconds
    • gkeconnect_http_request_duration_seconds_summary
    • alertmanager_nflog_snapshot_duration_seconds_summary

    Aunque estas métricas de tipo resumen se incluyan en la lista de métricas, gke-metrics-agent no las admite por el momento.
    Almacenamiento de registros y monitorización 1.10, 1.11, 1.12 y 1.13

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

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

    Solución alternativa:

    Para solucionar este problema, sigue estos pasos: En las versiones [1.9.5+, 1.10.2+, 1.11.0]: aumenta la CPU de gke-metrics-agent siguiendo los pasos del 1 al 4.

    1. Abre el stackdriver recurso 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 y el límite de CPU de 100m a 200m, añade 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 tener un aspecto 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 comprobar que los cambios se han aplicado, ejecuta el siguiente comando: 
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    --namespace kube-system get daemonset gke-metrics-agent -o yaml \
    | grep "cpu: 50m"
       El comando busca cpu: 50m para comprobar si los cambios se han aplicado.
    Almacenamiento de registros y monitorización 1.11.0-1.11.2, 1.12.0

    Si tu clúster de administrador se ve afectado por este problema, faltarán las métricas del programador y del gestor 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 este problema afecta a tu clúster de usuarios, faltarán las métricas del programador y del gestor 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 ha solucionado en Google Distributed Cloud 1.13.0 y versiones posteriores. Actualiza el clúster a una versión que incluya la corrección.
    Instalación, actualizaciones y mejoras 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 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

    Podrás seguir usando este clúster de administrador, pero recibirás el siguiente error si intentas actualizarlo a la versión 1.10.y más adelante.

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

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

    Si usas la función Identity Service for GKE para gestionar ClientConfig de Identity Service for GKE, es posible que Connect Agent se reinicie de forma inesperada.


    Solución alternativa:

    Si has tenido este problema con un clúster, puedes hacer una de las siguientes acciones:

    • Inhabilita el servicio de identidad de GKE. Si inhabilitas GKE Identity Service, no se eliminará el archivo binario de GKE Identity Service implementado ni el archivo ClientConfig de GKE Identity Service. Para inhabilitar Identity Service para GKE, ejecuta este comando: 
      gcloud container fleet identity-service disable \
    --project PROJECT_ID
       Sustituye PROJECT_ID por el ID del proyecto host de la flota.
    • 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 alternativa es inhabilitar el aprendizaje de IP añadiendo la dirección IP de Seesaw como IP virtual de las capas 4 a 7 en el controlador de infraestructura de políticas de aplicaciones (APIC) de Cisco.

    Para configurar la opción de IP virtual de las capas 4 a 7, vaya a Tenant > Application Profiles > Application EPGs (Cliente > Perfiles de aplicación > EPGs de aplicación) o uSeg EPGs (EPGs de uSeg). Si no se inhabilita el aprendizaje de IP, el endpoint de IP fluctuará entre diferentes ubicaciones en la estructura de la API de Cisco.
    VMware 1.10, 1.11, 1.12 y 1.13

    VMware ha detectado recientemente problemas críticos en las siguientes versiones de vSphere 7.0 Update 3:

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

    Solución alternativa:

    VMWare ha retirado estas versiones. Deberías actualizar ESXi y vCenter Server a una versión más reciente.
    Sistema operativo 1.10, 1.11, 1.12 y 1.13

    En los pods que se ejecutan en nodos que usan imágenes de Container-Optimized OS (COS), no puedes montar el volumen emptyDir como exec. Se monta como noexec y se produce 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

    En el Pod de prueba, si ejecutas mount | grep test-volume, se mostraría la opción noexec:

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

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

    Las réplicas del grupo de nodos no se actualizan una vez que se ha habilitado y inhabilitado el autoescalado en un grupo de nodos.


    Solución alternativa:

    Eliminar 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.
    Almacenamiento de registros y monitorización 1.11, 1.12 y 1.13

    Desde la versión 1.11, en los paneles de control de monitorización predefinidos, los paneles de control de estado de pod de Windows y de estado de nodo de Windows también muestran datos de clústeres de Linux. Esto se debe a que las métricas de los nodos y los pods de Windows también se exponen en los clústeres de Linux.
    Almacenamiento de registros y monitorización 1.10, 1.11 y 1.12

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


    Solución alternativa:

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

    1. Para evitar este comportamiento inesperado, reduce la escala stackdriver-log-forwarder: 
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    -n kube-system patch daemonset stackdriver-log-forwarder -p '{"spec": {"template": {"spec": {"nodeSelector": {"non-existing": "true"}}}}}'
       Sustituye USER_CLUSTER_KUBECONFIG por la ruta del archivo kubeconfig del clúster de usuario.
    2. Despliega 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 ha limpiado todos los fragmentos, puedes ejecutar los siguientes comandos. La salida de los dos comandos debe ser igual al número de nodos del 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. Elimina 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"}]'
    Almacenamiento de registros y monitorización 1.10, 1.11, 1.12, 1.13, 1.14, 1.15 y 1.16

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

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

    Solución:

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

    1. Abre el stackdriver recurso para editarlo: 
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    --namespace kube-system edit stackdriver stackdriver
    2. Para aumentar la solicitud de CPU de stackdriver-log-forwarder , añade la siguiente sección resourceAttrOverride al archivo de 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 tener un aspecto 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 comprobar que los cambios se han aplicado, ejecuta el siguiente comando: 
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    --namespace kube-system get daemonset stackdriver-log-forwarder -o yaml \
    | grep "cpu: 1200m"
       El comando busca cpu: 1200m para comprobar si los cambios se han aplicado.
    Seguridad 1.13

    Hay un breve periodo en el que el nodo está listo, pero el certificado del servidor kubelet no lo está. kubectl exec y kubectl logs no están disponibles durante estos segundos. Esto se debe a que el nuevo aprobador del certificado de servidor tarda en ver las IPs válidas actualizadas del nodo.

    Este problema solo afecta al certificado de servidor de kubelet y no afectará a la programación de pods.
    Mejoras y actualizaciones 1.12

    No se ha podido actualizar el clúster de usuarios:

    .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 ha actualizado por completo y la versión de estado sigue siendo la 1.10. La actualización del clúster de usuario a la versión 1.12 no se bloqueará por ninguna comprobación previa y fallará debido a un problema de diferencia de versiones.


    Solución alternativa:

    Primero, actualiza el clúster de administrador a la versión 1.11 y, después, 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 ha fallado con el siguiente error: 

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

    La validación del espacio libre del almacén de datos no se debe usar en los grupos de nodos de clústeres que ya existen. Se añadió en gkectl diagnose cluster por error.


    Solución alternativa:

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

    Es posible que no puedas añadir un nuevo clúster de usuarios si tu clúster de administrador está configurado con un balanceador de carga de MetalLB.

    El proceso de eliminación del clúster de usuario puede quedarse bloqueado por algún motivo, lo que provoca que se invalide el ConfigMap de MetalLB. No será posible añadir un nuevo clúster de usuarios en este estado.


    Solución alternativa:

    Puedes eliminar por la fuerza 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 gkectl check-config se ejecuta después de crear el clúster de administrador y antes de crear el clúster de usuario, se producirá un error 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 que el 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.
    Almacenamiento de registros y monitorización 1.12.0-1.12.1

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

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

    Solución alternativa:
    Otro 1.11.3

    El comando gkectl repair admin-master ha fallado con el siguiente error: 

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

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


    Solución alternativa:

    Vuelve a ejecutar el comando con --skip-validation.
    Almacenamiento de registros y monitorización 1.11, 1.12, 1.13, 1.14, 1.15 y 1.16

    Registros de auditoría de Cloud necesita una configuración de permisos especial que actualmente solo se realiza automáticamente para los clústeres de usuarios a través de GKE Hub. Se recomienda tener al menos un clúster de usuarios que use el mismo ID de proyecto y la misma cuenta de servicio que el clúster de administrador para los registros de auditoría de Cloud, de modo que el clúster de administrador tenga el permiso necesario.

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

    Solución alternativa:
    Operación, seguridad 1.11

    Si tu estación de trabajo no tiene acceso a los nodos de trabajo del clúster de usuarios, se producirán los siguientes errores al ejecutar gkectl diagnose:

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

    Si tu estación de trabajo no tiene acceso a los nodos de trabajador del clúster de administración, se producirán los siguientes errores al ejecutar gkectl diagnose:

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

    Solución alternativa:

    Puedes ignorar estos mensajes.
    Sistema operativo 1.8, 1.9, 1.10, 1.11, 1.12 y 1.13

    /var/log/audit/ se rellena con registros de auditoría. Puedes comprobar el uso del disco ejecutando sudo du -h -d 1 /var/log/audit.

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

    Desde Google Distributed Cloud v1.8, la imagen de Ubuntu se ha reforzado con el benchmark de nivel 2 de CIS. Una de las reglas de cumplimiento, "4.1.2.2 Ensure audit logs are not automatically deleted" (4.1.2.2. Asegúrate de que los registros de auditoría no se eliminen automáticamente), asegura el ajuste de auditd max_log_file_action = keep_logs. De esta forma, todas las reglas de auditoría se conservarán en el disco.


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

    Los usuarios no pueden crear ni actualizar objetos NetworkGatewayGroup debido al siguiente error del 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 enlazarse erróneamente a una dirección IP flotante asignada al nodo e informarla como dirección de nodo en node.status.addresses. El webhook de validación comprueba las NetworkGatewayGroup direcciones IP flotantes 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 se produce un error al crear o actualizar 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 restaurar 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. Elimina el elemento vnetworkgatewaygroup.kb.io de la lista de configuración de webhook y cierra 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
    Instalación, actualizaciones y mejoras 1.10.0-1.10.2

    Durante un intento de actualización del clúster de administrador, la máquina virtual del plano de control del administrador puede quedarse bloqueada durante la creación. La máquina virtual del plano de control del administrador entra en un bucle de espera infinito durante el arranque y verás el siguiente error de bucle infinito en el archivo /var/log/cloud-init-output.log:

    + echo 'waiting network configuration is applied'
waiting network configuration is applied
++ get-public-ip
+++ ip addr show dev ens192 scope global
+++ head -n 1
+++ grep -v 192.168.231.1
+++ grep -Eo 'inet ([0-9]{1,3}\.){3}[0-9]{1,3}'
+++ awk '{print $2}'
++ echo
+ '[' -n '' ']'
+ sleep 1
+ echo 'waiting network configuration is applied'
waiting network configuration is applied
++ get-public-ip
+++ ip addr show dev ens192 scope global
+++ grep -Eo 'inet ([0-9]{1,3}\.){3}[0-9]{1,3}'
+++ awk '{print $2}'
+++ grep -v 192.168.231.1
+++ head -n 1
++ echo
+ '[' -n '' ']'
+ sleep 1

    Esto se debe a que, cuando Google Distributed Cloud intenta obtener la dirección IP del nodo en la secuencia de comandos de inicio, usa grep -v ADMIN_CONTROL_PLANE_VIP para omitir el VIP del plano de control del clúster de administrador, que también se puede asignar a la NIC. Sin embargo, el comando también omite cualquier dirección IP que tenga un prefijo de la IP virtual del plano de control, lo que provoca que el script de inicio se bloquee.

    Por ejemplo, supongamos que la IP virtual del plano de control del clúster de administrador es 192.168.1.25. Si la dirección IP de la VM de plano de control del clúster de administrador tiene el mismo prefijo (por ejemplo, 192.168.1.254), la VM de plano de control se quedará bloqueada durante la creación. Este problema también puede producirse si la dirección de difusión tiene el mismo prefijo que la IP virtual del plano de control. Por ejemplo, 192.168.1.255.


    Solución alternativa:

    • Si el motivo del tiempo de espera de la creación del clúster de administrador es la dirección IP de difusión, ejecuta el siguiente comando en la VM de plano de control del clúster de administrador: 
      ip addr add ${ADMIN_CONTROL_PLANE_NODE_IP}/32 dev ens192
       De esta forma, se creará una línea sin una dirección de difusión y se desbloqueará el proceso de arranque. Una vez que se haya desbloqueado la secuencia de comandos de inicio, elimina la línea que has añadido con el siguiente comando: 
      ip addr del ${ADMIN_CONTROL_PLANE_NODE_IP}/32 dev ens192
    • Sin embargo, si el motivo del tiempo de espera de la creación del clúster de administrador se debe a la dirección IP de la máquina virtual del plano de control, no puedes desbloquear la secuencia de comandos de inicio. Cambia a otra dirección IP y vuelve a crear o actualiza a la versión 1.10.3 o a una posterior.
    Sistema operativo, actualizaciones 1.10.0-1.10.2

    DataDisk no se puede montar correctamente en el nodo maestro del clúster de administrador cuando se usa la imagen de COS, y el estado del clúster de administrador que usa la imagen de COS se perderá al actualizar el clúster de administrador o al reparar el administrador. (el clúster de administración que usa la imagen de COS es una función de vista previa)


    Solución alternativa:

    Volver a crear el clúster de administrador con osImageType definido como ubuntu_containerd

    Después de crear el clúster de administrador con osImageType definido como cos, obtén la clave SSH del clúster de administrador y conéctate al nodo maestro del administrador mediante SSH. df -h contiene /dev/sdb1 98G 209M 93G 1% /opt/data. El resultado de lsblk contiene -sdb1 8:17 0 100G 0 part /opt/data
    Sistema operativo 1.10

    En la versión 1.10.0 de Google Distributed Cloud, las resoluciones de nombres en Ubuntu se dirigen de forma predeterminada a systemd-resolved local, que escucha en 127.0.0.53. Esto se debe a que, en la imagen de Ubuntu 20.04 utilizada en la versión 1.10.0, /etc/resolv.conf está enlazado simbólicamente a /run/systemd/resolve/stub-resolv.conf, que apunta al stub DNS de localhost 127.0.0.53.

    Por lo tanto, la resolución de nombres DNS de localhost no comprueba los servidores DNS upstream (especificados en /run/systemd/resolve/resolv.conf) para los nombres con el sufijo .local, a menos que los nombres se especifiquen como dominios de búsqueda.

    Esto provoca que falle cualquier búsqueda de nombres de .local. Por ejemplo, durante el inicio del nodo, kubelet falla al extraer imágenes de un registro privado con el sufijo .local. Si especificas una dirección de vCenter con el sufijo .local, no funcionará en una estación de trabajo de administrador.


    Solución alternativa:

    Puedes evitar este problema en los nodos del clúster si especificas el campo searchDomainsForDNS en el archivo de configuración del clúster de administrador y en el archivo de configuración del clúster de usuario para incluir los dominios.

    Actualmente, gkectl update no permite actualizar el campo searchDomainsForDNS.

    Por lo tanto, si no has configurado este campo antes de crear el clúster, debes conectarte a los nodos mediante SSH y omitir el stub local de systemd-resolved cambiando el enlace simbólico de /etc/resolv.conf de /run/systemd/resolve/stub-resolv.conf (que contiene el stub local de 127.0.0.53) a /run/systemd/resolve/resolv.conf (que apunta al DNS upstream real): 

    sudo ln -sf /run/systemd/resolve/resolv.conf /etc/resolv.conf

    En cuanto a la estación de trabajo del administrador, gkeadm no admite la especificación de dominios de búsqueda, por lo que debe solucionar este problema con este paso manual.

    Esta solución no se mantiene al volver a crear las VMs. Debes volver a aplicar esta solución alternativa cada vez que se vuelvan a crear las VMs.
    Instalación, Sistema operativo 1.10

    Google Distributed Cloud especifica una subred dedicada para la dirección IP del puente Docker que usa --bip=169.254.123.1/24, de forma que no reserve la subred 172.17.0.1/16 predeterminada. Sin embargo, en la versión 1.10.0, hay un error en la imagen del SO Ubuntu que provoca que se ignore la configuración de Docker personalizada.

    Por lo tanto, Docker elige 172.17.0.1/16 como subred de la dirección IP del puente. Esto puede provocar un conflicto de direcciones IP si ya tienes una carga de trabajo en ejecución dentro de ese intervalo de direcciones IP.


    Solución alternativa:

    Para solucionar este problema, debes cambiar el nombre del siguiente archivo de configuración de systemd para dockerd y, a continuación, reiniciar el servicio:

    sudo mv /etc/systemd/system/docker.service.d/50-cloudimg-settings.cfg \
    /etc/systemd/system/docker.service.d/50-cloudimg-settings.conf

sudo systemctl daemon-reload

sudo systemctl restart docker

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

    ip a | grep docker0

    Esta solución no se mantiene al volver a crear las VMs. Debes volver a aplicar esta solución alternativa cada vez que se vuelvan a crear las VMs.
    Mejoras y actualizaciones 1.11

    En la versión 1.11.0 de Google Distributed Cloud, se han producido cambios en la definición de los recursos personalizados relacionados con el registro y la monitorización:

    • El nombre del grupo del recurso personalizado stackdriver ha cambiado de addons.sigs.k8s.io a addons.gke.io.
    • El nombre del grupo de los recursos personalizados monitoring y metricsserver ha cambiado de addons.k8s.io a addons.gke.io.
    • Las especificaciones de los recursos anteriores empiezan a validarse con su esquema. En concreto, la especificación resourceAttrOverride y storageSizeOverride del recurso personalizado stackdriver debe tener el tipo de cadena en los valores de las solicitudes y los límites de CPU, memoria y tamaño de almacenamiento.

    Los cambios en los nombres de los grupos se han realizado para cumplir las actualizaciones de CustomResourceDefinition en Kubernetes 1.22.

    No es necesario que hagas nada si no tienes ninguna lógica adicional que se aplique o edite los recursos personalizados afectados. El proceso de actualización de Google Distributed Cloud se encargará de migrar los recursos afectados y de mantener sus especificaciones después de cambiar el nombre del grupo.

    Sin embargo, si ejecutas alguna lógica que aplique o edite los recursos afectados, debes prestar especial atención. En primer lugar, deben hacer referencia al nuevo nombre de grupo en el archivo de manifiesto. Por ejemplo:

    apiVersion: addons.gke.io/v1alpha1  ## instead of `addons.sigs.k8s.io/v1alpha1`
kind: Stackdriver

    En segundo lugar, asegúrate de que los valores de especificación resourceAttrOverride y storageSizeOverride sean de tipo cadena. Por ejemplo:

    spec:
  resourceAttrOverride:
    stackdriver-log-forwarder/stackdriver-log-forwarder
      limits:
        cpu: 1000m # or "1"
        # cpu: 1 # integer value like this would not work
        memory: 3000Mi

    De lo contrario, los cambios y las aplicaciones no se harán efectivos y pueden provocar un estado inesperado en los componentes de registro y monitorización. Los posibles síntomas son:

    • Registros de errores de conciliación en onprem-user-cluster-controller, por ejemplo: 
      potential reconciliation error: Apply bundle components failed, requeue after 10s, error: failed to apply addon components: failed to apply bundle objects from stackdriver-operator-addon 1.11.2-gke.53 to cluster my-cluster: failed to create typed live object: .spec.resourceAttrOverride.stackdriver-log-forwarder/stackdriver-log-forwarder.limits.cpu: expected string, got &value.valueUnstructured{Value:1}
    • Error en kubectl edit stackdriver stackdriver, por ejemplo: 
      Error from server (NotFound): stackdrivers.addons.gke.io "stackdriver" not found

    Si se producen los errores anteriores, significa que ya había un tipo no admitido en la especificación CR de Stackdriver antes de la actualización. Como solución alternativa, puedes editar manualmente el CR de Stackdriver con el nombre del grupo antiguo kubectl edit stackdrivers.addons.sigs.k8s.io stackdriver y hacer lo siguiente:

    1. Cambia las solicitudes y los límites de recursos al tipo de cadena.
    2. Elimina cualquier anotación addons.gke.io/migrated-and-deprecated: true si la hay.
    A continuación, reanuda o reinicia el proceso de actualización.

    Sistema operativo 1.7 y versiones posteriores

    Cuando se produce un fallo en un servidor ESXi y la función de alta disponibilidad de vCenter se ha habilitado en el servidor, todas las máquinas virtuales del servidor ESXi defectuoso activan el mecanismo de vMotion y se mueven a otro servidor ESXi normal. Las VMs de COS migradas perderían sus IPs.

    Solución alternativa:

    Reiniciar la VM
    Redes todas las versiones anteriores a 1.14.7, 1.15.0-1.15.3 y 1.16.0

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

    Solución alternativa:

    Activa una conmutación por error de Seesaw ejecutando sudo seesaw -c failover en cualquiera de las VMs de Seesaw. Debería restaurarse el tráfico.
    Sistema operativo 1.16, 1.28.0-1.28.200

    Se ha definido "staticPodPath" por error para los nodos de trabajador

    Solución alternativa:

    Crea manualmente la carpeta "/etc/kubernetes/manifests".

    Siguientes pasos

    Si necesitas más ayuda, ponte en contacto con el servicio de atención al cliente de Cloud.

    También puedes consultar la sección Obtener asistencia para obtener más información sobre los recursos de asistencia, incluidos los siguientes: