Revisão do Kubecost para economizar dinheiro no Kubernetes nas nuvens

Revisão do Kubecost para economizar dinheiro no Kubernetes nas nuvens

Atualmente, cada vez mais empresas estão transferindo sua infraestrutura de servidores de hardware e de suas próprias máquinas virtuais para a nuvem. Esta solução é fácil de explicar: não há necessidade de se preocupar com hardware, o cluster é facilmente configurado de muitas maneiras diferentes... e o mais importante, as tecnologias existentes (como Kubernetes) tornam possível simplesmente dimensionar o poder de computação dependendo da carga .

O aspecto financeiro é sempre importante. A ferramenta discutida neste artigo foi projetada para ajudar a reduzir orçamentos ao usar infraestrutura em nuvem com Kubernetes.

Introdução

Kubecost é uma startup californiana do Google, criando uma solução para calcular custos de infraestrutura em serviços em nuvem (dentro de um cluster Kubernetes + recursos compartilhados), buscando gargalos nas configurações do cluster e enviando notificações apropriadas ao Slack.

Temos clientes com Kubernetes nas conhecidas nuvens AWS e GCP e, mais raramente para a comunidade Linux, Azure - em geral, em todas as plataformas suportadas pelo Kubecost. Para alguns deles, calculamos nós próprios os custos dos serviços intra-cluster (utilizando um método semelhante ao utilizado pela Kubecost), e também monitorizamos os custos de infraestrutura e tentamos otimizá-los. Portanto, é lógico que estivéssemos interessados ​​na possibilidade de automatizar tais tarefas.

O código-fonte do módulo principal do Kubecost é aberto sob os termos da licença Open Source (Licença Apache 2.0). Pode ser usado livremente e os recursos disponíveis devem ser suficientes para pequenos projetos. Porém, negócio é negócio: o resto do produto está fechado, pode ser utilizado por assinaturas pagas, o que também implica apoio comercial. Além disso, os autores oferecem uma licença gratuita para pequenos clusters (1 cluster com 10 nós - durante a redação deste artigo, esse limite foi ampliado para 20 nós) ou um período de teste com recursos completos por 1 mês.

Como tudo funciona

Então, a parte principal do Kubecost é a aplicação modelo de custo, escrito em Go. Um gráfico Helm que descreve todo o sistema é chamado analisador de custos e em sua essência está uma montagem de um modelo de custo com Prometheus, Grafana e vários dashboards.

De modo geral, o cost-model possui uma interface web própria, que mostra gráficos e estatísticas detalhadas de custos em forma de tabela, além, claro, de dicas para otimização de custos. Os dashboards apresentados no Grafana são um estágio inicial no desenvolvimento do Kubecost e contêm praticamente os mesmos dados do modelo de custo, complementando-os com as estatísticas usuais sobre o consumo de CPU/memória/rede/espaço em disco no cluster e seus componentes. .

Como funciona o Kubecost?

  • O modelo de custo recebe preços de serviços por meio da API de provedores de nuvem.
  • Além disso, dependendo do tipo de ferro do nó e da região, o custo por nó é calculado.
  • Com base no custo de execução dos nós, cada pod folha obtém um custo por hora de uso da CPU, por gigabyte de memória consumida e por hora por gigabyte de dados armazenados – dependendo do nó em que estava sendo executado ou da classe de armazenamento.
  • Com base no custo de operação de pods individuais, o pagamento é calculado para namespaces, serviços, implantações e StatefulSets.
  • As estatísticas são calculadas usando métricas fornecidas por kube-state-metrics e node-exporter.

É importante considerar que Kubecost por padrão conta apenas os recursos disponíveis no Kubernetes. Bancos de dados externos, servidores GitLab, armazenamentos S3 e outros serviços que não estão no cluster (mesmo que localizados na mesma nuvem) não são visíveis para ele. Embora para GCP e AWS você possa adicionar as chaves de suas contas de serviço e calcular tudo junto.

Instalação

Kubecost requer:

  • Kubernetes versão 1.8 e superior;
  • métricas de estado do kube;
  • Prometeu;
  • exportador de nó.

Acontece que em nossos clusters todas essas condições foram atendidas antecipadamente, então bastava especificar o endpoint correto para acesso ao Prometheus. No entanto, o gráfico oficial do kubecost Helm contém tudo que você precisa para executar em um cluster vazio.

