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

En esta página, se enumeran todos los problemas conocidos de Google Distributed Cloud en VMware. Para filtrar los problemas conocidos por versión o categoría de producto, selecciona los filtros deseados 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 alternativa
Configuración 1.29.0

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

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

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 causa que siempre muestre esta advertencia siempre que no se use dataplaneV2.forwardMode, incluso si ya configuraste enableDataplaneV2: true en el archivo de configuración del clúster.

Solución alternativa:

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

La verificación previa de la instalación del clúster de administrador de HA informa una cantidad incorrecta de IP estáticas requeridas

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

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

El requisito es incorrecto para los clústeres de administrador con alta disponibilidad 1.28 y superiores porque ya no tienen nodos complementarios. Además, debido a que las 3 IP del nodo 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 IP 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 preliminar 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 una migración sin alta disponibilidad al clúster de administrador con alta disponibilidad.

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

Solución alternativa:

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

Primero, obtén el nombre de 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 de onprem-admin-cluster-controller, agrega una anotación de "conciliación forzada" a la CR de onpremadmincluster:

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

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

Después de la solución alternativa (es posible que el controlador tarde unos minutos en finalizar la conciliación), puedes verificar que el error 400 “No se pudo verificar la firma de JWT” desapareció de los registros gke-connect-agent:

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

La IP del puente de 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 de Docker en la configuración de Docker a fin de evitar que se reserve 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 personalizara la configuración de Docker debido a una regresión en la imagen de 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 se conserva en las recreaciones de VM. Debes volver a aplicar esta solución alternativa cada vez que se vuelvan a crear VMs.
update 1.28.0-1.28.400, 1.29.0-1.29.100

El uso de interfaces de red múltiples con CNI estándar no funciona

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

No funcionará la interfaz de red múltiple con estos complementos de CNI.

Solución alternativa:

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

Las dependencias del tridente de Netapp interfieren en el controlador de CSI de vSphere.

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

Solución alternativa:

  • Inhabilitar multipathd
Actualizaciones 1.15, 1.16

El webhook del clúster de administrador puede bloquear las actualizaciones cuando agregas los parámetros de configuración necesarios.

Si algunos parámetros de configuración necesarios están vacíos en el clúster de administrador porque se omitieron las validaciones, es posible que el webhook del clúster de administrador bloquee el hecho de agregarlas. 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 recibir el siguiente mensaje de error:

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

Solución alternativa:

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

El valor predeterminado del campo controlPlaneNodePort es 30968 cuando la especificación manualLB está vacía

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

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

Solución alternativa:

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

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

Falta nfs-common en la imagen de SO Ubuntu

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

Si el registro contiene una entrada como la siguiente después de actualizar a la versión 1.28, te verás afectado por 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.

Luego, aplica el siguiente DaemonSet al 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 este clúster. Consulta las instructions.
Registro y supervisión 1.28.0-1.28.100

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

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

Solución alternativa:

En el espacio de nombres de `kube-system`, la CR `stackdriver` configura el campo `featureGates.disableExperimentalMetadataAgent` como `true` ejecutando el comando

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

luego, ejecuta

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

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

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

Cuando un clúster de administrador y cualquier clúster de usuario con ControlPlane V2 habilitado usan credenciales de vSphere diferentes, p.ej., después de actualizar las credenciales de vSphere para el clúster de administrador, es posible que clusterapi-controller no se conecte a vCenter después del reinicio. Ver 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, este problema te afecta: 
E1214 00:02:54.095668       1 machine_controller.go:165] Error checking existence of machine instance for machine object gke-admin-node-77f48c4f7f-s8wj2: Failed to check if machine gke-admin-node-77f48c4f7f-s8wj2 exists: failed to find datacenter "VSPHERE_DATACENTER": datacenter 'VSPHERE_DATACENTER' not found

Solución alternativa:

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

Registro y supervisión 1.14

Número alto de etcd de solicitudes de GRPC con errores en el Administrador de alertas de Prometheus

Prometheus podría informar alertas similares al siguiente ejemplo:

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

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

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

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

Solución alternativa:

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

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

Se interrumpen las conexiones de larga duración de la NAT de salida

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

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

Este problema ocurre porque la recolección de elementos no utilizados de anetd quita de forma involuntaria las entradas de conntrack que el daemon considera que no se usan. Hace poco, se integró una corrección upstream a anetd para corregir el comportamiento.


Solución alternativa:

No hay una solución alternativa sencilla y no vimos problemas en la versión 1.16 debido a este comportamiento. Si notas que se caen las 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 manera coherente en la conexión TCP.
Operación 1.14, 1.15 y 1.16

El firmante del CSR ignora spec.expirationSeconds cuando firma los certificados

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

Solución alternativa:

Si te afecta este problema, puedes actualizar el clúster de usuario. Para ello, agrega disableNodeIDVerificationCSRSigning: true al 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.
Herramientas de redes, actualizaciones y actualizaciones 1.16.0-1.16.3

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

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

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

Este error ocurre porque gkectl busca una dirección IP de entrada del balanceador de cargas durante las comprobaciones preliminares. Aunque esta verificación no es obligatoria cuando se inhabilita el Ingress agrupado, la verificación previa de gkectl falla cuando disableBundledIngress se establece en true.


Solución alternativa:

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

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

Para obtener más información, consulta cómo inhabilitar Ingress agrupada para un clúster existente.
Revisiones y 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 AC

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

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

Solución alternativa:

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

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

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

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

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

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

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

Si el Pod de carga de trabajo de CSI no se inicia, verás un error de tiempo de espera como el siguiente durante las validaciones de comprobación previa:

- [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 un conjunto de recursos de Pods, ejecuta el siguiente comando para verificar el estado del trabajo anthos-csi-workload-writer-<run-id>:

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

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

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

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

kubectl label namespace default istio.io/rev-

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

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

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

Operación 1.16.0-1.16.2

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

Cuando accedes a una estación de trabajo de administrador administrada por el usuario, es posible que el comando gkectl update cluster agote el tiempo de espera y no se pueda actualizar el clúster de usuario. Esto sucede si la versión del clúster de administrador es 1.15 y ejecutas gkectl update admin antes de ejecutar gkectl update cluster. Cuando se produce este error, 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, el validation-controller que activa las comprobaciones preliminares se quita del clúster. Si luego intentas actualizar el clúster de usuario, la comprobación preliminar se detiene hasta que se alcanza el tiempo de espera.

Solución alternativa:

  1. Ejecuta el siguiente comando para volver a implementar validation-controller: 
          gkectl prepare --kubeconfig ADMIN_KUBECONFIG --bundle-path BUNDLE_PATH --upgrade-platform
  2. 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

Los tiempos de espera de creación del clúster de usuario cuando la versión del clúster de administrador es 1.15

Cuando accedes a una estación de trabajo de administrador administrada por el usuario, es posible que el comando gkectl create cluster agote el tiempo de espera y no se pueda crear el clúster de usuario. Esto sucede si la versión del clúster de administrador es 1.15. Cuando se produce este error, 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 se agregó validation-controller en la versión 1.16, cuando se usa el clúster de administrador de la versión 1.15, falta la validation-controller responsable de activar las comprobaciones preliminares. Por lo tanto, cuando se intenta crear un clúster de usuario, las comprobaciones preliminares se bloquean hasta que se alcanza el tiempo de espera.

Solución alternativa:

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

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

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

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

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


Solución alternativa:

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

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

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

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

Cuando accedes a una estación de trabajo de administrador administrada por el usuario, es posible que el comando gkectl delete cluster agote el tiempo de espera y no pueda borrar el clúster de usuario. Esto sucede si primero ejecutaste gkectl en la estación de trabajo administrada por el usuario para crear, actualizar o actualizar el clúster de usuario. Cuando se produce este error, 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 la eliminación, un clúster primero borra todos sus objetos. La eliminación de los objetos de validación (que se crearon durante la creación, actualización o actualización) se detiene en la fase de eliminación. Esto sucede porque un finalizador bloquea la eliminación del objeto, lo que provoca que la eliminación del clúster falle.

Solución alternativa:

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

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

Herramientas de redes 1.15, 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 puerta de enlace de NAT de salida se encuentran en dos nodos trabajadores diferentes, el tráfico del Pod de origen no puede acceder a ningún servicio externo. Si los Pods se encuentran en el mismo host, la conexión al servicio externo o la aplicación se realiza de forma correcta.

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


Solución alternativa:

Cambia el puerto VXLAN que usa Cilium a 4789:

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

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

La actualización de un clúster de administrador con la encriptación de secretos siempre activada falla

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

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

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

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

Solución alternativa

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

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

Evita la falla de la actualización

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

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

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

Google Distributed Cloud no admite el seguimiento de bloques modificado (CBT) en los discos. Algunos software de copia de seguridad usan la función de CBT para realizar un seguimiento del estado del disco y realizar copias de seguridad, lo que hace que el disco no pueda conectarse a una VM que ejecute 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 una copia de seguridad de las VMs de Google Distributed Cloud, ya que el software de copia de seguridad de terceros podría provocar que el CBT se habilite en sus discos. No es necesario crear una copia de seguridad de estas VM.

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

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

Corrupción de datos en NFSv3 cuando los anexos paralelos a un archivo compartido se realizan desde varios hosts

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


Solución alternativa:

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

Diferencia de versión entre kubelet y el plano de control de Kubernetes

Para ciertas versiones de Google Distributed Cloud, el kubelet que se ejecuta en los nodos usa una versión diferente al plano de control de Kubernetes. Existe una discrepancia porque el objeto binario de kubelet precargado en la imagen de SO usa una versión diferente.

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

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

Solución alternativa:

No necesita realizar ninguna acción. La incoherencia solo se produce entre las versiones de parche de Kubernetes y este sesgo de versiones no ocasionó ningún problema.

Revisiones y actualizaciones 1.15.0-1.15.4

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

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

    CAVersion must start from 1

Solución alternativa:

  • Reduce 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 del nodo. Esto es necesario porque un campo nuevo introducido en el recurso personalizado del clúster de administrador en la versión 1.15 puede causar un error de puntero nulo en auto-resize-controller. 
     kubectl scale deployment auto-resize-controller -n kube-system --replicas=0 --kubeconfig KUBECONFIG
  • Ejecuta los comandos gkectl con la marca --disable-admin-cluster-webhook.Por ejemplo: 
            gkectl upgrade admin --config ADMIN_CLUSTER_CONFIG_FILE --kubeconfig KUBECONFIG --disable-admin-cluster-webhook
Operación 1.13, 1.14.0 a 1.14.8, 1.15.0 a 1.15.4, 1.16.0 a 1.16.1

La eliminación del clúster V2 del plano de control que no tiene alta disponibilidad se detiene hasta que se agote el tiempo de espera.

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

Solución alternativa:

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

De lo contrario, sigue estos pasos:

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

Después de la actualización a la versión 1.15 o posterior, aparecen las tareas constantes de attachvolume del CNS cada minuto para el PVC/PV del árbol

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


Solución alternativa:

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

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

Reinicia los Pods del controlador de CSI de vSphere:

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

Falsas advertencias contra PVC

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

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

Solución alternativa:

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

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

Si el campo annotations del resultado contiene lo siguiente, puedes ignorar la advertencia sin problemas:

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

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

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

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

Solución alternativa:

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

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

1.15 La máquina de la instancia principal del usuario experimenta una recreación inesperada cuando el controlador del clúster de usuario se actualiza 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 1.16, si tienes otros clústeres de usuario de 1.15 administrados por el mismo clúster de administrador, es posible que su máquina principal de usuario se vuelva a crear de forma inesperada.

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

La solución alternativa que elijas dependerá de cómo se encuentre el problema.

Solución cuando se actualiza el clúster de usuario con la consola de Google Cloud:

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

Opción 2: Sigue estos pasos:

  1. Agrega manualmente la anotación que se volvió a ejecutar con el siguiente comando: 
    kubectl edit onpremuserclusters USER_CLUSTER_NAME -n USER_CLUSTER_NAME-gke-onprem-mgmt --kubeconfig ADMIN_KUBECONFIG

    La anotación que se vuelve a ejecutar es la siguiente:

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

Solución cuando se actualiza el clúster de usuario con tu propia estación de trabajo de administrador:

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

Opción 2: Sigue estos pasos:

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

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

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

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

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

Solución alternativa:

Opción 1: Usa una versión que incluya la corrección.

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

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

Se produce una falla en la activación del volumen cuando se actualiza el clúster de administrador si se usa un clúster de administrador sin alta disponibilidad y un clúster de usuario v1 del plano de control.

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

A fin de verificar el problema, ejecuta los siguientes comandos para el Pod afectado:

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

Solución alternativa:

  1. Establece una conexión SSH en el nodo del plano de control del usuario. Como es un clúster de usuario del plano de control v1, el nodo del plano de control del usuario se encuentra en el clúster de administrador.
  2. Reinicia kubelet con el siguiente comando: 
        sudo systemctl restart kubelet
    Después del reinicio, el kubelet puede reconstruir la activación global de la etapa de manera correcta.
Revisiones y actualizaciones 1.16.0

No se puede crear el nodo del plano de control

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

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

Para identificar el síntoma, ejecuta el siguiente comando y accede al administrador del controlador de nube de vSphere en el clúster de administrador:

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

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

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

Solución alternativa:

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

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

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

Para identificar el problema, obtén los registros del Pod del administrador del controlador de nube de vSphere 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 (kubeception): 
          kubectl get pods --kubeconfig ADMIN_KUBECONFIG -n USER_CLUSTER_NAME | grep vsphere-cloud-controller-manager
      kubectl logs -f vsphere-cloud-controller-manager-POD_NAME_SUFFIX --kubeconfig ADMIN_KUBECONFIG -n USER_CLUSTER_NAME
  • Clúster de usuario: (Controlplane V2): 
          kubectl get pods --kubeconfig USER_KUBECONFIG -n kube-system | grep vsphere-cloud-controller-manager
      kubectl logs -f vsphere-cloud-controller-manager-POD_NAME_SUFFIX --kubeconfig USER_KUBECONFIG -n kube-system

Este es un ejemplo de mensaje de error:

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

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

Puedes usar el siguiente enfoque para verificar si el nombre de host está duplicado y, si es necesario, una solución alternativa. 
          export GOVC_DATACENTER=GOVC_DATACENTER
          export GOVC_URL=GOVC_URL
          export GOVC_USERNAME=GOVC_USERNAME
          export GOVC_PASSWORD=GOVC_PASSWORD
          export GOVC_INSECURE=true
          govc find . -type m -guest.hostName HOSTNAME
Comandos y resultados de ejemplo: 
          export GOVC_DATACENTER=mtv-lifecycle-vc01
          export GOVC_URL=https://mtv-lifecycle-vc01.anthos/sdk
          export GOVC_USERNAME=xxx
          export GOVC_PASSWORD=yyy
          export GOVC_INSECURE=true
          govc find . -type m -guest.hostName f8c3cd333432-lifecycle-337-xxxxxxxz
          ./vm/gke-admin-node-6b7788cd76-wkt8g
          ./vm/gke-admin-node-6b7788cd76-99sg2
          ./vm/gke-admin-master-5m2jb

La solución alternativa que debes seguir depende de la operación que falló.

Solución para las actualizaciones:

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

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

Solución alternativa para las instalaciones:

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

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

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

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

Usa una versión 1.16.4 o posterior de Google Distributed Cloud con la corrección o aplica la siguiente solución alternativa. La solución alternativa que debes seguir depende de la operación que falló.

Solución para las actualizaciones:

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

Solución alternativa para las instalaciones:

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

Se produce un error de creación de PVC después de que el nodo se vuelve a crear con el mismo nombre.

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

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

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


Solución alternativa:

Reinicia los Pods del controlador de CSI de vSphere:

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

La reparación de gkectl admin-master muestra el error kubeconfig unmarshall

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

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

Solución alternativa:

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

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

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

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

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

  3. Copia el nombre de la plantilla de VM que coincida con el nombre de la máquina que estás reparando y usa el nombre de la plantilla en el comando de reparación.
  gkectl repair admin-master \
      --config=/home/ubuntu/admin-cluster.yaml \
      --kubeconfig=/home/ubuntu/kubeconfig \
      --admin-master-vm-template=/atl-qual-vc07/vm/gke-admin-98g94-zx...7vx-0-tmpl
Herramientas de 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 no funciona debido a que hay poco espacio en el disco

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

    GRUB_FORCE_PARTUUID set, initrdless boot failed. Attempting with initrd

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


Solución alternativa:

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

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

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

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

Cuando intentes actualizar (gkectl upgrade admin) o actualizar (gkectl update admin) un clúster de administrador que no es de alta disponibilidad y que tiene un 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 Atención al cliente de Google para obtener ayuda.
Actualizaciones 1.13.0-1.13.9, 1.14.0-1.14.6, 1.15.1-1.15.2

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

Cuando un clúster de administrador está inscrito en la API de GKE On-Prem, la actualización del clúster de administrador a las versiones afectadas puede fallar porque no se pudo actualizar la membresía de la flota. Cuando se produce este error, 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 de forma explícita el clúster o cuando actualizas un clúster de usuario con un cliente de la API de GKE On-Prem.


Solución alternativa:

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

Cuando un clúster de administrador se inscribe en la API de GKE On-Prem, su anotación de vínculo de recursos se aplica al recurso personalizado OnPremAdminCluster, que no se conserva durante las actualizaciones posteriores del clúster de administrador debido a que se usa la clave de anotación incorrecta. Esto puede provocar 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 de forma explícita el clúster o cuando actualizas un clúster de usuario con un cliente de la API de GKE On-Prem.


Solución alternativa:

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

No se reconoce orderPolicy de CoreDNS

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

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


Solución alternativa:

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

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

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

Ciertas condiciones de carrera pueden hacer que el estado de OnPremAdminCluster no sea coherente entre el punto de control y la CR real. Cuando esto sucede, puedes encontrar 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 o actualización. Comunícate con nuestro equipo de asistencia al cliente para proceder con la solución alternativa.
Operación 1.13.0-1.13.9, 1.14.0-1.14.5, 1.15.0-1.15.1

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

Google Distributed Cloud cambia los certificados de administrador en los planos de control del clúster de administrador con cada proceso de conciliación, por ejemplo, durante una actualización del clúster. Este comportamiento aumenta la posibilidad de obtener certificados no válidos para el 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 kube-apiserver del clúster de administrador pueden contener errores como los siguientes: 
    Unable to authenticate the request" err="[x509: certificate has expired or is not yet valid...

Solución alternativa:

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

Componentes de la puerta de enlace de red de Anthos expulsados o pendientes debido a la falta de clase de prioridad

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

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

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


Solución alternativa:

Actualiza a la versión 1.15 o posterior.

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

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

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

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

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

Borra el espacio de nombres gke-connect: 

kubectl delete ns gke-connect --kubeconfig=ADMIN_KUBECONFIG
Obtén el nombre del clúster de administrador: 
kubectl get onpremadmincluster -n kube-system --kubeconfig=ADMIN_KUBECONFIG
Borra la membresía de la flota: 
gcloud container fleet memberships delete ADMIN_CLUSTER_NAME
y reanuda la actualización del clúster de administrador.
Operación 1.13.0-1.13.8, 1.14.0-1.14.5, 1.15.0-1.15.1

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

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

Errores de gkectl prepare windows

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


Solución alternativa:

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

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


Opción 1: Actualización azul-verde

Puedes crear un clúster nuevo con Google Distributed Cloud 1.13 o una versión posterior con grupos de nodos de Windows, migrar tus cargas de trabajo al nuevo clúster y, luego, eliminar 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 menos interrupciones y tiempo de inactividad 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: Para esta opción, las cargas de trabajo de Windows no podrán ejecutarse hasta que el clúster se actualice a la versión 1.13 y se vuelvan a agregar los grupos de nodos de Windows.

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

La configuración de RootDistanceMaxSec no surte efecto en ubuntu nodos

Se usará el valor predeterminado de 5 segundos para RootDistanceMaxSec en los nodos, en lugar de 20 segundos, que debería ser la configuración esperada. Si verificas el registro de inicio del nodo mediante una conexión SSH a la VM, que se encuentra en “/var/log/startup.log”, verás 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 no esté sincronizado con el servidor NTP cuando el desvío del reloj sea superior a 5 segundos.


Solución alternativa:

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

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

gkectl update admin falla debido a que hay un campo osImageType vacío.

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

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

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

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

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

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


Solución alternativa:

Actualiza a una versión de Google Distributed Cloud con la corrección. Si no puedes realizar la actualización, comunícate con Atención al cliente de Cloud para resolver el problema.
Instalación, seguridad 1.13, 1.14, 1.15, 1.16

SNI no funciona en clústeres de usuario 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 está habilitado Controlplane V2 ( enableControlplaneV2: true).


Solución alternativa:

Hasta que un parche de Google Distributed Cloud esté disponible con la corrección, si necesitas usar SNI, inhabilita Controlplane V2 (enableControlplaneV2: false).
Instalación 1.0-1.11, 1.12, 1.13.0-1.13.9, 1.14.0-1.14.5, 1.15.0-1.15.1

$ en el nombre de usuario del registro privado provoca un error 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 verifiques el /var/log/startup.log en la máquina del plano de control del administrador, verás el siguiente error:

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

Solución alternativa:

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

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

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

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

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

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

Los servidores virtuales de 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 BIG-IP de F5, los servidores virtuales de BIG-IP de F5 no se quitan después de la eliminación del clúster.


Solución alternativa:

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

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

Si creas una versión 1.13.8 o 1.14.4 del clúster de administrador, o actualizas un clúster de administrador a la versión 1.13.8 o 1.14.4, el tipo de clúster 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 la estación de trabajo de administrador, la creación o actualización del clúster de administrador no puede mostrar el tipo de clúster. Cuando ejecutas el siguiente comando en la estación de trabajo de administrador, se muestran los contenedores correspondientes que están pendientes con ErrImagePull:

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

    La respuesta contiene entradas como las siguientes:

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

    Estas imágenes de contenedor deben estar precargadas en el tipo de imagen de contenedor del clúster. Sin embargo, el tipo v0.18.0 tiene un problema con las imágenes de contenedor precargadas, 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 el clúster de administrador está pendiente de creación o actualización:

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

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

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

    La conmutación por error falla en el clúster de usuario y el clúster de administrador de HA en el plano de control V2 cuando la red filtra las solicitudes de GARP duplicadas.

    Si las VM del clúster están conectadas con un switch que filtra las solicitudes de GARP (ARP injustificadas) duplicadas, es posible que la elección de líder de keepalived experimente una condición de carrera, que haga que algunos nodos tengan entradas de tabla ARP incorrectas.

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


    Solución alternativa:

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

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

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

    Solución alternativa:

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

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

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

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

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

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

    Solución alternativa:

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

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

    Actualizaciones y actualizaciones 1.10, 1.11, 1.12, 1.13.0 a 1.13.1

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

    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:

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

    Configuración 1.15.0

    Mensaje de error falso sobre vCenter.dataDisk

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

    vCenter.dataDisk must be present in the AdminCluster spec

    Solución alternativa:

    Puedes ignorar este mensaje de error.
    VMware 1.15.0

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

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


    Solución alternativa:

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

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

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

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


    Solución alternativa:

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

    Los Pods permanecen en el estado Con errores después de volver a crearlos o actualizarlos en el nodo del plano de control

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


    Solución alternativa:

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

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

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

    failed to check secret reference for private registry …


    Solución alternativa:

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

    Revisiones y actualizaciones 1.15.0

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

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

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


    Solución alternativa:

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

    Los volúmenes de vSphere de árbol migrados que usan 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 un conjunto anterior de nodos (por ejemplo, cuando se actualiza un clúster o un grupo de nodos). Es posible que las cargas de trabajo con estado que antes funcionaban bien no puedan escribir en sus volúmenes en el nuevo conjunto de nodos.


    Solución alternativa:

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

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

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

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


    Solución alternativa:

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

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

    audit-proxy podría fallar debido a una --cluster-name vacía. 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 el Pod del proxy de auditoría.


    Solución alternativa:

    Para 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 de usuario mediante SSH y actualiza /etc/kubernetes/manifests/audit-proxy.yaml con --cluster_name=USER_CLUSTER_NAME.

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

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

    Se volverá a implementar el plano de control adicional justo después de gkectl upgrade cluster

    Justo después de gkectl upgrade cluster, los Pods del plano de control podrían volver a implementarse. El estado del clúster de gkectl list clusters cambia de RUNNING a RECONCILING. Es posible que se agote el tiempo de espera de las solicitudes al clúster de usuario.

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

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


    Solución alternativa:

    Espera a que el estado del clúster vuelva a cambiar a RUNNING en gkectl list clusters, o actualiza a las versiones con la corrección: 1.13.6 o superior, 1.14.2 o superior, o 1.15 o superior.
    Revisiones y 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 con errores y no debes usarla. Se quitaron los artefactos del bucket de Cloud Storage.

    Solución alternativa:

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

    gke-connect-agent sigue usando la imagen antigua después de que se actualiza la credencial de registro

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

    • gkectl update credentials componentaccess si no se usa el registro privado
    • gkectl update credentials privateregistry si usas el 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, 1.14.4 y posteriores de Google Distributed Cloud.


    Solución alternativa:

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

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

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

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

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

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

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

    Error de verificación manual de la configuración del balanceador de cargas

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

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

    Solución alternativa:

    Opción 1: Puedes usar las versiones 1.13.7 y 1.14.4 del parche que incluyen 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

    Inundación del reloj de etcd

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

    • Se interrumpió la programación de Pods
    • No se pueden registrar los nodos
    • kubelet no observa los cambios en el Pod

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

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

    Solución alternativa

    Si no puedes actualizar de inmediato, puedes mitigar el riesgo de que falle el clúster si reduces la cantidad de nodos en él. Quita nodos hasta que la métrica etcd_network_client_grpc_sent_bytes_total sea inferior a 300 Mbps.

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

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

      Ir al Explorador de métricas

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

    GKE Identity Service puede causar latencias del plano de control

    Cuando se reinicia o actualiza un clúster, GKE Identity Service puede sobrecargarse con el tráfico compuesto por tokens JWT vencidos que se reenvían desde kube-apiserver hacia GKE Identity Service a través del webhook de autenticación. Aunque GKE Identity Service no genera un bucle de fallas, deja de responder y deja de entregar más solicitudes. En última instancia, este problema conduce a latencias más altas del 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 te afecta este problema, sigue estos pasos:

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

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

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

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

        Si el registro contiene una entrada como la siguiente, entonces te verás afectado por este problema:

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

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

        Clúster de administrador:

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

        Clúster de usuario:

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

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

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

    Solución alternativa

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

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

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

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


    Solución alternativa:

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

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

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

    Faltan 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 que incluyen las verificaciones de estado de los Pods en los espacios de nombres. Sin embargo, comienzan a omitir los Pods del plano de control del usuario por error. Si usas el modo v2 del plano de control, esto no afectará tu clúster.


    Solución alternativa:

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

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

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

    Kubernetes redirección 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 la estación de trabajo de administrador, pero el proxy no permite registry.k8s.io y la imagen de contenedor k8s.gcr.io/pause:3.2 no se almacena en caché de forma local, las actualizaciones del clúster de administrador fallarán cuando se extraiga la imagen de contenedor.


    Solución alternativa:

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

    Se produjo un 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 sube y baja ya existe. La comprobación previa intenta validar un balanceador de cargas de sube y baja inexistente.

    Solución alternativa:

    Quita el archivo del grupo de sube y baja existente de este clúster. El nombre 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.
    Herramientas de redes 1.14

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

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

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

    sudo conntrack -S

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

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

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

    Solución alternativa

    La mitigación a corto plazo consiste en aumentar el tamaño de la tabla de hash de netfiler (nf_conntrack_buckets) y 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 de tamaño de la tabla es 262144. Te sugerimos que establezcas un valor igual a 65,536 veces la cantidad de núcleos en el nodo. Por ejemplo, si tu nodo tiene ocho núcleos, establece el tamaño de la tabla en 524288.
    Herramientas de redes 1.13.0-1.13.2

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

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

    Esto se debe a que las dos implementaciones toleran todos los taints, incluido el taint de nodo de Windows.


    Solución alternativa:

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

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

    Quita el siguiente spec.template.spec.tolerations:

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

    Además, 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 de registro privado del clúster de usuario

    Es posible que no puedas crear un clúster de usuario si especificas la sección privateRegistry con la credencial fileRef. Es posible que la solicitud preliminar 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 si deseas usar la misma credencial de registro privado que el clúster de administrador, puedes quitar o comentar la sección privateRegistry en el archivo de configuración del clúster de usuario.
    • Si deseas usar una credencial de registro privado específica para tu clúster de usuario, puedes especificar temporalmente la sección privateRegistry de esta manera:
      privateRegistry:
  address: PRIVATE_REGISTRY_ADDRESS
  credentials:
    username: PRIVATE_REGISTRY_USERNAME
    password: PRIVATE_REGISTRY_PASSWORD
  caCertPath: PRIVATE_REGISTRY_CACERT_PATH
      (NOTA: Esta es solo una solución temporal y estos campos ya dejaron de estar disponibles, considera usar el archivo de credenciales cuando actualices a la versión 1.14.3 o posterior).

    Operaciones 1.10+

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

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

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

    Este problema está presente en todas las versiones de GKE en Bare Metal 1.10. Sin embargo, algunas versiones más recientes de la versión 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 posterior, ejecuta lo siguiente:

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

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

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

    Almacenamiento 1.12+, 1.13.3

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

    Es posible que kube-controller-manager agote el tiempo de espera cuando se desconectan los PV/PVC después de 6 minutos y se desconectan de manera forzosa los PV/PVC. 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 mediante SSH y reinicia el nodo.
    Revisiones y actualizaciones 1.12+, 1.13+, 1.14+

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

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

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


    Solución alternativa:

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

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

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

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


    Solución alternativa:

    Apaga el nodo principal de administrador, sigue a https://kb.vmware.com/s/article/1003746 para actualizar el nodo a la versión esperada descrita 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+

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

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

    Por ejemplo, podrías ver los siguientes síntomas.

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


    Solución alternativa:

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

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

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

    Se limpió la clave de la cuenta de servicio de acceso a los componentes después de la actualización del clúster de administrador desde la versión 1.11.x.

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

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

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

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

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


    Solución alternativa:

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

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

    El escalador automático del clúster no funciona cuando está habilitado Controlplane V2

    En el caso de los clústeres de usuario creados con Controlplane V2 o un modelo de instalación nuevo, los grupos de nodos con 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 también muestra que su estado no está en buen estado. 

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


    Solución alternativa:

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

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

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

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


    Solución alternativa:

    Incluye IP individuales en el archivo de bloque de IP hasta actualizar a una versión con la corrección: 1.12.5, 1.13.4, 1.14.1+.
    Revisiones y actualizaciones 1.14.0-1.14.1

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

    Cuando Actualiza el tipo de imagen de SO del plano de control en admin-cluster.yaml, y si el clúster de usuario correspondiente se creó a través de Controlplane V2, es posible que las máquinas del plano de control del usuario no terminen de volver a crearse 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 imagen del SO de los nodos con kubectl --kubeconfig USER_KUBECONFIG get nodes -owide. Por ejemplo, si actualizas de Ubuntu a COS, debemos esperar a que todas las máquinas del plano de control cambien por completo de Ubuntu a COS, incluso después de que se complete el comando de actualización.

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

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

    Un problema con Calico en Google Distributed Cloud 1.14.0 hace que la creación y la eliminación del Pod fallen y se muestre 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 el clúster se crea o actualiza a 1.14 mediante Calico.

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

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


    Solución alternativa:

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

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

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

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

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

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


    Solución alternativa:

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

    Operaciones, actualizaciones y actualizaciones 1.11.0 - 1.11.1, 1.10.0 - 1.10.4, 1.9.0 - 1.9.6

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

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

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

    Operaciones, actualizaciones y actualizaciones 1.10+

    Vuelve a crear 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 de secretos siempre activada está habilitada con el comando “gkectl update”.

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

    Revisiones y actualizaciones 1.10

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

    Actualizar el primer clúster de usuario de 1.9 a 1.10 podría volver a crear nodos en otros clústeres de usuario en el mismo clúster de administrador. La recreación se realiza de forma 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:
    Revisiones y actualizaciones 1.10.0

    Docker se reinicia con frecuencia después de actualizar el clúster

    Actualizar el clúster de usuario a 1.10.0 puede provocar que Docker se reinicie con frecuencia.

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

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

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

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


    Solución alternativa:
    Revisiones y actualizaciones 1.11 y 1.12

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

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

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


    Solución alternativa:
    Operación 1.11, 1.12 y 1.13.0 a 1.13.1

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

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

    Sin embargo, algunos recursos de Kubernetes, como los objetos de la API de clúster, que se encuentran en este espacio de nombres, contienen información 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.
    Revisiones y actualizaciones 1.11.0-1.11.4, 1.12.0-1.12.3, 1.13.0-1.13.1

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

    Cuando se borra, actualiza o actualiza un clúster de usuario, el vaciado de nodos puede detenerse en las siguientes situaciones:

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

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

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

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

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

    kubevols es el directorio predeterminado para el controlador de árbol de vSphere. Cuando no se crean objetos PVC/PV, es posible que encuentres un error que indique que el vaciado de nodos se detendrá en el hallazgo 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 en el que se crea el nodo. Esto se define en el campo vCenter.datastore de los archivos user-cluster.yaml o admin-cluster.yaml.
    Configuración 1.7, 1.8, 1.9, 1.10, 1.11, 1.12, 1.13, 1.14

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

    Cuando se borra el clúster de usuario, también se borran los clusterrole y clusterrolebinding correspondientes para el escalador automático del clúster. Esto afecta a todos los demás clústeres de usuario del mismo clúster de administrador con el escalador automático de clústeres habilitado. Esto se debe a que se usan el mismo clusterrole y clusterrolebinding para todos los Pods del escalador automático del clúster 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
      en el que ADMIN_CLUSTER_KUBECONFIG es el archivo kubeconfig del clúster de administrador. Este es un ejemplo de los mensajes de error que podrías ver: 
      2023-03-26T10:45:44.866600973Z W0326 10:45:44.866463       1 reflector.go:424] k8s.io/client-go/dynamic/dynamicinformer/informer.go:91: failed to list *unstructured.Unstructured: onpremuserclusters.onprem.cluster.gke.io is forbidden: User "..." cannot list resource "onpremuserclusters" in API group "onprem.cluster.gke.io" at the cluster scope
2023-03-26T10:45:44.866646815Z E0326 10:45:44.866494       1 reflector.go:140] k8s.io/client-go/dynamic/dynamicinformer/informer.go:91: Failed to watch *unstructured.Unstructured: failed to list *unstructured.Unstructured: onpremuserclusters.onprem.cluster.gke.io is forbidden: User "..." cannot list resource "onpremuserclusters" in API group "onprem.cluster.gke.io" at the cluster scope

    Solución alternativa:

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

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

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

    Los síntomas son los siguientes:

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

    Solución alternativa:

    Configuración 1.12.1-1.12.3, 1.13.0-1.13.2

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

    Un problema conocido que podría fallar 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á y mostrará el siguiente mensaje de error:

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

    Solución alternativa:

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

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

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

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

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

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

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

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

    El registro de nodos falla durante la creación, actualización, actualización y reparación automática de nodos cuando ipMode.type es static y el nombre de host configurado en el archivo de bloque de IP contiene uno o más períodos. En este caso, las solicitudes de firma de certificados (CSR) de 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 para ver si hay mensajes de error:

    • Visualiza los registros en el clúster de administrador del contenedor clusterapi-controller-manager en el Pod clusterapi-controllers:
      kubectl logs clusterapi-controllers-POD_NAME \
    -c clusterapi-controller-manager -n kube-system \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG
    • Para ver los mismos registros en el clúster de usuario, ejecuta el siguiente comando:
      kubectl logs clusterapi-controllers-POD_NAME \
    -c clusterapi-controller-manager -n USER_CLUSTER_NAME \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG
      , en el que:
      • ADMIN_CLUSTER_KUBECONFIG es el archivo kubeconfig del clúster de administrador.
      • USER_CLUSTER_NAME es el nombre del clúster de usuario.
      Este es un ejemplo de 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 kubelet en el nodo problemático: 
      journalctl --u kubelet
      Este es un ejemplo de mensajes de error que podrías ver: "Error getting node" err="node \"node-worker-vm-1\" not found"

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

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


    Solución alternativa:

    Clúster de usuario

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

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

    Clúster de administrador

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

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

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

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

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

    Invalid value 'XXXX' specified for property startup-data

    A continuación, se muestra una ruta de archivo de ejemplo para el registro del controlador de 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 evita que el controlador asigne IP flotantes adicionales al nodo. Esto puede generar una mayor carga en otros nodos o una falta de redundancia para la alta disponibilidad.

    La actividad de Dataplane no se ve afectada.

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

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


    Solución alternativa:

    Actualiza a una versión corregida (cuando esté disponible).
    Revisiones y actualizaciones 1.12.0 a 1.12.2, 1.13.0

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

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

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

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

    En los registros del Pod clusterapi-controller, los errores son como los siguientes:

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

    El error se repite en la misma máquina durante varios minutos para ejecuciones exitosas, incluso sin este problema, la mayor parte del tiempo puede pasar con rapidez. Sin embargo, en algunos casos poco frecuentes, puede detenerse 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 queda atascado en la eliminación del finalizador debido a actualizaciones muy frecuentes de otros controladores. Esto puede provocar que el comando gkectl agote el tiempo de espera, pero el controlador sigue conciliando el clúster para que el proceso de actualización o actualización se complete con el tiempo.


    Solución alternativa:

    Preparamos varias opciones de mitigación diferentes para este problema, que depende del entorno y los requisitos.

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

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

      Lo bueno es que esta opción no necesita que realices ninguna acción, 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 máquina antiguos.

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

      La desventaja es que los Pods de las máquinas se borrarán directamente en lugar de expulsarse, 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: 
      kubectl --kubeconfig CLUSTER_KUBECONFIG get machines
      El comando que aplica la anotación de reparación automática para cada máquina: 
      kubectl annotate --kubeconfig CLUSTER_KUBECONFIG \
    machine MACHINE_NAME \
    onprem.cluster.gke.io/repair-machine=true

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

    gkectl preparar la falla previa de la validación de imagen de SO

    El comando gkectl prepare falló con el siguiente error:

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

    Las comprobaciones preliminares 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, 1.13

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

    La creación del clúster de administrador falló con el siguiente error:

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

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


    Solución alternativa:

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

    gkectl prepare de pánico en util.CheckFileExists

    gkectl prepare puede entrar en pánico con el siguiente seguimiento de pila:

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

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

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


    Solución alternativa:

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

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

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

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


    Solución alternativa:

    Si ya te enfrentaste a esta situación de falla, comunícate con el equipo de asistencia.
    Revisiones y actualizaciones 1.10 y 1.11

    Si se reanuda la actualización del clúster de administrador, es posible que falte 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 del clúster de administrador reanudado, se borra la plantilla de 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 del administrador se volverá a generar durante la próxima actualización del clúster de administrador.
    Sistema operativo 1.12, 1.13

    cgroup v2 podría afectar las cargas de trabajo

    En la versión 1.12.0, cgroup v2 (unificado) está habilitado de forma predeterminada para los nodos de Container Optimized OS (COS). Esto podría causar inestabilidad en las 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 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 cualquier cambio manual que hayas realizado en el recurso personalizado de ClientConfig.


    Solución alternativa:

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

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

    La validación falla porque las particiones de BIG-IP de F5 no se pueden encontrar, a pesar de que 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 con la elección de líder de cert-manager/ca-injector.

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

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

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

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

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

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

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

    Reinicia o actualiza vCenter para versiones anteriores a 7.0U2

    Si vCenter, para las versiones anteriores a la 7.0U2, se reinicia después de una actualización o de otra manera, el nombre de red en la información de la VM de vCenter no es correcto y hace que la máquina tenga un estado Unavailable. Con el tiempo, esto hará que los nodos se reparen de forma automática para crear otros nuevos.

    Error de govmomi relacionado.


    Solución alternativa:

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

    1. El problema se solucionó en vCenter 7.0U2 y versiones posteriores.
    2. En versiones anteriores, haz clic con el botón derecho en el host y, luego, selecciona Conexión > Desconectar. 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 superior, las imágenes del SO Ubuntu están reforzadas con CIS L1 Server Benchmark.

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

    ClientAliveInterval 300
