Com o tempo, a sua aplicação ficou bastante famosa e começou a receber muitos acessos e consequentemente, ela ficou muito lenta. Como resolver isso? Certa a resposta para quem pensou em provisionar mais recursos de infra para a aplicação. É necessário "Escalar" o Sistema. Você pode fazer isso de duas formas: Escalar verticalmente, aumentando o poder de processamento do servidor no qual a sua aplicação foi hospedada, aumentando recursos de CPU e memória, ou ainda, escalar horizontalmente, criando/adicionando nós ao cluster de servidores que atende as requisições para este Sistema.
Tomar essa decisão não é a coisa mais simples do mundo e depende de uma série de variáveis. O Sistema é monolítico ou baseado em Microserviços? Se você respondeu que ele foi construído baseado em uma arquitetura de microserviços, você ainda consegue escalar esse sistema de forma mais eficiente.
Agora vamos supor que você provisionou esses microserviços em containers. Para escalar, bastaria criar novos containers dos microserviços impactados pelo número de requisições feitos a ele.
Para quem é craque em docker sabe que isso é uma dor de cabeça. Como monitorar esses containers? Você pode gerenciar isso manualmente, fazendo sua aplicação escalar up/down de acordo com as necessidades. Controlar dois ou três serviços é fácil. Agora imagina monitorar dezenas ou centenas deles?
Pensando nisso, a Docker e diversas outras Empresas, correram atrás de criar soluções para orquestrar containers. A solução criada pela Google ganhou grande popularidade e até pouco tempo atrás era líder de mercado. Estamos falando aqui do Kubernetes.
O kubernetes, conhecido também como K8s, foi criado pela Google, baseado na experiência deles no gerenciamento de containers em produção. A evolução do kubernetes e ampla adoção se deu após este projeto se tornar open-source, ou seja, de código aberto, na qual qualquer pessoa ou empresa não somente passou a poder utilizá-lo gratuitamente, mas também novas funcionalidades e melhorias foram implementadas de forma mais rápida.
Fazendo uso do Kubernetes, a medida que sua aplicação vai recebendo mais acessos, novos “nodes” são criados, e se a aplicação tiver menos acessos estes “nodes” extras são destruídos, fazendo com que tenhamos mais flexibilidade.
Arquitetura do Kubernetes
Mas o que é um NODE? Um node é uma máquina, física ou virtual, onde o Kubernetes está instalado. No node criamos os containers(com docker) com as nossas aplicações.
Quando criamos uma aplicação em um container, o Kubernetes não faz uso/acesso direto ao container. Os Containeres ficam dentro de Pods.
A medida que o sistema vai recebendo mais acessos, o Kubernetes cria novos Pods com containers e faz o balancemento de cargas para dividir as requisições feitas ao sistema.
Se a quantidade de acessos à sua aplicação continuar a crescer e seu node não suportar novas instâncias da aplicação, ainda
podemos adicionar quantos novos nodes forem necessários ao cluster para dividir a carga.
Em alguns raros casos podemos ter a necessidade de uma
aplicação fazer uso de um container auxiliar, logo podem existir casos de um Pod conter mais de um container (Python e um container com o Redis por exemplo).
No Kubernetes os nodes costumam ser agrupados em CLUTERS. Caso um node venha a falhar, outro node assume o controle, evitando-se assim a indisponibilidade do sistema.
A partir do momento que temos um cluster, algum node tem que ficar responsável por gerenciá-lo. Gerenciar o cluster significa manter informações dos membros do cluster, monitorar os nodes, ativar um novo node ou não, quando um node falha. O node que faz esse papel é chamado MASTER. Os demais nodes são conhecidos com WORKERS.
Componentes do Kubernets
Quando instalamos o Kubernets, 6 componentes são instalados com ele. Aqui vai uma pequena descrição desses componentes:
API SERVER - A API Server funciona como um frontend para o Kubernetes. Ou seja, é através dele que gerenciamos usuários, dispositivos e interface de linha de comando.
ETCD - O etcd é usado para armazenar dados, de forma distribuída, no formato chave/valor para configuração e gerenciamento dos clusters. Podemos ter múltiplos clusters, cada cluster com seu master, e o etcd guardando dados de forma distribuída nos nodes. Além disso os logs dos clusters são gravados aqui.
SCHEDULE (agendador) é responsável por distribuir o trabalho para os containers através dos múltiplos nodes. Ele também “busca” por novos containers criados e anexa eles aos nodes.
CONTROLLER é o cérebro por traz da orquestração. Ele é responsável por tomar as decisões quando um node falha ou apresenta problemas e pode ativar novos nodes para substituir os
problemáticos.
CONTAINER RUNTIME faz interface com o software usado para criação dos containers, no nosso caso o docker engine, mas pode ser utilizado com outros softwares com o mesmo propósito.
KUBERLET é o agente que é executado em cada node em um cluster. O agente é responsável por checar se os containers estão sendo executado no node conforme o esperado.
O que difere um master node de um worker node é a quantidade de componentes que esses nodes possuem. Enquanto o node Master tem mais componentes, os work nodes possui menos componentes(Kuberlet e Container Runtime).
Por fim, ao instalar e configurar o Kubernetes, temos a disposição um programa
de linha de comando chamado kubectl (Kube Control Tool), utilizado, em muitos momentos, para executar
comandos do kubernetes. Uma das utilizações desta ferramenta é para realizar deploy (publicação) de aplicações em um cluster do kubernetes.
Resumindo, quer trabalhar com containers em ambiente de desenvolvimento ou homologação? Usa Docker. Vai trabalhar com containers em ambiente de produção? Kubernetes é o cara!
O Post ficou grande. Faremos outro para tratar ver na prática como o Kubernets pode nos facilitar a vida.
Até mais!
