Implementar microservicios escalables en Kubernetes

Kubernetes se ha convertido en el estándar de facto para la orquestación de contenedores, ofreciendo una plataforma robusta para la implementación, gestión y escalado de microservicios. Para los líderes técnicos, dominar sus complejidades no es simplemente una tarea operativa, sino un imperativo estratégico. Un despliegue de Kubernetes bien diseñado proporciona resiliencia, escalabilidad y velocidad, mientras que uno mal diseñado introduce complejidad y fragilidad.

Este artículo proporciona una guía técnica para implementar una arquitectura de microservicios escalable en Kubernetes. Analizaremos las decisiones arquitectónicas, proporcionaremos ejemplos de configuración listas para producción y abordaremos los pilares clave de escalabilidad, resiliencia y observabilidad.

Servicios de Ingeniería de Productos

Colabore con nuestros gestores de proyectos, ingenieros de software y probadores de calidad para desarrollar su nuevo producto de software personalizado o para apoyar su flujo de trabajo actual, siguiendo metodologías Agile, DevOps y Lean.

Build with 4Geeks

Planos Arquitectónicos: Componentes y Patrones Clave

Una arquitectura de microservicios escalable en Kubernetes es más que una colección de aplicaciones contenedorizadas. Es un ecosistema de componentes interactivos, cada uno configurado para una alta disponibilidad y rendimiento.

1. Nivel de detalle del servicio y comunicación

La primera decisión arquitectónica es definir los límites de sus microservicios. Cada servicio debe estar alineado con una capacidad empresarial específica (Diseño basado en el dominio). Una vez definidos, la comunicación se convierte en el siguiente desafío.

