Spectro Cloud Palette Edge
Autarker Peripherie-Dirigent
Veröffentlicht in Ausgabe 07/2026 - TESTS
Branchen wie Industrie, Einzelhandel oder Telekommunikation sehen sich aktuell unweigerlich mit dem Buzzword "Edge Computing" konfrontiert. Hinter der Marketinghülle verbirgt sich eine reale Herausforderung: Daten dort zu verarbeiten, wo sie entstehen, statt sie um die halbe Welt zu schicken. Das spart Bandbreite, reduziert Latenzen und löst Datenschutzfragen im Rahmen der DSGVO. Die Kehrseite hat jeder Admin schon erlebt, der versuchte, Softwareupdates in einer Filiale, auf einem Schiff oder einer Bohrinsel auszurollen: Die Verwaltung verteilter Systeme ist deutlich aufwendiger als die eines konsolidierten Rechenzentrums.
In diese Lücke stoßen Plattformen für das Management verteilter Kubernetes-Installationen. Während sich Red Hat mit OpenShift samt MicroShift-Variante positioniert hat und SUSE mit Rancher Prime und RKE2 den Markt bedient, tritt Spectro Cloud aus Santa Clara mit der Plattform "Palette" und der dazugehörigen Edge-Variante als Herausforderer an.
Anders als manche Mitbewerber richtet sich Palette explizit an große Infrastrukturen mit Tausenden von Edge-Standorten; der Hersteller wirbt mit Tests bei bis zu 30.000 Edge-Knoten pro Installation. Die genutzten Technologien lesen sich wie ein Who-is-Who der Cloudarchitektur: Cluster-API, Kairos und der von Spectro Cloud gepflegte Edge-Builder CanvOS sind nur einige Beispiele. Im Fokus dieses Tests stand die On-Premises-Installation – die SaaS-Variante erwähnen wir nur am Rande und die Air-Gap-Variante sprechen wir gesondert am Ende des Artikels an.
Branchen wie Industrie, Einzelhandel oder Telekommunikation sehen sich aktuell unweigerlich mit dem Buzzword "Edge Computing" konfrontiert. Hinter der Marketinghülle verbirgt sich eine reale Herausforderung: Daten dort zu verarbeiten, wo sie entstehen, statt sie um die halbe Welt zu schicken. Das spart Bandbreite, reduziert Latenzen und löst Datenschutzfragen im Rahmen der DSGVO. Die Kehrseite hat jeder Admin schon erlebt, der versuchte, Softwareupdates in einer Filiale, auf einem Schiff oder einer Bohrinsel auszurollen: Die Verwaltung verteilter Systeme ist deutlich aufwendiger als die eines konsolidierten Rechenzentrums.
In diese Lücke stoßen Plattformen für das Management verteilter Kubernetes-Installationen. Während sich Red Hat mit OpenShift samt MicroShift-Variante positioniert hat und SUSE mit Rancher Prime und RKE2 den Markt bedient, tritt Spectro Cloud aus Santa Clara mit der Plattform "Palette" und der dazugehörigen Edge-Variante als Herausforderer an.
Anders als manche Mitbewerber richtet sich Palette explizit an große Infrastrukturen mit Tausenden von Edge-Standorten; der Hersteller wirbt mit Tests bei bis zu 30.000 Edge-Knoten pro Installation. Die genutzten Technologien lesen sich wie ein Who-is-Who der Cloudarchitektur: Cluster-API, Kairos und der von Spectro Cloud gepflegte Edge-Builder CanvOS sind nur einige Beispiele. Im Fokus dieses Tests stand die On-Premises-Installation – die SaaS-Variante erwähnen wir nur am Rande und die Air-Gap-Variante sprechen wir gesondert am Ende des Artikels an.
| Produkt |
Kubernetes-Management-Plattform mit deklarativem Ansatz.
|
|---|---|
| Hersteller |
Spectro Cloud
|
| Preis |
Spectro Cloud berechnet für Bare-Metal- und Edge-Instanzen eine jährliche Flatrate, die sich nach der physischen Dimensionierung des jeweiligen Servers richtet: "Palette Edge" ist die Lizenz für Edge-Geräte, Industrie-PCs, Außenstellen oder sehr kleine Gateways und startet bei 250 US-Dollar pro Gerät. Hingegen liegt die "Palette Enterprise Bare-Metal"-Lizenz bei typischen 2-Socket-Servern im Bereich von 600 bis 1200 US-Dollar pro Node und Jahr.
SaaS rechnet sich nach Kilo-Core-Hours (kCh). Für Edge-Hosts liegt die jährliche Pauschale im Einstiegstarif (100 bis 499 kCh/Monat) bei rund 4000 US-Dollar/Monat und bei großen Deployments (über 5000 kCh/Monat) bei etwa 200.000 US-Dollar/Monat.
|
| Systemanforderungen |
Abhängig von der Anzahl der Worker-Nodes definiert der Anbieter drei Kategorien:
Small: Drei Knoten mit je acht CPU-Cores, 16 GByte RAM, 60 GByte Storage (maximal 1000 verwaltete Worker-Nodes auf rund 100 Clustern).
Medium: Drei Knoten mit je 16 CPU-Cores, 32 GByte RAM, 100 GByte Storage (maximal 3000 Worker-Nodes auf 300 Clustern).
Large: Drei Knoten mit je 32 CPU-Cores, 64 GByte RAM, 120 GByte Storage (maximal 5000 Worker-Nodes auf rund 500 Clustern).
|
| Technische Daten |
Deklarative Profile und autonome Agenten am Edge
Als "Kubernetes-Management-Plattform" verwaltet Palette den Lebenszyklus beliebig vieler Kubernetes-Cluster – von der initialen Provisionierung über die Konfiguration der Add-ons bis hin zu Day-2-Operationen wie Patches und Upgrades. Die Plattform unterstützt sowohl die Public-Cloud-Hyperscaler einschließlich der Managed-Kubernetes-Dienste (EKS bei AWS, AKS bei Azure und GKE bei Google) als auch virtualisierte und Bare-Metal-Umgebungen vor Ort. Edge-Standorte bedient der Anbieter unter dem Namen "Palette Edge" mit speziellen Werkzeugen.
Das zentrale Konzept hinter Palette sind die "Cluster Profiles". Statt Kubernetes-Cluster manuell aus Einzelkomponenten zusammenzusetzen, beschreiben Admins in einem Profil deklarativ den vollständigen Stack: Betriebssystem der Hardware, Kubernetes-Distribution, CNI-Plug-in für das Netzwerk, CSI-Treiber für den Storage und die gewünschten Add-ons. Das Cluster-Profil fungiert als Bauplan: Wer mehrere Cluster aus demselben Profil erzeugt, erhält identische Setups – ein wichtiger Vorteil bei dreistelligen Standortzahlen. Unter der Haube setzt Palette auf die offene Cluster-API-Implementierung der CNCF, die Spectro Cloud um eigene Komponenten ergänzt.
Architektonisch trennt Palette konsequent zwischen Management Plane und Control Plane. Während die Management Plane als zentraler Anlaufpunkt für Konfiguration, RBAC und Monitoring dient, läuft auf jedem verwalteten Cluster ein lokaler Agent. Dieser übernimmt die Durchsetzung hinterlegter Richtlinien ("Policys") sowie das automatisierte Beheben von Fehlkonfigurationen ("Self-Healing") eigenständig. Bricht die Verbindung zur Management Plane ab, läuft der Edge- Cluster weiter und versucht, die im Profil beschriebene Soll-Konfiguration aufrechtzuerhalten. Die Kommunikation zwischen den Microservices der Management Plane übernimmt ein gRPC-basierter Message Broker.
Palette Edge baut auf diesem Fundament auf. Da Edge-Hosts oft Bare-Metal-Geräte sind, die per Post an Filialen versandt und dort von technisch nicht geschultem Personal angeschlossen werden, hat der Hersteller das Konzept "EdgeForge" entwickelt. Mit dieser Toolchain lassen sich vorkonfigurierte Boot-Images bauen, die das Gerät nach dem Systemstart automatisch in den Soll-Zustand versetzen. Im Hintergrund arbeitet CanvOS, ein quelloffenes Build-Tool von Spectro Cloud, das auf Earthly und BuildKit aufsetzt. Die erzeugten Provider-Images basieren auf Kairos, einer Linux-Meta-Distribution mit Immutable-Eigenschaft. Diese wird von der CNCF derzeit als Sandbox-Projekt geführt und maßgeblich von Spectro Cloud gesponsert. Hadron, eine schlanke Linux-Basis aus der Kairos-Familie, steht alternativ für Edge-Hosts mit besonderen Anforderungen bereit.
Nicht alle Installationswege sind ohne Hürden
Für die Installation im eigenen Rechenzentrum stehen drei Wege zur Verfügung. Der klassische Weg ist die Bereitstellung über eine VMware-OVA. Im Test rollten wir das fertige Appliance-Image in einer vSphere-Umgebung aus. Die OVA stand in zwei Varianten bereit: Im Stand-alone- Modus lief Palette auf einer einzelnen virtuellen Maschine (geeignet für Proof- of-Concepts), während im Enterprise- Modus ein Drei-Knoten-HA-Cluster für eine ausfallsichere Management Plane startete.
Der zweite Weg richtet sich an IT-Verantwortliche mit bestehendem Kubernetes-Cluster. Per Helm-Chart lässt sich die Management Plane direkt dorthin deployen. Im Test zeigte sich, dass der Ziel-Cluster dafür strikte Voraussetzungen erfüllen muss: Ein ausreichend dimensionierter Worker-Pool war zwingend erforderlich und der Cert-Manager durfte noch nicht installiert sein, da Palette eine eigene Variante mitbrachte. Zudem waren K8s-Admin-Rechte für die Installation nötig. Die Installation selbst ließ sich zwar theoretisch über drei Helm-Befehle anstoßen, in der Testpraxis mussten wir jedoch die "values.yaml"-Datei der Palette-Installation in zahlreichen Parametern manuell anpassen – allen voran die Konfiguration von MongoDB, die als zentraler Datenspeicher dient.
Die dritte und neuere Option ist die "Palette Management Appliance". Diese liegt als bootfähige ISO-Datei vor, die direkt auf Bare-Metal startet und das System selbstständig installiert. Das Verfahren fungiert als "Plattform-Bootstrapper" und eignet sich für Zweigstellen ohne eigene Virtualisierungsinfrastruktur. Im Test stellten wir jedoch fest, dass sich dieser Installationsweg noch in der Tech-Preview-Phase befindet. Für geschäftskritische Umgebungen empfiehlt sich daher weiterhin der Weg über OVA oder Helm.
Deklarative Cluster-Profile verhindern Konfigurations-Drift
Nachdem wir Palette eingerichtet hatten, beschäftigten wir uns vor allem mit den Cluster-Profilen. Dies wird auch ein Admin im Tagesgeschäft so erleben, denn sie sind das Herzstück der Plattform – und gleichzeitig der Punkt, an dem sich Palette am deutlichsten von Konkurrenten wie Rancher Prime oder OpenShift abhebt. Während Rancher in seiner klassischen Variante eher imperativ arbeitet und einzelne Cluster Schritt für Schritt aufbaut, geht Palette einen rein deklarativen Weg: Der IT-Verantwortliche definiert einmalig, wie sein idealer Cluster aussieht, und die Plattform sorgt anschließend dafür, dass jeder daraus erzeugte Cluster diesen Vorgaben entspricht – inklusive stündlicher Reconciliation-Loops, die Abweichungen erkennen und korrigieren.
In der Praxis besteht ein Cluster-Profil aus mehreren Schichten, die aufeinander aufbauen. Die unterste Ebene ist das Betriebssystem, in der Edge-Variante typischerweise eines der von Spectro Cloud bereitgestellten Provider-Images auf Kairos- oder Ubuntu-Basis. Darauf folgt die Kubernetes-Schicht – wahlweise mit dem hauseigenen Palette eXtended Kubernetes (PXK), mit RKE2, mit K3s oder mit der seit Palette 4.7 unterstützten Canonical Kubernetes 1.32 LTS, die mit zwölf Jahren Support gerade für Edge- Standorte interessant ist, deren Lifecycle nicht nach wenigen Jahren enden soll. Auf der Kubernetes-Schicht setzen schließlich die Add-ons auf: CNI, CSI, Service-Mesh, Monitoring, Logging, Backup, Sicherheitsscanner und alle weiteren benötigten Komponenten. Spectro Cloud listet hier mehr als 50 vorvalidierte Integrationen auf. Komplementär integrieren Admins eigene Dienste per Helm oder als Operator, was sich vor allem für unternehmensspezifische Anwendungen anbietet.
Die Stärke dieses Ansatzes zeigte sich im Test insbesondere, sobald ein Update anstand. Statt uns auf jeden Cluster einzeln einzuloggen und den Patch dort manuell anzuwenden, änderten wir einfach die Version im Cluster-Profil. Palette rollte das Update anschließend automatisiert an alle damit verknüpften Cluster aus – auf Wunsch parallel und mit einer Zero-Downtime-Strategie. Bei einer Flotte von hundert Filialen mit jeweils einem kleinen Edge-Cluster verkürzt dieses Verfahren den Patchday von Wochen auf wenige Stunden. Wer die Konfiguration eines Clusters außerhalb von Palette manuell änderte, sah diese Änderungen spätestens bei der nächsten Reconciliation-Loop wieder zurückgedreht. Dies erwies sich im Test als zweischneidiges Schwert: Der Mechanismus verhindert zwar ungewollten Konfigurations-Drift, blockiert aber auch das schnelle, temporäre Patchen im Notfall.
Logistische Deployment- Probleme elegant gelöst
Der eigentliche Charme von Palette Edge zeigt sich beim Ausrollen von Geräten an entfernten Edge-Standorten. Klassische Kubernetes-Plattformen setzen voraus, dass vor Ort bereits ein vorbereiteter Knoten bereitsteht. Für Filialen ohne technisches Personal vor Ort ist dieses Modell unpraktisch, da dort niemand Bare-Metal-Server per IPMI konfigurieren kann. Spectro Cloud löst dieses Problem über den EdgeForge-Workflow.
Im Test spielten wir diese Pipeline durch, die im Wesentlichen zwei Artefakte erzeugte: einen Edge-Installer als ISO-Datei und ein Provider-Image als OCI-Con-tainer. Die ISO-Datei schrieben wir auf einen USB-Stick. Sobald der Edge-Host davon bootete, installierte sich das System selbstständig auf der Hardware, registrierte sich bei unserer zentralen Palette-Instanz oder lief im lokalen Modus weiter, falls die Verbindung zur Management Plane fehlte. Dieser Mechanismus entzerrte in der Testpraxis logistische Abhängigkeiten, da die Erstinstallation auch ohne aktiven Netzwerk-Uplink funktionierte.
Die Provider-Images brachten das Betriebssystem und die Kubernetes-Distribution in einer unveränderlichen, A/B-fähigen Form mit – sprich: Das System nutzt zwei redundante Partitionen, sodass ein Update im Hintergrund auf der inaktiven Partition landet und der Host bei einem Fehler beim anschließenden Reboot automatisch auf den funktionierenden Altbestand zurückfällt. Dadurch standen stets zwei Systemabbilder bereit. Schlug ein Update in der Ferne fehl, startete der Host einfach vom zweiten, funktionsfähigen Image, was die Gefahr von Totalausfällen minimierte. Vorbereitete Edge-Hosts müssen vor Ort nur noch an Strom und Netzwerk angeschlossen werden.
Die Konfiguration der ISO-Datei nahmen wir über zwei Files vor: eine ARG-Datei mit Build-Parametern wie der Kubernetes-Version und eine "user-data"-Datei im "cloud-init"-Format für IP-Adressen, Proxys und Registrierungstokens. Um den fehleranfälligen manuellen Aufbau dieser YAML-Dateien zu umgehen, nutzten wir das mit Version 4.7 eingeführte "Appliance Studio". Die grafische Oberfläche führte uns zügig durch den Konfigurationsprozess und gab die fertigen Dateien aus, was die Einstiegshürde spürbar senkte.
Zusätzlich fügten wir im Test der Edge-Installer-ISO ein optionales Content Bundle hinzu, das sämtliche Container-Images für eine bestimmte Cluster-Profilkonfiguration enthielt. Der so präparierte Host baute den Cluster komplett lokal auf – ohne Verbindung zu einer externen Registry. Dies ist für Air-Gap-Szenarien oder instabile WAN-Verbindungen optimal. Für kleine Edge-Setups mit nur zwei Knoten aktivierten wir zudem die "Two-Node- HA"-Option, die Ausfallsicherheit bietet, ohne das Budget mit einem dritten Masterknoten zu belasten.
Autarker Betrieb auch bei dauerhaftem Offlinestatus
Viele Konkurrenzprodukte vernachlässigen die Frage, wie ein Edge-Host konfiguriert wird, wenn die Verbindung zur Management Plane dauerhaft fehlt. Palette bot uns im Test dafür zwei Betriebsmodi an: den zentral verwalteten Standardmodus und den lokalen Modus. Letzterer ist für isolierte Umgebungen wie Schiffe oder Bohrinseln gedacht.
Nach dem Systemstart griffen wir über das lokale Webinterface ("Local UI") direkt auf den autarken Edge-Host zu. Wir importierten Cluster-Profile, legten lokale Cluster an und rollten Workloads aus, ohne dass eine Verbindung nach außen nötig war. Mehrere physische Hosts ließen sich so zu einem vollständig autonomen Cluster zusammenschließen. Das Local UI ist im Funktionsumfang gegenüber der zentralen Management Plane reduziert, deckt aber alle Kernaufgaben ab. Der Hersteller dokumentiert diese Einschränkungen transparent.
Air-Gap-Installation für regulierte Branchen
Eine Variante der Self-Hosted-Installation ist der Air-Gap-Modus. Hier läuft die gesamte Plattform vollständig ohne Internetverbindung – ein Szenario, das im Verteidigungssektor, im Gesundheitswesen und bei Betreibern kritischer Infrastrukturen zum Pflichtprogramm gehört. Den Anfang machte im Test eine spezielle Air-Gap-OVA, die der Hersteller auf Anfrage über den Support bereitstellte. Sie brachte eine vollständige Spectro-Cloud-Repository-Umgebung mit, die im Kern aus einer Harbor-Installation bestand. Harbor diente dabei als OCI-Registry für die beiden zentralen Verzeichnisse "spectro-packs" und "spectro-images", aus denen sich Palette bediente. Bemerkenswert war die Wahl der Container-Runtime: Während die regulären OVAs auf Docker setzen, kam in der Air-Gap-Variante ab Werk Podman zum Einsatz.Bei der Einrichtung ließen sich entweder selbst-signierte Zertifikate vom Setup-Skript erzeugen oder eigene SSL-Zertifikate im base64-PEM-Format einbringen. Der FQDN des Zertifikats musste zwingend mit dem Hostnamen oder der IP-Adresse der Air-Gap-Support-VM übereinstimmen – in der Testpraxis ein häufiger Stolperstein. Eine Erleichterung hat Spectro Cloud mit Palette 4.7 nachgeschoben: das "Artifact Studio". Über dieses Self-Service-Portal ließen sich im Test Helm-Charts und Provider-Images selektiv herunterladen, mit digitalen Signaturen verifizieren und über "zstandard"-komprimierte Bundles in die Air-Gap-Umgebung transferieren.
Hohe Skalierbarkeit bringt spürbaren Overhead mit sich
In unserem Test überzeugte Palette vor allem durch den klaren Fokus auf die Skalierbarkeit. Die dezentrale Architektur, bei der die Management Plane bewusst kein Single Point of Failure darstellt, bewährte sich im Betrieb. Auch die enge Verzahnung von Betriebssystem-Layer und Kubernetes-Schicht über die Cluster-Profile erleichterte das parallele Ausrollen von Kernelupdates auf verteilten Knoten erheblich.
Ein weiterer Vorteil ist die Distributionsneutralität. Im Gegensatz zu OpenShift, das eng an CoreOS gebunden ist, ließ uns Palette im Test freie Hand bei der Wahl der Basis. Wir konnten Ubuntu, RHEL oder openSUSE ebenso nutzen wie K3s, RKE2 oder die Canonical-LTS-Variante. Zudem importierten wir bestehende Test-Cluster und konvertierten deren Konfiguration nachträglich in ein Cluster-Profil, was den Migrationspfad von Rancher oder OpenShift vereinfacht.
Allerdings erkauften wir uns diese Flexibilität mit einer hohen Komplexität unseres Systems. Für kleine Setups mit nur wenigen Microservices ist Palette in der Praxis schlicht überdimensioniert. Die Modellierung der Profile erfordert eine steile Lernkurve. Zudem wies die ansonsten solide Dokumentation des Herstellers bei tiefergehenden Detailfragen Lücken auf, sodass wir im Testverlauf mehrmals den Support kontaktieren mussten. Auch die im Vergleich zu Schwergewichten wie Red Hat oder SUSE geringere Unternehmensgröße von Spectro Cloud sollten risikobewusste IT-Entscheider berücksichtigen.
Funktional ist Palette Edge im Vergleich zu Mitbewerbern gut aufgestellt. Rancher Prime bietet kein vergleichbares Konzept für das Management des darunterliegenden OS-Layers und stößt bei sehr großen Edge-Flotten an Skalierungsgrenzen des zentralen Management-Servers. Open-Shift mit MicroShift deckt das Szenario zwar ab, schränkt jedoch die Distributionswahl ein und ist lizenzseitig meist teurer. Reine Open-Source-Projekte wie Akri oder KubeEdge liefern zwar Werkzeuge für Edge-Workloads, bieten aber kein ganzheitliches Management-Framework. Für das konsistente Verwalten und Updaten einer heterogenen Edge-Flotte stellt Palette Edge somit eine ungewöhnlich runde Infrastruktur bereit.
Fazit
Spectro Cloud Palette Edge präsentierte sich im Test als ein bemerkenswert ausgereiftes Produkt. Die lokale Variante bewies, dass der Hersteller die Anforderungen versteht, die eine große Anzahl von Edge-Standorten mitbringen – und dies ohne Vendor-Lock-in bei Betriebssystem oder Kubernetes-Distribution. Das deklarative Modell der Cluster-Profile, die strikte Trennung von Management und Control Plane sowie die durchdachte EdgeForge-Toolchain heben die Plattform deutlich vom Wettbewerb ab.
Demgegenüber steht eine Komplexität, die in kleineren Umgebungen schnell zur Hürde wird. Wer nur einen einzelnen, mittelgroßen Cluster betreiben möchte, greift zum falschen Werkzeug und zahlt drauf. Zudem setzt die Inbetriebnahme der Self-Hosted-Variante fundiertes Know-how in den Bereichen Helm, Cert-Manager, MongoDB und Hypervisoren voraus. Wer diese Einstiegshürden überwindet, erhält jedoch eine hochgradig skalierbare Plattform, die sich im Edge- Bereich erfolgreich gegen die etablierte Konkurrenz behauptet.
(jp)
Skalierbarkeit
|
9
|
Edge-Funktionalität
|
8
|
Neutralität bei Distributionen
|
8
|
Bedienung und Lernkurve
|
6
|
Installationsoptionen
|
8
|
|
Die Details unserer Testmethodik finden Sie unter https://www.it-administrator.de/testmethodik
|
|