DEV Community: Rodrigo Fernandes

Observability for Resilience on Amazon EKS with OpenTelemetry + Datadog (Free Tier)

Rodrigo Fernandes — Wed, 24 Dec 2025 15:21:31 +0000

Building Dashboards That Truly Matter

Resilience in cloud-native applications is not just about restarting pods or running across multiple Availability Zones.

Without deep observability, you don’t know:

where latency increases
which service degrades first
whether autoscaling actually works
how long the system takes to recover

In other words: without observability, you test resilience in the dark.

In this article, you will learn how to build a complete observability platform for resilience on Amazon EKS, using only open-source tools and the Datadog free tier.

🧭 What You Will Build

By the end of this article, you will have:

✅ An EKS cluster ready for testing
✅ OpenTelemetry Collector deployed via Helm
✅ Metrics, logs, and traces exported
✅ Datadog configured (free tier)
✅ Dashboards focused on real resilience
✅ A foundation ready for Chaos Engineering

🧠 High-Level Architecture

The architecture follows the modern cloud-native observability pattern:

Instrumented (or auto-instrumented) applications
OpenTelemetry Collector as the central layer
Datadog as the visualization and APM backend
CloudWatch as a native AWS complement

👉 Metrics, logs, and traces flow in a unified way

1️⃣ Why Observability Is Fundamental to Resilience

Resilience is not just about staying up.
It is about understanding system behavior under failure.

With proper observability, you can answer questions such as:

✔ Does latency increase during failures?
Chaos tests almost always impact response time. Without metrics, this goes unnoticed.

✔ Does the system fail gracefully?
5xx and 4xx errors show whether the application degrades correctly or completely breaks.

✔ Is the bottleneck code or infrastructure?
CPU, memory, I/O, and network saturation tell the truth.

✔ Where is the bottleneck between microservices?
Distributed traces show exactly where time is spent.

✔ Is Kubernetes reacting properly?
Events, restarts, and scheduling behavior reveal a lot about resilience.

You cannot improve what you cannot observe.

2️⃣ Creating the EKS Cluster with eksctl

For labs, testing, and technical articles, eksctl is fast and efficient:

eksctl create cluster \
  --name observability-eks \
  --region us-east-1 \
  --version 1.30 \
  --nodegroup-name ng-default \
  --node-type t3.medium \
  --nodes 2 \
  --nodes-min 2 \
  --nodes-max 4 \
  --managed

This creates:

A functional EKS cluster
A managed node group
IAM automatically configured
kubeconfig ready to use

3️⃣ Minimal Application Instrumentation

Even without deep instrumentation, it is already possible to extract significant value.

📌 Automatic Kubernetes Metrics

Collected via kubelet and cAdvisor:
CPU and memory per pod
Restarts
Network usage
Scheduling latency

📌 Automatic Tracing (Auto-Instrumentation)

OpenTelemetry supports:

Java
Node.js
Python
Go (partial)

Without changing the code, you already get distributed traces.

📌 Structured Logs

Recommended format:

{
  "timestamp": "2025-01-01T12:34:56Z",
  "message": "Order created",
  "trace_id": "abc123",
  "span_id": "def456",
  "service": "checkout"
}

This enables direct correlation between logs and traces.

4️⃣ Deploying the OpenTelemetry Collector with Helm

The OpenTelemetry Collector acts as the central observability layer.

It receives data via OTLP, processes it, and exports it to Datadog.

Installation via Helm

helm install otel-collector ./otel-datadog \
  --namespace observability \
  --create-namespace \
  --set datadog.apiKey=<YOUR_API_KEY>

The Collector starts collecting:

Metrics (Prometheus / Kubernetes)
Logs
Traces
Cluster events

5️⃣ Datadog Free Tier

The Datadog Free Tier is surprisingly powerful:

✔ Up to 5 free hosts
✔ APM included
✔ Unlimited dashboards
✔ Automatic Service Map
✔ Basic alerts

This is more than enough for resilience and chaos testing.

6️⃣ Dashboards That Truly Matter for Resilience

This is the key point of the article: what to monitor.

📊 6.1 Service Latency (APM)

Metric:

trace.<service>.request.duration

Helps identify:

failure impact
progressive degradation
bottlenecks between services

🚨6.2 5xx and 4xx Errors

Metrics:

http.server.request.error.count
trace.<service>.errors

A direct indicator of user-perceived failure.

🔥 6.3 CPU and Memory Saturation per Pod

kubernetes.pod.cpu.usage.total
kubernetes.pod.memory.usage

Essential for validating:

HPA
Karpenter
poorly sized requests and limits

⚙️ 6.4 Event Loop (Node.js)

Custom metric:

event_loop_delay

Shows when the application is alive but unusable.

🗺️ 6.5 Service Map

Automatically visualizes:

broken dependencies
increased latency
critical services

One of Datadog’s most powerful features.

🔄 6.6 Kubernetes Events and Restarts

kubernetes.pod.restart.count
kubernetes.event.count

Detects:

CrashLoopBackOff
OOMKilled
readiness failures
scheduling issues

📊 Datadog Dashboard — EKS Resilience Observability
How to Use

Datadog → Dashboards
New Dashboard
Import JSON
Paste the content below

✅ Covered Items (Section 6 Checklist)

✔ 6.1 Service latency (APM)
✔ 6.2 5xx and 4xx errors
✔ 6.3 CPU per pod
✔ 6.3 Memory per pod
✔ 6.4 Event Loop (Node.js)
✔ 6.5 Service Map (operational reference)
✔ 6.6 Pod restarts
✔ 6.6 Kubernetes events

🧩 Dashboard JSON

{
  "title": "EKS Resilience Observability",
  "description": "Dashboards focados em resiliência no EKS usando OpenTelemetry + Datadog",
  "layout_type": "ordered",
  "widgets": [
    {
      "definition": {
        "type": "timeseries",
        "title": "APM - Latência por Serviço",
        "requests": [
          {
            "q": "avg:trace.*.request.duration{*} by {service}",
            "display_type": "line"
          }
        ]
      }
    },
    {
      "definition": {
        "type": "timeseries",
        "title": "APM - Taxa de Erros 5xx",
        "requests": [
          {
            "q": "sum:http.server.request.error.count{status:5xx} by {service}",
            "display_type": "line"
          }
        ]
      }
    },
    {
      "definition": {
        "type": "timeseries",
        "title": "APM - Taxa de Erros 4xx",
        "requests": [
          {
            "q": "sum:http.server.request.error.count{status:4xx} by {service}",
            "display_type": "line"
          }
        ]
      }
    },
    {
      "definition": {
        "type": "timeseries",
        "title": "Kubernetes - CPU por Pod",
        "requests": [
          {
            "q": "avg:kubernetes.pod.cpu.usage.total{*} by {pod_name,namespace}",
            "display_type": "line"
          }
        ]
      }
    },
    {
      "definition": {
        "type": "timeseries",
        "title": "Kubernetes - Memória por Pod",
        "requests": [
          {
            "q": "avg:kubernetes.pod.memory.usage{*} by {pod_name,namespace}",
            "display_type": "line"
          }
        ]
      }
    },
    {
      "definition": {
        "type": "timeseries",
        "title": "Node.js - Event Loop Delay",
        "requests": [
          {
            "q": "avg:event_loop_delay{*} by {service}",
            "display_type": "line"
          }
        ]
      }
    },
    {
      "definition": {
        "type": "timeseries",
        "title": "Kubernetes - Restarts de Pods",
        "requests": [
          {
            "q": "sum:kubernetes.pod.restart.count{*} by {pod_name,namespace}",
            "display_type": "bars"
          }
        ]
      }
    },
    {
      "definition": {
        "type": "timeseries",
        "title": "Kubernetes - Eventos por Tipo",
        "requests": [
          {
            "q": "sum:kubernetes.event.count{*} by {reason}",
            "display_type": "bars"
          }
        ]
      }
    },
    {
      "definition": {
        "type": "note",
        "content": "🔎 Use o **Service Map do Datadog (APM → Service Map)** para visualizar dependências, gargalos e falhas de comunicação entre microserviços.",
        "background_color": "blue",
        "font_size": "16"
      }
    }
  ]
}

🧠 How This Dashboard Helps with RESILIENCE

Signal | What It Validates
Latency Real impact of failures
5xx Errors User-perceived failure
4xx Errors Controlled degradation
CPU / Memory Bottlenecks and autoscaling
Event Loop App alive but degraded
Restarts Pod stability
Kubernetes Events Root cause
Service Map Critical dependencies

7️⃣ Complementing with CloudWatch

Even when using Datadog, CloudWatch remains useful for:

control plane logs
VPC CNI
EKS events
cluster scaling

This creates a hybrid and complete observability approach.

8️⃣ Validating Resilience in Practice

With everything observable, you can test:

✔ Node failure

pod redistribution
latency impact
recovery time

✔ Pod failure

perceived errors
retries
fallback

✔ Network failures

inter-service timeouts
artificial latency

✔ Traffic spikes

saturation
autoscaling behavior

Now you measure, rather than assume.

9️⃣ Conclusion — Observability Is a Pillar of Resilience

Resilience is not luck.
It is data-driven engineering.

With OpenTelemetry + Datadog, even on the free tier, you get:

✅ deep system visibility
✅ correlation between metrics, logs, and traces
✅ actionable dashboards
✅ a solid foundation for Chaos Engineering
✅ continuous feedback for improvement

If you want to build real resilience on Amazon EKS, the journey starts with observability.

🚀 EKS Auto Mode na prática

Rodrigo Fernandes — Mon, 15 Dec 2025 11:29:01 +0000

O Amazon EKS Auto Mode representa um avanço significativo na operação de clusters Kubernetes, eliminando controles de infraestrutura manual, provisionando compute sob demanda e permitindo foco exclusivo nas workloads.

Neste guia hands-on, você aprenderá:

A criar um cluster com Auto Mode já habilitado usando eksctl
A implantar a Retail Store Sample App — aplicação oficial da AWS para testes de workloads reais
A analisar o funcionamento do Auto Mode, incluindo provisionamento, escalabilidade e distribuição de Pods
A realizar testes práticos de resiliência e comportamento automático do cluster

📌 Arquivos de configuração do artigo:
👉 https://github.com/rodrigofrs13/eks-auto-mode-na-pratica

🧩 1. O que é o EKS Auto Mode?

O EKS Auto Mode executa automaticamente tarefas de operação de cluster, incluindo:

Seleção e provisionamento de compute sob demanda
Autoscaling e realocação de Pods
Gerenciamento de AMIs, patches e updates
Escolha automática dos melhores tipos de instância
Redução de custos com otimização inteligente
Você envia Pods → o Auto Mode provisiona infraestrutura → o workload roda

⚙️ 2. Criando o cluster com Auto Mode usando eksctl
📄 Arquivo conf-cluster-eks.yaml

# cluster.yaml
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
    name: cluster-eks
    region: us-east-1
    version: '1.32'
    tags:
      auto-mode: "enabled"
      graviton-enabled: "true"
      spot-instances-enabled: "true"
      cost-optimization: "enabled"
      architecture: "multi-arch"
      environment: "dev"
      owner: "devops-team"
      provisioned-by: "eksctl"


availabilityZones: ["us-east-1a", "us-east-1b", "us-east-1c"]    

