È disponibile il rilascio della piattaforma PaaS Cozystack 1.4, costruita su Kubernetes. Il progetto mira a fornire una piattaforma pronta per i fornitori di hosting e un framework per la creazione di nuvole private e pubbliche. La piattaforma viene installata direttamente sui server e copre tutti gli aspetti della preparazione dell'infrastruttura per fornire servizi gestiti. Cozystack consente di avviare e fornire cluster Kubernetes, database e macchine virtuali. Il codice della piattaforma è disponibile su GitHub e 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 gestire la rete dei servizi, MetalLB per l'annuncio dei servizi all'esterno. Lo storage è implementato su LINSTOR, dove si propone di utilizzare ZFS come livello base per lo storage e DRBD per la replicazione. È presente uno stack di monitoraggio preconfigurato basato su VictoriaMetrics e Grafana. Per l'avvio macchine virtuali viene utilizzata la tecnologia KubeVirt, che consente di eseguire macchine virtuali tradizionali direttamente nei contenitori Kubernetes e ha già tutte le integrazioni necessarie con Cluster API per avviare cluster Kubernetes gestiti all'interno di un cluster Kubernetes 'bare metal'. All'interno della piattaforma è possibile distribuire con un clic Kafka, FerretDB, PostgreSQL, Cilium, Grafana, Victoria Metrics e altri servizi.
Le principali novità in Cozystack 1.4.0:
- Introdotta una nuova interfaccia di gestione, basata sul progetto cozystack-ui. Il vecchio stack openapi-ui e BFF è stato sostituito da un frontend realizzato con React 19 e TypeScript, che lavora direttamente con l'API di Kubernetes. Inoltre, nell'interfaccia è stata aggiunta la supporto per gli URL WebSocket VNC dinamici per le macchine virtuali, branding del runtime tramite ConfigMap, lettura di ApplicationDefinition per il catalogo delle applicazioni e reindirizzamento degli indirizzi obsoleti /openapi-ui/*.
- Per i nodi worker dei cluster tenant, è stato implementato uno storage persistente. Le macchine virtuali dei nodi worker utilizzano ora dischi PVC tramite KubeVirt dataVolumeTemplates invece di emptyDisk. Grazie a questo, i certificati kubelet, kubeconfig e lo stato di containerd vengono mantenuti dopo il riavvio della macchina virtuale. Il campo ephemeralStorage è stato rinominato in diskSize, è stata aggiunta un'impostazione storageClass a livello di NodeGroup. Durante il processo di migrazione, i vecchi valori vengono automaticamente convertiti.
- Introdotta una nuova schema di preset delle risorse in analogia ai tipi di macchine virtuali offerte dai fornitori di cloud. I preset sono descritti nel formato ., dove le serie t1, c1, s1, u1 e m1 stabiliscono diversi rapporti tra 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 obsoleti e vengono migrati automaticamente senza modificare i limiti effettivi di CPU e memoria.
- Espansa la sistema di backup dichiarativo delle applicazioni gestite. Il controller backupstrategy ha ricevuto strategie per PostgreSQL, MariaDB, ClickHouse e FoundationDB. Sono supportati BackupClass, Plan, BackupJob e RestoreJob, backup programmati e on-demand, ripristino in loco e ripristino in 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 condiviso a GPU NVIDIA nei cluster tenant. I workload personalizzati possono richiedere risorse nvidia.com/gpu, nvidia.com/gpumem e nvidia.com/gpucores, consentendo di distribuire vGPU tra più pod. L'attivazione avviene tramite il parametro hami.enabled e richiede NVIDIA GPU Operator.
- È stata introdotta l'impostazione unica publishing.proxyProtocol per abilitare il protocollo PROXY sugli host con ingress-nginx. Quando attivata, viene automaticamente distribuito Ouroboros, che risolve il problema hairpin-NAT per le richieste dal cluster ai suoi nomi pubblici. Per i cluster tenant è previsto l'aggiuntivo addons.ouroboros.enabled.
- Nel cozystack-operator sono state aggiunte impostazioni di generazione di HelmRelease: interval, retry interval, install timeout, upgrade timeout e max history. La strategia di ripetizione è stata modificata in RetryOnFailure, mentre per applicazioni specifiche è possibile impostare il timeout attraverso l'annotazione release.cozystack.io/helm-install-timeout. Questo risolve vari problemi durante l'avvio a freddo dei cluster tenant.
- Per i nodi worker del Kubernetes tenant, la riserva delle risorse kubelet per CPU e memoria viene calcolata automaticamente. Le annotazioni del cluster-autoscaler ora riflettono le risorse allocate e non il totale della CPU e della 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. Sono stati 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, generando anche summary.txt con un riepilogo delle attuali problematiche. Sono stati aggiunti dashboard Grafana e regole di raccolta dati per il monitoraggio delle GPU.
- Risolti bug 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 TenantNamespace Get e Watch.
Durante l'aggiornamento, è importante notare che i nodi worker dei cluster tenant saranno sostituiti uno alla volta a causa del passaggio ai 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 live dei vecchi processi virt-launcher potrebbe fallire a causa della modifica della versione di QEMU. Inoltre, i parametri PostgreSQL sono ora tipizzati e verificati tramite denylist, mentre il cert-manager 1.20 avvia i contenitori con UID/GID 65532 per impostazione predefinita.
Fonte: opennet.ru
