Prácticas recomendadas para ejecutar aplicaciones de Kubernetes con optimización de costos en GKE

En este documento, se analizan las funciones y opciones de Google Kubernetes Engine (GKE) y las prácticas recomendadas para ejecutar aplicaciones con optimización de costos en GKE a fin de aprovechar la flexibilidad que proporciona Google Cloud. En este documento, se da por sentado que estás familiarizado con Kubernetes, Google Cloud, GKE y el ajuste de escala automático.

Introducción

A medida que Kubernetes se adopta de manera más general, una cantidad cada vez mayor de empresas y proveedores de plataforma como servicio (PaaS) y software como servicio (SaaS) usan clústeres de Kubernetes de usuarios múltiples para sus cargas de trabajo. Esto significa que un solo clúster podría ejecutar aplicaciones que pertenecen a distintos equipos, departamentos, clientes o entornos. Los usuarios múltiples que proporciona Kubernetes permiten que las empresas administren algunos clústeres grandes, en lugar de varios más pequeños, con beneficios como el uso adecuado de recursos, el control de administración simplificado y la fragmentación reducida.

Con el tiempo, algunas de estas empresas con clústeres de Kubernetes de crecimiento rápido comienzan a experimentar un aumento desproporcionado en el costo. Esto sucede porque algunas 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 hace que las aplicaciones se vuelvan inestables durante el ajuste de escala automático (por ejemplo, la volatilidad del tráfico durante un período normal del día), aumentos de actividad repentinos (como comerciales de TV o eventos de escala máxima como Black Friday y Cyber Monday). En un intento por “solucionar” el problema, estas empresas tienden a aprovisionar en exceso sus clústeres de la manera en que solían hacerlo en un entorno inflexible. El exceso de aprovisionamiento da como resultado una asignación de CPU y memoria que supera de manera considerable la que usan las aplicaciones durante la mayor parte del día.

En este documento, se proporcionan las prácticas recomendadas para ejecutar cargas de trabajo de Kubernetes con optimización de costo en GKE. En el siguiente diagrama, se describe este enfoque.

El enfoque a fin de optimizar las aplicaciones de Kubernetes para el costo.

La base para compilar aplicaciones con optimización de costos difunde la cultura de ahorro de costos entre los equipos. Además de llevar el análisis de costos al comienzo 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 lograr un costo bajo y la estabilidad de las aplicaciones, debes establecer o ajustar de forma correcta algunas funciones y la configuración (como el ajuste de escala automático, los tipos de máquinas y la selección de región). Otra consideración importante es el tipo de carga de trabajo que tienes porque, según este y los requisitos de tu aplicación, debes aplicar diferentes opciones de configuración para reducir aún más los costos. Por último, debes supervisar tus gastos y crear barreras de seguridad para poder aplicar las prácticas recomendadas en una etapa temprana del ciclo de desarrollo.

En la siguiente tabla, se resumen los desafíos que GKE te ayuda a resolver. Si bien te recomendamos leer el documento completo, en esta tabla se presenta un mapa de los temas que se tratan.

Desafío Acción
Quiero encontrar una forma sencilla para ahorrar en GKE. Selecciona la región adecuada, regístrate para obtener descuentos por compromiso de uso y usa los tipos de máquinas E2.
Necesito comprender mis costos 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 flexibilidad de GKE para mis cargas de trabajo existentes. Lee Escalador automático horizontal de Pods, Escalador automático del clúster y obtén información sobre las prácticas recomendadas para el escalador automático y el exceso de aprovisionamiento.
Quiero usar los tipos de máquinas más eficientes. Elige el tipo de máquina adecuado para tu carga de trabajo.
Muchos nodos del clúster están inactivos. Lee las prácticas recomendadas para el escalador automático del clúster.
Necesito ahorrar más en los trabajos por lotes. Lee las prácticas recomendadas para las cargas de trabajo por lotes.
Necesito ahorrar más en las cargas de trabajo de entrega. Lee las prácticas recomendadas para las cargas de trabajo de entrega.
No sé cómo ajustar el tamaño de mis solicitudes de recursos de Pods. Usa el escalador automático vertical de Pods (VPA), pero presta atención a las prácticas recomendadas para combinar el escalador automático horizontal de Pods (HPA) y el VPA.
Mis aplicaciones son inestables durante el ajuste de escala automático y las actividades de mantenimiento. Prepara aplicaciones basadas en la nube para Kubernetes y obtén información sobre cómo funciona el servidor de métricas y cómo supervisarlo.
¿Cómo hago para que los desarrolladores presten atención al uso de recursos de sus aplicaciones? Difunde la cultura de ahorro de costos, considera usar el controlador de políticas de Anthos, diseña tu canalización de CI/CD a fin de aplicar prácticas para ahorrar costos y usa las cuotas de recursos de Kubernetes.
¿Qué otros aspectos debería tener en cuenta para reducir aún más los costos de mi ecosistema? Revisa los clústeres de desarrollo pequeños, las estrategias de registro y supervisión y el tráfico de salida entre regiones en clústeres regionales y de varias zonas.

Funciones y opciones de optimización de costos de GKE

Las aplicaciones de Kubernetes con optimización de costos dependen en gran medida del ajuste de escala automático de GKE. Para equilibrar el costo, la confiabilidad y el rendimiento del escalamiento en GKE, debes comprender cómo funciona el ajuste de escala automático y qué opciones tienes. En esta sección, se analiza el ajuste de escala automático de GKE y otras opciones de configuración útiles a fin de optimizar costos para cargas de trabajo de entrega y por lotes.

Optimiza el ajuste de escala automático de GKE

El ajuste de escala automático es la estrategia que usa GKE para permitir que los clientes de Google Cloud paguen solo por lo que necesitan mediante la minimización del tiempo de actividad de la infraestructura. En otras palabras, el ajuste de escala automático te permite ahorrar costos, ya que 1) hace que las cargas de trabajo y su infraestructura subyacente comiencen antes de que aumente la demanda, y 2) las cierra cuando la demanda disminuye.

En el siguiente diagrama, se ilustra este concepto. En Kubernetes, tus cargas de trabajo son aplicaciones en contenedores que se ejecutan dentro de Pods y la infraestructura subyacente, que está compuesta por un conjunto de nodos, debe proporcionar suficiente capacidad de procesamiento para ejecutar las cargas de trabajo.

El ajuste de escala automático te permite ahorrar costos, ya que 1) hace que las cargas de trabajo y su infraestructura subyacente comiencen antes de que aumente la demanda, y 2) las cierra 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 de manera horizontal si se agregan y quitan Pods o nodos, y se escalan verticalmente mediante el aumento y la disminución del tamaño de los Pods o nodos.

Las cuatro dimensiones de escalabilidad de un entorno con optimización de costos.

GKE controla estas situaciones de ajuste de escala automático mediante funciones como las siguientes:

En el siguiente diagrama, se ilustran estas situaciones.

Usa las situaciones de aprovisionamiento automático de HPA, VPA, CA y nodos

