Neste artigo, vou apresentá-lo a Kubernetes, um sistema open source para automatizar deployment, dimensionamento e gerenciamento de aplicativos containerizados.

Vamos começar com uma pergunta: você implementaria um cluster Elasticsearch no ambiente de produção da sua empresa usando o Docker em uma única máquina com vários containers, assim como você faz em sua máquina local quando está usando ou aprendendo Docker? Claro que não! Por que não? Principalmente porque você quer manter seu emprego, não é? Então, o que há de errado com essa abordagem? Vamos listar alguns argumentos abaixo:

• Os containers (instâncias Elasticsearch) estariam sendo executados em uma única máquina. O que aconteceria se essa máquina falhasse?
• Se alguns desses containers estiverem desativados, como você saberia? Além disso, você teria que fazê-los funcionar novamente por você mesmo (emitindo o comando “docker run”), e isso não é divertido às 3h da manhã.

Na verdade, mesmo se você executar esses containers em máquinas separadas, você ainda teria que, sozinho, gerenciá-los um a um.

Claro que você poderia resolver esses problemas acima executando uma unidade systemd para cada container em cada máquina, que asseguraria que os containers estariam sempre rodando. No entanto, novamente, e se as máquinas falharem? Quem teria que iniciar novos containers em outras máquinas para fazer o cluster Elasticsearch funcionar novamente? Está certo: você! No entanto, se o Kubernetes estivessem gerenciando esses containers para você, seriam eles os responsáveis por relançá-los novamente nas máquinas mais apropriadas disponíveis no cluster Kubernetes (por exemplo, as que estão menos sobrecarregadas).

Bem, esses podem ser argumentos suficientes, mas ainda há muito mais. Esqueça o Elasticsearch e imagine agora que você está rodando uma aplicação web sem estado usando containers Docker. Como você faria o deploy de uma nova versão do aplicativo? Removendo manualmente containers e lançando novos com base na nova imagem do Docker? Realmente, como um engenheiro DevOps (ou qualquer outra forma como você queira chamar), é bom ler a palavra “manualmente”? Aposto que você sabe que a chave para a cultura DevOps é automação.

Eu acho que você já está convencido de que, para fins de produção, rodar e gerenciar (ou orquestrar) ciclos de vida de container por você mesmo pode não ser uma boa ideia. Então, quem vai fazer isso por você? Isso mesmo, Kubernetes! É por isso que chamamos ferramentas como Kubernetes, Docker Swarm, Amazon ECS e outras ferramentas de orquestração de Container.

O Kubernetes possue um conjunto de excelentes recursos que são muito úteis, especialmente quando falamos de ambientes de produção:

• Replicação de containers entre diferentes nós para garantir alta disponibilidade
• Recuperação automática de container quando ele falha por qualquer motivo
• Autoescala de container com base em métricas de cluster Kubernetes, como o consumo de CPU
• Liberação de deployments e rollbacks de deployment
• Descoberta de serviço. Isso é bom para deploying de microsserviços
• Balanceamento de carga e gerenciamento de volume
• Verificações da saúde do container
• Isolamento de recursos lógicos usando Namespaces
• Controle de recursos e cotas por Namespaces
• Gerenciando tarefas cron

Na verdade, há mais do que isso! Nos próximos artigos, mergulharei em alguns conceitos de Kubernetes, como Pods, Replica Sets, Services, Deployments, e assim por diante… Aprenderemos a executar Kubernetes localmente, então, vamos fazer deploy de algumas coisas legais e nos familiarizarmos com kubectl, que é a interface de linha de comando para executar comandos contra clusters Kubernetes.

***

Jorge Acetozi faz parte do time de colunistas internacionais do iMasters. A tradução do artigo é feita pela redação iMasters, com autorização do autor, e você pode acompanhar o artigo em inglês no link: https://www.jorgeacetozi.com/single-post/why-to-use-kubernetes.