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

Los secretos siguen encriptados después de inhabilitar la encriptación de secretos siempre activa

Después de inhabilitar la encriptación de secretos siempre activa con gkectl update cluster, los secretos se siguen almacenando en etcd con encriptación. Este problema solo se aplica a los clústeres de usuarios de kubeception. Si tu clúster usa Controlplane V2, este problema no te afecta.

Para verificar si los secretos aún están encriptados, 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 encriptación, el resultado es 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 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 el secreto no se almacena con encriptación, el resultado es 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. Realiza una actualización progresiva en un DaemonSet específico de la siguiente manera:

       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 en el clúster de usuario para que todos los secretos se almacenen en etcd como texto sin formato:

       kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
         apply -f SECRETS_MANIFEST.yaml
       

Falta el campo hostgroups en el archivo user-cluster.yaml generado

Al archivo de configuración del clúster de usuario, user-cluster.yaml, que generó el comando gkectl get-config, le falta el campo hostgroups en la sección nodePools. El comando gkectl get-config genera el archivo user-cluster.yaml en función 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 alternativa

Para resolver este problema, agrega 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 del clúster de usuario editado para actualizar tu clúster de usuario sin generar errores y el campo hostgroups se conservará.

El ingreso agrupado no es compatible con los recursos gateway.networking.k8s.io

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

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

Solución alternativa:

Aplica 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
    

Los nodos del plano de control del clúster de administrador se reinician continuamente después de ejecutar gkectl create admin

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

Solución alternativa:

Usa solo nombres de host en minúscula.

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

Cuando creas o actualizas estaciones de trabajo de administrador con los comandos de gkeadm, es posible que recibas un error de OOM cuando verifiques la imagen de 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:

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

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

Este problema ocurre si, en la VM principal del administrador, ip a | grep cali 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 nodo principal del administrador:

   gkectl repair admin-master --kubeconfig=ADMIN_KUBECONFIG \
       --config=ADMIN_CONFIG_FILE \
       --skip-validation
   

2. Selecciona la plantilla de VM 1.30 si ves un mensaje como el 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
   

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

Los archivos de configuración del clúster que genera gkectl create-config en 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 de forma segura del archivo de configuración.

Los nodos de complemento del administrador se atascan en el estado NotReady durante la migración del clúster de administrador de sin HA a HA

Cuando se migra un clúster de administrador sin HA que usa MetalLB a HA, es posible que los nodos del complemento de administrador se queden atascados 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 aún usan el secreto metallb-memberlist anterior. Como resultado de la condición de carrera, la antigua VIP del plano de control se vuelve inaccesible, lo que provoca que la migración se detenga.

Solución alternativa:

1. Borra el secreto metallb-memberlist existente:

   kubectl --kubeconfig=ADMIN_KUBECONFIG -n kube-system \
       delete secret metallb-memberlist
   

2. Reinicia el Deployment de metallb-controller para que pueda generar el nuevo metallb-memberlist:

   kubectl --kubeconfig=ADMIN_KUBECONFIG -n kube-system \
       rollout restart deployment metallb-controller
   

3. Asegúrate de que se genere el nuevo metallb-memberlist:

   kubectl --kubeconfig=ADMIN_KUBECONFIG -n kube-system \
       get secret metallb-memberlist
   

4. Actualiza updateStrategy.rollingUpdate.maxUnavailable en el DaemonSet metallb-speaker de 1 a 100%.

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

   kubectl --kubeconfig=ADMIN_KUBECONFIG -n kube-system \
       edit daemonset metallb-speaker
   

5. Reinicia el DaemonSet metallb-speaker para que pueda recoger la nueva lista de miembros:

   kubectl --kubeconfig=ADMIN_KUBECONFIG -n kube-system \
       rollout restart daemonset metallb-speaker
   

   Después de unos minutos, los nodos del complemento del administrador volverán a ser Ready y se podrá continuar con la migración.

6. Si el comando gkectl inicial agotó el tiempo de espera después de más de 3 horas, vuelve a ejecutar gkectl update para reanudar la migración fallida.

La copia de seguridad del clúster de administrador sin alta disponibilidad falla debido a nombres largos de almacén de datos y disco de datos

Cuando se intenta crear una copia de seguridad de un clúster de administrador que no es de alta disponibilidad, la copia de seguridad falla 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 caracteres para un nombre de almacén de datos es de 80.
La ruta de acceso de la copia de seguridad para un clúster de administrador sin alta disponibilidad tiene la sintaxis de nombres "__". Por lo tanto, si el nombre concatenado supera la longitud máxima, fallará la creación de 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.

El nodo del plano de control del administrador de HA muestra una versión anterior después de ejecutar gkectl repair admin-master

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

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

Solución alternativa:

1. Busca el nombre de la máquina que usa la versión anterior de Kubernetes:

       kubectl get machine -o wide --kubeconfig=ADMIN_KUBECONFIG
       

2. Quita la anotación onprem.cluster.gke.io/prevented-deletion:

       kubectl edit machine MACHINE_NAME --kubeconfig=ADMIN_KUBECONFIG
       

   Guarda la edición.

3. Ejecuta el siguiente comando para borrar la máquina:

       kubectl delete machine MACHINE_NAME --kubeconfig=ADMIN_KUBECONFIG
       

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

Terraform quita los campos vCenter de forma inesperada

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

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

Solución alternativa:

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

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

Los nodos del plano de control del clúster de usuario siempre se reinician durante la primera operación de actualización del clúster de administrador.

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

Errores al crear recursos personalizados

En la versión 1.31 de Google Distributed Cloud, es posible que recibas errores cuando intentes crear recursos personalizados, como clústeres (de todos los tipos) y cargas de trabajo. El problema se debe a un cambio que se introdujo en Kubernetes 1.31 y 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 a menudo se establecía en un valor improvisado de \n, ya que en versiones anteriores de Kubernetes, el servidor de la API no permitía contenido vacío del paquete de CA. Usar \n era una solución alternativa razonable para evitar confusiones, ya que cert-manager suele actualizar caBundle más adelante.

Si el caBundle se corrigió una vez de un estado no válido a uno válido, no debería haber problemas. Sin embargo, si la definición de recurso personalizado se reconcilia con \n (o con otro valor no válido), es posible 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 alternativa

Si tienes una definición de recurso personalizada en la que caBundle se establece en un valor no válido, puedes quitar el campo caBundle por completo sin problemas. Esto debería resolver el problema.

cloud-init status siempre devuelve un error

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

Solución alternativa:

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

    systemctl show -p Result cloud-final.service
    

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

    Result=success
    

Falla la verificación previa de la estación de trabajo de administrador cuando se actualiza a la versión 1.28 con un tamaño de disco inferior a 100 GB

Cuando se actualiza un clúster a la versión 1.28, el comando gkectl prepare falla durante la ejecución de las verificaciones 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 del administrador aumentó de 50 GB a 100 GB.

Solución alternativa:

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

gkectl devuelve un error falso en netapp storageclass

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

Certificado de CA no válido después de la rotación de la CA del clúster en ClientConfig impide la autenticación del clúster

Después de rotar los certificados de la autoridad certificadora (CA) en un clúster de usuario, el campo spec.certificateAuthorityData en 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 próxima autenticación de gcloud CLI, actualiza manualmente el campo spec.certificateAuthorityData en ClientConfig con el certificado de CA correcto.

1. Copia el certificado de CA del clúster del campo certificate-authority-data en el archivo kubeconfig del clúster de administrador.
2. Edita ClientConfig y pega el certificado de CA en el campo spec.certificateAuthorityData.

       kubectl edit clientconfig default -n kube-public --kubeconfig USER_CLUSTER_KUBECONFIG
       

Falla la comprobación previa cuando se inhabilita la entrada agrupada

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

Solución alternativa:

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

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

La actualización del clúster falla debido a que falta una regla del grupo antiafinidad en vCenter

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

Si describes los objetos de la máquina que presentan problemas, puedes ver mensajes recurrentes como "Se completó la tarea de regla de DRS "tarea-xxxx"".

    kubectl --kubeconfig KUBECONFIG describe machine MACHINE_OBJECT_NAME
    

Solución alternativa:

Inhabilita el parámetro de configuración del grupo de 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
    

La migración de un clúster de usuario a Controlplane V2 falla si alguna vez se habilitó la encriptación de secretos

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

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

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

La migración de un clúster de administrador de no HA a HA falla si la encriptación de secretos está habilitada

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

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

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

Si el resultado muestra la clave vacía como se indica a continuación, es probable que el clúster se vea afectado por este problema:

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

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

De lo contrario, antes de comenzar la migración, rota la clave de encriptación.

credential.yaml se regeneró de forma incorrecta durante la actualización de la estación de trabajo del administrador

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

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

Solución alternativa:

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

La actualización del clúster de usuario falla debido al tiempo de espera del proceso de reconciliación previo a la actualización

