Por qué planificar clústeres grandes de GKE
Todos los sistemas informáticos, incluido Kubernetes, tienen algunos límites arquitectónicos. Si supera los límites, puede afectar al rendimiento de su clúster o, en algunos casos, provocar tiempos de inactividad. Sigue las prácticas recomendadas y lleva a cabo las acciones recomendadas para asegurarte de que tus clústeres ejecuten tus cargas de trabajo de forma fiable a gran escala.
Limitaciones de los clústeres de GKE grandes
Cuando GKE escala un clúster a un gran número de nodos, intenta cambiar la cantidad de recursos disponibles para que se adapte a las necesidades de tu sistema sin superar sus objetivos de nivel de servicio (SLOs). Trusted Cloud by S3NS admite clústeres grandes. Sin embargo, en función de tu caso práctico, debes tener en cuenta las limitaciones de los clústeres grandes para responder mejor a los requisitos de escalado de tu infraestructura.
En esta sección se describen las limitaciones y las consideraciones que se deben tener en cuenta al diseñar clústeres de GKE grandes en función del número de nodos previsto.
Clústeres con hasta 5000 nodos
Al diseñar la arquitectura de tu clúster para que pueda escalarse hasta 5000 nodos, ten en cuenta las siguientes condiciones:
- Solo está disponible para el clúster regional.
- Solo está disponible para clústeres que usan Private Service Connect.
- Para migrar de clústeres zonales a regionales, debes volver a crear el clúster para desbloquear un nivel de cuota de nodos superior.
Si tienes previsto ampliar tu clúster a más de 5000 nodos, ponte en contacto con Cloud Customer Care para aumentar el tamaño del clúster y el límite de cuota.
Clústeres con más de 5000 nodos
GKE admite clústeres estándar grandes de hasta 15.000 nodos. En la versión 1.31 y posteriores, GKE admite clústeres grandes de hasta 65.000 nodos. El límite de 65.000 se ha diseñado para ejecutar cargas de trabajo de IA a gran escala.
Si tienes previsto escalar tu clúster a 15.000 o 65.000 nodos, completa las siguientes tareas:
Ten en cuenta las siguientes limitaciones:
- No se admite la herramienta de adaptación dinámica de clústeres. En su lugar, aumenta o reduce la escala de tus grupos de nodos con la API de GKE.
- No se admite multirred.
- Los servicios con más de 100 pods deben ser sin interfaz.
- Cada pod debe ejecutarse en su propio nodo, excepto los DaemonSets del sistema. Para definir la programación de pods en nodos específicos, puedes usar la afinidad o antiafinidad de pods de Kubernetes.
- Para migrar de clústeres de zona a clústeres regionales, debes volver a crear el clúster para desbloquear un nivel de cuota de nodos superior.
- Para migrar a clústeres que usen Private Service Connect, debes volver a crear el clúster para desbloquear el nivel de cuota de nodos superior.
Ponte en contacto con el equipo de Asistencia de Google Cloud para aumentar el tamaño del clúster y el límite de cuota a 15.000 o 65.000 nodos, en función de tus necesidades de escalado.
Prácticas recomendadas para dividir las cargas de trabajo entre varios clústeres
Puedes ejecutar tus cargas de trabajo en un solo clúster grande. Este enfoque es más fácil de gestionar, más rentable y proporciona un mejor uso de los recursos que varios clústeres. Sin embargo, en algunos casos, es necesario dividir la carga de trabajo en varios clústeres:
- Consulta los casos prácticos de varios clústeres para obtener más información sobre los requisitos generales y los escenarios de uso de varios clústeres.
- Además, desde el punto de vista de la escalabilidad, divide tu clúster cuando pueda superar uno de los límites descritos en la sección siguiente o una de las cuotas de GKE. Si se reduce el riesgo de alcanzar los límites de GKE, se reduce el riesgo de que se produzcan periodos de inactividad u otros problemas de fiabilidad.
Si decides dividir tu clúster, usa la gestión de flotas para simplificar la gestión de una flota de varios clústeres.
Límites y prácticas recomendadas
Para asegurarte de que tu arquitectura admite clústeres de GKE a gran escala, consulta los siguientes límites y las prácticas recomendadas relacionadas. Si se superan estos límites, el rendimiento del clúster puede verse reducido o pueden producirse problemas de fiabilidad.
Estas prácticas recomendadas se aplican a cualquier clúster de Kubernetes predeterminado sin extensiones instaladas. Es habitual ampliar los clústeres de Kubernetes con webhooks o definiciones de recursos personalizadas (CRDs), pero esto puede limitar tu capacidad para escalar el clúster.
En la siguiente tabla se amplían las cuotas y los límites de GKE principales. También debes familiarizarte con los límites de Kubernetes de código abierto para clústeres a gran escala.
Los requisitos de versión de GKE que se mencionan en la tabla se aplican tanto a los nodos como al plano de control.
| Límite de GKE | Descripción | Prácticas recomendadas |
|---|---|---|
| Tamaño de la base de datos etcd | El tamaño máximo de la base de datos etcd es de 6 GB. Debes monitorizar de forma proactiva el tamaño de la base de datos etcd de tu clúster y configurar alertas para recibir notificaciones cuando el uso se acerque a este límite. Si se supera el límite, pueden producirse problemas en el plano de control. | Puedes usar los siguientes recursos para monitorizar tu uso:
Para obtener más información sobre cómo responder cuando te acerques al límite, consulta Identificar clústeres en los que el uso de etcd se acerca al límite. |
| Tamaño total de los objetos etcd por tipo | El tamaño total de todos los objetos del tipo de recurso indicado no debe superar los 800 MB. Por ejemplo, puedes crear 750 MB de instancias de Pod y 750 MB de secretos, pero no puedes crear 850 MB de secretos. Si creas más de 800 MB de objetos, es posible que tus controladores de Kubernetes o personalizados no se inicialicen y se produzcan interrupciones. |
El tamaño total de todos los objetos de cada tipo almacenados en etcd no debe superar los 800 MB. Esto se aplica especialmente a los clústeres que usan muchos secretos o ConfigMaps de gran tamaño, o un gran volumen de CRDs. |
| Número de servicios de clústeres en los que GKE Dataplane V2 no está habilitado | El rendimiento de iptables que usa kube-proxy se reduce si ocurre alguna de las siguientes situaciones:
Este límite se elimina cuando se habilita GKE Dataplane V2. |
Mantén el número de servicios del clúster por debajo de 10.000. Para obtener más información, consulta Exponer aplicaciones mediante servicios. |
| Número de servicios por espacio de nombres | El número de variables de entorno generadas para los servicios puede superar los límites del shell. Esto puede provocar que los pods fallen al iniciarse. |
Mantén el número de servicios por espacio de nombres por debajo de 5000. Puedes inhabilitar el relleno de esas variables de entorno. Consulta la documentación sobre cómo definir Para obtener más información, consulta Exponer aplicaciones mediante servicios. |
| Número de pods detrás de un solo servicio en clústeres en los que GKE Dataplane V2 no está habilitado |
Cada nodo ejecuta un kube-proxy que usa watches para monitorizar cualquier cambio en el servicio. Cuanto mayor sea un clúster, más datos relacionados con los cambios procesará el agente. Esto se aprecia especialmente en los clústeres con más de 500 nodos. La información sobre los endpoints se divide
entre diferentes Los objetos de endpoint siguen estando disponibles para los componentes, pero cualquier endpoint que supere los 1000 pods se truncará automáticamente. |
Mantén el número de pods que hay detrás de un solo servicio por debajo de 10.000. Para obtener más información, consulta Exponer aplicaciones mediante servicios. |
| Número de pods detrás de un solo servicio en clústeres en los que GKE Dataplane V2 está habilitado |
GKE Dataplane V2 contiene límites en el número de pods expuestos por un solo servicio. Se aplica el mismo límite a los clústeres de Autopilot, ya que usan GKE Dataplane V2. |
En GKE 1.23 y versiones anteriores, el número de pods que hay detrás de un mismo servicio debe ser inferior a 1000. En GKE 1.24 y versiones posteriores, mantén el número de pods que hay detrás de un solo servicio por debajo de 10.000. Para obtener más información, consulta Exponer aplicaciones mediante servicios. |
| Registros DNS por servicio sin encabezado |
El número de registros DNS por servicio sin encabezado está limitado tanto en kube-dns como en Cloud DNS. |
Mantén el número de registros DNS por servicio sin encabezado por debajo de 1000 para kube-dns y de 3500/2000 (IPv4/IPv6) para Cloud DNS. |
| Número de todos los endpoints de servicio | El número de endpoints de todos los servicios puede alcanzar límites. Esto puede aumentar la latencia de programación o provocar que no se puedan programar nuevos endpoints. |
El número total de endpoints de todos los servicios no debe superar los 260.000. GKE Dataplane V2, que es el plano de datos predeterminado de GKE Autopilot, se basa en mapas eBPF que actualmente están limitados a 260.000 endpoints en todos los servicios. |
| Número de objetos de autoescalado horizontal de pods por clúster |
Cada Horizontal Pod Autoscaler (HPA) se procesa cada 15 segundos. Si hay más de 300 objetos HPA, el rendimiento puede degradarse de forma lineal. |
Mantén el número de objetos HPA dentro de este límite. De lo contrario, es posible que experimentes una degradación lineal de la frecuencia de procesamiento de HPA. Por ejemplo,en GKE 1.22 con 2000 HPAs, un solo HPA se volverá a procesar cada 1 minuto y 40 segundos. Para obtener más información, consulta Autoescalado basado en la utilización de recursos y Escalabilidad del autoescalado de pods horizontal. |
| Número de pods por nodo | GKE tiene un límite fijo de 256 pods por nodo. Esto presupone una media de dos contenedores o menos por pod. Si aumentas el número de contenedores por pod, este límite podría ser inferior porque GKE asigna más recursos por contenedor. |
Te recomendamos que uses nodos de trabajo con al menos una vCPU por cada 10 pods. Para obtener más información, consulta el artículo sobre cómo actualizar manualmente un clúster o un grupo de nodos. |
| Velocidad de los cambios de pods |
Kubernetes tiene límites internos que influyen en la frecuencia de creación o eliminación de pods (churn de pods) en respuesta a las solicitudes de escalado. Otros factores, como eliminar un pod que forma parte de un servicio, también pueden influir en esta tasa de abandono de pods. En los clústeres con hasta 500 nodos, se pueden crear y eliminar una media de 20 pods por segundo. En los clústeres de más de 500 nodos, se crearán y eliminarán 100 pods por segundo de media. |
Ten en cuenta el límite de frecuencia de creación y eliminación de pods al planificar cómo escalar tus cargas de trabajo. Los pods comparten el mismo rendimiento de eliminación con otros tipos de recursos (por ejemplo, EndpointSlices). Puedes reducir el rendimiento de eliminación cuando definas pods como parte de un servicio. Para permitir que la herramienta de adaptación dinámica del clúster elimine pods de nodos infrautilizados de forma eficaz, evita los PodDisruptionBudgets demasiado restrictivos y los periodos de gracia de finalización largos. Tampoco se recomienda usar tolerancias comodín Tolerations, ya que pueden provocar que las cargas de trabajo se programen en nodos que estén en proceso de eliminación. |
| Número de relojes abiertos | Los nodos crean un reloj para cada secreto y ConfigMaps que configures para los pods. La cantidad combinada de observadores creados por todos los nodos puede generar una carga considerable en el plano de control del clúster. Tener más de 200.000 relojes por clúster puede afectar al tiempo de inicialización del clúster. Este problema puede provocar que el plano de control se reinicie con frecuencia. |
Define nodos más grandes para reducir la probabilidad y la gravedad de los problemas causados por un gran número de relojes. Una mayor densidad de pods (menos nodos de gran tamaño) puede reducir el número de comprobaciones y mitigar la gravedad del problema. Para obtener más información, consulta la comparación de series de máquinas. |
| Número de secretos por clúster si el encriptado de secretos de la capa de aplicación está habilitado | Un clúster debe descifrar todos los secretos durante el inicio del clúster cuando el cifrado de secretos de la capa de aplicación está habilitado. Si almacenas más de 30.000 secretos, es posible que tu clúster se vuelva inestable durante el inicio o las actualizaciones, lo que provocaría interrupciones en las cargas de trabajo. | Almacena menos de 30.000 secretos cuando uses el encriptado de secretos de la capa de aplicación. Para obtener más información, consulta Encriptar secretos en la capa de aplicación. |
| Ancho de banda de registro por nodo |
Hay un límite en la cantidad máxima de registros que envía cada nodo a la API de Cloud Logging. El límite predeterminado varía entre 100 y 500 Kbps, en función de la carga. En los clústeres estándar, puedes aumentar el límite a 10 MiB implementando una configuración del agente de Logging de alto rendimiento. Si se supera este límite, es posible que se omitan entradas de registro. |
Configura Logging para que se mantenga dentro de los límites predeterminados o configura un agente de Logging de alto rendimiento. Para obtener más información, consulta Ajustar el rendimiento de los registros. |
| Grupos de nodos | Tener un gran número de grupos de nodos puede afectar a la latencia del autoescalado de la infraestructura, ya que aumenta el conjunto de nodos que se pueden añadir al clúster. Las funciones como la separación de cargas de trabajo o las clases de computación personalizadas aumentan el número de grupos de nodos. | Mantén el número de grupos de nodos por debajo de 200. |
| Límites de Backup for GKE |
Puedes usar Copia de seguridad de GKE para crear copias de seguridad de tus cargas de trabajo de GKE y restaurarlas. Backup for GKE está sujeto a límites que debes tener en cuenta al definir tus planes de copia de seguridad. |
Consulta los límites de Copia de seguridad de GKE. Si es posible que tu carga de trabajo supere estos límites, te recomendamos que crees varios planes de copias de seguridad para particionar tu copia de seguridad y no superar los límites. |
| Límites de Config Connector |
Puedes usar Config Connector para gestionar recursos de Trusted Cloud mediante Kubernetes. Config Connector tiene dos modos de funcionamiento:
|
Para obtener información sobre los límites de recursos, consulta las directrices de escalabilidad de Config Controller. Para obtener información sobre cómo gestionar un gran número de recursos, consulta las prácticas recomendadas de Config Connector. |