kubectl config to zestaw poleceń do zarządzania plikiem kubeconfig, czyli tym, w którym kubectl trzyma adresy klastrów, dane uwierzytelniające i konteksty (powiązania klaster + użytkownik + namespace). Dzięki niemu przełączasz się między klastrami i namespace’ami bez ręcznego dłubania w YAML-u. Sam kubectl config nic nie robi na klastrze — operuje wyłącznie na lokalnym pliku konfiguracyjnym (domyślnie ~/.kube/config), więc to twoja „książka adresowa”, a nie wykonanie czegokolwiek na produkcji.
Składnia i najważniejsze opcje
Podstawowa forma to kubectl config SUBCOMMAND [opcje]. Najczęściej używane podkomendy i flagi:
view— wyświetla scalony kubeconfig (klastry, konteksty, użytkownicy).get-contexts— lista wszystkich kontekstów; gwiazdka oznacza aktywny.current-context— pokazuje nazwę aktualnie używanego kontekstu.use-context NAZWA— przełącza aktywny kontekst na podany.set-context— tworzy lub aktualizuje kontekst; z flagą--currentmodyfikuje bieżący.--minify— przyviewpokazuje tylko dane związane z aktywnym kontekstem.--flatten— wstawia certyfikaty i tokeny inline zamiast odwołań do plików (przydatne przy eksporcie).--kubeconfig PLIK— wskazuje inny plik konfiguracyjny niż domyślny.
Przykłady użycia
kubectl config get-contexts— wypisuje wszystkie dostępne konteksty z zaznaczeniem aktywnego. Pierwszy ruch, gdy nie wiesz, gdzie aktualnie celujesz.kubectl config use-context produkcja— przełącza cię na klaster produkcyjny. Od tej chwili każdekubectl get podsleci tam.kubectl config set-context --current --namespace=dev— przypina namespacedevdo bieżącego kontekstu, żeby nie dopisywać-n devprzy każdym poleceniu.kubectl config view --minify --flatten— wyciąga kompletną konfigurację tylko aktywnego kontekstu, z osadzonymi danymi logowania. Wygodne do przeniesienia dostępu na inną maszynę.kubectl config current-context— szybkie upewnienie się, na którym klastrze jesteś, zanim coś skasujesz.
Częste błędy i pułapki
Klasyk to działanie na złym klastrze — wpisujesz delete będąc przekonanym, że to środowisko testowe, a kontekst wskazuje produkcję. Wyrób sobie nawyk sprawdzania current-context przed destrukcyjnymi operacjami. Pamiętaj też, że set-context bez --current wymaga podania nazwy — inaczej zmodyfikujesz nie ten kontekst, co trzeba.
Druga pułapka: kubectl config view domyślnie maskuje sekrety jako DATA+OMITTED, więc nie zobaczysz tam tokenów — dopiero --flatten je ujawnia. Traktuj wynik takiego eksportu jak hasło. Uważaj na zmienną KUBECONFIG: jeśli wskazuje na kilka plików rozdzielonych dwukropkiem, kubectl scala je, a zapisy trafiają do pierwszego z listy — łatwo wtedy „zgubić” wprowadzoną zmianę.
Powiązane komendy: kubectl config use-context, kubectl config set-credentials, kubectl config set-cluster, kubectl config delete-context oraz kubens i kubectx jako wygodniejsze nakładki.