Millicores
- Entrée
- 500m
- Résultat
- 0,5 cœur
1000m vaut un cœur. Une demande de 100m signifie que l'ordonnanceur réserve un dixième de cœur.
Calculateur de ressources Kubernetes
Convertissez millicores et suffixes de mémoire, multipliez par le nombre de réplicas et voyez la classe QoS que le kubelet attribuera. Le tableau des suffixes rend concret l'écart entre Mi et M, d'où viennent les dépenses invisibles et les OOMKill surprises.
Charges d'exemple
Classe QoS: BurstableLa limite CPU vaut 5.0× la demandeLa limite mémoire vaut 2.0× la demande
| Par pod | × 3 réplicas | |
|---|---|---|
| CPU request | 0.1 | 0.3 |
| CPU limit | 0.5 | 1.5 |
| Mémoire request | 128Mi | 384Mi |
| Mémoire limit | 256Mi | 768Mi |
Extrait de manifeste
resources:
requests:
cpu: 100m
memory: 128Mi
limits:
cpu: 500m
memory: 256Mi
# 3 replicas require
# cpu 0.3 cores requested, 1.5 at the limit
# memory 384Mi requested, 768Mi at the limitMi n'est pas M
Kubernetes accepte les suffixes binaires et décimaux, et ils ne valent pas la même chose.
| Suffixe | Octets | Suffixe | Octets | Écart |
|---|---|---|---|---|
| 1Ki | 1,024 | 1k | 1,000 | +2.4% |
| 1Mi | 1,048,576 | 1M | 1,000,000 | +4.9% |
| 1Gi | 1,073,741,824 | 1G | 1,000,000,000 | +7.4% |
Ainsi 1G vaut 1G tandis que 1Gi vaut 1Gi — environ 7 % de plus.
Tout se passe dans votre navigateur. Cette page est un fichier statique. Ce que vous saisissez reste dans l'onglet, n'est jamais envoyé à un serveur et disparaît à la fermeture — coller un vrai jeton ou une vraie configuration ne présente donc aucun risque.
Quand cela sert
- Pour dimensionner un Deployment et savoir quelle part de la capacité du cluster le nombre de réplicas va réclamer.
- Pour comprendre pourquoi un pod est Burstable alors que vous le vouliez Guaranteed.
- Pour traduire une limite mémoire de docker-compose dans les unités qu'attend un manifeste.
Exemples concrets
Le suffixe qui coûte cher
- Entrée
- 1000M contre 1Gi
- Résultat
- 1 000 000 000 contre 1 073 741 824 octets
Écrire M au lieu de Mi donne au conteneur environ 7 % de mémoire en moins que prévu.
QoS Guaranteed
- Entrée
- requests == limits
- Résultat
- Guaranteed
Uniquement quand les demandes CPU et mémoire égalent exactement leurs limites. Tout le reste est Burstable et se fait évincer plus tôt sous pression.
Là où l'on se trompe
Écrire M en pensant Mi
512M font 512 000 000 octets ; 512Mi en font 536 870 912. Le manifeste est valide dans les deux cas, donc rien ne prévient — le pod reçoit simplement moins de mémoire que le nombre ne le suggère.
Fixer une limite CPU très au-dessus de la demande
Une limite plusieurs fois supérieure à la demande laisse le pod s'emballer, puis le bride brutalement dès que le nœud est chargé. Bien des pics de latence pris pour des bugs applicatifs viennent du throttling CFS.
Omettre complètement les demandes
Un pod sans demandes est BestEffort et sera le premier évincé quand un nœud manque de ressources. Il ne donne rien à l'ordonnanceur pour planifier, et les nœuds se remplissent de façon déséquilibrée.
Questions fréquentes
Quelle différence entre une demande et une limite ?
La demande est ce que l'ordonnanceur réserve au placement du pod ; la limite est le plafond imposé par le noyau à l'exécution. Les demandes décident où le pod atterrit, les limites quand il est bridé ou tué pour dépassement mémoire.
Comment la classe QoS est-elle déterminée ?
Guaranteed signifie que chaque conteneur a des demandes CPU et mémoire égales à ses limites. BestEffort signifie aucune demande ni limite. Tout l'entre-deux est Burstable, ce qui compte car l'éviction suit cet ordre.
Faut-il vraiment fixer une limite CPU ?
Beaucoup d'équipes fixent les limites mémoire mais laissent le CPU libre : dépasser une limite mémoire tue le conteneur, dépasser une limite CPU ne fait que brider — souvent pour un coût en latence pire que de laisser le pod utiliser la capacité inutilisée.