En el resto de esta sección, se analizan estas funciones de ajuste de escala automático de GKE en más detalle y se abordan otras opciones de configuración útiles a fin de optimizar costos para cargas de trabajo por lotes y de entrega.

Escalador automático de pod horizontal

El Escalador automático horizontal de Pods (HPA) está diseñado para escalar aplicaciones que se ejecutan en Pods según las métricas que expresan carga. Puedes configurar el uso de CPU u otras métricas personalizadas (por ejemplo, solicitudes por segundo). En resumen, el HPA agrega y borra réplicas de Pods y es más adecuado para trabajadores sin estado que pueden iniciarse con rapidez a fin de reaccionar a los aumentos de uso y cerrarse de manera controlada con el fin de evitar inestabilidad en la carga de trabajo.

El umbral de uso objetivo del HPA te permite personalizar cuándo activar de forma automática el escalamiento.

Como se muestra en la imagen anterior, el HPA requiere un umbral de uso objetivo, expresado en porcentaje, que te permite personalizar cuándo activar el escalamiento de forma automática. En este ejemplo, el uso objetivo de CPU es del 70%. Eso significa que tu carga de trabajo tiene un búfer de CPU del 30% para administrar las solicitudes mientras se inician réplicas nuevas. Un búfer pequeño evita los escalamientos verticales tempranos, pero puede sobrecargar la aplicación durante los aumentos. Sin embargo, un búfer grande causa desperdicio de recursos, lo que aumenta los costos. El objetivo exacto es específico de la aplicación y debes considerar que el tamaño del búfer sea suficiente para controlar las solicitudes durante dos o tres minutos cuando haya un aumento. Incluso si garantizas que tu aplicación puede iniciarse en cuestión de segundos, este tiempo adicional es necesario cuando el escalador automático del clúster agrega nodos nuevos al clúster o cuando se limitan los Pods por falta de recursos.

A continuación, se detallan prácticas recomendadas para habilitar el HPA en tu aplicación:

Para obtener más información, consulta Configura un escalador automático horizontal de Pods.

Escalador automático vertical de Pods

A diferencia del HPA, que agrega y borra réplicas de Pods para reaccionar con rapidez a los aumentos de uso, el escalador automático vertical de Pods (VPA) observa los Pods en el tiempo y, de manera gradual, encuentra los recursos de CPU y memoria óptimos que requieren los Pods. Configurar los recursos correctos es importante para la estabilidad y la rentabilidad. Si los recursos de Pods son demasiado pequeños, la aplicación puede verse limitada o puede fallar debido a errores por memoria insuficiente. Si los recursos son demasiado grandes, tendrás pérdidas y, por lo tanto, facturas más grandes. El VPA se crea para cargas de trabajo con y sin estado que el HPA no administre o cuando no conoces las solicitudes adecuadas de recursos de Pods.

El VPA detecta que un Pod se ejecuta de manera constante al límite y vuelve a crearlo con recursos más grandes.

Como se muestra en la imagen anterior, el VPA detecta que el Pod se ejecuta de manera constante al límite y vuelve a crearlo con recursos más grandes. Lo contrario también ocurre cuando el Pod se usa con menos frecuencia de manera constante; en esos casos, se activa una reducción de escala.

El VPA puede funcionar de tres formas diferentes:

  • Desactivado: En este modo, también conocido como modo de recomendación, el VPA no aplica ningún cambio al Pod. Las recomendaciones se calculan y se pueden inspeccionar en el objeto del VPA.
  • Inicial: El VPA asigna solicitudes de recursos solo durante la creación del Pod y nunca las cambia más adelante.
  • Automático: El VPA actualiza las solicitudes de CPU y memoria durante la vida útil de un Pod. Esto significa que se borra el Pod, se ajusta la CPU y la memoria y, luego, se inicia un Pod nuevo.

Si planeas usar un VPA, la práctica recomendada es comenzar con el modo Desactivado para extraer recomendaciones del VPA. Asegúrate de que se ejecute durante 24 horas, en lo ideal una semana o más, antes de generar recomendaciones. Luego, solo cuando te sientas seguro, considera cambiar al modo Inicial o Automático.

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

Si estás considerando usar el modo Automático, también debes seguir estas prácticas:

Para obtener más información, consulta Configura el ajuste de escala automático vertical de Pods.

Combina HPA y VPA

La recomendación oficial es que no mezcles el VPA y el HPA en la CPU o la memoria. Sin embargo, puedes mezclarlos de forma segura cuando usas el modo de recomendación en el VPA o métricas personalizadas en el HPA, por ejemplo, las solicitudes por segundo. Cuando mezclas el VPA con el HPA, asegúrate de que las implementaciones reciban suficiente tráfico, es decir, que se ejecuten de forma constante por encima de un mínimo de réplicas del HPA. Esto permite que el VPA comprenda las necesidades de recursos del Pod.

Para obtener más información sobre las limitaciones del VPA, consulta Limitaciones del ajuste de escala automático vertical de Pods.

Escalador automático del clúster

El escalador automático del clúster (CA) cambia el tamaño de la infraestructura de procesamiento subyacente de forma automática. El CA proporciona nodos para Pods que no tienen un lugar para ejecutarse en el clúster y quita los nodos con poco uso. El CA está optimizado para el costo de la infraestructura. En otras palabras, si hay dos o más tipos de nodos en el clúster, el CA elige el menos costoso que se ajuste a la demanda.

A diferencia del HPA y el VPA, el CA no depende de las métricas de carga. En cambio, se basa en la simulación de programación y las solicitudes de Pods declaradas. Se recomienda habilitar el CA siempre que uses el HPA o el VPA. Esta práctica garantiza que, si los escaladores automáticos de Pods determinan que necesitas más capacidad, tu infraestructura subyacente crezca en consecuencia.

El CA agrega y quita de manera automática la capacidad de procesamiento para controlar los aumentos de tráfico.

Como se muestra en estos diagramas, el CA agrega y quita de manera automática la capacidad de procesamiento para controlar los aumentos de tráfico y ahorrarte dinero cuando los clientes están durmiendo. Se recomienda definir el presupuesto de interrupción del Pod (PDB) en todas tus aplicaciones. Es especialmente importante en la fase de reducción de escala del CA cuando el PDB controla la cantidad de réplicas que se pueden quitar a la vez.

Ciertos Pods no pueden reiniciarse mediante ningún escalador automático cuando causan alguna interrupción temporal, por lo que no se puede borrar el nodo en el que se ejecutan. Por ejemplo, los Pods del sistema (como metrics-server y kube-dns) y los que usan el almacenamiento local no se reiniciarán. Sin embargo, puedes cambiar este comportamiento si defines los PDB para estos Pods del sistema y configuras la anotación "cluster-autoscaler.kubernetes.io/safe-to-evict": "true" para los Pods que usan el almacenamiento local y que son seguros a fin de que el escalador automático se reinicie. Además, considera ejecutar Pods de larga duración que no puedan reiniciarse en un grupo de nodos diferente para que no bloqueen la reducción de escala de otros nodos. Por último, obtén información sobre cómo analizar los eventos del CA en los registros para comprender por qué una actividad de escalamiento en particular no se produjo como se esperaba.

