Se usó la API de Cloud Translation para traducir esta página.

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

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

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

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

Selecciona tu versión de Google Distributed Cloud:

Selecciona la categoría del problema:

O bien, busca tu problema:

Categoría Versiones identificadas Problema y solución

Actualizaciones

1.32.0-1.32.600, 1.33.0-1.33.100

No se pudo actualizar el clúster de usuario sin HA a un clúster avanzado con HA debido al campo `masterNode.replicas` inmutable

El uso de gkectl update para actualizar un clúster de usuario sin alta disponibilidad (sin HA) a un clúster avanzado con un plano de control de HA falla y muestra el siguiente mensaje de error:

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

Solución alternativa:

Usa el comando gkectl upgrade para actualizar el clúster de usuario sin alta disponibilidad a un clúster avanzado con alta disponibilidad.

Actualizaciones

1.30 y 1.31

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

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

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

Solución alternativa:

Haz una copia de seguridad del Secret user-component-options en el espacio de nombres del clúster de usuario:

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

Borra el secreto user-component-options:

    kubectl delete secret user-component-options -n USER_CLUSTER_NAME

Edita el recurso onpremusercluster para activar la reconciliación agregando la anotación onprem.cluster.gke.io/reconcile: "true":
```
    kubectl edit onpremusercluster USER_CLUSTER_NAME -n USER_CLUSTER_MGMT_NAMESPACE
    
```

Reemplaza USER_CLUSTER_NAME por el nombre de tu clúster de usuario.

Actualizaciones

1.32.0-1.32.500, 1.33.0

La actualización a un clúster avanzado falla si no se configura stackdriver.

Cuando actualizas un clúster no avanzado a un clúster avanzado, es posible que el proceso deje de responder si Stackdriver no está habilitado.

Solución alternativa:

Si el clúster aún no se actualizó, debes seguir los pasos para habilitar stackdriver:
1. Agrega la sección stackdriver al archivo de configuración del clúster.
2. Ejecuta gkectl update para habilitar stackdriver.

Si ya hay una actualización en curso, sigue estos pasos:

Edita el Secret user-cluster-creds en el espacio de nombres USER_CLUSTER_NAME-gke-onprem-mgmt con el siguiente comando:

kubectl --kubeconfig ADMIN_KUBECONFIG \
  patch secret user-cluster-creds \
  -n USER_CLUSTER_NAME-gke-onprem-mgmt \
  --type merge -p "{\"data\":{\"stackdriver-service-account-key\":\"$(cat STACKDRIVER_SERVICE_ACCOUNT_KEY_FILE | base64 | tr -d '\n')\"}}"

Actualiza el recurso personalizado OnPremUserCluster con el campo stackdriver. Debes usar el mismo proyecto con la misma ubicación del proyecto y la misma clave de la cuenta de servicio que cloudauditlogging si habilitaste la función.

kubectl --kubeconfig ADMIN_KUBECONFIG \
    patch onpremusercluster USER_CLUSTER_NAME \
    -n USER_CLUSTER_NAME-gke-onprem-mgmt --type merge -p '
    spec:
      stackdriver:
        clusterLocation: PROJECT_LOCATION
        providerID: PROJECT_ID
        serviceAccountKey:
          kubernetesSecret:
            keyName: stackdriver-service-account-key
            name: user-cluster-creds
'

Agrega la sección stackdriver al archivo de configuración del clúster para mantener la coherencia.

Actualizaciones

1.29, 1.30, 1.31, 1.32 y versiones posteriores

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

En los clústeres que usan la arquitectura de Control Plane V2 (CPv2) (predeterminada en la versión 1.29 y versiones posteriores) y Dataplane V2, es posible que los Pods no se puedan conectar al servidor de la API de Kubernetes (kubernetes.default.svc.cluster.local). Este problema suele deberse a la presencia de políticas de red, en especial aquellas con reglas de salida de rechazo predeterminadas. Los síntomas incluyen los siguientes:

Los intentos de conexión TCP a la dirección IP del clúster o a las direcciones IP de los nodos del servidor de la API generan un mensaje Connection reset by peer.
Se producen errores en el protocolo de enlace TLS cuando se conecta al servidor de la API.
Ejecutar el comando cilium monitor -t drop en el nodo afectado puede mostrar que se descartan los paquetes destinados a las direcciones IP del nodo del plano de control y al puerto del servidor de la API (por lo general, 6443).

Causa

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

Solución alternativa:

En las versiones 1.29, 1.30 y 1.31, evita usar políticas de red de salida restrictivas que puedan bloquear el tráfico hacia los nodos del plano de control. Si necesitas una política de rechazo predeterminada, es posible que debas agregar una regla de permiso amplia para todo el tráfico de salida, por ejemplo, no especificando ninguna regla to en la sección de salida, lo que permite todo el tráfico de salida de manera efectiva. Esta solución es menos segura y es posible que no sea adecuada para todos los entornos.

Para todas las demás versiones, habilita una configuración de Cilium para que coincidan correctamente las IPs de los nodos en los campos ipBlock de la política de red. Para que coincidan las IPs de los nodos en los campos ipBlock de la política de red, haz lo siguiente:

Edita el ConfigMap cilium-config:

kubectl edit configmap -n kube-system cilium-config

Agrega o modifica la sección de datos para incluir policy-cidr-match-mode: nodes:
```
data:
      policy-cidr-match-mode: nodes
```
Para aplicar el cambio de configuración, reinicia el DaemonSet de anetd:
```
kubectl rollout restart ds anetd -n kube-system
```

Asegúrate de tener una política de red que permita de forma explícita el tráfico de salida de tus Pods a las IPs de los nodos del plano de control en el puerto del servidor de la API. Para identificar las direcciones IP de los nodos del plano de control del clúster de usuario, ejecuta kubectl get svc kubernetes. El resultado es similar al siguiente:

    apiVersion: networking.k8s.io/v1
    kind: NetworkPolicy
    metadata:
      name: allow-egress-to-kube-apiserver
      namespace: NAMESPACE_NAME
    spec:
      podSelector: {} 
      policyTypes:
      - Egress
      egress:
      - to:
        - ipBlock:
            cidr: CP_NODE_IP_1/32
        - ipBlock:
            cidr: CP_NODE_IP_2/32
        ports:
        - protocol: TCP
          port: 6443 # Kubernetes API Server port on the node

Instalación

1.30.200-gke.101

El Pod del agente `gke-connect` está atascado en el estado `Pending` durante la creación del clúster de usuarios

Durante la creación del clúster de usuario, es posible que el Pod del agente gke-connect se quede atascado en un estado Pending, lo que impide que el clúster se cree por completo. Este problema se produce porque el Pod del agente gke-connect intenta programarse antes de que los nodos de trabajo estén disponibles, lo que genera un interbloqueo.

Este problema surge cuando falla la creación inicial del clúster de usuarios debido a errores de validación previa al vuelo y se realiza un intento posterior para crear el clúster sin borrar primero los recursos creados parcialmente. En el intento de creación del clúster posterior, el Pod del agente gke-connect se atasca debido a las marcas no toleradas en los nodos del plano de control, como lo indica un error similar al siguiente:

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

Solución alternativa:

Si la creación del clúster de usuario falla debido a errores de validación previa, borra los recursos del clúster creados parcialmente antes de intentar crear el clúster nuevamente con las configuraciones corregidas. Esto garantiza que el flujo de trabajo de creación se realice correctamente, incluida la creación de grupos de nodos antes de que se implemente el Pod del agente gke-connect.

Actualizar

1.16 y versiones anteriores, 1.28.0 a 1.28.1100, 1.29.0 a 1.29.700 y 1.30.0 a 1.30.200

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:

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

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

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

Configuración

1.29, 1.30 y 1.31

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 genera 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 activar errores y el campo hostgroups se conserva.

Redes

1.29.0-1.29.1000, 1.30.0-1.30.500, 1.31.0-1.31.100

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

Instalación

1.29.0-1.29.1000, 1.30.0-1.30.500, 1.31.0-1.31.100

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.

Instalación y actualizaciones

1.30.0 a 1.30.500, 1.31.0 a 1.31.100

`Runtime: out of memory` "error" 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:

Aumenta el tamaño de la memoria del SO en el que ejecutas el comando gkeadm.

Actualizaciones

1.30.0-1.30.400

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

Cuando se actualiza un clúster de administrador sin 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:

Repara el nodo principal del administrador:

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

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.

Reanuda la actualización:

gkectl upgrade admin --kubeconfig ADMIN_KUBECONFIG \
    --config ADMIN_CONFIG_FILE

Configuración

1.31.0

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

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

Migración

1.29.0-1.29.800, 1.30.0-1.30.400, 1.31.0

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

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:

Borra el secreto metallb-memberlist existente:

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

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

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

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

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
```
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 para administradores volverán a ser Ready y se podrá continuar con la migración.
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.

Configuración y funcionamiento

1.12+, 1.13+, 1.14+, 1.15+, 1.16+, 1.28+, 1.29+, 1.30+

La copia de seguridad del clúster de 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.

Actualizaciones

1.28, 1.29 y 1.30

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:

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

    kubectl get machine -o wide --kubeconfig=ADMIN_KUBECONFIG

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

    kubectl edit machine MACHINE_NAME --kubeconfig=ADMIN_KUBECONFIG

Guarda la edición.

Ejecuta el siguiente comando para borrar la máquina:
```
    kubectl delete machine MACHINE_NAME --kubeconfig=ADMIN_KUBECONFIG
    
