Zrestartować pody po aktualizacji configmap w Kubernetes?

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?

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.

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.

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 }}

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

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

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 }}

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?

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)