Si tus cargas de trabajo son resilientes a los nodos que se reinician de manera inadvertida y a la pérdida de capacidad, puedes ahorrar más dinero mediante la creación de un clúster o grupo de nodos con VM interrumpibles. A fin de que el CA funcione como se espera, las solicitudes de recursos del Pod deben ser lo suficientemente grandes como 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 los Pods se bloqueen o tengan problemas durante el tiempo de ejecución.

El siguiente es un resumen de las prácticas recomendadas para habilitar el escalador automático del clúster en tu clúster:

  • Usa el HPA o el VPA para realizar un ajuste de escala automático en tus cargas de trabajo.
  • Asegúrate de seguir las prácticas recomendadas descritas en el escalador automático de Pods elegido.
  • Ajusta el tamaño de tu aplicación de forma correcta mediante la configuración de solicitudes y límites adecuados de recursos. o usa el VPA.
  • Define un PDB para tus aplicaciones.
  • Define el PDB para los Pods del sistema que podrían bloquear la reducción de escala. Por ejemplo, kube-dns. A fin de evitar interrupciones temporales en el clúster, no configures el PDB para los Pods del sistema que tengan solo 1 réplica (como metrics-server).
  • Ejecuta los Pods de corta duración y los que se pueden reiniciar en grupos de nodos diferentes para que los de larga duración no bloqueen su reducción de escala.
  • Evita el exceso de aprovisionamiento mediante la configuración de nodos inactivos en el clúster. Para ello, debes conocer la capacidad mínima, que para muchas empresas es durante la noche, y establecer la cantidad mínima de nodos en los grupos de nodos a fin de admitir esa capacidad.
  • Si necesitas capacidad adicional para controlar las solicitudes durante los aumentos, usa los Pods de pausa, que se analizan en Escalador automático y el exceso de aprovisionamiento.

Para obtener más información, consulta Ajuste de escala automático en un clúster.

Aprovisionamiento automático de nodos

El aprovisionamiento automático de nodos (NAP) es un mecanismo del escalador automático del clúster que agrega grupos de nodos nuevos además de administrar su tamaño en nombre del usuario. Sin el aprovisionamiento automático de nodos, GKE considera iniciar nodos nuevos solo a partir del conjunto de grupos de nodos creados por el usuario. Con el aprovisionamiento automático de nodos, GKE puede crear y borrar grupos de nodos nuevos de manera automática.

El aprovisionamiento automático de nodos suele reducir el desperdicio de recursos mediante la creación dinámica de grupos de nodos que se adaptan mejor a las cargas de trabajo programadas. Sin embargo, la latencia del ajuste de escala automático puede ser un poco más alta cuando se deben crear grupos de nodos nuevos. Si tus cargas de trabajo son resilientes a los nodos que se reinician de manera inadvertida y a la pérdida de capacidad, puedes reducir aún más los costos mediante la configuración de la tolerancia de VM interrumpibles en el Pod.

Las siguientes son prácticas recomendadas para habilitar el aprovisionamiento automático de nodos:

  • Sigue todas las prácticas recomendadas del escalador automático del clúster.
  • Establece tamaños de recursos mínimos y máximos para evitar que el NAP realice cambios significativos en el clúster cuando la aplicación no recibe tráfico.
  • Cuando uses el escalador automático horizontal de Pods para entregar cargas de trabajo, considera reservar un búfer de uso objetivo un poco más grande, ya que el NAP podría aumentar la latencia del ajuste de escala automático en algunos casos.

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

Exceso de aprovisionamiento y escalador automático

Para controlar los costos, te recomendamos que habilites el escalador automático de acuerdo con las secciones anteriores. Ninguna configuración se ajusta a todas las situaciones posibles, por lo que debes optimizar la configuración de la carga de trabajo para asegurarte de que los escaladores automáticos respondan de manera correcta a los aumentos de tráfico.

Sin embargo, como se señaló en la sección Escalador automático horizontal de Pods, el escalamiento vertical puede tardar un tiempo debido al aprovisionamiento de infraestructura. Para visualizar esta diferencia en el tiempo y las posibles situaciones de escalamiento vertical, considera la siguiente imagen.

Visualiza la diferencia en el tiempo y las posibles situaciones de escalamiento vertical.

Cuando tu clúster tiene espacio suficiente para implementar Pods nuevos, se activa una de las situaciones de escalamiento vertical de cargas de trabajo. Por lo tanto, si un nodo existente nunca implementó la 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 réplica de Pod nueva de la aplicación, el tiempo de escalamiento vertical disminuye porque no se requiere la descarga de imágenes (situación 2).

Cuando tu clúster no tiene suficiente espacio para implementar nuevos Pods, se activa una de las situaciones de escalamiento vertical de la infraestructura y las cargas de trabajo. Esto significa que el escalador automático del clúster debe aprovisionar nodos nuevos e iniciar el software requerido antes de abordar la aplicación (situación 1). Si usas el aprovisionamiento automático de nodos, según la carga de trabajo programada, es posible que se necesiten grupos de nodos nuevos. En esta situación, el tiempo total de escalamiento vertical se incrementa debido a que el escalador automático del clúster debe aprovisionar nodos y grupos de nodos (situación 2).

Para situaciones en las que se requiera una infraestructura nueva, no fuerces demasiado tu clúster, es decir, debes aprovisionar de más, pero solo para reservar el búfer necesario a fin de controlar las solicitudes máximas esperadas durante los escalamientos verticales.

Existen dos estrategias principales para este tipo de exceso de aprovisionamiento:

  • Optimiza el ajuste del objetivo de uso del HPA. La siguiente ecuación es una forma simple 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 CPU. Esta variable es útil porque alcanzar el 100% de CPU significa que la latencia del procesamiento de solicitudes es mucho más alta de lo normal.
    • perc es el porcentaje de aumento del tráfico que se espera en dos o tres minutos.

    Por ejemplo, si esperas un crecimiento del 30% en tus solicitudes y deseas evitar alcanzar el 100% de CPU mediante la definición de un búfer de seguridad del 10%, tu fórmula se vería de la siguiente manera:

    (1 - 0.1)/(1 + 0.3) = 0.69

  • Configura Pods de pausa. No hay forma de configurar el escalador automático del clúster para iniciar nodos por adelantado. En cambio, puedes establecer un objetivo de uso del HPA para proporcionar un búfer que ayude a controlar los aumentos de carga. Sin embargo, si esperas aumentos de actividad grandes, es posible que establecer un objetivo de uso del HPA pequeño no sea suficiente o sea demasiado costoso.

    Una solución alternativa para este problema es usar Pods de pausa. Los Pods de pausa son implementaciones de prioridad baja que no hacen más que reservar espacio en tu clúster. Cada vez que se programa un Pod de prioridad alta, los Pods de pausa se expulsan y el Pod de prioridad alta ocupa su lugar de inmediato. Luego, los Pods de pausa expulsados se reprograman y, si no hay lugar en el clúster, el escalador automático del clúster inicia nodos nuevos para acomodarlos. Se recomienda tener un solo Pod de pausa por nodo. Por ejemplo, si usas 4 nodos de CPU, configura la solicitud de CPU de los Pods de pausa con alrededor de 3,200 m.