vpc:
  cidr: "10.0.0.0/16"
  nat:
    gateway: Single
  clusterEndpoints:
    publicAccess: true
    privateAccess: true    

cloudWatch:
  clusterLogging:
    enableTypes: ["api", "audit", "authenticator", "controllerManager", "scheduler"]
    logRetentionInDays: 1

autoModeConfig:
    enabled: true
    nodePools: 
      - general-purpose
      - system    

iam:
  withOIDC: true

▶️ Criando o cluster
📄 Arquivo 01-setup-cluster-eks.sh

sh 01-setup-cluster-eks.sh

🏬 3. Implantando a Retail Store Sample App

A Retail Store Sample App simula uma loja online composta por múltiplos microserviços, ideais para testes de provisionamento automático.

▶️ Instalar a aplicação

kubectl apply -f https://github.com/aws-containers/retail-store-sample-app/releases/latest/download/kubernetes.yaml

▶️ Aguardar os deployments ficarem disponíveis

kubectl wait --for=condition=available deployments --all

▶️ Acessar a aplicação via port-forward

kubectl port-forward $(kubectl get pods \
 --selector=app.kubernetes.io/name=ui -o jsonpath='{.items[0].metadata.name}') 8080:8080

A aplicação ficará disponível em:

👉 http://localhost:8080/

✅ 4. Testes e Análise da Configuração do Modo Automático do EKS

Agora vamos validar como o Auto Mode está provisionando, escalando e distribuindo Pods e compute.

🔍 4.1. Verificar os Node Pools do EKS Auto Mode

O Auto Mode organiza a infraestrutura em pools semelhantes ao Karpenter:

general-purpose → para workloads da aplicação
system→ reservado para workloads do sistema

▶️ Ver os Worker Nodes do general-purpose:

kubectl get nodes -l karpenter.sh/nodepool=general-purpose

▶️ Ver os Worker Nodes do system:

kubectl get nodes -l karpenter.sh/nodepool=system

🔍 4.2. Ver distribuição dos Pods entre os NodePools

for node in $(kubectl get nodes -l karpenter.sh/nodepool=general-purpose -o custom-columns=NAME:.metadata.name --no-headers); do
  echo "Pods on $node:"
  kubectl get pods --all-namespaces --field-selector spec.nodeName=$node
done

Isso permite analisar:

Balanceamento
Quantidade de Pods por nó
Regiões de alocação
Reações do Auto Mode ao workload

🔍 4.3. Analisando agendamento dos Pods

kubectl get pods -o wide -A

Você poderá avaliar:
Em qual nó cada Pod está rodando
IP, Node, estado e reinicializações
Padrões de alocação automática

📈 4.4. Simulando aumento de carga

Aumente as réplicas para ativar provisionamento automático:

kubectl scale deployment ui --replicas=10
kubectl scale deployment carts --replicas=10
kubectl scale deployment catalogue --replicas=10

Monitore em tempo real:

kubectl get pods -A -w

🔍 4.7. Ver distribuição dos Pods entre os NodePools

for node in $(kubectl get nodes -l karpenter.sh/nodepool=general-purpose -o custom-columns=NAME:.metadata.name --no-headers); do
  echo "Pods on $node:"
  kubectl get pods --all-namespaces --field-selector spec.nodeName=$node
done

O Auto Mode deve:

Criar novas instâncias
Realocar Pods
Ajustar compute
Reduzir nós quando a carga diminui

📊 4.5. Analisando métricas nativas do cluster
Uso de nós:

kubectl top nodes

Uso de Pods:

kubectl top pods -A

Eventos:

kubectl get events -A --sort-by=.metadata.creationTimestamp

🧪 4.6. Validando realocação alterando recursos

kubectl patch deployment ui \
  -p '{"spec": {"template": {"spec": {"containers": [{"name": "ui", "resources": {"requests": {"cpu": "700m", "memory": "700Mi"}}}]}}}}'

O comportamento esperado é:

Auto Mode provisiona compute mais robusto
Pods são redistribuídos
Novos nós podem surgir

🧹 5. Clean Up — Removendo todos os recursos
▶️ Remover a aplicação

kubectl delete -f https://github.com/aws-containers/retail-store-sample-app/releases/latest/download/kubernetes.yaml

▶️ Deletar o cluster EKS com Auto Mode

sh 02-cleanup-all.sh

🛡️ 6. Conclusão

Com o EKS Auto Mode, a operação de clusters Kubernetes torna-se mais simples, eficiente e automática.
Neste artigo, exploramos:

A criação de clusters prontos para Auto Mode
A implantação de uma aplicação real da AWS
A análise do comportamento inteligente de provisionamento
Testes práticos de resiliência e escalabilidade

Esse modo reduz consideravelmente o esforço de operação e permite foco total no desenvolvimento de aplicações.

📌 Todos os arquivos usados no artigo estão no repositório:
👉 https://github.com/rodrigofrs13/eks-auto-mode-na-pratica

Fundamentos de Resiliência no Amazon EKS: Como projetar workloads tolerantes a falhas em produção

Rodrigo Fernandes — Tue, 09 Dec 2025 21:43:52 +0000

A resiliência é um dos pilares fundamentais da arquitetura moderna em nuvem. Em ambientes distribuídos, falhas são inevitáveis — nós caem, Pods travam, redes apresentam latência e picos de carga acontecem de forma imprevisível.
Por isso, quando falamos em aplicações críticas rodando em Kubernetes, é indispensável pensar em tolerância a falhas, auto-recuperação, observabilidade e automação.

O Amazon Elastic Kubernetes Service (EKS), ao combinar a flexibilidade do Kubernetes com a robustez da infraestrutura da AWS, oferece um ecossistema poderoso para construir sistemas resilientes.
Mas a resiliência não é automática — ela precisa ser projetada.

🎯 1. O que é Resiliência no Contexto de Kubernetes e EKS?

Resiliência é a capacidade de um sistema:

continuar operando mesmo diante de falhas
recuperar-se automaticamente
degradar de maneira controlada
manter confiabilidade e disponibilidade

No Kubernetes/EKS, isso se traduz em:

multi-AZ
autoscaling
readiness e liveness probes
limites de recursos
rollouts seguros
automação de autoscaling da infraestrutura

Resiliência não significa não falhar, mas falhar com graça.

🏗️ 2. Arquitetura Multi-AZ e Auto-Healing

O EKS simplifica a criação de clusters distribuídos por múltiplas zonas de disponibilidade, reduzindo drasticamente o risco de interrupção.

Por que isso é importante?

Uma AZ pode falhar → seus Pods continuam funcionando em outras.
Interrupções de nós são automaticamente tratadas via: - Managed Node Groups auto-recovery - Auto-healing do Kubernetes

Boas práticas

