Generator Kubernetes Namespace

Generator manifestu Namespace

Namespace dzieli klaster na logiczne przestrzenie. Zasoby w różnych namespace mają odrębne nazwy, co ułatwia pracę wielu zespołom i środowiskom.

Po co namespace?

• Izolacja środowisk: dev, staging, production.
• Osobne uprawnienia i limity dla zespołów.
• Łatwiejsze porządkowanie i sprzątanie zasobów.
• Kontrola kosztów i polityk sieciowych.

Etykiety

Etykiety (labels) opisują namespace i umożliwiają selekcję. Przykładowe: team: backend, environment: staging.

Przykład

apiVersion: v1
kind: Namespace
metadata:
  name: staging
  labels:
    team: backend

Jak działa generator manifestu Namespace

Generator przyjmuje od Ciebie nazwę namespace oraz opcjonalne etykiety. Na tej podstawie buduje obiekt Kubernetes typu Namespace w wersji apiVersion: v1. Nie odwołuje się do klastra ani nie sprawdza, czy zasób już istnieje — działa wyłącznie na tekście. Wynikiem jest manifest YAML, który możesz zapisać i zastosować później.

Mechanizm jest deterministyczny: ta sama nazwa i ten sam zestaw etykiet dają identyczny YAML. Generator pilnuje składni pól metadata.name oraz metadata.labels. Nazwa trafia do metadata.name, a pary klucz-wartość do sekcji labels. YAML jest wcięty zgodnie z hierarchią, więc klaster może go odczytać bez dodatkowego formatowania.

Warto pamiętać, że Namespace jest zasobem klastrowym, a nie zasobem w innym namespace. Nie ma więc pola metadata.namespace. Generator nie tworzy polityk, limitów ani uprawnień. To osobne manifesty, które trzeba dodać ręcznie. Narzędzie koncentruje się tylko na poprawnym szkielecie Namespace.

Przykład krok po kroku: namespace backend-prod z etykietami

1. Wpisz nazwę: backend-prod. Nazwa ma 12 znaków (backend 7, myślnik 1, prod 4) i spełnia reguły DNS-1123 dla etykiet, bo zawiera małe litery oraz myślnik.
2. Dodaj etykietę zespołu: team: backend. To para klucz-wartość, która później pomoże wybierać zasoby przez selektory.
3. Dodaj etykietę środowiska: environment: production. Dzięki temu namespace można odróżnić od innych środowisk bez zaglądania w nazwę.
4. Wygeneruj manifest: narzędzie łączy apiVersion: v1, kind: Namespace oraz metadata z nazwą i dwiema etykietami.
5. Policz linie: apiVersion: v1, kind: Namespace, metadata:, name: backend-prod, labels:, team: backend, environment: production — razem 7 linii. To minimalny poprawny manifest dla tego przypadku.
6. Zastosuj w klastrze: zapisz plik jako backend-prod.yaml i wykonaj kubectl apply -f backend-prod.yaml. Wynikiem będzie utworzenie namespace backend-prod, o ile nazwa nie jest zajęta.

Pola manifestu Namespace — szybka ściągawka

Praktyczne wskazówki przy generowaniu namespace

• Nazwa zgodna z DNS-1123 — używaj małych liter, cyfr i myślników. Nie zaczynaj ani nie kończ nazwy myślnikiem, bo walidacja Kubernetes odrzuci manifest.
• Spójne etykiety — ten sam klucz team i environment w różnych namespace ułatwia filtrowanie oraz porządkowanie zasobów.
• Nie ustawiaj metadata.namespace — to częsty błąd przy kopiowaniu manifestów. Namespace jest zasobem klastrowym i nie zagnieżdża się w innym namespace.
• Używaj kubectl apply — apply jest deklaratywne i pozwala aktualizować etykiety bez ręcznego usuwania namespace.
• Sprawdzaj konflikty nazw — przed zastosowaniem manifestu upewnij się, że namespace o wybranej nazwie nie istnieje już w klastrze.

Ograniczenia generatora Namespace

• Nie wykonuje operacji w klastrze — narzędzie generuje wyłącznie YAML. Nie utworzy, nie zmieni ani nie usunie namespace.
• Nie waliduje konfliktów nazw — składnia może być poprawna, a namespace o tej nazwie może już istnieć. Konflikt wyjdzie przy kubectl apply.
• Nie dodaje innych zasobów — nie tworzy powiązanych polityk, limitów ani uprawnień. To osobne manifesty, które trzeba przygotować ręcznie.
• Nie zna stanu klastra — nie sprawdza istniejących namespace, ich etykiet ani obowiązujących uprawnień. Wynik zależy tylko od danych wejściowych.

Kiedy generator namespace realnie się przydaje

• Nowy zespół w klastrze — gdy wdrażasz kolejny zespół i chcesz od razu dać mu osobne miejsce na zasoby. Sprawdź, czy wybrana nazwa nie koliduje z tym, co już istnieje, oraz czy etykieta team pokrywa się z konwencją przyjętą w repozytorium.
• Rozdzielenie środowisk w jednym klastrze — gdy dev, staging i production mają działać obok siebie, a różnić się tylko nazwą i etykietą environment. Wygeneruj manifest osobno dla każdego wariantu i porównaj, czy poza tymi dwoma polami pliki są identyczne.
• Praca bez dostępu do klastra — gdy przygotowujesz pliki dla kogoś innego albo pracujesz offline. Zwróć uwagę na zgodność nazw i etykiet z ustaleniami zespołu, bo narzędzie nie odniesie ich do stanu klastra.
• Fundament pod polityki i limity — namespace jest punktem odniesienia dla ResourceQuota, LimitRange czy NetworkPolicy. Sprawdź, czy nazwa z manifestu zgadza się z nazwą używaną w tych plikach oraz w poleceniach z flagą -n.
• Repozytorium GitOps — gdy manifest ma trafić do katalogu z pozostałymi plikami i być stosowany automatycznie. Sprawdź spójność etykiet między środowiskami, bo selektory w innych manifestach zależą właśnie od tych wartości.

Najczęstsze błędy przy generowaniu manifestu

Większość problemów wynika ze składni YAML, a nie z samego obiektu Namespace. Wklejony plik często ma tabulatory zamiast spacji, brak spacji po dwukropku albo etykiety zapisane jako lista, a nie jako pary klucz-wartość. Uważaj też na wartości, które YAML potrafi zinterpretować jako typ logiczny — zapis bez cudzysłowu może zostać odczytany inaczej, niż zakładasz. Po wygenerowaniu manifestu przejrzyj wcięcia i przepuść plik przez walidator YAML, zanim trafi do klastra.

Drugi typ błędów to niespójne etykiety. Klucz team w jednym namespace i Team w innym wygląda podobnie, ale selektor ich nie połączy; to samo dotyczy par environment i env. Ustal jeden zestaw kluczy i trzymaj się go we wszystkich środowiskach. Nie zostawiaj pustych wartości etykiet, bo taki wpis niczego nie filtruje. Generator buduje poprawny szkielet, ale nie zna konwencji Twojego projektu — zgodność nazw i etykiet musisz zapewnić sam.

Najczęstsze pytania