Kubernetes: orquestrar e gerenciar containers em ambientes locais

Da lógica da orquestração à organização do cluster - Apresentação

Apresentando o curso e o instrutor

Olá! Eu sou Lucas Gonçalves, e dou as boas-vindas ao curso de Kubernetes em ambiente local.

Audiodescrição: Lucas é um homem de cabelo curto, com bigode e barba curtos. Veste uma camiseta preta e, atrás dele, há um cenário iluminado em tons de azul e roxo, com uma guitarra, alguns discos, jogos de tabuleiro e alguns RPGs.

Definindo os objetivos e o público-alvo

O objetivo deste curso é entendermos como o Kubernetes funciona, sua estrutura, como configurar e como executar aplicações no Kubernetes de forma resiliente, adotando boas práticas.

Com esses conhecimentos, entenderemos o necessário para trabalhar em ambientes Kubernetes, tanto on-premises (em instalações locais) quanto na nuvem.

Este curso não é voltado apenas para infraestrutura ou ops (operações), mas também para pessoas desenvolvedoras, pois o objetivo é entendermos o funcionamento e a configuração de Kubernetes até a implantação de uma aplicação.

Listando os pré-requisitos e concluindo a introdução

Como pré-requisitos, espera-se conhecimento de Docker, já que Kubernetes é um orquestrador de contêineres; de Git, para versionarmos os arquivos de configuração e de implantação; e de terminal, que será nosso principal meio de uso em um ambiente local.

Enfim, vamos encerrar por aqui. Eu te espero no próximo vídeo.

Da lógica da orquestração à organização do cluster - O que é um orquestrador

Contextualizando a execução de aplicações

Antes de começarmos a trabalhar com nosso orquestrador de contêineres, o Kubernetes, vamos entender o que é um orquestrador de contêineres. Para isso, é útil pensar em como executamos aplicações em ambientes mais comuns.

Normalmente, temos uma máquina anfitriã onde colocamos a aplicação em execução para que fique acessível. Podemos ter, por exemplo, uma máquina com tudo instalado para executar uma aplicação em Java 17 ou uma aplicação em Node.js. Instalamos ferramenta, linguagem, framework (estrutura), banco de dados e a tecnologia que for necessária.

Evidenciando conflitos e introduzindo containerização

No momento em que precisarmos executar outra aplicação, por exemplo, Java 22, surgirá um problema. Nossa máquina foi configurada para a aplicação em Java 17, e queremos executar uma aplicação em Java 22. As configurações são diferentes, as dependências são distintas, e isso se agrava quando há várias aplicações em execução. Em cenários com um servidor atendendo diferentes aplicações, tecnologias e versões, torna-se inviável gerir versões e dependências distintas.

Para resolver isso, utilizamos o conceito de contêineres. Em vez de manter instalações diretamente na máquina, passamos a ter contêineres para a aplicação 1, aplicação 2, aplicação 3 e assim por diante. Ao isolarmos as aplicações em contêineres, cada uma mantém suas próprias configurações e dependências, mas todas podem ser executadas na mesma máquina, no mesmo servidor. Elas não se comunicam entre si por padrão. Além de serem efêmeras, permanecem isoladas e só se comunicarão se configurarmos a comunicação entre contêineres. Com isso, deixamos de ter o problema de gerenciamento de configurações, versões e tecnologias. Esse é o conceito de containerização.

Justificando a necessidade de orquestração de contêineres

Quando começamos a trabalhar em maior escala, surgem outras necessidades. Suponhamos que tenhamos a aplicação 1 acessível externamente. Se começarmos a receber inúmeros acessos, a aplicação ficará sobrecarregada. Precisaremos replicá-la. Mas como gerir duas réplicas? Como administrar dois pontos diferentes, dois contêineres distintos? Surge, então, a necessidade não apenas do contêiner para isolar e evitar conflitos de configuração e versões, mas também de um orquestrador de contêineres.

