Le total du CPU et de la mémoire Kubernetes d'un coup d'œil.

Un millicore (le suffixe m, comme dans 250m) est un millième de cœur de CPU, si bien que 1000m équivalent à un vCPU / hyperthread. Kubernetes mesure le CPU dans ces unités fractionnaires car un Pod a rarement besoin d'un cœur entier — 250m signifie un quart de cœur de part garantie. Un nombre simple comme 0,5 équivaut à 500m ; le calculateur normalise tout en millicores afin que les requests et les totaux s'alignent.

Mi est un mébioctet — 1024 × 1024 = 1 048 576 octets — tandis que MB désigne généralement un mégaoctet de 1 000 000 d'octets. Les suffixes de mémoire Ki / Mi / Gi de Kubernetes sont binaires (puissances de 1024) ; les suffixes sans i K / M / G sont décimaux (puissances de 1000). Ils sont proches mais pas égaux : 1 Gi vaut environ 1,074 GB. Les mélanger sous-provisionne silencieusement, c'est pourquoi le calculateur garde les deux familles distinctes et convertit les deux en octets exacts.

Une request est ce que le scheduler réserve pour un conteneur — elle garantit cette quantité de CPU et de mémoire et c'est ce que le bin-packing utilise pour placer le Pod sur un nœud. Une limit est le plafond strict : le CPU au-dessus de la limit est throttlé, et la mémoire au-dessus de la limit fait OOM-killer le conteneur. Les requests pilotent la planification de capacité ; les limits bornent le rayon d'impact. Le calculateur totalise les deux pour que vous puissiez dimensionner un node pool en fonction des requests et surveiller le plafond en fonction des limits.

C'est invalide — le serveur d'API Kubernetes rejette un conteneur dont la limit est inférieure à sa request, car on ne peut pas plafonner une ressource en dessous de la quantité que l'on a garantie. Le calculateur signale toute ligne où la limit normalisée passe sous la request normalisée, pour que vous repériez l'erreur ici plutôt que dans un apply en échec ou un rejet par un admission webhook.

Non. Chaque quantité est analysée, normalisée et totalisée à 100 % côté client dans votre onglet — il n'y a pas de serveur, pas de compte et aucune journalisation. Vous pouvez coller en toute sécurité des blocs de ressources issus de manifestes internes ; rien n'est téléversé.

La request et la limit totales d'un pod sont la somme des valeurs individuelles de tous ses conteneurs. Multipliez ce total par pod par le nombre de replicas pour obtenir ce que réserve l'ensemble du déploiement. Par exemple, 3 replicas à 250m de CPU et 256Mi de mémoire chacun totalisent 750m de CPU et 768Mi. Saisissez les valeurs par conteneur et le nombre de replicas dans le calculateur et il calcule instantanément les totaux du workload.

Mi (mébioctets) et Gi (gibioctets) sont des unités binaires où 1024Mi équivalent à 1Gi. Divisez les Mi par 1024 pour obtenir des Gi, et multipliez les Gi par 1024 pour obtenir des Mi. Un Gi vaut 1 073 741 824 octets, soit légèrement plus que 1G (1 000 000 000 octets). Le calculateur normalise toutes les valeurs de mémoire en octets exacts en interne, si bien que les saisies en Mi et en Gi se comparent et se totalisent correctement sans aucune conversion manuelle.

Oui, le calculateur est entièrement gratuit. Il s'exécute intégralement dans votre navigateur, sans serveur, sans compte et sans téléversement de données — vous n'avez pas besoin de vous inscrire ni de vous connecter. Vous pouvez coller en toute sécurité des valeurs de ressources issues de manifestes internes, car rien ne quitte votre appareil.

Basez les requests sur l'utilisation p95 ou p99 observée, recueillie avec kubectl top sur une période représentative de 24 heures, puis fixez les limits à environ deux à cinq fois la valeur de la request. Des requests trop élevées gaspillent la capacité de nœud planifiable ; trop basses, elles affament le pod sous charge et provoquent du CPU throttling ou des OOMKills. Utilisez le calculateur pour totaliser les valeurs par conteneur sur l'ensemble des replicas avant d'inscrire des chiffres dans un manifeste.