Cuando se actualiza un clúster de usuario, es posible que la operación de reconciliación previa a la actualización tarde más que el tiempo de espera definido, lo que provoca un error en la actualización. El mensaje de error es similar al siguiente:

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

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

Solución alternativa:

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

gkectl upgrade cluster --skip-reconcile-before-preflight --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
--config USER_CLUSTER_CONFIG_FILE

La actualización de DataplaneV2 ForwardMode no activa automáticamente el reinicio del DaemonSet de anetd

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

Solución alternativa:

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

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG rollout restart daemonset anetd

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

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get daemonset anetd

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

No se encontró el comando etcdctl durante la actualización del clúster en la etapa de copia de seguridad del clúster de administrador

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

La causa del problema es que el binario etcdctl se agregó 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, incluida la toma de una instantánea de etcd y, luego, la escritura del archivo de metadatos para el clúster de administrador. La copia de seguridad de etcd aún se realiza correctamente porque etcdctl aún se puede activar después de un exec en el Pod de etcd. Sin embargo, la escritura del archivo de metadatos falla, ya que aún depende del archivo binario etcdctl para que se instale 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 de copia de seguridad se completa correctamente, al igual que la actualización del clúster de usuario.

Solución alternativa:

Si deseas crear una copia de seguridad del archivo de metadatos, sigue los pasos que se indican en Crea una copia de seguridad de un clúster de administrador y restablécelo con gkectl para activar una copia de seguridad independiente del clúster de administrador con la versión de gkectl que coincida con la versión de tu clúster de administrador.

Falla en la creación del clúster de usuario con balanceo de cargas manual

Cuando se crea un clúster de usuario configurado para el balanceo de cargas manual, se produce un error de gkectl check-config que indica que el valor de ingressHTTPNodePort debe ser de al menos 30000, incluso cuando se inhabilita Ingress en conjunto.

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

Solución alternativa:

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

Después de migrar un clúster de usuario a Controlplane V2, es posible que el PDB de metrics-server del clúster de administrador se configure de forma incorrecta.

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

Síntomas:

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

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

Solución alternativa:

Ejecuta el siguiente comando para borrar la PDB:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG delete pdb metrics-server -n gke-managed-metrics-server

El webhook de Autorización Binaria impide que se inicie el complemento de CNI, lo que provoca que uno de los grupos de nodos no se inicie

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

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

Solución alternativa:

1. Quita la configuración de 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, quita temporalmente la configuración del webhook de autorización binaria en el clúster de usuario con el siguiente comando.

           kubectl --kubeconfig USER_KUBECONFIG delete ValidatingWebhookConfiguration binauthz-validating-webhook-configuration
           

   Una vez que se complete el proceso de arranque, podrás volver a agregar la siguiente configuración de webhook.

   apiVersion: admissionregistration.k8s.io/v1
   kind: ValidatingWebhookConfiguration
   metadata:
     name: binauthz-validating-webhook-configuration
   webhooks:
   - name: "binaryauthorization.googleapis.com"
     namespaceSelector:
       matchExpressions:
       - key: control-plane
         operator: DoesNotExist
     objectSelector:
       matchExpressions:
       - key: "image-policy.k8s.io/break-glass"
         operator: NotIn
         values: ["true"]
     rules:
     - apiGroups:
       - ""
       apiVersions:
       - v1
       operations:
       - CREATE
       - UPDATE
       resources:
       - pods
       - pods/ephemeralcontainers
     admissionReviewVersions:
     - "v1beta1"
     clientConfig:
       service:
         name: binauthz
         namespace: binauthz-system
         path: /binauthz
       # CA Bundle will be updated by the cert rotator.
       caBundle: Cg==
     timeoutSeconds: 10
     # Fail Open
     failurePolicy: "Ignore"
     sideEffects: None
           

La actualización del clúster de usuario de CPV2 se detuvo debido a una máquina duplicada con deletionTimestamp

Durante una actualización del clúster de usuario, es posible que la operación de actualización se detenga si el objeto de máquina duplicado en el clúster de usuario contiene un deletionTimestamp. Si la actualización se detiene, se muestra el siguiente mensaje de error:

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

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

Solución alternativa:

1. Obtén el objeto de la máquina duplicada y guárdalo en un archivo local para fines de copia de seguridad.
2. Ejecuta el siguiente comando para borrar el finalizador de la máquina duplicada y espera a que se borre del clúster de usuarios.

       kubectl --kubeconfig ADMIN_KUBECONFIG patch machine/MACHINE_OBJECT_NAME -n USER_CLUSTER_NAME-gke-onprem-mgmt -p '{"metadata":{"finalizers":[]}}' --type=merge

3. Sigue los pasos que se indican en Nodo del plano de control del clúster de usuario de Controlplane V2 para activar la reparación de nodos en los nodos del plano de control, de modo que la especificación correcta de la máquina fuente se vuelva a sincronizar con el clúster de usuario.
4. Vuelve a ejecutar gkectl upgrade cluster para reanudar la actualización

Falla en la creación del clúster debido a la VIP del plano de control en una subred diferente

En el caso de un clúster de administrador con HA o un clúster de usuario de ControlPlane V2, la VIP del plano de control debe estar en la misma subred que otros nodos del clúster. De lo contrario, la creación del clúster fallará porque kubelet no puede comunicarse con el servidor de la API a través de la VIP del plano de control.

Solución alternativa:

Antes de crear el clúster, asegúrate de que la VIP del plano de control esté configurada en la misma subred que los demás nodos del clúster.

Falla en la creación o actualización del clúster debido a un nombre de usuario de vCenter que no es FQDN

La creación o actualización del clúster falla con un error en los Pods de CSI de vSphere que indica que el nombre de usuario de vCenter no es válido. Esto ocurre porque el nombre de usuario que se usa no es un nombre de dominio completamente calificado. Mensaje de error en el pod de 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 versiones posteriores, ya que se agregó una validación al controlador CSI de vSphere para exigir el uso de nombres de usuario de dominio completamente calificados.

Solución alternativa:

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

Falla la actualización del clúster de administrador para los clústeres creados en versiones 1.10 o anteriores

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

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

1. Conéctate a la máquina principal de administrador con errores a través de SSH.
2. Abre /var/log/startup.log y busca un error como el siguiente:

Error adding extensions from section apiserver_ext
801B3213B57F0000:error:1100007B:X509 V3 routines:v2i_AUTHORITY_KEYID:unable to get issuer keyid:../crypto/x509/v3_akid.c:177:
801B3213B57F0000:error:11000080:X509 V3 routines:X509V3_EXT_nconf_int:error in extension:../crypto/x509/v3_conf.c:48:section=apiserver_ext, name=authorityKeyIdentifier, value=keyid>
   

Solución alternativa:

1. Conéctate a la máquina principal del administrador con SSH. Para obtener más detalles, consulta Usa SSH para conectarte a un nodo del clúster de administrador.
2. Crea una copia de /etc/startup/pki-yaml.sh y asígnale el nombre /etc/startup/pki-yaml-copy.sh.
3. Editar /etc/startup/pki-yaml-copy.sh. Busca authorityKeyIdentifier=keyidset y cámbialo 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. Con un editor de texto, abre /opt/bin/master.sh, busca y reemplaza todas las ocurrencias de /etc/startup/pki-yaml.sh por /etc/startup/pki-yaml-copy.sh y, luego, guarda los cambios.
6. Ejecuta /opt/bin/master.sh para generar el certificado y completar el inicio de la máquina.
7. Vuelve a ejecutar gkectl upgrade admin para actualizar el clúster de administrador.
8. Una vez que se complete la actualización, rota el certificado de hoja para los clústeres de administrador y de usuario, como se describe en Cómo iniciar la rotación.
9. Una vez que se complete la rotación del certificado, realiza las mismas ediciones en /etc/startup/pki-yaml-copy.sh que hiciste anteriormente y ejecuta /opt/bin/master.sh.

Mensaje de advertencia incorrecto para clústeres con Dataplane V2 habilitado

Se genera el siguiente mensaje de advertencia incorrecto cuando ejecutas gkectl para crear, actualizar o migrar 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 use dataplaneV2.forwardMode, incluso si ya configuraste enableDataplaneV2: true en el archivo de configuración del clúster.

Solución alternativa:

Puedes ignorar esta advertencia.

La comprobación previa de la instalación del clúster de administrador de AA informa una cantidad incorrecta de IPs estáticas requeridas

Cuando creas un clúster de administrador de HA, 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 administrador de HA de la versión 1.28 y versiones posteriores, ya que ya no tienen nodos de complementos. Además, debido a que las IPs de los 3 nodos del plano de control del clúster de administrador se especifican en la sección network.controlPlaneIPBlock del archivo de configuración del clúster de administrador, las IPs del archivo de bloque de IP solo son necesarias para los nodos del plano de control del clúster de usuario de kubeception.

Solución alternativa:

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

El agente de Connect pierde la conexión con Google Cloud después de la migración de un clúster de administrador sin alta disponibilidad a uno con alta disponibilidad

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

