Escalar clústeres de Google Distributed Cloud

Al igual que cualquier clúster de Kubernetes, la escalabilidad de los clústeres de Google Distributed Cloud tiene muchas dimensiones interrelacionadas. Este documento tiene como objetivo ayudarte a entender las dimensiones clave que puedes ajustar para ampliar tus clústeres sin interrumpir tus cargas de trabajo.

Información sobre los límites

Google Distributed Cloud es un sistema complejo con una gran superficie de integración. Hay muchos aspectos que afectan a la escalabilidad de los clústeres. Por ejemplo, el número de nodos es solo una de las muchas dimensiones en las que se puede escalar Google Distributed Cloud. Otras dimensiones incluyen el número total de pods y servicios. Muchas de estas dimensiones, como el número de pods por nodo y el número de nodos por clúster, están interrelacionadas. Para obtener más información sobre las dimensiones que afectan a la escalabilidad, consulta los umbrales de escalabilidad de Kubernetes en la sección del grupo de interés especial (SIG) de escalabilidad del repositorio de la comunidad de Kubernetes en GitHub.

Los límites de escalabilidad también dependen del hardware y de la configuración de los nodos en los que se ejecuta el clúster. Los límites descritos en este documento se verifican en un entorno que probablemente sea diferente al tuyo. Por lo tanto, es posible que no obtengas los mismos números cuando el entorno subyacente sea el factor limitante.

Para obtener más información sobre los límites que se aplican a tus clústeres de Google Distributed Cloud, consulta Cuotas y límites.

Preparación para el escalado

Cuando te prepares para escalar tus clústeres de Google Distributed Cloud, ten en cuenta los requisitos y las limitaciones que se describen en las siguientes secciones.

Requisitos de CPU y memoria de los nodos del plano de control

En la siguiente tabla se describe la configuración recomendada de CPU y memoria para los nodos del plano de control de los clústeres que ejecutan cargas de trabajo de producción:

Número de nodos del clúster CPUs recomendadas para el plano de control Memoria recomendada del plano de control
1-50 8 núcleos 32 GiB
51-100 16 núcleos 64 GiB

Número de pods y servicios

El número de pods y servicios que puedes tener en tus clústeres se controla mediante los siguientes ajustes:

CIDR de pods y número máximo de nodos

El número total de direcciones IP reservadas para los pods de tu clúster es uno de los factores que limitan el escalado vertical del clúster. Este ajuste, junto con el ajuste del número máximo de pods por nodo, determina el número máximo de nodos que puedes tener en tu clúster antes de que te quedes sin direcciones IP para tus pods.

Ten en cuenta lo siguiente:

  • El número total de direcciones IP reservadas para los pods de tu clúster se especifica con clusterNetwork.pods.cidrBlocks, que toma un intervalo de direcciones IP especificado en notación CIDR. Por ejemplo, el valor predefinido 192.168.0.0/16 especifica un intervalo de 65.536 direcciones IP,de 192.168.0.0 a 192.168.255.255.

  • El número máximo de pods que se pueden ejecutar en un solo nodo se especifica con nodeConfig.podDensity.maxPodsPerNode.

  • En función del ajuste de número máximo de pods por nodo, Google Distributed Cloud asigna aproximadamente el doble de direcciones IP al nodo. Las direcciones IP adicionales ayudan a evitar que se reutilicen inadvertidamente las IPs de los pods en un breve periodo de tiempo.

  • Si divides el número total de direcciones IP de pods entre el número de direcciones IP de pods aprovisionadas en cada nodo, obtendrás el número total de nodos que puedes tener en tu clúster.

Por ejemplo, si tu CIDR de pods es 192.168.0.0/17, tienes un total de 32.768 direcciones IP (2(32-17) = 215 = 32.768). Si defines el número máximo de pods por nodo en 250, Google Distributed Cloud aprovisiona un intervalo de aproximadamente 500 direcciones IP, lo que equivale aproximadamente a un bloque CIDR /23 (2(32-23) = 29 = 512). Por lo tanto, el número máximo de nodos en este caso es 64 (215 direcciones por clúster dividido entre 29 direcciones por nodo = 2(15-9) nodos por clúster = 26 = 64 nodos por clúster).

