Kubernetes: Ingress, Helm Charts y buenas prácticas en producción

Ingress Controller y reglas Ingress

Un Service tipo NodePort o LoadBalancer expone tu aplicación, pero cuando tienes múltiples servicios en un mismo clúster, gestionar puertos y balanceadores se vuelve caótico. Aquí entra Ingress: un recurso que actúa como proxy inverso y enrutador HTTP/HTTPS hacia tus servicios internos.

Para que Ingress funcione, necesitas un Ingress Controller (como NGINX Ingress Controller, Traefik, o HAProxy). El controller es un Pod que lee las reglas Ingress y configura el proxy.

# Instalar NGINX Ingress Controller con Helm
helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
helm repo update
helm install nginx-ingress ingress-nginx/ingress-nginx \
  --namespace ingress-nginx --create-namespace

# Verificar
kubectl get pods -n ingress-nginx
kubectl get svc -n ingress-nginx

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: app-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  ingressClassName: nginx
  rules:
  - host: api.itfrontech.com
    http:
      paths:
      - path: /v1
        pathType: Prefix
        backend:
          service:
            name: api-svc
            port:
              number: 80
      - path: /v2
        pathType: Prefix
        backend:
          service:
            name: api-v2-svc
            port:
              number: 80
  - host: admin.itfrontech.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: admin-svc
            port:
              number: 8080
  tls:
  - hosts:
    - api.itfrontech.com
    secretName: api-tls

Helm: el gestor de paquetes de Kubernetes

Helm simplifica el despliegue de aplicaciones complejas en Kubernetes mediante charts. Un chart es un paquete con templates YAML parametrizables. En lugar de tener 20 archivos YAML para desplegar WordPress+MySQL, instalas un chart con helm install y ajustas valores con values.yaml.

# Buscar charts en repositorios públicos
helm search hub wordpress

# Agregar repositorio de Bitnami
helm repo add bitnami https://charts.bitnami.com/bitnami
helm repo update

# Instalar WordPress con valores personalizados
helm install my-wordpress bitnami/wordpress \
  --set wordpressUsername=admin \
  --set wordpressPassword=miPass \
  --set mariadb.auth.rootPassword=dbPass

# Ver releases instalados
helm list

# Valores personalizados en archivo
cat > values.yaml << 'EOF'
wordpressUsername: admin
wordpressPassword: miPass
replicaCount: 3
resources:
  requests:
    memory: 256Mi
    cpu: 250m
  limits:
    memory: 512Mi
    cpu: 500m
EOF

helm upgrade my-wordpress bitnami/wordpress -f values.yaml

Buenas prácticas en producción

Resource limits y requests: nunca despliegues un Pod sin definir recursos. Sin límites, un contenedor puede consumir toda la memoria del nodo y matar otros procesos. Siempre define requests (mínimo garantizado) y limits (máximo permitido).

apiVersion: v1
kind: Pod
metadata:
  name: prod-pod
spec:
  containers:
  - name: app
    image: myapp:1.0
    resources:
      requests:
        memory: "128Mi"
        cpu: "250m"
      limits:
        memory: "256Mi"
        cpu: "500m"
    readinessProbe:
      httpGet:
        path: /health
        port: 8080
      initialDelaySeconds: 5
      periodSeconds: 10
    livenessProbe:
      httpGet:
        path: /health
        port: 8080
      initialDelaySeconds: 15
      periodSeconds: 20

Otras prácticas esenciales:

• Namespaces: usa namespaces para aislar entornos (dev, staging, prod). Aplica ResourceQuota y LimitRange por namespace para evitar que un equipo abuse de los recursos.
• Readiness vs Liveness Probes: readiness indica cuándo un Pod está listo para recibir tráfico; liveness indica si el Pod sigue vivo. No confundirlas — sin readiness probe, el Service enviará tráfico a Pods que aún no han terminado de inicializarse.
• RBAC: nunca uses la cuenta default en producción. Crea ServiceAccounts con permisos mínimos (principio de menor privilegio).
• PodDisruptionBudget: asegura que un mínimo de réplicas estén disponibles durante mantenimientos de nodos.
• NetworkPolicies: por defecto todos los Pods pueden hablar entre sí. Define políticas de red para microsegmentar el tráfico.