Thursday, November 5, 2026
Home » Hey, Devs – Schluss mit manueller Bereitstellung von Objektspeicher dank des neuen COSI-Treibers von Scality

Hey, Devs – Schluss mit manueller Bereitstellung von Objektspeicher dank des neuen COSI-Treibers von Scality

Stellen Sie sich vor, Sie sind Entwickler und verwalten Anwendungen in einer Kubernetes-Umgebung. Sie brauchen Objektspeicher für wachsende Datenmengen, doch jedes Mal, wenn ein neues Projekt welchen benötigt, müssen Sie Ressourcen manuell anfordern und bereitstellen. Das verzögert nicht nur Ihren Workflow, sondern hält Sie auch von Ihren eigentlichen Entwicklungsaufgaben ab.

Traditionell war die Integration von Objektspeicher in Kubernetes ein manueller und fragmentierter Prozess – Anfragen stellen, auf Freigaben warten, Endpunkte konfigurieren und Zugriffsschlüssel verwalten. Für viele wirkt dieser Ansatz überholt in einer Welt, die von Automatisierung und Effizienz lebt.
Hier kommt der COSI-Treiber (Container Object Storage Interface) (auf Englisch) ins Spiel. COSI wurde entwickelt, um die Bereitstellung von Objektspeicher in Kubernetes zu vereinfachen und zu automatisieren, und bietet einen standardisierten, Kubernetes-nativen Ansatz. Indem COSI die Anforderungen des Objektspeichers abstrahiert, können sich Entwickler auf das Wesentliche konzentrieren – Anwendungen entwickeln und bereitstellen – ohne das ständige Ärgernis manueller Bereitstellung.

Herausforderungen manueller Kubernetes-Bereitstellung mit COSI lösen

Der COSI-Treiber von Scality (auf Englisch) geht die Herausforderung der manuellen, fragmentierten Bereitstellung von Objektspeicher in Kubernetes-Umgebungen direkt an.

COSI – ein aufkommender Standard in Kubernetes – ermöglicht die dynamische Bereitstellung von Buckets in externen Objektspeichersystemen, gesteuert über Custom Resource Definitions (CRD) innerhalb von Kubernetes. So können Entwickler benutzerdefinierte Objekte in Kubernetes genauso erstellen und verwalten wie integrierte Ressourcen.

Das Ergebnis ist ein echtes Self-Service-Modell, das den gesamten Prozess der Bucket-Bereitstellung über eine deklarative Konfiguration automatisiert. Entwickler können Ressourcen anfordern und Buckets automatisch bereitstellen lassen – alles innerhalb von Kubernetes. Das reduziert den Verwaltungsaufwand und vereinfacht ihre Arbeit erheblich.

So funktioniert es: die COSI-Architektur

COSI organisiert Kubernetes-Ressourcen in drei Domänen:

  • Admin-Domäne
  • Entwickler-Domäne
  • COSI-Subsystem

Das COSI-Subsystem fungiert als primärer COSI-Controller und verwaltet Änderungen an COSI-API-Objekten. Es bearbeitet Anfragen zum Erstellen, Aktualisieren und Löschen von Buckets sowie zur Zugriffsverwaltung. 

Jeder Kubernetes-Cluster benötigt eine Instanz des Controller-Managers, auch wenn mehrere Objektspeicheranbieter genutzt werden.

Der COSI-Workflow (API) im Überblick

Die COSI-API dreht sich um Buckets, denn der Bucket ist die Abstraktionseinheit für Objektspeicher. COSI definiert Kubernetes-APIs für deren Verwaltung.

Der Plattformadministrator steuert die verfügbaren Ressourcen, indem er Folgendes definiert:

  • BucketClass → Satz von Eigenschaften zum Erstellen von Buckets
  • BucketAccessClass → Satz von Eigenschaften für Zugangsdaten, die Zugriff auf Buckets gewähren

Entwickler stellen Anwendungen bereit und erstellen:

  • BucketClaim → Anforderung eines Objektspeicher-Buckets
  • BucketAccess → Anforderung von Zugangsdaten für den Zugriff auf den Bucket

Wenn Entwickler einen BucketClaim erstellen, verweist dieser auf eine BucketClass als Vorlage für die Ressource. Wenn sie BucketAccess anfordern, verweist dies auf eine BucketAccessClass als „Vorlage für Zugangsdaten“ und auf einen BucketClaim für die Ressourcen, auf die zugegriffen werden soll.

Das COSI-Subsystem überwacht alle COSI-Ressourcen und erstellt: 

  • Bucket → eine Darstellung des angeforderten Buckets mit seinen Eigenschaften
  • Secret → eine Kubernetes-Ressource, die die Zugriffsinformationen für den Bucket speichert

Das COSI-Subsystem nutzt den COSI-Treiber von Scality, um mit den APIs des Objektspeichersystems zu kommunizieren und dabei:

  • den Bucket zu erstellen
  • einen IAM-Benutzer und ein Schlüsselpaar aus Access Key und Secret Key für diesen Benutzer zu erstellen. Zudem wird eine Inline-Richtlinie erstellt, die diesem Benutzer Zugriff auf genau diesen Bucket gewährt.
  • diese Zugriffsdaten an Kubernetes zu übergeben

Der Anwendungs-Pod erhält Zugriffsinformationen und Status des Buckets aus den Kubernetes-Ressourcen und greift direkt über die Endpunkte des Objektspeichers auf den Bucket zu.

Prozess-Workflow des COSI-Treibers.

