O que é o Helm chart do Kubecost?
Você pode instalar o Kubecost usando o Helm chart oficial por meio do repositório cost-analyzer. Esse chart é um pacote para implantar o Kubecost em um cluster Kubernetes com o Helm. Ele define os recursos do Kubernetes de que o Kubecost precisa, como deployments, services, configuração e componentes relacionados. O Helm trata esses recursos como um único release, o que facilita instalar, atualizar, configurar e remover o Kubecost.
O que o chart inclui:
O Helm chart do Kubecost empacota os recursos do Kubernetes e as dependências configuráveis necessários para executar o Kubecost. Dependendo dos values configurados, isso pode incluir componentes da aplicação Kubecost, integração com Prometheus, componentes de métricas do Kubernetes, armazenamento persistente, Services e Ingress, recursos de monitoramento, coleta de custos de rede, network policies e integrações de precificação com provedores de nuvem.
Boas práticas de configuração:
- Fixe as versões do Helm chart do Kubecost: especifique uma versão explícita do chart para manter as implantações previsíveis e evitar mudanças inesperadas vindas de releases mais recentes.
- Mantenha os values do Helm em controle de versão: armazene as sobrescritas de configuração em um arquivo
values.yamlversionado, mantendo credenciais e outros segredos fora do repositório. - Use arquivos de values separados para cada ambiente: mantenha configurações específicas para desenvolvimento, staging e produção em vez de duplicar ou modificar os manifests do chart.
- Defina requests e limits de recursos adequados: dimensione as configurações de CPU e memória dos componentes do Kubecost de acordo com a escala do cluster e ajuste-as com base no consumo de recursos observado.
- Configure armazenamento persistente para produção: selecione uma capacidade de volume persistente adequada e uma StorageClass confiável com base nos requisitos de retenção, crescimento, backup e recuperação.
- Teste upgrades do Helm antes de ir para produção: valide novas versões do chart e os values personalizados existentes em um ambiente fora de produção e mantenha um caminho de rollback testado.
Neste artigo:
- Os dois Helm charts do Kubecost: cost-analyzer vs. kubecost
- O que o Helm chart inclui
- Como instalar o Kubecost com o Helm
- Helm chart do Kubecost vs. manifests do Kubernetes
- Boas práticas com o Helm chart do Kubecost
Os dois Helm charts do Kubecost: cost-analyzer vs. kubecost
O Kubecost agora tem duas linhas de Helm charts que os administradores podem encontrar: o chart cost-analyzer, mais antigo, usado nas implantações do Kubecost 2.x, e o chart kubecost, mais novo, introduzido com o Kubecost 3.x. O repositório atual do Kubecost identifica a versão 2.8 como o último release com novas funcionalidades da linha 2.x, a versão 2.9 como uma etapa intermediária de upgrade e a versão 3.0 como o primeiro release do Kubecost 3.x.
O chart cost-analyzer é o método de implantação legado usado em todo o Kubecost 2.x. Ambientes existentes podem continuar referenciando comandos como kubecost/cost-analyzer, e o Kubecost ainda mantém repositórios associados a esse chart para implantações mais antigas e cenários de upgrade.
Para o Kubecost 3.x, o chart principal agora se chama kubecost. Novas instalações usam o chart kubecost/kubecost do repositório Helm do Kubecost. O Kubecost 3.x também introduz mudanças arquiteturais significativas, incluindo armazenamento baseado em ClickHouse e um novo finops-agent, que substitui o agente cost-model usado anteriormente no 2.x.
Portanto, organizações que estão atualizando uma implantação existente do Kubecost 2.x devem tratar a migração como mais do que uma simples troca de nome do chart. O Kubecost recomenda atualizar os agentes para a versão 2.9 antes de migrar para o 3.x, dando tempo para que a versão intermediária rode antes de concluir a migração. Os values existentes do cost-analyzer também devem ser revisados, em vez de assumir que correspondem diretamente ao novo chart kubecost, porque nomes de componentes, arquitetura de armazenamento e opções de configuração mudaram.
O que o Helm chart inclui
O Helm chart do Kubecost inclui os templates do Kubernetes e as dependências configuráveis necessários para executar o Kubecost. Os recursos exatos implantados dependem da versão do chart e dos values que você habilita, mas em geral o chart cobre os seguintes componentes:
- Componentes da aplicação Kubecost: Deployments, Services, ConfigMaps, Secrets, service accounts e outros recursos necessários para executar o Kubecost e expor sua funcionalidade de monitoramento de custos.
- Coleta de métricas (
finops-agent): o chart implanta ofinops-agent, um agente leve que coleta as métricas do cluster que o Kubecost usa para alocação de custos, sem necessidade de uma implantação separada do Prometheus. - Componentes de métricas do Kubernetes: dependendo da configuração, o chart pode implantar componentes de apoio como
kube-state-metricse Node Exporter, que fornecem métricas de objetos do Kubernetes e dos nós. - Armazenamento persistente: os values do Helm podem criar persistent volume claims para os dados do Kubecost e do Prometheus, com tamanhos de armazenamento e storage classes configuráveis.
- Configuração de Ingress e Services: o chart oferece configurações para expor o Kubecost por meio de Services do Kubernetes e, quando habilitado, de um Ingress com hosts, paths, annotations e configurações de TLS configuráveis.
- Recursos de monitoramento: recursos opcionais como
ServiceMonitorePrometheusRulepodem ser criados para ambientes que usam o Prometheus Operator. - Funcionalidades e integrações opcionais: os values do Helm podem habilitar funcionalidades adicionais, como coleta de custos de rede, network policies, integrações de precificação com provedores de nuvem e outros recursos do Kubecost, sem modificar manualmente os manifests do Kubernetes gerados.
Como esses componentes são controlados pelo values.yaml do chart, as organizações podem habilitar apenas os recursos de que precisam ou integrar o Kubecost a componentes de monitoramento e infraestrutura que já existem no cluster.
Conteúdo relacionado: leia nosso guia de otimização de custos no Kubernetes
Como instalar o Kubecost com o Helm
O Kubecost pode ser instalado com o Helm adicionando o repositório oficial de charts do Kubecost e implantando o chart em um namespace dedicado. O repositório Helm atual do Kubecost disponibiliza o chart kubecost/kubecost para o Kubecost 3.x.
Primeiro, adicione o repositório Helm do Kubecost e atualize seu índice local de charts:
helm repo add kubecost https://kubecost.github.io/kubecost/helm repo updateEm seguida, instale o Kubecost em um namespace kubecost:
helm install kubecost kubecost/kubecost \ --namespace kubecost \ --create-namespaceO Kubecost também permite instalar diretamente a partir da URL do repositório. O exemplo oficial define global.clusterId para identificar o cluster:
helm install kubecost \ --repo https://kubecost.github.io/kubecost kubecost \ --namespace kubecost \ --create-namespace \ --set global.clusterId=my-clusterAntes de implantar em produção, você pode inspecionar os values aceitos por uma versão específica do chart:
helm show values kubecost/kubecost --version <chart-version>Depois, basta colocar a configuração necessária em um arquivo values.yaml personalizado e instalar o Kubecost com:
helm install kubecost kubecost/kubecost \ --namespace kubecost \ --create-namespace \ --values values.yamlUsar um arquivo de values facilita versionar e reproduzir a configuração de itens como armazenamento, alocação de recursos, monitoramento e componentes do Kubecost. O repositório oficial do Kubecost também recomenda verificar a compatibilidade entre as versões do chart e do Kubernetes ao escolher um release; por exemplo, os charts do Kubecost 3.0 são voltados para versões mais recentes do Kubernetes do que os últimos releases do Kubecost 2.x.
Helm chart do Kubecost vs. manifests do Kubernetes
Tanto Helm charts quanto manifests do Kubernetes podem ser usados para implantar aplicações no Kubernetes, mas eles gerenciam a configuração de formas diferentes. O Kubecost recomenda o Helm como método principal de instalação; seu chart oficial empacota os recursos necessários e expõe a configuração por meio de values do Helm.
| Helm chart do Kubecost | Manifests do Kubernetes | |
|---|---|---|
| Implantação | Instala o Kubecost como um release do Helm usando um chart empacotado. | Os recursos são aplicados diretamente com kubectl apply. |
| Configuração | As configurações ficam centralizadas no values.yaml ou são passadas com --set. |
A configuração é alterada editando definições de recursos YAML individuais. |
| Upgrades | O Helm rastreia o release e pode aplicar mudanças de versão do chart e de configuração com helm upgrade. |
Manifests atualizados geralmente precisam ser aplicados e mantidos manualmente. |
| Personalização | Os values do chart oferecem opções configuráveis para componentes, armazenamento, Prometheus, limites de recursos e outras configurações. | Oferece controle direto sobre cada objeto do Kubernetes, mas exige mais manutenção manual. |
| Repetibilidade | Uma versão de chart mais um arquivo de values torna a implantação mais fácil de reproduzir entre clusters. | As equipes precisam manter e sincronizar sua própria coleção de manifests. |
| Gestão do ciclo de vida | O Helm oferece instalação de releases, upgrades, rollback e desinstalação de forma nativa. | O Kubernetes gerencia recursos individuais, não um ciclo de vida de release do Helm. |
| Mais indicado para | A maioria das implantações do Kubecost, especialmente ambientes que precisam de configuração repetível e upgrades contínuos. | Ambientes que exigem especificamente controle direto sobre recursos estáticos do Kubernetes ou que não podem usar o Helm. |
Historicamente, o Kubecost ofereceu a implantação por manifests estáticos como alternativa, mas sua documentação recomenda o Helm, principalmente para implantações em produção. O Helm também facilita personalizar dependências e configurações (por exemplo, se o Kubecost usa seus componentes de monitoramento empacotados ou a infraestrutura existente) sem manter cópias modificadas de cada recurso do Kubernetes.
Boas práticas com o Helm chart do Kubecost
Confira algumas práticas úteis para trabalhar com o Helm chart do Kubecost.
1. Fixe as versões do Helm chart do Kubecost
Especifique uma versão explícita do chart do Kubecost em vez de deixar que o Helm instale automaticamente o release mais recente disponível. O Helm permite selecionar uma versão específica do chart com a opção --version; se ela for omitida, a versão mais recente pode ser selecionada.
Fixar versões torna as implantações mais previsíveis e impede que uma instalação automatizada ou um pipeline de CI/CD adote inesperadamente um chart mais novo com padrões ou dependências alterados. Revise as notas de release e os requisitos de compatibilidade do Kubecost antes de atualizar deliberadamente a versão fixada.
2. Mantenha os values do Helm em controle de versão
Armazene a configuração do Kubecost que você sobrescreve em um arquivo values.yaml dedicado e mantenha-o em controle de versão. Os values do Helm são o mecanismo padrão para sobrescrever os padrões do chart, incluindo configurações de componentes da aplicação, armazenamento, ingress e outras opções de implantação.
O controle de versão fornece um histórico de mudanças de configuração e facilita revisar, reproduzir ou reverter implantações do Kubecost. Evite colocar credenciais ou outros segredos sensíveis diretamente em um repositório; em vez disso, referencie um mecanismo adequado de gestão de segredos do Kubernetes ou externo.
3. Use arquivos de values separados para cada ambiente
Mantenha arquivos de values separados para desenvolvimento, staging e produção quando esses ambientes exigirem configurações diferentes do Kubecost. O Helm foi projetado para implantar o mesmo chart com values diferentes, evitando a necessidade de manter cópias separadas dos manifests do Kubernetes subjacentes.
Por exemplo, produção pode usar volumes persistentes e alocações de recursos maiores, enquanto um cluster de desenvolvimento pode usar configurações menores. Manter as sobrescritas específicas de cada ambiente separadas também reduz o risco de aplicar acidentalmente uma configuração de desenvolvimento em produção.
4. Defina requests e limits de recursos adequados
Configure requests e limits de CPU e memória para os componentes do Kubecost de acordo com o tamanho e os workloads do cluster. Os requests ajudam o Kubernetes a reservar recursos suficientes para os pods do Kubecost, enquanto os limits podem impedir que componentes individuais consumam capacidade excessiva do cluster.
Evite simplesmente copiar a mesma configuração de recursos entre clusters de tamanhos muito diferentes. Monitore o consumo real de recursos do Kubecost após a implantação e ajuste os values do Helm à medida que o número de nós, workloads e métricas coletadas aumenta.
5. Configure armazenamento persistente para produção
Use armazenamento persistente para os componentes do Kubecost que precisam preservar dados entre reinicializações ou reagendamentos de pods. O chart do Kubecost expõe configurações de volumes persistentes, como a ativação da persistência, o tamanho do volume e a StorageClass do Kubernetes usada para o volume.
Para implantações em produção, escolha uma StorageClass confiável e provisione capacidade suficiente para o crescimento esperado dos dados. As configurações de armazenamento também devem estar alinhadas aos requisitos de backup, retenção e recuperação de desastres da organização.
6. Teste upgrades do Helm antes de ir para produção
Aplique upgrades do chart do Kubecost em um cluster de desenvolvimento ou staging antes de atualizar o ambiente de produção. Teste tanto a nova versão do chart quanto seus values personalizados existentes, porque upgrades de chart podem introduzir novas configurações, modificar padrões ou alterar recursos do Kubernetes.
O Helm permite revisar e controlar os values de upgrade, além de reverter um release para uma revisão anterior quando necessário. Mantenha a versão anterior do chart e a configuração correspondente para ter um caminho de rollback testado caso o upgrade em produção cause problemas.
Otimizando custos do Kubernetes além do Kubecost com a PerfectScale
A PerfectScale by DoiT oferece otimização de custos responsável, que elimina recursos desperdiçados sem impactar a estabilidade e o desempenho do Kubernetes. O Kubecost é focado principalmente no monitoramento de custos do Kubernetes. A PerfectScale vai além: ajusta continuamente seu ambiente para obter o melhor desempenho e eficiência de custos, além de oferecer visibilidade e governança aprimoradas em node groups, namespaces, contêineres e workloads. O Helm chart do Kubecost implanta e mantém o Prometheus e componentes de métricas relacionados. A PerfectScale, por outro lado, roda como um único agente stateless com footprint mínimo e não exige Prometheus.
Principais recursos da PerfectScale:
- Otimização autônoma de custos: ajusta de forma autônoma seu ambiente Kubernetes com ações integradas ao GitOps, aplicando as economias continuamente em vez de apenas exibi-las em dashboards.
- Right-sizing abrangente: fornece recomendações de CPU e memória tanto para requests quanto para limits. Essas recomendações levam em conta mudanças no código e a configuração do HPA.
- Implantação com agente stateless: é instalada como um único agente leve, com manutenção mínima. Não há implementação de Prometheus para configurar ou manter.
- Visibilidade e alocação de custos granulares: oferece visibilidade e alocação de custos, previsão de custos e desperdício e visibilidade de workloads efêmeros. Também mostra alocação, utilização e capacidade ociosa dos nós, dá suporte a node groups e permite agrupar workloads efêmeros de formas personalizadas.
- Detecção e remediação de problemas de resiliência: identifica eventos de OOM, throttling de CPU, suspeitas de vazamento de memória, reinicializações frequentes, evictions e workloads que atingem o limite de réplicas. Também oferece priorização automática de riscos de resiliência, alertas personalizáveis e remediação autônoma.
- Funciona onde quer que o Kubernetes rode: oferece suporte a EKS, GKE, AKS, OpenShift e clusters on-premises.
Pronto para sair do monitoramento de custos e partir para a otimização autônoma do Kubernetes? Veja como a PerfectScale se compara ao Kubecost e comece um teste gratuito de 30 dias.