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

Kubernetes é o gorila de 300 libras da orquestração de contêineres. Funciona em alguns dos maiores sistemas de contêineres do mundo, mas é caro.

Particularmente caro para equipes menores, que exigirão muito tempo de suporte e uma curva de aprendizado acentuada. Isso é muita sobrecarga para nossa equipe de quatro pessoas. Então começamos a procurar alternativas - e nos apaixonamos por Nômade.

O que você quer

Nossa equipe oferece suporte a vários serviços comuns de monitoramento e análise de desempenho: endpoints de API para métricas escritas em Go, exportações do Prometheus, analisadores de log como Logstash e Gollum, bem como 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 funcionando.

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

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

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

• Marcar máquinas com base em suas capacidades (por exemplo, etiquetar máquinas com discos rápidos para serviços de E/S pesados).
• Capacidade de executar serviços independentemente do orquestrador (por exemplo, durante o desenvolvimento).
• Um lugar comum para compartilhar configurações e segredos.
• Endpoint para métricas e logs.

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

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

Por exemplo, o Kubernetes oferece suporte a configurações de serviço integradas por meio de ConfigMaps. Você pode ficar confuso rapidamente, especialmente ao mesclar vários arquivos de configuração ou adicionar serviços adicionais a um pod. Kubernetes (ou leme neste caso) permite implementar dinamicamente configurações externas para separar interesses. Mas isso resulta em um acoplamento estreito e oculto 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 para a imagem do Docker. No entanto, é tentador seguir esse caminho e construir abstrações desnecessárias das quais você poderá se arrepender mais tarde.

Além disso, o ecossistema Kubernetes está evoluindo rapidamente. É preciso muito tempo e energia para se manter atualizado com as melhores práticas e as ferramentas mais recentes. Kubectl, minikube, kubeadm, helm, leme, kops, oc - a lista é infinita. Nem todas essas ferramentas são necessárias quando você está começando, mas você não sabe do que vai precisar, então precisa estar atento a tudo. Por causa disso, a curva de aprendizado é bastante acentuada.

Quando usar o Kubernetes

Em nossa empresa, muitas pessoas usam Kubernetes e estão bastante satisfeitas com isso. Essas instâncias são gerenciadas pelo Google ou pela Amazon, que possuem os recursos para apoiá-las.

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

• Detalhado gestão de direitos.
• Controladores personalizados adicione lógica ao cluster. Estes são simplesmente programas que se comunicam com a API Kubernetes.
• Escalonamento automático! O Kubernetes pode dimensionar serviços sob demanda usando métricas de serviço e sem exigir intervenção manual.

A questão é se você realmente precisa de todos esses recursos. Você não pode confiar apenas em abstrações; você terá que descobrir o que está acontecendo nos bastidores.

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

Pilhas não incluídas

Nomad é 20% da orquestração que fornece 80% do que é necessário. Tudo o que ele faz é gerenciar implantações. O Nomad cuida das implantações, reinicia os containers em caso de erros... e pronto.

O objetivo do Nomad é o que ele faz mínimo: sem gerenciamento granular de direitos ou políticas de rede estendidas, isso foi especialmente projetado. Esses componentes são fornecidos externamente 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 precisar de mais controle, você mesmo terá que aumentá-los ou usar uma abordagem diferente. Nômade é justo orquestrador.

A melhor coisa do Nomad é que é fácil substituir. Praticamente não há conexão com o fornecedor, pois suas funções são facilmente integradas a qualquer outro sistema que gerencie serviços. Ele funciona como um binário normal em todas as máquinas do cluster, só isso!

Ecossistema nômade de componentes fracamente acoplados

A verdadeira força do Nomad é o seu ecossistema. Integra-se muito bem com outros produtos - totalmente opcionais - como Cônsul (armazenamento de valores-chave) ou Cofre (processando segredos). Dentro do arquivo Nomad existem seções para extrair dados destes 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 enquanto trabalhamos o expomos a uma variável de ambiente LOG_LEVEL. Apresentamos também a chave secret/geo-api-key do Vault como API_KEY. Simples, mas poderoso!

Devido à sua simplicidade, o Nomad é facilmente extensível com outros serviços via API. Por exemplo, tags para tarefas são suportadas. Marcamos todos os serviços com métricas trv-metrics. Desta forma, o Prometheus pode encontrar facilmente esses serviços via Consul e verificar periodicamente o endpoint /metrics para novos dados. O mesmo pode ser feito, por exemplo, para logs, usando Loki.

Existem muitos outros exemplos de extensibilidade:

• Execute um trabalho Jenkins usando um gancho e o Consul monitorará a reimplantação do trabalho Nomad quando a configuração do serviço for alterada.
• Ceph adiciona um sistema de arquivos distribuído ao Nomad.
• fabio para balanceamento de carga.

Tudo isso permite desenvolver infraestrutura organicamente sem qualquer conexão especial com o fornecedor.

Aviso justo

Nenhum sistema é perfeito. Não recomendo introduzir imediatamente os recursos mais recentes na produção. É claro que existem bugs e recursos ausentes, mas o mesmo se aplica ao Kubernetes.

Comparada ao Kubernetes, a comunidade Nomad não é tão grande. O Kubernetes já possui cerca de 75 commits e 000 contribuidores, enquanto o Nomad tem cerca de 2000 commits e 14 contribuidores. O Nomad terá dificuldade em acompanhar a velocidade do Kubernetes, mas talvez não seja necessário! É um sistema mais especializado, e a comunidade menor também significa que sua solicitação pull tem maior probabilidade de ser notada e aceita, em comparação com o Kubernetes.

Resumo

Resumindo: não use o Kubernetes só porque todo mundo está fazendo isso. Avalie cuidadosamente suas necessidades e verifique qual ferramenta é mais benéfica.

Se você planeja implantar vários serviços homogêneos em uma infraestrutura de grande escala, o Kubernetes é uma boa opção. Esteja ciente da complexidade adicional e dos custos operacionais. Alguns custos podem ser evitados usando um ambiente Kubernetes gerenciado, como Mecanismo do Google Kubernetes ou Amazon EX.

Se você está apenas procurando um orquestrador confiável, fácil de manter e extensível, por que não experimentar o Nomad? Você pode se surpreender com o quão longe isso o levará.

Se o Kubernetes for comparado a um carro, o Nomad seria uma scooter. Às vezes você precisa de uma coisa e às vezes de outra. Ambos têm o direito de existir.

Fonte: habr.com