Elige el tipo de máquina adecuado

Además del ajuste de escala automático, otras opciones de configuración pueden ayudarte a ejecutar aplicaciones de Kubernetes con optimización de costos en GKE. En esta sección, se explica cómo elegir el tipo de máquina adecuado.

VM interrumpibles

Las VM interrumpibles (PVM) son instancias de VM de Compute Engine que duran un máximo de 24 horas y no proporcionan garantías de disponibilidad. Las PVM son hasta un 80% más económicas que las VM estándar de Compute Engine, pero recomendamos que las uses con precaución en los clústeres de GKE. Las PVM de GKE son más adecuadas para ejecutar trabajos por lotes o tolerantes a errores que son menos sensibles a la naturaleza efímera y no garantizada de las PVM. Las cargas de trabajo con estado y de entrega no deben usar las PVM, a menos que prepares tu sistema y arquitectura para manejar las limitaciones de las PVM.

Cualquiera sea el tipo de carga de trabajo, debes prestar atención a las siguientes limitaciones:

  • Es posible que no se respete el presupuesto de interrupción del Pod porque los nodos interrumpibles pueden cerrarse de manera inadvertida.
  • No hay garantía de que los Pods se cierren de manera controlada una vez que la interrupción del nodo ignora el período de gracia del Pod.
  • GKE puede tardar varios minutos en detectar que el nodo se interrumpió y que los Pods ya no se están ejecutando, lo que retrasa la reprogramación de los Pods en un nodo nuevo.

Para mitigar estas restricciones, puedes implementar en el clúster un proyecto del controlador de eventos de terminación de nodo de la comunidad (importante: este no es un proyecto oficial de Google) que proporcione un adaptador para traducir eventos de terminación de nodos de Compute Engine a terminaciones controladas de Pods en Kubernetes. Con este proyecto de la comunidad, no se resuelven de forma confiable todas las limitaciones de las PVM una vez que los Presupuestos de interrupción de Pods pueden seguir sin respetarse. Por lo tanto, los Pods pueden tardar un poco más en reprogramarse.

Por último, las PVM no tienen disponibilidad garantizada, lo que significa que pueden agotarse con facilidad en algunas regiones. Para superar esta limitación, te recomendamos configurar un grupo de nodos de copia de seguridad sin PVM. El escalador automático del clúster le da preferencia a las PVM porque está optimizado para el costo de la infraestructura.

Para obtener más información, consulta la página sobre cómo ejecutar VM interrumpibles en GKE y cómo ejecutar aplicaciones web en GKE mediante PVM con optimización de costos.

Tipos de máquinas E2

Los tipos de máquinas E2 (VM E2) son VM con optimización de costos que ofrecen un 31% de ahorro en comparación con los tipos de máquinas N1. Las VM E2 son adecuadas para una gran variedad de cargas de trabajo, incluidos los servidores web, los microservicios, las aplicaciones esenciales para empresas, las bases de datos pequeñas y medianas y los entornos de desarrollo.

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

Selecciona la región adecuada

Cuando el costo es una limitación, es importante dónde ejecutas los clústeres de GKE. Debido a muchos factores, el costo varía según la región de procesamiento. Por lo tanto, asegúrate de ejecutar la carga de trabajo en la opción menos costosa, pero en la que la latencia no afecta al cliente. Si la carga de trabajo requiere que se copien datos de una región a otra, por ejemplo, para ejecutar un trabajo por lotes, también deberás considerar el costo de mover estos datos.

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

Regístrate para obtener descuentos por compromiso de uso

Si quieres quedarte con Google Cloud por unos años, te recomendamos que adquieras descuentos por compromiso de uso a cambio de precios muy reducidos por el uso de VM. Cuando firmas un contrato de compromiso de uso, adquieres recursos de procesamiento a un precio con descuento (hasta un 70% de descuento) a cambio de comprometerte a pagar por esos recursos durante un año o tres. Si no estás seguro de a cuántos recursos te quieres comprometer, consulta tu uso mínimo de procesamiento, por ejemplo, durante la noche, y confirma el pago por ese monto.

Si deseas obtener más información sobre los precios de compromiso de uso de diferentes tipos de máquinas, consulta Precios de instancias de VM.

Revisa los clústeres de desarrollo pequeños

Para los clústeres de desarrollo pequeños, como los clústeres con tres nodos o menos, que usan tipos de máquina con recursos limitados, puedes reducir el uso de recursos si inhabilitas o ajustas algunos complementos de clústeres. Esta práctica es especialmente útil si tienes una estrategia de un clúster por desarrollador y tus desarrolladores no necesitan, por ejemplo, el ajuste de escala automático, el registro o la supervisión. Sin embargo, debido al costo por clúster y la administración simplificada, recomendamos que comiences a usar una estrategia de clúster de usuarios múltiples.

Para obtener más información sobre qué complementos se pueden inhabilitar y el impacto que eso genera, consulta el instructivo Reduce el uso de recursos de complementos en clústeres más pequeños.

Revisa las estrategias de registro y supervisión

Si usas Cloud Logging y Cloud Monitoring para proporcionar observabilidad de las aplicaciones y la infraestructura, solo pagas por lo que usas. Sin embargo, cuanto más se registren la infraestructura y las aplicaciones y cuanto más tiempo conserves esos registros, más pagarás por ellos. Del mismo modo, cuantas más métricas externas y personalizadas tenga, mayores serán los costos. Revisa tus estrategias de registro y supervisión según la optimización de costos para Cloud Logging, Cloud Monitoring y la administración del rendimiento de las aplicaciones.

Revisa el tráfico de salida entre regiones en clústeres regionales y de varias zonas

Los tipos de clústeres de GKE disponibles son de una sola zona, de varias zonas y regionales. Debido a la alta disponibilidad de nodos entre las zonas, los clústeres regionales y de varias zonas son adecuados para entornos de producción. Sin embargo, se te cobrará por el tráfico de salida entre zonas. Para entornos de producción, te recomendamos supervisar la carga de tráfico entre zonas y mejorar tus API a fin de minimizarla. Además, considera usar las opciones de configuración 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 a fin de minimizar los costos y la latencia de red entre ellos. La forma sugerida de supervisar este tráfico es habilitar la medición del uso de GKE y su agente de salida de red, que está inhabilitado de forma predeterminada.

En entornos que no son de producción, se recomienda implementar clústeres de una sola zona para ahorrar costos.

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

