Die erste Ausgabe von Blockstor ist verf\u00fcgbar \u2013 einem offenen Verwaltungssystem f\u00fcr verteilte Blockspeicher f\u00fcr Kubernetes, das Datenreplikation \u00fcber DRBD erm\u00f6glicht. Blockstor ist \u00fcber die REST API mit LINSTOR kompatibel und kann ohne \u00c4nderungen in der bestehenden Kunden-\u00d6kosystem, einschlie\u00dflich des Befehlszeilen-Tools linstor, des CSI-Treibers, des Piraeus Operators, des ha-Controllers und der Bibliothek golinstor, eingesetzt werden. Das Projekt ist eine vollst\u00e4ndig eigenst\u00e4ndige (Clean-Room) Implementierung in der Programmiersprache Go, die keinen Code des Originals verwendet. Der Code wird unter der Apache 2.0 Lizenz verbreitet und entwickelt sich im Rahmen der Cozystack-Plattform (CNCF Sandbox-Projekt).<\/p>\n
Der Autor des Projekts ist \u0410\u043d\u0434\u0440\u0435\u0439 \u041a\u0432\u0430\u043f\u0438\u043b (@kvaps), Gr\u00fcnder von Cozystack und Mitglied der gemeinn\u00fctzigen Organisation Piraeus, in deren Rahmen der Operator und der CSI-Treiber LINSTOR f\u00fcr Kubernetes entwickelt werden. Der Autor ist in der Kubernetes-Community als Promoter von LINSTOR bekannt und hat mehrfach technische Vortr\u00e4ge zu diesem Thema gehalten. Urspr\u00fcnglich wurde die Entwicklung als kleine \u201cFreitags\u201d-Initiative gedacht, verwandelte sich aber letztendlich in etwa 20 Tage ununterbrochene Arbeit. Momentan entwickelt sich das Projekt als Forschungsprojekt, wird jedoch perspektivisch als m\u00f6gliche Alternative zu LINSTOR als standardm\u00e4\u00dfiges Speichersystem in Cozystack angesehen.<\/p>\n
Als Gr\u00fcnde f\u00fcr die Schaffung des neuen Projekts werden die Schwierigkeiten bei der Wartung des Originalprojekts und der \u00dcbertragung von \u00c4nderungen in das Hauptprojekt sowie architektonische Einschr\u00e4nkungen von LINSTOR genannt. Das Originalprojekt verwendet ein \u201crequest-based\u201d Modell zur Verarbeitung von Echtzeitanfragen, das bei gro\u00dfen Skalierungen Probleme aufzeigt, w\u00e4hrend der deklarative Reconciliation-Ansatz von Kubernetes und das Framework controller-runtime nach Ansicht des Autors deutlich besser f\u00fcr den Aufbau von verteilten Systemen geeignet sind.<\/p>\n
Im Gegensatz zu LINSTOR basiert die Architektur von Blockstor vollst\u00e4ndig auf dem Ansatz von Kubernetes controller-runtime. Die Konfiguration und der aktuelle Zustand des Systems werden in Form von Kubernetes CRD-Objekten dargestellt, und das System ist nicht daf\u00fcr ausgelegt, au\u00dferhalb eines Kubernetes-Clusters zu arbeiten.<\/p>\n
Zu den Hauptfunktionen von Blockstor geh\u00f6ren:<\/p>\n
Ein Merkmal des Projekts war die aktive Nutzung von KI-Tools w\u00e4hrend der Entwicklung. Fast der gesamte Code wurde mit Hilfe von Claude Code (Modell Opus 4.7) von Anthropic erstellt. Die Entwicklung fand fast rund um die Uhr \u00fcber einen Zeitraum von etwa 20 Tagen statt. Zu bestimmten Zeiten arbeiteten bis zu 60 KI-Agenten gleichzeitig, und der gesamte Entwicklungsdialog bestand aus etwa 1320 Anfragen des Autors und rund 36.000 Antworten des Modells im Rahmen einer einzigen kontinuierlichen Sitzung.<\/p>\n
Es entstanden 1500 Commits, in denen 83.000 Codezeilen f\u00fcr die Implementierung und weitere 137.000 Codezeilen f\u00fcr Tests ben\u00f6tigt wurden. Sch\u00e4tzungen zufolge wurden insgesamt etwa 18,9 Milliarden Token verbraucht, wobei die \u00e4quivalente Kosten f\u00fcr ein solches Volumen bei Nutzung von API-Tarifen ungef\u00e4hr 40.000 Dollar betragen w\u00fcrde.<\/p>\n
Der Autor plante urspr\u00fcnglich eine fast vollst\u00e4ndig autonome Entwicklung durch das KI-Modell, jedoch erforderte die komplexe Logik von DRBD st\u00e4ndige menschliche Intervention. Am schwierigsten waren die Szenarien der DRBD-Zustands\u00fcbereinstimmung, die Arbeit mit dem Generation Identifier (GI), das \u00dcberspringen der anf\u00e4nglichen Synchronisation und die Behandlung von Split-Brain-Szenarien.<\/p>\n
Da das urspr\u00fcngliche LINSTOR unter der GPL-Lizenz vertrieben wird, konnte der Code nicht direkt verwendet werden. Der Gro\u00dfteil der Implementierung wurde auf der Analyse von API-Vertr\u00e4gen, dem Verhalten von Tools, dem Python-Client von LINSTOR sowie von lizenzierten kompatiblen Projekten, einschlie\u00dflich piraeus-operator und CSI-Driver, erstellt.<\/p>\n