clústeres de Anthos alojados en VMware

En esta página, se enumeran todos los problemas conocidos de los clústeres de Anthos alojados en VMware. Para filtrar los problemas conocidos por categoría o versión de producto, selecciona los filtros que desees en los siguientes menús desplegables.

Selecciona tus versiones de clústeres de Anthos alojados en VMware:

Selecciona la categoría del problema:

O bien, busca el problema:

Categoría Versiones identificadas Problema y solución alternativa
Herramientas de redes, operación 1.10, 1.11, 1.12, 1.13, 1.14

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

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


$ 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 una incapacidad para programar Pods debido a los recursos de nodos. Dado que 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 tienen restricciones de recursos, los Pods de la puerta de enlace de la red pueden expulsarse. Este comportamiento es especialmente inadecuado para el DaemonSet de ang-node, ya que esos Pods deben estar programados 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 una PriorityClass de forma manual a los componentes de la puerta de enlace de Anthos Network. El controlador de clústeres de Anthos alojados en VMware reemplaza estos cambios manuales durante un proceso de conciliación, como durante la actualización de un clúster.

  • Asigna la clase system-cluster-critical PriorityClass a los objetos Deployment del controlador de clústeres ang-controller-manager y autoscaler.
  • Asigna la Prioridad system-node-critical al DaemonSet de nodo ang-daemon.
Revisiones y actualizaciones 1.12, 1.13, 1.14, 1.15

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

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


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

Puedes borrar el espacio de nombres gke-connect


kubectl delete ns gke-connect --kubeconfig=ADMIN_KUBECONFIG
y reanuda la actualización del clúster de administrador.
Operación 1.13.0-1.13.8, 1.14.0-1.14.5 y 1.15.0-1.15.1

gkectl diagnose snapshot --log-since no limita el período para 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 la información de depuración.
Instalación, actualizaciones y actualizaciones 1.9+, 1.10+, 1.11+ y 1.12+

gkectl prepare windows falla

gkectl prepare windows no puede instalar Docker en clústeres de Anthos alojados en versiones de VMware anteriores a 1.13 porque MicrosoftDockerProvider está obsoleto.


Solución alternativa:

La idea general para solucionar este problema es actualizar a clústeres de Anthos alojados en VMware 1.13 y usar el gkectl 1.13 a fin de crear una plantilla de VM de Windows y, luego, crear grupos de nodos de Windows. Hay dos opciones para acceder a los clústeres de Anthos alojados en VMware 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 usar esta opción.


Opción 1: Actualización azul-verde

Puedes crear un clúster nuevo con la versión 1.13 o superior de clústeres de Anthos alojados en VMware con grupos de nodos de Windows y migrar tus cargas de trabajo al clúster nuevo para, luego, eliminar el clúster actual. Se recomienda usar la versión secundaria más reciente de Anthos.

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


Opción 2: Borra los grupos de nodos de Windows y vuelve a agregarlos cuando actualices a clústeres de Anthos alojados en VMware 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. Para borrar los grupos de nodos de Windows existentes, quita la configuración de los grupos de nodos de Windows del archivo user-cluster.yaml y, luego, ejecuta el siguiente comando: 
    
gkectl update cluster --kubeconfig=ADMIN_KUBECONFIG --config USER_CLUSTER_CONFIG_FILE
  2. Actualiza los clústeres de administrador+usuario solo de Linux a la versión 1.12 según la guía del usuario de actualización para la versión secundaria de destino correspondiente.
  3. (Asegúrate de realizar este paso antes de actualizar a 1.13) Asegúrate de que enableWindowsDataplaneV2: true esté configurado en la CR de OnPremUserCluster; de lo contrario, el clúster seguirá usando Docker para los grupos de nodos de Windows, que no serán compatibles con la plantilla de VM de Windows 1.13 recién creada que no tenga instalado Docker. Si no está configurado o configurado como falso, actualice su clúster para que sea verdadero en user-cluster.yaml y luego ejecute lo siguiente: 
    
gkectl update cluster --kubeconfig=ADMIN_KUBECONFIG --config USER_CLUSTER_CONFIG_FILE
  4. Actualiza los clústeres de administrador+usuario solo de Linux a 1.13 según la guía del usuario de actualización.
  5. Prepara la plantilla de VM de Windows con la gkectl 1.13: 
    
gkectl prepare windows --base-vm-template BASE_WINDOWS_VM_TEMPLATE_NAME --bundle-path 1.13_BUNDLE_PATH --kubeconfig=ADMIN_KUBECONFIG
  6. Vuelve a agregar la configuración del grupo de nodos de Windows a user-cluster.yaml con el campo OSImage establecido en la plantilla de VM de Windows recién creada.
  7. Actualiza el clúster para agregar grupos de nodos de Windows 
    
gkectl update cluster --kubeconfig=ADMIN_KUBECONFIG --config USER_CLUSTER_CONFIG_FILE
Instalación, actualizaciones y actualizaciones 1.13.0-1.13.9, 1.14.0-1.14.5 y 1.15.0-1.15.1

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

El valor predeterminado de 5 segundos para RootDistanceMaxSec se usará 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”, puedes encontrar el siguiente error:


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

Si usas RootDistanceMaxSec de 5 segundos, es posible que el reloj del sistema no esté sincronizado con el servidor NTP cuando el desvío del reloj sea mayor de 5 segundos.


Solución alternativa:

Establece una conexión SSH a los nodos y configura RootDistanceMaxSec:


mkdir -p /etc/systemd/timesyncd.conf.d
cat > /etc/systemd/timesyncd.conf.d/90-gke.conf <<EOF
[Time]
RootDistanceMaxSec=20
EOF
systemctl restart systemd-timesyncd
Revisiones y actualizaciones 1.12.0-1.12.6, 1.13.0-1.13.6 y 1.14.0-1.14.2

gkectl update admin falla debido a que el campo osImageType está vacío

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


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

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


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

Si revisas el registro gkectl, es posible que veas que los diversos 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, ya que se introdujo en la versión 1.9.


Solución alternativa:

Actualiza a una versión de los clústeres de Anthos alojados en VMware con la solución. Si la actualización no es posible para ti, comunícate con el servicio de Atención al cliente de Cloud para resolver este problema.
Instalación, seguridad 1.13, 1.14, 1.15

La 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 se habilita Controlplane V2 ( enableControlplaneV2: true).


Solución alternativa:

Hasta que un parche de clústeres de Anthos alojados en VMware 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 causa fallas 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 /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 una versión de clústeres de Anthos alojados en VMware con la solución.
Revisiones y actualizaciones 1.12.0 a 1.12.4

Advertencias de falsos positivos sobre los 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 y 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 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 tu clave de firma de KSA a 1, pero conserva los datos de clave más recientes:
  1. Verifica el secreto del clúster de administrador en el espacio de nombres USER_CLUSTER_NAME y obtén el nombre del secreto de ksa-signing-key: 
    
kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME get secrets | grep ksa-signing-key
  2. Copia el secreto ksa-signing-key y asígnale el nombre como service-account-cert: 
    
kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME get secret KSA-KEY-SECRET-NAME -oyaml | \
sed 's/ name: .*/ name: service-account-cert/' | \
kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME apply -f -
  3. Borra el secreto de clave ksa anterior: 
    
kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME delete secret KSA-KEY-SECRET-NAME
  4. Actualiza el campo data.data en el mapa de configuración de ksa-signing-key-rotation-stage a '{"tokenVersion":1,"privateKeyVersion":1,"publicKeyVersions":[1]}': 
    
kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME \
edit configmap ksa-signing-key-rotation-stage
  5. Inhabilita el webhook de validación para editar la información de la versión en el recurso personalizado OnPremUserCluster: 
    
