Problemas conocidos de clústeres de Anthos en equipos físicos

Selecciona tus clústeres de Anthos en versión Bare Metal:

  • 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
  • Herramientas de redes
  • Seguridad
  • Restablecimiento/eliminación
  • Entorno de ejecución de VM de Anthos

O bien, busca tu problema:

Categoría Versiones identificadas Problema y solución alternativa
Operación 1.14

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

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

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

error="required IPv4 PodCIDR not available"

Solución alternativa

Sigue estos pasos para solucionar el problema:

  1. Actualiza a la versión 1.14.1 o posterior.
  2. Quita los nodos trabajadores y vuelve a agregarlos.
  3. Quita los nodos del plano de control y vuelve a agregarlos, preferentemente, uno por uno para evitar el tiempo de inactividad del clúster.
Operación, entorno de ejecución de VM de Anthos 1.10, 1.11, 1.12, 1.13, 1.14

Anthos VM Runtime: Cuando reinicias un pod, las VM del pod cambian las direcciones IP o pierden sus direcciones IP por completo.

Si la dirección IP de una VM cambia, esto no afecta la accesibilidad de las aplicaciones de VM expuestas como un servicio de Kubernetes.


Solución alternativa

Si se pierde la dirección IP, debes ejecutar dhclient desde la VM a fin de adquirir una dirección IP para la VM.
Revisiones y actualizaciones 1.10, 1.11, 1.12, 1.13, 1.14

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

Para obtener más información, incluidas las instrucciones para quitar nodos del modo de mantenimiento, consulta Cómo poner nodos en modo de mantenimiento.
Operación 1.10, 1.11, 1.12, 1.13, 1.14

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 de acceso del usuario. De lo contrario, fallará con un error crictl: command not found.

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


Solución alternativa

Actualiza secure_path en /etc/sudoers para incluir /usr/local/bin. Como alternativa, crea un vínculo simbólico para crictl en otro directorio /bin.
Instalación 1.10, 1.11, 1.12, 1.13, 1.14

Credenciales predeterminadas de la aplicación y bmctl

bmctl usa credenciales predeterminadas de la aplicación (ADC) para validar el valor de ubicación de la operación del clúster en cluster spec cuando no se establece en global.


Solución alternativa

Para que ADC funcione, debes apuntar la variable de entorno GOOGLE_APPLICATION_CREDENTIALS a un archivo de credenciales de la cuenta de servicio o ejecutar gcloud auth application-default login.
Registro y supervisión 1.10, 1.11, 1.12, 1.13, 1.14

Datos de métricas desconocidos en Cloud Monitoring

Los datos en los clústeres de la versión 1.10.x de Cloud Monitoring pueden contener entradas de métricas de resumen irrelevantes, como las siguientes:

Unknown metric: kubernetes.io/anthos/go_gc_duration_seconds_summary_percentile

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

  • apiserver_admission_step_admission_duration_seconds_summary
  • go_gc_duration_seconds
  • scheduler_scheduling_duration_seconds
  • gkeconnect_http_request_duration_seconds_summary
  • alertmanager_nflog_snapshot_duration_seconds_summary

Si bien estas métricas de tipo de resumen están en la lista de métricas, gke-metrics-agent no las admite en este momento.
Herramientas de redes 1.10, 1.11, 1.12, 1.13, 1.14

Direcciones egressSourceIP duplicadas

Cuando se usa la vista previa de la función de puerta de enlace NAT de salida, se pueden configurar reglas de selección de tráfico que especifiquen una dirección egressSourceIP que ya esté en uso para otro objeto EgressNATPolicy. Esto puede causar conflictos en el enrutamiento del tráfico de salida.


Solución alternativa

Coordina con tu equipo de desarrollo para determinar qué direcciones IP flotantes están disponibles antes de especificar la dirección egressSourceIP en tu recurso personalizado EgressNATPolicy.
Seguridad 1.10, 1.11, 1.12, 1.13, 1.14

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

Si usas containerd como entorno de ejecución del contenedor y tu sistema operativo tiene SELinux habilitado, es posible que 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 este problema te afecta, verás un error denied como el siguiente:

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

Solución alternativa

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

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

El vaciado de nodos no puede iniciarse cuando el nodo está fuera del alcance

El proceso de desvío de los nodos no comenzará si el nodo está fuera del alcance de los clústeres de Anthos en un equipo físico. Por ejemplo, si un nodo se desconecta durante un proceso de actualización del clúster, es posible que la actualización deje de responder. Esto es poco frecuente.


Solución alternativa

Para minimizar la probabilidad de encontrar este problema, asegúrate de que tus nodos funcionen correctamente antes de iniciar una actualización.
Revisiones y actualizaciones 1.14.0, 1.14.1