Solución alternativa:

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

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

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

Borra la implementación gke-connect:

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

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

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

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

Después de la solución alternativa (el controlador puede tardar unos minutos en finalizar la conciliación), puedes verificar que el error 400 "Failed to verify JWT signature" ya no aparezca en los registros de gke-connect-agent:

kubectl --kubeconfig KUBECONFIG logs GKE_CONNECT_POD_NAME -n gke-connect

La IP del puente Docker usa 172.17.0.1/16 para los nodos del plano de control del clúster de COS.

Google Distributed Cloud especifica una subred dedicada, --bip=169.254.123.1/24, para la IP del puente Docker en la configuración de Docker para evitar reservar la subred 172.17.0.1/16 predeterminada. Sin embargo, en las versiones 1.28.0 a 1.28.500 y 1.29.0, el servicio de Docker no se reinició después de que Google Distributed Cloud personalizó la configuración de Docker debido a una regresión en la imagen del SO de COS. Como resultado, Docker elige el 172.17.0.1/16 predeterminado como su subred de dirección IP de puente. Esto podría causar un conflicto de dirección IP si ya tienes una carga de trabajo en ejecución dentro de ese rango de direcciones IP.

Solución alternativa:

Para solucionar este problema, debes reiniciar el servicio de Docker:

sudo systemctl restart docker

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

ip a | grep docker0

Esta solución no persiste en las recreaciones de VM. Debes volver a aplicar esta solución alternativa cada vez que se vuelvan a crear VMs.

No funciona el uso de varias interfaces de red con CNI estándar

Los archivos binarios de 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 funcionará una interfaz de red múltiple con estos complementos de CNI.

Solución alternativa:

Si usas esta función, actualiza a la versión que incluye la corrección.

Las dependencias de NetApp Trident interfieren con el controlador CSI de vSphere

La instalación de multipathd en los nodos del clúster interfiere con el controlador de CSI de vSphere, lo que impide que se inicien las cargas de trabajo del usuario.

Solución alternativa:

• Inhabilitar multipathd

Es posible que el webhook del clúster de administrador bloquee las actualizaciones

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

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

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:

• Para los clústeres de administrador 1.15, ejecuta el comando gkectl update admin con la marca --disable-admin-cluster-webhook. Por ejemplo:

          gkectl update admin --config ADMIN_CLUSTER_CONFIG_FILE --kubeconfig ADMIN_CLUSTER_KUBECONFIG --disable-admin-cluster-webhook
          

• Para los clústeres de administrador de la versió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
          

El campo controlPlaneNodePort tiene el valor predeterminado 30968 cuando la especificación de manualLB está vacía.

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

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

Solución alternativa:

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

loadBalancer:
  ...
  kind: ManualLB
  manualLB:
    controlPlaneNodePort: 0
  ...

Falta nfs-common en la imagen de SO de Ubuntu

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

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

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

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

Solución alternativa:

Agrega el campo `vCenter.storagePolicyName` en el archivo de configuración del clúster de administrador si deseas configurar la política de almacenamiento para el clúster de administrador. Consulta las instrucciones.

La API de Kubernetes Metadata no admite los VPC-SC

La API kubernetesmetadata.googleapis.com agregada recientemente no admite VPC-SC. Esto hará que el agente de recopilación de metadatos no pueda acceder a esta API en VPC-SC. Posteriormente, faltarán las etiquetas de metadatos de las métricas.

Solución alternativa:

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

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

Luego, ejecuta

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

Es posible que clusterapi-controller falle cuando el clúster de administrador y cualquier clúster de usuario con ControlPlane V2 habilitado usen diferentes credenciales de vSphere.

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

kubectl logs -f -l component=clusterapi-controllers -c vsphere-controller-manager \
    -n kube-system --kubeconfig KUBECONFIG

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

Solución alternativa:

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

Gran cantidad de solicitudes de GRPC con errores en Prometheus Alert Manager

Prometheus podría informar alertas similares al siguiente ejemplo:

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

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

1. Compara la métrica grpc_server_handled_total sin procesar con la métrica grpc_method que se indica en el mensaje de alerta. En este ejemplo, verifica la etiqueta grpc_code para Watch.
   
   Puedes verificar esta métrica con Cloud Monitoring con la siguiente consulta en MQL:

   fetch
       k8s_container | metric 'kubernetes.io/anthos/grpc_server_handled_total' | align rate(1m) | every 1m

2. Se puede ignorar de forma segura una alerta sobre todos los códigos que no sean OK si el código no es uno de los siguientes:

   Unknown|FailedPrecondition|ResourceExhausted|Internal|Unavailable|DataLoss|DeadlineExceeded

Solución alternativa:

Para configurar Prometheus de modo que ignore estas alertas de falsos positivos, revisa las siguientes opciones:

1. Silencia la alerta desde la IU de Alert Manager.
2. Si silenciar la alerta no es una opción, revisa los siguientes pasos para suprimir los falsos positivos:
   1. Reduce el operador de supervisión a 0 réplicas para que las modificaciones persistan.
   2. Modifica el configmap de prometheus-config y agrega grpc_method!="Watch" a la configuración de alerta de etcdHighNumberOfFailedGRPCRequests, como se muestra en el siguiente ejemplo:
      • Original:

        rate(grpc_server_handled_total{cluster="CLUSTER_NAME",grpc_code!="OK",job=~".*etcd.*"}[5m])

      • Modificado:

        rate(grpc_server_handled_total{cluster="CLUSTER_NAME",grpc_code=~"Unknown|FailedPrecondition|ResourceExhausted|Internal|Unavailable|DataLoss|DeadlineExceeded",grpc_method!="Watch",job=~".*etcd.*"}[5m])

        Reemplaza el siguiente CLUSTER_NAME por el nombre de tu clúster.
   3. Reinicia el Statefulset de Prometheus y Alertmanager para recoger la nueva configuración.
3. Si el código se encuentra en uno de los casos problemáticos, verifica los registros de etcd y kube-apiserver para depurar más.

Se descartan las conexiones duraderas de NAT de salida

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

Como el seguimiento de la conexión solo importa en la dirección de entrada (conexiones externas al clúster), este problema solo ocurre si la conexión no transmite información durante un tiempo y, luego, el lado de destino transmite algo. Si el Pod con NAT de salida siempre instancia la mensajería, no se verá este problema.

Este problema se produce porque la recolección de elementos no utilizados de anetd quita de forma involuntaria las entradas de conntrack que el daemon cree que no se usan. Se integró recientemente una corrección upstream en anetd para corregir el comportamiento.

Solución alternativa:

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

El firmante de CSR ignora spec.expirationSeconds cuando firma certificados.

Si creas un CertificateSigningRequest (CSR) con expirationSeconds establecido, se ignora expirationSeconds.

Solución alternativa:

Si este problema te afecta, puedes actualizar tu clúster de usuario. Para ello, agrega disableNodeIDVerificationCSRSigning: true en el archivo de configuración del clúster de usuario y ejecuta el comando gkectl update cluster para actualizar el clúster con esta configuración.

Falla la validación del balanceador de cargas del clúster de usuario para disable_bundled_ingress

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

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

Este error se produce porque gkectl verifica la dirección IP de entrada del balanceador de cargas durante las verificaciones de comprobación previa. Si bien esta verificación no es obligatoria cuando se inhabilita la entrada agrupada, la verificación previa de gkectl falla cuando disableBundledIngress se establece en true.

Solución alternativa:

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

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

Para obtener más información, consulta cómo inhabilitar Ingress incluido para un clúster existente.

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

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

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

Solución alternativa:

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

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

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

Falla la verificación previa de la carga de trabajo de CSI debido a una falla en el inicio del Pod

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

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

• Si el Pod no tiene límites de recursos especificados, como sucede 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 con la inserción automática del archivo adicional de Istio habilitada en el espacio de nombres default, no se inicia el Pod de carga de trabajo de CSI.

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

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

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

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

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

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

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

kubectl label namespace default istio.io/rev-

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

1. Crea una PVC que use la StorageClass standard-rwo.
2. Crea un Pod que use la PVC.
3. Verifica que el Pod pueda leer y escribir datos en el volumen.
4. Quita 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 de vSphere funciona, ejecuta gkectl diagnose o gkectl upgrade con la marca --skip-validation-csi-workload para omitir la verificación de la carga de trabajo del CSI.

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

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

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

Durante la actualización de un clúster de administrador 1.15, se quita del clúster el validation-controller que activa las verificaciones previas al vuelo. Si luego intentas actualizar el clúster de usuario, la verificación previa se detendrá 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 que se complete la preparación, vuelve a ejecutar gkectl update cluster para actualizar el clúster de usuario.

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

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

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

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

Solución alternativa:

1. Ejecuta el siguiente comando para implementar validation-controller:

         gkectl prepare --kubeconfig ADMIN_KUBECONFIG --bundle-path BUNDLE_PATH --upgrade-platform
         

