Hoje vamos falar de algo que quase todo mundo já ouviu falar, mas ninguém sabe explicar a Kubernetes. É confuso porque ele resolve um problema que a maioria das pessoas não vê até se deparar com ele. Todo mundo sabe que é importante, mas pergunte o que ele faz e você receberá um olhar confuso. Ele não é um substituto para o Docker nem um sistema operacional de nuvem, embora as pessoas costumem supor isso. A confusão faz sentido, pois o Kubernetes resolve um problema que você nem sabe que existe até enfrentá-lo. É uma ferramenta que se torna essencial quando você tem mais do que alguns poucos containers para gerenciar. Ao final deste episódio, você entenderá o que o Kubernetes realmente é, como ele se encaixa com containers, e por que o Azure Kubernetes Service o torna prático para equipes que não querem construir tudo do zero. Pegue seu café e vamos começar. O problema antes dos containers.

Vamos voltar ao problema. Imagina uma empresa de software há 10 anos. Tem alguns aplicativos para rodar, então compra servidores, instala sistemas operacionais e faz o deploy de tudo manualmente. Cada aplicativo ganha sua própria máquina e você não pode compartilhar recursos entre eles. Se um app precisa de muita memória e outro mal-usa, ambos ganham seu próprio servidor do mesmo jeito. O desperdício era não. Servidores operavam com talvez 20% da capacidade, mas não podiam ser consolidados, porque os aplicativos brigavam por dependências. Você acabava com uma sala cheia de servidores, cada um mal trabalhando, consumindo energia e refrigeração e todos precisando de manutenção constante. Um app precisa do Python 3.8, o outro precisa do Python 3.8. Não precisa de uma biblioteca antiga, o outro precisa da mais recém. Você não pode rodá-los na mesma máquina sem quebrar algo, então compra mais servidores e paga por hardware que fica quase ocioso.

Máquinas virtuais ajudaram um pouco ao permitir dividir um servidor físico em partes menores, cada uma rodando seu próprio SEO, mas cada VM é pesada com um SEO completo que ocupa espaço em disco e memória, levando minutos para iniciar. E você precisava configurar cada uma separadamente, o que dava muito trabalho. Você ainda continuava gerenciando todos aqueles sistemas operacionais, corrigindo, atualizando e protegendo-os. As equipes precisavam de algo mais leve e portátil, uma maneira de empacotar um aplicativo com tudo o que ele precisa para rodar, sem a sobrecarga de uma máquina virtual completa que pudesse ser movido facilmente entre máquinas. Foi aí que os containers entram. O que os containers realmente são? Um container é um pequeno pacote que inclui seu aplicativo e tudo o que ele precisa para funcionar. Isso significa que o código runtime, as bibliotecas e os arquivos de configuração são agrupados em uma única unidade.

Pense nisso como um container de carga para software. Um container de carga pode ir em um caminhão, um trem ou um navio. O container em si permanece o mesmo. Seu container de software funciona da mesma forma. Você o cria uma vez e ele roda do mesmo jeito no seu laptop, no seu servidor de teste e no seu ambiente de produção. A principal diferença entre containers e máquinas virtuais é o quão eficientes eles são. Uma máquina virtual executa seu próprio sistema operacional completo, então cada VM tem seu próprio kernel, arquivos de sistema e tudo o resto. Um container compartilha o sistema operacional do rosto. É apenas um processo com sua própria visão isolada do mundo. Isso significa que os containers iniciam em segundos, não minutos. Eles usam menos memória e você pode colocar mais deles em uma única máquina. O Docker tornou os containers populares ao dar aos desenvolvedores uma maneira simples de criá-los e executá-los com um único comum.

De repente, o problema de na minha máquina funciona começou a desaparecer. Se a aplicação roda em um container no seu laptop, ela rodará da mesma forma no servidor. O ambiente é consistente em todos os lugares. Mas os containers resolvem um problema e criam outro. Com um punhado de containers, o gerenciamento manual funciona bem. Você pode iniciá-los, pará-los e acompanhá-los por conta própria. Mas o que acontece quando você está incendendo as delas? Você precisa decidir qual servidor executa qual container, reiniciar os que falharam, conectá-los entre si e escalá-los quando o tráfego aumenta. Esse é um novo desafio. E é exatamente aí que o Kubernetes entra. O problema de arquestração. Então, você conseguiu colocar os containers para funcionar. Você empacota a sua aplicação, ela roda consistentemente em toda a parte da Vdebo. Apenas por um tempo. Com 10 ou 20 containers, você consegue gerenciar as coisas no momento.

