En esta página se describen las prácticas recomendadas que puedes seguir al gestionar cargas de trabajo grandes en varios clústeres de GKE. Estas prácticas recomendadas abarcan consideraciones para distribuir cargas de trabajo en varios proyectos y ajustar las cuotas necesarias.
Prácticas recomendadas para distribuir cargas de trabajo de GKE en varios Google Cloud proyectos
Para definir mejor la estructura de tu proyecto y la distribución de las cargas de trabajo de GKE en función de tus requisitos empresariales, te recomendamos que tengas en cuenta las siguientes acciones de diseño y planificación: Google Cloud
- Sigue las directrices de la sección Decidir una jerarquía de recursos para tu Google Cloud zona de aterrizaje para tomar las decisiones iniciales sobre la estructura de tu organización de carpetas y proyectos. Google Cloud Te recomendamos que uses elementos de la jerarquía de recursos como carpetas y proyectos para dividir tu carga de trabajo en función de los límites de tu organización o de las políticas de acceso.
- Ten en cuenta si necesitas dividir tus cargas de trabajo debido a las cuotas de los proyectos. Google Cloud usa cuotas por proyecto para restringir el uso de recursos compartidos. Debes seguir las recomendaciones que se describen a continuación y ajustar las cuotas de proyecto para cargas de trabajo grandes. En la mayoría de las cargas de trabajo, deberías poder alcanzar las cuotas más altas necesarias en un solo proyecto. Esto significa que las cuotas no deben ser el factor principal para dividir tu carga de trabajo entre varios proyectos. Si mantienes tus cargas de trabajo en un número menor de proyectos, se simplificará la administración de tus cuotas y cargas de trabajo.
- Ten en cuenta si tienes previsto ejecutar cargas de trabajo muy grandes (con cientos de miles de CPUs o más). En ese caso, dividir la carga de trabajo en varios proyectos puede aumentar la disponibilidad de recursos en la nube (como CPUs o GPUs). Esto es posible gracias a la configuración optimizada de la virtualización de zonas. En estos casos, póngase en contacto con su gestor de cuentas para recibir asistencia y recomendaciones especiales.
Prácticas recomendadas para ajustar las cuotas de cargas de trabajo grandes de GKE
En esta sección se describen las directrices para ajustar las cuotas de los Google Cloud recursos que usan las cargas de trabajo de GKE. Ajusta las cuotas de tus proyectos siguiendo las directrices que se indican a continuación. Para saber cómo gestionar tu cuota con la consola Google Cloud , consulta Ver y gestionar cuotas.
Cuotas y prácticas recomendadas de Compute Engine
Los clústeres de GKE, que se ejecutan en los modos Autopilot y Standard, usan recursos de Compute Engine para ejecutar tus cargas de trabajo. A diferencia de los recursos del plano de control de Kubernetes, que gestiona internamente Google Cloud, puedes gestionar y evaluar las cuotas de Compute Engine que usan tus flujos de trabajo.
Las cuotas de Compute Engine, tanto de recursos como de APIs, se comparten entre todos los clústeres de GKE alojados en el mismo proyecto y región. Las mismas cuotas también se comparten con otros recursos de Compute Engine que no están relacionados con GKE (como instancias de VM independientes o grupos de instancias).
Los valores de cuota predeterminados pueden admitir varios cientos de nodos de trabajador y requieren ajustes para cargas de trabajo más grandes. Sin embargo, como administrador de la plataforma, puedes ajustar las cuotas de Compute Engine de forma proactiva para asegurarte de que tus clústeres de GKE tengan suficientes recursos. También debes tener en cuenta las necesidades de recursos futuras al evaluar o ajustar los valores de las cuotas.
Cuotas de recursos de Compute Engine usados por los nodos de trabajador de GKE
En la siguiente tabla se indican las cuotas de recursos de los recursos de Compute Engine más habituales que utilizan los nodos de trabajador de GKE. Estas cuotas se configuran por proyecto y por región. Las cuotas deben cubrir el tamaño combinado máximo de los nodos de trabajador de GKE que usa tu carga de trabajo, así como otros recursos de Compute Engine que no estén relacionados con GKE.
| Cuota de recursos | Descripción |
|---|---|
| CPUs | Número de CPUs usadas por todos los nodos de trabajo de todos los clústeres. |
| Tipo de CPUs | Número de cada tipo específico de CPU que usan todos los nodos de trabajo de todos los clústeres. |
| Instancias de VM | Número de todos los nodos de trabajo. Esta cuota se calcula automáticamente como 10 veces el número de CPUs. |
| Instancias por red de VPC | Número de todos los nodos de trabajador conectados a la red de VPC. |
| Disco persistente estándar (GB) | Tamaño total de los discos de arranque persistentes estándar conectados a todos los nodos de trabajador. |
| Disco persistente SSD (GB) | Tamaño total de los discos de arranque persistentes SSD conectados a todos los nodos de trabajador. |
| SSD local (GB) | Tamaño total de los discos efímeros SSD locales vinculados a todos los nodos de trabajador. |
Asegúrate de ajustar también las cuotas que usan los recursos que tu carga de trabajo pueda necesitar, como GPUs, direcciones IP o recursos de carácter preventivo.
Cuotas de llamadas a la API de Compute Engine
Los clústeres grandes o escalables requieren un mayor número de llamadas a la API de Compute Engine. GKE hace estas llamadas a la API de Compute Engine durante actividades como las siguientes:
- Comprobando el estado de los recursos de computación.
- Añadir o quitar nodos nuevos del clúster.
- Añadir o quitar grupos de nodos.
- Etiquetado periódico de recursos.
Cuando planifiques la arquitectura de tu clúster de gran tamaño, te recomendamos que hagas lo siguiente:
- Consulta el historial de consumo de cuota.
- Ajusta las cuotas según sea necesario, pero manteniendo un margen razonable. Puedes consultar las siguientes recomendaciones de prácticas recomendadas como punto de partida y ajustar las cuotas en función de las necesidades de tu carga de trabajo.
- Como las cuotas se configuran por región, solo debes ajustar las cuotas en las regiones en las que tengas previsto ejecutar cargas de trabajo grandes.
En la siguiente tabla se indican las cuotas de las llamadas a la API de Compute Engine. Estas cuotas se configuran por proyecto, de forma independiente en cada región. Las cuotas se comparten entre todos los clústeres de GKE alojados en el mismo proyecto y en la misma región.
| Cuota de API | Descripción | Prácticas recomendadas |
|---|---|---|
| Consultas por minuto por región | GKE usa estas llamadas para realizar varias comprobaciones en el estado de los distintos recursos de computación. |
En los proyectos y las regiones con varios cientos de nodos dinámicos, ajusta este valor a 3500. En el caso de los proyectos y las regiones con varios miles de nodos muy dinámicos, ajusta este valor a 6000. |
| Solicitudes de lectura por minuto y región | GKE usa estas llamadas para monitorizar el estado de las instancias de VM (nodos). |
En los proyectos y las regiones con varios cientos de nodos, ajusta este valor a 12.000. En los proyectos y las regiones con miles de nodos, ajusta este valor a 20.000. |
| Solicitudes de lista por minuto y región | GKE usa estas llamadas para monitorizar el estado de los grupos de instancias (grupos de nodos). |
En los proyectos y las regiones con varios cientos de nodos dinámicos, no cambie el valor predeterminado, ya que es suficiente. En proyectos y regiones con miles de nodos muy dinámicos en varios grupos de nodos, ajusta este valor a 2500. |
| Solicitudes de referentes de la lista de instancias por minuto y región | GKE usa estas llamadas para obtener información sobre las instancias de VM (nodos) en ejecución. |
En los proyectos y las regiones con miles de nodos muy dinámicos, ajusta este valor a 6000. |
| Solicitudes de lectura de operaciones por minuto y región | GKE usa estas llamadas para obtener información sobre las operaciones de la API Compute Engine en curso. |
En los proyectos y las regiones con miles de nodos muy dinámicos, ajusta este valor a 3000. |
Cuotas y prácticas recomendadas de las APIs Cloud Logging y Cloud Monitoring
En función de la configuración de tu clúster, las cargas de trabajo grandes que se ejecutan en clústeres de GKE pueden generar un gran volumen de información de diagnóstico. Si se superan las cuotas de las APIs Cloud Logging o Cloud Monitoring, es posible que se pierdan los datos de registro y monitorización. Te recomendamos que configures la verbosidad de los registros y que ajustes las cuotas de la API Cloud Logging y de la API Cloud Monitoring para registrar la información de diagnóstico generada. Managed Service for Prometheus consume cuotas de Cloud Monitoring.
Como cada carga de trabajo es diferente, te recomendamos que hagas lo siguiente:
- Consulta el historial de consumo de cuota.
- Ajusta las cuotas o la configuración de registro y monitorización según sea necesario. Mantén un margen razonable para los problemas inesperados.
En la siguiente tabla se indican las cuotas de llamadas a las APIs de Cloud Logging y Cloud Monitoring. Estas cuotas se configuran por proyecto y se comparten entre todos los clústeres de GKE alojados en el mismo proyecto.
| Servicio | Cuota | Descripción | Prácticas recomendadas |
|---|---|---|---|
| API de registro en la nube | Solicitudes de escritura por minuto | GKE usa esta cuota al añadir entradas a los archivos de registro almacenados en Cloud Logging. |
La tasa de inserción de registros depende de la cantidad de registros generados por los pods de tu clúster. Aumenta tu cuota en función del número de pods, la verbosidad del registro de aplicaciones y la configuración del registro. Para obtener más información, consulta cómo gestionar los registros de GKE. |
| API de Cloud Monitoring | Solicitudes de ingestión de series temporales por minuto |
GKE usa esta cuota al enviar métricas de Prometheus a Cloud Monitoring:
|
Monitoriza y ajusta esta cuota según sea necesario. Para obtener más información, consulta Gestionar métricas de GKE. |
Cuota de nodos de GKE y prácticas recomendadas
GKE admite los siguientes límites:
- Hasta 15.000 nodos en un único clúster con una cuota predeterminada de 5000 nodos. Esta cuota se define por separado para cada clúster de GKE y no por proyecto, como otras cuotas.
- En la versión 1.31 y posteriores, GKE admite clústeres grandes de hasta 65.000 nodos.
Si tienes previsto ampliar tu clúster a más de 5000 nodos, sigue estos pasos:
- Identifica el clúster que quieres escalar a más de 5000 nodos.
- Asegúrate de que tu carga de trabajo se mantenga dentro de los límites de los clústeres y las cuotas de GKE después de escalarla.
- Asegúrate de aumentar las cuotas de Compute Engine según sea necesario para tu carga de trabajo escalada.
- Comprueba que el tipo de disponibilidad de tu clúster sea regional y que el clúster use Private Service Connect.
- Para solicitar un aumento de la cuota del número de nodos por clúster, ponte en contacto con el equipo de Atención al Cliente de Cloud. El equipo de GKE se pondrá en contacto contigo para asegurarse de que tu carga de trabajo sigue las prácticas recomendadas de escalabilidad y está lista para escalar a más de 5000 nodos en un solo clúster.
Prácticas recomendadas para evitar otros límites en cargas de trabajo grandes
Límite del número de clústeres que usan el emparejamiento entre redes de VPC por red y por ubicación
Puedes crear un máximo de 75 clústeres que usen el emparejamiento entre redes de VPC en la misma red de VPC por ubicación (las zonas y las regiones se consideran ubicaciones independientes). Si se intenta crear más clústeres por encima del límite, se producirá un error similar al siguiente:
CREATE operation failed. Could not trigger cluster creation:
Your network already has the maximum number of clusters: (75) in location us-central1.
Los clústeres de GKE con nodos privados creados antes de la versión 1.29 usan el peering de redes de VPC para proporcionar comunicación interna entre el servidor de la API de Kubernetes (gestionado por Google) y los nodos privados que solo tienen direcciones internas.
Para solucionar este problema, puedes usar clústeres que utilicen la conectividad de Private Service Connect (PSC). Los clústeres con conectividad PSC proporcionan el mismo aislamiento que un clúster que usa el emparejamiento entre redes de VPC, pero sin la limitación de 75 clústeres. Los clústeres con conectividad PSC no usan el emparejamiento entre redes de VPC y no se ven afectados por el límite del número de emparejamientos entre redes de VPC.
Puedes usar las instrucciones que se proporcionan en Reutilización del emparejamiento entre redes de VPC para identificar si tus clústeres usan el emparejamiento entre redes de VPC.
Para no alcanzar el límite al crear clústeres, siga estos pasos:
- Asegúrate de que tu clúster use PSC.
- Configura el aislamiento de los grupos de nodos para que sean privados mediante el parámetro
enable-private-nodesen cada grupo de nodos. - Si quieres, configura el aislamiento del plano de control mediante el parámetro
enable-private-endpointa nivel de clúster. Para obtener más información, consulta Personalizar el aislamiento de la red.
También puedes ponerte en contacto con el Google Cloud equipo de Asistencia para aumentar el límite de 75 clústeres mediante el emparejamiento entre redes de VPC. Estas solicitudes se evalúan caso por caso y, cuando es posible aumentar el límite, se aplica un incremento de un solo dígito.
Optimizar la escalabilidad y la fiabilidad con HTTP/2
Para ejecutar cargas de trabajo a gran escala en GKE, usa HTTP/2 en lugar de HTTP/1.1. HTTP/2 mejora el rendimiento y la fiabilidad de las conexiones en entornos con mucho tráfico o latencia alta.
Ventajas de HTTP/2
Reduce el número de conexiones: HTTP/2 te permite enviar muchas solicitudes y recibir muchas respuestas a través de una sola conexión. De esta forma, se reduce la carga de los componentes del sistema, como los equilibradores de carga, los proxies y las pasarelas NAT.
Mejora la coherencia del rendimiento: con HTTP/1.1, cada solicitud suele necesitar su propia conexión. Si una conexión tiene problemas, puede retrasar o interrumpir la solicitud. Por ejemplo, si una conexión TCP pierde paquetes o experimenta una latencia alta, puede afectar a todas las solicitudes realizadas en esa conexión, lo que puede provocar retrasos o errores en la aplicación. Con HTTP/2, varias solicitudes comparten la misma conexión, por lo que los problemas de red afectan a todas las solicitudes de la misma forma, lo que hace que el rendimiento sea más predecible.
Incluye funciones integradas para que las conexiones sean fiables:
Control de flujo: ayuda a gestionar la cantidad de datos que se envían a la vez. Evita que los remitentes sobrecarguen a los destinatarios y ayuda a evitar la congestión de la red.
Marcos de ping: son señales ligeras que comprueban si una conexión sigue activa. Estas señales ayudan a mantener las conexiones persistentes y a evitar que se interrumpan debido a sistemas intermedios (como cortafuegos o proxies) que pueden cerrar las conexiones inactivas.
En HTTP/1.1, las conexiones pueden interrumpirse de forma inesperada si no hay tráfico durante un periodo. Esta situación es especialmente habitual cuando los cortafuegos o los proxies cierran las conexiones inactivas para liberar recursos. En HTTP/2, los marcos de ping mantienen las conexiones activas comprobando periódicamente el estado de la conexión.
Multiplexing: en HTTP/1.1, cuando se envían varias solicitudes al mismo tiempo mediante conexiones independientes, el orden en el que se reciben las respuestas puede provocar problemas si una solicitud depende de otra. Por ejemplo, si una solicitud se completa primero, pero otra tiene un retraso en la red, el resultado podría ser una respuesta incorrecta o desordenada. Este problema puede provocar una condición de carrera. HTTP/2 evita esto multiplexando todas las solicitudes a través de una sola conexión, lo que ayuda a asegurarse de que las respuestas estén correctamente alineadas.
Prácticas recomendadas para usar HTTP/2
- Usa HTTP/2 en aplicaciones que gestionen un gran volumen de tráfico o que necesiten una comunicación de baja latencia.
- Configura keepalives a nivel de aplicación para mantener las conexiones abiertas. Para obtener más información, consulta Cómo funcionan las conexiones.
- Monitoriza tu tráfico para asegurarte de que usa HTTP/2.
Para obtener más información, consulta el artículo sobre la compatibilidad con HTTP/2 en Cloud Load Balancing.
Siguientes pasos
- Consulta nuestros episodios sobre cómo crear clústeres grandes de GKE.