Escala verticalmente los 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. El objetivo de este documento es ayudarte a comprender las dimensiones clave que puedes ajustar para escalar 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 muchas dimensiones que afectan la escalabilidad del clúster. Por ejemplo, la cantidad de nodos es solo una de las muchas dimensiones en las que se puede escalar Google Distributed Cloud. Otras dimensiones incluyen la cantidad total de Pods y Services. Muchas de estas dimensiones, como la cantidad de Pods por nodo y la cantidad de nodos por clúster, están interrelacionadas. Para obtener más información sobre las dimensiones que afectan la escalabilidad, consulta 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 son sensibles a la configuración del hardware y los nodos en los que se ejecuta tu clúster. Los límites que se describen en este documento se verifican en un entorno que es muy diferente al tuyo. Por lo tanto, es posible que no reproduzcas las mismas cifras 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.

Prepárate para escalar

Mientras te preparas 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 del nodo 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:

Cantidad de nodos del clúster CPUs recomendadas del plano de control Memoria recomendada del plano de control
1-50 8 núcleos 32 GiB
Entre 51 y 100 16 núcleos 64 GiB

Cantidad de Pods y Services

La cantidad de Pods y Services que puedes tener en tus clústeres se controla mediante la siguiente configuración:

CIDR del Pod y cantidad máxima de nodos

La cantidad total de direcciones IP reservadas para Pods en tu clúster es uno de los factores limitantes para aumentar la escala de tu clúster. Este parámetro de configuración, junto con el parámetro de configuración para la cantidad máxima de Pods por nodo, determina la cantidad máxima de nodos que puedes tener en tu clúster antes de correr el riesgo de agotar las direcciones IP para tus Pods.

Ten en cuenta lo siguiente:

  • La cantidad total de direcciones IP reservadas para Pods en tu clúster se especifica con clusterNetwork.pods.cidrBlocks, que toma un rango de direcciones IP especificadas en notación CIDR. Por ejemplo, el valor completado previamente 192.168.0.0/16 especifica un rango de 65,536 direcciones IP de 192.168.0.0 a 192.168.255.255.

  • La cantidad máxima de Pods que pueden ejecutarse en un solo nodo se especifica con nodeConfig.podDensity.maxPodsPerNode.

  • Según el parámetro de configuración de la cantidad máxima de Pods por nodo, Google Distributed Cloud aprovisiona aproximadamente el doble de direcciones IP para el nodo. Las direcciones IP adicionales ayudan a evitar la reutilización inadvertida de las IPs de Pod en un corto período.

  • Si divides la cantidad total de direcciones IP de Pods por la cantidad de direcciones IP de Pods aprovisionadas en cada nodo, obtendrás la cantidad total de nodos que puedes tener en tu clúster.

Por ejemplo, si tu CIDR de Pod es 192.168.0.0/17, tienes un total de 32,768 direcciones IP (2(32-17) = 215 = 32,768). Si configuras la cantidad máxima de Pods por nodo en 250, Google Distributed Cloud aprovisiona un rango de aproximadamente 500 direcciones IP, que es aproximadamente equivalente a un /23 bloque CIDR (2(32-23) = 2 9 = 512). Por lo tanto, la cantidad máxima de nodos en este caso es 64 (215 direcciones/clúster dividido por 29 direcciones/nodo = 2(15-9)nodes/cluster = 26 = 64 nodos/clúster).

Tanto clusterNetwork.pods.cidrBlocks como nodeConfig.podDensity.maxPodsPerNode son inmutables, por lo que debes planificar cuidadosamente el crecimiento futuro de tu clúster para evitar quedarte sin capacidad de nodos. Para conocer 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

Tu CIDR de servicio se puede actualizar para agregar más servicios a medida que escalas tu clúster. Sin embargo, no puedes reducir el rango de CIDR del servicio. Para obtener más información, consulta Cómo aumentar el rango de la red de servicios.

