A virtualização de hardware oferece uma lista de vantagens, como escalabilidade, segurança, isolamento, etc., utilizando 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 o 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 fornecer aplicativos, incluindo aplicativos desenvolvidos usando a arquitetura de software baseada em microsserviços, e incluem todos os componentes necessários para executar aplicativos.
O Docker engine é a plataforma mais popular para executar containers. Kubernetes é um termo que você pode ouvir com mais frequência na esfera de 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 motor usado para executar aplicativos em contêineres. Ele é instalado no seu sistema operacional (SO), preferencialmente no Linux, mas também pode ser instalado no Windows e no 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 único arquivo de configuração YAML (yml) do Docker Compose para definir aplicativos de vários contêineres em vez de configurar manualmente arquivos Dockerfiles separados para cada contêiner. Depois de 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 há uma poderosa alternativa ao Docker Compose disponível, que se chama Kubernetes.
O que é 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 para 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 exigido 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ó).
- O 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 deles.
Diferentes CLI e APIs são usadas para comunicar serviços entre si se o Kubernetes for usado. Também existem termos específicos que são usados para nomear objetos e recursos da API RESTful, que são componentes do cluster construído com Kubernetes. - Pod é uma unidade básica de agendamento no Kubernetes. Este é um grupo de recursos nos quais vários containers podem funcionar. Os 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 estão isolados, mas podem se comunicar entre si facilmente. Assim, os Pods geralmente são usados no Kubernetes, mas se você usar um aplicativo Docker independente, apenas os pools 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 o nomeamento dinâmico e o balanceamento de carga de Pods usando abstrações. Essa abordagem garante uma conexão transparente entre serviços pelo nome e permite que você rastreie seu estado atual.
- Etiquetas 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 Kubernetes unido em múltiplos clusters virtuais. Cada cluster virtual pode existir dentro de um ambiente virtual limitado por cotas sem impactar 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 trabalhar 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 em 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ço de rede (NAT), o que permite que os contêineres se comuniquem entre si e se conectem a redes externas. Você pode configurar redirecionamento de porta para a interface de rede da máquina host se desejar se conectar a um contêiner a partir 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 host garante que um contêiner não fique 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 determinado contêiner, 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 de vários hosts para contêineres Docker. Se os contêineres estiverem sendo executados em hosts diferentes, eles podem se comunicar entre si depois de configurar a rede de sobreposição. Um serviço de armazenamento de chave-valor válido (Consul, Etcd ou ZooKeeper) deve ser configurado para criar tais redes.
Kubernetes. Se você usar 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 você estiver usando o Kubernetes, os 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 usados para tarefas relacionadas. Os 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 container de pausa especial para cada Pod. Este container especial destina-se a fornecer uma interface de rede (para comunicação interna e externa) para outros containers, e geralmente está em pausa (em modo de espera). Esses containers de pausa são ativados quando o Kubernetes envia um sinal “SIGTERM”.
O Flannel é tipicamente usado como uma estrutura de rede para conectar containers no Kubernetes usando princípios de sobreposição de rede. A sobreposição de rede permite que você execute containers 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 de código aberto etcd é usado para salvar os mapeamentos entre os endereços IP reais atribuídos aos containers pelos hosts nos quais os containers estão em execução, 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 Container NSX. Essa integração permite que você use uma topologia de rede multi-inquilino que não está disponível “pronta para uso” no Kubernetes.
O modelo de rede do Kubernetes fornece os seguintes recursos:
- Todos os containers podem se comunicar com qualquer outro container dentro de um cluster sem NAT.
- Todos os nós do cluster podem se comunicar com todos os containers dentro de um cluster sem NAT. Inversamente, todos os containers podem se comunicar com todos os nós do cluster.
- Os containers veem seus próprios endereços IP e esses endereços IP são vistos por outros componentes do Kubernetes.
Ingress é um objeto de API do Kubernetes usado para gerenciar o acesso a 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, término de SSL e hospedagem virtual baseada em nome. Um controlador de Ingress deve ser implantado no nó mestre para que as regras de Ingress funcionem.
Casos de Uso
Usar o Docker como 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 você deseja usar o Docker para executar um grande número de contêineres no ambiente de produção, pode encontrar algumas complicações pelo caminho. Por exemplo, alguns contêineres podem ser facilmente sobrecarregados ou falhar. Você pode reiniciar manualmente o contêiner na máquina apropriada, mas a gestão 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 é usado para desenvolvimento e teste.
Kubernetes vs Docker Swarm
Docker Swarm é uma ferramenta de agrupamento nativa para Docker que pode transformar um conjunto de hosts Docker em um único host virtual. O Docker Swarm é totalmente integrado com o Docker Engine e permite que você use APIs padrão e processos de rede; é 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 a orquestração de controle, gerenciamento do 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 realizar funções de nó gerenciador e nó trabalhador. Observe que os nós trabalhadores executam serviços do swarm.
Serviços. Um serviço do Docker Swarm define o estado ótimo necessário para cada serviço em contêiner. 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 espaço no qual um único contêiner está em execução. Tarefas são partes de um serviço do Swarm.
Assim, Docker Swarm e Kubernetes são duas plataformas diferentes usadas para propósitos similares. Agora é hora de compará-las em um conjunto apropriado de categorias.
Implantação de Cluster
Docker Swarm. Uma API Docker padrão permite que você implante um cluster com o Swarm usando uma CLI (interface de linha de comando) Docker padrão que facilita a implantação, especialmente quando usada pela primeira vez. A facilidade de implantação para o Swarm, quando comparada ao Kubernetes, também é alcançada pela capacidade de um único mestre Docker decidir como distribuir os serviços. Não são usados Pods no Docker Swarm.
Kubernetes requer que você use comandos especificados que são diferentes dos comandos Docker padrão. APIs especificadas são usadas no Kubernetes, o que significa que mesmo que você saiba os comandos para gerenciamento do Docker, você também pode precisar aprender a usar um conjunto adicional de ferramentas para implantação do Kubernetes. Os nós devem ser definidos manualmente no cluster Kubernetes – você deve selecionar o nó mestre, definir o controlador, agendador, etc.
Escalaridade
Docker Swarm. Graças à API simples fornecida pelo Docker, a implantação de contêineres e a atualização de serviços em clusters grandes e pequenos podem ser feitas 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 quando comparado ao 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 auto-escala, o Kubernetes é preferível devido à sua capacidade de analisar cargas do 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 similares, e em ambos os casos o sistema é auto-regulado e não requer reconfiguração manual após um nó falho voltar a fazer parte de um cluster.
Docker Swarm. Os nós gerenciadores lidam com os recursos dos nós de trabalho e todo o cluster. Os nós do cluster Swarm participam na replicação de serviços.
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ó em que uma aplicação containerizada está em execução falhe.
Balanceamento de carga
Docker Swarm. O balanceamento de carga é um recurso integrado e pode ser realizado automaticamente usando a rede Swarm interna. 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 solicitações de entrada para nomes de serviço.
Kubernetes. As políticas definidas em Pods são utilizadas 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 a CLI do Docker podem ser utilizados quando o Docker Swarm é utilizado, 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 a CLI do Docker não podem ser usados para implantar contêineres nesse caso. No Kubernetes, o sistema para definir serviços segue um princípio de funcionamento semelhante 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 um 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 redes para um único nó no cluster (muito parecido com o Docker Compose para um aplicativo Docker autônomo sem Swarm), e os serviços do Kubernetes são responsáveis pela configuração da operação do serviço dentro do cluster, tolerância a falhas, etc.
Redes
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, sendo um deles o Flannel, a opção mais popular. Os Pods interagem entre si, e essa interação pode ser restrita por políticas. Há 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, 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 este 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 monitorar serviços de contêineres.
Interface Gráfica do Usuário (GUI)
Docker Swarm. A GUI pode ser habilitada com ferramentas de terceiros, como o Portainer.io, que fornece uma interface web amigável. Como alternativa, você pode usar a Edição Empresarial do Docker que fornece uma interface gráfica para gerenciamento de cluster.
Kubernetes. O GUI fornecido pelo Kubernetes é um painel confiável que pode ser acessado através de uma interface web com a qual você pode facilmente controlar seu cluster. O 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 usa principalmente a API e a CLI do Docker. O Kubernetes, por outro lado, é um projeto do Google usado para implantar um cluster no qual os contêineres estão em execução.
Ambos o Docker Swarm e o Kubernetes fornecem recursos de alta disponibilidade, balanceamento de carga, rede de sobreposição e escalabilidade. O Docker Swarm é mais fácil de implantar, pois a maior parte de sua configuração de recursos é automatizada, e consome poucos recursos de hardware. No entanto, a funcionalidade é limitada pela API do Docker, e faltam ferramentas de monitoramento nativas.
O Kubernetes, por sua vez, é uma solução modular com um alto nível de flexibilidade que tem sido apoiada pela maioria das grandes entidades corporativas por vários anos. Ferramentas integradas para monitoramento de serviços e de todo o cluster estão disponíveis para o Kubernetes, embora a implantação e 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 aplicativos multi-contêiner altamente carregados.