Las empresas tienen diferentes requisitos de costos y disponibilidad. Sus cargas de trabajo pueden dividirse en cargas de trabajo de entrega, que deben responder con rapidez a aumentos repentinos de actividad, y cargas de trabajo por lotes, que se relacionan con el trabajo final que se realizará. Las cargas de trabajo de entrega requieren una latencia de escalamiento vertical pequeña mientras que las cargas de trabajo por lotes son más tolerantes a la latencia. Las diferentes expectativas de estos tipos de cargas de trabajo hacen que elegir diferentes métodos de ahorro de costos sea más flexible.

Cargas de trabajo por lotes

Debido a que las cargas de trabajo por lotes son las encargadas del trabajo final, permiten el ahorro de costos en GKE, ya que suelen tolerar cierta latencia cuando se inicia el trabajo. Esta tolerancia le da espacio al escalador automático del clúster para iniciar nodos nuevos solo cuando los trabajos están programados y los quita cuando se finalizan los trabajos.

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

  • El escalador automático del clúster puede borrar nodos vacíos más rápido cuando no necesita reiniciar los Pods. Cuando los trabajos por lotes finalizan, el clúster acelera el proceso de reducción de escala si la carga de trabajo se ejecuta en nodos dedicados que ahora están vacíos. Para mejorar aún más la velocidad de las reducciones de escala, considera configurar el perfil de optimización de uso del CA.
  • Algunos Pods no se pueden reiniciar, por lo que bloquean de forma permanente la reducción de escala de sus nodos. Estos Pods, que incluyen los Pods del sistema, deben ejecutarse en grupos de nodos diferentes para que no afecten la reducción de escala.

La segunda práctica recomendada es usar el aprovisionamiento automático de nodos a fin de crear de forma automática grupos de nodos dedicados para trabajos con un taint o una tolerancia que coincidan. De esta manera, puedes separar muchas cargas de trabajo diferentes sin tener que configurar todos esos grupos de nodos diferentes.

Recomendamos que uses VM interrumpibles solo si ejecutas trabajos tolerantes a errores que sean menos sensibles a la naturaleza efímera y no garantizada de las VM interrumpibles.

Para obtener más información sobre cómo configurar un entorno que cumpla estas prácticas, consulta el instructivo Optimiza el uso de recursos en un clúster de GKE de usuarios múltiples con aprovisionamiento automático de nodos.

Cargas de trabajo de entrega

A diferencia de las cargas de trabajo por lotes, las cargas de trabajo de entrega deben responder lo más rápido posible a los aumentos repentinos de actividad. Estos aumentos repentinos de tráfico pueden generarse por muchos factores, como los comerciales de TV, los eventos de escalamiento vertical, como el Black Friday o las noticias de último momento. Tu aplicación debe estar preparada para manejarlos.

Los problemas para manejar estos aumentos suelen estar relacionados con uno o más de los siguientes motivos:

  • Aplicaciones que no están listas para ejecutarse en Kubernetes, por ejemplo, apps con tamaños de imagen grandes, tiempos de inicio lentos o con opciones de configuración de Kubernetes que no son óptimas
  • Aplicaciones que dependen de infraestructura que tarda en aprovisionarse, como las GPU
  • Escaladores automáticos y exceso de aprovisionamiento que no se configuraron de forma correcta

Prepara 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, dado que la mayoría de estas prácticas están diseñadas para que tu aplicación funcione de forma confiable con los escaladores automáticos, te recomendamos que las implementes.

Obtén información sobre la capacidad de tu aplicación

Cuando planifiques la capacidad de la aplicación, debes saber cuántas solicitudes simultáneas puede manejar tu aplicación, cuánta CPU y memoria necesita y cómo responde a cargas pesadas. La mayoría de los equipos no conocen estas capacidades, por lo que te recomendamos probar cómo se comporta tu aplicación bajo presión. Intenta aislar una sola réplica del Pod de la aplicación con el ajuste de escala automático desactivado y, luego, ejecuta las pruebas que simulan una carga de uso real. Esto te ayuda a obtener información sobre la capacidad por Pod. Luego, te recomendamos configurar el escalador automático del clúster, las solicitudes y los límites de recursos y el HPA o el VPA. A continuación, vuelve poner a prueba tu aplicación, pero con más esfuerzo para simular aumentos repentinos de actividad.

Lo ideal es que, para terminar con las inquietudes acerca de la latencia, estas pruebas se ejecuten desde la misma región o zona en la que se ejecuta la aplicación en Google Cloud. Puedes usar la herramienta que prefieras para estas pruebas, ya sea una secuencia de comandos casera o una herramienta de rendimiento más avanzada, como Apache Benchmark, JMetter o Locust.

Para ver un ejemplo de cómo puedes realizar las pruebas, consulta Pruebas de carga distribuida mediante Google Kubernetes Engine.

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

Asegúrate de que tu aplicación pueda aumentar y reducir la escala. Esto significa que puedes optar por controlar los aumentos de tráfico mediante el agregado de más CPU y memoria o más réplicas de Pods. Esto te brinda la flexibilidad de experimentar lo que mejor se adapte a tu aplicación, ya sea una configuración de escalador automático diferente o un tamaño de nodo diferente. Por desgracia, algunas aplicaciones tienen un solo subproceso o están limitadas a una cantidad fija de trabajadores o subprocesos, lo que hace que este experimento sea imposible sin una refactorización completa de su arquitectura.

Establece las solicitudes y los límites de recursos adecuados

Comprende la capacidad de tu aplicación para determinar qué configurar en los recursos de tu contenedor. Los recursos en Kubernetes se definen principalmente como CPU y memoria (RAM). Configura la CPU o la memoria como la cantidad necesaria para ejecutar tu aplicación mediante la solicitud spec.containers[].resources.requests.<cpu|memory> y configura el límite mediante la solicitud spec.containers[].resources.limits.<cpu|memory>.

Cuando hayas configurado las solicitudes de recursos de manera correcta, el programador de Kubernetes puede usarlas para decidir en qué nodo colocar tu Pod. Esto garantiza que los Pods se coloquen en nodos que puedan hacer que funcionen con normalidad, por lo que experimentarás mayor estabilidad y una reducción en los desperdicios de recursos. Además, definir límites de recursos ayuda a garantizar que estas aplicaciones nunca usen toda la infraestructura subyacente disponible proporcionada por los nodos de procesamiento.

Una práctica recomendada a fin de configurar tus recursos de contenedor es usar la misma cantidad de memoria para las solicitudes y los límites, y un límite de CPU mayor o no delimitado. Tomemos la siguiente implementación como ejemplo:

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 razonamiento para el patrón anterior se basa en el funcionamiento del control de la falta de recursos de Kubernetes. En resumen, los nodos se vuelven inestables cuando se agotan los recursos de procesamiento. Para evitar esta situación, kubelet supervisa y evita la falta total de estos recursos mediante la clasificación de los Pods con falta de recursos. Cuando la CPU tiene un problema, estos Pods se pueden reducir a sus solicitudes. Sin embargo, debido a que la memoria es un recurso que no se puede comprimir, cuando se agota la memoria, se debe quitar el Pod. Para evitar que se quiten los Pods y, en consecuencia, se desestabilice tu entorno, debes establecer la memoria solicitada al límite de memoria.

