En esta página se detallan las cuotas y los límites de Google Distributed Cloud (solo software) en proyectos, clústeres y nodos de bare metal. Google Cloud
Límites
En las secciones siguientes se describen algunos límites básicos de los clústeres. Ten en cuenta estos límites al diseñar tus aplicaciones para que se ejecuten en Google Distributed Cloud.
Número máximo de clústeres de usuarios por clúster de administrador
Los clústeres de administrador gestionan el ciclo de vida de los clústeres de usuario y sus nodos asociados. Los clústeres de administrador controlan operaciones críticas de los clústeres de usuario, como la creación, el restablecimiento, la actualización y la mejora de clústeres o nodos. El número total de nodos de clúster de usuarios es uno de los principales factores que limitan el rendimiento y la fiabilidad.
Según las pruebas que se están llevando a cabo, un clúster de administradores puede admitir de forma fiable un máximo de 100 clústeres de usuarios con 10 nodos cada uno,lo que supone un total de 1000 nodos.
Número máximo de pods por clúster de usuarios
Te recomendamos que limites el número de pods por clúster de usuarios a 15.000 o menos. Por ejemplo, si tu clúster tiene 200 nodos, debes limitar el número de pods por nodo a 75 o menos. Del mismo modo, si quieres ejecutar 110 pods por nodo, debes limitar el número de nodos de tu clúster a 136 o menos. En la siguiente tabla se muestran ejemplos de configuraciones recomendadas y no recomendadas.
| Pods por nodo | Nodos por clúster | Pods por clúster | Resultado |
|---|---|---|---|
| 110 | 200 | 22.000 | Demasiados pods (no recomendado) |
| 110 | 136 | 14.960 | Dentro del límite |
| 100 | 150 | 15.000 | Dentro del límite |
| 75 | 200 | 15.000 | Dentro del límite |
La recomendación sobre el número máximo de pods por clúster de usuarios tiene prioridad sobre las recomendaciones de pods por nodo y nodos por clúster de usuarios de las siguientes secciones.
Número máximo de nodos por clúster de usuarios
Probamos Google Distributed Cloud para ejecutar cargas de trabajo con hasta 500 nodos. Sin embargo, para garantizar un rendimiento y una fiabilidad óptimos, te recomendamos que no superes los 200 nodos por clúster al ejecutar cargas de trabajo en producción.
| Tipo de clúster | Nodos mínimos | Número máximo de nodos recomendado | Número máximo absoluto de nodos |
|---|---|---|---|
| Usuario, independiente o híbrido | 1 | 200 | 500 |
En los clústeres de un solo nodo, debes quitar el taint node-role.kubernetes.io/master:NoSchedule para ejecutar cargas de trabajo en el nodo.
Para obtener más información, consulta el artículo sobre tolerancias e intolerancias de Kubernetes.
Número máximo de pods por nodo
Google Distributed Cloud admite la configuración del número máximo de pods por nodo en el ajuste nodeConfig.PodDensity.MaxPodsPerNode del archivo de configuración del clúster. En la siguiente tabla se muestran los valores mínimos y máximos admitidos para MaxPodsPerNode, que incluye los pods que ejecutan servicios complementarios:
| Tipo de clúster | Valor mínimo permitido | Valor máximo recomendado | Valor máximo permitido |
|---|---|---|---|
| Todos los clústeres de alta disponibilidad y los clústeres de usuarios que no son de alta disponibilidad | 32 | 110 | 250 |
| Todos los demás clústeres que no son de alta disponibilidad | 64 | 110 | 250 |
Número máximo de endpoints
En Red Hat Enterprise Linux (RHEL), hay un límite a nivel de clúster de 100.000 endpoints. Este número es la suma de todos los pods a los que hace referencia un servicio de Kubernetes. Si dos servicios hacen referencia al mismo conjunto de pods, esta situación se considera como dos conjuntos de endpoints independientes. La implementación subyacente de nftable
en RHEL provoca esta limitación, que no es intrínseca de Google Distributed Cloud.
Mitigación
En RHEL, no hay mitigaciones. En los sistemas Ubuntu y Debian, te recomendamos que cambies de la opción predeterminada nftables a la antigua
iptables en clústeres de gran tamaño.
GKE Dataplane V2
Google Distributed Cloud usa GKE Dataplane V2, un plano de datos de clúster implementado con Cilium y eBPF, que está optimizado para las redes de Kubernetes.
Límites de GKE Dataplane V2 NetworkPolicy
GKE Dataplane V2 usa Cilium para gestionar los recursos de NetworkPolicy de Kubernetes. Se aplican los siguientes límites a los clústeres:
| Dimensión | Límites admitidos |
|---|---|
| Tasa de cambio máxima de las etiquetas de espacio de nombres | Como máximo, un cambio por hora en cada espacio de nombres.
En la mayoría de los casos, este límite no es necesario. Siempre que los cambios no sean frecuentes (por ejemplo, cada segundo) o el número de identidades de Cilium (conjuntos de etiquetas únicos) no se acerque al límite: 16.000 conjuntos de etiquetas con políticas de red permitir todo o 65.535 conjuntos de etiquetas por clúster. |
| Número máximo de endpoints de servicio por clúster | 100.000 es el límite probado y recomendado. El límite codificado de los endpoints de servicio es 262.000. |
| Número máximo de políticas y reglas de red | Como máximo, 40.000 políticas de red y 80.000 reglas. Por ejemplo, puedes especificar 40.000 políticas de red con dos reglas cada una o 20.000 políticas con cuatro reglas cada una. |
| Tasa de cambio máxima de las políticas de red | Un máximo de 20 cambios (creaciones o eliminaciones) por segundo. |
| Número máximo de conjuntos de etiquetas de pods únicos | 65.535 (216-1). Este es el límite de identidades de seguridad de Cilium. |
| Número máximo de conjuntos de etiquetas de pods únicos seleccionados por selectores de políticas | 16.000 (el tamaño fijo del mapa eBPF). Una entrada de un mapa de selectores de políticas determinado consta de los siguientes elementos: identidad de seguridad, puerto y protocolo. |
Límite de eBPF de GKE Dataplane V2
El número máximo de entradas en el lbmap de BPF para Dataplane V2 es 65.536. Si aumentan los siguientes aspectos, puede crecer el número total de entradas:
- Número de servicios
- Número de puertos por servicio
- Número de backends por servicio
Te recomendamos que monitorices el número real de entradas que usa tu clúster para asegurarte de que no superas el límite. Usa el siguiente comando para obtener las entradas actuales:
kubectl get po -n kube-system -l k8s-app=cilium | cut -d " " -f1 | grep anetd | head -n1 | \
xargs -I % kubectl -n kube-system exec % -- cilium bpf lb list | wc -l
También le recomendamos que utilice su propia canalización de monitorización para recoger métricas del anetd DaemonSet. Monitoriza las siguientes condiciones para identificar cuándo el número de entradas está causando problemas:
cilium_bpf_map_ops_total{map_name="lb4_services_v2",operation="update",outcome="fail" } > 0
cilium_bpf_map_ops_total{map_name="lb4_backends_v2",operation="update",outcome="fail" } > 0
Límite de puertos de los servicios LoadBalancer y NodePort
El límite de puertos para los servicios LoadBalancer y NodePort es de 2768. El intervalo de puertos predeterminado es 30000-32767. Si supera el límite, no podrá crear nuevos servicios LoadBalancer ni NodePort, ni añadir nuevos puertos de nodo a los servicios que ya tenga.
De forma predeterminada, Kubernetes asigna puertos de nodo a los servicios de tipo LoadBalancer.
Estas asignaciones pueden agotar rápidamente los puertos de nodo disponibles de los 2768 asignados a tu clúster. Para guardar los puertos de nodo, inhabilita la asignación de puertos de nodo del balanceador de carga configurando el campo allocateLoadBalancerNodePorts en false en la especificación del servicio LoadBalancer. Este ajuste impide que Kubernetes asigne puertos de nodo a los servicios LoadBalancer. Para obtener más información, consulta el artículo sobre cómo inhabilitar la asignación de NodePort del balanceador de carga en la documentación de Kubernetes.
Usa el siguiente comando para comprobar el número de puertos asignados:
kubectl get svc -A | grep : | tr -s ' ' | cut -d ' ' -f6 | tr ',' '\n' | wc -l
Límites de conexión de nodos de balanceadores de carga agrupados
El número de conexiones permitidas para cada nodo usado en el balanceo de carga agrupado (MetalLB) es de 28.000. El intervalo de puertos efímeros predeterminado para estas conexiones es 32768-60999. Si superas el límite de conexiones, es posible que las solicitudes al servicio LoadBalancer fallen.
Si necesitas exponer un servicio de balanceador de carga que pueda gestionar un número considerable de conexiones (por ejemplo, para Ingress), te recomendamos que utilices un método de balanceo de carga alternativo para evitar esta limitación con MetalLB.
Cuotas de clústeres
De forma predeterminada, puedes registrar un máximo de 250 clústeres con membresías globales por flota. Si quieres registrar más clústeres en GKE Hub, puedes enviar una solicitud para aumentar tu cuota a través de la Google Cloud consola:
Para obtener más información sobre las cuotas de clústeres en función de la configuración de la pertenencia, consulta Cuotas de asignación.
Información de escalado
La información de este documento es relevante para planificar cómo ampliar tus clústeres. Para obtener más información, consulta Escalar verticalmente clústeres de Google Distributed Cloud.
¿No has encontrado lo que buscabas? Haz clic en Enviar comentarios y cuéntanos lo que echas en falta.