```
Se creará una máquina nueva con la versión correcta.

Configuración

1.30.0

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:

Ejecuta terraform plan
En el resultado, verifica si los campos vCenter están configurados como nil.
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.
Vuelve a ejecutar terraform plan y verifica el resultado para confirmar que la actualización sea la esperada.

Actualizaciones

1.13, 1.14, 1.15 y 1.16

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.

Instalación, actualizaciones y revisiones

1.31

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 del 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 solucionar el problema.

1.31

`cloud-init status` siempre devuelve un error

Cuando se actualiza a la versión 1.31 un clúster que usa la imagen de SO Container-Optimized OS (COS), falla el comando cloud-init status, 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

Actualizaciones

1.28

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 de administración aumentó de 50 GB a 100 GB.

Solución alternativa:

Revierte la estación de trabajo de administrador.
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.
Actualiza la estación de trabajo de administrador.

Actualizaciones

1.30

`gkectl` devuelve un error falso en la clase de almacenamiento de NetApp

El comando gkectl upgrade devuelve un error incorrecto sobre la clase de almacenamiento de NetApp. El mensaje de error es similar al siguiente:

    detected unsupported drivers:
      csi.trident.netapp.io

Solución alternativa:

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

Identidad

todas las versiones

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.

Copia el certificado de CA del clúster del campo certificate-authority-data en el archivo kubeconfig del clúster de administrador.

Edita ClientConfig y pega el certificado de CA en el campo spec.certificateAuthorityData.

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

Actualizaciones

1.28+

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.

VMware, actualizaciones

1.16

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

Migración

1.29 y 1.30

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.

Migración

1.29.0 a 1.29.600 y 1.30.0 a 1.30.100

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 afectadas 1.29 y 1.30, cuando se migra el clúster de administrador de no HA a HA, el proceso de migración no controla correctamente la clave de 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.

Actualizaciones

1.16, 1.28, 1.29 y 1.30

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

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.

Actualizaciones

1.16+

La actualización del clúster de usuario falla debido al tiempo de espera 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 una falla 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

Actualizaciones

1.16, 1.28.0-1.28.800, 1.29.0-1.29.400, 1.30.0

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.

Actualizaciones

1.16

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.

Instalación

1.16 a 1.29

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.

Actualizaciones

1.29.0

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

Instalación, actualizaciones y revisiones

1.28.0-1.28.600,1.29.0-1.29.100

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:

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.

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

Actualizaciones

1.16, 1.28 y 1.29

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:

Obtén el objeto de la máquina duplicada y guárdalo en un archivo local para fines de copia de seguridad.

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

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.
Vuelve a ejecutar gkectl upgrade cluster para reanudar la actualización

Configuración, instalación

1.15, 1.16, 1.28 y 1.29

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.

Instalación, actualizaciones y revisiones

1.29.0 - 1.29.100

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 ocurre en la versión 1.29 y versiones posteriores, ya que se agregó una validación al controlador de CSI de vSphere para aplicar el uso de nombres de usuario de dominio completamente calificados.

Solución alternativa:

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

Actualizaciones

1.28.0 a 1.28.500

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:

Conéctate a la máquina principal de administrador con errores a través de SSH.
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:

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.
Crea una copia de /etc/startup/pki-yaml.sh y asígnale el nombre /etc/startup/pki-yaml-copy.sh.

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

Guarda los cambios en /etc/startup/pki-yaml-copy.sh.
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.
Ejecuta /opt/bin/master.sh para generar el certificado y completar el inicio de la máquina.
Vuelve a ejecutar gkectl upgrade admin para actualizar el clúster de administrador.
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.
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.

Configuración

1.29.0

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 estableciste enableDataplaneV2: true en el archivo de configuración del clúster.

Solución alternativa:

Puedes ignorar esta advertencia.

Configuración

1.28.0-1.28.400, 1.29.0

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 con alta disponibilidad 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 comprobación previa incorrecta en una versión no corregida, agrega --skip-validation-net-config al comando gkectl.

Operación

1.29.0-1.29.100

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

Instalación, sistema operativo

1.28.0-1.28.500, 1.29.0

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.

update

1.28.0 a 1.28.400 y 1.29.0 a 1.29.100

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 múltiples 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.

update

1.15, 1.16 y 1.28

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

Actualizaciones

1.15 y 1.16

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

En ocasiones, puede haber un problema con la comunicación entre el servidor de la API de Kubernetes y el webhook. Cuando esto sucede, es posible que veas el siguiente mensaje de error:

failed to apply OnPremAdminCluster 'kube-system/gke-admin-btncc': Internal error occurred: failed calling webhook "monpremadmincluster.onprem.cluster.gke.io": failed to call webhook: Post "https://onprem-admin-cluster-controller.kube-system.svc:443/mutate-onprem-cluster-gke-io-v1alpha1-onpremadmincluster?timeout=10s": dial tcp 10.96.55.208:443: connect: connection refused

Solución alternativa:

Si encuentras alguno de estos errores, usa una de las siguientes soluciones alternativas, según tu versión:

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

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

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

Configuración

1.15.0 a 1.15.10, 1.16.0 a 1.16.6, 1.28.0 a 1.28.200

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 necesitar configurar la sección loadBalancer.manualLB en el archivo de configuración para un clúster de administrador de alta disponibilidad (HA) en las versiones 1.16 y posteriores. Sin embargo, cuando esta sección está vacía, Google Distributed Cloud asigna valores predeterminados a todos los NodePorts, incluido manualLB.controlPlaneNodePort, lo que 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
  ...

Almacenamiento

1.28.0-1.28.100

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.

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

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

Solución alternativa:

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

A continuación, aplica el siguiente DaemonSet a tu clúster para instalar nfs-common:

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

Almacenamiento

1.28.0-1.28.100

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.

Registro y supervisión

1.28.0-1.28.100

La API de Kubernetes Metadata no admite 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 el campo `featureGates.disableExperimentalMetadataAgent` en `true` en el CR `stackdriver` establecido en el espacio de nombres `kube-system`.

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

Luego, ejecuta

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

Actualizaciones

1.15.0 a 1.15.7, 1.16.0 a 1.16.4 y 1.28.0

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

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

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

Solución alternativa:

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

Registro y supervisión

1.14

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:

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

Silencia la alerta desde la IU de Alert Manager.
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 configuración nueva.
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.

Redes

1.16.0-1.16.2, 1.28.0

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.

Operación

1.14, 1.15 y 1.16

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

Redes, actualizaciones

1.16.0-1.16.3

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

Actualizaciones

1.13, 1.14, 1.15.0-1.15.6

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.

Almacenamiento

1.15.0 a 1.15.6 y 1.16.0 a 1.16.2

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

Crea una PVC que use la StorageClass standard-rwo.
Crea un Pod que use la PVC.
Verifica que el Pod pueda leer y escribir datos en el volumen.
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.

Operación

1.16.0-1.16.2

Cuando accedes a una estación de trabajo de administrador administrada por el usuario, es posible que el comando gkectl update cluster 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:

Ejecuta el siguiente comando para volver a implementar validation-controller:

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

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

Operación

1.16.0-1.16.2

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:

Ejecuta el siguiente comando para implementar validation-controller:

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

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

Actualizaciones

1.16.0-1.16.2

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:

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.
Agrega la anotación onprem.cluster.gke.io/skip-project-location-sameness-validation: true y guarda el recurso personalizado.
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 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.

Operación

1.16.0-1.16.2

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:

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

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

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.

Redes

1.15 y 1.16

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:

Edita el ConfigMap cilium-config:

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

Agrega lo siguiente al ConfigMap cilium-config:
```
tunnel-port: 4789
```

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.

Actualizaciones

1.15.0-1.15.4

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:

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
```
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.
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.
Para reiniciar el Pod estático kms-plugin, mueve /etc/kubernetes/manifests/kms-plugin.yaml a otro directorio y, luego, vuelve a moverlo.
Para reanudar la actualización del administrador, vuelve a ejecutar gkectl upgrade admin.

Cómo evitar la falla 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:

Crea una copia de seguridad del clúster de administrador.
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
```
Actualiza el clúster de administrador.
Vuelve a habilitar la encriptación de secretos siempre activa.

Almacenamiento

1.11-1.16

Errores de disco y fallas de conexión cuando se usa el seguimiento de bloques de cambio (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 crees 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.

Almacenamiento

1.14, 1.15 y 1.16

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.

Sistema operativo

1.13.10, 1.14.6, 1.15.3

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 versiones identificadas:

Versión de Google Distributed Cloud	Versión de kubelet	Versión de Kubernetes
1.13.10	v1.24.11-gke.1200	v1.24.14-gke.2100
1.14.6	v1.25.8-gke.1500	v1.25.10-gke.1200
1.15.3	v1.26.2-gke.1001	v1.26.5-gke.2100

Solución alternativa:

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

Actualizaciones

1.15.0-1.15.4

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

Operación

1.13, 1.14.0 a 1.14.8, 1.15.0 a 1.15.4, 1.16.0 a 1.16.1

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 detiene 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

Almacenamiento

1.15.0 y 1.16.0

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

Almacenamiento

1.16.0

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

Actualizaciones

1.15.0 y 1.16.0

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.

Actualizaciones

1.16.0-1.16.5

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:

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

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:

Agrega el archivo de información de compilación /etc/cloud/build.info con el siguiente contenido. Esto hace que las verificaciones 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
```
Vuelve a ejecutar el comando de actualización.
Una vez que se complete la actualización, borra el archivo build.info.

Crear

1.16.0 a 1.16.5 y 1.28.0 a 1.28.100

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.

Actualizaciones

1.16

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 provoca 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

Y verás los eventos de la siguiente manera:

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

Solución alternativa:

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.
Reinicia kubelet con el siguiente comando:
```
    sudo systemctl restart kubelet
    
```
Después del reinicio, kubelet puede reconstruir el montaje global de la etapa correctamente.

Actualizaciones

1.16.0

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 nuevo nodo del plano de control. 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:

Reinicia la máquina con errores para volver a crear el objeto del nodo borrado.

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

Vuelve a ejecutar el comando de actualización.

Operación

1.16

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:

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

          export GOVC_DATACENTER=GOVC_DATACENTER
          export GOVC_URL=GOVC_URL
          export GOVC_USERNAME=GOVC_USERNAME
          export GOVC_PASSWORD=GOVC_PASSWORD
          export GOVC_INSECURE=true
          govc find . -type m -guest.hostName HOSTNAME

Comandos y resultados de ejemplo:

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

La solución 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:

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

Si se trata de un clúster de administrador sin alta disponibilidad y ves 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}'

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.

Operación

1.16.0, 1.16.1, 1.16.2, 1.16.3

`$` y ` no son compatibles con el nombre de usuario ni 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 de la versión 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:

Cambia el nombre de usuario o la contraseña de vCenter en el lado de vCenter para quitar $ y `.
Actualiza el nombre de usuario o la contraseña de vCenter en tu archivo de configuración de credenciales.
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:

Cambia el nombre de usuario o la contraseña de vCenter en el lado de vCenter para quitar $ y `.
Actualiza el nombre de usuario o la contraseña de vCenter en tu archivo de configuración de credenciales.
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.

Almacenamiento

1.11+, 1.12+, 1.13+, 1.14+, 1.15+ y 1.16

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

Operación

1.16.0

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:

Ve a la página Hosts and Clusters en el cliente de vSphere.
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.
Copia el nombre de la plantilla de VM que coincida con el nombre de la máquina que estás reparando y usa el nombre de la plantilla en el comando de reparación.

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

Redes

1.10.0+, 1.11.0+, 1.12.0+, 1.13.0+, 1.14.0-1.14.7, 1.15.0-1.15.3, 1.16.0

La VM de Seesaw se dañó porque el espacio en el disco es insuficiente

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.

Operación

1.13, 1.14.0-1.14.6 y 1.15

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.

Actualizaciones

1.13.0 a 1.13.9, 1.14.0 a 1.14.6, 1.15.1 a 1.15.2

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:

Cancela la inscripción del clúster de administrador:

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

y reanuda la actualización del clúster de administrador. Es posible que veas temporalmente el error obsoleto "No se pudo registrar el clúster". Después de un tiempo, debería actualizarse automáticamente.

Actualizaciones

1.13.0 a 1.13.9, 1.14.0 a 1.14.4 y 1.15.0

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:

Cancela la inscripción del clúster de administrador:

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

y volver a inscribir el clúster de administrador.

Redes

1.15.0-1.15.2

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

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

Actualizaciones

1.10, 1.11, 1.12, 1.13.0 a 1.13.7, 1.14.0 a 1.14.3

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

Para solucionar este problema, deberás editar el punto de control o inhabilitarlo para la actualización. Comunícate con nuestro equipo de asistencia al cliente para continuar con la solución alternativa.

Operación

1.13.0 a 1.13.9, 1.14.0 a 1.14.5, 1.15.0 a 1.15.1

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 mostrar errores de autorización como los siguientes:
```
Failed to reconcile admin cluster: unable to populate admin clients: failed to get admin controller runtime client: Unauthorized
```

Los registros de kube-apiserver 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.

Operación de redes

1.10, 1.11, 1.12, 1.13 y 1.14

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 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 un objeto PriorityClass a los componentes de la puerta de enlace de red de Anthos. El controlador de Google Distributed Cloud reemplaza estos cambios manuales durante un proceso de 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.

Actualizaciones

1.12, 1.13, 1.14, 1.15.0-1.15.2

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

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

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

Borra el espacio de nombres gke-connect:

kubectl delete ns gke-connect --kubeconfig=ADMIN_KUBECONFIG

Obtén el nombre del clúster de administrador:

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

Borra la membresía de la flota:

gcloud container fleet memberships delete ADMIN_CLUSTER_NAME

y reanuda la actualización del clúster de administrador.

Operación

1.13.0 a 1.13.8, 1.14.0 a 1.14.5, 1.15.0 a 1.15.1

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

Instalación, actualizaciones y revisiones

1.9+, 1.10+, 1.11+, 1.12+

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

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
```
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.
(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 el siguiente comando:
```
gkectl update cluster --kubeconfig=ADMIN_KUBECONFIG --config USER_CLUSTER_CONFIG_FILE
```
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.

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

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.

Actualiza el clúster para agregar grupos de nodos de Windows

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

Instalación, actualizaciones y revisiones

1.13.0 a 1.13.9, 1.14.0 a 1.14.5, 1.15.0 a 1.15.1

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 los 20 segundos que deberían 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 hacer que el reloj del sistema se desincronice con el servidor NTP cuando la desviación del reloj sea mayor que 5 segundos.

Solución alternativa:

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

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

Actualizaciones

1.12.0 a 1.12.6, 1.13.0 a 1.13.6, 1.14.0 a 1.14.2

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

Instalación y seguridad

1.13, 1.14, 1.15 y 1.16

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

Instalación

1.0-1.11, 1.12, 1.13.0-1.13.9, 1.14.0-1.14.5, 1.15.0-1.15.1

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.

Actualizaciones

1.12.0-1.12.4

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

Cuando actualices 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,
      ...
    }

