Zarządzanie obiektami Kubernetesa

Narzędzie wiersza poleceń kubectl obsługuje kilka różnych sposobów tworzenia i zarządzania obiektami Kubernetesa. Ten dokument zawiera przegląd różnych podejść. Przeczytaj Księgę Kubectl aby uzyskać szczegółowe informacje na temat zarządzania obiektami za pomocą Kubectl.

Techniki zarządzania

Technika zarządzania Działa na Rekomendowane środowisko Obsługiwani autorzy Krzywa uczenia się
Polecenia imperatywne Obiekty na żywo Projekty rozwojowe 1+ Najniższy
Imperatywna konfiguracja obiektów Pojedyncze pliki Projekty produkcyjne 1 Umiarkowane
Deklaratywna konfiguracja obiektów Katalogi plików Projekty produkcyjne 1+ Najwyższy

Polecenia imperatywne

Podczas korzystania z poleceń imperatywnych, użytkownik operuje bezpośrednio na obiektach działających w klastrze. Użytkownik dostarcza operacje do polecenia kubectl jako argumenty lub flagi.

To jest zalecany sposób rozpoczęcia pracy lub uruchomienia jednorazowego zadania w klastrze. Ponieważ ta technika działa bezpośrednio na żywych obiektach, nie zapewnia historii wcześniejszych konfiguracji.

Przykłady

Uruchom instancję kontenera nginx, tworząc obiekt Deployment:

kubectl create deployment nginx --image nginx

Kompromisy

Zalety w porównaniu do konfiguracji obiektów:

  • Polecenia są wyrażane jako pojedyncze słowo akcji.
  • Polecenia wymagają tylko jednego kroku, aby wprowadzić zmiany w klastrze.

Wady w porównaniu do konfiguracji obiektów:

  • Polecenia nie integrują się z procesami przeglądu zmian.
  • Polecenia nie zapewniają śladu audytu związanego ze zmianami.
  • Polecenia nie dostarczają źródła zapisów poza tym, co jest aktywne.
  • Polecenia nie zapewniają szablonu do tworzenia nowych obiektów.

Imperatywna konfiguracja obiektów

W trybie imperatywnej konfiguracji obiektów polecenie kubectl określa operację (np. create, replace), opcjonalne flagi oraz co najmniej jedną nazwę pliku. Podany plik musi zawierać pełną definicję obiektu w formacie YAML lub JSON.

Zobacz dokumentację API, aby uzyskać więcej szczegółów na temat definicji obiektów.

Przykłady

Utwórz obiekty zdefiniowane w pliku konfiguracyjnym:

kubectl create -f nginx.yaml

Usuń obiekty zdefiniowane w dwóch plikach konfiguracyjnych:

kubectl delete -f nginx.yaml -f redis.yaml

Zaktualizuj obiekty zdefiniowane w pliku konfiguracyjnym poprzez nadpisanie aktualnej konfiguracji:

kubectl replace -f nginx.yaml

Kompromisy

Zalety w porównaniu z komendami imperatywnymi:

  • Konfiguracja obiektów może być przechowywana w systemie kontroli wersji, takim jak Git.
  • Konfiguracja obiektów może być zintegrowana z procesami takimi jak przeglądanie zmian przed ich wprowadzeniem oraz ścieżki audytu.
  • Konfiguracja obiektu dostarcza szablon do tworzenia nowych obiektów.

Wady w porównaniu do poleceń imperatywnych:

  • Konfiguracja obiektu wymaga podstawowego zrozumienia schematu obiektu.
  • Konfiguracja obiektu wymaga dodatkowego kroku w postaci napisania pliku YAML.

Zalety w porównaniu do deklaratywnej konfiguracji obiektów:

  • Zachowanie imperatywnej konfiguracji obiektów jest prostsze i łatwiejsze do zrozumienia.
  • Od wersji Kubernetes 1.5, imperatywna konfiguracja obiektów jest bardziej rozwinięta.

Wady w porównaniu do deklaratywnej konfiguracji obiektów:

  • Imperatywna konfiguracja obiektów działa najlepiej na plikach, a nie na katalogach.
  • Wszelkie aktualizacje obiektów w systemie muszą być przeniesione do plików konfiguracyjnych, inaczej zostaną utracone podczas następnej operacji replace.

Deklaratywna konfiguracja obiektów

Podczas korzystania z deklaratywnej konfiguracji obiektów, użytkownik operuje na plikach konfiguracyjnych obiektów przechowywanych lokalnie, jednakże użytkownik nie definiuje operacji do wykonania na tych plikach. Operacje tworzenia, aktualizacji i usuwania są automatycznie wykrywane dla każdego obiektu przez kubectl. Dzięki temu można pracować na całych katalogach, w których różne obiekty wymagają różnych operacji.

Przykłady

Przetwórz wszystkie pliki konfiguracyjne obiektów w katalogu configs, a następnie utwórz lub zastusuj zmiany do obiektów istniejących w systemie. Możesz najpierw użyć diff, aby zobaczyć, jakie zmiany zostaną wprowadzone, a następnie zastosować:

kubectl diff -f configs/
kubectl apply -f configs/

Rekursywne przetwarzanie katalogów:

kubectl diff -R -f configs/
kubectl apply -R -f configs/

Kompromisy

Zalety w porównaniu z imperatywną konfiguracją obiektów:

  • Zmiany wprowadzone bezpośrednio do obiektów działających są zachowywane, nawet jeśli nie zostaną scalone z plikami konfiguracyjnymi.
  • Deklaratywna konfiguracja obiektów lepiej wspiera operacje na katalogach i automatyczne wykrywanie typów operacji (tworzenie, łatanie, usuwanie) dla każdego obiektu.

Wady w porównaniu z imperatywną konfiguracją obiektów:

  • Konfiguracja obiektów deklaratywnych jest trudniejsza do debugowania i zrozumienia wyników w sytuacjach nieoczekiwanych.
  • Częściowe aktualizacje przy użyciu różnic tworzą złożone operacje scalania i łatania.

Co dalej?