Prácticas recomendadas para ejecutar aplicaciones de Kubernetes de coste optimizado en GKE

Last reviewed 2024-09-11 UTC

En este documento se describen las funciones y opciones de Google Kubernetes Engine (GKE), así como las prácticas recomendadas para ejecutar aplicaciones de coste optimizado en GKE y aprovechar la elasticidad que ofrece Google Cloud. En este documento se da por hecho que conoces Kubernetes, Google Cloud, GKE y el autoescalado.

Introducción

A medida que Kubernetes se va adoptando de forma generalizada, cada vez más empresas y proveedores de plataforma como servicio (PaaS) y software como servicio (SaaS) usan clústeres de Kubernetes multiinquilino para sus cargas de trabajo. Esto significa que un solo clúster puede ejecutar aplicaciones que pertenezcan a diferentes equipos, departamentos, clientes o entornos. La arquitectura multi-tenant de Kubernetes permite a las empresas gestionar unos pocos clústeres grandes en lugar de varios más pequeños, lo que ofrece ventajas como un uso adecuado de los recursos, un control de gestión simplificado y una menor fragmentación.

Con el tiempo, algunas de estas empresas con clústeres de Kubernetes de rápido crecimiento empiezan a experimentar un aumento desproporcionado de los costes. Esto ocurre porque las empresas tradicionales que adoptan soluciones basadas en la nube, como Kubernetes, no tienen desarrolladores ni operadores con experiencia en la nube. Esta falta de preparación para la nube provoca que las aplicaciones se vuelvan inestables durante el autoescalado (por ejemplo, la volatilidad del tráfico durante un periodo normal del día), los picos repentinos o los picos (como los anuncios de televisión o los eventos de escalado máximo, como el Black Friday y el Ciberlunes). Para intentar "solucionar" el problema, estas empresas suelen aprovisionar en exceso sus clústeres de la misma forma que lo hacían en un entorno no elástico. El sobreaprovisionamiento da como resultado una asignación de CPU y memoria considerablemente mayor que la que usan las aplicaciones durante la mayor parte del día.

En este documento se describen las prácticas recomendadas para ejecutar cargas de trabajo de Kubernetes de coste optimizado en GKE. En el siguiente diagrama se describe este enfoque.

El enfoque para optimizar los costes de las aplicaciones de Kubernetes.

La base para crear aplicaciones optimizadas en cuanto a costes es difundir la cultura de ahorro de costes entre los equipos. Además de trasladar las conversaciones sobre los costes al principio del proceso de desarrollo, este enfoque te obliga a comprender mejor el entorno en el que se ejecutan tus aplicaciones (en este contexto, el entorno de GKE).

Para conseguir un coste bajo y la estabilidad de la aplicación, debes definir o ajustar correctamente algunas funciones y configuraciones (como el autoescalado, los tipos de máquina y la selección de región). Otro factor importante que debes tener en cuenta es el tipo de carga de trabajo, ya que, en función de este y de los requisitos de tu aplicación, tendrás que aplicar diferentes configuraciones para reducir aún más los costes. Por último, debes monitorizar tus gastos y crear medidas de protección para poder aplicar las prácticas recomendadas en las primeras fases del ciclo de desarrollo.

En la siguiente tabla se resumen los problemas que te ayuda a resolver GKE. Aunque te recomendamos que leas todo el documento, esta tabla muestra un mapa de lo que se incluye.

Reto Acción
Quiero ver cómo puedo ahorrar costes fácilmente en GKE. Selecciona la región adecuada, regístrate para obtener descuentos por uso comprometido y usa tipos de máquina E2.
Necesito entender mis costes de GKE. Observa tus clústeres de GKE y busca recomendaciones, y habilita la medición de uso de GKE
Quiero aprovechar al máximo la elasticidad de GKE para mis cargas de trabajo actuales. Consulta Herramienta de adaptación dinámica horizontal de pods y Herramienta de adaptación dinámica de clústeres, y descubre las prácticas recomendadas para Herramienta de adaptación dinámica y aprovisionamiento excesivo.
Quiero usar los tipos de máquinas más eficientes. Elige el tipo de máquina adecuado para tu carga de trabajo.
Muchos nodos de mi clúster están inactivos. Consulta las prácticas recomendadas para Cluster Autoscaler.
Necesito mejorar el ahorro de costes en mis trabajos por lotes. Consulta las prácticas recomendadas para las cargas de trabajo por lotes.
Necesito mejorar el ahorro de costes en mis cargas de trabajo de servicio. Consulta las prácticas recomendadas para servir cargas de trabajo.
No sé cómo dimensionar mis solicitudes de recursos de Pod. Usa Vertical Pod Autoscaler (VPA), pero ten en cuenta las prácticas recomendadas para combinar Horizontal Pod Autoscaler (HPA) y VPA.
Mis aplicaciones son inestables durante las actividades de escalado automático y mantenimiento. Prepara aplicaciones basadas en la nube para Kubernetes y descubre cómo funciona Metrics Server y cómo monitorizarlo.
¿Cómo puedo hacer que mis desarrolladores presten atención al uso de recursos de sus aplicaciones? Fomenta una cultura de ahorro de costes, considera la posibilidad de usar GKE Enterprise Policy Controller, diseña tu canalización de CI/CD para aplicar prácticas de ahorro de costes y usa cuotas de recursos de Kubernetes.
¿Qué más puedo hacer para reducir los costes de mi ecosistema? Revisa los clústeres de desarrollo pequeños, revisa tus estrategias de registro y monitorización y revisa el tráfico de salida entre regiones en clústeres regionales y multizonales.

Funciones y opciones de optimización de costes de GKE

Las aplicaciones de Kubernetes optimizadas para los costes dependen en gran medida del escalado automático de GKE. Para equilibrar el coste, la fiabilidad y el rendimiento del escalado en GKE, debes saber cómo funciona el autoescalado y qué opciones tienes. En esta sección se habla del autoescalado de GKE y de otras configuraciones útiles y optimizadas para los costes de las cargas de trabajo de servicio y por lotes.

Ajustar el autoescalado de GKE

El escalado automático es la estrategia que usa GKE para que los clientes paguen solo por lo que necesitan, minimizando el tiempo de actividad de la infraestructura.Google Cloud En otras palabras, el escalado automático ahorra costes de dos formas: 1) haciendo que las cargas de trabajo y su infraestructura subyacente se inicien antes de que aumente la demanda y 2) cerrándolas cuando la demanda disminuye.

En el siguiente diagrama se ilustra este concepto. En Kubernetes, las cargas de trabajo son aplicaciones en contenedores que se ejecutan en pods, y la infraestructura subyacente, que se compone de un conjunto de nodos, debe proporcionar suficiente capacidad de computación para ejecutar las cargas de trabajo.

El escalado automático ahorra costes de dos formas: 1) haciendo que las cargas de trabajo y su infraestructura subyacente se inicien antes de que aumente la demanda y 2) cerrándolas cuando la demanda disminuye.

Como se muestra en el siguiente diagrama, este entorno tiene cuatro dimensiones de escalabilidad. La carga de trabajo y la infraestructura se pueden escalar horizontalmente añadiendo y quitando pods o nodos, y se pueden escalar verticalmente aumentando y disminuyendo el tamaño de los pods o nodos.

Las cuatro dimensiones de escalabilidad de un entorno con costes optimizados.

