s <0x0

En esta página, se enumeran todos los problemas conocidos de Google Distributed Cloud (solo software) para Bare Metal (antes conocido como Google Distributed Cloud Virtual y, anteriormente, como clústeres de Anthos alojados en Bare Metal).

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

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

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

Selecciona tu versión de Google Distributed Cloud:

1.34 1.33 1.32 1.31 1.30 1.29 1.28 1.16 1.15 1.14 1.13 1.12 1.11 1.10

Selecciona la categoría del problema:

Configuración Instalación Revisiones y actualizaciones Operación Registro y supervisión Redes Seguridad Restablecimiento/eliminación Entorno de ejecución de VM en GDC

O bien, busca tu problema:

Categoría	Versiones identificadas	Problema y solución
Herramientas de redes, actualizaciones y revisiones	1.30 y versiones posteriores	El Pod de Istiod no alcanza el estado de preparación durante las actualizaciones La función de Ingress incluida en Google Distributed Cloud usa istiod. Esta función no usa definiciones de recursos personalizados definidas por Istio. Sin embargo, debido a que el código utilizado es de código abierto, los Pods son sensibles a las instalaciones de Istio que puedas tener para tus propios casos de uso. Si no hay definiciones de recursos personalizados de Istio en los clústeres, Istiod se declara listo sin esperar las definiciones de recursos personalizados. Sin embargo, si hay definiciones de recursos personalizados v1beta en el clúster, Istiod espera a que haya definiciones de recursos personalizados v1 antes de declarar que está listo. Como resultado, es posible que el Pod de Istiod no alcance el estado de preparación, lo que provocará que fallen las actualizaciones del clúster. Verificación: Para confirmar si tu clúster está afectado, verifica el estado del pod de Istiod en el espacio de nombres gke-system: kubectl get pods -n gke-system -l app=istiod Si el estado del pod es Running, pero la verificación de preparación falla (por ejemplo, 0/1 listo), es probable que tu clúster esté afectado. Solución alternativa: Para resolver este problema, usa una de las siguientes soluciones alternativas: Implementa manualmente las definiciones de recursos personalizados v1 de Istio en tu clúster. Inhabilita la función de entrada agrupada si no la usas.
Instalación, actualizaciones y revisiones	1.30.400 y versiones anteriores	lifecycle-controllers-manager falla cuando se verifican los recursos personalizados de PreflightCheck Los clústeres de la versión 1.30.400 o anterior pueden experimentar fallas en los pods de lifecycle-controllers-manager cuando se validan recursos personalizados de PreflightCheck. Estas fallas detienen el aprovisionamiento y las actualizaciones de clústeres. Este problema se produce debido a una desreferencia de puntero nulo durante la validación de recursos de PreflightCheck. Solución alternativa: Para permitir que se aprovisionen o actualicen los clústeres, omite las verificaciones previas. Establece el campo bypassPreflightCheck en true en el archivo de configuración del clúster: spec: bypassPreflightCheck: true Para obtener más información, consulta Omite las verificaciones previas cuando apliques recursos de Kubernetes.
Operación, restablecimiento/eliminación	1.33 y versiones anteriores	Node Problem Detector no se inicia después de restablecer el clúster Cuando restableces un clúster con bmctl restore cluster, el servicio systemd de Node Problem Detector (NPD) no se inicia en los nodos después de que se completa la operación de restablecimiento. Para verificar si te afecta, ejecuta systemctl is-active node-problem-detector en los nodos del clúster después de una operación de restablecimiento. Si el comando devuelve inactive, significa que te afecta este problema. Solución alternativa: Para restablecer la NPD, haz lo siguiente: Inhabilita el NPD según el proceso que se describe en Cómo habilitar y inhabilitar el Detector de problemas del nodo. Habilita NPD según el proceso que se describe en Cómo habilitar o inhabilitar el Detector de problemas del nodo. Inhabilitar y habilitar NPD activa de forma explícita los trabajos del implementador de NPD, que instalan el servicio de NPD en todos los nodos.
Operación de redes	1.28 y versiones anteriores, 1.29.0 a 1.29.700, 1.30.0 a 1.30.300	Los Pods del balanceador de cargas del plano de control se reinician cada 7 días En los clústeres que usan el balanceador de cargas de capa 2 incluido, es posible que observes errores de "Conexión rechazada" o una breve falta de disponibilidad del servidor de la API (aproximadamente 1 minuto) cada 7 días. Este comportamiento se produce porque los Pods haproxy y keepalived en los nodos del plano de control se reinician debido a un parámetro de configuración de tiempo de vida del trabajo. Este problema afecta a los clústeres en las versiones 1.29.0 a 1.29.700, 1.30.0 a 1.30.300 y 1.28 y anteriores. Verificación: Para confirmar que tu clúster se ve afectado por este problema específico, verifica la configuración del trabajo de actualización del balanceador de cargas completando los siguientes pasos: Busca el nombre del trabajo de actualización: kubectl get jobs -n kube-system | grep bm-system-cplb-update Verifica el parámetro de configuración del tiempo de actividad del trabajo: kubectl get job JOB_NAME -n kube-system -o jsonpath='{.spec.ttlSecondsAfterFinished}' Reemplaza JOB_NAME por el nombre que se devolvió en el paso anterior. Si el resultado es 604800 (que equivale a 7 días en segundos), tu clúster se ve afectado por este problema. Solución alternativa: Para evitar los reinicios semanales, aplica parches manualmente al campo ttlSecondsAfterFinished en los trabajos de actualización del balanceador de cargas existentes con un valor más grande. Para ello, completa los siguientes pasos: Edita el trabajo de actualización del balanceador de cargas: kubectl edit job JOB_NAME -n kube-system En el editor, busca el campo ttlSecondsAfterFinished y cambia el valor a 7776000 (aproximadamente 90 días). Guarda los cambios y sal del editor para aplicarlos.
Operación	1.32.0-1.32.700, 1.33.0-1.33.300, 1.34.0	El pod cluster-operator falla con una eliminación de referencia de puntero nulo Es posible que el pod cluster-operator falle o entre en un bucle de fallas debido a un error de pánico: assignment to entry in nil map en un controlador. Esto puede ocurrir cuando el controlador intenta actualizar las anotaciones en un recurso personalizado, como un NodePool, que no tiene ninguna anotación (mapa nulo). Solución alternativa: Para evitar el pánico, asegúrate de que el recurso personalizado (por ejemplo, NodePool) tenga al menos una anotación. Puedes agregar una anotación ficticia con el siguiente comando: kubectl annotate nodepool NODEPOOL_NAME \ -n CLUSTER_NAMESPACE dummy-annotation="added-manually" --overwrite \ --kubeconfig=ADMIN_KUBECONFIG Reemplaza lo siguiente: NODEPOOL_NAME: Es el nombre del recurso personalizado NodePool. CLUSTER_NAMESPACE: Es el espacio de nombres del clúster. ADMIN_KUBECONFIG: Es la ruta al archivo kubeconfig del clúster de administrador.
Revisiones y actualizaciones	1.34.0	La actualización del nodo de trabajador falla debido a una discrepancia en el nombre de host Las actualizaciones de los nodos de trabajo fallan debido a una regresión (kubernetes/kubeadm#3244) en kubeadm. La regresión se produce cuando el nombre de host de Linux no coincide con el valor de la etiqueta kubernetes.io/hostname en los nodos de Kubernetes correspondientes. Para confirmar que el nodo afectado falla, usa journalctl de la siguiente manera: [root@vm-lb-0--40b1a328a3448f5-112eaaafe1beedad ~]# journalctl -t kubeadm La respuesta debería ser similar al siguiente ejemplo: Dec 09 20:09:50 vm-lb-0--40b1a328a3448f5-112eaaafe1beedad kubeadm[3684235]: error: error execution phase kubelet-config: could not remove the CRI socket annotation from Node "vm-lb-0--40b1a328a3448f5-112eaaafe1beedad": nodes "vm-lb-0--40b1a328a3448f5-112eaaafe1beedad" not found En este ejemplo, el nombre de host de Linux que se informa en la respuesta de journalctl no coincide con la etiqueta kubernetes.io/hostname del nodo, lo que confirma que la actualización se ve afectada por este problema: kubectl get nodes lb-0--40b1a328a3448f5-112eaaafe1beedad.lab.anthos \ -ojsonpath='{.metadata.labels.kubernetes\.io\/hostname}' La respuesta: lb-0--40b1a328a3448f5-112eaaafe1beedad.lab.anthos Solución alternativa: Para que el nodo afectado complete la actualización, intenta cambiar temporalmente el nombre de host para que coincida con el valor de la etiqueta kubernetes.io/hostname en los nodos de Kubernetes correspondientes, de manera similar a lo siguiente: [root@vm-lb-0--40b1a328a3448f5-112eaaafe1beedad ~]# hostname lb-0--40b1a328a3448f5-112eaaafe1beedad.lab.anthos
Redes	1.34.0	La migración gradual descarta las conexiones existentes en el acordonamiento de nodos Cuando habilitas la conmutación por error rápida de NAT de salida, el aislamiento de un nodo de puerta de enlace con kubectl cordon <NODE_NAME> inicia una migración correcta que mantiene las conexiones de salida existentes. Sin embargo, en la versión 1.34.0 de Google Distributed Cloud que solo usa software, la función de migración correcta no funciona según lo previsto. Si un administrador aísla un nodo de puerta de enlace de salida activo en un clúster de la versión 1.34.0 que usa la conmutación por error rápida, el aislamiento se comporta como una falla no planificada del nodo y finaliza de inmediato todas las conexiones con estado existentes en ese nodo. Solución alternativa: No hay una solución para este problema.
Redes	1.32.0	Errores de comunicación del Service ClusterIP Los servicios ClusterIP pueden experimentar conexiones intermitentes o fallidas cuando el tráfico se direcciona a Pods de backend en diferentes nodos. Esta falla de comunicación se debe a una regresión en Cilium v1.15 que provocó la eliminación de las reglas de CILIUM_POST_nat de iptables. Las reglas de CILIUM_POST_nat son necesarias para la traducción de direcciones de red de origen (SNAT), y su eliminación genera un enmascaramiento poco confiable por parte de kube-proxy, lo que provoca fallas en la comunicación del servicio ClusterIP. Por ejemplo, si estás actualizando un clúster y la operación se detiene, es posible que veas mensajes de registro como los siguientes, que indican que se agotó el tiempo de espera del protocolo de enlace TLS mientras el servicio ClusterIP intentaba conectarse al servidor de la API en el grupo de nodos np1: I0527 15:42:39.261368 372146 upgrade.go:994] Error trying to connect to api server: Get "https://10.200.0.108:443/apis/baremetal.cluster.gke.io/v1/namespaces/cluster-baremetal-test/nodepools/np1": net/http: TLS handshake timeout E0527 15:42:39.264789 372146 exec.go:207] command "/root/bmctl-upgrade upgrade cluster --kubeconfig /root/bmctl-workspace/baremetal-test/baremetal-test-kubeconfig --quiet --cluster baremetal-test --manifest-profile-env staging" times out Este problema se corrigió en la versión 1.32.100 y posteriores. Solución alternativa: Si no puedes actualizar a una versión con la corrección, te recomendamos que actualices la imagen de Cilium de forma manual a la versión v1.15.6-anthos1.32.50 o posterior. Esta actualización resuelve el problema reincorporando las reglas de CILIUM_POST_nat necesarias. Nota: También puedes restablecer la comunicación actualizando manualmente las reglas de iptables para agregar la regla de NAT faltante, pero no recomendamos este tipo de cambio. Es posible que los cambios de configuración de bajo nivel como este no persistan después de reiniciar el nodo o actualizar el clúster. Para actualizar la imagen de Cilium, sigue estos pasos: Edita el DaemonSet anetd en el espacio de nombres kube-system: kubectl edit ds anetd -n kube-system Replace all occurrences of the Cilium image tag with version v1.15.6-anthos1.32.50 or a later version. Example old image: image: gcr.io/anthos-baremetal-staging/anthos-networking/cilium/cilium:v1.15.6-anthos1.32-gke.41@sha256:1940fccc... Ejemplo de imagen nueva: image: gcr.io/anthos-baremetal-staging/anthos-networking/cilium/cilium:v1.15.6-anthos1.32-gke.50 Guarda los cambios y cierra el editor.
Instalación, actualizaciones y revisiones	1.33	bmctl configure projects devuelve un error Identity Pool does not exist Cuando se intenta usar el comando bmctl configure projects para configurar la federación de identidades para cargas de trabajo para un proyecto Google Cloud nuevo, el comando falla y muestra el siguiente mensaje de error: Error ((retry 1) error adding iam policy bindings: failed to add project binding: failed to set project "<>" iam policy: googleapi: Error 400: Identity Pool does not exist (projectID.svc.id.goog). Please check that you specified a valid resource name as returned in the `name` attribute in the configuration API., badRequest) ensuring iam policy binding: project-Id Este error se produce porque el grupo de identidades para cargas de trabajo predeterminado necesario, llamado projectID.svc.id.goog, no se aprovisiona automáticamente en el proyecto nuevo. Solución alternativa: Sigue estos pasos para configurar la federación de identidades para cargas de trabajo en tu proyecto: Crea manualmente el grupo de identidades para cargas de trabajo predeterminado faltante: gcloud iam workload-identity-pools create PROJECT_ID.svc.id.goog \ --location=global \ --project=PROJECT_ID Reemplaza PROJECT_ID con el ID del proyecto. En tu estación de trabajo de administrador, actualiza la variable de entorno GCP_ACCESS_TOKEN con un token de acceso recuperado recientemente: export GCP_ACCESS_TOKEN=$(gcloud auth application-default print-access-token) De forma predeterminada, el token de acceso tiene una vida útil de 3,600 segundos (1 hora). Cuando usas la autenticación de clústeres de Workload Identity, bmctl verifica la hora de vencimiento del token. Si el vencimiento del token es dentro de los 1,800 segundos (30 minutos), bmctl informa un error y sale. Vuelve a ejecutar bmctl configure projects.
Actualizaciones y revisiones, registro y supervisión	1.29, 1.30, 1.31 y 1.32	cal-update La guía de Ansible falla cuando se cambia la marca de registro de auditoría El playbook de Ansible cal-update contiene errores lógicos que provocan que falle cuando se intenta cambiar la marca disableCloudAuditLogging. Esto impide que se habiliten o inhabiliten correctamente los registros de auditoría. Cuando disableCloudAuditLogging cambia de true a false, no se pueden habilitar los registros de auditoría porque la secuencia de comandos falla antes de aplicar el cambio de configuración a kube-apiserver. Cuando disableCloudAuditLogging cambia de false a true, se pueden inhabilitar los registros de auditoría, pero el trabajo cal-update falla de forma continua, lo que impide que el playbook llegue a las verificaciones de estado. El mensaje de error observado es: The task includes an option with an undefined variable. The error was: 'dict object' has no attribute 'stdout_lines' Solución alternativa: No hay una solución alternativa para este problema. Debes actualizar el clúster a una versión que tenga la corrección. Cuando realices la actualización, sigue estos pasos: Inhabilita el registro de auditoría configurando disableCloudAuditLogging en true. Cuando el parche esté disponible, actualiza tu clúster a una de las siguientes versiones de parche de la versión secundaria (o posterior), que tienen la corrección: 1.30.1200 1.31.800 1.32.400 Para volver a habilitar los registros de auditoría de Cloud, vuelve a configurar disableCloudAuditLogging en false.
Revisiones y actualizaciones	1.32+	Las actualizaciones de los clústeres de administrador con alta disponibilidad (HA) fallan después de una operación de reparación En los clústeres de administrador con HA, el comando gkectl upgrade admin falla y se bloquea cuando lo ejecutas después de ejecutar el comando gkectl repair admin-master. El comando gkectl repair admin-master agrega una anotación machine.onprem.gke.io/managed=false a las máquinas reparadas. Esta anotación hace que el controlador cluster-api se quede atascado en un estado de reconciliación cuando ejecutas el comando gkectl upgrade admin. Las actualizaciones para clústeres que no son de alta disponibilidad incluyen lógica de pivote que quita esta anotación, pero la lógica de pivote no está presente en las actualizaciones para clústeres de alta disponibilidad. Solución alternativa: Quita manualmente la anotación machine.onprem.gke.io/managed de los recursos de la máquina en el clúster de administrador antes de iniciar la actualización.
Actualizaciones, configuración	1.32.0 - 1.32.200	El duplicado del registro provoca una falla en la verificación previa a la actualización Los clústeres configurados con una duplicación de registro fallan en la verificación previa check_gcr_pass durante una actualización a la versión 1.32.0 o posterior. Este error se debe a un cambio en la forma en que se construye el recurso personalizado PreflightCheck, que omite las configuraciones de duplicación de registro de la especificación del clúster que se usa en la verificación. Este problema se descubrió durante las pruebas internas en clústeres con configuraciones de proxy y de duplicación de registro. Solución alternativa: Puedes usar cualquiera de las siguientes opciones como solución alternativa para este problema: Usa la marca --force cuando actives la actualización. Obtén la configuración actual del clúster con bmctl get config y usa este archivo de configuración recién generado para activar la actualización.
Configuración y actualizaciones	1.15 a 1.30, 1.31.0 a 1.31.800, 1.32.0 a 1.32.300	El CronJob de verificación de estado periódica no se actualiza después de que cambia la especificación del clúster En las versiones de clúster especificadas, es posible que los CronJobs de verificación de estado periódica no actualicen sus especificaciones cuando haya cambios en la configuración del recurso Cluster. Estas fallas de actualización provocan verificaciones de estado desactualizadas y posibles fallas en los trabajos. Este problema se solucionó en las versiones 1.31.900, 1.32.400 y 1.33.0 y posteriores de Google Distributed Cloud. Solución alternativa: En las versiones 1.30 y anteriores, puedes seguir estos pasos como solución alternativa: Inhabilita las verificaciones de estado periódicas. Esto borra el recurso HealthCheck actual. Vuelve a habilitar las verificaciones de estado periódicas. Esto crea nuevos recursos de HealthCheck, que tienen en cuenta la configuración del clúster más reciente.
Redes	1.10, 1.11, 1.12, 1.13, 1.14, 1.15, 1.16, 1.28, 1.29, 1.30, 1.31	Entrelazado de ARP gratuitas para la VIP del plano de control Keepalived se usa para mover la VIP del plano de control de una máquina a otra para lograr una alta disponibilidad. Cuando la VIP del plano de control se controla con el balanceador de cargas de capa 2 incluido, es posible que las conmutaciones por error de la instancia de Keepalived provoquen breves intervalos (menos de un segundo) en los que se intercalan los ARP injustificados con diferentes direcciones MAC. La infraestructura de red de conmutación puede interpretar esta intercalación como anormal y rechazar más mensajes ARP durante períodos de hasta 30 minutos. A su vez, los mensajes ARP bloqueados pueden provocar que la VIP del plano de control no esté disponible durante este período. La intercalación de los ARP injustificados se debe a la configuración de Keepalived que se usa en la versión 1.31 y anteriores. Específicamente, todos los nodos se configuraron para usar la misma prioridad. Los cambios de configuración de Keepalived en la versión 1.32 abordan este problema configurando diferentes prioridades para cada instancia de Keepalived y también proporcionando un parámetro de configuración del clúster, controlPlane.loadBalancer.keepalivedVRRPGARPMasterRepeat, para reducir la cantidad de ARP gratuitos. Solución alternativa: En las versiones 1.31 y anteriores, puedes reducir la intercalación de los ARP gratuitos editando directamente el archivo de configuración de Keepalived, /usr/local/etc/keepalived/keepalived.conf. Para cada uno de los nodos que ejecutan el balanceador de cargas del plano de control, edita el archivo de configuración para cambiar los siguientes parámetros de configuración: priority: Establece un valor de priority distinto para cada nodo (los valores válidos están entre 1 y 254). weight: Cambia el valor de weight de -2 a -253 para asegurarte de que se active una conmutación por error de Keepalived cuando falle una verificación de estado.
Registro y supervisión	1.30, 1.31, 1.32 y 1.33	Discrepancia en la métrica kubernetes.io/anthos/custom_resurce_watchers Debido a un error interno en la definición, es posible que la métrica kubernetes.io/anthos/custom_resurce_watchers muestre datos imprecisos. Si te afecta este problema, es posible que veas errores en los registros similares a los siguientes: One or more TimeSeries could not be written: timeSeries[42]: Value type for metric kubernetes.io/anthos/custom_resurce_watchers must be INT64, but is DOUBLE. Puedes ignorar estos errores de forma segura. Esta métrica no se usa para las alertas críticas del sistema, y los errores no afectan el funcionamiento de tu proyecto ni de tus clústeres.
Operación	1.30, 1.31, 1.32 y 1.33	No se pudo analizar el archivo de configuración del clúster durante la captura de la instantánea Si falta el directorio .manifests en la estación de trabajo de administrador cuando ejecutas bmctl check cluster --snapshot, el comando falla con un error similar al siguiente: Error message: failing while capturing snapshot failed to parse cluster config file failed to get CRD file Este error se produce porque el comando bmctl check cluster --snapshot requiere los archivos de definición de recursos personalizados en el directorio .manifests para validar la configuración del clúster. Por lo general, este directorio se crea durante la configuración del clúster. Si borras el directorio por accidente o ejecutas bmctl desde una ubicación diferente, el comando no podrá continuar con la operación de instantánea. Soluciones alternativas: Puedes resolver este problema regenerando manualmente el directorio .manifests con cualquiera de los siguientes métodos: Ejecuta el comando bmctl check cluster: bmctl check cluster --cluster CLUSTER_NAME \ --kubeconfig ADMIN_KUBECONFIG Como parte de sus verificaciones iniciales, este comando crea automáticamente el directorio .manifests en tu directorio de trabajo actual, independientemente de si el comando se completa correctamente o no. En el directorio que contiene el archivo de configuración del clúster actual, ejecuta el comando bmctl create cluster: bmctl create cluster --cluster TEST_CLUSTER Aunque es probable que este comando genere un error, como Unable to Parse Cluster Configuration File, el directorio .manifests se crea en tu directorio de trabajo actual. El directorio temporal bmctl-workspace/TEST_CLUSTER que se genera se puede borrar de forma segura después. Después de realizar cualquiera de las soluciones alternativas anteriores, vuelve a intentar el comando bmctl check cluster --snapshot.
Instalación, actualizaciones y revisiones	1.32.0 y 1.32.100	La VIP del plano de control no se mueve cuando HAProxy no está disponible Si la instancia de HAProxy no está disponible en un nodo que aloja la VIP del plano de control, el parámetro de configuración nopreempt en la instancia de Keepalived impide que la VIP del plano de control se mueva a un nodo con un HAProxy en buen estado. Este problema se relaciona con una función que configura automáticamente las prioridades del protocolo de redundancia de router virtual (VRRP) de Keepalived, que es incompatible con el parámetro de configuración nopreempt. Solución alternativa: Como solución alternativa, sigue estos pasos para inhabilitar la función Keepalived: Agrega la anotación preview.baremetal.cluster.gke.io/keepalived-different-priorities: "disable" al clúster: kubectl annotate --kubeconfig ADMIN_KUBECONFIG \ -n CLUSTER_NAMESPACE \ clusters.baremetal.cluster.gke.io/CLUSTER_NAME \ preview.baremetal.cluster.gke.io/keepalived-different-priorities="disable" Quita nopreempt de /usr/local/etc/keepalived/keepalived.conf en los nodos que ejecutan el balanceador de cargas del plano de control. Según la configuración del balanceador de cargas, estos son los nodos del plano de control o los nodos de un grupo de nodos del balanceador de cargas. Después de quitar nopreempt, se deben reiniciar los Pods estáticos de keepalived para que se apliquen los cambios de los archivos de configuración. Para ello, en cada nodo, usa el siguiente comando para reiniciar los Pods de keepalived: crictl rmp -f \ $(crictl pods --namespace=kube-system --name='keepalived-*' -q)
Instalación, actualizaciones y revisiones	1.30, 1.31 y 1.32.0	No se limpian las carpetas abm-tools-* Los trabajos de verificación previa y de verificación de estado fallidos pueden dejar artefactos en carpetas abm-tools-* con marcas de tiempo en /usr/local/bin. Si te afecta este problema, es posible que veas numerosas carpetas como la siguiente: /usr/local/bin/abm-tools-preflight-20250410T114317. Las fallas reiteradas pueden generar un mayor uso del disco. Solución alternativa Si tienes este problema, quita estas carpetas de forma manual: rm -rf /usr/local/bin/abm-tools-*
Redes	1.28.0-1.28.200	Se descarta el tráfico del balanceador de cargas cuando se usa una puerta de enlace NAT de salida En los clústeres que tienen habilitada la puerta de enlace NAT de salida, si un balanceador de cargas elige backends que coinciden con las reglas de selección de tráfico especificadas por un recurso personalizado EgressNATPolicy obsoleto, se descarta el tráfico del balanceador de cargas. Este problema se produce cuando se crean y borran Pods que coinciden con una política de salida. Las políticas de salida no se limpian como deberían cuando se borran los Pods, y las políticas de salida obsoletas hacen que los Pods de LoadBalancer intenten enviar tráfico a una conexión que ya no existe. Este problema se solucionó en las versiones 1.28.300 y posteriores de Google Distributed Cloud. Solución alternativa Para limpiar los recursos de la política de NAT de salida, reinicia cada nodo que aloje un backend que esté fallando.
Actualizaciones, restablecimiento y eliminación	1.28	Falla de machine-init: El nuevo nodo del plano de control se bloqueó durante el reemplazo Cuando se reemplaza (quita o agrega) un nodo del plano de control en Google Distributed Cloud 1.28, es posible que el nodo nuevo no pueda unirse al clúster. Esto se debe a que el proceso responsable de configurar el nuevo nodo (bm-system-machine-init) encuentra el siguiente error: Failed to add etcd member: etcdserver: unhealthy cluster Este error se produce cuando se quita un nodo del plano de control anterior y no se limpia correctamente su membresía en etcd-events, lo que deja un miembro desactualizado. El miembro desactualizado impide que los nodos nuevos se unan al clúster etcd-events, lo que provoca que falle el proceso machine-init y que el nodo nuevo se vuelva a crear de forma continua. Las consecuencias de este problema incluyen lo siguiente: El nuevo nodo del plano de control no se puede iniciar correctamente. El clúster puede atascarse en un estado RECONCILING. El nodo del plano de control se borra y se vuelve a crear de forma continua debido a la falla de machine-init. Este problema se corrigió en las versiones 1.29 y posteriores. Solución alternativa: Si no puedes actualizar a la versión 1.29, puedes limpiar manualmente el miembro etcd-events defectuoso del clúster con las siguientes instrucciones: Usa SSH para acceder a un nodo del plano de control en funcionamiento. Ejecuta el siguiente comando: ETCDCTL_API=3 etcdctl \ --cacert=/etc/kubernetes/pki/etcd/ca.crt \ --cert=/etc/kubernetes/pki/etcd/server.crt \ --key=/etc/kubernetes/pki/etcd/server.key \ --endpoints=localhost:2382 \ member list Si la respuesta incluye el nodo quitado en la lista de miembros, busca el ID de miembro en la primera columna del nodo y ejecuta el siguiente comando: ETCDCTL_API=3 etcdctl \ --cacert=/etc/kubernetes/pki/etcd/ca.crt \ --cert=/etc/kubernetes/pki/etcd/server.crt \ --key=/etc/kubernetes/pki/etcd/server.key \ --endpoints=localhost:2382 \ member remove MEMBER_ID Reemplaza MEMBER_ID por el ID del miembro del nodo quitado. El nuevo nodo del plano de control debería unirse automáticamente al clúster después de unos minutos.
Revisiones y actualizaciones	1.30.500-gke.126, 1.30.600-gke.68, 1.31.100-gke.136, 1.31.200-gke.58	Falla en la actualización del plano de control debido a la falta del archivo super-admin.conf Durante la actualización de un clúster, es posible que el proceso de actualización falle en el primer nodo del plano de control con un mensaje de error dentro del trabajo de Ansible que indica que falta el archivo super-admin.conf. Este problema se produce porque es posible que el primer nodo del plano de control que se actualice no sea el primer nodo que se aprovisionó durante la creación del clúster. El proceso de actualización supone que el primer nodo que se actualizará es el que contiene el archivo super-admin.conf. Este problema se solucionó en las siguientes actualizaciones de parches: 1.30.500-gke.127, 1.30.600-gke.69 y 1.31.200-gke.59 Solución alternativa: Para mitigar el problema, realiza el siguiente paso en el nodo con errores: Copia el archivo /etc/kubernetes/admin.conf en /etc/kubernetes/super-admin.conf: cp /etc/kubernetes/admin.conf /etc/kubernetes/super-admin.conf El proceso de actualización se reintenta automáticamente y debería completarse correctamente.
Revisiones y actualizaciones	1.29.0 a 1.29.1100, 1.30.0 a 1.30.400	El vaciado de nodos se detiene si los Pods toleran los taints NoSchedule Los Pods con una tolerancia NoSchedule se consideran para la expulsión durante las actualizaciones. Sin embargo, debido a la tolerancia NoSchedule, es posible que el controlador de Deployment o DaemonSet vuelva a programar el Pod en el nodo en el que se está realizando el mantenimiento, lo que podría retrasar la actualización. Para saber si este problema te afecta, sigue estos pasos: Revisa los registros del pod anthos-cluster-operator para identificar los pods que impiden que se agote el nodo. En el siguiente fragmento de registro de ejemplo, el Pod node-problem-detector-mgmt-ydhc2 aún no se vació: nodepool_controller.go:720] controllers/NodePool "msg"="Pods yet to drain for 10.0.0.3 machine are 1 : [node-problem-detector-mgmt-ydhc2]" "nodepool"={"Namespace":"test-cluster","Name":"test-cluster"} Para cada Pod que impide el vaciado del nodo, ejecuta el siguiente comando para verificar las tolerancias: kubectl get po POD_NAME -n kube-system \ -o json | jq '.spec.tolerations' Reemplaza POD_NAME por el nombre del Pod que impide el vaciado del nodo. Deberías ver una de las siguientes combinaciones: Tolerancia con efecto NoSchedule y operador Exists Tolerancia con efecto NoSchedule y clave "baremetal.cluster.gke.io/maintenance" Tolerancia con un efecto vacío y una clave "baremetal.cluster.gke.io/maintenance" Por ejemplo, la respuesta podría verse de la siguiente manera: { "effect": "NoSchedule", "operator": "Exists" }, Solución alternativa: Para desbloquear el nodo y evitar que se agote, puedes realizar una de las siguientes acciones: Agrega la tolerancia baremetal.cluster.gke.io/maintenance:NoExecute a los Pods que tienen una tolerancia baremetal.cluster.gke.io/maintenance:Schedule y no requieren una finalización ordenada. Quita las combinaciones de tolerancia identificadas de los Pods que se deben desalojar durante el drenaje del nodo.
Redes	1.28, 1.29 y 1.30	Las llamadas de red a Pods con hostPort habilitado fallan para las solicitudes que se originan en el mismo nodo. Las llamadas de red a los Pods que tienen habilitado hostPort fallan y descartan paquetes si la solicitud se origina desde el mismo nodo en el que se ejecuta el Pod. Esto se aplica a todos los tipos de clústeres y nodos. Sin embargo, los clústeres creados sin kube-proxy no se ven afectados. Para verificar si este problema te afecta, sigue estos pasos: Obtén los nombres de los Pods anetd: Los Pods de anetd son responsables de controlar el tráfico de red. kubectl get pods -l k8s-app=cilium -n kube-system Verifica el estado de los Pods anetd: kubectl -n kube-system exec -it ANETD_POD_NAME -- cilium status --all-clusters Reemplaza ANETD_POD_NAME por el nombre de uno de los Pods anetd en tu clúster. Si la respuesta incluye KubeProxyReplacement: Partial ..., significa que te afecta este problema. Solución alternativa Si tienes un caso de uso para enviar solicitudes a Pods que usan hostPort desde el mismo nodo en el que se ejecutan, puedes crear un clúster sin kube-proxy. Como alternativa, puedes configurar los Pods para que usen un portmap complemento de interfaz de red de contenedor (CNI).
Registro y supervisión	Se identificó en la versión 1.29.100, pero es posible que ocurra en otras versiones también.	E/S de disco alta debido a la pérdida de conectividad de red o a una cuenta de servicio no válida Es posible que los Pods de stackdriver-log-forwarder experimenten pérdida de conectividad o que la cuenta de servicio haya vencido, lo que provocará que no se envíen esos registros a logging.googleapis.com, lo que generará una acumulación de registros en el búfer y, por lo tanto, una alta E/S de disco. El agente de Cloud Logging (Fluent Bit), un DaemonSet llamado stackdriver-log-forwarder, usa un búfer basado en el sistema de archivos con un límite de 4 GB. Cuando está lleno, el agente intenta rotar o vaciar el búfer, lo que puede causar una E/S alta. Elementos que debes comprobar: Verifica si vencieron las claves de la cuenta de servicio (SA). Si es así, rótalos para resolver el problema. Puedes confirmar la cuenta de servicio que se usa actualmente con el siguiente comando y validar la misma en IAM: kubectl get secret google-cloud-credentials -n CLUSTER_NAMESPACE -o jsonpath='{.data.credentials\.json}' | base64 --decode Solución alternativa: Advertencia: Si quitas el búfer, se perderán de forma permanente todos los registros almacenados actualmente en él (incluidos los registros de nodos, Pods y contenedores de Kubernetes). Si la acumulación del búfer se debe a la pérdida de conectividad de red con el servicio de registro de Google Cloud, estos registros se perderán de forma permanente cuando se borre el búfer o si el búfer está lleno y el agente no puede enviar los registros. Para quitar el pod del daemonset stackdriver-log-forwarder del clúster, agrega un selector de nodos (esto mantiene el DaemonSet stackdriver-log-forwarder, pero lo anula de la programación de los nodos): 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. Si esto ocurre en uno o pocos nodos, haz lo siguiente: Conéctate al nodo con SSH donde se ejecutaba stackdriver-log-forwarder (verifica que stackdriver-log-forwarder ya no se ejecute en esos nodos). En el nodo, borra todos los archivos de búfer con rm -rf /var/log/fluent-bit-buffers/ y, luego, sigue el paso 6. Si hay demasiados nodos con esos archivos y deseas aplicar una secuencia de comandos para limpiar todos los nodos que tienen estos fragmentos de backlog, usa las siguientes secuencias de comandos: Implementa un DaemonSet para limpiar todos los datos en los 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 Asegúrate de que el DaemonSet haya limpiado 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 Borra el DaemonSet de limpieza: kubectl --kubeconfig KUBECONFIG -n kube-system delete ds \ fluent-bit-cleanup 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"}]'
Actualizaciones y revisiones, Operación	1.28, 1.29, 1.30.0 y 1.30.100	Las actualizaciones se bloquean debido a Pods atascados por un problema de containerd Los Pods pueden quedarse atascados durante la finalización cuando se desvían los nodos. Los Pods atascados pueden bloquear operaciones, como las actualizaciones, que agotan los nodos. Los Pods pueden quedar atascados cuando el contenedor se muestra como en ejecución, aunque el proceso principal subyacente del contenedor ya se haya detenido correctamente. En este caso, el comando crictl stop tampoco detiene el contenedor. Para confirmar si el problema te afecta, sigue estos pasos: Verifica si tu clúster tiene Pods atascados con el estado Terminating: kubectl get pods --kubeconfig CLUSTER_KUBECONFIG -A \ -o wide | grep Terminating En el caso de los Pods que no se puedan detener, usa kubectl describe para verificar si hay eventos: kubectl describe pod POD_NAME \ --kubeconfig CLUSTER_KUBECONFIG \ -n NAMESPACE Si ves advertencias como las siguientes con Unhealthy y FailedKillPod como motivos, significa que te afecta este problema: Events: Type Reason Age From Message ---- ------ ---- ---- ------- Warning FailedKillPod 19m (x592 over 46h) kubelet error killing pod: [failed to "KillContainer" for "dnsmasq" with KillContainerError: "rpc error: code = DeadlineExceeded desc = context deadline exceeded", failed to "KillPodSandbox" for "0843f660-461e-458e-8f07-efe052deae23" with KillPodSandboxError: "rpc error: code = DeadlineExceeded desc = context deadline exceeded"] Warning Unhealthy 4m37s (x16870 over 46h) kubelet (combined from similar events): Readiness probe errored: rpc error: code = Unknown desc = failed to exec in container: failed to start exec "c1ea4ffe7e4f1bacaab4f312bcc45c879785f6e22e7dc2d94abc3a019e20e1a9": OCI runtime exec failed: exec failed: cannot exec in a stopped container: unknown Este problema se debe a un problema de containerd upstream, que se solucionó en las versiones 1.28.1000, 1.29.600, 1.30.200, 1.31 y posteriores de Google Distributed Cloud. Solución alternativa Para desbloquear la operación del clúster, haz lo siguiente: Para forzar la eliminación de los Pods atascados, haz lo siguiente: kubectl delete pod POD_NAME -n POD_NAMESPACE --force Cuando los Pods se reinicien correctamente, vuelve a intentar la operación del clúster.
Actualizaciones y revisiones, Operación	1.28, 1.29 y 1.30.0 a 1.30.100	Las actualizaciones se bloquearon debido a Pods atascados por no quitar cgroups Los Pods pueden quedarse atascados durante la finalización cuando se desvían los nodos. Los Pods atascados pueden bloquear operaciones del clúster, como actualizaciones, que vacían nodos. Los Pods pueden quedar atascados cuando el proceso runc init se bloquea, lo que impide que containerd borre el cgroups asociado a ese Pod. Para confirmar si el problema te afecta, sigue estos pasos: Verifica si tu clúster tiene Pods atascados con el estado Terminating: kubectl get pods --kubeconfig CLUSTER_KUBECONFIG -A \ -o wide | grep Terminating Verifica los registros de kubelet en los nodos que tienen Pods atascados en el proceso de finalización: El siguiente comando devuelve entradas de registro que contienen el texto Failed to remove cgroup. journalctl -u kubelet --no-pager -f | grep "Failed to remove cgroup" Si la respuesta contiene advertencias como las siguientes, te afecta este problema: May 22 23:08:00 control-1--f1c6edcdeaa9e08-e387c07294a9d3ab.lab.anthos kubelet[3751]: time="2024-05-22T23:08:00Z" level=warning msg="Failed to remove cgroup (will retry)" error="rmdir /sys/fs/cgroup/freezer/kubepods.slice/kubepods-burstable.slice/kubepods-burstable-podea876418628af89ec2a74ea73d4a6023.slice/cri-containerd-d06aacfec2b399fcf05a187883341db1207c04be3698ec058214a6392cfc6148.scope: device or resource busy" ... May 22 23:09:04 control-1 kubelet[3751]: time="2024-05-22T23:09:04Z" level=warning msg="Failed to remove cgroup (will retry)" error="rmdir /sys/fs/cgroup/net_cls,net_prio/kubepods.slice/kubepods-burstable.slice/kubepods-burstable-podea876418628af89ec2a74ea73d4a6023.slice/cri-containerd-d06aacfec2b399fcf05a187883341db1207c04be3698ec058214a6392cfc6148.scope: device or resource busy" ... Solución alternativa Para reactivar el proceso runc init y desbloquear las operaciones del clúster, haz lo siguiente: Con la ruta de acceso cgroup de los registros de kubelet, comprueba si cgroup está inactivo. Para ello, verifica el contenido del archivo freezer.state: cat CGROUP_PATH_FROM_KUBELET_LOGS/freezer.state El contenido de freezer.state indica el estado de cgroup. Con una ruta de las entradas de registro del ejemplo anterior, el comando se vería de la siguiente manera: cat /sys/fs/cgroup/freezer/kubepods.slice/kubepods-burstable.slice/kubepods-burstable-podea876418628af89ec2a74ea73d4a6023.slice/cri-containerd-d06aacfec2b399fcf05a187883341db1207c04be3698ec058214a6392cfc6148.scope/freezer.state Desbloquea los cgroups que se encuentren en el estado FREEZING o FROZEN: echo "THAWED" > CGROUP_PATH_FROM_KUBELET_LOGS/freezer.state Cuando los cgroups se THAWED, los procesos de runc init correspondientes se cierran automáticamente y los cgroups se quitan automáticamente. Esto evita que aparezcan advertencias Failed to remove cgroup adicionales en los registros de kubelet. Los Pods atascados en el estado Terminating también se quitan automáticamente poco después de la limpieza. Una vez que se hayan limpiado los cgroups inactivos y se hayan quitado los Pods atascados, vuelve a intentar la operación del clúster.
Configuración, Herramientas de redes	1.28.0 a 1.28.1000, 1.29.0 a 1.29.500 y 1.30.0 a 1.30.200	Eventos NodeNotReady debido a actualizaciones de arrendamiento fallidas En las versiones identificadas de Google Distributed Cloud, es posible que kubelet no pueda actualizar las concesiones de nodos durante más de 40 segundos, lo que genera eventos NodeNotReady. El problema es intermitente y ocurre aproximadamente cada 7 días. La conmutación por error de la VIP del plano de control puede ocurrir cerca del momento de los eventos NodeNotReady. Este problema se solucionó en las versiones 1.28.1100, 1.29.600, 1.30.300 y posteriores. Solución alternativa: Para mitigar el problema, puedes configurar kubelet con los siguientes pasos: Crea /etc/default/kubelet y agrégale las siguientes variables de entorno: HTTP2_READ_IDLE_TIMEOUT_SECONDS=10 HTTP2_PING_TIMEOUT_SECONDS=5 Reinicia kubelet: systemctl restart kubelet Obtén el nuevo ID de proceso (PID) para kubelet: pgrep kubelet Verifica que las variables de entorno surtan efecto después de reiniciar kubelet en el nodo: cat /proc/KUBELET_PID/environ | tr '\0' '\n' | grep -e HTTP2_READ_IDLE_TIMEOUT_SECONDS -e HTTP2_PING_TIMEOUT_SECONDS Reemplaza KUBELET_PID por el resultado del comando del paso anterior. El resultado del comando cat debe enumerar las dos variables de entorno agregadas en las últimas líneas.
Actualizaciones	1.30	Se produce un error de campo inmutable cuando se actualizan clústeres de usuario con la versión 1.30.x de bmctl Cuando creas un clúster de usuario con el comando bmctl create cluster y pasas el campo cloudOperationsServiceAccountKeyPath en el encabezado, el campo spec.clusterOperations.serviceAccountSecret se agrega al recurso Cluster que se crea. Este campo no se encuentra en el archivo de configuración del clúster y es inmutable. El comando bmctl update cluster no propaga este campo desde el encabezado, por lo que los intentos de actualizar el clúster con el comando bmctl update cluster y el archivo de configuración del clúster original fallan con el siguiente error: [2025-01-15 16:38:46+0000] Failed to calculate diff: --- E000090: Unable to calculate diff An error occurred while calculating diff between live configuration and cluster.yaml file Wrapped error: error in dryRunClient.Update for {map[apiVersion:baremetal.cluster.gke.io/v1 kind:Cluster metadata:map[annotations:map[baremetal.cluster.gke.io/enable-kubelet-read-only-port:false baremetal.cluster.gke.io/maintenance-mode-deadline-seconds:180 preview.baremetal.cluster.gke.io/add-on-configuration:enable] creationTimestamp: name:user-test namespace:cluster-user-test resourceVersion:1171702] spec:map[anthosBareMetalVersion:0.0.0-gke.0 bypassPreflightCheck:false clusterNetwork:map[multipleNetworkInterfaces:false pods:map[cidrBlocks:[10.240.0.0/13]] services:map[cidrBlocks:[172.26.0.0/16]]] clusterOperations:map[location:us-west1 projectID:baremetal-test] controlPlane:map[nodePoolSpec:map[nodes:[map[address:10.200.0.15]]]] gkeConnect:map[projectID:baremetal-test] loadBalancer:map[addressPools:[map[addresses:[10.200.0.20/32 10.200.0.21/32 10.200.0.22/32 10.200.0.23/32 10.200.0.24/32 fd00:1::15/128 fd00:1::16/128 fd00:1::17/128 fd00:1::18/128] name:pool1]] mode:bundled ports:map[controlPlaneLBPort:443] vips:map[controlPlaneVIP:10.200.0.19 ingressVIP:10.200.0.20]] nodeAccess:map[loginUser:root] nodeConfig:map[podDensity:map[maxPodsPerNode:250]] profile:default storage:map[lvpNodeMounts:map[path:/mnt/localpv-disk storageClassName:local-disks] lvpShare:map[numPVUnderSharedPath:5 path:/mnt/localpv-share storageClassName:local-shared]] type:user] status:map[]]}: admission webhook "vcluster.kb.io" denied the request: Cluster.baremetal.cluster.gke.io "user-test" is invalid: spec: Forbidden: Fields should be immutable. (A in old) (B in new) {"clusterNetwork":{"multipleNetworkInterfaces":false,"services":{"cidrBlocks":["172.26.0.0/16"]},"pods":{"cidrBlocks":["10.240.0.0/13"]},"bundledIngress":true},"controlPlane":{"nodePoolSpec":{"nodes":[{"address":"10.200.0.15"}],"operatingSystem":"linux"}},"credentials":{"sshKeySecret":{"name":"ssh-key","namespace":"cluster-user-test"},"imagePullSecret":{"name":"private-registry-creds","namespace":"cluster-user-test"}},"loadBalancer":{"mode":"bundled","ports":{"controlPlaneLBPort":443},"vips":{"controlPlaneVIP":"10.200.0.19","ingressVIP":"10.200.0.20"},"addressPools":[{"name":"pool1","addresses":["10.200.0.20/32","10.200.0.21/32","10.200.0.22/32","10.200.0.23/32","10.200.0.24/32","fd00:1::15/128","fd00:1::16/128","fd00:1::17/128","fd00:1::18/128"]}]},"gkeConnect":{"projectID":"baremetal-test","location":"global","connectServiceAccountSecret":{"name":"gke-connect","namespace":"cluster-user-test"},"registerServiceAccountSecret":{"name":"gke-register","namespace":"cluster-user-test"}},"storage":{"lvpShare":{"path":"/mnt/localpv-share","storageClassName":"local-shared","numPVUnderSharedPath":5},"lvpNodeMounts":{"path":"/mnt/localpv-disk","storageClassName":"local-disks"}},"clusterOperations":{"projectID":"baremetal-test","location":"us-west1" A: ,"serviceAccountSecret":{"name":"google-cloud-credentials","namespace":"cluster-user-test"}},"type":"user","nodeAccess":{"loginUser":"root"},"anthosBareMetalVersion":"0.0.0-gke.0","bypassPreflightCheck":false,"nodeConfig":{"podDensity":{"maxPodsPerNode":250},"containerRuntime":"containerd"},"profile":"default"} B: },"type":"user","nodeAccess":{"loginUser":"root"},"anthosBareMetalVersion":"0.0.0-gke.0","bypassPreflightCheck":false,"nodeConfig":{"podDensity":{"maxPodsPerNode":250},"containerRuntime":"containerd"},"profile":"default"} For more information, see https://cloud.google.com/distributed-cloud/docs/reference/gke-error-ref#E000090 Este problema solo se aplica cuando usas una versión 1.30.x de bmctl para realizar actualizaciones. Solución alternativa: Como solución alternativa, puedes obtener la configuración del clúster del recurso Cluster real antes de realizar las actualizaciones: Recupera el archivo de configuración del clúster de usuario según el recurso Cluster implementado: bmctl get config --cluster CLUSTER_NAME \ --kubeconfig ADMIN_KUBECONFIG_PATH El recurso personalizado recuperado se escribe en un archivo YAML llamado: bmctl-workspace/CLUSTER_NAME/CLUSTER_NAME-TIMESTAMP.yaml. Este nuevo archivo de configuración incluye spec.clusterOperations.serviceAccountSecret, que es necesario para que funcione el comando de actualización. El TIMESTAMP en el nombre del archivo indica la fecha y hora en que se creó el archivo. Reemplaza el archivo de configuración del clúster existente por el archivo recuperado. Guarda la copia de seguridad del archivo existente. Edita el nuevo archivo de configuración del clúster y usa bmctl update para actualizar tu clúster de usuario: bmctl update cluster --cluster CLUSTER_NAME \ --kubeconfig ADMIN_KUBECONFIG_PATH
Actualizaciones y revisiones, seguridad	1.29, 1.30 y 1.31	La rotación del certificado de Kubelet falla cuando los archivos de certificado actuales no son vínculos simbólicos La rotación del certificado de Kubelet falla cuando kubelet-client-current.pem y kubelet-server-current.pem son archivos reales, en lugar de vínculos simbólicos (symlinks). Este problema puede ocurrir después de usar bmctl restore para restablecer un clúster a partir de una copia de seguridad. Solución alternativa: Si este problema te afecta, puedes seguir estos pasos como solución alternativa: Crea una copia de seguridad de los archivos de certificado actuales: mkdir -p ~/kubelet-backup/ cp -r /var/lib/kubelet/pki/ ~/kubelet-backup/ De manera opcional, borra los archivos de certificado acumulados: ls | grep -E "^kubelet-server-20*" | xargs rm -rf ls | grep -E "^kubelet-client-20*" | xargs rm -rf Cambia el nombre de los archivos kubelet-client-current.pem y kubelet-server-current.pem: Usar una marca de tiempo es un esquema de cambio de nombre común. datetime=$(date +%Y-%m-%d-%H-%M-%S) mv kubelet-server-current.pem kubelet-server-${datetime}.pem mv kubelet-client-current.pem kubelet-client-${datetime}.pem En la misma sesión que el comando anterior, crea vínculos simbólicos que apunten a los certificados válidos más recientes (con el nombre cambiado): ln -s kubelet-server-${datetime}.pem kubelet-server-current.pem ln -s kubelet-client-${datetime}.pem kubelet-client-current.pem Establece los permisos en 777 para los vínculos simbólicos: chmod 777 kubelet-server-current.pem chmod 777 kubelet-client-current.pem Si los certificados se rotaron correctamente, borra el directorio de copias de seguridad: rm -rf ~/kubelet-backup/
Instalación, actualizaciones y revisiones	1.31	Errores al crear recursos personalizados En la versión 1.31 de Google Distributed Cloud, es posible que recibas errores cuando intentes crear recursos personalizados, como clústeres (de todos los tipos) y cargas de trabajo. El problema se debe a un cambio que interrumpe la compatibilidad y que se introdujo en Kubernetes 1.31, lo que impide que el campo caBundle de una definición de recurso personalizado pase de un estado válido a uno no válido. Para obtener más información sobre el cambio, consulta el registro de cambios de Kubernetes 1.31. Antes de Kubernetes 1.31, el campo caBundle a menudo se establecía en un valor provisional de \n, ya que en versiones anteriores de Kubernetes, el servidor de la API no permitía contenido vacío del paquete de CA. Usar \n era una solución alternativa razonable para evitar confusiones, ya que cert-manager suele actualizar caBundle más adelante. Si el caBundle se corrigió una vez de un estado no válido a uno válido, no debería haber problemas. Sin embargo, si la definición del recurso personalizado se reconcilia con \n (o con otro valor no válido), es posible que se produzca el siguiente error: ...Invalid value: []byte{0x5c, 0x6e}: unable to load root certificates: unable to parse bytes as PEM block] Solución alternativa Si tienes una definición de recurso personalizada en la que caBundle se establece en un valor no válido, puedes quitar el campo caBundle por completo sin problemas. Esto debería solucionar el problema.
Instalación, actualizaciones y revisiones	1.28, 1.29 y 1.30	Las actualizaciones del clúster tardan demasiado En una actualización de clúster, cada nodo del clúster se vacía y se actualiza. En las versiones 1.28 y posteriores, Google Distributed Cloud cambió de vaciado de nodos basado en marcas de exclusión a vaciado basado en expulsión. Además, para abordar las interdependencias de los Pods, el vaciado basado en el desalojo sigue un orden de vaciado de varias etapas. En cada etapa del vaciado, los Pods tienen un período de gracia de 20 minutos para finalizar, mientras que el vaciado anterior basado en la contaminación tenía un solo tiempo de espera de 20 minutos. Si cada etapa requiere los 20 minutos completos para expulsar todos los Pods, el tiempo para agotar un nodo puede ser significativamente más largo que el agotamiento anterior basado en la contaminación. A su vez, el aumento del tiempo de vaciado de nodos puede incrementar significativamente el tiempo necesario para completar una actualización del clúster o para poner un clúster en modo de mantenimiento. También hay un problema de Kubernetes upstream que afecta la lógica de tiempo de espera para el vaciado basado en expulsión. Este problema también podría aumentar los tiempos de vaciado de nodos. Solución alternativa: Como solución alternativa, puedes inhabilitar el vaciado de nodos basado en la expulsión. Esto revierte el vaciado basado en la contaminación. Sin embargo, no recomendamos el desalojo basado en la contaminación, ya que no respeta los PodDisruptionBudgets (PDB), lo que podría provocar interrupciones del servicio.
Instalación, actualizaciones y revisiones	1.16, 1.28 y 1.29	Es posible que una comprobación previa fallida obsoleta bloquee las operaciones del clúster La reconciliación del clúster es una fase estándar para la mayoría de las operaciones del clúster, incluidas la creación y las actualizaciones del clúster. Durante la reconciliación del clúster, el controlador de clúster de Google Distributed Cloud activa una verificación de solicitud preliminar. Si falla esta comprobación previa, se bloqueará la reconciliación adicional del clúster. Como resultado, también se bloquean las operaciones de clúster que incluyen la reconciliación del clúster. Esta verificación previa no se ejecuta de forma periódica, sino solo como parte de la reconciliación del clúster. Por lo tanto, incluso si corriges el problema que causó la falla inicial de la verificación previa y las verificaciones previas a pedido se ejecutan correctamente, la reconciliación del clúster seguirá bloqueada debido a esta verificación previa fallida obsoleta. Si tienes una instalación o actualización de clúster que se detuvo, puedes comprobar si este problema te afecta con los siguientes pasos: Verifica los registros del Pod anthos-cluster-operator para ver entradas como las siguientes: "msg"="Preflight check not ready. Won't reconcile" Verifica si la comprobación previa activada por el controlador del clúster se encuentra en un estado de falla: kubectl describe preflightcheck PREFLIGHT_CHECK_NAME \ -n CLUSTER_NAMESPACE \ --kubeconfig=ADMIN_KUBECONFIG Reemplaza lo siguiente: PREFLIGHT_CHECK_NAME: Es el nombre de la verificación previa al vuelo que se borrará. En este caso, el nombre es el mismo que el del clúster. CLUSTER_NAMESPACE: Es el espacio de nombres del clúster para el que falla la verificación previa al inicio. ADMIN_KUBECONFIG: Es la ruta del archivo kubeconfig del clúster de administrador. Si la comprobación previa falló (Status.Pass es false), es probable que este problema te afecte. Este problema se solucionó en la versión 1.30 y en todas las versiones posteriores. Solución alternativa Para desbloquear las operaciones del clúster, borra manualmente la verificación previa al vuelo fallida del clúster de administrador: kubectl delete preflightcheck PREFLIGHT_CHECK_NAME \ -n CLUSTER_NAMESPACE \ --kubeconfig=ADMIN_KUBECONFIG Una vez que se borra la comprobación previa fallida obsoleta, el controlador del clúster puede crear una nueva comprobación previa.
Instalación, actualizaciones y revisiones	1.30.100, 1.30.200 y 1.30.300	Es posible que no se realicen correctamente las operaciones de creación o actualización de clústeres de usuario Es posible que no se puedan crear clústeres de usuario en las versiones 1.30.100, 1.30.200 o 1.30.300, ni actualizar los clústeres de usuario existentes a esas versiones. Este problema se aplica solo cuando se usa kubectl o un cliente de la API de GKE On-Prem (la consola de Google Cloud , gcloud CLI o Terraform) para las operaciones de creación y actualización del clúster de usuario. En esta situación, la operación de creación del clúster de usuario se atasca en el estado Provisioning y la actualización del clúster de usuario se atasca en el estado Reconciling. Para verificar si un clúster está afectado, sigue estos pasos: Obtén el recurso del clúster: kubectl get cluster CLUSTER_NAME -n USER_CLUSTER_NAMESPACE \ --kubeconfig ADMIN_KUBECONFIG Reemplaza lo siguiente: CLUSTER_NAME: Es el nombre del clúster de usuario que está atascado. USER_CLUSTER_NAMESPACE: Es el nombre del espacio de nombres del clúster de usuario. ADMIN_KUBECONFIG: Es la ruta de acceso del archivo kubeconfig del clúster de administración. Si el valor de CLUSTER STATE es Provisioning o Reconciling, es posible que este problema te afecte. La siguiente respuesta de ejemplo es un indicador de que una actualización está atascada: NAME ABM VERSION DESIRED ABM VERSION CLUSTER STATE some-cluster 1.30.0-gke.1930 1.30.100-gke.96 Reconciling Las versiones no coincidentes también son un indicador de que no se completó la actualización del clúster. Busca el nombre completo del Pod anthos-cluster-operator: kubectl get pods -n kube-system -o=name \ -l baremetal.cluster.gke.io/lifecycle-controller-component=true \ --kubeconfig ADMIN_KUBECONFIG Como se muestra en el siguiente ejemplo, el resultado es una lista de Pods que incluye el Pod anthos-cluster-operator: pod/anthos-cluster-operator-1.30.100-gke.96-d96cf6765-lqbsg pod/cap-controller-manager-1.30.100-gke.96-fcb5b5797-xzmb7 Transmite los registros del Pod anthos-cluster-operator para ver si hay un mensaje repetitivo que indique que el clúster está atascado en el aprovisionamiento o la conciliación: kubectl logs POD_NAME -n kube-system -f --since=15s \ --kubeconfig ADMIN_KUBECONFIG | \ grep "Waiting for configMapForwarder to forward kube-system/metadata-image-digests to the cluster namespace, requeuing" Reemplaza POD_NAME por el nombre completo del Pod anthos-cluster-operator del paso anterior. A medida que se ejecuta el comando, observa un flujo continuo de líneas de registro coincidentes, lo que indica que la operación del clúster está atascada. El siguiente ejemplo de resultado es similar al que ves cuando un clúster se queda atascado en la reconciliación: ... I1107 17:06:32.528471 1 reconciler.go:1475] "msg"="Waiting for configMapForwarder to forward kube-system/metadata-image-digests to the cluster namespace, requeuing" "Cluster"={"name":"user-t05db3f0761d4061-cluster","namespace":"cluster-user-t05db3f0761d4061-cluster"} "controller"="cluster" "controllerGroup"="baremetal.cluster.gke.io" "controllerKind"="Cluster" "name"="user-t05db3f0761d4061-cluster" "namespace"="cluster-user-t05db3f0761d4061-cluster" "reconcileID"="a09c70a6-059f-4e81-b6b2-aaf19fd5f926" I1107 17:06:37.575174 1 reconciler.go:1475] "msg"="Waiting for configMapForwarder to forward kube-system/metadata-image-digests to the cluster namespace, requeuing" "Cluster"={"name":"user-t05db3f0761d4061-cluster","namespace":"cluster-user-t05db3f0761d4061-cluster"} "controller"="cluster" "controllerGroup"="baremetal.cluster.gke.io" "controllerKind"="Cluster" "name"="user-t05db3f0761d4061-cluster" "namespace"="cluster-user-t05db3f0761d4061-cluster" "reconcileID"="e1906c8a-cee0-43fd-ad78-88d106d4d30a""Name":"user-test-v2"} "err"="1 error occurred:\n\t* failed to construct the job: ConfigMap \"metadata-image-digests\" not found\n\n" ... Presiona Control+C para detener la transmisión de los registros. Comprueba si el ConfigMapForwarder está detenido: kubectl get configmapforwarder metadata-image-digests-in-cluster \ -n USER_CLUSTER_NAMESPACE \ -o jsonpath='{range .status.conditions[?(@.type=="Ready")]}Reason: {.reason}{"\n"}Message: {.message}{"\n"}{end}' \ --kubeconfig ADMIN_KUBECONFIG La respuesta contiene motivos y mensajes del recurso ConfigMapForwarder. Cuando ConfigMapForwarder se detiene, deberías ver un resultado como el siguiente: Reason: Stalled Message: cannot forward configmap kube-system/metadata-image-digests without "baremetal.cluster.gke.io/mark-source" annotation Confirma que el ConfigMap metadata-image-digests no esté presente en el espacio de nombres del clúster de usuario: kubectl get configmaps metadata-image-digests \ -n USER_CLUSTER_NAMESPACE \ --kubeconfig ADMIN_KUBECONFIG La respuesta debería ser como la siguiente: Error from server (NotFound): configmaps "metadata-image-digests" not found Solución alternativa Como solución alternativa, puedes actualizar manualmente el ConfigMap para agregar la anotación que falta: Agrega la anotación faltante al ConfigMap: kubectl annotate configmap metadata-image-digests \ -n kube-system "baremetal.cluster.gke.io/mark-source"="true" \ --kubeconfig ADMIN_KUBECONFIG Cuando se anota correctamente, el ConfigMap metadata-image-digests se debe crear automáticamente en el espacio de nombres del clúster de usuario. Confirma que el ConfigMap se cree automáticamente en el espacio de nombres del clúster de usuario: kubectl get configmaps metadata-image-digests \ -n USER_CLUSTER_NAMESPACE \ --kubeconfig ADMIN_KUBECONFIG Si el ConfigMap se creó correctamente, la respuesta del comando se verá similar a la siguiente: NAME DATA AGE metadata-image-digests 0 7s Con la corrección y la verificación anteriores, deberías ver que se desbloquea el operador del clúster y que las operaciones del clúster continúan como de costumbre.
Operación, restablecimiento/eliminación	1.30.0 a 1.30.300, 1.29.0 a 1.29.700, 1.28.0 a 1.28.1100	Los usuarios no raíz no pueden ejecutar bmctl restore para restablecer el quórum. Cuando se ejecuta bmctl restore --control-plane-node como un usuario no raíz, se produce un problema de chown al copiar archivos del nodo del plano de control a la máquina de la estación de trabajo. Solución alternativa: Ejecuta el comando bmctl restore --control-plane-node con sudo para los usuarios no raíz.
Actualizaciones	1.30.0-gke.1930	El trabajo de verificación de estado de la actualización permanece en estado activo debido a que falta la imagen pause:3.9 Durante una actualización, es posible que el trabajo de verificación de estado de la actualización permanezca en un estado activo debido a la falta de la imagen pause:3.9. Este problema no afecta el éxito de la actualización. Solución alternativa: Borra manualmente el trabajo de verificación de estado de actualización con el siguiente comando: kubectl delete job upgrade-health-check-JOB_ID --cascade=true
Sistema operativo	1.28, 1.29 y 1.30	Descargas lentas dentro de contenedores en RHEL 9.2 Las descargas de artefactos con tamaños que superan el límite de memory.max del cgroup pueden ser extremadamente lentas. Este problema se debe a un error en el kernel de Linux para Red Hat Enterprise Linux (RHEL) 9.2. Los kernels con cgroup v2 habilitado se ven afectados. El problema se solucionó en las versiones del kernel 5.14.0-284.40.1.el_9.2 y posteriores. Solución alternativa: En el caso de los Pods afectados, aumenta la configuración del límite de memoria de sus contenedores (spec.containers[].resources.limits.memory) para que los límites sean mayores que el tamaño de los artefactos descargados.
Actualizaciones	1.28 a 1.29.200	La actualización del clúster falla debido a un conflicto en la definición de recurso personalizado networks.networking.gke.io Durante la actualización de un clúster de metal desnudo, es posible que la actualización falle y se muestre un mensaje de error que indica que hay un conflicto en la definición de recurso personalizado networks.networking.gke.io. Específicamente, el error indica que v1alpha1 no está presente en spec.versions. Este problema ocurre porque la versión v1alpha1 de la definición de recursos personalizados no se migró a v1 durante el proceso de actualización. Solución alternativa: Aplica parches a los clústeres afectados con los siguientes comandos: kubectl patch customresourcedefinitions/networkinterfaces.networking.gke.io \ --subresource status --type json \ --patch='[{ "op": "replace", "path": "/status/storedVersions", "value": ["v1"]}]' kubectl patch customresourcedefinitions/networks.networking.gke.io \ --subresource status --type json \ --patch='[{ "op": "replace", "path": "/status/storedVersions", "value": ["v1"]}]'
Instalación, actualizaciones y revisiones	1.28.0 a 1.28.600 y 1.29.0 a 1.29.200	Fallas en la verificación previa de la máquina para los parámetros de configuración de check_inotify_max_user_instances y check_inotify_max_user_watches Durante la instalación o actualización del clúster, es posible que fallen las verificaciones previas de la máquina relacionadas con la configuración del kernel de fs.inotify. Si te afecta este problema, el registro de la verificación previa de la máquina contiene un error como el siguiente: Minimum kernel setting required for fs.inotify.max_user_instances is 8192. Current fs.inotify.max_user_instances value is 128. Please run "echo "fs.inotify.max_user_instances=8192" | sudo tee --append /etc/sysctl.conf" to set the correct value. Este problema se produce porque los valores de fs.inotify max_user_instances y max_user_watches se leen de forma incorrecta desde el plano de control y los hosts de arranque, en lugar de las máquinas de nodos previstas. Solución alternativa: Para solucionar este problema, ajusta fs.inotify.max_user_instances y fs.inotify.max_user_watches a los valores recomendados en todas las máquinas del plano de control y de arranque: echo fs.inotify.max_user_watches=524288 | sudo tee --append /etc/sysctl.conf echo fs.inotify.max_user_instances=8192 | sudo tee --append /etc/sysctl.conf sudo sysctl -p Después de que se complete la operación de instalación o actualización, estos valores se pueden revertir, si es necesario.
Actualizaciones	1.28.0 a 1.28.500	La actualización del clúster falla con un error de verificación de accesibilidad de Google Cloud Cuando usas bmctl para actualizar un clúster, es posible que la actualización falle con un error GCP reachability check failed, incluso si se puede acceder a la URL de destino desde la estación de trabajo de administrador. Este problema se debe a un error en las versiones de bmctl de la 1.28.0 a la 1.28.500. Solución alternativa: Antes de ejecutar el comando bmctl upgrade, configura la variable de entorno GOOGLE_APPLICATION_CREDENTIALS para que apunte a un archivo de claves de cuenta de servicio válido: export GOOGLE_APPLICATION_CREDENTIALS=JSON_KEY_PATH bmctl upgrade cluster -c CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG Configurar las credenciales predeterminadas de la aplicación (ADC) de esta manera garantiza que bmctl tenga las credenciales necesarias para acceder al extremo de la API de Google.
Configuración, instalación, actualizaciones, redes y seguridad	1.15, 1.16, 1.28 y 1.29	La instalación y actualización del clúster fallan cuando se requiere ipam-controller-manager La instalación y actualización del clúster fallan cuando se requiere ipam-controller-manager y el clúster se ejecuta en Red Hat Enterprise Linux (RHEL) 8.9 o versiones posteriores (según los cambios de RHEL upstream) con SELinux ejecutándose en modo de aplicación. Esto se aplica específicamente cuando la versión de container-selinux es superior a 2.225.0. Tu clúster requiere ipam-controller-manager en cualquiera de las siguientes situaciones: Tu clúster está configurado para redes de pila doble IPv4/IPv6 Tu clúster está configurado con clusterNetwork.flatIPv4 establecido en true. Tu clúster está configurado con la anotación preview.baremetal.cluster.gke.io/multi-networking: enable. La instalación y actualización del clúster no se realizan correctamente cuando se instala ipam-controller-manager. Solución alternativa Establece el contexto predeterminado para el directorio /etc/kubernetes en cada nodo del plano de control para que escriba etc_t: semanage fcontext /etc/kubernetes --add -t etc_t semanage fcontext /etc/kubernetes/controller-manager.conf --add -t etc_t restorecon -R /etc/kubernetes Estos comandos revierten el cambio de container-selinux en el directorio /etc/kubernetes. Después de actualizar el clúster a una versión con la corrección, deshace el cambio de contexto del archivo anterior en cada nodo del plano de control: semanage fcontext /etc/kubernetes --delete -t etc_t semanage fcontext /etc/kubernetes/controller-manager.conf --delete -t etc_t restorecon -R /etc/kubernetes
Actualizaciones	1.28.0 a 1.28.500	La actualización del clúster falla con un error de verificación de accesibilidad de Google Cloud Cuando usas bmctl para actualizar un clúster, es posible que la actualización falle con un error GCP reachability check failed, incluso si se puede acceder a la URL de destino desde la estación de trabajo de administrador. Este problema se debe a un error en las versiones de bmctl de la 1.28.0 a la 1.28.500. Solución alternativa: Antes de ejecutar el comando bmctl upgrade, configura la variable de entorno GOOGLE_APPLICATION_CREDENTIALS para que apunte a un archivo de claves de cuenta de servicio válido: export GOOGLE_APPLICATION_CREDENTIALS=JSON_KEY_PATH bmctl upgrade cluster -c CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG Configurar las credenciales predeterminadas de la aplicación (ADC) de esta manera garantiza que bmctl tenga las credenciales necesarias para acceder al extremo de la API de Google.
Instalación	1.29	Problema de autorización binaria para el clúster con un grupo de nodos de balanceador de cargas independiente Es posible que falle la instalación de un clúster con un grupo de nodos de balanceador de cargas independiente si habilitas la política de autorización binaria durante la creación del clúster. Este problema se produce porque el webhook de autorización binaria bloquea la creación del Pod del servicio de identidad de GKE y otros Pods críticos. Para determinar si este problema te afecta, completa los siguientes pasos: Identifica los Pods que fallan: kubectl get pods \ -n anthos-identity-service \ --kubeconfig CLUSTER_KUBECONFIG Describe el Pod que falla. Busca el siguiente mensaje en el resultado: admission webhook "binaryauthorization.googleapis.com" denied the request: failed to post request to endpoint: Post "https://binaryauthorization.googleapis.com/internal/projects/PROJECT_NUMBER/policy/locations/LOCATION/clusters/CLUSTER_NAME:admissionReview": oauth2/google: status code 400: {"error":"invalid_target","error_description":"The target service indicated by the \"audience\" parameters is invalid. This might either be because the pool or provider is disabled or deleted or because it doesn't exist."} Si ves el mensaje anterior, tu clúster tiene este problema. Solución alternativa: Para solucionar este problema, completa los siguientes pasos: Cancela la operación de creación del clúster. Quita el bloque spec.binaryAuthorization del archivo de configuración del clúster. Crea el clúster con la Autorización Binaria inhabilitada. Una vez finalizada la instalación, habilita la política de Autorización Binaria para un clúster existente.
Configuración, instalación	1.10, 1.11, 1.12, 1.13, 1.14, 1.15, 1.16, 1.28, 1.29, 1.30	Los puntos de activación con SELinux habilitado causan problemas Si tienes habilitado SELinux y activas sistemas de archivos en directorios relacionados con Kubernetes, es posible que experimentes problemas como fallas en la creación de clústeres, archivos ilegibles o problemas de permisos. Para determinar si este problema te afecta, ejecuta el siguiente comando: ls -Z /var/lib/containerd . Si ves system_u:object_r:unlabeled_t:s0 donde esperarías ver otra etiqueta, como system_u:object_r:container_var_lib_t:s0, significa que el problema te afecta. Solución alternativa: Si recientemente activaste sistemas de archivos en directorios, asegúrate de que esos directorios estén actualizados con tu configuración de SELinux. También debes ejecutar los siguientes comandos en cada máquina antes de ejecutar bmctl create cluster: restorecon -R -v /var restorecon -R -v /etc Esta corrección única persistirá después del reinicio, pero se requiere cada vez que se agregue un nodo nuevo con los mismos puntos de montaje. Para obtener más información, consulta Mounting File Systems en la documentación de Red Hat.
Restablecimiento/eliminación	1.29.0	El restablecimiento del clúster de usuario falla al intentar borrar el espacio de nombres Cuando se ejecuta bmctl reset cluster -c ${USER_CLUSTER}, después de que finalizan todos los trabajos relacionados, el comando no puede borrar el espacio de nombres del clúster de usuario. El espacio de nombres del clúster de usuario está atascado en el estado Terminating. Finalmente, 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 usuarios, sigue estos pasos: 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 esta situación, el Pod metrics-server impide la eliminación del espacio de nombres del clúster. En el clúster de administrador, fuerza la eliminación del finalizador en el 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 y seguridad	1.16.0 a 1.16.7 y 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 Google Distributed Cloud 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 experimentes un problema con la programación de los Pods para la función. En estas versiones, a la implementación de Binary Authorization 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 errores, pero no es el esperado. Solución alternativa: Para todos los clústeres afectados, completa los siguientes pasos: Abre el archivo de implementación de la Autorización binaria: kubectl edit -n binauthz-system deployment binauthz-module-deployment Agrega el siguiente nodeSelector en el bloque spec.template.spec: nodeSelector: node-role.kubernetes.io/control-plane: "" 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 se debe aplicar después de cada actualización.
Revisiones y actualizaciones	1.28.0, 1.28.100, 1.28.200, 1.28.300	Error al actualizar un clúster a la versión 1.28.0-1.28.300 La actualización de clústeres creados antes de la versión 1.11.0 a las versiones 1.28.0-1.28.300 podría provocar 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 corrigió en la versión 1.28.400. Actualiza a la versión 1.28.400 o 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 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 suceder cuando el clúster está configurado para usar la observabilidad PROJECT_ONE, que se establece en el campo clusterOperations.projectID en 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 se etiqueta 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 la clave de la cuenta de servicio al proyecto actual. Cambia project_id directamente en el filtro de registros del Explorador de registros.
Redes	1.29 y 1.30	Disminución del rendimiento en clústeres que usan el balanceo de cargas en paquetes con BGP En el caso de los clústeres de la versión 1.29.0 que usan el balanceo de cargas en paquetes con BGP, el rendimiento del balanceo de cargas puede disminuir a medida que la cantidad total de servicios de tipo LoadBalancer se acerca a 2,000. A medida que disminuye el rendimiento, los servicios recién creados tardan mucho en conectarse o un cliente no puede conectarse a ellos. Los Servicios existentes siguen funcionando, pero no controlan los modos de falla, como la pérdida de un nodo del balanceador de cargas, de manera eficaz. Estos problemas del servicio ocurren cuando se finaliza la Deployment de ang-controller-manager debido a que se agotó la 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 de ang-controller-manager se encuentra en un estado CrashLoopBackOff. La respuesta cuando se enumeran las implementaciones de ang-controller-manager 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 de la Deployment de 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 Cuando realices los cambios correctamente y cierres el editor, deberías ver el siguiente resultado: deployment.apps/ang-controller-manager edited Para verificar que los cambios se aplicaron, 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 y 1.28.100	Los problemas de conectividad del extremo gcr.io de Artifact Registry pueden bloquear las operaciones del clúster Las operaciones de varios clústeres para los clústeres de administrador crean un clúster de arranque. Antes de crear un clúster de arranque, bmctl realiza una Google Cloud verificación de accesibilidad desde la estación de trabajo de administrador. Es posible que esta verificación falle debido a problemas de conectividad con el extremo de Artifact Registry, gcr.io, y 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.
Redes	1.15 y 1.16	GKE Dataplane V2 no es compatible con algunos controladores de almacenamiento Los clústeres de Bare Metal usan GKE Dataplane V2, que es incompatible con algunos proveedores de almacenamiento. Es posible que tengas problemas con los volúmenes de NFS o los Pods bloqueados. Esto es especialmente 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 (volúmenes de servicio de sharedv4) csi-nfs Esta lista no es exhaustiva. Solución alternativa Hay una solución para este problema disponible para las siguientes versiones de Ubuntu: 20.04 LTS: Usa una imagen del kernel 5.4.0 posterior a linux-image-5.4.0-166-generic. 22.04 LTS: Usa una imagen del kernel 5.15.0 posterior a linux-image-5.15.0-88-generic o el kernel 6.5 de HWE. Si no usas una de estas versiones, comunícate con el equipo de asistencia de Google.
Registro y supervisión	1.15, 1.16 y 1.28	kube-state-metrics OOM en 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 se quedaron sin memoria (OOM). Esto puede ocurrir en clústeres con más de 50 nodos o con muchos objetos de Kubernetes. Solución alternativa Para resolver este problema, actualiza la definición del recurso personalizado stackdriver para usar el acceso a la función ksmNodePodMetricsOnly. Este indicador de activación garantiza que solo se exponga una pequeña cantidad de métricas críticas. Para usar esta solución alternativa, completa los siguientes pasos: Verifica la definición del recurso personalizado stackdriver para conocer los interruptores de funciones disponibles: kubectl -n kube-system get crd stackdrivers.addons.gke.io -o yaml | grep ksmNodePodMetricsOnly Actualiza la definición de recurso personalizado stackdriver para habilitar ksmNodePodMetricsOnly: kind:stackdriver spec: featureGates: ksmNodePodMetricsOnly: true
Instalación	1.28.0-1.28.200	Falla la comprobación previa en RHEL 9.2 debido a la falta de iptables Cuando instales un clúster en el sistema operativo Red Hat Enterprise Linux (RHEL) 9.2, es posible que se produzca un error debido a la falta del paquete iptables. La falla se produce durante las verificaciones previas al vuelo 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 versión preliminar para la versión 1.28 de Google Distributed Cloud. Solución alternativa Para omitir el error de la comprobación previa, configura spec.bypassPreflightCheck como true en el recurso Cluster.
Operación	1.10, 1.11, 1.12, 1.13, 1.14, 1.15 y 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 con límite de frecuencia que, cuando se encuentra en una escala alta, puede tardar un tiempo en llegar al servicio que necesita conmutar por error. Solución alternativa Actualiza tu clúster a la versión 1.28 o posterior. Si no puedes actualizar el servicio, editarlo de forma manual (por ejemplo, agregar una anotación) hace que conmute por error más rápido.
Operación	1.16.0 a 1.16.6 y 1.28.0 a 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 errores de proxy si no tienes definidas las variables de entorno HTTPS_PROXY y NO_PROXY en la estación de trabajo del administrador. El comando bmctl informa un mensaje de error sobre la imposibilidad de 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 manualmente HTTPS_PROXY y NO_PROXY en la estación de trabajo de administrador.
Revisiones y actualizaciones	1.28.0-gke.435	Es posible que las actualizaciones a la versión 1.28.0-gke.435 fallen si audit.log tiene una 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 del usuario establecida en root. Este parámetro de configuración de propiedad del archivo provoca errores 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 que se crearon 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 para que sea la misma que la del directorio principal, /var/log/apiserver.
Herramientas de redes, actualizaciones y revisiones	1.28.0-gke.435	MetalLB no asigna direcciones IP a los servicios VIP Google Distributed Cloud usa MetalLB para el balanceo de cargas en paquetes. En la versión 1.28.0-gke.435 de Google Distributed Cloud, el MetalLB incluido se actualizó a la versión 0.13, que introduce la compatibilidad con CRD para IPAddressPools. Sin embargo, debido a que ConfigMaps permite cualquier nombre para un IPAddressPool, los nombres del grupo debieron convertirse en un nombre compatible con Kubernetes agregando un hash al final del nombre del 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 un IPPool para la selección, la conversión de nombres impide que MetalLB realice una selección de grupo y asigne direcciones IP. Por lo tanto, los Services que usan metallb.universe.tf/address-pool como anotación para seleccionar el grupo de direcciones de una dirección IP ya no reciben una dirección IP del controlador de MetalLB. Este problema se solucionó en la versión 1.28.100-gke.146 de Google Distributed Cloud. 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: Obtén el nombre convertido de IPAddressPool: kubectl get IPAddressPools -n kube-system 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 en el servicio a metallb.universe.tf/address-pool: default-qpvpd. El hash que se usa en la conversión de nombres es determinístico, por lo que la solución alternativa es persistente.
Revisiones y actualizaciones	1.14, 1.15, 1.16, 1.28 y 1.29	Pods huérfanos después de actualizar a la versión 1.14.x Cuando actualizas los clústeres a la versión 1.14.x, no se borran algunos recursos de la versión anterior. Específicamente, 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 directamente el funcionamiento del clúster, pero, como práctica recomendada, 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 solucionó en la versión 1.15.0 y posteriores de Google Distributed Cloud.
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, es posible que se produzca un error debido a los trabajos de machine-init, similar al siguiente ejemplo de salida: "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 de etcd obsoleto que provoca la falla del trabajo machine-init. Completa los siguientes pasos en un nodo del plano de control que funcione: 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 el estado 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 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 que falló. En el resultado del ejemplo anterior, este ID es bd1949bcb70e2cb5. En el siguiente ejemplo de resultado, se muestra que se quitó al miembro: Member bd1949bcb70e2cb5 removed from cluster 9d70e2a69debf2f
Redes	1.28.0	Faltan los permisos de Cilium-operator, el nodo list y watch. En Cilium 1.13, los permisos de cilium-operator ClusterRole son incorrectos. Faltan los permisos de nodo list y watch. El cilium-operator no puede iniciar los recolectores de basura, lo que genera los siguientes problemas: Se produce una fuga de recursos de Cilium. Las identidades obsoletas no se quitan de los mapas de políticas de BFP. Es posible que los mapas de políticas alcancen el límite de 16 K. No se pueden agregar entradas nuevas. Aplicación incorrecta de NetworkPolicy. Es posible que las identidades alcancen el límite de 64 K. 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 faltantes de ClusterRole al operador: Quita los objetos CiliumIdentity existentes: kubectl delete ciliumid –-all Edita el objeto cilium-operator ClusterRole: kubectl edit clusterrole cilium-operator 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 Guarda y cierra el editor. El operador detecta de forma dinámica el cambio de permiso. No es necesario que reinicies el operador de forma manual.
Revisiones y actualizaciones	1.15.0 a 1.15.7 y 1.16.0 a 1.16.3	Se produjo un problema transitorio durante la verificación previa Una de las tareas de verificación de estado de kubeadm que se ejecuta durante la verificación previa a la actualización puede fallar con 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 sin problemas. Si se produce este error que bloquea la actualización, vuelve a ejecutar el comando de actualización. Si observas este error cuando ejecutas la verificación previa con el comando bmctl preflightcheck, este error no bloquea nada. Puedes volver a ejecutar la verificación previa para obtener la información precisa. Solución alternativa: Vuelve a ejecutar el comando de actualización o, si se produjo 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	Falla la verificación de estado de red periódica cuando se reemplaza o quita un nodo Este problema afecta a los clústeres que realizan verificaciones de estado de la red periódicas después de que se reemplazó o quitó un nodo. Si tu clúster se somete a verificaciones de estado periódicas, los resultados de la verificación de estado de la red periódica fallarán después del reemplazo o la eliminación de un nodo, ya que el ConfigMap del inventario de la red no se actualiza una vez que se crea. Solución alternativa: La solución alternativa recomendada es borrar el ConfigMap del inventario y la verificación de estado de la red periódica. El operador del clúster los recrea automáticamente 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 versiones 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
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 realizar cambios. Cuando la puerta de enlace de red para GDC verifica si la detección de direcciones duplicadas (DAD) está habilitada, es posible que la verificación falle y, por lo tanto, no se concilie. 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 a 1.16.2: Este error siempre se produce cuando los nombres de tus 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 tus clústeres, quita el punto (.) del nombre del dispositivo.
Actualizaciones, redes y 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án las actualizaciones a la versión 1.16.0. La versión 1.16 de Google Distributed Cloud usa la versión 1.27 de Kubernetes. En la versión 1.27.0 y posteriores de Kubernetes, la función para configurar perfiles de seccomp está disponible de forma general y ya no usa un interruptor de función. Este cambio de Kubernetes provoca 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 posteriores. Si el campo cluster.spec.clusterSecurity.enableSeccomp está configurado como false, puedes actualizar a la versión 1.16.1 o posterior. Los clústeres con spec.clusterSecurity.enableSeccomp sin configurar o establecidos en true no se ven afectados.
Instalación y funcionamiento	1.11, 1.12, 1.13, 1.14, 1.15.0 a 1.15.5, 1.16.0 a 1.16.1	Es posible que los metadatos de containerd se dañen después del reinicio cuando se activa /var/lib/containerd. Si montaste /var/lib/containerd de forma opcional, es posible que los metadatos de containerd se dañen después de un reinicio. Los metadatos dañados pueden provocar fallas en los Pods, incluidos los Pods críticos para el sistema. Para verificar si este problema te afecta, comprueba si se define un montaje opcional en /etc/fstab para /var/lib/containerd/ y si tiene nofail en las opciones de montaje. Solución alternativa: Quita la opción de montaje 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 estado Failed y con el estado TaintToleration. Estos Pods no usan recursos del clúster, pero se deben borrar. 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: Para cada Pod con los síntomas descritos, verifica el ReplicaSet al que pertenece el Pod. Si el ReplicaSet está satisfecho, puedes borrar los Pods: Obtén el ReplicaSet que administra el Pod y busca el valor de ownerRef.Kind: kubectl get pod POD_NAME -n NAMESPACE -o yaml Obtén el ReplicaSet y verifica que status.replicas sea igual que spec.replicas: kubectl get replicaset REPLICA_NAME -n NAMESPACE -o yaml Si los nombres coinciden, borra el Pod: kubectl delete pod POD_NAME -n NAMESPACE.
Actualizaciones	1.16.0	etcd-events puede detenerse 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. Específicamente, el trabajo upgrade-node falla en el paso TASK [etcd_events_install : Run etcdevents]. Si te afecta este problema, verás errores de Pod como los siguientes: El Pod kube-apiserver no se inicia y muestra 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 y muestra 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 con la corrección, usa la siguiente solución alternativa temporal para abordar los errores: Usa SSH para acceder al nodo del plano de control con los errores informados. Edita el archivo de manifiesto de etcd-events, /etc/kubernetes/manifests/etcd-events.yaml, y quita la marca initial-cluster-state=existing. Aplica el manifiesto. La actualización debería continuar.
Redes	1.15.0-1.15.2	No se reconoce CoreDNS orderPolicy OrderPolicy no se reconoce como un parámetro y no se usa. En cambio, Google Distributed Cloud siempre usa Random. Este problema se produce porque no se actualizó la plantilla de CoreDNS, lo que hace que se ignore orderPolicy. Solución alternativa: Actualiza la plantilla de CoreDNS y aplica la corrección. Esta corrección persiste hasta una actualización. 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 }}
Operación de redes	1.10, 1.11, 1.12, 1.13 y 1.14	Los componentes de la puerta de enlace de red para GDC se desalojaron o están pendientes debido a la falta de una clase de prioridad. Los Pods de la puerta de enlace de red en kube-system pueden mostrar un estado de Pending o Evicted, como se muestra en el siguiente ejemplo de resultado condensado: $ kubectl -n kube-system get pods | grep ang-node ang-node-bjkkc 2/2 Running 0 5d2h ang-node-mw8cq 0/2 Evicted 0 6m5s ang-node-zsmq7 0/2 Pending 0 7h Estos errores indican eventos de expulsión o la imposibilidad de programar Pods debido a los recursos del nodo. Como las puertas de enlace de red para los Pods de GDC no tienen PriorityClass, tienen la misma prioridad predeterminada que otras cargas de trabajo. Cuando los nodos tienen restricciones de recursos, es posible que se expulsen los Pods de la puerta de enlace de red. Este comportamiento es particularmente malo para el DaemonSet de ang-node, ya que esos Pods deben programarse en un nodo específico y no pueden migrar. Solución alternativa: Actualiza a la versión 1.15 o posterior. Como solución a corto plazo, puedes asignar manualmente un PriorityClass a la puerta de enlace de red para los componentes de GDC. El controlador de Google Distributed Cloud reemplaza estos cambios manuales durante un proceso de reconciliación, como durante una actualización del clúster. Asigna la PriorityClass system-cluster-critical a las implementaciones de los controladores de clústeres ang-controller-manager y autoscaler. Asigna la PriorityClass system-node-critical al DaemonSet del nodo ang-daemon.
Instalación, actualizaciones y revisiones	1.15.0, 1.15.1 y 1.15.2	La creación y las actualizaciones de clústeres fallan debido a la longitud del nombre del clúster La creación de clústeres de las versiones 1.15.0, 1.15.1 o 1.15.2, o la actualización de clústeres a las versiones 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 del clúster, Google Distributed Cloud 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 de clúster largos, el nombre del recurso de verificación de estado supera la restricción de longitud de 63 caracteres de Kubernetes para los nombres de etiquetas, lo que impide la creación del recurso de verificación de estado. Si no se realiza una verificación de estado exitosa, la operación del clúster falla. Para ver si este problema te afecta, usa kubectl describe para verificar el recurso que falla: 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 un ReconcileError como el 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 creación o actualización del clúster, puedes omitir la verificación de estado. Usa el siguiente comando para aplicar parches 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 y 1.15	Los clústeres de las versiones 1.14.0 y 1.14.1 con funciones en versión preliminar 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, se bloqueará la actualización correcta a la versión 1.15.x. Esto se aplica a las funciones en 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, recibirá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 posteriores. Solución alternativa: Si no puedes actualizar tus clústeres a la versión 1.14.2 o posterior antes de actualizar a la versión 1.15.x, puedes actualizar directamente a la versión 1.15.x con 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 recursos personalizados NetworkGatewayGroup nuevos que contengan direcciones IP en spec.floatingIPs que ya se usen en recursos personalizados NetworkGatewayGroup existentes. Esta regla se aplica mediante un webhook en los clústeres de equipos físicos de la versión 1.15.0 y posteriores. Las direcciones IP flotantes duplicadas preexistentes no causan errores. El webhook solo impide la creación de recursos personalizados NetworkGatewayGroups nuevos que contengan direcciones IP duplicadas. El mensaje de error del 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 La documentación inicial para las funciones de redes avanzadas, como la puerta de enlace NAT de salida, no advierte sobre las direcciones IP duplicadas. Inicialmente, el reconciliador solo reconocía el recurso NetworkGatewayGroup llamado default. La puerta de enlace de red para GDC ahora reconoce todos los recursos personalizados de NetworkGatewayGroup en el espacio de nombres del sistema. Los recursos personalizados NetworkGatewayGroup existentes se respetan tal como están. Solución alternativa: Los errores solo se producen cuando se crea un recurso personalizado NetworkGatewayGroup nuevo. Para resolver el error, haz lo siguiente: Usa el siguiente comando para enumerar los recursos personalizados de NetworkGatewayGroups: kubectl get NetworkGatewayGroups --kubeconfig ADMIN_KUBECONFIG \ -n kube-system -o yaml 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 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 clústeres de la versión 1.13.7 que usan un registro privado Cuando habilitas el entorno de ejecución de VM en GDC en un clúster de la versión 1.13.7 nueva o actualizada que usa un registro privado, es posible que las VMs que se conectan a la red de nodos o usan una GPU no se inicien correctamente. Este problema se debe a que algunos Pods del sistema en el espacio de nombres vm-system generan errores de extracción de imágenes. Por ejemplo, si tu VM usa la red de nodos, es posible que algunos Pods informen errores de extracción de imágenes como los siguientes: macvtap-4x9zp 0/1 Init:ImagePullBackOff 0 70m Este problema se solucionó en los clústeres de la versión 1.14.0 y posteriores. 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 CNI de macvtap para tu VM y la envían a tu 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 y 1.12	Durante la creación del clúster en el clúster de kind, no se inicia el pod de gke-metric-agent Durante la creación del clúster en el clúster de kind, el pod de gke-metrics-agent no se inicia debido a un error de extracción de imágenes, como se muestra 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 de 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" Verás el siguiente error de "falla en la extracción" en el pod: 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 gke-metrics-agent en el clúster de Kind es facilitar la tasa de éxito de la creación del clúster y realizar un seguimiento y una 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 gke-metrics-agent en el clúster de Kind es facilitar la tasa de éxito de la creación del clúster y realizar un seguimiento y una supervisión internos. Por lo tanto, puedes ignorar este error.
Operación, redes	1.12, 1.13, 1.14, 1.15, 1.16, 1.28	El acceso a un extremo de Service IPv6 falla en 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, es posible que falle el nodo LoadBalancer que entrega el Service. Este problema afecta a los clientes que usan servicios de doble pila con CentOS o RHEL y una versión del kernel anterior a kernel-4.18.0-372.46.1.el8_6. Si crees que este problema te afecta, verifica la versión del kernel en el nodo de LoadBalancer con el comando uname -a. Solución alternativa: Actualiza el nodo LoadBalancer a la versión del kernel kernel-4.18.0-372.46.1.el8_6 o posterior. Esta versión del kernel está disponible de forma predeterminada en CentOS y RHEL 8.6 y versiones posteriores.
Redes	1.11, 1.12, 1.13 y 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 para 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ó en 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 servicio afectado: sudo iptables -L FORWARD Si ves la regla KUBE-FORWARD antes de la regla CILIUM_FORWARD en iptables, es posible que tengas este problema. En el siguiente ejemplo de resultado, 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 de anetd en el nodo que está mal configurado. Después de reiniciar el Pod de anetd, la regla de reenvío en iptables debería configurarse correctamente. En el siguiente ejemplo de resultado, se muestra que la regla CILIUM_FORWARD ahora está configurada correctamente antes de 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 y 1.10	La función de vista previa no conserva la información original del permiso y del propietario. La función de vista previa del clúster 1.9.x que usa bmctl 1.9.x no conserva la información original del propietario y los permisos. Para verificar si esta función te afecta, extrae el archivo de copia de seguridad con el siguiente comando: tar -xzvf BACKUP_FILE Solución alternativa Verifica si metadata.json está presente y si bmctlVersion es 1.9.x. Si no está presente metadata.json, actualiza el clúster a la versión 1.10.x y usa bmctl 1.10.x para crear copias de seguridad y restablecerlas.
Actualizaciones y creaciones	1.14.2	clientconfig-operator atascado en el estado pendiente con CreateContainerConfigError Si actualizaste a un clúster de la versión 1.14.2 o creaste uno con una configuración de OIDC/LDAP, es posible que veas el Pod clientconfig-operator atascado 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 la 1.14.0 y la 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 parches 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 del clúster de destino.
Operación	1.11, 1.12, 1.13, 1.14 y 1.15	Falla la rotación de la autoridad certificadora para los clústeres sin balanceo de cargas agrupado En el caso de los clústeres sin balanceo de cargas agrupado (spec.loadBalancer.mode establecido en 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 este problema te afecta, es posible que el comando bmctl muestre el siguiente mensaje antes de dejar de responder: Signing CA completed in 3/0 control-plane nodes En este caso, el comando falla. El registro de rotación de la autoridad de certificación 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 asistencia de Google.
Instalación y redes	1.11, 1.12, 1.13, 1.14.0-1.14.1	ipam-controller-manager bucles de fallas en clústeres de pila doble Cuando implementas un clúster de pila doble (un clúster con direcciones IPv4 e IPv6), es posible que los Pods ipam-controller-manager entren en un bucle de fallas. Este comportamiento hace que los nodos alternen entre los estados Ready y NotReady, y puede provocar que falle la instalación del clúster. Este problema puede ocurrir cuando el servidor de la API está 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 asignado ningún PodCIDR, como se muestra en el siguiente ejemplo de resultado: PodCIDRs: En un clúster en buen estado, todos los nodos deben tener asignados PodCIDRs de doble pila, 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	Falta de recursos de observación de etcd Los clústeres que ejecutan la versión 3.4.13 de etcd o una anterior pueden experimentar agotamiento de la observación y observaciones de recursos no operativas, lo que puede provocar los siguientes problemas: Se interrumpe la programación de Pods Los nodos no se pueden registrar kubelet no observa los cambios en los pods Estos problemas pueden hacer que el clúster deje de funcionar. Este problema se solucionó en las versiones 1.12.9, 1.13.6 y 1.14.3 de Google Distributed Cloud, y en las versiones posteriores. Estas versiones más recientes usan la versión 3.4.21 de etcd. Todas las versiones anteriores de Google Distributed Cloud se ven afectadas por este problema. Solución alternativa Si no puedes actualizar de inmediato, puedes mitigar el riesgo de falla del clúster reduciendo la cantidad de nodos en él. Quita nodos hasta que la métrica etcd_network_client_grpc_sent_bytes_total sea inferior a 300 MB/s. Para ver esta métrica en el Explorador de métricas, sigue estos pasos: Ve al Explorador de métricas en la Google Cloud consola: Ir al Explorador de métricas Selecciona la pestaña Configuración. Expande el menú Seleccionar una métrica, ingresa Kubernetes Container en la barra de filtros y, luego, usa los submenús para seleccionar la métrica: En el menú Recursos activos, selecciona Contenedor de Kubernetes. En el menú Categorías de métricas activas, elige Anthos. En el menú Métricas activas, selecciona etcd_network_client_grpc_sent_bytes_total. Haz clic en Aplicar.
Redes	1.11.6, 1.12.3	Estado "Failed" del modo vfio-pci del operador de SR-IOV El objeto SriovNetworkNodeState de syncStatus puede informar el valor "Failed" 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 "Failed", actualiza tu 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 y 1.14.1	Algunos nodos trabajadores no están en estado Listo después de la actualización Una vez que finalice la actualización, es posible que algunos nodos trabajadores tengan su condición Ready establecida en false. En el recurso Node, verás un error junto a la condición Ready 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 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 revisiones, seguridad	1.10	Varias rotaciones de certificados de cert-manager generan inconsistencias 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 que emitió 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 cert-manager en un clúster de más de 180 días y nunca reiniciaste anthos-cluster-operator. Si realizaste rotaciones manuales de certificados cert-manager emitidos en un clúster de más de 90 días y nunca reiniciaste anthos-cluster-operator. Solución alternativa Para reiniciar el Pod, finaliza el anthos-cluster-operator.
Revisiones y actualizaciones	1.14.0	Pods del implementador del controlador del ciclo de vida desactualizados creados durante la actualización del clúster de usuario En los clústeres de administrador de la versión 1.14.0, es posible que se creen uno o más pods de implementador de controladores de ciclo de vida desactualizados durante las actualizaciones de los clústeres de usuario. Este problema se aplica a los clústeres de usuario que se crearon inicialmente en versiones anteriores a la 1.12. Los Pods creados de forma involuntaria no impiden las operaciones de actualización, pero es posible que se encuentren 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 de ciclo de vida desactualizado, haz lo siguiente: Enumera los recursos de verificación previa: kubectl get preflightchecks --kubeconfig ADMIN_KUBECONFIG -A La salida obtenida se verá así: NAMESPACE NAME PASS AGE cluster-ci-87a021b9dcbb31c ci-87a021b9dcbb31c true 20d cluster-ci-87a021b9dcbb31c ci-87a021b9dcbb31cd6jv6 false 20d donde ci-87a021b9dcbb31c es el nombre del clúster. Borra los recursos cuyo valor en la columna PASS sea true o false. Por ejemplo, para borrar los recursos en el resultado de la 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
Redes	1.9, 1.10, 1.11, 1.12, 1.13, 1.14, 1.15, 1.16, 1.28	El estado de BGPSession cambia constantemente debido a la gran cantidad de rutas entrantes. Las redes avanzadas de Google Distributed Cloud no pueden administrar las sesiones de BGP correctamente 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 puede actualizar el estado. La falta de actualizaciones de estado o de una verificación de estado hace que se borre la sesión por estar inactiva. Entre los comportamientos no deseados en las sesiones de BGP que podrías notar y que indican un problema, se incluyen los siguientes: Se borra y se vuelve a crear bgpsession de forma continua. bgpsession.status.state nunca se convierte en Established Rutas que no se anuncian o que se anuncian y retiran de forma reiterada Los problemas de balanceo de cargas de BGP pueden ser evidentes con problemas de conectividad a los servicios de LoadBalancer. El problema de BGP FlatIP podría ser evidente con problemas de conectividad a los Pods. Para determinar si tus problemas de BGP se deben a que los pares remotos anuncian demasiadas rutas, usa los siguientes comandos para revisar los estados y los resultados asociados: Usa kubectl get bgpsessions en el clúster afectado. El resultado muestra bgpsessions con el estado "Not Established" y la hora del último informe aumenta continuamente hasta aproximadamente 10 o 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 obsoletas: 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 par remoto al clúster con una política de exportación. En las versiones de clúster 1.14.2 y posteriores, también puedes inhabilitar la función que procesa las rutas recibidas con un AddOnConfiguration. Agrega el argumento --disable-received-routes al contenedor bgpd del daemonset ang-daemon.
Redes	1.14, 1.15, 1.16 y 1.28	Se agotó el tiempo de espera de la aplicación debido a errores de inserción en la tabla de conntrack Los clústeres que se ejecutan en un SO Ubuntu que usa el kernel 5.15 o una versión posterior son susceptibles a fallas de inserción en la tabla de seguimiento de conexiones (conntrack) de netfilter. Las fallas de inserción pueden ocurrir incluso cuando la tabla de conntrack tiene espacio para nuevas entradas. Los errores se deben a cambios en el kernel 5.15 y versiones posteriores que restringen las inserciones de tablas según la longitud de la cadena. Para ver si este problema te afecta, puedes verificar las estadísticas del sistema de seguimiento de conexiones en el 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 de chaintoolong en la respuesta es un número distinto de cero, significa que este problema te afecta. Solución alternativa La mitigación a corto plazo consiste en aumentar el tamaño de la tabla hash de netfilter (nf_conntrack_buckets) y de la tabla de seguimiento de conexiones de netfilter (nf_conntrack_max). Usa los siguientes comandos en cada nodo del clúster para aumentar el tamaño de las tablas: sysctl -w net.netfilter.nf_conntrack_buckets=TABLE_SIZE sysctl -w net.netfilter.nf_conntrack_max=TABLE_SIZE Reemplaza TABLE_SIZE por el nuevo tamaño en bytes. El valor predeterminado del tamaño de la tabla es 262144. Te sugerimos que establezcas un valor igual a 65,536 veces la cantidad de núcleos del nodo. Por ejemplo, si tu nodo tiene ocho núcleos, establece el tamaño de la tabla en 524288.
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 copias de seguridad del clúster con bmctl para algunas versiones Te recomendamos que crees copias de seguridad de tus clústeres antes de actualizarlos para que puedas restablecer la versión anterior si la actualización no se realiza correctamente. Un problema con el comando bmctl restore cluster hace que no se puedan restablecer las copias de seguridad de los clústeres con las versiones identificadas. Este problema es específico de las actualizaciones, en las que se restablece una copia de seguridad de una versión anterior. Si tu clúster se ve afectado, el registro de 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 que se indican en Cómo crear copias de seguridad de clústeres y restablecerlos para crear copias de seguridad de tus clústeres de forma manual y restablecerlos de forma manual, si es necesario.
Redes	1.10, 1.11, 1.12, 1.13, 1.14.0 a 1.14.2	NetworkGatewayGroup falla si no hay una dirección IP en la interfaz NetworkGatewayGroup no puede crear daemons para los nodos que no tienen interfaces IPv4 e IPv6. Esto provoca que fallen funciones como el LB de BGP y EgressNAT. Si revisas los registros del Pod ang-node con errores en el espacio de nombres kube-system, se mostrarán errores similares al siguiente ejemplo cuando falte 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 el nodo no tiene una dirección IPv4. NetworkGatewayGroup intenta establecer una conexión ARP y una conexión NDP con la dirección IP local de vínculo. Si la dirección IP no existe (IPv4 para ARP, 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 a la vinculación 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: Es la interfaz de tu nodo, como ens192. ADDRESS: Dirección IP y máscara de subred que se aplicarán a la interfaz.
Restablecimiento/eliminación	1.10, 1.11, 1.12, 1.13.0-1.13.2	Bucle de fallas de anthos-cluster-operator cuando se quita un nodo del plano de control Cuando intentas quitar un nodo del plano de control quitando la dirección IP del Cluster.Spec, el anthos-cluster-operator entra en un estado de bucle de fallas que bloquea cualquier otra operación. Solución alternativa: El problema se solucionó 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 fallas. 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 clústeres 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 la versión 1.13.4 y posteriores de Google Distributed Cloud. 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 después de que se complete la instalación.
Registro y supervisión	1.10, 1.11, 1.12 y 1.13.0	Límite de CPU bajo para metrics-server en clústeres de Edge En los clústeres de Google Distributed Cloud Edge, los límites bajos de CPU para metrics-server pueden provocar 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 la CPU, revisa uno de los siguientes archivos:metrics-server Versiones del clúster 1.x a 1.12: kubectl get deployment metrics-server -n kube-system \ -o yaml > metrics-server.yaml Versiones del clúster 1.13 o posteriores: kubectl get deployment metrics-server -n gke-managed-metrics-server \ -o yaml > metrics-server.yaml Solución alternativa: Este problema se resolvió en las versiones de clúster 1.13.1 o posteriores. Para solucionar este problema, actualiza tus clústeres. Una solución alternativa a corto plazo hasta que puedas actualizar los clústeres es aumentar manualmente los límites de CPU para metrics-server de la siguiente manera: Reduce verticalmente la escala de metrics-server-operator: kubectl scale deploy metrics-server-operator --replicas=0 Actualiza la configuración y aumenta los límites de CPU: Versiones de clústeres 1.x a 1.12: kubectl -n kube-system edit deployment metrics-server Versiones de clústeres 1.13: 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 [...] Guarda y cierra el archivo metrics-server para aplicar los cambios.
Redes	1.14, 1.15 y 1.16	No funciona la conexión directa de NodePort al Pod de hostNetwork La conexión a un Pod habilitado con hostNetwork a través del servicio NodePort falla cuando el Pod de backend se encuentra en el mismo nodo que el NodePort de destino. Este problema afecta a los objetos Service de LoadBalancer cuando se usan con Pods con 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 NodePort, no segmentes el nodo en el que se ejecuta alguno de los Pods de backend. Cuando uses el servicio LoadBalancer, asegúrate de que los Pods con hostNetwork no se ejecuten en los nodos de LoadBalancer.
Revisiones y actualizaciones	1.12.3 y 1.13.0	Los clústeres de administrador de la versión 1.13.0 no pueden administrar los clústeres de usuario de la versión 1.12.3 Los clústeres de administrador que ejecutan la versión 1.13.0 no pueden administrar 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 tu 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 versiones posteriores no pueden contener grupos de nodo trabajador. Se bloquean las actualizaciones a la versión 1.13.0 o posterior 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 quieres 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 al actualizar recursos con kubectl apply Si actualizas recursos existentes, como los recursos personalizados ClientConfig o Stackdriver, con kubectl apply, es posible que el controlador muestre un error o revierta tu entrada y los cambios planificados. Por ejemplo, puedes intentar editar el recurso personalizado Stackdriver de la siguiente manera: primero, obtén el recurso y, luego, aplica una versión actualizada: Obtén la definición de YAML existente: kubectl get stackdriver -n kube-system stackdriver \ -o yaml > stackdriver.yaml Habilita funciones o actualiza la configuración en el archivo YAML. Vuelve a aplicar el archivo YAML actualizado: kubectl apply -f stackdriver.yaml El paso final para kubectl apply es donde podrías tener problemas. Solución alternativa: No uses kubectl apply para realizar cambios en recursos existentes. En su lugar, usa kubectl edit o kubectl patch, como se muestra en los siguientes ejemplos: Edita el recurso personalizado Stackdriver: kubectl edit stackdriver -n kube-system stackdriver Habilita funciones o actualiza la configuración en el archivo YAML. Guarda y cierra el editor. Enfoque alternativo con kubectl patch: Obtén la definición de YAML existente: kubectl get stackdriver -n kube-system stackdriver \ -o yaml > stackdriver.yaml Habilita funciones o actualiza la configuración en el archivo YAML. 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 y 1.16	Los fragmentos de backlog dañados provocan un bucle de fallas de stackdriver-log-forwarder El stackdriver-log-forwarder se bloquea en un bucle si intenta procesar un fragmento de la lista de tareas pendientes dañado. En los registros del contenedor, se muestran los siguientes errores de ejemplo: [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 se produce este bucle de fallas, no puedes ver los registros en Cloud Logging. Solución alternativa: Para resolver estos errores, completa los siguientes pasos: Identifica los fragmentos dañados del backlog. 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 almacena en var/log/fluent-bit-buffers/tail.1/ está en falta. Se debe quitar cada archivo *.flb en el que falló la verificación de formato. 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 a tu archivo kubeconfig del clúster de usuario. Verifica que los Pods stackdriver-log-forwarder se borren antes de continuar con el siguiente paso. Conéctate al nodo con SSH en el que se ejecuta stackdriver-log-forwarder. 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 pendientes, usa las siguientes secuencias de comandos: Implementa un DaemonSet para limpiar todos los datos no válidos en los 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 Asegúrate de que el DaemonSet haya limpiado 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 Borra el DaemonSet de limpieza: kubectl --kubeconfig KUBECONFIG -n kube-system delete ds \ fluent-bit-cleanup 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"}]'
Redes, entorno de ejecución de VM en GDC	1.14.0	Reiniciar Dataplane V2 (anetd) en los clústeres puede provocar que las VMs existentes no puedan adjuntarse a la red que no es de Pod. En los clústeres con varias NIC, reiniciar Dataplane V2 (anetd) puede provocar que las máquinas virtuales no puedan adjuntarse a las redes. Es posible que se observe un error similar al siguiente en los registros del pod de 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 se repita el problema, actualiza tu clúster a la versión 1.14.1 o a una posterior.
Operación	1.13, 1.14.0 y 1.14.1	gke-metrics-agent no tiene límite de memoria en los clústeres de perfiles perimetrales Según la carga de trabajo del clúster, el gke-metrics-agent podría usar más de 4608 MiB de memoria. Este problema solo afecta a los clústeres de perfil perimetral de Google Distributed Cloud para Bare Metal. 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 y 1.13	Es posible que la creación del clúster falle debido a condiciones de carrera Cuando creas clústeres con kubectl, es posible que la comprobación previa nunca finalice debido a condiciones de carrera. Por lo tanto, la creación del clúster puede fallar en ciertos casos. El conciliador de la verificación previa al vuelo crea un SecretForwarder para copiar el Secret ssh-key predeterminado en el espacio de nombres de destino. Por lo general, la verificación previa aprovecha las referencias del propietario y se reconcilia una vez que se completa la SecretForwarder. Sin embargo, en casos excepcionales, las referencias del propietario de SecretForwarder pueden perder la referencia a la verificación previa, lo que provoca que esta se detenga. Como resultado, falla la creación del clúster. Para continuar con la conciliación de la verificación previa controlada por el controlador, borra el pod de cluster-operator o el recurso de preflight-check. Cuando borras el recurso de verificación previa al vuelo, se crea otro y se continúa con la conciliación. Como alternativa, puedes actualizar tus clústeres existentes (que se crearon con una versión anterior) a una versión corregida.
Redes	1.9, 1.10, 1.11, 1.12, 1.13, 1.14 y 1.15	Las direcciones IP reservadas no se liberan cuando se usa el complemento whereabouts con la función de varias NIC En la función de varias NIC, si usas el complemento whereabouts de CNI y la operación DEL de CNI para borrar una interfaz de red de un Pod, es posible que algunas direcciones IP reservadas no se liberen correctamente. Esto sucede cuando se interrumpe la operación DEL de CNI. Puedes verificar las reservas de direcciones IP no utilizadas de los Pods ejecutando el siguiente comando: kubectl get ippools -A --kubeconfig KUBECONFIG_PATH Solución alternativa: Borra manualmente las direcciones IP (ippools) que no se usen.
Instalación	1.10, 1.11.0, 1.11.1 y 1.11.2	Falla el detector de problemas de nodos en el clúster de usuario 1.10.4 Es posible que el Detector de problemas de nodos falle 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 administren clústeres de usuario de la versión 1.10.x. Cuando falla el detector de problemas del nodo, 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 de clúster IPv4 en modo isla de la versión 1.14 tienen un tamaño de máscara de CIDR de Pod de 24. En la versión 1.14, el parámetro de configuración maxPodsPerNode no se tiene en cuenta para los clústeres en modo aislado, por lo que a los nodos se les asigna un tamaño de máscara de CIDR de Pod de 24 (256 direcciones IP).Esto puede hacer que el clúster se quede sin direcciones IP de 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 en la red durante un período de alta rotación de pods cuando maxPodsPerNode se establece en 129 o más y no hay suficiente sobrecarga en el CIDR del pod para cada nodo. Este problema solo afecta a los clústeres IPv4 en modo isla que usan maxPodsPerNode fuera del rango de 65 a 128. 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 un podCIDR disponible: error="required IPv4 PodCIDR not available" Solución alternativa Sigue estos pasos para resolver el problema: Actualiza a la versión 1.14.1 o una posterior. Quita los nodos trabajadores y vuelve a agregarlos. Quita los nodos del plano de control y vuelve a agregarlos, de preferencia uno por uno para evitar el tiempo de inactividad del clúster.
Revisiones y actualizaciones	1.14.0 y 1.14.1	Error en la reversión de la actualización del clúster Es posible que falle la reversión de la actualización para los clústeres de las versiones 1.14.0 o 1.14.1. Si actualizas un clúster de la versión 1.14.0 a la 1.14.1 y, luego, intentas revertir a la versión 1.14.0 con el comando bmctl restore cluster, es posible que se muestre un error como el 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 en el espacio de nombres del clúster y, luego, vuelve a ejecutar el comando bmctl restore cluster: Enumera todos los recursos de healthchecks.baremetal.cluster.gke.io: 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 al archivo kubeconfig del clúster de administrador. Borra todos los recursos de healthchecks.baremetal.cluster.gke.io que se enumeraron 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. Vuelve a ejecutar el comando bmctl restore cluster.
Redes	1.12.0	La dirección IP externa del servicio no funciona en el modo plano. En un clúster que tiene flatIPv4 establecido en true, no se puede acceder a los servicios de tipo LoadBalancer por sus direcciones IP externas. Este problema se corrigió en la versión 1.12.1. Solución alternativa: En el ConfigMap cilium-config, establece enable-415 en "true" y, luego, reinicia los Pods anetd.
Revisiones y actualizaciones	1.13.0 y 1.14	Las actualizaciones locales de 1.13.0 a 1.14.x nunca finalizan Cuando intentas realizar una actualización en un solo lugar de la versión 1.13.0 a la 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 previa nunca finaliza. Solución alternativa: Primero, 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 la versión 1.13.0 a la 1.13.1. O bien, actualiza de 1.13.0 a 1.14.x sin la marca --use-bootstrap=false.
Actualizaciones y revisiones, seguridad	1.13 y 1.14	Los clústeres actualizados a la versión 1.14.0 pierden las marcas de la instancia principal Los nodos del plano de control requieren uno de los dos taints específicos para evitar que se programen en ellos los pods de carga de trabajo. Cuando actualizas los clústeres de la versión 1.13 a la versión 1.14.0, los nodos del plano de control pierden los siguientes contaminantes obligatorios: node-role.kubernetes.io/master:NoSchedule node-role.kubernetes.io/master:PreferNoSchedule Nota: Los clústeres de administración automática, como los de tipo independiente, usan el aislamiento PreferNoSchedule de forma predeterminada. Este problema no provoca fallas en la actualización, pero es posible que los Pods que no deberían ejecutarse en los nodos del plano de control comiencen a hacerlo. Estos Pods de carga de trabajo pueden sobrecargar los nodos del plano de control y provocar inestabilidad en el clúster. Determina si te afecta Para encontrar 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 Para verificar la lista de taints en un nodo, usa el siguiente comando: kubectl describe node NODE_NAME \ --kubeconfig KUBECONFIG_PATH Si no se indica ninguno de los dos, significa que te afecta. Solución alternativa Sigue estos pasos para cada nodo del plano de control de tu clúster afectado de la versión 1.14.0 para restablecer el funcionamiento adecuado. 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 la marca PreferNoSchedule, ajusta los pasos según corresponda. Ver los pasos de la solución alternativa Aplica el aislamiento faltante: kubectl taint nodes NODE_NAME \ node-role.kubernetes.io/master:NoSchedule \ -–kubeconfig KUBECONFIG_PATH Busca pods sin la tolerancia node-role.kubernetes.io/master:NoSchedule: kubectl get pods -A --field-selector spec.nodeName="NODE_NAME" \ -o=custom-columns='Name:metadata.name,Toleration:spec.tolerations[*].key' \ --kubeconfig KUBECONFIG_PATH | \ grep -v "node-role.kubernetes.io/master" | uniq Borra los pods que no tienen la tolerancia node-role.kubernetes.io/master:NoSchedule: kubectl delete pod POD_NAME –-kubeconfig KUBECONFIG_PATH
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, 1.30, 1.31	La creación de la VM falla de forma intermitente con errores de carga La creación de una nueva máquina virtual (VM) 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 parecerá 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 la VM.
Actualizaciones y revisiones, registro y supervisión	1.11	Los componentes de recopilación administrada en clústeres 1.11 no se conservan en las actualizaciones a la versión 1.12 Los componentes de recopilación administrada forman parte del servicio administrado para Prometheus. Si implementaste manualmente los componentes de la colección administrada en el espacio de nombres gmp-system de tus clústeres de la versión 1.11, los recursos asociados no se conservarán cuando actualices a la versión 1.12. A partir de la versión 1.12.0 de los clústeres, stackdriver-operator administra los componentes del servicio administrado para Prometheus en el espacio de nombres gmp-system y las definiciones de recursos personalizados relacionados con el campo enableGMPForApplications. El campo enableGMPForApplications tiene el valor predeterminado true, por lo que, si implementas manualmente 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 administrados manualmente, haz lo siguiente: Crea una copia de seguridad de todos los recursos personalizados de PodMonitoring existentes. Actualiza el clúster a la versión 1.12 y habilita el servicio administrado para Prometheus. 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 tiempo de ejecución del contenedor 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 volver a intentarla.
Instalación	1.11	bmctl sale antes de que se complete la creación del clúster. La creación de clústeres puede fallar para la versión 1.11.0 de Google Distributed Cloud (este problema se solucionó en la versión 1.11.1 de Google Distributed Cloud). En algunos casos, el comando bmctl create cluster sale con anticipación 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 funciona. Si este problema te afecta, sigue estos pasos para limpiar los artefactos y crear un clúster: Ver los pasos de la solución alternativa Para borrar los artefactos del clúster y restablecer la máquina del nodo, ejecuta el siguiente comando: bmctl reset -c USER_CLUSTER_NAME Para iniciar la operación de creación de clústeres, ejecuta el siguiente comando: bmctl create cluster -c USER_CLUSTER_NAME \ --keep-bootstrap-cluster La marca --keep-bootstrap-cluster es importante si este comando falla. Si el comando de creación del clúster se ejecuta de forma correcta, puedes omitir los pasos restantes. De lo contrario, continúa. Ejecuta el siguiente comando para obtener la versión del clúster de arranque: kubectl get cluster USER_CLUSTER_NAME \ -n USER_CLUSTER_NAMESPACE \ --kubeconfig bmctl-workspace/.kindkubeconfig \ -o=jsonpath='{.status.anthosBareMetalVersion} El resultado debería ser 1.11.0. Si el resultado no es 1.11.0, espera uno o dos minutos y vuelve a intentarlo. Para mover manualmente los recursos del clúster de arranque al clúster de destino, ejecuta el siguiente comando: bmctl move --from-kubeconfig bmctl-workspace/.kindkubeconfig \ --to-kubeconfig \ bmctl-workspace/USER_CLUSTER_NAME/USER_CLUSTER_NAME-kubeconfig \ -n USER_CLUSTER_NAMESPACE Para borrar el clúster, ejecuta el siguiente comando: bmctl reset bootstrap
Instalación, entorno de ejecución de VM en GDC	1.11 y 1.12	Errores de conciliación del entorno de ejecución de VM que informa la 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 y 1.12	La creación del clúster falla cuando se usan varias NIC, containerd y un proxy HTTPS La creación de clústeres 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 configurado como containerd en el archivo de configuración del clúster, la opción predeterminada para la versión 1.13 y posteriores de Google Distributed Cloud). El clúster está configurado para proporcionar interfaces de red múltiples, varias NIC, para los Pods (clusterNetwork.multipleNetworkInterfaces configurado como true en el archivo de configuración del clúster). El clúster se configura para usar un proxy (spec.proxy.url se especifica en el archivo de configuración del clúster). Aunque la creación de clústeres falla, este parámetro de configuración se propaga cuando intentas crear un clúster. Es posible que veas esta configuración de proxy como una variable de entorno HTTPS_PROXY o en la configuración de containerd (/etc/systemd/system/containerd.service.d/09-proxy.conf). Solución alternativa Agrega los CIDR de servicio (clusterNetwork.services.cidrBlocks) a la variable de entorno NO_PROXY en todas las máquinas de nodos.
Instalación	1.10, 1.11 y 1.12	Falla en sistemas con un parámetro de configuración umask restrictivo La versión 1.10.0 de Google Distributed Cloud 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 provocar fallas de instalación o actualización en los sistemas con un parámetro de configuración umask más restrictivo de 0077. Solución alternativa Restablece los nodos del plano de control y cambia el parámetro de configuración umask a 0022 en todas las máquinas del plano de control. Una vez actualizadas las máquinas, vuelve a intentar la instalación. Como alternativa, puedes cambiar los permisos del directorio y del archivo de /etc/kubernetes en las máquinas de plano de control para que la instalación o la actualización continúen. Haz que /etc/kubernetes y todos sus subdirectorios sean legibles para todo el mundo: chmod o+rx. Haz que todos los archivos que son propiedad del usuario root en el directorio (de forma recursiva) /etc/kubernetes sean legibles para todo el mundo (chmod o+r). Excluye los archivos de claves privadas (.key) de estos cambios, ya que ya 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 y 1.13	Incompatibilidad del grupo de control v2 El grupo de control v2 (cgroup v2) no es compatible con las versiones 1.13 y anteriores de Google Distributed Cloud. Sin embargo, la versión 1.14 admite cgroup v2 como una 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 el 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 y 1.29	Verificaciones de comprobación previa y credenciales de cuentas de servicio Para las instalaciones activadas por clústeres híbridos o de administrador (en otras palabras, clústeres no creados con bmctl, como clústeres de usuarios), la verificación de comprobació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, 1.30	Realiza la instalación en vSphere Cuando instales clústeres de equipos físicos 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 que realiza el controlador de vSphere VMXNET3 y no funcionan con el túnel GENEVE de clústeres de equipos físicos. 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 debería tener entradas como las siguientes: ... tx-udp_tnl-segmentation: on tx-udp_tnl-csum-segmentation: on ... En ocasiones, en RHEL 8.4, ethtool muestra que estas marcas están desactivadas cuando no lo están. Para desactivar estas marcas de manera explícita, activa y desactiva las marcas 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 que establezcan 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 versión inferior La CLI de bmctl no puede crear, actualizar ni restablecer un clúster de usuario con una versión secundaria inferior, 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 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 los registros similares al siguiente 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	Las actualizaciones de clústeres a la versión 1.12.1 pueden detenerse. A veces, la actualización de clústeres a la versión 1.12.1 se detiene debido a que el servidor de la API deja de estar disponible. Este problema afecta a todos los tipos de clústeres y a todos los sistemas operativos compatibles. Cuando se produce este problema, el comando bmctl upgrade cluster puede fallar en varios puntos, incluso durante la segunda fase de las verificaciones previas al vuelo. Solución alternativa Puedes consultar tus registros de actualización para determinar si este problema te afecta. De forma predeterminada, los registros de actualización se encuentran en /baremetal/bmctl-workspace/CLUSTER_NAME/log/upgrade-cluster-TIMESTAMP. El formulario 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 repetidas 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). ... HAProxy 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 HAProxy o Keepalived no se ejecutan en un nodo, reinicia kubelet en el nodo: systemctl restart kubelet
Actualizaciones del entorno de ejecución de VM en GDC	1.11 y 1.12	La actualización de los clústeres a la versión 1.12.0 o una superior falla cuando se habilita el entorno de ejecución de VM en GDC. En los clústeres de la versión 1.12.0, 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 la versión de DG del entorno de ejecución de VM en 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 una versión posterior fallará, a menos que primero inhabilite el entorno de ejecución de VM en GDC. Cuando te afecta 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 VM en GDC, haz lo siguiente: Edita el recurso personalizado VMRuntime: kubectl edit vmruntime Establece enabled como false en la especificación: apiVersion: vm.cluster.gke.io/v1 kind: VMRuntime metadata: name: vmruntime spec: enabled: false ... Guarda el recurso personalizado en tu editor. 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 Habilita o inhabilita el entorno de ejecución de VM en GDC.
Revisiones y actualizaciones	1.10, 1.11 y 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 un recurso actualizado de forma incorrecta. Para determinar si este problema te afecta y corregirlo, verifica 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 del problema. Solución alternativa Si encuentras estos errores en tus registros, completa los siguientes pasos: Usa kubectl edit para quitar la anotación kubectl.kubernetes.io/last-applied-configuration del recurso que el mensaje de registro contiene. Guarda los cambios y aplícalos al recurso. Vuelve a intentar la actualización del clúster.
Revisiones y actualizaciones	1.10, 1.11 y 1.12	Las actualizaciones se bloquean para los clústeres con funciones que usan Network Gateway para GDC Las actualizaciones de clúster de la versión 1.10.x a la 1.11.x fallan para los clústeres que usan la puerta de enlace NAT de salida o el balanceo de cargas en paquetes con BGP. Ambas funciones usan Network Gateway para GDC. Las actualizaciones de clúster se atascan en el mensaje de la línea de comandos Waiting for upgrade to complete... y los errores de registro anthos-cluster-operator como los siguientes: apply run failed ... MatchExpressions:[]v1.LabelSelectorRequirement(nil)}: field is immutable... Solución alternativa Precaución: La siguiente solución alternativa borra los manifiestos y provoca un breve tiempo de inactividad de 30 a 60 segundos para el balanceo de cargas en paquetes con BGP. Las sesiones de BGP se descartan y se restablecen, y los servicios LoadBalancer no están disponibles durante este período. La función se restablece cuando anthos-cluster-operator reinstala los manifiestos. 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 y 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 los nodos del modo de mantenimiento, consulta Coloca los nodos en modo de mantenimiento.
Operación	1.10, 1.11 y 1.12	Los nodos se desacordonan 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 manualmente en un nodo, es posible que Google Distributed Cloud en Bare Metal desacordone el nodo antes de que esté listo en un intento por conciliar el estado esperado. Solución alternativa En el caso de los clústeres de la versión 1.12.0 y anteriores, usa el modo de mantenimiento para acordonar y drenar los nodos de forma segura. En la versión 1.12.1 (anthosBareMetalVersion: 1.12.1) o posterior, Google Distributed Cloud en equipos físicos no desacordonará tus 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 de registro no pueden administrar los clústeres de la versión 1.10 Si tu clúster de administrador está en la versión 1.11 y usa una duplicación de registro, no puede administrar clústeres de usuario que estén en una versión secundaria inferior. Este problema afecta las operaciones de restablecimiento, actualización y actualización en el clúster de usuario. Para determinar si este problema te afecta, revisa los registros de las operaciones del 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 y 1.11	Se reemplazó el objeto Secret de kubeconfig El comando bmctl check cluster, cuando se ejecuta en clústeres de usuarios, reemplaza el objeto Secret de kubeconfig del clúster de usuario por el archivo kubeconfig del clúster de administrador. Reemplazar el archivo hace que las operaciones de clúster estándar, como la actualización, no funcionen en los clústeres de usuario afectados. Este problema se aplica a las versiones de clúster 1.11.1 y anteriores. Para determinar si este problema afecta 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 al archivo kubeconfig del clúster de administrador. USER_CLUSTER_NAMESPACE: Es el espacio de nombres del clúster. De forma predeterminada, los nombres de los espacios de nombres del clúster son el nombre del clúster precedido por cluster-. Por ejemplo, si le asignas el nombre test al 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 verá 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 En los siguientes pasos, se restablece la función a un clúster de usuario afectado (USER_CLUSTER_NAME): Ubica el archivo kubeconfig del clúster de usuario. Google Distributed Cloud para equipos físicos genera el archivo kubeconfig en la estación de trabajo de administrador cuando creas un clúster. De forma predeterminada, el archivo está en el directorio bmctl-workspace/USER_CLUSTER_NAME. Verifica que el archivo kubeconfig sea el archivo 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. En la respuesta, se muestran detalles sobre los nodos del clúster de usuario. Confirma que los nombres de las máquinas sean correctos para tu clúster. 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 Ejecuta el siguiente comando para guardar el secret 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, 1.30	Captura una instantánea como usuario no raíz de acceso Si usas containerd como entorno de ejecución del contenedor, la ejecución de la instantánea como usuario no raíz requiere que /usr/local/bin esté en la RUTA del usuario. De lo contrario, fallará con un error crictl: command not found. Cuando no accedes como el usuario raíz, sudo se usa para ejecutar los comandos de la instantánea. La RUTA sudo puede diferir del perfil raíz y puede no 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 tiempo de ejecución del contenedor (CRI) usa una expresión regular incorrecta para analizar el tiempo, los registros del Pod stackdriver-log-forwarder contendrán 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: Ver los pasos de la solución alternativa Actualiza tu clúster a la versión 1.11.0 o posterior. Si no puedes actualizar tus clústeres de inmediato, sigue estos pasos para actualizar la regex de análisis de CRI: Para evitar que los cambios se reviertan, reduce verticalmente la escala de stackdriver-operator: kubectl --kubeconfig KUBECONFIG \ -n kube-system scale deploy \ stackdriver-operator --replicas=0 Edita la entrada Regex en el ConfigMap stackdriver-log-forwarder-config: kubectl --kubeconfig KUBECONFIG \ -n kube-system edit configmap \ stackdriver-log-forwarder-config El recurso editado debe ser similar al siguiente: [PARSER] # https://rubular.com/r/Vn30bO78GlkvyB Name cri Format regex # The timestamp is described in https://www.rfc-editor.org/rfc/rfc3339#section-5.6 Regex ^(?<time>[0-9]{4}-[0-9]{2}-[0-9]{2}[Tt ][0-9] {2}:[0-9]{2}:[0-9]{2}(?:\.[0-9]+)?(?:[Zz]|[+-][0-9] {2}:[0-9]{2})) (?<stream>stdout|stderr) (?<logtag>[^ ]*) (?<log>.*)$ Time_Key time Time_Format %Y-%m-%dT%H:%M:%S.%L%z Time_Keep off Reinicia los Pods del agente de reenvío de registros: kubectl --kubeconfig KUBECONFIG \ -n kube-system rollout restart daemonset \ stackdriver-log-forwarder
Registro y supervisión	1.10, 1.11, 1.12, 1.13, 1.14 y 1.15	Facturación inesperada de supervisión En el caso de las versiones de clúster del 1.10 al 1.15, algunos clientes observaron una facturación inesperadamente alta para Metrics volume en la página Facturación. Este problema te afecta solo cuando se aplican todas las circunstancias siguientes: La supervisión de la aplicación está habilitada (enableStackdriverForApplications=true) Managed Service for 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 una facturación por métricas no deseadas, entonces este problema se aplica a tu caso. Solución alternativa Si este problema te afecta, te recomendamos que actualices tus clústeres a la versión 1.12 y que cambies a la nueva solución de supervisión de aplicaciones managed-service-for-prometheus que soluciona este problema: Marcas separadas para controlar la recopilación de registros de la aplicación en comparación con las métricas de la aplicación Google Cloud Managed Service para Prometheus incluido Si no puedes actualizar a la versión 1.12, sigue estos pasos: Busca los Pods y los 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"' 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	Las modificaciones que se realizaron en metrics-server-config no se conservan. La densidad alta de Pods puede, en casos extremos, 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 el servidor de métricas en ejecución. Sin embargo, debido a la conciliación, las modificaciones que se realicen 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 reinicie, seleccionará el ConfigMap revertido y será vulnerable a una sobrecarga excesiva. Solución alternativa En la versión 1.11.x, puedes ejecutar una secuencia de comandos en la edición del ConfigMap y realizarla junto con las 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 y 1.12	Las métricas obsoletas afectan al panel de Cloud Monitoring. Varias métricas de Google Distributed Cloud solo para software dejaron de estar disponibles y, a partir de la versión 1.11 de Google Distributed Cloud, 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á datos 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 del clúster anteriores a la 1.11, el archivo de definición de políticas para la alerta 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 actualizó para las versiones 1.11.0 y posteriores. Solución alternativa Sigue estos pasos para migrar a las métricas de reemplazo: En la Google Cloud consola, selecciona Monitoring o haz clic en el siguiente botón: Ir a Monitoring En el panel de navegación, selecciona Paneles y borra el panel Estado del nodo del clúster de Anthos. Haz clic en la pestaña Biblioteca de muestra y vuelve a instalar el panel de estado del nodo del clúster de Anthos. Sigue las instrucciones en Crea políticas de alertas para crear una política con el archivo de definición de políticas node-cpu-usage-high.json actualizado.
Registro y supervisión	1.10 y 1.11	stackdriver-log-forwarder tiene errores CrashloopBackOff En algunas situaciones, el agente de registro fluent-bit puede atascarse en el procesamiento de fragmentos dañados. Cuando el agente de registro no puede omitir los fragmentos dañados, es posible que observes que stackdriver-log-forwarder falla con un error CrashloopBackOff. Si tienes este problema, tus registros tendrán 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 de búfer para el agente 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. 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 borren antes de continuar con el siguiente paso. 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 Usa los siguientes comandos para verificar que 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. Borra el DaemonSet de limpieza: kubectl --kubeconfig KUBECONFIG -n \ kube-system delete ds fluent-bit-cleanup Reinicia los Pods del agente 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 desconocido de métricas 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. Es posible que genere 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, incluidos los siguientes (sin limitaciones): 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 sin problemas, ya que las métricas a las que hacen referencia no son compatibles y no son críticas para fines de supervisión.
Registro y supervisión	1.10 y 1.11	Interrupciones intermitentes en la exportación de métricas Es posible que los clústeres experimenten interrupciones en la exportación normal y continua de métricas, o que falten métricas en algunos nodos. Si este problema afecta tus clústeres, es posible que veas vacíos 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 tus clústeres a la versión 1.11.1 o posterior. Si no puedes actualizar, realiza los siguientes pasos como una solución alternativa: Abre tu recurso stackdriver para editarlo: kubectl -n kube-system edit stackdriver stackdriver Para aumentar la solicitud de CPU de gke-metrics-agent de 10m a 50m, agrega la siguiente sección resourceAttrOverride al manifiesto stackdriver: spec: resourceAttrOverride: gke-metrics-agent/gke-metrics-agent: limits: cpu: 100m memory: 4608Mi requests: cpu: 50m memory: 200Mi El recurso editado debe ser similar al siguiente: 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 Guarda los cambios y cierra el editor de texto. Para verificar que los cambios se aplicaron, 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.
Redes	1.10	Múltiples puertas de enlace predeterminadas interrumpen la conectividad a extremos externos Tener múltiples puertas de enlace predeterminadas en un nodo puede provocar que la conectividad se interrumpa desde un Pod hacia extremos externos, como google.com. Para determinar si este problema te afecta, ejecuta el siguiente comando en el nodo: ip route show Múltiples instancias de default en la respuesta indican que te afecta.
Redes	1.12	Se reemplazan las ediciones de recursos personalizados de redes en clústeres de usuarios. Los clústeres de la versión 1.12.x no te impiden editar manualmente los recursos personalizados de redes en tu clúster de usuario. Google Distributed Cloud reconcilia los recursos personalizados en los clústeres de usuario con los recursos personalizados en tu clúster de administrador durante las actualizaciones del clúster. Esta conciliación reemplaza cualquier edición realizada directamente en los recursos personalizados de redes del clúster de usuario. Los recursos personalizados de redes solo se deben modificar en el clúster de administrador, pero los clústeres de la versión 1.12.x no aplican este requisito. Las funciones de redes avanzadas, como el balanceo de cargas en paquetes con BGP, la puerta de enlace NAT de salida, las redes SR-IOV, el modo plano con BGP y la NIC múltiple para Pods usan los siguientes recursos personalizados: BGPLoadBalancer BGPPeer NetworkGatewayGroup NetworkAttachmentDefinition ClusterCIDRConfig FlatIPMode Editas estos recursos personalizados en tu clúster de administrador y el paso de reconciliación aplica los cambios a tus 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 realizar la actualización. Este paso garantiza que se conserven los cambios de configuración. Las versiones de clúster 1.13.0 y posteriores impiden que modifiques directamente los recursos personalizados de redes en tus clústeres de usuario.
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 Google Distributed Cloud configura el filtrado de ruta de acceso inversa en los nodos para inhabilitar la validación de origen (net.ipv4.conf.all.rp_filter=0). Si el parámetro de configuración rp_filter se cambia a 1 o 2, los pods fallarán debido a que se agotaron los tiempos de espera de la comunicación fuera del nodo. El filtrado de ruta de acceso inversa se establece con los archivos rp_filter en la carpeta de configuración de IPv4 (net/ipv4/conf/all). También es posible que sysctl anule este valor, que almacena la configuración del filtrado de la ruta de acceso inversa en un archivo de configuración de seguridad de red, como /etc/sysctl.d/60-gce-network-security.conf. Solución alternativa Para restablecer la conectividad del Pod, puedes realizar cualquiera 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 en 0. Para reiniciar el Pod anetd, usa los siguientes comandos para ubicar y borrar el Pod anetd, y se iniciará un nuevo Pod anetd 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 aplicar cualquiera de las soluciones alternativas, verifica que el valor de net.ipv4.conf.all.rp_filter esté establecido en 0 ejecutando sysctl net.ipv4.conf.all.rp_filter en cada nodo.
Redes	1.10, 1.11, 1.12, 1.13, 1.14, 1.15, 1.16, 1.28, 1.29, 1.30, 1.31, 1.32, 1.33, 1.34	Direcciones IP del clúster de arranque (kind) y superposición de direcciones IP de nodo del clúster 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 (kind). Las verificaciones de comprobación previa 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 de clústeres falla en CentOS En diciembre de 2020, la comunidad de CentOS y Red Hat anunciaron la desactivación de CentOS. El 31 de enero de 2022, CentOS 8 llegó al final del ciclo de vida (EOL). Como resultado del EOL, los repositorios yum dejaron de funcionar para CentOS, lo que hace que las operaciones de creación y actualización del clústeres fallen. Esto se aplica a todas las versiones compatibles de CentOS y afecta a todas las versiones de los clústeres. Solución alternativa Ver los pasos de la solución alternativa Como solución alternativa, ejecuta los siguientes comandos para que CentOS use un feed de archivos: sed -i 's/mirrorlist/#mirrorlist/g' /etc/yum.repos.d/CentOS-Linux-* sed -i 's|#baseurl=http://mirror.centos.org|baseurl=http://vault.centos.org|g' \ /etc/yum.repos.d/CentOS-Linux-* Como solución a largo plazo, considera migrar a otro sistema operativo compatible.
Seguridad	1.10, 1.11, 1.12, 1.13, 1.14, 1.15, 1.16, 1.28	El contenedor no puede escribir en el VOLUME definido en el 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 no se pueda escribir en el VOLUME definido en el Dockerfile de la aplicación. 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 este problema te afecta, 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 de Dockerfile.
Revisiones y actualizaciones	1.10, 1.11 y 1.12	Node Problem Detector no está habilitado de forma predeterminada después de las actualizaciones del clúster Cuando actualizas clústeres, el detector de problemas del nodo no se habilita 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 del nodo, haz lo siguiente: Verifica si el servicio node-problem-detector systemd se está ejecutando en el nodo. Usa el comando SSH y conéctate al nodo. Verifica si el servicio node-problem-detector systemd se está ejecutando en el nodo: systemctl is-active node-problem-detector Si el resultado del comando muestra inactive, el detector de problemas del nodo no se está ejecutando en el nodo. Para habilitar el detector de problemas del nodo, usa el comando kubectl edit y edita el ConfigMap node-problem-detector-config. Para obtener más información, consulta Node Problem Detector.
Operación	1.9 y 1.10	La copia de seguridad del clúster falla cuando se usa un acceso no raíz. El comando bmctl backup cluster falla si nodeAccess.loginUser se establece en 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 solucionó en la versión 1.10.2 y posteriores.
Redes	1.10, 1.11 y 1.12	Los servicios de balanceador de cargas no funcionan con contenedores en la red del host del plano de control. Hay un error en anetd en el que se descartan paquetes 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 la especificación 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 ayudarte si usas un servicio LoadBalancer respaldado por Pods hostNetwork: Ejecútalos en nodos trabajadores (no en nodos del plano de control). Usa externalTrafficPolicy: local en la especificación del Service y asegúrate de que tus cargas de trabajo se ejecuten en los nodos del balanceador de cargas.
Actualizaciones	1.12 y 1.13	El pod anthos-version-$version$ huérfano no puede extraer la imagen Es posible que la actualización del clúster de la versión 1.12.x a la 1.13.x muestre un pod anthos-version-$version$ con errores de ImagePullBackOff. Esto sucede debido a la condición de carrera de anthos-cluster-operator que se actualiza 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 con kubectl delete job anthos-version-$version$ -n kube-system
Revisiones y actualizaciones	1.13	Los clústeres 1.12 actualizados desde 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 afecta, revisa 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, significa que te afecta el problema. 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: Ejecuta los siguientes comandos en tu 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' Vuelve a intentar la actualización del clúster.
Logging y Monitoring	1.16.2 y 1.16.3	Uso alto 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 la CPU es inferior a 50 miliCPU (50m) para stackdriver-operator en estado de inactividad. La causa es una falta de coincidencia de los recursos Certificate que stackdriver-operator aplica con las expectativas de cert-manager. Esta falta de coincidencia provoca una condición de carrera entre cert-manager y stackdriver-operator al actualizar esos recursos. Este problema puede reducir el rendimiento en clústeres con disponibilidad limitada de CPU. Solución alternativa: Hasta que puedas actualizar a una versión que corrija este error, usa la siguiente solución alternativa: Para reducir temporalmente la escala de stackdriver-operator a 0 réplicas, aplica un recurso personalizado AddonConfiguration: kubectl scale deploy stackdriver-operator --replicas=0 Una vez que hayas actualizado a una versión que corrige este problema, vuelve a escalar stackdriver-operator: kubectl scale deploy stackdriver-operator --replicas=1
Logging y Monitoring	1.16.0 y 1.16.1	No funciona la recuperación de métricas basadas en anotaciones En la versión secundaria 1.16 de Google Distributed Cloud, el campo enableStackdriverForApplications en la especificación del recurso personalizado stackdriver dejó de estar disponible. Este campo se reemplaza por dos campos, enableCloudLoggingForApplications y enableGMPForApplications, en el recurso personalizado de Stackdriver. Te recomendamos que uses Google Cloud Managed Service para Prometheus para 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 las anotaciones prometheus.io/scrape en tus cargas de trabajo, puedes usar la marca de la puerta de acceso a la función annotationBasedApplicationMetrics para mantener el comportamiento anterior. Sin embargo, hay un problema que impide que annotationBasedApplicationMetrics funcione correctamente, lo que a su vez impide que se recopilen 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 posterior. La recopilación de métricas de cargas de trabajo basadas en anotaciones que habilita el acceso anticipado a la función annotationBasedApplicationMetrics recopila métricas para los objetos que tienen la anotación prometheus.io/scrape. Muchos sistemas de software de código abierto pueden usar esta anotación. Si sigues usando este método de recopilación de métricas, ten en cuenta esta dependencia para que no te sorprendan los cargos por métricas en Cloud Monitoring.
Logging y Monitoring	1.15, 1.16, 1.28.0 a 1.28.900, 1.29.0 a 1.29.400, 1.30.0, 1.30.100	Falla de Cloud Audit Logging debido a que se denegó el permiso Los registros de auditoría de Cloud necesitan una configuración de permisos especial que el operador de clúster realiza automáticamente a través de GKE Hub. Sin embargo, en los casos en los que un clúster de administrador administraba varios clústeres con diferentes IDs del proyecto, un error en cluster-operator hacía que la misma cuenta de servicio se agregara a la lista de entidades permitidas de forma repetida y que fallara la solicitud de inclusión en la lista de entidades permitidas debido a la limitación de tamaño. Esto provocaría que no se insertaran en Google Cloudlos registros de auditoría de algunos o todos estos clústeres. El síntoma es una serie de errores Permission Denied en el Pod audit-proxy del clúster afectado. Otro síntoma es el estado de error y una larga lista de cuentas de servicio duplicadas cuando verificas la lista de entidades permitidas de los registros de auditoría de Cloud a través de GKE Hub: curl -H "Authorization: Bearer $(gcloud auth print-access-token)" \ https://gkehub.googleapis.com/v1alpha/projects/PROJECT_ID/locations/global/features/cloudauditlogging { "name": "projects/PROJECT_ID/locations/global/features/cloudauditlogging", "spec": { "cloudauditlogging": { "allowlistedServiceAccounts": [ "SERVICE-ACCOUNT-EMAIL", ... ... multiple lines of the same service account ] } }, "state": { "state": { "code": "ERROR" } } } Para resolver el problema, puedes actualizar tu clúster a la versión 1.28.1000, 1.29.500 o 1.30.200, en la que se corrigió el problema, o bien aplicar la siguiente solución alternativa: Ver los pasos de la solución alternativa Borra y vuelve a crear la función de registro de auditoría de Cloud de GKE Hub para forzar la activación de la automatización de la lista de entidades permitidas. Para borrar la función cloudauditlogging de Hub, haz lo siguiente: curl -X DELETE -H "Authorization: Bearer $(gcloud auth print-access-token)" \ https://gkehub.googleapis.com/v1alpha/projects/PROJECT_ID/locations/global/features/cloudauditlogging Vuelve a crear la función de Hub cloudauditlogging de la siguiente manera: curl -X POST -H "Authorization: Bearer $(gcloud auth print-access-token)" \ -H "Content-Type: application/json" \ https://gkehub.googleapis.com/v1alpha/projects/PROJECT_ID/locations/global/features?feature_id=cloudauditlogging -d \ '{"spec":{"cloudauditlogging":{"allowlistedServiceAccounts":["SERVICE_ACCOUNT_EMAIL"]}}}' En los comandos anteriores: Reemplaza PROJECT_ID por el proyecto de operaciones del clúster. Reemplaza SERVICE_ACCOUNT_EMAIL por la dirección de correo electrónico de la cuenta de servicio de registro y supervisión del clúster.
Configuración	Todas las versiones de parche en 1.29 y versiones anteriores, 1.30.400 y versiones anteriores, y 1.31.0	La configuración del duplicado del registro en los nodos no se actualiza cuando solo se cambia el campo hosts. Cuando actualizas el campo containerRuntime.registryMirrors.hosts para un extremo de duplicación del registro en la especificación del clúster, los cambios no se aplican automáticamente a los nodos del clúster. Este problema se debe a que la lógica de conciliación no detecta los cambios realizados exclusivamente en el campo hosts y, en consecuencia, no se activan los trabajos de actualización de la máquina responsables de actualizar la configuración de containerd en los nodos. Verificación: Para verificar este problema, modifica solo el campo hosts de un duplicado del registro y, luego, inspecciona el archivo de configuración de containerd (la ruta de acceso podría ser /etc/containerd/config.toml o alguna otra, como /etc/containerd/config.d/01-containerd.conf, según la versión y la configuración) en un nodo trabajador. El archivo no muestra la lista actualizada de hosts para el extremo de duplicación. Solución alternativa: Elige una de estas opciones: Actualiza a una versión con la corrección: Actualiza tus clústeres a la versión 1.30.500-gke.126 o posterior, la versión 1.31.100-gke.136 o posterior, o la versión 1.32.0. Activa una actualización a través de un cambio en NodePool: Realiza un cambio trivial en la especificación de NodePool para los nodos afectados. Por ejemplo, agregar una etiqueta o anotación temporal Esto activa el proceso de actualización de la máquina, que detecta los cambios en el duplicado del registro. Luego, puedes quitar el cambio trivial.

¿Qué sigue?

Si necesitas asistencia adicional, comunícate con Atención al cliente de Cloud. También puedes consultar Cómo obtener asistencia para obtener más información sobre los recursos de asistencia, incluidos los siguientes:

• Requisitos para abrir un caso de asistencia
• Herramientas para ayudarte a solucionar problemas, como la configuración de tu entorno, los registros y las métricas
• Componentes compatibles.