Você sabe qual servidor executa cada container, pode reiniciar algo que se travar e pode atualizar algumas coisas aqui e ali. Gerenciar. Então, sua aplicação cresce. Você migra para micro serviços. Então, ao invés de uma grande aplicação, você tem 20 menores. Cada uma precisa de várias cópias rodando para garantir confiabilidade e agora você está lidando com 200 containers. O gerenciamento manual não funciona mais. Você precisa decidir qual servidor executa cada container, reiniciar containers quando falham e conectá-los para que possam se comunicar. Você também precisa escalar quando o tráfego aumenta. Talvez durante uma promoção ou lançamento de produto e reduzir quando as coisas se acalmam. E você precisa implementar atualizações sem tempo de inatividade, o que significa substituir containers antigos por novos, um de cada vez cuidadosamente, sem quebrar nada. Esses são problemas de orquestração e são exatamente o que o Kubernetes foi criado para resolver.

O Kubernetes é uma plataforma de código aberto que automatiza a implantação, o dimensionamento e o gerenciamento de aplicativos containerizados. Pense nele como sistema operacional do seu datacenter. Assim como o Windows ou o Linux gerenciam recursos em um único computador, como CPU, memória e disco, o Kubernetes gerencia os recursos de todos os seus servidores. Ele trata todas as suas máquinas como um grande pool de poder computacional. Você diz o que quer executar, ele decide onde colocar, como conectar a todo o resto.

Conceitos fundamentais, pods, nós e clusters. Vamos ver como o Kubernetes realmente funciona. A menor unidade no Kubernetes é chamada de pod. Um pod é a grupo 1 ou mais containers. Containers dentro do mesmo pod compartilham armazenamento e rede, então eles podem se comunicar via localhost. Você pode pensar em um pod como uma unidade única de implantação. Você não implanta containers diretamente no Kubernetes. Você implanta pods. Pods não rodam sozinhos, eles rodam em nós. Um nó é um servidor, físico ou virtual, que faz parte do seu cluster Kubernetes. Cada nó executa o software necessário para rodar pods, além de outras coisas que veremos em um momento. Um cluster é o conjunto de todos os nons gerenciados como um sistema unificado. Em termos simples, um pod é a sua aplicação, um nó é onde ela roda, e o cluster é todo o ambiente. Pods são efêmeros. Eles podem ser criados, destruídos ou movidos a qualquer maneira.

Isso é propósito. Se um não há falha, o Kubernetes move os pods para o outro. Para escalar, ele cria novos pods. E quando um pod trava, ele é substituído automaticamente. O sistema trata os pods como temporários. Mas se os pods vão e vêm, você precisa de uma maneira de falar com eles. Em vez de falar com um pod diretamente, você fala com um serviço. Um serviço fornece um endereço de rede estável que roteia o tráfego para os pods corretos, mesmo quando eles mudam. Imagine um hotel. Número de telefone do hotel é o serviço. Os quartos mudam de hóspedes o tempo todo, mas o número de telefone continua o mesmo. Você liga para a recepção e eles encaminham sua chamada para o quarto, certo? É exatamente isso que um serviço faz no Kubernetes. Ele oferece o endereço fixo que sempre aponta para os pods que estão executando sua aplicação. O plano de controle, o cérebro do cluster. Então, você tem pods, nós e um cluster.

A questão é quem decide o que roda onde. Essa é a função do plano de controle. Todo cluster Kubernetes tem um, e ele é o cérebro de toda a operação. Todas as decisões acontecem aqui. O plano de controle possui vários componentes. O primeiro é o servidor de API, que atua como uma porta de entrada para o seu cluster. Cada comando que você envia ao Kubernetes, seja da linha de comando, de um painel ou de um script automatizado, passa pelo servidor de API. Ele autentica a sua solicitação. Verifica se você tem permissão para o que está pedindo e, em seguida, encaminha para o lugar certo. Nada acontece no Kubernetes sem antes passar pelo servidor de API. Em seguida, temos o agendador que decide qual nó executa cada pod. Quando você diz, quero esta aplicação rodando, o agendador analisa todos os nóis disponíveis, verifica os recursos disponíveis, como CPU, memória e espaço em disco, e escolhe o melhor para o trabalho.

