En esta página, se explican las cuotas y los límites de Google Distributed Cloud versión 1.30 para proyectos, clústeres y nodos de Google Cloud.
Límites
En las siguientes secciones, se describen algunos límites básicos para tus clústeres. Ten en cuenta estos límites cuando diseñes tus aplicaciones para que se ejecuten en Google Distributed Cloud.
Clústeres de usuario máximos por clúster de administrador
Los clústeres de administrador administran 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 de clústeres o nodos, las actualizaciones y las mejoras de clústeres. La cantidad total de nodos del clúster de usuario es uno de los factores principales que limitan el rendimiento y la confiabilidad.
Según las pruebas en curso, un clúster de administrador puede admitir de forma confiable un máximo de 100 clústeres de usuario con 10 nodos cada uno, para un total de 1,000 nodos.
Cantidad máxima de Pods por clúster de usuarios
Recomendamos que limites la cantidad de Pods por clúster de usuarios a 15,000 o menos. Por ejemplo, si tu clúster tiene 200 nodos, debes restringir la cantidad de Pods por nodo a 75 o menos. Del mismo modo, si deseas ejecutar 110 Pods por nodo, debes restringir la cantidad de nodos de tu clúster a 136 o menos. En la siguiente tabla, se proporcionan ejemplos de configuraciones que se recomiendan y otras que no.
| Pods por nodo | Nodes per cluster | Pods por clúster | Resultado |
|---|---|---|---|
| 110 | 200 | 22,000 | Demasiados Pods, no se recomienda |
| 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 cantidad máxima de Pods por recomendación de clúster de usuario tiene prioridad sobre las recomendaciones de Pods por nodo y nodos por clúster de usuario en las siguientes secciones.
Cantidad máxima de nodos por clúster de usuario
Probamos Google Distributed Cloud para ejecutar cargas de trabajo con hasta 500 nodos. Sin embargo, para garantizar un rendimiento y una confiabilidad óptimos, te recomendamos que no excedas los 200 nodos por clúster cuando ejecutes cargas de trabajo en producción.
| Tipo de clúster | Cantidad mínima de nodos | Cantidad máxima de nodos recomendada | Nodos máximos absolutos |
|---|---|---|---|
| Usuario, independiente o híbrido | 1 | 200 | 500 |
Para los clústeres de nodo único, debes quitar el taint node-role.kubernetes.io/master:NoSchedule a fin de ejecutar cargas de trabajo en el nodo.
Para obtener más información, consulta Taints y tolerancias de Kubernetes.
Cantidad máxima de Pods por nodo
Google Distributed Cloud admite la configuración de un máximo de Pods por nodo en la configuración nodeConfig.PodDensity.MaxPodsPerNode del archivo de configuración de clúster. En la siguiente tabla, se muestran los valores mínimos y máximos admitidos para MaxPodsPerNode, que incluyen Pods que ejecutan servicios de complementos:
| Tipo de clúster | Valor mínimo permitido | Valor máximo recomendado | Valor máximo permitido |
|---|---|---|---|
| Todos los clústeres de HA y clústeres de usuario que no son de HA | 32 | 110 | 250 |
| Todos los demás clústeres que no son de HA | 64 | 110 | 250 |
Cantidad máxima de extremos
En Red Hat Enterprise Linux (RHEL), hay una limitación a nivel del clúster de 100,000 extremos. Este número es la suma de todos los pods a los que hace referencia un servicio de Kubernetes. Si dos Services hacen referencia al mismo conjunto de Pods, esta situación cuenta como dos conjuntos separados de extremos. La implementación subyacente de nftable en RHEL genera esta limitación. No es una limitación intrínseca de Google Distributed Cloud.
Mitigación
Para RHEL, no hay mitigaciones. Para los sistemas Ubuntu y Debian, recomendamos cambiar de nftables predeterminado a iptables heredado en clústeres a gran escala.
GKE Dataplane V2
Google Distributed Cloud usa GKE Dataplane V2, un plano de datos de clústeres implementado con Cilium y eBPF, que está optimizado para las herramientas de redes de Kubernetes.
Límites de NetworkPolicy de GKE Dataplane V2
GKE Dataplane V2 usa Cilium para administrar los recursos NetworkPolicy de Kubernetes. Se aplican los siguientes límites a tus clústeres de Google Distributed Cloud:
| Dimensión | Límites admitidos |
|---|---|
| Tasa de cambio máxima para etiquetas de espacio de nombres | Como máximo, un cambio por hora para cada espacio de nombres
En la mayoría de los casos, este límite no es necesario. Siempre que los cambios no sean frecuentes, como cada segundo, o la cantidad de identidades de Cilium (conjuntos de etiquetas únicos) no esté cerca del límite: 16,000 conjuntos de etiquetas con políticas de red de permitir todo o 65,535 conjuntos de etiquetas por clúster. |
| Cantidad máxima de extremos de servicio por clúster | 100,000 extremos es el límite probado y recomendado. El límite codificado para los extremos de servicio es de 262,000. |
| Cantidad máxima 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 máxima de cambios para las políticas de red | Como máximo, 20 cambios (creaciones o eliminaciones) por segundo. |
| Cantidad máxima de conjuntos de etiquetas de Pod único | 65,535 (216-1). Este es el límite de la identidad de seguridad de Cilium. |
| Cantidad máxima de conjuntos de etiquetas de Pod único seleccionados por selectores de políticas | 16,000 (el tamaño fijo del mapa de eBPF). Una entrada de mapa del selector de políticas determinada consiste en lo siguiente: identidad de seguridad, puerto y protocolo. |
Límite de eBPF de GKE Dataplane V2
La cantidad máxima de entradas en el lbmap de BPF para Dataplane V2 es de 65,536. Los aumentos en las siguientes áreas pueden hacer que la cantidad total de entradas crezca:
- Cantidad de Services
- Cantidad de puertos por Service
- Cantidad de backends por Service
Recomendamos que supervises la cantidad real de entradas que usa tu clúster para asegurarte de no exceder 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 te recomendamos usar tu propia canalización de supervisión para recopilar métricas del DaemonSet de anetd. Supervisa las siguientes condiciones para identificar cuándo la cantidad de entradas genera 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 Services LoadBalancer y NodePort
El límite de puertos para los servicios LoadBalancer y NodePort es de 2,768. El rango de puertos predeterminado es 30000-32767. Si excedes el límite, no puedes crear servicios nuevos de LoadBalancer o NodePort, y no puedes agregar puertos de nodos nuevos para servicios existentes.
De forma predeterminada, Kubernetes asigna puertos de nodo a servicios de tipo LoadBalancer.
Estas asignaciones pueden agotar rápidamente los puertos de nodo disponibles de los 2,768 asignados a tu clúster. Para guardar los puertos de nodo, inhabilita la asignación de puertos de nodo del balanceador de cargas configurando el campo allocateLoadBalancerNodePorts en false en la especificación del servicio LoadBalancer. Este parámetro de configuración evita que Kubernetes asigne puertos de nodo a los servicios LoadBalancer. Para obtener más información, consulta Cómo inhabilitar la asignación de NodePort del balanceador de cargas en la documentación de Kubernetes.
Usa el siguiente comando para verificar la cantidad de puertos asignados:
kubectl get svc -A | grep : | tr -s ' ' | cut -d ' ' -f6 | tr ',' '\n' | wc -l
Límites de conexiones de nodos del balanceador de cargas en paquetes
La cantidad de conexiones permitidas para cada nodo que se usa en el balanceo de cargas en paquetes (MetalLB) es de 28,000. El rango de puertos efímeros predeterminado para estas conexiones es 32768-60999. Si excedes el límite de conexión, pueden fallar las solicitudes al Service LoadBalancer.
Si necesitas exponer un servicio de balanceador de cargas que pueda controlar una cantidad sustancial de conexiones (por ejemplo, para Ingress), te recomendamos que consideres un método de balanceo de cargas alternativo a fin de 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 deseas registrar más clústeres en GKE Hub, puedes enviar una solicitud para aumentar tu cuota en la consola de Google Cloud.
Para obtener más información sobre las cuotas de clústeres según la configuración de membresía, consulta Cuotas de asignación.
Información de escalamiento
La información de este documento es relevante para planificar cómo escalar verticalmente tus clústeres. Para obtener más información, consulta Escala verticalmente los clústeres de Google Distributed Cloud.
¿No encontraste lo que buscabas? Haz clic en Enviar comentarios y cuéntanos qué es lo que falta.