Skip to content

Cloud Run : le disque éphémère en disponibilité générale

Le disque éphémère de Cloud Run est en disponibilité générale : tailles, quotas, prérequis gen2, configuration gcloud et limites à connaître.

Publié le 3 min de lecture
Cloud Run : le disque éphémère en disponibilité générale

Les conteneurs serverless de Google ont enfin un vrai espace disque local. Depuis le 4 novembre 2026, le disque éphémère de Cloud Run est en disponibilité générale, selon les notes de version de Google Cloud. La fonction permet de monter, sur une instance de service, de job ou de worker pool, un volume qui ne vit que le temps de cette instance. Pour les traitements de gros fichiers, c'est une alternative au stockage en mémoire, plus coûteux.

Ce que fait le disque éphémère

Le principe est simple : on choisit une taille et un point de montage, et Cloud Run attache à chaque instance un disque qui lui est dédié. D'après la documentation, ces disques sont préformatés en ext4 et chiffrés avec des clés propres à chaque instance. Ils ne sont partagés ni entre instances, ni entre révisions.

Contrepartie attendue : toutes les données sont définitivement supprimées à l'arrêt de l'instance, que ce soit après un plantage, une réduction du nombre d'instances ou une bascule du trafic vers une nouvelle révision. Avant l'arrêt, Cloud Run envoie un signal SIGTERM, puis SIGKILL dix secondes plus tard. Google recommande donc de copier les données utiles au fil de l'eau vers un stockage persistant comme Cloud Storage, plutôt que de compter sur ce délai.

L'application lit et écrit sur le volume avec les API de fichiers habituelles de son langage : un programme qui attend un système de fichiers local fonctionne sans modification.

Tailles, quotas et prérequis

La documentation fixe plusieurs limites :

  • chaque volume mesure de 1 à 100 Gio ;
  • une instance dispose par défaut de 10 Gio au total, davantage sur demande d'augmentation de quota ;
  • une instance accepte au maximum 10 volumes ;
  • le quota de projet est de 0 Gio par région au départ, porté à 100 Gio au premier déploiement d'une ressource utilisant un disque éphémère dans cette région.

Ce quota régional est partagé par les instances en cours d'exécution : la taille du disque multipliée par le nombre maximal d'instances ne doit pas le dépasser. Avec un disque de 10 Gio et une limite de 100 Gio, on plafonne ainsi à dix instances.

Côté prérequis, la fonction exige l'environnement d'exécution de deuxième génération (gen2) et est proposée dans toutes les régions Cloud Run. La facturation dépend de la taille provisionnée et de la durée d'exécution de l'instance, en plus du processeur, de la mémoire et du trafic sortant.

Configuration et pièges

Avec gcloud, on ajoute un volume de type ephemeral-disk via --add-volume, puis on le monte avec --add-volume-mount, en précisant --execution-environment=gen2. En YAML, il s'agit d'un volume emptyDir avec medium: Disk et une sizeLimit ; Terraform suit la même logique dans la ressource google_cloud_run_v2_service. Il est impossible de monter un volume sous /dev, /proc ou /sys.

La documentation signale un piège : un déploiement depuis la console peut convertir le disque en volume en mémoire, ce qui fait consommer de la RAM à chaque écriture et peut provoquer des erreurs de mémoire. Il faut alors redéployer avec gcloud ou YAML en indiquant explicitement medium: Disk. Pour accélérer les transferts vers Cloud Storage, Google conseille aussi d'activer le Direct VPC egress et l'accès privé à Google.

D'autres nouveautés récentes

Cette disponibilité générale s'ajoute à d'autres annonces de la plateforme : les jobs Cloud Run avec GPU peuvent désormais tourner jusqu'à 12 heures (en préversion), et le runtime Python 3.15 est en préversion depuis le 2 novembre. Une évolution qui suit de près la fin d'un autre runtime : Cloud Run a coupé Node.js 20 le 30 octobre. Pour les nouveautés du langage, voir notre article sur Python 3.15.

Articles liés

Le runtime Node.js 20 de Cloud Run est décommissionné le 30 octobre 2026 : plus de déploiement possible. Ce qui change et comment migrer.
Identity Service for GKE n'est plus pris en charge à partir de GKE 1.37. Google bloque les mises à jour des clusters concernés : comment migrer.
Autoscaling Amazon ECS : AWS publie des mesures sur les métriques à 20 secondes, qui déclenchent la montée en charge en 86 s au lieu de 363 s.