GKE gestiona estos casos de autoescalado mediante funciones como las siguientes:

En el siguiente diagrama se ilustran estos casos.

Usar los escenarios de HPA, VPA, CA y aprovisionamiento automático de nodos.

En el resto de esta sección se describen estas funciones de escalado automático de GKE con más detalle y se explican otras configuraciones útiles y optimizadas para los costes de las cargas de trabajo de servicio y por lotes.

Herramienta de adaptación dinámica de grupo horizontal

La herramienta de adaptación dinámica horizontal de pods (HPA) se usa para escalar aplicaciones que se ejecutan en pods en función de métricas que expresan la carga. Puedes configurar el uso de la CPU u otras métricas personalizadas (por ejemplo, solicitudes por segundo). En resumen, HPA añade y elimina réplicas de pods, y es más adecuado para los trabajadores sin estado que pueden iniciarse rápidamente para reaccionar a los picos de uso y cerrarse correctamente para evitar la inestabilidad de la carga de trabajo.

El umbral de uso objetivo de HPA te permite personalizar cuándo se debe activar el escalado automáticamente.

Como se muestra en la imagen anterior, HPA requiere un umbral de utilización objetivo, expresado en porcentaje, que te permite personalizar cuándo se debe activar el escalado automáticamente. En este ejemplo, el uso de CPU objetivo es del 70%. Esto significa que tu carga de trabajo tiene un búfer de CPU del 30% para gestionar las solicitudes mientras se activan las nuevas réplicas. Un pequeño búfer evita que se produzcan aumentos de escala prematuros, pero puede sobrecargar tu aplicación durante los picos. Sin embargo, un búfer grande provoca un desperdicio de recursos, lo que aumenta los costes. El objetivo exacto es específico de la aplicación y debes tener en cuenta que el tamaño del búfer debe ser suficiente para gestionar las solicitudes durante dos o tres minutos durante un pico. Aunque garantices que tu aplicación puede iniciarse en cuestión de segundos, este tiempo adicional es necesario cuando Cluster Autoscaler añade nodos a tu clúster o cuando se limita el uso de pods debido a la falta de recursos.

Estas son las prácticas recomendadas para habilitar HPA en tu aplicación:

Para obtener más información, consulta Configurar un autoescalador de pods horizontal.

Herramienta de adaptación dinámica vertical de pods

A diferencia de HPA, que añade y elimina réplicas de pods para reaccionar rápidamente a los picos de uso, Vertical Pod Autoscaler (VPA) observa los pods a lo largo del tiempo y encuentra gradualmente los recursos óptimos de CPU y memoria que necesitan los pods. Configurar los recursos adecuados es importante para la estabilidad y la rentabilidad. Si los recursos de tu pod son demasiado pequeños, tu aplicación puede sufrir limitaciones o fallar debido a errores de falta de memoria. Si tus recursos son demasiado grandes, se desperdician y, por lo tanto, las facturas son más elevadas. VPA está diseñado para cargas de trabajo con y sin estado que no gestiona HPA o cuando no conoces las solicitudes de recursos de Pod adecuadas.

VPA detecta que un pod se ejecuta constantemente al límite y lo vuelve a crear con más recursos.

Como se muestra en la imagen anterior, VPA detecta que el pod se está ejecutando constantemente al límite y lo vuelve a crear con más recursos. También ocurre lo contrario cuando el pod se infrautiliza de forma constante: se activa una reducción.

El asistente de voz puede funcionar de tres formas distintas:

  • Desactivado: en este modo, también conocido como modo de recomendación, el VPA no aplica ningún cambio a tu Pod. Las recomendaciones se calculan y se pueden inspeccionar en el objeto VPA.
  • Inicial: VPA asigna solicitudes de recursos solo en la creación del pod y nunca las cambia después.
  • Automático: VPA actualiza las solicitudes de CPU y memoria durante el ciclo de vida de un pod. Es decir, el pod se elimina, se ajustan la CPU y la memoria, y se inicia un nuevo pod.

Si tienes previsto usar VPA, la práctica recomendada es empezar con el modo Desactivado para obtener recomendaciones de VPA. Asegúrate de que se ejecute durante 24 horas, o idealmente una semana o más, antes de obtener recomendaciones. Después, cuando te sientas seguro, puedes cambiar al modo Inicial o Automático.

Sigue estas prácticas recomendadas para habilitar el VPA en tu aplicación, ya sea en el modo Inicial o en el Automático:

Si estás pensando en usar el modo Automático, asegúrate de seguir estas prácticas:

Para obtener más información, consulta el artículo sobre cómo configurar el autoescalado de pods vertical.

Combinar HPA y VPA

La recomendación oficial es que no mezcles VPA y HPA en la CPU o en la memoria. Sin embargo, puedes combinarlos de forma segura cuando usas el modo de recomendación en VPA o métricas personalizadas en HPA, como las solicitudes por segundo. Cuando combines VPA con HPA, asegúrate de que tus implementaciones reciban suficiente tráfico, es decir, que se ejecuten de forma constante por encima del valor min-replicas de HPA. De esta forma, el asistente de voz puede entender las necesidades de recursos de tu Pod.

Para obtener más información sobre las limitaciones de VPA, consulta Limitaciones del autoescalado de pods vertical.

Herramienta de adaptación dinámica de clústeres

Cluster Autoscaler (CA) cambia automáticamente el tamaño de la infraestructura informática subyacente. CA proporciona nodos para los pods que no tienen un lugar donde ejecutarse en el clúster y elimina los nodos infrautilizados. CA está optimizado para el coste de la infraestructura. Es decir, si hay dos o más tipos de nodos en el clúster, la CA elige el menos caro que se ajuste a la demanda.

A diferencia de HPA y VPA, CA no depende de las métricas de carga. En su lugar, se basa en la simulación de la programación y en las solicitudes de pods declaradas. Te recomendamos que habilites CA siempre que uses HPA o VPA. De esta forma, si los escaladores automáticos de pods determinan que necesitas más capacidad, la infraestructura subyacente se ampliará en consecuencia.

CA añade y elimina automáticamente capacidad de computación para gestionar los picos de tráfico.

Como se muestra en estos diagramas, la CA añade y elimina automáticamente capacidad de computación para gestionar los picos de tráfico y ahorrarte dinero cuando tus clientes están durmiendo. Es una práctica recomendada definir un presupuesto de interrupción de pods (PDB) para todas tus aplicaciones. Es especialmente importante en la fase de reducción de la escala de la CA, cuando PDB controla el número de réplicas que se pueden desactivar a la vez.

Algunos pods no pueden reiniciarse con ningún escalador automático cuando provocan alguna interrupción temporal, por lo que el nodo en el que se ejecutan no se puede eliminar. Por ejemplo, los pods del sistema (como metrics-server y kube-dns) y los pods que usan almacenamiento local no se reiniciarán. Sin embargo, puedes cambiar este comportamiento definiendo PDBs para estos pods del sistema y configurando la anotación "cluster-autoscaler.kubernetes.io/safe-to-evict": "true" para los pods que usen almacenamiento local y que se puedan reiniciar de forma segura con el escalador automático. Además, plantéate ejecutar pods de larga duración que no se puedan reiniciar en un grupo de nodos independiente para que no bloqueen la reducción de otros nodos. Por último, consulta cómo analizar los eventos de CA en los registros para saber por qué una actividad de escalado concreta no se ha producido como se esperaba.

