Menina na scooter. Ilustração freepik, logotipo da Nomad de HashiCorp

Kubernetes é um gorila de 300 quilos para orquestração de contêineres. Ele opera alguns dos maiores sistemas de contêineres do mundo, mas custa caro.

Particularmente caro para pequenas equipes, que precisarão gastar muito tempo em manutenção e numa curva de aprendizado difícil. Para a nossa equipe de quatro pessoas, isso é uma sobrecarga excessiva. Portanto, começamos a procurar alternativas e nos apaixonamos por Nomad.

O que queremos

Nossa equipe mantém uma série de serviços típicos para monitoramento e análise de desempenho: endpoints de API para métricas, escritas em Go, exportação para Prometheus, analisadores de logs, como Logstash e Gollum, além de bancos de dados, como InfluxDB ou Elasticsearch. Cada um desses serviços opera em seu próprio contêiner. Precisamos de um sistema simples para manter tudo isso funcionando.

Começamos com uma lista de requisitos para orquestração de contêineres:

• Implantação de um conjunto de serviços em várias máquinas.
• Visão geral dos serviços em execução.
• Conexões entre serviços.
• Reinício automático se o serviço falhar.
• Manutenção da infraestrutura por uma pequena equipe.

Além disso, as seguintes características seriam agradáveis, mas não essenciais:

• Marcação de máquinas por suas capacidades (por exemplo, marcação de máquinas com discos rápidos para serviços pesados de I/O).
• Capacidade de executar serviços independentemente do orquestrador (por exemplo, durante o desenvolvimento).
• Um local compartilhado para configurações e segredos.
• Um endpoint para métricas e logs.

Por que Kubernetes não é adequado para nós

Ao criar um protótipo com Kubernetes, percebemos que estávamos adicionando camadas de lógica cada vez mais complexas nas quais dependíamos incondicionalmente.

