Zrestartować pody po aktualizacji configmap w Kubernetes?


121

Jak automatycznie ponownie uruchomić pody i pody Kubernetes skojarzone z wdrożeniami, gdy ich mapa konfiguracji zostanie zmieniona / zaktualizowana?


Wiem, że mówiono o możliwości automatycznego restartowania podów, gdy zmieni się mapa konfiguracji, ale według mojej wiedzy nie jest to jeszcze dostępne w Kubernetes 1.2.

Więc to, co (myślę), chciałbym zrobić, to „kroczący restart” zasobu wdrażania skojarzonego z podami zużywającymi mapę konfiguracji. Czy jest możliwe, a jeśli tak, to jak wymusić stopniowe ponowne uruchomienie wdrożenia w Kubernetes bez zmiany czegokolwiek w rzeczywistym szablonie? Czy jest to obecnie najlepszy sposób na zrobienie tego, czy jest lepsza opcja?


$ kubectl set env deployment my deployment --env="LAST_RESTART=$(date)" --namespace ...zrób robotę za mnie
maciek

Odpowiedzi:


60

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

Zawsze możesz napisać niestandardowy pid1, który zauważy zmianę mapy confimap i ponownie uruchomi Twoją aplikację.

Możesz także np .: zamontować tę samą mapę konfiguracji w 2 kontenerach, wystawić kontrolę stanu http w drugim kontenerze, która kończy się niepowodzeniem, jeśli zmieni się skrót zawartości mapy konfiguracji, i wrzucić ją jako sondę na żywo pierwszego kontenera (ponieważ kontenery w pod współdzielą tę samą przestrzeń nazw sieci). Kubelet uruchomi ponownie twój pierwszy kontener, gdy sonda ulegnie awarii.

Oczywiście, jeśli nie obchodzi Cię, na których węzłach znajdują się pody, możesz je po prostu usunąć, a kontroler replikacji „zrestartuje” je za Ciebie.


Przez „usuwanie podów” masz na myśli: zbieranie wszystkich nazw podów, usuwanie jednego, czekanie na wymianę, usuwanie drugiego, czekanie na wymianę itp. Prawidłowo?
Torsten Bronger

6
używając wdrożenia, skalowałbym go w dół, a następnie w górę. Jednak nadal będziesz mieć tak niewielką ilość przestojów. Możesz to zrobić w jednej linii, aby to zmniejszyć ... kubectl scale deployment/update-demo --replicas=0; kubectl scale deployment/update-demo --replicas=4;
Nick H,

Jeśli nie chcesz znaleźć wszystkich zasobników i nie przejmujesz się przestojami - po prostu usuń RC, a następnie ponownie utwórz RC.
Drew

1
Czy to oznacza, że ​​wolumin, na którym jest zamontowany, jest aktualizowany i wystarczy ponownie odczytać plik z kapsuły bez ponownego uruchamiania całego zasobnika?
Matt Williamson,

@NickH Szybki i brudny, na szczęście w moim przypadku przestój był do zaakceptowania i to działało świetnie, dzięki!
ChocolateAndCheese

129