Recursos reservados para 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 daemons del sistema para que estos daemons tengan los recursos que necesitan. Sin esta función, los Pods podrían consumir la mayoría de los recursos de un nodo, lo que imposibilitaría que los daemons del sistema completen sus tareas.

Específicamente, Google Distributed Cloud reserva 80 mCPU y 280 MiB de memoria en cada nodo para los daemons del sistema. Ten en cuenta que la unidad de CPU mCPU significa milésima de un núcleo, por lo que se reserva el 80/1000 o el 8% de un núcleo 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 en un nodo puede desalojar Pods si su uso de CPU o memoria supera las cantidades que se les asignaron.

Redes con MetalLB

Es posible que desees aumentar la cantidad de bocinas 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 cargas depende de la cantidad de bocinas y del ancho de banda de cada nodo de bocina. El aumento del tráfico de red requiere más bocinas.

  • Tolerancia a errores: Cuantos más altavoces haya, menor será el impacto general de un solo error en un altavoz.

MetalLB requiere conectividad de capa 2 entre los nodos de balanceo de cargas. En este caso, es posible que estés limitado por la cantidad de nodos con conectividad de capa 2 en los que puedes colocar los dispositivos de MetalLB.

Planifica cuidadosamente cuántos dispositivos de MetalLB deseas 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 otro lado, cuando se usa el modo de balanceo de cargas agrupado, los nodos del plano de control también deben estar en la misma red de capa 2. El balanceo de cargas manual no tiene esta restricción. Para obtener más información, consulta Modo de balanceador de cargas manual.

Ejecuta muchos nodos, Pods y Services

Agregar nodos, Pods y Services es una forma de escalar verticalmente tu clúster. En las siguientes secciones, se abordan algunos parámetros de configuración adicionales que debes tener en cuenta cuando aumentas la cantidad de nodos, Pods y Services en tu clúster. Para obtener información sobre los límites de estas dimensiones y cómo se relacionan entre sí, consulta Límites.

Crea un clúster sin kube-proxy

Para crear un clúster de alto rendimiento que pueda escalar verticalmente para usar una gran cantidad de Services y extremos, te recomendamos que crees el clúster sin kube-proxy. Sin kube-proxy, el clúster usa GKE Dataplane V2 en el modo de reemplazo de kube-proxy. Este modo evita el consumo de recursos necesario para mantener un gran conjunto de reglas de iptables.

No puedes inhabilitar el uso de kube-proxy para un clúster existente. Esta configuración se debe establecer cuando se crea el clúster. Para obtener instrucciones y más información, consulta Crea un clúster sin kube-proxy.

Configuración de CoreDNS

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

DNS del Pod

De forma predeterminada, los clústeres de Google Distributed Cloud insertan Pods con un resolv.conf que se ve de la siguiente manera:

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 completamente calificados (FQDN). El servidor DNS agrega 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 cuando se resuelve 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) y IPv6 (registro AAAA), lo que genera 12 solicitudes de DNS para cada consulta que no es FQDN, lo que amplifica significativamente el tráfico de DNS. Para mitigar este problema, te recomendamos que declares el nombre de host que se buscará como un FQDN mediante la adición de un punto final (google.com.). Esta declaración debe realizarse a nivel de la carga de trabajo de la aplicación. Para obtener más información, consulta la página del manual de resolv.conf.

IPv6

Si el clúster no usa IPv6, es posible reducir las solicitudes de DNS a la mitad si se elimina la búsqueda de registros AAAA en el servidor DNS upstream. Si necesitas ayuda para inhabilitar las búsquedas de AAAA, comunícate con Atención al cliente de Cloud.

Grupo de nodos dedicado

Debido a la naturaleza crítica de las consultas de DNS en los ciclos de vida de las aplicaciones, te recomendamos que uses nodos dedicados para la Deployment de coredns. Este Deployment se encuentra en un dominio de fallas diferente al de las aplicaciones normales. Si necesitas ayuda para configurar nodos dedicados para la Deployment coredns, comunícate con 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 una bocina de MetalLB que entrega una VIP de LoadBalancer en particular.