ClientAliveCountMax 0

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

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

    Solución alternativa:

    Tienes varias opciones:

    • Usa nohup para evitar que tu comando finalice durante la desconexión 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 necesitas instalar tu propio cert-manager por ciertos motivos, sigue las instrucciones siguientes para evitar conflictos:

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

    Nota: Un síntoma común de la instalación de tu propio cert-manager es que la versión o imagen de cert-manager (por ejemplo, v1.7.2) puede 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:

    <pEvitar conflictos durante la actualización

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

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

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

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

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

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

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

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

    Los elementos Docker, containerd y runc en las imágenes del SO Ubuntu que se incluyen con Google Distributed Cloud se fijan a versiones especiales que usan PPA de Ubuntu. Esto garantiza que Google Distributed Cloud califique cualquier cambio en el entorno de ejecución del contenedor antes de cada versión.

    Sin embargo, las versiones especiales son desconocidas para el Rastreador de CVE de Ubuntu, que varias herramientas de análisis de CVE usan como feed de vulnerabilidades. Por lo tanto, verás falsos positivos en los resultados del análisis de vulnerabilidades de Docker, containerd y runc.

    Por ejemplo, es posible que veas los siguientes falsos positivos de los resultados del análisis de CVE. Estas CVE ya se corrigieron en las versiones de parche más recientes de 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 puede hacer un seguimiento de la solución en https://github.com/canonical/sec-cvescan/issues/73.
    Revisiones y 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 de usuario no esté disponible por un período breve durante la actualización de los clústeres que no tienen alta disponibilidad

    Si actualizas clústeres sin alta disponibilidad de 1.9 a 1.10, es posible que notes que kubectl exec, kubectl log y webhook en relación con los clústeres de usuario podrían no estar disponibles por un período breve. Este tiempo de inactividad puede ser de hasta un minuto. Esto sucede porque kube-apiserver controla la solicitud entrante (kubectl exec, kubectl log y webhook) para el clúster de usuario. El usuario kube-apiserver es un 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 anterior no esté disponible, pero que el kube-apiserver nuevo aún no esté listo.


    Solución alternativa:

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

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

    Si estás creando o actualizando un clúster de HA y notas que la verificación de preparación de la conexión falló en el diagnóstico del clúster, en la mayoría de los casos, no afectará la funcionalidad de Google Distributed Cloud (kubectl exec, kubectl log y webhook). Esto sucede porque, en ocasiones, una o dos de las réplicas de conectividad pueden no estar listas durante un período debido a la inestabilidad de las redes o algún otro problema.


    Solución alternativa:

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

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

    A partir de la versión 1.7.2 de Google Distributed Cloud, las imágenes del SO Ubuntu están reforzadas con CIS L1 Server Benchmark.

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

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


    Solución alternativa:

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

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

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

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

    El problema subyacente es que las reglas de firewall distribuidas de NSX-T con estado finalizan la conexión de un cliente al servidor de la API del clúster de usuario a través del balanceador de cargas de Seesaw, ya que este 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 cuyos tamaños sean superiores a 32,000.


    Solución alternativa:

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

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

    Facturación de supervisión inesperada

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

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

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


    Solución alternativa

    Si te afecta este problema, te recomendamos que actualices los 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 se basa en la anotación prometheus.io/scrap=true. Con la nueva solución, también puedes controlar la recopilación de registros y métricas por separado para tus aplicaciones, con las marcas enableCloudLoggingForApplications y enableGMPForApplications, respectivamente.

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

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

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

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

    1. Busca los Pods y Services de origen que tengan las métricas facturadas no deseadas. 
      kubectl --kubeconfig KUBECONFIG \
  get pods -A -o yaml | grep 'prometheus.io/scrape: "true"'
