Você já deve ter ouvido falar de Kubernetes, né? Já fizemos um artigo com uma pequena introdução sobre o assunto, diferenciando de Openshift e Docker. Neste artigo, porém, vou explicar o que é, para quê serve e porque a comunidade está bem interessada em usá-lo para escalar ambientes em produção. Bora lá?

O Kubernetes

Antes de começar, vou dar uma pista:

Esse aí é o logotipo do Kubernetes, um leme de navio. Dá para imaginar o que ele faz? Vamos lá então, marujos! Está na hora de assumir o controle desses Containers!

O Kubernetes, ou K8S (um trocadilho com o nome Kubernetes: k + 8 caracteres + s) ou “kube”, para aqueles que já estão mais íntimos, é um sistema de cluster e orquestração para containers Docker que suporta outros sistemas de container, como o Rocket, por exemplo.

Em outras palavras, o Kubernetes é uma ferramenta de código aberto usada para orquestrar e gerenciar clusters de containers. Só que aqui, o cluster é composto por várias máquinas com uma engine de container, que no nosso caso, e na maioria de todos os casos, é o Docker, a engine mais usada para esse trabalho de provisionar os containers nos hosts do cluster.

O Kubernetes entra aqui para gerenciar esses hosts e executar demandas que são recebidas pelo cluster. Muita gente ainda tem dúvida ou faz confusão tentando comparar Docker e Kubernetes, mas a comparação correta seria “Docker Swarm” e Kubernetes, ambas ferramentas de orquestração de cluster. O Kubernetes usa o Docker para criar os containers nos nós do cluster. O trabalho dele aqui é gerenciar, controlar e monitorar o estado desses containers ao longo do cluster.

Um pouco de história

O Kubernetes foi criado e desenvolvido pelos engenheiros da Google, uma das pioneiras no desenvolvimento da tecnologia de containers.

A Google já revelou que executa alguns dos seus serviços em containers, como Google Docs e Gmail, por exemplo, e tem alguns números surreais: são mais de 2 bilhões de implantações de contêineres por semana, que são viabilizadas por uma plataforma interna chamada Borg, antecessor do Kubernetes e que serviu como base para seu desenvolvimento.

Em 2015 o Kubernetes foi doado para a “Cloud Native Computing foundation” e Linux Foundations, e se tornou um projeto Open Source. Uma curiosidade sobre o Kubernetes é que os sete raios do logotipo fazem referência ao nome original do projeto, “Project Seven of Nine” (Projeto Sete de Nove).

A palavra Kubernetes vem da palavra grega Kuvernetes, que representa a pessoa que pilota o navio.

Estrutura do Kubernetes

O Kubernetes possui alguns termos e componentes para determinadas funções e tarefas. Inicialmente pode parecer confuso e não fazer muito sentido alguns desses componentes, mas ao começar a usar o Kubernetes e a entender a forma como ele trabalha, fica mais fácil saber o que cada carinha desse faz.

Antes deles, porém, vamos falar sobre como é a estrutura do cluster. Até aqui é bem parecido com o Swarm, no qual temos os Masters e os nós Workes, que aqui chamávamos de “Minions“. Esse conceito não é mais usado, mas ainda pode ser encontrado em alguns artigos e documentações mais antigas.

Master, por sua vez, é a máquina que controla os nós do Kubernetes. É nela que todas as atribuições de tarefas do cluster se originam. No Master temos todos os componentes rodando, assim:

Agora vamos aos componentes, ou os serviços que sobem na máquina Master para manter o estado desejado dos nossos serviços no cluster. São quatro:

• ETCD: é uma base de dados de chave valor. Ele armazena os dados de configuração do cluster e o estado do cluster;
• API Server: fornece API kubernetes usando Jason. Estados de objetos da API são armazenados no ETCD, e o kubectl usa o API Serve para se comunicar com o cluster;
• Controller Manager: monitora os controladores de replicação e cria os pods para manter o estado desejado;
• Scheduler: é responsável por executar as tarefas de agendamento, como execução de contêineres nos minions com base na disponibilidade de recursos.

Kubectl é um utilitário de linha de comando que se conecta ao servidor API, usado pelos administradores para criar pods, deployments, serviços, etc. Vamos usa-lo bastante para gerenciar nosso cluster. Workes é o nome dado para cada host do cluster (nós ou nodes). São as máquinas que realizam as tarefas solicitadas.

E quais são os componentes que rodam nos Minions?

• Kubelet: agente que é executado em cada nó worker, se conecta ao Docker e cuida da criação, execução e exclusão de contêineres;
• Docker: não preciso nem falar muito, né? É responsável por rodar e executar os containers, só que quem vai solicitar é o Kubernetes;
• Kube-Proxy: encaminha o tráfego para os contêineres apropriados com base no endereço IP e no número da porta da solicitação recebida.

