Co to jest kubectl?
Autor: Redakcja Domeny.ForSale Opublikowano
W skrócie: kubectl to narzędzie wiersza poleceń do obsługi Kubernetes — systemu, który zarządza aplikacjami uruchamianymi w kontenerach. Pozwala sprawdzać stan aplikacji, wdrażać zmiany, odczytywać logi i zarządzać zasobami klastra. Nie jest samym Kubernetes ani nie tworzy automatycznie środowiska do uruchamiania aplikacji: potrzebuje dostępu do istniejącego klastra.
Jak kubectl współpracuje z Kubernetes
Klaster Kubernetes to środowisko złożone z maszyn, nazywanych węzłami, oraz komponentów zarządzających uruchamianiem aplikacji. Kontener jest sposobem pakowania aplikacji wraz z jej zależnościami. Kubernetes uruchamia kontenery w jednostkach zwanych Podami; Pod może zawierać jeden lub kilka współpracujących kontenerów.
kubectl działa na komputerze administratora, programisty albo w systemie automatyzującym wdrożenia. Wysyła żądania do serwera API Kubernetes, czyli punktu komunikacji służącego do odczytywania i zmieniania zasobów klastra. Nie steruje bezpośrednio każdym kontenerem — to komponenty Kubernetes wykonują działania potrzebne do osiągnięcia zadanego stanu.
Przykładowo, jeśli zlecisz utrzymywanie trzech kopii aplikacji, kubectl przekaże tę konfigurację do API. Kubernetes będzie następnie dążyć do tego, aby wymagane kopie działały. Możesz zamknąć terminal: działanie aplikacji nie zależy od uruchomionego procesu kubectl.
Co jest potrzebne, żeby zacząć
Samo zainstalowanie kubectl nie wystarczy. Potrzebujesz klastra — lokalnego środowiska testowego, na przykład utworzonego przez kind lub minikube, albo klastra udostępnionego przez firmę czy dostawcę chmurowego — oraz uprawnień do korzystania z niego.
Dane połączenia zwykle znajdują się w pliku kubeconfig. Zawiera on adresy klastrów, ustawienia uwierzytelniania lub odwołania do mechanizmów logowania oraz konteksty. Kontekst wskazuje, z którym klastrem i jako który użytkownik pracujesz; może też określać domyślną przestrzeń nazw. Przestrzeń nazw, czyli namespace, grupuje zasoby w obrębie klastra.
Domyślną lokalizacją konfiguracji jest $HOME/.kube/config, ale można wskazać inny plik. Przed pracą sprawdź klienta i aktywne połączenie:
kubectl version --client
kubectl config current-context
kubectl cluster-info
Pierwsze polecenie sprawdza wersję lokalnego narzędzia, bez potwierdzania dostępu do klastra. Drugie pokazuje wybrany kontekst, a trzecie próbuje pobrać informacje o klastrze. Błędy mogą wynikać z braku konfiguracji, problemów sieciowych, wygasłego logowania lub niewystarczających uprawnień.
Sposób instalacji i obsługiwane różnice wersji klienta oraz serwera sprawdź w oficjalnej dokumentacji Kubernetes. W środowisku firmowym korzystaj także z instrukcji administratora dotyczących logowania.
Podstawowe polecenia do sprawdzania aplikacji
Polecenia mają zwykle postać kubectl czasownik typ-zasobu nazwa. Opcje pozwalają między innymi wybrać przestrzeń nazw i format wyniku. Na początku najbardziej przydatne są operacje odczytu:
| Polecenie | Zastosowanie |
|---|---|
kubectl get pods -n test | Lista Podów w przestrzeni test i ich podstawowy stan. |
kubectl describe pod NAZWA -n test | Szczegóły Poda oraz zdarzenia pomocne w diagnozie. |
kubectl logs NAZWA -n test | Logi kontenera w podanym Podzie. |
kubectl get deployments -n test | Stan zasobów zarządzających kopiami aplikacji. |
NAZWA zastąp rzeczywistą nazwą Poda. Jeśli Pod ma kilka kontenerów, przy odczytywaniu logów może być potrzebna opcja -c NAZWA_KONTENERA.
Załóżmy, że aplikacja nie odpowiada po wdrożeniu. Zacznij od get pods, aby sprawdzić, czy jej Pody działają. Następnie użyj describe, szukając zdarzeń dotyczących na przykład pobierania obrazu lub uruchamiania kontenera, a potem odczytaj logi aplikacji. Sam stan Poda nie zawsze wystarczy do ustalenia przyczyny problemu.
Jak wdrażać zmiany za pomocą pliku YAML
kubectl może tworzyć zasoby pojedynczymi poleceniami, ale konfigurację aplikacji często zapisuje się w manifeście — pliku opisującym pożądany stan zasobów. Najczęściej używa się formatu YAML. Taki plik można przechowywać w repozytorium i przeglądać jego zmiany przed wdrożeniem.
Poniższy manifest tworzy Deployment, czyli zasób utrzymujący określoną liczbę kopii aplikacji i zarządzający ich aktualizacją:
apiVersion: apps/v1
kind: Deployment
metadata:
name: demo
spec:
replicas: 1
selector:
matchLabels:
app: demo
template:
metadata:
labels:
app: demo
spec:
containers:
- name: nginx
image: nginx:stable
Zapisz go jako deployment.yaml. W klastrze testowym możesz zastosować konfigurację i sprawdzić postęp:
kubectl apply -f deployment.yaml
kubectl rollout status deployment/demo
kubectl get pods -l app=demo
Przykład uruchamia serwer nginx, ale nie udostępnia go automatycznie w internecie. Dostęp sieciowy wymaga dodatkowej konfiguracji, często zasobu Service, który kieruje ruch do Podów. Uruchomienie przykładu zależy również od możliwości pobrania obrazu i dostępnych zasobów klastra.
Jak unikać zmian w niewłaściwym środowisku
kubectl może obsługiwać zarówno środowisko testowe, jak i produkcyjne. Przed operacją zmieniającą zasoby sprawdź kontekst oraz przestrzeń nazw. Możesz wskazać je jawnie opcjami --context i -n, zamiast polegać na ustawieniach domyślnych.
Przed zastosowaniem manifestu pomocne są kubectl diff -f deployment.yaml, pokazujące różnice względem istniejących zasobów, oraz kubectl apply --dry-run=server -f deployment.yaml, które wysyła żądanie próbne bez zapisania zmiany. Nie gwarantują one jednak, że aplikacja będzie działać poprawnie po wdrożeniu.
Polecenie delete usuwa zasoby i może przerwać działanie aplikacji. Kubeconfig traktuj jako plik wrażliwy: nie publikuj go w repozytorium ani nie używaj konfiguracji z niezaufanego źródła. Pierwsze ćwiczenia wykonuj w klastrze testowym, zaczynając od sprawdzenia kontekstu i odczytu stanu Podów.
Zobacz też: Co to jest FTP?
Przeczytaj także
