zastosowanie kubectl vs tworzenie kubectl?


266

Z dokumentacji zrozumiałem, że:

  • kubectl create = Tworzy nowy zasób k8s w klastrze
  • kubectl replace = Aktualizuje zasób w klastrze na żywo
  • kubectl Apply = Jeśli chcę zrobić, stwórz + zamień ( odniesienie )

Moje pytania są

  1. Dlaczego są trzy operacje wykonywania tego samego zadania w klastrze?
  2. Jakie są przypadki użycia tych operacji?
  3. Czym różnią się od siebie pod maską?

Odpowiedzi:


315

Są to dwa różne podejścia:

Imperatywne zarządzanie

kubectl createto, co nazywamy imperatywnym zarządzaniem . Dzięki takiemu podejściu powiesz interfejsowi API Kubernetes, jak chcesz tworzyć, zamieniać lub usuwać, a nie jak chcesz wyglądać świat klastrów K8s.

Zarządzanie deklaratywne

kubectl applyjest częścią podejścia do zarządzania deklaratywnego , w którym zmiany, które mogłeś zastosować do obiektu aktywnego (tj. poprzez scale) są „ utrzymywane ”, nawet jeśli applywprowadzisz inne zmiany w obiekcie.

Więcej informacji na temat zarządzania imperatywnego i deklaratywnego można znaleźć w dokumentacji zarządzania obiektami Kubernetes .


24
Który następnie zastosować w produkcji?
Yogesh Jilhawar

11
@YogeshJilhawar oba są prawidłowymi sposobami pracy w produkcji.
gitarzysta

2
Zasadniczo więc jest to jak modyfikacja całego obiektu vs. częściowa łatka?
Ryall

12
Ta odpowiedź nie potwierdził, czy te dwie operacje kubectl createi kubectl applymają identyczny efekt, czy też nie.
Nawaz

61
@Nawaz - Robią różne rzeczy. kubectl createzgłosi błąd, jeśli zasób już istnieje. kubectl applyprzyzwyczajenie. Różnica polega na tym, że kubectl createkonkretnie mówi „stwórz to”, a kubectl apply„rób wszystko, co konieczne (twórz, aktualizuj itp.), Aby wyglądało to tak”.
Pan Llama,

44

Podczas uruchamiania w skrypcie CI wystąpią problemy z poleceniami rozkazującymi, ponieważ tworzenie powoduje błąd, jeśli zasób już istnieje.

Możesz zastosować (wzorzec deklaratywny) dane wyjściowe polecenia imperatywnego, używając opcji --dry-run=truei -o yaml:

kubectl create whatever --dry-run=true -o yaml | kubectl apply -f -

Powyższe polecenie nie zgłosi błędu, jeśli zasób już istnieje (i w razie potrzeby zaktualizuje zasób).

Jest to bardzo przydatne w niektórych przypadkach, w których nie można użyć wzorca deklaratywnego (na przykład podczas tworzenia tajnego rejestru dokera).


Ewentualnie usuń zasób przed utworzeniem go z flagą --ignore-not-found . Nie spowoduje to błędu AlreadyExists . Na przykład:kubectl delete deployment nginx --ignore-not-found; kubectl create deployment nginx --image=nginx
Noam Manos

33

Żeby dać prostszą odpowiedź, z mojego zrozumienia:

apply- wprowadza przyrostowe zmiany w istniejącym obiekcie
create- tworzy zupełnie nowy obiekt (wcześniej nieistniejący / usunięty)


Biorąc to z artykułu DigitalOcean, który został połączony ze stroną Kubernetes:

Używamy tutaj aplikacji zamiast tworzenia, abyśmy mogli w przyszłości stopniowo wprowadzać zmiany do obiektów Ingress Controller zamiast całkowicie je nadpisywać.


Czy to jest na przykład kiedy używamy komponowania dokera: + użyj applyjak docker-compose up -d+ użyj createjak docker-compose up -d --build?
Whoiskp

8

Są to polecenia rozkazujące :

kubectl run = kubectl create deployment

