Serverless sur OpenShift avec OpenShift Serverless (Knative)

Serverless sur OpenShift : pourquoi ?

Le modèle Serverless ne signifie pas “sans serveur” — il signifie que vous ne gérez plus la capacité. Les applications scalent automatiquement en fonction de la charge, jusqu’à zéro instance en l’absence de trafic, et redémarrent en quelques secondes à la première requête.

OpenShift Serverless est la distribution Red Hat de Knative, qui se décompose en deux composants :

Knative Serving — déploiement de services HTTP avec scale-to-zero et gestion des révisions
Knative Eventing — architecture événementielle (event sources, brokers, triggers)

Avantages en entreprise :

Réduction des coûts — ressources consommées uniquement lors d’utilisation
Déploiements Blue/Green et Canary natifs via le split de trafic entre révisions
Intégration Kafka, AMQ pour les architectures event-driven

Installation de l’Operator OpenShift Serverless

# Créer le namespace dédié
oc create namespace openshift-serverless

# Installer l'Operator
cat <<EOF | oc apply -f -
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: serverless-operator
  namespace: openshift-serverless
spec:
  channel: stable
  name: serverless-operator
  source: redhat-operators
  sourceNamespace: openshift-marketplace
EOF

Vérifier l’installation :

oc get csv -n openshift-serverless | grep serverless

Activer Knative Serving

Knative Serving gère le cycle de vie des services HTTP serverless.

apiVersion: operator.knative.dev/v1beta1
kind: KnativeServing
metadata:
  name: knative-serving
  namespace: knative-serving
spec:
  config:
    autoscaler:
      # Délai avant de scaler à zéro (en secondes)
      scale-to-zero-grace-period: "60s"
      # Fenêtre de mesure pour l'autoscaler
      stable-window: "60s"
      # Algorithme : kpa (Knative Pod Autoscaler) ou hpa
      pod-autoscaler-class: kpa.autoscaling.knative.dev
    defaults:
      # Concurrence max par pod par défaut
      container-concurrency: "100"
  ingress:
    kourier:
      enabled: true    # Ingress léger intégré à OpenShift

Déployer un Knative Service (ksvc)

Un Service Knative (ksvc) est l’unité de déploiement principale. Il crée automatiquement une Route et une Configuration.

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: mon-api
  namespace: production
spec:
  template:
    metadata:
      annotations:
        # Nombre minimum de pods (0 = scale-to-zero activé)
        autoscaling.knative.dev/min-scale: "0"
        # Nombre maximum de pods
        autoscaling.knative.dev/max-scale: "20"
        # Cible de requêtes concurrentes par pod
        autoscaling.knative.dev/target: "50"
        # Délai scale-to-zero spécifique au service
        autoscaling.knative.dev/scale-to-zero-pod-retention-period: "30s"
    spec:
      containerConcurrency: 50
      timeoutSeconds: 300
      containers:
        - image: quay.io/mon-org/mon-api:v1.2.0
          ports:
            - containerPort: 8080
              protocol: TCP
          env:
            - name: ENV
              value: production
          resources:
            requests:
              cpu: 100m
              memory: 256Mi
            limits:
              cpu: 1000m
              memory: 512Mi
          readinessProbe:
            httpGet:
              path: /health
              port: 8080
            initialDelaySeconds: 3

Vérifier le déploiement :

oc get ksvc mon-api -n production
# NAME      URL                                          LATESTCREATED   LATESTREADY   READY
# mon-api   https://mon-api-production.apps.cluster.com  mon-api-00001   mon-api-00001 True

Révisions et split de trafic (Blue/Green, Canary)

Chaque déploiement crée une nouvelle Révision. Le split de trafic entre révisions est déclaratif.

Déploiement Canary : 10% vers la nouvelle version

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: mon-api
  namespace: production
spec:
  traffic:
    - revisionName: mon-api-00001    # Version stable
      percent: 90
      tag: stable
    - revisionName: mon-api-00002    # Nouvelle version
      percent: 10
      tag: canary
  template:
    metadata:
      name: mon-api-00002
    spec:
      containers:
        - image: quay.io/mon-org/mon-api:v1.3.0

Chaque tag crée une URL spécifique pour les tests directs :

https://stable-mon-api-production.apps.cluster.com
https://canary-mon-api-production.apps.cluster.com

Basculement complet vers la nouvelle version

