Migration v2.7

Nouveautes

Envoy Gateway API (remplacement nginx Ingress)

L’Ingress Controller nginx est remplace par Envoy Gateway via le standard Kubernetes Gateway API.

Chaque aspect du trafic est gere par une ressource K8s dediee :

Concern	Ressource Gateway API
Routage HTTP	HTTPRoute
TLS/HTTPS	Gateway + cert-manager
CORS	SecurityPolicy
IP Whitelist	SecurityPolicy
Timeout, retry, rate limit	BackendTrafficPolicy
Gzip	ClientTrafficPolicy
Redirections regex (Lua)	EnvoyExtensionPolicy

Aucune modification du deployer.yaml n’est necessaire pour les fonctionnalites existantes. Le deployer genere automatiquement les bonnes ressources selon la plateforme cible.

Note

La migration est transparente : les memes proprietes network du deployer.yaml produisent des resources Gateway API au lieu d’annotations Ingress nginx.

Labels personnalises

Les labels sont maintenant un dictionnaire key: value (au lieu d’un tableau d’objets).

# Avant (v2.6)
labels:
  - name: team
    value: team-services

# Apres (v2.7)
labels:
  team: team-services
  cost-center: cc-1234

Les labels sont propages sur :

• Tous les pods Kubernetes (deployments, workers, cronjobs)
• Les ressources GCP (Pub/Sub, buckets, etc.) via default_labels

Breaking change

Le format tableau [{name, value}] n’est plus supporte. Convertir en Record<string, string>.

Les valeurs doivent etre en minuscules (contrainte GCP) : cc-1234 et non CC-1234.

PodMonitoring Prometheus

Scrape automatique des metriques Prometheus via GMP (Google Managed Prometheus).

prometheusScrape:
  enabled: true
  port: 3000        # defaut : port du network principal
  path: /metrics     # defaut
  interval: 30s      # defaut

Un PodMonitoring est cree pour les applications Web uniquement.

Lifecycle rules sur les buckets

Les buckets applicatifs supportent maintenant les lifecycle rules GCS :

storage:
  app:
    - name: uploads
      lifecycleRules:
        - action: Delete
          age: 90
        - action: SetStorageClass
          age: 30
          storageClass: NEARLINE

Defaults resources env-aware

Les resources CPU/memoire par defaut sont maintenant adaptees a l’environnement :

Parametre	Production	Staging / Lab / Preview
CPU request	100m	10m
Memory request	128Mi	64Mi

Le VPA ajuste automatiquement en staging. Les projets qui ont besoin de plus peuvent toujours definir resourcesRequests explicitement.

Cloud Functions : cpu, memory, concurrency et runtime par defaut

Les champs cpu et memory de cloudFunctions sont maintenant reellement appliques sur la ressource Terraform (available_cpu et available_memory de Cloud Run v2). Avant, les valeurs etaient ignorees et GCP utilisait ses propres defaults.

Le runtime par defaut passe de nodejs10 (EOL 2021) a nodejs22 (LTS). Impact nul en pratique : les apps qui utilisaient le default avaient deja leur deploiement rejete par GCP.

Nouveau champ max_instance_request_concurrency pour controler le nombre de requetes concurrentes par instance :

cloudFunctions:
  - name: my-fn
    source: ./fn
    cpu: "1"
    memory: 1024M
    max_instance_request_concurrency: 50

Attention au re-scaling

Si vous aviez cpu/memory dans votre deployer.yaml sans qu’ils soient appliques, le prochain deploiement les appliquera reellement. Verifier que les valeurs correspondent bien a vos besoins avant de deployer.

DNS www automatique

Les enregistrements DNS www.* sont maintenant crees automatiquement quand fromToWWW: true (defaut). Corrige un bug ou seule la redirection HTTP etait configuree sans l’enregistrement DNS correspondant.

Breaking changes

1. Labels : tableau → dictionnaire

Action requise : modifier le format dans deployer.yaml.

labels:
  - name: team
    value: my-team
labels:
  team: my-team

Si vous n’utilisez pas de labels, aucune action necessaire.

2. Resources par defaut reduites en staging

Les CPU/memory requests sont plus bas en non-prod (10m/64Mi au lieu de 100m/128Mi). Le VPA compense automatiquement, mais si votre application a besoin d’un minimum garanti au demarrage :

resourcesRequests:
  cpu: 100m
  memory: 128Mi

3. Redirections regex : groupes optionnels PCRE

Les patterns PCRE avec groupes optionnels (...)? sont maintenant correctement geres. Le deployer genere automatiquement 2 checks Lua (avec et sans le groupe).

Avant : ^/login(\?.*)?$ ne matchait pas /login (seulement /login?...). Apres : /login et /login?foo sont tous les deux rediriges.

Si vos redirections regex fonctionnaient deja, aucune action necessaire. Si elles ne marchaient pas sur certains paths, elles devraient maintenant fonctionner.

Guide de migration

Etape 1 — Mettre a jour les labels

Chercher dans votre deployer.yaml :

grep -A2 "labels:" deployer.yaml

Si le format est un tableau d’objets, convertir en dictionnaire.

Etape 2 — Verifier les resources

Si votre application crash au demarrage avec les nouveaux defaults (10m CPU), ajouter des resourcesRequests explicites.

Etape 3 — Tester en preview

Deployer sur une branche de feature pour valider :

# Le deployer detecte automatiquement l'environnement preview
git push origin feat/migration-test

Verifier :

• L’application demarre correctement
• Les redirections fonctionnent
• Le CORS est correct (si applicable)
• Les metriques Prometheus remontent (si prometheusScrape active)

Etape 4 — Deployer en staging puis production

Aucune action specifique — le deployer gere la transition automatiquement.

---

Voir aussi : Valeurs par defaut | Labels & Monitoring | Gateway API