Kubernetes para WhatzMeAPI: Pods, Deployments y Services

Activa tu API REST + Chatbot para WhatsApp en minutos: respuestas automáticas, envíos masivos y flujos inteligentes. ¿Te muestro un demo? 🚀ACTIVAR

¿Quieres correr WhatzMeAPI en Kubernetes de forma robusta y escalable? Aquí tienes una guía práctica enfocada en los componentes típicos de WhatzMeAPI (webhook inbound, API REST, workers de envío, orquestador de flujos/chatbot, cache/cola y base de datos), usando Pods, Deployments y Services como pilares.

1) Arquitectura de referencia para WhatzMeAPI en K8s

Componentes lógicos

• Inbound Webhook: recibe mensajes/eventos (HTTPS público).
• Core API: endpoints REST para clientes, auth, planes, webhooks de salida.
• Dispatcher/Workers: envío saliente, reintentos, rate-limit/backoff.
• Chatbot/Flows: orquestación de diálogos, plantillas y NLP si aplica.
• Cache/Queue: Redis/RabbitMQ/Streams para deduplicación y trabajo asíncrono.
• DB: MongoDB/MySQL (gestionado o externo al cluster).
• Observabilidad: Prometheus/Grafana + logs/trace.

Patrones clave

• Stateless para API/webhook/workers (fáciles de escalar).
• Idempotencia (messageId/eventId en Redis) para evitar duplicados.
• Backpressure (colas + HPA/KEDA) para absorber picos.
• Rate limiting por cuenta/instancia para cumplir políticas del proveedor.

---

2) Pods: unidad mínima (por microservicio)

Buenas prácticas

• 1 proceso principal por contenedor.
• Requests/Limits de CPU/Mem para evitar OOM/Throttle.
• Probes (liveness/readiness) con health endpoints.
• Variables de entorno via ConfigMaps/Secrets (tokens, claves).

Ejemplo Pod (esquema) – evita usar Pods sueltos en producción; usa Deployments

apiVersion: v1
kind: Pod
metadata:
  name: wz-inbound-webhook-pod
  labels: { app: wz-inbound }
spec:
  containers:
    - name: inbound
      image: your-registry/wz-inbound:1.0.0
      ports: [{ containerPort: 8080 }]
      env:
        - name: APP_ENV
          valueFrom: { configMapKeyRef: { name: wz-config, key: APP_ENV } }
        - name: API_TOKEN
          valueFrom: { secretKeyRef: { name: wz-secrets, key: API_TOKEN } }
      readinessProbe:
        httpGet: { path: /health/ready, port: 8080 }
        initialDelaySeconds: 3
        periodSeconds: 5
      livenessProbe:
        httpGet: { path: /health/live, port: 8080 }
        initialDelaySeconds: 10
        periodSeconds: 10
      resources:
        requests: { cpu: "200m", memory: "256Mi" }
        limits:   { cpu: "500m", memory: "512Mi" }

---

3) Deployments: escalado y rollouts sin dolor

Crea un Deployment por componente (inbound, api, worker, chatbot). Activa rolling updates, historial de revisiones y HPA.

Deployment – Inbound Webhook

apiVersion: apps/v1
kind: Deployment
metadata:
  name: wz-inbound
spec:
  replicas: 3
  revisionHistoryLimit: 5
  strategy:
    type: RollingUpdate
    rollingUpdate: { maxSurge: 1, maxUnavailable: 0 }
  selector:
    matchLabels: { app: wz-inbound }
  template:
    metadata:
      labels: { app: wz-inbound }
    spec:
      containers:
        - name: inbound
          image: your-registry/wz-inbound:1.1.0
          ports: [{ containerPort: 8080 }]
          envFrom:
            - configMapRef: { name: wz-config }
            - secretRef:    { name: wz-secrets }
          readinessProbe:
            httpGet: { path: /health/ready, port: 8080 }
          livenessProbe:
            httpGet: { path: /health/live, port: 8080 }
          resources:
            requests: { cpu: "200m", memory: "256Mi" }
            limits:   { cpu: "600m", memory: "512Mi" }

Deployment – Worker (Dispatcher de envíos)

apiVersion: apps/v1
kind: Deployment
metadata:
  name: wz-dispatcher
spec:
  replicas: 2
  selector:
    matchLabels: { app: wz-dispatcher }
  template:
    metadata:
      labels: { app: wz-dispatcher }
    spec:
      containers:
        - name: worker
          image: your-registry/wz-worker:2.0.0
          args: ["--mode=dispatcher", "--concurrency=8"]
          envFrom:
            - configMapRef: { name: wz-config }
            - secretRef:    { name: wz-secrets }
          resources:
            requests: { cpu: "250m", memory: "256Mi" }
            limits:   { cpu: "1",    memory: "1Gi" }

Comandos útiles

