Knative Serverless Kubernetes 2025: Despliegue y Escalado

Introducción al despliegue serverless con Knative sobre Kubernetes

El ecosistema cloud-native ha evolucionado hacia modelos de ejecución que maximizan la eficiencia de recursos y minimizan la gestión operativa. En este contexto, Knative emerge como la plataforma de referencia para ejecutar cargas de trabajo serverless sobre Kubernetes. No se trata de un producto comercial cerrado, sino de un proyecto open source (actualmente en la CNCF) que extiende Kubernetes para proporcionar capacidades de escalado automático a cero, revisiones de versiones, enrutamiento de tráfico y un modelo de abstracción limpio para desarrolladores.

El valor principal de Knative reside en que no necesitas gestionar servidores, clústeres de aplicaciones ni infraestructura de escalado. Simplemente empaquetas tu código en un contenedor OCI estándar, defines un servicio Knative y el sistema se encarga del resto: desde el escalado automático hasta el aprovisionamiento de recursos bajo demanda. Esto lo convierte en una opción ideal para equipos que ya operan Kubernetes y quieren adoptar un paradigma serverless sin atarse a proveedores cloud específicos.

¿Qué es Knative y cómo se integra con Kubernetes?

Knative está compuesto por dos componentes principales:

Knative Serving: Gestiona el ciclo de vida de las aplicaciones serverless. Proporciona escalado automático a cero, actualizaciones progresivas (rolling updates) y enrutamiento de tráfico entre revisiones.
Knative Eventing: Permite construir arquitecturas orientadas a eventos, conectando fuentes (bancos de eventos, colas, HTTP) con servicios Knative.

Ambos se despliegan sobre un clúster Kubernetes estándar, añadiendo CRDs (Custom Resource Definitions) y controladores que extienden la API nativa. Esto significa que puedes usar kubectl para gestionar servicios Knative de la misma forma que gestionas Deployments o Services.

Requisitos previos

Antes de comenzar, necesitas:

Un clúster Kubernetes funcional (versión 1.26 o superior recomendada).
Istio, Contour, Kourier o cualquier Ingress Gateway compatible como capa de red. Kourier es la opción más ligera para entornos de prueba.
kn (CLI de Knative) y kubectl instalados.

[INFO] Knative Serving requiere un Ingress Gateway para enrutar el tráfico externo hacia los servicios. Kourier es la opción recomendada para empezar por su simplicidad.

Instalación de Knative Serving en un clúster Kubernetes

La instalación consta de dos pasos: desplegar el operador de Knative y configurar la capa de red. Vamos a usar Kourier como ejemplo.

Paso 1: Instalar el operador de Knative Serving

kubectl apply -f https://github.com/knative/operator/releases/download/knative-v1.14.0/operator.yaml

Esto crea el namespace knative-operator y despliega los controladores necesarios.

Paso 2: Crear el recurso KnativeServing

Crea un archivo knative-serving.yaml:

apiVersion: operator.knative.dev/v1alpha1
kind: KnativeServing
metadata:
  name: knative-serving
  namespace: knative-serving
spec:
  config:
    network:
      ingress-class: kourier.ingress.networking.knative.dev

Aplica el recurso:

kubectl apply -f knative-serving.yaml

Paso 3: Instalar Kourier como Ingress Gateway

kubectl apply -f https://github.com/knative/net-kourier/releases/download/knative-v1.14.0/kourier.yaml

Tras unos minutos, verifica que todos los pods están en estado Running:

kubectl get pods -n knative-serving
kubectl get pods -n kourier-system

[TIP] Si usas Minikube o Kind, recuerda exponer el puerto del gateway: kubectl port-forward --namespace kourier-system service/kourier 8080:80

Despliegue de tu primer servicio serverless con Knative

Una vez instalado, desplegar una aplicación es tan sencillo como definir un recurso Service de Knative. A diferencia de un Deployment tradicional, aquí no especificamos réplicas ni estrategias de escalado; Knative lo gestiona automáticamente.

Ejemplo: Servicio Hello World en Go

Crea un archivo service.yaml:

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: hello-world
  namespace: default
spec:
  template:
    spec:
      containers:
        - image: gcr.io/knative-samples/helloworld-go
          env:
            - name: TARGET
              value: "Knative"

Despliega el servicio:

kubectl apply -f service.yaml

Verifica el estado:

kubectl get ksvc hello-world

La salida mostrará una URL similar a http://hello-world.default.example.com. Para acceder desde tu máquina local, necesitas configurar un mapeo DNS o usar el hostname del gateway.

Escalado automático a cero

Una de las características más potentes de Knative es el escalado automático basado en métricas de concurrencia (número de peticiones simultáneas). Cuando no hay tráfico, el servicio escala a cero réplicas, liberando completamente los recursos del clúster. Al recibir una nueva solicitud, el sistema reactiva el pod en cuestión de segundos (lo que se conoce como cold start).

Puedes observar este comportamiento monitoreando los pods:

kubectl get pods -l serving.knative.dev/service=hello-world -w

Al enviar una petición HTTP verás cómo aparece un pod, se procesa la solicitud y, tras un período de inactividad (configurable), el pod se termina.

Gestión de cold starts y rendimiento

El principal desafío de cualquier plataforma serverless son los cold starts: el tiempo que tarda en arrancar un nuevo contenedor cuando no hay réplicas activas. En Knative, este tiempo depende de:

Tamaño de la imagen: Imágenes más grandes tardan más en descargarse.
Latencia de red: La descarga desde el registro de contenedores.
Tiempo de inicialización de la aplicación: Código de arranque, conexiones a bases de datos, etc.

Estrategias para mitigar cold starts

Imágenes ligeras: Usa imágenes base mínimas (distroless, Alpine) y optimiza el Dockerfile.
Configurar el escalado mínimo: Puedes forzar que siempre haya al menos una réplica activa mediante la anotación autoscaling.knative.dev/min-scale:
```
metadata:
  annotations:
    autoscaling.knative.dev/min-scale: "1"
```
Activar el modo "activator": Knative incluye un componente llamado Activator que mantiene un buffer de peticiones mientras el pod arranca, reduciendo la latencia percibida.
Usar revisiones con warm-up: Knative permite mantener revisiones anteriores activas durante un tiempo para evitar cold starts en despliegues progresivos.

[WARNING] Forzar un min-scale: 1 elimina el beneficio del escalado a cero. Evalúa si realmente necesitas cero coste o prefieres baja latencia.

Enrutamiento de tráfico y versionado

Knative Serving gestiona de forma nativa el versionado de servicios. Cada cambio en el spec.template genera una nueva revisión (revision). Puedes controlar qué porcentaje de tráfico recibe cada revisión, lo que permite:

Despliegues azul/verde: Enviar todo el tráfico a la nueva revisión y, si falla, revertir instantáneamente.
Canary releases: Enviar gradualmente un porcentaje pequeño de tráfico a la nueva versión.

Ejemplo de configuración de tráfico:

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: my-service
spec:
  template:
    metadata:
      name: v2
    spec:
      containers:
        - image: my-image:v2
  traffic:
    - revisionName: v2
      percent: 10
    - revisionName: v1
      percent: 90

Esto se puede actualizar dinámicamente sin redeploy del servicio.

Integración con Knative Eventing para arquitecturas reactivas

Knative Eventing permite que tus servicios serverless reaccionen a eventos externos: mensajes de Kafka, cambios en bases de datos, webhooks, etc. En lugar de exponer un endpoint HTTP, defines un trigger que conecta un broker (por ejemplo, InMemoryChannel o KafkaChannel) con tu servicio.

Ejemplo básico con un broker por defecto:

apiVersion: eventing.knative.dev/v1
kind: Trigger
metadata:
  name: my-trigger
spec:
  broker: default
  subscriber:
    ref:
      apiVersion: serving.knative.dev/v1
      kind: Service
      name: event-display

Esto permite construir pipelines de procesamiento de eventos totalmente serverless, donde cada servicio escala según la carga de eventos.

Monitorización y observabilidad

Knative se integra de serie con Prometheus y Grafana para métricas de escalado, latencia y concurrencia. Puedes instalar el stack de monitorización recomendado:

kubectl apply -f https://github.com/knative/serving/releases/download/knative-v1.14.0/monitoring-core.yaml

Las métricas clave a observar son:

activator_request_count: peticiones gestionadas por el Activator.
revision_request_count: peticiones totales por revisión.
revision_request_latencies: percentiles de latencia (p50, p95, p99).
autoscaler_actual_pods: número real de pods en cada momento.

[TIP] Configura alertas en Prometheus para cuando el tiempo de cold start supere un umbral (por ejemplo, 5 segundos) o cuando el escalado no pueda seguir la demanda.

Casos de uso reales y limitaciones

Dónde brilla Knative

APIs y microservicios con tráfico variable: Aplicaciones que reciben picos de uso (por ejemplo, procesamiento de imágenes, chatbots).
ETL y procesamiento por lotes: Tareas que se ejecutan bajo demanda y pueden escalar a cero.
Backends para aplicaciones móviles: Endpoints que solo se usan en momentos concretos.

Limitaciones a considerar

Cold starts inevitables: Aunque se pueden mitigar, siempre existirá una latencia inicial si escalas a cero.
Complejidad operativa: Knative añade una capa adicional sobre Kubernetes; no es recomendable para clústeres pequeños o equipos sin experiencia en Kubernetes.
Dependencia de la capa de red: Kourier, Istio o Contour deben estar correctamente configurados y monitoreados.
Coste de recursos del plano de control: Los controladores de Knative consumen recursos aunque no haya cargas de trabajo.

Conclusión

Knative representa la evolución natural de Kubernetes hacia un modelo serverless maduro, portable y open source. Su capacidad de escalado automático a cero, junto con un potente sistema de versionado y enrutamiento, lo convierte en una herramienta indispensable para equipos que buscan eficiencia operativa sin sacrificar control.

El despliegue de servidores serverless con Knative no solo reduce costes de infraestructura, sino que también acelera el ciclo de desarrollo al abstraer la gestión del escalado. Sin embargo, requiere una comprensión sólida de Kubernetes y una planificación cuidadosa para mitigar los cold starts y gestionar la complejidad adicional.

Si tu organización ya invierte en Kubernetes, Knative es la puerta de entrada a un ecosistema serverless que no te ata a ningún proveedor cloud. Empieza con un servicio simple, mide los tiempos de respuesta y ajusta la configuración de escalado según tus necesidades reales. El futuro de la computación en la nube es serverless, y Knative es el vehículo para llegar allí desde Kubernetes.