A virtualização de hardware oferece uma lista de vantagens, como escalabilidade, segurança, isolamento, etc., usando hipervisores para compartilhar hardware físico com máquinas virtuais (VMs). Atualmente, as máquinas virtuais não são a única forma de virtualização, pois os containers também se tornaram bastante populares. Enquanto as VMs compartilham hardware físico das máquinas subjacentes, os containers compartilham o kernel do sistema operacional subjacente. Os containers não são máquinas virtuais leves, mas são pacotes executáveis padronizados usados para entregar aplicativos, incluindo aplicativos que são desenvolvidos usando a arquitetura de software baseada em microsserviços e incluem todos os componentes necessários para executar aplicativos.
O motor Docker é a plataforma mais popular para executar containers. Kubernetes é um termo que você pode ouvir com frequência crescente na esfera da containerização e computação em nuvem. Mas o que é melhor – Docker ou Kubernetes? É um tópico popular de debate, mas formular dessa maneira não é tecnicamente correto. Por exemplo, você não pode perguntar: “O que é melhor – quente ou azul?”
O que é Docker?
O Docker é um aplicativo autônomo de código aberto que funciona como um mecanismo usado para executar aplicativos containerizados. Ele é instalado no seu sistema operacional (SO), preferencialmente no Linux, mas também pode ser instalado no Windows e macOS, que por sua vez é executado em uma máquina física ou virtual.
Uma aplicação em execução em um contêiner é isolada do restante do sistema e de outros contêineres, mas dá a ilusão de estar sendo executada em sua própria instância de sistema operacional. Múltiplos contêineres Docker podem ser executados no mesmo sistema operacional simultaneamente; você pode gerenciar esses contêineres com o Docker, e o Docker pode ser executado sem o Kubernetes. Se você tiver vários hosts para executar contêineres, gerenciá-los manualmente pode ser difícil, e geralmente é melhor selecionar uma ferramenta de gerenciamento centralizada ou uma solução de orquestração.
O Docker Compose é uma ferramenta básica de orquestração de contêineres usada para executar aplicativos Docker de vários contêineres. Você pode configurar um arquivo de configuração Docker Compose YAML (yml) para definir aplicativos de vários contêineres em vez de configurar manualmente arquivos Dockerfiles separados para cada contêiner. Após configurar o único arquivo YAML, você pode executar todos os contêineres necessários com um único comando em seu console Linux. Usar o Docker Compose é uma maneira de orquestrar seus contêineres Docker, mas existe uma poderosa alternativa ao Docker Compose disponível chamada Kubernetes.
O Que É o Kubernetes?
O Kubernetes é uma solução de orquestração de contêineres de código aberto usada para gerenciar software e serviços containerizados com um alto grau de automação.
O Kubernetes é um projeto do Google destinado a automatizar implantação, dimensionamento e disponibilidade de aplicativos em execução em contêineres. Você pode aumentar o número de hosts executando contêineres até 11 ou mais hosts. Além disso, você pode criar um cluster de contêineres Docker com o Kubernetes para garantir alta disponibilidade e balanceamento de carga.
Hospedeiros que são usados em um cluster são chamados de nós. O tipo de arquitetura do Kubernetes é mestre-escravo – o cluster consiste em nós mestres e nós de trabalho. O número mínimo recomendado de nós necessários pelo Kubernetes é quatro. Embora você possa construir um cluster com uma máquina, para executar todos os exemplos e testes, você precisa de pelo menos quatro nós. Um cluster do Kubernetes que lida com o tráfego de produção deve ter um mínimo de três nós de trabalho. O uso de dois nós mestres protege seu cluster contra a falha de um nó mestre. Você pode usar mais de dois nós mestres, se necessário.
- Nós mestres são usados para gerenciar o estado de um cluster, que inclui aceitar solicitações de clientes, agendar operações com contêineres, executar loops de controle, etc. Uma cópia do etcd banco de dados que armazena todos os dados do cluster precisa ser executada em cada nó mestre. O nó mestre executa um conjunto dos três processos: kube-apiserver, kube-controller-manager e kube-scheduler.
- Nós de trabalho são usados para executar cargas de trabalho de aplicativos executando contêineres. Os dois processos do Kubernetes são executados no nó não-mestre: kubelet (para se comunicar com os nós mestres) e kube-proxy (para refletir os serviços de rede do Kubernetes em cada nó).
- Controlador de Replicação é um componente usado para garantir que as réplicas de Pods, cujo número é especificado, estejam sempre em execução em qualquer momento dado. Assim, você pode garantir que os Pods estejam sempre disponíveis sempre que precisar.
Diferentes CLI e APIs são usadas para comunicar serviços entre si se o Kubernetes for usado. Existem também termos específicos que são usados para nomear objetos e recursos da API RESTful que são componentes do cluster construído com o Kubernetes. - Pod é uma unidade básica de agendamento no Kubernetes. Este é um grupo de recursos em que múltiplos containers podem trabalhar. Containers que pertencem a um Pod podem ser executados no mesmo host e usar os mesmos recursos e a mesma rede local. Os containers no Pod são isolados, mas podem se comunicar entre si com facilidade. Assim, os Pods são geralmente usados no Kubernetes, mas se você usar um aplicativo Docker independente, apenas grupos de containers estão disponíveis.
- Serviço é um conjunto de containers que trabalham juntos fornecendo, por exemplo, o funcionamento de uma aplicação de várias camadas. O Kubernetes suporta a nomeação dinâmica e o balanceamento de carga de Pods usando abstrações. Esta abordagem garante uma conexão transparente entre os serviços pelo nome e permite rastrear seu estado atual.
- Labels são pares de chave/valor que estão vinculados a Pods e outros objetos ou serviços, além de permitir agrupá-los facilmente e atribuir tarefas.
- Namespaces é um método que permite dividir logicamente o cluster unificado do Kubernetes em múltiplos clusters virtuais. Cada cluster virtual pode existir dentro de um ambiente virtual limitado por quotas sem afetar outros clusters virtuais.
O Kubernetes pode ser usado com o Docker, embora o Docker não seja a única plataforma de contêineres com a qual o Kubernetes pode ser usado. O Kubernetes também pode funcionar em conjunto com contêineres do Windows, contêineres do Linux, rkt, etc. K8s é o nome do Kubernetes que às vezes pode ser encontrado na documentação técnica.
Kubernetes vs Docker: Comparação de Rede
Vamos revisar as opções de rede para cada solução.
Docker fornece três modos de rede para comunicação de rede entre contêineres.
Bridge. Este modo é usado por padrão, criando uma ponte virtual de camada 3. O nome da rede no seu host é docker0 para esta rede. O Docker cria automaticamente uma ponte de rede de camada 3 e configura regras de masquerading para a interface de rede externa, usando o princípio de tradução de endereços de rede (NAT), que permite que os contêineres se comuniquem entre si e se conectem a redes externas. Você pode configurar o encaminhamento de porta para a interface de rede da máquina host se desejar se conectar a um contêiner de outros hosts e redes externas. Assim, ao se conectar à porta apropriada da máquina host, você é encaminhado para a porta necessária do contêiner Docker. Você pode criar mais de uma interface de rede para um contêiner Docker, se necessário.
Host. Neste modo, um driver de rede de hospedeiro garante que um contêiner não esteja isolado do host Docker. O contêiner compartilha a pilha de rede do host, e o nome do host do contêiner é o mesmo que o nome do host do sistema operacional do host. Se você executar um contêiner no qual uma porta TCP 8080 está sendo ouvida, a aplicação do contêiner estará disponível na porta TCP 8080 do endereço IP da máquina host. O driver de rede do host está disponível apenas para máquinas Linux.
Nenhum. Nenhum endereço IP é configurado para a interface de rede de um contêiner específico, exceto o endereço 127.0.0.1 para a interface de loopback. Não há acesso a redes externas se o modo de rede Nenhum estiver definido.
Rede multi-hospedeira para contêineres Docker. Se os contêineres estiverem sendo executados em hosts diferentes, eles podem se comunicar entre si após a configuração da rede de sobreposição. Um serviço de armazenamento de chave-valor válido (Consul, Etcd ou ZooKeeper) deve ser configurado para criar essas redes.
Kubernetes. Se você estiver usando contêineres Docker autônomos, cada contêiner pode ser considerado uma unidade básica que se comunica via rede usando a interface de rede apropriada. Se estiver usando Kubernetes, Pods são as unidades básicas do cluster de contêineres. Cada pod tem seu próprio endereço IP e consiste em pelo menos um contêiner. Um Pod pode consistir em vários contêineres que são usados para tarefas relacionadas. Contêineres do mesmo Pod não podem abrir a mesma porta simultaneamente. Esse tipo de restrição é usado porque um Pod que consiste em vários contêineres ainda tem um único endereço IP.
Além disso, o Kubernetes cria um contêiner de pausa especial para cada Pod. Este contêiner especial destina-se a fornecer uma interface de rede (para comunicação interna e externa) para outros contêineres e geralmente está em pausa (em modo de suspensão). Esses contêineres de pausa são ativados quando o Kubernetes envia um sinal “SIGTERM”.
O Flannel é tipicamente usado como uma estrutura de rede para conectar contêineres no Kubernetes usando princípios de sobreposição de rede. A sobreposição de rede permite executar contêineres comunicando-se por meio da rede lógica em diferentes hosts físicos do cluster (que são referidos como nós). O armazenamento de chave/valor etcd de código aberto é usado para salvar as correspondências entre os endereços IP reais atribuídos aos contêineres pelos hosts nos quais os contêineres estão sendo executados e os endereços IP na rede de sobreposição.
A rede do Kubernetes pode ser integrada com o VMware NSX-T usando o Plugin de Contêiner NSX. Essa integração permite usar uma topologia de rede multinível que não está disponível “pronta para uso” no Kubernetes.
O modelo de rede do Kubernetes oferece as seguintes características:
- Todos os contêineres podem se comunicar com qualquer outro contêiner dentro de um cluster sem NAT.
- Todos os nós do cluster podem se comunicar com todos os contêineres dentro de um cluster sem NAT. Inversamente, todos os contêineres podem se comunicar com todos os nós do cluster.
- Os contêineres veem seus próprios endereços IP e esses endereços IP são vistos por outros componentes do Kubernetes.
O Ingress é um objeto de API do Kubernetes que é usado para gerenciar o acesso aos serviços no cluster de fora (principalmente HTTP e HTTPS). Você pode configurar o Ingress para realizar acesso externo aos serviços containerizados, para balanceamento de carga, terminação SSL e hospedagem virtual baseada em nome. Um controlador de Ingress deve ser implantado no nó mestre para que as regras de ingresso funcionem.
Casos de Uso
O uso do Docker como um software independente é bom para o desenvolvimento de aplicativos, pois os desenvolvedores podem executar seus aplicativos em ambientes isolados. Além disso, os testadores também podem usar o Docker para executar aplicativos em ambientes de sandbox. Se desejar usar o Docker para executar um grande número de contêineres no ambiente de produção, você pode encontrar algumas complicações ao longo do caminho. Por exemplo, alguns contêineres podem ser facilmente sobrecarregados ou falhar. Você pode reiniciar manualmente o contêiner na máquina apropriada, mas o gerenciamento manual pode consumir muito do seu tempo e energia valiosos.
O Kubernetes permite resolver esses problemas fornecendo recursos-chave como alta disponibilidade, balanceamento de carga, ferramentas de orquestração de contêineres, etc. Como resultado, o Kubernetes é mais adequado para ambientes de produção altamente carregados com um grande número de contêineres Docker. Implantar o Kubernetes é mais difícil do que instalar um aplicativo Docker independente, razão pela qual o Kubernetes nem sempre pode ser usado para desenvolvimento e testes.
Kubernetes vs Docker Swarm
Docker Swarm é uma ferramenta de clusterização nativa para Docker que pode transformar um conjunto de hosts Docker em um único host virtual. O Docker Swarm está totalmente integrado com o Docker Engine e permite que você utilize APIs padrão e processos de rede; ele é destinado a implantar, gerenciar e dimensionar contêineres Docker.
O Swarm é um cluster de hosts Docker chamados de nós. Vamos considerar os seguintes componentes principais de um cluster ao usar o Docker Swarm antes de comparar a implantação do cluster com Kubernetes e Docker Swarm:
Nós gerenciadores são usados para realizar orquestração de controle, gerenciamento de cluster e distribuição de tarefas.
Nós trabalhadores são usados para executar contêineres cujas tarefas são atribuídas pelos nós gerenciadores. Cada nó pode ser configurado como um nó gerenciador, nó trabalhador ou como ambos, para desempenhar funções de nó gerenciador e nó trabalhador. Observe que os nós trabalhadores executam serviços de enxame.
Serviços. Um serviço do Docker Swarm define o estado ideal necessário para cada serviço containerizado. Um serviço controla parâmetros como o número de réplicas, os recursos de rede disponíveis para ele, as portas que devem ser acessíveis a partir de redes externas, etc. A configuração do serviço, como a configuração de rede, pode ser modificada e aplicada a um contêiner sem exigir que você reinicie o serviço com o contêiner manualmente.
Tarefas. Uma tarefa é um slot no qual um único contêiner está em execução. As tarefas são as partes de um serviço de Swarm.
Assim, Docker Swarm e Kubernetes são duas plataformas diferentes usadas para propósitos semelhantes. Agora é hora de compará-los em um conjunto apropriado de categorias.
Implantação de cluster
Docker Swarm. Uma API Docker padrão permite implantar um cluster com Swarm usando uma interface de linha de comando (CLI) Docker padrão, o que torna a implantação mais fácil, especialmente quando usada pela primeira vez. A facilidade de implantação para Swarm em comparação com Kubernetes também é alcançada pela capacidade de um único mestre Docker decidir como distribuir serviços. Não são usados Pods no Docker Swarm.
Kubernetes exige que você use comandos especificados que são diferentes dos comandos Docker padrão. APIs específicas são usadas no Kubernetes, o que significa que, mesmo que você conheça os comandos para gerenciamento do Docker, também pode ser necessário aprender a usar um conjunto adicional de ferramentas para implantação do Kubernetes. Os nós devem ser definidos manualmente no cluster do Kubernetes – você deve selecionar o nó mestre, definir o controlador, o escalonador, etc.
Escalabilidade
Docker Swarm. Graças à API simples fornecida pelo Docker, a implantação de contêineres e atualização de serviços em grandes e pequenos clusters pode ser feita mais rapidamente. Uma interface de linha de comando (CLI) é bastante simples e fácil de entender. Como resultado, o Swarm pode ser considerado uma solução mais escalável em comparação com o Kubernetes.
O Kubernetes fornece APIs comparativamente unificadas e uma série de recursos que frequentemente resultam em um processo de implantação mais lento. Existem três tipos de componentes que devem ser configurados: Pod, Deploy e Service. Quando se trata de autoescalabilidade, o Kubernetes é preferível devido à sua capacidade de analisar cargas de servidor, além de fornecer a oportunidade de dimensionar automaticamente para cima e para baixo de acordo com os requisitos dados. O Kubernetes é a escolha ideal para redes distribuídas grandes e sistemas complexos.
Alta disponibilidade
As duas opções de solução possuem mecanismos de replicação de serviço e redundância semelhantes, e em ambos os casos o sistema é auto-regulado e não requer reconfiguração manual após um nó falho retornar ao cluster.
Docker Swarm. Os nós gerentes lidam com os recursos dos nós de trabalho e de todo o cluster. Os nós do cluster Swarm participam da replicação de serviços.
O Kubernetes. Nós não saudáveis são detectados pelos serviços de balanceamento de carga do Kubernetes e são eliminados do cluster. Todos os Pods são distribuídos entre os nós, fornecendo assim alta disponibilidade, caso um nó no qual uma aplicação em contêiner está sendo executada falhe.
Balanceamento de carga
Docker Swarm. O balanceamento de carga é um recurso integrado e pode ser executado automaticamente usando a rede interna do Swarm. Todas as solicitações ao cluster são distribuídas e redirecionadas para os nós do cluster; qualquer nó pode se conectar a qualquer contêiner. Um elemento DNS é usado pelo Docker Swarm para distribuir as solicitações recebidas para nomes de serviço.
Kubernetes. As políticas definidas nos Pods são usadas para balanceamento de carga no Kubernetes. Neste caso, os Pods de contêiner devem ser definidos como serviços. Você tem que configurar manualmente as configurações de balanceamento de carga, enquanto o Ingress pode ser utilizado para balanceamento de carga.
Criando e executando contêineres
Docker Swarm. A grande maioria dos comandos disponíveis para o Docker CLI pode ser utilizada quando o Docker Swarm é usado, graças à API padronizada do Docker Swarm. O Docker Compose define o trabalho com volumes e redes utilizadas, além de definir quais contêineres devem ser agrupados juntos. O número preciso de réplicas pode ser definido com o Docker Compose para o Docker Swarm.
Kubernetes. O Kubernetes tem sua própria API, cliente, e precisa de arquivos YAML para serem configurados. Esta é uma das principais diferenças, pois o Docker Compose e o Docker CLI não podem ser usados para implantar contêineres neste caso. No Kubernetes, o sistema para definir serviços segue um princípio de funcionamento similar ao do Docker Compose, mas é mais complexo. A funcionalidade do Docker Compose é realizada usando Pods, Implantações e Serviços no Kubernetes, dentro dos quais cada camada é usada para seu próprio propósito especificado. Os Pods são responsáveis pela interação do contêiner, enquanto as implantações são responsáveis pela alta disponibilidade e rede para um único nó no cluster (muito parecido com o Docker Compose para um aplicativo Docker independente sem Swarm), e os serviços Kubernetes são responsáveis pela configuração da operação do serviço dentro do cluster, tolerância a falhas, etc.
Rede
Docker Swarm. Existe uma rede interna padrão para comunicação de contêineres dentro de um cluster, na qual mais redes podem ser adicionadas se necessário. As redes são protegidas com certificados TLS gerados. A geração manual de certificados é suportada para a criptografia do tráfego de dados do contêiner.
Kubernetes. O modelo de rede do Kubernetes é bastante diferente e é implementado usando plugins, um dos quais é o Flannel, a opção mais popular. Os pods interagem entre si, e essa interação pode ser restrita por políticas. Existe uma rede interna gerenciada pelo serviço etcd. A criptografia TLS também está disponível, mas deve ser configurada manualmente. O modelo de rede do Kubernetes presume a configuração de dois CIDRs, Classless Inter-Domain Routing, que também é conhecido como supernetting.
Monitoramento
Docker Swarm. Não há ferramentas integradas para monitoramento e registro, embora você possa configurar manualmente ferramentas de monitoramento de terceiros. ELK ou Reimann podem ser usados para esse fim.
Kubernetes. Ferramentas integradas são fornecidas pelo Kubernetes para registro e monitoramento. Elasticsearch e Kibana (ELK) podem ser usados para monitorar todo o estado do cluster, enquanto Heapster, Grafana e Influx são suportados para monitoramento de serviços de contêineres.
Interface Gráfica do Usuário (GUI)
Docker Swarm. A GUI pode ser habilitada com ferramentas de terceiros como Portainer.io, que fornece uma interface web amigável. Como alternativa, você pode usar a Edição Enterprise do Docker que fornece uma interface gráfica para gerenciamento de clusters.
Kubernetes. A interface gráfica fornecida pelo Kubernetes é um painel confiável que pode ser acessado através de uma interface web com a qual você pode controlar facilmente o seu cluster. A GUI pode ser uma ferramenta altamente valiosa para usuários com pouca experiência em gerenciar o Kubernetes com a CLI.
Conclusão
O Docker Swarm é uma solução nativa do Docker que utiliza principalmente a API e a CLI do Docker. Kubernetes, por outro lado, é um projeto do Google usado para implantar um cluster no qual os contêineres estão em execução.
Ambos Docker Swarm e Kubernetes fornecem alta disponibilidade, balanceamento de carga, redes de sobreposição e recursos de escalabilidade. O Docker Swarm é o mais fácil dos dois para implantação, pois a maioria de suas configurações de recursos é automatizada e consome poucos recursos de hardware. No entanto, a funcionalidade é limitada pela API do Docker, e ferramentas nativas de monitoramento estão ausentes.
O Kubernetes, por outro lado, é uma solução modular com um alto nível de flexibilidade, que tem sido apoiada pela maioria das grandes entidades corporativas há vários anos. Ferramentas integradas para monitorar serviços e todo o cluster estão disponíveis para o Kubernetes, embora a implantação e a configuração sejam mais difíceis, tornando este recurso uma solução mais exigente. O Kubernetes não é compatível com a CLI do Docker e o Docker Compose. O uso do Kubernetes é preferido em ambientes grandes onde estão em execução aplicações multi-contêiner altamente carregadas.