Runtimes

gVisor

Runtime de sandboxing Google (runsc) avec kernel en espace utilisateur. Isolation renforcée sans VM complète, intégration Kubernetes via RuntimeClass, utilisé dans Google Cloud Run.

gVisor est un runtime de conteneurs développé par Google qui intercède entre le conteneur et le kernel Linux hôte via un kernel en espace utilisateur (userspace kernel). Son binaire OCI s'appelle runsc. Au lieu que le conteneur accède directement aux appels système du kernel hôte (comme runc), gVisor intercepte ces appels via son composant "Sentry" et les réimplémente en espace utilisateur. Cela réduit drastiquement la surface d'attaque sur le kernel hôte.

Idéal pour : clusters multi-tenant où les workloads ne se font pas confiance, SaaS hébergeant du code client arbitraire, environnements exigeant un deuxième niveau d'isolation sans l'overhead complet d'une VM.


Informations essentielles

Origine : Google (open sourcé en 2018)  ·  Licence : Apache 2.0  ·  Architectures : x86_64, ARM64

Liens : Site officiel  ·  Documentation  ·  GitHub  ·  Releases

Support : gVisor publie des releases hebdomadaires ("weekly"). Une release "stable" est taguée périodiquement. Projet actif maintenu par Google.

Architecture

ComposantRôle
SentryKernel utilisateur - intercepte et réimplémente les syscalls
GoferProxy d'accès au système de fichiers de l'hôte
runscBinaire OCI - interface entre containerd et gVisor

Plateformes d'exécution

PlateformeMécanismePerformancePrérequis
systrap (défaut depuis 2023)Interception via ptrace/seccompBonne (remplace ptrace)Aucun
kvmHyperviseur minimalMeilleureKVM hardware (/dev/kvm)

La plateforme systrap a remplacé ptrace en 2023 avec de meilleures performances. La plateforme kvm reste plus rapide pour les workloads I/O intensifs.


Limitations importantes

gVisor ne supporte pas tous les appels système Linux. Les limitations les plus notables :

  • /proc et /sys partiellement implémentés - certaines applications lisant ces pseudo-FS peuvent échouer
  • Performances I/O réseau et disque inférieures à runc (overhead du Gofer pour les accès fichiers)
  • Modules kernel et accès direct au hardware impossibles
  • ptrace sur les processus dans le sandbox limité
  • Vérifier la compatibilité des applications avant déploiement en production

Installation

Sur chaque nœud Kubernetes

# Dépôt APT officiel
curl -fsSL https://gvisor.dev/archive.key | sudo gpg --dearmor -o /usr/share/keyrings/gvisor-archive-keyring.gpg

echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/gvisor-archive-keyring.gpg] \
  https://storage.googleapis.com/gvisor/releases release main" | \
  sudo tee /etc/apt/sources.list.d/gvisor.list

sudo apt-get update && sudo apt-get install -y runsc

# Vérifier
runsc --version

Intégration avec containerd

1. Configurer containerd

# Ajouter dans /etc/containerd/config.toml
[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runsc]
  runtime_type = "io.containerd.runsc.v1"
sudo systemctl restart containerd

2. Créer la RuntimeClass Kubernetes

# runtimeclass-gvisor.yaml
apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
  name: gvisor
handler: runsc
kubectl apply -f runtimeclass-gvisor.yaml

3. Utiliser gVisor dans un pod

apiVersion: v1
kind: Pod
metadata:
  name: nginx-sandboxed
spec:
  runtimeClassName: gvisor
  containers:
  - name: nginx
    image: nginx:alpine
kubectl apply -f pod.yaml

# Vérifier que gVisor est actif dans le conteneur
kubectl exec nginx-sandboxed -- dmesg | head -5
# Doit afficher "gVisor..." dans le kernel

Configuration avancée

Activer la plateforme KVM (meilleures performances)

# /etc/containerd/config.toml
[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runsc.options]
  TypeUrl = "io.containerd.runsc.v1.options"
  ConfigPath = "/etc/runsc/config.toml"
# /etc/runsc/config.toml
platform = "kvm"
# Vérifier que KVM est disponible
ls -la /dev/kvm
# Les nœuds doivent avoir KVM accessible (bare-metal ou VM avec nested virt)

Mise à jour

sudo apt-get install --only-upgrade runsc
sudo systemctl restart containerd

Troubleshooting

Pod en erreur après création

kubectl describe pod <nom>
# Chercher les événements d'erreur runtime

# Tester runsc directement
runsc --platform=systrap do /bin/echo hello

Application incompatible avec gVisor

# Vérifier les syscalls non supportés
kubectl logs <pod>
# Erreurs "operation not permitted" ou "function not implemented"

# Consulter la liste de compatibilité
# https://gvisor.dev/docs/user_guide/compatibility/

Performances dégradées

# Passer à la plateforme KVM si disponible
ls -la /dev/kvm

# Vérifier l'overhead via les métriques du pod
kubectl top pod <nom>

Commandes utiles

# Tester runsc localement
runsc --version
runsc --platform=systrap do /bin/ls /

# Inspecter un conteneur gVisor via crictl
sudo crictl inspect <container-id> | grep -i sandbox

# Vérifier les RuntimeClasses disponibles
kubectl get runtimeclass

Ressources

Newsletter · 2 000+ abonnés

Reste au courant de ce qui bouge en prod

RudeOps veille devops hebdo, droit au but.

Gratuit · Sans spam · Désinscription en un clic