Actualizaciones

1.13.0 a 1.13.9, 1.14.0 a 1.14.5, 1.15.0 a 1.15.1

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:

Cambia la versión de tu clave de firma de KSA a 1, pero conserva los datos de la clave más reciente:

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

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 -

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

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

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
'

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

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
'

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

Operación

1.13.1+, 1.14, 1., 1.16

Los servidores virtuales 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 .

Instalación, actualizaciones y revisiones

1.13.8, 1.14.4

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 extrae las siguientes imágenes de contenedor de docker.io:

docker.io/kindest/kindnetd

docker.io/kindest/local-path-provisioner

docker.io/kindest/local-path-helper

Si no se puede acceder a docker.io desde tu estación de trabajo de administrador, la creación o actualización del clúster de administrador no 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

Operación

1.13.0 a 1.13.7, 1.14.0 a 1.14.4 y 1.15.0

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:

Ejecuta el siguiente comando en cada nodo del plano de control del clúster afectado:

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

Actualizaciones

1.13.0 a 1.13.7, 1.14.0 a 1.14.4 y 1.15.0

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

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

Solución alternativa:

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

Instalación

1.10.3 a 1.10.7, 1.11, 1.12, 1.13.0 a 1.13.1

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.

Para identificar el síntoma, puedes buscar los siguientes mensajes de error en el registro de `gkectl create admin`:

Failed to register admin cluster

También puedes verificar si 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,

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

Actualizaciones

1.10, 1.11, 1.12, 1.13.0-1.13.1

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:

Comprueba si el clúster aparece entre los clústeres registrados. Como paso opcional, accede al clúster después de configurar la autenticación. Si el clúster aún está registrado, puedes omitir las siguientes instrucciones para volver a intentar el registro. Para los clústeres actualizados a la versión 1.12 y 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 actualizados a versiones anteriores, se aplica lo siguiente:

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

Configuración

1.15.0

Mensaje de error falso sobre `vCenter.dataDisk`

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

vCenter.dataDisk must be present in the AdminCluster spec

Solución alternativa:

Puedes ignorar este mensaje de error.

VMware

1.15.0

La creación del grupo de nodos falla debido a reglas de afinidad de VM a 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].

Operación

1.15.0

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

Actualizaciones

1.15.0

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.

Seguridad y configuración

1.15.0-1.15.1

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.

Actualizaciones

1.15.0

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

Durante gkectl upgrade admin, la verificación previa del almacenamiento para la migración 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 registra una 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.

Almacenamiento

1.15 y 1.16

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 los nodos de Windows. Esto hace que el volumen correspondiente sea de solo lectura dentro de un Pod. Es más probable que este problema ocurra cuando un conjunto nuevo de nodos reemplaza a un conjunto anterior (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:

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

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

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

Obtén acceso a PowerShell en el nodo a través de SSH o la interfaz web de vSphere.

Establece las variables de entorno:

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

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

Verifica que el disco sea readonly:

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

El resultado debería ser True.

Establece readonly en false.

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

Borra el Pod para que se reinicie:

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

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

Actualizaciones

1.12, 1.13.0 a 1.13.7, 1.14.0 a 1.14.4

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

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

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

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 \
    )\"}}"

Reinicia vsphere-csi-controller:

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

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.

Actualizaciones

1.10, 1.11, 1.12.0-1.12.6, 1.13.0-1.13.6, 1.14.0-1.14.2

`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 que --cluster-name está vacío. Este comportamiento se debe a un error en la lógica de actualización, en el que el nombre del clúster no se propaga al manifiesto del 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 del plano de control v1, edita el contenedor audit-proxy en el conjunto de réplicas con estado kube-apiserver para agregar --cluster_name=USER_CLUSTER_NAME:

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

Actualizaciones

1.11, 1.12, 1.13.0 a 1.13.5, 1.14.0 a 1.14.1

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 los Pods del plano de control se vuelvan a implementar. El estado del clúster de gkectl list clusters cambia de RUNNING a RECONCILING. Es posible que se agote el tiempo de espera de las solicitudes al clúster de usuario.

Este comportamiento se debe a que la rotación del certificado del plano de control 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+.

Actualizaciones

1.12.7

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.

Actualizaciones

1.12.0 y versiones posteriores, 1.13.0 a 1.13.7, 1.14.0 a 1.14.3

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

Borra el espacio de nombres gke-connect:

kubectl --kubeconfig=KUBECONFIG delete namespace gke-connect

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:

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 -

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

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

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

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

Instalación

1.13 y 1.14

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

Operación

1.0, 1.1, 1.2, 1.3, 1.4, 1.5, 1.6, 1.7, 1.8, 1.9, 1.10, 1.11, 1.12, 1.13 y 1.14

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:

Ve al Explorador de métricas en la consola de Google Cloud :
Ir al Explorador de métricas
Selecciona la pestaña Configuración.
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.

Actualizaciones

1.10, 1.11, 1.12, 1.13 y 1.14

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:

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.

Verifica los registros de GKE Identity Service y kube-apiserver:

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:

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:

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

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

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
```
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.
Reinicia los Pods identificados a partir de los tokens.

Operación

1.8, 1.9 y 1.10

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

Se ven afectados los Pods de mantenimiento de etcd que usan la imagen etcddefrag:gke_master_etcddefrag_20210211.00_p0. 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

Operación

1.9, 1.10, 1.11, 1.12 y 1.13

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

Actualizaciones

1.6+, 1.7+

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.

Redes

1.10, 1.11, 1.12.0-1.12.6, 1.13.0-1.13.6, 1.14.0-1.14.2

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.

Redes

1.14

Se agota 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 entradas nuevas. 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.

Redes

1.13.0-1.13.2

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 todos los taint, incluido el taint 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

Configuración

1.14.0-1.14.2

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, simplemente puedes quitar o comentar la sección privateRegistry en el archivo de configuración del clúster de usuario.
Si deseas usar una credencial de registro privado específica para tu clúster de usuario, puedes especificar temporalmente la sección privateRegistry de esta manera:
```
privateRegistry:
  address: PRIVATE_REGISTRY_ADDRESS
  credentials:
    username: PRIVATE_REGISTRY_USERNAME
    password: PRIVATE_REGISTRY_PASSWORD
  caCertPath: PRIVATE_REGISTRY_CACERT_PATH
```
(NOTE: Esta es solo una solución temporal, y estos campos ya están obsoletos. Considera usar el archivo de credenciales cuando actualices a la versión 1.14.3 o posterior).

Operaciones

1.10+

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 se usan 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

Almacenamiento

1.12 y versiones posteriores, 1.13.3

