Perfis do Fargate para pods sem servidor

AWS Fargate para EKS permite executar pods do Kubernetes sem provisionar ou gerenciar nós do EC2. Em vez de pensar em tipos de instância e grupos de nós, você define um perfil do Fargate que informa ao EKS quais pods devem ser executados no Fargate, com base no namespace e em seletores de rótulos opcionais. A AWS provisiona automaticamente a quantidade adequada de capacidade computacional para cada pod e a encerra quando o pod é interrompido.

Um perfil do Fargate é associado a um cluster do EKS e contém um ou mais seletores — cada seletor especifica um namespace e pares opcionais de chave e valor de rótulos do Kubernetes. Um pod precisa corresponder a pelo menos um seletor para ser agendado no Fargate. O perfil também especifica a função de execução do pod (uma função do IAM) e as sub-redes privadas que o Fargate deve usar para iniciar os pods.

A função de execução do pod é uma função do IAM que o EKS assume quando o Fargate obtém imagens de contêiner e envia logs de pods para o CloudWatch. Ela precisa incluir a política gerenciada pela AWS AmazonEKSFargatePodExecutionRolePolicy. Sem essa função, os pods agendados no Fargate não conseguirão iniciar, pois o Fargate não poderá se autenticar no ECR nem gravar no CloudWatch Logs.

O Fargate impõe restrições importantes de namespace. O namespace kube-system não pode ser usado pela maioria dos perfis do Fargate, pois pods do sistema, como o kube-proxy, são executados nele. Uma exceção é o CoreDNS: a AWS fornece um processo guiado para aplicar um patch à implantação do CoreDNS e remover a anotação eks.amazonaws.com/compute-type: ec2, permitindo sua execução no Fargate. Os pods em namespaces excluídos continuarão sem agendamento se nenhum nó do EC2 estiver disponível.

O Fargate aloca recursos computacionais com base nas solicitações de CPU e memória definidas na especificação do pod. Ele arredonda os valores para a combinação de vCPU/memória compatível mais próxima do Fargate (por exemplo, de 0,25 vCPU / 0,5 GB até 16 vCPU / 120 GB). Você paga apenas pelos recursos alocados por segundo enquanto o pod está em execução. Sempre defina solicitações de recursos precisas — solicitar menos do que o necessário causa encerramentos por falta de memória; solicitar mais aumenta o custo.

O Fargate elimina o gerenciamento de nós, mas tem algumas limitações: não oferece DaemonSets (pois não há nós persistentes nos quais agendá-los), não permite contêineres privilegiados e oferece suporte limitado a determinados tipos de armazenamento. Os grupos de nós do EC2 oferecem suporte a GPUs, kernels personalizados e cargas de trabalho com estado que usam unidades NVMe locais. Um padrão comum é executar serviços sem estado no Fargate e cargas de trabalho com estado ou que usam GPU em grupos de nós dedicados do EC2 dentro do mesmo cluster do EKS.

Cada pod do Fargate recebe sua própria interface de rede elástica (ENI) e um IP privado da sub-rede especificada no perfil. Isso permite aplicar um grupo de segurança exclusivo a cada pod usando o recurso Security Groups for Pods. Os pods do Fargate oferecem suporte a todas as regras padrão de grupos de segurança da VPC, proporcionando um controle detalhado do tráfego de entrada e saída no nível de cada pod — uma importante vantagem de segurança em relação aos grupos de segurança compartilhados no nível do nó.

Os pods do Fargate enviam logs para o Amazon CloudWatch Logs usando o roteador de logs integrado Fluent Bit. Você configura o logging criando um ConfigMap chamado aws-logging no namespace aws-observability. A função de execução do pod precisa ter permissão para criar grupos de logs e gravar eventos de log. Os logs são organizados em grupos de logs do CloudWatch por cluster e namespace, facilitando a agregação centralizada de logs sem executar um agente de logs separado.

O Fargate oferece suporte ao Horizontal Pod Autoscaler (HPA) do Kubernetes. Quando o HPA aumenta o número de réplicas, o Fargate provisiona automaticamente novas microVMs, sem que você precise ajustar o tamanho de nenhum grupo de nós. Isso proporciona uma experiência verdadeiramente sem servidor de escalabilidade automática: o HPA controla a quantidade de pods, e o Fargate gerencia a capacidade computacional de forma elástica. Você ainda precisa ter o Metrics Server implantado no cluster para que o HPA leia o uso de CPU e memória.

Você paga pelo consumo de vCPU-segundo e GB-segundo no Fargate, com um mínimo de 1 minuto por pod. Não há custos no nível do nó, cobranças por capacidade reservada nem custos de aplicação de patches na AMI ou no OS. Normalmente, o Fargate é mais caro por unidade de capacidade computacional do que instâncias sob demanda do EC2 dimensionadas corretamente, mas o custo total de propriedade costuma ser menor quando se considera o tempo de engenharia economizado no gerenciamento de nós, na aplicação de patches e nas decisões de escalabilidade.

Principais limitações do Fargate para a prova SAA-C03: não oferece suporte a DaemonSet (os pods não podem ser colocados em cada nó porque não há nós persistentes), não permite contêineres privilegiados, não oferece o modo hostNetwork, e o armazenamento efêmero é limitado a 20 GB por pod (podendo ser expandido para 200 GB com uma configuração). O armazenamento persistente em bloco com EBS não é compatível — use EFS para armazenamento persistente compartilhado de arquivos com pods do Fargate.

Teste sua compreensão dos conceitos do AWS Solutions Architect (SAA-C03) desta lição.

Nesta lição, você aprendeu que: os perfis do Fargate usam seletores de namespace e rótulos para agendar pods sem servidor; a função de execução do pod concede ao Fargate permissão para obter imagens e gravar logs; e o Fargate não oferece suporte a DaemonSets nem a EBS — use EFS para armazenamento persistente. A seguir, exploraremos a rede do EKS com o plug-in VPC CNI e o AWS Load Balancer Controller.