Como cualquier clúster de Kubernetes, la escalabilidad de 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 verticalmente 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 plataforma 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 tienen un efecto en la escalabilidad, consulta Umbrales de escalabilidad de Kubernetes en la sección 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 al hardware y a la configuración de nodos en los que se ejecuta tu 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 reproduzcas 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.
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 | CPU del plano de control recomendadas | 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 con la siguiente configuración:
clusterNetwork.pods.cidrBlocksespecifica la cantidad de Pods permitidos en tu clúster.nodeConfig.podDensity.maxPodsPerNodeespecifica la cantidad máxima de Pods que pueden ejecutarse en un solo nodo.clusterNetwork.services.cidrBlocksespecifica la cantidad de Services permitidos en tu clúster.
CIDR del Pod y cantidad máxima de nodos
La cantidad total de direcciones IP reservadas para los Pods en tu clúster es uno de los factores limitantes a la hora de escalar verticalmente tu clúster. Esta configuración, junto con la de 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 de tus Pods.
Ten en cuenta lo siguiente:
La cantidad total de direcciones IP reservadas para los Pods en el clúster se especifica con
clusterNetwork.pods.cidrBlocks, que toma un rango de direcciones IP especificadas en la notación CIDR. Por ejemplo, el valor192.168.0.0/16prepropagado especifica un rango de 65,536 direcciones IP de192.168.0.0a192.168.255.255.La cantidad máxima de Pods que pueden ejecutarse en un solo nodo se especifica con
nodeConfig.podDensity.maxPodsPerNode.Según la configuración máxima de Pods por nodo, Google Distributed Cloud aprovisiona alrededor del doble de direcciones IP al nodo. Las direcciones IP adicionales ayudan a evitar la reutilización involuntaria de las IP del Pod en un corto período de tiempo.
Dividir la cantidad total de direcciones IP del Pod por la cantidad de direcciones IP del Pod aprovisionadas en cada nodo te brinda la cantidad total de nodos que puedes tener en el clúster.
Por ejemplo, si el CIDR de tu Pod es 192.168.0.0/17, tienes un total de 32,768 direcciones IP (2(32-17) = 215 = 32,768). Si estableces 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 bloque CIDR /23 (2(32-23) = 29 = 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) nodos/clúster = 26 = 64 nodos/clúster).
Tanto clusterNetwork.pods.cidrBlocks como nodeConfig.podDensity.maxPodsPerNode son inmutables, por lo que debes planificar con cuidado el crecimiento futuro del clúster para evitar quedarte sin capacidad de nodo. Para conocer los valores máximos recomendados por clúster, Pods por nodo y nodos por clúster basados en las pruebas, consulta Límites.
CIDR de Service
El CIDR de tu Service se puede actualizar para agregar más Services a medida que escalas verticalmente el clúster. Sin embargo, no puedes reducir el rango de CIDR del Service. Para obtener más información, consulta Aumenta el rango de red de los servicios.
Recursos reservados para daemons del sistema
De forma predeterminada, Google Distributed Cloud reserva recursos automáticamente en un nodo para daemons del sistema, como sshd o udev. Los recursos de CPU y memoria se reservan en un nodo para daemons del sistema, de modo que estos daemons tengan los recursos que necesitan. Sin esta función, los Pods pueden consumir la mayoría de los recursos en un nodo, lo que imposibilita que los daemons del sistema completen sus tareas.
Específicamente, Google Distributed Cloud reserva 80 millicores de CPU (80 mCPU) y 280 mebibytes (280 MiB) de memoria en cada nodo para daemons del sistema. Ten en cuenta que la unidad de CPU mCPU representa la milésima de un núcleo, por lo que el 80/1,000 (o el 8%) de un núcleo de cada nodo se reserva para 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 expulsar Pods si su uso de CPU o memoria supera las cantidades que se les asignaron.
Herramientas de redes con MetalLB
Te recomendamos que aumentes la cantidad de bocinas de MetalLB para abordar los siguientes aspectos:
Ancho de banda: todo el ancho de banda del clúster para los servicios de balanceo de cargas depende de la cantidad de bocinas y el ancho de banda de cada nodo. El aumento del tráfico de red requiere más bocinas.
Tolerancia a errores: Una mayor cantidad de bocinas reduce el impacto general de la falla de una sola bocina.
MetalLB requiere conectividad de capa 2 entre los nodos del balanceo de cargas. En este caso, es posible que la cantidad de nodos con conectividad de capa 2 te limite a la cantidad de nodos en los que puedes colocar las bocinas MetalLB.
Planifica con cuidado cuántas bocinas de MetalLB quieres tener en el 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 en paquetes, 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 servicios
Agregar nodos, Pods y objetos Service es una forma de escalar verticalmente tu clúster. En las siguientes secciones, se abordan algunas configuraciones adicionales que debes tener en cuenta cuando aumentes la cantidad de nodos, pods y servicios 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.
Crear un clúster sin kube-proxy
Para crear un clúster de alto rendimiento que pueda escalar verticalmente a fin de usar una gran cantidad de servicios 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 kube-proxy-replacement. 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. Se debe establecer esta configuración 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 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 un nombre de dominio completamente calificado (FQDN). El servidor DNS agrega todos los dominios de búsqueda especificados antes de buscar el nombre de host solicitado originalmente, que ordena las búsquedas como la siguiente cuando se resuelve google.com:
google.com.NAMESPACE.svc.cluster.localgoogle.com.svc.cluster.localgoogle.com.cluster.localgoogle.com.c.PROJECT_ID.internalgoogle.com.google.internalgoogle.com
Cada una de las búsquedas se realiza para IPv4 (registro A) e IPv6 (registro AAAA), lo que da como resultado 12 solicitudes DNS para cada consulta que no sea FQDN, lo que amplifica el tráfico de DNS de manera significativa. Para mitigar este problema, te recomendamos que declares el nombre de host que quieres buscar como un FQDN agregando un punto final (google.com.). Esta declaración se debe realizar 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 a la mitad las solicitudes de DNS mediante la eliminación de la búsqueda de registros AAAA en el servidor DNS ascendente. 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 la aplicación, te recomendamos que uses nodos dedicados para la Deployment de coredns. Esta Deployment pertenece a un dominio de fallas diferente al de las aplicaciones normales. Si necesitas ayuda a fin de configurar nodos exclusivos 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 todo momento, solo hay una sola bocina de MetalLB que entrega una VIP LoadBalancer específica.
Conmutación por error
Antes de la versión 1.28.0 de Google Distributed Cloud, a 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 específica, como un Service de Ingress, que espera cerca o más de 30,000 conexiones simultáneas, es probable que el nodo de la bocina que controla la VIP agote los puertos disponibles. Debido a una limitación de arquitectura, MetalLB no puede mitigar este problema. Considera cambiar al balanceo de cargas agrupado con BGP antes de la creación del clúster o usa una clase de entrada diferente. Para obtener más información, consulta Configuración de Ingress.
Bocinas 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 bocinas 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. En las implementaciones de producción, te recomendamos que uses tres nodos del plano de control para alta disponibilidad. Es posible que aumentar la cantidad de nodos del plano de control a más de tres para admitir bocinas adicionales no sea un buen uso de tus recursos.
Configuración de Ingress
Si esperas que se produzcan cerca de 30,000 conexiones simultáneas en una sola VIP del servicio LoadBalancer, es posible que MetalLB no sea compatible.
Puedes considerar exponer la VIP a través de otros mecanismos, como BIG-IP de F5. De manera alternativa, puedes crear un clúster nuevo mediante 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 los parámetros de configuración de recursos predeterminados para los componentes de Cloud Logging y Cloud Monitoring no sean suficientes. Si deseas obtener instrucciones para ajustar las solicitudes y los límites de recursos de los componentes de observabilidad, consulta Configura los recursos de los componentes de Stackdriver.
En particular, las métricas de estado de kube en clústeres con una gran cantidad de servicios y extremos pueden causar un uso excesivo de la memoria tanto en kube-state-metrics como en gke-metrics-agent en el mismo nodo. El uso de recursos del servidor de métricas también puede escalar en términos de nodos, pods y servicios. Si tienes problemas con los recursos de 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 para tus nodos de modo 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 quieras intentar 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...
El ajuste 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 del SO.
prácticas recomendadas
En esta sección, se describen las prácticas recomendadas para escalar verticalmente tu clúster.
Ajustar una dimensión a la vez
Para minimizar los problemas y facilitar la reversión de cambios, no ajustes más de una dimensión a la vez. Aumentar la escala de varias dimensiones simultáneamente puede causar problemas incluso en clústeres más pequeños. Por ejemplo, es probable que no tengas éxito si intentas aumentar la cantidad de Pods programados por nodo a 110 y, al mismo tiempo, aumentar la cantidad de nodos en el clúster, porque la cantidad de Pods, la cantidad de Pods por nodo y la cantidad de nodos se extiende demasiado.
Escala clústeres en etapas
El escalamiento vertical de un clúster puede consumir muchos recursos. Para reducir el riesgo de que fallen las operaciones del clúster o que 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 trabajadores, es mejor crear primero un clúster de alta disponibilidad (HA) con nodos del plano de control y, luego, escalar verticalmente de forma gradual. La operación de creación de clústeres usa un clúster de arranque, que no tiene alta disponibilidad y, por lo tanto, es menos confiable. Una vez que se haya creado el clúster independiente o híbrido con alta disponibilidad, puedes usarlo para escalar verticalmente a más nodos.
Aumentar la cantidad de nodos trabajadores en lotes
Si vas a expandir un clúster a más nodos trabajadores, es mejor hacerlo en etapas. Te recomendamos que no agregues 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 en serie, una tras otra. Si tienes una conexión ascendente negativa a tu servidor de registro de imágenes, una extracción de imagen errónea puede detener toda la cola para un grupo de nodos determinado.
Para mitigar esto, te recomendamos que configures serializeImagePulls como false en la configuración personalizada de kubelet. Para obtener instrucciones y más información, consulta Establece la configuración de extracción de imágenes de kubelet.
Habilitar las extracciones de imágenes paralelas puede generar aumentos repentinos en el consumo de ancho de banda de red o E/S de disco.
Ajusta las solicitudes y los límites de recursos de las aplicaciones
En entornos densamente empaquetados, las cargas de trabajo de aplicaciones podrían expulsarse. Kubernetes usa el mecanismo al que se hace referencia para clasificar los Pods en caso de expulsión.
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 Cloud Architecture Center.
Usa un socio de almacenamiento
Te recomendamos que uses uno de los socios de almacenamiento listos para GDCV para implementaciones a gran escala. Es importante confirmar la siguiente información con el socio de almacenamiento específico:
- 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 nodo y las solicitudes y 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 escala alta que desees implementar.
Configura clústeres para una alta disponibilidad
Es importante auditar tu implementación a gran escala y asegurarte de que los componentes fundamentales estén configurados para la alta disponibilidad siempre que sea posible. Google Distributed Cloud admite opciones de implementación de HA para todos los tipos de clústeres. Para obtener más información, consulta Elige un modelo de implementación. Para ver ejemplos de archivos de configuración de clúster de implementaciones de alta disponibilidad, consulta Muestras de configuración de clúster.
También es importante auditar otros componentes, como los siguientes:
- Proveedor de almacenamiento
- Webhooks de clúster
Supervisa el uso de recursos
En esta sección, se proporcionan algunas recomendaciones de supervisión básicas para clústeres a gran escala.
Supervisa atentamente las métricas de uso
Es fundamental supervisar el uso de los nodos y de los componentes individuales del sistema, y asegurarse de que tengan un margen seguro de forma cómoda. Para ver qué funciones de supervisión estándar están disponibles de forma predeterminada, consulta Usa paneles predefinidos.
Supervisa el consumo del ancho de banda
Supervisa el consumo de ancho de banda de cerca para asegurarte de que no se esté saturando la red, lo que provocará 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 de etcd estándar usa /var/lib/etcd como su directorio de datos y el puerto 2379 para las solicitudes de clientes. La instancia de etcd-events usa /var/lib/etcd-events como su 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 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 E/S de disco.
La documentación de etcd proporciona recomendaciones de hardware adicionales para garantizar el mejor rendimiento de etcd cuando se ejecutan los 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 “aplicar entradas de tiempo demasiado tiempo”? y ¿Qué significa la advertencia de etcd “no se pudo enviar la señal de monitoreo de funcionamiento a tiempo”?.
Si necesitas asistencia adicional, comunícate con Atención al cliente de Cloud.