Problemas conocidos de GKE en Bare Metal

En esta página, se enumeran todos los problemas conocidos de Google Distributed Cloud Virtual for Bare Metal. Para filtrar los problemas conocidos por versión o categoría del producto, selecciona los filtros en los siguientes menús desplegables.

Selecciona tu GDCV para la versión de Bare Metal:

Selecciona la categoría del problema:

También puedes buscar tu problema de la siguiente manera:

Categoría Versiones identificadas Problema y solución alternativa
Restablecimiento/eliminación 1.29.0

No se pudo restablecer el clúster de usuario cuando se intentaba borrar el espacio de nombres

Cuando se ejecuta bmctl reset cluster -c ${USER_CLUSTER}, el comando no borra el espacio de nombres del clúster de usuario después de que finalicen todos los trabajos relacionados. El espacio de nombres del clúster de usuario está atascado en el estado Terminating. Al final, se agota el tiempo de espera del restablecimiento del clúster y se muestra un error.

Solución alternativa:

Para quitar el espacio de nombres y completar el restablecimiento del clúster de usuario, sigue estos pasos:

  1. Borra el Pod metrics-server del clúster de administrador:
    kubectl delete pods -l k8s-app=metrics-server \
        -n gke-managed-metrics-server --kubeconfig ADMIN_KUBECONFIG_PATH
    
    En este caso, el Pod metrics-server evita la eliminación del espacio de nombres del clúster.
  2. En el clúster de administrador, fuerza la eliminación del finalizador del espacio de nombres del clúster de usuario:
    kubectl get ns ${USER_CLUSTER_NAMESPACE} -ojson | \
        jq '.spec.finalizers = []' | \
        kubectl replace --raw "/api/v1/namespaces/${USER_CLUSTER_NAMESPACE}/finalize" -f -
    
    Una vez que se quita el finalizador, se quita el espacio de nombres del clúster y se completa el restablecimiento del clúster.
Configuración, instalación, seguridad 1.16.0 a 1.16.7 y de 1.28.0 a 1.28.400

Falta un nodeSelector en la implementación de la autorización binaria

Si habilitaste la autorización binaria para GKE en Bare Metal y usas una versión de 1.16.0 a 1.16.7 o de 1.28.0 a 1.28.400, es posible que tengas un problema relacionado con dónde están programados los Pods para la función. En estas versiones, a la implementación de la autorización binaria le falta un nodeSelector, por lo que los Pods de la función se pueden programar en nodos trabajadores en lugar de nodos del plano de control. Este comportamiento no provoca que falle nada, pero no está previsto.

Solución alternativa:

Para todos los clústeres afectados, completa los siguientes pasos:

  1. Abre el archivo de implementación de Autorización Binaria:
    kubectl edit -n binauthz-system deployment binauthz-module-deployment
  2. Agrega el siguiente nodeSelector al bloque spec.template.spec:
  3.       nodeSelector:
            node-role.kubernetes.io/control-plane: ""
    
  4. Guarda los cambios.

Después de guardar el cambio, los Pods se vuelven a implementar solo en los nodos del plano de control. Esta corrección debe aplicarse después de cada actualización.

Revisiones y actualizaciones 1.28.0, 1.28.100, 1.28.200, 1.28.300

Se produjo un error cuando se actualizaba un clúster a 1.28.0-1.28.300

Actualizar los clústeres creados antes de la versión 1.11.0 a las versiones 1.28.0 a 1.28.300 puede hacer que el Pod del implementador del controlador de ciclo de vida entre en un estado de error durante la actualización. Cuando esto sucede, los registros del Pod del implementador del controlador de ciclo de vida tienen un mensaje de error similar al siguiente:

"inventorymachines.baremetal.cluster.gke.io\" is invalid: status.storedVersions[0]: Invalid value: \"v1alpha1\": must appear in spec.versions

Solución alternativa:

Este problema se solucionó en la versión 1.28.400. Actualiza a la versión 1.28.400 o una versión posterior para resolver el problema.

Si no puedes actualizar, ejecuta los siguientes comandos para resolver el problema:

kubectl patch customresourcedefinitions/nodepoolclaims.baremetal.cluster.gke.io \
    --subresource status --type json \
    --patch='[{ "op": "replace", "path": "/status/storedVersions", "value": ["v1"]}]'

kubectl patch customresourcedefinitions/machineclasses.baremetal.cluster.gke.io \
    --subresource status --type json \
    --patch='[{ "op": "replace", "path": "/status/storedVersions", "value": ["v1"]}]'

kubectl patch customresourcedefinitions/inventorymachines.baremetal.cluster.gke.io \
    --subresource status --type json \
    --patch='[{ "op": "replace", "path": "/status/storedVersions", "value": ["v1"]}]'
Registro y supervisión 1.13.7, 1.14, 1.15, 1.16, 1.28

Se muestra un ID del proyecto incorrecto en el Explorador de registros

A veces, los registros de clústeres o contenedores se etiquetan con un ID del proyecto diferente en resource.labels.project_id en el Explorador de registros.

Esto puede ocurrir cuando el clúster está configurado para usar la observabilidad PROJECT_ONE, que se establece en el campo clusterOperations.projectID de la configuración del clúster. Sin embargo, el cloudOperationsServiceAccountKeyPath en la configuración tiene una clave de cuenta de servicio del proyecto PROJECT_TWO.

En esos casos, todos los registros se enrutan a PROJECT_ONE, pero resource.labels.project_id está etiquetado como PROJECT_TWO.

Solución alternativa:

Usa una de las siguientes opciones para resolver el problema:

  • Usa una cuenta de servicio del mismo proyecto de destino.
  • Cambia project_id en el archivo JSON de claves de la cuenta de servicio por el proyecto actual.
  • Cambia project_id directamente en el filtro de registros del Explorador de registros.
Herramientas de redes 1.29.0

Degradación del rendimiento de los clústeres que usan el balanceo de cargas en paquetes con BGP

Para los clústeres de la versión 1.29.0 que usan balanceo de cargas en paquetes con BGP, el rendimiento del balanceo de cargas puede disminuir a medida que la cantidad total de objetos Service del tipo LoadBalancer se acerca a 2,000. A medida que se degrada el rendimiento, los servicios creados recientemente tardan mucho tiempo en conectarse o los clientes no pueden conectarse a ellos. Los Services existentes continúan funcionando, pero no controlan los modos de falla, como la pérdida de un nodo del balanceador de cargas, de manera efectiva. Estos problemas del servicio ocurren cuando la Deployment de ang-controller-manager finaliza debido a la falta de memoria.

Si tu clúster se ve afectado por este problema, no se puede acceder a los servicios del clúster, no están en buen estado y la Deployment ang-controller-manager se encuentra en CrashLoopBackOff. Cuando se enumeran los objetos Deployment de ang-controller-manager, la respuesta es similar a la siguiente:

ang-controller-manager-79cdd97b88-9b2rd   0/1    CrashLoopBackOff   639 (59s ago)   2d10h   10.250.210.152   vm-bgplb-centos4-n1-02   <none>   <none>

ang-controller-manager-79cdd97b88-r6tcl   0/1   CrashLoopBackOff   620 (4m6s ago)   2d10h   10.250.202.2     vm-bgplb-centos4-n1-11   <none>   <none>

Solución alternativa

Como solución alternativa, puedes aumentar el límite de recursos de memoria del Deployment ang-controller-manager en 100 MiB y quitar el límite de CPU:

kubectl edit deployment ang-controller-manager -n kube-system --kubeconfig ADMIN_KUBECONFIG

Después de realizar los cambios y cerrar el editor de forma correcta, deberías ver el siguiente resultado:

deployment.apps/ang-controller-manager edited

Para verificar que se hayan aplicado los cambios, inspecciona el manifiesto de ang-controller-manager en el clúster:

kubectl get deployment ang-controller-manager \
   -n kube-system \
   -o custom-columns=NAME:.metadata.name,CPU_LIMITS:.spec.template.spec.containers[*].resources.limits.cpu,MEMORY_LIMITS:.spec.template.spec.containers[*].resources.limits.memory \
   --kubeconfig ADMIN_KUBECONFIG

La respuesta debería ser similar a la siguiente:

NAME                     CPU_LIMITS   MEMORY_LIMITS
ang-controller-manager   <none>       400Mi
Instalación, actualizaciones, copias de seguridad y restablecimiento 1.28.0, 1.28.100

Los problemas de conectividad del extremo gcr.io de Container Registry pueden bloquear las operaciones del clúster

Varias operaciones de clúster para clústeres de administrador crean un clúster de arranque. Antes de crear un clúster de arranque, bmctl realiza una verificación de accesibilidad de Google Cloud desde la estación de trabajo de administrador. Esta verificación puede fallar debido a problemas de conectividad con el extremo de Container Registry, gcr.io, y es posible que veas un mensaje de error como el siguiente:

        system checks failed for bootstrap machine: GCP reachability check failed: failed to reach url https://gcr.io: Get "https://cloud.google.com/artifact-registry/": net/http: request canceled (Client.Timeout exceeded while awaiting headers)
        

Solución alternativa

Para solucionar este problema, vuelve a intentar la operación con la marca --ignore-validation-errors.

Herramientas de redes 1.15, 1.16

GKE Dataplane V2 no es compatible con algunos controladores de almacenamiento

Los clústeres de GKE alojados en Bare Metal usan GKE Dataplane V2, que no es compatible con algunos proveedores de almacenamiento. Es posible que tengas problemas con Pods o volúmenes NFS atascados. Esto es muy probable si tienes cargas de trabajo que usan volúmenes ReadWriteMany respaldados por controladores de almacenamiento que son susceptibles a este problema:

  • Robin.io
  • Portworx (sharedv4 volúmenes de servicio)
  • csi-nfs

Esta lista no es exhaustiva.

Solución alternativa

Hay una solución a este problema disponible para las siguientes versiones de Ubuntu:

  • 20.04 LTS: Usa una imagen de kernel 5.4.0 posterior a linux-image-5.4.0-166-generic
  • 22.04 LTS: Usa una imagen de kernel 5.15.0 posterior a linux-image-5.15.0-88-generic o el kernel HWE 6.5.

Si no usas una de estas versiones, comunícate con el equipo de Atención al cliente de Google.

Registro y supervisión 1.15, 1.16, 1.28

kube-state-metrics OOM en un clúster grande

Es posible que notes que kube-state-metrics o el Pod gke-metrics-agent que existe en el mismo nodo que kube-state-metrics no tienen memoria (OOM).

Esto puede ocurrir en clústeres con más de 50 nodos o con muchos objetos de Kubernetes.

Solución alternativa

A fin de resolver este problema, actualiza la definición de recurso personalizado stackdriver para usar la puerta de funciones ksmNodePodMetricsOnly. Esta puerta de funciones garantiza que solo se exponga una pequeña cantidad de métricas críticas.

Para utilizar esta solución alternativa, completa los siguientes pasos:

  1. Verifica la definición de recurso personalizado stackdriver para las puertas de funciones disponibles:
    kubectl -n kube-system get crd stackdrivers.addons.gke.io -o yaml | grep ksmNodePodMetricsOnly
            
  2. Actualiza la definición del recurso personalizado stackdriver para habilitar ksmNodePodMetricsOnly:
    kind:stackdriver
    spec:
      featureGates:
         ksmNodePodMetricsOnly: true
            
Instalación 1.28.0-1.28.200

La verificación previa falla en RHEL 9.2 debido a que faltan iptables

Cuando instalas un clúster en el sistema operativo Red Hat Enterprise Linux (RHEL) 9.2, es posible que experimentes una falla debido a que falta el paquete iptables. El error se produce durante las comprobaciones preliminares y activa un mensaje de error similar al siguiente:

'check_package_availability_pass': "The following packages are not available: ['iptables']"
        

RHEL 9.2 está en vista previa para GKE en la versión 1.28 de Bare Metal.

Solución alternativa

Para omitir el error de comprobación previa, configura spec.bypassPreflightCheck como true en el recurso del clúster.

Operación 1.10, 1.11, 1.12, 1.13, 1.14, 1.15, 1.16

Conmutación por error lenta de MetalLB a gran escala

Cuando MetalLB controla una gran cantidad de servicios (más de 10,000), la conmutación por error puede tardar más de una hora. Esto sucede porque MetalLB usa una cola limitada por frecuencia que, cuando se encuentra en escala alta, puede tardar un poco en llegar al servicio que debe conmutarse por error.

Solución alternativa

Actualiza tu clúster a la versión 1.28 o posterior. Si no puedes hacerlo, editar el servicio de forma manual (por ejemplo, agregar una anotación) hará que la conmutación por error se realice con mayor rapidez.

Operación 1.16.0-1.16.6, 1.28.0-1/28.200

Si el proxy está habilitado, se deben configurar las variables de entorno en la estación de trabajo de administrador

bmctl check cluster puede fallar debido a fallas del proxy si no tienes definidas las variables de entorno HTTPS_PROXY y NO_PROXY en la estación de trabajo de administrador. El comando bmctl informa un mensaje de error que indica que no se pudieron llamar a algunos servicios de Google, como en el siguiente ejemplo:

[2024-01-29 23:49:03+0000] error validating cluster config: 2 errors occurred:
        * GKERegister check failed: 2 errors occurred:
        * Get "https://gkehub.googleapis.com/v1beta1/projects/baremetal-runqi/locations/global/memberships/ci-ec1a14a903eb1fc": oauth2: cannot fetch token: Post "https://oauth2.googleapis.com/token": dial tcp 108.177.98.95:443: i/o timeout
        * Post "https://cloudresourcemanager.googleapis.com/v1/projects/baremetal-runqi:testIamPermissions?alt=json&prettyPrint=false": oauth2: cannot fetch token: Post "https://oauth2.googleapis.com/token": dial tcp 74.125.199.95:443: i/o timeout

Solución alternativa

Configura HTTPS_PROXY y NO_PROXY de forma manual en la estación de trabajo de administrador.

Revisiones y actualizaciones 1.28.0-gke.435

Las actualizaciones a la versión 1.28.0-gke.435 pueden fallar si audit.log tiene la propiedad incorrecta

En algunos casos, el archivo /var/log/apiserver/audit.log en los nodos del plano de control tiene la propiedad del grupo y el usuario establecida en root. Esta configuración de propiedad de archivos provoca fallas de actualización para los nodos del plano de control cuando se actualiza un clúster de la versión 1.16.x a la versión 1.28.0-gke.435. Este problema solo se aplica a los clústeres creados antes de la versión 1.11 y que tenían inhabilitados los Registros de auditoría de Cloud. Los Registros de auditoría de Cloud están habilitados de forma predeterminada para los clústeres de la versión 1.9 y posteriores.

Solución alternativa

Si no puedes actualizar tu clúster a la versión 1.28.100-gke.146, sigue estos pasos como solución alternativa para completar la actualización del clúster a la versión 1.28.0-gke.435:

  • Si los registros de auditoría de Cloud están habilitados, quita el archivo /var/log/apiserver/audit.log.
  • Si los Registros de auditoría de Cloud están inhabilitados, cambia la propiedad de /var/log/apiserver/audit.log a la misma que la del directorio superior, /var/log/apiserver.
Herramientas de redes, actualizaciones y actualizaciones 1.28.0-gke.435

MetalLB no asigna direcciones IP a servicios VIP

GKE en Bare Metal usa MetalLB para el balanceo de cargas en paquetes. En la versión 1.28.0-gke.435 de GKE en Bare Metal, el paquete de MetalLB se actualiza a la versión 0.13, que incluye compatibilidad con CRD para IPAddressPools. Sin embargo, debido a que ConfigMaps permite cualquier nombre para una IPAddressPool, los nombres del grupo tenían que convertirse en un nombre que cumpliera con Kubernetes. Para ello, agrega un hash al final del nombre de IPAddressPool. Por ejemplo, un IPAddressPool con el nombre default se convierte en un nombre como default-qpvpd cuando actualizas tu clúster a la versión 1.28.0-gke.435.

Dado que MetalLB requiere un nombre específico de IPPool para la selección, la conversión de nombres evita que MetalLB seleccione un grupo y asigne direcciones IP. Por lo tanto, los servicios que usan metallb.universe.tf/address-pool como anotación para seleccionar el grupo de direcciones para una dirección IP ya no recibirán una dirección IP del controlador de MetalLB.

Este problema se corrigió en la versión 1.28.100-gke.146 de GKE en Bare Metal.

Solución alternativa

Si no puedes actualizar tu clúster a la versión 1.28.100-gke.146, sigue estos pasos como solución alternativa:

  1. Obtén el nombre convertido de IPAddressPool:
    kubectl get IPAddressPools -n kube-system
    
  2. Actualiza el servicio afectado para establecer la anotación metallb.universe.tf/address-pool en el nombre convertido con el hash.

    Por ejemplo, si el nombre IPAddressPool se convirtió de default a un nombre como default-qpvpd, cambia la anotación metallb.universe.tf/address-pool: default del Service a metallb.universe.tf/address-pool: default-qpvpd.

