Posted on: August 01, 2022 10:00 PM

Posted by: Renato

Categories: Docker Kubernetes kube devops DevSecOps linux

Views: 860

Kubernetes vs. Docker

Considere estas definições:

• O Docker Engine é um “tempo de execução de contêiner”. Ele sabe como executar e gerenciar contêineres em um único host do sistema operacional. Você deve controlar cada host separadamente.
• Kubernetes (K8s) é uma “plataforma de orquestração de contêineres” de código aberto (AKA orquestrador). Ele sabe como gerenciar contêineres em muitos hosts do sistema operacional, que, por sua vez, executam seu próprio tempo de execução de contêiner .

Há muito o que descompactar nessas declarações. Neste post, vou abordar questões como as seguintes:

• Quais são essas ferramentas e por que são importantes?
• O “Docker Engine” é diferente do Docker?
• Todo mundo precisa do Docker e do Kubernetes?
• Quais são suas alternativas?
• E quanto ao serverless e como os contêineres estão relacionados?

Vamos cavar!

Origens do Docker

Em 2013, Solomon Hykes, CEO da Dotcloud, anunciou o projeto de código aberto Docker. Quando atingiu 1,0 em 2014, eu tentei. Foi “amor à primeira implantação”.

Quanto mais eu entendia sobre seus recursos, mais eu queria usar o Docker em todos os lugares.

O conceito de aplicativos em contêiner – usando contêineres para isolar muitos aplicativos uns dos outros em um único servidor – existe há décadas. No entanto, não havia uma ferramenta fácil de usar focada no ciclo de vida completo do aplicativo até o Docker.

A equipe que criou o Docker pegou ferramentas complexas e as envolveu em uma interface de linha de comando (CLI) que meros mortais podiam entender.

O que o Docker Engine tem a ver com o Docker?

Logo após o lançamento do Docker, os fundadores descartaram o Dotcloud e criaram a Docker Inc. Eles agora fazem uma linha de produtos com Docker no nome.

Neste post, vamos nos concentrar no projeto original, agora chamado Docker Engine. É sobre isso que as pessoas geralmente falam quando dizem “Docker” e ao que me referirei por padrão neste artigo.

Observe que o Docker também cria o Docker Desktop , um pacote de produtos para Windows e Mac. O Docker Desktop é a maneira mais fácil de executar o Docker e o Kubernetes em sua máquina local para desenvolvimento e teste de aplicativos de servidor. Milhões de pessoas o usam todos os meses, e eu o recomendo.

As três principais inovações do Docker

O Docker inventou três processos para aplicativos em contêiner que anteriormente não podíamos fazer facilmente em uma única linha de comando e daemon de servidor:

1. Embalagem fácil de aplicativos

O Docker pega seu aplicativo e todas as suas dependências de software – menos o kernel do sistema operacional e os drivers de hardware – e os agrupa em um conjunto de tarballs (semelhante a arquivos zip). O Docker garante que esses tarballs sejam idênticos em todas as máquinas em que são executados usando hash criptográfico .

Os tarballs e metadados do aplicativo são conhecidos juntos como uma imagem de contêiner. Isso agora é considerado a maneira moderna de empacotar aplicativos de servidor. O padrão de imagem de contêiner é uma grande melhoria em comparação com sistemas de empacotamento anteriores (como apt, yum, msi, npm, maven, etc.) que não contêm dependências de aplicativos.

2. Fácil execução do aplicativo

O Docker executa cada contêiner em um sistema de arquivos isolado. Cada contêiner obtém seus próprios limites de rede e recursos e não pode ver mais nada no sistema operacional do host. Ele pode fazer isso em um único e curto comando.

Essa abordagem opinativa aos contêineres mantém a CLI amigável e fácil de usar para iniciantes. É o molho secreto que tornou o Docker famoso entre os desenvolvedores.

3. Fácil distribuição de aplicativos

O Docker criou a ideia de um “registro de imagem de contêiner”, que permite armazenar imagens em um servidor HTTP/S central e fazer push/pull delas com a mesma facilidade com os commits do git. O registro mais popular é o Docker Hub e você pode encontrar muitos projetos de código aberto com imagens oficiais lá.

A ideia de um push/pull integrado para as imagens do seu aplicativo foi um sucesso instantâneo, e agora os registros de imagem de contêiner estão em toda parte. É como a versão do servidor de uma Apple/Google App Store.