Zalety:

  • Prosty, łatwy do nauczenia i łatwy do zapamiętania.
  • Wymagaj tylko jednego kroku, aby wprowadzić zmiany w klastrze.

Niedogodności:

  • Nie integruj z procesami przeglądu zmian.
  • Nie udostępniaj ścieżki audytu związanej ze zmianami.
  • Nie podawaj źródła nagrań oprócz tego, co jest na żywo.
  • Nie udostępniaj szablonu do tworzenia nowych obiektów.

Są to niezbędne konfiguracje obiektów :

kubectl create -f your-object-config.yaml

kubectl delete -f your-object-config.yaml

kubectl replace -f your-object-config.yaml

Zalety w porównaniu do poleceń rozkazujących:

  • Może być przechowywany w systemie kontroli źródła, takim jak Git.
  • Może integrować się z procesami takimi jak przegląd zmian przed wypychaniem i śladami audytu.
  • Zapewnia szablon do tworzenia nowych obiektów.

Wady w porównaniu do poleceń rozkazujących:

  • Wymaga podstawowego zrozumienia schematu obiektu.
  • Wymaga dodatkowego kroku zapisu pliku YAML.

Zalety w porównaniu do deklaratywnej konfiguracji obiektu:

  • Prostsze i łatwiejsze do zrozumienia.
  • Bardziej dojrzały po wersji 1.5 Kubernetes.

Wady w porównaniu do deklaratywnej konfiguracji obiektu:

  • Działa najlepiej w przypadku plików, a nie katalogów.
  • Aktualizacje obiektów aktywnych muszą zostać odzwierciedlone w plikach konfiguracyjnych, w przeciwnym razie zostaną utracone podczas następnej wymiany.

Są to deklaratywna konfiguracja obiektu

kubectl diff -f configs/

kubectl apply -f configs/

Zalety w porównaniu do konfiguracji obiektu imperatywnego:

  • Zmiany wprowadzone bezpośrednio w obiektach aktywnych są zachowywane, nawet jeśli nie zostaną ponownie scalone z plikami konfiguracyjnymi.
  • Lepsza obsługa operacji na katalogach i automatyczne wykrywanie typów operacji (tworzenie, łatanie, usuwanie) dla obiektu.

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

  • Trudniej jest debugować i zrozumieć wyniki, gdy są nieoczekiwane.
  • Częściowe aktualizacje przy użyciu różnic tworzą złożone operacje scalania i łatania.

3

Wyjaśnienie poniżej z oficjalnej dokumentacji pomogło mi zrozumieć kubectl apply.

To polecenie porówna wersję konfiguracji, którą wypychasz z poprzednią wersją, i zastosuje wprowadzone zmiany, nie zastępując zautomatyzowanych zmian właściwości, których nie określiłeś.

kubectl create z drugiej strony stworzą (powinny być nieistniejące) zasoby.


1

Kubectl create może pracować z jednym plikiem konfiguracyjnym obiektu na raz. Jest to również znane jako zarządzanie imperatywne

kubectl create -f nazwa_pliku | url

Kubectl Apply działa z katalogami i podkatalogami zawierającymi pliki yaml konfiguracji obiektu. Jest to również znane jako zarządzanie deklaratywne. Można pobrać wiele plików konfiguracji obiektu z katalogów. kubectl stosuje -f katalog /

Szczegóły:
https://kubernetes.io/docs/tasks/manage-kubernetes-objects/declarative-config/ https://kubernetes.io/docs/tasks/manage-kubernetes-objects/imperative-config/


0

Uwielbiamy Kubernetes, ponieważ kiedy damy im to, czego chcemy, dalej zastanawia się, jak to osiągnąć bez naszego zaangażowania.

„tworzenie” jest jak granie w BOGA przez wzięcie rzeczy w nasze ręce. Jest dobry do lokalnego debugowania, gdy chcesz pracować tylko z POD, a nie dbać o abt Deployment / Replication Controller.

„Apply” jest zgodne z zasadami. „Apply” jest jak główne narzędzie, które pomaga tworzyć i modyfikować i nie wymaga od ciebie niczego, aby zarządzać zasobnikami.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.