Ponownie uruchamiać strąki podczas aktualizowania pliku configmap w Kubernetes?

Question

Wiem, że mówiono o możliwości automatycznego restartu strąków po zmianie map konfiguracji, ale według mojej wiedzy nie jest to jeszcze dostępne w Kubernetes 1.2.

Co (jak sądzę) chciałbym zrobić to "ciągły restart" zasobu deployment związanego ze strąkami zużywającymi mapę konfiguracji. Czy jest możliwe, a jeśli tak, to jak wymusić ponowne uruchomienie wdrożenia w Kubernetes bez zmiany czegokolwiek w aktualnym szablonie? Czy jest to obecnie najlepszy sposób na to, czy jest lepsza opcja?

Answer 1

Sygnalizacja kapsuły przy aktualizacji mapy konfiguracji jest funkcją w pracach (https://github.com/kubernetes/kubernetes/issues/22368).

Zawsze możesz napisać niestandardowy pid1, który zauważy, że confimap się zmienił i uruchamia ponownie Twoją aplikację.

Możesz także np. Zamontować tę samą mapę konfiguracji w 2 kontenerach, wystawić kontrolę stanu http w drugim pojemniku, który się nie powiedzie, jeśli zmienią się zawartość mieszania mapy konfiguracyjnej i wepchnie to jako próbę aktywacji pierwszego pojemnika (ponieważ kontenery w zasobniku współdzielą tę samą przestrzeń nazw w sieci). Kubek uruchomi ponownie twój pierwszy pojemnik, gdy sonda zawiedzie.

Oczywiście, jeśli nie dbasz o to, w których węzłach znajdują się strąki, możesz po prostu je usunąć, a kontroler replikacji "zrestartuje" je dla Ciebie.

Answer 2

Obecne najlepsze rozwiązanie tego problemu (wymienione głęboko w https://github.com/kubernetes/kubernetes/issues/22368 połączone z odpowiedzią dla rodzeństwa) polega na użyciu Deploymentów i rozważeniu, czy konfiguracja ConfigMaps jest niezmienna.

Aby zmienić konfigurację, utwórz nową mapę ConfigMap ze zmianami, które chcesz wprowadzić, i wskaż wdrożenie na nowej mapie ConfigMap. Jeśli nowa konfiguracja zostanie zerwana, Deployment nie będzie mógł skalować działającego zestawu ReplicaSet. Jeśli nowa konfiguracja działa, Twój stary ReplicaSet zostanie przeskalowany do 0 replik i usunięty, a nowe podsystemy zostaną uruchomione z nową konfiguracją.

Nie tak szybkie, jak tylko edycja pliku ConfigMap w miejscu, ale o wiele bezpieczniejsze.

Answer 3

https://github.com/kubernetes/helm/blob/master/docs/charts_tips_and_tricks.md#user-content-automatically-roll-deployments-when-configmaps-or-secrets-change

Często configmaps lub tajemnice są wstrzykiwane jako pliki konfiguracyjne w pojemnikach. W zależności od aplikacji może być wymagane ponowne uruchomienie, jeśli zostaną zaktualizowane o kolejne helm upgrade, ale jeśli sama specyfikacja wdrożenia nie zmieni się, aplikacja będzie nadal działać ze starą konfiguracją, co spowoduje niespójne wdrożenie.

sha256sum Funkcja może być używana razem z funkcją include celu zapewnienia sekcję wdrożeń szablon jest aktualizowany jeśli kolejne zmiany Spec:

kind: Deployment 
spec: 
    template: 
    metadata: 
     annotations: 
     checksum/config: {{ include (print $.Template.BasePath "/secret.yaml") . | sha256sum }} 
[...] 

w moim przypadku, z jakichś powodów, $.Template.BasePath nie działa ale $.Chart.Name robi:

spec: 
    replicas: 1 
    template: 
    metadata: 
     labels: 
     app: admin-app 
     annotations: 
     checksum/config: {{ include (print $.Chart.Name "/templates/" $.Chart.Name "-configmap.yaml") . | sha256sum }} 

Answer 4

Innym sposobem jest trzymać go do sekcji dowodzenia Wdrożenie:

... 
command: [ "echo", " 
    option = value\n 
    other_option = value\n 
" ] 
... 

Alternatywnie, aby uczynić go bardziej configMap podobny, użyj dodatkowe wykorzystanie że będzie tylko host, który config w sekcji command oraz wykonywać kubectl create na nim dodając unikalny „wersja” do jego nazwy (jak obliczenia mieszania treść) i modyfikowanie wszystkich wdrożeń, które używają tego config:

... 
command: [ "/usr/sbin/kubectl-apply-config.sh", " 
    option = value\n 
    other_option = value\n 
" ] 
... 

prawdopodobnie będę zamieszczać kubectl-apply-config.sh jeśli kończy się praca.