As três inovações originais do Docker ajudaram a torná-lo a plataforma número 1 mais procurada por vários anos na pesquisa de desenvolvedores do Stack Overflow . Como resultado, o Docker Engine nos oferece essa linha de comando excelente e fácil de usar para humanos fazerem muitas coisas relacionadas a aplicativos em contêiner, incluindo:

• Crie imagens de contêiner com um construtor integrado (semelhante a scripts make ou bash)
• Empurre e puxe imagens de registros
• Crie e gerencie contêineres em uma única máquina
• Crie redes virtuais para que os contêineres se comuniquem no mesmo host
• Exportar/importar imagens para transporte offline
• Execute comandos personalizados em contêineres existentes
• Centralize e acesse logs de aplicativos
• E muito mais!

Se o Docker é tão bom, por que precisamos do Kubernetes?

Você descobrirá que, quando começar a usar contêineres, desejará usá-los em todos os lugares – e, quando tiver mais do que alguns servidores, começará a desejar uma maneira mais fácil de executar vários contêineres relacionados para seus aplicativos.

Com o Docker, você ainda precisa configurar manualmente as redes entre servidores, incluindo políticas de segurança, DNS, armazenamento, balanceadores de carga, backups, monitoramento e muito mais. Quando se trata de dezenas de contêineres relacionados, isso cria tanto trabalho (se não mais) quanto tínhamos antes dos aplicativos em contêiner.

Esse problema de vários servidores é o que os fundadores do Kubernetes queriam resolver. Eles sabiam que, para tornar os sistemas de contêiner de produção tão fáceis quanto o Docker é para uma única máquina, eles precisavam abordar o hardware subjacente e os recursos de rede. Kubernetes é um sistema de cluster de vários servidores de código aberto. Ele orquestra todas as ferramentas necessárias para uma solução do mundo real que hospeda dezenas, centenas ou até milhares de aplicativos. Pense nisso como uma abstração, escondendo todas as partes necessárias do processo para executar vários aplicativos em contêiner.

O Kubernetes é para um grupo de servidores o que o Docker é para um único servidor. É um conjunto de programas e APIs que controlam muitos Docker Engines a partir de uma CLI.

O Kubernetes orquestra seus contêineres usando o paradigma do “estado desejado”. Você fornece o resultado desejado (como "Executar 5 servidores da Web Apache") e ele descobre a melhor maneira de fazer isso em seu cluster Kubernetes. Em seguida, garante que esses contêineres estejam sempre em execução. Se um falhar, ele será recriado para garantir que o estado desejado corresponda ao estado real.

O Kubernetes tem um “plano de controle” de serviços padrão, que podem ser executados como contêineres do Docker. Eles controlam uma ou mais máquinas (sistemas operacionais Linux e Windows) com um agente.

O principal trabalho do Kubernetes é dizer ao Docker o que fazer, mas agora ele fornece um número crescente de tarefas relacionadas. Outros recursos integrados incluem verificações de integridade de contêiner, substituição automática de aplicativos com falha, automatização de configurações de proxy da Web, gerenciamento de políticas de segurança de rede e até mesmo provisionamento automático de armazenamento externo.

Você quer ainda mais?

Um dos recursos mais significativos do Kubernetes é sua extensibilidade na forma de Custom Resource Definitions (CRDs). Os CRDs permitem que você adicione novos tipos de objetos e funcionalidades para se tornarem recursos de primeira classe do Kubernetes. Os CRDs transformaram o Kubernetes de um gerenciador de contêineres em um mecanismo de automação completo para tudo relacionado ao gerenciamento do ciclo de vida completo do aplicativo.

Alguns plugins CRD são avançados o suficiente para que a comunidade tenha criado um novo termo para descrevê-los: Kubernetes Operators.

Precisa provisionar, gerenciar e atualizar um cluster Postgres SQL de vários nós? Os operadores podem fazer isso . Precisa de uma solução de backup para os aplicativos e uma ferramenta de recuperação de desastres de cluster? Os operadores do Kubernetes também podem fazer isso .

Usando o Docker com Kubernetes

Agora que você sabe de onde vêm essas ferramentas e quais problemas elas resolvem, a pergunta é: você deve usá-las juntas?

Sim. Por enquanto.

Se você só precisa controlar contêineres em uma única máquina e é novo em contêineres, o Docker é a melhor escolha. Mantenha-o simples para começar e você poderá se tornar um orquestrador mais tarde. Se você precisar executar vários contêineres para seus aplicativos, talvez seja hora de considerar o Kubernetes.

