22. Arquitetura e workloads do Kubernetes

Este capítulo apresenta Arquitetura e workloads do Kubernetes em uma sequência pensada para quem está aprendendo o assunto. Os conceitos serão ligados a problemas, decisões, formas de execução e evidências, para que siglas e ferramentas ganhem sentido dentro do ciclo completo da tecnologia.

Com as bases consolidadas, estudamos como abstração e automação compartilham recursos, distribuem cargas e aceleram a entrega. A nuvem combina infraestrutura, serviços, responsabilidade compartilhada e operação em escala. Este é o capítulo 22 de 27 da disciplina Computação em Nuvem, Virtualização e Contêineres. Ele retoma Harbor, registro de imagens e Red Hat Clair e acrescenta uma nova camada. Na sequência, estudaremos Redes, armazenamento e segurança no Kubernetes.

Ponto de partida

Para compreender infraestrutura, acompanhe o caminho completo de uma solicitação e de seus dados. Identifique o componente que recebe a entrada, o estado que precisa conservar, as dependências que aciona e a saída que entrega. Depois introduza atraso, indisponibilidade ou configuração incorreta e observe como o sistema reage.

Em Computação em Nuvem, Virtualização e Contêineres, o nome de uma tecnologia é apenas o começo. O entendimento surge quando você relaciona finalidade, arquitetura, configuração, operação, segurança e recuperação. Essa leitura por camadas evita decorar siglas sem compreender o mecanismo que sustenta o serviço.

Fundamentos e vocabulário

Começamos por Fundamentos e vocabulário, que fornece a linguagem necessária para compreender as partes seguintes.

O primeiro elemento dessa parte estabelece a base. Metadados são amplamente visíveis e não apropriados a segredo. Observe como essa regra define o papel do componente e quais efeitos aparecem nas camadas vizinhas.

A partir dessa base, aparece uma consequência importante. NetworkPolicies e outros controles são necessários à multitenancy. Para enxergar o mecanismo, acompanhe entrada, transformação, estado e saída, inclusive quando uma dependência deixa de responder.

Esse comportamento se conecta ao próximo componente. Jobs devem ser idempotentes e políticas de concorrência devem ser definidas. Na prática, o conceito só fica completo quando configuração, contexto e resultado podem ser relacionados.

Na operação cotidiana, a mesma lógica revela outro aspecto. Workload finito difere de Deployment. O ponto central é localizar essa função na arquitetura e distingui-la de recursos com nomes ou efeitos parecidos.

Quando o ambiente cresce ou falha, surge uma condição adicional. Agentes de log e rede são usos típicos; Jobs tratam conclusão. A decisão correta depende de capacidade, compatibilidade, risco e comportamento durante falhas, e não apenas do funcionamento em condições ideais.

Com essas relações em mente, podemos avançar mais um passo. DaemonSet mantém Pod em todos ou em subconjunto de nós, útil para agentes. Esse vínculo entre desenho e operação permite prever consequências e escolher uma evidência adequada para confirmar o resultado.

O primeiro elemento dessa parte estabelece a base. Schema e APIs disponíveis também precisam ser compatíveis. Observe como essa regra define o papel do componente e quais efeitos aparecem nas camadas vizinhas.