Aller au contenu

GKE - Capacité réelle des nodes

Sur GKE, le node size annoncé et ce que K8S voit réellement sont 2 choses différentes. GKE réserve une part du CPU et de la RAM pour ses composants système et ce n'est pas négligeable sur les petits gabarits.

Source : GKE - Plan node sizes / Resource reservations

Chiffres valables en avril 2026

Ces valeurs reflètent la documentation GKE au moment de l'écriture de cet article. GCP peut modifier les formules de réservation à tout moment - vérifier la source officielle ci-dessus avant de dimensionner en production.

Ce qui est réservé

CPU (progressif, toujours en millicores)

  • 6% du 1er core
  • 1% du 2e core
  • 0,5% des cores 3 et 4
  • 0,25% au-delà de 4 cores

RAM (progressif également)

  • 25% des premiers 4 GiB
  • 20% des 4 GiB suivants (jusqu'à 8 GiB)
  • 10% des 8 GiB suivants (jusqu'à 16 GiB)
  • 6% des 112 GiB suivants (jusqu'à 128 GiB)
  • 2% au-delà de 128 GiB
  • +100 MiB fixe pour le seuil d'éviction pods

Capacité réelle par gabarit

Valeurs calculées pour des nodes avec autant de GiB que de vCPU (ex: 4 GiB / 4 vCPU) :

Node (GiB / vCPU) RAM réservée (GiB) RAM allouable (GiB) CPU réservé (vCPU) CPU allouable (vCPU) Efficacité RAM
4 1,10 2,90 0,08 3,92 72,5%
8 1,90 6,10 0,09 7,91 76,3%
16 2,70 13,30 0,11 15,89 83,1%
32 3,66 28,34 0,15 31,85 88,6%
64 5,58 58,42 0,23 63,77 91,3%
128 9,42 118,58 0,39 127,61 92,6%

La réservation CPU est quasi négligeable (< 0,5 vCPU dans tous les cas). La RAM, en revanche, pique sur les petits nodes : sur un 4 GiB, on perd 27,5% avant même de scheduler le moindre pod.

Implication FinOps

Privilégier des nodes plus grands améliore l'efficacité RAM (72% → 92%). Sur des clusters avec beaucoup de petits nodes, on paye pour de la RAM que K8S ne peut pas utiliser.

Voir aussi

  • GKE Spot Nodes - Réduire les coûts en complément du dimensionnement