Kubernetes vs Docker Swarm: qual você deve usar?

O modo Swarm do Kubernetes e do Docker são duas ferramentas de orquestração de contêineres que permitem dimensionar réplicas de carga de trabalho em várias máquinas físicas. Embora o Kubernetes seja a escolha mais popular, o Docker Swarm tem alguns benefícios exclusivos que também valem a pena considerar.

Aqui está uma olhada em como essas duas tecnologias se comparam em suas funções principais. Ambos têm o mesmo objetivo final – permitindo que você dimensione contêineres – mas às vezes conseguem isso de maneiras bem diferentes. Não importa qual você escolha, você será capaz de lançar e dimensionar contêineres criados a partir de imagens construídas com Docker ou outro mecanismo de contêiner popular.

Visão geral

O Kubernetes foi inicialmente desenvolvido como um projeto de código aberto no Google. Ele agora reside na Cloud Native Computing Foundation (CNCF), um esforço de vários setores para promover e manter projetos nativos em nuvem amplamente usados.

Para configurar o Kubernetes, é necessário criar um cluster de máquinas físicas chamadas de nós. Essas máquinas executam seus contêineres e são controladas por um nó primário centralizado que emite instruções de agendamento de contêiner. Os nós de trabalho agem de acordo com essas instruções para extrair imagens de registros e iniciar seus contêineres.

O Kubernetes foi criado para ser de nível empresarial e pronto para produção. Seus recursos de programação incorporam escalonamento automático, colocação automática, distribuição de carga e monitoramento contínuo para terminações e reinicializações de contêineres.

Publicidade

O modo Swarm é o orquestrador integrado do Docker, incluído como parte da distribuição padrão do Docker. Qualquer máquina com docker instalado pode criar ou ingressar em um cluster swarm.

O Swarm também permite conectar várias máquinas físicas independentes em um cluster. Ele unifica efetivamente um conjunto de hosts Docker em um único host virtual. Há uma curva de aprendizado relativamente superficial e os usuários familiarizados com o Docker de host único geralmente podem se familiarizar com o modo Swarm rapidamente.

Como o Kubernetes, um único nó gerenciador do Swarm é responsável por agendar e monitorar contêineres. O gerenciador pode reagir a incidentes no cluster, como um nó que fica offline, e reprogramar os contêineres de acordo. Ele também oferece suporte a atualizações contínuas, permitindo que você dimensione as cargas de trabalho sem afetar a disponibilidade.

Adicionando novas cargas de trabalho

Os aplicativos Kubernetes são implantados criando uma representação declarativa dos recursos de sua pilha em um arquivo YAML. O YAML é “ aplicado ” para seu cluster, normalmente usando uma CLI como kubectl, em seguida, acionada pelo plano de controle do Kubernetes em execução no nó primário.

Ferramentas adicionais por meio de projetos como o Helm permitem que você “ instale ” aplicativos usando gráficos “ pré-configurados. ” Essas são coleções de arquivos YAML que foram empacotados para facilitar a adição ao seu cluster.

O Kubernetes oferece dezenas de tipos de recursos que abstraem funções de cluster, como rede, armazenamento e implantações de contêiner. Aprender os diferentes tipos de recursos e suas funções apresenta uma curva de aprendizado bastante íngreme para um recém-chegado. Você é incentivado a examinar a arquitetura geral do seu sistema, não apenas as porcas e parafusos de contêineres individuais.

Publicidade

O Docker Swarm também usa arquivos YAML, mas implantações simples podem ser criadas sem eles. O Swarm CLI oferece comandos imperativos como uma alternativa para que você possa iniciar um trio de contêineres NGINX executando:

 serviço docker criar --replicas 3 --name nginx nginx: mais recente 

Quando arquivos YAML são usados, o formato ainda é muito mais conciso do que os recursos do Kubernetes. As definições de pilha Swarm são muito semelhantes aos arquivos Docker Compose; O Swarm pode implantar a maioria dos arquivos Compose no estado em que se encontram, o que permite a você facilmente fazer a transição de suas cargas de trabalho Dockerizadas existentes para uma operação escalonada em um cluster Swarm de vários nós.

O Kubernetes trabalha com abstrações que ficam muito acima de seus contêineres reais. Você precisa entender termos como conjunto de réplicas, implantação e pod e como eles se relacionam com os contêineres que você está executando. Por outro lado, definir os serviços Swarm parecerá familiar para qualquer pessoa que já tenha usado o Docker e o Docker Compose.

Dimensionamento de contêineres

O Kubernetes e o Docker Swarm foram desenvolvidos tendo a escalabilidade como objetivo principal. Em um nível básico, eles permitem que você replique seus contêineres em vários nós de trabalho isolados, melhorando sua resiliência a falhas de hardware e permitindo que você adicione novas instâncias de contêiner para atender à demanda.

O Kubernetes oferece fortes garantias sobre replicação, consistência e distribuição. Ele pode escalar automaticamente seus serviços com base em fatores externos, garantindo que suas cargas de trabalho permaneçam acessíveis mesmo durante os horários de pico de demanda. Essa automação pode ser um fator decisivo para equipes de operações ocupadas.

O Docker Swarm requer que o dimensionamento seja conduzido manualmente, atualizando o arquivo Compose da pilha ou usando um comando CLI para alterar a contagem de réplicas. É simples, mas eficaz: as alterações são aplicadas muito mais rapidamente do que o Kubernetes, pois o Swarm é um sistema menos complicado. Isso significa que pode ser a melhor escolha se você precisar de capacidade de resposta extrema.

Publicidade