Conmutación por error

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

Límites de conexión

Si hay una VIP LoadBalancer particular, como un Service de entrada, que espera cerca de 30,000 conexiones simultáneas o más, es probable que el nodo de interlocutor que maneja la VIP puedeagote los puertos disponibles. Debido a una limitación de la arquitectura, MetalLB no puede mitigar este problema. Considera cambiar al balanceo de cargas en paquetes con BGP antes de crear el clúster o usa una clase de Ingress diferente. Para obtener más información, consulta Configuración de Ingress.

Parlantes del balanceador de cargas

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

Para aumentar la cantidad de interlocutores cuando usas el grupo de nodos del plano de control para el balanceo de cargas, debes aumentar la cantidad de máquinas del plano de control. Para las implementaciones de producción, te recomendamos que uses tres nodos del plano de control para lograr una alta disponibilidad. Aumentar la cantidad de nodos del plano de control a más de tres para admitir interlocutores adicionales podría no ser un buen uso de tus recursos.

Configuración de Ingress

Si esperas cerca de 30,000 conexiones simultáneas que ingresen a una sola VIP de Service LoadBalancer, es posible que MetalLB no pueda admitirlas.

Puedes considerar exponer la VIP a través de otros mecanismos, como F5 BIG-IP. Como alternativa, puedes crear un clúster nuevo con el balanceo de cargas en paquetes con BGP, que no tiene la misma limitación.

Ajusta los componentes de Cloud Logging y Cloud Monitoring

En clústeres grandes, según los perfiles de aplicación y el patrón de tráfico, es posible que las configuraciones de recursos predeterminadas para los componentes de Cloud Logging y Cloud Monitoring no sean suficientes. Para obtener instrucciones para ajustar las solicitudes y los límites de recursos de los componentes de observabilidad, consulta Configura los recursos del componente de Stackdriver.

En particular, kube-state-metrics en clústeres con una gran cantidad de servicios y extremos puede causar un uso excesivo de la memoria tanto en el propio kube-state-metrics como en el gke-metrics-agent en el mismo nodo. El uso de recursos de metrics-server también puede escalar en términos de nodos, Pods y servicios. Si tienes problemas de recursos en estos componentes, comunícate con Atención al cliente de Cloud.

Usa sysctl para configurar tu sistema operativo

Te recomendamos que ajustes la configuración del sistema operativo de tus nodos para que se adapte mejor a tu caso de uso de carga de trabajo. Los parámetros fs.inotify.max_user_watches y fs.inotify.max_user_instances que controlan la cantidad de recursos de inotify a menudo necesitan ajustes. Por ejemplo, si ves mensajes de error como los siguientes, es posible que desees intentar ver si estos parámetros deben ajustarse:

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

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

Por lo general, el ajuste varía según los tipos de cargas de trabajo y la configuración de hardware. Puedes consultar las prácticas recomendadas específicas del SO con el proveedor del SO.

Prácticas recomendadas

En esta sección, se describen las prácticas recomendadas para aumentar la escala de tu clúster.

Escala una dimensión a la vez

Para minimizar los problemas y facilitar la reversión de los cambios, no ajustes más de una dimensión a la vez. Escalar verticalmente varias dimensiones de forma simultánea puede causar problemas, incluso en clústeres más pequeños. Por ejemplo, es probable que el intento de aumentar la cantidad de Pods programados por nodo a 110 y, al mismo tiempo, aumentar la cantidad de nodos en el clúster a 250 no tenga éxito, ya que la cantidad de Pods, la cantidad de Pods por nodo y la cantidad de nodos se extenderían demasiado.

Escala clústeres por etapas

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

Crea clústeres híbridos o independientes sin nodos trabajadores

