La version libre de la plateforme PaaS Cozystack 1.4, basée sur Kubernetes, est maintenant disponible. Le projet vise à fournir une plateforme prête à l'emploi pour les fournisseurs d'hébergement ainsi qu'un cadre pour la construction de clouds privés et publics. La plateforme s'installe directement sur les serveurs et couvre tous les aspects de la préparation de l'infrastructure pour la fourniture de services gérés. Cozystack permet de lancer et de fournir des clusters Kubernetes, des bases de données et machines virtuelles. Le code de la plateforme est disponible sur GitHub et est distribué sous la licence Apache-2.0.
La plateforme comprend une implémentation libre d'infrastructure réseau (fabric) basée sur Kube-OVN, et utilise Cilium pour organiser le réseau de services, ainsi que MetalLB pour annoncer les services à l'extérieur. Le stockage est réalisé sur LINSTOR, où l'utilisation de ZFS est proposée comme couche de base pour le stockage et DRBD pour la réplication. Un stack de monitoring préconfiguré basé sur VictoriaMetrics et Grafana est disponible. Pour le lancement machines virtuelles la technologie KubeVirt est utilisée, permettant d'exécuter des machines virtuelles classiques directement dans les conteneurs Kubernetes, et dispose déjà de toutes les intégrations nécessaires avec Cluster API pour lancer des clusters Kubernetes gérés au sein d'un cluster Kubernetes 'bare-metal'. Dans le cadre de la plateforme, il est possible de déployer en un clic Kafka, FerretDB, PostgreSQL, Cilium, Grafana, Victoria Metrics et d'autres services.
Les principales nouveautés de Cozystack 1.4.0 :
- Une nouvelle interface de gestion est présentée, basée sur le projet cozystack-ui. L'ancien stack openapi-ui et BFF a été remplacé par un front-end utilisant React 19 et TypeScript, qui communique directement avec l'API Kubernetes. De plus, l'interface prend désormais en charge les URL WebSocket VNC dynamiques pour les machines virtuelles, le branding runtime via ConfigMap, la lecture de ApplicationDefinition pour le catalogue d'applications et le redirectionnement des anciennes adresses /openapi-ui/*.
- Pour les nœuds de travail des clusters de locataires, un stockage persistant a été mis en place. Les machines virtuelles des nœuds de travail utilisent désormais des disques PVC via KubeVirt dataVolumeTemplates au lieu d'emptyDisk. Grâce à cela, les certificats kubelet, kubeconfig et l'état de containerd sont préservés après le redémarrage de la machine virtuelle. Le champ ephemeralStorage a été renommé en diskSize, et une configuration storageClass a été ajoutée au niveau de NodeGroup. Lors de la migration, les anciennes valeurs sont automatiquement converties.
- Une nouvelle configuration de présélections de ressources a été ajoutée, similaire aux types de machines virtuelles chez les fournisseurs de cloud. Les présélections sont décrites au format ., où les séries t1, c1, s1, u1 et m1 définissent différents rapports CPU et mémoire, les tailles variant de nano à 4xlarge. Un total de 40 options est disponible. Les anciens noms de présélections sont conservés en tant qu'alias obsolètes et migrent automatiquement sans modifier les limites réelles de CPU et de mémoire.
- Le système de sauvegarde déclarative des applications gérées a été étendu. Le contrôleur backupstrategy a reçu des stratégies pour PostgreSQL, MariaDB, ClickHouse et FoundationDB. Les BackupClass, Plan, BackupJob et RestoreJob sont pris en charge, ainsi que les sauvegardes planifiées et ponctuelles, la récupération sur place et la récupération dans une copie. Les données sont exportées vers un stockage objet compatible S3, et les informations d'identification sont transmises via Kubernetes Secret.
- Un package système optionnel hami a été ajouté avec HAMi 2.8.1 pour un accès partagé aux GPU NVIDIA dans les clusters locataires. Les workloads personnalisés peuvent demander des ressources nvidia.com/gpu, nvidia.com/gpumem et nvidia.com/gpucores, ce qui permet de répartir les vGPU entre plusieurs pods. L'activation se fait via le paramètre hami.enabled et nécessite le NVIDIA GPU Operator.
- Un paramètre unique publishing.proxyProtocol est maintenant disponible pour activer le protocole PROXY sur les hôtes avec ingress-nginx. Lors de son activation, Ouroboros est automatiquement déployé, éliminant le problème du hairpin-NAT pour les requêtes du cluster vers ses noms publics. Un complément addons.ouroboros.enabled est prévu pour les clusters locataires.
- Des paramètres pour la génération HelmRelease ont été ajoutés dans cozystack-operator : intervalle, intervalle de réessai, délai d'installation, délai de mise à niveau et historique maximum. La stratégie de réessai a été modifiée pour RetryOnFailure, et pour certaines applications, un délai peut être défini via l'annotation release.cozystack.io/helm-install-timeout. Cela résout divers problèmes lors du démarrage à froid des clusters locataires.
- Pour les nœuds workers de Kubernetes des locataires, la réservation des ressources kubelet pour le CPU et la mémoire est calculée automatiquement. Les annotations cluster-autoscaler reflètent maintenant les ressources allouées, et non le volume total de CPU et de mémoire.
- Les composants de base de la plateforme ont été mis à jour : 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. De nouveaux packages HAMi 2.8.1 et Ouroboros 0.7.2 ont été ajoutés.
- Amélioration du diagnostic : cozyreport collecte désormais des informations sur Flux, cert-manager, l'environnement hôte, les ressources Application, ApplicationDefinition et Tenant, et génère un summary.txt avec un résumé des problèmes actuels. Des tableaux de bord Grafana et des règles de collecte de données pour le suivi des GPU ont été ajoutés.
- Des bugs ont été corrigés dans MongoDB, Kafka, le bootstrap Kubernetes des tenants, etcd, Velero, Kamaji, LINSTOR, SeaweedFS, Harbor, objectstorage-controller, API et d'autres composants. Dans l'API, la vulnérabilité IDOR a été corrigée dans les gestionnaires TenantNamespace Get et Watch.
Lors de la mise à jour, il est à noter que les nœuds worker des clusters de tenants seront remplacés de manière séquentielle en raison du passage aux disques PVC permanents. Les machines virtuelles KubeVirt lancées avant la mise à jour de la plateforme nécessiteront un redémarrage à froid après le passage à KubeVirt 1.8.2, car la migration vivante des anciens processus virt-launcher peut échouer en raison du changement de version de QEMU. De plus, les paramètres PostgreSQL sont désormais typés et vérifiés par une liste de refus, et cert-manager 1.20 lance par défaut les conteneurs avec UID/GID 65532.
Source : opennet.ru
