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ą
- Dlaczego są trzy operacje wykonywania tego samego zadania w klastrze?
- Jakie są przypadki użycia tych operacji?
- Czym różnią się od siebie pod maską?
kubernetes
kubectl
Suresh Vishnoi
źródło
źródło
kubectl create
ikubectl apply
mają identyczny efekt, czy też nie.kubectl create
zgłosi błąd, jeśli zasób już istnieje.kubectl apply
przyzwyczajenie. Różnica polega na tym, żekubectl create
konkretnie mówi „stwórz to”, akubectl apply
„rób wszystko, co konieczne (twórz, aktualizuj itp.), Aby wyglądało to tak”.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=true
i-o yaml
: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).
źródło
kubectl delete deployment nginx --ignore-not-found; kubectl create deployment nginx --image=nginx
Żeby dać prostszą odpowiedź, z mojego zrozumienia:
apply
- wprowadza przyrostowe zmiany w istniejącym obiekciecreate
- 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:
źródło
apply
jakdocker-compose up -d
+ użyjcreate
jakdocker-compose up -d --build
?Są to polecenia rozkazujące :
kubectl run
=kubectl create deployment
Zalety:
Niedogodności:
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:
Wady w porównaniu do poleceń rozkazujących:
Zalety w porównaniu do deklaratywnej konfiguracji obiektu:
Wady w porównaniu do deklaratywnej konfiguracji obiektu:
Są to deklaratywna konfiguracja obiektu
kubectl diff -f configs/
kubectl apply -f configs/
Zalety w porównaniu do konfiguracji obiektu imperatywnego:
Wady w porównaniu z konfiguracją obiektów imperatywnych:
źródło
Wyjaśnienie poniżej z oficjalnej dokumentacji pomogło mi zrozumieć
kubectl apply
.kubectl create
z drugiej strony stworzą (powinny być nieistniejące) zasoby.źródło
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/
źródło
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.
źródło