El hash que se usa en la conversión de nombres es determinista, por lo que la solución alternativa es persistente.

Revisiones y actualizaciones 1.14, 1.15, 1.16, 1.28, 1.29

Pods huérfanos después de actualizar a la versión 1.14.x

Cuando actualizas GKE en clústeres de Bare Metal a la versión 1.14.x, algunos recursos de la versión anterior no se borran. En particular, es posible que veas un conjunto de Pods huérfanos como el siguiente:

capi-webhook-system/capi-controller-manager-xxx
capi-webhook-system/capi-kubeadm-bootstrap-controller-manager-xxx

Estos objetos huérfanos no afectan la operación del clúster directamente, pero te sugerimos que los quites.

  • Ejecuta los siguientes comandos para quitar los objetos huérfanos:
    kubectl delete ns capi-webhook-system
    kubectl delete validatingwebhookconfigurations capi-validating-webhook-configuration
    kubectl delete mutatingwebhookconfigurations capi-mutating-webhook-configuration
    

Este problema se corrigió en la versión 1.15.0 y posteriores de GKE en Bare Metal.

Instalación 1.14

La creación del clúster se detuvo en el trabajo machine-init

Si intentas instalar la versión 1.14.x de Google Distributed Cloud Virtual for Bare Metal, es posible que experimentes una falla debido a los trabajos machine-init, similar al siguiente resultado de ejemplo:

"kubeadm join" task failed due to:
error execution phase control-plane-join/etcd: error creating local etcd static pod manifest file: etcdserver: re-configuration failed due to not enough started members

"kubeadm reset" task failed due to:
panic: runtime error: invalid memory address or nil pointer dereference

Solución alternativa:

Quita el miembro obsoleto de etcd que hace que el trabajo machine-init falle. Completa los siguientes pasos en un nodo del plano de control en funcionamiento:

  1. Enumera los miembros de etcd existentes:
    etcdctl --key=/etc/kubernetes/pki/etcd/peer.key \
      --cacert=/etc/kubernetes/pki/etcd/ca.crt \
      --cert=/etc/kubernetes/pki/etcd/peer.crt \
      member list
    
    Busca miembros con un estado de unstarted, como se muestra en el siguiente resultado de ejemplo:
    5feb7ac839625038, started, vm-72fed95a, https://203.0.113.11:2380, https://203.0.113.11:2379, false
    99f09f145a74cb15, started, vm-8a5bc966, https://203.0.113.12:2380, https://203.0.113.12:2379, false
    bd1949bcb70e2cb5, unstarted, , https://203.0.113.10:2380, , false
    
  2. Quita el miembro de etcd con errores:
    etcdctl --key=/etc/kubernetes/pki/etcd/peer.key \
      --cacert=/etc/kubernetes/pki/etcd/ca.crt \
      --cert=/etc/kubernetes/pki/etcd/peer.crt \
      member remove MEMBER_ID
    
    Reemplaza MEMBER_ID por el ID del miembro de etcd con errores. En el resultado de ejemplo anterior, este ID es bd1949bcb70e2cb5.

    En el siguiente resultado de ejemplo, se muestra que se quitó el miembro:
    Member bd1949bcb70e2cb5 removed from cluster  9d70e2a69debf2f
    
    .
Herramientas de redes 1.28.0

A Cilium-operator le faltan los permisos list y watch del nodo

En Cilium 1.13, los permisos de ClusterRole cilium-operator son incorrectos. Faltan los permisos list y watch del nodo. cilium-operator no inicia los recolectores de elementos no utilizados, lo que genera los siguientes problemas:

  • Fuga de recursos de cilio.
  • Las identidades inactivas no se quitan de los mapas de políticas de BFP.
  • Los mapas de políticas podrían alcanzar el límite de 16,000.
    • No se pueden agregar entradas nuevas.
    • La aplicación de NetworkPolicy es incorrecta.
  • Es posible que las identidades alcancen el límite de 64,000.
    • No se pueden crear nuevos Pods.

Un operador al que le faltan los permisos de nodo informa el siguiente mensaje de registro de ejemplo:

2024-01-02T20:41:37.742276761Z level=error msg=k8sError error="github.com/cilium/cilium/operator/watchers/node.go:83: Failed to watch *v1.Node: failed to list *v1.Node: nodes is forbidden: User \"system:serviceaccount:kube-system:cilium-operator\" cannot list resource \"nodes\" in API group \"\" at the cluster scope" subsys=k8s

El agente de Cilium informa un mensaje de error cuando no puede insertar una entrada en un mapa de políticas, como en el siguiente ejemplo:

level=error msg="Failed to add PolicyMap key" bpfMapKey="{6572100 0 0 0}" containerID= datapathPolicyRevision=0 desiredPolicyRevision=7 endpointID=1313 error="Unable to update element for Cilium_policy_01313 map with file descriptor 190: the map is full, please consider resizing it. argument list too long" identity=128 ipv4= ipv6= k8sPodName=/ port=0 subsys=endpoint

Solución alternativa:

Quita las identidades de Cilium y, luego, agrega los permisos de ClusterRole que faltan al operador:

  1. Quita los objetos CiliumIdentity existentes:
    kubectl delete ciliumid –-all
    
  2. Edita el objeto ClusterRole cilium-operator:
    kubectl edit clusterrole cilium-operator
    
  3. Agrega una sección para nodes que incluya los permisos faltantes, como se muestra en el siguiente ejemplo:
    - apiGroups:
      - ""
      resources:
      - nodes
      verbs:
      - get
      - list
      - watch
    
  4. Guarda el editor y ciérralo. El operador detecta de forma dinámica el cambio de permiso. No necesitas reiniciar el operador de forma manual.
Revisiones y actualizaciones 1.15.0-1.15.7, 1.16.0-1.16.3

Se detectó un problema transitorio durante la comprobación preliminar

Es posible que una de las tareas de verificación de estado de kubeadm que se ejecuta durante la verificación previa de la actualización falle y muestre el siguiente mensaje de error:

[ERROR CreateJob]: could not delete Job \"upgrade-health-check\" in the namespace \"kube-system\": jobs.batch \"upgrade-health-check\" not found

Este error se puede ignorar de forma segura. Si encuentras este error que bloquea la actualización, vuelve a ejecutar el comando de actualización.

Si observas este error cuando ejecutas la comprobación preliminar con el comando bmctl preflightcheck, esta falla no bloquea nada. Puedes volver a ejecutar la comprobación preliminar para obtener la información precisa.


Solución alternativa:

Vuelve a ejecutar el comando de actualización o, si se encuentra durante bmctl preflightcheck, vuelve a ejecutar el comando preflightcheck.

Operación 1.14, 1.15.0-1.15.7, 1.16.0-1.16.3, 1.28.0

La verificación de estado periódica de la red falla cuando se reemplaza o quita un nodo.

Este problema afecta a los clústeres que realizan verificaciones periódicas de estado de la red después de que se reemplaza o quita un nodo. Si tu clúster se somete a verificaciones de estado periódicas, estas últimas generarán errores después del reemplazo o eliminación de un nodo, ya que el ConfigMap del inventario de red no se actualiza una vez creado.


Solución alternativa:

La solución recomendada es borrar el ConfigMap del inventario y la verificación periódica de estado de la red. El operador del clúster los vuelve a crear de forma automática con la información más actualizada.

Para los clústeres 1.14.x, ejecuta los siguientes comandos:

kubectl delete configmap \
    $(kubectl get cronjob CLUSTER_NAME-network -o=jsonpath='{.spec.jobTemplate.spec.template.spec.volumes[?(@name=="inventory-config-volume")].configMap.name}' \
    -n CLUSTER_NAMESPACE) \
    -n CLUSTER_NAMESPACE \
    --kubeconfig ADMIN_KUBECONFIG
kubectl delete healthchecks.baremetal.cluster.gke.io \
    CLUSTER_NAME-network -n CLUSTER_NAMESPACE \
    --kubeconfig ADMIN_KUBECONFIG

Para los clústeres 1.15.0 y posteriores, ejecuta los siguientes comandos:

kubectl delete configmap \
    $(kubectl get cronjob bm-system-network -o=jsonpath='{.spec.jobTemplate.spec.template.spec.volumes[?(@.name=="inventory-config-volume")]configMap.name}' \
    -n CLUSTER_NAMESPACE) \
    -n CLUSTER_NAMESPACE \
    --kubeconfig ADMIN_KUBECONFIG
kubectl delete healthchecks.baremetal.cluster.gke.io \
    bm-system-network -n CLUSTER_NAMESPACE \
    --kubeconfig ADMIN_KUBECONFIG
Herramientas de redes 1.14, 1.15, 1.16.0 a 1.16.2

La puerta de enlace de red para GDC no puede aplicar tu configuración cuando el nombre del dispositivo contiene un punto.

Si tienes un dispositivo de red que incluye un carácter de punto (.) en el nombre, como bond0.2, la puerta de enlace de red para GDC trata el punto como una ruta de acceso en el directorio cuando ejecuta sysctl para hacer cambios. Cuando la puerta de enlace de red para GDC comprueba si la detección de direcciones duplicadas (DAD) está habilitada, la verificación puede fallar y, por lo tanto, no se conciliará.

El comportamiento es diferente entre las versiones del clúster:

  • 1.14 y 1.15: Este error solo existe cuando usas direcciones IP flotantes IPv6. Si no usas direcciones IP flotantes IPv6, no notarás este problema cuando los nombres de tus dispositivos contengan un punto.
  • 1.16.0 - 1.16.2: Este error siempre existe cuando los nombres de los dispositivos contienen un punto.

Solución alternativa:

Actualiza tu clúster a la versión 1.16.3 o posterior.

Como solución alternativa hasta que puedas actualizar los clústeres, quita el punto (.) del nombre del dispositivo.

Actualizaciones, herramientas de redes, seguridad 1.16.0

Las actualizaciones a la versión 1.16.0 fallan cuando seccomp está inhabilitado

Si seccomp está inhabilitado para tu clúster (spec.clusterSecurity.enableSeccomp establecido en false), fallará la actualización a la versión 1.16.0.

La versión 1.16 de GKE en Bare Metal usa la versión 1.27 de Kubernetes. En Kubernetes 1.27.0 y versiones posteriores, la función para configurar perfiles de seccomp tiene disponibilidad general y ya no usa una puerta de funciones. Este cambio de Kubernetes hace que las actualizaciones a la versión 1.16.0 fallen cuando seccomp está inhabilitado en la configuración del clúster. Este problema se solucionó en los clústeres de la versión 1.16.1 y de versiones posteriores. Si el campo cluster.spec.clusterSecurity.enableSeccomp está configurado como false, puedes actualizar a la versión 1.16.1 o una posterior.

Los clústeres con spec.clusterSecurity.enableSeccomp sin establecer o establecido como true no se ven afectados.

Instalación y funcionamiento 1.11, 1.12, 1.13, 1.14, 1.15.0-1.15.5, 1.16.0-1.16.1

Los metadatos de containerd pueden dañarse después del reinicio cuando se activa /var/lib/containerd.

Si activaste de forma opcional /var/lib/containerd, los metadatos de containerd pueden dañarse después de un reinicio. Los metadatos dañados pueden hacer que los Pods fallen, incluidos los Pods críticos para el sistema.

Para verificar si este problema te afecta, comprueba si se definió una activación opcional en /etc/fstab para /var/lib/containerd/ y si tiene nofail en las opciones de activación.


Solución alternativa:

Quita la opción de activación nofail en /etc/fstab o actualiza tu clúster a la versión 1.15.6 o posterior.

Operación 1.13, 1.14, 1.15, 1.16, 1.28

Limpia los Pods inactivos del clúster

Es posible que veas Pods administrados por un Deployment (ReplicaSet) en un estado Failed y con el estado TaintToleration. Estos Pods no usan recursos del clúster, pero deben borrarse.

Puedes usar el siguiente comando de kubectl para enumerar los Pods que puedes limpiar:

kubectl get pods –A | grep TaintToleration

En el siguiente resultado de ejemplo, se muestra un Pod con el estado TaintToleration:

kube-system    stackdriver-metadata-agent-[...]    0/1    TaintToleration    0

Solución alternativa:

En cada Pod con los síntomas descritos, verifica el ReplicaSet al que pertenece el Pod. Si el ReplicaSet está satisfecho, puedes borrar los Pods:

  1. Obtén el ReplicaSet que administra el Pod y busca el valor ownerRef.Kind:
    kubectl get pod POD_NAME -n NAMESPACE -o yaml
    
  2. Obtén el ReplicaSet y verifica que el status.replicas sea el mismo que spec.replicas:
    kubectl get replicaset REPLICA_NAME -n NAMESPACE -o yaml
    
  3. Si los nombres coinciden, borra el Pod:
    kubectl delete pod POD_NAME -n NAMESPACE.
    
Actualizaciones 1.16.0

etcd-events puede bloquearse cuando se actualiza a la versión 1.16.0

Cuando actualizas un clúster existente a la versión 1.16.0, las fallas de Pods relacionadas con etcd-events pueden detener la operación. En particular, el trabajo del nodo de actualización falla para el paso TASK [etcd_events_install : Run etcdevents].

Si te afecta este problema, verás fallas de Pods como las siguientes:

  • El Pod kube-apiserver no se inicia con el siguiente error:
    connection error: desc = "transport: Error while dialing dial tcp 127.0.0.1:2382: connect: connection refused"
    
  • El pod etcd-events no se inicia con el siguiente error:
    Error: error syncing endpoints with etcd: context deadline exceeded
    

Solución alternativa:

Si no puedes actualizar tu clúster a una versión que incluya la corrección, usa la siguiente solución temporal para abordar los errores:

  1. Usa SSH para acceder al nodo del plano de control con los errores informados.
  2. Edita el archivo de manifiesto etcd-events, /etc/kubernetes/manifests/etcd-events.yaml, y quita la marca initial-cluster-state=existing.
  3. Aplica el manifiesto.
  4. La actualización debería continuar.
Herramientas de redes 1.15.0-1.15.2

No se reconoce orderPolicy de CoreDNS

OrderPolicy no se reconoce como un parámetro y no se usa. En cambio, GKE en Bare Metal siempre usa Random.

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


Solución alternativa:

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

  1. Edita la plantilla existente:
    kubectl edit cm -n kube-system coredns-template
    
    Reemplaza el contenido de la plantilla por lo siguiente:
    coredns-template: |-
      .:53 {
        errors
        health {
          lameduck 5s
        }
        ready
        kubernetes cluster.local in-addr.arpa ip6.arpa {
          pods insecure
          fallthrough in-addr.arpa ip6.arpa
        }
    {{- if .PrivateGoogleAccess }}
        import zones/private.Corefile
    {{- end }}
    {{- if .RestrictedGoogleAccess }}
        import zones/restricted.Corefile
    {{- end }}
        prometheus :9153
        forward . {{ .UpstreamNameservers }} {
          max_concurrent 1000
          {{- if ne .OrderPolicy "" }}
          policy {{ .OrderPolicy }}
          {{- end }}
        }
        cache 30
    {{- if .DefaultDomainQueryLogging }}
        log
    {{- end }}
        loop
        reload
        loadbalance
    }{{ range $i, $stubdomain := .StubDomains }}
    {{ $stubdomain.Domain }}:53 {
      errors
    {{- if $stubdomain.QueryLogging }}
      log
    {{- end }}
      cache 30
      forward . {{ $stubdomain.Nameservers }} {
        max_concurrent 1000
        {{- if ne $.OrderPolicy "" }}
        policy {{ $.OrderPolicy }}
        {{- end }}
      }
    }
    {{- end }}
    
Herramientas de redes, operación 1.10, 1.11, 1.12, 1.13, 1.14

Puerta de enlace de red para componentes de GDC expulsados o pendientes debido a la falta de clase de prioridad

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

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

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


Solución alternativa:

Actualiza a la versión 1.15 o posterior.

Como solución a corto plazo, puedes asignar una PriorityClass a la puerta de enlace de red para los componentes de GDC de forma manual. El controlador de GKE en Bare Metal reemplaza estos cambios manuales durante un proceso de conciliación, como durante la actualización de un clúster.

  • Asigna la PriorityClass system-cluster-critical a las implementaciones del controlador de clúster ang-controller-manager y autoscaler.
  • Asigna la PriorityClass system-node-critical al DaemonSet del nodo ang-daemon.
Instalación, actualizaciones y actualizaciones 1.15.0, 1.15.1, 1.15.2

La creación y las actualizaciones del clúster fallan debido a la longitud del nombre del clúster

