Dostępna jest wersja wolnej platformy PaaS Cozystack 1.4, zbudowanej na bazie Kubernetes. Projekt ma na celu dostarczenie gotowej platformy dla dostawców usług hostingowych oraz frameworku do budowy prywatnych i publicznych chmur. Platforma instalowana jest bezpośrednio na serwerach i obejmuje wszystkie aspekty przygotowania infrastruktury do świadczenia zarządzanych usług. Cozystack umożliwia uruchamianie i dostarczanie klastrów Kubernetes, baz danych i maszyn wirtualnych. Kod platformy jest dostępny na GitHubie i rozpowszechniany na licencji Apache-2.0.
Platforma obejmuje wolną implementację infrastruktury sieciowej (fabric) opartą na Kube-OVN i wykorzystuje Cilium do organizacji sieci serwisowej, MetalLB do ogłaszania usług na zewnątrz. Przechowywanie danych realizowane jest na LINSTOR, gdzie oferowane jest użycie ZFS jako podstawowej warstwy przechowywania oraz DRBD do replikacji. Istnieje wstępnie skonfigurowany stos monitorowania oparty na VictoriaMetrics i Grafana. Do uruchomienia maszyn wirtualnych Wykorzystuje technologię KubeVirt, która umożliwia uruchamianie klasycznych maszyn wirtualnych bezpośrednio w kontenerach Kubernetes i już ma wszystkie niezbędne integracje z Cluster API do uruchamiania zarządzanych klastrów Kubernetes wewnątrz „fizycznego” klastra Kubernetes. W ramach platformy można uruchamiać Kafka, FerretDB, PostgreSQL, Cilium, Grafana, Victoria Metrics i inne usługi za pomocą jednego kliknięcia.
Główne nowości w Cozystack 1.4.0:
- Wprowadzono nowy interfejs zarządzania, oparty na projekcie cozystack-ui. Stary stos openapi-ui i BFF został zastąpiony frontendem opartym na React 19 i TypeScript, który działa bezpośrednio z Kubernetes API. Ponadto w interfejsie pojawiło się wsparcie dla dynamicznych adresów URL VNC WebSocket dla maszyn wirtualnych, branding runtime przez ConfigMap, odczyt ApplicationDefinition dla katalogu aplikacji oraz przekierowanie starych adresów /openapi-ui/*.
- Dla węzłów roboczych klastrów tenantów wdrożono stałe przechowywanie. Maszyny wirtualne węzłów roboczych teraz wykorzystują dyski PVC poprzez KubeVirt dataVolumeTemplates zamiast emptyDisk. Dzięki temu certyfikaty kubelet, kubeconfig i stan containerd są zachowywane po ponownym uruchomieniu maszyny wirtualnej. Pole ephemeralStorage zostało przemianowane na diskSize, dodano ustawienie storageClass na poziomie NodeGroup. W trakcie migracji stare wartości są automatycznie konwertowane.
- Dodano nowe schemat presetu zasobów, wzorowane na typach maszyn wirtualnych u dostawców chmurowych. Presety są opisywane w formacie ., gdzie serie t1, c1, s1, u1 i m1 określają różne proporcje CPU do pamięci, a rozmiary wahają się od nano do 4xlarge. Całkowicie dostępnych jest 40 opcji. Stare nazwy presetów zostały zachowane jako przestarzałe aliasy i są automatycznie migrowane bez zmiany faktycznych limitów CPU i pamięci.
- Rozszerzono system deklaratywnego tworzenia kopii zapasowych zarządzanych aplikacji. Kontroler backupstrategy otrzymał strategie dla PostgreSQL, MariaDB, ClickHouse i FoundationDB. Obsługiwane są BackupClass, Plan, BackupJob i RestoreJob, zaplanowane i jednorazowe kopie zapasowe, przywracanie w miejscu oraz przywracanie do kopii. Dane są eksportowane do magazynu obiektowego zgodnego z S3, a poświadczenia są przekazywane przez Kubernetes Secret.
- Dodano opcjonalny pakiet systemowy hami z HAMi 2.8.1 do wspólnego korzystania z NVIDIA GPU w klastrach wielotenantowych. Użytkownikowskie obciążenia mogą żądać zasobów nvidia.com/gpu, nvidia.com/gpumem i nvidia.com/gpucores, co pozwala na przydzielanie vGPU między wieloma podami. Włączenie jest realizowane za pomocą parametru hami.enabled i wymaga NVIDIA GPU Operator.
- Pojawiła się jednolita konfiguracja publishing.proxyProtocol do włączenia protokołu PROXY na hostach z ingress-nginx. Po jej aktywacji automatycznie uruchamiany jest Ouroboros, eliminujący problem hairpin-NAT dla połączeń z klastra do jego publicznych nazw. Dla klastrów najemnych przewidziano dodatek addons.ouroboros.enabled.
- W cozystack-operator dodano ustawienia generacji HelmRelease: interval, retry interval, install timeout, upgrade timeout i max history. Strategia ponownych prób została przetłumaczona na RetryOnFailure, a dla poszczególnych aplikacji można ustawić timeout przez adnotację release.cozystack.io/helm-install-timeout. Rozwiązuje to szereg problemów związanych z zimnym uruchomieniem klastrów najemnych.
- Dla węzłów roboczych najemnego Kubernetes automatycznie obliczane jest rezerwowanie zasobów kubelet dla CPU i pamięci. Adnotacje cluster-autoscaler teraz odzwierciedlają przydzielone zasoby, a nie całkowitą ilość CPU i pamięci.
- Zaktualizowano podstawowe komponenty platformy: 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. Dodano nowe pakiety HAMi 2.8.1 i Ouroboros 0.7.2.
- Ulepszona diagnostyka: cozyreport teraz zbiera informacje o Flux, cert-manager, środowisku hosta, Application, ApplicationDefinition i zasobach Tenant, a także tworzy summary.txt z krótkim podsumowaniem bieżących problemów. Dodano pulpity nawigacyjne Grafana oraz zasady zbierania danych do monitorowania GPU.
- Naprawiono błędy w MongoDB, Kafka, bootstrapie tenant Kubernetes, etcd, Velero, Kamaji, LINSTOR, SeaweedFS, Harbor, objectstorage-controller, API i innych komponentach. W API usunięto lukę IDOR w obsłudze TenantNamespace Get i Watch.
Podczas aktualizacji należy wziąć pod uwagę, że węzły robocze klastrów tenant będą jednym razem stopniowo wymieniane z powodu przejścia na stałe dyski PVC. Maszyny wirtualne KubeVirt uruchomione przed aktualizacją platformy będą wymagały zimnego restartu po przejściu na KubeVirt 1.8.2, ponieważ migracja na żywo starych procesów virt-launcher może zakończyć się błędem z powodu zmiany wersji QEMU. Ponadto parametry PostgreSQL są teraz typowane i sprawdzane według denylist, a cert-manager 1.20 domyślnie uruchamia kontenery z UID/GID 65532.
Źródło: opennet.ru