Obecnie najlepszym rozwiązaniem tego problemu (do którego odwołujemy się głęboko w https://github.com/kubernetes/kubernetes/issues/22368 link w odpowiedzi dla rodzeństwa) jest użycie wdrożeń i uznanie, że Twoje ConfigMaps są niezmienne.

Jeśli chcesz zmienić konfigurację, utwórz nową mapę ConfigMap ze zmianami, które chcesz wprowadzić, i wskaż wdrożenie nowej mapy ConfigMap. Jeśli nowa konfiguracja jest uszkodzona, wdrożenie odmówi skalowania działającego zestawu replik. Jeśli nowa konfiguracja działa, stary ReplicaSet zostanie przeskalowany do 0 replik i usunięty, a nowe pody zostaną uruchomione z nową konfiguracją.

Nie tak szybka, jak zwykła edycja mapy ConfigMap, ale znacznie bezpieczniejsza.


2
Takie podejście też przyjęliśmy
Johan

5
Warto wspomnieć, że nowe narzędzie eksperymentalne kustomizeobsługuje automatyczne tworzenie deterministycznego skrótu mapy konfiguracyjnej, co oznacza, że ​​nie trzeba ręcznie tworzyć nowej mapy konfiguracyjnej: github.com/kubernetes-sigs/kustomize/blob/ ...
Symmetric

To jest to, co robi Spinnaker za kulisami, więc jeśli go używasz, nie musisz się tym martwić.
Gus

32

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 mapy konfiguracyjne lub wpisy tajne są wprowadzane jako pliki konfiguracyjne w kontenerach. W zależności od aplikacji może być wymagane ponowne uruchomienie, jeśli te zostaną zaktualizowane kolejnymi helm upgrade, ale jeśli sama specyfikacja wdrożenia nie uległa zmianie, aplikacja nadal działa ze starą konfiguracją, co powoduje niespójne wdrożenie.

sha256sumFunkcja ta może być używana wraz z includefunkcją celu zapewnienia wdrożenia sekcja szablon jest aktualizowane, jeśli kolejne wyspecjalizoway zmianami:

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

W moim przypadku z pewnych powodów $.Template.BasePathnie zadziałało, ale $.Chart.Namedziała:

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

8
Nie dotyczy ogólnego użytku Kubernetes, dotyczy tylko Helm
Emii Khaos

2
Odpowiedź jest pomocna, ale prawdopodobnie nie dotyczy tego pytania
Anand Singh Kunwar

helm3 został niedawno wydany. Dlatego link jest nieaktualny. Wskazuje na mastergałąź. Następujący adres URL prowadzi do (obecnie) ostatnich helm2 dokumentów: github.com/helm/helm/blob/release-2.16/docs/…
Marcel Hoyer

Fajne rozwiązanie. Zmieniłem na sha1sum, ponieważ w moim przypadku sha256sum miał 65 znaków, co zaowocowało Deployment.apps "xxx" is invalid: metadata.labels: Invalid value: "xxx": must be no more than 63 characters. Alternatywą byłoby | trunc 63, ale sha1sum powinno być „bardziej unikalne”.
iptizer

32

Najlepszym sposobem, jaki znalazłem, jest uruchomienie Reloadera

Pozwala zdefiniować configmapy lub wpisy tajne do oglądania, gdy zostaną zaktualizowane, wykonywana jest stopniowa aktualizacja wdrożenia. Oto przykład:

Masz wdrożenie fooi plik ConfigMap o nazwie foo-configmap. Chcesz rzucić pody we wdrożeniu za każdym razem, gdy zostanie zmieniona mapa konfiguracji. Musisz uruchomić Reloader z:

kubectl apply -f https://raw.githubusercontent.com/stakater/Reloader/master/deployments/kubernetes/reloader.yaml

Następnie określ tę adnotację w swoim wdrożeniu:

kind: Deployment
metadata:
  annotations:
    configmap.reloader.stakater.com/reload: "foo-configmap"
  name: foo
...

Reloader jest kompatybilny z kubernetes> = 1.9
jacktrade

11

Możesz zaktualizować etykietę metadanych, która nie jest odpowiednia dla Twojego wdrożenia. spowoduje to aktualizację kroczącą

na przykład:

metadata:
  labels:
    configmap-version: 1

Szukam dokumentów o metadanych: etykiety: configmap-version: 1
c4f4t0r

7
zmiany etykiet metadanych nie powodują ponownego uruchomienia strąków
dan carter

Ta odpowiedź ma pozytywne opinie, więc muszę zapytać. Jeśli zaktualizujemy metadane, czy klaster Kubernetes wyzwoli aktualizację kroczącą? @ maoz-zadok
titus

1
Uważam, że to działa, o ile etykieta metadanych znajduje się pod etykietątemplate.spec
Saikiran Yerram

1

Miałem ten problem, gdy wdrożenie było na wykresie podrzędnym, a kontrolujące go wartości znajdowały się w pliku wartości wykresu nadrzędnego. Oto, czego użyliśmy do uruchomienia restartu:

spec:
  template:
    metadata:
      annotations:
        checksum/config: {{ tpl (toYaml .Values) . | sha256sum }}

Oczywiście spowoduje to ponowne uruchomienie przy każdej zmianie wartości, ale działa to w naszej sytuacji. To, co pierwotnie znajdowało się na wykresie podrzędnym, działałoby tylko wtedy, gdyby plik config.yaml w samym wykresie podrzędnym został zmieniony:

    checksum/config: {{ include (print $.Template.BasePath "/config.yaml") . | sha256sum }}

0

Robię rozwiązanie kwantów i działa idealnie. Ale nie rozumiem, że kapsuła nie uruchamia się ponownie ... Kapsuła jest nadal taka sama, ale jest zmiana!

Na przykład: Pod działa od 50 minut i zmieniam coś, a zmiana jest w trybie online. Widzę to w przeglądarce, a moduł nadal działa + 50 minut !! Używam Helm3 ... Czy wiesz, co umożliwia to bez ponownego uruchamiania aktualizacji configmap?


1
Dobrze! Dowiaduję się tego ... Ponieważ zamontowaliśmy naszą mapę konfiguracji jako wolumin i aktualizowaliśmy ją dynamicznie ... Dlatego kiedy robię to "sumę kontrolną", mój moduł nie uruchamia się ponownie, ale zmiany już istnieją! dobre rozwiązanie :)
Ibrahim Yesilay

-1

Innym sposobem jest umieszczenie go w sekcji poleceń wdrożenia:

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

Alternatywnie, aby uczynić ją bardziej podobną do ConfigMap, użyj dodatkowego Wdrożenia, które po prostu będzie hostować tę konfigurację w commandsekcji i wykonywać kubectl createna niej, dodając unikalną `` wersję '' do jej nazwy (np. Obliczając skrót zawartości) i modyfikując wszystkie wdrożenia, które używają tej konfiguracji:

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

Prawdopodobnie opublikuję, kubectl-apply-config.shjeśli to zadziała.

(nie rób tego; wygląda to źle)

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.