Co robi ten walidator
Manifesty Kubernetesa wyglądają jak zwykły YAML, ale prawdziwa walidacja dzieje się dopiero w klastrze: `kubectl apply` przyjmuje plik, a dopiero potem, po przejściu przez API server i admission controllery, dowiadujesz się, że coś jest nie tak. Wtedy może już być za późno: źle skonfigurowany Deployment kręci się w produkcji bez liveness probe, bez limitów zasobów, a Service nie kieruje ruchu do podów, bo selector etykiet nie pasuje.
To narzędzie łapie 30 najczęstszych pomyłek zanim apply'ujesz. Wklejasz dowolny manifest K8s, multi-doc z separatorem `---` też zadziała. Walidator parsuje każdy dokument, wykrywa kind i odpala ręcznie zakodowane sprawdzenia: brak `apiVersion` czy `metadata.name`, Service z `targetPort`, który nie istnieje w podzie, Deployment z selectorem nie pasującym do etykiet poda, kontenery z `privileged: true`, tagi `:latest`, brak limitów i probe'ów, Ingress na przestarzałej wersji API, PVC bez rozmiaru.
Wszystko działa w przeglądarce. Bez uploadu, bez kubectl, bez kontaktu z klastrem. Walidator nie pobiera schematów CRD z Twojego klastra (te żyją tam), więc custom resources pokazują się tylko jako info.
Jak używać
- Wybierz przykład u góry, żeby zobaczyć jak wygląda wynik, albo wklej własny YAML w panelu wejściowym. Walidator obsługuje pliki multi-doc z separatorem `---`.
- Po prawej masz liczniki błędów / ostrzeżeń / info. Błędy to rzeczy, które API server odrzuci albo będą działać błędnie (brak pól, niepasujący selector, niepoprawny HPA). Ostrzeżenia to naruszenia dobrych praktyk (`:latest`, brak limitów zasobów, `privileged: true`). Info to sugestie.
- Każdy issue pokazuje kind, nazwę zasobu, indeks dokumentu (który manifest w pliku multi-doc), wiadomość i podpowiedź naprawy.
- Często wskazywane poprawki: dodaj liveness/readiness probe, ustaw requesty i limity zasobów, usuń hostPort, zamień `:latest` na konkretny tag, dopasuj selector matchLabels do template metadata.labels, ustaw HPA scaleTargetRef i sensowny zakres min/max replik.
- Dla Services walidator dodatkowo sprawdza, że `targetPort` rzeczywiście istnieje jako `containerPort` w podzie wybranym przez `spec.selector`. Łapie to klasyczny błąd Service'a, który po cichu nie routuje nigdzie.
- Gdy wejście jest puste albo parsowanie YAML pada, dostajesz błąd parsowania z numerem linii z js-yaml. Najpierw napraw to, a reszta sprawdzeń się odpali.
- Kliknij Kopiuj, żeby wrzucić manifest do schowka, potem wklej do `kubectl apply -f -`, żeby faktycznie wdrożyć. Walidator nigdzie nie wysyła Twojego YAMLa.
Kiedy się przydaje
Siedem konkretnych sytuacji, w których złapanie błędów K8s przed kubectl apply oszczędza realnego downtime:
- Pierwszy raz z K8s. Dokumentacja oficjalna jest ogromna i jeszcze nie masz intuicji, które pola są obowiązkowe. Walidator natychmiast wskazuje brak `apiVersion`, `kind`, `metadata.name` i daje podpowiedź naprawy.
- Service, który łączy się z niczym. Klasyk: selector Service'a mówi `app: web`, etykiety w template Deploymentu mówią `app: api`. K8s tworzy Service, Service nie ma endpointów, ruch wraca 503. Walidator pokaże dokładnie, które klucze nie pasują.
- Pre-commit gate dla repo K8s. Wpinasz check w proces review. PR, które wprowadzają `privileged: true`, `:latest`, brak limitów, brak probe'ów dostają flagę przed mergem.
- Audyt repo GitOps. Repo z setkami manifestów ciężko sprawdzić wzrokowo. Wklejasz plik, widzisz wszystkie issues naraz. Powtarzasz na pliku albo wpinasz ręcznie w CI.
- Migracja Ingress z extensions/v1beta1 do networking.k8s.io/v1. Walidator flaguje starą wersję API z jednowierszowym fixem. Oszczędza deploy, który zwróci 404 po następnym upgrade klastra.
- CronJob bez limitów na małym nodzie. Nocny backup bez limitu pamięci może OOM-ować całego noda. Walidator ostrzega o każdym kontenerze bez limitów.
- HPA źle skonfigurowane, skaluje tylko między 1 a 1. Sprawdzenie łapie `minReplicas >= maxReplicas` (niepoprawne) i brak `scaleTargetRef` (przez co HPA nic nie robi).