Error de reversión de la actualización del clúster

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

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

Solución alternativa:

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

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

    Reemplaza lo siguiente:

    • CLUSTER_NAMESPACE: El espacio de nombres del clúster.
    • ADMIN_KUBECONFIG: Es la ruta de acceso al archivo kubeconfig del clúster de administrador.
  2. Borra todos los recursos healthchecks.baremetal.cluster.gke.io que se muestran 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 la verificación de estado.
  3. Vuelve a ejecutar el comando bmctl restore cluster.
Seguridad 1.10, 1.11, 1.12, 1.13, 1.14

Errores de SELinux durante la creación de Pods

A veces, la creación del Pod falla cuando SELinux evita que el entorno de ejecución del contenedor configure etiquetas en las activaciones tmpfs. Esta falla es poco común, pero puede ocurrir cuando SELinux está en modo Enforcing y en algunos kernels.

Para verificar que SELinux sea la causa de las fallas en la creación del pod, usa el siguiente comando a fin de detectar errores en los registros kubelet:

journalctl -u kubelet

Si SELinux hace que la creación del pod falle, la respuesta del comando contiene un error similar al siguiente:

error setting label on mount source '/var/lib/kubelet/pods/6d9466f7-d818-4658-b27c-3474bfd48c79/volumes/kubernetes.io~secret/localpv-token-bpw5x': failed to set file label on /var/lib/kubelet/pods/6d9466f7-d818-4658-b27c-3474bfd48c79/volumes/kubernetes.io~secret/localpv-token-bpw5x: permission denied

Para verificar que este problema esté relacionado con la aplicación de SELinux, ejecuta el siguiente comando:

ausearch -m avc

Este comando busca errores de permiso de la caché de vectores de acceso (AVC) en los registros de auditoría. El avc: denied en la siguiente respuesta de muestra confirma que las fallas de creación del pod están relacionadas con la aplicación de SELinux.

type=AVC msg=audit(1627410995.808:9534): avc:  denied { associate } for pid=20660 comm="dockerd" name="/" dev="tmpfs" ino=186492 scontext=system_u:object_r: container_file_t:s0:c61,c201 tcontext=system_u: object_r:locale_t:s0 tclass=filesystem permissive=0

La causa raíz de este problema de creación de pods con SELinux es un error de kernel que se encuentra en las siguientes imágenes de Linux:

  • Versiones de Red Hat Enterprise Linux (RHEL) anteriores a 8.3
  • Versiones de CentOS anteriores a la 8.3

Solución alternativa

Reiniciar la máquina ayuda a solucionar el problema.

Para evitar que se produzcan errores de creación de Pods, usa RHEL 8.3 o una versión posterior, o CentOS 8.3 o una versión posterior, ya que esas versiones corrigieron el error de kernel.
Registro y supervisión 1.10, 1.11, 1.12, 1.13, 1.14

Facturación inesperada de Monitoring

Para los clústeres de Anthos en las versiones 1.10 de Bare Metal a la versión más reciente, algunos clientes notaron una facturación inesperadamente alta para Metrics volume en la página Facturación. Este problema solo afecta a las siguientes circunstancias:

  • Se habilitó la supervisión de la aplicación (enableStackdriverForApplications=true)
  • Servicio administrado para Prometheus no está habilitado (enableGMPForApplications)
  • Los pods de la aplicación tienen la anotación prometheus.io/scrap=true.

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


Solución alternativa

Si te afecta este problema, te recomendamos que actualices tus clústeres a la versión 1.12 y cambies a la nueva solución de supervisión de aplicaciones managed-service-for-prometheus que abordan 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
  • Paquete de Google Cloud Managed Service para Prometheus

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

    1. Encuentra los servicios y los pods de origen que tienen la facturación no deseada 
      kubectl --kubeconfig KUBECONFIG \
  get pods -A -o yaml | grep 'prometheus.io/scrape: "true"'