Usar 2 ou 3 AZs no cluster.
Preferir Managed Node Groups ou EKS Auto Mode. (Tenho um artigo falando mais sobre o EKS Auto Mode
Configurar Pod Anti-Affinity para distribuir Pods entre nós/AZs.

🔧 3. Probes: Garantindo Saúde da Aplicação

As probes são essenciais para resiliência.

Liveness Probe

Detecte travamentos.
Se falhar → Kubernetes reinicia o Pod.

Readiness Probe

Defina quando o Pod está pronto para receber tráfego.

Startup Probe

Evite falsos positivos de liveness em aplicações lentas para iniciar.

Boas práticas

Sempre definir healthchecks adequados
Nunca usar a mesma URL para readiness e liveness
Ajustar tempos: initialDelay, timeout, period

📦 4. Requests, Limits e QoS

Grande parte dos incidentes em clusters vêm de uso incorreto de recursos, como:

consumo excessivo de memória
uso intensivo de CPU
OOMKills
throttling

Requests

Quantidade mínima necessária.

Limits

Máximo permitido para o Pod.

QoS

Guaranteed
Burstable
BestEffort

Boas práticas

Sempre definir requests e limits
Monitorar OOMKills e throttling
Avaliar Vertical Pod Autoscaler em clusters maduros

📈 5. Autoscaling: HPA, Karpenter e EKS Auto Mode

Resiliência também envolve adaptação automática.

HPA (Horizontal Pod Autoscaler)

Escala Pods com base em:

CPU
Memória
Latência
Métricas customizadas (Prometheus)

Infraestrutura: Karpenter ou EKS Auto Mode

Karpenter provê provisionamento inteligente.
EKS Auto Mode leva isso ao próximo nível:

Provisionamento automático baseado nos Pods
Multi-AZ
Zero configuração de node groups
Alta resiliência + redução de custo

Boas práticas

Usar HPA + Auto Mode/Karpenter
Configurar Pod Disruption Budgets
Garantir readiness antes de receber tráfego

🔄 6. Implantação Resiliente: Rolling, Blue/Green e Canary
Rolling Update

Atualização gradual sem downtime.

Blue/Green

Versão nova só recebe tráfego quando validada.

Canary

Tráfego gradual para nova versão baseado em métricas.

Ferramentas recomendadas:

Argo Rollouts
AWS App Mesh
NGINX Ingress Controller

Boas práticas

Evitar breaking changes
Usar feature flags
Monitorar cada etapa do rollout

🧪 7. Testes de Resiliência: Caos, Carga e Funcionais
Chaos Engineering

Ferramentas:

ChaosMesh
LitmusChaos
AWS Fault Injection Simulator

Cenários comuns:

Falha de nó
Falha de Pod
Perda de rede
Latência artificial

Testes de Carga

K6
Locust
Artillery

Testes Funcionais

Robot Framework
Postman/Newman
Cypress (front)

Por que isso importa?

Revela:

gargalos
comportamentos inesperados
falta de tolerância a falhas

📊 8. Observabilidade para Resiliência

Sem visibilidade, não há resiliência.

Métricas

Prometheus
CloudWatch
OpenTelemetry

Logs

Fluent Bit
CloudWatch Logs
OpenSearch

Traces

X-Ray
Jaeger
Tempo (Grafana)

Boas práticas

Criar métricas de SLO (latência, erros)
Dashboards dedicados para Pods, Nodes, Deployments
Alertas automáticos com CloudWatch ou Alertmanager

🛣️ 9. Padrões Fundamentais para Resiliência no Kubernetes

- Pod Disruption Budget (PDB)
- Pod Affinity/Anti-Affinity
- Topology Spread Constraints
- Retry + Exponential Backoff
- Circuit Breaker
- Idempotência
- Timeouts bem definidos

Esses padrões evitam:

cascatas de falhas
saturação de recursos
degradação global do serviço

🎯 10. Conclusão

O EKS fornece uma base robusta, mas a resiliência depende de:

padrões arquiteturais
práticas operacionais
observabilidade
testes contínuos
cultura DevOps
automação inteligente

Ao aplicar esses fundamentos, você obtém aplicações que:

- toleram falhas
- escala automaticamente
- recuperam-se sem intervenção humana
- entregam confiabilidade em produção

Resiliência é uma disciplina, não uma configuração.

Reducing Kubernetes costs using AWS EKS Auto Mode

Rodrigo Fernandes — Tue, 05 Aug 2025 20:05:39 +0000

🚀 Introduction

Efficiently managing Kubernetes clusters can be challenging—especially when it comes to cost optimization. Maintaining underutilized instances, manually configuring scalability, and managing node groups requires time and specialized knowledge.

According to recent studies, organizations often overspend on Kubernetes infrastructure due to over-provisioning and poor resource management.
AWS introduced Amazon EKS Auto Mode, a simpler and more cost-effective way to operate Kubernetes clusters.

In this article, you’ll learn how EKS Auto Mode works, why it helps reduce costs, and how to implement it in your environment with practical examples.

🚀 What is EKS Auto Mode?
EKS Auto Mode is a new operational mode for Amazon EKS that completely abstracts away the infrastructure management of Kubernetes nodes.
Launched in November 2024, it is a natural evolution of Karpenter, offering an even more simplified experience.

🧩 Key Features:

- Automatic Provisioning: Nodes are created and removed automatically based on pod demand
- Smart Optimization: Automatically selects instance types, availability zones, and pricing models
- Zero Management: Eliminates the need to create Node Groups or Launch Templates

💰 How EKS Auto Mode Reduces Costs
The main goal of Auto Mode is to avoid over-provisioning and maximize EC2 usage efficiency.

🎯 Pod-Based Intelligent Scaling
Unlike Node Groups that scale based on CPU/Memory metrics, Auto Mode scales based on pending pods. This removes the need for pre-allocated "buffer" resources.

💸 Automatic Spot Instance Optimization
The system intelligently mixes Spot and On-Demand instances, potentially saving up to 90% on interruption-tolerant workloads.

🔁 Elimination of Idle Nodes
Instances are automatically terminated when no pods are running, with a default grace period of 30 seconds.

🤖 Smart Instance Selection
Auto Mode takes multiple factors into account simultaneously:

Pod CPU/Memory requirements
Instance pricing
Availability across AZs
Architecture (AMD64/ARM64)

⚙️ EKS Auto Mode Setup
✅ Prerequisites

AWS CLI configured
kubectl installed
Helm 3.x
IAM permissions

🧾 Step 1: Clone the Repository

git clone https://github.com/rodrigofrs13/eks-auto-mode.git
cd eks-auto-mode

⚙️ Step 2: Configure the Cluster
Edit the conf-cluster-eks-auto-mode.yaml file with your desired settings for testing.

🚀 Step 3: Create the Cluster
Run the script to set up and enable Auto Mode:

sh setup-cluster-eks-auto-mode.sh

🔌 Step 4: Connect to the Cluster

aws eks --region <region> update-kubeconfig --name <cluster-name>

🔍 Step 5: Verify Resources
Check if Karpenter-related resources were created:

NodePool

kubectl get nodepool

NodeClass

kubectl get nodeclass

EC2NodeClass: Defines EC2 configurations (AMI, security groups, subnets, user data)
NodePool: Defines scaling policies (instance types, taints, resource limits)

🧠 Advanced Configuration - NodePool for AMD64

For workloads requiring AMD64 architecture, apply:

kubectl apply -f NodePool-AMD.yaml

🧪 Scalability Test
🧱 Apply the Test Deployment

Apply deployment

kubectl apply -f deploy-scaling-SPOT.yaml

📈 Scale to 50 replicas

kubectl scale deployment nginx-arm64-spot --replicas=50

🔎 Monitor in Real Time

Pods

kubectl get pods -w

*NodeClaims *

kubectl get nodeclaim

Worker Nodes

kubectl get nodes --show-labels

✅ Expected Results
⏱️ Response Time: New nodes within 30–45 seconds

💡 Optimization: Auto Spot/On-Demand mix

🧹 Cleanup: Idle nodes deleted after 30s grace period

📊 Cost Monitoring with Kubecost

Install Kubecost

helm repo add kubecost https://kubecost.github.io/cost-analyzer/
helm repo update

helm install kubecost kubecost/cost-analyzer \
  --namespace kubecost \
  --create-namespace \
  --set persistentVolume.enabled=false \
  --set prometheus.server.persistentVolume.enabled=false \
  --set persistentVolume.enabled=false

Check Installation

kubectl get pods -n kubecost

kubectl port-forward --namespace kubecost deployment/kubecost-cost-analyzer 9090

Access the dashboard at: http://localhost:9090
🕒 Wait ~25 minutes for full metric collection.

🔍 Key Metrics:

Cost per namespace
Efficiency metrics: Usage vs. requests
Spot vs On-Demand ratio
Hourly cost trends

🧠 Best Practices for Maximum Optimization

Accurate Resource Requests and Limits

resources:
  requests:
    cpu: "100m"
    memory: "128Mi"
  limits:
    cpu: "500m"
    memory: "512Mi"

Toleration Separation by Interruption Tolerance

tolerations:
- key: "spot"
  operator: "Equal"
  value: "false"
  effect: "NoSchedule"

Para workloads tolerantes

tolerations:
- key: "spot"
  operator: "Equal"
  value: "true"
  effect: "NoSchedule"

Node Affinity for Spot Optimization

affinity:
  nodeAffinity:
    preferredDuringSchedulingIgnoredDuringExecution:
    - weight: 100
      preference:
        matchExpressions:
        - key: karpenter.sh/capacity-type
          operator: In
          values: ["spot"]

Use PodDisruptionBudgets

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: my-app-pdb
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: my-app

Cost Monitoring and Alerts

Custom CloudWatch Log Group

aws logs create-log-group --log-group-name /aws/eks/auto-mode/costs

Cost Explorer automation

aws ce get-cost-and-usage \
  --time-period Start=2024-01-01,End=2024-01-31 \
  --granularity MONTHLY \
  --metrics BlendedCost

⚠️ Limitations and When Not to Use
Auto Mode is not suitable for:

Custom AMIs: It uses AWS-optimized AMIs
Specialized Hardware: GPU, Inferentia, or other special instance types
Granular Control Needs: Deeply customized configurations
Strict Compliance Environments: Instance type constraints
Stateful Workloads: Databases needing persistent local storage

✅ Conclusion
Amazon EKS Auto Mode represents a paradigm shift in Kubernetes cluster operations, offering:

🛠️ Operational Simplicity: Up to 80% management time reduction

💸 Cost Savings: 60–70% lower infrastructure costs

🚀 Instant Scalability: Rapid response to demand changes

🧠 Continuous Optimization: Machine learning–based decisions

For organizations seeking to reduce complexity and costs, Auto Mode is a proven and mature solution.
The combination of smart provisioning, Spot instance optimization, and zero over-provisioning leads to substantial savings.

🔗 Additional Resources

🧹 Environment Cleanup
⚠️ Important: Always clean up unused resources to avoid unwanted charges:

chmod +x cleanup-all.sh
./cleanup-all.sh

Creating a simple and fast EKS Cluster

Rodrigo Fernandes — Sun, 03 Nov 2024 13:20:17 +0000

As a DevOps engineer, having the ability to quickly create and manage Kubernetes clusters is essential. In this article, I'll show you three different ways to create an EKS cluster on AWS, from the simplest to the most complete, helping you be more efficient in your daily tasks.

How This Will Help DevOps Engineers

Quick Environment Setup: Create dev/test environments in minutes
Infrastructure as Code: Maintain cluster configurations in version control
Automation Ready: Easy to integrate with CI/CD pipelines
Scalable Approach: Start simple and evolve as needed

Choose the one that best suits your needs!

Option 1: EKS Cluster in One Command

For those who want to start quickly, there's a super simple way:

eksctl create cluster --name simple-cluster

Done! With this single command you already have:

2 t2.micro nodes
New VPC
Public subnets
Basic security groups

Option 2: Cluster with Custom Settings

If you need more control, you can use this command with parameters:

eksctl create cluster \
    --name middle-cluster \
    --region us-east-1 \
    --version 1.28 \
    --nodegroup-name workers \
    --node-type t3.medium \
    --nodes 2 \
    --nodes-min 2 \
    --nodes-max 4 \
    --managed \
    --asg-access \
    --external-dns-access \
    --full-ecr-access \
    --tags "Environment=development" \
    --zones us-east-1a,us-east-1b

Done! This command gives you:

t3.medium nodes with auto-scaling
ECR and external DNS access
Organization tags
Specific availability zones

Option 3: Cluster via Configuration File

For more robust environments, use a cluster.yaml file:

apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig

metadata:
  name: hard-cluster
  region: us-east-1
  version: "1.28"
  tags:
    karpenter.sh/discovery: cluster-with-karpenter

availabilityZones: ["us-east-1a", "us-east-1b", "us-east-1c"]  

vpc:
  cidr: "10.0.0.0/16"
  nat:
    gateway: Single

iam:
  withOIDC: true

karpenter:
  version: 'v0.20.0'
  createServiceAccount: true
  withSpotInterruptionQueue: true

nodeGroups:
  - name: apps
    availabilityZones: ["us-east-1a", "us-east-1b", "us-east-1c"]
    instanceType: t3.medium
    desiredCapacity: 2
    minSize: 2
    maxSize: 4
   labels:
      role: apps
    tags:
      Environment: production
    iam:
      withAddonPolicies:
        autoScaler: true
        albIngress: true

- name: system
    instanceType: t3.small
    availabilityZones: ["us-east-1a", "us-east-1b", "us-east-1c"]
    desiredCapacity: 2
    minSize: 2
    maxSize: 3
    labels:
      role: system

cloudWatch:
    clusterLogging:
        enableTypes: ["api", "audit", "authenticator", "controllerManager", "scheduler"]
        logRetentionInDays: 1 

addons:
  - name: vpc-cni
    version: latest
  - name: coredns
    version: latest

Execute with:

eksctl create cluster -f cluster.yaml

Done! This configuration gives you:

Custom VPC with specific CIDR
Two node groups with different purposes:
Apps group: t3.medium nodes with auto-scaling
System group: t3.small nodes for system components
Auto Scaler and ALB Ingress enabled
Latest versions of core addons
Production-ready setup with proper labeling

Which Option to Choose?
Option 1 (Simple Command)

Quick tests
POCs
Learning

Option 2 (Command with parameters)

Development environment
Specific configurations
Script automation

Option 3 (Configuration file)

Production environment
Version-controlled configuration
Multiple node groups

Cleaning Up Resources
Don't forget to delete the cluster when you no longer need it:

# For any of the options
eksctl delete cluster --name CLUSTER_NAME

# For cluster created with file
eksctl delete cluster -f cluster.yaml

Conclusion

Creating EKS clusters quickly and efficiently brings several key benefits for DevOps professionals:

Time and Productivity Benefits
Rapid Development Cycles: Create new environments in minutes instead of hours
Quick Testing: Validate changes and configurations without long setup times
Fast Disaster Recovery: Quickly spin up new clusters if needed
Efficient Experimentation: Test new configurations and settings without lengthy processes

Cost Benefits
Pay Only What You Need: Create clusters only when needed
Environment Control: Easily spin up and tear down environments
Resource Optimization: Scale environments based on actual needs
Development Cost Reduction: Use temporary clusters for testing instead of maintaining permanent ones

Technical Benefits
Infrastructure as Code: Maintain consistent environments across teams
Version Control: Track all cluster configurations in Git
Automation Ready: Easily integrate with CI/CD pipelines
Environment Parity: Ensure development matches production

Team Benefits
Self-Service Infrastructure: Teams can create their own environments
Reduced Dependencies: Less reliance on infrastructure teams
Better Learning: Quick feedback loop for learning Kubernetes
Increased Confidence: More testing and validation opportunities

Business Benefits
Faster Time to Market: Reduce environment setup time
Improved Quality: More thorough testing in production-like environments
Risk Reduction: Test changes in isolated environments
Better Resource Utilization: Create and destroy environments as needed

By mastering these cluster creation methods, you'll be able to:
Support development teams more effectively
Respond to incidents faster
Manage resources more efficiently
Implement better testing practices
Improve your infrastructure automation

Remember: The ability to quickly create and manage EKS clusters isn't just about technical capability - it's about enabling your organization to move faster, work more efficiently, and deliver better results.

Hands-On: Escalonamento automático com EKS e Cluster Autoscaler utilizando Terraform e Helm

Rodrigo Fernandes — Thu, 20 Jun 2024 14:59:05 +0000

Introdução

O escalonamento automático de clusters é uma funcionalidade essencial em ambientes de computação em nuvem, especialmente quando se trata de gerenciar recursos de forma eficiente e econômica.

Nesse contexto o Cluster Autoscaler (CA) é uma ferramenta vital para ajustar dinamicamente o número de instâncias de nó em um cluster Kubernetes, garantindo que as cargas de trabalho tenham recursos suficientes enquanto minimiza os custos.

Este artigo técnico explora o processo de configuração e uso do Amazon EKS e do Cluster Autoscaler utilizando Terraform e Helm para implementar o escalonamento automático.

Informações gerais

As configurações abaixo são para ambientes de testes, workshops e demos. Não utilizar em ambientes de produção.

Caso já conheça o Cluster Autoscaler e quer fazer testes, clique nesse link e use o repositório completo.

Se quer fazer o passo-a-passo para entender em detalhes, siga as instruções abaixo.

Setup do Cluster

Para o setup do cluster, iremos utilizar um repositório em Terraform com o código de um cluster básico já pronto.

Acesse o repositório clicando aqui, no readme existe o passo-a-passo para o setup completo do cluster.

Após a execução dos passos, aguarde até conclusão, o output será conforme imagem abaixo:

Pronto, o setup do cluster está concluido, vamos acessar o cluster e fazer alguns testes iniciais para analisar a integridade do cluster.

Acessando o Cluster

Para acessar o cluster vamos utilizar o AWS Cloud9 e para a configuração vamos seguir o artigo Boosting AWS Cloud9 to Simplify Amazon EKS Administration clicando aqui.

Após seguir os passos do artigo teremos o Cloud9 e o script de ferramentas para Kubernetes configurados.

Copie o comando abaixo, altere a região e o nome do cluster e execute o comando para acessar o cluster EKS .

$ aws eks --region <sua-região> update-kubeconfig --name <nome-do-cluster>

Vamos fazer alguns testes iniciais para verificar a integridade do cluster.

Coletando algumas informações.

kubectl cluster-info

Verificando os Worker Nodes.

kubectl get nodes -o wide

Analisando todos os recursos criados.

kubectl get all -A

Com isso podemos concluir que nosso cluster está funcionando corretamente.

Com o cluster configurado vamos ao Cluster Autoscaler.

O que é o Cluster Autoscaler

O Cluster Autoscaler é uma ferramenta de gerenciamento automático de recursos em clusters Kubernetes.

Ele ajusta automaticamente o tamanho de um cluster Kubernetes, aumentando ou diminuindo o número de Worker Nodes conforme a necessidade de execução das cargas de trabalho.

O Cluster Autoscaler toma decisões com base na quantidade de pods em execução e nas suas respectivas necessidades de recursos.

Para saber mais sobre o Cluster Autoscaler acesse a documentação oficial clicando aqui.

Instalação do Cluster Autoscaler

Vamos dividir os arquivos de insralação e configuração do cluster em 3 partes:

cluster_autoscaler_iam.tf
cluster_autoscaler_chart.tf
cluster_autoscaler_values.yaml

Vamos começar configurando as permissões.

Primeiramente temos que pegar o id da conta AWS e o id do OIDC Provider criado pelo cluster EKS.

Para pegar o id do OIDC Provider execute o comando abaixo, alterando a variável cluster_name.

aws eks describe-cluster --name <cluster_name> --query "cluster.identity.oidc.issuer" --output text

Com o id da conta aws e o id do OIDC Provider, vamos criar o arquivo cluster_autoscaler_iam.tf e colar o trecho do código abaixo.

Lembrado de alterar as variáveis id-da-conta-aws e oidc.

# Criação da política IAM para o Cluster Autoscaler
resource "aws_iam_policy" "cluster_autoscaler_policy" {
  name        = "ClusterAutoscalerPolicy"
  description = "Policy for Kubernetes Cluster Autoscaler"
  policy      = jsonencode({
    Version = "2012-10-17",
    Statement = [
      {
        Effect = "Allow",
        Action = [
          "autoscaling:DescribeAutoScalingGroups",
          "autoscaling:DescribeAutoScalingInstances",
          "autoscaling:DescribeLaunchConfigurations",
          "autoscaling:DescribeTags",
          "autoscaling:SetDesiredCapacity",
          "autoscaling:TerminateInstanceInAutoScalingGroup",
          "ec2:DescribeInstances",
          "ec2:DescribeLaunchTemplateVersions",
          "ec2:DescribeTags"
        ],
        Resource = "*"
      }
    ]
  })
}

# Criar a IAM Role
resource "aws_iam_role" "cluster_autoscaler" {
  name = "eks-cluster-autoscaler-role"

  assume_role_policy = jsonencode({
    Version = "2012-10-17",
    Statement = [
      {
        Effect = "Allow",
        Principal = {
          Federated = "arn:aws:iam::<id-da-conta-aws>:oidc-provider/oidc.eks.us-east-1.amazonaws.com/id/<iodc>"
         },
        Action = "sts:AssumeRoleWithWebIdentity",
        Condition = {
          StringEquals = {
            "oidc.eks.${var.region}.amazonaws.com/id/<iodc>:aud" = "sts.amazonaws.com"
            "oidc.eks.${var.region}.amazonaws.com/id/<iodc>:sub" = "system:serviceaccount:kube-system:cluster-autoscaler"
          }
        }
      },
    ],
  })
}

# Criar a service account
resource "kubernetes_service_account" "cluster_autoscaler" {
  metadata {
    name      = "cluster-autoscaler"
    namespace = "kube-system"
    annotations = {
      "eks.amazonaws.com/role-arn" = aws_iam_role.cluster_autoscaler.arn
    }
  }
}

# Atachar a policy na role
resource "aws_iam_role_policy_attachment" "cluster_autoscaler_policy_attachment" {
  policy_arn = aws_iam_policy.cluster_autoscaler_policy.arn  #"arn:aws:iam::${data.aws_caller_identity.current.account_id}:policy/ClusterAutoscalerPolicy"
  role       = aws_iam_role.cluster_autoscaler.name
}

# (Opcional) Se você estiver usando uma instância EC2 para executar o Cluster Autoscaler, crie um profile para a instância
resource "aws_iam_instance_profile" "cluster_autoscaler_instance_profile" {
  name = "ClusterAutoscalerInstanceProfile"
  role = aws_iam_role.cluster_autoscaler.name
}

Criamos uma IAM Policy chamada ClusterAutoscalerPolicy com as permissões necessárias para o Cluster Autoscaler funcionar.

Criamos uma IAM Role com as permissões necessárias para o OIDC Provider.
Criamos uma Service Account e "atachamos" a role criada.

Opcional, se você estiver usando uma instância EC2 para executar o Cluster Autoscaler, crie um instance profile.

Agora vamos configurar o Helm Chart, para isso crie um arquivo chamado cluster_autoscaler_chart.tf e cole o trecho de código abaixo:

resource "helm_release" "cluster_autoscaler" {
  name       = "cluster-autoscaler"
  repository = "https://kubernetes.github.io/autoscaler"
  chart      = "cluster-autoscaler"
  namespace  = "kube-system"
  timeout    = 300
  version = "9.34.1"

  values = [
    "${file("cluster_autoscaler_values.yaml")}"
  ]

  set {
    name  = "autoDiscovery.clusterName"
    value = data.aws_eks_cluster.cluster.name
  }

  set {
    name  = "awsRegion"
    value = var.region
  }

  set {
    name  = "rbac.serviceAccount.create"
    value = "false"
  }

  set {
    name  = "rbac.serviceAccount.name"
    value = "cluster-autoscaler"
  }

}

Para configurar o Cluster Autoscaler com opções avançadas do Helm chart, você pode ajustar vários parâmetros que controlam o comportamento do autoscaler.

O arquivo_ values.yaml_ permite configurar opções como escalonamento mínimo e máximo de Worker Nodes, controle de tolerâncias, métricas, intervalos de checagem, e muito mais.

Agora crie o arquivo cluster_autoscaler_values.yaml e cole o trecho abaixo.

Temos que ajustar alguns parâmetros:

clusterName - Inserir o nome do cluster EKS
awsRegion - Inserir a região da AWS

## Ref: https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity
# affinity -- Affinity for pod assignment
affinity: {}

# additionalLabels -- Labels to add to each object of the chart.
additionalLabels: {}

autoDiscovery:
  # cloudProviders `aws`, `gce`, `azure`, `magnum`, `clusterapi` and `oci` are supported by auto-discovery at this time
  # AWS: Set tags as described in https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md#auto-discovery-setup

  # autoDiscovery.clusterName -- Enable autodiscovery for `cloudProvider=aws`, for groups matching `autoDiscovery.tags`.
  # autoDiscovery.clusterName -- Enable autodiscovery for `cloudProvider=azure`, using tags defined in https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/azure/README.md#auto-discovery-setup.
  # Enable autodiscovery for `cloudProvider=clusterapi`, for groups matching `autoDiscovery.labels`.
  # Enable autodiscovery for `cloudProvider=gce`, but no MIG tagging required.
  # Enable autodiscovery for `cloudProvider=magnum`, for groups matching `autoDiscovery.roles`.
  clusterName: cluster-workshop

  # autoDiscovery.namespace -- Enable autodiscovery via cluster namespace for for `cloudProvider=clusterapi`
  namespace:  # default

  # autoDiscovery.tags -- ASG tags to match, run through `tpl`.
  tags:
    - k8s.io/cluster-autoscaler/enabled
    - k8s.io/cluster-autoscaler/{{ .Values.autoDiscovery.clusterName }}
  # - kubernetes.io/cluster/{{ .Values.autoDiscovery.clusterName }}

  # autoDiscovery.roles -- Magnum node group roles to match.
  roles:
    - worker

  # autoDiscovery.labels -- Cluster-API labels to match  https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/clusterapi/README.md#configuring-node-group-auto-discovery
  labels: []
    # - color: green
    # - shape: circle
# autoscalingGroups -- For AWS, Azure AKS or Magnum. At least one element is required if not using `autoDiscovery`. For example:
# <pre>
# - name: asg1<br />
#   maxSize: 2<br />
#   minSize: 1
# </pre>
# For Hetzner Cloud, the `instanceType` and `region` keys are also required.
# <pre>
# - name: mypool<br />
#   maxSize: 2<br />
#   minSize: 1<br />
#   instanceType: CPX21<br />
#   region: FSN1
# </pre>
autoscalingGroups: []
# - name: asg1
#   maxSize: 2
#   minSize: 1
# - name: asg2
#   maxSize: 2
#   minSize: 1

# autoscalingGroupsnamePrefix -- For GCE. At least one element is required if not using `autoDiscovery`. For example:
# <pre>
# - name: ig01<br />
#   maxSize: 10<br />
#   minSize: 0
# </pre>
autoscalingGroupsnamePrefix: []
# - name: ig01
#   maxSize: 10
#   minSize: 0
# - name: ig02
#   maxSize: 10
#   minSize: 0

# awsAccessKeyID -- AWS access key ID ([if AWS user keys used](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md#using-aws-credentials))
awsAccessKeyID: ""

# awsRegion -- AWS region (required if `cloudProvider=aws`)
awsRegion: us-east-1

# awsSecretAccessKey -- AWS access secret key ([if AWS user keys used](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md#using-aws-credentials))
awsSecretAccessKey: ""

# azureClientID -- Service Principal ClientID with contributor permission to Cluster and Node ResourceGroup.
# Required if `cloudProvider=azure`
azureClientID: ""

# azureClientSecret -- Service Principal ClientSecret with contributor permission to Cluster and Node ResourceGroup.
# Required if `cloudProvider=azure`
azureClientSecret: ""

# azureResourceGroup -- Azure resource group that the cluster is located.
# Required if `cloudProvider=azure`
azureResourceGroup: ""

# azureSubscriptionID -- Azure subscription where the resources are located.
# Required if `cloudProvider=azure`
azureSubscriptionID: ""

# azureTenantID -- Azure tenant where the resources are located.
# Required if `cloudProvider=azure`
azureTenantID: ""

# azureUseManagedIdentityExtension -- Whether to use Azure's managed identity extension for credentials. If using MSI, ensure subscription ID, resource group, and azure AKS cluster name are set. You can only use one authentication method at a time, either azureUseWorkloadIdentityExtension or azureUseManagedIdentityExtension should be set.
azureUseManagedIdentityExtension: false

# azureUseWorkloadIdentityExtension -- Whether to use Azure's workload identity extension for credentials. See the project here: https://github.com/Azure/azure-workload-identity for more details. You can only use one authentication method at a time, either azureUseWorkloadIdentityExtension or azureUseManagedIdentityExtension should be set.
azureUseWorkloadIdentityExtension: false

# azureVMType -- Azure VM type.
azureVMType: "vmss"

# azureEnableForceDelete -- Whether to force delete VMs or VMSS instances when scaling down.
azureEnableForceDelete: false

# cloudConfigPath -- Configuration file for cloud provider.
cloudConfigPath: ""

# cloudProvider -- The cloud provider where the autoscaler runs.
# Currently only `gce`, `aws`, `azure`, `magnum` and `clusterapi` are supported.
# `aws` supported for AWS. `gce` for GCE. `azure` for Azure AKS.
# `magnum` for OpenStack Magnum, `clusterapi` for Cluster API.
cloudProvider: aws

# clusterAPICloudConfigPath -- Path to kubeconfig for connecting to Cluster API Management Cluster, only used if `clusterAPIMode=kubeconfig-kubeconfig or incluster-kubeconfig`
clusterAPICloudConfigPath: /etc/kubernetes/mgmt-kubeconfig

# clusterAPIConfigMapsNamespace -- Namespace on the workload cluster to store Leader election and status configmaps
clusterAPIConfigMapsNamespace: ""

# clusterAPIKubeconfigSecret -- Secret containing kubeconfig for connecting to Cluster API managed workloadcluster
# Required if `cloudProvider=clusterapi` and `clusterAPIMode=kubeconfig-kubeconfig,kubeconfig-incluster or incluster-kubeconfig`
clusterAPIKubeconfigSecret: ""

# clusterAPIMode --  Cluster API mode, see https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/clusterapi/README.md#connecting-cluster-autoscaler-to-cluster-api-management-and-workload-clusters
# Syntax: workloadClusterMode-ManagementClusterMode
# for `kubeconfig-kubeconfig`, `incluster-kubeconfig` and `single-kubeconfig` you always must mount the external kubeconfig using either `extraVolumeSecrets` or `extraMounts` and `extraVolumes`
# if you dont set `clusterAPIKubeconfigSecret`and thus use an in-cluster config or want to use a non capi generated kubeconfig you must do so for the workload kubeconfig as well
clusterAPIMode: incluster-incluster  # incluster-incluster, incluster-kubeconfig, kubeconfig-incluster, kubeconfig-kubeconfig, single-kubeconfig

# clusterAPIWorkloadKubeconfigPath -- Path to kubeconfig for connecting to Cluster API managed workloadcluster, only used if `clusterAPIMode=kubeconfig-kubeconfig or kubeconfig-incluster`
clusterAPIWorkloadKubeconfigPath: /etc/kubernetes/value

# containerSecurityContext -- [Security context for container](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/)
containerSecurityContext: {}
  # capabilities:
  #   drop:
  #   - ALL

deployment:
  # deployment.annotations -- Annotations to add to the Deployment object.
  annotations: {}

# dnsPolicy -- Defaults to `ClusterFirst`. Valid values are:
# `ClusterFirstWithHostNet`, `ClusterFirst`, `Default` or `None`.
# If autoscaler does not depend on cluster DNS, recommended to set this to `Default`.
dnsPolicy: ClusterFirst

# envFromConfigMap -- ConfigMap name to use as envFrom.
envFromConfigMap: ""

# envFromSecret -- Secret name to use as envFrom.
envFromSecret: ""

## Priorities Expander
# expanderPriorities -- The expanderPriorities is used if `extraArgs.expander` contains `priority` and expanderPriorities is also set with the priorities.
# If `extraArgs.expander` contains `priority`, then expanderPriorities is used to define cluster-autoscaler-priority-expander priorities.
# See: https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/expander/priority/readme.md
expanderPriorities: {}

# extraArgs -- Additional container arguments.
# Refer to https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/FAQ.md#what-are-the-parameters-to-ca for the full list of cluster autoscaler
# parameters and their default values.
# Everything after the first _ will be ignored allowing the use of multi-string arguments.
extraArgs:
  logtostderr: true
  stderrthreshold: info
  v: 4
  # write-status-configmap: true
  # status-config-map-name: cluster-autoscaler-status
  # leader-elect: true
  # leader-elect-resource-lock: endpoints
  # skip-nodes-with-local-storage: true
  # expander: random
  # scale-down-enabled: true
  # balance-similar-node-groups: true
  # min-replica-count: 0
  # scale-down-utilization-threshold: 0.5
  # scale-down-non-empty-candidates-count: 30
  # max-node-provision-time: 15m0s
  # scan-interval: 10s
  # scale-down-delay-after-add: 10m
  # scale-down-delay-after-delete: 0s
  # scale-down-delay-after-failure: 3m
  # scale-down-unneeded-time: 10m
  # skip-nodes-with-system-pods: true
  # balancing-ignore-label_1: first-label-to-ignore
  # balancing-ignore-label_2: second-label-to-ignore

# extraEnv -- Additional container environment variables.
extraEnv: {}

# extraEnvConfigMaps -- Additional container environment variables from ConfigMaps.
extraEnvConfigMaps: {}

# extraEnvSecrets -- Additional container environment variables from Secrets.
extraEnvSecrets: {}

# extraVolumeMounts -- Additional volumes to mount.
extraVolumeMounts: []
  # - name: ssl-certs
  #   mountPath: /etc/ssl/certs/ca-certificates.crt
  #   readOnly: true

# extraVolumes -- Additional volumes.
extraVolumes: []
  # - name: ssl-certs
  #   hostPath:
  #     path: /etc/ssl/certs/ca-bundle.crt

# extraVolumeSecrets -- Additional volumes to mount from Secrets.
extraVolumeSecrets: {}
  # autoscaler-vol:
  #   mountPath: /data/autoscaler/
  # custom-vol:
  #   name: custom-secret
  #   mountPath: /data/custom/
  #   items:
  #     - key: subkey
  #       path: mypath

# fullnameOverride -- String to fully override `cluster-autoscaler.fullname` template.
fullnameOverride: ""

# hostNetwork -- Whether to expose network interfaces of the host machine to pods.
hostNetwork: false

image:
  # image.repository -- Image repository
  repository: registry.k8s.io/autoscaling/cluster-autoscaler
  # image.tag -- Image tag
  tag: v1.30.0
  # image.pullPolicy -- Image pull policy
  pullPolicy: IfNotPresent
  ## Optionally specify an array of imagePullSecrets.
  ## Secrets must be manually created in the namespace.
  ## ref: https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/
  ##
  # image.pullSecrets -- Image pull secrets
  pullSecrets: []
  # - myRegistrKeySecretName

# kubeTargetVersionOverride -- Allow overriding the `.Capabilities.KubeVersion.GitVersion` check. Useful for `helm template` commands.
kubeTargetVersionOverride: ""

# kwokConfigMapName -- configmap for configuring kwok provider
kwokConfigMapName: "kwok-provider-config"

# magnumCABundlePath -- Path to the host's CA bundle, from `ca-file` in the cloud-config file.
magnumCABundlePath: "/etc/kubernetes/ca-bundle.crt"

# magnumClusterName -- Cluster name or ID in Magnum.
# Required if `cloudProvider=magnum` and not setting `autoDiscovery.clusterName`.
magnumClusterName: ""

# nameOverride -- String to partially override `cluster-autoscaler.fullname` template (will maintain the release name)
nameOverride: ""

# nodeSelector -- Node labels for pod assignment. Ref: https://kubernetes.io/docs/user-guide/node-selection/.
nodeSelector: {}

# podAnnotations -- Annotations to add to each pod.
podAnnotations:
  cluster-autoscaler.kubernetes.io/safe-to-evict: "false"

# podDisruptionBudget -- Pod disruption budget.
podDisruptionBudget:
  maxUnavailable: 1
  # minAvailable: 2

# podLabels -- Labels to add to each pod.
podLabels: {}

# priorityClassName -- priorityClassName
priorityClassName: "system-cluster-critical"

# priorityConfigMapAnnotations -- Annotations to add to `cluster-autoscaler-priority-expander` ConfigMap.
priorityConfigMapAnnotations: {}
  # key1: "value1"
  # key2: "value2"

## Custom PrometheusRule to be defined
## The value is evaluated as a template, so, for example, the value can depend on .Release or .Chart
## ref: https://github.com/coreos/prometheus-operator#customresourcedefinitions
prometheusRule:
  # prometheusRule.enabled -- If true, creates a Prometheus Operator PrometheusRule.
  enabled: false
  # prometheusRule.additionalLabels -- Additional labels to be set in metadata.
  additionalLabels: {}
  # prometheusRule.namespace -- Namespace which Prometheus is running in.
  namespace: monitoring
  # prometheusRule.interval -- How often rules in the group are evaluated (falls back to `global.evaluation_interval` if not set).
  interval: null
  # prometheusRule.rules -- Rules spec template (see https://github.com/prometheus-operator/prometheus-operator/blob/master/Documentation/api.md#rule).
  rules: []

rbac:
  # rbac.create -- If `true`, create and use RBAC resources.
  create: true
  # rbac.pspEnabled -- If `true`, creates and uses RBAC resources required in the cluster with [Pod Security Policies](https://kubernetes.io/docs/concepts/policy/pod-security-policy/) enabled.
  # Must be used with `rbac.create` set to `true`.
  pspEnabled: false
  # rbac.clusterScoped -- if set to false will only provision RBAC to alter resources in the current namespace. Most useful for Cluster-API
  clusterScoped: true
  serviceAccount:
    # rbac.serviceAccount.annotations -- Additional Service Account annotations.
    annotations: {}
    # rbac.serviceAccount.create -- If `true` and `rbac.create` is also true, a Service Account will be created.
    create: true
    # rbac.serviceAccount.name -- The name of the ServiceAccount to use. If not set and create is `true`, a name is generated using the fullname template.
    name: ""
    # rbac.serviceAccount.automountServiceAccountToken -- Automount API credentials for a Service Account.
    automountServiceAccountToken: true

# replicaCount -- Desired number of pods
replicaCount: 1

# resources -- Pod resource requests and limits.
resources: {}
  # limits:
  #   cpu: 100m
  #   memory: 300Mi
  # requests:
  #   cpu: 100m
  #   memory: 300Mi

# revisionHistoryLimit -- The number of revisions to keep.
revisionHistoryLimit: 10

# securityContext -- [Security context for pod](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/)
securityContext: {}
  # runAsNonRoot: true
  # runAsUser: 1001
  # runAsGroup: 1001

service:
  # service.create -- If `true`, a Service will be created.
  create: true
  # service.annotations -- Annotations to add to service
  annotations: {}
  # service.labels -- Labels to add to service
  labels: {}
  # service.externalIPs -- List of IP addresses at which the service is available. Ref: https://kubernetes.io/docs/user-guide/services/#external-ips.
  externalIPs: []

  # service.loadBalancerIP -- IP address to assign to load balancer (if supported).
  loadBalancerIP: ""
  # service.loadBalancerSourceRanges -- List of IP CIDRs allowed access to load balancer (if supported).
  loadBalancerSourceRanges: []
  # service.servicePort -- Service port to expose.
  servicePort: 8085
  # service.portName -- Name for service port.
  portName: http
  # service.type -- Type of service to create.
  type: ClusterIP

## Are you using Prometheus Operator?
serviceMonitor:
  # serviceMonitor.enabled -- If true, creates a Prometheus Operator ServiceMonitor.
  enabled: false
  # serviceMonitor.interval -- Interval that Prometheus scrapes Cluster Autoscaler metrics.
  interval: 10s
  # serviceMonitor.namespace -- Namespace which Prometheus is running in.
  namespace: monitoring
  ## [Prometheus Selector Label](https://github.com/helm/charts/tree/master/stable/prometheus-operator#prometheus-operator-1)
  ## [Kube Prometheus Selector Label](https://github.com/helm/charts/tree/master/stable/prometheus-operator#exporters)
  # serviceMonitor.selector -- Default to kube-prometheus install (CoreOS recommended), but should be set according to Prometheus install.
  selector:
    release: prometheus-operator
  # serviceMonitor.path -- The path to scrape for metrics; autoscaler exposes `/metrics` (this is standard)
  path: /metrics
  # serviceMonitor.annotations -- Annotations to add to service monitor
  annotations: {}
  ## [RelabelConfig](https://github.com/prometheus-operator/prometheus-operator/blob/main/Documentation/api.md#monitoring.coreos.com/v1.RelabelConfig)
  # serviceMonitor.metricRelabelings -- MetricRelabelConfigs to apply to samples before ingestion.
  metricRelabelings: {}

# tolerations -- List of node taints to tolerate (requires Kubernetes >= 1.6).
tolerations: []

# topologySpreadConstraints -- You can use topology spread constraints to control how Pods are spread across your cluster among failure-domains such as regions, zones, nodes, and other user-defined topology domains. (requires Kubernetes >= 1.19).
topologySpreadConstraints: []
  # - maxSkew: 1
  #   topologyKey: topology.kubernetes.io/zone
  #   whenUnsatisfiable: DoNotSchedule
  #   labelSelector:
  #     matchLabels:
  #       app.kubernetes.io/instance: cluster-autoscaler

# updateStrategy -- [Deployment update strategy](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#strategy)
updateStrategy: {}
  # rollingUpdate:
  #   maxSurge: 1
  #   maxUnavailable: 0
  # type: RollingUpdate

# vpa -- Configure a VerticalPodAutoscaler for the cluster-autoscaler Deployment.
vpa:
  # vpa.enabled -- If true, creates a VerticalPodAutoscaler.
  enabled: false
  # vpa.updateMode -- [UpdateMode](https://github.com/kubernetes/autoscaler/blob/vertical-pod-autoscaler/v0.13.0/vertical-pod-autoscaler/pkg/apis/autoscaling.k8s.io/v1/types.go#L124)
  updateMode: "Auto"
  # vpa.containerPolicy -- [ContainerResourcePolicy](https://github.com/kubernetes/autoscaler/blob/vertical-pod-autoscaler/v0.13.0/vertical-pod-autoscaler/pkg/apis/autoscaling.k8s.io/v1/types.go#L159). The containerName is always et to the deployment's container name. This value is required if VPA is enabled.
  containerPolicy: {}

# secretKeyRefNameOverride -- Overrides the name of the Secret to use when loading the secretKeyRef for AWS and Azure env variables
secretKeyRefNameOverride: ""

Algumas configurações que podem ser personalizadas no arquivo de values:

autoDiscovery: Configura o nome do cluster para descoberta automática de grupos de Auto Scaling.
extraArgs: Define argumentos adicionais para o Cluster Autoscaler, como políticas de escalonamento e thresholds.
rbac: Configura a conta de serviço e as permissões RBAC.
image: Define a versão da imagem do Cluster Autoscaler.
resources: Especifica os recursos solicitados e limites para o pod do Cluster Autoscaler.
nodeSelector, tolerations, affinity: Configurações para especificar onde os pods do Cluster Autoscaler podem ser agendados.
replicaCount: Define o número de réplicas do Cluster Autoscaler.
podAnnotations: Adiciona anotações ao pod do Cluster Autoscaler.

Após criar todos os arquivos acima, vamos aplica-lo´s com o Terraform executando o comando abaixo:

terraform apply --auto-approve

Acompanhe os logs do Cluster Autoscaler para avaliar se o deploy ocorreu com sucesso.

kubectl -n kube-system logs -f deployment/cluster-autoscaler-aws-cluster-autoscaler

Caso esteja tudo certo o Cluster Autoscaler está operacional e pronto para testes de escalonamento.

Teste o escalonamento automático

Vamos iniciar os teste o escalonamento automático para isso vamos obter algumas informações, criar alguns recursos e acompanhar os resultados.

Observe a quantidade de Worker Nodes atuais com o comando abaixo:

kubectl get nodes

Observe que nesse momento temos somente 1 Worker Node disponível.

Vamos criar um deployment para os testes de stress.

Crie um arquivo com o nome de cpu-stress-deployment.yaml e cole o código abaixo:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: cpu-stress
spec:
  replicas: 5
  selector:
    matchLabels:
      app: cpu-stress
  template:
    metadata:
      labels:
        app: cpu-stress
    spec:
      containers:
      - name: cpu-stress
        image: vish/stress
        resources:
          requests:
            cpu: "1"
        args:
        - -cpus
        - "1"

Aplique o deployment com o comando:

kubectl apply -f cpu-stress-deployment.yaml

Observe o comportamento do Cluster Autoscaler, que deve aumentar o número de Worker Nodes para acomodar o workload adicional.

Acopanhe os logs do Cluster Autoscaler.

kubectl -n kube-system logs -f deployment/cluster-autoscaler-aws-cluster-autoscaler

Acompanhe os Worker Nodes escalando e nota-se que ele escalou vários Worker Nodes para acomodar o novo workload.

kubectl get nodes

Vamos simular a redução do workload excedente, voltando o ambiente normal.

Vamos zerar a quantidade de pods no deployment e acompanhe os Worker Nodes sendo desprovisionados da infraestrutura e voltando ao seu estado original.

Conclusão

Usar Terraform e Helm para configurar um cluster EKS e o Cluster Autoscaler proporciona uma solução robusta e automatizada para gerenciar a escalabilidade dos clusters Kubernetes.
Este artigo detalhado fornece os passos necessários para implementar e gerenciar o escalonamento automático, garantindo que os recursos sejam utilizados de forma eficiente e econômica.
Com estas ferramentas, você pode otimizar os custos e melhorar o desempenho das suas aplicações em um ambiente Kubernetes gerenciado pela AWS.

Implementando aplicações altamente escaláveis com Amazon EKS e Karpenter utilizando Terraform.

Rodrigo Fernandes — Mon, 25 Mar 2024 21:16:08 +0000

Introdução

A automação e escalabilidade são elementos cruciais na gestão de infraestrutura em ambientes de nuvem, especialmente quando se trata de clusters Kubernetes. Neste artigo, exploraremos o processo técnico de implantação do Karpenter, uma ferramenta de escalonamento automático para Kubernetes, usando Terraform em um cluster Amazon EKS na AWS.

O papel do Karpenter na escalabilidade

O Karpenter utiliza métricas de uso de recursos e políticas de escalonamento para provisionar automaticamente e de forma otimizada novos nós de computação quando necessário, garantindo que as aplicações tenham recursos suficientes para lidar com as demandas.

Desafios e Soluções

Implementar manualmente políticas de escalonamento automático pode ser complexo e propenso a erros. O uso do Terraform simplifica esse processo, permitindo a definição da infraestrutura como código (IaC) e garantindo a consistência e repetibilidade nas implantações.

Benefícios desta Abordagem

Ao adotar essa abordagem, você automatiza a implantação e o gerenciamento do Karpenter em um ambiente Kubernetes na AWS, garantindo uma infraestrutura escalável, confiável e consistente.

O que é Karpenter

Karpenter é um sistema de autoescalonamento ele foi projetado para automatizar o dimensionamento de recursos em ambientes baseados em Kubernetes.

O objetivo principal é otimizar o uso de recursos, garantindo que os aplicativos tenham a capacidade necessária para atender à demanda, ao mesmo tempo em que evita o desperdício de recursos quando a demanda diminui.

O Karpenter é uma ferramenta útil para equipes que gerenciam clusters em Kubernetes, pois elimina a necessidade de ajustes manuais no dimensionamento dos recursos.

Ele monitora a utilização dos recursos e toma decisões automatizadas com base nas métricas e políticas configuradas pelos usuários.

Isso ajuda a garantir um desempenho eficiente e econômico dos aplicativos implantados em ambientes Kubernetes.

Mais informações sobre o Karpenter acesse a pagina oficial clicando aqui.

Como funciona

O Karpenter funciona como um controlador personalizado para Kubernetes. Ele estende as capacidades padrão do Kubernetes, permitindo um autoescalonamento mais inteligente e eficiente.

Abaixo uma visão geral de como o Karpenter opera:

Monitoramento de métricas
Monitora constantemente métricas como uso de CPU, memória, e outras métricas relevantes dos pods e dos nós do cluster Kubernetes. Pode se integrar a sistemas de monitoramento como Prometheus para coletar essas métricas.

Análise de métricas e demanda
Com base nas métricas coletadas, o Karpenter analisa a demanda atual dos recursos pelo cluster, identificando padrões de uso e tendências.

Políticas de autoescalonamento
Os usuários podem definir políticas de autoescalonamento que especificam como o Karpenter deve ajustar a quantidade de recursos disponíveis no cluster. Isso inclui especificar limites mínimos e máximos para o número de pods e nós, bem como configurar estratégias de alocação de recursos.

Decisões de escalonamento
Com base nas métricas coletadas e nas políticas definidas, o Karpenter toma decisões automatizadas sobre a criação, destruição ou dimensionamento de pods e nós no cluster Kubernetes. Ele pode escalar para cima (aumentando o número de pods ou nós) ou para baixo (reduzindo o número de pods ou nós) conforme necessário para atender à demanda.

Alocação inteligente de recursos
Ele realiza uma alocação inteligente de recursos, distribuindo os pods de maneira eficiente nos nós disponíveis, levando em consideração as políticas de balanceamento de carga e os requisitos de recursos de cada pod.

Em resumo
O Karpenter automatiza o processo de escalonamento de recursos em clusters Kubernetes, garantindo que os aplicativos tenham a capacidade necessária para lidar com a demanda atual, ao mesmo tempo em que otimiza a utilização dos recursos disponíveis e evita o desperdício.

Isso simplifica a operação e a gestão de ambientes Kubernetes, melhorando a eficiência e o desempenho dos aplicativos implantados.

Alguns pontos importantes

Provisione Worker Nodes com base nos requisitos de Workload.
Crie diversas configurações de Worker Nodes por tipo de instância, usando opções flexíveis de NodePool. Em vez de gerenciar muitos Worker Nodes Groups personalizados específicos, o Karpenter pode permitir que você gerencie diversas capacidades de carga de trabalho com um NodePool único e flexível.
Obtenha um melhor agendamento de pods em escala, iniciando rapidamente Worker Nodes e agendando pods.

Alguns conceitos importantes

AWS NodeTemplate

No contexto do Karpenter se refere a uma funcionalidade específica dessa ferramenta de autoescalonamento para ambientes Kubernetes na AWS.

O AWS NodeTemplate permite definir configurações detalhadas para instâncias Worker Nodes no AWS EKS, incluindo o tipo de instância, capacidade de CPU, capacidade de memória, sistema operacional, configurações de rede, volumes anexados e outras opções. Essas configurações são essenciais para a criação de novos Worker Nodes no cluster Kubernetes da AWS de acordo com as necessidades específicas de cada aplicativo.

SubnetSelector

É uma funcionalidade que permite aos usuários selecionar sub-redes específicas dentro de uma VPC para implantar instâncias de Worker Nodes quando estão utilizando o Karpenter em conjunto com o Amazon EKS.

SecurityGroupSelector

É uma funcionalidade que permite aos usuários selecionar Security Groups específicos da AWS para Worker Nodes que estão sendo implantadas em um cluster Kubernetes gerenciado pelo Karpenter, especialmente quando utilizado em conjunto com o Amazon EKS.

Essa funcionalidade é útil por várias razões:

Segurança: Permite implementar políticas de segurança granulares, garantindo que as instâncias de Worker Nodes sejam associadas aos grupos de segurança adequados com as regras de firewall corretas.

Conformidade: Facilita a conformidade com padrões e regulamentos de segurança, pois você pode garantir que apenas as instâncias de Worker Nodes apropriadas tenham acesso aos recursos de rede necessários.

Isolamento: Ajuda a isolar o tráfego de rede entre diferentes componentes do seu ambiente Kubernetes na AWS, aumentando a segurança e reduzindo riscos.

Best practices

Exclua tipos de instância que não se adequam à sua carga de trabalho
Considere excluir tipos de instâncias específicas com a chave node.kubernetes.io/instance-type se elas não forem exigidas pelas cargas de trabalho em execução no seu cluster.

O exemplo a seguir mostra como evitar o provisionamento de grandes instâncias Graviton.

key: node.kubernetes.io/instance-type operator: NotIn values:
- m6g.16xlarge
- m6gd.16xlarge
- r6g.16xlarge
- r6gd.16xlarge
- c6g.16xlarge

Habilite o tratamento de interrupções ao usar o Spot
Karpenter suporta tratamento de interrupção nativo , habilitado através do --interruption-queue-nameargumento CLI com o nome da fila SQS. O tratamento de interrupções monitora eventos futuros de interrupção involuntária que causariam interrupção em suas cargas de trabalho, como:

Avisos de interrupção pontual
Eventos de integridade de alteração agendados (eventos de manutenção)
Eventos de encerramento de instância
Eventos de interrupção de instância
Quando o Karpenter detecta que um desses eventos ocorrerá em seus Worker Nodes, ele automaticamente isola, drena e encerra os Worker Nodes antes do evento de interrupção para fornecer o tempo máximo para limpeza da carga de trabalho antes da interrupção

Criando NodePools
As práticas recomendadas a seguir abrangem tópicos relacionados à criação de NodePools.

Crie vários NodePools quando...
Quando diferentes equipes estão compartilhando um cluster e precisam executar suas cargas de trabalho em diferentes Worker Nodes de trabalho ou têm diferentes requisitos de sistema operacional ou de tipo de instância, crie vários NodePools. Por exemplo, uma equipe pode querer usar o Bottlerocket, enquanto outra pode querer usar o Amazon Linux. Da mesma forma, uma equipe pode ter acesso a hardware de GPU caro que não seria necessário para outra equipe. O uso de vários NodePools garante que os ativos mais apropriados estejam disponíveis para cada equipe.

Crie NodePools que sejam mutuamente exclusivos ou ponderados
Recomenda-se criar NodePools que sejam mutuamente exclusivos ou ponderados para fornecer um comportamento de agendamento consistente. Se não forem e vários NodePools corresponderem, o Karpenter escolherá aleatoriamente qual usar, causando resultados inesperados.

Use temporizadores (TTL) para excluir automaticamente Worker Nodes do cluster
É possível usar temporizadores em Worker Nodes provisionados para definir quando excluir Worker Nodes que estão desprovidos de pods de carga de trabalho ou que atingiram um tempo de expiração. A expiração do nó pode ser usada como meio de atualização, para que os Worker Nodes sejam retirados e substituídos por versões atualizadas. Consulte Expiração na documentação do Karpenter para obter informações sobre como spec.disruption.expireAfterconfigurar a expiração do nó.

Criando o ambiente do cluster EKS

Para criar um ambiente com um cluster EKS para nossos testes, iremos utilizar o repositório que está disponivel nesse link.

EKS Blueprint
O código fonte do repositório acima é baseado nos Blueprints que são forneceidos pela AWS.
A AWS disponibiliza diversos templates prontos, os chamados Blueprints. Eles abstraem as complexidades da infraestrutura permitindo que seja implantado cargas de trabalhado de forma simples e replicavel.
Segue o link dos vários modelos de Blueprint que pode ser acessado clicando aqui.

Clone do repositório

git clone https://github.com/rodrigofrs13/workshop-aws-eks-karpenter

Acesse o diretório /workshop-aws-eks-karpenter/enviroment

Editando as variaveis
Edite o arquivo arquivo terraform.tfvars com as variaveis que podem ser ajustadas antes de iniciar a instalação, como por exemplo:

- Região AWS
- Nome do cluster EKS
- Versão do cluster EKS
- Versão dos Addons
- Nome da Role Admin

Setup do ambiente
Com o comando abaixo vamos iniciar o Terraform, criar o Plan e efeturar o setup.

terraform init && terraform plan && terraform apply --auto-approve

Acesse o diretório /workshop-aws-eks-karpenter/eks-blue

Editando as variaveis
Edite o arquivo arquivo terraform.tfvars com as variaveis que podem ser ajustadas antes de iniciar a instalação, como por exemplo:

- Região AWS
- Nome do cluster EKS
- Versão do cluster EKS
- Versão dos Addons
- Nome da Role Admin

Setup do ambiente
Com o comando abaixo vamos iniciar o Terraform, criar o Plan e efeturar o setup.

terraform init && terraform plan && terraform apply --auto-approve

Acessando o Cluster

Vamos acessar o cluster EKS com seguinte comando para configurar o kubectl para apontar para o cluster desejado:

$ aws eks --region <region> update-kubeconfig --name <cluster-name>

Caso tenha perdido o output, utilize o comando terraform output.

Vamos fazer alguns testes iniciais para verificar se está tudo certo com nosso cluster.

Coletando algumas informações.

kubectl cluster-info

Verificando os Worker Nodes

kubectl get nodes -o wide

Analisando todos os recursos criados

kubectl get all -A

Com isso podemos concluir que nosso cluster está funcionando corretamente e estamos prontos para a próxima etapa, o Karpenter.

Validando o Karpenter

Como utilizamos um Blueprint da AWS, o Karpenter já está instalado e configurado em nosso cluster.

Vamos fazer algumas validações para confirmar se está tudo certo com o Karpenter.

Validando os pods.

kubectl get pods -n karpenter

Validando o Provisioner

kubectl get provisioner

Com isso o Karpenter está instalado e executando com sucesso.

Vamos criar um NodePool com algumas regras para começarmos a utilizar o Karpenter e escalar de forma inteligente o nosso ambiente.

Como estamos utilizando os Blueprints já temos a parte GitOps e CICD configurados. Em nosso estudo de caso vamos utilizar uma parte dessas ferramentas.

O repositório que pode ser acessado por esse link é um Fork de um blueprint que iremos utilizar.
Faça o clone do repositório com o comando git clone https://github.com/rodrigofrs13/eks-blueprints-workloads.git

No deployment da app temos o NodeSelector que indica que todos os pods daquele deployment serão deployados nos Worker Nodes do Karpenter.

Iremos utilizar o Team Riker para nossos testes, acesse arquivo do Karpenter que está nesse caminho: teams/team-riker/dev/templates/karpenter.yaml.

Vamos configurar o nosso AWSNodeTemplate e Provisioner para definir algumas configurações para o Karpenter.

Segue abaixo um exemplo do nosso NodePool



{{ if .Values.spec.karpenterInstanceProfile }}
apiVersion: karpenter.k8s.aws/v1alpha1
kind: AWSNodeTemplate
metadata:
  name: karpenter-default
  labels:
    {{- toYaml .Values.labels | nindent 4 }}  
spec:
  instanceProfile: '{{ .Values.spec.karpenterInstanceProfile }}'
  subnetSelector:
    kubernetes.io/cluster/{{ .Values.spec.clusterName }}: '*'
    kubernetes.io/role/internal-elb: '1' # to select only private subnets
  securityGroupSelector:
    aws:eks:cluster-name: '{{ .Values.spec.clusterName }}' # Choose only security groups of nodes
  tags:
    karpenter.sh/cluster_name: {{.Values.spec.clusterName}}
    karpenter.sh/provisioner: default
  metadataOptions:
    httpEndpoint: enabled
    httpProtocolIPv6: disabled
    httpPutResponseHopLimit: 2
    httpTokens: required
---
apiVersion: karpenter.sh/v1alpha5
kind: Provisioner
metadata:
  name: default
  labels:
    {{- toYaml .Values.labels | nindent 4 }}
spec:
  consolidation:
    enabled: true
  #ttlSecondsAfterEmpty: 60 # mutual exclusive with consolitation
  requirements:
    - key: "karpenter.k8s.aws/instance-category"
      operator: In
      values: ["c", "m"]
    - key: karpenter.k8s.aws/instance-cpu
      operator: Lt
      values:
        - '33'    
    - key: 'kubernetes.io/arch'
      operator: In
      values: ['amd64']
    - key: karpenter.sh/capacity-type
      operator: In
      values: ['on-demand']
    - key: kubernetes.io/os
      operator: In
      values:
        - linux
  providerRef:
    name: karpenter-default

  ttlSecondsUntilExpired: 2592000 # 30 Days = 60 * 60 * 24 * 30 Seconds;

  # Priority given to the provisioner when the scheduler considers which provisioner
  # to select. Higher weights indicate higher priority when comparing provisioners.
  # Specifying no weight is equivalent to specifying a weight of 0.
  weight: 1
  limits:
    resources:
      cpu: '2k'
  labels:
    billing-team: default
    team: default
    type: karpenter

  # Do we want to apply some taints on the nodes ?  
  # taints:
  #   - key: karpenter
  #     value: 'true'
  #     effect: NoSchedule

  # Karpenter provides the ability to specify a few additional Kubelet args.
  # These are all optional and provide support for additional customization and use cases.
  kubeletConfiguration:
    containerRuntime: containerd
    maxPods: 110     
    systemReserved:
      cpu: '1'
      memory: 5Gi
      ephemeral-storage: 2Gi
{{ end }}

Alguns itens que foram defidos

Labels
Definimos labels dedicados que podem ser usados por pods como nodeSelectors.

Taints
Podemos adicionar taints aos Worker Nodes para que as cargas de trabalho precisem tolerar que esses taints sejam agendados nos Worker Nodes do Karpenter.

Especificamos alguns requisitos em torno de tipos de instâncias, capacidade e arquitetura; cada provisionador é altamente personalizável.

Após os ajustes vamos fazer o commit e o push

git add teams/team-riker/dev/templates/karpenter.yaml git commit -m "Add Karpenter provisioner" git push

Podemos verificar com o eks-node-view(para saber mais clique aqui) abaixo e já podemos ver que alguns Worker Nodes do Karpenter já foram provisionados, cada um em uma AZ por conta das configurações que fizemos.

O próximo passo é aumentar o nosso Workload para que o Karpenter começe a dimencionar os Worker Nodes.

Vamos escalar a app skiapp-deployment do Team Riker com o comando abaixo:

> kubectl scale deployment -n team-riker skiapp-deployment --replicas 30

Podemos notar que o Karpenter começa a escalar os novos Worker Nodes conforme os requirimentos baseando sempre na menor instância.

Em um primerio momento o Karpenter adcionou 3 novos Worker Nodes (Atendendo o requisito de Multi-AZ) menores para suportar o aumento do Workload.

No segundo momento o Karpenter adcionou 3 novos Worker Nodes (Atendendo o requisito de Multi-AZ) menores para suportar o aumento do Workload.

Vamos escalar a app skiapp-deployment do Team Riker com o comando abaixo para simular um consumo alto de WorkLoad

kubectl scale deployment -n team-riker skiapp-deployment --replicas 100

Podemos notar em um primeiro momento que o Karpenter adcionou novas instancias.

Em um segundo momento o Karpenter alterou o tipo de instancia para melhorar a eficiencia do ambiente.

O Karpenter sempre tenta infinitamente economizar custos em seu cluster.

Removendo o ambiente

Vamos dismobilizar a infra reduzindo o Workload para 1

kubectl scale deployment -n team-riker skiapp-deployment --replicas 1

Removendo o cluster
Acesse o diretório /workshop-aws-eks-karpenter/enviroment

terraform destroy--auto-approve

Após a conclusão, acesse o diretório /workshop-aws-eks-karpenter/eks-blue e execute o comando abaixo

terraform destroy--auto-approve

Conclusão

Agora temos a capacidade de adicionar mais capacidade ao nosso cluster para dimensionar nosso Workload e o Karpenter garante um equilíbrio entre instâncias e custos de forma inteligente.

Referências

https://aws.github.io/aws-eks-best-practices/karpenter/

AWS Artifact

Rodrigo Fernandes — Fri, 19 May 2023 14:35:17 +0000

Anotações sobre AWS Artifact para ajudar na preparação das certificações AWS.

Até o momento as anotações são para as certificações abaixo:

Anotações gerais

Acesso aos relatórios emitidos pelo auditor da AWS
ISO 9001:2015 Certification
HIPPA
PCI - Payment Card Industry (PCI - Setor de cartões de pagamento)
SOC - Service Organization Control (SOC - Controle de organização de serviço)
Não é um serviço AWS
Tem que ter permissões para acessar os relatórios

Identity and access management in AWS Artifact

Documentação oficial

Exemplo policy que libera todos os relatórios

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "artifact:Get"
            ],
            "Resource": [
                "arn:aws:artifact:::report-package/*"
            ]
        }
    ]
}