La creación de clústeres de la versión 1.15.0, 1.15.1 o 1.15.2 o la actualización de clústeres a la versión 1.15.0, 1.15.1 o 1.15.2 falla cuando el nombre del clúster tiene más de 48 caracteres (versión 1.15.0) o 45 caracteres (versión 1.15.1 o 1.15.2). Durante las operaciones de creación y actualización de clústeres, GKE en Bare Metal crea un recurso de verificación de estado con un nombre que incorpora el nombre y la versión del clúster:

  • Para los clústeres de la versión 1.15.0, el nombre del recurso de verificación de estado es CLUSTER_NAME-add-ons-CLUSTER_VER.
  • Para los clústeres de las versiones 1.15.1 o 1.15.2, el nombre del recurso de verificación de estado es CLUSTER_NAME-kubernetes-CLUSTER_VER.

En el caso de los nombres largos de clústeres, el nombre del recurso de verificación de estado supera la restricción de 63 caracteres de Kubernetes para nombres de etiquetas, lo que impide la creación del recurso de verificación de estado. Sin una verificación de estado correcta, la operación del clúster falla.

Para ver si te afecta este problema, usa kubectl describe a fin de verificar el recurso con errores:

kubectl describe healthchecks.baremetal.cluster.gke.io \
    HEALTHCHECK_CR_NAME -n CLUSTER_NAMESPACE \
    --kubeconfig ADMIN_KUBECONFIG

Si este problema te afecta, la respuesta contendrá una advertencia para una ReconcileError como la siguiente:

...
Events:
  Type     Reason          Age                   From                    Message
  ----     ------          ----                  ----                    -------
  Warning  ReconcileError  77s (x15 over 2m39s)  healthcheck-controller  Reconcile error, retrying: 1 error occurred:
           * failed to create job for health check
db-uat-mfd7-fic-hybrid-cloud-uk-wdc-cluster-02-kubernetes-1.15.1: Job.batch
"bm-system-db-uat-mfd7-fic-hybrid-cloud-u24d5f180362cffa4a743" is invalid: [metadata.labels: Invalid
value: "db-uat-mfd7-fic-hybrid-cloud-uk-wdc-cluster-02-kubernetes-1.15.1": must be no more than 63
characters, spec.template.labels: Invalid value:
"db-uat-mfd7-fic-hybrid-cloud-uk-wdc-cluster-02-kubernetes-1.15.1": must be no more than 63 characters]

Solución alternativa

Para desbloquear la actualización o creación del clúster, puedes omitir la verificación de estado. Usa el siguiente comando para aplicar un parche al recurso personalizado de verificación de estado con el estado de aprobación: (status: {pass: true})

kubectl patch healthchecks.baremetal.cluster.gke.io \
    HEALTHCHECK_CR_NAME -n CLUSTER_NAMESPACE \
    --kubeconfig ADMIN_KUBECONFIG --type=merge \
    --subresource status --patch 'status: {pass: true}'
Actualizaciones 1.14, 1.15

Los clústeres de las versiones 1.14.0 y 1.14.1 con funciones de vista previa no se pueden actualizar a la versión 1.15.x.

Si los clústeres de las versiones 1.14.0 y 1.14.1 tienen habilitada una función de vista previa, no se les permitirá actualizar correctamente a la versión 1.15.x. Esto se aplica a las funciones de versión preliminar, como la capacidad de crear un clúster sin kube-proxy, que se habilita con la siguiente anotación en el archivo de configuración del clúster:

preview.baremetal.cluster.gke.io/kube-proxy-free: "enable"

Si te afecta este problema, verás un error como el siguiente durante la actualización del clúster:

[2023-06-20 23:37:47+0000] error judging if the cluster is managing itself:
error to parse the target cluster: error parsing cluster config: 1 error
occurred:

Cluster.baremetal.cluster.gke.io "$cluster-name" is invalid:
Annotations[preview.baremetal.cluster.gke.io/$preview-feature-name]:
Forbidden: preview.baremetal.cluster.gke.io/$preview-feature-name feature
isn't supported in 1.15.1 Anthos Bare Metal version

Este problema se solucionó en los clústeres de la versión 1.14.2 y superiores.


Solución alternativa:

Si no puedes actualizar tus clústeres a la versión 1.14.2 o superior antes de actualizar a la versión 1.15.x, puedes actualizar a la versión 1.15.x directamente mediante un clúster de arranque:

bmctl upgrade cluster --use-bootstrap=true
Operación 1.15

Los clústeres de la versión 1.15 no aceptan direcciones IP flotantes duplicadas.

La puerta de enlace de red para GDC no te permite crear nuevos recursos personalizados NetworkGatewayGroup que contengan direcciones IP en spec.floatingIPs que ya se usen en recursos personalizados NetworkGatewayGroup existentes. Esta regla se aplica mediante un webhook en GKE en los clústeres de Bare Metal versión 1.15.0 y posteriores. Las direcciones IP flotantes duplicadas preexistentes no causan errores. El webhook solo evita la creación de nuevos recursos personalizados NetworkGatewayGroups que contienen direcciones IP duplicadas.

El mensaje de error de webhook identifica la dirección IP en conflicto y el recurso personalizado existente que ya la usa:

IP address exists in other gateway with name default

En la documentación inicial para las funciones de red avanzadas, como la puerta de enlace NAT de salida, no se previenen las direcciones IP duplicadas. Inicialmente, el conciliador reconoció solo el recurso NetworkGatewayGroup llamado default. La puerta de enlace de red para GDC ahora reconoce todos los recursos personalizados NetworkGatewayGroup en el espacio de nombres del sistema. Los recursos personalizados NetworkGatewayGroup existentes se respetan sin modificaciones.


Solución alternativa:

Los errores ocurren solo cuando se crea un nuevo recurso personalizado NetworkGatewayGroup.

Para solucionar el error, haz lo siguiente:

  1. Usa el siguiente comando para enumerar NetworkGatewayGroups recursos personalizados:
    kubectl get NetworkGatewayGroups --kubeconfig ADMIN_KUBECONFIG \
        -n kube-system -o yaml
    
  2. Abre los recursos personalizados NetworkGatewayGroup existentes y quita las direcciones IP flotantes en conflicto (spec.floatingIPs):
    kubectl edit NetworkGatewayGroups --kubeconfig ADMIN_KUBECONFIG \
        -n kube-system RESOURCE_NAME
    
  3. Para aplicar los cambios, cierra y guarda los recursos personalizados editados.
Entorno de ejecución de VM en GDC 1.13.7

Es posible que las VMs no se inicien en los clústeres 1.13.7 que usan un registro privado

Cuando habilitas el entorno de ejecución de VM en GDC en un clúster nuevo o actualizado de la versión 1.13.7 que usa un registro privado, es posible que las VMs que se conectan a la red del nodo o usen una GPU no se inicien de forma correcta. Este problema se debe a que algunos Pods del sistema en el espacio de nombres vm-system obtienen errores de extracción de imágenes. Por ejemplo, si la VM usa la red de nodos, algunos Pods podrían informar errores de extracción de imágenes como los siguientes:

macvtap-4x9zp              0/1   Init:ImagePullBackOff  0     70m

Este problema se corrigió en la versión 1.14.0 y posteriores de GKE en clústeres de Bare Metal.

Solución alternativa

Si no puedes actualizar tus clústeres de inmediato, puedes extraer imágenes de forma manual. Los siguientes comandos extraen la imagen del complemento de la CNI macvtap para la VM y la envían al registro privado:

docker pull \
    gcr.io/anthos-baremetal-release/kubevirt/macvtap-cni:v0.5.1-gke.:21
docker tag \
    gcr.io/anthos-baremetal-release/kubevirt/macvtap-cni:v0.5.1-gke.:21 \
    REG_HOST/anthos-baremetal-release/kubevirt/macvtap-cni:v0.5.1-gke.:21
docker push \
    REG_HOST/anthos-baremetal-release/kubevirt/macvtap-cni:v0.5.1-gke.:21

Reemplaza REG_HOST por el nombre de dominio de un host que duplicas de forma local.

Instalación 1.11, 1.12

Durante la creación del clúster en el clúster de tipo, el pod gke-metric-agent no se inicia

Durante la creación de clústeres en el clúster de similares, el Pod gke-metrics-agent no se inicia debido a un error de extracción de imágenes, como se indica a continuación:

error="failed to pull and unpack image \"gcr.io/gke-on-prem-staging/gke-metrics-agent:1.8.3-anthos.2\": failed to resolve reference \"gcr.io/gke-on-prem-staging/gke-metrics-agent:1.8.3-anthos.2\": pulling from host gcr.io failed with status code [manifests 1.8.3-anthos.2]: 403 Forbidden"

Además, en el registro containerd del clúster de arranque, verás la siguiente entrada:

Sep 13 23:54:20 bmctl-control-plane containerd[198]: time="2022-09-13T23:54:20.378172743Z" level=info msg="PullImage \"gcr.io/gke-on-prem-staging/gke-metrics-agent:1.8.3-anthos.2\" " Sep 13 23:54:21 bmctl-control-plane containerd[198]: time="2022-09-13T23:54:21.057247258Z" level=error msg="PullImage \"gcr.io/gke-on-prem-staging/gke-metrics-agent:1.8.3-anthos.2\" failed" error="failed to pull and unpack image \"gcr.io/gke-on-prem-staging/gke-metrics-agent:1.8.3-anthos.2\": failed to resolve reference \"gcr.io/gke-on-prem-staging/gke-metrics-agent:1.8.3-anthos.2\": pulling from host gcr.io failed with status code [manifests 1.8.3-anthos.2]: 403 Forbidden"

En el Pod, verás el siguiente error “failing to pull”:

gcr.io/gke-on-prem-staging/gke-metrics-agent

Solución alternativa

A pesar de los errores, el proceso de creación del clúster no se bloquea, ya que el propósito del Pod de gke-metrics-agent en el clúster de tipo es facilitar la tasa de éxito de creación de clústeres y realizar seguimientos y supervisión internos. Por lo tanto, puedes ignorar este error.

Solución alternativa

A pesar de los errores, el proceso de creación del clúster no se bloquea, ya que el propósito del Pod de gke-metrics-agent en el clúster de tipo es facilitar la tasa de éxito de creación de clústeres y realizar seguimientos y supervisión internos. Por lo tanto, puedes ignorar este error.

Operación, Herramientas de redes 1.12, 1.13, 1.14, 1.15, 1.16, 1.28

El acceso a un extremo de Service IPv6 hace que falle el nodo LoadBalancer en CentOS o RHEL

Cuando accedes a un Service de pila doble (un Service que tiene extremos IPv4 e IPv6) y usas el extremo IPv6, el nodo LoadBalancer que entrega el Service puede fallar. Este problema afecta a los clientes que usan servicios de pila doble con CentOS o RHEL y una versión de kernel anterior a kernel-4.18.0-372.46.1.el8_6.

Si crees que este problema te afecta, verifica la versión de kernel en el nodo LoadBalancer con el comando uname -a.


Solución alternativa:

Actualiza el nodo LoadBalancer a la versión de kernel kernel-4.18.0-372.46.1.el8_6 o a una versión posterior. Esta versión de kernel está disponible de forma predeterminada en CentOS y RHEL versión 8.6 y posteriores.

Herramientas de redes 1.11, 1.12, 1.13, 1.14.0

Problemas de conectividad intermitentes después de reiniciar el nodo

Después de reiniciar un nodo, es posible que veas problemas de conectividad intermitentes en un servicio NodePort o LoadBalancer. Por ejemplo, es posible que tengas errores intermitentes de protocolo de enlace TLS o de restablecimiento de conexión. Este problema se solucionó para las versiones de clúster 1.14.1 y posteriores.

Para verificar si este problema te afecta, consulta las reglas de reenvío de iptables en los nodos en los que se ejecuta el Pod de backend del Service afectado:

sudo iptables -L FORWARD

Si ves la regla KUBE-FORWARD antes de la regla CILIUM_FORWARD en iptables, es posible que este problema te afecte. En el siguiente resultado de ejemplo, se muestra un nodo en el que existe el problema:

Chain FORWARD (policy ACCEPT)
target                  prot opt source   destination
KUBE-FORWARD            all  --  anywhere anywhere                /* kubernetes forwarding rules */
KUBE-SERVICES           all  --  anywhere anywhere    ctstate NEW /* kubernetes service portals */
KUBE-EXTERNAL-SERVICES  all  --  anywhere anywhere    ctstate NEW /* kubernetes externally-visible service portals */
CILIUM_FORWARD          all  --  anywhere anywhere                /* cilium-feeder: CILIUM_FORWARD */

Solución alternativa:

Reinicia el Pod anetd en el nodo mal configurado. Después de reiniciar el Pod anetd, la regla de reenvío en iptables debería configurarse de forma correcta.

En el siguiente resultado de ejemplo, se muestra que la regla CILIUM_FORWARD ahora está configurada de forma correcta antes que la regla KUBE-FORWARD:

Chain FORWARD (policy ACCEPT)
target                  prot opt source   destination
CILIUM_FORWARD          all  --  anywhere anywhere                /* cilium-feeder: CILIUM_FORWARD */
KUBE-FORWARD            all  --  anywhere anywhere                /* kubernetes forwarding rules */
KUBE-SERVICES           all  --  anywhere anywhere    ctstate NEW /* kubernetes service portals */
KUBE-EXTERNAL-SERVICES  all  --  anywhere anywhere    ctstate NEW /* kubernetes externally-visible service portals */
Revisiones y actualizaciones 1.9, 1.10

La función de versión preliminar no conserva el permiso original ni la información del propietario

La función de vista previa del clúster 1.9.x con bmctl 1.9.x no conserva el permiso original ni la información del propietario. Para verificar si esta función te afecta, extrae el archivo del que creaste una copia de seguridad mediante el siguiente comando:

tar -xzvf BACKUP_FILE

Solución alternativa

Verifica si metadata.json está presente y si bmctlVersion es 1.9.x. Si metadata.json no está presente, actualiza al clúster 1.10.x y usa bmctl 1.10.x para crear una copia de seguridad y restablecer.

Actualizaciones y creaciones 1.14.2

clientconfig-operator quedó en estado pendiente con CreateContainerConfigError

Si actualizaste a un clúster de versión 1.14.2 o creaste uno con una configuración OIDC/LDAP, es posible que veas que el Pod clientconfig-operator se atascó en un estado pendiente. Con este problema, hay dos Pods clientconfig-operator, uno en estado de ejecución y el otro en estado pendiente.

Este problema solo se aplica a los clústeres de la versión 1.14.2. Las versiones anteriores del clúster, como 1.14.0 y 1.14.1, no se ven afectadas. Este problema se solucionó en la versión 1.14.3 y en todas las versiones posteriores, incluidas la 1.15.0 y las posteriores.


Solución alternativa:

Como solución alternativa, puedes aplicar parches a la implementación de clientconfig-operator para agregar contexto de seguridad adicional y asegurarte de que la implementación esté lista.

Usa el siguiente comando para aplicar un parche a clientconfig-operator en el clúster de destino:

kubectl patch deployment clientconfig-operator -n kube-system \
    -p '{"spec":{"template":{"spec":{"containers": [{"name":"oidcproxy","securityContext":{"runAsGroup":2038,"runAsUser":2038}}]}}}}' \
    --kubeconfig CLUSTER_KUBECONFIG

Reemplaza lo siguiente:

  • CLUSTER_KUBECONFIG: Es la ruta de acceso del archivo kubeconfig para el clúster de destino.
Operación 1.11, 1.12, 1.13, 1.14, 1.15

La rotación de la autoridad certificadora falla para los clústeres sin balanceo de cargas en paquetes

Para los clústeres sin balanceo de cargas en paquetes (spec.loadBalancer.mode configurado como manual), el comando bmctl update credentials certificate-authorities rotate puede dejar de responder y fallar con el siguiente error: x509: certificate signed by unknown authority.

Si te afecta este problema, es posible que el comando bmctl genere el siguiente mensaje antes de dejar de responder:

Signing CA completed in 3/0 control-plane nodes

En este caso, el comando falla en algún momento. El registro de rotación de la autoridad certificadora de un clúster con tres planos de control puede incluir entradas como las siguientes:

[2023-06-14 22:33:17+0000] waiting for all nodes to trust CA bundle OK
[2023-06-14 22:41:27+0000] waiting for first round of pod restart to complete OK
Signing CA completed in 0/0 control-plane nodes
Signing CA completed in 1/0 control-plane nodes
Signing CA completed in 2/0 control-plane nodes
Signing CA completed in 3/0 control-plane nodes
...
Unable to connect to the server: x509: certificate signed by unknown
authority (possibly because of "crypto/rsa: verification error" while
trying to verify candidate authority certificate "kubernetes")

Solución alternativa

Si necesitas más ayuda, comunícate con el equipo de Atención al cliente de Google.

Instalación, Herramientas de redes 1.11, 1.12, 1.13, 1.14.0-1.14.1