2. Una vez que se complete la preparación, vuelve a ejecutar gkectl create cluster para crear el clúster de usuario.

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

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

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

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

Solución alternativa:

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

1. Edita el recurso del clúster onpremadminclusters:

   kubectl edit onpremadminclusters ADMIN_CLUSTER_NAME -n kube-system –kubeconfig ADMIN_CLUSTER_KUBECONFIG

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

     • gkectl upgrade admin --config ADMIN_CONFIG_file --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
         --disable-upgrade-from-checkpoint

   • Para clústeres de administrador con HA o si el archivo de punto de control está inhabilitado: Actualiza o mejora el clúster de administrador de forma normal. No se necesitan parámetros adicionales en los comandos de actualización.

La eliminación del clúster de usuario falla cuando se usa una estación de trabajo de administrador administrada por el usuario

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

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

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

Solución alternativa:

1. Obtén los nombres de todos los objetos de Validation:

            kubectl  --kubeconfig ADMIN_KUBECONFIG get validations \
              -n USER_CLUSTER_NAME-gke-onprem-mgmt
           

2. Para cada objeto Validation, ejecuta el siguiente comando para quitar el finalizador del objeto Validation:

         kubectl --kubeconfig ADMIN_KUBECONFIG patch validation/VALIDATION_OBJECT_NAME \
           -n USER_CLUSTER_NAME-gke-onprem-mgmt -p '{"metadata":{"finalizers":[]}}' --type=merge
         

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

Falla el tráfico de la puerta de enlace NAT de salida al servidor externo

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

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

Solución alternativa:

Cambia el puerto VXLAN que usa Cilium a 4789:

1. Edita el ConfigMap cilium-config:

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

2. Agrega lo siguiente al ConfigMap cilium-config:

   tunnel-port: 4789

3. Reinicia el DaemonSet de 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 su problema en vSphere para que la corrección sea permanente.

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

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

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

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

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

Solución alternativa

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

1. Inhabilita secretsEncryption en el archivo de configuración del clúster de administrador y actualiza el clúster con el siguiente comando:

   gkectl update admin --config ADMIN_CLUSTER_CONFIG_FILE --kubeconfig KUBECONFIG

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

Cómo evitar el error de actualización

Si aún no lo hiciste, te recomendamos que no actualices a la versión 1.15.0-1.15.4. Si debes actualizar a una versión afectada, realiza los siguientes pasos antes de actualizar el clúster de administrador:

1. Crea una copia de seguridad del clúster de administrador.
2. Inhabilita secretsEncryption en el archivo de configuración del clúster de administrador y actualiza el clúster con el siguiente comando:

   gkectl update admin --config ADMIN_CLUSTER_CONFIG_FILE --kubeconfig KUBECONFIG

3. Actualiza el clúster de administrador.
4. Vuelve a habilitar la encriptación de secretos siempre activa.

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

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

Solución alternativa:

No hagas copias de seguridad de las VMs de Google Distributed Cloud, ya que el software de copias de seguridad de terceros podría habilitar el 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 persistirá en las actualizaciones.

Si ya tienes discos con CBT habilitado, sigue los pasos de la Resolución en el artículo de la KB de VMware para inhabilitar CBT en el disco de primera clase.

Se produce corrupción de datos en NFSv3 cuando se realizan anexos paralelos a un archivo compartido desde varios hosts.

Si usas arrays de almacenamiento de Nutanix para proporcionar recursos compartidos de NFSv3 a tus hosts, es posible que experimentes corrupción de datos o que los Pods no se ejecuten correctamente. Este problema se debe a un problema de compatibilidad conocido entre ciertas versiones de VMware y Nutanix. Para obtener más información, consulta el artículo de la KB de VMware asociado.

Solución alternativa:

El artículo de la base de conocimientos de VMware está desactualizado al indicar que no hay una resolución actual. Para resolver este problema, actualiza a la versión más reciente de ESXi en tus hosts y a la versión más reciente de Nutanix en tus arrays de almacenamiento.

Incompatibilidad de versiones entre kubelet y el plano de control de Kubernetes

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 de kubelet precargado en la imagen de SO usa una versión diferente.

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

Solución alternativa:

No se requiere ninguna acción. La incoherencia solo se da entre las versiones de parche de Kubernetes, y esta diferencia de versión no ha causado problemas.

Falla la actualización de un clúster de administrador con una versión de CA superior a 1

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

    CAVersion must start from 1
    

Solución alternativa:

• Reduce la 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 campo nuevo 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 gkectl con la marca --disable-admin-cluster-webhook.Por ejemplo:

          gkectl upgrade admin --config ADMIN_CLUSTER_CONFIG_FILE --kubeconfig KUBECONFIG --disable-admin-cluster-webhook
          

La eliminación del clúster de Controlplane V2 sin alta disponibilidad se bloquea hasta que se agota el tiempo de espera

Cuando se borra un clúster de Controlplane V2 sin alta disponibilidad, se bloquea en el borrado de nodos hasta que se agota el tiempo de espera.

Solución alternativa:

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

De lo contrario, sigue estos pasos:

• Borra todas las VMs del clúster de vSphere. Puedes borrar las VMs a través de la IU de vSphere o ejecutar el siguiente comando:

        govc vm.destroy

  .
• Vuelve a forzar la eliminación del clúster:

       gkectl delete cluster --cluster USER_CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG --force
       

Las tareas constantes de CNS attachvolume aparecen cada minuto para PVC/PV integrados después de actualizar a la versión 1.15 o posterior

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

Solución alternativa:

Edita el ConfigMap de la función CSI de vSphere y establece list-volumes en false:

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

Reinicia los Pods del controlador CSI de vSphere:

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

Advertencias falsas sobre los PVC

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

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

Solución alternativa:

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

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

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

      pv.kubernetes.io/bind-completed: "yes"
      pv.kubernetes.io/bound-by-controller: "yes"
      volume.beta.kubernetes.io/storage-provisioner: csi.vsphere.vmware.com
    

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

Si tu clúster no usa un registro privado y vencieron las claves de la cuenta de servicio de acceso a los componentes y las claves de la cuenta de servicio de supervisión de registros (o de registro de Connect), cuando rotes las claves de la cuenta de servicio, gkectl update credentials fallará con un error similar al siguiente:

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

Solución alternativa:

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

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

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

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

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

La solución alternativa que apliques dependerá de cómo se presente el problema.

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

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

Opción 2: Sigue estos pasos:

1. Agrega manualmente la anotación de nueva ejecució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 volver a ejecutar es la siguiente:

   onprem.cluster.gke.io/server-side-preflight-rerun: true

2. Supervisa el progreso de la actualización. Para ello, verifica el campo status de OnPremUserCluster.

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

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

Opción 2: Sigue estos pasos:

1. Agrega el archivo de información de compilación /etc/cloud/build.info con el siguiente contenido. Esto hace que las comprobaciones previas se ejecuten de forma local en 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 complete la actualización, borra el archivo build.info.

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

Durante la creación del clúster, si no especificas un nombre de host para cada dirección IP del archivo de bloque de IP, la verificación previa fallará con el siguiente mensaje de error:

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

Hay un error en la verificación previa al vuelo que supone que el nombre de host vacío es un duplicado.

Solución alternativa:

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

Opción 2: Agrega la marca --skip-validation-net-config para omitir esta verificación previa al vuelo.

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

Falla en el montaje del volumen al actualizar el clúster de administrador si se usa un clúster de administrador sin alta disponibilidad y un clúster de usuario de la versión 1 del plano de control

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

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

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG --namespace USER_CLUSTER_NAME describe pod IMPACTED_POD_NAME

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

Solución alternativa:

1. Establece una conexión SSH con el nodo del plano de control del usuario, ya que es un clúster de usuario de la versión 1 del plano de control, el nodo del plano de control del usuario está en el clúster de administrador.
2. Reinicia kubelet con el siguiente comando:

       sudo systemctl restart kubelet
       

   Después del reinicio, kubelet puede reconstruir el montaje global de la etapa correctamente.

No se pudo crear el nodo del plano de control

Durante una actualización de un clúster de administrador, una condición de carrera podría hacer que el administrador de controladores de Cloud de vSphere borre de forma inesperada un nodo del plano de control nuevo. Esto hace que el clusterapi-controller se quede atascado esperando que se cree el nodo y, finalmente, se agote el tiempo de espera de la actualización. En este caso, el resultado del comando de actualización gkectl es similar al siguiente:

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

Para identificar el síntoma, ejecuta el siguiente comando para acceder al registro del administrador del controlador de Cloud en vSphere en el clúster de administrador:

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

Este es un mensaje de error de ejemplo del comando anterior:

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

Solución alternativa:

1. Reinicia la máquina con errores para volver a crear el objeto del nodo borrado.
2. Establece una conexión SSH a cada nodo del plano de control y reinicia el Pod estático del administrador de controladores de Cloud 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.

La duplicación del nombre de host en el mismo centro de datos provoca errores en la creación o actualización del clúster

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

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