Por exemplo, Kubernetes suporta configurações de serviços embutidas através de ConfigMaps. Você pode rapidamente ficar confuso, especialmente ao mesclar vários arquivos de configuração ou adicionar serviços adicionais ao pod. Kubernetes (ou helm Neste caso, permite implantar configurações externas dinamicamente para dividir interesses. No entanto, isso resulta em uma conexão rígida e oculta entre seu projeto e o Kubernetes. No entanto, o Helm e os ConfigMaps são opções adicionais, portanto, você não é obrigado a usá-los. Você pode simplesmente copiar a configuração para a imagem Docker. No entanto, é tentador seguir esse caminho e construir abstrações desnecessárias, das quais você pode se arrepender mais tarde.

Além disso, o ecossistema do Kubernetes está evoluindo rapidamente. É necessário muito tempo e energia para se manter atualizado com as melhores práticas e as ferramentas mais recentes. Kubectl, minikube, kubeadm, helm, tiller, kops, oc — a lista continua e continua. No início, nem todas essas ferramentas serão necessárias, mas você não sabe o que precisará, por isso deve estar ciente de tudo. Devido a isso, a curva de aprendizado é bastante íngreme.

Quando usar Kubernetes

Na nossa empresa, muitos usam Kubernetes e estão bastante satisfeitos. Essas instâncias são gerenciadas pelo Google ou pela Amazon, que têm recursos suficientes para suporte.

O Kubernetes vem com recursos surpreendentes, que tornam a orquestração em larga escala de contêineres mais gerenciável:

• Gerenciamento detalhado de permissões.
• Controladores personalizados adicionam lógica ao cluster. São apenas programas que interagem com a API do Kubernetes.
• Escalonamento automático! O Kubernetes pode escalar serviços sob demanda, utilizando métricas de serviço e sem requerer intervenção manual.

A questão é: você realmente precisa de todos esses recursos? Não é possível confiar apenas nas abstrações; você terá que entender o que acontece por trás das cenas.

Nossa equipe fornece a maioria dos serviços remotamente (devido à forte conexão com a infraestrutura subjacente), portanto, não queríamos criar nosso próprio cluster Kubernetes. Queríamos apenas fornecer serviços.

Baterias não incluídas

O Nomad é 20% da orquestração que oferece 80% do que é necessário. Tudo o que ele faz é gerenciar implantações. O Nomad cuida das implantações, reinicia contêineres em caso de falhas... e é só isso.

O objetivo do Nomad é que ele faz pelo menossem gerenciamento detalhado de permissões ou políticas de rede avançadas, isso foi projetado intencionalmente. Esses componentes são fornecidos externamente ou não são fornecidos de forma alguma.

Acho que o Nomad encontrou o compromisso perfeito entre facilidade de uso e utilidade. Ele é bom para pequenos serviços independentes. Se você precisar de mais controle, terá que configurá-los sozinho ou usar uma abordagem diferente. O Nomad é simplesmente um orquestrador.

A melhor coisa sobre o Nomad é que ele é fácil substituir. A ligação com o fornecedor é praticamente inexistente, uma vez que suas funções se integram facilmente a qualquer outro sistema que gerencia serviços. Ele funciona apenas como um binário comum em cada máquina do cluster, e é isso!

O ecossistema Nomad é composto por componentes fracamente acoplados

A verdadeira força do Nomad está em seu ecossistema. Ele se integra muito bem com outros produtos — que são totalmente opcionais — como Consul (armazenamento de chave-valor) ou Vault (manipulação de segredos). Dentro do arquivo Nomad, há seções para extrair dados desses serviços:

template {
  data = <<EOH
LOG_LEVEL="{{key "service/geo-api/log-verbosity"}}"
API_KEY="{{with secret "secret/geo-api-key"}}{{.Data.value}}{{end}}"
EOH

  destination = "secrets/file.env"
  env         = true
}

Aqui lemos a chave service/geo-api/log-verbosity do Consul e durante a execução a apresentamos como variável de ambiente LOG_LEVEL. Também apresentamos a chave secret/geo-api-key do Vault como API_KEY. Simples, mas poderoso!

Graças à sua simplicidade, o Nomad é facilmente ampliado com outros serviços através da API. Por exemplo, tags para jobs são suportadas. Marcamos todos os serviços com métricas com a tag trv-metrics. Assim, o Prometheus encontra facilmente esses serviços através do Consul e verifica periodicamente o endpoint /metrics em busca de novos dados. O mesmo pode ser feito, por exemplo, para logs, usando Loki.

Há muitos outros exemplos de escalabilidade:

• Executar um job do Jenkins através de um hook, enquanto o Consul monitora o reimplante do job do Nomad ao mudar a configuração do serviço.
• O Ceph adiciona ao Nomad um sistema de arquivos distribuído.
• O fabio para balanceamento de carga.

Tudo isso permite desenvolver a infraestrutura de forma orgânica sem uma forte ligação com o fornecedor.

Um aviso honesto

Nenhum sistema é perfeito. Não recomendo implementar imediatamente as funções mais novas em produção. Claro, há bugs e funcionalidades ausentes, mas o mesmo se aplica ao Kubernetes.

Comparado ao Kubernetes, a comunidade do Nomad não é tão grande. O Kubernetes já conta com cerca de 75.000 commits e 2.000 contribuidores, enquanto o Nomad tem cerca de 14.000 commits e 300 contribuidores. Será difícil para o Nomad acompanhar a velocidade do Kubernetes, mas talvez isso nem seja necessário! É um sistema mais especializado, e uma comunidade menor também significa que o seu pull request será notado e aceito mais rapidamente em comparação com o Kubernetes.

Resumo

Conclusão: não use Kubernetes apenas porque todo mundo o utiliza. Avalie cuidadosamente suas necessidades e veja qual ferramenta é mais vantajosa.

Se você planeja implantar uma grande quantidade de serviços homogêneos em uma infraestrutura em larga escala, o Kubernetes é uma boa opção. Apenas lembre-se da complexidade adicional e dos custos operacionais. Alguns desses custos podem ser evitados ao usar um ambiente Kubernetes gerenciado, como Google Kubernetes Engine ou Amazon EKS.

Se você está apenas procurando um orquestrador confiável, fácil de manter e escalável, por que não experimentar o Nomad? Você pode se surpreender com até onde isso pode levá-lo.

Se compararmos o Kubernetes a um carro, o Nomad seria uma scooter. Às vezes você precisa de um, e às vezes de outro. Ambos têm seu valor.

Fonte: habr.com