Si tus cargas de trabajo son resistentes a los reinicios involuntarios de los nodos y a las pérdidas de capacidad, puedes ahorrar más dinero creando un clúster o un grupo de nodos con máquinas virtuales de acceso puntual. Para que la CA funcione correctamente, las solicitudes de recursos de los pods deben ser lo suficientemente grandes para que el pod funcione con normalidad. Si las solicitudes de recursos son demasiado pequeñas, es posible que los nodos no tengan suficientes recursos y que tus pods fallen o tengan problemas durante el tiempo de ejecución.

A continuación, se resumen las prácticas recomendadas para habilitar el escalador automático de clústeres en tu clúster:

  • Usa HPA o VPA para autoescalar tus cargas de trabajo.
  • Asegúrate de seguir las prácticas recomendadas que se describen en el escalador automático de pods elegido.
  • Ajusta el tamaño de tu aplicación correctamente definiendo solicitudes y límites de recursos adecuados o usa VPA.
  • Define un PDB para tus aplicaciones.
  • Define un PDB para los pods del sistema que puedan bloquear la reducción. Por ejemplo, kube-dns. Para evitar interrupciones temporales en tu clúster, no definas PDB para los pods del sistema que solo tengan una réplica (como metrics-server).
  • Ejecuta los pods de corta duración y los pods que se pueden reiniciar en grupos de nodos independientes para que los pods de larga duración no bloqueen su reducción.
  • Evita el aprovisionamiento excesivo configurando nodos inactivos en tu clúster. Para ello, debes conocer tu capacidad mínima (en muchas empresas, es durante la noche) y definir el número mínimo de nodos en tus grupos de nodos para admitir esa capacidad.
  • Si necesitas capacidad adicional para gestionar las solicitudes durante los picos, utiliza los pods de pausa, que se explican en la sección Autoescalador y aprovisionamiento excesivo.

Para obtener más información, consulta Escalar automáticamente un clúster.

Aprovisionamiento automático de nodos

El aprovisionamiento automático de nodos (NAP) es un mecanismo de la herramienta de adaptación dinámica del clúster que añade automáticamente nuevos grupos de nodos y gestiona su tamaño en nombre del usuario. Sin el aprovisionamiento automático de nodos, GKE solo tiene en cuenta los nuevos nodos pertenecientes a los grupos de nodos creados por el usuario. Con el aprovisionamiento automático de nodos, GKE puede crear y eliminar grupos de nodos automáticamente.

El aprovisionamiento automático de nodos tiende a reducir el desperdicio de recursos creando dinámicamente grupos de nodos que se adaptan mejor a las cargas de trabajo programadas. Sin embargo, la latencia del escalado automático puede ser ligeramente superior cuando se tienen que crear grupos de nodos. Si tus cargas de trabajo son resistentes a los reinicios involuntarios de los nodos y a las pérdidas de capacidad, puedes reducir aún más los costes configurando la tolerancia de las máquinas virtuales de acceso puntual en tu pod.

Estas son las prácticas recomendadas para habilitar el aprovisionamiento automático de nodos:

  • Sigue todas las prácticas recomendadas de la herramienta de adaptación dinámica de clústeres.
  • Define los tamaños de recursos mínimos y máximos para evitar que NAP haga cambios significativos en tu clúster cuando tu aplicación no reciba tráfico.
  • Cuando uses la herramienta de adaptación dinámica horizontal de pods para servir cargas de trabajo, te recomendamos que reserves un margen de utilización objetivo ligeramente superior, ya que la negociación de perfil de aplicación puede aumentar la latencia del autoescalado en algunos casos.

Para obtener más información, consulta Usar el aprovisionamiento automático de nodos y Funciones no admitidas.

Adaptación dinámica y aprovisionamiento excesivo

Para controlar los costes, te recomendamos que habilites el escalador automático siguiendo las instrucciones de las secciones anteriores. No hay una configuración que se adapte a todos los escenarios posibles, por lo que debe ajustar la configuración de su carga de trabajo para asegurarse de que los escaladores automáticos respondan correctamente a los aumentos del tráfico.

Sin embargo, como se indica en la sección Herramienta de adaptación dinámica horizontal de pods, las ampliaciones pueden tardar un poco debido al aprovisionamiento de la infraestructura. Para visualizar esta diferencia en el tiempo y los posibles escenarios de ampliación, consulta la siguiente imagen.

Visualizar la diferencia de tiempo y los posibles escenarios de ampliación.

Cuando tu clúster tenga suficiente espacio para desplegar nuevos pods, se activará uno de los casos de aumento de la escala de la carga de trabajo. Es decir, si un nodo no ha desplegado nunca tu aplicación, debe descargar sus imágenes de contenedor antes de iniciar el pod (situación 1). Sin embargo, si el mismo nodo debe iniciar una nueva réplica de Pod de tu aplicación, el tiempo total de escalado aumenta se reduce porque no es necesario descargar ninguna imagen (situación 2).

Cuando tu clúster no tiene espacio suficiente para desplegar nuevos pods, se activa uno de los escenarios de escalado vertical de infraestructura y carga de trabajo. Esto significa que Cluster Autoscaler debe aprovisionar nuevos nodos e iniciar el software necesario antes de acercarse a tu aplicación (situación 1). Si usas el aprovisionamiento automático de nodos, es posible que se necesiten nuevos grupos de nodos en función de la carga de trabajo programada. En esta situación, el tiempo total de escalado vertical aumenta porque el autoescalador de clústeres tiene que aprovisionar nodos y grupos de nodos (situación 2).

En los casos en los que se necesite una nueva infraestructura, no sobrecargues demasiado el clúster. Es decir, debes aprovisionar en exceso, pero solo para reservar el búfer necesario para gestionar los picos de solicitudes previstos durante los aumentos de escala.

Hay dos estrategias principales para este tipo de aprovisionamiento excesivo:

  • Ajusta el objetivo de utilización de HPA. La siguiente ecuación es una forma sencilla y segura de encontrar un buen objetivo de CPU:

    (1 - buff)/(1 + perc)

    • buff es un búfer de seguridad que puedes configurar para evitar alcanzar el 100% de la CPU. Esta variable es útil porque, si se alcanza el 100% de la CPU, significa que la latencia del procesamiento de solicitudes es mucho mayor de lo habitual.
    • perc es el porcentaje de crecimiento del tráfico que esperas en dos o tres minutos.

    Por ejemplo, si prevés un aumento del 30% en tus solicitudes y quieres evitar alcanzar el 100% de la CPU definiendo un margen de seguridad del 10 %, la fórmula sería la siguiente:

    (1 - 0,1)/(1 + 0,3) = 0,69

  • Configurar pods de pausa. No se puede configurar el autoescalador de clústeres para que ponga en marcha los nodos por adelantado. En su lugar, puedes definir un objetivo de utilización de HPA para proporcionar un margen que ayude a gestionar los picos de carga. Sin embargo, si esperas picos grandes, puede que no sea suficiente con definir un objetivo de utilización de HPA pequeño o que resulte demasiado caro.

    Otra solución para este problema es usar la opción Pausar pódcasts. Los pods de pausa son implementaciones de baja prioridad que no hacen nada, salvo reservar espacio en el clúster. Cuando se programa un pod de prioridad alta, los pods en pausa se expulsan y el pod de prioridad alta ocupa su lugar inmediatamente. A continuación, se reprograman los pods de pausa desalojados y, si no hay espacio en el clúster, la herramienta de escalado automático de clústeres crea nuevos nodos para alojarlos. Es recomendable tener un solo pod de pausa por nodo. Por ejemplo, si utilizas 4 nodos de CPU, configura la solicitud de CPU de los pods de pausa con unos 3200 m.