Com um orquestrador, podemos ter escalabilidade vertical (de recursos) e escalabilidade horizontal (replicação do contêiner da aplicação), além de um ponto único de balanceamento, comunicação e acesso. Em vez de acessos individuais a cada instância, passamos a ter um acesso unificado, com um ponto único — o orquestrador, um load balancer (balanceador de carga) ou um proxy (intermediário). Esse componente decide como distribuir o tráfego entre as diferentes instâncias e contêineres.

Detalhando escalabilidade e balanceamento de carga

Dessa forma, obtemos escalabilidade horizontal: a cada requisição, o orquestrador direciona para a instância menos carregada; se uma instância estiver sobrecarregada, o tráfego é redirecionado para outra. Com essa configuração e forma de uso, podemos realizar escalonamento dinâmico. Por exemplo, se houver três cópias e o orquestrador observar alta carga, ele realizará o escalonamento, criando mais réplicas para aliviar o acesso e aumentar a disponibilidade.

Assim, escalabilidade vertical, escalabilidade horizontal, ponto único de acesso e comunicação, e balanceamento de carga são vantagens que conseguimos com um orquestrador de contêineres. A tecnologia de contêineres é utilizada em servidores e também na nuvem.

Apresentando resiliência, auto-reparação e atualizações

Para termos toda a configuração e a gestão de forma mais fácil e unificada, em uma configuração única, utilizamos um orquestrador de contêineres. Esses pontos nos permitem ter contingência e resiliência, além do conhecido self-healing (auto-reparação).

Com um orquestrador de contêineres e a comunicação ocorrendo normalmente, quando o orquestrador identifica que uma de nossas réplicas caiu, ele conclui: “precisamos daquela terceira réplica pela quantidade de acessos”. Como a réplica caiu, é necessário criar outra para manter a mesma qualidade de serviço e a mesma carga suportada. O orquestrador identifica a queda e cria automaticamente uma nova réplica para manter a contagem desejada.

Além do self-healing (auto-reparação), também temos a atualização de versão. Por algum motivo, queremos mudar nossa aplicação 1, representada “em preto”, para a aplicação 1 “em verde”. Quando fazemos essa alteração, o orquestrador passa a gerenciar o processo. Veremos isso na prática, mas, do ponto de vista diagramático, funciona assim: queremos alterar a versão; o orquestrador cria a nova versão e, gradualmente, redireciona o tráfego, substituindo as instâncias antigas. Ele encerra uma réplica, cria outra na nova versão e aponta para a nova versão; depois encerra outra, substitui pela nova e assim sucessivamente, até completar a migração. Quando verifica que tudo o que é necessário para a nova versão foi criado, remove as instâncias anteriores, mantendo, claro, o que for necessário para um rollback (reversão).

Abordando rollback e situando o orquestrador

Além da atualização de versão e do self-healing (auto-reparação), também temos a possibilidade de rollback (reversão). Atualizamos nossa aplicação para a nova versão, mas ocorreu algum erro ou problema; emitimos o comando e o orquestrador inicia automaticamente o retorno à versão anterior que não apresentava problemas. Tudo isso pode ser feito por meio de comandos e configurações para automatização.

Essa capacidade de gerenciar nossos contêineres e nosso ambiente de forma unificada, resiliente, escalável e segura — para atualização de versões e para rollback (reversão) — é possibilitada por um orquestrador de contêineres. O Kubernetes é nosso orquestrador de contêineres. Ele executa sobre um runtime (tempo de execução) de contêineres, como, por exemplo, Docker ou containerd. A tecnologia de contêineres precisa estar instalada por baixo (Docker, containerd, entre outras).

Comparando com outros orquestradores

Também existem outros orquestradores de contêineres, como o Docker Swarm. No entanto, no caso do Swarm, a própria empresa Docker recomenda que não seja utilizado em produção. O Docker Swarm é uma forma de orquestração de contêineres mais adequada para testes, experimentação e atividades semelhantes, jamais em produção. Acreditamos que, na realidade, atualmente quase não existam ambientes que utilizem Docker Swarm em produção, justamente porque essa é a recomendação de boas práticas da Docker: não utilizá-lo em produção.

