🥇 Revisão do Kubecost para economia de custos em Kubernetes na nuvem

Atualmente, um número crescente de empresas está migrando sua infraestrutura de servidores físicos e máquinas virtuais próprias para a nuvem. Essa decisão é facilmente explicável: não há necessidade de se preocupar com o hardware, o cluster pode ser configurado de várias maneiras diferentes… e o mais importante — as tecnologias disponíveis (como Kubernetes) permitem escalar facilmente o poder computacional de acordo com a carga.

O aspecto financeiro também é sempre importante. A ferramenta que será discutida neste artigo visa ajudar a reduzir orçamentos ao utilizar infraestrutura em nuvem com Kubernetes.

Introdução

Kubecost — uma startup californiana composta por ex-funcionários do Google, que cria uma solução para calcular custos de infraestrutura em serviços de nuvem (dentro do cluster Kubernetes + recursos comuns), identificar gargalos nas configurações do cluster e enviar as notificações apropriadas para o Slack.

Temos clientes com Kubernetes tanto nas conhecidas nuvens AWS e GCP, quanto na Azure, que é mais rara na comunidade Linux — em geral, em todas as plataformas suportadas pelo Kubecost. Para alguns deles, calculamos os custos de serviços internos do cluster de forma autônoma (com uma metodologia semelhante à usada pelo Kubecost), além de monitorar os gastos com infraestrutura e tentar otimizá-los. Portanto, faz sentido que nos tenha interessado a possibilidade de automatizar tais tarefas.

O código-fonte do módulo principal do Kubecost é aberto sob uma licença Open Source (Apache License 2.0). Ele pode ser utilizado livremente, e as funções disponíveis devem ser suficientes para pequenos projetos. No entanto, negócios são negócios: a parte restante do produto é fechada e pode ser acessada através de assinaturas pagas, que também implicam suporte comercial. Além disso, os autores oferecem uma licença gratuita para pequenos clusters (1 cluster com 10 nós — no momento da redação deste artigo, esse limite foi ampliado para 20 nós) ou um período de teste com todas as funcionalidades por 1 mês.

Como tudo funciona

Portanto, a parte principal do Kubecost é um aplicativo cost-model, escrito em Go. O gráfico Helm, que descreve todo o sistema como um todo, é chamado de cost-analyzer e basicamente é um conjunto do cost-model com Prometheus, Grafana e vários dashboards.

De modo geral, o cost-model possui uma interface web que mostra gráficos e estatísticas detalhadas sobre despesas em formato de tabela, além, é claro, de sugestões para otimização de custos. Os dashboards apresentados no Grafana são uma etapa anterior no desenvolvimento do Kubecost e contêm em grande parte os mesmos dados que o cost-model, complementando-os com estatísticas habituais sobre o uso de CPU/memória/rede/armazenamento no cluster e suas componentes.

Como funciona o Kubecost?

O cost-model obtém preços de manutenção através da API dos provedores de nuvem.
Em seguida, dependendo do tipo de hardware do nó e da região, é calculado o custo por nó.
Com base no custo de operação dos nós, cada pod final recebe um custo por hora de uso do processador, consumo de um gigabyte de memória e custo por hora de armazenamento de um gigabyte de dados — dependendo do nó em que esteve ativo ou da classe de armazenamento.
A partir do custo de operação de pods individuais, é calculado o pagamento por namespaces, serviços, Deployments, StatefulSets.
Para calcular as estatísticas, são utilizadas métricas fornecidas pelo kube-state-metrics e node-exporter.

É importante considerar que o Kubecost considera apenas os recursos disponíveis no Kubernetes. Bancos de dados externos, servidores GitLab, armazenamento S3 e outros serviços que não estão no cluster (mesmo que estejam na mesma nuvem) não são visíveis para ele. No entanto, para o GCP e AWS, é possível adicionar as chaves das contas de serviço e calcular tudo junto.

Instalação

Para o funcionamento do Kubecost, são necessários:

Kubernetes versão 1.8 ou superior;
kube-state-metrics;
Prometheus;
node-exporter.

Acontece que em nossos clusters todas essas condições já estavam atendidas, portanto, foi suficiente apenas indicar o endpoint correto para acessar o Prometheus. No entanto, o chart oficial do Helm do kubecost contém tudo o que é necessário para ser executado até mesmo em um cluster "limpo".

O Kubecost pode ser instalado de várias maneiras:

O método padrão de instalação está descrito em documentação no site do desenvolvedor. É necessário adicionar o repositório cost-analyzer ao Helm, depois disso, instalar o chart. Basta redirecionar a porta e ajustar as configurações para o estado desejado manualmente (via kubectl) e/ou usando a interface web do cost-model.
Esse método nós não experimentamos, pois não utilizamos configurações prontas de terceiros, mas parece uma boa opção para "simplesmente experimentar". Se você já tiver uma parte dos componentes do sistema instalada ou quiser uma configuração mais detalhada, é melhor considerar a segunda opção.
Usar essencialmente o mesmo chart, mas configurá-lo e instalá-lo manualmente da maneira que for mais conveniente.
Como já mencionado, além do próprio kubecost, este chart contém charts do Grafana e Prometheus, que também podem ser configurados de acordo com sua preferência.
O que está disponível no chart values.yaml para o cost-analyzer permite configurar:
- a lista de componentes do cost-analyzer que devem ser implantados;
- seu endpoint para o Prometheus (se você já o tiver);
- domínios e outras configurações de ingress para o cost-model e Grafana;
- anotações para os pods;
- a necessidade de usar armazenamento persistente e seu tamanho.
A lista completa de opções de configuração disponíveis com descrição pode ser encontrada em documentação.
Como o kubecost em sua versão básica não consegue restringir o acesso, será necessário configurar o basic-auth para o painel da web imediatamente.
Instalar somente o núcleo do sistema — cost-model. Para isso, é necessário ter o Prometheus instalado no cluster e indicar o valor correspondente de seu endereço na variável prometheusEndpoint para o Helm. Depois disso, aplique um conjunto de configurações YAML. no cluster.
Novamente, será necessário adicionar manualmente o Ingress com basic-auth. E, finalmente, será preciso adicionar uma seção para coletar métricas do cost-model em extraScrapeConfigs no arquivo de configuração do 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
```

O que conseguimos?

Com uma instalação completa, temos à nossa disposição o painel da web do kubecost e Grafana com um conjunto de dashboards.

Custo total, exibido na tela inicial, na verdade mostra o custo estimado dos recursos por mês. Isso é um preço previsto que representa o custo de uso do cluster (por mês) com o nível atual de consumo de recursos.

Essa métrica é mais para análise de gastos e sua otimização. No kubecost, não é muito conveniente ver os gastos totais para um julho abstrato: você terá que ir para a cobrança. Mas você pode ver os gastos detalhados por namespaces, labels e pods por 1/2/7/30/90 dias, o que a cobrança nunca mostrará.

Falando em labels. É importante acessar imediatamente as configurações e definir os nomes dos rótulos que serão usados como categorias adicionais para agrupar os custos:

Você pode atribuir qualquer rótulo a eles — é conveniente se você já tem seu próprio sistema de rotulagem.

Lá também é possível alterar o endereço do endpoint da API ao qual o modelo de custo se conecta, ajustar o tamanho do desconto no GCP e definir seus próprios preços para recursos e moeda para medições (essa funcionalidade, por algum motivo, não afeta o custo total).

O Kubecost pode mostrar várias problemas no cluster (e até alertar em caso de perigo). Infelizmente, a opção não é configurável, portanto, se você tiver ambientes para desenvolvedores que estão em uso, poderá observar constantemente algo semelhante:

Uma ferramenta importante — Economias do Cluster. Ela mede a atividade dos pods (uso de recursos, incluindo o de rede), além de calcular quanto dinheiro pode ser economizado e em que áreas.

Pode parecer que as dicas de otimização são bem óbvias, no entanto, a experiência mostra que sempre há algo a ser revisado. Em particular, a atividade de rede dos pods é monitorada (o Kubecost sugere prestar atenção em aqueles inativos), compara o consumo de memória e CPU solicitado versus o real, assim como a CPU utilizada pelos nós do cluster (sugere consolidar vários nós em um só), a carga nos discos e mais algumas dezenas de parâmetros.

Como em qualquer questão relacionada à otimização, a otimização de recursos com base nos dados do Kubecost deve ser abordada com cautela. Por exemplo, as Economias do Cluster sugerem remover nós, afirmando que isso é seguro, mas não considera a presença de seletores de nó e taints nos pods implantados que não estão presentes nos outros nós. Além disso, até mesmo os criadores do produto em sua um artigo recente (aliás, isso pode ser bastante útil para aqueles que estão interessados no tema do projeto) recomendam não se precipitar na otimização de custos, abordando a questão de maneira ponderada.

Resultados

Após usar o Kubecost por um mês em alguns projetos, podemos concluir que é uma ferramenta interessante (e fácil de entender e instalar) para análise e otimização de custos em serviços de provedores de nuvem usados para clusters Kubernetes. Os cálculos são bastante precisos: em nossos experimentos, eles corresponderam ao que os provedores realmente exigiam.

Não faltaram desvantagens: existem bugs não críticos, e algumas funcionalidades não atendem a necessidades específicas de certos projetos. No entanto, se você precisar entender rapidamente para onde está indo o dinheiro e o que pode ser "cortado" para reduzir a conta com serviços em nuvem em 5-30% (como aconteceu no nosso caso), essa é uma ótima opção.

P.S.

Confira também em nosso blog:

Fonte: habr.com

Visão geral do Kubecost para economia de custos no Kubernetes em nuvem