Elegir el tipo de máquina adecuado

Además del autoescalado, hay otras configuraciones que pueden ayudarte a ejecutar aplicaciones de Kubernetes de coste optimizado en GKE. En esta sección se explica cómo elegir el tipo de máquina adecuado.

Spot VMs

Las máquinas virtuales de acceso puntual son instancias de VM de Compute Engine que no ofrecen garantías de disponibilidad. Las máquinas virtuales de acceso puntual son hasta un 91% más baratas que las máquinas virtuales de Compute Engine estándar, pero te recomendamos que las uses con precaución en los clústeres de GKE. Las máquinas virtuales de acceso puntual en GKE son las más adecuadas para ejecutar tareas tolerantes a fallos o por lotes, que son menos sensibles al carácter no garantizado y efímero de este tipo de máquinas. Las cargas de trabajo con estado y de servicio no deben usar Spot VMs a menos que prepares tu sistema y tu arquitectura para gestionar las restricciones de las Spot VMs.

Sea cual sea el tipo de carga de trabajo, debes tener en cuenta las siguientes restricciones:

  • Es posible que no se respete el presupuesto de interrupción de pods porque las VMs de acceso puntual se pueden apagar de forma involuntaria.
  • No se garantiza que tus pods se apaguen correctamente cuando la expropiación de nodos ignore el periodo de gracia de los pods.
  • GKE puede tardar varios minutos en detectar que el nodo se ha desalojado y que los pods ya no se están ejecutando, lo que retrasa la reprogramación de los pods en un nuevo nodo.

A partir de GKE 1.20, el cierre de nodos controlado se habilita de forma predeterminada para avisar a las cargas de trabajo en ejecución.

Las VMs de Spot no tienen disponibilidad garantizada, lo que significa que pueden agotarse fácilmente en algunas regiones. Para solucionar esta limitación, te recomendamos que definas un grupo de nodos de reserva sin VMs Spot. El autoescalador de clústeres da preferencia a las VMs de acceso puntual porque está optimizado para el coste de la infraestructura.

Para obtener más información, consulta los artículos Ejecutar cargas de trabajo tolerantes a fallos a un coste inferior con máquinas virtuales de acceso puntual, Ejecutar cargas de trabajo tolerantes a fallos a un coste inferior en pods de acceso puntual y Ejecutar aplicaciones web en GKE con máquinas virtuales de acceso puntual optimizadas para costes.

Tipos de máquinas E2

Los tipos de máquinas E2 (máquinas virtuales E2) son máquinas virtuales optimizadas para reducir costes que te permiten ahorrar un 31% en comparación con los tipos de máquinas N1. Las máquinas virtuales E2 son adecuadas para una amplia gama de cargas de trabajo, como servidores web, microservicios, aplicaciones esenciales para la empresa, bases de datos de tamaño pequeño o mediano y entornos de desarrollo.

Para obtener más información sobre las máquinas virtuales E2 y cómo se comparan con otrosGoogle Cloud tipos de máquinas, consulta Gestión dinámica de recursos basada en el rendimiento en máquinas virtuales E2 y Tipos de máquinas.

Selecciona la región adecuada

Cuando el coste es un factor limitante, es importante dónde ejecutes tus clústeres de GKE. Debido a muchos factores, el coste varía según la región de computación. Por lo tanto, asegúrate de ejecutar tu carga de trabajo en la opción menos costosa, pero en la que la latencia no afecte a tus clientes. Si tu carga de trabajo requiere copiar datos de una región a otra (por ejemplo, para ejecutar un trabajo por lotes), también debes tener en cuenta el coste de mover estos datos.

Para obtener más información sobre cómo elegir la región adecuada, consulta las prácticas recomendadas para seleccionar regiones de Compute Engine.

Registrarse para obtener descuentos por compromiso de uso

Si tienes intención de quedarte con Google Cloud durante unos años, te recomendamos que compres descuentos por uso confirmado para obtener precios muy reducidos en el uso de máquinas virtuales. Cuando firmas un contrato de uso confirmado, compras recursos de computación a un precio con descuento (hasta un 70% de descuento) a cambio de comprometerte a pagar por esos recursos durante uno o tres años. Si no sabes cuántos recursos debes comprometer, consulta tu uso mínimo de computación (por ejemplo, durante la noche) y compromete el pago de esa cantidad.

Para obtener más información sobre los precios por uso confirmado de los diferentes tipos de máquinas, consulta los precios de las instancias de máquinas virtuales.

Revisar clústeres de desarrollo pequeños

En el caso de los clústeres de desarrollo pequeños en los que necesites minimizar los costes, te recomendamos que uses clústeres de Autopilot. En los clústeres que funcionan en este modo, no se te cobra por los pods de sistema, los costes del sistema operativo ni las cargas de trabajo no programadas.

Revisar las estrategias de registro y monitorización

Si usas Cloud Logging y Cloud Monitoring para obtener información sobre tus aplicaciones e infraestructura, solo pagas por lo que usas. Sin embargo, cuanto más registren tu infraestructura y tus aplicaciones, y cuanto más tiempo conserves esos registros, más pagarás por ellos. Del mismo modo, cuantos más métricas externas y personalizadas tenga, mayores serán sus costes.

Revisar el tráfico de salida entre regiones en clústeres regionales y multizona

Los tipos de clústeres de GKE disponibles son de una sola zona, multizona y regionales. Gracias a la alta disponibilidad de los nodos en las zonas, los clústeres regionales y multizonales son adecuados para entornos de producción. Sin embargo, se te cobra por el tráfico de salida entre zonas. En los entornos de producción, le recomendamos que monitorice la carga del tráfico en las zonas y mejore sus APIs para minimizarla. También puedes usar configuraciones de afinidad y antiafinidad entre pods para colocar los pods dependientes de diferentes servicios en los mismos nodos o en la misma zona de disponibilidad para minimizar los costes y la latencia de red entre ellos. La forma recomendada de monitorizar este tráfico es habilitar la medición de uso de GKE y su agente de salida de red, que está inhabilitado de forma predeterminada.

En los entornos que no son de producción, la práctica recomendada para ahorrar costes es implementar clústeres de una sola zona.

Preparar el entorno para que se adapte a tu tipo de carga de trabajo

Las empresas tienen requisitos de costes y disponibilidad diferentes. Sus cargas de trabajo se pueden dividir en cargas de trabajo de servicio, que deben responder rápidamente a picos o aumentos repentinos, y cargas de trabajo por lotes, que se centran en el trabajo que se debe realizar. Las cargas de trabajo de servicio requieren una latencia de escalado vertical pequeña, mientras que las cargas de trabajo por lotes toleran mejor la latencia. Las diferentes expectativas de estos tipos de cargas de trabajo hacen que la elección de diferentes métodos de ahorro de costes sea más flexible.

Cargas de trabajo por lotes