También puedes usar el VPA en modo de recomendación para determinar el uso de CPU y memoria de una aplicación determinada. Debido a que el VPA proporciona esas recomendaciones en función del uso de tu aplicación, te recomendamos que la habilites en un entorno similar al de producción para enfrentar el tráfico real. Luego, el estado del VPA genera un informe con las solicitudes y los límites de recursos sugeridos, que puedes especificar de forma estática en el manifiesto de implementación. Si tu aplicación ya define el HPA, consulta Combina el HPA y el VPA.

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

Cuando ejecutas aplicaciones en contenedores, es importante seguir algunas prácticas para compilar esos contenedores. Cuando ejecutas esos contenedores en Kubernetes, algunas de estas prácticas son aún más importantes porque tu aplicación puede iniciarse y detenerse en cualquier momento. Esta sección se enfoca en gran medida en las dos siguientes prácticas:

  • Tener la imagen más pequeña posible. Se recomienda tener imágenes pequeñas porque cada vez que el escalador automático del clúster aprovisiona un nodo nuevo 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.

  • Iniciar la aplicación lo más rápido posible. Algunas aplicaciones pueden tardar minutos en iniciarse debido a la carga de la clase, el almacenamiento en caché, etcétera. Cuando un Pod requiere un inicio prolongado, las solicitudes de los clientes pueden fallar mientras se inicia la aplicación.

Ten en cuenta estas dos prácticas cuando diseñes tu sistema, en especial si esperas aumentos repentinos de actividad. Tener una imagen pequeña y un inicio rápido te ayudan a reducir la latencia del escalamiento vertical. En consecuencia, puedes manejar mejor los aumentos de tráfico sin preocuparte demasiado por la inestabilidad. Estas prácticas funcionan mejor con las prácticas recomendadas de ajuste de escala automático que se analizan en Ajuste de escala automático de GKE.

Si deseas obtener más información sobre cómo compilar contenedores, consulta Prácticas recomendadas para compilar contenedores.

Agrega un presupuesto de interrupción de Pods a tu aplicación

El presupuesto de interrupción de Pods (PDB) limita la cantidad de Pods que se pueden quitar de manera simultánea de una interrupción involuntaria. Eso significa que el presupuesto de interrupción definido se respeta en los lanzamientos, las actualizaciones de nodos y cualquier actividad de ajuste de escala automático. Sin embargo, este presupuesto no puede garantizarse cuando ocurre algo involuntario, como una falla de hardware, un kernel panic o la eliminación de una VM por error.

Cuando el PDB se respeta durante la fase de compactación del escalador automático del clúster, se recomienda definir un presupuesto de interrupción del Pod para cada aplicación. De esta manera, puedes controlar la cantidad mínima de réplicas necesarias para admitir tu carga en cualquier momento, incluso cuando el CA reduce la escala de tu clúster.

A fin de obtener más información, consulta Especificando un presupuesto de disrupción para tu aplicación.

Establece sondeos de preparación y funcionamiento significativos para tu aplicación

Configurar sondeos significativos garantiza que tu aplicación reciba tráfico solo cuando esté en ejecución y lista para aceptar tráfico. GKE usa sondeos de preparación para determinar cuándo agregar o quitar Pods de los balanceadores de cargas. GKE usa sondeos de capacidad de respuesta para determinar cuándo reiniciar los Pods.

El sondeo de capacidad de respuesta es útil para indicarle a Kubernetes que un Pod determinado no puede avanzar, por ejemplo, cuando se detecta un estado de interbloqueo. El sondeo de preparación es útil a fin de indicarle a Kubernetes que tu aplicación no está lista para recibir tráfico, por ejemplo, mientras se cargan datos de caché grandes en el inicio.

Para garantizar el ciclo de vida adecuado de tu aplicación durante las actividades de escalamiento vertical, es importante hacer lo siguiente:

  • Define el sondeo de preparación para todos tus contenedores.
  • Si tu aplicación depende de que se cargue una caché en el inicio, el sondeo de preparación debe indicar que está lista solo después de que la caché esté completamente cargada.
  • Si tu aplicación puede comenzar a entregar de inmediato, una buena implementación de sondeo predeterminada puede ser lo más simple posible, por ejemplo, un extremo HTTP que muestra un código de estado 200.
  • Si implementas un sondeo más avanzado, como verificar si el grupo de conexiones tiene recursos disponibles, asegúrate de que tu tasa de error no aumente en comparación con una implementación más simple.
  • Nunca hagas que una lógica de sondeo acceda a otros servicios. Puede poner en riesgo el ciclo de vida del Pod si estos servicios no responden de inmediato.

Para obtener más información, consulta Configure Liveness, Readiness and Startup Probes (Configura sondeos de inicio, preparación y capacidad de respuesta).

Asegúrate de que las aplicaciones se cierren de acuerdo con las expectativas de Kubernetes

Para ayudarte a responder a los aumentos, los escaladores automáticos activan Pods y nodos nuevos y los borran cuando terminan los aumentos. Eso significa que, a fin de evitar errores durante la entrega, los Pods deben estar preparado para un inicio rápido o un cierre controlado.

Debido a que Kubernetes actualiza los extremos y los balanceadores de cargas de forma asíncrona, es importante seguir estas prácticas recomendadas para garantizar que no haya cierres no disruptivos:

  • No dejes de aceptar solicitudes nuevas de forma inmediata después de SIGTERM. Tu aplicación no debe detenerse de inmediato, sino terminar todas las solicitudes que están en tránsito y seguir escuchando las conexiones entrantes que lleguen después de que comience la finalización del Pod. Kubernetes puede tardar un tiempo en actualizar todos los kube-proxies y los balanceadores de cargas. Si tu aplicación finaliza antes de que se actualicen, es posible que algunas solicitudes causen errores al 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 administras un sistema sobre el que no tienes control, como nginx, el hook preStop es una buena opción para activar un cierre controlado sin modificar la aplicación. Una estrategia común es ejecutar, en el hook preStop, una suspensión de unos segundos para posponer SIGTERM. Esto le brinda a Kubernetes tiempo adicional para finalizar el proceso de eliminación del Pod y reduce los errores de conexión del lado del cliente.
  • Maneja SIGTERM para realizar limpiezas. Si la aplicación debe realizar una limpieza o tiene un estado en la memoria que debe conservarse antes de que finalice el proceso, este es el momento de hacerlo. Los diferentes lenguajes de programación tienen diferentes maneras de captar esta señal, por lo que debes encontrar la manera adecuada en tu lenguaje.
  • Configura terminationGracePeriodSeconds para que se adapte a las necesidades de tu aplicación. Algunas aplicaciones necesitan más que los 30 segundos predeterminados para finalizar. En este caso, debes especificar terminationGracePeriodSeconds. Los valores altos pueden aumentar el tiempo de los lanzamientos o las actualizaciones de los nodos, por ejemplo. Es posible que los valores bajos no permitan tiempo suficiente para que Kubernetes termine el proceso de finalización del Pod. De cualquier manera, te recomendamos que establezcas el período de finalización de tu aplicación en menos de 10 minutos, ya que el escalador automático del clúster lo respeta solo por 10 minutos.
  • Si tu aplicación usa el balanceo de cargas nativo del contenedor, el sondeo de preparación comienza a fallar cuando recibas un SIGTERM. Esta acción indica directamente a los balanceadores de cargas que dejen de reenviar solicitudes nuevas al Pod del backend. Según la carrera entre la configuración de la verificación de estado y la programación de extremos, el Pod del backend podría alejarse del tráfico con anterioridad.