• Clúster de administrador:

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

• Clúster de usuario 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 usuario 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 ejemplo de mensaje de error:

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

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

          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
          

          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 falló.

Solución alternativa para las actualizaciones:

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

• Clúster de usuario:
  1. Actualiza el nombre de host de la máquina afectada en user-ip-block.yaml a un nombre único y activa una actualización forzada:
     

               gkectl update cluster --kubeconfig ADMIN_KUBECONFIG --config NEW_USER_CLUSTER_CONFIG --force
               

  2. Volver a ejecutar gkectl upgrade cluster
• Clúster de administrador:
  1. Actualiza el nombre de host de la máquina afectada en admin-ip-block.yaml a un nombre único y activa una actualización forzada:
     

               gkectl update admin --kubeconfig ADMIN_KUBECONFIG --config NEW_ADMIN_CLUSTER_CONFIG --force --skip-cluster-ready-check
               

  2. Si se trata de un clúster de administrador sin alta disponibilidad y detectas que la VM principal del administrador usa un nombre de host duplicado, también debes hacer lo siguiente:
     Obtén el nombre de la máquina principal del administrador

               kubectl get machine --kubeconfig ADMIN_KUBECONFIG -owide -A
               

     Actualiza el objeto de la máquina principal del administrador
     Nota: El valor de NEW_ADMIN_MASTER_HOSTNAME debe ser el mismo que el que configuraste en admin-ip-block.yaml en el paso 1.
     

               kubectl patch machine ADMIN_MASTER_MACHINE_NAME --kubeconfig ADMIN_KUBECONFIG --type='json' -p '[{"op": "replace", "path": "/spec/providerSpec/value/networkSpec/address/hostname", "value":"NEW_ADMIN_MASTER_HOSTNAME"}]'
               

     Verifica que el nombre de host se haya actualizado en el objeto de la máquina principal del administrador:
     

               kubectl get machine ADMIN_MASTER_MACHINE_NAME --kubeconfig ADMIN_KUBECONFIG -oyaml
               kubectl get machine ADMIN_MASTER_MACHINE_NAME --kubeconfig ADMIN_KUBECONFIG -o jsonpath='{.spec.providerSpec.value.networkSpec.address.hostname}'
               

  3. Vuelve a ejecutar la actualización del clúster de administrador con el punto de control inhabilitado:
     

               gkectl upgrade admin --kubeconfig ADMIN_KUBECONFIG --config ADMIN_CLUSTER_CONFIG --disable-upgrade-from-checkpoint
               

Solución alternativa para instalaciones:

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

• Clúster de administrador:
  1. Borra la máquina del nodo de administrador.
  2. Borra el disco de datos.
  3. Borra el archivo de punto de control del clúster de administrador.
  4. Actualiza el nombre de host de la máquina afectada en admin-ip-block.yaml a un nombre único.
  5. Vuelve a ejecutar gkectl create admin.
• Clúster de usuario:
  1. Limpia los recursos.
  2. Actualiza el nombre de host de la máquina afectada en user-ip-block.yaml a un nombre único.
  3. Vuelve a ejecutar gkectl create cluster.

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

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

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

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

Solución alternativa para las actualizaciones:

1. Cambia el nombre de usuario o la contraseña de vCenter en el lado de vCenter para quitar $ y `.
2. Actualiza el nombre de usuario o la contraseña de vCenter en tu archivo de configuración de credenciales.
3. Activa una actualización forzada del clúster.
• Clúster de usuario

          gkectl update cluster --kubeconfig ADMIN_KUBECONFIG --config USER_CLUSTER_CONFIG --force
          

• Clúster de administrador:

          gkectl update admin --kubeconfig ADMIN_KUBECONFIG --config ADMIN_CLUSTER_CONFIG --force --skip-cluster-ready-check
          

Solución alternativa para instalaciones:

1. Cambia el nombre de usuario o la contraseña de vCenter en el lado de vCenter para quitar $ y `.
2. Actualiza el nombre de usuario o la contraseña de vCenter en tu archivo de configuración de credenciales.
3. Aplica la solución alternativa para el tipo de clúster correspondiente.
• Clúster de administrador:
  1. Borra la máquina del nodo de administrador.
  2. Borra el disco de datos.
  3. Borra el archivo de punto de control del clúster de administrador.
  4. Vuelve a ejecutar gkectl create admin.
• Clúster de usuario:
  1. Limpia los recursos.
  2. Vuelve a ejecutar gkectl create cluster.

Falla en la creación del PVC después de que se vuelve a crear el nodo con el mismo nombre

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

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

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

Solución alternativa:

Reinicia los Pods del controlador CSI de vSphere:

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

gkectl repair admin-master devuelve un error de kubeconfig unmarshall

Cuando ejecutas el comando gkectl repair admin-master en un clúster de administrador de AA, 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:

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

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

Para encontrar la plantilla de VM de la máquina, haz lo siguiente:

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

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

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

  gkectl repair admin-master \
      --config=/home/ubuntu/admin-cluster.yaml \
      --kubeconfig=/home/ubuntu/kubeconfig \
      --admin-master-vm-template=/atl-qual-vc07/vm/gke-admin-98g94-zx...7vx-0-tmpl

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

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

    GRUB_FORCE_PARTUUID set, initrdless boot failed. Attempting with initrd
    

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

Solución alternativa:

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

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

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

Error de clave pública SSH de administrador después de actualizar el clúster de administrador

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

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

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

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

Solución alternativa:

Si no puedes actualizar a una versión de parche de Google Distributed Cloud con la corrección, comunícate con el equipo de asistencia de Google para obtener ayuda.

Es posible que falle la actualización de un clúster de administrador inscrito en la API de GKE On-Prem

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

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

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

Solución alternativa:

    gcloud alpha container vmware admin-clusters unenroll ADMIN_CLUSTER_NAME --project CLUSTER_PROJECT --location=CLUSTER_LOCATION --allow-missing
    

No se conserva la anotación del vínculo de recursos del clúster de administrador inscrito

Cuando un clúster de administrador se inscribe en la API de GKE On-Prem, su anotación de vínculo 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 hacer que el clúster de administrador se vuelva a inscribir en la API de GKE On-Prem por error.

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

Solución alternativa:

    gcloud alpha container vmware admin-clusters unenroll ADMIN_CLUSTER_NAME --project CLUSTER_PROJECT --location=CLUSTER_LOCATION --allow-missing
    

No se reconoce CoreDNS orderPolicy

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

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

Solución alternativa:

Actualiza la plantilla de CoreDNS y aplica la corrección. Esta corrección persiste hasta una actualización.

1. Edita la plantilla existente:

   kubectl edit cm -n kube-system coredns-template

   Reemplaza 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 }}

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

Algunas condiciones de carrera podrían provocar que el estado de OnPremAdminCluster sea inconsistente entre el punto de control y el CR real. Cuando ocurre el problema, es posible que encuentres el siguiente error cuando actualices el clúster de administrador después de actualizarlo:

Exit with error:
E0321 10:20:53.515562  961695 console.go:93] Failed to update the admin cluster: OnPremAdminCluster "gke-admin-rj8jr" is in the middle of a create/upgrade ("" -> "1.15.0-gke.123"), which must be completed before it can be updated
Failed to update the admin cluster: OnPremAdminCluster "gke-admin-rj8jr" is in the middle of a create/upgrade ("" -> "1.15.0-gke.123"), which must be completed before it can be updated

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

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

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

• Los certificados no válidos pueden provocar que los siguientes comandos agoten el tiempo de espera y muestren 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 y versiones posteriores, 1.14.6 y versiones posteriores, 1.15.2 y versiones posteriores. Si no puedes realizar la actualización, comunícate con Atención al cliente de Cloud para resolver este problema.

Los componentes de Anthos Network Gateway se desalojaron o están pendientes debido a la falta de una clase de prioridad

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

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

Estos errores indican eventos de expulsión o la imposibilidad de programar Pods debido a los recursos del nodo. Como los Pods de Anthos Network Gateway no tienen PriorityClass, tienen la misma prioridad predeterminada que otras cargas de trabajo. Cuando los nodos tienen restricciones de recursos, es posible que se expulsen los Pods de la puerta de enlace de red. Este comportamiento es particularmente malo para el DaemonSet de ang-node, 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 posterior.

Como solución a corto plazo, puedes asignar manualmente una PriorityClass a los componentes de Anthos Network Gateway. El controlador de Google Distributed Cloud reemplaza estos cambios manuales durante un proceso de reconciliación, como durante una actualización del clúster.

• Asigna la PriorityClass system-cluster-critical a las implementaciones de los controladores de clústeres ang-controller-manager y autoscaler.
• Asigna la PriorityClass system-node-critical al DaemonSet del nodo ang-daemon.

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

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

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

Borra el espacio de nombres gke-connect:

kubectl delete ns gke-connect --kubeconfig=ADMIN_KUBECONFIG

