Fundamentos do EKS: Arquitetura e Componentes
Amazon EKS (Elastic Kubernetes Service) é um serviço gerenciado que elimina a complexidade de manter um plano de controle Kubernetes. Você se concentra apenas nos nós de trabalho, enquanto a AWS gerencia os componentes de controle (API Server, etcd, controladores). O EKS suporta diferentes modelos de computação: EC2 (tradicional), Fargate (serverless) e agora Graviton (ARM64). Essa flexibilidade permite otimizar custos e performance conforme sua carga de trabalho.
A arquitetura separa-se em dois planos: o plano de controle (gerenciado pela AWS) e o plano de dados (seus nós). Para provisionar um cluster básico, use Terraform ou AWS CLI. Um cluster EKS mínimo requer VPC, subnets e uma role IAM com permissão AmazonEKSClusterPolicy. Após criar o cluster, configure o kubeconfig local para acessá-lo via kubectl.
# Criar cluster EKS básico com AWS CLI
aws eks create-cluster \
--name meu-cluster \
--version 1.27 \
--role-arn arn:aws:iam::ACCOUNT:role/eks-service-role \
--resources-vpc-config subnetIds=subnet-12345,subnet-67890 \
--region us-east-1
# Atualizar kubeconfig
aws eks update-kubeconfig --name meu-cluster --region us-east-1
Managed Node Groups: Escalabilidade Declarativa
Managed Node Groups automatizam a criação e o ciclo de vida de nós EC2. Você define o tipo de instância, quantidade desejada e políticas de escalabilidade automática. A AWS cuida de patches, atualizações e substituição de nós não íntegros. Isso reduz significativamente a operação manual e risco de configurações inconsistentes.
Para configurar um node group com Terraform, defina o tipo de instância, capacidade desejada e tags. O exemplo abaixo cria um grupo com 3 nós t3.medium que escala automaticamente de 2 a 5 conforme demanda. A role IAM associada precisa de AmazonEKSWorkerNodePolicy, AmazonEKS_CNI_Policy e AmazonEC2ContainerRegistryReadOnly.
resource "aws_eks_node_group" "primary" {
cluster_name = aws_eks_cluster.main.name
node_group_name = "primary-group"
node_role_arn = aws_iam_role.worker_role.arn
subnet_ids = var.private_subnets
scaling_config {
desired_size = 3
max_size = 5
min_size = 2
}
instance_types = ["t3.medium"]
disk_size = 50
tags = {
Environment = "production"
}
depends_on = [
aws_iam_role_policy_attachment.worker_policy,
aws_iam_role_policy_attachment.cni_policy
]
}
Combine Managed Node Groups com Cluster Autoscaler ou Karpenter para escalabilidade inteligente. O Cluster Autoscaler monitora pods não agendáveis e solicita novos nós; Karpenter, mais recente, consolida automaticamente recursos ociosos, reduzindo custos em até 40%.
Fargate: Serverless no Kubernetes
AWS Fargate abstrai completamente a gerência de servidores. Você define um Fargate Profile associando namespaces ou labels a pods que rodarão sem nós visíveis. Ideal para cargas variáveis, microserviços efêmeros ou quando sua equipe não quer pensar em infraestrutura. O custo é por CPU e memória consumidas, não por instância reservada.
Crie um Fargate Profile para um namespace específico. Pods com labels correspondentes executarão automaticamente em Fargate. Note que nem todos os tipos de workload são adequados: DaemonSets, privilégios elevados e acesso direto a hardware não funcionam. Fargate funciona melhor com aplicações stateless containerizadas.
# Criar Fargate Profile para namespace 'production'
aws eks create-fargate-profile \
--cluster-name meu-cluster \
--fargate-profile-name production-profile \
--pod-execution-role-arn arn:aws:iam::ACCOUNT:role/eks-fargate-pod-role \
--subnets subnet-12345 subnet-67890 \
--selectors namespace=production,labels={app=web}
# Pod será agendado em Fargate se corresponder ao seletor
apiVersion: v1
kind: Pod
metadata:
name: minha-app
namespace: production
labels:
app: web
spec:
containers:
- name: app
image: meu-repo/minha-app:1.0
resources:
requests:
memory: "512Mi"
cpu: "256m"
Add-ons: Extensões Essenciais do Cluster
Add-ons são componentes gerenciados pela AWS que adicionam funcionalidades críticas: CNI (vpc-cni para networking), CoreDNS (resolução DNS), kube-proxy (roteamento de serviços) e observabilidade. Em vez de instalar manualmente, use a console EKS, Terraform ou AWS CLI para ativar, e a AWS faz updates automaticamente.
VPC CNI é essencial para networking. Ele atribui IPs elásticos da VPC diretamente a pods, permitindo roteamento nativo. Configure o número máximo de ENIs (Elastic Network Interfaces) e IPs por nó conforme seu tipo de instância. Adicione o add-on de segredos (AWS Secrets Manager), observabilidade (CloudWatch Container Insights) e ingress controller (AWS Load Balancer Controller) conforme necessário.
# Ativar add-on VPC CNI com Terraform
resource "aws_eks_addon" "vpc_cni" {
cluster_name = aws_eks_cluster.main.name
addon_name = "vpc-cni"
addon_version = "v1.14.1-eksbuild.1"
resolve_conflicts = "OVERWRITE"
service_account_role_arn = aws_iam_role.cni_role.arn
tags = {
"Environment" = "production"
}
}
# Ativar AWS Load Balancer Controller
resource "aws_eks_addon" "aws_load_balancer_controller" {
cluster_name = aws_eks_cluster.main.name
addon_name = "aws-load-balancer-controller"
addon_version = "v2.6.0-eksbuild.1"
service_account_role_arn = aws_iam_role.alb_controller_role.arn
}
Sempre mantenha add-ons atualizados. A AWS fornece versões compatíveis com cada versão do Kubernetes. Monitore a saúde via kubectl get daemonsets -n kube-system e logs no CloudWatch para diagnosticar falhas de networking ou DNS.
Conclusão
Três aprendizados fundamentais: (1) Managed Node Groups automatizam operação EC2 enquanto você mantém controle granular; (2) Fargate elimina complexidade de infraestrutura para workloads stateless, sendo perfeito para burst traffic; (3) Add-ons gerenciados garantem que componentes críticos (CNI, DNS, controladores) permaneçam atualizados sem intervenção manual. Combine essas três abordagens conforme sua arquitetura — a maioria dos clusters produtivos usa Node Groups para workloads previsíveis e Fargate para variáveis.