Também existe o HashiCorp Nomad, assim como o OpenShift. O interessante do OpenShift é que, de certa forma, ele é uma distribuição do Kubernetes. Em outras palavras, o OpenShift é Kubernetes com alguns ajustes e personalizações adicionais para oferecer mais funcionalidades, mantido sob o guarda-chuva da Red Hat. Em geral, o funcionamento é muito similar entre esses orquestradores: todos eles executam sobre um runtime (tempo de execução) de contêineres, gerenciando contêineres. Como mencionado, o OpenShift é, de certa forma, uma personalização do Kubernetes.

Generalizando o uso em diferentes ambientes e provedores

Ao aprendermos Kubernetes, conseguimos trabalhar com diferentes ambientes, tanto on-premises (em ambiente local) quanto na nuvem, em diferentes tipos de clusters (agrupamentos), porque, por baixo, quase tudo é Kubernetes. O AKS da Azure é Kubernetes (Azure Kubernetes Service). O EKS da AWS é Kubernetes (Elastic Kubernetes Service). O GKE do Google é Kubernetes (Google Kubernetes Engine). São tecnologias e provedores distintos, executando Kubernetes.

Assim, se aprendermos a usar Kubernetes em k3d, kind, Minikube, em um ambiente com clusters (agrupamentos), on-premises (em ambiente local) ou na nuvem, o uso e o conceito por trás serão os mesmos. A ideia é avançarmos nos estudos para, em seguida, conseguirmos replicar o que fizermos em diferentes ambientes com clusters (agrupamentos).

Da lógica da orquestração à organização do cluster - Conhecendo o orquestrador

Apresentando o contexto histórico do Kubernetes

Vamos conhecer melhor o Kubernetes. No livro em inglês intitulado Site Reliability Engineering (Engenharia de Confiabilidade de Sites), do Google — neste caso, a edição com a capa exibida —, encontramos um panorama sobre a história do Kubernetes, com foco neste orquestrador em específico e também na tecnologia de maneira geral em relação à resiliência, à engenharia de resiliência.

Kubernetes é uma tecnologia criada pelo Google e, internamente, foi associada ao projeto chamado Borg. Para quem conhece Star Trek (Jornada nas Estrelas), há uma correlação: se temos uma coletividade de contêineres de diferentes tecnologias, uma forma de unificá-los em uma existência coletiva remete aos Borg. Com essa referência, pensamos em incontáveis contêineres que podemos gerenciar de forma unificada por uma “rainha”, o Kubernetes — o projeto Borg de então —, que consegue orquestrar toda essa coletividade de contêineres. Esse nome surgiu justamente para evidenciar que poderíamos ter inúmeras configurações, projetos e recursos centralizados a partir de um único ponto, com uma única forma de configuração.

Explicando a governança e a etimologia do Kubernetes

Depois de um tempo, o projeto foi doado à Linux Foundation (Fundação Linux) e, na sequência, o ecossistema evoluiu com a Cloud Native Computing Foundation (Fundação de Computação Nativa em Nuvem) (CNCF). Hoje, é um projeto de código aberto, o que possibilita o uso gratuito. Em grande parte por isso, temos diferentes empresas e tecnologias construídas sobre o Kubernetes. Como o código é aberto, é possível utilizá-lo e modificá-lo; por isso, também existe o OpenShift, que é uma modificação do Kubernetes. Trata-se, portanto, de um projeto totalmente aberto.

A palavra Kubernetes vem do grego e significa “timoneiro”, motivo pelo qual seu logotipo é um timão. Assim, o timoneiro conduz um navio que transporta inúmeros contêineres; essa é a metáfora central: o Kubernetes, o timoneiro, gerencia o transporte e a orquestração de todos esses contêineres. O timão do logotipo tem sete pontas porque o nome original do Kubernetes fazia referência ao projeto chamado Seven of Nine (Sete de Nove), outro personagem de Star Trek (Jornada nas Estrelas). Mesmo que o nome tenha mudado, a referência permaneceu no logotipo com as sete pontas, preservando a ideia de coletividade associada aos Borg e à gestão de um grande número de contêineres.

Destacando as principais capacidades do orquestrador