kubectl get onpremadmincluster -n kube-system --kubeconfig=ADMIN_KUBECONFIG

gcloud container fleet memberships delete ADMIN_CLUSTER_NAME

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

Esto no afecta la funcionalidad de tomar una instantánea del clúster, ya que la instantánea sigue incluyendo todos los registros que se recopilan de forma predeterminada cuando se ejecuta journalctl en los nodos del clúster. Por lo tanto, no se pierde información de depuración.

gkectl prepare windows falla

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

Solución alternativa:

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

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

Opción 1: Actualización azul-verde

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

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

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

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

1. Borra los grupos de nodos de Windows existentes quitando la configuración de los grupos de nodos de Windows del archivo user-cluster.yaml y, luego, ejecuta el siguiente comando:

   gkectl update cluster --kubeconfig=ADMIN_KUBECONFIG --config USER_CLUSTER_CONFIG_FILE

2. Actualiza los clústeres de administrador y de usuario exclusivos de Linux a la versión 1.12 siguiendo la guía del usuario para la 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 de OnPremUserCluster. De lo contrario, el clúster seguirá usando Docker para los grupos de nodos de Windows, lo que no será compatible con la plantilla de VM de Windows 1.13 recién creada que no tiene instalado Docker. Si no se configuró o se estableció como falso, actualiza tu clúster para establecerlo como verdadero en user-cluster.yaml y, luego, ejecuta lo siguiente:

   gkectl update cluster --kubeconfig=ADMIN_KUBECONFIG --config USER_CLUSTER_CONFIG_FILE

4. Actualiza los clústeres de administrador y de usuario exclusivos de Linux a la versión 1.13 siguiendo la guía de actualización del usuario.
5. Prepara la plantilla de VM de Windows con gkectl 1.13:

   gkectl prepare windows --base-vm-template BASE_WINDOWS_VM_TEMPLATE_NAME --bundle-path 1.13_BUNDLE_PATH --kubeconfig=ADMIN_KUBECONFIG

6. Vuelve a agregar la configuración del grupo de nodos de Windows a user-cluster.yaml con el campo OSImage establecido en la plantilla de VM de Windows recién creada.
7. Actualiza el clúster para agregar grupos de nodos de Windows

   gkectl update cluster --kubeconfig=ADMIN_KUBECONFIG --config USER_CLUSTER_CONFIG_FILE

La configuración de RootDistanceMaxSec no tiene efecto en los nodos de ubuntu

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 verificas el registro de inicio del nodo conectándote a la VM a través de SSH, que se encuentra en `/var/log/startup.log`, puedes encontrar el siguiente error:

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

Usar un RootDistanceMaxSec de 5 segundos puede provocar que el reloj del sistema se desincronice con el servidor NTP cuando la desviación del reloj sea mayor 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: /

gkectl update admin falla porque el campo osImageType está vacío

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

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

Cuando usas gkectl update admin para clústeres de las versiones 1.13 o 1.14, es posible que veas el siguiente mensaje en la respuesta:

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

Si revisas el registro de gkectl, es posible que veas que los múltiples cambios incluyen 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 realizar la actualización, comunícate con Atención al cliente de Cloud para resolver este problema.

La SNI no funciona en clústeres de usuarios con Controlplane V2

La capacidad de proporcionar un certificado de entrega adicional para el servidor de la API de Kubernetes de un clúster de usuario con authentication.sni no funciona cuando 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).

El carácter $ en el nombre de usuario del registro privado provoca una falla en el inicio de la máquina del plano de control del administrador

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

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

Solución alternativa:

Usa un nombre de usuario de registro privado sin $ o usa una versión de Google Distributed Cloud con la corrección.

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

Cuando actualices clústeres de administrador, verás las siguientes advertencias de falso positivo en el registro, y podrás ignorarlas.

    console.go:47] detected unsupported changes: &v1alpha1.OnPremAdminCluster{
      ...
      -         CARotation:        &v1alpha1.CARotationConfig{Generated: &v1alpha1.CARotationGenerated{CAVersion: 1}},
      +         CARotation:        nil,
      ...
    }

La actualización del clúster de usuario falló después de la rotación de claves de firma de KSA

Después de rotar las claves de firma de KSA y, luego, actualizar un clúster de usuario, es posible que gkectl update falle con el siguiente mensaje de error:

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

Solución alternativa:

1. Verifica el secreto en el clúster de administrador en el espacio de nombres USER_CLUSTER_NAME y obtén el nombre del secreto ksa-signing-key:

   kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME get secrets | grep ksa-signing-key

2. Copia el secreto ksa-signing-key y asígnale el nombre service-account-cert al secreto copiado:

   kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME get secret KSA-KEY-SECRET-NAME -oyaml | \
   sed 's/ name: .*/ name: service-account-cert/' | \
   kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME apply -f -

3. Borra el secreto de la clave de firma de ksa anterior:

   kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME delete secret KSA-KEY-SECRET-NAME

4. Actualiza el campo data.data en el configmap ksa-signing-key-rotation-stage a '{"tokenVersion":1,"privateKeyVersion":1,"publicKeyVersions":[1]}':

   kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME \
   edit configmap ksa-signing-key-rotation-stage

5. Inhabilita el webhook de validación para editar la información de la versión en el recurso personalizado OnPremUserCluster:

   kubectl --kubeconfig=ADMIN_KUBECONFIG patch validatingwebhookconfiguration onprem-user-cluster-controller -p '
   webhooks:
   - name: vonpremnodepool.onprem.cluster.gke.io
     rules:
     - apiGroups:
       - onprem.cluster.gke.io
       apiVersions:
       - v1alpha1
       operations:
       - CREATE
       resources:
       - onpremnodepools
   - name: vonpremusercluster.onprem.cluster.gke.io
     rules:
     - apiGroups:
       - onprem.cluster.gke.io
       apiVersions:
       - v1alpha1
       operations:
       - CREATE
       resources:
       - onpremuserclusters
   '

6. Actualiza el campo spec.ksaSigningKeyRotation.generated.ksaSigningKeyRotation a 1 en tu recurso personalizado OnPremUserCluster:

   kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME-gke-onprem-mgmt \
   edit onpremusercluster USER_CLUSTER_NAME

7. Espera a que el clúster de usuario de destino esté listo. Puedes verificar el estado de la siguiente manera:

   kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME-gke-onprem-mgmt \
   get onpremusercluster

8. Restablece el webhook de validación para el clúster de usuario:

   kubectl --kubeconfig=ADMIN_KUBECONFIG patch validatingwebhookconfiguration onprem-user-cluster-controller -p '
   webhooks:
   - name: vonpremnodepool.onprem.cluster.gke.io
     rules:
     - apiGroups:
       - onprem.cluster.gke.io
       apiVersions:
       - v1alpha1
       operations:
       - CREATE
       - UPDATE
       resources:
       - onpremnodepools
   - name: vonpremusercluster.onprem.cluster.gke.io
     rules:
     - apiGroups:
       - onprem.cluster.gke.io
       apiVersions:
       - v1alpha1
       operations:
       - CREATE
       - UPDATE
       resources:
       - onpremuserclusters
   '

9. Evita otra rotación de claves de firma de KSA hasta que el clúster se actualice a la versión con la corrección.

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

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

Solución alternativa:

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

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

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

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

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

La respuesta contiene entradas como las siguientes:

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

Estas imágenes de contenedor deben precargarse en la imagen de contenedor del clúster de kind. Sin embargo, kind v0.18.0 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 la creación o actualización del clúster de administrador está pendiente:

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

Conmutación por error sin éxito en el clúster de usuario y el clúster de administrador de Controlplane V2 con alta disponibilidad cuando la red filtra las solicitudes de GARP duplicadas

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

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

Solución alternativa:

    iptables -I FORWARD -i ens192 --destination CONTROL_PLANE_VIP -j DROP
    

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

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

Solución alternativa:

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

kubectl --kubeconfig=ADMIN_KUBECONFIG rollout restart deployment vsphere-csi-controller -n kube-system

La creación del clúster de administrador no falla debido a errores de registro del clúster

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

Failed to register admin cluster

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

Solución alternativa:

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

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

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

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 del usuario, el clúster de administrador no se volverá a registrar con la versión actualizada del agente de Connect.

Solución alternativa:

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

Mensaje de error falso sobre vCenter.dataDisk

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

vCenter.dataDisk must be present in the AdminCluster spec

Solución alternativa:

Puedes ignorar este mensaje de error.

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

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

Solución alternativa:

Quita las reglas redundantes antiguas para que se pueda crear el grupo de nodos. Estas reglas se denominan [USER_CLUSTER_NAME]-[HASH].

gkectl repair admin-master puede fallar debido a failed to delete the admin master node object and reboot the admin master VM

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

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

Solución alternativa:

Este comando es idempotente. Se puede volver a ejecutar de forma segura hasta que el comando se ejecute correctamente.

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

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

Solución alternativa:

Puedes ignorar los Pods con errores o borrarlos de forma manual.

El clúster de usuario OnPrem no está listo debido a las credenciales del registro privado

Si usas credenciales preparadas y un registro privado, pero no configuraste credenciales preparadas para tu registro privado, es posible que OnPremUserCluster no esté listo y 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 según las instrucciones en Configura credenciales preparadas.

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

Durante gkectl upgrade admin, la verificación previa del almacenamiento para la migración a CSI verifica que las StorageClasses no tengan parámetros que se ignoren después de la migración a CSI. Por ejemplo, si hay un StorageClass con el parámetro diskformat, entonces gkectl upgrade admin marca el StorageClass y genera un informe de falla en la validación previa al vuelo. Los clústeres de administrador creados en Google Distributed Cloud 1.10 y versiones anteriores tienen una StorageClass con diskformat: thin, lo que provocará un error en esta validación. Sin embargo, esta StorageClass seguirá funcionando correctamente después de la migración de CSI. Estos errores se deben interpretar como advertencias.

Para obtener más información, consulta la sección de parámetros de StorageClass en Migración de volúmenes de vSphere integrados 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 ejecución de la migración de CSI, ejecuta gkectl upgrade admin con la marca --skip-validation-cluster-health.

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

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

Solución alternativa:

1. Obtén el UID del Pod que no puede escribir en su volumen:

   kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get pod \
       POD_NAME --namespace POD_NAMESPACE \
       -o=jsonpath='{.metadata.uid}{"\n"}'

2. Usa el objeto PersistentVolumeClaim para obtener el nombre del objeto PersistentVolume:

   kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get pvc \
       PVC_NAME --namespace POD_NAMESPACE \
       -o jsonpath='{.spec.volumeName}{"\n"}'

3. Determina el nombre del nodo en el que se ejecuta el Pod:

   kubectl --kubeconfig USER_CLUSTER_KUBECONFIGget pods \
       --namespace POD_NAMESPACE \
       -o jsonpath='{.spec.nodeName}{"\n"}'

4. Obtén acceso a PowerShell en el nodo a través de SSH o la interfaz web de vSphere.
5. Establece las variables de entorno:

   PS C:\Users\administrator> pvname=PV_NAME
   PS C:\Users\administrator> podid=POD_UID

6. Identifica el número de disco asociado 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. Verifica que el disco sea readonly:

   PS C:\Users\administrator> (Get-Disk -Number $disknum).IsReadonly

   El resultado debería ser True.
8. Establece readonly en false.

   PS C:\Users\administrator> Set-Disk -Number $disknum -IsReadonly $false
   PS C:\Users\administrator> (Get-Disk -Number $disknum).IsReadonly

9. Borra el Pod para que se reinicie:

   kubectl --kubeconfig USER_CLUSTER_KUBECONFIG delete pod POD_NAME \
       --namespace POD_NAMESPACE

10. El Pod se debe programar en el mismo nodo. Sin embargo, en caso de que el Pod se programe en un nodo nuevo, es posible que debas repetir los pasos anteriores en el nodo nuevo.

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

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

Solución alternativa:

1. Obtén el nombre del secreto vsphere-csi-secret:

   kubectl --kubeconfig=ADMIN_KUBECONFIG -n=kube-system get secrets | grep vsphere-csi-secret

2. Actualiza los datos del secreto vsphere-csi-secret que obtuviste en el paso anterior:

   kubectl --kubeconfig=ADMIN_KUBECONFIG -n=kube-system patch secret CSI_SECRET_NAME -p \
     "{\"data\":{\"config\":\"$( \
       kubectl --kubeconfig=ADMIN_KUBECONFIG -n=kube-system get secrets CSI_SECRET_NAME -ojsonpath='{.data.config}' \
         | base64 -d \
         | sed -e '/user/c user = \"VSPHERE_USERNAME_TO_BE_UPDATED\"' \
         | sed -e '/password/c password = \"VSPHERE_PASSWORD_TO_BE_UPDATED\"' \
         | base64 -w 0 \
       )\"}}"

3. Reinicia vsphere-csi-controller:

   kubectl --kubeconfig=ADMIN_KUBECONFIG -n=kube-system rollout restart deployment vsphere-csi-controller

4. Puedes hacer un seguimiento del estado del lanzamiento con el siguiente comando:

   kubectl --kubeconfig=ADMIN_KUBECONFIG -n=kube-system rollout status deployment vsphere-csi-controller

   Después de que la implementación se lance correctamente, el controlador debe usar el vsphere-csi-secret actualizado.

audit-proxy bucle de fallas cuando se habilitan los Registros de auditoría de Cloud con gkectl update cluster

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

Solución alternativa:

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

Para un clúster de usuario de plano de control v1, edita el contenedor audit-proxy en el conjunto con estado kube-apiserver para agregar --cluster_name=USER_CLUSTER_NAME:

kubectl edit statefulset kube-apiserver -n USER_CLUSTER_NAME --kubeconfig=ADMIN_CLUSTER_KUBECONFIG

Derecho de volver a implementar un plano de control adicional inmediatamente después de gkectl upgrade cluster

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

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

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

Solución alternativa:

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

Se quitó la versión incorrecta 1.12.7-gke.19

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

Solución alternativa:

En su lugar, usa la versión 1.12.7-gke.20.

gke-connect-agent sigue usando la imagen anterior después de que se actualizaron las credenciales del registro

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

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

Es posible que gke-connect-agent siga usando la imagen anterior 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, y en las versiones posteriores.

Solución alternativa:

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

1. Borra el espacio de nombres gke-connect:

   kubectl --kubeconfig=KUBECONFIG delete namespace gke-connect

2. Vuelve a implementar gke-connect-agent con la clave de la cuenta de servicio de registro original (no es necesario actualizar la clave):
   Para el clúster de administrador:

   gkectl update credentials register --kubeconfig=ADMIN_CLUSTER_KUBECONFIG --config ADMIN_CLUSTER_CONFIG_FILE --admin-cluster

   Para el clúster de usuarios:

   gkectl update credentials register --kubeconfig=ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG_FILE

Opción 2: Puedes cambiar manualmente los datos del secreto de extracción de imágenes regcred que usa la implementación de gke-connect-agent:

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

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

1. Copia el secreto predeterminado en el espacio de nombres gke-connect:

   kubectl --kubeconfig=KUBECONFIG -n=kube-system get secret private-registry-creds -oyaml | sed 's/ namespace: .*/ namespace: gke-connect/' | kubectl --kubeconfig=KUBECONFIG -n=gke-connect apply -f -

2. Obtén el nombre de la implementación de gke-connect-agent:

   kubectl --kubeconfig=KUBECONFIG -n=gke-connect get deployment | grep gke-connect-agent

3. Agrega el secreto predeterminado a la implementación de gke-connect-agent:

   kubectl --kubeconfig=KUBECONFIG -n=gke-connect patch deployment DEPLOYMENT_NAME -p '{"spec":{"template":{"spec":{"imagePullSecrets": [{"name": "private-registry-creds"}, {"name": "regcred"}]}}}}'

Falla en la verificación manual de la configuración del balanceador de cargas

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

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

Solución alternativa:

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

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

gkectl check-config --skip-validation-load-balancer

Agotamiento de la observación de etcd

Los clústeres que ejecutan la versión 3.4.13 de etcd o una anterior pueden experimentar agotamiento de la observación y observaciones de recursos no operativas, lo que puede provocar los siguientes problemas:

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

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

Este problema se solucionó en las versiones 1.12.7, 1.13.6 y 1.14.3 de Google Distributed Cloud, y 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 alternativa

Si no puedes actualizar de inmediato, puedes mitigar el riesgo de falla del clúster reduciendo la cantidad de nodos en él. Quita nodos hasta que la métrica etcd_network_client_grpc_sent_bytes_total sea inferior a 300 MB/s.

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

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

   Ir al Explorador de métricas

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

GKE Identity Service puede causar latencias en el plano de control

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

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

• 1.12.6+
• 1.13.6+
• 1.14.2+

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

1. Verifica si se puede acceder al extremo de GKE Identity Service de forma externa:

   curl -s -o /dev/null -w "%{http_code}" \
       -X POST https://CLUSTER_ENDPOINT/api/v1/namespaces/anthos-identity-service/services/https:ais:https/proxy/authenticate -d '{}'

   Reemplaza CLUSTER_ENDPOINT por la VIP del plano de control y el puerto del balanceador de cargas del plano de control 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 se agota el tiempo de espera de la solicitud, reinicia el Pod ais y vuelve a ejecutar el comando curl para ver si se resuelve el problema. Si recibes un código de estado 000, el problema se resolvió y terminaste. Si sigues recibiendo un código de estado 400, significa que el servidor HTTP de GKE Identity Service no se inicia. En este caso, continúa.