`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/PVC después de 6 minutos y desconectar los PV/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.

Actualizaciones

1.12+, 1.13+ y 1.14+

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

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

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

Solución alternativa:

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

Operación

1.10+, 1.11+, 1.12+, 1.13+, 1.14+

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

Sistema operativo

1.10+, 1.11+, 1.12+, 1.13+, 1.14+, 1.15+, 1.16+, 1.28+, 1.29+, 1.30+, 1.31+, 1.32+

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 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 una IP diferente a la VM, lo que genera un conflicto de IP (a nivel de Kubernetes, no de vSphere) o un cambio de IP en las VMs, lo que puede dañar los clústeres de varias maneras.

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

La IU de vCenter muestra que ninguna VM usa la misma IP, pero

kubectl get
        nodes -o wide

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

Operación, actualizaciones

1.12.0 a 1.12.5, 1.13.0 a 1.13.5, 1.14.0 a 1.14.1

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'

Si el resultado está vacío, significa que se borró la clave.

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 -

Operación

1.13.0 y versiones posteriores, 1.14.0 y versiones posteriores

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

Para encontrar el pod del escalador automático de clúster, ejecuta los siguientes comandos.

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

Solución alternativa:

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

Instalación

1.12.0 a 1.12.4, 1.13.0 a 1.13.3 y 1.14.0

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.

Actualizaciones

1.14.0-1.14.1

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

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

Operación

1.10, 1.11, 1.12, 1.13, 1.14.0

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

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

  error getting ClusterInformation: connection is unauthorized: Unauthorized

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

Los clústeres de administrador siempre usan Calico, mientras que, para los clústeres de usuario, hay un campo de configuración `enableDataPlaneV2` en user-cluster.yaml. Si ese campo se establece en `false` o no se especifica, significa que estás usando Calico en el clúster de usuario.

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

Solución alternativa:

Este problema se corrigió en la versión 1.14.1 de Google Distributed Cloud. Actualiza a esta versión o a una posterior.

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

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

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

Reemplaza lo siguiente:

ADMIN_CLUSTER_KUBECONFIG: Es la ruta de acceso al archivo kubeconfig del clúster de administrador.
USER_CLUSTER_CONFIG_FILE: Es la ruta de acceso del archivo de configuración del clúster de usuario.

Instalación

1.12.0 a 1.12.4, 1.13.0 a 1.13.3 y 1.14.0

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

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

Solución alternativa:

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

Operación, actualizaciones

1.11.0 - 1.11.1, 1.10.0 - 1.10.4, 1.9.0 - 1.9.6

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

Cuando la función de encriptación de Secrets siempre activa está habilitada junto con la copia de seguridad del clúster, la copia de seguridad del clúster de administrador no incluye las claves de encriptación ni la configuración que requiere la función de encriptación de Secrets siempre activa. Como resultado, reparar el elemento principal del administrador con esta copia de seguridad usando gkectl repair admin-master --restore-from-backup provoca el siguiente error:

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

Solución alternativa:

Usa el objeto binario gkectl de la versión de parche disponible más reciente para la versión secundaria correspondiente para realizar la copia de seguridad del clúster de administrador después de las operaciones críticas del clúster. Por ejemplo, si el clúster ejecuta una versión 1.10.2, usa el objeto binario gkectl 1.10.5 para realizar una copia de seguridad manual del clúster de administrador, como se describe en Crea una copia de seguridad de un clúster de administrador y restablécelo con gkectl.

Operación, actualizaciones

1.10+

La recreación de la VM principal de administrador con un disco de arranque nuevo (p.ej., `gkectl repair admin-master`) fallará si la función de encriptación siempre activa de Secrets está habilitada con el comando "gkectl update".

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

Actualizaciones

1.10

La actualización del primer clúster de usuario de la versión 1.9 a la 1.10 vuelve a crear nodos en otros clústeres de usuario

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

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

Solución alternativa:

Ver los pasos de la solución alternativa

Reduce la réplica de clusterapi-controllers a 0 para todos los clústeres de usuario.

kubectl scale --replicas=0 -n=USER_CLUSTER_NAME deployment/clusterapi-controllers --kubeconfig ADMIN_CLUSTER_KUBECONFIG

Actualiza cada clúster de usuario uno por uno.

Actualizaciones

1.10.0

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

La actualización del clúster de usuario a la versión 1.10.0 podría provocar que Docker se reinicie con frecuencia.

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

Una condición del nodo mostrará si Docker se reinicia con frecuencia. A continuación, se muestra un ejemplo de resultado:

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

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

Solución alternativa:

Usa containerd para el entorno de ejecución del contenedor
Actualiza el clúster a la versión más reciente de 1.10

Actualizaciones

1.11 y 1.12

Los componentes de GMP implementados por el usuario no se conservan después de actualizar a la versión 1.12

Si usas una versión de Google Distributed Cloud anterior a la 1.12 y configuraste manualmente los componentes de Prometheus administrado por Google (GMP) en el espacio de nombres gmp-system de tu clúster, los componentes no se conservarán cuando actualices a la versión 1.12.x.

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

Solución alternativa:

Haz una copia de seguridad de todos los recursos personalizados (CR) de PodMonitoring existentes.
Actualiza todos los clústeres a la versión 1.12 y habilita Managed Service para Prometheus.
Vuelve a implementar los CR de PodMonitoring.

Operación

1.11, 1.12, 1.13.0 - 1.13.1

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

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

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

Solución alternativa:

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

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

donde:

USER_CLUSTER_KUBECONFIG es el archivo kubeconfig del clúster de usuario.

Actualizaciones

1.11.0 a 1.11.4, 1.12.0 a 1.12.3, 1.13.0 a 1.13.1

La eliminación del clúster de usuario se detiene en el vaciado de nodos para la configuración de vSAN

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

El clúster de administrador usa el controlador CSI de vSphere en vSAN desde la versión 1.12.x.
Los complementos de vSphere integrados no crean objetos PVC/PV en el clúster de administrador ni en el de usuario.

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

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

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

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

kubevols es el directorio predeterminado para el controlador integrado de vSphere. Cuando no se crean objetos de PVC/PV, es posible que se produzca un error que haga que el vaciado del nodo se quede atascado en la búsqueda de kubevols, ya que la implementación actual supone que kubevols siempre existe.

Solución alternativa:

Crea el directorio kubevols en el almacén de datos donde se crea el nodo. Esto se define en el campo vCenter.datastore de los archivos user-cluster.yaml o admin-cluster.yaml.

Configuración

1.7, 1.8, 1.9, 1.10, 1.11, 1.12, 1.13 y 1.14

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

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

Los síntomas son los siguientes:

Registros cluster-autoscaler

kubectl logs --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n kube-system \
cluster-autoscaler

ADMIN_CLUSTER_KUBECONFIG

2023-03-26T10:45:44.866600973Z W0326 10:45:44.866463       1 reflector.go:424] k8s.io/client-go/dynamic/dynamicinformer/informer.go:91: failed to list *unstructured.Unstructured: onpremuserclusters.onprem.cluster.gke.io is forbidden: User "..." cannot list resource "onpremuserclusters" in API group "onprem.cluster.gke.io" at the cluster scope
2023-03-26T10:45:44.866646815Z E0326 10:45:44.866494       1 reflector.go:140] k8s.io/client-go/dynamic/dynamicinformer/informer.go:91: Failed to watch *unstructured.Unstructured: failed to list *unstructured.Unstructured: onpremuserclusters.onprem.cluster.gke.io is forbidden: User "..." cannot list resource "onpremuserclusters" in API group "onprem.cluster.gke.io" at the cluster scope

Solución alternativa:

Ver los pasos de la solución alternativa

Verifica si faltan clusterrole y clusterrolebinding en el clúster de administrador

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

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

Aplica los siguientes clusterrole y clusterrolebinding al clúster de administrador si faltan. Agrega los asuntos de la cuenta de servicio a la vinculación de ClusterRole para cada clúster de usuario.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: cluster-autoscaler
rules:
- apiGroups: ["cluster.k8s.io"]
  resources: ["clusters"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["cluster.k8s.io"]
  resources: ["machinesets","machinedeployments", "machinedeployments/scale","machines"]
  verbs: ["get", "list", "watch", "update", "patch"]
- apiGroups: ["onprem.cluster.gke.io"]
  resources: ["onpremuserclusters"]
  verbs: ["get", "list", "watch"]
- apiGroups:
  - coordination.k8s.io
  resources:
  - leases
  resourceNames: ["cluster-autoscaler"]
  verbs:
  - get
  - list
  - watch
  - create
  - update
  - patch
- apiGroups:
  - ""
  resources:
  - nodes
  verbs: ["get", "list", "watch", "update", "patch"]
- apiGroups:
  - ""
  resources:
  - pods
  verbs: ["get", "list", "watch"]
- apiGroups:
  - ""
  resources:
  - pods/eviction
  verbs: ["create"]
# read-only access to cluster state
- apiGroups: [""]
  resources: ["services", "replicationcontrollers", "persistentvolumes", "persistentvolumeclaims"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["apps"]
  resources: ["daemonsets", "replicasets"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["apps"]
  resources: ["statefulsets"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["batch"]
  resources: ["jobs"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["policy"]
  resources: ["poddisruptionbudgets"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["storage.k8s.io"]
  resources: ["storageclasses", "csinodes"]
  verbs: ["get", "list", "watch"]
# misc access
- apiGroups: [""]
  resources: ["events"]
  verbs: ["create", "update", "patch"]
- apiGroups: [""]
  resources: ["configmaps"]
  verbs: ["create"]
- apiGroups: [""]
  resources: ["configmaps"]
  resourceNames: ["cluster-autoscaler-status"]
  verbs: ["get", "update", "patch", "delete"]

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  labels:
    k8s-app: cluster-autoscaler
  name: cluster-autoscaler
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-autoscaler
subjects:
  - kind: ServiceAccount
  name: cluster-autoscaler
  namespace:  NAMESPACE_OF_USER_CLUSTER_1 
  - kind: ServiceAccount
  name: cluster-autoscaler
  namespace:  NAMESPACE_OF_USER_CLUSTER_2 
  ...

Configuración

1.7, 1.8, 1.9, 1.10, 1.11, 1.12 y 1.13

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

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

Los síntomas son los siguientes:

Registros cluster-health-controller

kubectl logs --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n kube-system \
cluster-health-controller

ADMIN_CLUSTER_KUBECONFIG

error retrieving resource lock default/onprem-cluster-health-leader-election: configmaps "onprem-cluster-health-leader-election" is forbidden: User "system:serviceaccount:kube-system:cluster-health-controller" cannot get resource "configmaps" in API group "" in the namespace "default": RBAC: clusterrole.rbac.authorization.k8s.io "cluster-health-controller-role" not found

Registros vsphere-metrics-exporter

kubectl logs --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n kube-system \
vsphere-metrics-exporter

ADMIN_CLUSTER_KUBECONFIG

vsphere-metrics-exporter/cmd/vsphere-metrics-exporter/main.go:68: Failed to watch *v1alpha1.Cluster: failed to list *v1alpha1.Cluster: clusters.cluster.k8s.io is forbidden: User "system:serviceaccount:kube-system:vsphere-metrics-exporter" cannot list resource "clusters" in API group "cluster.k8s.io" in the namespace "default"

Solución alternativa:

Ver los pasos de la solución alternativa

Aplica el siguiente YAML al clúster de administrador

Para vsphere-metrics-exporter

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: vsphere-metrics-exporter
rules:
  - apiGroups:
      - cluster.k8s.io
    resources:
      - clusters
    verbs: [get, list, watch]
  - apiGroups:
      - ""
    resources:
      - nodes
    verbs: [get, list, watch]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  labels:
    k8s-app: vsphere-metrics-exporter
  name: vsphere-metrics-exporter
  namespace: kube-system
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: vsphere-metrics-exporter
subjects:
  - kind: ServiceAccount
    name: vsphere-metrics-exporter
    namespace: kube-system

Para cluster-health-controller

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: cluster-health-controller-role
rules:
- apiGroups:
  - "*"
  resources:
  - "*"
  verbs:
  - "*"

Configuración

1.12.1 a 1.12.3, 1.13.0 a 1.13.2

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

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

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

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

Solución alternativa:

Opción 1: Ejecuta gkectl prepare para subir las imágenes de SO faltantes.

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

Actualizaciones

1.11, 1.12 y 1.13

`gkectl update admin/cluster` no puede actualizar los grupos antiafinidad

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

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

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

Solución alternativa:

Ver los pasos de la solución alternativa

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

Para la actualización del clúster de administrador, se deben volver a crear los nodos principales de usuario y los nodos de complementos de administrador

Para la actualización del clúster de usuario, se deben volver a crear los nodos trabajadores del usuario

Cómo volver a crear nodos trabajadores del usuario

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

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

kubectl delete machines MACHINE_NAME --kubeconfig USER_KUBECONFIG

Cómo volver a crear nodos principales del usuario

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

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

kubectl delete machines MACHINE_NAME --kubeconfig ADMIN_KUBECONFIG

Cómo volver a crear nodos de complemento de administrador

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

kubectl delete machines MACHINE_NAME --kubeconfig ADMIN_KUBECONFIG

Instalación, actualizaciones y revisiones

1.13.0 a 1.13.8, 1.14.0 a 1.14.4 y 1.15.0

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

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

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

kubectl get csr -A -o wide

Revisa los siguientes registros en busca de mensajes de error:

Visualiza los registros en el clúster de administrador para el contenedor clusterapi-controller-manager en el Pod clusterapi-controllers:

kubectl logs clusterapi-controllers-POD_NAME \
    -c clusterapi-controller-manager -n kube-system \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG

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

Si especificas un nombre de dominio en el campo de nombre de host de un archivo de bloqueo de IP, se ignorarán los caracteres que sigan al primer punto. Por ejemplo, si especificas el nombre de host como bob-vm-1.bank.plc, el nombre de host de la VM y el nombre del nodo se establecerán en bob-vm-1.

Cuando se habilita la verificación del ID del nodo, el aprobador de la CSR compara el nombre del nodo con el nombre de host en la especificación de la máquina y no puede conciliar el nombre. El aprobador rechaza la CSR y el nodo no puede iniciar el proceso de arranque.

Solución alternativa:

Clúster de usuario

Para inhabilitar la verificación del ID del nodo, completa los siguientes pasos:

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

Clúster de administrador

Abre el recurso personalizado OnPremAdminCluster para editarlo:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    edit onpremadmincluster -n kube-system

Agrega la siguiente anotación al recurso personalizado:

features.onprem.cluster.gke.io/disable-node-id-verification: enabled

Edita el manifiesto kube-controller-manager en el plano de control del clúster de administrador:
1. Establece una conexión SSH al nodo del plano de control del clúster de administrador.
2. Abre el manifiesto de kube-controller-manager para editarlo:
```
sudo vi /etc/kubernetes/manifests/kube-controller-manager.yaml
```
3. Busca la lista de controllers:
```
--controllers=*,bootstrapsigner,tokencleaner,-csrapproving,-csrsigning
```
4. Actualiza esta sección como se muestra a continuación:
```
--controllers=*,bootstrapsigner,tokencleaner
```

Abre el controlador de la API de clúster de Deployment para editarlo:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    edit deployment clusterapi-controllers -n kube-system

Cambia los valores de node-id-verification-enabled y node-id-verification-csr-signing-enabled a false:
```
--node-id-verification-enabled=false
--node-id-verification-csr-signing-enabled=false
```

Instalación, actualizaciones y revisiones

1.11.0-1.11.4

Falla en el inicio de la máquina del plano de control del administrador debido al paquete de certificados del registro privado

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

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

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

Invalid value 'XXXX' specified for property startup-data

A continuación, se muestra un ejemplo de la ruta de acceso del archivo de registro del controlador de la API de clúster:

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

Networking

1.10, 1.11.0-1.11.3, 1.12.0-1.12.2, 1.13.0

`NetworkGatewayNodes` marked unhealthy from concurrent status update conflict

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

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

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

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

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

La contención en el objeto networkgatewaygroup provoca que algunas actualizaciones de estado fallen debido a una falla en el control de reintentos. Si fallan demasiadas actualizaciones de estado, ang-controller-manager considera que el nodo superó su límite de tiempo de latido y lo marca como NotHealthy.

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

Solución alternativa:

Actualiza a una versión corregida cuando esté disponible.

Actualizaciones

1.12.0-1.12.2, 1.13.0

Una condición de carrera bloquea la eliminación del objeto de la máquina durante una actualización

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

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

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

En los registros del Pod clusterapi-controller, los errores son similares a los que se muestran a continuación:

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

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

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

Solución alternativa:

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

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

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

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

El controlador de MachineSet filtrará las máquinas que tengan la anotación de reparación automática y la marca de tiempo de eliminación distintas de cero, y no seguirá emitiendo llamadas de eliminación en esas máquinas, lo que puede ayudar a evitar la condición de carrera.

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

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

Si tienes este problema y la actualización no se completa después de un tiempo, comunícate con nuestro equipo de asistencia al cliente para obtener soluciones.

Instalación, actualizaciones y revisiones

1.10.2, 1.11, 1.12 y 1.13

`gkectl` prepare imagen de SO validation preflight failure

El comando gkectl prepare falló con el siguiente mensaje:

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

Las verificaciones previas de gkectl prepare incluyeron una validación incorrecta.

Solución alternativa:

Ejecuta el mismo comando con una marca adicional --skip-validation-os-images.

Instalación

1.7, 1.8, 1.9, 1.10, 1.11, 1.12 y 1.13

La URL de vCenter con el prefijo `https://` o `http://` puede provocar una falla en el inicio del clúster

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

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

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