Exemplo policy que libera os relatórios de SOC, PCI e ISO

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "artifact:Get"
            ],
            "Resource": [
                "arn:aws:artifact:::report-package/Certifications and Attestations/SOC/*",
                "arn:aws:artifact:::report-package/Certifications and Attestations/PCI/*",
                "arn:aws:artifact:::report-package/Certifications and Attestations/ISO/*"
            ]
        }
    ]
}

PCI DSS

Documentação oficial

Amazon Route53

Rodrigo Fernandes — Fri, 19 May 2023 14:35:04 +0000

Anotações sobre o Amazon Route53 para ajudar na preparação das certificações AWS.

Até o momento as anotações são para as certificações abaixo:

Anotações gerais

Serviço de DNS
Envia logs para CloudWatch Logs
Tem que adicionar a VPC na Query dos Logs

Public DNS query logging

Documentação oficial

Logs recebidos

Domínio ou subdomínio que foi solicitado
Data e hora do pedido
Tipo de registro DNS (como A ou AAAA)
Edge Location do Route 53 que respondeu à consulta DNS
Código de resposta DNS, como NoErrorou ServFail

Os Logs podem ser enviados para

CloudWatch Logs
Bucket S3
Kinesis Data Firehose

Referências

AWS Network Firewall

Rodrigo Fernandes — Fri, 19 May 2023 14:34:48 +0000

