È disponibile il rilascio della piattaforma PaaS Cozystack 1.4, basata su Kubernetes. Questo progetto mira a fornire una piattaforma pronta per i fornitori di hosting e un framework per costruire cloud privati e pubblici. La piattaforma si installa direttamente sui server e copre tutti gli aspetti della preparazione dell'infrastruttura per fornire servizi gestiti. Cozystack consente di avviare e gestire cluster Kubernetes, database e macchine virtuali. Il codice della piattaforma è disponibile su GitHub ed è distribuito con licenza Apache-2.0.
La piattaforma include un'implementazione open-source dell'infrastruttura di rete (fabric) basata su Kube-OVN e utilizza Cilium per organizzare la rete dei servizi, MetalLB per l'annuncio dei servizi all'esterno. Lo storage è implementato su LINSTOR, con utilizzo di ZFS come strato base per lo storage e DRBD per la replicazione. È presente un stack di monitoraggio preconfigurato basato su VictoriaMetrics e Grafana. Per avviare di macchine virtuali viene utilizzata la tecnologia KubeVirt, che consente di eseguire macchine virtuali classiche direttamente nei container Kubernetes e ha già tutte le integrazioni necessarie con Cluster API per avviare cluster Kubernetes gestiti all'interno di un cluster Kubernetes "bare metal". Sulla piattaforma è possibile implementare con un clic Kafka, FerretDB, PostgreSQL, Cilium, Grafana, Victoria Metrics e altri servizi.
Le principali novità in Cozystack 1.4.0:
- È stato presentato un nuovo interfaccia di gestione, basata sul progetto cozystack-ui. Il vecchio stack openapi-ui e BFF è stato sostituito da un front-end in React 19 e TypeScript, che interagisce direttamente con l'API di Kubernetes. Inoltre, l'interfaccia ha ora il supporto per URL dinamici VNC WebSocket per macchine virtuali, il branding runtime tramite ConfigMap, la lettura della ApplicationDefinition per il catalogo delle applicazioni e il reindirizzamento degli indirizzi obsoleti /openapi-ui/*.
- Per i nodi worker dei cluster tenant è stato implementato uno storage persistente. Le macchine virtuali dei nodi worker ora utilizzano dischi PVC tramite KubeVirt dataVolumeTemplates invece di emptyDisk. Grazie a ciò, i certificati kubelet, kubeconfig e lo stato di containerd vengono preservati dopo il riavvio della macchina virtuale. Il campo ephemeralStorage è stato rinominato in diskSize, ed è stata aggiunta l'impostazione storageClass a livello di NodeGroup. Durante la migrazione, i vecchi valori vengono automaticamente convertiti.
- È stata aggiunta una nuova schema di preset delle risorse analogamente ai tipi di macchine virtuali dei fornitori cloud. I preset sono descritti nel formato ., dove le serie t1, c1, s1, u1 e m1 definiscono differenti proporzioni di CPU e memoria, mentre le dimensioni variano da nano a 4xlarge. Sono disponibili in totale 40 opzioni. I vecchi nomi dei preset sono stati mantenuti come alias deprecati e migrati automaticamente senza modificare i limiti effettivi di CPU e memoria.
- È stato ampliato il sistema di backup dichiarativo per le applicazioni gestite. Il controller backupstrategy ha ricevuto strategie per PostgreSQL, MariaDB, ClickHouse e FoundationDB. Sono supportati BackupClass, Plan, BackupJob e RestoreJob, backup pianificati e singoli, recupero in loco e recupero su copia. I dati vengono esportati in uno storage a oggetti compatibile con S3, e le credenziali vengono trasmesse tramite Kubernetes Secret.
- È stato aggiunto il pacchetto di sistema opzionale hami con HAMi 2.8.1 per l'accesso simultaneo alle GPU NVIDIA nei cluster tenant. I workload personalizzati possono richiedere risorse nvidia.com/gpu, nvidia.com/gpumem e nvidia.com/gpucores, permettendo di distribuire vGPU tra più pod. L'attivazione avviene tramite il parametro hami.enabled e richiede il NVIDIA GPU Operator.
- È stata introdotta un'impostazione unificata publishing.proxyProtocol per abilitare il protocollo PROXY sugli host con ingress-nginx. Quando attivata, viene automaticamente distribuito Ouroboros, risolvendo il problema hairpin-NAT per le richieste dal cluster ai suoi nomi pubblici. Per i cluster tenant è previsto il complemento addons.ouroboros.enabled.
- Nel cozystack-operator sono state aggiunte le impostazioni per la generazione di HelmRelease: intervallo, intervallo di ripetizione, timeout di installazione, timeout di aggiornamento e max history. La strategia di ripetizione è stata convertita in RetryOnFailure, e per applicazioni specifiche è possibile impostare il timeout tramite l'annotazione release.cozystack.io/helm-install-timeout. Questo risolve vari problemi durante l'avvio a freddo dei cluster tenant.
- Per i nodi worker di Kubernetes tenant, viene calcolato automaticamente il riservato delle risorse kubelet per CPU e memoria. Le annotazioni del cluster-autoscaler ora riflettono le risorse allocate, e non il volume totale di CPU e memoria.
- Aggiornati i componenti di base della piattaforma: 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. Aggiunti nuovi pacchetti HAMi 2.8.1 e Ouroboros 0.7.2.
- Migliorata la diagnostica: cozyreport ora raccoglie informazioni su Flux, cert-manager, ambiente host, Application, ApplicationDefinition e risorse Tenant, e genera un summary.txt con un breve riepilogo dei problemi attuali. Aggiunti dashboard Grafana e regole di raccolta dati per il monitoraggio GPU.
- Corrette le vulnerabilità in MongoDB, Kafka, bootstrap di Kubernetes tenant, etcd, Velero, Kamaji, LINSTOR, SeaweedFS, Harbor, objectstorage-controller, API e altri componenti. Nell'API è stata rimossa la vulnerabilità IDOR nei gestori di Get e Watch di TenantNamespace.
Si deve tenere presente che i nodi worker dei cluster tenant verranno sostituiti una sola volta in sequenza a causa della migrazione verso dischi PVC permanenti. Le macchine virtuali KubeVirt avviate prima dell'aggiornamento della piattaforma richiederanno un riavvio a freddo dopo il passaggio a KubeVirt 1.8.2, poiché la migrazione a caldo dei vecchi processi virt-launcher può restituire un errore a causa della modifica della versione di QEMU. Inoltre, i parametri di PostgreSQL sono ora tipizzati e verificati tramite denylist, mentre cert-manager 1.20 avvia per default i contenitori con UID/GID 65532.
Fonte: opennet.ru
