Olá pessoal,

Nesse post quero trazer uma visão geral do Kubernetes, sua história, e como sua arquitetura é composta. Mas o que é o Kubernetes?

Ele é uma plataforma opensource portável, extensível focado em gerenciar serviços containerizados, desenvolvida pela Google em 2014 e lançada publicamente em 2015. Essa plataforma atua de forma que ele ajuda a preparar e gerenciar clusters, e também nos contâiners Docker e portanto atua na sua orquestração e isso é possível através da automação por meio de configurações declarativas via arquivos YAML. Com isso ela oferece uma alta disponibilidade, escalabilidade e resiliência em ambientes de produção.

Como ela surgiu?

O surgiu a partir de uma tecnologia de orquestração de contêineres interna chamada Borg. A Google começou a trabalhar nessa ferramenta em 2003 para gerenciar seus próprios serviços internos em contêineres. Ele foi projetado para lidar com a escalabilidade e a alta disponibilidade de serviços, além de oferecer um ambiente de desenvolvimento mais fácil e ágil.

Em 2014, a Google decidiu disponibilizar o que conhecemos como Kubernetes hoje, mas como um projeto de código aberto, o que permitiu que outras empresas e desenvolvedores utilizassem a tecnologia. O projeto rapidamente se tornou popular, atraindo uma comunidade de desenvolvedores e contribuidores em todo o mundo. Em 2015, a Kubernetes foi doada para a Cloud Native Computing Foundation (CNCF), uma organização de código aberto que ajuda a gerenciar e promover tecnologias nativas de nuvem.

Desde então, ela tornou-se uma das tecnologias mais populares no espaço de contêineres, sendo amplamente adotada por empresas de todos os tamanhos em todo o mundo.

Como era antes?

Antes do Kubernetes, os deploys eram geralmente feitos de forma manual, o que exigia muito esforço. Os desenvolvedores precisavam configurar manualmente cada servidor e instalar todas as dependências e bibliotecas necessárias. Isso exigia muitos scripts de automação personalizados e era um processo propenso a erros humanos.

Olhando em uma perspectiva maior, a imagem mostra como tem sido a evolução da infraestrutura em que as nossas aplicações eram implantados:

• Deploy tradicional: Nesse momento era feito o deploy em máquinas físicas, e com isso um ou mais aplicações utilizam o mesmo recurso. O problema disso é que uma determinada aplicação poderia utilizar recursos o suficiente para deixar quaisquer outras subutilizadas a nível de performance. Então para resolver isso era separando sua implantação em máquinas físicas diferentes, tornando seu gerenciamento e manutenção custosos e caros.

• Deploy virtualizado: Como solução, a virtualização foi introduzido, em que temos um ou mais servidores que atuam como hypervisor e assim eles hospedam ou mais máquinas virtuais. Dessa forma as aplicações estão isoladas a nível desta virtualização, cada um com seus recursos delimitados desde o início. Outra vantagem é que a escalabilidade vertical aqui nesse ambiente é instântanea porque não é acoplada com o físico totalmente, mas claro ainda é limitado.

• Deploy via contâiner: Contâiners são similares aos VMs, mas eles possuem um isolamento menos estrito, de forma que compartilham do mesmo Sistema Operacional. Dessa forma, além de serem leves por isso como VMs eles possuem o seu próprio filesystem, compartilhamento de CPU, memória, process space, e muito mais. Como eles são mais desacoplados da infraestrutura, eles são muito mais portáveis entre clouds e outros sistemas operacionais.

O gerenciamento de aplicativos também era um desafio. À medida que o número de servidores aumentava, era difícil garantir que cada servidor estivesse executando as mesmas versões de software e bibliotecas. Também era difícil escalar aplicativos para atender às necessidades de tráfego crescente. Para lidar com esses problemas, surgiram ferramentas como Ansible, Chef e Puppet, que automatizavam a configuração do servidor e gerenciavam as dependências do aplicativo.

No entanto, essas ferramentas não eram específicas para contêineres, o que significava que os desenvolvedores ainda precisavam gerenciar manualmente as implantações e escalas dos contêineres. Isso levou ao desenvolvimento de ferramentas de orquestração de contêineres, como o Rancher, Docker Swarm e o Apache Mesos. No entanto, essas ferramentas tinham suas próprias limitações. Por exemplo, o Docker Swarm não tinha recursos avançados de escalabilidade e gerenciamento de aplicativos, enquanto o Apache Mesos era mais complexo de configurar e gerenciar.