Solución alternativa:

Quita el prefijo https:// o http:// del campo vCenter.Address en el archivo YAML de configuración del clúster de administrador o del clúster de usuario.

Instalación, actualizaciones y revisiones

1.10, 1.11, 1.12 y 1.13

`gkectl prepare` pánico en `util.CheckFileExists`

gkectl prepare puede generar una excepción con el siguiente registro de seguimiento:

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

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

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

Solución alternativa:

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

sudo mkdir -p /etc/docker/certs.d/PRIVATE_REGISTRY_ADDRESS
sudo chmod 0755 /etc/docker/certs.d/PRIVATE_REGISTRY_ADDRESS

Actualizaciones

1.10, 1.11, 1.12 y 1.13

`gkectl repair admin-master` y la actualización de administrador reanudable no funcionan juntos

Después de un intento fallido de actualización del clúster de administrador, no ejecutes gkectl repair admin-master. Si lo haces, es posible que los intentos posteriores de actualización del administrador fallen con problemas como la falla de encendido del administrador principal o la inaccesibilidad de la VM.

Solución alternativa:

Si ya te encontraste con esta situación de falla, comunícate con el equipo de asistencia.

Actualizaciones

1.10 y 1.11

La reanudación de la actualización del clúster de administrador puede provocar la falta de la plantilla de VM del plano de control del administrador

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

Solución alternativa:

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

Sistema operativo

1.12 y 1.13

cgroup v2 podría afectar las cargas de trabajo

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

Solución alternativa:

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

Identidad

1.10, 1.11, 1.12 y 1.13

Recurso personalizado de ClientConfig

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

Solución alternativa:

Te recomendamos crear una copia de seguridad del recurso ClientConfig después de cada cambio manual.

Instalación

1.10, 1.11, 1.12 y 1.13

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

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

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

Solución alternativa:

Vuelve a ejecutar gkectl check-config.

Instalación

1.12

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

Es posible que veas un error de instalación debido a cert-manager-cainjector en bloqueo, cuando apiserver/etcd es lento:

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

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

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

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

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

Solución alternativa:

Ver los pasos de la solución alternativa

Ejecuta los siguientes comandos para mitigar el problema.

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

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

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

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

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

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

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

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

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

Los cambios se revierten después de cada actualización. Realiza los mismos pasos una vez más para mitigar el problema hasta que se solucione en una versión futura.

VMware

1.10, 1.11, 1.12 y 1.13

Reinicia o actualiza vCenter para versiones anteriores a 7.0U2

Si vCenter, en versiones anteriores a 7.0U2, se reinicia después de una actualización o de otra manera, el nombre de red en la información de VM de vCenter es incorrecto y hace que la máquina esté en un estado Unavailable. Finalmente, esto hace que los nodos se reparen automáticamente para crear otros nuevos.

Error relacionado de govmomi.

Solución alternativa:

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

El problema se solucionó en las versiones 7.0U2 y posteriores de vCenter.
En versiones anteriores, haz clic con el botón derecho en el host y, luego, selecciona Connection > Disconnect. A continuación, vuelve a conectarte, lo que fuerza una actualización del grupo de puertos de la VM.

Sistema operativo

1.10, 1.11, 1.12 y 1.13

Conexión SSH cerrada por host remoto

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

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

ClientAliveInterval 300
ClientAliveCountMax 0

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

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

Solución alternativa:

Para hacerlo, tienes las alternativas siguientes:

Usa nohup para evitar que el comando se finalice cuando te desconectes de SSH.

nohup gkectl upgrade admin --config admin-cluster.yaml \
    --kubeconfig kubeconfig

Actualiza sshd_config para usar un valor ClientAliveCountMax distinto de cero. La regla de CIS recomienda usar un valor inferior a 3:
```
sudo sed -i 's/ClientAliveCountMax 0/ClientAliveCountMax 1/g' \
    /etc/ssh/sshd_config
sudo systemctl restart sshd
```

Asegúrate de volver a conectar tu sesión SSH.

Instalación

1.10, 1.11, 1.12 y 1.13

Instalación de `cert-manager` en conflicto

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

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

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

Solución alternativa:

<pEvita conflictos durante la actualización

Desinstala tu versión de cert-manager. Si definiste tus propios recursos, es posible que desees crear una copia de seguridad de ellos.

Realiza la actualización.

Sigue las instrucciones que se indican a continuación para restablecer tu propio cert-manager.

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

Escala el Deployment monitoring-operator a 0:
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \ -n USER_CLUSTER_NAME \ scale deployment monitoring-operator --replicas=0

Escala las implementaciones de cert-manager administradas por monitoring-operator a 0:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \ -n cert-manager scale deployment cert-manager --replicas=0 kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \ -n cert-manager scale deployment cert-manager-cainjector\ --replicas=0 kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \ -n cert-manager scale deployment cert-manager-webhook --replicas=0

Vuelve a instalar tu versión de cert-manager. Restablece tus recursos personalizados si los tienes.

Puedes omitir este paso si usas la instalación predeterminada ascendente de cert-manager o si tienes la certeza de que cert-manager está instalado en el espacio de nombres cert-manager. De lo contrario, copia el certificado metrics-ca cert-manager.io/v1 y los recursos de la entidad emisora de metrics-pki.cluster.local de cert-manager al espacio de nombres del recurso del clúster de tu cert-manager instalado.
relevant_fields=' { apiVersion: .apiVersion, kind: .kind, metadata: { name: .metadata.name, namespace: "YOUR_INSTALLED_CERT_MANAGER_NAMESPACE" }, spec: .spec } ' f1=$(mktemp) f2=$(mktemp) kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \ get issuer -n cert-manager metrics-pki.cluster.local -o json \ | jq "${relevant_fields}" > $f1 kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \ get certificate -n cert-manager metrics-ca -o json \ | jq "${relevant_fields}" > $f2 kubectl apply --kubeconfig USER_CLUSTER_KUBECONFIG -f $f1 kubectl apply --kubeconfig USER_CLUSTER_KUBECONFIG -f $f2

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

En general, no deberías reinstalar cert-manager en los clústeres de administrador, ya que estos solo ejecutan cargas de trabajo del plano de control de Google Distributed Cloud. En los casos excepcionales en los que también necesites instalar tu propio cert-manager en clústeres de administrador, sigue las instrucciones que se indican a continuación para evitar conflictos. Ten en cuenta que, si eres cliente de Apigee y solo necesitas cert-manager para Apigee, no es necesario que ejecutes los comandos del clúster de administrador.

Escala la implementación de monitoring-operator a 0.
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \ -n kube-system scale deployment monitoring-operator --replicas=0

Escala las implementaciones de cert-manager administradas por monitoring-operator a 0.
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \ -n cert-manager scale deployment cert-manager \ --replicas=0 kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \ -n cert-manager scale deployment cert-manager-cainjector \ --replicas=0 kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \ -n cert-manager scale deployment cert-manager-webhook \ --replicas=0

Vuelve a instalar tu versión de cert-manager. Restablece tus recursos personalizados si los tienes.

Puedes omitir este paso si usas la instalación predeterminada ascendente de cert-manager o si tienes la certeza de que cert-manager está instalado en el espacio de nombres cert-manager. De lo contrario, copia el certificado metrics-ca cert-manager.io/v1 y los recursos de la entidad emisora de metrics-pki.cluster.local de cert-manager al espacio de nombres del recurso del clúster de tu cert-manager instalado.
relevant_fields=' { apiVersion: .apiVersion, kind: .kind, metadata: { name: .metadata.name, namespace: "YOUR_INSTALLED_CERT_MANAGER_NAMESPACE" }, spec: .spec } ' f3=$(mktemp) f4=$(mktemp) kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \n get issuer -n cert-manager metrics-pki.cluster.local -o json \ | jq "${relevant_fields}" > $f3 kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \ get certificate -n cert-manager metrics-ca -o json \ | jq "${relevant_fields}" > $f4 kubectl apply --kubeconfig ADMIN_CLUSTER_KUBECONFIG -f $f3 kubectl apply --kubeconfig ADMIN_CLUSTER_KUBECONFIG -f $f4

</p

Sistema operativo

1.10, 1.11, 1.12 y 1.13

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

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

Sin embargo, las versiones especiales no son conocidas para la Herramienta de seguimiento de CVE de Ubuntu, que se usa como feed de vulnerabilidad en varias herramientas de análisis de CVE. Por lo tanto, verás falsos positivos en los resultados del análisis de vulnerabilidades de Docker, containerd y runc.

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

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

Solución alternativa:

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

Actualizaciones

1.10, 1.11, 1.12 y 1.13

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