ipam-controller-manager de bucles de falla en clústeres de pila doble

Cuando implementas un clúster de pila doble (un clúster con direcciones IPv4 e IPv6), los Pods ipam-controller-manager pueden generar un bucle de fallas. Este comportamiento hace que los nodos fluyan entre los estados Ready y NotReady, y puede hacer que la instalación del clúster falle. Este problema puede ocurrir cuando el servidor de la API se encuentra bajo una carga alta.

Para ver si este problema te afecta, verifica si los Pods ipam-controller-manager fallan con errores CrashLoopBackOff:

kubectl -n kube-system get pods | grep  ipam-controller-manager

En el siguiente resultado de ejemplo, se muestran los Pods en un estado CrashLoopBackOff:

ipam-controller-manager-h7xb8   0/1  CrashLoopBackOff   3 (19s ago)   2m ipam-controller-manager-vzrrf   0/1  CrashLoopBackOff   3 (19s ago)   2m1s
ipam-controller-manager-z8bdw   0/1  CrashLoopBackOff   3 (31s ago)   2m2s

Obtén detalles del nodo que se encuentra en estado NotReady:

kubectl describe node <node-name> | grep PodCIDRs

En un clúster con este problema, un nodo no tiene PodsCIDR asignados, como se muestra en el siguiente resultado de ejemplo:

PodCIDRs:

En un clúster en buen estado, todos los nodos deben tener asignados PodCIDR de pila doble, como se muestra en el siguiente resultado de ejemplo:

PodCIDRs:    192.168.6.0/24,222:333:444:555:5:4:7:0/120

Solución alternativa:

Reinicia los Pods ipam-controller-manager:

kubectl -n kube-system rollout restart ds ipam-controller-manager
Operación 1.6, 1.7, 1.8, 1.9, 1.10, 1.11, 1.12, 1.13 y 1.14

etcd ver hambre

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

  • Se interrumpe 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 GDCV para las versiones 1.12.9, 1.13.6, 1.14.3 y posteriores de Bare Metal. Estas versiones más recientes usan la versión de etcd 3.4.21. Este problema afecta a todas las versiones anteriores de GDCV para Bare Metal.

Solución alternativa

Si no puedes actualizar de inmediato, puedes mitigar el riesgo de falla del clúster si reduces la cantidad de nodos en tu 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 Seleccionar una métrica, ingresa Kubernetes Container en la barra de filtros y, luego, utiliza los submenús para seleccionar la métrica:
    1. En el menú Recursos activos, selecciona Contenedor de Kubernetes.
    2. En el menú Categorías de métricas activas, selecciona Anthos.
    3. En el menú Métricas activas, selecciona etcd_network_client_grpc_sent_bytes_total.
    4. Haz clic en Aplicar.
Herramientas de redes 1.11.6, 1.12.3

Estado "Fallido" del operador vfio-pci del SR-IOV

El syncStatus del objeto SriovNetworkNodeState puede informar el valor "Fallido" para un nodo configurado. Para ver el estado de un nodo y determinar si el problema te afecta, ejecuta el siguiente comando:

kubectl -n gke-operators get \
    sriovnetworknodestates.sriovnetwork.k8s.cni.cncf.io NODE_NAME \
    -o jsonpath='{.status.syncStatus}'

Reemplaza NODE_NAME por el nombre del nodo que deseas verificar.


Solución alternativa:

Si el estado del objeto SriovNetworkNodeState es “Fallido”, actualiza el clúster a la versión 1.11.7 o posterior, o a la versión 1.12.4 o posterior.

Revisiones y actualizaciones 1.10, 1.11, 1.12, 1.13, 1.14.0, 1.14.1

Algunos nodos trabajadores no están en estado Listo después de la actualización

Una vez finalizada la actualización, es posible que la condición Listo de algunos nodos trabajadores se establezca en false. En el recurso Node, verás un error junto a la condición Listo similar al siguiente ejemplo:

container runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:Network plugin returns error: cni plugin not initialized

Cuando accedes a la máquina detenida, la configuración de la CNI en la máquina está vacía:

sudo ls /etc/cni/net.d/

Solución alternativa

Borra el Pod anetd del nodo para reiniciarlo.

Actualizaciones y actualizaciones, Seguridad 1.10

Varias rotaciones de certificados de cert-manager generan incoherencias.

Después de varias rotaciones de certificados manuales o automáticas, el pod de webhook, como anthos-cluster-operator, no se actualiza con los certificados nuevos emitidos por cert-manager. Cualquier actualización del recurso personalizado del clúster falla y genera un error similar al siguiente:

Internal error occurred: failed calling
webhook "vcluster.kb.io": failed to call webhook: Post "https://webhook-service.kube-system.svc:443/validate-baremetal-cluster-gke-io-v1-cluster?timeout=10s": x509: certificate signed by unknown authority (possibly because of "x509:
invalid signature: parent certificate cannot sign this kind of certificate"
while trying to verify candidate authority certificate
"webhook-service.kube-system.svc")

Este problema puede ocurrir en las siguientes circunstancias:

  • Si realizaste dos rotaciones manuales de certificados emitidos por el administrador de certificados en un clúster con más de 180 días o más, y nunca reiniciaste el anthos-cluster-operator.
  • Si realizaste rotaciones manuales de certificados emitidos por cert-manager en un clúster con más de 90 días de antigüedad y nunca reiniciaste el anthos-cluster-operator.

Solución alternativa

Reinicia el Pod mediante la finalización del anthos-cluster-operator.

Revisiones y actualizaciones 1.14.0

Pods del controlador del ciclo de vida desactualizados que se crearon durante la actualización del clúster de usuario

En los clústeres de administrador de la versión 1.14.0, se pueden crear uno o más Pods de implementador del controlador de ciclo de vida desactualizados durante las actualizaciones del clúster de usuario. Este problema se aplica a los clústeres de usuario que se crearon en un principio en versiones anteriores a la 1.12. Los Pods creados de forma involuntaria no impiden las operaciones de actualización, pero pueden encontrarse en un estado inesperado. Te recomendamos que quites los Pods desactualizados.

Este problema se corrigió en la versión 1.14.1.

Solución alternativa:

Para quitar los Pods del implementador del controlador del ciclo de vida desactualizados, haz lo siguiente:

  1. Enumera recursos de comprobación preliminar:
    kubectl get preflightchecks --kubeconfig ADMIN_KUBECONFIG -A
    

    El resultado se verá así:

    NAMESPACE                    NAME                      PASS   AGE
    cluster-ci-87a021b9dcbb31c   ci-87a021b9dcbb31c        true   20d
    cluster-ci-87a021b9dcbb31c   ci-87a021b9dcbb31cd6jv6   false  20d
    

    en el que ci-87a021b9dcbb31c es el nombre del clúster.

  2. Borra los recursos cuyo valor en la columna PASS sea true o false.

    Por ejemplo, para borrar los recursos en el resultado de muestra anterior, usa los siguientes comandos:

    kubectl delete preflightchecks ci-87a021b9dcbb31c \
        -n cluster-ci-87a021b9dcbb31c \
        --kubeconfig ADMIN_KUBECONFIG 
    kubectl delete preflightchecks ci-87a021b9dcbb31cd6jv6 \
        -n cluster-ci-87a021b9dcbb31c \
        --kubeconfig ADMIN_KUBECONFIG
    
Herramientas de redes 1.9, 1.10, 1.11, 1.12, 1.13, 1.14, 1.15, 1.16, 1.28

El estado BGPSession cambia constantemente debido a una gran cantidad de rutas entrantes

Las herramientas de redes avanzadas de GKE en Bare Metal no pueden administrar las sesiones de BGP de forma correcta cuando los pares externos anuncian una gran cantidad de rutas (alrededor de 100 o más). Con una gran cantidad de rutas entrantes, el controlador de BGP local del nodo tarda demasiado en conciliar las sesiones de BGP y no actualiza el estado. La falta de actualizaciones de estado, o una verificación de estado, provoca que la sesión se borre por estar inactiva.

Entre los comportamientos no deseados en las sesiones de BGP que puedes observar y que indican un problema, se incluyen los siguientes:

  • Eliminación y recreación continuas de bgpsession.
  • bgpsession.status.state nunca se convierte en Established
  • Rutas que no publican anuncios o que se anuncian y se retiran repetidamente

Los problemas de balanceo de cargas de BGP pueden notarse debido a problemas de conectividad a los servicios de LoadBalancer.

El problema FlatIP de BGP puede notarse debido a problemas de conectividad a los Pods.

Para determinar si los problemas de BGP se deben a los pares remotos que anuncian demasiadas rutas, usa los siguientes comandos a fin de revisar los estados y el resultado asociados:

  • Usa kubectl get bgpsessions en el clúster afectado. El resultado muestra bgpsessions con el estado "Sin establecer" y la hora del último informe cuenta de forma continua de 10 a 12 segundos antes de que parezca restablecerse a cero.
  • El resultado de kubectl get bgpsessions muestra que las sesiones afectadas se recrean de forma repetida:
    kubectl get bgpsessions \
        -o jsonpath="{.items[*]['metadata.name', 'metadata.creationTimestamp']}"
    
  • Los mensajes de registro indican que se están borrando las sesiones de BGP inactivas:
    kubectl logs ang-controller-manager-POD_NUMBER
    

    Reemplaza POD_NUMBER por el Pod líder de tu clúster.


Solución alternativa:

Reduce o elimina la cantidad de rutas anunciadas desde el intercambio de tráfico remoto al clúster con una política de exportación.

En la versión 1.14.2 y posteriores del clúster de GKE en Bare Metal, también puedes inhabilitar la función que procesa las rutas recibidas mediante un AddOnConfiguration. Agrega el argumento --disable-received-routes al contenedor bgpd del daemonset ang-daemon.

Herramientas de redes 1.14, 1.15, 1.16, 1.28

Tiempos de espera de la aplicación causados por fallas de inserción de tablas de conntrack

Los clústeres que se ejecutan en un SO Ubuntu que usa el kernel 5.15 o superior son susceptibles a fallas de inserción de tablas de seguimiento de conexión de netfilter (conntrack). Las fallas de inserción 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 te afecta este problema, puedes comprobar las estadísticas del sistema de seguimiento de conexiones del kernel con el siguiente comando:

sudo conntrack -S

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

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

Si un valor chaintoolong en la respuesta es un número distinto de cero, este problema te afectará.

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 un 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 del nodo. Por ejemplo, si tu nodo tiene ocho núcleos, establece el tamaño de la tabla en 524288.

Revisiones y actualizaciones 1.11.3, 1.11.4, 1.11.5, 1.11.6, 1.11.7, 1.11.8, 1.12.4, 1.12.5, 1.12.6, 1.12.7, 1.12.8, 1.13.4, 1.13.5

No se pueden restablecer las copias de seguridad de los clústeres con bmctl para algunas versiones

Te recomendamos que crees una copia de seguridad de los clústeres antes de la actualización para que puedas restablecer la versión anterior si la actualización no se realiza de forma correcta. Un problema con el comando bmctl restore cluster hace que no pueda restablecer las copias de seguridad de los clústeres con las versiones identificadas. Este problema es específico de las actualizaciones, en las que restableces una copia de seguridad de una versión anterior.

Si tu clúster se ve afectado, el registro bmctl restore cluster contiene el siguiente error:

Error: failed to extract image paths from profile: anthos version VERSION not supported

Solución alternativa:

Hasta que se solucione este problema, te recomendamos que sigas las instrucciones en Crea una copia de seguridad y restablece clústeres para hacer una copia de seguridad de tus clústeres y restablecerlos de forma manual, si es necesario.
Herramientas de redes 1.10, 1.11, 1.12, 1.13, 1.14.0-1.14.2

NetworkGatewayGroup falla si no hay una dirección IP en la interfaz.

NetworkGatewayGroup no crea daemons para los nodos que no tienen interfaces IPv4 y también IPv6. Esto hace que funciones como el balanceador de cargas de BGP y la NAT de salida fallen. Si verificas los registros del Pod ang-node con errores en el espacio de nombres kube-system, se muestran errores similares al siguiente ejemplo cuando falta una dirección IPv6:

ANGd.Setup    Failed to create ANG daemon    {"nodeName": "bm-node-1", "error":
"creating NDP client failed: ndp: address \"linklocal\" not found on interface \"ens192\""}

En el ejemplo anterior, no hay una dirección IPv6 en la interfaz ens192. Se muestran errores de ARP similares si al nodo le falta una dirección IPv4.

NetworkGatewayGroup intenta establecer una conexión ARP y una conexión NDP a la dirección IP local del vínculo. Si la dirección IP no existe (IPv4 para ARP o IPv6 para NDP), la conexión falla y el daemon no continúa.

Este problema se corrigió en la versión 1.14.3.


Solución alternativa:

Conéctate al nodo con SSH y agrega una dirección IPv4 o IPv6 al vínculo que contiene la IP del nodo. En la entrada de registro del ejemplo anterior, esta interfaz era ens192:

ip address add dev INTERFACE scope link ADDRESS

Reemplaza lo siguiente:

  • INTERFACE: La interfaz para tu nodo, como ens192.
  • ADDRESS: La dirección IP y la máscara de subred que se aplicará a la interfaz.
Restablecimiento/eliminación 1.10, 1.11, 1.12, 1.13.0 a 1.13.2

Bucle de falla anthos-cluster-operator cuando se quita un nodo del plano de control

Cuando intentas quitar un nodo del plano de control mediante la eliminación de la dirección IP de Cluster.Spec, anthos-cluster-operator entra en un estado de bucle de falla que bloquea cualquier otra operación.


Solución alternativa:

El problema se corrigió en las versiones 1.13.3, 1.14.0 y posteriores. Todas las demás versiones se ven afectadas. Actualiza a una de las versiones corregidas

Como solución alternativa, ejecuta el siguiente comando:

kubectl label baremetalmachine IP_ADDRESS \
    -n CLUSTER_NAMESPACE baremetal.cluster.gke.io/upgrade-apply-

Reemplaza lo siguiente:

  • IP_ADDRESS: Es la dirección IP del nodo en estado de bucle de falla.
  • CLUSTER_NAMESPACE: Es el espacio de nombres del clúster.
Instalación 1.13.1, 1.13.2 y 1.13.3

kubeadm join falla en clústeres grandes debido a una discrepancia de tokens

Cuando instalas GKE en clústeres de Bare Metal con una gran cantidad de nodos, es posible que veas un mensaje de error kubeadmin join similar al siguiente ejemplo:

TASK [kubeadm : kubeadm join --config /dev/stdin --ignore-preflight-errors=all] ***
fatal: [10.200.0.138]: FAILED! => {"changed": true, "cmd": "kubeadm join
--config /dev/stdin --ignore-preflight-errors=all", "delta": "0:05:00.140669", "end": "2022-11-01 21:53:15.195648", "msg": "non-zero return code", "rc": 1,
"start": "2022-11-01 21:48:15.054979", "stderr": "W1101 21:48:15.082440   99570 initconfiguration.go:119]
Usage of CRI endpoints without URL scheme is deprecated and can cause kubelet errors in the future.
Automatically prepending scheme \"unix\" to the \"criSocket\" with value \"/run/containerd/containerd.sock\". Please update your configuration!\nerror
execution phase preflight: couldn't validate the identity of the API Server: could not find a JWS signature in the cluster-info ConfigMap for token ID \"yjcik0\"\n
To see the stack trace of this error execute with --v=5 or higher", "stderr_lines":
["W1101 21:48:15.082440   99570 initconfiguration.go:119] Usage of CRI endpoints without URL scheme is deprecated and can cause kubelet errors in the future.
Automatically prepending scheme \"unix\" to the \"criSocket\" with value \"/run/containerd/containerd.sock\".
Please update your configuration!", "error execution phase preflight: couldn't validate the identity of the API Server:
could not find a JWS signature in the cluster-info ConfigMap for token ID \"yjcik0\"",
"To see the stack trace of this error execute with --v=5 or higher"], "stdout": "[preflight]
Running pre-flight checks", "stdout_lines": ["[preflight] Running pre-flight checks"]}

Solución alternativa:

Este problema se resolvió en el GDCV para Bare Metal versión 1.13.4 y posteriores.

Si necesitas usar una versión afectada, primero crea un clúster con menos de 20 nodos y, luego, cambia el tamaño del clúster para agregar nodos adicionales una vez que se complete la instalación.

Registro y supervisión 1.10, 1.11, 1.12, 1.13.0

Límite de CPU bajo para metrics-server en clústeres de Edge

En GKE en clústeres de Bare Metal Edge, los límites bajos de CPU para metrics-server pueden causar reinicios frecuentes de metrics-server. El ajuste de escala automático horizontal de Pods (HPA) no funciona porque metrics-server no está en buen estado.

Si el límite de CPU de metrics-server es inferior a 40m, tus clústeres pueden verse afectados. Para verificar los límites de CPU de metrics-server, revisa uno de los siguientes archivos:

  • Versión 1.x-1.12 de GKE en clústeres de Bare Metal:
    kubectl get deployment metrics-server -n kube-system \
        -o yaml > metrics-server.yaml
    
  • GKE en clústeres de Bare Metal versión 1.13 o posterior:
    kubectl get deployment metrics-server -n gke-managed-metrics-server \
        -o yaml > metrics-server.yaml
    

Solución alternativa:

Este problema se resuelve en los clústeres de GKE en Bare Metal versión 1.13.1 o posterior. Para solucionar este problema, actualiza tus clústeres.

Una solución alternativa a corto plazo hasta que puedas actualizar los clústeres es aumentar de forma manual los límites de CPU para metrics-server de la siguiente manera:

  1. Escala verticalmente metrics-server-operator:
    kubectl scale deploy metrics-server-operator --replicas=0
  2. Actualiza la configuración y aumenta los límites de CPU:
    • Versión 1.x-1.12 de GKE en clústeres de Bare Metal:
      kubectl -n kube-system edit deployment metrics-server
    • Versión 1.13 de GKE en clústeres de Bare Metal:
      kubectl -n gke-managed-metrics-server edit deployment metrics-server

    Quita la línea --config-dir=/etc/config y aumenta los límites de CPU, como se muestra en el siguiente ejemplo:

    [...]
    - command:
    - /pod_nanny
    # - --config-dir=/etc/config # <--- Remove this line
    - --container=metrics-server
    - --cpu=50m # <--- Increase CPU, such as to 50m
    - --extra-cpu=0.5m
    - --memory=35Mi
    - --extra-memory=4Mi
    - --threshold=5
    - --deployment=metrics-server
    - --poll-period=30000
    - --estimator=exponential
    - --scale-down-delay=24h
    - --minClusterSize=5
    - --use-metrics=true
    [...]
    
  3. Guarda el metrics-server y ciérralo para aplicar los cambios.
Herramientas de redes 1.14, 1.15, 1.16

La conexión directa de NodePort al Pod de hostNetwork no funciona

La conexión a un Pod habilitado con hostNetwork mediante el servicio NodePort falla cuando el Pod de backend está en el mismo nodo que el NodePort de destino. Este problema afecta a los servicios de LoadBalancer cuando se usa con Pods de hostNetwork. Con varios backends, puede haber una falla de conexión esporádica.

Este problema se debe a un error en el programa eBPF.


Solución alternativa:

Cuando uses un servicio de Nodeport, no te orientes al nodo en el que se ejecuta ninguno de los Pods de backend. Cuando uses el servicio LoadBalancer, asegúrate de que los Pods alojados en hostNetwork no se ejecuten en nodos LoadBalancer.

Revisiones y actualizaciones 1.12.3, 1.13.0

Los clústeres de administrador 1.13.0 no pueden administrar los clústeres de usuario 1.12.3

Los clústeres de administrador que ejecutan la versión 1.13.0 no pueden administrar los clústeres de usuario que ejecutan la versión 1.12.3. Las operaciones en un clúster de usuario de la versión 1.12.3 fallan.


Solución alternativa:

Actualiza el clúster de administrador a la versión 1.13.1 o actualiza el clúster de usuario a la misma versión que el clúster de administrador.

Revisiones y actualizaciones 1.12

Se bloqueó la actualización a la versión 1.13.x para los clústeres de administrador con grupos de nodo trabajador

Los clústeres de administrador de la versión 1.13.0 y posteriores no pueden contener grupos de nodo trabajador. Se bloquean las actualizaciones a la versión 1.13.0 o posteriores para los clústeres de administrador con grupos de nodo trabajador. Si la actualización del clúster de administrador está detenida, puedes confirmar si los grupos de nodo trabajador son la causa. Para ello, verifica el siguiente error en el archivo upgrade-cluster.log dentro de la carpeta bmctl-workspace:

Operation failed, retrying with backoff. Cause: error creating "baremetal.cluster.gke.io/v1, Kind=NodePool" cluster-test-cluster-2023-06-06-140654/np1: admission webhook "vnodepool.kb.io" denied the request: Adding worker nodepool to Admin cluster is disallowed.

Solución alternativa:

Antes de actualizar, mueve todos los grupos de nodo trabajador a los clústeres de usuario. Si deseas obtener instrucciones para agregar y quitar grupos de nodos, consulta Administra grupos de nodos en un clúster.

Revisiones y actualizaciones 1.10, 1.11, 1.12, 1.13, 1.14, 1.15, 1.16, 1.28

Errores cuando se actualizan recursos con kubectl apply

Si actualizas recursos existentes como los recursos personalizados ClientConfig o Stackdriver con kubectl apply, el controlador puede mostrar un error o revertir la entrada y los cambios planificados.

Por ejemplo, puedes intentar editar el recurso personalizado Stackdriver de la siguiente manera. Para ello, primero obtén el recurso y, luego, aplica una versión actualizada:

  1. Obtén la definición de YAML existente:
    kubectl get stackdriver -n kube-system stackdriver \
        -o yaml > stackdriver.yaml
    
  2. Habilita funciones o actualiza la configuración en el archivo YAML.
  3. Vuelve a aplicar el archivo YAML actualizado:
    kubectl apply -f stackdriver.yaml
    

En el último paso de kubectl apply, es posible que tengas problemas.


Solución alternativa:

No uses kubectl apply para realizar cambios en los recursos existentes. En su lugar, usa kubectl edit o kubectl patch como se muestra en los siguientes ejemplos:

  1. Edita el recurso personalizado Stackdriver:
    kubectl edit stackdriver -n kube-system stackdriver
    
  2. Habilita funciones o actualiza la configuración en el archivo YAML.
  3. Guardar y salir del editor

Enfoque alternativo con kubectl patch:

  1. Obtén la definición de YAML existente:
    kubectl get stackdriver -n kube-system stackdriver \
        -o yaml > stackdriver.yaml
    
  2. Habilita funciones o actualiza la configuración en el archivo YAML.
  3. Vuelve a aplicar el archivo YAML actualizado:
    kubectl patch stackdriver stackdriver --type merge \
        -n kube-system --patch-file stackdriver.yaml
    
Registro y supervisión 1.12, 1.13, 1.14, 1.15, 1.16

Los fragmentos de trabajo pendientes dañados causan un bucle de fallas stackdriver-log-forwarder

El bucle de fallas stackdriver-log-forwarder falla si intenta procesar un fragmento de trabajo pendiente dañado. Los siguientes errores de ejemplo se muestran en los registros de contenedores:

[2022/09/16 02:05:01] [error] [storage] format check failed: tail.1/1-1659339894.252926599.flb
[2022/09/16 02:05:01] [error] [engine] could not segregate backlog chunks

Cuando ocurre este bucle de fallas, no puedes ver los registros en Cloud Logging.


Solución alternativa:

Para resolverlos, sigue estos pasos:

  1. Identificar los fragmentos de trabajo pendientes dañados. Revisa los siguientes ejemplos de mensajes de error:
    [2022/09/16 02:05:01] [error] [storage] format check failed: tail.1/1-1659339894.252926599.flb
    [2022/09/16 02:05:01] [error] [engine] could not segregate backlog chunks
    
    En este ejemplo, el archivo tail.1/1-1659339894.252926599.flb que se almacenó en var/log/fluent-bit-buffers/tail.1/ fue el error. Se deben quitar todos los archivos *.flb en los que haya fallado una verificación de formato.
  2. Finaliza los Pods en ejecución para stackdriver-log-forwarder:
    kubectl --kubeconfig KUBECONFIG -n kube-system \
        patch daemonset stackdriver-log-forwarder \
        -p '{"spec": {"template": {"spec": {"nodeSelector": {"non-existing": "true"}}}}}'
    
    Reemplaza KUBECONFIG por la ruta de acceso al archivo kubeconfig del clúster de usuario.

    Verifica que los Pods stackdriver-log-forwarder se borren antes de continuar con el siguiente paso.
  3. Conéctate al nodo mediante SSH en el que se ejecuta stackdriver-log-forwarder.
  4. En el nodo, borra todos los archivos *.flb dañados en var/log/fluent-bit-buffers/tail.1/.

    Si hay demasiados archivos dañados y quieres aplicar una secuencia de comandos para limpiar todos los fragmentos de tareas pendientes, usa las siguientes secuencias de comandos:
    1. Implementa un DaemonSet para limpiar todos los datos sucios en búferes en fluent-bit:
      kubectl --kubeconfig KUBECONFIG -n kube-system apply -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
      
    2. Asegúrate de que el DaemonSet limpió todos los nodos. El resultado de los siguientes dos comandos debe ser igual a la cantidad de nodos del clúster:
      kubectl --kubeconfig KUBECONFIG logs \
          -n kube-system -l app=fluent-bit-cleanup | grep "cleaned up" | wc -l
      kubectl --kubeconfig KUBECONFIG \
          -n kube-system get pods -l app=fluent-bit-cleanup --no-headers | wc -l
      
    3. Borra el DaemonSet de limpieza:
      kubectl --kubeconfig KUBECONFIG -n kube-system delete ds \
          fluent-bit-cleanup
      
    4. Reinicia los Pods stackdriver-log-forwarder:
      kubectl --kubeconfig KUBECONFIG \
          -n kube-system patch daemonset stackdriver-log-forwarder --type json \
          -p='[{"op": "remove", "path": "/spec/template/spec/nodeSelector/non-existing"}]'
      
Herramientas de redes, entorno de ejecución de VM en GDC 1.14.0

Si reinicias Dataplane V2 (anetd) en los clústeres, es posible que las VMs existentes no se puedan conectar a una red que no sea del Pod.

En clústeres de varios NIC, reiniciar Dataplane V2 (anetd) puede provocar que las máquinas virtuales no se puedan conectar a las redes. Se puede observar un error similar al siguiente en los registros del Pod anetd:

could not find an allocator to allocate the IP of the multi-nic endpoint

Solución alternativa:

Puedes reiniciar la VM como solución rápida. Para evitar que el problema vuelva a ocurrir, actualiza el clúster a la versión 1.14.1 o una posterior.

Operación 1.13, 1.14.0, 1.14.1

gke-metrics-agent no tiene límite de memoria en clústeres de perfiles de Edge.

Según la carga de trabajo del clúster, el gke-metrics-agent puede usar más de 4,608 MiB de memoria. Este problema solo afecta a GKE en los clústeres de perfil de Bare Metal Edge. Los clústeres de perfiles predeterminados no se ven afectados.


Solución alternativa:

Actualiza tu clúster a la versión 1.14.2 o posterior.

Instalación 1.12, 1.13

La creación del clúster puede fallar debido a condiciones de carrera

Cuando creas clústeres con kubectl, es posible que la verificación preliminar nunca finalice debido a las condiciones de carrera. Como resultado, la creación del clúster puede fallar en ciertos casos.

El conciliador de verificación previa crea un SecretForwarder para copiar el secreto ssh-key predeterminado en el espacio de nombres de destino. Por lo general, la comprobación preliminar aprovecha las referencias de propietario y se concilia una vez que se completa el SecretForwarder. Sin embargo, en casos excepcionales, las referencias del propietario de SecretForwarder pueden perder la referencia a la comprobación preliminar, lo que provoca que la comprobación preliminar se detenga. Como resultado, la creación del clúster falla. Para continuar con la conciliación de la verificación preliminar controlada por el controlador, borra el Pod del operador del clúster o el recurso de verificación previa. Cuando borras el recurso de comprobación previa, se crea otro y continúa la conciliación. Como alternativa, puedes actualizar tus clústeres existentes (que se crearon con una versión anterior) a una versión fija.

Herramientas de redes 1.9, 1.10, 1.11, 1.12, 1.13, 1.14, 1.15

Las direcciones IP reservadas no se liberan cuando se usa el complemento ubicación con la función de varias NIC.

En la función de varios Nic, si usas el complemento de ubicación de CNI y usas la operación CNI DEL para borrar una interfaz de red para un Pod, es posible que algunas direcciones IP reservadas no se liberen correctamente. Esto sucede cuando se interrumpe la operación CNI DEL.

Para verificar las reservas de direcciones IP sin usar de los Pods, ejecuta el siguiente comando:

kubectl get ippools -A --kubeconfig KUBECONFIG_PATH

Solución alternativa:

Borra de forma manual las direcciones IP (ippools) que no se usan.

Instalación 1.10, 1.11.0, 1.11.1, 1.11.2

El detector de problemas de nodos falla en el clúster de usuario 1.10.4

El detector de problemas de nodos puede fallar en los clústeres de usuario de la versión 1.10.x, cuando los clústeres de administrador de las versiones 1.11.0, 1.11.1 o 1.11.2 administran los clústeres de usuario 1.10.x. Cuando falla el detector de problemas de nodos, el registro se actualiza con el siguiente mensaje de error:

Error - NPD not supported for anthos baremetal version 1.10.4:
anthos version 1.10.4 not supported.

Solución alternativa

Actualiza el clúster de administrador a la versión 1.11.3 para resolver el problema.

Operación 1.14

Los nodos del clúster IPv4 de modo isla 1.14 tienen un tamaño de máscara CIDR de Pod de 24.

En la versión 1.14, no se tiene en cuenta la configuración maxPodsPerNode para los clústeres de modo isla, por lo que a los nodos se les asigna un tamaño de máscara CIDR de Pod de 24 (256 direcciones IP).Esto podría provocar que el clúster se quede sin direcciones IP del Pod antes de lo esperado. Por ejemplo, si tu clúster tiene un tamaño de máscara de CIDR de Pod de 22, a cada nodo se le asignará una máscara de CIDR de Pod de 24 y el clúster solo podrá admitir hasta 4 nodos. Es posible que tu clúster también experimente inestabilidad de la red en un período de alta deserción de Pods cuando maxPodsPerNode se establezca en 129 o un valor superior y no haya suficiente sobrecarga en el CIDR del Pod para cada nodo.

Si tu clúster se ve afectado, el Pod anetd informa el siguiente error cuando agregas un nodo nuevo al clúster y no hay podCIDR disponible:

error="required IPv4 PodCIDR not available"

Solución alternativa

Sigue estos pasos para resolver el problema:

  1. Actualiza a 1.14.1 o una versión posterior.
  2. Quita los nodos trabajadores y vuelve a agregarlos.
  3. Quita los nodos del plano de control y vuelve a agregarlos, preferentemente uno por uno para evitar el tiempo de inactividad del clúster.
Revisiones y actualizaciones 1.14.0, 1.14.1

Falla en la reversión de la actualización del clúster

Una reversión de actualización puede fallar para los clústeres de la versión 1.14.0 o 1.14.1. Si actualizas un clúster de 1.14.0 a 1.14.1 y, luego, intentas revertirla a 1.14.0 mediante el comando bmctl restore cluster, es posible que se muestre un error como el del siguiente ejemplo:

I0119 22:11:49.705596  107905 client.go:48] Operation failed, retrying with backoff.
Cause: error updating "baremetal.cluster.gke.io/v1, Kind=HealthCheck" cluster-user-ci-f3a04dc1b0d2ac8/user-ci-f3a04dc1b0d2ac8-network: admission webhook "vhealthcheck.kb.io"
denied the request: HealthCheck.baremetal.cluster.gke.io "user-ci-f3a04dc1b0d2ac8-network" is invalid:
Spec: Invalid value: v1.HealthCheckSpec{ClusterName:(*string)(0xc0003096e0), AnthosBareMetalVersion:(*string)(0xc000309690),
Type:(*v1.CheckType)(0xc000309710), NodePoolNames:[]string(nil), NodeAddresses:[]string(nil), ConfigYAML:(*string)(nil),
CheckImageVersion:(*string)(nil), IntervalInSeconds:(*int64)(0xc0015c29f8)}: Field is immutable

Solución alternativa:

Borra todos los recursos healthchecks.baremetal.cluster.gke.io del espacio de nombres del clúster y, luego, vuelve a ejecutar el comando bmctl restore cluster:

  1. Enumera los healthchecks.baremetal.cluster.gke.io recursos:
    kubectl get healthchecks.baremetal.cluster.gke.io \
        --namespace=CLUSTER_NAMESPACE \
        --kubeconfig=ADMIN_KUBECONFIG
    

    Reemplaza lo siguiente:

    • CLUSTER_NAMESPACE: Es el espacio de nombres del clúster.
    • ADMIN_KUBECONFIG: Es la ruta de acceso al archivo kubeconfig del clúster de administrador.
  2. Borra todos los healthchecks.baremetal.cluster.gke.io recursos enumerados en el paso anterior:
    kubectl delete healthchecks.baremetal.cluster.gke.io \
        HEALTHCHECK_RESOURCE_NAME \
        --namespace=CLUSTER_NAMESPACE \
        --kubeconfig=ADMIN_KUBECONFIG
    
    Reemplaza HEALTHCHECK_RESOURCE_NAME por el nombre de los recursos de verificación de estado.
  3. Vuelve a ejecutar el comando bmctl restore cluster.
