Walidator YAML Kubernetes
Wklej jeden lub więcej manifestów Kubernetes (rozdzielonych ---) i zwaliduj je względem prawdziwego schematu przed kubectl apply.
Przeciągnij tu plik .yaml/.yml lub wklej tekst manifestu powyżej.
Manifesty rozdzielone znakiem "---" są walidowane jako osobne dokumenty.
Opcje zaawansowane
Parsowanie i walidacja działają w Twojej przeglądarce — z publicznego CDN pobierany jest wyłącznie schemat zasobu, nigdy Twój manifest.
Wklej powyżej manifest Kubernetes (lub wczytaj przykład), a wyniki walidacji pojawią się tutaj.
Wyłapywanie błędów w manifestach Kubernetes, zanim zrobi to kubectl
Odrzucone `kubectl apply` to zwykle pierwszy moment, w którym błąd w manifeście Kubernetes staje się widoczny — a wtedy często jesteś w trakcie wdrożenia i wpatrujesz się w komunikat cytujący ścieżkę walidacji JSON Schema (`spec.template.spec.containers[0].image: Required value`), która nie przekłada się oczywiście na plik YAML, który właśnie edytowałeś. Wychwycenie tej samej klasy błędów wcześniej, z podświetloną dokładną linią, zamienia to w poprawkę na pięć sekund zamiast zmiany kontekstu.
Sama składnia YAML ma ostre krawędzie, których nie ma w większości innych formatów konfiguracji: wcięcia są znaczące, a niespójne tabulatory i spacje w niektórych przypadkach po cichu dadzą inną (błędną) strukturę zamiast błędu; separatory dokumentów `---` łatwo zgubić w długim pliku z wieloma zasobami; a zbłąkany dodatkowy poziom zagnieżdżenia wygląda jak poprawny YAML, choć dla Kubernetesa znaczy coś zupełnie innego. To narzędzie parsuje podejściem, które zachowuje pełną informację o pozycji w źródle, więc problem ze składnią jest zgłaszany w rzeczywistej linii, w której występuje, a nie tylko „gdzieś w tym 200-wierszowym pliku”.
Przestarzałe apiVersion to pułapka o wolniejszym działaniu: Deploymenty `extensions/v1beta1`, StatefulSety i DaemonSety `apps/v1beta1`/`apps/v1beta2` oraz Ingressy `networking.k8s.io/v1beta1` nadal parsują się jako zupełnie poprawny YAML i nawet działały na starszych klastrach — dopóki klaster nie zostanie zaktualizowany poza wersję, w której Kubernetes ostatecznie całkowicie usuwa starą grupę API, i wtedy każdy manifest, który jej używa, zaczyna się nie stosować, bez wcześniejszego ostrzeżenia. Wychwycenie tego podczas edycji (z podpowiedzią właściwego apiVersion) pozwala uniknąć odkrycia problemu dopiero przy aktualizacji klastra.
Walidacja względem prawdziwej specyfikacji OpenAPI Kubernetesa wyłapuje resztę: pole `replicas`, które trafiło jako ciąg w cudzysłowie zamiast liczby, `containerPort` poza dopuszczalnym zakresem, wymagane pole, takie jak `spec.selector` w Deployment, które zniknęło przy kopiowaniu między manifestami. Żaden z tych błędów nie jest błędem składni YAML — plik parsuje się poprawnie — i dlatego właśnie osobne sprawdzenie schematu wyłapuje to, czego zwykłe przejrzenie pliku wzrokiem zazwyczaj nie zauważa.
Najczęstsze pytania
Czy to zastępuje `kubectl apply --dry-run` lub `kubeconform`?
Nie. `kubectl apply --dry-run=server` to jedyna kontrola działająca na serwerze API Twojego prawdziwego klastra (wraz z zainstalowanymi CRD i webhookami admission), a `kubeconform`/`kubeval` to dojrzałe narzędzia CLI stworzone do potoków CI. To narzędzie sprawdza tę samą klasę rzeczy — składnię YAML, kształt schematu, przestarzałe apiVersion — z karty przeglądarki, zanim skonfigurujesz `kubectl` do czegokolwiek, albo podczas przeglądania manifestu, który przysłał Ci ktoś inny.
Skąd pochodzą schematy?
Z `yannh/kubernetes-json-schema`, utrzymywanego przez społeczność, automatycznie aktualizowanego lustra schematów JSON Schema wywiedzionych z OpenAPI Kubernetesa, pobieranych na żądanie z publicznego CDN dla wybranej wersji Kubernetesa. Nic z Twojego manifestu nie jest nigdzie wysyłane — pobierany jest tylko sam (wersjonowany, publiczny) plik schematu, taki sam dla każdego użytkownika walidującego dany rodzaj/wersję.
Dlaczego tylko 10 rodzajów zasobów?
Deployment, Service, Ingress, ConfigMap, Secret, StatefulSet, DaemonSet, Job, CronJob i PersistentVolumeClaim obejmują zdecydowaną większość ręcznie pisanych manifestów. Pozostałe rodzaje nadal mają pełne sprawdzanie składni YAML i wykrywanie przestarzałych apiVersion — po prostu nie mają jeszcze walidacji kształtu według schematu.
Czy mój YAML kiedykolwiek opuszcza przeglądarkę?
Nie. Parsowanie i walidacja schematu działają w czystym JavaScripcie w tej karcie — jedyne żądanie sieciowe, jakie to narzędzie wysyła, to pobranie publicznego pliku JSON Schema dla wybranego rodzaju zasobu i wersji Kubernetesa, nigdy zawartości Twojego manifestu.