kubectl apply -f wz-inbound.yaml
kubectl rollout status deployment/wz-inbound
kubectl set image deployment/wz-inbound inbound=your-registry/wz-inbound:1.1.1
kubectl rollout undo deployment/wz-inbound
kubectl scale deployment/wz-dispatcher --replicas=6

---

4) Services: red estable y balanceo

• ClusterIP para comunicación interna (inbound → api, api → chatbot).
• LoadBalancer/Ingress para exponer el Webhook y/o API públicamente.
• Headless si necesitas discovery directo (menos común aquí).

Service interno (ClusterIP) – Core API

apiVersion: v1
kind: Service
metadata:
  name: wz-api-svc
spec:
  selector: { app: wz-api }
  ports:
    - name: http
      port: 80
      targetPort: 8080
  type: ClusterIP

Ingress TLS – Webhook público

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: wz-inbound-ing
  annotations:
    cert-manager.io/cluster-issuer: letsencrypt
spec:
  tls:
    - hosts: [ "webhook.whatzmeapi.com" ]
      secretName: wz-webhook-tls
  rules:
    - host: webhook.whatzmeapi.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: wz-inbound-svc
                port: { number: 80 }

Consejo: si estás en cloud (EKS/GKE/AKS), usa Ingress Controller (NGINX/ALB) + cert-manager para TLS automático.

---

5) Configuración y secretos (multi-tenant)

ConfigMap + Secret

apiVersion: v1
kind: ConfigMap
metadata: { name: wz-config }
data:
  APP_ENV: "prod"
  RATE_LIMIT_PER_MINUTE: "45"
  REDIS_URL: "redis://wz-redis:6379"
---
apiVersion: v1
kind: Secret
metadata: { name: wz-secrets }
type: Opaque
stringData:
  PROVIDER_TOKEN: "<token>"
  DB_PASSWORD: "<db-pass>"

Env en un Deployment

env:
  - name: RATE_LIMIT_PER_MINUTE
    valueFrom: { configMapKeyRef: { name: wz-config, key: RATE_LIMIT_PER_MINUTE } }
  - name: PROVIDER_TOKEN
    valueFrom: { secretKeyRef: { name: wz-secrets, key: PROVIDER_TOKEN } }

---

Obtén descuentos exclusivos de nuestros cursos en vivo en línea

Capacítate con los expertos

Quiero recibir noticias

Por favor clic en quiero recibir noticias.

Email es requerido.

x

You Have Successfully Subscribed to the Newsletter

6) Autoscaling (HPA/KEDA) y picos de tráfico

• HPA por CPU/RAM o métricas personalizadas (requests/seg, lag de cola).
• KEDA si escalas por profundidad de colas (Redis/RabbitMQ/Kafka).

HPA por CPU – Inbound

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: wz-inbound-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: wz-inbound
  minReplicas: 3
  maxReplicas: 15
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 60

---

7) Resiliencia: idempotencia, reintentos y backoff

• Deduplicación: guarda messageId/eventId en Redis con TTL (p.ej., 24h).
• Reintentos con backoff exponencial (p.ej., 1s, 2s, 4s, … máx. 5 intentos).
• DLQ (cola de muertos) para mensajes no procesables.
• PDB y anti-affinity** para alta disponibilidad durante mantenimientos.

PodDisruptionBudget

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: wz-inbound-pdb
spec:
  minAvailable: 2
  selector:
    matchLabels: { app: wz-inbound }

---

8) Observabilidad y trazas

• Logs estructurados (JSON) → Fácil de indexar/filtrar por tenantId, messageId.
• Métricas: peticiones/seg, latencias p50/p95/p99, tasa de errores, cola en curso.
• Tracing: OpenTelemetry (propaga traceparent en llamadas internas).

kubectl logs deploy/wz-inbound -f
kubectl top pods
kubectl get events --sort-by=.lastTimestamp

---

9) Seguridad y cumplimiento

• RBAC mínimo y Namespaces por ambiente/cliente si aplica.
• Secrets cifrados en reposo + rotación.
• NetworkPolicies (deny-by-default) abriendo solo lo necesario.
• Supply chain: imágenes firmadas (Cosign), escaneo (Trivy/Grype).

NetworkPolicy – permitir solo Ingress Controller → Inbound

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: wz-inbound-allow-ingress
spec:
  podSelector: { matchLabels: { app: wz-inbound } }
  policyTypes: ["Ingress"]
  ingress:
    - from:
        - podSelector: { matchLabels: { app.kubernetes.io/name: ingress-nginx } }
      ports: [{ protocol: TCP, port: 8080 }]

---

10) Estrategias de despliegue en producción

• RollingUpdate (default) + readiness checks correctos.
• Blue/Green para cambios grandes (cambia el Service/Ingress de golpe).
• Canary con Ingress/API-Gateway o malla de servicio (p.ej., 10% tráfico a v2).