Tanto clusterNetwork.pods.cidrBlocks como nodeConfig.podDensity.maxPodsPerNode son inmutables, así que planifica con cuidado el crecimiento futuro de tu clúster para evitar quedarte sin capacidad de nodos. Para ver los máximos recomendados de pods por clúster, pods por nodo y nodos por clúster según las pruebas, consulta Límites.

CIDR de servicio

Puedes actualizar el CIDR de servicio para añadir más servicios a medida que amplías tu clúster. Sin embargo, no puedes reducir el intervalo CIDR del servicio. Para obtener más información, consulta Aumentar la cobertura de la red de servicio.

Recursos reservados para los daemons del sistema

De forma predeterminada, Google Distributed Cloud reserva automáticamente recursos en un nodo para los daemons del sistema, como sshd o udev. Los recursos de CPU y memoria se reservan en un nodo para los daemons del sistema, de forma que estos daemons tengan los recursos que necesitan. Sin esta función, los pods pueden consumir la mayoría de los recursos de un nodo, lo que impide que los daemons del sistema completen sus tareas.

En concreto, Google Distributed Cloud reserva 80 milinúcleos de CPU (80 mCPU) y 280 mebibytes (280 MiB) de memoria en cada nodo para los daemons del sistema. Ten en cuenta que la unidad de CPU mCPU representa una milésima parte de un núcleo, por lo que se reserva el 8 % de un núcleo (80/1000) en cada nodo para los daemons del sistema. La cantidad de recursos reservados es pequeña y no tiene un impacto significativo en el rendimiento del pod. Sin embargo, el kubelet de un nodo puede desalojar pods si su uso de CPU o memoria supera las cantidades que se les han asignado.

Redes con MetalLB

Puede que quieras aumentar el número de altavoces de MetalLB para abordar los siguientes aspectos:

  • Ancho de banda: el ancho de banda de todo el clúster para los servicios de balanceo de carga depende del número de altavoces y del ancho de banda de cada nodo de altavoz. Si aumenta el tráfico de la red, necesitarás más altavoces.

  • Tolerancia a fallos: cuantos más altavoces haya, menor será el impacto general de un fallo en un altavoz.

MetalLB requiere conectividad de capa 2 entre los nodos de balanceo de carga. En este caso, es posible que estés limitado por el número de nodos con conectividad de capa 2 en los que puedes colocar altavoces MetalLB.

Planifica cuidadosamente cuántos altavoces MetalLB quieres tener en tu clúster y determina cuántos nodos de capa 2 necesitas. Para obtener más información, consulta Problemas de escalabilidad de MetalLB.

Por otra parte, cuando se usa el modo de balanceo de carga agrupado, los nodos del plano de control también deben estar en la misma red de capa 2. El balanceo de carga manual no tiene esta restricción. Para obtener más información, consulta Modo de balanceador de carga manual.

Ejecutar muchos nodos, pods y servicios

Añadir nodos, pods y servicios es una forma de ampliar tu clúster. En las siguientes secciones se describen algunos ajustes y configuraciones adicionales que debes tener en cuenta al aumentar el número de nodos, pods y servicios de tu clúster. Para obtener información sobre los límites de estas dimensiones y cómo se relacionan entre sí, consulte Límites.

Crear un clúster sin kube-proxy

Para crear un clúster de alto rendimiento que pueda escalarse para usar un gran número de servicios y endpoints, te recomendamos que crees el clúster sin kube-proxy. Sin kube-proxy, el clúster usa GKE Dataplane V2 en el modo kube-proxy-replacement. De esta forma, se evita el consumo de recursos necesario para mantener un gran conjunto de reglas de iptables.

No puedes inhabilitar el uso de kube-proxy en un clúster que ya tengas. Esta configuración debe definirse cuando se cree el clúster. Para obtener instrucciones y más información, consulta Crear un clúster sin kube-proxy.

Configuración de CoreDNS

En esta sección se describen los aspectos de CoreDNS que afectan a la escalabilidad de los clústeres.

DNS de pods

De forma predeterminada, los clústeres de Google Distributed Cloud insertan pods con un resolv.conf que tiene el siguiente aspecto:

nameserver KUBEDNS_CLUSTER_IP
search <NAMESPACE>.svc.cluster.local svc.cluster.local cluster.local c.PROJECT_ID.internal google.internal
options ndots:5

La opción ndots:5 significa que los nombres de host que tienen menos de 5 puntos no se consideran nombres de dominio completos (FQDN). El servidor DNS añade todos los dominios de búsqueda especificados antes de buscar el nombre de host solicitado originalmente, lo que ordena las búsquedas de la siguiente manera al resolver google.com:

  1. google.com.NAMESPACE.svc.cluster.local
  2. google.com.svc.cluster.local
  3. google.com.cluster.local
  4. google.com.c.PROJECT_ID.internal
  5. google.com.google.internal
  6. google.com

Cada una de las búsquedas se realiza para IPv4 (registro A) e IPv6 (registro AAAA), lo que da como resultado 12 solicitudes de DNS por cada consulta que no sea un nombre de dominio completo, lo que amplifica significativamente el tráfico de DNS. Para mitigar este problema, le recomendamos que declare el nombre de host que se va a buscar como FQDN añadiendo un punto al final (google.com.). Esta declaración debe hacerse a nivel de carga de trabajo de la aplicación. Para obtener más información, consulta la página del manual resolv.conf.

IPv6

Si el clúster no usa IPv6, es posible reducir las solicitudes de DNS a la mitad eliminando la búsqueda de registros AAAA en el servidor DNS upstream. Si necesitas ayuda para inhabilitar las búsquedas de AAAA, ponte en contacto con Cloud Customer Care.

Grupo de nodos dedicado

Debido a la naturaleza crítica de las consultas de DNS en los ciclos de vida de las aplicaciones, le recomendamos que utilice nodos dedicados para la corednsimplementación. Esta implementación se incluye en un dominio de errores diferente al de las aplicaciones normales. Si necesitas ayuda para configurar nodos dedicados para la implementación de coredns, ponte en contacto con el servicio de atención al cliente de Cloud.

Problemas de escalabilidad de MetalLB

MetalLB se ejecuta en modo activo-pasivo, lo que significa que, en cualquier momento, solo hay un altavoz de MetalLB que sirve una VIP LoadBalancer concreta.

Conmutación por error

Antes de la versión 1.28.0 de Google Distributed Cloud, en el caso de las implementaciones a gran escala, la conmutación por error de MetalLB podía tardar mucho tiempo y suponer un riesgo para la fiabilidad del clúster.

Límites de conexiones

Si hay un LoadBalancer VIP concreto, como un servicio de Ingress, que espera cerca de 30.000 conexiones simultáneas o más, es probable que el nodo de altavoz que gestione el VIP agote los puertos disponibles. Debido a una limitación de la arquitectura, MetalLB no puede mitigar este problema. Considera la posibilidad de cambiar al balanceo de carga agrupado con BGP antes de crear el clúster o usa otra clase de entrada. Para obtener más información, consulta la sección Configuración de Ingress.

Altavoces del balanceador de carga

De forma predeterminada, Google Distributed Cloud usa el mismo grupo de nodos de balanceador de carga tanto para el plano de control como para el plano de datos. Si no especificas un grupo de nodos del balanceador de carga (loadBalancer.nodePoolSpec), se usará el grupo de nodos del plano de control (controlPlane.nodePoolSpec).

Para aumentar el número de altavoces cuando usas el grupo de nodos del plano de control para el equilibrio de carga, debes aumentar el número de máquinas del plano de control. Para las implementaciones de producción, te recomendamos que uses tres nodos del plano de control para conseguir una alta disponibilidad. Aumentar el número de nodos del plano de control a más de tres para dar cabida a más altavoces puede no ser una buena forma de usar tus recursos.

Configuración de Ingress

Si esperas que se produzcan cerca de 30.000 conexiones simultáneas en un único VIP de servicio LoadBalancer, es posible que MetalLB no pueda admitirlas.

Puedes exponer la IP virtual a través de otros mecanismos, como F5 BIG-IP. También puedes crear un clúster con el balanceo de carga agrupado con BGP, que no tiene la misma limitación.