Anotações sobre o AWS Network Firewall para ajudar na preparação das certificações AWS.

Até o momento as anotações são para as certificações abaixo:

Definição do fornecedor

O AWS Network Firewall é um serviço gerenciado que facilita a implantação de proteções básicas de rede para todas as suas Amazon Virtual Private Clouds (VPCs).

Anotações gerais

Sempre associado a uma VPC
Statefull/Stateless Firewall
Sistema de prevenção de intrusões (IPS)
Não protege contra DDoS
Gerencia liberação ou bloqueio de URL´s
HTTP/HTTPS
Pode importar regras da Suricata
Não é capaz de permitir que EC2 em uma sub-rede privada se conectem à Internet enquanto impede conexões externas.

Delete protection

Protege o firewall contra exclusão. Use esta configuração para proteger contra a exclusão acidental de um firewall que está em uso.

Veem habilitado por padrão

Subnet change protection

Protege o firewall contra alterações nas associações de sub-rede. Use essa configuração para proteger contra a modificação acidental das associações de sub-rede de um firewall que está em uso.

Veem habilitado por padrão

Network Firewall Policy

Adiciona múltiplos Role Groups e outras configurações

Network Firewall Role Group

Statefull ou Stateless
Cria as regras de bloqueio na VPC
Pode inserir domínios como "facebook.com"
Pode inserir ip´s diretos como "8.8.8.8"
Pode bloquear por protocolo (HTTP, HTTPs, ICMP)