Si actualizas clústeres sin alta disponibilidad de la versión 1.9 a la 1.10, es posible que notes que kubectl exec, kubectl log y webhook en los clústeres de usuario no están disponibles por un período breve. Este tiempo de inactividad puede durar hasta un minuto. Esto sucede porque kube-apiserver maneja la solicitud entrante (kubectl exec, kubectl log y webhook) para el clúster de usuario. El usuario kube-apiserver es un Statefulset. En un clúster sin alta disponibilidad, solo hay una réplica para el Statefulset. Por lo tanto, durante la actualización, existe la posibilidad de que el kube-apiserver antiguo no esté disponible mientras el nuevo kube-apiserver aún no está listo.

Solución alternativa:

Este tiempo de inactividad solo ocurre durante el proceso de actualización. Si deseas tener un tiempo de inactividad más breve durante la actualización, te recomendamos cambiar a clústeres de HA.

Instalación, actualizaciones y revisiones

1.10, 1.11, 1.12 y 1.13

La verificación de preparación de la conectividad falló en el diagnóstico de clústeres de HA después de la creación o actualización del clúster

Si creas o actualizas un clúster de HA y notas que la verificación de preparación de la conectividad falló en el diagnóstico de clústeres, en la mayoría de los casos no afectará la funcionalidad de Google Distributed Cloud (kubectl exec, kubectl log y webhook). Esto sucede porque, a veces, una o dos de las réplicas de conectividad pueden no estar listas durante un período debido a herramientas de redes inestables o a otros problemas.

Solución alternativa:

La conectividad se recuperará sola. Espera entre 30 minutos y 1 hora, y vuelve a ejecutar el diagnóstico del clúster.

Sistema operativo

1.7, 1.8, 1.9, 1.10 y 1.11

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

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

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

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

Solución alternativa:

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

sudo chmod -x /etc/cron.daily/aide

Redes

1.10, 1.11, 1.12 y 1.13

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

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

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

Solución alternativa:

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

Si tus clústeres usan un balanceador de cargas manual, sigue estas instrucciones para configurar tu balanceador de cargas a fin de restablecer las conexiones de clientes cuando detecte una falla del nodo de backend. Sin esta configuración, los clientes del servidor de la API de Kubernetes podrían dejar de responder durante varios minutos cuando falla una instancia del servidor.

Registro y supervisión

1.10, 1.11, 1.12, 1.13, 1.14 y 1.15

Facturación inesperada de supervisión

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

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

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

Solución alternativa

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

Para dejar de usar la marca enableStackdriverForApplications, abre el objeto "stackdriver" para editarlo:

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

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

Si no puedes dejar de usar la recopilación de métricas basada en anotaciones, sigue estos pasos:

Busca los Pods y los Services de origen que tienen las métricas facturadas no deseadas.

kubectl --kubeconfig KUBECONFIG \
  get pods -A -o yaml | grep 'prometheus.io/scrape: "true"'
kubectl --kubeconfig KUBECONFIG get \
  services -A -o yaml | grep 'prometheus.io/scrape: "true"'

Quita la anotación prometheus.io/scrap=true del Pod o Service. Si Cloud Service Mesh agrega la anotación, considera configurar Cloud Service Mesh sin la opción de Prometheus o desactivar la función de combinación de métricas de Istio.

Instalación

1.11, 1.12 y 1.13

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

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

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

Solución alternativa:

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

Para obtener más información sobre la creación de roles, consulta privilegios de la cuenta de usuario de vCenter.

Registro y supervisión

1.9.0 a 1.9.4 y 1.10.0 a 1.10.1

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

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

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

Solución alternativa:

Ver los pasos de la solución alternativa

Actualiza a la versión 1.10.2/1.9.5 o a una posterior.

Para mitigar este problema en una versión anterior, haz lo siguiente:

Reduce la escala vertical de `stackdriver-operator`:
```
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    --namespace kube-system \
    scale deployment stackdriver-operator --replicas=0
```
Reemplaza USER_CLUSTER_KUBECONFIG por la ruta de acceso al archivo kubeconfig del clúster de usuario.

Abre el ConfigMap gke-metrics-agent-conf para editar:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    --namespace kube-system \
    edit configmap gke-metrics-agent-conf

Aumenta el intervalo del sondeo de 0.1 segundos a 13 segundos:

  processors:
    disk_buffer/metrics:
      backend_endpoint: https://monitoring.googleapis.com:443
      buffer_dir: /metrics-data/nsq-metrics-metrics
      probe_interval: 13s
      retention_size_mib: 6144
  disk_buffer/self:
      backend_endpoint: https://monitoring.googleapis.com:443
      buffer_dir: /metrics-data/nsq-metrics-self
      probe_interval: 13s
      retention_size_mib: 200
    disk_buffer/uptime:
      backend_endpoint: https://monitoring.googleapis.com:443
      buffer_dir: /metrics-data/nsq-metrics-uptime
      probe_interval: 13s
      retention_size_mib: 200

Cierra la sesión de edición.

Cambia la versión de DaemonSet de gke-metrics-agent a 1.1.0-anthos.8:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG  \
  --namespace kube-system  set image daemonset/gke-metrics-agent \
  gke-metrics-agent=gcr.io/gke-on-prem-release/gke-metrics-agent:1.1.0-anthos.8

Registro y supervisión

1.10 y 1.11

`gke-metrics-agent` tiene errores frecuentes de CrashLoopBackOff

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

Solución alternativa:

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

Para evitar que los cambios se reviertan, reduce verticalmente la escala de stackdriver-operator:
```
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    --namespace kube-system scale deploy stackdriver-operator \
    --replicas=0
```
Reemplaza USER_CLUSTER_KUBECONFIG por la ruta de acceso al archivo kubeconfig del clúster de usuario.

Abre el ConfigMap gke-metrics-agent-conf para editar:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    --namespace kube-system edit configmap gke-metrics-agent-conf

En services.pipelines, comenta toda la sección metrics/app-metrics:

services:
  pipelines:
    #metrics/app-metrics:
    #  exporters:
    #  - googlecloud/app-metrics
    #  processors:
    #  - resource
    #  - metric_to_resource
    #  - infer_resource
    #  - disk_buffer/app-metrics
    #  receivers:
    #  - prometheus/app-metrics
    metrics/metrics:
      exporters:
      - googlecloud/metrics
      processors:
      - resource
      - metric_to_resource
      - infer_resource
      - disk_buffer/metrics
      receivers:
      - prometheus/metrics

Cierra la sesión de edición.

Reinicia el DaemonSet gke-metrics-agent:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    --namespace kube-system rollout restart daemonset gke-metrics-agent

Registro y supervisión

1.11, 1.12 y 1.13

Reemplaza métricas obsoletas en el panel

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

gcloud monitoring dashboards list > all-dashboard.json

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

Las siguientes métricas obsoletas se deben migrar a sus reemplazos.

Obsoleto	Reemplazo
`kube_daemonset_updated_number_scheduled`	`kube_daemonset_status_updated_number_scheduled`
`kube_node_status_allocatable_cpu_cores` `kube_node_status_allocatable_memory_bytes` `kube_node_status_allocatable_pods`	`kube_node_status_allocatable`
`kube_node_status_capacity_cpu_cores` `kube_node_status_capacity_memory_bytes` `kube_node_status_capacity_pods`	`kube_node_status_capacity`
`kube_hpa_status_current_replicas`	`kube_horizontalpodautoscaler_status_current_replicas`

Solución alternativa:

Para reemplazar las métricas obsoletas

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

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

Registro y supervisión

1.10, 1.11, 1.12 y 1.13

Datos de métricas desconocidos en Cloud Monitoring

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

Unknown metric: kubernetes.io/anthos/go_gc_duration_seconds_summary_percentile

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

apiserver_admission_step_admission_duration_seconds_summary
go_gc_duration_seconds
scheduler_scheduling_duration_seconds
gkeconnect_http_request_duration_seconds_summary
alertmanager_nflog_snapshot_duration_seconds_summary

Si bien estas métricas de tipo de resumen están en la lista de métricas, no son compatibles con gke-metrics-agent en este momento.

Registro y supervisión

1.10, 1.11, 1.12 y 1.13

Faltan métricas en algunos nodos

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

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

Solución alternativa:

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

Abre tu recurso stackdriver para editarlo:

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

Para aumentar la solicitud de CPU de gke-metrics-agent de 10m a 50m y el límite de CPU de 100m a 200m, agrega la siguiente sección resourceAttrOverride al manifiesto stackdriver :

spec:
  resourceAttrOverride:
    gke-metrics-agent/gke-metrics-agent:
      limits:
        cpu: 100m
        memory: 4608Mi
      requests:
        cpu: 10m
        memory: 200Mi

El recurso editado debe ser similar al siguiente:

spec:
  anthosDistribution: on-prem
  clusterLocation: us-west1-a
  clusterName: my-cluster
  enableStackdriverForApplications: true
  gcpServiceAccountSecretName: ...
  optimizedMetrics: true
  portable: true
  projectID: my-project-191923
  proxyConfigSecretName: ...
  resourceAttrOverride:
    gke-metrics-agent/gke-metrics-agent:
      limits:
        cpu: 200m
        memory: 4608Mi
      requests:
        cpu: 50m
        memory: 200Mi

Guarda los cambios y cierra el editor de texto.

Para verificar que los cambios se aplicaron, ejecuta el siguiente comando:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    --namespace kube-system get daemonset gke-metrics-agent -o yaml \
    | grep "cpu: 50m"

El comando encuentra cpu: 50m si tus ediciones se aplicaron.

Registro y supervisión

1.11.0-1.11.2, 1.12.0

Faltan métricas del programador y del administrador de controladores en el clúster de administrador

Si tu clúster de administrador se ve afectado por este problema, faltarán las métricas del programador y del administrador de controladores. Por ejemplo, estas dos métricas no están disponibles

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

Solución alternativa:

Actualiza a la versión 1.11.3 o posterior, la 1.12.1 o posterior, o la 1.13 o posterior.

1.11.0-1.11.2, 1.12.0

Faltan métricas del programador y del administrador de controladores en el clúster de usuario

Si tu clúster de usuario se ve afectado por este problema, faltarán las métricas del programador y del administrador de controladores. Por ejemplo, faltan estas dos métricas:

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

Solución alternativa:

Este problema se solucionó en la versión 1.13.0 y posteriores de Google Distributed Cloud. Actualiza el clúster a una versión con la corrección.

Instalación, actualizaciones y revisiones

1.10, 1.11, 1.12 y 1.13

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

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

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

Aún podrás usar este clúster de administrador, pero recibirás el siguiente error si luego intentas actualizarlo a la versión 1.10.y.

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

Solución alternativa:

Ver los pasos de la solución alternativa

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

Ejecuta gkectl update admin para registrar el clúster de administrador con la clave de cuenta de servicio correcta.

Crea una cuenta de servicio dedicada para aplicar parches al recurso personalizado OnPremAdminCluster.

export KUBECONFIG=ADMIN_CLUSTER_KUBECONFIG

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

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

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

kubectl apply -f - <<EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  creationTimestamp: null
  name: modify-admin-rolebinding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: modify-admin-role
subjects:
- kind: ServiceAccount
  name: modify-admin
  namespace: kube-system
EOF

Reemplaza ADMIN_CLUSTER_KUBECONFIG por la ruta de acceso del archivo kubeconfig del clúster de administrador.

Ejecuta estos comandos para actualizar el recurso personalizado OnPremAdminCluster.

export KUBECONFIG=ADMIN_CLUSTER_KUBECONFIG

SERVICE_ACCOUNT=modify-admin

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

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

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

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

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