Para obtener más información, consulta las Prácticas recomendadas de Kubernetes: Finalización controlada.

Configura NodeLocal DNSCache

El DNS administrado por GKE se implementa mediante kube-dns, un complemento implementado en todos los clústeres de GKE. Cuando ejecutas aplicaciones con falta de DNS, la configuración predeterminada de kube-dns-autoscaler, que ajusta la cantidad de réplicas de kube-dns según la cantidad de nodos y núcleos del clúster, podría no ser suficiente. En esta situación, las consultas de DNS pueden retrasarse o agotarse. Para mitigar este problema, las empresas están acostumbradas a configurar el ConfigMap kube-dns-autoscaler a fin de aumentar la cantidad de réplicas de kube-dns en sus clústeres. Aunque esta estrategia puede funcionar como se espera, aumenta el uso de recursos y el costo total de GKE.

Otra alternativa con optimización de costos y más escalable es configurar NodeLocal DNSCache en tu clúster. NodeLocal DNSCache es un complemento opcional de GKE que mejora la latencia de búsqueda de DNS, hace que los tiempos de búsqueda de DNS sean más coherentes y reduce la cantidad de consultas de DNS a kube-dns mediante la ejecución de una caché de DNS en cada nodo del clúster.

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

Usa el balanceo de cargas nativo del contenedor mediante Ingress

El balanceo de cargas nativo del contenedor permite que los balanceadores de cargas se orienten directamente a Pods de Kubernetes y distribuyan el tráfico de manera uniforme a los Pods mediante un modelo de datos llamado grupos de extremos de red (NEG). Con este enfoque, se mejora el rendimiento de la red, se aumenta la visibilidad, se habilitan las funciones avanzadas del balanceo de cargas y se habilita el uso de Traffic Director, el plano de control de tráfico completamente administrado de Google Cloud para la malla de servicios.

Debido a estos beneficios, el balanceo de cargas nativo del contenedor es la solución recomendada para el balanceo de cargas mediante Ingress. Cuando los NEG se usan con Ingress de GKE, el controlador de Ingress facilita la creación de todos los aspectos del balanceador de cargas L7. Esto incluye la creación de la dirección IP virtual, las reglas de reenvío, las verificaciones de estado, las reglas de firewall y mucho más.

El balanceo de cargas nativo del contenedor se vuelve aún más importante cuando se usa el escalador automático del clúster. Para los balanceadores de cargas ajenos a NEG, durante la reducción de escala, la programación del balanceo de cargas y el vaciado de conexiones pueden no completarse en su totalidad antes de que el escalador automático del clúster finalice las instancias del nodo. Esto puede interrumpir las conexiones en curso que fluyen a través del nodo, incluso cuando los Pods del backend no están en el nodo.

El balanceo de cargas nativo del contenedor está habilitado de forma predeterminada para los objetos Service cuando se cumplen todas las condiciones a continuación:

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

Para obtener más información, consulta la documentación de Ingress de GKE y Usa el balanceo de cargas nativo del contenedor.

Considera usar reintentos con retirada exponencial

En arquitecturas de microservicios que se ejecutan en Kubernetes, las fallas transitorias pueden ocurrir por varias razones, por ejemplo:

Estos problemas son efímeros y puedes mitigarlos si llamas de nuevo al servicio después de una demora. Sin embargo, para evitar abrumar el servicio de destino con solicitudes, es importante que ejecutes estas llamadas mediante una retirada exponencial.

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

Es importante planificar que tu aplicación admita los reintentos de llamadas de servicio, por ejemplo, para evitar la inserción de información que ya se agregó. Ten en cuenta que una cadena de reintentos podría afectar la latencia de tu usuario final, lo que podría agotar el tiempo de espera si no se planifica de manera adecuada.

Supervisa tu entorno y aplica opciones de configuración y prácticas de optimización de los costos

En muchas empresas medianas y grandes, un equipo de infraestructura y plataforma centralizada suele ser el responsable de crear, mantener y supervisar los clústeres de Kubernetes de toda la empresa. Esto representa una necesidad significativa de tener responsabilidad en el uso de los recursos y garantizar que todos los equipos cumplan con las políticas de la empresa. En esta sección, se abordan las opciones para supervisar y aplicar prácticas relacionadas con los costos.

Observa tus clústeres de GKE y busca recomendaciones

Para verificar el uso de recursos en un clúster de Kubernetes, examina los contenedores, los Pods y los servicios y las características generales del clúster. Hay muchas formas de realizar esta tarea, pero el enfoque inicial que recomendamos es observar tus clústeres de GKE a través del panel de supervisión. Esto te da datos de series temporales sobre cómo se usa tu clúster, lo que te permite agregar y abarcar desde la infraestructura, las cargas de trabajo y los servicios.

Si bien este es un buen punto de partida, Google Cloud ofrece otras opciones, por ejemplo:

  • En Cloud Console, en la página Clústeres de GKE, consulta la columna Notificaciones. Si tienes un desperdicio alto de recursos en un clúster, la IU te dará una sugerencia de la información general asignada en comparación con la solicitada.

    Ir a Lista de clústeres de GKE

  • En Cloud Console, en la página Recomendaciones, busca tarjetas de recomendaciones de Ahorro de costos.

    Ir al Centro de recomendaciones

Para obtener más detalles, consulta Observa tus clústeres de GKE y Comienza a usar el centro de recomendaciones.

Habilitar la medición del uso de GKE

Para obtener un enfoque más flexible que te permita ver desgloses de costos aproximados, prueba la medición del uso de GKE. La medición del uso de GKE te permite ver los perfiles de uso de tus clústeres de GKE desglosados por espacios de nombres y etiquetas. Realiza un seguimiento de 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, de forma opcional, la salida de red.

La medición del uso de GKE te ayuda a comprender la estructura de costos general de los clústeres de GKE, cuál es el equipo o la aplicación que más gasta, qué entorno o componente causó un aumento repentino en el uso o los costos y qué equipo genera mucho desperdicio. Cuando comparas las solicitudes de recursos con el uso real, puedes obtener información sobre qué cargas de trabajo están aprovisionadas de forma insuficiente o en exceso.

Puedes aprovechar las plantillas predeterminadas de Data Studio o ir un paso más allá y personalizar los paneles según tus necesidades organizativas. Para obtener más información sobre la medición del uso de GKE y sus requisitos, consulta Obtén información sobre el uso de recursos del clúster.

