Despliegue de Clústeres Kubernetes (K3s) sobre Arquitectura ARM64: Optimización, Traefik y Cert-Manager

La adopción de procesadores basados en la arquitectura ARM64 (aarch64) en centros de datos modernos ha transformado la relación costo-rendimiento de la computación en la nube. A diferencia de las arquitecturas x86_64 tradicionales con hilos simultáneos (SMT), los procesadores ARM nativos para servidores ofrecen núcleos físicos dedicados con un consumo energético significativamente menor y un rendimiento predecible por vCPU. En Inovaxsoft operamos nuestra infraestructura de microservicios sobre un clúster Kubernetes ligero (K3s) corriendo en nodos Ubuntu LTS ARM64.

1. ¿Por qué K3s en lugar de Kubernetes Vanilla (kubeadm) para Cargas Medianas?

Una distribución estándar de Kubernetes carga en memoria numerosos controladores de nube heredados, plugins de almacenamiento en árbol y un clúster etcd que puede consumir fácilmente entre 1.5 GB y 2.5 GB de RAM solo para el plano de control (Control Plane). K3s, proyecto graduado de la CNCF, empaqueta todos los componentes del plano de control (`kube-apiserver`, `kube-controller-manager`, `kube-scheduler`, `kubelet`, `kube-proxy` y `flannel`) en un único binario optimizado de menos de 70 MB, reduciendo la huella de memoria base a cerca de 512 MB de RAM.

• Containerd integrado: Elimina la sobrecarga del demonio de Docker en tiempo de ejecución, interactuando directamente mediante CRI (Container Runtime Interface).
• Importación directa de imágenes locales: Permite construir imágenes OCI y registrarlas en el namespace de Kubernetes sin exponer un registro inseguro a internet mediante docker save app:latest | k3s ctr images import -.
• Ingress Controller Traefik y ServiceLB nativos: Facilita el enrutamiento HTTP/HTTPS en los puertos 80 y 443 desde el primer minuto.

2. Gestión de Certificados TLS Automatizados con Cert-Manager y ACME HTTP-01

Para que un servicio web moderno cumpla con los estándares de seguridad de navegadores, motores de búsqueda y redes publicitarias, el cifrado TLS 1.2/1.3 es obligatorio. Mediante cert-manager, el ciclo de vida de los certificados X.509 se gestiona de manera declarativa como recursos nativos de Kubernetes.

Un error común al configurar un ClusterIssuer de Let's Encrypt es olvidar definir correctamente la clase del solucionador HTTP-01 o dejar correos de ejemplo inválidos (como example.com), lo que provoca el rechazo inmediato del registro ACME. La configuración de producción recomendada con Traefik es:

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-production
spec:
  acme:
    email: contacto@inovaxsoft.com
    server: https://acme-v02.api.letsencrypt.org/directory
    privateKeySecretRef:
      name: letsencrypt-production-account-key
    solvers:
    - http01:
        ingress:
          class: traefik

Cuando se despliega un objeto Ingress con la anotación cert-manager.io/cluster-issuer y su bloque tls correspondiente, cert-manager crea temporalmente un pod cm-acme-http-solver que responde al desafío en la ruta /.well-known/acme-challenge/<token>, almacena el certificado firmado en un Secret de tipo kubernetes.io/tls y programa su renovación automática 30 días antes del vencimiento.

3. Definición Estricta de Requests, Limits y Probes en Despliegues Web

Ejecutar múltiples aplicaciones (portales web, servidores WebSocket y bases de datos) dentro de un mismo clúster exige aislar el consumo de memoria y CPU para evitar el temido fenómeno de Noisy Neighbor o que el kernel de Linux invoque al OOMKiller sobre procesos críticos del nodo.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-service
spec:
  replicas: 1
  strategy:
    type: RollingUpdate
  template:
    spec:
      containers:
      - name: app
        image: app-arm64:1.2.0
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 80
        resources:
          requests:
            cpu: "50m"
            memory: "64Mi"
          limits:
            cpu: "500m"
            memory: "256Mi"
        livenessProbe:
          httpGet:
            path: /api/health
            port: 80
          initialDelaySeconds: 10
          periodSeconds: 15
        readinessProbe:
          httpGet:
            path: /api/health
            port: 80
          initialDelaySeconds: 5
          periodSeconds: 10

4. Compilación Multi-Arquitectura (ARM64 vs AMD64)

Al desarrollar en estaciones de trabajo Windows o Linux x86_64 y desplegar en servidores ARM64, es fundamental garantizar que los binarios nativos (como módulos C++ de Node.js, better-sqlite3 o imágenes base de Alpine/Debian) coincidan con la arquitectura del nodo. Compilar directamente en el nodo ARM64 o utilizar docker buildx build --platform linux/arm64 previene errores de tipo exec format error en el arranque de los pods.

5. Monitoreo y Limpieza de Recursos Huérfanos

Mantener un clúster saludable requiere auditar periódicamente los pods en estado Pending, ImagePullBackOff o CrashLoopBackOff. Un pod en bucle de reinicio constante no solo ensucia los registros de auditoría, sino que consume ciclos de I/O y CPU en `containerd` y `kubelet`. Establecer políticas claras de retención de réplicas (revisionHistoryLimit: 5) y monitoreo activo garantiza una infraestructura limpia, veloz y de alta disponibilidad.