kubectl --kubeconfig KUBECONFIG get \
  services -A -o yaml | grep 'prometheus.io/scrape: "true"'
    2. Quita la anotación prometheus.io/scrap=true del pod o servicio. Si Anthos Service Mesh agrega la anotación, considera configurar Anthos Service Mesh sin la opción de Prometheus o desactivar la función de combinación de métricas de Istio.
    Instalación 1.11, 1.12 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 función es incorrecta, la creación de un disco de datos de vSphere con govc se bloquea y el disco se crea con un tamaño igual a 0. Para solucionar el problema, debes vincular la función personalizada a nivel de vSphere vCenter (raíz).


    Solución alternativa:

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

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

    Tráfico de red alto a monitoring.googleapis.com

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

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


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

    gke-metrics-agent tiene errores frecuentes de CrashLoopBackOff

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


    Solución alternativa:

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

    1. Para evitar que se reviertan los siguientes cambios, reduce la escala verticalmente stackdriver-operator: 
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    --namespace kube-system scale deploy stackdriver-operator \
    --replicas=0
      Reemplaza USER_CLUSTER_KUBECONFIG por la ruta de acceso del archivo kubeconfig del clúster de usuario.
    2. Abre el ConfigMap gke-metrics-agent-conf para editar: 
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    --namespace kube-system edit configmap gke-metrics-agent-conf
    3. En services.pipelines, marca como comentario toda la sección de metrics/app-metrics:
      services:
  pipelines:
    #metrics/app-metrics:
    #  exporters:
    #  - googlecloud/app-metrics
    #  processors:
    #  - resource
    #  - metric_to_resource
    #  - infer_resource
    #  - disk_buffer/app-metrics
    #  receivers:
    #  - prometheus/app-metrics
    metrics/metrics:
      exporters:
      - googlecloud/metrics
      processors:
      - resource
      - metric_to_resource
      - infer_resource
      - disk_buffer/metrics
      receivers:
      - prometheus/metrics
    4. Cierra la sesión de edición.
    5. Reinicia el DaemonSet de 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 los paneles de la OOTB, verás algunos gráficos vacíos. Para encontrar métricas obsoletas en los paneles de Monitoring, ejecuta los siguientes comandos:

    gcloud monitoring dashboards list > all-dashboard.json

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

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

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

    Solución alternativa:

    Para reemplazar las métricas obsoletas

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

      4. Esta baja se debe a la actualización del agente de kube-state-metrics de la versión 1.9 a la 2.4, que es obligatoria para Kubernetes 1.22. Puedes reemplazar todas las métricas de 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 la versión 1.10 de Google Distributed Cloud y las versiones posteriores, los datos de los clústeres en Cloud Monitoring pueden contener entradas de métricas de resumen irrelevantes, como la siguiente:

    Unknown metric: kubernetes.io/anthos/go_gc_duration_seconds_summary_percentile

    A continuación, se mencionan otros tipos de métricas que pueden tener métricas de resumen irrelevantes:

    :
    • apiserver_admission_step_admission_duration_seconds_summary
    • go_gc_duration_seconds
    • scheduler_scheduling_duration_seconds
    • gkeconnect_http_request_duration_seconds_summary
    • alertmanager_nflog_snapshot_duration_seconds_summary

    Si bien estas métricas de tipo de resumen se encuentran en la lista, 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 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 [versiones 1.9.5 y posteriores, 1.10.2 y 1.11.0], aumenta la CPU para gke-metrics-agent mediante los pasos 1 a 4.

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

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

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

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

    Solución alternativa:

    Actualizar a las versiones 1.11.3 (o posteriores), versiones 1.12.1 (o posteriores) o 1.13 (y versiones posteriores)
    1.11.0 a 1.11.2, 1.12.0

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

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

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

    Solución alternativa:

    Este problema se solucionó en Google Distributed Cloud 1.13.0 y versiones posteriores. Actualiza tu clúster a una versión con la solución.
    Instalación, actualizaciones y actualizaciones 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 este no se registra con la especificación gkeConnect proporcionada durante su creación, recibirás el siguiente error.

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

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

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

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

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

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


    Solución alternativa:

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

    • Inhabilitar GKE Identity Service Si inhabilitas GKE Identity Service, no se quitará el objeto binario implementado de GKE Identity Service ni se quitará ClientConfig de GKE Identity Service. Para inhabilitar GKE Identity Service, ejecuta este comando: 
      gcloud container fleet identity-service disable \
    --project PROJECT_ID
      Reemplaza PROJECT_ID por el ID del proyecto host de la flota del clúster.
    • Actualiza el clúster a la versión 1.9.3 o posterior, o a la versión 1.10.1 o posterior para actualizar la versión del agente de Connect.
    Herramientas de 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 la IP del plano de datos.


    Solución alternativa:

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

    Puedes configurar la opción de IP virtual de L4-L7 en Tenant > Perfiles de aplicación > 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 la actualización 3 de vSphere 7.0

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

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

    Solución alternativa:

    Desde entonces, VMWare quitó estas versiones. Debes actualizar ESXi y vCenter Servers 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 que se ejecuta en nodos COS.

    Para los Pods que se ejecutan en nodos que usan imágenes de Container-Optimized OS (COS), no puedes activar el volumen emptyDir como exec. Se activa como noexec y se mostrará 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

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

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

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

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

    Las réplicas del grupo de nodos no se actualizan una vez que el ajuste de escala automático se habilita y se inhabilita 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 los clústeres de Linux

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

    stackdriver-log-forwarder en CrashLoopBackOff constante

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


    Solución alternativa:

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

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

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

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

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

    2023-06-02T10:53:40.444017427Z [2023/06/02 10:53:40] [error] [input chunk] chunk 1-1685703077.747168499.flb would exceed total limit size in plugin stackdriver.0