kubectl --kubeconfig=ADMIN_KUBECONFIG patch validatingwebhookconfiguration onprem-user-cluster-controller -p '
webhooks:
- name: vonpremnodepool.onprem.cluster.gke.io
  rules:
  - apiGroups:
    - onprem.cluster.gke.io
    apiVersions:
    - v1alpha1
    operations:
    - CREATE
    resources:
    - onpremnodepools
- name: vonpremusercluster.onprem.cluster.gke.io
  rules:
  - apiGroups:
    - onprem.cluster.gke.io
    apiVersions:
    - v1alpha1
    operations:
    - CREATE
    resources:
    - onpremuserclusters
'
  6. Actualiza el campo spec.ksaSigningKeyRotation.generated.ksaSigningKeyRotation a 1 en tu recurso personalizado OnPremUserCluster: 
    
kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME-gke-onprem-mgmt \
edit onpremusercluster USER_CLUSTER_NAME
  7. Espera a que el clúster de usuario de destino esté listo: Para verificar el estado, haz lo siguiente: 
    
kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME-gke-onprem-mgmt \
get onpremusercluster
  8. Restablece el webhook de validación para el clúster de usuario: 
    
kubectl --kubeconfig=ADMIN_KUBECONFIG patch validatingwebhookconfiguration onprem-user-cluster-controller -p '
webhooks:
- name: vonpremnodepool.onprem.cluster.gke.io
  rules:
  - apiGroups:
    - onprem.cluster.gke.io
    apiVersions:
    - v1alpha1
    operations:
    - CREATE
    - UPDATE
    resources:
    - onpremnodepools
- name: vonpremusercluster.onprem.cluster.gke.io
  rules:
  - apiGroups:
    - onprem.cluster.gke.io
    apiVersions:
    - v1alpha1
    operations:
    - CREATE
    - UPDATE
    resources:
    - onpremuserclusters
'
  9. Evita otra rotación de 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.15

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

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


Solución alternativa:

A fin de quitar los recursos de F5, sigue los pasos para limpiar una partición de F5 de un clúster de usuario
Instalación, actualizaciones y actualizaciones 1.13.8, 1.14.4

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

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

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

    La respuesta contiene entradas como las siguientes:

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

    Estas imágenes de contenedor se deben precargar en la imagen del contenedor del clúster de tipo. Sin embargo, la categoría v0.18.0 tiene un problema con las imágenes de contenedor precargadas, lo que hace que se extraigan de Internet por error.


    Solución alternativa:

    Ejecuta los siguientes comandos en la estación de trabajo de administrador, mientras el clúster de administrador está pendiente de creación o actualización:

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

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

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

    No se pudo realizar la conmutación por error en el clúster de usuario y de administrador de HA Controlplane V2 cuando la red filtró solicitudes de GARP duplicadas

    Si las VM de tu clúster están conectadas con un interruptor que filtra las solicitudes GARP duplicadas (ARP injustificada), la elección de líder de keepalife puede encontrar una condición de carrera, lo que hace 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 la 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 y 1.15.0

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

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

    Solución alternativa:

    Para los clústeres creados en 1.13 y versiones posteriores, sigue las instrucciones a continuación a fin de 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 del clúster.

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

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

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

    Solución alternativa:

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

    1. Agregar un par clave-valor falso como “foo: bar” al archivo de claves de 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-1.13.1

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

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


    Solución alternativa:

    Comprueba si el clúster se muestra entre los clústeres registrados. Como paso opcional, accede al clúster después de configurar la autenticación. Si el clúster aún está registrado, puedes omitir las siguientes instrucciones para volver a intentarlo. Para los clústeres actualizados a la versión 1.12 y posteriores, sigue las instrucciones a fin de volver a intentar el registro del clúster de administrador después de su creación. 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 de 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.
    VMware 1.15.0

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

    Durante la creación de un grupo de nodos que usa la afinidad de VM-Host, una condición de carrera puede generar que se creen varias reglas de afinidad de VM-Host con el mismo nombre. Esto puede provocar que la creación del grupo de nodos falle.


    Solución alternativa:

    Quita las reglas redundantes anteriores para que pueda continuar la creación del grupo de nodos. 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 funcione correctamente.
    Revisiones y actualizaciones 1.15.0

    Los Pods permanecen en estado de error durante la recreación o la actualización de un nodo del plano de control

    Después de volver a crear o actualizar un nodo del plano de control, es posible que algunos Pods queden en 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:

    Puede ignorar de forma segura los Pods con errores o borrarlos de forma manual.
    Seguridad, configuración 1.15

    OnPremUserCluster no está listo debido a las credenciales del registro privado

    Si usas credenciales preparadas y un registro privado, pero no configuraste credenciales preparadas para tu registro privado, es posible que OnPremUserCluster no esté listo y es posible 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 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 del almacenamiento para la migración de CSI verifica que las StorageClass no tengan parámetros que se ignoren después de la migración de CSI. Por ejemplo, si hay una StorageClass con el parámetro diskformat, gkectl upgrade admin marca la StorageClass y, luego, informa un error en la validación previa. Los clústeres de administrador creados en Anthos 1.10 y versiones anteriores tienen una StorageClass con diskformat: thin, que fallará esta validación. Sin embargo, esta aún funciona bien después de la migración de CSI. En su lugar, estas fallas deben interpretarse como advertencias.

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


    Solución alternativa:

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

    No se pueden usar los volúmenes de vSphere de árbol migrado mediante el sistema de archivos de Windows 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 nuevo conjunto de nodos reemplaza un conjunto antiguo de nodos (por ejemplo, la actualización del clúster o la actualización del grupo de nodos). Es posible que las cargas de trabajo con estado que funcionaron bien antes no puedan escribir en sus volúmenes en el nuevo conjunto de nodos.


    Solución alternativa:

    1. Obtenga 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. Determine el nombre del nodo en el que se ejecuta el Pod: 
      
kubectl --kubeconfig USER_CLUSTER_KUBECONFIGget pods \
    --namespace POD_NAMESPACE \
    -o jsonpath='{.spec.nodeName}{"\n"}'
    4. Obtén acceso de PowerShell al nodo, ya sea a través de SSH o de la interfaz web de vSphere.
    5. Establece las variables de entorno: 
      
PS C:\Users\administrator> pvname=PV_NAME
PS C:\Users\administrator> podid=POD_UID
    6. Identifica el número del 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 debe 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 para 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-1.13.7, 1.14.0-1.14.4

    vsphere-csi-secret no se actualizará 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 aún usa la credencial anterior.


    Solución alternativa:

    1. Obtén el nombre 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 realizar un seguimiento del estado del lanzamiento con los siguientes elementos: 
      
kubectl --kubeconfig=ADMIN_KUBECONFIG -n=kube-system rollout status deployment vsphere-csi-controller
      Después de que se implementa correctamente la implementación, 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

    audit-proxy un bucle de falla cuando se habilitan los registros de auditoría de Cloud con gkectl update cluster

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


    Solución alternativa:

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

    En un clúster de usuario del plano de control v1, edita el contenedor audit-proxy en el set con estado 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

    Una reimplementación adicional del plano de control justo después de gkectl upgrade cluster

    Justo después de gkectl upgrade cluster, es posible que los Pods del plano de control se vuelvan a implementar. El estado del clúster de gkectl list clusters 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 la rotación del certificado del plano de control que ocurre automáticamente después de gkectl upgrade cluster.

    Este problema solo sucede 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 versiones con la corrección: 1.13.6+, 1.14.2+ o 1.15+.
    Revisiones y actualizaciones 1.12.7

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

    Los clústeres de Anthos alojados en VMware 1.12.7-gke.19 son una versión incorrecta y no debes usarlo. 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 continúa usando la imagen anterior después de que se actualiza la credencial de registro.

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

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

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

    Este problema se solucionará en las versiones 1.13.8, 1.14.4 y posteriores de clústeres de Anthos alojados en VMware.


    Solución alternativa:

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

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

      Para el clúster de administrador: 
      
