kubectl scale

kubectl scale to polecenie, którym ręcznie ustawiasz liczbę replik (czyli działających podów) dla obiektu w Kubernetes — najczęściej Deployment, ale też StatefulSet, ReplicaSet czy ReplicationController. Mówisz klastrowi „chcę dokładnie N kopii tej aplikacji”, a kontroler dba o to, żeby tyle podów faktycznie chodziło: dokłada brakujące albo ubija nadmiarowe. To Twoje główne narzędzie do ręcznego zwiększania mocy pod ruch albo do zatrzymania aplikacji bez kasowania jej konfiguracji (skalowanie do zera).

Składnia i najważniejsze opcje

Podstawowa forma wygląda tak: kubectl scale --replicas=N TYPE/NAME

• --replicas=N — docelowa liczba replik. To jedyna obowiązkowa flaga; bez niej polecenie nie wie, do ilu ma skalować.
• --current-replicas=N — warunek wstępny: skaluj tylko, jeśli obecna liczba replik wynosi dokładnie N. Świetne przeciw wyścigom (race condition), gdy ktoś lub HPA grzebie przy tym samym obiekcie.
• --resource-version=V — skaluj tylko, jeśli zasób ma podaną wersję. Druga warstwa zabezpieczenia przed nadpisaniem cudzej zmiany.
• --all — zastosuj do wszystkich obiektów danego typu w przestrzeni nazw, zamiast wskazywać jeden po nazwie.
• -l, --selector — wybierz obiekty po etykietach, np. -l app=web, zamiast podawać nazwę.
• -f, --filename — wskaż obiekt z pliku YAML/JSON zamiast pisać TYPE/NAME w wierszu poleceń.
• --timeout=30s — ile czekać na zakończenie operacji; 0 oznacza „nie czekaj”.
• -n, --namespace — przestrzeń nazw, w której działa obiekt (domyślnie default).

Przykłady użycia

• kubectl scale --replicas=5 deployment/nginx — ustawia 5 replik deploymentu nginx.
• kubectl scale --replicas=0 deployment/worker — zbija aplikację do zera podów, np. na noc lub do oszczędzania zasobów, bez kasowania konfiguracji.
• kubectl scale --current-replicas=2 --replicas=4 deployment/api — podwaja repliki, ale tylko jeśli teraz jest ich dokładnie 2.
• kubectl scale --replicas=3 statefulset/postgres — skaluje StatefulSet (uwaga: tu kolejność i tożsamość podów ma znaczenie).
• kubectl scale --replicas=2 -l app=frontend --all — skaluje wszystkie pasujące do etykiety obiekty naraz.

Częste błędy i pułapki

Największa pułapka: jeśli na obiekcie działa HorizontalPodAutoscaler, Twoje ręczne skalowanie zostanie po chwili nadpisane przez HPA. Wtedy „magicznie” wraca poprzednia liczba podów i myślisz, że polecenie nie zadziałało — zadziałało, tylko autoskaler je cofnął.

Druga sprawa: kubectl scale zmienia stan tylko w klastrze. Jeśli trzymasz manifesty w Git i robisz kubectl apply, następne wdrożenie przywróci replicas z pliku. Skalowanie z palca to rozwiązanie doraźne, nie trwałe. Pamiętaj też, że Pody i Joby skalujesz nie tym poleceniem — pojedynczego Poda nie da się „przeskalować”, a do Jobów służy parallelism.

Powiązane komendy: kubectl get, kubectl apply, kubectl autoscale, kubectl rollout, kubectl edit.