Como las cargas de trabajo por lotes se centran en el trabajo final, permiten ahorrar costes en GKE, ya que suelen tolerar cierta latencia en el tiempo de inicio de los trabajos. Esta tolerancia da espacio a la herramienta de ajuste automático de clústeres para poner en marcha nuevos nodos solo cuando se programan trabajos y para desactivarlos cuando finalizan.

La primera práctica recomendada es separar las cargas de trabajo por lotes en diferentes grupos de nodos mediante etiquetas y selectores y taints y tolerancias. La razón es la siguiente:

  • La herramienta de ajuste automático de escala de clústeres puede eliminar nodos vacíos más rápido cuando no necesita reiniciar pods. Cuando finalizan los trabajos por lotes, el clúster acelera el proceso de reducción si la carga de trabajo se está ejecutando en nodos dedicados que ahora están vacíos. Para mejorar aún más la velocidad de las reducciones, puedes configurar el perfil de optimización de la utilización de la CA.
  • Algunos pods no se pueden reiniciar, por lo que bloquean permanentemente la reducción de sus nodos. Estos pods, incluidos los pods del sistema, deben ejecutarse en grupos de nodos diferentes para que no afecten a la reducción.

La segunda práctica recomendada es usar el aprovisionamiento automático de nodos para crear automáticamente grupos de nodos dedicados para las tareas que tengan una marca o una tolerancia coincidentes. De esta forma, puedes separar muchas cargas de trabajo diferentes sin tener que configurar todos esos grupos de nodos.

Te recomendamos que uses máquinas virtuales de Spot solo si ejecutas tareas tolerantes a fallos que son menos sensibles al carácter efímero y no garantizado de las máquinas virtuales de Spot.

Cargas de trabajo de servicio

A diferencia de las cargas de trabajo por lotes, las cargas de trabajo de servicio deben responder lo más rápido posible a los picos o aumentos repentinos. Estos aumentos repentinos del tráfico pueden deberse a muchos factores, como anuncios de televisión, eventos de gran escala como el Black Friday o noticias de última hora. Tu aplicación debe estar preparada para gestionarlos.

Los problemas a la hora de gestionar estos picos suelen estar relacionados con uno o varios de los siguientes motivos:

  • Las aplicaciones no están listas para ejecutarse en Kubernetes. Por ejemplo, las aplicaciones con imágenes de gran tamaño, tiempos de inicio lentos o configuraciones de Kubernetes no óptimas.
  • Aplicaciones que dependen de una infraestructura que tarda en aprovisionarse, como las GPUs.
  • Los escaladores automáticos y el aprovisionamiento excesivo no se han configurado correctamente.

Preparar aplicaciones de Kubernetes basadas en la nube

Algunas de las prácticas recomendadas de esta sección pueden ahorrarte dinero por sí solas. Sin embargo, como la mayoría de estas prácticas están pensadas para que tu aplicación funcione de forma fiable con los escaladores automáticos, te recomendamos que las implementes.

Conocer la capacidad de tu aplicación

Cuando planifiques la capacidad de la aplicación, debes saber cuántas solicitudes simultáneas puede gestionar, cuánta CPU y memoria necesita y cómo responde cuando está sometida a una carga elevada. La mayoría de los equipos no conocen estas capacidades, por lo que le recomendamos que pruebe cómo se comporta su aplicación bajo presión. Prueba a aislar una sola réplica de Pod de una aplicación con el escalado automático desactivado y, a continuación, ejecuta las pruebas simulando una carga de uso real. Esto te ayuda a conocer la capacidad de cada pod. Después, te recomendamos que configures el autoescalador de clústeres, las solicitudes y los límites de recursos, y el HPA o el VPA. A continuación, vuelve a ejercer presión sobre la aplicación, pero con más fuerza para simular picos o ráfagas repentinas.

Lo ideal es que estas pruebas se ejecuten en la misma región o zona en la que se ejecuta la aplicación para evitar problemas de latencia. Google CloudPuedes usar la herramienta que quieras para hacer estas pruebas, ya sea una secuencia de comandos creada por ti o una herramienta de rendimiento más avanzada, como Apache Benchmark, JMeter o Locust.

Para ver un ejemplo de cómo puedes realizar tus pruebas, consulta Pruebas de carga distribuidas con Google Kubernetes Engine.

Asegúrate de que tu aplicación pueda crecer vertical y horizontalmente

Asegúrate de que tu aplicación pueda crecer y reducirse. Esto significa que puedes gestionar los aumentos de tráfico añadiendo más CPU y memoria o añadiendo más réplicas de Pod. De esta forma, puedes experimentar con lo que mejor se adapte a tu aplicación, ya sea una configuración de escalado automático diferente o un tamaño de nodo distinto. Lamentablemente, algunas aplicaciones son de un solo hilo o están limitadas por un número fijo de trabajadores o subprocesos, lo que hace que este experimento sea imposible sin una refactorización completa de su arquitectura.

Definir solicitudes y límites de recursos adecuados

Si conoces la capacidad de tu aplicación, puedes determinar qué configurar en los recursos de tu contenedor. Los recursos de Kubernetes se definen principalmente como CPU y memoria (RAM). Para configurar la CPU o la memoria como la cantidad necesaria para ejecutar tu aplicación, usa la solicitud spec.containers[].resources.requests.<cpu|memory>. Para configurar el límite, usa la solicitud spec.containers[].resources.limits.<cpu|memory>. Para obtener más información sobre cómo configurar solicitudes de recursos, consulta Definir manualmente las solicitudes de recursos de pods.

Cuando hayas definido correctamente las solicitudes de recursos, el programador de Kubernetes podrá usarlas para decidir en qué nodo colocar tu pod. De esta forma, se garantiza que los pods se coloquen en nodos que puedan hacer que funcionen con normalidad, lo que te permite disfrutar de una mayor estabilidad y reducir el desperdicio de recursos. Además, definir límites de recursos ayuda a asegurar que estas aplicaciones nunca utilicen toda la infraestructura subyacente disponible proporcionada por los nodos de computación.

Siga estas prácticas recomendadas para definir las solicitudes y los límites de recursos de los contenedores:

  • Memoria: asigna la misma cantidad de memoria a la solicitud y al límite.
  • CPU: en la solicitud, especifica la CPU mínima necesaria para asegurar el correcto funcionamiento, de acuerdo con tus propios SLOs. Define un límite de CPU ilimitado.

Tomemos como ejemplo la siguiente implementación:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: wordpress
spec:
  replicas: 1
  selector:
    matchLabels:
      app: wp
  template:
    metadata:
      labels:
        app: wp
    spec:
      containers:
  - name: wp
    image: wordpress
    resources:
      requests:
        memory: "128Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"

El motivo del patrón anterior se basa en cómo funciona la gestión de falta de recursos de Kubernetes. En resumen, cuando se agotan los recursos del ordenador, los nodos se vuelven inestables. Para evitar esta situación, kubelet monitoriza y evita la falta total de estos recursos clasificando los pods que consumen muchos recursos. Cuando la CPU está en disputa, estos pods pueden reducirse a sus solicitudes. Sin embargo, como la memoria es un recurso que no se puede comprimir, cuando se agota, el pod debe detenerse. Para evitar que se desactiven los pods y, por lo tanto, que se desestabilice tu entorno, debes definir la memoria solicitada como límite de memoria. Para identificar las cargas de trabajo que no tienen configuradas solicitudes o límites de recursos para sus contenedores, consulta las estadísticas del subtipo REQUEST_OR_LIMIT_NOT_SET. Para obtener más información, consulta Identificar cargas de trabajo sin solicitudes ni límites de recursos.