Além desses, ainda temos alguns conceitos que são interessantes ter em mente no Kubernetes:

Pod, que pode ser definido como um grupo de contêineres que são implantados em um único nó de trabalho, é a menor unidade dentro de um cluster Kubernetes, e nada mais é do que containers rodando dentro de seu cluster de Kubernetes. Pode ser um container rodando nginx, php, apache, etc. Pod é a abstração de containers. Pode ter um ou mais containers em um Pod e posso ter vários Pods dentro de cada nó.

Replication Controller é o responsável por manter um número determinado de pods em execução. É no RC que você diz quantos containers você deseja que fiquem rodando para atender determinado serviço, e caso um caia no RC, outra instância é criada automaticamente. Por exemplo: em três réplicas do Nginx, o RC fica responsável por garantir o estado desse serviço, e caso um caia, o RC sobe outro automaticamente.

Services é o responsável por atrelar uma faixa de IP para um determinado RC. Cada vez que o RC cria uma nova instância de pod, ele inicia com um IP determinado pelo service. Services vai ser o ponto de entrada dos nossos serviços.

Com o Namespace, você pode dividir seu Cluster de Kubernetes em dois ambientes, como Produção e Teste, por exemplo, podendo limitar os recursos computacionais para ambos.

Quando usar Kubernetes?

O Kubernetes pode ser executado em várias plataformas: no seu laptop, VMs em um provedor de nuvem e em vários servidores bare metal, além de podermos instalar em vários sistemas Linux (Centos, Ubuntu, Debian ou Redhat).

A principal vantagem de usá-lo, é que os clusters podem abranger hosts em clouds públicas, privadas ou híbridas e funciona muito bem para ambientes que rodam vários containers com vários nós em larga escala. Ele ainda suporta mais de um runtime de container, alta disponibilidade, escalável, entre outros fatores.

Por outro lado, a documentação não é amigável para marinheiros de primeira viagem e a curva de aprendizagem é mais longa se comparada ao seu concorrente direto, o Docker Swarm.

Entretanto, vale lembrar que o fato do Kubernetes ser mais difícil não o desabona de nada! A plataforma é excelente para esse tipo de trabalho e é mais madura que o Swarm, que é relativamente novo se comparado ao Kubernetes. A comunidade é muito boa e vem crescendo a cada dia, e além disso, o site do kubernetes.io vem tentando deixar a documentação mais fácil, separando os tópicos e sugerindo tutoriais.

Esses são só alguns dos motivos que fazem o Kubernetes ser mais usado em produção e ser o queridinho da maioria. Mas se você ainda não está convencido, pode saber mais sobre um case recente interessante, o Pokémon Go.

No final de 2017, a própria Docker lançou a compatibilidade entre o Docker e o Kubernetes, e com essa versão do Docker, podemos ter no mesmo cluster o Swarm e o Kubernetes. É só escolher qual orquestrador queremos no momento da implantação dos serviços.

Mas isso é assunto para outro artigo.

O Minikube

Como já falamos, o setup do Kubernetes é mais complexo se comparado ao seu concorrente Docker Swarm. Para realizar um lab ou até mesmo colocar um ambiente em produção, dá um pouco de trabalho, demanda mais conhecimento de rede e ambientes distribuídos de quem vai executar e implantar o cluster.

Antigamente, quando íamos realizar um lab do Kubernetes, o mínimo exigido era cinco máquinas para simular um clusters com três Masters e dois Workes/Nós.

Pensando nisso, a galera da comunidade criou o Minikube, assim como a Docker fez com o Docker Toolbox para facilitar os labs/estudos, e deixou um pouco mais tranquila a vida de quem está começando com o Kubernetes. A ferramenta sobe rápido um ambiente, no qual é possível conhecer e ver o Kubernetes funcionando, usando o VirtualBox para criar a Vm do Minikube. O setup é muito tranquilo e podemos rodar em qualquer plataforma Windows/Linux ou Mac.

Isso ajudou muito, pois o Minikube simula um cluster real de um único nó com tudo o que é necessário já instalado e funcionando. Ele também já sobe alguns serviços que são usados pelo sistema, o de rede para os pods se comunicarem pelo cluster e um pod que é o Dashboard do Kubernetes.

Este último serve para facilitar e ter uma visão geral do cluster usando interface gráfica, basta passar a URL do cluster no browser, que no nosso caso é o Minikube rodando na nossa máquina.

• Aqui está o link do Github do Minikube.

Depois dessa longa introdução, é hora de colocar a mão na massa, certo? Calma! Em breve eu voltarei com essa parte do artigo. Mas se você tiver alguma dúvida ou alguma contribuição até aqui, não deixe de comentar logo abaixo. Até logo!

***

Este artigo foi publicado originalmente em: https://www.concrete.com.br/2018/02/22/tudo-o-que-voce-precisa-saber-sobre-kubernetes/