Você deve instalar o Kubernetes em cima do Docker?

Voltando às minhas definições iniciais, lembre-se de que o Kubernetes requer um tempo de execução de contêiner para gerenciar contêineres em seu nome. Antes de instalar o Kubernetes, você deve decidir qual tempo de execução usar.

Para quase todos os clusters de criação de sysadmin, o Docker tem sido o padrão desde o início do Kubernetes. Houve várias outras opções de tempo de execução para Kubernetes, mas o Docker tende a ter o suporte mais amplo de recursos como um tempo de execução de contêiner, especialmente no Windows Server.

A verdade é que, muitas vezes, você não precisará se preocupar em escolher um tempo de execução do contêiner. O Kubernetes é único por ser um ecossistema de escolhas em vez de um único download.

Aqui estão duas distinções significativas que diferenciam o Kubernetes dos projetos típicos de código aberto:

1. Kubernetes é um conjunto de escolhas que se juntam para formar o plano de controle. Algumas partes são padrão, como a API do Kubernetes, o Agendador e o agente Kubelet. Outras peças não têm padrão e exigem a escolha de muitas opções do setor, como tempo de execução do contêiner, rede e proxy de entrada.
2. Minha recomendação ao adotar o Kubernetes é escolher entre as mais de 100 distribuições do plano de controle do Kubernetes , de preferência escolhendo uma que esteja alinhada com seus fornecedores e requisitos existentes. Cada distribuição agrupa um conjunto dessas opções e decide o que é melhor para seus clientes. Eles geralmente fornecem uma experiência imediata mais agradável com ferramentas adicionais para ajudar na implantação, atualizações e muito mais. Essas distribuições geralmente são muito mais do que o Kubernetes de upstream vanilla que você encontrará no GitHub, e eu recomendo que você as experimente primeiro.

A maioria dos profissionais escolhe distribuições Linux (Ubuntu, CentOS, RHEL, etc.) Da mesma forma, muitas pessoas escolhem distribuições do Kubernetes para executar o Kubernetes. O plano de controle e os plugins do Kubernetes são como uma distribuição Linux; haverá apenas alguns de nós que podem juntar manualmente todas as peças para criar uma solução completa, estável e segura sem precisar de uma distribuição. A maioria das empresas não precisa desse nível de complexidade de qualquer maneira.

Todos os principais serviços de nuvem pública oferecem sua distribuição como serviço, como AWS EKS, Azure AKS, DigitalOcean Kubernetes etc. Existem várias opções específicas de fornecedor (VMWare, RedHat, NetApp) e neutras de fornecedor (Rancher, Docker Enterprise , k3s). Muitas dessas distribuições do Kubernetes, especialmente as distribuições na nuvem, decidem o tempo de execução do contêiner para você.

Usando Kubernetes sem Docker

Depois de optar por executar o Kubernetes, você raramente tocará na CLI para o tempo de execução do contêiner. Torna-se uma API de utilitário que é gerenciada pelo Kubernetes. O Docker tem um amplo conjunto de recursos que o Kubernetes nunca usará, e muitos estão procurando por um tempo de execução de contêiner menor que não seja cheio de todos os recursos “focados no usuário” do Docker.

O Kubernetes quer uma API de gerenciamento de contêiner mínima para fazer o trabalho pesado. O Kubernetes até criou um padrão de API chamado Container Runtime Interface (CRI) para incentivar mais tempos de execução além do Docker. À medida que as alternativas amadureceram, vimos o uso do Docker à medida que o CRI nos clusters do Kubernetes cai à medida que outros tempos de execução surgiram. Em 2019, o relatório de uso do Sysdig mostrou que 79% dos contêineres são executados pelo Docker Engine.

Lembra do containerd? É esse subprocesso do Docker que faz o trabalho pesado de conversar com o Kernel Linux. Bem, o containerd é agora o segundo runtime mais popular do Kubernetes. É bastante popular como uma alternativa mínima ao Docker Engine. Os provedores de serviços em nuvem costumam usá-lo como padrão devido à sua pequena área de cobertura e design e supervisão puramente de código aberto. Ele não visa ser amigável para humanos diretamente, mas sim atuar como o middleware entre seus contêineres e ferramentas como o Kubernetes.

Há também o CRI-O, um runtime criado pela Red Hat projetado exclusivamente para Kubernetes. É o padrão ao usar a distribuição Red Hat OpenShift do Kubernetes.

