kubectl logs

Wyświetla logi kontenera w podzie.

kubectl logs wyciąga z Kubernetesa to, co kontener wypisał na standardowe wyjście (stdout/stderr). To pierwsze narzędzie, po które sięgasz, gdy pod się sypie, restartuje albo zwraca błędy — zamiast logować się do kontenera, prosisz API Kubernetesa o jego logi. Domyślnie pokazuje logi jednego kontenera w wskazanym podzie i kończy działanie. Jeśli pod ma kilka kontenerów, musisz wskazać który (-c), bo inaczej kubectl albo poprosi o doprecyzowanie, albo weźmie domyślny.

Składnia i najważniejsze opcje

Podstawowa forma: kubectl logs [-f] [-p] (POD | TYPE/NAME) [-c CONTAINER] [flags]

  • -f, --follow — strumieniuje logi na żywo (jak tail -f), póki nie przerwiesz Ctrl+C.
  • -p, --previous — pokazuje logi z poprzedniej, już ubitej instancji kontenera. Złoto, gdy pod wpadł w CrashLoopBackOff.
  • -c CONTAINER, --container — wybiera konkretny kontener w wielokontenerowym podzie.
  • --all-containers — zwraca logi ze wszystkich kontenerów poda naraz.
  • --tail=N — tylko ostatnie N linii (domyślnie wszystko, a przy -f ostatnie 10).
  • --since=DURATION — logi z ostatniego okresu, np. 1h, 15m, 30s.
  • --timestamps — dokleja znacznik czasu do każdej linii.
  • -l SELECTOR, --selector — logi z wszystkich podów pasujących do etykiety, nie z jednego.

Przykłady użycia

  • kubectl logs my-pod — pokazuje całość logów poda my-pod i kończy.
  • kubectl logs -f my-pod — śledzi logi na bieżąco, idealne przy debugowaniu requestów.
  • kubectl logs my-pod -c sidecar --tail=50 — ostatnie 50 linii z kontenera sidecar.
  • kubectl logs my-pod -p — logi z poprzedniego, padniętego kontenera; pierwsze co robisz przy restart loop.
  • kubectl logs -l app=api --since=10m --timestamps — logi z ostatnich 10 minut ze wszystkich podów z etykietą app=api, ze znacznikami czasu.

Częste błędy i pułapki

  • Wiele kontenerów bez -c — kubectl odmówi albo zgadnie. Sprawdź nazwy przez kubectl get pod my-pod -o jsonpath='{.spec.containers[*].name}'.
  • Pusty wynik po restarcie — bieżący kontener dopiero wstał i nic nie wypisał. Tego, co było przed krachem, szukaj przez -p.
  • Logi nie znikają w nieskończoność — kubectl zna tylko bufor kubeleta dla aktualnej instancji. Po usunięciu poda logi przepadają, chyba że masz centralny stack (Loki, ELK).
  • -l i limit podów — przy selektorze kubectl czyta z ograniczonej liczby podów; przy dużych deploymentach nie zobaczysz wszystkiego. Do agregacji użyj zewnętrznego narzędzia.
  • Mylenie z opisem stanu — jeśli pod w ogóle nie startuje (ImagePullBackOff, brak schedulowania), logów nie ma. Tam zaglądasz przez kubectl describe pod, nie logs.

Powiązane komendy: kubectl describe pod, kubectl get pods, kubectl exec, kubectl events, a do wielu podów naraz zewnętrzne stern.