# Create the Status field and set the gkeOnPremVersion in OnPremAdminCluster CR
curl -H "Accept: application/json" \
    --header "Authorization: Bearer $TOKEN" -XPATCH \
    -H "Content-Type: application/merge-patch+json" \
    --cacert /tmp/ca.crt \
    --data '{"status": {"gkeOnPremVersion": "'$GKE_ON_PREM_VERSION'"}}' \
    $APISERVER/apis/onprem.cluster.gke.io/v1alpha1/namespaces/kube-system/onpremadminclusters/$ADMIN_CLUSTER_NAME/status

Intenta actualizar el clúster de administrador de nuevo con la marca --disable-upgrade-from-checkpoint.
```
gkectl upgrade admin --config ADMIN_CLUSTER_CONFIG \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --disable-upgrade-from-checkpoint
```
Reemplaza ADMIN_CLUSTER_CONFIG por la ruta de acceso del archivo de configuración del clúster de administrador.

Identidad

1.10, 1.11, 1.12 y 1.13

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

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

Solución alternativa:

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

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

Redes

1.10, 1.11, 1.12 y 1.13

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

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

Solución alternativa:

Una posible solución es inhabilitar el aprendizaje de IP agregando la dirección IP de Seesaw como una IP virtual de L4-L7 en el controlador de infraestructura de política de aplicación (APIC) de Cisco.

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

VMware

1.10, 1.11, 1.12 y 1.13

Problemas con vSphere 7.0 Update 3

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

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

Solución alternativa:

Desde entonces, VMWare quitó estos lanzamientos. Debes actualizar los ESXi y vCenter a una versión más reciente.

Sistema operativo

1.10, 1.11, 1.12 y 1.13

No se pudo activar el volumen emptyDir como `exec` en el Pod en ejecución en nodos de COS

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

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

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

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

Solución alternativa:

Ver los pasos de la solución alternativa

Aplica un recurso de DaemonSet, por ejemplo:

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

Actualizaciones

1.10, 1.11, 1.12 y 1.13

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

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

Solución alternativa:

Quita las anotaciones cluster.x-k8s.io/cluster-api-autoscaler-node-group-max-size y cluster.x-k8s.io/cluster-api-autoscaler-node-group-min-size de la implementación de la máquina del grupo de nodos correspondiente.

Registro y supervisión

1.11, 1.12 y 1.13

Los paneles de supervisión de Windows muestran datos de clústeres de Linux

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

Registro y supervisión

1.10, 1.11 y 1.12

`stackdriver-log-forwarder` en CrashLoopBackOff constante

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

Solución alternativa:

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

Para evitar el comportamiento inesperado, reduce verticalmente la escala de stackdriver-log-forwarder:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    -n kube-system patch daemonset stackdriver-log-forwarder -p '{"spec": {"template": {"spec": {"nodeSelector": {"non-existing": "true"}}}}}'

Reemplaza USER_CLUSTER_KUBECONFIG por la ruta de acceso al archivo kubeconfig del clúster de usuario.

Implementa el DaemonSet de limpieza para limpiar los fragmentos rotos:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    -n kube-system -f - << EOF
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluent-bit-cleanup
  namespace: kube-system
spec:
  selector:
    matchLabels:
      app: fluent-bit-cleanup
  template:
    metadata:
      labels:
        app: fluent-bit-cleanup
    spec:
      containers:
      - name: fluent-bit-cleanup
        image: debian:10-slim
        command: ["bash", "-c"]
        args:
        - |
          rm -rf /var/log/fluent-bit-buffers/
          echo "Fluent Bit local buffer is cleaned up."
          sleep 3600
        volumeMounts:
        - name: varlog
          mountPath: /var/log
        securityContext:
          privileged: true
      tolerations:
      - key: "CriticalAddonsOnly"
        operator: "Exists"
      - key: node-role.kubernetes.io/master
        effect: NoSchedule
      - key: node-role.gke.io/observability
        effect: NoSchedule
      volumes:
      - name: varlog
        hostPath:
          path: /var/log
EOF

Para asegurarte de que el DaemonSet de limpieza haya limpiado todos los fragmentos, puedes ejecutar los siguientes comandos. El resultado de los dos comandos debe ser igual al número de nodo en el clúster:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
  logs -n kube-system -l app=fluent-bit-cleanup | grep "cleaned up" | wc -l

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
  -n kube-system get pods -l app=fluent-bit-cleanup --no-headers | wc -l

Borra el DaemonSet de limpieza:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
  -n kube-system delete ds fluent-bit-cleanup

Reanudar stackdriver-log-forwarder:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
  -n kube-system patch daemonset stackdriver-log-forwarder --type json -p='[{"op": "remove", "path": "/spec/template/spec/nodeSelector/non-existing"}]'

Registro y supervisión

1.10, 1.11, 1.12, 1.13, 1.14, 1.15 y 1.16

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

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

2023-06-02T10:53:40.444017427Z [2023/06/02 10:53:40] [error] [input chunk] chunk 1-1685703077.747168499.flb would exceed total limit size in plugin stackdriver.0
2023-06-02T10:53:40.444028047Z [2023/06/02 10:53:40] [error] [input chunk] no available chunk

Es probable que la tasa de entrada de registros supere el límite del agente de Logging, lo que provoca que stackdriver-log-forwarder no envíe registros. Este problema ocurre en todas las versiones de Google Distributed Cloud.

Solución alternativa:

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

Abre tu recurso stackdriver para editarlo:

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

Para aumentar la solicitud de CPU para stackdriver-log-forwarder , agrega la siguiente sección resourceAttrOverride al manifiesto stackdriver :

spec:
  resourceAttrOverride:
    stackdriver-log-forwarder/stackdriver-log-forwarder:
      limits:
        cpu: 1200m
        memory: 600Mi
      requests:
        cpu: 600m
        memory: 600Mi

El recurso editado debe ser similar al siguiente:

spec:
  anthosDistribution: on-prem
  clusterLocation: us-west1-a
  clusterName: my-cluster
  enableStackdriverForApplications: true
  gcpServiceAccountSecretName: ...
  optimizedMetrics: true
  portable: true
  projectID: my-project-191923
  proxyConfigSecretName: ...
  resourceAttrOverride:
    stackdriver-log-forwarder/stackdriver-log-forwarder:
      limits:
        cpu: 1200m
        memory: 600Mi
      requests:
        cpu: 600m
        memory: 600Mi

Guarda los cambios y cierra el editor de texto.

Para verificar que los cambios se aplicaron, ejecuta el siguiente comando:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    --namespace kube-system get daemonset stackdriver-log-forwarder -o yaml \
    | grep "cpu: 1200m"

El comando encuentra cpu: 1200m si tus ediciones se aplicaron.

Seguridad

1.13

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

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

Este problema solo afecta al certificado del servidor de kubelet y no afectará la programación de Pods.

Actualizaciones

1.12

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

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

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

El clúster de administrador no se actualizó por completo y la versión de estado sigue siendo 1.10. La actualización del clúster de usuario a la versión 1.12 no se bloqueará por ninguna verificación previa y fallará con un problema de sesgo de versión.

Solución alternativa:

Completa la actualización del clúster de administrador a la versión 1.11 primero y, luego, actualiza el clúster de usuario a la versión 1.12.

Almacenamiento

1.10.0 a 1.10.5, 1.11.0 a 1.11.2 y 1.12.0

Datastore informa incorrectamente que no hay suficiente espacio libre

El comando gkectl diagnose cluster falló con el siguiente mensaje:

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

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

Solución alternativa:

Puedes ignorar el mensaje de error o omitir la validación con --skip-validation-infra.

Operación, redes

1.11, 1.12.0-1.12.1

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

El proceso de eliminación del clúster de usuarios puede quedar atascado por algún motivo, lo que provoca la invalidación del ConfigMap de MatalLB. No será posible agregar un clúster de usuario nuevo en este estado.

Solución alternativa:

Puedes forzar la eliminación de tu clúster de usuario.

Instalación, sistema operativo

1.10, 1.11, 1.12 y 1.13

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

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

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

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

Solución alternativa:

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

Registro y supervisión

1.12.0-1.12.1

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

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

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

Solución alternativa:

Ver los pasos de la solución alternativa

sigue estos pasos:

Reduce la escala de la implementación de monitoring-operator en el espacio de nombres kube-system del clúster de administrador.

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --namespace kube-system scale deploy monitoring-operator \
    --replicas=0

Edita el ConfigMap pushprox-server-rbac-proxy-config en el espacio de nombres kube-system del clúster de administrador.

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --namespace kube-system edit cm pushprox-server-rbac-proxy-config

Busca la línea principals para el listener external-pushprox-server-auth-proxy y corrige el principal_name para todos los clústeres de usuario quitando la subcadena kube-system de pushprox-client.metrics-consumers.kube-system.cluster. La nueva configuración debería verse de la siguiente manera:

permissions:
- or_rules:
    rules:
    - header: { name: ":path", exact_match: "/poll" }
    - header: { name: ":path", exact_match: "/push" }
principals: [{"authenticated":{"principal_name":{"exact":"pushprox-client.metrics-consumers.kube-system.cluster.local"}}},{"authenticated":{"principal_name":{"exact":"pushprox-client.metrics-consumers.kube-system.cluster."}}},{"authenticated":{"principal_name":{"exact":"pushprox-client.metrics-consumers.cluster."}}}]

Reinicia la implementación de pushprox-server en el clúster de administrador y la implementación de pushprox-client en los clústeres de usuario afectados:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG --namespace kube-system rollout restart deploy pushprox-server
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG --namespace kube-system rollout restart deploy pushprox-client

Los pasos anteriores deberían resolver el problema. Una vez que el clúster se actualice a la versión 1.12.2 y posteriores, en las que se corrigió el problema, aumenta la cantidad de kube-system monitoring-operator del clúster de administrador para que pueda volver a administrar la canalización.
```
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG --namespace kube-system scale deploy monitoring-operator --replicas=1
```

Otro

1.11.3

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

El comando gkectl repair admin-master falló con el siguiente mensaje:

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

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

Solución alternativa:

Vuelve a ejecutar el comando con --skip-validation.

Registro y supervisión

1.11, 1.12, 1.13, 1.14, 1.15 y 1.16

Falla de Cloud Audit Logging debido a que se denegó el permiso

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

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

Solución alternativa:

Ver los pasos de la solución alternativa

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

Primero, verifica las cuentas de servicio existentes permitidas para los registros de auditoría de Cloud en tu proyecto:

curl -H "Authorization: Bearer $(gcloud auth print-access-token)" \
    https://gkehub.googleapis.com/v1alpha/projects/PROJECT_ID/locations/global/features/cloudauditlogging

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

En los comandos anteriores:

Reemplaza PROJECT_ID por el proyecto de registro de auditoría del clúster.
Reemplaza SERVICE_ACCOUNT_EMAIL por la dirección de correo electrónico de la cuenta de servicio de registro de auditoría del clúster.

Operación, seguridad

1.11

Falla de los certificados de verificación `gkectl diagnose`

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

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

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

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

Solución alternativa:

Puedes ignorar estos mensajes.

Sistema operativo

1.8, 1.9, 1.10, 1.11, 1.12, 1.13

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

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

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

Desde Google Distributed Cloud v1.8, la imagen de Ubuntu se endurece con la comparativa de CIS de nivel 2. Una de las reglas de cumplimiento, "4.1.2.2 Ensure audit logs are not automatically deleted", garantiza el parámetro de configuración de auditd max_log_file_action = keep_logs. Esto genera que todas las reglas de auditoría se conserven en el disco.

Solución alternativa:

Ver los pasos de la solución alternativa

Estación de trabajo de administrador

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

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

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

Nodos del clúster

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

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