Herramientas de redes 1.12.0

La dirección IP externa del servicio no funciona en modo plano

En un clúster que tiene flatIPv4 configurado como true, no se puede acceder a los servicios de tipo LoadBalancer mediante sus direcciones IP externas.

Este problema se solucionó en la versión 1.12.1.


Solución alternativa:

En el ConfigMap cilium-config, configura enable-415 como "true" y, luego, reinicia los Pods anetd.

Revisiones y actualizaciones 1.13.0 y 1.14

Las actualizaciones in situ de la versión 1.13.0 a la 1.14.x nunca finalizan.

Cuando intentas realizar una actualización in situ de 1.13.0 a 1.14.x con bmctl 1.14.0 y la marca --use-bootstrap=false, la actualización nunca finaliza.

Un error con el operador preflight-check hace que el clúster nunca programe las verificaciones requeridas, lo que significa que la verificación preliminar nunca finaliza.


Solución alternativa:

Actualiza a la versión 1.13.1 antes de actualizar a la versión 1.14.x. Debería funcionar una actualización in situ de 1.13.0 a 1.13.1. También puedes actualizar de 1.13.0 a 1.14.x sin la marca --use-bootstrap=false.

Actualizaciones y actualizaciones, Seguridad 1.13 y 1.14

Los clústeres actualizados a la versión 1.14.0 pierden los taints de instancia principal.

Los nodos del plano de control requieren uno de dos taints específicos para evitar que se programen Pods de carga de trabajo en ellos. Cuando actualizas los clústeres de GKE de la versión 1.13 a la versión 1.14.0, los nodos del plano de control pierden los siguientes taints obligatorios:

  • node-role.kubernetes.io/master:NoSchedule
  • node-role.kubernetes.io/master:PreferNoSchedule

Este problema no causa fallas de actualización, pero los Pods que no deben ejecutarse en los nodos del plano de control pueden comenzar a hacerlo. Estos Pods de cargas de trabajo pueden sobrecargar los nodos del plano de control y provocar inestabilidad en el clúster.

Determina si te afecta esto

  1. Busca los nodos del plano de control, usa el siguiente comando:
    kubectl get node -l 'node-role.kubernetes.io/control-plane' \
        -o name --kubeconfig KUBECONFIG_PATH
    
  2. Para verificar la lista de taints en un nodo, usa el siguiente comando:
    kubectl describe node NODE_NAME \
        --kubeconfig KUBECONFIG_PATH
    

    Si no se enumera ninguno de los taints necesarios, se verá afectado.

Solución alternativa

Usa los siguientes pasos para cada nodo del plano de control del clúster de la versión 1.14.0 afectado a fin de restablecer la función adecuada. Estos pasos son para el taint node-role.kubernetes.io/master:NoSchedule y los pods relacionados. Si deseas que los nodos del plano de control usen el taint PreferNoSchedule, ajusta los pasos según corresponda.

Operación, entorno de ejecución de VM en GDC 1.11, 1.12, 1.13, 1.14, 1.15, 1.16, 1.28, 1.29

La creación de la VM falla de forma intermitente con errores de carga

La creación de una máquina virtual (VM) nueva con el comando kubectl virt create vm falla con poca frecuencia durante la carga de imágenes. Este problema se aplica a las VMs de Linux y Windows. El error se parece al siguiente ejemplo:

PVC default/heritage-linux-vm-boot-dv not found DataVolume default/heritage-linux-vm-boot-dv created
Waiting for PVC heritage-linux-vm-boot-dv upload pod to be ready... Pod now ready
Uploading data to https://10.200.0.51

 2.38 MiB / 570.75 MiB [>----------------------------------------------------------------------------------]   0.42% 0s

fail to upload image: unexpected return value 500,  ...

Solución alternativa

Vuelve a ejecutar el comando kubectl virt create vm para crear tu VM.

Actualizaciones y actualizaciones, registro y supervisión 1.11

Los componentes de la colección administrada en los clústeres 1.11 no se conservan en las actualizaciones a la versión 1.12.

Los componentes de la colección administrada forman parte de Managed Service para Prometheus. Si implementaste manualmente los componentes de la recopilación administrada en el espacio de nombres gmp-system de los clústeres de la versión 1.11, los recursos asociados no se conservan cuando actualizas a la versión 1.12.

A partir de los clústeres de la versión 1.12.0, stackdriver-operator administra los componentes de Managed Service para Prometheus en el espacio de nombres gmp-system y las definiciones de recursos personalizados relacionadas con el campo enableGMPForApplications. El campo enableGMPForApplications se establece de forma predeterminada como true, por lo que, si implementas de forma manual los componentes de Managed Service para Prometheus en el espacio de nombres antes de actualizar a la versión 1.12, stackdriver-operator borrará los recursos.

Solución alternativa

Para conservar los recursos de recopilación administrada de forma manual, haz lo siguiente:

  1. Crea una copia de seguridad de todos los recursos personalizados de PodMonitoring existentes.
  2. Actualiza el clúster a la versión 1.12 y habilita el servicio administrado para Prometheus.
  3. Vuelve a implementar los recursos personalizados de PodMonitoring en tu clúster actualizado.
Revisiones y actualizaciones 1.13

Algunos clústeres de la versión 1.12 con el entorno de ejecución de contenedores de Docker no se pueden actualizar a la versión 1.13

Si a un clúster de la versión 1.12 que usa el entorno de ejecución del contenedor de Docker le falta la siguiente anotación, no se puede actualizar a la versión 1.13:

baremetal.cluster.gke.io/allow-docker-container-runtime:  "true"

Si te afecta este problema, bmctl escribe el siguiente error en el archivo upgrade-cluster.log dentro de la carpeta bmctl-workspace:

Operation failed, retrying with backoff. Cause: error creating "baremetal.cluster.gke.io/v1, Kind=Cluster": admission webhook
"vcluster.kb.io" denied the request: Spec.NodeConfig.ContainerRuntime: Forbidden: Starting with Anthos Bare Metal version 1.13 Docker container
runtime will not be supported. Before 1.13 please set the containerRuntime to containerd in your cluster resources.

Although highly discouraged, you can create a cluster with Docker node pools until 1.13 by passing the flag "--allow-docker-container-runtime" to bmctl
create cluster or add the annotation "baremetal.cluster.gke.io/allow-docker- container-runtime: true" to the cluster configuration file.

Es más probable que esto ocurra con los clústeres de Docker de la versión 1.12 que se actualizaron desde la versión 1.11, ya que esa actualización no requiere la anotación para mantener el entorno de ejecución del contenedor de Docker. En este caso, los clústeres no tienen la anotación cuando se actualizan a la versión 1.13. Ten en cuenta que, a partir de la versión 1.13, containerd es el único entorno de ejecución de contenedores permitido.

Solución alternativa:

Si te afecta este problema, actualiza el recurso del clúster con la anotación faltante. Puedes agregar la anotación mientras se ejecuta la actualización o después de cancelarla, y antes de reintentar la actualización.

Instalación 1.11

bmctl sale antes de que se complete la creación del clúster

La creación del clúster puede fallar en GDCV para la versión 1.11.0 de Bare Metal (este problema se solucionó en GDCV para la versión 1.11.1 de Bare Metal). En algunos casos, el comando bmctl create cluster se cierra antes de tiempo y escribe errores como los siguientes en los registros:

Error creating cluster: error waiting for applied resources: provider cluster-api watching namespace USER_CLUSTER_NAME not found in the target cluster

Solución alternativa

La operación con errores produce artefactos, pero el clúster no está operativo. Si este problema te afecta, sigue estos pasos para limpiar los artefactos y crear un clúster:

Instalación, entorno de ejecución de VM en GDC 1.11, 1.12

Error de conciliación del entorno de ejecución de la VM en los informes de instalación

La operación de creación del clúster puede informar un error similar al siguiente:

I0423 01:17:20.895640 3935589 logs.go:82]  "msg"="Cluster reconciling:" "message"="Internal error occurred: failed calling webhook \"vvmruntime.kb.io\": failed to call webhook: Post \"https://vmruntime-webhook-service.kube-system.svc:443/validate-vm-cluster-gke-io-v1vmruntime?timeout=10s\": dial tcp 10.95.5.151:443: connect: connection refused" "name"="xxx" "reason"="ReconciliationError"

Solución alternativa

Este error es benigno y puedes ignorarlo.

Instalación 1.10, 1.11, 1.12

La creación del clúster falla cuando se usan varias NIC, containerd y proxy HTTPS

La creación del clúster falla cuando tienes la siguiente combinación de condiciones:

  • El clúster está configurado para usar containerd como el entorno de ejecución del contenedor (nodeConfig.containerRuntime establecido en containerd en el archivo de configuración del clúster, el valor predeterminado de GDCV para Bare Metal versión 1.13 y superior).
  • El clúster está configurado con el fin de proporcionar varias interfaces de red, varias NIC, para Pods (clusterNetwork.multipleNetworkInterfaces configurado como true en el archivo de configuración del clúster).
  • El clúster está configurado para usar un proxy (se especifica spec.proxy.url en el archivo de configuración del clúster). Aunque la creación del clúster falle, esta configuración se propaga cuando intentas crear uno. Puedes ver esta configuración del proxy como una variable de entorno HTTPS_PROXY o en tu configuración containerd (/etc/systemd/system/containerd.service.d/09-proxy.conf).

Solución alternativa

Agrega CIDR de servicio (clusterNetwork.services.cidrBlocks) a la variable de entorno NO_PROXY en todas las máquinas de nodo.

Instalación 1.10, 1.11, 1.12

Errores en sistemas con configuración restrictiva de umask

GDCV para Bare Metal versión 1.10.0 introdujo una función de plano de control sin raíz que ejecuta todos los componentes del plano de control como un usuario no raíz. Ejecutar todos los componentes como un usuario no raíz puede causar fallas de instalación o actualización en sistemas con una configuración de umask más restrictiva de 0077.


Solución alternativa

Restablece los nodos del plano de control y cambia la configuración de umask a 0022 en todas las máquinas del plano de control. Después de actualizar las máquinas, vuelve a intentar la instalación.

Como alternativa, puedes cambiar los permisos de directorio y archivo de /etc/kubernetes en las máquinas del plano de control para que la instalación o actualización continúe.

  • Haz que /etc/kubernetes y todos sus subdirectorios sean legibles en todo el mundo: chmod o+rx.
  • Permite que todos los archivos que pertenecen al usuario root del directorio /etc/kubernetes (de manera recurrente) sean legibles para todo el mundo (chmod o+r). Excluye los archivos de claves privadas (.key) de estos cambios, ya que se crearon con la propiedad y los permisos correctos.
  • Haz que /usr/local/etc/haproxy/haproxy.cfg sea legible en todo el mundo.
  • Haz que /usr/local/etc/bgpadvertiser/bgpadvertiser-cfg.yaml sea legible en todo el mundo.
Instalación 1.10, 1.11, 1.12, 1.13

Incompatibilidad del grupo de control v2

El grupo de control v2 (cgroup v2) no es compatible con GKE en las versiones 1.13 y anteriores de los clústeres de Bare Metal de GDCV para Bare Metal. Sin embargo, la versión 1.14 admite cgroup v2 como función de Versión preliminar . La presencia de /sys/fs/cgroup/cgroup.controllers indica que tu sistema usa cgroup v2.


Solución alternativa

Si tu sistema usa cgroup v2, actualiza tu clúster a la versión 1.14.

Instalación 1.10, 1.11, 1.12, 1.13, 1.14, 1.15, 1.16, 1.28, 1.29

Verificaciones de comprobación previa y credenciales de cuentas de servicio

En el caso de las instalaciones activadas por clústeres híbridos o de administrador (en otras palabras, clústeres que no se crearon con bmctl, como los clústeres de usuario), la verificación previa no verifica las credenciales de la cuenta de servicio de Google Cloud ni sus permisos asociados.

Instalación 1.10, 1.11, 1.12, 1.13, 1.14, 1.15, 1.16, 1.28, 1.29

Realiza la instalación en vSphere

Cuando instalas GKE en clústeres Bare Metal en VMs de vSphere, debes desactivar las marcas tx-udp_tnl-segmentation y tx-udp_tnl-csum-segmentation. Estas marcas están relacionadas con la descarga de segmentación de hardware realizada por el controlador de vSphere VMXNET3 y no funcionan con el túnel GENEVE de GKE en los clústeres de Bare Metal.


Solución alternativa

Ejecuta el siguiente comando en cada nodo para verificar los valores actuales de estas marcas:

ethtool -k NET_INTFC | grep segm

Reemplaza NET_INTFC por la interfaz de red asociada con la dirección IP del nodo.

La respuesta debe tener entradas como las siguientes:

...
tx-udp_tnl-segmentation: on
tx-udp_tnl-csum-segmentation: on
...
A veces, en RHEL 8.4, ethtool muestra que estas marcas están desactivadas, pero no lo están. Para desactivar de forma explícita estas marcas, actívalas y, luego, desactívalas con los siguientes comandos:
ethtool -K ens192 tx-udp_tnl-segmentation on ethtool -K ens192 \
    tx-udp_tnl-csum-segmentation on
ethtool -K ens192 tx-udp_tnl-segmentation off ethtool -K ens192 \
    tx-udp_tnl-csum-segmentation off

Este cambio de marca no persiste en los reinicios. Configura las secuencias de comandos de inicio para establecer de forma explícita estas marcas cuando se inicie el sistema.

Revisiones y actualizaciones 1.10

bmctl no puede crear, actualizar ni restablecer clústeres de usuario de versiones anteriores

La CLI de bmctl no puede crear, actualizar ni restablecer un clúster de usuario con una versión secundaria anterior, sin importar la versión del clúster de administrador. Por ejemplo, no puedes usar bmctl con una versión de 1.N.X para restablecer un clúster de usuario de la versión 1.N-1.Y, incluso si el clúster de administrador también está en la versión 1.N.X.

Si te afecta este problema, deberías ver registros similares a los siguientes cuando uses bmctl:

[2022-06-02 05:36:03-0500] error judging if the cluster is managing itself: error to parse the target cluster: error parsing cluster config: 1 error occurred:

*   cluster version 1.8.1 isn't supported in bmctl version 1.9.5, only cluster version 1.9.5 is supported

Solución alternativa:

Usa kubectl para crear, editar o borrar el recurso personalizado del clúster de usuario dentro del clúster de administrador.

La capacidad de actualizar los clústeres de usuario no se ve afectada.

Revisiones y actualizaciones 1.12

Es posible que se detengan las actualizaciones del clúster a la versión 1.12.1

La actualización de los clústeres a la versión 1.12.1 a veces se detiene debido a que el servidor de la API no está disponible. Este problema afecta a todos los tipos de clústeres y a todos los sistemas operativos compatibles. Cuando ocurre este problema, el comando bmctl upgrade cluster puede fallar en varios puntos, incluso durante la segunda fase de las comprobaciones preliminares.


Solución alternativa

Puedes verificar tus registros de actualización para determinar si este problema te afecta. Los registros de actualización se encuentran en /baremetal/bmctl-workspace/CLUSTER_NAME/log/upgrade-cluster-TIMESTAMP de forma predeterminada.

upgrade-cluster.log puede contener errores como los siguientes:

Failed to upgrade cluster: preflight checks failed: preflight check failed
El registro de la máquina puede contener errores como los siguientes (las fallas reiteradas indican que te afecta este problema):
FAILED - RETRYING: Query CNI health endpoint (30 retries left). FAILED - RETRYING: Query CNI health endpoint (29 retries left).
FAILED - RETRYING: Query CNI health endpoint (28 retries left). ...

WorkManager y Keepalived deben ejecutarse en cada nodo del plano de control antes de que vuelvas a intentar actualizar tu clúster a la versión 1.12.1. Usa la interfaz de línea de comandos de crictl en cada nodo para verificar si los contenedores haproxy y keepalived se están ejecutando:

docker/crictl ps | grep haproxy docker/crictl ps | grep keepalived

Si MediaStore o Keepalived no se ejecutan en un nodo, reinicia kubelet en el nodo:

systemctl restart kubelet
Actualizaciones, entorno de ejecución de VM en GDC 1.11, 1.12

La actualización de clústeres a la versión 1.12.0 o posterior falla cuando el entorno de ejecución de VM en GDC está habilitado.