También puedes usar VPA en el modo de recomendación para determinar el uso de CPU y memoria de una aplicación concreta. Para obtener más información, consulta el artículo sobre cómo analizar solicitudes de recursos.

Como VPA proporciona estas recomendaciones en función del uso que se hace de tu aplicación, te recomendamos que uses VPA en el modo de recomendación en un entorno similar al de producción para hacer frente al tráfico real. A continuación, el estado de VPA genera un informe con los límites y las solicitudes de recursos sugeridos, que puedes especificar de forma estática en el manifiesto de implementación. Si tu aplicación ya define HPA, consulta Combinar HPA y VPA.

Asegúrate de que tu contenedor sea lo más ligero posible

Cuando ejecutas contenedores en Kubernetes, tu aplicación puede iniciarse y detenerse en cualquier momento. Por lo tanto, es importante seguir estas prácticas recomendadas:

  • Tener la imagen más pequeña posible. Es recomendable usar imágenes pequeñas, ya que cada vez que el autoescalador de clústeres aprovisiona un nuevo nodo para tu clúster, el nodo debe descargar las imágenes que se ejecutarán en él. Cuanto más pequeña sea la imagen, más rápido podrá descargarla el nodo.

  • Inicia la aplicación lo antes posible. Algunas aplicaciones pueden tardar minutos en iniciarse debido a la carga de clases, el almacenamiento en caché, etc. Cuando un Pod requiere un inicio prolongado, es posible que las solicitudes de tus clientes fallen mientras se inicia tu aplicación.

Ten en cuenta estas dos prácticas al diseñar tu sistema, sobre todo si esperas picos o aumentos repentinos. Tener una imagen pequeña y un inicio rápido te ayuda a reducir la latencia de las ampliaciones. Por lo tanto, puedes gestionar mejor los aumentos de tráfico sin preocuparte demasiado por la inestabilidad. Estas prácticas funcionan mejor con las prácticas recomendadas de autoescalado que se describen en el artículo sobre el autoescalado de GKE.

Añadir un presupuesto de interrupción de pods a una aplicación

El presupuesto de interrupciones de pods (PDB) limita el número de pods que se pueden inhabilitar simultáneamente debido a una interrupción voluntaria. Esto significa que el presupuesto de interrupción definido se respeta en los lanzamientos, las actualizaciones de nodos y cualquier actividad de escalado automático. Sin embargo, este presupuesto no se puede garantizar cuando ocurren cosas involuntarias, como un fallo de hardware, un error del kernel o que alguien elimine una VM por error.

Si se respeta el PDB durante la fase de compactación de Cluster Autoscaler, es recomendable definir un presupuesto de interrupción de pods para cada aplicación. De esta forma, puedes controlar el número mínimo de réplicas necesarias para admitir tu carga en cualquier momento, incluso cuando el escalado automático de clústeres reduce el tamaño de tu clúster.

Para obtener más información, consulta Especificar un presupuesto de interrupción para tu aplicación.

Configurar comprobaciones de vivacidad y preparación significativas para tu aplicación

Si configura sondas significativas, su aplicación solo recibirá tráfico cuando esté activa y lista para aceptarlo. GKE usa sondas de disponibilidad para determinar cuándo añadir o quitar pods de los balanceadores de carga. GKE usa sondas de actividad para determinar cuándo reiniciar tus pods.

La comprobación de vivacidad es útil para indicar a Kubernetes que un pod determinado no puede avanzar, por ejemplo, cuando se detecta un estado de bloqueo. La sonda de disponibilidad es útil para indicar a Kubernetes que tu aplicación no está lista para recibir tráfico, por ejemplo, mientras carga datos de caché grandes al inicio.

Para asegurarte de que el ciclo de vida de tu aplicación sea correcto durante las actividades de escalado vertical, es importante que hagas lo siguiente:

  • Define la sonda de preparación de todos tus contenedores.
  • Si tu aplicación depende de que se cargue una caché al inicio, la sonda de disponibilidad debe indicar que está lista solo después de que la caché se haya cargado por completo.
  • Si tu aplicación puede empezar a servir contenido de inmediato, una buena implementación predeterminada de la sonda puede ser lo más sencilla posible. Por ejemplo, un endpoint HTTP que devuelva un código de estado 200.
  • Si implementas una sonda más avanzada, como comprobar si el grupo de conexiones tiene recursos disponibles, asegúrate de que la tasa de errores no aumente en comparación con una implementación más sencilla.
  • Nunca permitas que la lógica de las sondas acceda a otros servicios. Si estos servicios no responden rápidamente, puede verse comprometido el ciclo de vida de tu pod.

Para obtener más información, consulta Configurar sondas de vivacidad, preparación e inicio.

Asegúrate de que tus aplicaciones se cierran según las expectativas de Kubernetes

Los escaladores automáticos te ayudan a responder a los picos creando nuevos pods y nodos, y eliminándolos cuando finalizan los picos. Esto significa que, para evitar errores durante el servicio, tus pods deben estar preparados para un inicio rápido o un cierre correcto.

Como Kubernetes actualiza los endpoints y los balanceadores de carga de forma asíncrona, es importante seguir estas prácticas recomendadas para asegurarse de que los cierres no sean disruptivos:

  • No dejes de aceptar nuevas solicitudes justo después de SIGTERM. Tu aplicación no debe detenerse inmediatamente, sino que debe completar todas las solicitudes en curso y seguir escuchando las conexiones entrantes que lleguen después de que empiece la finalización del pod. Kubernetes puede tardar un poco en actualizar todos los kube-proxies y los balanceadores de carga. Si tu aplicación finaliza antes de que se actualicen, algunas solicitudes pueden provocar errores en el lado del cliente.
  • Si tu aplicación no sigue la práctica anterior, usa el hook preStop. La mayoría de los programas no dejan de aceptar solicitudes de inmediato. Sin embargo, si usas código de terceros o gestionas un sistema sobre el que no tienes control, como nginx, el hook preStop es una buena opción para activar un cierre ordenado sin modificar la aplicación. Una estrategia habitual es ejecutar, en el gancho preStop, un tiempo de espera de unos segundos para posponer el SIGTERM. De esta forma, Kubernetes tiene más tiempo para finalizar el proceso de eliminación del pod y se reducen los errores de conexión en el lado del cliente.
  • Gestiona SIGTERM para las limpiezas. Si tu aplicación debe limpiar o tiene un estado en memoria que debe conservarse antes de que finalice el proceso, ahora es el momento de hacerlo. Cada lenguaje de programación tiene una forma diferente de detectar esta señal, así que busca la forma adecuada en tu lenguaje.
  • Configura terminationGracePeriodSeconds para que se adapte a las necesidades de tu aplicación. Algunas aplicaciones necesitan más de los 30 segundos predeterminados para finalizar. En este caso, debe especificar terminationGracePeriodSeconds. Por ejemplo, los valores altos pueden aumentar el tiempo de las actualizaciones o los lanzamientos de nodos. Si los valores son bajos, es posible que Kubernetes no tenga tiempo suficiente para finalizar el proceso de finalización del pod. En cualquier caso, te recomendamos que definas el periodo de finalización de tu aplicación en menos de 10 minutos, ya que Escalador automático de clústeres solo lo respeta durante 10 minutos.
  • Si tu aplicación usa el balanceo de carga nativo de contenedores, empieza a fallar tu sonda de disponibilidad cuando recibas una señal SIGTERM. Esta acción indica directamente a los balanceadores de carga que dejen de reenviar nuevas solicitudes al pod de backend. En función de la carrera entre la configuración de la comprobación de estado y la programación del endpoint, es posible que el pod de backend se retire del tráfico antes.