Ten en cuenta que realizar este cambio en la configuración de auditd incumpliría la regla "4.1.2.2 Ensure audit logs are not automatically deleted" del nivel 2 de CIS.

Redes

1.10, 1.11.0-1.11.3, 1.12.0-1.12.2, 1.13.0

`NetworkGatewayGroup` La IP flotante entra en conflicto con la dirección del nodo

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

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

En las versiones afectadas, kubelet puede vincularse erróneamente a una dirección IP flotante asignada al nodo y registrarla como dirección de nodo en node.status.addresses. El webhook de validación verifica las direcciones IP flotantes de NetworkGatewayGroup en comparación con todas las de node.status.addresses en el clúster y las considera un conflicto.

Solución alternativa:

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

Guarda la configuración del webhook para que se pueda restablecer al final:

kubectl -n kube-system get validatingwebhookconfiguration \
    ang-validating-webhook-configuration -o yaml > webhook-config.yaml

Edita la configuración del webhook:

kubectl -n kube-system edit validatingwebhookconfiguration \
    ang-validating-webhook-configuration

Quita el elemento vnetworkgatewaygroup.kb.io de la lista de configuración del webhook y cierra para aplicar los cambios.
Crea o edita tu objeto NetworkGatewayGroup.

Vuelve a aplicar la configuración original del webhook:

kubectl -n kube-system apply -f webhook-config.yaml

Instalación, actualizaciones y revisiones

1.10.0-1.10.2

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

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

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

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

Por ejemplo, supongamos que la VIP del plano de control del clúster de administrador es 192.168.1.25. Si la dirección IP de la VM del plano de control del clúster de administrador tiene el mismo prefijo, por ejemplo,192.168.1.254, la VM del plano de control se bloqueará durante la creación. Este problema también puede activarse si la dirección de transmisión tiene el mismo prefijo que la VIP del plano de control, por ejemplo, 192.168.1.255.

Solución alternativa:

Si el motivo del tiempo de espera agotado para la creación del clúster de administrador se debe a la dirección IP de transmisión, ejecuta el siguiente comando en la VM del plano de control del clúster de administrador:
```
ip addr add ${ADMIN_CONTROL_PLANE_NODE_IP}/32 dev ens192
```
Esto creará una línea sin una dirección de transmisión y desbloqueará el proceso de inicio. Después de desbloquear la secuencia de comandos de inicio, ejecuta el siguiente comando para quitar esta línea agregada:
```
ip addr del ${ADMIN_CONTROL_PLANE_NODE_IP}/32 dev ens192
```
Sin embargo, si el motivo del tiempo de espera para la creación del clúster de administrador se debe a la dirección IP de la VM del plano de control, no podrás desbloquear la secuencia de comandos de inicio. Cambia a otra dirección IP y vuelve a crear o actualiza a la versión 1.10.3 o posterior.

Sistema operativo, actualizaciones

1.10.0-1.10.2

El estado del clúster de administrador que usa la imagen de COS se perderá cuando se actualice el clúster de administrador o se repare la instancia principal de administrador.

DataDisk no se puede activar correctamente en el nodo instancia principal del clúster de administrador cuando se usa la imagen de COS, y el estado del clúster de administrador que usa esta imagen se perderá al actualizarse el clúster de administrador o al repararse la instancia principal de administrador. (el clúster de administrador que usa la imagen de COS es una función en versión preliminar)

Solución alternativa:

Vuelve a crear el clúster de administrador con osImageType configurado como ubuntu_containerd

Después de crear el clúster de administrador con osImageType configurado como cos, toma la clave SSH del clúster de administrador y establece una conexión SSH al nodo principal del administrador. El resultado de df -h contiene /dev/sdb1 98G 209M 93G 1% /opt/data. Y el resultado de lsblk contiene -sdb1 8:17 0 100G 0 part /opt/data.

Sistema operativo

1.10

Búsqueda de DNS con error resuelto por el sistema en dominios `.local`

En la versión 1.10.0 de Google Distributed Cloud, las resoluciones de nombres en Ubuntu se enrutan a la escucha local resuelta por sistemas que se ejecuta en 127.0.0.53 de forma predeterminada. El motivo es que, en la imagen de Ubuntu 20.04 que se usa en la versión 1.10.0, /etc/resolv.conf está vinculado con un symlink a /run/systemd/resolve/stub-resolv.conf, que apunta al stub de DNS localhost 127.0.0.53.

Como resultado, la resolución de nombres de DNS del host local se niega a verificar los servidores DNS ascendentes (especificados en /run/systemd/resolve/resolv.conf) para los nombres con un sufijo .local, a menos que los nombres se especifiquen como dominios de búsqueda.

Esto hace que las búsquedas de nombres de .local fallen. Por ejemplo, durante el inicio de los nodos, kubelet falla en la extracción de imágenes de un registro privado con un sufijo .local. Especificar una dirección de vCenter con un sufijo .local no funcionará en una estación de trabajo de administrador.

Solución alternativa:

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

Por el momento, gkectl update aún no admite la actualización del campo searchDomainsForDNS.

Por lo tanto, si no configuraste este campo antes de la creación del clúster, debes establecer una conexión SSH a los nodos y omitir el stub resuelto por el sistema local cambiando el symlink de /etc/resolv.conf de /run/systemd/resolve/stub-resolv.conf (que contiene el stub 127.0.0.53 local) a /run/systemd/resolve/resolv.conf (que apunta al DNS ascendente real):

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

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

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

Instalación, sistema operativo

1.10

La IP del puente de Docker usa `172.17.0.1/16` en lugar de `169.254.123.1/24`

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

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 cambiar el nombre del siguiente archivo de configuración de systemd para dockerd y, luego, reiniciar el servicio:

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

sudo systemctl daemon-reload

sudo systemctl restart docker

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

ip a | grep docker0

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

Actualizaciones

1.11

La actualización a la versión 1.11 está bloqueada por la preparación de Stackdriver

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

El nombre del grupo del recurso personalizado stackdriver cambió de addons.sigs.k8s.io a addons.gke.io.
Se cambió el nombre del grupo de los recursos personalizados monitoring y metricsserver de addons.k8s.io a addons.gke.io.
Las especificaciones de los recursos anteriores comienzan a validarse en función de su esquema. En particular, las especificaciones resourceAttrOverride y storageSizeOverride en el recurso personalizado stackdriver deben tener un tipo de cadena en los valores de las solicitudes y los límites de CPU, memoria y tamaño de almacenamiento.

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

No es necesario que realices ninguna acción si no tienes lógica adicional que se aplique a los recursos personalizados afectados o los edite. El proceso de actualización de Google Distributed Cloud se encargará de la migración de los recursos afectados y mantendrá sus especificaciones existentes después del cambio de nombre del grupo.

Sin embargo, si ejecutas alguna lógica que aplique o edite los recursos afectados, se requiere una atención especial. Primero, se debe hacer referencia a ellos con el nuevo nombre de grupo en el archivo de manifiesto. Por ejemplo:

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

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

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

De lo contrario, las aplicaciones y ediciones no surtirán efecto y podrían generar un estado inesperado en los componentes de registro y supervisión. Entre los posibles síntomas, se incluyen los siguientes:

Registros de errores de conciliación en onprem-user-cluster-controller, por ejemplo:

potential reconciliation error: Apply bundle components failed, requeue after 10s, error: failed to apply addon components: failed to apply bundle objects from stackdriver-operator-addon 1.11.2-gke.53 to cluster my-cluster: failed to create typed live object: .spec.resourceAttrOverride.stackdriver-log-forwarder/stackdriver-log-forwarder.limits.cpu: expected string, got &value.valueUnstructured{Value:1}

Falla en kubectl edit stackdriver stackdriver, por ejemplo:

Error from server (NotFound): stackdrivers.addons.gke.io "stackdriver" not found

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

Cambia las solicitudes y los límites de recursos al tipo de cadena.
Quita cualquier anotación de addons.gke.io/migrated-and-deprecated: true si está presente.

Luego, reanuda o reinicia el proceso de actualización.

Sistema operativo

1.7 y versiones posteriores

Las VMs de COS no muestran IPs cuando se mueven a través de un cierre no ordenado del host

Cuando hay una falla en un servidor ESXi y se habilitó la función de vCenter HA para el servidor, todas las VMs del servidor ESXi con fallas activan el mecanismo de vMotion y se mueven a otro servidor ESXi normal. Las VMs de COS migradas perderían sus IPs.

Solución alternativa:

Reiniciar la VM

Redes

Todas las versiones anteriores a 1.14.7, 1.15.0-1.15.3 y 1.16.0

La respuesta de GARP que envía Seesaw no establece la IP de destino

El GARP periódico (ARP gratuito) que envía Seesaw cada 20 s no establece la IP de destino en el encabezado ARP. Es posible que algunas redes no acepten este tipo de paquetes (como Cisco ACI). Puede causar un tiempo de inactividad más prolongado después de que se recupera un cerebro dividido (debido a pérdidas de paquetes de VRRP).

Solución alternativa:

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

Sistema operativo

1.16, 1.28.0 a 1.28.200

Kubelet se inunda con registros que indican que "/etc/kubernetes/manifests" no existe en los nodos trabajadores.

Se configuró "staticPodPath" por error para los nodos trabajadores

Solución alternativa:

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

¿Qué sigue?

Si necesitas asistencia adicional, comunícate con Atención al cliente de Cloud.

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

Requisitos para abrir un caso de asistencia
Herramientas para ayudarte a solucionar problemas, como registros y métricas
Componentes, versiones y funciones compatibles de Google Distributed Cloud para VMware (solo software).

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

No se pudo actualizar el clúster de usuario sin HA a un clúster avanzado con HA debido al campo masterNode.replicas inmutable

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

La actualización a un clúster avanzado falla si no se configura stackdriver.

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

Causa

El Pod del agente gke-connect está atascado en el estado Pending durante la creación del clúster de usuarios

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

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

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

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

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

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

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

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

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

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

Terraform quita los campos vCenter de forma inesperada

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.

Errores al crear recursos personalizados

cloud-init status siempre devuelve un error

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

gkectl devuelve un error falso en la clase de almacenamiento de NetApp

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Falta nfs-common en la imagen de SO de Ubuntu

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

La API de Kubernetes Metadata no admite VPC-SC

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

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

Se descartan las conexiones duraderas de NAT de salida

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

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

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

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

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

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

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

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

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

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

Solución alternativa

Cómo evitar la falla de actualización

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

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

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

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

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

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

Advertencias falsas sobre los PVC

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

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

La verificación previa falla cuando el nombre de host no está 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

No se pudo crear el nodo del plano de control

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

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

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

No se pudo actualizar el clúster de usuario sin HA a un clúster avanzado con HA debido al campo `masterNode.replicas` inmutable

El Pod del agente `gke-connect` está atascado en el estado `Pending` durante la creación del clúster de usuarios

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

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

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

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

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

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

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

Terraform quita los campos `vCenter` de forma inesperada

`cloud-init status` siempre devuelve un error

`gkectl` devuelve un error falso en la clase de almacenamiento de NetApp

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

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

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

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

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

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

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

No se reconoce CoreDNS `orderPolicy`

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

`gkectl prepare windows` falla

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

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

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

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

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

Mensaje de error falso sobre `vCenter.dataDisk`

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

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

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

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

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

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

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

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

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

La recreación de la VM principal de administrador con un disco de arranque nuevo (p.ej., `gkectl repair admin-master`) fallará si la función de encriptación siempre activa de Secrets está habilitada con el comando "gkectl update".

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

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

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