GiB in MiB umrechnen

Ein Gibibyte sind 1.073.741.824 Byte, rund 7 % mehr als ein Gigabyte. Windows misst in Gibibyte, schreibt aber „GB" daran — darin besteht das ganze Rätsel des verschwundenen Speicherplatzes.

Ein Mebibyte sind 1.024 Kibibyte, also 1.048.576 Byte. Linux-Werkzeuge und Speicherangaben meinen in aller Regel das, auch wenn „MB" dasteht.

In dieser Richtung wird multipliziert, und zwar mit einer ganzen Zahl: ein Gibibyte sind 1.024 Mebibyte, exakt. 1.024 ist die Definition und keine Messung, die knapp danebenlag.

Damit ist es eine der wenigen Umrechnungen, die sich im Kopf lohnen, und das Ergebnis lässt sich prüfen: rechne zurück, und du musst exakt auf der Ausgangszahl landen, ohne Rest, den man wegerklären müsste.

Ein GiB sind 1.024 der Einheit darunter, ein GB sind 1.000. Auf dieser Seite ist das der Unterschied zwischen 1024 MiB und 953,6743 MiB — 7,4 % —, und der Abstand wächst mit jeder Stufe. Bei einem Foto ist er ein Rundungsfehler, bei einer Festplatte ein sichtbares Stück.

Darin besteht das Rätsel um den fehlenden Speicherplatz vollständig. Eine Platte, die als GB verkauft wird, enthält exakt das, was draufsteht; Windows teilt anschließend durch 1.024 statt durch 1.000, behält den dezimalen Namen bei und zeigt deshalb eine kleinere Zahl an. macOS rechnet seit Version 10.6 in den dezimalen Einheiten und zeigt die Zahl von der Verpackung — dieselbe Platte, zwei Rechner, zwei Größen, und verloren geht dabei nichts.

Ein resources.limits.memory: 512Mi in einer Kubernetes-Manifestdatei ist eindeutig binär — das i in Mi steht genau dafür. Die Kapazität eines Clusters wird dagegen fast immer in Gibibyte diskutiert: „der Node hat 32 GiB", „das Deployment braucht insgesamt 6 GiB über alle Replicas". Zwischen diesen beiden Ebenen liegt exakt diese Umrechnung, und sie kommt bei jedem neuen Deployment mindestens einmal vor.

Der Faktor ist glatt: 1 GiB sind 1.024 Mi. Ein Pod-Limit von 4Gi entspricht 4.096Mi, und beides ist in Kubernetes gültige Schreibweise für dieselbe Zahl — 4Gi ist lediglich die kompaktere Form. Wer aus Gewohnheit 4G statt 4Gi schreibt, weist dagegen nur 3,73 GiB zu, weil Kubernetes das unmarkierte G als dezimales Gigabyte liest.

Kubernetes unterscheidet konsequent zwischen den binären Suffixen Ki, Mi, Gi und den dezimalen k, M, G, und beide sind gültig — sie meinen nur nicht dasselbe. memory: 512M sind 512.000.000 Byte, memory: 512Mi sind 536.870.912 Byte, ein Unterschied von 4,9 Prozent. Bei einem eng bemessenen Limit ist das der Unterschied zwischen einem Pod, der läuft, und einem, der wegen Out-of-Memory neu gestartet wird.

In der Praxis schreiben die meisten Teams reflexhaft Mi und Gi, weil das die Suffixe sind, die in jedem Beispiel aus der Kubernetes-Dokumentation stehen — aber genau diese Gewohnheit macht ein versehentliches M schwer auffindbar, weil es syntaktisch gültig bleibt und nur eine kleinere Zahl bedeutet, keinen Fehler.

Ein Node-Manager rechnet Kapazität in Mebibyte gegen, und dort wird die Gibibyte-Zahl des Blechs zum ersten Mal in die kleinere Einheit übersetzt. Ein Node mit 32 GiB Arbeitsspeicher meldet dem Scheduler nicht die volle Zahl — davon werden System-Reserven für Kubelet, Betriebssystem und, falls konfiguriert, ein Eviction-Threshold abgezogen, alles in Mi ausgedrückt und alles vor der ersten Pod-Zuweisung.

Die zuverlässige Reihenfolge ist deshalb: die GiB-Zahl des Nodes in Mi umrechnen, die dokumentierten Systemreserven abziehen, und erst den Rest auf requests und limits der Pods verteilen. Wer stattdessen die dezimal umgerechnete MB-Zahl verwendet, plant mit fast fünf Prozent mehr Kapazität, als der Node tatsächlich für Pods freigibt — eine Lücke, die sich erst zeigt, wenn der letzte Pod nicht mehr scheduled wird.

Ein Limit von 1.500Mi ist syntaktisch vollkommen gültig und funktioniert — es teilt sich nur nicht glatt durch die Seitengröße des Kernels und durch keinen gängigen cgroup-Grenzwert. Ein Reviewer, der auf ein YAML-Manifest schaut, erkennt an einer runden Zahl wie 2.048Mi sofort, dass sie 2 GiB entspricht; bei 2.000Mi muss erst nachgerechnet werden, ob das gemeint war oder ein Tippfehler aus einer dezimalen Quelle ist.

Das ist mehr als Ästhetik, sobald mehrere Teams an denselben Manifesten arbeiten. Ein Cluster, in dem jedes Limit ein Vielfaches von 1.024 ist, lässt sich im Kopf gegen die Node-Kapazität aufsummieren; ein Cluster mit einer Mischung aus 1.500Mi, 2.000Mi und 4.096Mi verlangt für jede Kapazitätsprüfung einen Taschenrechner.

Ein Pod mit requests.memory: 2Gi und limits.memory: 4Gi bekommt vom Scheduler nur die 2.048Mi der Anfrage garantiert reserviert, darf aber bis 4.096Mi wachsen, bevor der OOM-Killer eingreift. Diese Differenz ist auf einem stark ausgelasteten Cluster genau der Spielraum, den der Scheduler nutzt, um mehr Pods auf einen Node zu packen, als die Summe aller Limits erlauben würde — dieselbe Übercommit-Logik wie bei einer virtuellen Maschine, nur pro Container statt pro Gast.

Sichtbar wird das erst, wenn mehrere Pods gleichzeitig gegen ihr Limit wachsen wollen: Dann verliert einer von ihnen, unabhängig davon, welcher zuerst gestartet wurde, und der Grund steht selten in der Fehlermeldung des Pods selbst. kubectl top pod gegen die eingetragenen Limits zu prüfen, ist der schnellste Weg, einen Verdacht in diese Richtung zu bestätigen oder auszuräumen.