---

11) Checklist de errores comunes (y cómo evitarlos)

1. Falta de readiness/liveness → rollouts “verdes” pero tráfico roto.
2. Sin limits/requests → OOMKills o throttling bajo carga.
3. Service selector mal puesto → el tráfico no llega a ningún Pod.
4. Tokens en imagen → usa Secrets, no embebas credenciales.
5. Sin idempotencia → mensajes duplicados a usuarios.
6. Sin HPA/KEDA → colas crecen y aumentan latencia.
7. Sin PDB/anti-affinity → downtime en mantenimientos.

---

12) Mini “cheat sheet” WhatzMeAPI en K8s

# Namespaces por ambiente
kubectl create ns wz-prod
kubectl -n wz-prod apply -f wz-config.yaml -f wz-secrets.yaml

# Despliegues
kubectl -n wz-prod apply -f wz-inbound.yaml -f wz-api.yaml -f wz-worker.yaml
kubectl -n wz-prod apply -f wz-svc.yaml -f wz-ingress.yaml -f wz-hpa.yaml

# Rollouts y escalado
kubectl -n wz-prod rollout status deploy/wz-inbound
kubectl -n wz-prod set image deploy/wz-api api=your-registry/wz-api:1.2.0
kubectl -n wz-prod scale deploy/wz-dispatcher --replicas=8

---

Conclusión

Con Pods bien definidos, Deployments para orquestar rollouts/escala y Services/Ingress para exponer endpoints clave, puedes ejecutar WhatzMeAPI en Kubernetes con resiliencia y crecimiento controlado. Añade HPA/KEDA, idempotencia, observabilidad y NetworkPolicies para operar a nivel producción sin sorpresas.

Siguiente paso: crea un namespace de prueba, despliega wz-inbound + wz-api + wz-dispatcher con los YAML anteriores, agrega HPA, simula picos con una cola/loader y valida métricas (latencia p95, errores, cola pendiente). Si quieres, te armo los manifiestos completos por servicio con tu set real de variables.

Esquema rápido

• Servicios: inbound webhook, core API, workers (envío), chatbot/flows.
• Patrones: stateless, idempotencia (messageId), backoff + DLQ, rate-limit por cuenta.
• Infra: Redis/cola, DB gestionada fuera del cluster, Ingress + TLS.

Pods / Deployments

• 1 microservicio = 1 Deployment.
• Probes (readiness/liveness), requests/limits y env vía ConfigMap/Secret.
• Rolling update + kubectl rollout undo para rollback.
• HPA/KEDA para picos (CPU o profundidad de cola).

Services / Ingress

• ClusterIP para interno (API, chatbot, workers).
• Ingress + TLS para el webhook/API público.

Observabilidad & Seguridad

• Logs JSON (tenantId, messageId), métricas p50/p95, tasa de error.
• OpenTelemetry para trazas.
• RBAC mínimo, NetworkPolicies (deny-by-default), Secrets cifrados.
• PDB + anti-affinity para alta disponibilidad.

YAML mínimo (inbound + service + ingress)

apiVersion: apps/v1
kind: Deployment
metadata: { name: wz-inbound }
spec:
  replicas: 3
  selector: { matchLabels: { app: wz-inbound } }
  template:
    metadata: { labels: { app: wz-inbound } }
    spec:
      containers:
        - name: inbound
          image: your-registry/wz-inbound:1.1.0
          ports: [{ containerPort: 8080 }]
          envFrom:
            - configMapRef: { name: wz-config }
            - secretRef:    { name: wz-secrets }
          readinessProbe: { httpGet: { path: /health/ready, port: 8080 } }
          livenessProbe:  { httpGet: { path: /health/live,  port: 8080 } }
---
apiVersion: v1
kind: Service
metadata: { name: wz-inbound-svc }
spec:
  selector: { app: wz-inbound }
  ports: [{ port: 80, targetPort: 8080 }]
  type: ClusterIP
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: wz-inbound-ing
  annotations: { cert-manager.io/cluster-issuer: letsencrypt }
spec:
  tls: [{ hosts: ["webhook.whatzmeapi.com"], secretName: wz-webhook-tls }]
  rules:
    - host: webhook.whatzmeapi.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend: { service: { name: wz-inbound-svc, port: { number: 80 } } }

Checklist de producción

• ✔ Idempotencia y reintentos con backoff + DLQ
• ✔ HPA/KEDA activo
• ✔ PDB + anti-affinity
• ✔ NetworkPolicies y Secrets
• ✔ Métricas clave: req/s, p95, errores, lag de cola

Potencia tu WhatsApp con WhatzMeAPI: API REST, chatbot, plantillas y analíticas para vender más 📈
Conoce planes y features aquí 👉 https://www.whatzmeapi.com/ ✅