🥇Revisión de Kubecost para ahorrar dinero en Kubernetes en la nube

Actualmente, cada vez más empresas están trasladando su infraestructura de servidores físicos y máquinas virtuales propias a la nube. Esta decisión es fácil de explicar: no hay necesidad de preocuparse por el hardware, el clúster se puede configurar de muchas maneras diferentes... y lo más importante, las tecnologías existentes (como Kubernetes) permiten escalar fácilmente la capacidad de cómputo según la carga.

Siempre es importante el aspecto financiero. La herramienta de la que se hablará en este artículo está diseñada para ayudar a reducir presupuestos al utilizar infraestructura en la nube con Kubernetes.

Introducción

Kubecost — una startup californiana creada por ex-empleados de Google, desarrollando una solución para calcular costos de infraestructura en servicios en la nube (dentro del clúster de Kubernetes + recursos comunes), detectar cuellos de botella en la configuración del clúster y enviar notificaciones correspondientes a Slack.

Tenemos clientes con Kubernetes tanto en las nubes comunes AWS y GCP, como en la menos común comunidad de Linux Azure; en general, en todas las plataformas soportadas por Kubecost. Para algunos de ellos, calculamos los costos de los servicios intra-clúster de forma independiente (usando un método similar al de Kubecost), así como monitoreamos los gastos de infraestructura y buscamos optimizarlos. Por lo tanto, tiene sentido que estemos interesados en la posibilidad de automatizar estas tareas.

El código fuente del módulo principal de Kubecost está disponible bajo una licencia de código abierto (Apache License 2.0). Se puede utilizar libremente, y las funciones disponibles deberían ser suficientes para proyectos pequeños. Sin embargo, el negocio es negocio: el resto del producto es cerrado y se puede acceder mediante suscripciones de pago, que también incluyen soporte comercial. Además, los autores ofrecen una licencia gratuita para clústeres pequeños (1 clúster con 10 nodos; al momento de escribir este artículo, este límite se ha ampliado a 20 nodos) o un período de prueba con todas las funcionalidades durante 1 mes.

Cómo funciona todo

Así, la parte principal de Kubecost es una aplicación cost-model, escrita en Go. El chart de Helm que describe todo el sistema en su totalidad se llama cost-analyzer , y en esencia, es un conjunto de cost-model con Prometheus, Grafana y varios dashboards.

En general, el modelo de costos tiene su propia interfaz web que muestra gráficos y estadísticas detalladas sobre los gastos en forma de tabla, así como, por supuesto, consejos para optimizar los costos. Los paneles presentados en Grafana son una etapa más temprana en el desarrollo de Kubecost y contienen en gran medida los mismos datos que el modelo de costos, complementándolos con estadísticas habituales sobre el uso de CPU/memoria/red/espacio en disco en el clúster y sus componentes.

¿Cómo funciona Kubecost?

El modelo de costos obtiene precios de servicio a través de la API de proveedores de la nube.
Luego, en función del tipo de hardware del nodo y la región, se calcula el costo por nodos.
Sobre la base del costo de operación de los nodos, cada pod final recibe un costo por hora de uso del procesador, consumo de un gigabyte de memoria y costo por hora de almacenamiento de un gigabyte de datos, dependiendo del nodo en el que ha trabajado o la clase de almacenamiento.
A partir del costo de operación de los pods individuales, se calcula el pago por namespaces, servicios, deployments, stateful sets.
Para calcular las estadísticas se utilizan métricas proporcionadas por kube-state-metrics y node-exporter.

Es importante tener en cuenta que Kubecost por defecto solo considera los recursos disponibles en Kubernetes. Bases de datos externas, servidores de GitLab, almacenamiento S3 y otros servicios que no están en el clúster (aunque estén en la misma nube), no son visibles para él. Sin embargo, para GCP y AWS se pueden agregar claves de sus cuentas de servicio y calcular todo junto.

Instalación

Para el funcionamiento de Kubecost se requieren:

Kubernetes versión 1.8 y superior;
kube-state-metrics;
Prometheus;
node-exporter.

Resultó que en nuestros clústeres se cumplían todas estas condiciones de antemano, por lo que solo fue necesario especificar el endpoint correcto para acceder a Prometheus. Sin embargo, el chart oficial de Helm de kubecost contiene todo lo necesario para iniciarse incluso en un clúster 'en bruto'.

Se puede instalar Kubecost de varias maneras:

El método estándar de instalación, descrito en la guía en el sitio del desarrollador. Es necesario agregar el repositorio de Helm cost-analyzer, después de lo cual se instalará el chart. Solo queda redirigir un puerto y ajustar la configuración a su estado deseado manualmente (a través de kubectl) y/o con la ayuda de la interfaz web del modelo de costos.
No hemos probado este método ya que no utilizamos configuraciones de terceros, pero parece una buena opción para "simplemente probarlo por uno mismo". Si ya tiene algunos componentes del sistema instalados o desea una configuración más precisa, es mejor considerar la segunda opción.
Usar, en esencia, la misma chart, pero configurarlo e instalarlo uno mismo de cualquier forma conveniente.
Como se mencionó anteriormente, además del propio kubecost, esta chart contiene charts de Grafana y Prometheus, que también se pueden configurar a tu gusto.
El chart disponible values.yaml para cost-analyzer permite configurar:
- la lista de componentes del cost-analyzer que se deben desplegar;
- tu endpoint para Prometheus (si ya lo tienes);
- dominios y otras configuraciones de ingress para cost-model y Grafana;
- anotaciones para los pods;
- la necesidad de usar almacenamiento persistente y su tamaño.
Hay una lista completa de opciones de configuración disponibles con descripciones en la documentación.
Dado que kubecost, en su versión básica, no puede restringir el acceso, será necesario configurar basic-auth para el panel web de inmediato.
Instalar solo el núcleo del sistema — cost-model. Para esto, es necesario tener Prometheus instalado en el clúster y especificar su dirección correspondiente en la variable prometheusEndpoint para Helm. Después de esto, debes aplicar un conjunto de configuraciones en YAML en el clúster.
De nuevo, tendrás que agregar manualmente Ingress con basic-auth. Y finalmente, será necesario agregar una sección para recolectar métricas del cost-model en extraScrapeConfigs en la configuración de Prometheus:
```
- job_name: kubecost
  honor_labels: true
  scrape_interval: 1m
  scrape_timeout: 10s
  metrics_path: /metrics
  scheme: http
  dns_sd_configs:
  - names:
    - 
    type: 'A'
    port: 9003
```

¿Qué obtenemos?

Con una instalación completa, se dispone del panel web de kubecost y Grafana con un conjunto de dashboards.

Costo total, que se muestra en la pantalla principal, muestra efectivamente el costo calculado de los recursos por mes. Este es un pronóstico del precio, que refleja el costo de usar el clúster (por mes) al nivel actual de consumo de recursos.

Esta métrica es más para analizar gastos y optimizarlos. Ver los gastos totales para un julio abstracto en kubecost no es muy conveniente: para eso tendrás que ir a la facturación.Sin embargo, puedes ver los gastos desglosados por espacios de nombres, etiquetas, pods para 1/2/7/30/90 días, lo cual la facturación nunca te mostrará.

Hablando de etiquetas. Es recomendable ingresar de inmediato a la configuración y establecer los nombres de las etiquetas que se utilizarán como categorías adicionales para agrupar los gastos:

Se pueden asignar cualquier etiqueta a ellas, lo cual es conveniente si ya tienes tu propio sistema de etiquetado.

También se puede cambiar la dirección del endpoint de la API al que se conecta el modelo de costos, ajustar el tamaño del descuento en GCP y establecer los precios propios de los recursos y la moneda para su medición (esta función, curiosamente, no afecta al costo total).

Kubecost puede mostrar varios problemas en el clúster (e incluso alertar en caso de peligro). Lamentablemente, la opción no es configurable, por lo que, si tienes entornos para desarrolladores y se utilizan, se podrá observar continuamente algo similar a esto:

Una herramienta importante es Cluster Savings. Mide la actividad de los pods (consumo de recursos, incluida la red), así como calcula cuánto dinero se puede ahorrar y en qué.

Puede parecer que los consejos de optimización son bastante obvios, sin embargo, la experiencia indica que siempre hay algo a lo que prestar atención. En particular, se rastrea la actividad de la red de los pods (Kubecost sugiere prestar atención a los inactivos), se compara el consumo de memoria y CPU solicitado y real, así como la CPU utilizada por los nodos del clúster (sugiere consolidar varios nodos en uno), la carga en los discos y un par de docenas de parámetros más.

Como en cualquier asunto relacionado con la optimización, la optimización de recursos basada en los datos de Kubecost debe ser abordada con precaución. Por ejemplo, Cluster Savings sugiere eliminar nodos, afirmando que es seguro, sin embargo, no tiene en cuenta la presencia de pods desplegados en ellos con selectores de nodo y taints que no están en otros nodos. Además, incluso los autores del producto en su un artículo reciente (por cierto, puede ser bastante útil para aquellos interesados en el tema del proyecto) recomiendan no lanzarse de cabeza a la optimización de gastos, sino abordar el asunto de manera reflexiva.

Resultados

Después de usar Kubecost durante un mes en un par de proyectos, podemos concluir que es una herramienta interesante (además, fácil de aprender e instalar) para el análisis y optimización de gastos en servicios de proveedores de nube utilizados para clústeres de Kubernetes. Los cálculos resultan ser bastante precisos: en nuestros experimentos coincidían con lo que realmente requerían los proveedores.

También hay desventajas: hay errores no críticos y las funcionalidades a veces no cubren las necesidades específicas de algunos proyectos. Sin embargo, si necesitas entender rápidamente a dónde va el dinero y qué se puede "recortar" para reducir de manera estable la factura de servicios en la nube en un 5-30% (como sucedió en nuestro caso), esta es una excelente opción.

P.D.

También puedes leer en nuestro blog:

Fuente: habr.com