Obtén información sobre el funcionamiento del servidor de métricas y supervísalo

El servidor de métricas es la fuente de las métricas de recursos del contenedor para las canalizaciones de ajuste de escala automático integradas en GKE. El servidor de métricas recupera las métricas de kubelets y las expone a través de la API de Metrics de Kubernetes. El HPA y el VPA usan estas métricas para determinar cuándo activar el ajuste de escala automático.

Para el estado del ajuste de escala automático de GKE, debes tener un servidor de métricas en buen estado. Con la implementación de metrics-server de GKE, se instala un asistente de cambio de tamaño, lo que hace que el contenedor del servidor de métricas se escale de manera vertical si se agrega o se quita CPU y memoria según el recuento del nodo del clúster. La actualización local de Pods aún no es compatible con Kubernetes, por lo que el asistente debe reiniciar el Pod de metrics-server para aplicar los recursos nuevos necesarios.

Aunque el reinicio ocurre con rapidez, la latencia total para que los escaladores automáticos se den cuenta de que deben actuar puede aumentar un poco después de cambiar el tamaño de metrics-server. Para evitar reinicios frecuentes del servidor de métricas en clústeres que cambian con rapidez, a partir de GKE 1.15.11-gke.9, el asistente admite demoras de cambio de tamaño.

Sigue estas prácticas recomendadas cuando uses el servidor de métricas:

  • Elige la versión de GKE que admite demoras en el cambio de tamaño de metrics-server. Para confirmarlo, verifica si el archivo YAML de implementación metrics-server tiene la configuración scale-down-delay en el contenedor metrics-server-nanny.
  • Supervisa la implementación de metrics-server. Si el servidor de métricas no está en funcionamiento, significa que el ajuste de escala automático no funciona. Necesitas servicios de supervisión de prioridad superior para supervisar esta implementación.
  • Sigue las recomendaciones que se analizan en Ajuste de escala automático de GKE.

Usa cuotas de recursos de Kubernetes

En los clústeres de usuarios múltiples, los distintos equipos suelen convertirse en responsables de las aplicaciones implementadas en diferentes espacios de nombres. Para un grupo de infraestructura y plataforma centralizada, es preocupante que un equipo use más recursos de los necesarios. Quitar todos los recursos de procesamiento de los clústeres o incluso activar demasiados escalamientos verticales puede aumentar tus costos.

Para abordar este problema, debes usar cuotas de recursos. Las cuotas de recursos administran la cantidad de recursos que usan los objetos en un espacio de nombres. Puedes establecer cuotas en cuanto a los recursos de procesamiento (CPU y memoria) y almacenamiento, o el recuentos de objetos. Con las cuotas de recursos, te aseguras de que ningún usuario usará más de lo que se le asigna de los recursos de clúster.

A fin de obtener más información, consulta Configura cuotas de memoria y CPU para un espacio de nombres.

Considera usar el controlador de políticas de Anthos

El controlador de políticas de Anthos (APC) es un controlador de admisión dinámico de Kubernetes que verifica, audita y aplica el cumplimiento de tus clústeres con las políticas relacionadas con las reglas de seguridad, las normativas o las reglas comerciales arbitrarias. El controlador de políticas usa restricciones para aplicar el cumplimiento de los clústeres. Por ejemplo, puedes instalar en las restricciones de tu clúster muchas de las prácticas recomendadas que se analizan en la sección Prepara tu aplicación de Kubernetes basada en la nube. De esta manera, las implementaciones se rechazan si no cumplen de manera estricta con tus prácticas de Kubernetes. La aplicación de esas reglas ayuda a evitar aumentos inesperados en los costos y reduce las posibilidades de experimentar inestabilidad de las cargas de trabajo durante el ajuste de escala automático.

Para obtener más información sobre cómo aplicar y escribir tus propias reglas, consulta Crea limitaciones y Escribe una plantilla de limitación. Si no eres cliente de Anthos, puedes usar Gatekeeper, el software de código abierto en el que se compila el APC.

Diseña tu canalización de CI/CD a fin de aplicar prácticas para ahorrar costos

El controlador de políticas de Anthos te ayuda a evitar la implementación de software no compatible en tu clúster de GKE. Sin embargo, recomendamos que apliques estas restricciones de políticas al comienzo de tu ciclo de desarrollo, en verificaciones de confirmación previa, verificaciones de solicitudes de extracción, flujos de trabajo de entrega o cualquier paso que sea significativo en tu entorno. Esta práctica te permite encontrar y corregir las opciones de configuración incorrectas con rapidez y te ayuda a obtener información sobre a qué debes prestar atención mediante la creación de recursos de seguridad.

También considera usar funciones de kpt en tu canalización de CI/CD para validar si tus archivos de configuración de Kubernetes cumplen con las restricciones aplicadas por el controlador de políticas de Anthos y estimar el uso de recursos o el costo de implementación. De esta manera, puedes detener la canalización cuando se detecta un problema relacionado con el costo. O bien, puedes crear un proceso de aprobación de implementación diferente para las opciones de configuración que, por ejemplo, aumenten la cantidad de réplicas.

Para obtener más información, consulta Usa el controlador de políticas en una canalización de CI y, para ver un ejemplo completo de una plataforma de entrega, consulta Modern CI/CD with Anthos (CI/CD modernas con Anthos).

Difunde la cultura del ahorro de costos

Muchas organizaciones crean abstracciones y plataformas para ocultarte la complejidad de la infraestructura. Esta es una práctica común en las empresas que migran 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 común ver desarrolladores que nunca tocaron un clúster de Kubernetes.

Las prácticas recomendadas de esta sección no implican que debas dejar de realizar abstracciones por completo. Por otro lado, te ayudan a ver tus gastos en Google Cloud y entrenar a los desarrolladores y los operadores en tu infraestructura. Puedes hacerlo mediante la creación de incentivos y programas de aprendizaje en los que puedas usar clases tradicionales o en línea, grupos de discusión, evaluaciones entre compañeros, programación en pareja, ludificaciones para ahorrar costos y CI/CD y mucho más. Por ejemplo, en el mundo de Kubernetes, es importante comprender el impacto de una aplicación de imagen de 3 Gb, un sondeo de preparación faltante o una configuración incorrecta del HPA.

Por último, como se muestra en la investigación de DORA de Google, las capacidades culturales son algunos de los factores principales que impulsan un mejor rendimiento de la organización, menos repeticiones de trabajo, menos agotamiento, etcétera. El ahorro de costos no es diferente. Otorgar a tus empleados acceso a sus gastos los alinea más con los objetivos y las limitaciones empresariales.

Resumen de prácticas recomendadas

En la siguiente tabla, se resumen las prácticas recomendadas de este documento.

Tema Tarea
Funciones y opciones de optimización de costos de GKE
Prepara tus aplicaciones de Kubernetes nativas de la nube
Supervisa tu entorno y aplica opciones de configuración y prácticas de optimización de los costos
Cultura

¿Qué sigue?