Após essa breve apresentação, entendemos o Kubernetes como nosso orquestrador de contêineres: a ferramenta que controlará a coletividade de contêineres e tecnologias de maneira centralizada. Entre seus pontos principais, destacamos:

• Escalabilidade: quando precisamos aumentar ou diminuir a capacidade, o Kubernetes permite escalar dinamicamente e também de forma manual. Se um serviço está pouco utilizado e consumindo recursos sem necessidade, ele reduz a alocação. Se está muito utilizado, precisa de mais recursos e réplicas para balancear acessos e carga, ele aumenta a capacidade.

• Resiliência: o objetivo é manter a aplicação em funcionamento, assim como os nós (as máquinas onde os contêineres rodam). O Kubernetes identifica a saúde dos componentes, detecta estados e pode controlá-los. Se algum componente cair, ele repõe criando novos. Quando há disponibilidade, é possível gerenciar o uso equilibrando a alocação para evitar desperdício e, ao mesmo tempo, utilizar os recursos de maneira controlada.

• Gestão de configuração e segredos: podemos gerenciar variáveis de ambiente, credenciais de acesso e outras configurações. Senhas e dados sensíveis não devem ficar em variáveis de ambiente comuns; para isso, usamos Secrets, que o Kubernetes também gerencia. Assim, tanto a configuração via variáveis de ambiente quanto os Secrets podem ser controlados de forma segura por meio do Kubernetes.

• Service Discovery (Descoberta de Serviço): mesmo com inúmeras réplicas, vários pontos e subdomínios, podemos unificá-los em um único ponto de acesso. O Kubernetes realiza o endereçamento correto: acessamos um único endereço, e ele se encarrega do balanceamento e do roteamento nos bastidores. Para a pessoa usuária final, o acesso acontece em um único lugar: a aplicação.

Descrevendo operação, auto-recuperação e observabilidade

Muitas vezes, inclusive dentro do Kubernetes, teremos uma aplicação que se comunica com um banco de dados. Esse banco de dados fica isolado, sem acesso externo direto. Ao acessar o ponto que o Kubernetes expõe externamente, ele gerencia qual réplica será utilizada, e essa réplica acessa o banco de dados. Dessa forma, toda a gestão ocorre de maneira segura e isolada por meio da orquestração do Kubernetes.

Esta parte de self-healing (auto-recuperação), como também comentamos, garante que, se um contêiner cair ou apresentar algum problema — configuração incorreta, erro de aplicação ou qualquer falha relacionada a recursos —, o orquestrador detecta a situação. Podemos configurá-lo para identificar uso excessivo de recursos, erros relativos a recursos, aplicação ou configuração; ele irá identificar, reverter ao estado anterior, redirecionar o tráfego, criar mais réplicas — essa é a auto-recuperação por meio da orquestração do Kubernetes.

Também podemos, com o orquestrador Kubernetes, realizar monitoramento de contêineres para identificar desperdício de recursos e problemas de capacidade. O metrics-server (servidor de métricas) ajuda muito; podemos ver as métricas do nosso cluster (agrupamento) como um todo. Com sidecars (contêineres auxiliares) junto às aplicações, executamos o monitoramento acoplado para obter observabilidade dos contêineres de forma mais controlada.

Quanto à gestão de recursos, podemos configurar RAM, CPU e, de modo geral, gerenciar os recursos do nosso cluster (agrupamento), das aplicações, do banco de dados e dos próprios contêineres. Kubernetes é um orquestrador completo que nos permite ter controle total do ambiente.

Comparando com ambientes de máquinas virtuais

É útil fazermos uma breve comparação com um ambiente de VM (máquina virtual). Basicamente, em um ambiente de máquinas virtuais, temos um ponto de acesso que direciona para alguma VM executando uma aplicação, outra VM executando uma API (interface de programação de aplicações) e outra VM executando um ambiente completo, com aplicação e banco de dados — a solução completa está ali dentro. Agora, se por algum motivo essa VM cair, perdemos a VM. Sem orquestração, a configuração manual nos obriga a religar a máquina e aguardar a inicialização até que o ambiente fique novamente disponível. Isso é mais custoso e mais arriscado e, dependendo do negócio, pode ser inviável. Pior ainda quando ocorre a queda de uma solução completa sem plano de contingência ou plano de rollback (reversão); isso é um grande problema.