2023-06-02T10:53:40.444028047Z [2023/06/02 10:53:40] [error] [input chunk] no available chunk
    Es probable que la frecuencia de entrada de registros supere el límite del agente de Logging, lo que 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 del agente de Logging.

    1. Abre el recurso stackdriver para editar: 
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    --namespace kube-system edit stackdriver stackdriver
    2. Para aumentar la solicitud de CPU de stackdriver-log-forwarder, agrega la siguiente sección resourceAttrOverride al manifiesto de stackdriver: 
      spec:
  resourceAttrOverride:
    stackdriver-log-forwarder/stackdriver-log-forwarder:
      limits:
        cpu: 1200m
        memory: 600Mi
      requests:
        cpu: 600m
        memory: 600Mi
      El recurso editado debe ser similar al siguiente: 
      spec:
  anthosDistribution: on-prem
  clusterLocation: us-west1-a
  clusterName: my-cluster
  enableStackdriverForApplications: true
  gcpServiceAccountSecretName: ...
  optimizedMetrics: true
  portable: true
  projectID: my-project-191923
  proxyConfigSecretName: ...
  resourceAttrOverride:
    stackdriver-log-forwarder/stackdriver-log-forwarder:
      limits:
        cpu: 1200m
        memory: 600Mi
      requests:
        cpu: 600m
        memory: 600Mi
    3. Guarda los cambios y cierra el editor de texto.
    4. Para verificar que se aplicaron los cambios, 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 se aplicaron los cambios.
    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 kubelet no está listo. kubectl exec y kubectl logs no están disponibles durante estas decenas de segundos. Esto se debe a que el nuevo responsable de aprobación de certificados de servidor tarda un tiempo en ver las IP válidas actualizadas del nodo.

    Este problema afecta solo al certificado del servidor de kubelet, no a la programación de Pods.
    Revisiones y actualizaciones 1.12

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

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

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

    El clúster de administrador no está completamente actualizado y la versión de estado sigue siendo 1.10. La actualización del clúster de usuario a la versión 1.12 no se bloqueará con ninguna comprobación preliminar y fallará con el 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, 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 de manera incorrecta que el espacio libre es insuficiente

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

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

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


    Solución alternativa:

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

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

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

    El proceso de eliminación del clúster de usuario puede detenerse por algún motivo, lo que puede dar como resultado una invalidación del ConfigMap de MatalLB. No podrás agregar un clúster de usuario nuevo en este estado.


    Solución alternativa:

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

    Se produce una 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 gkectl check-config se ejecuta después de la creación del clúster de administrador y antes de la creación del clúster de usuario, fallará en:

    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 de forma predeterminada usa el mismo osImageType del clúster de administrador. Por el momento, la VM de prueba aún no es compatible con COS.


    Solución alternativa:

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

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

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

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

    Solución alternativa:
    Otro 1.11.3

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

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

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

    gkectl repair admin-master no puede recuperar la plantilla de VM que se usará para reparar la VM del plano de control del 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, 1.16

    Se produjo un error en los registros de auditoría de Cloud debido a un permiso denegado

    Los registros de auditoría de Cloud necesitan una configuración de permisos especial que, por el momento, solo se aplica automáticamente a 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 proyectoo y cuenta de servicio con el clúster de administrador para los Registros de auditoría de Cloud, de modo que el clúster de administrador tenga el permiso necesario.

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

    Solución alternativa:
    Operaciones, seguridad 1.11

    Error en la comprobación de certificados de gkectl diagnose

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

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

    Si tu estación de trabajo no tiene acceso a los nodos trabajadores del clúster de administrador o a los nodos trabajadores del clúster de administrador, obtendrá las siguientes fallas cuando 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:

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

    /var/log/audit/ ocupando espacio en el disco en las VMs

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

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

    Desde Google Distributed Cloud v1.8, la imagen de Ubuntu está endurecida con la comparativa de CIS nivel 2. Y una de las reglas de cumplimiento, “4.1.2.2 Asegúrate de que los registros de auditoría no se borren automáticamente”, garantiza la configuración de auditoría max_log_file_action = keep_logs. Esto da como resultado todas las reglas de auditoría que se mantienen en el disco.


    Solución alternativa:
    Herramientas de redes 1.10, 1.11.0 a 1.11.3, 1.12.0 a 1.12.2 y 1.13.0

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

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

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

    En las versiones afectadas, el kubelet puede vincularse por error a una dirección IP flotante asignada al nodo y notificarla como una dirección de nodo en node.status.addresses. El webhook de validación compara las direcciones IP flotantes NetworkGatewayGroup con todas las node.status.addresses del clúster y considera que se trata de un conflicto.


    Solución alternativa:

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

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

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

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

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

    Esto se debe a que, cuando 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 hace que la secuencia de comandos de inicio se bloquee.

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


    Solución alternativa:

    • Si el motivo del tiempo de espera 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
      De esta manera, se creará una línea sin una dirección de transmisión y se desbloqueará el proceso de inicio. Después de desbloquear la secuencia de comandos de inicio, ejecuta el siguiente comando para quitar la línea que se agregó: 
      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 es la dirección IP de la VM del plano de control, no puedes desbloquear la secuencia de comandos de inicio. Cambia a una dirección IP diferente y vuelve a crear o actualiza a la versión 1.10.3 o una posterior.
    Sistema operativo, actualizaciones y actualizaciones 1.10.0-1.10.2

    El estado del clúster de administrador que usa la imagen de COS se perderá cuando se actualice el clúster de administrador o se repare la instancia principal del 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 la imagen de COS se perderá cuando se actualice el clúster de administrador o se repare la instancia principal del administrador. (el clúster de administrador que usa una imagen de COS es una función de versión preliminar)


    Solución alternativa:

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

    Después de crear el clúster de administrador con osImageType configurado como cos, toma la clave SSH del clúster de administrador y establece una conexión SSH al nodo principal de administrador. El resultado de df -h contiene /dev/sdb1 98G 209M 93G 1% /opt/data. Y el resultado 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 un objeto de escucha local resuelto por systemd en 127.0.0.53 de forma predeterminada. Esto se debe a que, en la imagen de Ubuntu 20.04 que se usó en la versión 1.10.0, /etc/resolv.conf tiene un vínculo simbólico a /run/systemd/resolve/stub-resolv.conf, que apunta al stub de DNS del host local 127.0.0.53.

    Como resultado, la resolución de nombres de DNS de localhost no verifica los servidores DNS ascendentes (especificados en /run/systemd/resolve/resolv.conf) para 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 del nodo, kubelet no puede extraer 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.

    Actualmente, 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 en los nodos y omitir el stub local resuelto por systemd. Para ello, cambia el symlink de /etc/resolv.conf de /run/systemd/resolve/stub-resolv.conf (que contiene el stub local 127.0.0.53) a /run/systemd/resolve/resolv.conf (que apunta al DNS ascendente real):

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

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

    Esta solución no se conserva 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 de 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 de Docker que usa --bip=169.254.123.1/24, de modo que no reservará la subred 172.17.0.1/16 predeterminada. Sin embargo, en la versión 1.10.0, hay un error en la imagen de SO Ubuntu que causó que se ignorara la configuración personalizada de Docker.

    Como resultado, Docker elige la 172.17.0.1/16 predeterminada 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 systemd para Docker y, luego, reiniciar el servicio:

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