In Begriffen, die Kubernetes-Nutzern bereits vertraut sind: Bucket und BucketClaim entsprechen in etwa PersistentVolume und PersistentVolumeClaim aus dem Datei-/Block-Pendant StorageClass.

Dynamisch oder statisch? Passend zu Ihrem Workflow

COSI unterstützt sowohl dynamische als auch statische Bereitstellung. 

  • Dynamische Bereitstellung ermöglicht die automatische Erstellung von Buckets innerhalb von Kubernetes und den Zugriff darauf für den anfragenden Benutzer. 
  • Statische Bereitstellung ermöglicht einem Kubernetes-Benutzer die Verbindung mit einem vorhandenen Bucket, der außerhalb von Kubernetes erstellt wurde. Das ist nützlich, wenn der Entwickler Zugriff auf bereits vorhandene Daten benötigt.

Für Skalierung gebaut: Mandantenfähigkeit

COSI ist vollständig mandantenfähig und ermöglicht Kubernetes den Zugriff auf verschiedene IAM-Konten auf demselben Scality-RING-Objektspeichersystem oder auf Konten in verschiedenen RING-Speichersystemen. 

Es gibt einen Treiber pro Kubernetes-Cluster, und dieser Treiber kann mit verschiedenen IAM-Konten kommunizieren. Die Mandantenisolierung in Kubernetes erfolgt über rollenbasierte Zugriffskontrolle, mit der der Administrator Kubernetes-Aktionen festlegen kann – etwa, auf welche BucketClass-Ressourcen Anfragende bei einem Claim verweisen dürfen.

Observability inklusive: Metriken, Tracing & Monitoring

Der COSI-Treiber von Scality liefert Metriken, Traces und Logs gemäß OpenTelemetry (auf Englisch). Der Treiber stellt einen Endpunkt bereit, von dem ein Monitoring-System – typischerweise Prometheus – die Metriken abrufen kann. 

Der Treiber liefert Metriken zu internen Aufrufen, IAM-Operationen und S3-Operationsstatistiken, zum Beispiel zur Anzahl der erstellten und gelöschten Buckets und IAM-Benutzer. Außerdem lässt sich Tracing aktivieren, um alle Aktionen innerhalb des Treibers nachzuverfolgen. 

Von Entwicklern für Entwickler: agil, anpassungsfähig und in stetiger Weiterentwicklung

Als aktiver Mitwirkender der COSI-Gruppe von Kubernetes gestaltet Scality die Entwicklung der COSI-Spezifikation auf Basis realer Kundenanwendungsfälle mit.

Unsere Implementierung des COSI-Treibers ist darauf ausgelegt, sich mit den Anforderungen unserer Nutzer weiterzuentwickeln. Die Architektur des Treibers ermöglicht unabhängige Release-Zyklen, sodass wir neue Funktionen und Fehlerbehebungen bereitstellen können, ohne auf größere RING-Releases zu warten. 

Dieser agile Ansatz hält uns im Einklang mit dem sich entwickelnden COSI-Standard und ermöglicht es uns, schnell auf Kundenanforderungen zu reagieren – damit der Treiber auch dann echten Mehrwert liefert, wenn Anwendungsfälle wachsen und sich verändern.

Warum das wichtig ist: die wichtigsten Vorteile des COSI-Treibers von Scality im Überblick

  • Vereinfachte Workflows: Entwickler können Buckets direkt aus Kubernetes heraus erstellen und verwalten – ohne manuelle Anfragen und lange Wartezeiten.
  • Automatisierung: Der Treiber automatisiert die Bucket-Bereitstellung und die Benutzerverwaltung, reduziert den Verwaltungsaufwand und beschleunigt Entwicklungszyklen.
  • Mandantenfähigkeit: Unser Treiber unterstützt Mandantenfähigkeit, sodass ein Kubernetes-Cluster auf mehrere Konten und RINGs zugreifen kann – für mehr Flexibilität und Skalierbarkeit.
  • Standardkonformität: Auf Basis standardisierter S3- und IAM-Schnittstellen arbeitet unser Treiber nahtlos mit RING, ARTESCA und jedem System zusammen, das Standard-S3 und -IAM unterstützt (Support verfügbar für RING und in Kürze für ARTESCA).
  • Metriken und Tracing: Der Treiber umfasst OpenTelemetry-konforme Metriken und Tracing für robustes Monitoring und effiziente Fehlerbehebung.

Ausblick: Innovation vorantreiben, ein Bucket nach dem anderen

Wir sind überzeugt, dass der COSI-Treiber von Scality die Art und Weise, wie Entwickler mit Objektspeicher in Kubernetes arbeiten, grundlegend verbessern kann. Mit einer nahtlosen, automatisierten und entwicklerfreundlichen Erfahrung helfen wir Teams, betriebliche Reibung zu verringern und sich auf das Wichtigste zu konzentrieren: großartige Anwendungen zu entwickeln und bereitzustellen.

Mehr erfahren Sie auf unserer GitHub-Seite (auf Englisch) mit ausführlicher Dokumentation, Installationsanleitungen und allem, was Sie für den Einstieg mit dem COSI-Treiber benötigen.

Bei Scality liefern wir nicht nur Speicher – wir entwickeln Tools, die unseren Kunden die Freiheit zur Innovation geben. Der COSI-Treiber ist nur ein Beispiel dafür, wie wir die Bedürfnisse von Entwicklern und kundenorientiertes Design in den Mittelpunkt all unserer Arbeit stellen.