Ajustar los componentes de Cloud Logging y Cloud Monitoring

En los clústeres grandes, en función de los perfiles de aplicación y del patrón de tráfico, es posible que las configuraciones de recursos predeterminadas de los componentes de Cloud Logging y Cloud Monitoring no sean suficientes. Para obtener instrucciones sobre cómo ajustar las solicitudes y los límites de recursos de los componentes de observabilidad, consulta el artículo Configurar los recursos de los componentes de Stackdriver.

En concreto, kube-state-metrics en clústeres con un gran número de servicios y endpoints puede provocar un uso excesivo de memoria tanto en el propio kube-state-metrics como en el gke-metrics-agent del mismo nodo. El uso de recursos de metrics-server también se puede escalar en términos de nodos, pods y servicios. Si tienes problemas con los recursos de estos componentes, ponte en contacto con el equipo de Asistencia de Google Cloud.

Usar sysctl para configurar el sistema operativo

Te recomendamos que ajustes la configuración del sistema operativo de tus nodos para que se adapte mejor a tu caso práctico de carga de trabajo. Los parámetros fs.inotify.max_user_watches y fs.inotify.max_user_instances que controlan el número de recursos de inotify a menudo necesitan ajustes. Por ejemplo, si ves mensajes de error como los siguientes, puedes probar a ver si es necesario ajustar estos parámetros:

The configured user limit (128) on the number of inotify instances has been reached

ENOSPC: System limit for number of file watchers reached...

La optimización suele variar según los tipos de cargas de trabajo y la configuración del hardware. Puedes consultar las prácticas recomendadas específicas del SO con tu proveedor.

Prácticas recomendadas

En esta sección se describen las prácticas recomendadas para ampliar un clúster.

Redimensionar una dimensión a la vez

Para minimizar los problemas y facilitar la reversión de los cambios, no modifiques más de una dimensión a la vez. Escalar varias dimensiones simultáneamente puede causar problemas incluso en clústeres más pequeños. Por ejemplo, si intentas aumentar el número de pods programados por nodo a 110 y el número de nodos del clúster a 250, es probable que no lo consigas, ya que el número de pods, el número de pods por nodo y el número de nodos se han ampliado demasiado.

Escalar clústeres por fases

Escalar un clúster puede requerir muchos recursos. Para reducir el riesgo de que fallen las operaciones del clúster o de que se interrumpan las cargas de trabajo del clúster, no recomendamos intentar crear clústeres grandes con muchos nodos en una sola operación.

Crear clústeres híbridos o independientes sin nodos de trabajo

Si vas a crear un clúster híbrido o independiente grande con más de 50 nodos de trabajador, es mejor que crees primero un clúster de alta disponibilidad con nodos de plano de control y, después, que aumentes la escala gradualmente. La operación de creación de clústeres usa un clúster de arranque, que no es de alta disponibilidad y, por lo tanto, es menos fiable. Una vez que se haya creado el clúster híbrido o independiente de alta disponibilidad, podrá usarlo para ampliarlo a más nodos.

Aumentar el número de nodos de trabajador en lotes

Si vas a ampliar un clúster para añadir más nodos de trabajador, es mejor que lo hagas por fases. Te recomendamos que añadas un máximo de 20 nodos a la vez. Esto es especialmente importante en los clústeres que ejecutan cargas de trabajo críticas.

Habilitar las extracciones de imágenes en paralelo

De forma predeterminada, kubelet extrae las imágenes en serie, una tras otra. Si tienes una conexión upstream deficiente con el servidor de tu registro de imágenes, una extracción de imágenes incorrecta puede bloquear toda la cola de un grupo de nodos determinado.

Para mitigar este problema, te recomendamos que definas serializeImagePulls como false en la configuración de kubelet personalizada. Para obtener instrucciones y más información, consulta Configurar los ajustes de extracción de imágenes de kubelet. Si habilitas las extracciones de imágenes paralelas, se pueden producir picos en el consumo de ancho de banda de la red o de E/S de disco.

Ajustar las solicitudes y los límites de recursos de las aplicaciones

En entornos con mucha densidad, las cargas de trabajo de las aplicaciones pueden expulsarse. Kubernetes usa el mecanismo referenciado para clasificar los pods en caso de desalojo.