2. Verifica los registros de GKE Identity Service y kube-apiserver:
   1. Verifica el registro de GKE Identity Service:

      kubectl logs -f -l k8s-app=ais -n anthos-identity-service \
          --kubeconfig KUBECONFIG

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

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

   2. Verifica los registros de kube-apiserver de tus clústeres:

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

      Clúster de administrador:

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

      Clúster de usuario

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

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

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

Solución alternativa

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

1. Aumenta el nivel de verbosidad de GKE Identity Service a 9:

   kubectl patch deployment ais -n anthos-identity-service --type=json \
       -p='[{"op": "add", "path": "/spec/template/spec/containers/0/args/-", \
       "value":"--vmodule=cloud/identity/hybrid/charon/*=9"}]' \
       --kubeconfig KUBECONFIG

2. Verifica el registro de GKE Identity Service 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 la cuenta de servicio relacionada 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.

El problema del aumento del uso de memoria de los pods de etcd-maintenance

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

Solución alternativa:

Opción 1: Actualiza a la versión de parche más reciente de la 1.8 a la 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 cantidad de réplicas del pod etcd-maintenance para el clúster de administrador y el 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

No se realizan las verificaciones de estado de los Pods del plano de control del clúster de usuario

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

Solución alternativa:

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

kubectl get pods -owide -n USER_CLUSTER_NAME --kubeconfig ADMIN_CLUSTER_KUBECONFIG

Las actualizaciones de los clústeres de administrador de las versiones 1.6 y 1.7 pueden verse afectadas por el redireccionamiento 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 este no permite registry.k8s.io, y la imagen del contenedor k8s.gcr.io/pause:3.2 no se almacena en caché de forma local, las actualizaciones del clúster de administrador fallarán cuando se extraiga la imagen del contenedor.

Solución alternativa:

Agrega registry.k8s.io a la lista de entidades permitidas del proxy para tu estación de trabajo de administrador.

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

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

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

Esto se debe a que el archivo del grupo de Seesaw ya existe. Y la verificación previa intenta validar un balanceador de cargas de seesaw inexistente.

Solución alternativa:

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

Se agotó el tiempo de espera de la aplicación debido a errores de inserción en la tabla de conntrack

La versión 1.14 de Google Distributed Cloud es susceptible a errores de inserción de la tabla de seguimiento de conexiones (conntrack) de netfilter cuando se usan imágenes del sistema operativo Ubuntu o COS. Las fallas de inserción provocan tiempos de espera aleatorios de la aplicación y pueden ocurrir incluso cuando la tabla de seguimiento de conexiones 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 según la longitud de la cadena.

Para ver si este problema te afecta, 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 es similar a la que se muestra a continuación:

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

Si un valor de chaintoolong en la respuesta es un número distinto de cero, significa que este problema te afecta.

Solución alternativa

La 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

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

Bucle de fallas de calico-typha o anetd-operator en nodos de Windows con Controlplane V2

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

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

Solución alternativa:

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

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

Quita los siguientes elementos spec.template.spec.tolerations:

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

Agrega la siguiente tolerancia:

    - key: node-role.kubernetes.io/master
      operator: Exists
    

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

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

[FAILURE] Docker registry access: Failed to login.

Solución alternativa:

• Si no tenías la intención de especificar el campo o quieres usar la misma credencial de registro privado que el clúster de administrador, puedes quitar o comentar la sección privateRegistry en el archivo de configuración del clúster de usuario.
• Si deseas usar una credencial de registro privado específica para tu clúster de usuario, puedes especificar temporalmente la sección privateRegistry de esta manera:

  privateRegistry:
    address: PRIVATE_REGISTRY_ADDRESS
    credentials:
      username: PRIVATE_REGISTRY_USERNAME
      password: PRIVATE_REGISTRY_PASSWORD
    caCertPath: PRIVATE_REGISTRY_CACERT_PATH

  (NOTA: Esta es solo una solución temporal, y estos campos ya están obsoletos. Considera usar el archivo de credenciales cuando actualices a la versión 1.14.3 o posterior).

Cloud Service Mesh y otras mallas de servicio no compatibles con Dataplane v2

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

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

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

Solución alternativa:

Actualiza a la versión 1.11 para obtener compatibilidad total o, si ejecutas 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
    

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

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

kube-controller-manager podría desconectar volúmenes persistentes de forma forzada después de 6 minutos

kube-controller-manager podría agotar el tiempo de espera cuando se desconectan los PV o PVC después de 6 minutos y desconectar los PV o PVC de forma forzada. Los registros detallados de kube-controller-manager muestran eventos similares a los siguientes:

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

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

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

# See all the mounting points with disks
lsblk -f

# See some ext4 errors
sudo dmesg -T

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

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

Solución alternativa:

Conéctate al nodo afectado con SSH y reinícialo.

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

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

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

Solución alternativa:

Realiza la actualización con la opción --skip-validation-all.

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

El nodo principal del administrador creado a través de gkectl repair admin-master puede usar una versión de hardware de VM inferior a la esperada. Cuando ocurra el problema, verás el error en el informe de gkectl diagnose cluster.

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

Solución alternativa:

Apaga el nodo principal del administrador, sigue las instrucciones en https://kb.vmware.com/s/article/1003746 para actualizar el nodo a la versión esperada que se describe en el mensaje de error y, luego, inicia el nodo.

La VM libera la asignación de tiempo de DHCP cuando se apaga o reinicia de forma inesperada, lo que puede provocar cambios en la IP.

En systemd v244, systemd-networkd tiene un cambio de comportamiento predeterminado en la configuración de KeepConfiguration. Antes de este cambio, las VMs no enviaban un mensaje de liberación de la concesión de DHCP al servidor de DHCP cuando se apagaban o reiniciaban. Después de este cambio, las VMs envían ese mensaje y devuelven las IPs al servidor DHCP. Como resultado, la IP liberada se puede reasignar a otra VM o se le puede asignar otra IP a la VM, lo que genera un conflicto de IP (a nivel de Kubernetes, no de vSphere) o un cambio de IP en las VMs, lo que puede dañar los clústeres de varias maneras.

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

• La IU de vCenter muestra que ninguna VM usa la misma IP, pero kubectl get nodes -o wide 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 de calico-node

  2023-01-19T22:07:08.817410035Z 2023-01-19 22:07:08.817 [WARNING][9] startup/startup.go 1135: Calico node 'node1' is already using the IPv4 address 10.180.85.130.
  2023-01-19T22:07:08.817514332Z 2023-01-19 22:07:08.817 [INFO][9] startup/startup.go 354: Clearing out-of-date IPv4 address from this node IP="10.180.85.130/24"
  2023-01-19T22:07:08.825614667Z 2023-01-19 22:07:08.825 [WARNING][9] startup/startup.go 1347: Terminating
  2023-01-19T22:07:08.828218856Z Calico node failed to start

Solución alternativa:

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

      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
      

Se borró la clave de la cuenta de servicio de acceso a componentes después de actualizar el clúster de administrador de la versión 1.11.x

Este problema solo afectará a los clústeres de administrador que se actualicen desde la versión 1.11.x y no afectará a los clústeres de administrador que se creen 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 verificarlo, ejecuta el siguiente comando:

kubectl --kubeconfig ADMIN_KUBECONFIG -n kube-system get secret admin-cluster-creds -o yaml | grep 'component-access-sa-key'

Después de que se borre la clave de la cuenta de servicio de acceso al componente, fallará la instalación de clústeres de usuarios nuevos o la actualización de los existentes. A continuación, se enumeran algunos mensajes de error que podrías encontrar:

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

Solución alternativa:

Vuelve a agregar 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 -

El escalador automático de clústeres no funciona cuando Controlplane V2 está habilitado

En el caso de los clústeres de usuario creados con Controlplane V2 habilitado, los grupos de nodos con ajuste de escala automático habilitado siempre usan su autoscaling.minReplicas en user-cluster.yaml. El registro del pod del escalador automático del clúster 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
  

  > kubectl --kubeconfig $USER_CLUSTER_KUBECONFIG -n kube-system \
   get pods | grep cluster-autoscaler
cluster-autoscaler-5857c74586-txx2c                          4648017n    48076Ki    30s
  

Solución alternativa:

Inhabilita el ajuste de escala automático en todos los grupos de nodos con `gkectl update cluster` hasta que actualices a una versión con la corrección.

No se permite el CIDR en el archivo de bloqueo de IP

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

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

Solución alternativa:

Incluye IPs individuales en el archivo de bloqueo de IP hasta que actualices a una versión con la corrección: 1.12.5, 1.13.4, 1.14.1 o posterior.

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

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

Solución alternativa:

Una vez finalizada la actualización, sigue esperando a que las máquinas del plano de control del usuario también terminen de volver a crearse. Para ello, supervisa los tipos de imágenes del SO de sus nodos con kubectl --kubeconfig USER_KUBECONFIG get nodes -owide. p.ej., si se actualiza de Ubuntu a COS, debemos esperar a que todas las máquinas del plano de control cambien por completo de Ubuntu a COS, incluso después de que se complete el comando de actualización.

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