Auto Scaling y GitOps

Kubernetes puede escalar tu aplicacion automaticamente segun la demanda. Los mecanismos principales son:

• HPA (Horizontal Pod Autoscaler): Aumenta o reduce el numero de pods basandose en CPU, memoria u otras metricas. Es el mas comun. • VPA (Vertical Pod Autoscaler): Ajusta los recursos (CPU/memoria) de cada pod sin cambiar el numero de replicas. Util para workloads impredecibles. • Cluster Autoscaler: Agrega o elimina nodos del cluster cuando no hay capacidad para nuevos pods (o hay nodos sobrantes).

Orden de escala tipico: 1. HPA escala pods horizontalmente 2. Si no hay nodos con capacidad, Cluster Autoscaler agrega nodos 3. VPA ajusta recursos de pods individuales

# hpa.yaml — Horizontal Pod Autoscaler
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: mi-app-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: mi-app
  minReplicas: 2
  maxReplicas: 10
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70  # escala si CPU > 70%
    - type: Resource
      resource:
        name: memory
        target:
          type: Utilization
          averageUtilization: 80  # escala si memoria > 80%
  behavior:
    scaleDown:
      stabilizationWindowSeconds: 300  # espera 5 min antes de reducir
      policies:
        - type: Percent
          value: 10
          periodSeconds: 60  # reduce max 10% por minuto

# Comandos de autoscaling

# Crear HPA rapidamente desde CLI
kubectl autoscale deployment mi-app \
  --min=2 --max=10 --cpu-percent=70

# Ver HPAs y su estado actual
kubectl get hpa
# NAME         REFERENCE       TARGETS   MINPODS  MAXPODS  REPLICAS
# mi-app-hpa   Deployment/app  45%/70%   2        10       3

# Ver detalle del HPA
kubectl describe hpa mi-app-hpa

# IMPORTANTE: Para que HPA funcione, tus pods DEBEN
# tener resources.requests definidos:
#   resources:
#     requests:
#       cpu: "250m"
#       memory: "128Mi"
# Sin requests, HPA no puede calcular el porcentaje de uso

GitOps: infraestructura como codigo + Git como fuente de verdad

GitOps es un modelo donde TODO tu estado de Kubernetes esta definido en archivos YAML en un repositorio Git. Un operador (ArgoCD o Flux) observa el repo y aplica cambios automaticamente al cluster.

Flujo GitOps: 1. Developer hace push de cambios al repo Git 2. CI pipeline construye nueva imagen Docker 3. Se actualiza el tag de imagen en los manifests YAML del repo 4. ArgoCD/Flux detecta el cambio 5. Aplica automaticamente los nuevos manifests al cluster 6. Si algo falla, haces git revert y el cluster vuelve al estado anterior

Ventajas: • Historial completo de todos los cambios (git log) • Rollback instantaneo (git revert) • Pull Requests para revisar cambios de infra • Un solo repo como fuente de verdad

# Ejemplo: ArgoCD Application
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: mi-app
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/mi-org/k8s-manifests.git
    targetRevision: main
    path: apps/mi-app        # carpeta con los YAMLs
  destination:
    server: https://kubernetes.default.svc
    namespace: production
  syncPolicy:
    automated:
      prune: true            # elimina recursos que ya no estan en Git
      selfHeal: true         # revierte cambios manuales al cluster
    syncOptions:
      - CreateNamespace=true

# Instalar ArgoCD en tu cluster
kubectl create namespace argocd
kubectl apply -n argocd -f \
  https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

# Obtener password inicial del admin
kubectl -n argocd get secret argocd-initial-admin-secret \
  -o jsonpath="{.data.password}" | base64 -d

# Port-forward para acceder a la UI
kubectl port-forward svc/argocd-server -n argocd 8080:443
# Abre https://localhost:8080 — user: admin

# CLI de ArgoCD
argocd login localhost:8080
argocd app list
argocd app sync mi-app
argocd app history mi-app