Para obtener más información, consulta el artículo Prácticas recomendadas de Kubernetes: finalización con gracia.

Configurar NodeLocal DNSCache

El DNS gestionado por GKE se implementa mediante kube-dns, un complemento desplegado en todos los clústeres de GKE. Cuando ejecutas aplicaciones que consumen muchos recursos de DNS, es posible que la configuración predeterminada de kube-dns-autoscaler, que ajusta el número de réplicas de kube-dns en función del número de nodos y núcleos del clúster, no sea suficiente. En este caso, las consultas de DNS pueden ralentizarse o agotarse. Para mitigar este problema, las empresas suelen ajustar el kube-dns-autoscaler ConfigMap para aumentar el número de réplicas de kube-dns en sus clústeres. Aunque esta estrategia puede funcionar correctamente, aumenta el uso de recursos y el coste total de GKE.

Otra alternativa más escalable y optimizada para los costes es configurar NodeLocal DNSCache en tu clúster. NodeLocal DNSCache es un complemento opcional de GKE que mejora la latencia de las peticiones de DNS, hace que los tiempos de las peticiones de DNS sean más coherentes y reduce el número de consultas de DNS a kube-dns ejecutando una caché de DNS en cada nodo del clúster.

Para obtener más información, consulta Configurar NodeLocal DNSCache.

Usar el balanceo de carga nativo de contenedores mediante Ingress

El balanceo de carga nativo de contenedores permite que los balanceadores de carga se dirijan directamente a los pods de Kubernetes y distribuyan el tráfico de forma uniforme entre los pods mediante un modelo de datos denominado grupos de puntos finales de red (NEGs). Este enfoque mejora el rendimiento de la red, aumenta la visibilidad, permite usar funciones avanzadas de balanceo de carga y habilita el uso de Cloud Service Mesh, el plano de control del tráfico totalmente gestionado deGoogle Cloudpara mallas de servicios.

Por estas ventajas, el balanceo de carga nativo de contenedores es la solución recomendada para el balanceo de carga mediante Ingress. Cuando se usan NEGs con Ingress de GKE, el controlador Ingress facilita la creación de todos los aspectos del balanceador de carga de nivel 7. Esto incluye la creación de la dirección IP virtual, las reglas de reenvío, las comprobaciones de estado, las reglas de cortafuegos y más.

El balanceo de carga nativo de contenedores es aún más importante cuando se usa Cluster Autoscaler. En el caso de los balanceadores de carga que no son NEG, durante las reducciones de escala, la programación del balanceo de carga y la purga de conexiones podrían no completarse antes de que el escalador automático de clústeres finalice las instancias de nodo. Esto podría interrumpir las conexiones en curso que fluyen a través del nodo, incluso cuando los pods de backend no estén en el nodo.

El balanceo de carga nativo de contenedores está habilitado de forma predeterminada en los servicios cuando se cumplen todas las condiciones siguientes:

  • Los servicios se crearon en clústeres de GKE con la versión 1.17.6-gke.7 o una posterior.
  • Si usas clústeres nativos de VPC.
  • Si no utilizas una VPC compartida.
  • Si no usas la política de red de GKE.

Para obtener más información, consulta la documentación de Ingress de GKE y el artículo Usar el balanceo de carga nativo de contenedores.

Considera la posibilidad de usar reintentos con un tiempo de espera exponencial

En las arquitecturas de microservicios que se ejecutan en Kubernetes, pueden producirse errores transitorios por varios motivos. Por ejemplo:

Estos problemas son efímeros y puedes mitigarlos volviendo a llamar al servicio después de un tiempo. Sin embargo, para evitar que el servicio de destino se vea desbordado por las solicitudes, es importante que ejecutes estas llamadas con un tiempo de espera exponencial.

Para facilitar este patrón de reintentos, muchas bibliotecas implementan la lógica de reintentos exponencial. Puedes usar la biblioteca que quieras o escribir tu propio código. Si usas Istio o Cloud Service Mesh (ASM), puedes optar por el mecanismo de reintento a nivel de proxy, que ejecuta los reintentos de forma transparente en tu nombre.

Es importante planificar que tu aplicación admita reintentos de llamadas de servicio, por ejemplo, para evitar insertar información que ya se ha insertado. Ten en cuenta que una cadena de reintentos puede afectar a la latencia del usuario final, que puede agotarse si no se planifica correctamente.

Monitorizar el entorno y aplicar configuraciones y prácticas optimizadas para los costes

En muchas empresas medianas y grandes, un equipo centralizado de plataforma e infraestructura suele ser el responsable de crear, mantener y monitorizar clústeres de Kubernetes para toda la empresa. Esto demuestra la gran necesidad de rendir cuentas sobre el uso de los recursos y de asegurarse de que todos los equipos cumplen las políticas de la empresa. En esta sección se describen las opciones para monitorizar y aplicar prácticas relacionadas con los costes.

Observar clústeres de GKE y buscar recomendaciones

Para comprobar la utilización de recursos en un clúster de Kubernetes, examina los contenedores, los pods y los servicios, así como las características del clúster en general. Hay muchas formas de llevar a cabo esta tarea, pero el primer método que te recomendamos es observar tus clústeres de GKE a través del panel de control Monitoring. De esta forma, obtendrás datos de series temporales sobre cómo se usa tu clúster, lo que te permitirá agregar y abarcar la infraestructura, las cargas de trabajo y los servicios.

Aunque es un buen punto de partida, Google Cloud ofrece otras opciones, como las siguientes:

  • En la Google Cloud consola, en la página Clusters de GKE, consulta la columna Notificaciones. Si un clúster tiene un alto nivel de desperdicio de recursos, la interfaz de usuario te dará una pista sobre la información general de los recursos asignados frente a los solicitados.

    Ir a la lista de clústeres de GKE

  • En la Google Cloud consola, en la página Recomendaciones, busca las tarjetas de recomendación Ahorro de costes.

    Ir al centro de recomendaciones

Para obtener más información, consulta los artículos Monitorizar clústeres de GKE y Empezar a usar Recommendation Hub.

Habilitar la medición de uso de GKE

Si quieres un enfoque más flexible que te permita ver desgloses de costes aproximados, prueba la medición del uso de GKE. La medición del uso de GKE te permite consultar los perfiles de uso de tus clústeres de GKE desglosados por espacios de nombres y etiquetas. Monitoriza la información sobre las solicitudes de recursos y el consumo de recursos de las cargas de trabajo de tu clúster, como CPU, GPU, TPU, memoria, almacenamiento y, opcionalmente, salida de red.

Las métricas de uso de GKE te ayudan a entender la estructura de costes general de tus clústeres de GKE, qué equipo o aplicación está gastando más, qué entorno o componente ha provocado un aumento repentino del uso o de los costes, y qué equipo está derrochando recursos. Si comparas las solicitudes de recursos con el uso real, puedes saber qué cargas de trabajo están aprovisionadas por debajo o por encima de lo necesario.