kn service update mon-api \
  --traffic mon-api-00002=100 \
  -n production

Knative Eventing : architecture événementielle

Knative Eventing permet de connecter des sources d’événements à des services Knative de façon découplée.

Composants principaux

Composant	Rôle
EventSource	Produit des événements (Kafka, cron, API…)
Broker	Bus d’événements central
Trigger	Filtre et route les événements vers un subscriber
Channel	Canal de communication asynchrone

Exemple complet : consommer des événements Kafka

# 1. Installer le KafkaSource
apiVersion: sources.knative.dev/v1beta1
kind: KafkaSource
metadata:
  name: kafka-source
  namespace: production
spec:
  consumerGroup: knative-group
  bootstrapServers:
    - kafka-broker.kafka.svc.cluster.local:9092
  topics:
    - commandes.nouvelles
  sink:
    ref:
      apiVersion: eventing.knative.dev/v1
      kind: Broker
      name: default
---
# 2. Créer un Broker
apiVersion: eventing.knative.dev/v1
kind: Broker
metadata:
  name: default
  namespace: production
---
# 3. Créer un Trigger pour router vers le service de traitement
apiVersion: eventing.knative.dev/v1
kind: Trigger
metadata:
  name: trigger-commandes
  namespace: production
spec:
  broker: default
  filter:
    attributes:
      type: com.entreprise.commande.nouvelle
  subscriber:
    ref:
      apiVersion: serving.knative.dev/v1
      kind: Service
      name: service-traitement-commandes

Source Cron (PingSource)

# Déclencher un service toutes les heures
apiVersion: sources.knative.dev/v1
kind: PingSource
metadata:
  name: cron-rapport
  namespace: production
spec:
  schedule: "0 * * * *"
  contentType: "application/json"
  data: '{"action": "generate-report"}'
  sink:
    ref:
      apiVersion: serving.knative.dev/v1
      kind: Service
      name: service-rapports

Scale-to-zero et cold start

Le principal inconvénient du scale-to-zero est le cold start : la première requête après une période d’inactivité attend que le pod démarre.

Stratégies pour réduire le cold start

1. Maintenir un pod minimum actif pour les services critiques :

annotations:
  autoscaling.knative.dev/min-scale: "1"    # Jamais à zéro

2. Optimiser l’image container :

Utiliser des images légères (UBI Micro, distroless)
Pré-charger les dépendances au démarrage
Utiliser GraalVM Native Image pour les applications Java

3. Configurer le scale-up aggressif :

annotations:
  autoscaling.knative.dev/scale-up-delay: "0s"
  # Garder le pod actif 2 minutes après la dernière requête
  autoscaling.knative.dev/scale-to-zero-pod-retention-period: "120s"

Observabilité des services Knative

# Installer la CLI kn
# Sur RHEL/Fedora
sudo dnf install openshift-clients

# Lister les services et révisions
kn service list -n production
kn revision list -n production

# Voir les logs d'un service
kn service logs mon-api -n production --follow

# Décrire les détails d'autoscaling
kn service describe mon-api -n production

Métriques Prometheus exposées par Knative :

activator_request_count — requêtes en cours
autoscaler_desired_pods — pods souhaités par l’autoscaler
revision_request_latencies — latences par révision

Intégration avec Tekton Pipelines

OpenShift Pipelines (Tekton) s’intègre nativement avec Serverless pour des déploiements CI/CD automatisés :

# Task Tekton pour mettre à jour un Knative Service
apiVersion: tekton.dev/v1beta1
kind: Task
metadata:
  name: deploy-knative-service
spec:
  params:
    - name: service-name
    - name: image
    - name: namespace
  steps:
    - name: deploy
      image: gcr.io/knative-releases/knative.dev/client/cmd/kn
      script: |
        kn service update $(params.service-name) \
          --image $(params.image) \
          --namespace $(params.namespace) \
          --traffic @latest=100

Conclusion

OpenShift Serverless apporte le modèle serverless au cœur des entreprises, sur des infrastructures on-premise ou hybrides. Le scale-to-zero réduit drastiquement la consommation de ressources, le split de trafic natif entre révisions simplifie les déploiements progressifs, et Knative Eventing permet de construire des architectures event-driven découplées. Combiné à Tekton Pipelines et ArgoCD, il forme un socle complet pour une plateforme applicative moderne sur OpenShift.