Garota em uma scooter. Ilustração de freepik , logotipo Nomad por HashiCorp

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

Especialmente caro para equipes pequenas que precisam gastar muito tempo com suporte e uma curva de aprendizado acentuada. Para nossa equipe de quatro pessoas, isso é demais. Então começamos a procurar alternativas - e nos apaixonamos pelo Nomad .

O que voce quer

Nossa equipe oferece suporte a vários serviços típicos para monitorar e analisar o desempenho: pontos de extremidade da API para métricas Go, exportação de Prometheus, analisadores de log como Logstash e Gollum , além de bancos de dados como InfluxDB ou Elasticsearch. Cada um desses serviços é executado em seu próprio contêiner. Precisamos de um sistema simples para manter tudo isso operacional.

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

• Inicie um conjunto de serviços em muitas máquinas.
  
• Visão geral dos serviços em execução.
  
• Comunicação entre serviços.
  
• Reinicialização automática se o serviço travar.
  
• Manutenção de infraestrutura por uma pequena equipe.

Além disso, as seguintes coisas serão boas, mas não as adições obrigatórias:

• Máquinas de marcação de acordo com suas capacidades (por exemplo, máquinas de marcação com discos rápidos para serviços pesados ​​de E / S).
  
• A capacidade de iniciar serviços, independentemente da orquestra (por exemplo, durante o desenvolvimento).
  
• Um lugar comum para compartilhar configurações e segredos.
  
• Ponto final para métricas e logs.

Por que o Kubernetes não combina conosco

Ao criar um protótipo com o Kubernetes, percebemos que começamos a adicionar camadas de lógica cada vez mais complexas, nas quais dependíamos incondicionalmente.

Como um exemplo, o Kubernetes suporta configurações de serviço internas através do ConfigMaps . Você pode se confundir rapidamente, especialmente ao mesclar vários arquivos de configuração ou adicionar serviços adicionais ao pod. O Kubernetes (ou helm neste caso) permite implementar configurações externas dinamicamente para separar interesses. Mas isso leva a uma conexão secreta difícil entre seu projeto e o Kubernetes. No entanto, Helm e ConfigMaps são opções adicionais, portanto você não precisa usá-los. Você pode simplesmente copiar a configuração na imagem do Docker. No entanto, é tentador seguir esse caminho e criar abstrações desnecessárias, das quais você pode se arrepender mais tarde.

Além disso, o ecossistema Kubernetes está crescendo rapidamente. É preciso muito tempo e energia para manter-se atualizado com as melhores práticas e as ferramentas mais recentes. Kubectl, minikube, kubeadm, leme, leme, kops, oc - a lista continua. No início do trabalho, nem todas essas ferramentas são necessárias, mas você não sabe o que é necessário e, portanto, precisa estar ciente de tudo. Por esse motivo, a curva de aprendizado é bastante acentuada.

Quando usar o Kubernetes

Na nossa empresa, muitos usam o Kubernetes e estão muito felizes com isso. Essas instâncias são gerenciadas pelo Google ou Amazon, que possuem recursos de suporte suficientes.

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

• Gerenciamento detalhado de direitos .
  
• Controladores personalizados adicionam lógica ao cluster. Estes são apenas programas que falam com a API do Kubernetes.
  
• Escalonamento automático ! O Kubernetes pode dimensionar serviços sob demanda usando métricas de serviço sem exigir intervenção manual.

A questão é se você realmente precisa de todos esses recursos. Você não pode apenas confiar na abstração; você tem que descobrir o que está acontecendo sob o capô .

Nossa equipe fornece a maioria dos serviços remotamente (devido à estreita conexão com a infraestrutura principal), portanto, não queremos criar nosso próprio cluster Kubernetes. Nós apenas queríamos prestar serviços.

Pilhas não incluídas

Nômade é 20% da orquestração, o que dá 80% do necessário. Tudo o que ele faz é gerenciar implantações. O Nomad cuida das implantações, reinicia os contêineres em caso de erros ... e é isso.

O ponto principal do Nomad é que ele faz um mínimo : nenhum gerenciamento detalhado de direitos ou políticas avançadas de rede são tão especialmente concebidas. Esses componentes são fornecidos ou não são fornecidos.

Acho que o Nomad encontrou o compromisso perfeito entre facilidade de uso e utilidade. É bom para serviços pequenos e independentes. Se você precisar de mais controle, precisará aumentá-los ou usar uma abordagem diferente. Nomad é apenas uma orquestra.

A melhor coisa sobre o Nomad é que é fácil de substituir . Praticamente não há vinculação ao fornecedor, pois suas funções são facilmente integradas a qualquer outro sistema que gerencia serviços. Funciona como um binário comum em todas as máquinas de um cluster, é isso!

Ecossistema nômade de componentes fracamente acoplados

O verdadeiro poder do Nomad em seu ecossistema. Ele se integra muito bem a outros produtos - completamente opcionais -, como Consul (armazenamento de valor-chave) ou Vault (processamento de segredos). Dentro do arquivo Nomad, existem 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 da Consul e no processo a representamos com a variável de ambiente LOG_LEVEL . Também representamos a secret/geo-api-key do Vault como API_KEY . Simples, mas poderoso!

Devido à sua simplicidade, o Nomad é facilmente extensível através de outros serviços através da API. Por exemplo, tags para tarefas são suportadas. Marcamos todos os serviços com métricas com a tag trv-metrics . Assim, o Prometheus encontra esses serviços com facilidade através do Consul e verifica periodicamente o terminal /metrics para novos dados. O mesmo pode ser feito, por exemplo, para logs usando o Loki .

Existem muitos outros exemplos de extensibilidade:

• Executando o trabalho Jenkins com um gancho, e o Consul acompanha a reimplantação do trabalho Nomad quando a configuração do serviço é alterada.
  
• O Ceph adiciona um sistema de arquivos distribuído ao Nomad.
  
• fabio para balanceamento de carga.

Tudo isso permite que você desenvolva organicamente a infraestrutura sem nenhuma ligação específica ao fornecedor.

Aviso honesto

Nenhum sistema é perfeito. Não recomendo a introdução imediata dos recursos mais recentes na produção. Obviamente, existem bugs e recursos ausentes, mas o mesmo vale para o Kubernetes.

Comparado a Kubernetes, a comunidade nômade não é tão grande. O Kubernetes já possui cerca de 75.000 confirmados e 2.000 colaboradores, enquanto o Nomad possui cerca de 14.000 confirmados e 300 colaboradores. Nômade será pressionado para acompanhar Kubernetes em velocidade, mas talvez isso não seja necessário! Este é um sistema mais especializado e uma comunidade menor também significa que sua solicitação de recebimento é mais provável de ser notada e aceita do que o Kubernetes.

Sumário

Conclusão: Não use o Kubernetes apenas porque todo mundo faz. Avalie cuidadosamente seus requisitos e verifique qual ferramenta é mais lucrativa.

Se você planeja implantar uma tonelada de serviços homogêneos em uma infraestrutura de larga escala, o Kubernetes é uma boa opção. Lembre-se da complexidade e dos custos de manutenção. Alguns dos custos podem ser evitados usando um ambiente gerenciado do Kubernetes, como o Google Kubernetes Engine ou o Amazon EKS .

Se você está procurando apenas um orquestrador confiável, fácil de suportar e expansível, por que não experimentar o Nomad? Você pode se perguntar até onde isso vai levar você.

Se você comparar o Kubernetes com um carro, o Nomad será uma scooter. Às vezes você precisa de um, e outras vezes. Ambos têm o direito de existir.