kubectl --kubeconfig KUBECONFIG get \
  services -A -o yaml | grep 'prometheus.io/scrape: "true"'
    2. Quita la anotación prometheus.io/scrap=true del Pod o del Service.
    Herramientas de redes 1.11, 1.12, 1.13, 1.14

    Falla de NAT con demasiadas conexiones paralelas

    Para un nodo determinado en tu clúster, la dirección IP del nodo proporciona traducción de direcciones de red (NAT) para los paquetes enrutados a una dirección fuera del clúster. Del mismo modo, cuando los paquetes entrantes ingresan a un nodo de balanceo de cargas configurado para usar el balanceo de cargas en paquetes (spec.loadBalancer.mode: bundled), la traducción de direcciones de red de origen (SNAT) enruta los paquetes a la dirección IP del nodo antes de que se reenvíen a un pod de backend.

    El rango de puertos para NAT que usan los clústeres de Anthos en Bare Metal es de 32768 a 65535. Este rango limita la cantidad de conexiones paralelas a 32,767 por protocolo en ese nodo. Cada conexión necesita una entrada en la tabla de conntrack. Si tienes demasiadas conexiones de corta duración, la tabla de conntrack se queda sin puertos para NAT. Un recolector de elementos no utilizados limpia las entradas inactivas, pero la limpieza no es inmediata.

    Cuando la cantidad de conexiones en tu nodo se acerque a 32,767, comenzarás a ver disminuciones de paquetes para conexiones que necesitan NAT.

    Para identificar este problema, ejecuta el siguiente comando en el pod anetd en el nodo problemático: 

    kubectl -n kube-system anetd-XXX -- hubble observe \
    --from-ip $IP --to-ip $IP -f

    Deberías ver los siguientes errores:

    No mapping for NAT masquerade DROPPED

    Solución alternativa

    Redistribuye tu tráfico a otros nodos.
    Herramientas de redes 1.10, 1.11, 1.12, 1.13, 1.14

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

    Los clústeres de Anthos en Bare Metal configuran el filtrado de rutas de acceso inverso en los nodos para inhabilitar la validación de la fuente (net.ipv4.conf.all.rp_filter=0). Si la configuración rp_filter se cambia a 1 o 2, los Pods fallarán debido a los tiempos de espera de comunicación fuera del nodo.

    El filtrado de ruta de acceso inverso se establece con archivos rp_filter en la carpeta de configuración de IPv4 (net/ipv4/conf/all). Este valor también puede ser anulado por sysctl, que almacena la configuración de filtro de 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, vuelve a establecer net.ipv4.conf.all.rp_filter en 0 de forma manual 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 a fin de 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.
    Herramientas de redes 1.10, 1.11, 1.12, 1.13, 1.14

    IP de origen del cliente con balanceo de cargas de capa 2

    Si estableces la política de tráfico externo en Local, se pueden generar errores de enrutamiento, como No route to host, para el balanceo de cargas de la capa 2. La política de tráfico externo se establece en Cluster (externalTrafficPolicy: Cluster) de forma predeterminada. Con esta configuración, Kubernetes controla el tráfico en todo el clúster. Los servicios de tipo LoadBalancer o NodePort pueden usar externalTrafficPolicy: Local para conservar la dirección IP de origen del cliente. Sin embargo, con esta configuración, Kubernetes solo maneja el tráfico local del nodo.


    Solución alternativa

    Si deseas conservar la dirección IP de origen del cliente, es posible que se requiera una configuración adicional para garantizar que las IP de servicio sean accesibles. Para obtener más información sobre la configuración, consulta la sección sobre la preservación de la dirección IP de origen del cliente en la configuración del balanceo de cargas en paquetes.
    Operación, entorno de ejecución de VM de Anthos 1.11, 1.12, 1.13 y 1.14

    La creación de una 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 VM de Linux y Windows. El error se parece al siguiente ejemplo: 

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

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

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

    Solución alternativa

    Vuelve a ejecutar el comando kubectl virt create vm para crear tu VM.
    Sistema operativo 1.10, 1.11, 1.12, 1.13, 1.14

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

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


    Solución alternativa

    Como solución alternativa, ejecuta los siguientes comandos para que CentOS use un feed de archivo:

      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.
    Revisiones y actualizaciones 1.13.0, 1.14

    Las actualizaciones in situ de 1.13.0 a 1.14.x nunca finalizan

    Cuando intentas realizar una actualización in situ de 1.13.0 a 1.14.x mediante 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:

    Actualiza a la versión 1.13.1 antes de actualizar a la versión 1.14.x. Una actualización in situ debería funcionar de 1.13.0 a 1.13.1. También puedes actualizar de 1.13.0 a 1.14.x sin la marca --use-bootstrap=false.
    Herramientas de redes 1.10, 1.11, 1.12, 1.13, 1.14

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

    192.168.122.0/24 y 10.96.0.0/27 son los Pods de servicio y Pod predeterminados que usa el clúster de arranque (similares). Las comprobaciones previas 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 a fin de especificar valores diferentes.
    Sistema operativo 1.10, 1.11, 1.12, 1.13, 1.14

    Limitaciones del extremo del sistema operativo

    En RHEL y CentOS, hay una limitación a nivel de clúster de 100,000 extremos. Servicio de Kubernetes Si 2 servicios hacen referencia al mismo conjunto de pods, se cuenta como 2 conjuntos separados de extremos. La implementación subyacente de nftable en RHEL y CentOS provoca esta limitación; no es una limitación intrínseca de los clústeres de Anthos en equipos físicos.
    Actualizaciones y actualizaciones, Seguridad 1.13 y 1.14

    Los clústeres actualizados a la versión 1.14.0 pierden taints principales

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

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

    Este problema no causa fallas de actualización, pero los pods que no deben ejecutarse en los nodos del plano de control pueden comenzar a hacerlo. Estos pods de carga de trabajo pueden abrumar los nodos del plano de control y generar inestabilidad del clúster.

    Cómo determinar si se ve afectado

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

      Si no aparece ninguno de los taints requeridos, entonces se ve afectado.

    Solución alternativa

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

    1. Aplica el taint faltante:
      2. kubectl taint nodes NODE_NAME \
    node-role.kubernetes.io/master:NoSchedule \
    -–kubeconfig KUBECONFIG_PATH
    2. 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
    3. Borra los pods que no tengan la tolerancia node-role.kubernetes.io/master:NoSchedule: 
      kubectl delete pod POD_NAME –-kubeconfig KUBECONFIG_PATH
    Registro y supervisión 1.11, 1.12, 1.13, 1.14

    No se mantienen las modificaciones en metrics-server-config

    En casos extremos, la alta densidad de pods puede generar 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 de 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 se pueden revertir al valor predeterminado durante una operación de actualización o actualización del clúster. El servidor de métricas no se ve afectado de inmediato, pero la próxima vez que se reinicia, recoge el ConfigMap revertido y es vulnerable a una sobrecarga excesiva.


    Solución alternativa

    Para la versión 1.11.x, puedes crear una secuencia de comandos del cambio de ConfigMap y realizarlo junto con las actualizaciones o las actualizaciones del clúster. Si tu versión es de 1.12 en adelante, comunícate con el equipo de asistencia.
    Instalación 1.10, 1.11, 1.12, 1.13, 1.14

    Realiza la instalación en vSphere

    Cuando instalas clústeres de Anthos en equipos físicos en las VM 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 por hardware realizada por el controlador de vSphere VMXNET3 y no funcionan con el túnel GENEVE de los clústeres de Anthos en Bare Metal.


    Solución alternativa

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

    ethtool -k NET_INTFC |grep segm