Foi nesse contexto que o Kubernetes foi desenvolvido, para preencher essa lacuna e oferecer uma plataforma de orquestração de contêineres de ponta a ponta.

Como é sua arquitetura?

Ele tem uma arquitetura altamente modular e escalável, que consiste em vários componentes que trabalham juntos para fornecer recursos de orquestração de contêineres. Esses componentes incluem o seguinte:

Cluster

O cluster é a estrutura básica do Kubernetes, que consiste em um ou mais nós (ou servidores) em um grupo. Cada nó executa um agente de Kubernetes (kubelet) para gerenciar os contêineres e outros recursos. O cluster é gerenciado pelo componente de controle do Kubernetes.

Componente de controle

O componente de controle do Kubernetes é responsável por gerenciar o estado do cluster. Ele é composto por vários componentes, incluindo:

• kube-apiserver: é um componente que expõem um API Kubernetes e que serve de frontend para o control pane, ou seja, é aqui que vai receber os comandos do “mundo externo” através do programa kubectl de maneira declarativa ou imperativa

• etcd: atua como storage de chave e valor para o Kubernetes, armazenando dados relativos aos clusters

• kube-scheduler: componente que observa por novas criações de pods que não possuem atribuição e nenhum node e seleciona um mais adequado para ser hospedado e executado

• kube-controller-manager: é um componente que execute processos controladores, o que basicamente são processos que rodam em loop para regular o estado do sistema. No control pane temos alguns tipos como Node Controller, Job Controller, entre outros.

• cloud-controller-manager: esse componente incorpora a lógica de controle do seu cluster com as APIs dos provedores da nuvem, separando as partes do cluster as particularidades dos fornecedores. Aqui ele executa controladores específicos do fornecedor que implantou seu ambiente. Dessa forma, caso esteja utilizando um cluster em sua própria infraestrutura ou está utilizando para fins de estudo, você não utiliza esse componente.

Nós

Componentes dos nós executam em cada uma delas, mantendo a execução dos contêineres e provendo o ambiente de execução para o Kubernetes.

Cada um desses componentes abaixo rodam em cada nó do cluster, fazendo parte do conceito de Kubernetes Service.

• kubelet: ele tem o objetivo de manter o conjunto de pods; registrar o nó ao cluster, enviando eventos e status relacionados além de reportar utilização de recursos. Também ele recebe um conjunto de PodSpecs por meio do API Kubernetes para garantir que os pods estarão executando conforme esperado e com estabilidade.

• kube-proxy: ele gerencia e mantêm as regras de rede do nó do cluster. É com essas regras que que autoriza a comunicação dos pods dentro ou fora do seu cluster.

Pods

Os pods são a unidade básica de implantação no Kubernetes, que consiste em um ou mais contêineres que compartilham o mesmo espaço de rede e armazenamento. Os pods são agendados em nós pelos componentes de controle e são gerenciados pelo kubelet em cada nó.

Serviços

Os serviços fornecem uma maneira de expor um conjunto de pods como um serviço de rede. Eles são responsáveis por encaminhar o tráfego para os pods correspondentes, permitindo que os aplicativos sejam escalonados e mantidos sem interrupções.

Volumes

Os volumes fornecem uma maneira de armazenar dados persistentes em contêineres. Os volumes podem ser compartilhados entre vários contêineres em um pod e podem ser gerenciados pelo Kubernetes para garantir que os dados persistam durante as atualizações e falhas.

Uma ferramenta cada vez mais essencial nas soluções

O Kubernetes é uma ferramenta poderosa e flexível gerenciarmos e mantermos nossas aplicações rodando. Com sua arquitetura altamente modular e escalável, ele permite que os desenvolvedores gerenciem e orquestrem facilmente suas aplicações em contêineres, independentemente da infraestrutura subjacente. Hoje faz parte da rotina de todo desenvolvedor trabalhar com essa infraestrutura, de forma direta ou não, seja onpremise ou no cloud. Caso não conheça, acesse a documentação para saber mais.

Até mais!