Wdrażanie kontrolera replikacji w Kubernetes

Question

Chciałem wiedzieć, jaka jest różnica między kontrolerem replikacji a wdrożeniem w pakiecie Kubernetes (1.2). Przechodząc przez dokument wprowadzający (http://kubernetes.io/docs/hellonode/) Utworzyłem wdrożenie - ale nie pojawia się ono w interfejsie internetowym.

Gdy tworzę aplikacje z interfejsu internetowego - są one tworzone jako kontrolery replikacji. Funkcjonalnie jednak wydają się bardzo podobne (obaj zarządzają strąkami i mają usługi).

Jaka jest różnica i kiedy należy korzystać z każdej z nich?

Answer 1

Wdrożenia są nowszą i wyższą koncepcją niż kontrolery replikacji. Zarządzają wdrożeniem zestawów replik (także nowszą koncepcją, ale w dużym stopniu odpowiadają kontrolerom replikacji) i umożliwiają łatwe aktualizowanie zestawu replik, a także możliwość przywrócenia poprzedniego wdrożenia.

Poprzednio należało to zrobić z kubectl rolling-update, która nie była deklaratywna i nie zapewniała funkcji wycofywania.

Tablica Kubernetes nie została jeszcze zaktualizowana w celu obsługi wdrożeń, a obecnie obsługuje tylko kontrolery replikacji (patrz Deployments not visible in Kubernetes Dashboard).

EDYCJA: pulpit obsługuje teraz wdrożenia.

Answer 2

Deployments są nadal w fazie beta (ich API jest pod extensions/v1beta1), co prawdopodobnie powoduje, że nie pojawiają się w interfejsie użytkownika. Automatyzują przejścia między stanami, a utrzymują żywe kapsuły. Z podlinkowanej strony:

Wdrożenie zapewnia deklaratywne aktualizacje dla zestawów podpórek i replik (kontroler replikacji następnej generacji). Musisz tylko opisać żądany stan w obiekcie wdrażania za pomocą , a kontroler wdrożenia zmieni aktualny stan na żądany stan z kontrolowaną stawką kontrolowaną . Możesz zdefiniować wdrożenia, aby utworzyć nowe zasoby lub zastąpić istniejące nowymi.

Zapewniają również historię wdrożenia i inne użyteczne funkcje.

$ kubectl rollout history deployment/nginx-deployment 
deployments "nginx-deployment": 
REVISION CHANGE-CAUSE 
1   kubectl create -f docs/user-guide/nginx-deployment.yaml --record 
2   kubectl apply -f docs/user-guide/new-nginx-deployment.yaml 
3   kubectl apply -f docs/user-guide/bad-nginx-deployment.yaml 

Śledzi również zmiany.

$ kubectl rollout history deployment/nginx-deployment --revision=2 
deployments "nginx-deployment" revision 2 
Labels:  app=nginx,pod-template-hash=1564180365 
Annotations: kubernetes.io/change-cause=kubectl apply -f docs/user-guide/new-nginx-deployment.yaml 
Image(s): nginx:1.9.1 
No volumes. 

Answer 3

Deska rozdzielcza (Web UI) został ogromnie przeprojektowany wspomagającego zarządzanie więcej zasobów (jak Deployments i DaemonSets, etc.) i obecny desce rozdzielczej nie pozwala znacznie dotyczące Deployments.

Zarządzanie wdrożeniami w panelu będzie wkrótce obsługiwane w pakiecie kubernetes 1.3 (patrz: numer Feature request: handle Deployments).

Answer 4

Teraz z release 1.1 Dashboard obsługuje wdrożenia. Możesz wdrożyć lub zaktualizować swój pulpit bez czekania na wydanie 1.3 wersji K8. Możesz na przykład użyć official YAML, którą właśnie zmieniliśmy, aby używać dzisiaj Deploymentów.

Ogólnie zalecam (a także osoby pracujące w Google i Kubernetes) używanie Deployments over RCs, ponieważ są one znacznie bardziej wydajnymi prymitywami (zawierają ciągłe aktualizacje, wersjonowanie/audytowanie, wdrożenia canaray/green-blue, wycofywanie zmian itp.).

Answer 5

Z moich doświadczeń wynika, że ​​wdrożenia zapewniają nie wszystkie funkcje, których potrzebuję. Lub, być może, używam ich w niewłaściwy sposób.

Gdy zachodzi potrzeba zrestartowania serwera węzłów - wszystkie pods działające na tym serwerze uruchomione przez wdrożenie - nie działają. I nie mogę znaleźć sposobu, aby tego uniknąć.

Ale,

Pomyśl rozwiązaniem jest kontroler replikacji. Przynajmniej w opisie jest napisane, że obsługuje takie przypadki.

Zaletą wdrożenia głównego, jak widzę, jest ciągłe zmienianie wersji aplikacji.

Tak więc oba sposoby są dobre, ale z różnych powodów.