En la versión 1.12.0 de GKE en clústeres de Bare Metal, todos los recursos relacionados con el entorno de ejecución de VM en GDC se migran al espacio de nombres vm-system para admitir mejor el entorno de ejecución de VM en la versión de DG de GDC. Si tienes habilitado el entorno de ejecución de VM en GDC en un clúster de la versión 1.11.x o anterior, la actualización a la versión 1.12.0 o posterior fallará, a menos que primero inhabilites el entorno de ejecución de VM en GDC. Cuando te ves afectado por este problema, la operación de actualización informa el siguiente error:

Failed to upgrade cluster: cluster isn't upgradable with vmruntime enabled from
version 1.11.x to version 1.12.0: please disable VMruntime before upgrade to
1.12.0 and higher version

Solución alternativa

Para inhabilitar el entorno de ejecución de la VM en GDC, sigue estos pasos:

  1. Edita el recurso personalizado VMRuntime:
    kubectl edit vmruntime
    
  2. Establece enabled como false en la especificación:
    apiVersion: vm.cluster.gke.io/v1
    kind: VMRuntime
    metadata:
      name: vmruntime
    spec:
      enabled: false
      ...
    
  3. Guarda el recurso personalizado en tu editor.
  4. Una vez que se complete la actualización del clúster, vuelve a habilitar el entorno de ejecución de VM en GDC.

Para obtener más información, consulta Trabaja con cargas de trabajo basadas en VM.

Revisiones y actualizaciones 1.10, 1.11, 1.12

La actualización se detuvo en error during manifests operations

En algunas situaciones, las actualizaciones del clúster no se completan y la CLI de bmctl deja de responder. Este problema puede deberse a que un recurso se actualizó de forma incorrecta. Para determinar si te afecta este problema y corregirlo, consulta los registros anthos-cluster-operator y busca errores similares a las siguientes entradas:

controllers/Cluster "msg"="error during manifests operations" "error"="1 error occurred: ... {RESOURCE_NAME} is invalid: metadata.resourceVersion: Invalid value: 0x0: must be specified for an update

Estas entradas son un síntoma de un recurso actualizado de forma incorrecta, en el que {RESOURCE_NAME} es el nombre del recurso que causa problemas.


Solución alternativa

Si encuentras estos errores en tus registros, completa los siguientes pasos:

  1. Usa kubectl edit para quitar la anotación kubectl.kubernetes.io/last-applied-configuration del recurso contenido en el mensaje de registro.
  2. Guarda los cambios y aplícalos al recurso.
  3. Vuelve a intentar la actualización del clúster.
Revisiones y actualizaciones 1.10, 1.11, 1.12

Las actualizaciones están bloqueadas para los clústeres con funciones que usan la puerta de enlace de red para GDC

Las actualizaciones de los clústeres de la versión 1.10.x a la 1.11.x fallan para los clústeres que usan puerta de enlace NAT de salida o balanceo de cargas agrupado con BGP. Ambas funciones usan la puerta de enlace de red para GDC. Las actualizaciones del clúster se detienen en el mensaje de línea de comandos Waiting for upgrade to complete... y anthos-cluster-operator registra errores como los siguientes:

apply run failed ... MatchExpressions:[]v1.LabelSelectorRequirement(nil)}: field
is immutable...

Solución alternativa

Para desbloquear la actualización, ejecuta los siguientes comandos en el clúster que estás actualizando:

kubectl -n kube-system delete deployment \
    ang-controller-manager-autoscaler
kubectl -n kube-system delete deployment \
    ang-controller-manager
kubectl -n kube-system delete ds ang-node
Revisiones y actualizaciones 1.10, 1.11, 1.12, 1.13, 1.14, 1.15

bmctl update no quita los bloques de mantenimiento

El comando bmctl update no puede quitar ni modificar la sección maintenanceBlocks de la configuración de recursos del clúster.


Solución alternativa

Si deseas obtener más información, incluidas las instrucciones para quitar nodos del modo de mantenimiento, consulta Coloca nodos en modo de mantenimiento.

Operación 1.10, 1.11, 1.12

Nodos desacordonados si no usas el procedimiento del modo de mantenimiento

Si ejecutas clústeres de la versión 1.12.0 (anthosBareMetalVersion: 1.12.0) o anteriores y usas kubectl cordon de forma manual en un nodo, GKE en Bare Metal podría desacordonar el nodo antes de que estés listo en un esfuerzo por conciliar el estado esperado.


Solución alternativa

Para los clústeres de la versión 1.12.0 y anteriores, usa el modo de mantenimiento a fin de acordonar y vaciar los nodos de forma segura.

En la versión 1.12.1 (anthosBareMetalVersion: 1.12.1) o posterior, GKE en Bare Metal no desacordonará los nodos de forma inesperada cuando uses kubectl cordon.

Operación 1.11

Los clústeres de administrador de la versión 11 que usan una duplicación del registro no pueden administrar los clústeres de la versión 1.10

Si el clúster de administrador está en la versión 1.11 y usa una duplicación del registro, no puede administrar los clústeres de usuario que se encuentren en una versión secundaria inferior. Este problema afecta las operaciones de restablecimiento, actualización y actualización del clúster de usuario.

Para determinar si este problema te afecta, revisa tus registros en busca de operaciones de clúster, como crear, actualizar o restablecer. Estos registros se encuentran en la carpeta bmctl-workspace/CLUSTER_NAME/ de forma predeterminada. Si te afecta el problema, tus registros contienen el siguiente mensaje de error:

flag provided but not defined: -registry-mirror-host-to-endpoints
Operación 1.10, 1.11

El secreto de kubeconfig reemplazó

Cuando se ejecuta en clústeres de usuario, el comando bmctl check cluster reemplaza el Secreto de kubeconfig del clúster de usuario por el kubeconfig del clúster de administrador. Reemplazar el archivo provoca que las operaciones de clúster estándar, como la actualización y la actualización, fallen para los clústeres de usuario afectados. Este problema se aplica a las versiones 1.11.1 y anteriores del clúster de GKE en Bare Metal.

Para determinar si este problema afecta a un clúster de usuario, ejecuta el siguiente comando:

kubectl --kubeconfig ADMIN_KUBECONFIG \
    get secret -n USER_CLUSTER_NAMESPACE \
    USER_CLUSTER_NAME -kubeconfig \
    -o json  | jq -r '.data.value'  | base64 -d

Reemplaza lo siguiente:

  • ADMIN_KUBECONFIG: Es la ruta de acceso al archivo kubeconfig del clúster de administrador.
  • USER_CLUSTER_NAMESPACE: Es el espacio de nombres del clúster. De forma predeterminada, los espacios de nombres del clúster para los clústeres de GKE en Bare Metal son el nombre del clúster precedido por cluster-. Por ejemplo, si le asignas el nombre test a tu clúster, el espacio de nombres predeterminado es cluster-test.
  • USER_CLUSTER_NAME: Es el nombre del clúster de usuario que se verificará.

Si el nombre del clúster en el resultado (consulta contexts.context.cluster en el siguiente resultado de muestra) es el nombre del clúster de administrador, el clúster de usuario especificado se ve afectado.

apiVersion: v1
clusters:
- cluster:
    certificate-authority-data:LS0tLS1CRU...UtLS0tLQo=
    server: https://10.200.0.6:443
  name: ci-aed78cdeca81874
contexts:
- context:
    cluster: ci-aed78cdeca81
    user: ci-aed78cdeca81-admin
  name: ci-aed78cdeca81-admin@ci-aed78cdeca81
current-context: ci-aed78cdeca81-admin@ci-aed78cdeca81
kind: Config
preferences: {}
users:
- name: ci-aed78cdeca81-admin
  user:
    client-certificate-data: LS0tLS1CRU...UtLS0tLQo=
    client-key-data: LS0tLS1CRU...0tLS0tCg==

Solución alternativa

Sigue estos pasos para restablecer la función en un clúster de usuario afectado (USER_CLUSTER_NAME):

  1. Ubica el archivo kubeconfig del clúster de usuario. GKE en Bare Metal genera el archivo kubeconfig en la estación de trabajo de administrador cuando creas un clúster. De forma predeterminada, el archivo se encuentra en el directorio bmctl-workspace/USER_CLUSTER_NAME.
  2. Verifica que el kubeconfig sea el kubeconfig del clúster de usuario correcto:
    kubectl get nodes \
        --kubeconfig PATH_TO_GENERATED_FILE
    
    Reemplaza PATH_TO_GENERATED_FILE por la ruta de acceso al archivo kubeconfig del clúster de usuario. La respuesta muestra detalles sobre los nodos del clúster de usuario. Confirma que los nombres de las máquinas sean correctos para tu clúster.
  3. Ejecuta el siguiente comando para borrar el archivo kubeconfig dañado en el clúster de administrador:
    kubectl delete secret \
        -n USER_CLUSTER_NAMESPACE \
        USER_CLUSTER_NAME-kubeconfig
    
  4. Ejecuta el siguiente comando para volver a guardar el secreto de kubeconfig correcto en el clúster de administrador:
    kubectl create secret generic \
        -n USER_CLUSTER_NAMESPACE \
        USER_CLUSTER_NAME-kubeconfig \
        --from-file=value=PATH_TO_GENERATED_FILE
    
Operación 1.10, 1.11, 1.12, 1.13, 1.14, 1.15, 1.16, 1.28, 1.29

Captura una instantánea como usuario no raíz de acceso

Si usas containerd como entorno de ejecución del contenedor, ejecutar la instantánea como usuario no raíz requiere que /usr/local/bin esté en la ruta de acceso del usuario. De lo contrario, fallará con el error crictl: command not found.

Cuando no accedes como usuario raíz, sudo se usa para ejecutar los comandos de la instantánea. La ruta de acceso sudo puede diferir del perfil raíz y no puede contener /usr/local/bin.


Solución alternativa

Actualiza secure_path en /etc/sudoers para incluir /usr/local/bin. Como alternativa, crea un vínculo simbólico para crictl en otro directorio /bin.

Registro y supervisión 1.10

stackdriver-log-forwarder tiene [parser:cri] invalid time format registros de advertencia

Si el analizador de la interfaz de entorno de ejecución del contenedor (CRI) usa una expresión regular incorrecta para analizar el tiempo, los registros del Pod stackdriver-log-forwarder contienen errores y advertencias como los siguientes:

[2022/03/04 17:47:54] [error] [parser] time string length is too long [2022/03/04 20:16:43] [ warn] [parser:cri] invalid time format %Y-%m-%dT%H:%M:%S.%L%z for '2022-03-04T20:16:43.680484387Z'

Solución alternativa:

Registro y supervisión 1.10, 1.11, 1.12, 1.13, 1.14, 1.15

Facturación de supervisión inesperada

Para las versiones de 1.10 a 1.15 del clúster de GKE en Bare Metal, algunos clientes encontraron una facturación inesperadamente alta para Metrics volume en la página Facturación. Este problema te afecta solo cuando se cumplen 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

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