Com Kubernetes, temos controle muito maior. Passamos a ter acesso unificado por meio de um load balancer (balanceador de carga), um unificador, um Ingress (recurso de entrada) — um ponto de acesso unificado do Kubernetes para dentro do cluster (agrupamento) —, e o próprio orquestrador fará a gestão. Podemos, por exemplo, ter uma aplicação executando com três réplicas e garantir que essa aplicação tenha recursos suficientes; o Kubernetes gerenciará para onde o acesso irá. As máquinas serão os nós, executando diferentes soluções e diferentes contêineres; a parte de gestão e configuração fica com o Kubernetes. Não precisamos controlar o que há dentro de cada nó; o Kubernetes fará essa gestão por nós. Podemos declarar que queremos três réplicas de uma aplicação, e ele mesmo as distribuirá.

Se houver recursos disponíveis ou, por exemplo, se um de nossos nós cair, se uma de nossas máquinas falhar, se o nosso cluster (agrupamento) apresentar falha por algum motivo, o Kubernetes redireciona, gerencia e restaura nosso contêiner sem necessidade de aguardar a inicialização da máquina; não é necessário que todo o ambiente suba novamente. Ele detecta que houve um problema no local onde aqueles contêineres estavam em execução e move esses contêineres para outros nós. Às vezes, identifica que uma API (interface de programação de aplicações) está recebendo muito tráfego e não há mais recursos naquela máquina ou naquele nó; nesse caso, é possível movê-la para outro nó. O Kubernetes faz essa gestão. Quando o acesso à máquina volta, o Kubernetes busca aliviar a carga e desestressar os nós. Tudo isso faz parte da gestão pelo Kubernetes.

Organizando ambientes e destacando benefícios gerais

Além disso, podemos fazer separação de ambientes com Kubernetes. Por exemplo, podemos ter o banco de dados de produção e o banco de dados de homologação em execução e acessá-los individualmente, ainda que estejam no mesmo nó. Ao acessar, isso é transparente, pois, por meio da separação por namespaces, conseguimos isolá-los e usá-los separadamente. Podemos tornar os bancos de dados acessíveis apenas dentro do ambiente do cluster (agrupamento); isto é, somente as aplicações podem acessá-los. O acesso externo pode ser bloqueado por motivos de segurança. O mesmo vale para as aplicações, a comunicação interna e a separação por namespaces; toda essa gestão é possibilitada pelo cluster de Kubernetes.

Trata-se de uma tecnologia muito eficiente que confere resiliência, escalabilidade, segurança e boas práticas — tudo por meio de configurações simples, arquivos em YAML, arquivos de configuração, gestão de Secrets (segredos) e similares. Com isso, vimos que o ambiente com Kubernetes é muito mais gerenciável e muito mais seguro.

Sobre o curso Kubernetes: orquestrar e gerenciar containers em ambientes locais

O curso Kubernetes: orquestrar e gerenciar containers em ambientes locais possui 663 minutos de vídeos, em um total de 91 atividades. Gostou? Conheça nossos outros cursos de Containers em DevOps, ou leia nossos artigos de DevOps.

Matricule-se e comece a estudar com a gente hoje! Conheça outros tópicos abordados durante o curso:

• Da lógica da orquestração à organização do cluster
• Ambiente Kubernetes local: instalação de ferramentas, criação de clusters e gerenciamento
• Do pod ao acesso externo: deployments, rollback e configuração de services no Kubernetes
• Explorando arquiteturas de cluster: do Kind local ao gerenciamento de máquinas virtuais e nuvem
• Trabalhando com múltiplos nodes: do deployment YAML às boas práticas de estabilidade no Kubernetes
• Configurações seguras e variáveis de ambiente: como utilizar ConfigMaps e Secrets em seus deployments
• Ciclo de vida e saúde da aplicação: políticas de imagem, restart e o uso de probes no Kubernetes
• Gestão de recursos e namespaces: configurando requests, limits e comunicação entre ambientes