Ambos os orquestradores também são eficazes para manter a alta disponibilidade. O Kubernetes e o Docker Swarm reprogramarão os contêineres se um deles falhar ou se um nó de trabalho ficar offline. Esse comportamento mantém automaticamente sua contagem de réplicas especificada, supondo que recursos suficientes estejam disponíveis em seus outros nós.

Rede e balanceamento de carga

O Kubernetes expõe cargas de trabalho por meio de “ serviços ” que atuam como balanceadores de carga no cluster. O tráfego geralmente chega ao serviço por meio de um Ingress, um recurso que permite filtrar as solicitações recebidas com base em propriedades como o nome do host e o URL.

Como de costume com o Kubernetes, isso significa que há várias etapas e abstrações a serem aprendidas. Seus pods de contêiner precisam fazer referência a um serviço, que é referenciado por uma entrada que define suas regras de roteamento. A vantagem é que tudo isso é integrado ao Kubernetes; o único pré-requisito é um balanceador de carga externo apontando para o endereço IP primário do seu cluster. Os provedores de nuvem Kubernetes gerenciados geralmente oferecem um método de um clique para criar esse balanceador de carga.

A rede se comporta de maneira diferente no Docker Swarm. De maneira semelhante aos contêineres Docker regulares, você pode publicar portas facilmente para uma rede de entrada que é acessível em todos os hosts no enxame. Isso incorpora uma malha de roteamento que garante que as solicitações recebidas cheguem a uma instância do seu contêiner em qualquer um dos nós disponíveis. O Swarm também oferece um modo de rede por host em que as portas são abertas apenas em hosts individuais nos quais os contêineres são executados.

O que falta ao Swarm é uma maneira integrada de rotear o tráfego para contêineres com base nas características da solicitação, como o nome do host e o URL. Para conseguir isso, você geralmente adiciona um proxy reverso, como NGINX, Traefik ou HAProxy, que atua como ponto de entrada para seu enxame, corresponde às solicitações recebidas e as encaminha para o contêiner apropriado. Adicionar um componente de infraestrutura adicional para expor serviços por trás de diferentes nomes de domínio pode tornar o Swarm menos adequado para várias cargas de trabalho de produção.

Observabilidade

O Kubernetes e o Docker Swarm têm ferramentas integradas de registro e monitoramento que permitem inspecionar os registros do contêiner e o consumo de recursos. No caso do Kubernetes, você pode observar seu cluster usando ferramentas populares da CLI, como kubectl, ou mudar para uma interface baseada na web, como o painel oficial. O Swarm expõe registros por meio de sua CLI de maneira semelhante aos registros regulares de contêineres do Docker – use logs de serviço do docker para fazer streaming de um serviço.

Publicidade

Onde Kubernetes &’ o suporte à observabilidade vai além do Swarm &’ s em suas integrações com ferramentas de terceiros. Adicionar um sistema de monitoramento como o Prometheus permite consultar, visualizar e armazenar métricas e alertas, enquanto agregadores como o Fluentd fornecem recursos semelhantes para logs. Isso ajuda a desenvolver um cluster altamente observável que você pode inspecionar prontamente de fora.

Essas ferramentas ainda podem ser usadas com o Docker Swarm, mas você precisará configurar seus próprios procedimentos para mover dados do seu swarm para as plataformas de agregação. O Kubernetes oferece uma experiência mais perfeita onde as ferramentas são executadas dentro do cluster, inspecionando-o de dentro.

Conclusão

Kubernetes e Docker Swarm são dois orquestradores de contêineres que você pode usar para dimensionar seus serviços. O que você deve usar depende do tamanho e da complexidade do seu serviço, dos seus objetivos em relação à replicação e de quaisquer requisitos especiais que você tenha para rede e capacidade de observação.

O Kubernetes é um sistema de nível de produção que inclui escalonamento automático, entrada de rede e integrações de fácil observação em sua instalação padrão. Essa instalação pode ser mais complicada de conseguir, pois você precisará manter seu próprio cluster ou criar um com um provedor de nuvem pública. O autogerenciamento do plano de controle pode ser bastante complicado, com a administração do Kubernetes agora comumente vista como um título de trabalho por si só.

A implantação no Kubernetes requer uma compreensão dos conceitos subjacentes, como eles abstraem os fundamentos do contêiner e o tipo de recurso que você deve usar em cada cenário. Isso cria uma curva de aprendizado relativamente íngreme; O Kubernetes tem uma reputação de complexidade e confusão para os recém-chegados, o que vale a pena ter em mente se você não tiver uma equipe de operações dedicada.

O Docker Swarm é muito mais simples de executar. Se você instalou o Docker, já tem tudo de que precisa. O Swarm pode distribuir horizontalmente seus contêineres, reagendá-los em uma situação de failover e escaloná-los sob demanda.

Publicidade

O uso diário é muito semelhante aos fluxos de trabalho estabelecidos do Docker. Os comandos CLI principais são uma reminiscência de operações regulares de contêiner do Docker e há compatibilidade com seus arquivos Docker Compose existentes. Isso torna o Swarm ideal para uso rápido em ambientes internos e sandboxes de desenvolvedor que já são fortemente dockerizados.

Você não precisa colocar tudo em uma plataforma: muitas equipes usam Swarm e Kubernetes para sistemas diferentes, permitindo que os benefícios de ambos sejam percebidos. O Swarm é mais simples, fácil de manter, mais familiar para os desenvolvedores e mais rápido para dimensionar seus serviços. O Kubernetes é mais exigente para operar e baseado em suas próprias abstrações, mas oferece automação, uma solução de rede totalmente integrada e acesso a um ecossistema crescente de ferramentas de suporte.