Existem várias maneiras de instalar o Kubecost:

  1. Método de instalação padrão descrito em instruções no site do desenvolvedor. Obrigatório adicione o repositório do analisador de custos ao Helm e instale o gráfico. Tudo o que resta é encaminhar sua porta e ajustar as configurações para o estado desejado manualmente (via kubectl) e/ou usando a interface web do modelo de custo.

    Ainda nem testamos esse método, já que não usamos configurações prontas de terceiros, mas parece uma boa opção “tente você mesmo”. Se você já possui alguns componentes do sistema instalados ou deseja um ajuste mais fino, é melhor considerar o segundo caminho.

  2. Use essencialmente o mesmo gráfico, mas configure e instale você mesmo de qualquer maneira conveniente.

    Como já mencionado, além do próprio kubecost, este gráfico contém gráficos Grafana e Prometheus, que também podem ser customizados conforme desejado.

    Disponível no gráfico values.yaml para analisador de custos permite configurar:

    • uma lista de componentes do analisador de custos que precisam ser implantados;
    • seu endpoint para Prometheus (se você já tiver um);
    • domínios e outras configurações de entrada para modelo de custo e Grafana;
    • anotações para pods;
    • a necessidade de utilização de armazenamento permanente e seu tamanho.

    Uma lista completa de opções de configuração disponíveis com descrições está disponível em documentação.

    Como o kubecost em sua versão básica não pode restringir o acesso, você precisará configurar imediatamente o basic-auth para o painel web.

  3. Instalar apenas o núcleo do sistema - modelo de custo. Para fazer isso, você deve ter o Prometheus instalado no cluster e especificar o valor correspondente de seu endereço na variável prometheusEndpoint para Helm. Depois disso - aplique conjunto de configurações YAML no aglomerado.

    Novamente, você terá que adicionar manualmente o Ingress com autenticação básica. Finalmente, você precisará adicionar uma seção para coletar métricas do modelo de custo em extraScrapeConfigs na 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:
        - <адрес вашего сервиса kubecost>
        type: 'A'
        port: 9003

O que nós ganhamos?

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

Custo total, exibido na tela principal, mostra na verdade o custo estimado dos recursos para o mês. Esse previsível preço que reflete o custo de uso do cluster (por mês) no nível atual de consumo de recursos.

Essa métrica serve mais para analisar despesas e otimizá-las. Não é muito conveniente olhar os custos totais do julho abstrato no kubecost: você terá que ir para faturamento. Mas você pode ver os custos divididos por namespaces, rótulos e pods para 1/2/7/30/90 dias, que o faturamento nunca mostrará.

Revisão do Kubecost para economizar dinheiro no Kubernetes nas nuvens

Falando de rótulos. Você deve ir imediatamente às configurações e definir os nomes dos rótulos que serão usados ​​​​como categorias adicionais para agrupar custos:

Revisão do Kubecost para economizar dinheiro no Kubernetes nas nuvens

Você pode pendurar qualquer etiqueta neles - conveniente se você já tiver seu próprio sistema de etiquetagem.

Lá você também pode 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 sua medição (por algum motivo, o recurso não afeta o custo total).

Kubecost pode mostrar vários problemas no cluster (e até alerta em caso de perigo). Infelizmente, a opção não é configurável e, portanto, se você possui ambientes para desenvolvedores e os utiliza, verá constantemente algo assim:

Revisão do Kubecost para economizar dinheiro no Kubernetes nas nuvens

Uma ferramenta importante - Economia de cluster. Ele mede a atividade dos pods (consumo de recursos, inclusive de rede) e também calcula quanto dinheiro e quanto você pode economizar.

Pode parecer que as dicas de otimização são bastante óbvias, mas a experiência sugere que ainda há algo para se observar. Em particular, a atividade de rede dos pods é monitorada (Kubecost sugere prestar atenção aos inativos), a memória solicitada e real e o consumo de CPU são comparados, bem como a CPU usada pelos nós do cluster (sugere recolher vários nós em um), disco carregar e mais algumas dúzias de parâmetros.

Como acontece com qualquer problema de otimização, a otimização de recursos com base nos dados do Kubecost requer: trate com cuidado. Por exemplo, Cluster Savings sugere a exclusão de nós, alegando que é seguro, mas não leva em consideração a presença de seletores de nós e taints nos pods implantados neles que não estão disponíveis em outros nós. E em geral, mesmo os autores do produto em seus artigo recente (aliás, pode ser muito útil para quem se interessa pelo tema do projeto) recomenda-se não se precipitar na otimização de custos, mas abordar o assunto com atenção.

Resultados de

Depois de usar o kubecost por um mês em alguns projetos, podemos concluir que é uma ferramenta interessante (e também fácil de aprender e instalar) para analisar e otimizar custos dos serviços de provedores de nuvem usados ​​para clusters Kubernetes. Os cálculos revelaram-se muito precisos: nas nossas experiências coincidiram com o que os fornecedores realmente exigiam.

Existem também algumas desvantagens: existem bugs não críticos e, em alguns lugares, a funcionalidade não cobre as necessidades específicas de alguns projetos. No entanto, se você precisa entender rapidamente para onde vai o dinheiro e o que pode ser “cortado” para reduzir consistentemente a conta dos serviços em nuvem em 5-30% (foi o que aconteceu no nosso caso), esta é uma ótima opção. .

PS

Leia também em nosso blog:

Fonte: habr.com

Adicionar um comentário