Si creas un clúster híbrido o independiente grande con más de 50 nodos de trabajador, es mejor crear primero un clúster de alta disponibilidad (HA) con nodos de plano de control y, luego, aumentar la escala de forma gradual. La operación de creación del clúster usa un clúster de arranque, que no es de alta disponibilidad y, por lo tanto, es menos confiable. Una vez que se haya creado el clúster híbrido o independiente con alta disponibilidad, puedes usarlo para aumentar la cantidad de nodos.

Aumenta la cantidad de nodos trabajadores en lotes

Si vas a expandir un clúster para incluir más nodos trabajadores, es mejor hacerlo por etapas. Te recomendamos que agregues no más de 20 nodos a la vez. Esto es especialmente cierto para los clústeres que ejecutan cargas de trabajo críticas.

Habilita las extracciones de imágenes paralelas

De forma predeterminada, kubelet extrae imágenes de forma serial, una tras otra. Si tienes una mala conexión upstream con el servidor de registro de imágenes, una mala extracción de imágenes puede detener toda la cola de un grupo de nodos determinado.

Para mitigar este problema, te recomendamos que configures serializeImagePulls como false en la configuración personalizada de kubelet. Para obtener instrucciones y más información, consulta Cómo configurar los parámetros de extracción de imágenes de kubelet. Habilitar las extracciones de imágenes paralelas puede generar picos en el consumo de ancho de banda de la red o en la E/S del disco.

Ajusta las solicitudes y los límites de recursos de la aplicación

En entornos con una gran cantidad de elementos, es posible que se desalojen las cargas de trabajo de las aplicaciones. Kubernetes usa el mecanismo al que se hace referencia para clasificar los Pods en caso de desalojo.

Una práctica recomendada a fin de configurar tus recursos de contenedor es usar la misma cantidad de memoria para las solicitudes y los límites, y un límite de CPU mayor o no delimitado. Para obtener más información, consulta Prepara aplicaciones de Kubernetes basadas en la nube en el Cloud Architecture Center.

Usa un socio de almacenamiento

Te recomendamos que uses uno de los socios de almacenamiento de GDC Ready para implementaciones a gran escala. Es importante confirmar la siguiente información con el socio de almacenamiento en particular:

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

Configura 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 Cómo elegir un modelo de implementación. Para ver ejemplos de archivos de configuración de clústeres de implementaciones de HA, consulta Muestras de configuración de clústeres.

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

  • Proveedor de almacenamiento
  • Webhooks de clúster

Supervisa el uso de recursos

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

Supervisa de cerca las métricas de utilización

Es fundamental supervisar la utilización de los nodos y los componentes individuales del sistema, y asegurarse de que tengan un margen seguro y cómodo. Para ver qué capacidades de supervisión estándar están disponibles de forma predeterminada, consulta Usa paneles predefinidos.

Supervisa el consumo de ancho de banda

Supervisa de cerca el consumo de ancho de banda para asegurarte de que la red no se sature, lo que provocaría una degradación del rendimiento de tu clúster.

Mejora el rendimiento de etcd

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

Te recomendamos que uses un disco de estado sólido (SSD) para tus almacenes de etcd. Para obtener un rendimiento óptimo, activa discos separados en /var/lib/etcd y /var/lib/etcd-events. El uso de discos dedicados garantiza que las dos instancias de etcd no compartan la E/S de disco.

En la documentación de etcd, se proporcionan recomendaciones de hardware adicionales para garantizar el mejor rendimiento de etcd cuando ejecutas tus clústeres en producción.

Para verificar el rendimiento del 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 para el percentil 99 (p99).
  • etcd_disk_wal_fsync_duration_seconds: la duración debe ser inferior a 10 milisegundos para el percentil 99 (p99).

Para obtener más información sobre el rendimiento de etcd, consulta ¿Qué significa la advertencia de etcd que indica que “las entradas se aplicaron demasiado tiempo”? y ¿Qué significa la advertencia de etcd "error al enviar señales de monitoreo de funcionamiento a tiempo"?.

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

Próximos pasos