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ą?

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 .

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).

Ż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ć.

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.

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.

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/

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.