kubectl apply

Tworzy lub aktualizuje zasoby z plików manifestu (deklaratywnie).

kubectl apply to deklaratywny sposób zarządzania zasobami w Kubernetes. Zamiast ręcznie tworzyć i edytować obiekty pojedynczymi komendami, opisujesz pożądany stan w plikach manifestu (YAML lub JSON), a Kubernetes sam ustala, co dodać, zmienić albo zostawić w spokoju. Jeśli zasób nie istnieje, zostanie utworzony. Jeśli już jest, zostanie zaktualizowany tak, by pasował do manifestu. To podstawowe narzędzie pracy z GitOps i każdej sytuacji, w której chcesz, żeby Twój plik był jedynym źródłem prawdy o tym, jak ma wyglądać klaster.

Składnia i najważniejsze opcje

Podstawowa składnia: kubectl apply -f PLIK|KATALOG|URL [flagi]

  • -f, --filename — wskazuje plik, katalog albo URL z manifestem. Możesz podać tę flagę wielokrotnie.
  • -R, --recursive — przeszukuje katalog rekurencyjnie, łącznie z podkatalogami.
  • -k, --kustomize — stosuje konfigurację zbudowaną przez Kustomize (katalog z kustomization.yaml).
  • --dry-run — przyjmuje none, client albo server. Pozwala zobaczyć, co by się stało, bez zapisu (server dodatkowo waliduje po stronie API).
  • --server-side — włącza Server-Side Apply, gdzie to API server zarządza własnością pól zamiast klienta.
  • --force-conflicts — przy --server-side wymusza przejęcie pól, gdy pojawia się konflikt własności.
  • -n, --namespace — wskazuje przestrzeń nazw, w której operujesz.
  • --prune — usuwa wcześniej zaaplikowane zasoby, których nie ma już w bieżącym zestawie (używaj ostrożnie, najlepiej z -l i --prune-allowlist).

Przykłady użycia

  • kubectl apply -f deployment.yaml — tworzy lub aktualizuje zasoby opisane w jednym pliku.
  • kubectl apply -f ./manifests/ -R — aplikuje wszystkie manifesty z katalogu i jego podkatalogów naraz.
  • kubectl apply -f deployment.yaml --dry-run=server — sprawdza i waliduje zmianę po stronie serwera, niczego nie zapisując.
  • kubectl apply -k ./overlays/prod — buduje konfigurację Kustomize z katalogu i od razu ją aplikuje.
  • kubectl apply -f https://raw.githubusercontent.com/user/repo/main/svc.yaml — aplikuje manifest prosto z adresu URL.

Częste błędy i pułapki

Najczęstsza wpadka to mieszanie kubectl apply z poleceniami imperatywnymi jak kubectl edit czy kubectl create. apply opiera się na adnotacji last-applied-configuration, żeby liczyć różnice. Jeśli zmodyfikujesz zasób ręcznie, a potem aplikujesz manifest, możesz zobaczyć nieoczekiwane nadpisania albo pozostawione „sieroce” pola. Trzymaj się jednego trybu.

Uważaj z --prune. To wciąż niedopracowany mechanizm — bez precyzyjnego selektora -l i listy --prune-allowlist potrafi skasować więcej, niż się spodziewasz. Najpierw przetestuj z --dry-run=client.

Pamiętaj też, że apply aktualizuje istniejący obiekt, ale nie zmieni pól tylko do odczytu (np. większości elementów specyfikacji Pod) — wtedy dostaniesz błąd i trzeba usunąć oraz utworzyć zasób na nowo. Jeśli nie podasz -n, zasób trafia do namespace z aktualnego kontekstu, a nie zawsze do default.

Powiązane komendy: kubectl create, kubectl delete, kubectl get, kubectl diff, kubectl edit, kubectl replace.