• Comunicación Síncrona (REST/gRPC): Para las interacciones de solicitud/respuesta, los servicios necesitan un mecanismo para descubrir y comunicarse entre sí. Kubernetes proporciona un mecanismo de Descubrimiento de Servicios basado en DNS. Un servicio puede llamar de forma fiable a otro utilizando su Servicio nombre (por ejemplo, http://user-service:8080/users).
• Comunicación Asíncrona (Colas de Mensajes): Para desacoplar los servicios y manejar los flujos de trabajo basados en eventos, un intermediario de mensajes como RabbitMQ o Kafka es esencial. Este componente también debe implementarse dentro del clúster de Kubernetes, gestionado mediante un operador para la persistencia de estado.

2. API Gateway

Exponer docenas de microservicios directamente a internet público es insostenible. Una API Gateway sirve como el único punto de entrada, proporcionando funciones esenciales:

• Enrutamiento: Dirige las solicitudes entrantes al servicio backend apropiado.
• Autenticación y Autorización: Descarga la validación de JWT o las comprobaciones de claves API.
• Control de velocidad: Protege los servicios del abuso.
• Terminación SSL: Centraliza la gestión de certificados TLS/SSL.

Algunas opciones populares incluyen Kong, Ambassador o soluciones nativas en la nube como AWS API Gateway. En Kubernetes, un Ingress Controller (por ejemplo, NGINX Ingress, Traefik) es la implementación estándar para un API Gateway.

3. Gestión de la configuración

Definir la configuración de forma fija en las imágenes de contenedor es un error grave. Kubernetes proporciona dos recursos principales para gestionar la configuración de forma externa:

• ConfigMaps: Para datos no sensibles, como las banderas de características, las URLs de los endpoints o la configuración del entorno.
• Secretos: Para datos sensibles, como las claves de API, las credenciales de la base de datos y los certificados TLS. Se almacenan en formato base64, pero para entornos de producción, se recomienda encarecidamente integrarse con una solución de almacenamiento de secretos (por ejemplo, HashiCorp Vault, AWS Secrets Manager) para una gestión de secretos real.

Implementación Práctica: De Código a Cluster

Vamos a traducir la arquitectura a una implementación práctica utilizando un ejemplo de order-service escrito en Go.

Paso 1: Contener el microservicio

La base de un despliegue de Kubernetes es la imagen del contenedor. El Dockerfile debe estar optimizado tanto para el tamaño como para la seguridad. La construcción en múltiples etapas es la mejor práctica.

orden-servicio/main.go

package main

import (
	"encoding/json"
	"log"
	"net/http"
	"os"
)

func main() {
	http.HandleFunc("/orders", func(w http.ResponseWriter, r *http.Request) {
		dbHost := os.Getenv("DATABASE_HOST") // Injected via ConfigMap/Secret
		orders := map[string]string{
			"orderId": "12345",
			"status":  "processed",
			"db_host": dbHost,
		}
		w.Header().Set("Content-Type", "application/json")
		json.NewEncoder(w).Encode(orders)
	})

	log.Println("Order service starting on port 8080...")
	log.Fatal(http.ListenAndServe(":8080", nil))
}

Dockerfile(De varias etapas)

# Stage 1: Build the application
FROM golang:1.21-alpine AS builder
WORKDIR /app
COPY go.mod go.sum ./
RUN go mod download
COPY . .
# Build the binary statically to avoid C dependencies
RUN CGO_ENABLED=0 GOOS=linux go build -a -installsuffix cgo -o order-service .

# Stage 2: Create the final, minimal image
FROM alpine:latest
WORKDIR /root/
# Copy only the compiled binary from the builder stage
COPY --from=builder /app/order-service .
# Expose port and run the application
EXPOSE 8080
CMD ["./order-service"]

Este proceso de construcción en múltiples etapas resulta en una imagen pequeña y segura que contiene únicamente el binario de la aplicación compilada, reduciendo la superficie de ataque y mejorando la velocidad de implementación.

Paso 2: Archivos de Kubernetes

Loscomandosraw de

configmap.yaml: Para inyectar la configuración específica del entorno.

apiVersion: v1
kind: ConfigMap
metadata:
  name: order-service-config
data:
  DATABASE_HOST: "postgres.prod.svc.cluster.local"

deployment.yaml: Esto define los pods de la aplicación, incluyendo réplicas, imagen del contenedor y solicitudes de recursos.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: order-service
spec:
  replicas: 3 # Start with 3 replicas for high availability
  selector:
    matchLabels:
      app: order-service
  template:
    metadata:
      labels:
        app: order-service
    spec:
      containers:
      - name: order-service
        image: your-registry/order-service:1.0.0 # Replace with your image
        ports:
        - containerPort: 8080
        envFrom:
        - configMapRef:
            name: order-service-config
        resources:
          requests:
            cpu: "100m"    # 0.1 vCPU
            memory: "128Mi"
          limits:
            cpu: "250m"
            memory: "256Mi"
        # Liveness and Readiness Probes are CRITICAL for resilience
        readinessProbe:
          httpGet:
            path: /orders # A lightweight endpoint
            port: 8080
          initialDelaySeconds: 5
          periodSeconds: 10
        livenessProbe:
          httpGet:
            path: /orders
            port: 8080
          initialDelaySeconds: 15
          periodSeconds: 20

Puntos clave:

• Solicitudes/Límites de recursos: Establecer estos es obligatorio para cargas de trabajo de producción. Evitan la contención de recursos y aseguran un rendimiento predecible.
• Prueba de preparación: Indica si el servicio está listo para aceptar tráfico. Kubernetes no dirigirá el tráfico a un contenedor hasta que esta prueba pase.
• Prueba de vitalidad: Verifica si la aplicación sigue funcionando correctamente. Si falla, Kubernetes reiniciará el contenedor.

Servicios de Ingeniería de Productos

Trabaje con nuestros gestores de proyectos, ingenieros de software y probadores de calidad internos para desarrollar su nuevo producto de software personalizado o para apoyar su flujo de trabajo actual, siguiendo metodologías Agile, DevOps y Lean.

Build with 4Geeks

service.yaml: Proporciona un punto de acceso interno estable para el Despliegue.

apiVersion: v1
kind: Service
metadata:
  name: order-service
spec:
  selector:
    app: order-service
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080
  type: ClusterIP # Exposes the service only within the cluster

ingress.yaml: Gestiona el acceso externo al servicio.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: order-service-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
  - host: api.yourdomain.com
    http:
      paths:
      - path: /orders
        pathType: Prefix
        backend:
          service:
            name: order-service
            port:
              number: 80

Esta configuración dirige el tráfico desde api.yourdomain.com/orders al servicio de order-service.

Garantizar la escalabilidad y la resiliencia

Implementar el servicio es solo el comienzo. El sistema debe poder gestionar cargas variables y recuperarse automáticamente de los fallos.

Autoscaler de Pods Horizontal (HPA)

El HPA escala automáticamente el número de pods en un despliegue según las métricas observadas, como el uso de la CPU o métricas personalizadas (por ejemplo, solicitudes por segundo).

hpa.yaml:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: order-service-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: order-service
  minReplicas: 3
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 80 # Scale up when CPU usage exceeds 80%

Con esta HPA, Kubernetes añadirá automáticamente más contenedores de servicio cuando el uso promedio de la CPU en todos los contenedores supere el 80%, hasta un máximo de 10 contenedores. Se reducirá automáticamente cuando el uso disminuya.

Cierre elegante y Presupuestos de Interrupción de Pods

Cuando un nodo se desconecta para mantenimiento o se actualiza una implementación, los pods se terminan. Es crucial que se apaguen de forma ordenada, completando las solicitudes en curso. Esto se gestiona escuchando la señal SIGTERMSIGTERM

Un PodDisruptionBudget (PDB) garantiza que un número mínimo de réplicas estén siempre disponibles durante las interrupciones voluntarias (como un drenaje de nodos), evitando interrupciones del servicio.

pdb.yaml:

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: order-service-pdb
spec:
  minAvailable: 2 # Or use a percentage like "80%"
  selector:
    matchLabels:
      app: order-service

Este PDB garantiza que al menos 2 réplicas de order-service siempre estarán en funcionamiento durante las interrupciones voluntarias.

Observabilidad: Los Tres Pilares

En un sistema distribuido, no puedes depurar mediante ssh-ing a un servidor. Un robusto conjunto de herramientas de observabilidad es imprescindible.

1. Registro: Los registros de los contenedores deben escribirse en stdout y stderr. Un agregador de registros como Fluentd, que se ejecuta como un DaemonSet, puede recopilar estos registros de todos los nodos y enviarlos a una plataforma centralizada como Elasticsearch o Loki.
2. Métricas: El Prometheus Operator es el estándar de la industria para la recopilación de métricas en Kubernetes. Instrumente sus aplicaciones con una biblioteca de cliente (por ejemplo, prometheus/client_golang) para exponer métricas clave de negocio y rendimiento. Utilice Grafana para crear paneles de control para visualizar estos datos.
3. Rastreo: Para comprender el ciclo de vida de una solicitud a medida que atraviesa múltiples microservicios, el rastreo distribuido es esencial. Implemente OpenTelemetry en sus servicios y envíe los rastros a un backend como Jaeger o Zipkin. Esto es invaluable para identificar cuellos de botella en el rendimiento en flujos de trabajo complejos.

Por último

Implementar microservicios en Kubernetes es una tarea compleja que requiere un conocimiento profundo de los principios de las tecnologías nativas en la nube. El éxito depende de un esquema arquitectónico bien definido que aborde la comunicación entre servicios, la gestión de la configuración y los patrones de acceso externo.

Al implementar manifiestos declarativos, comprobaciones de salud robustas y escalado automatizado con HPAs, puede construir un sistema que sea tanto resiliente como de alto rendimiento. Además, invertir en una pila completa de observabilidad no es un extra, sino un requisito fundamental para operar un sistema distribuido a gran escala. Este marco proporciona la base técnica para que los directores técnicos (CTOs) y los ingenieros construyan y gestionen una plataforma de microservicios verdaderamente escalable y de producción en Kubernetes.

Preguntas frecuentes