Schluss mit geratenen Resource-Requests — VPA und Goldilocks im Recommend-Only-Modus

Auf vier ARM-Boards ist jedes Mebibyte gezählt — trotzdem habe ich CPU- und Memory-Requests jahrelang aus dem Bauch gesetzt. Der Vertical Pod Autoscaler beobachtet jetzt den echten Verbrauch und schreibt Empfehlungen, Goldilocks macht sie als Dashboard lesbar. Bewusst nur als Ratgeber: VPA fasst keinen einzigen Pod von selbst an.

Resource-Requests und -Limits habe ich in meinem Lab lange so gesetzt, wie man es eben macht: ein paar Werte aus dem Bauch, 100m/128Mi als Reflex, und dann nie wieder angefasst. Auf einer dicken Cloud ist das egal. Auf vier RK1-Boards mit endlichem ARM-Speicher ist es das nicht: Setze ich zu hoch, verschenke ich Kapazität, die kein anderer Pod mehr bekommt, weil der Scheduler den Request reserviert, nicht den Verbrauch. Setze ich zu niedrig, holt mir der OOM-Killer nachts einen Pod ab oder die CPU wird in den Boden gethrottlet. Beides hatte ich. Was mir fehlte, war kein Gefühl, sondern eine Zahl.

Ceph auf vier ARM-Boards — das Speicher-Fundament unterm Lab

Fast jeder Lab-Artikel sagt beiläufig ceph-block oder ceph-filesystem — erklärt wurde es nie. Hier ist die Schicht darunter: Rook-Ceph, das die NVMe von vier RK1-Boards zu einem fehlertoleranten Speicher bündelt. Mit der echten CephCluster-Config, dem OSD-pro-NVMe-Mapping, den drei StorageClasses — und den Day-2-Kriegsgeschichten, wenn ein MON-Quorum oder eine OSD wegbricht.

In nahezu jedem Beitrag taucht es beiläufig auf: storageClass: ceph-block, eine RWO-PVC, ein copyMethod: Snapshot. Erklärt habe ich diese Schicht nie — dabei funktioniert ohne sie nichts. Das hier ist das Fundament: Rook -Ceph, das die NVMe-SSDs der Turing-Pi-/RK1-Boards zu einem fehlertoleranten Speicher zusammenfasst.

Die Hardware-Basis meines Labs: Turing Pi, RK1 und Talos

Vom Kickstarter-Board mit vier Raspberry-Pi-Modulen zum RK1-Cluster mit NVMe — und warum am Ende Talos Linux darauf läuft

Jedes Lab braucht ein Stück Blech, auf dem es steht. Bei mir ist das ein Turing Pi -Board — ein Mini-ITX-Träger für vier Compute-Module, den ich seinerzeit in der Kickstarter-Kampagne mitfinanziert habe. Die Idee, einen kleinen, lautlosen und stromsparenden Cluster aus austauschbaren Knoten in einem einzigen Gehäuse zu betreiben, hat mich sofort überzeugt. Diese Geschichte handelt davon, wie aus der ersten, etwas naiven Bestückung über ein paar Umwege die heutige Basis von hydra wurde.