Una buena práctica para definir los recursos de los contenedores es usar la misma cantidad de memoria para las solicitudes y los límites, y un límite de CPU mayor o ilimitado. Para obtener más información, consulta el artículo Preparar aplicaciones de Kubernetes basadas en la nube del Centro de Arquitectura de Cloud.

Usar un partner de almacenamiento

Te recomendamos que utilices uno de los partners de almacenamiento aptos para GDC para las implementaciones a gran escala. Es importante que confirme la siguiente información con el partner de almacenamiento en cuestión:

  • Las implementaciones de almacenamiento siguen las prácticas recomendadas para los aspectos de almacenamiento, como la alta disponibilidad, la configuración de prioridades, las afinidades de nodos y las solicitudes y los límites de recursos.
  • La versión de almacenamiento se califica con la versión concreta de Google Distributed Cloud.
  • El proveedor de almacenamiento puede admitir la gran escala que quieras implementar.

Configurar clústeres para alta disponibilidad

Es importante auditar tu implementación a gran escala y asegurarte de que los componentes críticos estén configurados para la alta disponibilidad siempre que sea posible. Google Distributed Cloud admite opciones de implementación de alta disponibilidad para todos los tipos de clústeres. Para obtener más información, consulta Elegir un modelo de implementación. Para ver archivos de configuración de clústeres de ejemplo de implementaciones de alta disponibilidad, consulta Ejemplos de configuración de clústeres.

También es importante auditar otros componentes, como los siguientes:

  • Proveedor de almacenamiento
  • Webhooks de clúster

Monitorizar el uso de recursos

En esta sección se ofrecen algunas recomendaciones básicas de monitorización para clústeres a gran escala.

Monitoriza de cerca las métricas de uso

Es fundamental monitorizar la utilización de los nodos y de los componentes del sistema, así como asegurarse de que tengan un margen de seguridad suficiente. Para ver qué funciones de monitorización estándar están disponibles de forma predeterminada, consulta Usar paneles predefinidos.

Monitorizar el consumo de ancho de banda

Monitoriza el consumo de ancho de banda para asegurarte de que la red no esté saturada, lo que provocaría una degradación del rendimiento del clúster.

Mejorar el rendimiento de etcd

La velocidad del disco es fundamental para el rendimiento y la estabilidad de etcd. Un disco lento aumenta la latencia de las solicitudes de etcd, lo que puede provocar problemas de estabilidad en el clúster. Para mejorar el rendimiento del clúster, Google Distributed Cloud almacena los objetos Event en una instancia de etcd independiente y específica. La instancia estándar de etcd usa /var/lib/etcd como directorio de datos y el puerto 2379 para las solicitudes de los clientes. La instancia de etcd-events usa /var/lib/etcd-events como directorio de datos y el puerto 2382 para las solicitudes de clientes.

Te recomendamos que uses un disco de estado sólido (SSD) para tus almacenes etcd. Para obtener un rendimiento óptimo, monta discos independientes en /var/lib/etcd y /var/lib/etcd-events. Si usas discos dedicados, te aseguras de que las dos instancias de etcd no compartan E/S de disco.

datos complementarios que se proporcionan de la mejor forma posible.

En la documentación de etcd se ofrecen recomendaciones de hardware adicionales para asegurar el mejor rendimiento de etcd al ejecutar los clústeres en producción.

Para comprobar el rendimiento de etcd y del disco, usa las siguientes métricas de latencia de E/S de etcd en el explorador de métricas:

  • etcd_disk_backend_commit_duration_seconds: la duración debe ser inferior a 25 milisegundos en el percentil 99 (p99).
  • etcd_disk_wal_fsync_duration_seconds: la duración debe ser inferior a 10 milisegundos en el percentil 99 (p99).

Para obtener más información sobre el rendimiento de etcd, consulta ¿Qué significa la advertencia de etcd "apply entries took too long"? y ¿Qué significa la advertencia de etcd "failed to send out heartbeat on time"?.

Si necesitas más ayuda, ponte en contacto con el servicio de atención al cliente de Cloud. También puedes consultar la sección 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 admitidos.

Siguientes pasos