O Kubernetes surgiu como plataforma de orquestração de containers, sendo ferramenta essencial para equipes de Engenharia de Dados. Sua importância é cada vez maior na infraestrutura de Big Data e no deploy de modelos de Machine Learning e em um próximo post vamos discutir isso em mais detalhes. Mas antes vamos compreender o que é o Kubernetes.

O Que é o Kubernetes?

Kubernetes é um sistema de código aberto que foi desenvolvido pelo Google para gerenciamento de aplicativos em containers através de múltiplos hosts de um cluster. Tem como principal objetivo facilitar a implantação de aplicativos baseados em microsserviços. Ele foi baseado na experiência do Google de muitos anos trabalhando com containers, adaptando-os para se trabalhar com Docker. Programado em Go, trata-se de um sistema cujo mais essencial objetivo é o de facilitar a implantação de aplicativos a partir da perspectiva dos microsserviços. O Kubernetes vai além de um mero instrumento de orquestração de containers: ele pode simplesmente reduzir a necessidade de monitoramento por meio de automatizações. Essa virtude explica por que Kubernetes e containers fazem tanto sucesso dentro da comunidade DevOps!

O Kubernetes tem um enorme apoio e impulso da comunidade open-source e 2018 deve marcar o ano de consolidação do Kubernetes como solução para processamento de Big Data. As organizações já estão usando o Kubernetes para uma variedade de tarefas e o processamento de Big Data será o próximo. O Kubernetes tem sido particularmente bem-sucedido com microsserviços e aplicativos modernos e descentralizados. Na verdade, se seguirmos as tendências atuais, os microsserviços containerizados em execução no Kubernetes, são o futuro.

Com o uso cada vez maior de containers, os problemas de orquestração tornaram-se mais relevantes. Nos últimos anos, vários projetos e empresas tentaram enfrentar o desafio – mas o Kubernetes surgiu como uma plataforma forte e dominante para operar containers. Atualmente, a maioria das empresas está executando (ou está planejando migrar para) o Kubernetes como uma plataforma para executar várias cargas de trabalho – sejam microsserviços sem estado, agendamentos, cargas de trabalho de estado, como bancos de dados, e deploy de modelos de Machine Learning.

Porquê o Kubernetes?

Por que o Kubernetes? Porque ele oferece algumas vantagens como plataforma, por exemplo:

• Uma maneira consistente de empacotar um aplicativo (container) permite consistência em todo o pipeline – do seu laptop ao cluster de produção.
• O Kubernetes é uma excelente plataforma para executar cargas de trabalho em vários nós de hardware commodity, enquanto abstrai a complexidade e o gerenciamento de nós.
• Você pode dimensionar com base na demanda – tanto o aplicativo, como o próprio cluster.
• O Kubernetes já é uma plataforma bem aceita para executar microsserviços e há esforços em andamento, por exemplo, para executar cargas de trabalho serverless no Kubernetes. Seria ótimo ter uma única plataforma que pudesse abstrair os recursos e tornar mais fácil para o operador gerenciar uma plataforma única.

O Kubernetes está rapidamente se tornando o novo padrão para implantar e gerenciar software na nuvem. Com todo o poder que o Kubernetes oferece, no entanto, há uma curva de aprendizado. Como recém-chegado, tentar analisar a documentação oficial pode ser esmagador. Há muitas partes diferentes que compõem o sistema e pode ser difícil dizer quais delas são relevantes para seu caso de uso. Este artigo fornecerá uma visão simplificada do Kubernetes, mas tentará fornecer uma visão geral de alto nível dos componentes mais importantes e como eles se encaixam. Primeiro, vamos ver como o hardware é representado.

Hardware

Nodes

Um nó é a menor unidade de hardware de computação no Kubernetes. É uma representação de uma única máquina no seu cluster. Na maioria dos sistemas de produção, um nó provavelmente será uma máquina física em um datacenter ou uma máquina virtual hospedada em um provedor de nuvem, como o Google Cloud Platform. Não deixe as convenções limitá-lo, no entanto; em teoria, você pode fazer um nó de quase qualquer coisa.

Pensar em uma máquina como um “nó” nos permite inserir uma camada de abstração. Agora, em vez de nos preocuparmos com as características únicas de qualquer máquina individual, podemos simplesmente ver cada máquina como um conjunto de recursos de CPU e RAM que podem ser utilizados. Desta forma, qualquer máquina pode substituir qualquer outra máquina em um cluster Kubernetes.

Cluster

Embora o trabalho com nós individuais possa ser útil, não é o modo de funcionamento do Kubernetes. Em geral, você deve pensar no cluster como um todo, em vez de se preocupar com o estado de nós individuais.

No Kubernetes, os nós agrupam seus recursos para formar uma máquina mais poderosa. Quando você implanta programas no cluster, ele manipula de forma inteligente o trabalho de distribuição para os nós individuais para você. Se algum nó for adicionado ou removido, o cluster se deslocará ao trabalho conforme necessário. Não deve importar para o programa ou o programador quais máquinas individuais estão realmente executando o código.

Se esse tipo de sistema parecido com o hivemind lembra você o Borg de Star Trek, você não está sozinho; “Borg” é o nome do projeto interno do Google no qual o Kubernetes foi baseado.

Volumes Persistentes

Como os programas em execução no seu cluster não têm garantia de serem executados em um nó específico, os dados não podem ser salvos em nenhum lugar arbitrário no sistema de arquivos. Se um programa tentar salvar dados em um arquivo para mais tarde, mas for realocado em um novo nó, o arquivo não estará mais onde o programa espera que ele esteja. Por esse motivo, o armazenamento local tradicional associado a cada nó é tratado como um cache temporário para manter os programas, mas os dados salvos localmente não podem persistir.

