Cuotas y límites

En esta página, se explican las cuotas y los límites de los clústeres de Anthos en equipos físicos 1.9 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

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 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 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 los 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 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

Los clústeres de Anthos alojados en equipos físicos admiten 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 RHEL y CentOS, 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 Service 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 y CentOS genera esta limitación. No es una limitación intrínseca de clústeres de Anthos alojados en Bare Metal.

Mitigación

Para RHEL y CentOS, no hay mitigaciones. Para los sistemas Ubuntu y Debian, recomendamos cambiar de iptables predeterminado a iptables heredado en clústeres a gran escala.

Límite de eBPF de 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 Services LoadBalancer y NodePort es 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.

Usa el siguiente comando para verificar la cantidad de puertos asignados en la actualidad:

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 15 clústeres. Si deseas registrar más clústeres en GKE Hub, puedes enviar una solicitud para aumentar tu cuota en la consola de Google Cloud.

Ir a Cuotas

¿No encontraste lo que buscabas? Haz clic en Enviar comentarios y cuéntanos qué es lo que falta.