¿Qué es el Helm chart de Kubecost?
Puedes instalar Kubecost usando el Helm chart oficial a través del repositorio cost-analyzer. Este chart es un paquete para desplegar Kubecost en un clúster de Kubernetes con Helm. Define los recursos de Kubernetes que Kubecost necesita, como deployments, services, configuración y componentes relacionados. Helm gestiona estos recursos como un solo release, lo que facilita instalar, actualizar, configurar y eliminar Kubecost.
Qué incluye el chart:
El Helm chart de Kubecost empaqueta los recursos de Kubernetes y las dependencias configurables necesarias para ejecutar Kubecost. Según los valores configurados, esto puede incluir los componentes de la aplicación Kubecost, la integración con Prometheus, componentes de métricas de Kubernetes, almacenamiento persistente, Services e Ingress, recursos de monitoreo, recolección de costos de red, políticas de red e integraciones de precios de proveedores de nube.
Buenas prácticas de configuración:
- Fija las versiones del Helm chart de Kubecost: Especifica una versión explícita del chart para mantener despliegues predecibles y evitar cambios inesperados en releases más recientes.
- Mantén los valores de Helm en control de versiones: Guarda los overrides de configuración en un archivo
values.yamlversionado, manteniendo las credenciales y otros secretos fuera del repositorio. - Usa archivos de valores separados para cada entorno: Mantén configuraciones específicas para desarrollo, staging y producción en lugar de duplicar o modificar los manifiestos del chart.
- Define requests y límites de recursos adecuados: Dimensiona la CPU y la memoria de los componentes de Kubecost según la escala del clúster y ajústalas con base en el consumo real observado.
- Configura almacenamiento persistente para producción: Elige una capacidad de volumen persistente adecuada y una StorageClass confiable según los requisitos de retención, crecimiento, respaldo y recuperación.
- Prueba las actualizaciones de Helm antes de producción: Valida las nuevas versiones del chart y tus valores personalizados en un entorno que no sea de producción y mantén una ruta de rollback probada.
En este artículo:
- Los dos Helm charts de Kubecost: cost-analyzer vs. kubecost
- Qué incluye el Helm chart
- Cómo instalar Kubecost con Helm
- Helm chart de Kubecost vs. manifiestos de Kubernetes
- Buenas prácticas para el Helm chart de Kubecost
Los dos Helm charts de Kubecost: cost-analyzer vs. kubecost
Actualmente, Kubecost tiene dos líneas de Helm charts con las que los administradores pueden toparse: el chart cost-analyzer, más antiguo, usado en despliegues de Kubecost 2.x, y el nuevo chart kubecost, presentado con Kubecost 3.x. El repositorio actual de Kubecost identifica la versión 2.8 como el último release con funcionalidades nuevas de la línea 2.x, la versión 2.9 como un paso intermedio de actualización y la versión 3.0 como el primer release de Kubecost 3.x.
El chart cost-analyzer es el método de despliegue heredado usado durante toda la línea Kubecost 2.x. Los entornos existentes pueden seguir haciendo referencia a comandos como kubecost/cost-analyzer, y Kubecost aún mantiene repositorios asociados a ese chart para despliegues antiguos y escenarios de actualización.
Para Kubecost 3.x, el chart principal ahora se llama kubecost. Las instalaciones nuevas usan el chart kubecost/kubecost del repositorio de Helm de Kubecost. Kubecost 3.x también introduce cambios arquitectónicos importantes, como el almacenamiento basado en ClickHouse y un nuevo finops-agent que reemplaza al agente cost-model usado en 2.x.
Por lo tanto, las organizaciones que actualicen un despliegue existente de Kubecost 2.x deberían tratar el cambio como algo más que un simple cambio de nombre del chart. Kubecost recomienda actualizar los agentes a la versión 2.9 antes de pasar a 3.x, dejando que la versión intermedia funcione durante un tiempo antes de completar la migración. También conviene revisar los valores existentes de cost-analyzer en lugar de asumir que se corresponden directamente con el nuevo chart kubecost, porque los nombres de componentes, la arquitectura de almacenamiento y las opciones de configuración cambiaron.
Qué incluye el Helm chart
El Helm chart de Kubecost incluye las plantillas de Kubernetes y las dependencias configurables necesarias para ejecutar Kubecost. Los recursos exactos que se despliegan dependen de la versión del chart y de los valores que habilites, pero en general el chart cubre los siguientes componentes:
- Componentes de la aplicación Kubecost: Deployments, Services, ConfigMaps, Secrets, service accounts y otros recursos necesarios para ejecutar Kubecost y exponer su funcionalidad de monitoreo de costos.
- Recolección de métricas (
finops-agent): El chart despliega elfinops-agent, un agente ligero que recopila las métricas del clúster que Kubecost usa para la asignación de costos, sin necesidad de un despliegue separado de Prometheus. - Componentes de métricas de Kubernetes: Según la configuración, el chart puede desplegar componentes de apoyo como
kube-state-metricsy Node Exporter, que proporcionan métricas de objetos de Kubernetes y a nivel de nodo. - Almacenamiento persistente: Los valores de Helm pueden crear persistent volume claims para los datos de Kubecost y Prometheus, con tamaños de almacenamiento y storage classes configurables.
- Configuración de Ingress y services: El chart ofrece opciones para exponer Kubecost mediante Services de Kubernetes y, cuando se habilita, un Ingress con hosts, rutas, anotaciones y configuración de TLS personalizables.
- Recursos de monitoreo: Se pueden crear recursos opcionales como
ServiceMonitoryPrometheusRulepara entornos que usan el Prometheus Operator. - Funcionalidades e integraciones opcionales: Los valores de Helm permiten habilitar funcionalidades adicionales como la recolección de costos de red, políticas de red, integraciones de precios de proveedores de nube y otras funciones de Kubecost sin modificar manualmente los manifiestos de Kubernetes generados.
Como estos componentes se controlan a través del values.yaml del chart, las organizaciones pueden habilitar solo los recursos que necesitan o integrar Kubecost con los componentes de monitoreo e infraestructura que ya existen en el clúster.
Contenido relacionado: Lee nuestra guía sobre optimización de costos de Kubernetes
Cómo instalar Kubecost con Helm
Kubecost se puede instalar con Helm agregando el repositorio oficial de charts de Kubecost y desplegando el chart en un namespace dedicado. El repositorio actual de Helm charts de Kubecost proporciona el chart kubecost/kubecost para Kubecost 3.x.
Primero, agrega el repositorio de Helm de Kubecost y actualiza tu índice local de charts:
helm repo add kubecost https://kubecost.github.io/kubecost/helm repo updateLuego instala Kubecost en un namespace kubecost:
helm install kubecost kubecost/kubecost \ --namespace kubecost \ --create-namespaceKubecost también permite instalar directamente desde la URL del repositorio. El ejemplo oficial establece global.clusterId para identificar el clúster:
helm install kubecost \ --repo https://kubecost.github.io/kubecost kubecost \ --namespace kubecost \ --create-namespace \ --set global.clusterId=my-clusterAntes de desplegar en producción, puedes inspeccionar los valores que admite una versión específica del chart:
helm show values kubecost/kubecost --version <chart-version>Después puedes colocar la configuración necesaria en un archivo values.yaml personalizado e instalar Kubecost con:
helm install kubecost kubecost/kubecost \ --namespace kubecost \ --create-namespace \ --values values.yamlUsar un archivo de valores facilita versionar y reproducir la configuración de aspectos como el almacenamiento, la asignación de recursos, el monitoreo y los componentes de Kubecost. El repositorio oficial de Kubecost también recomienda verificar la compatibilidad entre versiones del chart y de Kubernetes al elegir un release; por ejemplo, los charts de Kubecost 3.0 están pensados para versiones de Kubernetes más recientes que los últimos releases de Kubecost 2.x.
Helm chart de Kubecost vs. manifiestos de Kubernetes
Tanto los Helm charts como los manifiestos de Kubernetes sirven para desplegar aplicaciones en Kubernetes, pero gestionan la configuración de manera distinta. Kubecost recomienda Helm como su método de instalación principal; su chart oficial empaqueta los recursos necesarios y expone la configuración a través de valores de Helm.
| Helm chart de Kubecost | Manifiestos de Kubernetes | |
|---|---|---|
| Despliegue | Instala Kubecost como un release de Helm usando un chart empaquetado. | Los recursos se aplican directamente con kubectl apply. |
| Configuración | Los ajustes se centralizan en values.yaml o se pasan con --set. |
La configuración se cambia editando definiciones YAML individuales. |
| Actualizaciones | Helm lleva registro del release y puede aplicar cambios de versión del chart y de configuración mediante helm upgrade. |
Los manifiestos actualizados en general deben aplicarse y mantenerse manualmente. |
| Personalización | Los valores del chart ofrecen opciones configurables para componentes, almacenamiento, Prometheus, límites de recursos y otros ajustes. | Ofrece control directo sobre cada objeto de Kubernetes, pero exige más mantenimiento manual. |
| Repetibilidad | Una versión del chart más un archivo de valores facilita reproducir el despliegue en varios clústeres. | Los equipos deben mantener y sincronizar su propia colección de manifiestos. |
| Gestión del ciclo de vida | Helm incluye instalación de releases, actualizaciones, capacidad de rollback y desinstalación. | Kubernetes gestiona recursos individuales, no el ciclo de vida de un release de Helm. |
| Ideal para | La mayoría de los despliegues de Kubecost, en particular entornos que necesitan configuración reproducible y actualizaciones continuas. | Entornos que requieren específicamente control directo sobre recursos estáticos de Kubernetes o que no pueden usar Helm. |
Históricamente, Kubecost ha ofrecido el despliegue con manifiestos estáticos como alternativa, pero su documentación recomienda Helm, sobre todo para producción. Helm también facilita personalizar dependencias y ajustes (por ejemplo, si Kubecost usa sus componentes de monitoreo integrados o la infraestructura existente) sin mantener copias modificadas de cada recurso de Kubernetes.
Buenas prácticas para el Helm chart de Kubecost
Estas son algunas prácticas útiles a tener en cuenta al trabajar con el Helm chart de Kubecost.
1. Fija las versiones del Helm chart de Kubecost
Especifica una versión explícita del chart de Kubecost en lugar de dejar que Helm instale automáticamente el último release disponible. Helm permite seleccionar una versión específica del chart con la opción --version; si la omites, puede seleccionarse la versión más reciente del chart.
Fijar versiones hace que los despliegues sean más predecibles y evita que una instalación automatizada o un pipeline de CI/CD adopte sin querer un chart más nuevo con valores predeterminados o dependencias distintas. Revisa las notas de release y los requisitos de compatibilidad de Kubecost antes de actualizar deliberadamente la versión fijada.
2. Mantén los valores de Helm en control de versiones
Guarda la configuración de Kubecost que sobrescribes en un archivo values.yaml dedicado y mantenlo en control de versiones. Los valores de Helm son el mecanismo estándar para sobrescribir los valores predeterminados del chart, incluidos los ajustes de los componentes de la aplicación, el almacenamiento, el ingress y otras opciones de despliegue.
El control de versiones proporciona un historial de cambios de configuración y facilita revisar, reproducir o revertir despliegues de Kubecost. Evita colocar credenciales u otros secretos sensibles directamente en un repositorio; en su lugar, referencia un mecanismo adecuado de gestión de secretos de Kubernetes o externo.
3. Usa archivos de valores separados para cada entorno
Mantén archivos de valores separados para desarrollo, staging y producción cuando esos entornos requieran configuraciones distintas de Kubecost. Helm está diseñado para desplegar el mismo chart con diferentes valores, lo que evita mantener copias separadas de los manifiestos de Kubernetes subyacentes.
Por ejemplo, producción puede usar volúmenes persistentes y asignaciones de recursos más grandes, mientras que un clúster de desarrollo puede funcionar con configuraciones más pequeñas. Separar los overrides por entorno también reduce el riesgo de aplicar accidentalmente configuración de desarrollo en producción.
4. Define requests y límites de recursos adecuados
Configura requests y límites de CPU y memoria para los componentes de Kubecost según el tamaño y la carga del clúster. Los requests ayudan a que Kubernetes reserve suficientes recursos para los pods de Kubecost, mientras que los límites pueden evitar que componentes individuales consuman capacidad excesiva del clúster.
Evita copiar sin más la misma configuración de recursos en clústeres de tamaños muy distintos. Monitorea el consumo real de recursos de Kubecost después del despliegue y ajusta los valores de Helm a medida que crezcan los nodos, los workloads y las métricas recopiladas.
5. Configura almacenamiento persistente para producción
Usa almacenamiento persistente para los componentes de Kubecost que necesitan conservar datos entre reinicios o reprogramaciones de pods. El chart de Kubecost expone la configuración de volúmenes persistentes, como la habilitación de la persistencia, el tamaño del volumen y la StorageClass de Kubernetes utilizada.
Para despliegues en producción, elige una StorageClass confiable y aprovisiona capacidad suficiente para el crecimiento esperado de los datos. La configuración de almacenamiento también debe alinearse con los requisitos de respaldo, retención y recuperación ante desastres de la organización.
6. Prueba las actualizaciones de Helm antes de producción
Aplica las actualizaciones del chart de Kubecost en un clúster de desarrollo o staging antes de actualizar producción. Prueba tanto la nueva versión del chart como tus valores personalizados existentes, porque las actualizaciones del chart pueden introducir nuevos ajustes, modificar valores predeterminados o cambiar recursos de Kubernetes.
Helm permite revisar y controlar los valores de una actualización, así como hacer rollback de un release a una revisión anterior cuando sea necesario. Conserva la versión anterior del chart y su configuración para contar con una ruta de rollback probada si la actualización en producción causa problemas.
Optimiza los costos de Kubernetes más allá de Kubecost con PerfectScale
PerfectScale by DoiT ofrece una optimización de costos responsable que elimina la pérdida de recursos sin afectar la estabilidad ni el rendimiento de Kubernetes. Kubecost se centra principalmente en el monitoreo de costos de Kubernetes. PerfectScale va más allá: ajusta tu entorno de forma continua para lograr un rendimiento óptimo y la mejor eficiencia de costos, y aporta mayor visibilidad y gobernanza en grupos de nodos, namespaces, contenedores y workloads. El Helm chart de Kubecost despliega y mantiene Prometheus y componentes de métricas relacionados. PerfectScale, en cambio, funciona como un único agente sin estado con una huella mínima, y no requiere Prometheus.
Capacidades clave de PerfectScale:
- Optimización autónoma de costos: Ajusta de forma autónoma tu entorno de Kubernetes con acciones integradas con GitOps, de modo que el ahorro de costos se aplica de forma continua en lugar de mostrarse solo en dashboards.
- Right-sizing integral: Ofrece recomendaciones de CPU y memoria tanto para requests como para límites. Estas recomendaciones tienen en cuenta los cambios en el código y la configuración del HPA.
- Despliegue con agente sin estado: Se instala como un único agente ligero con un mantenimiento mínimo. No hay ninguna implementación de Prometheus que configurar ni mantener.
- Visibilidad y asignación granular de costos: Proporciona visibilidad y asignación de costos, pronóstico de costos y de pérdida, y visibilidad de workloads efímeros. También muestra la asignación, la utilización y la capacidad ociosa de los nodos, soporta grupos de nodos y te permite agrupar workloads efímeros de forma personalizada.
- Detección y remediación de problemas de resiliencia: Identifica eventos OOM, throttling de CPU, posibles fugas de memoria, reinicios frecuentes, evictions y workloads que alcanzan sus límites de réplicas. También ofrece priorización automática de riesgos de resiliencia, alertas personalizables y remediación autónoma.
- Funciona dondequiera que corra Kubernetes: Soporta EKS, GKE, AKS, OpenShift y clústeres on-premises.
¿Listo para pasar del monitoreo de costos a la optimización autónoma de Kubernetes? Mira cómo se compara PerfectScale con Kubecost y comienza una prueba gratuita de 30 días.