Prácticas recomendadas para distribuir cargas de trabajo de GKE en varios proyectos de Google Cloud
Para definir mejor la estructura de tu proyecto Google Cloud y la distribución de cargas de trabajo de GKE, según tus requisitos empresariales, te recomendamos que consideres las siguientes acciones de diseño y planificación:
- Sigue las instrucciones en Elige una jerarquía de recursos para tu Google Cloud zona de destino para tomar decisiones iniciales sobre la estructura de tu organización en carpetas y proyectos. Google Cloud recomienda usar elementos de jerarquía de recursos, como carpetas y proyectos, para dividir la carga de trabajo según tus propios límites organizacionales o políticas de acceso.
- Considera 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 estas recomendaciones y ajustar las cuotas de proyectos para cargas de trabajo grandes. Para la mayoría de las cargas de trabajo, deberías poder alcanzar cuotas más altas y necesarias en un solo proyecto. Esto significa que las cuotas no deben ser el controlador principal para dividir la carga de trabajo entre varios proyectos. Mantener las cargas de trabajo en una cantidad menor de proyectos simplifica la administración de las cuotas y cargas de trabajo.
- Considera si planeas ejecutar cargas de trabajo muy grandes (escalamiento de cientos de miles de CPU o más). En ese caso, dividir la carga de trabajo en varios proyectos puede aumentar la disponibilidad de los recursos de la nube (como CPU o GPU). Esto es posible debido a la configuración optimizada de la virtualización de la zona. En esos casos, comunícate con tu administrador de cuentas para obtener asistencia y recomendaciones especiales.
Prácticas recomendadas a fin de ajustar las cuotas para cargas de trabajo grandes de GKE
En esta sección, se describen los lineamientos para ajustar las cuotas de los recursos de Google Cloudque usan las cargas de trabajo de GKE. Ajusta las cuotas para tus proyectos en función de los siguientes lineamientos. Para obtener información sobre cómo administrar tu cuota con la consola de Google Cloud , consulta Visualiza y administra cuotas.
Cuotas y prácticas recomendadas de Compute Engine
Los clústeres de GKE, que se ejecutan en modo Autopilot y Estándar, usan recursos de Compute Engine para ejecutar tus cargas de trabajo. A diferencia de los recursos del plano de control de Kubernetes que administra Google Cloudde forma interna, puedes administrar y evaluar las cuotas de Compute Engine que usan tus flujos de trabajo.
Las cuotas de Compute Engine, tanto para recursos como para API, son compartidas por todos los clústeres de GKE alojados en el mismo proyecto y la misma región. Las mismas cuotas también se comparten con otros recursos de Compute Engine (no relacionados con GKE) (como instancias de VM independientes o grupos de instancias).
Los valores de cuota predeterminados pueden admitir cientos de nodos trabajadores y requieren ajuste 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 los clústeres de GKE tengan recursos suficientes. También debes considerar las futuras necesidades de recursos cuando evalúes o ajustes los valores de la cuota.
Cuotas para recursos de Compute Engine que usan los nodos trabajadores de GKE
En la siguiente tabla, se enumeran las cuotas de recursos para los recursos más comunes de Compute Engine que usan los nodos trabajadores de GKE. Estas cuotas se configuran por proyecto y por región. Las cuotas deben abarcar el tamaño máximo combinado de los nodos trabajadores de GKE que usa tu carga de trabajo y otros recursos de Compute Engine no relacionados con GKE.
| Cuota de recursos | Descripción |
|---|---|
| CPU | Cantidad de CPU que usan todos los nodos trabajadores de todos los clústeres. |
| Tipo de CPU | Cantidad de cada tipo específico de CPU que usan todos los nodos trabajadores de todos los clústeres. |
| Instancias de VM | Cantidad de todos los nodos trabajadores. Esta cuota se calcula de forma automática como 10 veces la cantidad de CPU. |
| Instancias por red de VPC | Cantidad de todos los nodos trabajadores conectados a la red de VPC. |
| Persistent Disk estándar (GB) | Tamaño total de los discos de arranque persistentes estándar conectados a todos los nodos trabajadores. |
| Persistent Disk SSD (GB) | Tamaño total de los discos de arranque persistentes SSD conectados a todos los nodos trabajadores. |
| Local SSD (GB) | Tamaño total de los discos efímeros SSD locales conectados a todos los nodos trabajadores. |
Asegúrate de ajustar las cuotas que usan los recursos que la carga de trabajo podría requerir, como GPU, direcciones IP o recursos interrumpibles.
Cuotas para llamadas a la API de Compute Engine
Los clústeres grandes o escalables requieren una mayor cantidad de llamadas a la API de Compute Engine. GKE realiza estas llamadas a la API de Compute Engine durante actividades como las siguientes:
- Verificación del estado de los recursos de procesamiento.
- Adición los nodos nuevos al clúster o eliminación de los nodos nuevos del clúster.
- Adición o eliminación de grupos de nodos nuevos.
- Etiquetado periódico de los recursos.
Cuando planifiques la arquitectura del clúster de gran tamaño, te recomendamos que hagas lo siguiente:
- Observa el consumo de cuota histórico.
- Ajusta las cuotas según sea necesario y mantén un búfer razonable. Puedes consultar las siguientes prácticas recomendadas como punto de partida y ajustar las cuotas según las necesidades de la carga de trabajo.
- Dado que las cuotas se configuran por región, ajústalas solo en las regiones en las que planeas ejecutar cargas de trabajo grandes.
En la siguiente tabla, se muestra una lista de cuotas para las llamadas a la API de Compute Engine. Estas cuotas se configuran por proyecto, de forma independiente para 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 y por región | GKE usa estas llamadas para realizar varias verificaciones en el estado de los distintos recursos de procesamiento. |
Para proyectos y regiones con varios cientos de nodos dinámicos, ajusta este valor a 3,500. Para proyectos y regiones con varios miles de nodos altamente dinámicos, ajusta este valor a 6,000. |
| Solicitudes de lectura por región por minuto | GKE usa estas llamadas para supervisar el estado de las instancias de VM (nodos). |
Para proyectos y regiones con varios cientos de nodos, ajusta este valor a 12,000. Para proyectos y regiones con miles de nodos, ajusta este valor a 20,000. |
| Solicitudes de lista por minuto, por región | GKE usa estas llamadas para supervisar el estado de los grupos de instancias (grupos de nodos). |
Para los proyectos y las regiones con varios cientos de nodos dinámicos, no cambies el valor predeterminado, ya que es suficiente. Para proyectos y regiones con miles de nodos altamente dinámicos, en varios grupos de nodos, ajusta este valor a 2,500. |
| Solicitudes de referentes de la lista de instancias por minuto, por región | GKE usa estas llamadas para obtener información sobre las instancias de VM (nodos) en ejecución. |
Para proyectos y regiones con miles de nodos altamente dinámicos, ajusta este valor a 6,000. |
| Solicitudes de lectura de operaciones por minuto, por región | GKE usa estas llamadas para obtener información sobre las operaciones en curso de la API de Compute Engine. |
Para proyectos y regiones con miles de nodos altamente dinámicos, ajusta este valor a 3,000. |
Cuotas y prácticas recomendadas de la API de Cloud Logging y la API de Cloud Monitoring
Según la configuración del clúster, las cargas de trabajo grandes que se ejecutan en los clústeres de GKE pueden generar un gran volumen de información de diagnóstico. Cuando se superan las cuotas de la API de Cloud Logging o de la API de Cloud Monitoring, es posible que se pierdan los datos de registro y supervisión. Te recomendamos configurar la verbosidad de los registros y ajustar las cuotas de la API de Cloud Logging y la API de Cloud Monitoring para capturar información de diagnóstico generada. Managed Service para Prometheus consume cuotas de Cloud Monitoring.
Debido a que cada carga de trabajo es diferente, te recomendamos que hagas lo siguiente:
- Observa el consumo de cuota histórico.
- Ajusta las cuotas o ajusta la configuración de registros y supervisión según sea necesario. Mantén un búfer razonable para los problemas inesperados.
En la siguiente tabla, se enumeran las cuotas de las API de Cloud Logging y las llamadas a las API de Cloud Monitoring. Estas cuotas se configuran por proyecto y se comparten en todos los clústeres de GKE alojados en el mismo proyecto.
| Servicio | Cuota | Descripción | Prácticas recomendadas |
|---|---|---|---|
| API de Cloud Logging | Solicitudes de escritura por minuto | GKE usa esta cuota cuando agrega entradas a los archivos de registro almacenados en Cloud Logging. |
La tasa de inserción de registros depende de la cantidad de registros que generan los Pods en tu clúster. Aumenta tu cuota según la cantidad de Pods, la verbosidad del registro de aplicaciones y la configuración de registros. Para obtener más información, consulta Administra los registros de GKE. |
| API de Cloud Monitoring | Solicitudes de transferencia de series temporales por minuto |
GKE usa esta cuota cuando envía métricas de Prometheus a Cloud Monitoring:
|
Supervisa y ajusta esta cuota según corresponda. Para obtener más información, consulta Administra las métricas de GKE. |
Cuota y prácticas recomendadas para los nodos de GKE
GKE admite los siguientes límites:
- Hasta 15,000 nodos en un solo clúster con la cuota predeterminada establecida en 5,000 nodos. Esta cuota se establece 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 planeas escalar tu clúster a más de 5,000 nodos, realiza los siguientes pasos:
- Identifica el clúster que deseas escalar más allá de los 5,000 nodos.
- Asegúrate de que la carga de trabajo permanezca dentro de los límites del clúster y las cuotas de GKE después del escalamiento.
- Asegúrate de aumentar las cuotas de Compute Engine según sea necesario para la carga de trabajo escalada.
- Asegúrate de que el tipo de disponibilidad de tu clúster sea regional y que tu clúster use Private Service Connect.
- Para solicitar un aumento de la cuota para la cantidad de nodos por clúster, comunícate con Atención al cliente de Cloud. El equipo de GKE se comunicará contigo para garantizar que tu carga de trabajo siga las prácticas recomendadas de escalabilidad y esté lista para escalar más allá de 5,000 nodos en un solo clúster.
Prácticas recomendadas para evitar otros límites en cargas de trabajo grandes
Límite de la cantidad de clústeres que usan intercambio de tráfico entre redes de VPC por red y por ubicación
Puedes crear un máximo de 75 clústeres que usen el intercambio de tráfico entre redes de VPC en la misma red de VPC por ubicación (las zonas y las regiones se tratan como ubicaciones separadas). Los intentos de crear clústeres adicionales por encima del límite fallarán con 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 intercambio de tráfico entre redes de VPC para proporcionar comunicación interna entre el servidor de la API de Kubernetes (administrado por Google) y los nodos privados que solo tienen direcciones internas.
Para resolver este problema, puedes usar clústeres que usen la conectividad de Private Service Connect (PSC). Los clústeres con conectividad PSC proporcionan el mismo aislamiento que un clúster que usa el intercambio de tráfico entre redes de VPC, sin la limitación de 75 clústeres. Los clústeres con conectividad de PSC no usan el intercambio de tráfico entre redes de VPC y no se ven afectados por el límite de la cantidad de intercambios de tráfico de VPC.
Puedes usar las instrucciones proporcionadas en Reutilización del intercambio de tráfico entre redes de VPC para identificar si tus clústeres usan el intercambio de tráfico entre redes de VPC.
Para evitar alcanzar el límite mientras creas clústeres nuevos, sigue estos pasos:
- Asegúrate de que tu clúster use PSC.
- Configura el aislamiento para que los grupos de nodos se hagan privados con el parámetro
enable-private-nodesen cada grupo de nodos. - De forma opcional, configura el aislamiento para el plano de control mediante el parámetro
enable-private-endpointa nivel del clúster. Para obtener más información, consulta Cómo personalizar el aislamiento de la red.
También puedes comunicarte con el Google Cloud equipo de asistencia al cliente para aumentar el límite de 75 clústeres del intercambio de tráfico entre redes de VPC. Estas solicitudes se evalúan caso por caso y, cuando es posible aumentar el límite, se aplica un aumento de un solo dígito.
Optimiza la escalabilidad y la confiabilidad 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 confiabilidad de la conexión en entornos de latencia alta o tráfico alto.
Beneficios de HTTP/2
Reduce la cantidad de conexiones: HTTP/2 te permite enviar muchas solicitudes y recibir muchas respuestas a través de una sola conexión. Esto reduce la carga en los componentes del sistema, como los balanceadores de cargas, los proxies y las puertas de enlace 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 descarta paquetes o experimenta una latencia alta, es posible que afecte todas las solicitudes realizadas en esa conexión, lo que puede causar demoras 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 manera, lo que hace que el rendimiento sea más predecible.
Incluye funciones integradas para mantener la confiabilidad de las conexiones:
Control de flujo: El control de flujo ayuda a administrar 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: Los marcos de ping son señales ligeras que verifican si una conexión sigue activa. Estos indicadores ayudan a mantener conexiones persistentes y a evitar las conexiones interrumpidas causadas por sistemas intermedios (como firewalls o proxies) que podrían cerrar las conexiones inactivas.
En HTTP/1.1, las conexiones pueden interrumpirse de forma inesperada si no hay tráfico durante un período. Esta situación es especialmente común cuando los firewalls o los proxies cierran las conexiones inactivas para liberar recursos. En HTTP/2, los tramas ping mantienen activas las conexiones verificando periódicamente su estado.
Multiplexación: En HTTP/1.1, cuando se envían varias solicitudes al mismo tiempo con conexiones separadas, el orden en el que se reciben las respuestas puede causar problemas si una solicitud depende de otra. Por ejemplo, si una solicitud se completa primero, pero otra tiene una demora de red, el resultado podría ser una respuesta incorrecta o desordenada. Este problema puede causar 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 garantizar que las respuestas estén alineadas correctamente.
Prácticas recomendadas para usar HTTP/2
- Usa HTTP/2 para las aplicaciones que manejan un gran volumen de tráfico o necesitan comunicación de baja latencia.
- Configura keepalives a nivel de la aplicación para mantener las conexiones abiertas. Para obtener más información, consulta Cómo funcionan las conexiones.
- Supervisa tu tráfico para asegurarte de que use HTTP/2.
Para obtener más información, consulta Compatibilidad con HTTP/2 en Cloud Load Balancing.
Próximos pasos
- Mira nuestros álbumes sobre la compilación de clústeres grandes de GKE.