Elérhető a Cozystack 1.4 kiadása, amely egy Kubernetes alapú nyílt PaaS platform. A projekt célja, hogy kész platformot biztosítson a hosztoló szolgáltatók számára, valamint keretrendszert a privát és nyilvános felhők kiépítéséhez. A platform közvetlenül a szerverekre telepíthető, és lefedi az infrastruktúra előkészítésének minden aspektusát a menedzselt szolgáltatások nyújtásához. A Cozystack lehetővé teszi a Kubernetes klaszterek, adatbázisok és virtuális gépek. A platform kódja elérhető a GitHubon, és Apache-2.0 licenc alatt terjesztik.
A platform tartalmazza a Kube-OVN alapú hálózati infrastruktúra (fabric) szabad implementációját, és a Ciliumt használja a szolgáltatási hálózat szervezésére, a MetalLB-t pedig a szolgáltatások külső hirdetésére. A tárolás a LINSTOR-on valósul meg, ahol a ZFS használata ajánlott alaprétegnek a tároláshoz és a DRBD a replikációhoz. Előre konfigurált monitorozó stack áll rendelkezésre VictoriaMetrics és Grafana alapokon. A következőhez használt virtuális gépekhez a KubeVirt technológia, amely lehetővé teszi a klasszikus virtuális gépek indítását közvetlenül a Kubernetes konténereiben, és már rendelkezik az összes szükséges integrációval a Cluster API-val a menedzselt Kubernetes klaszterek indításához a 'hardver' Kubernetes klaszteren belül. A platform keretein belül egy kattintással telepíthetők a Kafka, FerretDB, PostgreSQL, Cilium, Grafana, Victoria Metrics és más szolgáltatások.
A Cozystack 1.4.0 fő újdonságai:
- Bemutatkozott az új kezelőfelület, amely a cozystack-ui projekt alapjain nyugszik. A régi openapi-ui és BFF stacket a React 19 és TypeScript alapú frontend váltotta fel, amely közvetlenül a Kubernetes API-val működik. Ezen kívül a felületen megjelent a dinamikus VNC WebSocket URL-ek támogatása a virtuális gépekhez, a runtime-branding a ConfigMap-en keresztül, az ApplicationDefinition olvasása az alkalmazáskönyvtárhoz és a régi címek /openapi-ui/* átirányítása.
- A tenant klaszterek worker-csomópontjaihoz állandó tárolás került bevezetésre. A worker-csomópontok virtuális gépei most PVC-lemezként használják a KubeVirt dataVolumeTemplates-t az emptyDisk helyett. Ennek köszönhetően a kubelet-cerifikátok, kubeconfig és a containerd állapota megmarad a virtuális gép újraindítása után. Az ephemeralStorage mező diskSize-ra lett átnevezve, és hozzáadva a storageClass beállítás a NodeGroup szintjén. A migráció során a régi értékek automatikusan átalakulnak.
- Új erőforrás-előbeállítási séma került bevezetésre a felhőszolgáltatók virtuális géptípusaihoz hasonlóan. Az előbeállítások formátum szerint vannak leírva: ., ahol a sorozatok: t1, c1, s1, u1 és m1 különböző CPU és memória arányokat képeznek, a méretek pedig nano-tól 4xlarge-ig terjednek. Összesen 40 lehetőség érhető el. A régi előbeállítási nevek elavult aliasokként megmaradtak, és automatikusan migrálódnak anélkül, hogy a tényleges CPU és memória korlátok változnának.
- Kibővült a deklaratív biztonsági másolat készítésének rendszere a kezelt alkalmazások számára. A backupstrategy vezérlő új stratégiákat kapott PostgreSQL, MariaDB, ClickHouse és FoundationDB számára. Támogatott a BackupClass, Plan, BackupJob és RestoreJob, tervezett és egyszeri biztonsági mentések, helyben történő helyreállítás és másolatba történő helyreállítás. Az adatok S3-kompatibilis objektumtárolóba kerülnek, a hitelesítő adatok pedig Kubernetes Secret-en keresztül kerülnek átadásra.
- Új, választható rendszercsomag került bevezetésre a hami 2.8.1 verzióval, amely lehetővé teszi a közös NVIDIA GPU hozzáférést a bérlői klaszterekben. A felhasználói workload-ok képesek kérni az nvidia.com/gpu, nvidia.com/gpumem és nvidia.com/gpucores erőforrásokat, ami lehetővé teszi a vGPU-k elosztását több pod között. Az aktiválás a hami.enabled paraméterrel történik, és NVIDIA GPU Operator-t igényel.
- Megjelent egy egységes publishing.proxyProtocol beállítás a PROXY protokoll engedélyezésére az ingress-nginx-el rendelkező hosztoknál. E beállítás aktiválásakor automatikusan telepítésre kerül az Ouroboros, amely megszünteti a hairpin-NAT problémát a klaszteren belüli nyilvános nevekre irányuló hívások során. A bérlői klaszterekhez kiegészítőként az addons.ouroboros.enabled beállítás áll rendelkezésre.
- A cozystack-operatorba új HelmRelease-generálási beállítások kerültek bevezetésre: interval, retry interval, install timeout, upgrade timeout és max history. A megismétlési stratégia a RetryOnFailure-ra lett átállítva, és egyes alkalmazások számára időkorlát állítható be a release.cozystack.io/helm-install-timeout annotációval. Ez számos problémát megszüntet a bérlői klaszterek hideg indításakor.
- A bérlői Kubernetes worker csomópontjai automatikusan kiszámítják a kubelet erőforrásainak fenntartását CPU és memória tekintetében. A cluster-autoscaler annotációi mostantól a kiosztott erőforrásokat tükrözik, nem pedig a CPU és memória teljes mennyiségét.
- Frissítettük a platform alapvető komponenseit: 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. Új HAMi 2.8.1 és Ouroboros 0.7.2 csomagok kerültek bevezetésre.
- Javult a diagnosztika: a cozyreport mostantól gyűjti az információkat a Fluxról, cert-managerről, a hoszt-környezetről, az Applicationről, ApplicationDefinitionről és Tenant-erőforrásokról, valamint készít egy summary.txt fájlt a jelenlegi problémák rövid összefoglalójával. Grafana irányítópultok és adatok gyűjtésére vonatkozó szabályok lettek hozzáadva a GPU monitorozásához.
- Hibák javítva a MongoDB, Kafka, tenant Kubernetes bootstrap, etcd, Velero, Kamaji, LINSTOR, SeaweedFS, Harbor, objectstorage-controller, API és más komponensekben. Az API-ban megszüntették az IDOR sebezhetőséget a TenantNamespace Get és Watch kezelőkben.
Frissítéskor figyelembe kell venni, hogy a tenant klaszterek worker csomópontjait egyszer egymást követően cserélik le a tartós PVC-lemezekre való átállás miatt. A KubeVirt virtuális gépek, amelyek a platform frissítése előtt indultak el, hideg újraindítást igényelnek a KubeVirt 1.8.2-re való átállás után, mivel az élő migrációs régi virt-launcher folyamatok hibára futhat, a QEMU verzióváltása miatt. Ezenkívül a PostgreSQL paraméterek most típusosak és ellenőrizve vannak a denylist alapján, míg a cert-manager 1.20 alapértelmezés szerint 65532-es UID/GID-val indítja a konténereket.
Forrás: opennet.ru