Para armazenar dados permanentemente, o Kubernetes usa Volumes Persistentes. Embora os recursos de CPU e RAM de todos os nós sejam efetivamente agrupados e gerenciados pelo cluster, o armazenamento de arquivos persistentes não é. Em vez disso, unidades locais ou na nuvem podem ser anexadas ao cluster como um volume persistente. Isso pode ser considerado como conectar um disco rígido externo ao cluster. Os Volumes Persistentes fornecem um sistema de arquivos que pode ser montado no cluster, sem estar associado a nenhum nó específico.

Software

Containers

Os programas em execução no Kubernetes são empacotados como containers do Linux. Os containers são um padrão amplamente aceito, portanto, já existem muitas imagens pré-criadas que podem ser implantadas no Kubernetes.

Containerization permite que você crie ambientes de execução Linux independentes. Qualquer programa e todas as suas dependências podem ser agrupados em um único arquivo e, em seguida, compartilhados na Internet. Qualquer pessoa pode baixar o container e implantá-lo em sua infraestrutura com pouca configuração necessária. A criação de um container pode ser feita de forma programática, permitindo que poderosos pipelines de Data Science sejam formados.

Vários programas podem ser adicionados em um único container, mas você deve se limitar a um processo por container, se possível. É melhor ter muitos pequenos containers do que um grande. Se cada container tiver um foco preciso, as atualizações serão mais fáceis de implantar e os problemas serão mais fáceis de diagnosticar.

Pods

Ao contrário de outros sistemas que você pode ter usado no passado, o Kubernetes não executa containers diretamente; em vez disso, ele envolve um ou mais containers em uma estrutura de nível mais alto chamada pod. Qualquer container no mesmo pod compartilhará os mesmos recursos e rede local. Os containers podem se comunicar facilmente com outros containers no mesmo agrupamento, como se estivessem na mesma máquina, mantendo um grau de isolamento de outros.

Os pods são usados ​​como a unidade de replicação no Kubernetes. Se seu aplicativo se tornar muito popular e uma única instância de um pod não puder carregar, o Kubernetes poderá ser configurado para implantar novas réplicas de seu pod no cluster, conforme necessário. Mesmo quando não está sob carga pesada, é padrão ter várias cópias de um pod em execução a qualquer momento em um sistema de produção para permitir o balanceamento de carga e a resistência a falhas.

Os pods podem conter vários containers, mas você deve se limitar quando possível. Como os pods são dimensionados para cima e para baixo como uma unidade, todos os containers de um pod devem ser dimensionados juntos, independentemente de suas necessidades individuais. Isso leva a recursos desperdiçados e uma conta cara. Para resolver isso, os pods devem permanecer o menor possível, geralmente contendo apenas um processo principal e seus containers auxiliares fortemente acoplados (esses containers auxiliares são geralmente chamados de “carros laterais”).

Deployment

Embora os pods sejam a unidade básica de computação no Kubernetes, eles normalmente não são lançados diretamente em um cluster. Em vez disso, os pods geralmente são gerenciados por mais uma camada de abstração: o deployment.

O objetivo principal de um deployment é declarar quantas réplicas de um pod devem estar em execução por vez. Quando uma implantação é adicionada ao cluster, ela automaticamente aumenta o número solicitado de pods e os monitora. Se um pod morre, o deployment irá recriá-lo automaticamente.

Usando um deployment, você não precisa lidar com os pods manualmente. Você pode apenas declarar o estado desejado do sistema e ele será gerenciado automaticamente para você.

Ingress

Usando os conceitos descritos acima, você pode criar um cluster de nós e iniciar implantações de pods no cluster. Há um último problema a ser resolvido: permitir o tráfego externo para seu aplicativo.

Por padrão, o Kubernetes fornece isolamento entre os pods e o mundo externo. Se você deseja se comunicar com um serviço em execução em um pod, é necessário abrir um canal para comunicação. Isso é chamado de ingress.

Existem várias maneiras de adicionar ingresso ao seu cluster. As formas mais comuns são adicionando um controlador de ingresso ou um LoadBalancer. As compensações exatas entre essas duas opções estão fora do escopo deste post, mas você deve estar ciente de que o ingresso é algo com o qual você precisa lidar antes de experimentar o Kubernetes.

E qual o próximo passo?

O que está descrito acima é uma versão super simplificada do Kubernetes, mas deve fornecer os fundamentos necessários para começar a experimentar. Agora que você entende as peças que compõem o sistema, é hora de usá-las para implantar um aplicativo real. Os tutoriais oficiais do Kubernetes são um ótimo lugar para começar.

Para experimentar o Kubernetes localmente, o Minikube criará um cluster virtual em seu hardware pessoal. Se você está pronto para experimentar um serviço na nuvem, o Google Kubernetes Engine tem uma coleção de tutoriais bem completos.

Se você é novo no mundo dos containers e da infraestrutura da Web, sugiro ler a metodologia do 12 Factor App. Isso descreve algumas das práticas recomendadas a serem lembradas ao projetar software para execução em um ambiente como o Kubernetes.

No próximo post veremos como o Kubernetes vem sendo usado como parte integrante de uma infraestrutura de Big Data e no deploy de modelos de Machine Learning.

David Matos

Referências:

Kubernetes – Site Oficial

O Que é o Kubernetes?

Kubernetes – Parte I

Sete razões para mudar para microsserviços

Setup Kubernetes on a Raspberry Pi Cluster easily the official way!

Introducing the Resource Management Working Group

Kubernetes 101: Pods, Nodes, Containers, and Clusters

Deploy de Modelos de Machine Learning

* Imagens extraídas do excelente post de Daniel Sanche, Engenheiro de Kubernetes no Google, com a devida autorização.