En esta página, se explican las cuotas y los límites de la versión 1.16 de GKE on Bare Metal para proyectos, clústeres y nodos de Google Cloud.
Límites
En las siguientes secciones, se describen algunos límites básicos para los clústeres. Ten en cuenta estos límites cuando diseñes las aplicaciones para que se ejecuten en GKE en Bare Metal.
Cantidad máxima de clústeres de usuario 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 las operaciones fundamentales de los clústeres de usuario, como la creación de clústeres, el restablecimiento de clústeres o nodos, las actualizaciones de clústeres y las actualizaciones 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.
En función de las pruebas en curso, un clúster de administrador puede admitir de manera 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 usuario
Te recomendamos que limites la cantidad de Pods por clúster de usuario 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 en tu clúster a 136 o menos. En la siguiente tabla, se proporcionan ejemplos de configuraciones que se recomiendan y 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 para 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 GKE en Bare Metal 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
GKE en Bare Metal admite la configuración de Pods máximos por nodo en la configuración 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 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 causa esta limitación; no es una limitación intrínseca de GKE en Bare Metal.
Mitigación
Para RHEL y CentOS, no hay mitigaciones. Para los sistemas Ubuntu y Debian, recomendamos cambiar del nftables 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 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 superas el límite, no podrás crear servicios LoadBalancer o NodePort nuevos ni agregar puertos de nodo nuevos para los servicios existentes.
De forma predeterminada, Kubernetes asigna puertos de nodo a Services de tipo LoadBalancer.
Estas asignaciones pueden agotar con rapidez 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 del nodo del balanceador de cargas mediante la configuración del campo allocateLoadBalancerNodePorts en false en las especificaciones del Service de LoadBalancer. Esta configuración evita que Kubernetes asigne puertos de nodo a los servicios de LoadBalancer. Para obtener más información, consulta Inhabilita 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 15 clústeres. Si deseas registrar más clústeres en GKE Hub, puedes enviar una solicitud para aumentar la cuota en la consola de Google Cloud:
Problemas de escalamiento
En esta sección, se describen algunos problemas que debes tener en cuenta cuando escalas los clústeres.
Recursos reservados para daemons del sistema
A partir de la versión 1.14, GKE en Bare Metal reserva recursos de forma automática 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, que está habilitada de forma predeterminada, los Pods pueden consumir la mayoría de los recursos en un nodo, lo que hace imposible que los daemons del sistema completen sus tareas.
Específicamente, GKE en Bare Metal reserva 50 millicores de CPU (50 mCPU) y 280 mebibytes (280 MiB) de memoria en cada nodo para daemons del sistema. Ten en cuenta que la unidad de CPU "mCPU" significa "milésima de un núcleo", por lo que el 50/1,000 o el 5% de un núcleo en 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.
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, GKE en Bare Metal almacena objetos de evento 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 del 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 que indica que “las entradas se aplicaron demasiado tiempo”? y ¿Qué significa la advertencia de etcd "error al enviar señales de monitoreo de funcionamiento a tiempo"?.
¿No encontraste lo que buscabas? Haz clic en Enviar comentarios y cuéntanos qué falta.