kubectl describe

Pokazuje szczegóły zasobu wraz ze zdarzeniami (events).

kubectl describe to twoje pierwsze narzędzie, gdy coś w Kubernetesie nie działa, a nie wiesz dlaczego. Pokazuje pełny, czytelny dla człowieka opis zasobu (poda, deploymentu, węzła, serwisu) razem z sekcją Events na końcu, gdzie zwykle leży odpowiedź: brak obrazu, niewystarczające zasoby, nieudany probe, problem z montowaniem wolumenu. W przeciwieństwie do kubectl get -o yaml, które wypluwa surowy manifest, describe agreguje powiązane informacje (kontrolery, zdarzenia) w jedną sensowną całość.

Składnia i najważniejsze opcje

Podstawowa forma: kubectl describe TYPE NAME (np. kubectl describe pod nginx). Działa też zapis TYPE/NAME oraz wskazanie zasobów po pliku albo etykiecie.

  • -n, --namespace — wskazuje przestrzeń nazw; bez tego describe patrzy tylko w bieżącą (zwykle default).
  • -A, --all-namespaces — przeszukuje wszystkie przestrzenie nazw naraz.
  • -l, --selector — opisuje zasoby pasujące do selektora etykiet, np. -l app=web.
  • -f, --filename — opisuje zasoby zdefiniowane w pliku, katalogu lub URL-u manifestu.
  • -R, --recursive — przy -f wchodzi rekurencyjnie w podkatalogi.
  • --show-events — czy dołączyć sekcję zdarzeń; domyślnie true, ustaw --show-events=false, by ją pominąć.

Przykłady użycia

  • kubectl describe pod web-7d9f-abcde -n produkcja — pełna diagnostyka konkretnego poda w przestrzeni produkcja, z eventami na dole.
  • kubectl describe deployment frontend — pokazuje strategię wdrożenia, liczbę replik i status rolloutu deploymentu frontend.
  • kubectl describe node worker-01 — kondycja węzła: zużycie zasobów, taints, warunki (np. DiskPressure) i pody na nim działające.
  • kubectl describe pods -l app=api — opisuje wszystkie pody z etykietą app=api za jednym zamachem.
  • kubectl describe -f deployment.yaml — opisuje zasoby zdefiniowane w manifeście, bez ręcznego wpisywania nazw.

Częste błędy i pułapki

Najczęstsza wpadka juniora: NotFound, bo zapomniałeś o -n i szukasz poda w złej przestrzeni nazw. Po drugie — sekcja Events jest ulotna: domyślnie zdarzenia żyją tylko około godziny, więc jeśli pod wywalił się wczoraj, describe może już nic nie pokazać (sięgnij wtedy po logi). Pamiętaj też, że describe jest tylko do czytania — niczego nie zmienia, więc możesz go odpalać bez obaw. Nie myl go z kubectl get -o yaml: jeśli potrzebujesz dokładnych pól manifestu do skryptu, describe się nie nadaje, bo formatuje wyjście pod człowieka, nie pod parser.

Powiązane komendy: kubectl get (lista i surowy YAML), kubectl logs (logi kontenera), kubectl events (same zdarzenia, też po przeterminowaniu z describe), kubectl explain (opis pól zasobu).