Está disponível a versão da plataforma PaaS livre Cozystack 1.4, construída sobre Kubernetes. O projeto visa fornecer uma plataforma pronta para provedores de hospedagem e um framework para construir nuvens privadas e públicas. A plataforma é instalada diretamente nos servidores e cobre todos os aspectos da preparação da infraestrutura para fornecer serviços gerenciados. O Cozystack permite iniciar e fornecer clusters Kubernetes, bancos de dados e máquinas virtuais. O código da plataforma está disponível no GitHub e é distribuído sob a licença Apache-2.0.
A plataforma inclui uma implementação de rede (fabric) baseada em Kube-OVN e utiliza Cilium para a organização da rede de serviços, MetalLB para a divulgação de serviços externamente. O armazenamento é implementado com o LINSTOR, onde é proposta a utilização do ZFS como camada base para o armazenamento e DRBD para replicação. Existe um stack de monitoramento pré-configurado baseado em VictoriaMetrics e Grafana. Para a inicialização máquinas virtuais é utilizada a tecnologia KubeVirt, que permite iniciar máquinas virtuais clássicas diretamente em containers Kubernetes e já possui todas as integrações necessárias com o Cluster API para iniciar clusters Kubernetes gerenciados dentro de um cluster Kubernetes 'bare metal'. Dentro da plataforma, é possível implantar com um clique Kafka, FerretDB, PostgreSQL, Cilium, Grafana, Victoria Metrics e outros serviços.
Principais inovações no Cozystack 1.4.0:
- Foi apresentado uma nova interface de gerenciamento, baseada no projeto cozystack-ui. O antigo stack openapi-ui e BFF foi substituído por um frontend em React 19 e TypeScript, que trabalha diretamente com a API do Kubernetes. Além disso, a interface agora possui suporte para URLs dinâmicos de VNC WebSocket para máquinas virtuais, branding em tempo de execução através do ConfigMap, leitura de ApplicationDefinition para o catálogo de aplicativos e redirecionamento de antigos endereços /openapi-ui/*.
- Para nós workers de clusters multi-inquilino, foi implementado armazenamento persistente. As máquinas virtuais dos nós workers agora utilizam discos PVC através de KubeVirt dataVolumeTemplates em vez de emptyDisk. Com isso, os certificados kubelet, kubeconfig e o estado do containerd são mantidos após a reinicialização da máquina virtual. O campo ephemeralStorage foi renomeado para diskSize, e uma configuração storageClass foi adicionada ao nível do NodeGroup. Durante a migração, os antigos valores são convertidos automaticamente.
- Foi adicionada uma nova esquema de presets de recursos, semelhante aos tipos de máquinas virtuais dos provedores de nuvem. Os presets são descritos no formato ., onde as séries t1, c1, s1, u1 e m1 definem diferentes relações de CPU e memória, e os tamanhos variam de nano a 4xlarge. Ao todo, estão disponíveis 40 opções. Os antigos nomes dos presets foram mantidos como aliases obsoletos e migrados automaticamente sem alterar os limites efetivos de CPU e memória.
- O sistema de backup declarativo de aplicativos gerenciados foi expandido. O controlador backupstrategy recebeu estratégias para PostgreSQL, MariaDB, ClickHouse e FoundationDB. Suportam-se BackupClass, Plan, BackupJob e RestoreJob, backups agendados e pontuais, recuperação no local e recuperação em cópia. Os dados são exportados para armazenamento de objetos compatível com S3, e as credenciais são transmitidas via Kubernetes Secret.
- Adicionado o pacote de sistema opcional hami com HAMi 2.8.1 para acesso compartilhado ao NVIDIA GPU em clusters de tenant. As workloads personalizadas podem solicitar recursos nvidia.com/gpu, nvidia.com/gpumem e nvidia.com/gpucores, permitindo a distribuição de vGPU entre vários pods. A ativação é feita através do parâmetro hami.enabled e requer o NVIDIA GPU Operator.
- Foi adicionada uma configuração única publishing.proxyProtocol para habilitar o protocolo PROXY em hosts com ingress-nginx. Ao ativá-la, o Ouroboros é implantado automaticamente, solucionando o problema de hairpin-NAT para acessos do cluster a seus nomes públicos. Para clusters de tenant, existe a adição addons.ouroboros.enabled.
- No cozystack-operator, foram adicionadas configurações para geração de HelmRelease: interval, retry interval, install timeout, upgrade timeout e max history. A estratégia de repetição foi alterada para RetryOnFailure, e para aplicações individuais, é possível definir o timeout através da anotação release.cozystack.io/helm-install-timeout. Isso resolve diversos problemas durante a inicialização a frio de clusters de tenant.
- Para os nós worker do Kubernetes de tenant, o provisionamento de recursos kubelet para CPU e memória é calculado automaticamente. As anotações cluster-autoscaler agora refletem os recursos alocados, em vez do total de CPU e memória.
- Os componentes principais da plataforma foram atualizados: 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. Novos pacotes HAMi 2.8.1 e Ouroboros 0.7.2 foram adicionados.
- A diagnose foi aprimorada: o cozyreport agora coleta informações sobre Flux, cert-manager, ambiente host, Application, ApplicationDefinition e recursos de Tenant, além de gerar um summary.txt com um resumo das questões atuais. Adicionados dashboards do Grafana e regras de coleta de dados para monitoramento de GPU.
- Foram corrigidos erros no MongoDB, Kafka, bootstrap do Kubernetes de tenant, etcd, Velero, Kamaji, LINSTOR, SeaweedFS, Harbor, objectstorage-controller, API e outros componentes. No API, a vulnerabilidade IDOR nos manipuladores TenantNamespace Get e Watch foi corrigida.
Ao atualizar, deve-se levar em consideração que os nós worker dos clusters de tenant serão substituídos sequencialmente uma vez devido à transição para discos PVC permanentes. Máquinas virtuais KubeVirt, iniciadas antes da atualização da plataforma, requererão um reboot a frio após a transição para KubeVirt 1.8.2, pois a migração ao vivo de processos virt-launcher antigos pode falhar devido à mudança de versão do QEMU. Além disso, os parâmetros do PostgreSQL agora são tipificados e verificados pela denylist, e o cert-manager 1.20, por padrão, executa contêineres com UID/GID 65532.
Fonte: opennet.ru