AWS Firewall Manager

Rodrigo Fernandes — Fri, 19 May 2023 14:34:32 +0000

Anotações sobre o AWS Firewall Manager para ajudar na preparação das certificações AWS.

Até o momento as anotações são para as certificações abaixo:

Definição do fornecedor

O AWS Firewall Manager é um serviço de gerenciamento de segurança que permite a configuração e o gerenciamento centralizados de regras do firewall entre todas as contas e aplicações no AWS Organizations.

Anotações gerais

Pré requisito -> AWS Organizations e AWS Config
Alto custo
Simplifica as tarefas de administração e manutenção de grupos de segurança AWS WAF, AWS Shield Advanced e Amazon VPC em várias contas e recursos.

Serviços suportados

AWS WAF
Security Groups
AWS Network Firewall
Route53 DNS Firewall
AWS Shield Advanced
Palo Alto Cloud Next-generation Firewalls

Referências

AWS Organizations

Rodrigo Fernandes — Fri, 19 May 2023 14:34:16 +0000

Anotações sobre o AWS Organizations para ajudar na preparação das certificações AWS.

Até o momento as anotações são para as certificações abaixo:

Definição do fornecedor

O AWS Organizations ajuda você a gerenciar e controlar seu ambiente de maneira centralizada à medida que os negócios e seus recursos da AWS expandem.
Usando o AWS Organizations, você pode criar novas contas da AWS e alocar recursos, agrupar contas para organizar seus fluxos de trabalho, aplicar políticas a contas ou grupos para governança e simplificar o faturamento usando um único método de pagamento para todas as suas contas.

