Instalación y Configuración de Knative
- Preparación del entorno
1.1 Herramienta de línea de comandos
# Clonar y compilar la herramienta CLI de Knative
git clone https://github.com/knative/client.git
cd client/cmd/kn
go build -o kn main.go
sudo mv kn /usr/local/bin/
1.2 Componentes de Serving
# Desplegar definiciones de recursos personalizados
kubectl apply -f https://github.com/knative/serving/releases/download/knative-v1.10.1/serving-crds.yaml
# Implementar los componentes principales
kubectl apply -f https://github.com/knative/serving/releases/download/knative-v1.11.1/serving-core.yaml
# Configurar la red mediante Istio (requiere instalación previa)
kubectl apply -f https://github.com/knative/net-istio/releases/download/knative-v1.11.0/net-istio.yaml
1.3 Componentes de Eventing
# Crear las definiciones de eventos
kubectl apply -f https://github.com/knative/eventing/releases/download/knative-v1.11.4/eventing-crds.yaml
# Instalar el núcleo del sistema de eventos
kubectl apply -f https://github.com/knative/eventing/releases/download/knative-v1.11.4/eventing-core.yaml
- Arquitectura y Componentes Principales
Knative proporciona una base para ejecutar cargas de trabajo sin servidor, independientemente de la plataforma subyacente. Su arquitectura se compone de dos módulos fundamentales: Serving y Eventing.
2.1 Componente Serving
Este módulo define recursos personalizados de Kubernetes para gestionar el ciclo de vida de las aplicaciones sin servidor, incluyendo despliegues, versiones y rutas.
2.1.1 Recurso Service
El recurso Service abstrae la gestión completa de la aplicación. Controla la creación de configuraciones, revisiones y rutas, asegurando que el tráfico se dirija correctamente.
Controladores y Coordinadores
El sistema incluye múltiples controladores especializados:
- Controladores para desarrolladores: Gestionan configuraciones, revisiones, rutas y servicios.
- Controladores de infraestructura: Manejan etiquetas, activación sin servidor y recolección de basura.
Componente Webhook
Este componente valida y establece valores predeterminados para los recursos, como límites de tiempo, concurrencia y configuración de contenedores.
Sistema de Escalamiento Automático
El KPA (Knative Pod Autoscaler) ajusta dinámicamente las instancias basándose en la carga de trabajo. Su modo pánico reduce el tiempo de muestreo para detectar picos de tráfico rápidamente.
# Configuración del autoscaler (fragmento)
data:
stable-window: "60s"
panic-window-percentage: "10.0"
max-scale-up-rate: "1000.0"
scale-to-zero-grace-period: "30s"
initial-scale: "1"
min-scale: "0"
max-scale: "0"
2.1.2 Recurso Route
Las rutas permiten dirigir el tráfico a diferentes versiones de la aplicación, facilitando estrategias como despliegues canarios o blue-green.
# Ejemplo de comando para asignar etiquetas y tráfico
kn service update app-demo --tag v1=stable --traffic stable=70,@latest=30
# Verificar el estado de la ruta
kn route describe app-demo
2.1.3 Recurso Configuration
Define el estado deseado de la aplicación. Cualquier modificación genera automáticamente una nueva revisión.
# Definición de una configuración (ejemplo YAML simplificado)
apiVersion: serving.knative.dev/v1
kind: Configuration
metadata:
name: mi-aplicacion
spec:
template:
spec:
containers:
- image: registry.io/mi-app:v2
ports:
- containerPort: 8080
env:
- name: ENTORNO
value: "produccion"
2.1.4 Recurso Revision
Cada revisión representa una instantánea inmutable de la configuración de la aplicación. Las revisiones pueden escalar automáticamente según la demanda.
2.2 Componente Eventing
Proporciona infraestructura para arquitecturas orientadas a eventos, permitiendo la comunicación entre servicios mediante eventos CloudEvents.
2.2.1 Estándar CloudEvent
Los eventos siguen la especificación CloudEvent con atributos obligatorios como specversion, source, type e id.
2.2.2 Recurso Broker
Actúa como punto de entrada central para los eventos, permitiendo el enrutamiento mediante desencadenadores (triggers).
# Ejemplo de un broker basado en Kafka
apiVersion: eventing.knative.dev/v1
kind: Broker
metadata:
name: broker-produccion
annotations:
eventing.knative.dev/broker.class: Kafka
spec:
config:
apiVersion: v1
kind: ConfigMap
name: configuracion-kafka
namespace: knative-eventing
2.2.3 Recurso Trigger
Permite filtrar y enrutar eventos específicos a servicios de destino.
# Desencadenador con filtro por tipo de evento
apiVersion: eventing.knative.dev/v1
kind: Trigger
metadata:
name: procesar-pagos
spec:
broker: broker-produccion
filter:
attributes:
type: com.ejemplo.pago.creado
subscriber:
ref:
apiVersion: serving.knative.dev/v1
kind: Service
name: servicio-procesamiento
2.2.4 Fuentes de Eventos
Las fuentes (sources) generan eventos a partir de diferentes sistemas. Ejemplos comunes incluyen:
- PingSource: Eventos programados similar a cron.
- KafkaSource: Consume eventos de topics de Kafka.
- ApiServerSource: Monitorea cambios en recursos de Kubernetes.
# Fuente de eventos programada
apiVersion: sources.knative.dev/v1
kind: PingSource
metadata:
name: verificacion-periodica
spec:
schedule: "*/5 * * * *"
contentType: "application/json"
data: '{"accion": "verificar"}'
sink:
ref:
apiVersion: v1
kind: Service
name: servicio-monitor
2.2.5 Destinos (Sinks)
Los destinos reciben eventos y pueden ser servicios, canales u otros recursos direccionables.
2.2.6 Manejo de Fallos
Las suscripciones permiten configurar dead-letter sinks para eventos que fallen durante el procesamiento.
# Suscripción con manejo de errores
apiVersion: messaging.knative.dev/v1
kind: Subscription
metadata:
name: subscripcion-segura
spec:
channel:
apiVersion: messaging.knative.dev/v1
kind: InMemoryChannel
name: canal-principal
delivery:
deadLetterSink:
ref:
apiVersion: serving.knative.dev/v1
kind: Service
name: servicio-errores
retry: 5
backoffPolicy: "exponential"
backoffDelay: "PT2S"
subscriber:
ref:
apiVersion: serving.knative.dev/v1
kind: Service
name: servicio-procesamiento
2.2.7 Flujos de Eventos
Los flujos (flows) permiten orquestar procesamientos complejos mediante patrones paralelos y secuenciales.
2.3 Integración con Istio
Istio proporciona la capa de red para Knative, gestionando el enrutamiento de tráfico y las políticas de seguridad.
- Flujo de Tráfico y Despliegue
El tráfico sigue esta ruta genarel: Cliente → Istio Ingress → VirtualService → Servicio Knative → Activator → Cola de Pods.
# Desplegar un ejemplo básico
apiVersion: serving.knative.dev/v1
kind: Service
metadata:
name: demo-app
spec:
template:
spec:
containers:
- image: mi-repositorio/app-demo:latest
env:
- name: MENSAJE
value: "Hola Knative"
# Verificar el despliegue
kubectl get ksvc demo-app
- Gestión de Configuraciones Avanzadas
4.1 Configuración del Eventing
Los parámetros globales de Eventing se controlan mediante ConfigMaps en el namespace knative-eventing.
4.2 Configuración de Canales
Se pueden establecer canales predeterminados para toda la plataforma o por namespace.
# Configuración de canal por defecto
apiVersion: v1
kind: ConfigMap
metadata:
name: default-ch-webhook
namespace: knative-eventing
data:
default-ch-config: |
clusterDefault:
apiVersion: messaging.knative.dev/v1
kind: InMemoryChannel
namespaceDefaults:
produccion:
apiVersion: messaging.knative.dev/v1beta1
kind: KafkaChannel
- Observabilidad y Monitoreo
5.1 Trazabilidad Distribuida
La integración con sistemas como Zipkin permite seguir el recorrido de las solicitudes a través de múltiples servicios.
5.2 Registro de Logs
Se recomienda utilizar colectores como Fluent Bit para centralizar los logs de todos los componentes.
5.3 Métricas y Dashboards
La instalación de ServiceMonitors y dashboards de Grafana proporciona visibilidad del rendimiento del sistema.