gkectl update credentials register --kubeconfig=ADMIN_CLUSTER_KUBECONFIG --config ADMIN_CLUSTER_CONFIG_FILE --admin-cluster
      Para el clúster de 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 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, 1.14

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

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

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

    Solución alternativa:

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

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

    
gkectl check-config --skip-validation-load-balancer
    Operación 1.0, 1.1, 1.2, 1.3, 1.4, 1.5, 1.6, 1.7, 1.8, 1.9, 1.10, 1.11, 1.12, 1.13 y 1.14

    escasez de reloj etcd

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

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

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

    Este problema se solucionó en las versiones 1.12.7, 1.13.6, 1.14.3 y posteriores de clústeres de Anthos alojados en VMware. Estas versiones más recientes utilizan la versión 3.4.21 de etcd. Todas las versiones anteriores de clústeres de Anthos alojados en VMware se ven afectadas por este problema.

    Solución alternativa

    Si no puedes actualizar de inmediato, puedes mitigar el riesgo de que el clúster falle mediante la reducción de la cantidad de nodos en el clúster. Quita los nodos hasta que la métrica etcd_network_client_grpc_sent_bytes_total sea inferior a 300 MBps.

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

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

      Ir al Explorador de métricas

    2. Selecciona la pestaña Configuración.
    3. Expande la opción Seleccionar una métrica, ingresa Kubernetes Container en la barra de filtros y, luego, usa los submenús para seleccionarla:
      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. Haga clic en Aplicar.
    Revisiones y actualizaciones 1.10, 1.11, 1.12, 1.13 y 1.14

    Anthos Identity Service puede causar latencias del plano de control

    Cuando se reinician los clústeres o se realizan actualizaciones, Anthos Identity Service puede verse abrumado por el tráfico que consta de tokens JWT vencidos que se reenvían de kube-apiserver a Anthos Identity Service a través del webhook de autenticación. Aunque Anthos Identity Service no falla, deja de responder y deja de entregar más solicitudes. Este problema, en última instancia, genera latencias de plano de control más altas.

    Este problema se solucionó en las siguientes versiones de clústeres de Anthos alojados en VMware:

    • 1.12.6 y posteriores
    • 1.13.6 o superior
    • 1.14.2 o posterior

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

    1. Verifica si se puede acceder al extremo de Anthos 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 clúster de control (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 recibes un código de estado de 000, significa que el problema se resolvió y ya terminaste. Si aún recibes un código de estado 400, no se inicia el servidor HTTP de Anthos Identity Service. En este caso, continúa.

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

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

        
I0811 22:32:03.583448      32 authentication_plugin.cc:295] Stopping OIDC authentication for ???. Unable to verify the OIDC ID token: JWT verification failed: The JWT does not appear to be from this identity provider. To match this provider, the 'aud' claim must contain one of the following audiences:
      2. 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, entonces este problema te afecta:

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

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

    El problema de aumento de 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 descongelación y las conexiones antiguas no se borran.


    Solución alternativa:

    Opción 1: Actualiza a la versión de parche más reciente de 1.8 a 1.11 que contenga la corrección.

    Opción 2: Si usas la versión del parche anterior a las 1.9.6 y 1.10.3, debes reducir verticalmente la escala del Pod de mantenimiento de etcd 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, 1.13

    Perderá las verificaciones de estado de los Pods del plano de control del clúster de usuario

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


    Solución alternativa:

    Esto no afectará la administración de las cargas de trabajo ni de los clústeres. Si desea verificar el estado de los Pods del plano de control, puede ejecutar los siguientes comandos:

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

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

    Kubernetes redireccionó el tráfico de k8s.gcr.io a registry.k8s.io el 20/3/2023. En los clústeres de Anthos alojados en VMware 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 y 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

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

    gkectl create loadbalancer falla con el siguiente mensaje de error:

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

    Esto se debe a que el archivo del grupo de Seesaw ya existe. Además, la comprobación previa intenta validar un balanceador de cargas de sube y baja inexistente.

    Solución alternativa:

    Quita el archivo del grupo de Seesaw existente de este clúster. El nombre de 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 de inserción de la tabla de conntrack

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

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

    
sudo conntrack -S

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

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

    Si un valor de chaintoolong en la respuesta es un número distinto de 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 la tabla de seguimiento de conexión 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 tamaño nuevo en bytes. El valor predeterminado del tamaño de la tabla es 262144. Te sugerimos que establezcas un valor igual a 65,536 veces la cantidad de núcleos 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

    Calic-typha o bucle de falla de anetd-operator en nodos de Windows con Controlplane v2

    Con Controlplane v2 o un nuevo modelo de instalación, calico-typha o anetd-operator pueden programarse en nodos de Windows y entrar en un bucle de fallas.

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


    Solución alternativa:

    Actualiza a la versión 1.13.3+ o 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 los siguientes spec.template.spec.tolerations:

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

    Agrega la siguiente tolerancia:

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

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

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

    
[FAILURE] Docker registry access: Failed to login.


    Solución alternativa:

    • Si no querías especificar el campo o quieres usar la misma credencial de registro privado que el clúster de administrador, puedes quitar o comentar la sección privateRegistry en tu archivo de configuración de clúster de usuario.
    • Si deseas usar una credencial de registro privado específica para tu clúster de usuario, puedes especificar de forma temporal la sección privateRegistry de la siguiente manera: 
      
