kubectl create to imperatywny sposób na powołanie zasobu w klastrze Kubernetes. Mówisz wprost: „stwórz mi to teraz” — albo podajesz gotowy plik manifestu (-f), albo używasz podkomendy generatora (np. deployment, configmap, secret, namespace, job). W przeciwieństwie do kubectl apply, które jest deklaratywne i idempotentne, create zawsze próbuje utworzyć nowy obiekt — jeśli taki już istnieje, dostaniesz błąd AlreadyExists. To narzędzie do szybkiego rozkręcania zasobów i do generowania szkieletów YAML.
Składnia i najważniejsze opcje
Podstawowa forma to kubectl create RESOURCE [flagi] lub kubectl create -f PLIK.yaml.
-f, --filename— tworzy zasób z pliku, katalogu albo adresu URL (można podać flagę kilka razy).-k, --kustomize— buduje zasoby z katalogu zawierającegokustomization.yaml.--dry-run— przyjmujenone,clientlubserver; symuluje tworzenie bez zapisu w klastrze.-o, --output— format wyjścia, np.yamllubjson; w parze z dry-run generuje gotowy manifest.--save-config— zapisuje konfigurację w adnotacji obiektu, żeby później dało się go aktualizować przezapply.--edit— otwiera wygenerowany manifest w edytorze, zanim obiekt powstanie.-n, --namespace— wskazuje przestrzeń nazw, w której zasób ma powstać.--validate— kontrola schematu (np.strict), zanim coś poleci na serwer.
Przykłady użycia
kubectl create -f deployment.yaml— tworzy zasoby opisane w pliku manifestu.kubectl create deployment nginx --image=nginx:1.27— powołuje Deployment z podanym obrazem bez pisania YAML-a.kubectl create namespace dev— zakłada nową przestrzeń nazw dev.kubectl create deployment web --image=nginx --dry-run=client -o yaml > web.yaml— generuje gotowy manifest do pliku, niczego nie tworząc w klastrze (klasyczny trik na szybki szkielet YAML).kubectl create secret generic db-pass --from-literal=password=tajne— tworzy Secret z wartością podaną wprost.
Częste błędy i pułapki
Najczęstsza wpadka to próba „aktualizacji” przez ponowne create — dostaniesz AlreadyExists, bo to nie jest komenda od zmian. Do modyfikacji istniejących obiektów używaj apply albo edit. Druga pułapka: --dry-run=client sprawdza tylko po stronie klienta i nie złapie błędów walidacji serwera — do realnego testu użyj --dry-run=server. Pamiętaj też, że create nie ma sensownego trybu „zaktualizuj jeśli się różni”, więc w pipeline’ach CI/CD lepiej trzymać się apply. I uwaga na sekrety z --from-literal — hasło ląduje w historii powłoki, więc na produkcji raczej --from-file.
Powiązane komendy: kubectl apply, kubectl edit, kubectl delete, kubectl get, kubectl run, kubectl expose.