É como um gerente de hotel designando quartos com base na necessidade de cada hóspede. Um hóspede com muita bagagem recebe um quarto maior, enquanto uma aplicação leve recebe um nó menor com capacidade disponível. Há o gerenciador de controladores. Este componente monitora o cluster e garante que o estado real corresponda ao que você declarou. Você disse que quer três cópias da sua aplicação web rodando. O gerenciador de controladores verifica se existem, de fato, três cópias. Se uma falhar, ele percebe e inicia uma substituta. Se alguém excluir um pod acidentalmente, ele cria um novo. É o componente que mantém seu cluster consistente. E, finalmente, o etcd, que é o banco de dados do cluster. Ele armazena tudo, como o que está rodando, onde está rodando e como está configurado. É a fonte da verdade para todo o cluster. Se o servidor de API é a porta de entrada, o etcd é o arquivo na secretaria onde todos os registros são guardados.

A beleza deste design é que você descreve o que quer e o Kubernetes descobre como tornar isso realidade. Você não diz a ele como fazer as coisas, se diz como o resultado final deve ser. Esse é o modelo declarativo e a ideia é central por trás de tudo o que o Kubernetes faz. Cargas de trabalho, implantações, serviços, calonamento. Então, vamos falar sobre como você realmente executa aplicações no Kubernetes. Se não criar a pod, diria também. Em vez disso, você usará um objeto de nível superior chamado deployment. Pense em um deployment como um gerente que diz ao Kubernetes quantas cópias do seu pod devem rodar, qual imagem de container usar e como atualizá-las quando uma nova versão surgir. É a maneira padrão de executar aplicações sem estado. Quando você atualiza um deployment, digamos que você publica uma nova versão da sua aplicação, o Kubernetes realiza uma atualização gradual. Ele substitui os pods 1 a 1, garantindo que pelo menos uma cópia esteja sempre em execução.

Isso significa zero tempo de inatividade e nenhuma interrupção repentina para seus usuários. E se algo der errado com a nova versão, você pode retornar a versão anterior com um único comando. Essa é uma rede de segurança poderosa. Mas seus pods ainda precisam estar acessíveis. É aí que entra o serviço. Um serviço fornece um endereço de rede estável que encaminha o tráfego para os pods corretos. Ele também pode expor esses pods a outras partes da sua aplicação ou ao mundo exterior. Um serviço pode ser interno, acessível apenas dentro do cluster ou externo, com um IP público que os usuários alcançam pela internet. Agora vamos falar sobre escalabilidade. Kubernetes pode aumentar e diminuir automaticamente sua aplicação com base na demanda. Define um alvo, digamos 70% de uso de CPU, e o Kubernetes adiciona mais pods quando o uso supera esse limite e os remove quando ele cai. Sua aplicação escala para cima durante um pico de tráfego e reduz quando as coisas se acalmam.

Nenhuma intervenção manual é necessária, mas todo esse poder vem com complexidade. Executar seu próprio cluster Kubernetes significa ser responsável pelo plano de controle, atualizações, patches e segurança e backups. Você precisa de conhecimento profundo para lidar com falhas de nós, configuração de rede e escalonamento de cluster. Muitas equipes passam mais tempo gerenciando o cluster do que desenvolvendo aplicações. E é aí que entra o Kubernetes gerenciado. Kubernetes auto-gerenciado versus gerenciado. Então vamos falar sobre a realidade de executar o Kubernetes por conta própria. Ao configurar seu próprio cluster, você é responsável por tudo. Plano de controle, atualizações, patches de segurança e backups do ETCD. Se o servidor de API caiu, o problema é seu. Se uma vulnerabilidade de segurança for descoberta na versão que você usa, você precisa aplicar o patch. Se o ETCD for corrompido, você precisa restaurar a parte do backup.

