<h2>Fundamentos do EKS: Arquitetura e Componentes</h2>
<p>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.</p>
<p>A arquitetura separa-se em dois planos: o <strong>plano de controle</strong> (gerenciado pela AWS) e o <strong>plano de dados</strong> (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 <code>AmazonEKSClusterPolicy</code>. Após criar o cluster, configure o kubeconfig local para acessá-lo via kubectl.</p>
<pre><code class="language-bash"># 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</code></pre>
<h2>Managed Node Groups: Escalabilidade Declarativa</h2>
<p>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.</p>
<p>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 <code>AmazonEKSWorkerNodePolicy</code>, <code>AmazonEKS_CNI_Policy</code> e <code>AmazonEC2ContainerRegistryReadOnly</code>.</p>
<pre><code class="language-hcl">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
]
}</code></pre>
<p>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%.</p>
<h2>Fargate: Serverless no Kubernetes</h2>
<p>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.</p>
<p>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.</p>
<pre><code class="language-bash"># 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}</code></pre>
<pre><code class="language-yaml"># 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"</code></pre>
<h2>Add-ons: Extensões Essenciais do Cluster</h2>
<p>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.</p>
<p>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.</p>
<pre><code class="language-hcl"># 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
}</code></pre>
<p>Sempre mantenha add-ons atualizados. A AWS fornece versões compatíveis com cada versão do Kubernetes. Monitore a saúde via <code>kubectl get daemonsets -n kube-system</code> e logs no CloudWatch para diagnosticar falhas de networking ou DNS.</p>
<h2>Conclusão</h2>
<p><strong>Três aprendizados fundamentais:</strong> (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.</p>
<h2>Referências</h2>
<ul>
<li><a href="https://docs.aws.amazon.com/eks/" target="_blank" rel="noopener noreferrer">AWS EKS Documentation - Official</a></li>
<li><a href="https://docs.aws.amazon.com/eks/latest/userguide/managed-node-groups.html" target="_blank" rel="noopener noreferrer">Managed Node Groups - AWS Developer Guide</a></li>
<li><a href="https://docs.aws.amazon.com/eks/latest/userguide/fargate.html" target="_blank" rel="noopener noreferrer">AWS Fargate for EKS</a></li>
<li><a href="https://docs.aws.amazon.com/eks/latest/userguide/eks-add-ons.html" target="_blank" rel="noopener noreferrer">EKS Add-ons Management</a></li>
<li><a href="https://karpenter.sh/docs/" target="_blank" rel="noopener noreferrer">Karpenter - Open Source Node Autoscaler</a></li>
</ul>