Die neueste Version der freien PaaS-Plattform Cozystack 1.4, die auf Kubernetes basiert, ist jetzt verfügbar. Das Projekt zielt darauf ab, Hosting-Anbietern eine fertige Plattform und einen Rahmen zum Erstellen von privaten und öffentlichen Clouds zu bieten. Die Plattform wird direkt auf Servern installiert und deckt alle Aspekte der Infrastrukturvorbereitung für die Bereitstellung verwalteter Dienste ab. Cozystack ermöglicht das Starten und Bereitstellen von Kubernetes-Clustern, Datenbanken und virtuelle Maschinen. Der Quellcode der Plattform ist auf GitHub verfügbar und wird unter der Apache-2.0-Lizenz verbreitet.
Die Plattform umfasst eine Open-Source-Netzwerkinfrastruktur (Fabric) auf Basis von Kube-OVN, verwendet Cilium für die Organisation des Servicenetzwerks und MetalLB für die Ankündigung von Diensten nach außen. Der Speicher wird auf LINSTOR implementiert, wobei ZFS als Basisschicht für den Speicher und DRBD für die Replikation angeboten wird. Es gibt einen vorinstallierten Überwachungsstack auf Basis von VictoriaMetrics und Grafana. Um zu starten virtuellen Maschinen Die KubeVirt-Technologie ermöglicht den Betrieb klassischer virtueller Maschinen direkt in Kubernetes-Containern und bietet bereits alle notwendigen Integrationen mit dem Cluster-API zur Bereitstellung von verwalteten Kubernetes-Clustern innerhalb eines „physischen“ Kubernetes-Clusters. Innerhalb der Plattform können Sie mit einem Klick Kafka, FerretDB, PostgreSQL, Cilium, Grafana, Victoria Metrics und weitere Dienste bereitstellen.
Die wichtigsten Neuerungen in Cozystack 1.4.0:
- Eine neue Verwaltungsoberfläche, basierend auf dem Projekt cozystack-ui, wurde vorgestellt. Der alte Stack openapi-ui und BFF wurde durch ein Frontend mit React 19 und TypeScript ersetzt, das direkt mit der Kubernetes API arbeitet. Darüber hinaus bietet die Benutzeroberfläche jetzt Unterstützung für dynamische VNC-WebSocket-URLs für virtuelle Maschinen, Runtime-Branding über ConfigMap, das Lesen von ApplicationDefinition für den Anwendungsbereich und die Umleitung alter Adressen /openapi-ui/*.
- Für Worker-Knoten in tenantbasierten Clustern wurde ein permanentes Speichersystem implementiert. Virtuelle Maschinen der Worker-Knoten verwenden jetzt PVC-Datenträger über KubeVirt dataVolumeTemplates anstelle von emptyDisk. Dadurch bleiben kubelet-Zertifikate, kubeconfig und der Zustand von containerd nach einem Neustart der virtuellen Maschine erhalten. Das Feld ephemeralStorage wurde in diskSize umbenannt, und eine Konfiguration für die storageClass auf NodeGroup-Ebene wurde hinzugefügt. Während der Migration werden die alten Werte automatisch umgewandelt.
- Ein neues Schema für Ressourcen-Presets wurde analog zu den Typen von virtuellen Maschinen bei Cloud-Anbietern hinzugefügt. Die Presets werden im Format . beschrieben, wobei die Serien t1, c1, s1, u1 und m1 unterschiedliche Verhältnisse von CPU und Speicher definieren und die Größen von nano bis 4xlarge variieren. Insgesamt sind 40 Varianten verfügbar. Alte Preset-Namen werden als veraltete Aliase beibehalten und ohne Änderung der tatsächlichen CPU- und Speicherkapazitäten automatisch migriert.
- Das deklarative Backup-System für verwaltete Anwendungen wurde erweitert. Der Backup-Controller hat Strategien für PostgreSQL, MariaDB, ClickHouse und FoundationDB erhalten. BackupClass, Plan, BackupJob und RestoreJob werden unterstützt, einschließlich geplanter und einmaliger Backups, Wiederherstellung vor Ort und Wiederherstellung in eine Kopie. Daten werden in ein S3-kompatibles Objektspeicher abgelegt, und die Anmeldeinformationen werden über Kubernetes Secret übertragen.
- Ein optionales Systempaket hami mit HAMi 2.8.1 wurde hinzugefügt, um den gemeinsamen Zugriff auf NVIDIA GPUs in Tenant-Clustern zu ermöglichen. Benutzer-Workloads können Ressourcen von nvidia.com/gpu, nvidia.com/gpumem und nvidia.com/gpucores anfordern, was es ermöglicht, vGPUs zwischen mehreren Pods zu verteilen. Die Aktivierung erfolgt über den Parameter hami.enabled und erfordert den NVIDIA GPU Operator.
- Es gibt eine zentrale Einstellung publishing.proxyProtocol zur Aktivierung des PROXY-Protokolls auf Hosts mit ingress-nginx. Bei Aktivierung wird automatisch Ouroboros bereitgestellt, der das Problem des Hairpin-NAT für Anfragen aus dem Cluster an seine öffentlichen Namen löst. Für Tenant-Cluster ist die Zusatzoption addons.ouroboros.enabled vorgesehen.
- Im cozystack-operator wurden die Einstellungen für die HelmRelease-Generierung hinzugefügt: Intervall, Wiederholungsintervall, Installationszeitlimit, Upgrade-Zeitlimit und maximale Historie. Die Wiederholstrategie wurde auf RetryOnFailure umgestellt, und für einzelne Anwendungen kann das Zeitlimit über die Annotation release.cozystack.io/helm-install-timeout festgelegt werden. Dies beseitigt eine Reihe von Problemen beim kalten Start von Tenant-Clustern.
- Für die Worker-Knoten des Tenant-Kubernetes werden die Kubernetes Ressourcenvorräte für CPU und Speicher automatisch berechnet. Die Annotations des Cluster-Autoscalers spiegeln jetzt die zugewiesenen Ressourcen wider, nicht das gesamte Volumen an CPU und Speicher.
- Die Basisbestandteile der Plattform wurden aktualisiert: Talos 1.13.0, cert-manager 1.20.2, Cilium 1.19.3, NVIDIA GPU Operator 26.3.1, etcd-operator 0.4.3, KubeVirt 1.8.2, cozy-proxy 0.3.0, linstor-csi 1.10.6. Neu hinzugefügte Pakete sind HAMi 2.8.1 und Ouroboros 0.7.2.
- Die Diagnostik wurde verbessert: cozyreport sammelt jetzt Informationen über Flux, cert-manager, die Host-Umgebung, Application, ApplicationDefinition und Tenant-Ressourcen und erstellt außerdem eine summary.txt mit einer kurzen Zusammenfassung aktueller Probleme. Grafana-Dashboards und Datensammelregeln für das Monitoring von GPU wurden hinzugefügt.
- Fehler in MongoDB, Kafka, Tenant-Kubernetes-Bootstrap, etcd, Velero, Kamaji, LINSTOR, SeaweedFS, Harbor, objectstorage-controller, API und anderen Komponenten wurden behoben. Im API wurde die IDOR-Schwachstelle in den Handlern für TenantNamespace Get und Watch behoben.
Bei einem Update ist zu beachten, dass die Worker-Knoten der Tenant-Cluster einmal sequenziell wegen der Umstellung auf permanente PVC-Laufwerke ersetzt werden. Virtuelle Maschinen von KubeVirt, die vor dem Plattform-Update gestartet wurden, benötigen nach der Umstellung auf KubeVirt 1.8.2 einen kalten Neustart, da die Live-Migration alter virt-launcher-Prozesse aufgrund der Änderung der QEMU-Version fehlerhaft sein kann. Zudem sind die PostgreSQL-Parameter nun typisiert und werden anhand einer Denylist geprüft, während cert-manager 1.20 standardmäßig Container mit UID/GID 65532 startet.
Quelle: opennet.ru