Anotações gerais

Global Service
Para automatizar a criação de AWS Accounts
Gerenciamento centralizado de todas as contas
Agrupamento - OU
Controle de serviços/API por conta
Habilita CloudTrail em todas as contas para enviar os Log´s para um Bucket S3 central
Envia todos os CloudWatch Logs para uma conta central
Para remover uma conta, a conta AWS deve ser capaz de operar como uma conta autônoma. Só então ele pode ser removido das organizações AWS

Consolidated Billing

Documentação oficial

Descontos
Volume
Reserved Instances
Só recebe os descontos se as EC2 estiverem na mesma AZ
Saving Plans
Uma invoice

Service Control Polices (SCP)

Documentação oficial

Política da organização que você pode usar para gerenciar permissões em sua organização.
Um SCP abrange todos os usuários, grupos e funções do IAM, incluindo o usuário raiz da conta da AWS.
Whitelist e Black List
Apply OU ou Account level
Não é aplicado na conta Master
Aplica em todos os usuários e roles, incluindo o root
Deve ter a permissão Explicito

Organizational unit (OU)

Documentação oficial

Uma maneira mais fácil de controlar o acesso aos recursos da AWS usando a organização AWS dos principais IAM

Documentação oficial

Para alguns serviços, você concede permissões usando resource-based policies para especificar as contas e principais que podem acessar o recurso e quais ações podem executar nele.

aws:PrincipalOrgID - nessas políticas para exigir que todos os principais que acessam o recurso sejam de uma conta (incluindo a conta mestra) na organização.

Exemplo

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowGetObject",
            "Effect": "Allow",
            "Principal": {
                "AWS":[
                        "arn:aws:iam::094697565664:user/Casey",
                        "arn:aws:iam::094697565664:user/David",
                        "arn:aws:iam::094697565664:user/Tom",
                        "arn:aws:iam::094697565664:user/Michael",
                        "arn:aws:iam::094697565664:user/Brenda",
                        "arn:aws:iam::094697565664:user/Lisa",
                        "arn:aws:iam::094697565664:user/Norman",
                        "arn:aws:iam::094697565646:user/Steve",
                        "arn:aws:iam::087695765465:user/Douglas",
                        "arn:aws:iam::087695765465:user/Michelle"
]
},
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::2018-Financial-Data/*",
**            "Condition": {"StringEquals": 
                             {"aws:PrincipalOrgID": [ "o-yyyyyyyyyy" ]}
                         }**
        }
    ]
}