En esta página, se explican las cuotas y los límites de los clústeres de Anthos en la versión 1.12 de Bare Metal para proyectos, clústeres y nodos de Google Cloud.
Límites
Ten en cuenta los siguientes límites y recomendaciones para tus clústeres.
Cantidad máxima de pods por clúster
Te recomendamos que limites la cantidad de pods por clúster 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 recomendadas y no recomendadas.
| 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 recomendación de la cantidad máxima de pods por clúster tiene prioridad sobre las recomendaciones de pods por nodo y nodos por clúster en las siguientes secciones.
Cantidad máxima de nodos por clúster
Probamos clústeres de Anthos en equipos físicos para ejecutar cargas de trabajo con hasta 500 nodos. Sin embargo, para garantizar un rendimiento y una confiabilidad óptimos, te recomendamos que no superes 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 | Cantidad máxima de nodos 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
Los clústeres de Anthos en equipos físicos admiten la configuración de pods máximos por nodo en la configuración nodeConfig.PodDensity.MaxPodsPerNode del archivo de configuración de clústeres. En la siguiente tabla, se muestran los valores mínimos y máximos compatibles con MaxPodsPerNode, incluidos los pods que ejecutan servicios de complemento:
| 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 RHEL y CentOS, existe una limitación a nivel de 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 servicios hacen referencia al mismo conjunto de pods, esta situación cuenta como dos conjuntos de extremos separados. La implementación subyacente de nftable en RHEL y CentOS provoca esta limitación; no es una limitación intrínseca de los clústeres de Anthos en Bare Metal.
Mitigación
Para RHEL y CentOS, no hay mitigaciones. Para los sistemas Ubuntu y Debian, recomendamos cambiar del iptables predeterminado al iptables heredado en clústeres a gran escala.
Límite de eBPF de Dataplane V2
La cantidad máxima de entradas en el mapa de bits de BPF para Dataplane V2 es 65,536. Los aumentos en las siguientes áreas pueden hacer que aumente la cantidad total de entradas:
- Cantidad de servicios
- Cantidad de puertos por servicio
- Cantidad de backends por servicio
Te recomendamos que supervises la cantidad real de entradas que usa el 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 que uses 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 causa 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 2,768. El rango de puertos predeterminado es 30000-32767. Si excedes el límite, no puedes crear servicios LoadBalancer ni NodePort nuevos ni agregar puertos de nodo nuevos para los servicios existentes.
Usa el siguiente comando para verificar la cantidad de puertos asignados actualmente:
kubectl get svc -A | grep : | tr -s ' ' | cut -d ' ' -f6 | tr ',' '\n' | wc -l
Límites de conexión de los 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 28,000. El rango de puertos efímero predeterminado para estas conexiones es 32768-60999. Si excedes el límite de conexiones, las solicitudes al servicio LoadBalancer podrían fallar.
Si necesitas exponer un servicio de balanceador de cargas que pueda manejar una cantidad sustancial de conexiones (por ejemplo, Ingress), te recomendamos que consideres un método de balanceo de cargas alternativo para evitar esta limitación con MetalLB.
Cuotas de clústeres
De forma predeterminada, puedes registrar un máximo de 15 clústeres. Para registrar más clústeres en GKE Hub, puedes enviar una solicitud a fin de aumentar tu cuota en Google Cloud Console:
¿No encontraste lo que buscabas? Haz clic en Enviar comentarios y cuéntanos qué es lo que falta.