Solución alternativa

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

  • Marcas separadas para controlar la recopilación de los registros de la aplicación y las métricas de la aplicación
  • Google Cloud Managed Service para Prometheus
  • Si no puedes actualizar a la versión 1.12, sigue estos pasos:

    1. Busca los Pods y Services de origen que tienen la facturación no deseada:
      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 Service.
    Registro y supervisión 1.11, 1.12, 1.13, 1.14, 1.15, 1.16, 1.28

    Los cambios en metrics-server-config no se conservan

    En casos extremos, una densidad alta de Pods puede crear una sobrecarga excesiva de registro y supervisión, lo que puede hacer que el servidor de métricas se detenga y se reinicie. Puedes editar el ConfigMap metrics-server-config para asignar más recursos y mantener en ejecución el servidor de métricas. Sin embargo, debido a la conciliación, las ediciones realizadas en metrics-server-config pueden revertirse al valor predeterminado durante una operación de actualización o actualización del clúster. El servidor de métricas no se ve afectado de inmediato, pero la próxima vez que se reinicia, recoge el ConfigMap revertido y vuelve a ser vulnerable a una sobrecarga excesiva.


    Solución alternativa

    Para la versión 1.11.x, puedes crear una secuencia de comandos de edición del ConfigMap y realizarla junto con actualizaciones del clúster. Para la versión 1.12 y posteriores, comunícate con el equipo de asistencia.

    Registro y supervisión 1.11, 1.12

    Las métricas obsoletas afectan el panel de Cloud Monitoring

    Varias métricas de GKE en Bare Metal dejaron de estar disponibles y, a partir de GDCV para Bare Metal versión 1.11, ya no se recopilan datos para estas métricas obsoletas. Si usas estas métricas en alguna de tus políticas de alertas, no habrá ningún dato para activar la condición de alerta.

    En la siguiente tabla, se enumeran las métricas individuales que dejaron de estar disponibles y la métrica que las reemplaza.

    Métricas obsoletas Métrica de reemplazo
    kube_daemonset_updated_number_scheduled kube_daemonset_status_updated_number_scheduled
    kube_node_status_allocatable_cpu_cores
    kube_node_status_allocatable_memory_bytes
    kube_node_status_allocatable_pods
    kube_node_status_allocatable
    kube_node_status_capacity_cpu_cores
    kube_node_status_capacity_memory_bytes
    kube_node_status_capacity_pods
    kube_node_status_capacity

    En las versiones anteriores a 1.11 del clúster de GKE en Bare Metal, el archivo de definición de la política para la alerta de Anthos on baremetal node cpu usage exceeds 80 percent (critical) recomendada usa las métricas obsoletas. El archivo de definición JSON node-cpu-usage-high.json se actualiza para las versiones 1.11.0 y posteriores.


    Solución alternativa

    Sigue estos pasos para migrar a las métricas de reemplazo:

    1. En la consola de Google Cloud, selecciona Monitoring o haz clic en el siguiente botón:
      Ir a Monitoring
    2. En el panel de navegación, selecciona Paneles y borra el panel Estado del nodo del clúster de Anthos (Anthos cluster node status).
    3. Haz clic en la pestaña Biblioteca de muestra y vuelve a instalar el panel Estado del nodo del clúster de Anthos.
    4. Sigue las instrucciones que se indican en Crea políticas de alertas para crear una política con el archivo de definición de política node-cpu-usage-high.json actualizado.
    Registro y supervisión 1.10, 1.11

    stackdriver-log-forwarder tiene errores CrashloopBackOff

    En algunas situaciones, el agente de registro fluent-bit puede atascarse procesando fragmentos dañados. Cuando el agente de Logging no puede omitir los fragmentos dañados, es posible que observes que stackdriver-log-forwarder sigue fallando con un error CrashloopBackOff. Si tienes este problema, tus registros tienen entradas como las siguientes

    [2022/03/09 02:18:44] [engine] caught signal (SIGSEGV) #0  0x5590aa24bdd5
    in  validate_insert_id() at plugins/out_stackdriver/stackdriver.c:1232
    #1  0x5590aa24c502      in  stackdriver_format() at plugins/out_stackdriver/stackdriver.c:1523
    #2  0x5590aa24e509      in  cb_stackdriver_flush() at plugins/out_stackdriver/stackdriver.c:2105
    #3  0x5590aa19c0de      in  output_pre_cb_flush() at include/fluent-bit/flb_output.h:490
    #4  0x5590aa6889a6      in  co_init() at lib/monkey/deps/flb_libco/amd64.c:117 #5  0xffffffffffffffff  in  ???() at ???:0
    

    Solución alternativa:

    Limpia los fragmentos del búfer del servidor de reenvío de registros de Stackdriver.

    Nota: En los siguientes comandos, reemplaza KUBECONFIG por la ruta de acceso al archivo kubeconfig del clúster de administrador.

    1. Finaliza todos los Pods stackdriver-log-forwarder:
      kubectl --kubeconfig KUBECONFIG -n kube-system patch daemonset \
          stackdriver-log-forwarder -p \
          '{"spec": {"template": {"spec": {"nodeSelector": {"non-existing": "true"}}}}}'
      
      Verifica que los Pods stackdriver-log-forwarder se hayan borrado antes de continuar con el siguiente paso.
    2. Implementa el siguiente DaemonSet para limpiar los datos dañados en los búferes fluent-bit:
      kubectl --kubeconfig KUBECONFIG -n kube-system apply -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. Usa los siguientes comandos para verificar que el DaemonSet limpió todos los nodos:
      kubectl --kubeconfig KUBECONFIG logs \
          -n kube-system -l \
          app=fluent-bit-cleanup | grep "cleaned up" | wc -l
      kubectl --kubeconfig KUBECONFIG -n \
          kube-system get pods -l \
          app=fluent-bit-cleanup --no-headers | wc -l
      
      El resultado de los dos comandos debe ser igual a la cantidad de nodos en tu clúster.
    4. Borra el DaemonSet de limpieza:
      kubectl --kubeconfig KUBECONFIG -n \
          kube-system delete ds fluent-bit-cleanup
      
    5. Reinicia los Pods del servidor de reenvío de registros:
      kubectl --kubeconfig KUBECONFIG \
          -n kube-system patch daemonset \
          stackdriver-log-forwarder --type json \
          -p='[{"op": "remove", "path": "/spec/template/spec/nodeSelector/non-existing"}]'
      
    Registro y supervisión 1.10, 1.11, 1.12, 1.13, 1.14, 1.15, 1.16, 1.28

    Error de métricas desconocidas en el registro de gke-metrics-agent

    gke-metrics-agent es un daemonset que recopila métricas en cada nodo y las reenvía a Cloud Monitoring. Puede generar registros como los siguientes:

    Unknown metric: kubernetes.io/anthos/go_gc_duration_seconds_summary_percentile
    

    Pueden ocurrir errores similares con otros tipos de métricas, entre los que se incluyen los siguientes:

    • apiserver_admission_step_admission_duration_seconds_summary
    • go_gc_duration_seconds
    • scheduler_scheduling_duration_seconds
    • gkeconnect_http_request_duration_seconds_summary
    • alertmanager_nflog_snapshot_duration_seconds_summary

    Estos registros de errores se pueden ignorar de forma segura, ya que las métricas a las que hacen referencia no son compatibles y no son fundamentales para la supervisión.

    Registro y supervisión 1.10, 1.11

    Interrupciones intermitentes en la exportación de métricas

    Es posible que los clústeres de GKE en Bare Metal experimenten interrupciones en la exportación continua y normal de métricas, o bien métricas faltantes en algunos nodos. Si este problema afecta a los clústeres, es posible que veas brechas en los datos de las siguientes métricas (como mínimo):

    • 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

    Actualiza los clústeres a la versión 1.11.1 o posterior.

    Si no puedes actualizar, realiza los siguientes pasos como una solución alternativa:

    1. Abre el recurso stackdriver para editar:
      kubectl -n kube-system edit stackdriver stackdriver
      
    2. Para aumentar la solicitud de CPU de gke-metrics-agent de 10m a 50m, agrega la siguiente sección resourceAttrOverride al manifiesto de stackdriver:
      spec:
        resourceAttrOverride:
          gke-metrics-agent/gke-metrics-agent:
            limits:
              cpu: 100m
              memory: 4608Mi
            requests:
              cpu: 50m
              memory: 200Mi
      
      spec:
        anthosDistribution: baremetal
        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: 100m
              memory: 4608Mi
            requests:
              cpu: 50m
              memory: 200Mi
      
    3. Guarda los cambios y cierra el editor de texto.
    4. Para verificar que se hayan aplicado los cambios, ejecuta el siguiente comando:
      kubectl -n kube-system get daemonset \
          gke-metrics-agent -o yaml | grep "cpu: 50m"
      
      El comando encuentra cpu: 50m si tus ediciones se aplicaron.
    Herramientas de redes 1.10

    Múltiples puertas de enlace predeterminadas interrumpen la conectividad a extremos externos

    Tener varias puertas de enlace predeterminadas en un nodo puede causar una conectividad interrumpida desde un Pod hasta extremos externos, como google.com.

    Para determinar si te afecta este problema, ejecuta el siguiente comando en el nodo:

    ip route show
    

    Varias instancias de default en la respuesta indican que te ves afectado.

    Herramientas de redes 1.12

    Se reemplazan las ediciones de recursos personalizados de las Herramientas de redes en los clústeres de usuario

    La versión 1.12.x de GKE en clústeres de Bare Metal no te impide editar manualmente los recursos personalizados de las redes en tu clúster de usuario. GKE en Bare Metal concilia los recursos personalizados en los clústeres de usuario con los recursos personalizados en el clúster de administrador durante las actualizaciones del clúster. Esta conciliación reemplaza cualquier edición realizada directamente en los recursos personalizados de red en el clúster de usuario. Los recursos personalizados de herramientas de redes se deben modificar solo en el clúster de administrador, pero los clústeres de la versión 1.12.x no aplican este requisito.

    Las funciones de herramientas de redes avanzadas, como el balanceo de cargas agrupado con BGP, la puerta de enlace NAT de salida, las redes de SR-IOV, el modo plano con BGP y la de múltiples NIC para Pods usan los siguientes recursos personalizados:

    • BGPLoadBalancer
    • BGPPeer
    • NetworkGatewayGroup
    • NetworkAttachmentDefinition
    • ClusterCIDRConfig
    • FlatIPMode

    Edita estos recursos personalizados en el clúster de administrador y el paso de conciliación aplica los cambios a los clústeres de usuario.


    Solución alternativa

    Si modificaste alguno de los recursos personalizados mencionados anteriormente en un clúster de usuario, modifica los recursos personalizados correspondientes en tu clúster de administrador para que coincidan antes de la actualización. Este paso garantiza que se conserven los cambios de configuración. Las versiones 1.13.0 y posteriores de los clústeres de GKE en Bare Metal evitan que modifiques los recursos personalizados de red en los clústeres de usuario directamente.

    Herramientas de redes 1.10, 1.11, 1.12, 1.13, 1.14, 1.15, 1.16, 1.28

    Fallas de conectividad del Pod y filtrado de la ruta de acceso inversa

    GKE en Bare Metal configura el filtrado de ruta inversa en los nodos para inhabilitar la validación de la fuente (net.ipv4.conf.all.rp_filter=0). Si la configuración rp_filter se cambia a 1 o 2, los Pods fallarán debido a los tiempos de espera de la comunicación fuera del nodo.

    El filtrado de rutas de acceso inversas se establece con los archivos rp_filter en la carpeta de configuración IPv4 (net/ipv4/conf/all). sysctl también puede anular este valor, ya que almacena los ajustes del filtrado de rutas de acceso inversas en un archivo de configuración de seguridad de red, como /etc/sysctl.d/60-gce-network-security.conf.


    Solución alternativa

    La conectividad del Pod se puede restablecer mediante una de las siguientes soluciones alternativas:

    Vuelve a establecer el valor de net.ipv4.conf.all.rp_filter en 0 de forma manual y, luego, ejecuta sudo sysctl -p para aplicar el cambio.

    O

    Reinicia el Pod anetd para volver a establecer net.ipv4.conf.all.rp_filter como 0. Para reiniciar el Pod anetd, usa los siguientes comandos a fin de ubicar y borrar el Pod anetd, y se iniciará un Pod anetd nuevo en su lugar:

    kubectl get pods -n kube-system kubectl delete pods -n kube-system ANETD_XYZ
    

    Reemplaza ANETD_XYZ por el nombre del Pod anetd.

    Después de implementar cualquiera de las soluciones alternativas, verifica que el valor net.ipv4.conf.all.rp_filter se establezca en 0 mediante la ejecución de sysctl net.ipv4.conf.all.rp_filter en cada nodo.

    Herramientas de redes 1.10, 1.11, 1.12, 1.13, 1.14, 1.15, 1.16, 1.28, 1.29

    Las direcciones IP del clúster de arranque (tipo) y las direcciones IP del nodo del clúster se superponen

    192.168.122.0/24 y 10.96.0.0/27 son los CIDR predeterminados del Pod y del servicio que usa el clúster de arranque (tipo). Las comprobaciones preliminares fallarán si se superponen con las direcciones IP de la máquina del nodo del clúster.


    Solución alternativa

    Para evitar el conflicto, puedes pasar las marcas --bootstrap-cluster-pod-cidr y --bootstrap-cluster-service-cidr a bmctl para especificar valores diferentes.

    Sistema operativo 1.10, 1.11, 1.12, 1.13, 1.14, 1.15, 1.16, 1.28

    La creación o actualización del clúster falla en CentOS

    En diciembre de 2020, la comunidad de CentOS y Red Hat anunciaron la baja de CentOS. El 31 de enero de 2022, CentOS 8 alcanzó su final del ciclo de vida (EOL). Como resultado del EOL, los repositorios de yum dejaron de funcionar para CentOS, lo que provoca que las operaciones de creación y actualización de clústeres fallen. Esto se aplica a todas las versiones compatibles de CentOS y afecta a todas las versiones de GKE en clústeres de Bare Metal.


    Solución alternativa

    Seguridad 1.10, 1.11, 1.12, 1.13, 1.14, 1.15, 1.16, 1.28

    El contenedor no puede escribir en VOLUME definido en Dockerfile con containerd y SELinux

    Si usas containerd como entorno de ejecución del contenedor y tu sistema operativo tiene SELinux habilitado, es posible que el VOLUME definido en el Dockerfile de la aplicación no se pueda escribir. Por ejemplo, los contenedores compilados con el siguiente Dockerfile no pueden escribir en la carpeta /tmp.

    FROM ubuntu:20.04 RUN chmod -R 777 /tmp VOLUME /tmp
    

    Para verificar si te afecta este problema, ejecuta el siguiente comando en el nodo que aloja el contenedor problemático:

    ausearch -m avc
    

    Si te afecta este problema, verás un error denied como el siguiente:

    time->Mon Apr  4 21:01:32 2022 type=PROCTITLE msg=audit(1649106092.768:10979): proctitle="bash" type=SYSCALL msg=audit(1649106092.768:10979): arch=c000003e syscall=257 success=no exit=-13 a0=ffffff9c a1=55eeba72b320 a2=241 a3=1b6 items=0 ppid=75712 pid=76042 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=4294967295 comm="bash" exe="/usr/bin/bash" subj=system_u:system_r:container_t:s0:c701,c935 key=(null) type=AVC msg=audit(1649106092.768:10979): avc:  denied { write } for  pid=76042 comm="bash" name="aca03d7bb8de23c725a86cb9f50945664cb338dfe6ac19ed0036c" dev="sda2" ino=369501097 scontext=system_u:system_r: container_t:s0:c701,c935 tcontext=system_u:object_r: container_ro_file_t:s0 tclass=dir permissive=0
    

    Solución alternativa

    Para solucionar el problema, realiza uno de los siguientes cambios:

    • Desactiva SELinux.
    • No uses la función VOLUME dentro del Dockerfile.
    Revisiones y actualizaciones 1.10, 1.11, 1.12

    El detector de problemas de nodos no está habilitado de forma predeterminada después de las actualizaciones del clúster.

    Cuando actualizas GKE en clústeres de Bare Metal, el detector de problemas de nodos no está habilitado de forma predeterminada. Este problema se aplica a las actualizaciones de la versión 1.10 a la 1.12.1 y se corrigió en la versión 1.12.2.


    Solución alternativa:

    Para habilitar el detector de problemas de nodos, sigue estos pasos:

    1. Verifica si el servicio node-problem-detector systemd se está ejecutando en el nodo.
      1. Usa el comando SSH y conéctate al nodo.
      2. Verifica si se está ejecutando el servicio node-problem-detector systemd en el nodo:
        systemctl is-active node-problem-detector
        
        Si el resultado del comando muestra inactive, significa que el detector de problemas del nodo no se está ejecutando en el nodo.
    2. Para habilitar el detector de problemas de nodos, usa el comando kubectl edit y edita el ConfigMap de node-problem-detector-config. Para obtener más información, consulta Detector de problemas de nodos.
    Operación 1.9, 1.10

    La copia de seguridad del clúster falla cuando se usa un acceso que no es raíz

    El comando bmctl backup cluster falla si nodeAccess.loginUser se configura como un nombre de usuario que no es raíz].


    Solución alternativa:

    Este problema se aplica a las versiones 1.9.x, 1.10.0 y 1.10.1, y se corrige en las versiones 1.10.2 y posteriores.

    Herramientas de redes 1.10, 1.11, 1.12

    Los servicios del balanceador de cargas no funcionan con contenedores en la red del host del plano de control

    Hay un error en anetd en el que los paquetes se descartan para los servicios de LoadBalancer si los Pods de backend se ejecutan en el nodo del plano de control y usan el campo hostNetwork: true en las especificaciones del contenedor.

    El error no está presente en la versión 1.13 ni en versiones posteriores.


    Solución alternativa:

    Las siguientes soluciones alternativas pueden ser útiles si usas un servicio LoadBalancer respaldado por Pods hostNetwork:

    1. Ejecútalas en nodos trabajadores (no en nodos del plano de control).
    2. Usa externalTrafficPolicy: local en la especificación del servicio y asegúrate de que tus cargas de trabajo se ejecuten en los nodos del balanceador de cargas.
    Actualizaciones 1.12, 1.13

    El Pod de anthos-version-$version$ huérfano no pudo extraer la imagen

    El clúster que se actualiza de 1.12.x a 1.13.x puede observar un Pod anthos-version-$version$ con errores con el error ImagePullBackOff. Esto sucede debido a que se actualiza la condición de carrera de anthos-cluster-operator y no debería afectar ninguna capacidad normal del clúster.

    El error no está presente después de la versión 1.13 o posterior.


    Solución alternativa:

    Borra el trabajo de dynamic-version-installer mediante kubectl delete job anthos-version-$version$ -n kube-system .

    Revisiones y actualizaciones 1.13

    Los clústeres 1.12 actualizados de la versión 1.11 no se pueden actualizar a la versión 1.13.0

    Los clústeres de la versión 1.12 que se actualizaron desde la versión 1.11 no se pueden actualizar a la versión 1.13.0. Este problema de actualización no se aplica a los clústeres que se crearon en la versión 1.12.

    Para determinar si te ves afectado, verifica los registros del trabajo de actualización que contiene la cadena upgrade-first-no* en el clúster de administrador. Si ves el siguiente mensaje de error, esto te afecta.

    TASK [kubeadm_upgrade_apply : Run kubeadm upgrade apply] *******
    ...
    [upgrade/config] FATAL: featureGates: Invalid value: map[string]bool{\"IPv6DualStack\":false}: IPv6DualStack isn't a valid feature name.
    ...
    

    Solución alternativa:

    Para solucionar este problema, haz lo siguiente:

    1. Ejecuta los siguientes comandos en la estación de trabajo de administrador:
      echo '[{ "op": "remove", "path": \
          "/spec/clusterConfiguration/featureGates" }]' \
          > remove-feature-gates.patch
      export KUBECONFIG=$ADMIN_KUBECONFIG
      kubectl get kubeadmconfig -A --no-headers | xargs -L1 bash -c \
          'kubectl patch kubeadmconfig $1 -n $0 --type json \
          --patch-file remove-feature-gates.patch'
      
    2. Vuelve a intentar actualizar el clúster.
    Logging y Monitoring 1.16.2, 1.16.3

    Uso elevado de CPU para stackdriver-operator

    Hay un problema en stackdriver-operator que hace que consuma más tiempo de CPU de lo normal. El uso normal de CPU es inferior a 50 millicores de CPU (50m) para stackdriver-operator en estado inactivo. La causa es una discrepancia de los recursos de certificado que stackdriver-operator aplica con las expectativas de cert-manager. Esta discrepancia genera una condición de carrera entre cert-manager y stackdriver-operator en la actualización de esos recursos.

    Este problema puede reducir el rendimiento en los clústeres con disponibilidad de CPU limitada.


    Solución alternativa:

    Hasta que puedas actualizar a una versión que haya corregido este error, usa la siguiente solución alternativa:

    1. Para reducir temporalmente la escala de stackdriver-operator a 0 réplicas, aplica un recurso personalizado AddonConfiguration:
      kubectl scale deploy stackdriver-operator --replicas=0
      
    2. Una vez que hayas actualizado a una versión que corrija este problema, vuelve a escalar stackdriver-operator:
      kubectl scale deploy stackdriver-operator --replicas=1
      
    Logging y Monitoring 1.16.0, 1.16.1

    El scraping de métricas basadas en anotaciones no funciona

    En el GDCV para la versión secundaria de Bare Metal 1.16, el campo enableStackdriverForApplications en la especificación de recursos personalizados stackdriver dejó de estar disponible. Este campo se reemplazó por dos campos, enableCloudLoggingForApplications y enableGMPForApplications, en el recurso personalizado de Stackdriver.

    Te recomendamos que uses Google Cloud Managed Service para Prometheus a fin de supervisar tus cargas de trabajo. Usa el campo enableGMPForApplications para habilitar esta función.

    Si dependes de la recopilación de métricas activada por anotaciones prometheus.io/scrape en tus cargas de trabajo, puedes usar la marca de puerta de atributos annotationBasedApplicationMetrics para mantener el comportamiento anterior. Sin embargo, hay un problema que impide que annotationBasedApplicationMetrics funcione correctamente, lo que impide la recopilación de métricas de tus aplicaciones en Cloud Monitoring.


    Solución alternativa:

    Para resolver este problema, actualiza tu clúster a la versión 1.16.2 o superior.

    La recopilación de métricas de carga de trabajo basadas en anotaciones que permite la puerta de funciones annotationBasedApplicationMetrics recopila métricas de los objetos que tienen la anotación prometheus.io/scrape. Muchos sistemas de software con origen de código abierto pueden usar esta anotación. Si continúas usando este método de recopilación de métricas, ten en cuenta esta dependencia para que no te sorprendan los cargos de métricas en Cloud Monitoring.

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