...
tx-udp_tnl-segmentation: on
tx-udp_tnl-csum-segmentation: on
...
     Reemplaza NET_INTFC por la interfaz de red asociada con la dirección IP del nodo. A veces, en RHEL 8.4, ethtool muestra que estas marcas están desactivadas cuando no lo están. Para desactivar estas marcas de forma 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 configurar de manera explícita estas marcas cuando se inicia el sistema.
    Restablecimiento/eliminación 1.10, 1.11, 1.12, 1.13, 1.14

    servicio de containerd

    El comando bmctl reset no borra los archivos de configuración ni los objetos binarios de containerd. El servicio containerd systemd queda en funcionamiento. El comando borra los contenedores que ejecutan pods programados en el nodo.
    Instalación 1.10, 1.11, 1.12, 1.13, 1.14

    Servicio de Docker

    En las máquinas de nodo del clúster, si el ejecutable de Docker está presente en la variable de entorno PATH, pero el servicio de Docker no está activo, la verificación previa fallará y se informará que Docker service is not active.


    Solución alternativa

    Quita Docker o habilita el servicio Docker.
    Herramientas de redes 1.10, 1.11, 1.12, 1.13, 1.14

    Si se modifica firewalld, se borrarán las cadenas de política de iptable de Cilium

    Cuando ejecutas clústeres de Anthos en equipos físicos con firewalld habilitado en CentOS o Red Had Enterprise Linux (RHEL), los cambios en firewalld pueden quitar las cadenas iptables de Cilium en la red host. El Pod anetd agrega las cadenas iptables cuando se inicia. La pérdida de las cadenas iptables de Cilium provoca que el pod en el nodo pierda la conectividad de red fuera del nodo.

    Los cambios en firewalld que quitarán las cadenas iptables incluyen, entre otros:

    • Reinicio de firewalld con systemctl
    • Vuelve a cargar firewalld con el cliente de línea de comandos (firewall-cmd --reload)

    Solución alternativa

    Reinicia anetd en el nodo. Ubica y borra el pod anetd con los siguientes comandos para reiniciar anetd:

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

    Reemplaza ANETD_XYZ por el nombre del Pod anetd.
    Instalación 1.10, 1.11, 1.12, 1.13, 1.14

    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 que no se crearon con bmctl, como clústeres de usuario), la verificación previa no verifica las credenciales de la cuenta de servicio de Google Cloud ni sus permisos asociados.
    Si necesitas asistencia adicional, comunícate con la Asistencia de Google.