Está disponible la versión 1.4 de la plataforma PaaS de Cozystack, construida sobre Kubernetes. El proyecto está dirigido a proporcionar una plataforma lista para proveedores de hosting y un marco para la construcción de nubes privadas y públicas. La plataforma se instala directamente en los servidores y abarca todos los aspectos de la preparación de la infraestructura para ofrecer servicios gestionados. Cozystack permite iniciar y proporcionar clústeres de Kubernetes, bases de datos y máquinas virtuales. El código de la plataforma está disponible en GitHub y se distribuye bajo la licencia Apache-2.0.
La plataforma incluye una implementación libre de la infraestructura de red (fabric) basada en Kube-OVN, y utiliza Cilium para gestionar la red de servicios, MetalLB para el anuncio de servicios al exterior. El almacenamiento está implementado sobre LINSTOR, donde se ofrece el uso de ZFS como capa base para el almacenamiento y DRBD para replicación. Se cuenta con un stack de monitoreo preconfigurado basado en VictoriaMetrics y Grafana. Para iniciar máquinas virtuales se utiliza la tecnología KubeVirt, que permite ejecutar máquinas virtuales clásicas directamente en los contenedores de Kubernetes y ya tiene todas las integraciones necesarias con Cluster API para iniciar clústeres de Kubernetes gestionados dentro de un clúster de Kubernetes "metal". Dentro de la plataforma, es posible desplegar con un clic Kafka, FerretDB, PostgreSQL, Cilium, Grafana, Victoria Metrics y otros servicios.
Principales novedades en Cozystack 1.4.0:
- Se presentó una nueva interfaz de gestión basada en el proyecto cozystack-ui. La antigua pila openapi-ui y BFF fue reemplazada por un frontend en React 19 y TypeScript, que interactúa directamente con la API de Kubernetes. Además, la interfaz ahora soporta URL WebSocket VNC dinámicas para máquinas virtuales, branding en tiempo de ejecución a través de ConfigMap, lectura de ApplicationDefinition para el directorio de aplicaciones y redirección de antiguas direcciones /openapi-ui/*.
- Se implementó almacenamiento persistente para los nodos worker de clústeres de inquilinos. Las máquinas virtuales de los nodos worker ahora utilizan discos PVC a través de KubeVirt dataVolumeTemplates en lugar de emptyDisk. Gracias a esto, los certificados kubelet, kubeconfig y el estado de containerd se mantienen después del reinicio de la máquina virtual. El campo ephemeralStorage fue renombrado a diskSize, y se añadió la configuración storageClass a nivel de NodeGroup. Durante la migración, los antiguos valores se convierten automáticamente.
- Se añadió un nuevo esquema de presets de recursos, similar a los tipos de máquinas virtuales de los proveedores de nube. Los presets se describen en el formato ., donde las series t1, c1, s1, u1 y m1 definen diferentes proporciones de CPU y memoria, y los tamaños varían desde nano hasta 4xlarge. En total, hay 40 opciones disponibles. Los antiguos nombres de presets se conservaron como alias obsoletos y se migran automáticamente sin cambiar los límites reales de CPU y memoria.
- Se amplió el sistema de copias de seguridad declarativas para aplicaciones gestionadas. El controlador backupstrategy recibió estrategias para PostgreSQL, MariaDB, ClickHouse y FoundationDB. Soporta BackupClass, Plan, BackupJob y RestoreJob, copias de seguridad programadas y puntuales, restauración in situ y restauración en respaldo. Los datos se exportan a un almacenamiento de objetos compatible con S3, y las credenciales se transmiten a través de Kubernetes Secret.
- Se ha añadido un paquete del sistema opcional hami con HAMi 2.8.1 para el acceso conjunto a NVIDIA GPU en clústeres de inquilinos. Los trabajos de usuario pueden solicitar recursos nvidia.com/gpu, nvidia.com/gpumem y nvidia.com/gpucores, lo que permite distribuir vGPU entre varios pod. La activación se realiza a través del parámetro hami.enabled y requiere el NVIDIA GPU Operator.
- Ahora hay una configuración unificada publishing.proxyProtocol para habilitar el protocolo PROXY en hosts con ingress-nginx. Al activarla, se despliega automáticamente Ouroboros, que elimina el problema de hairpin-NAT para las solicitudes desde el clúster a sus nombres públicos. Para clústeres de inquilentes, se ha previsto el complemento addons.ouroboros.enabled.
- Se han añadido configuraciones de generación de HelmRelease en cozystack-operator: interval, retry interval, install timeout, upgrade timeout y max history. La estrategia de reintentos se ha cambiado a RetryOnFailure, y para aplicaciones individuales se puede establecer un timeout a través de la anotación release.cozystack.io/helm-install-timeout. Esto elimina varios problemas en el inicio en frío de clústeres de inquilentes.
- Para los nodos worker de Kubernetes de inquilentes, se calcula automáticamente la reserva de recursos kubelet para la CPU y la memoria. Las anotaciones cluster-autoscaler ahora reflejan los recursos asignados, no el total de CPU y memoria.
- Se han actualizado los componentes básicos de la plataforma: 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. Se han añadido nuevos paquetes HAMi 2.8.1 y Ouroboros 0.7.2.
- Se ha mejorado el diagnóstico: cozyreport ahora recopila información sobre Flux, cert-manager, el entorno del host, Application, ApplicationDefinition y recursos de Tenant, además de generar summary.txt con un breve resumen de los problemas actuales. Se han añadido tableros de Grafana y reglas de recolección de datos para la supervisión de GPU.
- Se han corregido errores en MongoDB, Kafka, bootstrap de Kubernetes de inquilentes, etcd, Velero, Kamaji, LINSTOR, SeaweedFS, Harbor, objectstorage-controller, API y otros componentes. En la API se ha eliminado una vulnerabilidad IDOR en los manejadores TenantNamespace Get y Watch.
Al actualizar, se debe tener en cuenta que los nodos worker de los clústeres de inquilentes serán reemplazados secuencialmente una vez debido a la transición a discos PVC permanentes. Las máquinas virtuales KubeVirt, que se ejecutaron antes de la actualización de la plataforma, necesitarán un reinicio en frío después de cambiar a KubeVirt 1.8.2, ya que la migración en vivo de los antiguos procesos virt-launcher puede fallar debido al cambio de versión de QEMU. Además, los parámetros de PostgreSQL ahora están tipificados y son verificados por una lista de bloqueo, y cert-manager 1.20 por defecto ejecuta contenedores con UID/GID 65532.
Fuente: opennet.ru