Puedes aprovechar las plantillas predeterminadas de Looker Studio o ir un paso más allá y personalizar los paneles de control según las necesidades de tu organización. Para obtener más información sobre la medición del uso de GKE y sus requisitos previos, consulta Información sobre el uso de recursos de los clústeres.

Entender cómo funciona Metrics Server y monitorizarlo

Metrics Server es la fuente de las métricas de recursos de contenedores de las canalizaciones de autoescalado integradas de GKE. Metrics Server obtiene métricas de los kubelets y las expone a través de la API de métricas de Kubernetes. A continuación, HPA y VPA usan estas métricas para determinar cuándo activar el ajuste de escala automático.

Para que el autoescalado de GKE funcione correctamente, debes tener un servidor de métricas en buen estado. Con la implementación de GKE metrics-server, se instala un nanny de cambio de tamaño, que hace que el contenedor Metrics Server crezca verticalmente añadiendo o quitando CPU y memoria en función del número de nodos del clúster. Kubernetes aún no admite la actualización in situ de los pods, por lo que el proceso nanny debe reiniciar el pod metrics-server para aplicar los nuevos recursos necesarios.

Aunque el reinicio se produce rápidamente, la latencia total de los escaladores automáticos para darse cuenta de que deben actuar puede aumentar ligeramente después de un cambio de tamaño metrics-server. Para evitar que Metrics Server se reinicie con frecuencia en clústeres que cambian rápidamente, a partir de GKE 1.15.11-gke.9, el proceso nanny admite retrasos en el cambio de tamaño.

Sigue estas prácticas recomendadas cuando uses Metric Server:

  • Elige la versión de GKE que admita metrics-server retrasos en el cambio de tamaño. Para confirmarlo, comprueba si el archivo YAML de metrics-serverdespliegue tiene la configuración scale-down-delay en el contenedor metrics-server-nanny.
  • Monitoriza la implementación de metrics-server. Si Metrics Server no funciona, significa que no funciona ningún ajuste de escala automático. Quieres que tus servicios de monitorización de máxima prioridad monitoricen esta implementación.
  • Sigue las prácticas recomendadas que se describen en el artículo sobre el escalado automático de GKE.

Usar cuotas de recursos de Kubernetes

En los clústeres multiinquilino, es habitual que diferentes equipos se encarguen de las aplicaciones implementadas en distintos espacios de nombres. En el caso de un grupo de infraestructura y una plataforma centralizados, preocupa que un equipo pueda usar más recursos de los necesarios. Si no asignas suficientes recursos de computación a todos los clústeres o activas demasiados escalados verticales, tus costes pueden aumentar.

Para solucionar este problema, debe usar cuotas de recursos. Las cuotas de recursos gestionan la cantidad de recursos que usan los objetos de un espacio de nombres. Puede definir cuotas en términos de recursos de computación (CPU y memoria) y de almacenamiento, o en términos de recuento de objetos. Las cuotas de recursos te permiten asegurarte de que ningún cliente utilice más recursos de clústeres de los que tiene asignados.

Para obtener más información, consulta Configurar cuotas de memoria y CPU para un espacio de nombres.

Plantéate usar Policy Controller de GKE Enterprise

Policy Controller de GKE Enterprise es un controlador dinámico de admisión de Kubernetes que comprueba, audita y aplica el cumplimiento de las políticas en tus clústeres. Estas políticas están relacionadas con la seguridad, las normativas o las reglas empresariales arbitrarias. Policy Controller usa restricciones para aplicar el cumplimiento en tus clústeres. Por ejemplo, puedes instalar en tu clúster restricciones para muchas de las prácticas recomendadas que se describen en la sección Preparar tu aplicación de Kubernetes basada en la nube. De esta forma, los despliegues se rechazan si no se ajustan estrictamente a tus prácticas de Kubernetes. Aplicar estas reglas ayuda a evitar picos de costes inesperados y reduce las probabilidades de que la carga de trabajo sea inestable durante el autoescalado.

Para obtener más información sobre cómo aplicar y escribir tus propias reglas, consulta los artículos Crear restricciones y Escribir una plantilla de restricción. Si no eres cliente de GKE Enterprise, puedes usar Gatekeeper, el software de código abierto en el que se basa Policy Controller.

Diseñar tu flujo de procesamiento de CI/CD para aplicar prácticas de ahorro de costes

GKE Enterprise Policy Controller te ayuda a evitar que se implemente software no conforme en tu clúster de GKE. Sin embargo, te recomendamos que apliques estas restricciones de políticas en las primeras fases del ciclo de desarrollo, ya sea en las comprobaciones previas a la confirmación, en las comprobaciones de solicitudes de extracción, en los flujos de trabajo de entrega o en cualquier paso que tenga sentido en tu entorno. Esta práctica te permite encontrar y corregir errores de configuración rápidamente, así como entender a qué debes prestar atención creando medidas de protección.

También puedes usar funciones de kpt en tu canalización de CI/CD para validar si tus archivos de configuración de Kubernetes cumplen las restricciones que aplica Policy Controller de GKE Enterprise y para estimar la utilización de recursos o el coste de implementación. De esta forma, puedes detener la canalización cuando se detecte un problema relacionado con los costes. También puedes crear un proceso de aprobación de despliegue diferente para las configuraciones que, por ejemplo, aumenten el número de réplicas.

Para obtener más información, consulta Usar Policy Controller en un flujo de procesamiento de CI. Para ver un ejemplo completo de una plataforma de entrega, consulta CI/CD moderno con GKE Enterprise.

Difunde la cultura del ahorro

Muchas organizaciones crean abstracciones y plataformas para ocultar la complejidad de la infraestructura. Es una práctica habitual en las empresas que están migrando sus servicios de máquinas virtuales a Kubernetes. A veces, estas empresas permiten que los desarrolladores configuren sus propias aplicaciones en producción. Sin embargo, no es raro ver a desarrolladores que nunca han usado un clúster de Kubernetes.

Las prácticas que recomendamos en esta sección no significan que debas dejar de hacer abstracciones. En su lugar, te ayudan a ver tu inversión enGoogle Cloud y a formar a tus desarrolladores y operadores en tu infraestructura. Para ello, puedes crear incentivos y programas de aprendizaje en los que se utilicen clases tradicionales u online, grupos de debate, revisiones entre compañeros, programación en parejas, CI/CD y gamificaciones que permitan ahorrar costes, entre otras opciones. Por ejemplo, en el mundo de Kubernetes, es importante entender el impacto de una aplicación de imagen de 3 GB, una sonda de preparación que falta o una configuración incorrecta de HPA.

Por último, tal como se muestra en la investigación de DORA de Google, las capacidades culturales son algunos de los principales factores que impulsan un mejor rendimiento de la organización, menos repeticiones, menos agotamiento, etc. La reducción de costes no es diferente. Si tus empleados tienen acceso a sus gastos, se alinearán más con los objetivos y las limitaciones de la empresa.

Resumen de las prácticas recomendadas

En la siguiente tabla se resumen las prácticas recomendadas que se indican en este documento.

Tema Tarea
Funciones y opciones de optimización de costes de GKE
Preparar aplicaciones de Kubernetes nativas de la nube
Monitorizar el entorno y aplicar configuraciones y prácticas optimizadas para los costes
Cultura

Siguientes pasos