sudo systemctl daemon-reload

sudo systemctl restart docker

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

    ip a | grep docker0

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

    La preparación de Stackdriver bloquea la actualización a 1.11.

    En la versión 1.11.0 de Google Distributed Cloud, hay 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.
    • El nombre del grupo de los recursos personalizados monitoring y metricsserver cambió de addons.k8s.io a addons.gke.io.
    • Las especificaciones de los recursos anteriores comienzan a validarse en función de su esquema. En particular, las especificaciones resourceAttrOverride y storageSizeOverride del recurso personalizado stackdriver deben tener un tipo de cadena en los valores de las solicitudes y los límites de tamaño de la CPU, la memoria y el almacenamiento.

    Los cambios en el nombre 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 una lógica adicional que aplique o edite los recursos personalizados afectados. El proceso de actualización de Google Distributed Cloud se encargará de la migración de los recursos afectados y conservará las especificaciones existentes después de que cambie el nombre del grupo.

    Sin embargo, si ejecutas cualquier lógica que aplica o edita los recursos afectados, se requiere atención especial. En primer lugar, se les debe hacer referencia con el nuevo nombre de grupo en tu archivo de manifiesto. Por ejemplo:

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

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

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

    De lo contrario, las acciones aplicadas y ediciones no tendrán efecto y pueden generar un estado inesperado en los componentes de registro y supervisión. Estos son algunos de los posibles síntomas:

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

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

    1. Cambiar las solicitudes y los límites de recursos al tipo de cadena
    2. Quita cualquier anotación addons.gke.io/migrated-and-deprecated: true si está presente.
    Luego, reanuda o reinicia el proceso de actualización.

    Sistema operativo 1.7, 1.8, 1.9, 1.10, 1.11, 1.12, 1.13, 1.14, 1.15, 1.16

    Las VMs de COS no muestran IP cuando se pasan a través del cierre incorrecto del host.

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

    Solución alternativa:

    Reiniciar la VM
    Herramientas de redes todas las versiones anteriores a 1.14.7, 1.15.0-1.15.3, 1.16.0

    La respuesta de GARP que envió Seesaw no establece la IP de destino.

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

    Solución alternativa:

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

    Kubelet está repleto de registros que indican que “/etc/kubernetes/manifests” no existe en los nodos trabajadores

    "staticPodPath" se configuró por error para nodos trabajadores.

    Solución alternativa:

    Crea la carpeta “/etc/kubernetes/manifests” de forma manual
    Si necesitas asistencia adicional, comunícate con Atención al cliente de Cloud.