Tudo isso exige um conhecimento profundo. Você precisa entender como os nós falham, como a rede funciona no nível do cluster e como escalar, sem quebrar as coisas. Aqui está algo que surpreende muitas equipes. Muitas organizações gastam mais tempo gerenciando seu cluster Kubernetes do que construindo as aplicações que rodam nele. Elas estão constantemente lutando com atualizações, resolvendo problemas de rede e lidando com falhas de nós. Cluster se torna um trabalho de tempo integral. Não foi para isso que você adotou Kubernetes inicialmente. É aqui que entram os serviços de Kubernetes gerenciados. Serviços como Azure Kubernetes Service ou AKS cuidam do plano de controle para você. O Azure gerencia o servidor de API, o ETCD, o agendador e o gerenciador de controladores. Você não precisa se preocupar em corrigi-los ou mantê-los em execução. Você paga apenas pelos nós de trabalho, as máquinas virtuais que realmente executam suas cargas de trabalho.

O plano de controle em si gratuito. Isso muda a equação drasticamente. Em vez de gastar seu tempo na manutenção do cluster, sua equipe pode focar no que realmente importa, as aplicações que vocês estão criando. Para a maioria das equipes, especialmente aquelas que estão começando o Kubernetes gerenciado, a escolha é certa. Você obtém todo o poder do Kubernetes sem a sobrecarga operacional. AKS, Kubernetes simplificado no Azure. Então, o que exatamente é o AKS? É o serviço de Kubernetes gerenciado do Azure oferecendo um cluster completo sem que você precise criá-lo do zero. O plano de controle é gratuito, como mencionamos, então você paga apenas pelas máquinas virtuais que executam suas cargas. Isso significa que você pode começar pequeno, pagar muito pouco e escalar conforme suas necessidades. O Azure cuida de todo o trabalho pesado. Atualizações, correções e monitoramento da integridade do plano de controle são todos resolvidos pelos.

Você não precisa de uma equipe dedicada de especialistas em Kubernetes apenas para manter as coisas funcionando. E como o AKS faz parte do ecossistema Azure, isso integra as ferramentas que você provavelmente já usa. Azure Active Directory para autenticação, Azure Monitor para logs e métricas e Azure Policy para governança. Todos funcionam juntos prontamente, sem a necessidade de adicionar peça separada. Configurar pipelines de CI e CD com GitHub e Actions ou Azure DevOps leva apenas alguns minutos. Envie uma alteração para o seu repositório. Ele constrói automaticamente uma nova imagem de container. Envia para o Azure Container Registry e atualiza sua implantação no AKS. Sem etapas manuais, sem necessidade de SSH em servidores. É tudo automatizado. Para iniciantes, existe um modo automático do AKS projetado para equipes que não querem tomar todas as decisões sobre a configuração do cluster.

Ele oferece padrões prontos para uso em escala, rede, segurança e atualizações. Então não precisa se tornar um especialista em Kubernetes para começar. Basta escrever sua aplicação e o AKS cuida do resto. Um comando cria seu cluster, um arquivo de manifesto coloca sua aplicação em execução. As habilidades que você aprende no AKS são transferíveis para qualquer ambiente de Kubernetes, porque ele é Kubernetes padrão internamente. Você não está aprendendo um sistema proprietário, você está aprendendo um sistema real com o Azure, cuidando da complexidade operacional. Então agora você tem uma visão geral. Containers empacotam suas aplicações para que rodem de forma consistente em qualquer lugar e o Kubernetes orquestra esses containers em escala, lidando com implantação, escala e recuperação automaticamente. O AKS torna essa orquestração gerenciável ao cuidar do plano de controle e se integrar às ferramentas do Azure que você já conhece.

O ponto principal é este. O Kubernetes não é apenas para grandes empresas de tecnologia com enormes equipes de engenharia. Com serviços gerenciados como o AKS, ele é acessível para qualquer equipe. Sua tarefa para esta semana é simples. Crie uma conta gratuita no Azure, suba um cluster AKS e implante uma aplicação simples. Leva alguns minutos e você verá o quanto a plataforma evolui. Pronto para se aprofundar. Próximo episódio aborda como criar sua primeira imagem de container e enviá-la ao Azure Container Registry. Inscreva-se na sua plataforma de podcast favorita e compartilhe isso com alguém que está começando sua jornada no Kubernetes.