Generator Kubernetes StatefulSet

Generator Kubernetes StatefulSet

StatefulSet służy aplikacjom wymagającym trwałej tożsamości i dysku – bazom danych, kolejkom, systemom rozproszonym. W odróżnieniu od Deployment każda replika ma stałą nazwę, własny wolumen i własny adres DNS. Generator składa gotowy manifest Kubernetes StatefulSet (opcjonalnie z headless Service), liczy łączne zużycie dysku, CPU i pamięci oraz pokazuje nazwy podów, PVC i adresy, które powstaną w klastrze.

StatefulSet kontra Deployment

Co zawiera wygenerowany manifest

• serviceName – wskazuje Service o tej samej nazwie co StatefulSet; po zaznaczeniu opcji generator dokłada jego definicję z clusterIP: None,
• volumeClaimTemplates – szablon PVC o nazwie data z trybem ReadWriteOnce, rozmiarem i storageClassName (puste pole oznacza domyślną klasę klastra),
• volumeMounts z katalogiem danych i opcjonalnym subPath,
• resources – requests i limits CPU oraz pamięci dla jednego poda,
• securityContext z runAsNonRoot: true, profilem seccomp RuntimeDefault, odebranymi capabilities i – jeśli podasz UID/GID – runAsUser, runAsGroup oraz fsGroup,
• opcjonalnie envFrom z Secretem (np. z hasłem bazy), readinessProbe typu TCP na porcie kontenera i podManagementPolicy: Parallel.

Przyciski PostgreSQL, MySQL, Redis i MongoDB wypełniają obraz, port, katalog danych, subPath i UID/GID typowymi wartościami oficjalnych obrazów. Wynik możesz skopiować albo pobrać jako statefulset.yaml; pod manifestem są też polecenia kubectl do wdrożenia i sprawdzenia podów oraz PVC.

Jak działa generator

Generator przyjmuje nazwę obiektu, obraz, liczbę replik (1–100), port, namespace, parametry dysku i zasoby, a następnie składa z nich manifest YAML. Narzędzie nie łączy się z klastrem i nie odczytuje z niego żadnych danych, więc każda wartość w polu wynikowym jest wprost konsekwencją tego, co wpisałeś. Przed wygenerowaniem sprawdza poprawność danych: nazwy muszą spełniać reguły DNS (do 63 znaków, małe litery, cyfry i myślniki), obraz musi mieć tag lub digest, a tag :latest jest odrzucany. Request CPU lub pamięci większy niż limit też blokuje wynik, bo Kubernetes nie przyjąłby takiego manifestu.

Podstawą działania StatefulSet jest tożsamość wyprowadzona z liczby porządkowej. Przy liczbie replik równej N pody nazywają się nazwa obiektu plus myślnik i indeks od zera do N minus jeden. Nazwa nie zawiera losowego sufiksu, więc pozostaje niezmieniona po restarcie. Ten sam indeks wiąże pod z wolumenem: volumeClaimTemplates tworzy osobny PVC dla każdej repliki, a Kubernetes nadaje mu nazwę zbudowaną z nazwy szablonu i nazwy poda. Dzięki temu usunięty i ponownie utworzony pod wraca do tego samego dysku.

Generator wypisuje spójną etykietę app w spec.selector, w szablonie poda i w selektorze Service. Kolejność pól i wcięcia są stałe, więc dwa uruchomienia z tymi samymi parametrami dają identyczny plik, co ułatwia porównywanie manifestów w repozytorium.

Przykład krok po kroku: PostgreSQL z 3 replikami

1. Kliknij preset PostgreSQL. Nazwa to postgres, obraz postgres:16, port 5432, katalog danych /var/lib/postgresql/data, subPath pgdata, UID/GID 999.
2. Ustaw liczbę replik na 3, rozmiar wolumenu 10Gi, klasę przechowywania standard i namespace default.
3. Wygenerowany manifest tworzy pody postgres-0, postgres-1 i postgres-2 oraz wolumeny data-postgres-0, data-postgres-1 i data-postgres-2. Łączne zapotrzebowanie na dysk to 3 × 10 Gi = 30 Gi, ponieważ każda replika dostaje własny PVC.
4. Przy domyślnych zasobach (request 250m CPU i 512Mi pamięci, limit 1 CPU i 1Gi) cały StatefulSet rezerwuje 3 × 250m = 0,75 vCPU i 3 × 512 Mi = 1,5 Gi pamięci, a może zużyć do 3 vCPU i 3 Gi.
5. Zmień liczbę replik na 5: dochodzą pody postgres-3 i postgres-4 oraz dwa nowe wolumeny po 10 Gi, więc dysk łącznie to 50 Gi, a requests rosną do 1,25 vCPU i 2,5 Gi.
6. Przy włączonym headless Service każdy pod ma adres w postaci postgres-0.postgres.default.svc.cluster.local (przy domyślnej domenie klastra). W obrębie tego samego namespace wystarczy krótsza forma postgres-0.postgres, co pozwala adresować konkretną replikę.

Pola manifestu i ich źródło

Praktyczne wskazówki

• Utrzymuj serviceName spójne z istniejącym Service. Jeśli wyłączysz opcję Service, a nie utworzysz go osobno, pody nie dostaną stabilnych nazw DNS i komunikacja między replikami przestanie działać.
• Nie zmieniaj nazwy obiektu po wdrożeniu. Nowa nazwa oznacza nowy StatefulSet i nowe wolumeny, a poprzednie PVC zostają w klastrze i nadal zajmują miejsce.
• Sprawdź, czy klasa przechowywania istnieje (kubectl get storageclass). Generator wpisuje storageClassName dosłownie; przy nieistniejącej klasie wolumeny pozostaną w stanie Pending.
• Podaj UID/GID zgodny z obrazem. Manifest zawsze ma runAsNonRoot: true, więc obraz, który domyślnie startuje jako root, bez runAsUser się nie uruchomi.
• Ustaw subPath dla baz danych. Świeży wolumen bywa niepusty (katalog lost+found), przez co PostgreSQL lub MySQL odmawia inicjalizacji katalogu danych.
• Trzymaj manifest w repozytorium. Deterministyczne wyjście sprawia, że w porównaniu wersji widać dokładnie tę zmianę, którą wprowadziłeś.

Ograniczenia narzędzia

• Brak walidacji względem klastra. Narzędzie nie sprawdza wersji API, dostępności klasy przechowywania, istnienia Secretu ani limitów przydziału w przestrzeni nazw.
• Tylko szkielet obiektu. Nie generuje konfiguracji aplikacji, samego Secretu, ConfigMap ani reguł sieciowych. Nie konfiguruje też replikacji danych: trzy pody PostgreSQL to trzy niezależne bazy, dopóki nie zajmie się tym aplikacja lub operator.
• Brak polityki usuwania wolumenów. Manifest nie ustawia persistentVolumeClaimRetentionPolicy, więc obowiązuje domyślne zachowanie: PVC zostają po usunięciu StatefulSet i po zmniejszeniu liczby replik.
• Prosta sonda gotowości. Readiness probe sprawdza tylko, czy port TCP jest otwarty, a nie czy aplikacja przyjmuje zapytania.
• Nie weryfikuje obrazu w rejestrze. Literówka w nazwie lub nieistniejący tag ujawnią się dopiero przy wdrożeniu.