Die Veröffentlichung der freien PaaS-Plattform Cozystack 1.4, die auf Kubernetes basiert, ist verfügbar. Das Projekt zielt darauf ab, eine fertige Plattform für Hosting-Anbieter und ein Framework für den Aufbau privater und öffentlicher Clouds bereitzustellen. Die Plattform wird direkt auf Server installiert und umfasst alle Aspekte der Infrastrukturvorbereitung zur Bereitstellung verwalteter Dienste. Cozystack ermöglicht das Starten und Bereitstellen von Kubernetes-Clustern, Datenbanken und virtuelle Maschinen. Der Code der Plattform ist auf GitHub verfügbar und wird unter der Lizenz Apache-2.0 verbreitet.
Die Plattform beinhaltet eine freie Implementierung der Netzwerk-Infrastruktur (Fabric) auf Basis von Kube-OVN und verwendet Cilium zur Organisation des Servicenetzwerks, MetalLB zur Ankündigung von Services nach außen. Der Speicher wird auf LINSTOR implementiert, wobei die Verwendung von ZFS als Basisschicht für den Speicher und DRBD für die Replikation vorgeschlagen wird. Ein vorinstallierter Monitoring-Stack basierend auf VictoriaMetrics und Grafana ist enthalten. Für den Start virtuelle Maschinen wird die Technologie KubeVirt verwendet, die es ermöglicht, klassische virtuelle Maschinen direkt in Kubernetes-Containern auszuführen und bereits alle notwendigen Integrationen mit Cluster API für den Betrieb verwalteter Kubernetes-Cluster innerhalb eines physischen Kubernetes-Clusters hat. Im Rahmen der Plattform können mit einem Klick Kafka, FerretDB, PostgreSQL, Cilium, Grafana, Victoria Metrics und andere Services bereitgestellt werden.
Die wichtigsten Neuerungen in Cozystack 1.4.0:
- Eine neue Verwaltungsoberfläche, die auf dem Projekt cozystack-ui basiert, wurde eingeführt. Der alte Stack openapi-ui und BFF wurde durch ein Frontend auf React 19 und TypeScript ersetzt, das direkt mit der Kubernetes-API arbeitet. Darüber hinaus bietet die Benutzeroberfläche Unterstützung für dynamische VNC-WebSocket-URLs für virtuelle Maschinen, Runtime-Branding über ConfigMap, Lesezugriff auf ApplicationDefinition für den Anwendungskatalog und die Umleitung alter Adressen /openapi-ui/*.
- Für die Worker-Knoten der Mandantencluster wurde ein permanentes Speichersystem implementiert. Die virtuellen Maschinen der Worker-Knoten nutzen jetzt PVC-Volumes über KubeVirt dataVolumeTemplates anstelle von emptyDisk. Dadurch werden kubelet-Zertifikate, kubeconfig und der Zustand von containerd nach einem Neustart der virtuellen Maschine gespeichert. Das Feld ephemeralStorage wurde in diskSize umbenannt, und die Einstellung storageClass auf Ebene der NodeGroup wurde hinzugefügt. Bei der Migration werden die alten Werte automatisch konvertiert.
- Ein neues Schema für Ressourcen-Presets wurde analog zu den Typen virtueller 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 RAM festlegen, während die Größen von nano bis 4xlarge reichen. Insgesamt stehen 40 Varianten zur Verfügung. Die alten Namen der Presets wurden als veraltete Aliase gespeichert und werden ohne Änderung der tatsächlichen CPU- und RAM-Limits automatisch migriert.
- Das System für deklaratives Backup verwalteter Anwendungen wurde erweitert. Der Controller backupstrategy erhielt Strategien für PostgreSQL, MariaDB, ClickHouse und FoundationDB. BackupClass, Plan, BackupJob und RestoreJob sowie geplante und einmalige Backups, Wiederherstellung vor Ort und Wiederherstellung in eine Kopie werden unterstützt. Daten werden in ein S3-kompatibles Objekt-Storage exportiert, und die Anmeldedaten werden über Kubernetes Secret übertragen.
- Ein fakultatives Systempaket hami mit HAMi 2.8.1 wurde hinzugefügt, um den gemeinsamen Zugriff auf NVIDIA GPU in Multi-Tenant-Clustern zu ermöglichen. Benutzerdefinierte Workloads können Ressourcen von nvidia.com/gpu, nvidia.com/gpumem und nvidia.com/gpucores anfordern, was die Verteilung von vGPU auf mehrere Pods ermöglicht. Die Aktivierung erfolgt über den Parameter hami.enabled und erfordert den NVIDIA GPU Operator.
- Es gibt jetzt eine einheitliche Einstellung publishing.proxyProtocol zur Aktivierung des PROXY-Protokolls auf Hosts mit ingress-nginx. Bei Aktivierung wird automatisch Ouroboros bereitgestellt, das das Problem des hairpin-NAT für Anfragen aus dem Cluster an seine öffentlichen Namen behebt. Für Multi-Tenant-Cluster gibt es das Add-on addons.ouroboros.enabled.
- Im cozystack-operator wurden Einstellungen zur Erstellung von HelmRelease hinzugefügt: Intervall, Wiederholungsintervall, Installationszeitüberschreitung, Upgrade-Zeitüberschreitung und maximale Historie. Die Wiederholungsstrategie wurde auf RetryOnFailure umgestellt, und für bestimmte Anwendungen kann eine Zeitüberschreitung über die Annotation release.cozystack.io/helm-install-timeout festgelegt werden. Dies behebt mehrere Probleme bei den Kaltstarts von Multi-Tenant-Clustern.
- Für die Worker-Knoten des Multi-Tenant-Kubernetes wird die Ressourcenzuteilung des Kubelet für CPU und RAM automatisch berechnet. Die Annotationen des Cluster-Autoscalers spiegeln jetzt die zugewiesenen Ressourcen wider, nicht das gesamte Volumen an CPU und RAM.
- Die Basis-Komponenten 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. Neue Pakete HAMi 2.8.1 und Ouroboros 0.7.2 wurden hinzugefügt.
- Die Diagnose wurde verbessert: cozyreport sammelt jetzt Informationen über Flux, cert-manager, Host-Umgebung, Application, ApplicationDefinition und Tenant-Ressourcen und erstellt eine summary.txt mit einer kurzen Zusammenfassung der aktuellen Probleme. Grafana-Dashboards und Datensammelregeln zur Überwachung von GPUs wurden hinzugefügt.
- Fehler in MongoDB, Kafka, Multi-Tenant Kubernetes Bootstrap, etcd, Velero, Kamaji, LINSTOR, SeaweedFS, Harbor, objectstorage-controller, API und anderen Komponenten wurden behoben. Im API wurde die IDOR-Sicherheitsanfälligkeit in den Handlern TenantNamespace Get und Watch behoben.
Bei einem Upgrade ist zu beachten, dass die Worker-Knoten der Multi-Tenant-Cluster einmal der Reihe nach wegen des Wechsels zu persistenten PVC-Laufwerken ersetzt werden. Virtuelle Maschinen von KubeVirt, die vor dem Upgrade der Plattform gestartet wurden, benötigen nach dem Übergang zu KubeVirt 1.8.2 einen Kaltneustart, da die Live-Migration alter virt-launcher-Prozesse aufgrund der Änderung der QEMU-Version fehlschlagen kann. Darüber hinaus sind die PostgreSQL-Parameter jetzt typisiert und werden anhand einer Negativliste geprüft, und der cert-manager 1.20 startet standardmäßig Container mit UID/GID 65532.
Quelle: opennet.ru