A propósito: não confunda essa mudança nos CRIs de cluster de servidor com o uso de desktop local por desenvolvedores e administradores de sistema. Como a imagem do contêiner é um padrão, você pode usar ferramentas diferentes para executá-las com base em suas necessidades sem se preocupar com a compatibilidade.

Com a abordagem amigável do Docker, ainda a vejo usada por todos que conheço como sua maneira padrão de executar contêineres localmente (principalmente por meio do Docker Desktop e Docker Compose).

Você ainda precisa do Kubernetes?

Você ouvirá as pessoas (especialmente eu) falarem sobre o quão complexo o Kubernetes pode ser. As duas maiores desvantagens do Kubernetes são a complexidade de aprender e gerenciar clusters do Kubernetes e a sobrecarga extra de recursos de hardware necessários. Isso faz uma grande diferença, tanto que às vezes leva meus alunos e clientes a procurar abordagens alternativas.

O fato é que os operadores escreveram o Kubernetes para os operadores. Pode ser difícil pular da ferramenta amigável do Docker focada no desenvolvedor para o mundo detalhado e sem opinião do Kubernetes . Os projetos estão tentando resolver as partes difíceis como k3s e Rio , mas está longe de ser fácil se você estiver gerenciando um cluster personalizado. O Kubernetes pode suportar requisitos grandes e complexos. Isso também significa que é provavelmente desnecessário se tudo o que você precisa é de algumas dúzias de contêineres e três a cinco servidores.

Costumo trabalhar com equipes de engenharia responsáveis ​​por criar sua infraestrutura. Costumamos gastar muito do nosso tempo descobrindo se precisamos do Kubernetes. O Kubernetes é, sem dúvida, o orquestrador multisservidor de contêiner mais popular na maioria dos círculos, mas existem alternativas notáveis, como:

• AWS ECS – a Amazon criou essa solução proprietária antes que o Kubernetes fosse popular e permaneceu como a alternativa mais direta ao AWS EKS.
• Docker Swarm – Agora mantido pela Mirantis, esse recurso interno do Docker Engine funciona muito bem para muitos dos meus alunos do Docker. É conhecido por sua facilidade de configuração e implantação de aplicativos. É lento para progredir em novos recursos, mas muitas empresas confiam nele diariamente.
• HashiCorp Nomad – Tem uma base de fãs leal e um fluxo constante de atualizações.

Pessoalmente, sou fã do Docker Swarm e de qualquer coisa que a HashiCorp faça.

E sem servidor?

Se sua equipe já está seguindo esse caminho, ótimo. Sob o capô da maioria das infraestruturas sem servidor, ele está executando suas funções em contêineres.

O Serverless trata contêineres e orquestradores como abstrações de nível inferior que outra pessoa gerenciará.

Você pode desfrutar da execução de suas funções em cima desses contêineres e orquestradores que gerenciam toda a sobrecarga para economizar o tempo de sua equipe controlando os servidores. Abstrações como essa removem o encanamento da infraestrutura e provavelmente são o futuro para muitos de nós.

Lembre-se, as ferramentas não são o objetivo final.

Independentemente de você escolher Docker, Kubernetes ou serverless, lembre-se de que a ferramenta não é o objetivo final. Tenha sempre em mente os objetivos de DevOps da sua empresa e tente não se distrair com o apelo “brilhante” das ferramentas avançadas apenas para usar novas tecnologias interessantes.

As métricas do projeto de implementação de contêiner geralmente se concentram em aumentar a velocidade e, ao mesmo tempo, aumentar a confiabilidade.

Os objetivos que costumo focar ao implementar essas ferramentas incluem:

1. Aumentando a agilidade – tempo desde a ideia de negócio até a entrega ao cliente
2. Reduzindo o tempo de implantação – tempo desde a confirmação até a implantação do servidor
3. Aumentando a resiliência – com que frequência você tem falhas, mas, mais importante, com que rapidez elas são corrigidas

Os contêineres e suas ferramentas podem melhorar todos esses fatores. Ainda assim, eles virão com seus próprios “novos problemas” e carga de trabalho adicional. Esteja ciente dos trade-offs ao escolher suas ferramentas.

Desejo-lhe boa sorte em sua jornada de contêineres e que todas as suas implantações sejam bem-sucedidas!

....

Fonte:

https://www.bretfisher.com/kubernetes-vs-docker/

Renato

Developer

No comments yet! Be the first to comment