privateRegistry:
  address: PRIVATE_REGISTRY_ADDRESS
  credentials:
    username: PRIVATE_REGISTRY_USERNAME
    password: PRIVATE_REGISTRY_PASSWORD
  caCertPath: PRIVATE_REGISTRY_CACERT_PATH
      (NOTA: Esta es solo una solución temporal y estos campos ya dejaron de estar disponibles; considera usar el archivo de credenciales cuando actualices a la versión 1.14.3 o una versión 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 la inspección de paquetes, ya que el Pod se omite y nunca usa IPTables.

    Esto se manifiesta en el modo gratuito de kube-proxy por pérdida de conectividad o enrutamiento de tráfico incorrecto para 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 clústeres de Anthos alojados en Bare Metal 1.10; sin embargo, algunas versiones más recientes de la versión 1.10 (1.10.2+) tienen una solución alternativa.


    Solución alternativa:

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

    kube-controller-manager podría desconectar los volúmenes persistentes con fuerza después de 6 minutos.

    Es posible que se agote el tiempo de espera de kube-controller-manager cuando se desconecta el PV/PVC después de 6 minutos y que se desconecta de forma forzada. En los registros detallados de kube-controller-manager, se 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 los siguientes errores:

    
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+ y 1.14+

    La actualización del clúster se detiene si se usa el 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 mediante la opción --skip-validation-all.
    Operación 1.10+, 1.11+, 1.12+, 1.13+ y 1.14+

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

    Es posible que el nodo principal del administrador que se creó mediante gkectl repair admin-master use una versión de hardware de VM inferior a la esperada. Cuando ocurra el problema, verás el error en el informe gkectl diagnose cluster. 

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


    Solución alternativa:

    Cierra el nodo principal del administrador, sigue https://kb.vmware.com/s/article/1003746 para actualizarlo a la versión esperada que se describe en el mensaje de error y, luego, inícialo.
    Sistema operativo 1.10+, 1.11+, 1.12+, 1.13+, 1.14+ y 1.15+

    La VM libera la asignación de tiempo de DHCP al apagar o reiniciar de forma inesperada, lo que puede provocar cambios en la IP.

    En systemd v244, systemd-networkd tiene un cambio de comportamiento predeterminado en la configuración KeepConfiguration. Antes de este cambio, las VM no enviaban un mensaje de liberación de asignación de tiempo de DHCP al servidor de DHCP cuando se cerraba o se reiniciaba. Después de este cambio, las VMs envían ese mensaje y muestran las IP al servidor DHCP. Como resultado, la IP liberada se puede reasignar a una VM diferente o se puede asignar una IP diferente a la VM, lo que genera un conflicto de IP (a nivel de Kubernetes, no a nivel de vSphere) o cambio de IP en las VM, lo que puede interrumpir los clústeres de varias maneras.

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

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


    Solución alternativa:

    Implementa el siguiente DaemonSet en el clúster para revertir el cambio de comportamiento predeterminado systemd-networkd. Las VM que ejecuten este DaemonSet no liberarán las IP al servidor DHCP durante el apagado o el reinicio. El servidor DHCP liberará las IP automáticamente cuando venzan las asignaciones. 

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

    Operación, actualizaciones y actualizaciones 1.12.0+, 1.13.0+ y 1.14.0+

    La clave de la cuenta de servicio de acceso a los componentes se limpia después de que el clúster de administrador se actualiza de la versión 1.11.x

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

    Después de actualizar un clúster 1.11.x a 1.12.x, el campo component-access-sa-key del secreto admin-cluster-creds se limpiará para vaciarlo. Para ello, ejecute 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ó.

    Una vez que se haya borrado la clave de la cuenta de servicio de acceso a los componentes, fallará la instalación de clústeres de usuarios nuevos o la actualización de clústeres de usuarios existentes. A continuación, se enumeran algunos mensajes de error que puedes encontrar:

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


    Solución:

    Agrega la clave de la cuenta de servicio de acceso a los componentes de forma manual en el Secret mediante el siguiente comando: 

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

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

    En el caso de los clústeres de usuario creados con Controlplane V2 o un modelo de instalación nuevo, los grupos de nodos que tienen habilitado el ajuste de escala automático siempre usan sus ajuste de escala automático.minReplicas en user-cluster.yaml. El registro del Pod del escalador automático del clúster también muestra que están en mal 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
    El Pod del escalador automático del clúster se puede encontrar 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:

    Inhabilitar 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 y 1.14.0

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

    Cuando los usuarios usan CIDR en el archivo de bloqueo 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:

    Incluye las IP individuales en el archivo del bloque de IP hasta que actualices 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 máquinas del plano de control de 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 de usuario no terminen la recreación cuando finalice el comando gkectl.


    Solución:

    Una vez que finalice la actualización, siga esperando que las máquinas del plano de control de usuario también vuelvan a crear mediante la supervisión de sus tipos de imagen de SO del nodo con kubectl --kubeconfig USER_KUBECONFIG get nodes -owide. P.ej., si se actualiza de Ubuntu a COS, deberíamos 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.14.0

    Error al crear o borrar el Pod debido a un problema de token de autenticación de la cuenta de servicio de CNI de Calico

    Un problema con Calico en clústeres de Anthos alojados en VMware 1.14.0 hace que la creación y eliminación de Pods falle y 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 se crea o actualiza el clúster a la versión 1.14 mediante Calico.

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

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


    Solución alternativa:

    Para mitigar el problema, aplica el siguiente parche en el DaemonSet de 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 y 1.14.0

    La validación del bloqueo 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 que la creación falla porque el clúster no tiene suficientes IP.


    Solución:

    Divide los CIDR en varios bloques 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 de N+1, en los que N es la cantidad de nodos del clúster, esto debería ser suficiente.

    Operación, 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 las claves de encriptación de secretos siempre activas y la configuración

    Cuando la función de encriptación de secretos siempre activada está habilitada junto con la copia de seguridad del clúster, esta no puede incluir las claves de encriptación y la configuración que requiere la función de encriptación de secretos siempre activa. Como resultado, reparar la instancia principal del 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

    Operación, actualizaciones y actualizaciones 1.10+

    Volver a crear la VM de la instancia 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 activa usa el comando “gkectl update”.

    Si la función de encriptación de secretos siempre activada no está habilitada en la creación del clúster, pero se habilita más adelante mediante la operación gkectl update, gkectl repair admin-master no puede reparar el nodo del plano de control del clúster de administrador. Se recomienda habilitar la función de encriptación de secretos siempre activa durante la creación del clúster. No existe una mitigación actual.

    Revisiones y actualizaciones 1.10

    Si se actualiza el primer clúster de usuario de 1.9 a 1.10, se vuelven a crear los nodos en otros clústeres de usuario.

    Si actualizas el primer clúster de usuario de 1.9 a 1.10, se pueden recrear nodos en otros clústeres de usuario bajo el mismo clúster de administrador. La recreación se realiza de manera 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 la actualización del clúster

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

    Ejecuta kubectl describe node NODE_NAME --kubeconfig USER_CLUSTER_KUBECONFIG para detectar este problema

    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 tenga el síntoma y ejecutar comandos como sudo journalctl --utc -u docker o sudo journalctl -x


    Solución alternativa:
    Revisiones y actualizaciones 1.11, 1.12

    No se conservan los componentes de GMP de implementación automática después de la actualización a la versión 1.12

    Si usas una versión de clústeres de Anthos alojados en VMware anterior a la 1.12 y configuraste de forma manual los componentes de Prometheus administrados por Google (GMP) en el espacio de nombres gmp-system de tu clúster, los componentes no se conservarán cuando actualices a la versión 1.12.x.

    A partir de la versión 1.12, los componentes de GMP en el espacio de nombres gmp-system y las CRD se administran mediante el objeto stackdriver, con la marca enableGMPForApplications configurada en false de forma predeterminada. Si implementas de forma manual los componentes de GMP en el espacio de nombres antes de actualizar a la versión 1.12, stackdriver borrará los recursos.


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

    Faltan objetos de 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 y 1.13.0-1.13.1

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

    Cuando borras, actualizas o actualizas un clúster de usuario, el desvío 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 PVC/PV creados por complementos de vSphere de á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 mensaje de error de muestra del comando anterior:

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

    kubevols es el directorio predeterminado para el controlador en árbol de vSphere. Cuando no se crean objetos PVC/PV, es posible que detectes un error que asegura que el desvío de nodo se detenga en la búsqueda de kubevols, ya que la implementación actual supone que kubevols siempre existe.


    Solución alternativa:

    Crea el directorio kubevols en el almacén de datos donde se crea el nodo. Esto se define en el campo vCenter.datastore en 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

    Se borrarán Cluster Autoscaler clusterrolebinding y clusterrole 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 en el mismo clúster de administrador con el escalador automático habilitado. Esto se debe a que se usan el mismo clúster de funciones y atributos Clusterrolebinding para todos los Pods del escalador automático de clústeres dentro del mismo clúster de administrador.

    Los síntomas son los siguientes:

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

    El clúster 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 el exportador de métricas de reparación automática y de vSphere no funcione.

    Los síntomas son los siguientes:

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

    Es un problema conocido que puede generar un error en gkectl check-config sin ejecutar gkectl prepare. Esto es confuso porque sugerimos ejecutar el comando antes de ejecutar gkectl prepare

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

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

    Solución alternativa:

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

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

    gkectl update admin/cluster no puede actualizar los grupos antiafinidad

    Se produjo un error conocido que podía fallar el gkectl update admin/cluster cuando se actualizaba anti affinity groups.

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

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

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

    No se pueden registrar los nodos si el nombre de host configurado contiene un punto

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

    Para ver las CSRs pendientes de un nodo, ejecute 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 ejemplo anterior, se ilustra lo siguiente:
      • ADMIN_CLUSTER_KUBECONFIG es el archivo kubeconfig del clúster de administrador.
      • USER_CLUSTER_NAME es el nombre del clúster de usuario.
      A continuación, se muestra un ejemplo de mensajes de error que puedes 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
      A continuación, se muestra un ejemplo de mensajes de error que puedes ver: "Error getting node" err="node \"node-worker-vm-1\" not found"

    Si especificas un nombre de dominio en el campo de nombre de host de un archivo de bloqueo de IP, se ignorarán los caracteres posteriores al primer período. Por ejemplo, si especificas el nombre de host como bob-vm-1.bank.plc, el nombre de host y el nombre de nodo de la VM se establecerán en 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 concilia el nombre. El responsable de aprobación rechaza la CSR y el nodo no puede iniciarse.


    Solución alternativa:

    Clúster de usuario

    Para inhabilitar la verificación del ID del 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 editarlo: 
        
sudo vi /etc/kubernetes/manifests/kube-controller-manager.yaml
      3. Busca la lista de controllers: 
        
--controllers=*,bootstrapsigner,tokencleaner,-csrapproving,-csrsigning
      4. Actualiza esta sección como se muestra a continuación: 
        
--controllers=*,bootstrapsigner,tokencleaner
    4. Abre el controlador de la API de clúster de implementación 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 certificado del registro privado

    La creación o actualización del clúster de administrador se bloquea 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

    Esta es 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.
    Herramientas de redes 1.10, 1.11.0-1.11.3, 1.12.0-1.12.2, 1.13.0

    Se marcó NetworkGatewayNodes como en mal estado debido a un conflicto de actualización de estado simultáneo

    En networkgatewaygroups.status.nodes, algunos nodos cambian entre NotHealthy y Up.

    Los registros del Pod ang-daemon que se ejecuta en ese nodo muestran errores repetidos: 

    
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.

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

    La contención en el objeto networkgatewaygroup provoca que algunas actualizaciones de estado fallen debido a un error en el control de reintentos. Si fallan demasiadas actualizaciones de estado, ang-controller-manager verá que el nodo supera su límite de tiempo de funcionamiento y lo marca como NotHealthy.

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


    Solución alternativa:

    Actualiza a una versión fija, 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 del objeto de la máquina durante la actualización o la actualización.

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

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

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

    En los registros del Pod clusterapi-controller, se muestran los siguientes errores:

    
$ 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 para la misma máquina durante varios minutos en ejecuciones exitosas incluso sin este error. Durante la mayor parte del tiempo, puede ejecutarse rápidamente, pero en algunos casos poco frecuentes puede quedarse en esta condición de carrera durante varias horas.

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


    Solución alternativa:

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

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

      Según el análisis y la reproducción en tu entorno, la actualización puede finalizar por sí sola sin ninguna intervención manual. La salvedad de esta opción es que no se sabe cuánto tiempo tardará la eliminación del finalizador en cada objeto de máquina. Puede pasar de inmediato si tiene la suerte o podría durar varias horas si la conciliación del controlador del 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 ninguna acción de tu lado, y las cargas de trabajo no se interrumpirán. La actualización solo demorará más tiempo en completarse.
    • Opción 2: Aplica la anotación de reparación automática a todos los objetos antiguos de la máquina.

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

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

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

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

    gkectl prepara la falla de comprobación previa de la validación de imagen de SO

    El comando gkectl prepare falló con lo siguiente:

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

    Las comprobaciones previas de gkectl prepare incluían una validación incorrecta.


    Solución alternativa:

    Ejecuta el mismo comando con una marca adicional --skip-validation-os-images.
    Instalación 1.7, 1.8, 1.9, 1.10, 1.11, 1.12, 1.13

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

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

    
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 el archivo YAML de configuración del clúster de usuario.
    Instalación, actualizaciones y actualizaciones 1.10, 1.11, 1.12, 1.13

    Pánico en gkectl prepare el 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 del certificado 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, 1.13

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

    Después de un intento de actualización con errores del clúster de administrador, no ejecutes gkectl repair admin-master. Si lo haces, es posible que los intentos de actualización posteriores del administrador fallen con problemas como la falla de la instancia principal del administrador en caso de falla o la VM a la que no se puede acceder.


    Solución alternativa:

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

    La actualización reanudada del clúster de administrador puede provocar que falte una 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 reanudada, se borra la plantilla de la VM del plano de control de administrador. La plantilla de VM del plano de control del administrador es la plantilla de la instancia principal del administrador que se usa para recuperar la máquina del plano de control con gkectl repair admin-master.


    Solución alternativa:

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

    cgroup v2 podría afectar las cargas de trabajo

    En la versión 1.12.0, el 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 de un clúster de COS.


    Solución alternativa:

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

    Recurso personalizado de ClientConfig

    gkectl update revierte cualquier cambio manual que hayas realizado al recurso personalizado ClientConfig.


    Solución alternativa:

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

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

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

    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 al problema de elección de líder de cert-manager/ca-injector

    Es posible que veas una falla de instalación a causa de 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:
    Seguridad, actualizaciones y actualizaciones 1.10, 1.11, 1.12, 1.13

    Es posible que sea necesario renovar los certificados antes de actualizar el clúster del administrador

    Antes de comenzar el proceso de actualización del clúster de administrador, debes asegurarte de que los certificados del clúster de administrador sean válidos y renovarlos si no lo son.

    Si comenzaste el proceso de actualización y encontraste un error relacionado con el vencimiento del certificado, comunícate con Atención al cliente de Google para obtener asistencia.

    Nota: Esta guía es solo para la renovación de los certificados del clúster de administrador.

    Solución alternativa:
    VMware 1.10, 1.11, 1.12, 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, de lo contrario, el nombre de red en la información de VM de vCenter es incorrecto y la máquina tiene el estado Unavailable. De esta manera, con el tiempo, los nodos se repararán automáticamente para crear otros nuevos.

    Error de govmomi.


    Solución alternativa:

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

    1. El problema se corrigió en vCenter 7.0U2 y versiones posteriores.
    2. Para versiones anteriores, haz clic con el botón derecho en el host y 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, 1.13

    Conexión SSH cerrada por host remoto

    Para los clústeres de Anthos alojados en VMware versión 1.7.2 y posteriores, las imágenes del SO Ubuntu se endurecen con la comparativa de servidores CIS L1.

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

    
ClientAliveInterval 300
ClientAliveCountMax 0

    El propósito de esta configuración es finalizar una sesión de cliente después de 5 minutos de tiempo de inactividad. Sin embargo, el valor ClientAliveCountMax 0 provoca un comportamiento inesperado. Cuando usas la sesión SSH en la estación de trabajo de administrador o en un nodo del clúster, la conexión SSH puede desconectarse, incluso tu cliente SSH no está inactivo, como cuando se ejecuta un comando lento, y es posible que el comando finalice 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 en la desconexión 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, 1.13

    Instalación cert-manager en conflicto

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

    Solo debes aplicar este trabajo alrededor de una vez para cada clúster, y los cambios se conservarán en la actualización del clúster.

    Nota: Un síntoma común de instalación de tu propio cert-manager es que la versión cert-manager o la imagen (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 revertir la versión en el proceso.

    Solución alternativa:

    Evita conflictos durante la actualización

    1. Desinstala tu versión de cert-manager. Si definiste tus propios recursos, te recomendamos crear una copia de seguridad .
    2. Realiza la actualización.
    3. Sigue estas instrucciones para restablecer tu propio cert-manager.

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

    • Escala la Deployment monitoring-operator a 0: 
      
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    -n USER_CLUSTER_NAME \
    scale deployment monitoring-operator --replicas=0
    • Escala las implementaciones cert-manager administradas por monitoring-operator a 0: 
      
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    -n cert-manager scale deployment cert-manager --replicas=0
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    -n cert-manager scale deployment cert-manager-cainjector\
    --replicas=0
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    -n cert-manager scale deployment cert-manager-webhook --replicas=0
    • Vuelve a instalar tu versión de cert-manager. Restablece los recursos personalizados, si los tienes.
    • Puedes omitir este paso si usas la instalación predeterminada de cert-manager ascendente o si estás seguro de que cert-manager está instalado en el espacio de nombres cert-manager. De lo contrario, copia el certificado metrics-ca cert-manager.io/v1 y los recursos del emisor de metrics-pki.cluster.local de cert-manager en el 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 es necesario volver a instalar cert-manager en los clústeres de administrador, ya que estos solo ejecutan clústeres de Anthos en cargas de trabajo del plano de control de VMware. En los casos excepcionales en los 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 cert-manager administradas por monitoring-operator a 0. 
      
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    -n cert-manager scale deployment cert-manager \
    --replicas=0

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

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    -n cert-manager scale deployment cert-manager-webhook \
    --replicas=0
    • Vuelve a instalar tu versión de cert-manager. Restablece los recursos personalizados, si los tienes.
    • Puedes omitir este paso si usas la instalación predeterminada de cert-manager ascendente o si estás seguro de que cert-manager está instalado en el espacio de nombres cert-manager. De lo contrario, copia el certificado metrics-ca cert-manager.io/v1 y los recursos del emisor de metrics-pki.cluster.local de cert-manager en el 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
    Sistema operativo 1.10, 1.11, 1.12, 1.13

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

    Las imágenes de Docker, containerd y runc de las imágenes de Ubuntu OS que se envían con los clústeres de Anthos alojados en VMware se fijan a versiones especiales con el PPA de Ubuntu. Esto garantiza que los cambios de entorno de ejecución de contenedores califiquen los clústeres de Anthos alojados en VMware antes de cada lanzamiento.

    Sin embargo, el rastreador de CVE de Ubuntu no conoce las versiones especiales, las cuales se usan como feeds de vulnerabilidades por parte de varias herramientas de análisis de CVE. Por lo tanto, verás falsos positivos en los resultados de análisis de vulnerabilidades de Docker, containerd y runc.

    Por ejemplo, es posible que veas los siguientes falsos positivos de tus resultados de análisis de CVE. Estas CVE ya se corrigieron en las versiones de parche más recientes de los clústeres de Anthos alojados en VMware.

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


    Solución alternativa:

    Canonical está al tanto de este problema y se realiza un seguimiento de la solución en https://github.com/canonical/sec-cvescan/issues/73.
    Revisiones y actualizaciones 1.10, 1.11, 1.12, 1.13

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

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


    Solución alternativa:

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

    No se pudo verificar la preparación de Konnectivity en el diagnóstico del clúster con alta disponibilidad después de crearlo o actualizarlo

    Si estás creando o actualizando un clúster con alta disponibilidad y observas que la verificación de preparación de Konectivity falló en el diagnóstico del clúster, en la mayoría de los casos, no afectará la funcionalidad de los clústeres de Anthos alojados en VMware (kubectl exec, kubectl log y webhook). Esto sucede porque, a veces, una o dos de las réplicas de contención pueden no estar listas para un período de tiempo debido a problemas de red inestables o a otros problemas.


    Solución alternativa:

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

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

    A partir de la versión 1.7.2 de los clústeres de Anthos alojados en VMware, las imágenes del SO Ubuntu se endurecen con la comparativa del servidor CIS L1.

    Como resultado, se instaló la secuencia de comandos cron /etc/cron.daily/aide para programar una verificación de aide a fin de garantizar que se siga la regla 1.4.2 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 en el sistema de archivos, es posible que experimentes aumentos repentinos de uso de CPU y memoria en ese momento.aide


    Solución alternativa:

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

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

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

    Cuando implementas clústeres de Anthos alojados en VMware 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 distribuidas con estado de NSX-T, stackdriver-operator puede que no cree gke-metrics-agent-conf de ConfigMap y cause que los Pods gke-connect-agent estén en un bucle de fallas.

    El problema subyacente es que las reglas de firewall distribuidas con 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 porque Seesaw usa flujos de conexión asimétricas. Los problemas de integración con las reglas de firewall distribuidas de NSX-T afectan a todos los clústeres de Anthos alojados en VMware que usan Seesaw. Es posible que veas problemas de conexión similares en tus propias aplicaciones cuando creen objetos grandes de Kubernetes con tamaños superiores a 32,000.


    Solución alternativa:

    Sigue estas instrucciones a fin de inhabilitar las reglas de firewall distribuidas de NSX-T o usar reglas de firewall distribuidas sin estado para 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 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 del servidor falla.
    Registro y supervisión 1.10, 1.11, 1.12, 1.13, 1.14, 1.15

    Facturación inesperada de supervisión

    En el caso de los clústeres de Anthos alojados en VMware 1.10 a la versión más reciente, algunos clientes encontraron una facturación inesperadamente alta para Metrics volume en la página Facturación. Este problema solo te afecta cuando se aplican todas las siguientes circunstancias:

    • La supervisión de aplicaciones está habilitada (enableStackdriverForApplications=true)
    • El servicio administrado para Prometheus no está habilitado (enableGMPForApplications).
    • Los Pods de la aplicación tienen la anotación prometheus.io/scrap=true. Instalar Anthos Service Mesh también puede agregar esta anotación.

    Para confirmar si este problema te afecta, enumera las métricas definidas por el usuario. Si ves la facturación por métricas no deseadas, este problema se aplica a tu caso.


    Solución alternativa

    Si este problema te afecta, te recomendamos que actualices los clústeres a la versión 1.12 y cambie a la nueva solución de supervisión de aplicaciones managed-service-for-prometheus que resuelve este problema:

  • Marcas independientes para controlar la recopilación de registros de aplicaciones frente a las métricas de aplicaciones
  • Google Cloud Managed Service para Prometheus

    • Si no puedes actualizar a la versión 1.12, sigue estos pasos:

    1. Busca los Pods y servicios de origen que tienen el no deseado facturado. 
      
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 del Service. Si se agrega la anotación mediante Anthos Service Mesh, considera configurar Anthos Service Mesh sin la opción Prometheus o desactivar la función de combinación de métricas de Istio.
    Instalación 1.11, 1.12, 1.13

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

    El instalador de clústeres de Anthos alojados en VMware puede fallar si las funciones personalizadas están vinculadas en el nivel de permisos incorrecto.

    Cuando la vinculación de función es incorrecta, se crea un disco de datos de vSphere con govc que 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 un valor 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 funciones, consulta Privilegios de cuenta de usuario de vCenter.
    Registro y supervisión 1.9.0-1.9.4, 1.10.0-1.10.1

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

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

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


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

    gke-metrics-agent tiene errores frecuentes de CrashLoopBackOff

    Para los clústeres de Anthos alojados en VMware versión 1.10 y posteriores, “gke-metrics-agent” DaemonSet 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 ejecutando 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 de stackdriver-operator: 
      
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    --namespace kube-system scale deploy stackdriver-operator \
    --replicas=0
      Reemplaza USER_CLUSTER_KUBECONFIG por la ruta de acceso 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, comenta toda la sección metrics/app-metrics: 
      
services:
  pipelines:
    #metrics/app-metrics:
    #  exporters:
    #  - googlecloud/app-metrics
    #  processors:
    #  - resource
    #  - metric_to_resource
    #  - infer_resource
    #  - disk_buffer/app-metrics
    #  receivers:
    #  - prometheus/app-metrics
    metrics/metrics:
      exporters:
      - googlecloud/metrics
      processors:
      - resource
      - metric_to_resource
      - infer_resource
      - disk_buffer/metrics
      receivers:
      - prometheus/metrics
    4. Cierra la sesión de edición.
    5. Reinicia el DaemonSet gke-metrics-agent: 
      
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    --namespace kube-system rollout restart daemonset gke-metrics-agent
    Registro y supervisión 1.11, 1.12, 1.13

    Reemplaza métricas obsoletas en el panel

    Si se usan métricas obsoletas en tus paneles de 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 deberían migrarse a sus reemplazos.

    Funciones obsoletasReemplazo
    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 que dejaron de estar disponibles

    1. Borra “Estado del nodo de GKE On-Prem” en el panel de Google Cloud Monitoring. Vuelve a instalar el estado del nodo de GKE On-Prem. Para ello, sigue estas instrucciones.
    2. Borra “Uso de nodos de GKE On-Prem” en el panel de Google Cloud Monitoring. Vuelve a instalar el “uso de nodos de GKE On-Prem” según estas instrucciones.
    3. Borra “Estado de la VM de vSphere de GKE On-Prem” en el panel de Google Cloud Monitoring. Vuelve a instalar “GKE On-Prem vSphere VM health” siguiendo estas instrucciones.

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

    Datos de métricas desconocidos en Cloud Monitoring

    Para los clústeres de Anthos alojados en VMware versión 1.10 y superior, los datos de los clústeres en Cloud Monitoring pueden contener entradas de métricas de resumen irrelevantes, como las siguientes:

    
Unknown metric: kubernetes.io/anthos/go_gc_duration_seconds_summary_percentile

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

    • apiserver_admission_step_admission_duration_seconds_summary
    • go_gc_duration_seconds
    • scheduler_scheduling_duration_seconds
    • gkeconnect_http_request_duration_seconds_summary
    • alertmanager_nflog_snapshot_duration_seconds_summary

    Si bien estas métricas de tipo de resumen están en la lista de métricas, no son compatibles con gke-metrics-agent en este momento.
    Registro y supervisión 1.10, 1.11, 1.12, 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 [versión 1.9.5+, 1.10.2+ y 1.11.0], sigue los pasos 1 a 4 a fin de aumentar la CPU de gke-metrics-agent.

    1. Abre tu recurso stackdriver para editarlo: 
      
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    --namespace kube-system edit stackdriver stackdriver
    2. Para aumentar la solicitud de CPU de gke-metrics-agent de 10m a 50m, el límite de CPU de 100m a 200m agrega la siguiente sección resourceAttrOverride al manifiesto stackdriver : 
      
spec:
  resourceAttrOverride:
    gke-metrics-agent/gke-metrics-agent:
      limits:
        cpu: 100m
        memory: 4608Mi
      requests:
        cpu: 10m
        memory: 200Mi
      El recurso editado 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 los cambios se aplicaron, ejecuta el siguiente comando: 
      
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    --namespace kube-system get daemonset gke-metrics-agent -o yaml \
    | grep "cpu: 50m"
      El comando encuentra cpu: 50m si tus ediciones se aplicaron.
    Registro y supervisión 1.11.0-1.11.2, 1.12.0

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

    Si tu clúster se ve afectado por este problema, faltan las métricas del programador y del administrador-controlador. Por ejemplo, faltan estas dos métricas.

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

    Solución alternativa:

    Actualiza a la versión 1.11.3 o posterior, o a la versión 1.12.1 o posterior.
    1.11.0-1.11.2, 1.12.0

    Faltan métricas del programador y del administrador-controlador 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-controlador. 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 los clústeres de Anthos alojados en VMware versión 1.13.0 y posteriores. Actualiza el clúster a una versión con la solución.
    Instalación, actualizaciones y actualizaciones 1.10, 1.11, 1.12, 1.13

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

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

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

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

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

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


    Solución alternativa:

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

    • Inhabilita Anthos Identity Service (AIS). Si inhabilitas AIS, no se quitará el objeto binario AIS implementado ni AIS ClientConfig. Para inhabilitar AIS, ejecuta este comando: 
      
gcloud beta container hub identity-service disable \
    --project PROJECT_NAME
      Reemplaza PROJECT_NAME por el nombre 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, 1.13

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

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


    Solución alternativa:

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

    Para configurar la opción de IP virtual L4-L7, ve a Tenant > Application Profiles > Application EPGs o uSeg EPGs. Si no se inhabilita el aprendizaje de IP, se moverá el extremo de IP entre diferentes ubicaciones de la estructura de la API de Cisco.
    VMware 1.10, 1.11, 1.12, 1.13

    Problemas de vSphere 7.0 con la actualización 3

    Recientemente, VMWare identificó problemas críticos con las siguientes versiones de Actualización 3 de vSphere 7.0:

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

    Solución alternativa:

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

    No se pudo activar el volumen emptyDir como exec en el Pod que se ejecuta en los nodos de 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 obtendrás el siguiente error: exec user process caused: permission denied. Por ejemplo, verás este mensaje de error si implementas el siguiente Pod de prueba:

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

    Y en el Pod de prueba, si ejecutas mount | grep test-volume, verás 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, 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 se habilita o se inhabilita el ajuste de escala automático en un grupo de nodos.


    Solución alternativa:

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

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

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

    stackdriver-log-forwarder en CrashLoopBackOff constante

    Para los clústeres de Anthos alojados en VMware versión 1.10, 1.11 y 1.12, stackdriver-log-forwarder Es posible que DaemonSet tenga errores CrashLoopBackOff cuando haya registros almacenados en búfer en el disco.


    Solución alternativa:

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

    1. Para evitar un comportamiento inesperado, reduce la escala de stackdriver-log-forwarder: 
      
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    -n kube-system patch daemonset stackdriver-log-forwarder -p '{"spec": {"template": {"spec": {"nodeSelector": {"non-existing": "true"}}}}}'
      Reemplaza USER_CLUSTER_KUBECONFIG por la ruta de acceso del archivo kubeconfig del clúster de usuario.
    2. Implementa el DaemonSet de limpieza para limpiar fragmentos dañados: 
      
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 limpió todos los fragmentos, puedes ejecutar los siguientes comandos. El resultado de los dos comandos debe ser igual al número de nodo del clúster: 
      
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
  logs -n kube-system -l app=fluent-bit-cleanup | grep "cleaned up" | wc -l

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
  -n kube-system get pods -l app=fluent-bit-cleanup --no-headers | wc -l
    4. 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

    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 tasa de entrada de registros supere el límite del agente de Logging, lo que hace que stackdriver-log-forwarder no envíe registros. Este problema ocurre en todas las versiones de clústeres de Anthos alojados en VMware.

    Solución alternativa:

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

    1. Abre tu recurso stackdriver para editarlo: 
      
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    --namespace kube-system edit stackdriver stackdriver
    2. Para aumentar la solicitud de CPU de stackdriver-log-forwarder, agrega la siguiente sección resourceAttrOverride al manifiesto stackdriver : 
      
spec:
  resourceAttrOverride:
    stackdriver-log-forwarder/stackdriver-log-forwarder:
      limits:
        cpu: 1200m
        memory: 600Mi
      requests:
        cpu: 600m
        memory: 600Mi
      El recurso editado 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 los cambios se aplicaron, ejecuta el siguiente comando: 
      
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    --namespace kube-system get daemonset stackdriver-log-forwarder -o yaml \
    | grep "cpu: 1200m"
      El comando encuentra cpu: 1200m si tus ediciones se aplicaron.
    Seguridad 1.13

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

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

    Este problema solo afecta al certificado del servidor de kubelet y 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

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

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

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


    Solución alternativa:

    Completa el paso para actualizar el clúster de administrador a la versión 1.11 y, luego, actualiza a 1.12.
    Almacenamiento 1.10.0-1.10.5, 1.11.0-1.11.2 y 1.12.0

    Datastore informa de manera incorrecta espacio insuficiente

    El comando gkectl diagnose cluster falló con lo siguiente: 

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

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


    Solución alternativa:

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

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

    Es posible que no puedas agregar un clúster de usuario nuevo si el de administrador tiene una configuración de balanceador de cargas de MetalLB.

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


    Solución alternativa:

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

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

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

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

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


    Solución alternativa:

    Para evitar la verificació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 a 1.12.1

    Grafana en el clúster de administrador no puede llegar 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 VMware. Proviene de una discrepancia entre los certificados del cliente de pushprox en los clústeres de usuarios y la lista de entidades permitidas en el servidor pushprox del clúster de administrador. El síntoma es pushprox-client en clústeres de usuario que imprimen registros de error como el siguiente:

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

    Solución alternativa:
    Otro 1.11.3

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

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

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

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


    Solución alternativa:

    Vuelve a ejecutar el comando con --skip-validation.
    Registro y supervisión 1.11, 1.12, 1.13, 1.14, 1.15

    Error de Cloud Audit Logging debido al permiso denegado

    Anthos Cloud Audit Logging necesita una configuración de permisos especial que, por el momento, solo se realiza de forma automática para los clústeres de usuario a través de GKE Hub. Se recomienda tener al menos un clúster de usuario que use el mismo ID del proyecto y la misma cuenta de servicio que el clúster de administrador para los registros de auditoría en la nube, de modo que el clúster tenga el permiso adecuado que necesita.

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


    Solución alternativa:
    Operación, seguridad 1.11

    gkectl diagnose reprobando errores en los certificados

    Si tu estación de trabajo no tiene acceso a los nodos trabajadores del clúster de usuario, se producirán 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, se mostrarán 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, 1.13

    /var/log/audit/ llena el espacio en el disco en la estación de trabajo de administrador

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

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

    A partir de Anthos v1.8, la imagen de Ubuntu se endurece con la comparativa de CIS de nivel 2. Además, una de las reglas de cumplimiento, “4.1.2.2, Garantiza que los registros de auditoría no se borren automáticamente”, garantiza la configuración auditada de 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-1.11.3, 1.12.0-1.12.2, 1.13.0

    NetworkGatewayGroup Conflictos de IP flotantes con dirección de 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, kubelet puede vincularse por error a una dirección IP flotante asignada al nodo y, luego, informarlo como una dirección de nodo en node.status.addresses. El webhook de validación compara las direcciones IP flotantes de NetworkGatewayGroup con todas las node.status.addresses del clúster y lo ve como un conflicto.


    Solución alternativa:

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

    1. Guarda la configuración del webhook para que 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. Vuelva a aplicar la configuración original del webhook: 
      
kubectl -n kube-system apply -f webhook-config.yaml
    Instalación, actualizaciones y actualizaciones 1.10.0-1.10.2

    Crear o actualizar 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 pasa a 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 los clústeres de Anthos alojados en VMware intentan 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 se puede priorizar 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 de creación del clúster de administrador es la dirección IP de transmisión, ejecuta el siguiente comando en la VM del plano de control del clúster de administrador: 
      
ip addr add ${ADMIN_CONTROL_PLANE_NODE_IP}/32 dev ens192
      Esto creará una línea sin una dirección de emisión y desbloqueará el proceso de inicio. Después de desbloquear la secuencia de comandos de inicio, ejecuta el siguiente comando para quitar esta línea agregada: 
      
ip addr del ${ADMIN_CONTROL_PLANE_NODE_IP}/32 dev ens192
    • Sin embargo, si el motivo del tiempo de espera de creación del clúster de administrador se debe a 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 recrea 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 use la imagen COS se perderá cuando se actualice el clúster o se realice la reparación de la instancia principal del administrador

    DataDisk no se puede activar de forma correcta 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 del administrador o se repare la instancia principal. (el clúster de administrador que usa la imagen de COS es una función de vista previa)


    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 llave SSH del clúster de administrador y SSH en el nodo de la instancia principal de administrador. El resultado de df -h contiene /dev/sdb1 98G 209M 93G 1% /opt/data. Y el resultado de lsblk contiene -sdb1 8:17 0 100G 0 part /opt/data
    Sistema operativo 1.10

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

    En la versión 1.10.0 de los clústeres de Anthos alojados en VMware, las resoluciones de nombre en Ubuntu se enrutan a la escucha local resuelta por el sistema en 127.0.0.53 de forma predeterminada. El motivo es que, en la imagen de Ubuntu 20.04 que se usa en la versión 1.10.0, /etc/resolv.conf está vinculado con un archivo sym a /run/systemd/resolve/stub-resolv.conf, que apunta al stub de DNS de 127.0.0.53.

    Como resultado, la resolución de nombres de DNS de localhost se niega a verificar los servidores DNS ascendentes (especificados en /run/systemd/resolve/resolv.conf) en busca de 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 en el archivo de configuración del clúster de usuario para incluir los dominios.

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

    Por lo tanto, si no configuraste este campo antes de la creación del clúster, debes establecer una conexión SSH en los nodos y omitir el stub que resuelve el sistema local. 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 resolver este problema con este paso manual.

    Esta solución no se conserva durante las recreaciones de VM. Debes volver a aplicar esta solución alternativa cada vez que se vuelvan a crear las VM.
    Instalación, sistema operativo 1.10

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

    Los clústeres de Anthos alojados en VMware especifican una subred dedicada para la dirección IP del puente de Docker que usa --bip=169.254.123.1/24, de modo que no reserve la subred 172.17.0.1/16 predeterminada. Sin embargo, en la versión 1.10.0, hay un error en la imagen de SO de Ubuntu con el que se ignoraba la configuración personalizada de Docker.

    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 direcciones IP si ya tienes una carga de trabajo en ejecución dentro de ese rango de direcciones IP.


    Solución alternativa:

    A fin de solucionar este problema, debes cambiar el nombre del siguiente archivo de configuración de 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 persiste durante las recreaciones de VM. Debes volver a aplicar esta solución alternativa cada vez que se vuelvan a crear las VM.
    Revisiones y actualizaciones 1.11

    La preparación está bloqueada y se actualizó a la versión 1.11.

    En la versión 1.11.0 de los clústeres de Anthos alojados en VMware, hay cambios en la definición de 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 se comienzan a medir según su esquema. En especial, las especificaciones resourceAttrOverride y storageSizeOverride en el recurso personalizado stackdriver deben tener un tipo de string en los valores de las solicitudes y los límites de tamaño de CPU, memoria y almacenamiento.

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

    No es necesario que realice ninguna acción si no tiene una lógica adicional que aplique o edite los recursos personalizados afectados. El proceso de actualización de los clústeres de Anthos alojados en VMware se encargará de la migración de los recursos afectados y mantendrá sus especificaciones existentes después del cambio de nombre del grupo.

    Sin embargo, si ejecutas alguna lógica que aplique o edite los recursos afectados, se debe prestar especial atención. Primero, se debe hacer referencia a ella con el nuevo nombre del 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 del 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 aplicaciones y las modificaciones no surtirán efecto y es posible que generen 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 ves los errores anteriores, significa que ya había un tipo no compatible con 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 anterior del grupo 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 string
    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

    Las VM de COS no muestran IP cuando las VM se mueven a través del cierre incorrecto del host

    Cuando hay un error en un servidor ESXi y la función de alta disponibilidad de vCenter se habilita para el servidor, todas las VMs del servidor ESXi con errores activan el mecanismo de vMotion y se mueven a otro servidor ESXi normal. Las VMs migradas de COS perderán sus IP.

    Solución alternativa:

    Reiniciar la VM
    Si necesitas asistencia adicional, comunícate con el equipo de Atención al cliente de Google.