Перезапустить контейнеры при обновлении configmap в Kubernetes?

Ответ 1

Сигнализация pod для обновления карты конфигурации - это функция в работе (https://github.com/kubernetes/kubernetes/issues/22368).

Вы всегда можете написать пользовательский pid1, который замечает, что конфиг изменился и перезапустил ваше приложение.

Вы также можете: смонтировать одну и ту же конфигурационную карту в двух контейнерах, выставить проверку работоспособности HTTP во втором контейнере, которая не удастся, если хэш содержимого конфигурации конфигурации изменится, и засунуть это как пробку живой активности в первый контейнер (потому что контейнеры в пакете имеют одно и то же пространство имен в сети). Кубелет перезапустит ваш первый контейнер для вас, когда зонд не сработает.

Конечно, если вы не заботитесь о том, какие узлы находятся, вы можете просто удалить их, и контроллер репликации "перезапустит" их для вас.

Ответ 2

Нынешнее наилучшее решение этой проблемы (ссылка на глубину https://github.com/kubernetes/kubernetes/issues/22368, связанная в ответе на сестры) заключается в использовании развертываний и ConfigMaps должен быть неизменным.

Если вы хотите изменить свой конфиг, создайте новый ConfigMap с изменениями, которые вы хотите внести, и укажите развертывание в новом ConfigMap. Если новая конфигурация нарушена, Deployment откажется сократить ваш рабочий ReplicaSet. Если новая конфигурация работает, то ваш старый ReplicaSet будет масштабирован до 0 реплик и удален, а новые модули будут запущены с новой конфигурацией.

Не так быстро, как просто редактировать ConfigMap на месте, но гораздо безопаснее.

Ответ 3

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

Часто конфигурационные файлы или секреты вводятся в виде файлов конфигурации в контейнерах. В зависимости от приложения может потребоваться перезагрузка, если они будут обновлены с последующим helm upgrade, но если сама спецификация развертывания не изменилась, приложение продолжает работать со старой конфигурацией, что приводит к непоследовательному развертыванию.

Функция sha256sum может использоваться вместе с функцией include чтобы гарантировать, что раздел шаблонов развертывания обновляется, если изменяется другая спецификация:

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

В моем случае по некоторым причинам $.Template.BasePath не работал, но $.Chart.Name:

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

Ответ 4

Лучший способ сделать это - запустить Reloader.

Он позволяет вам определять конфигурационные карты или секреты, которые нужно отслеживать, когда они обновляются, выполняется обновление вашего развертывания. Вот пример:

У вас есть foo для развертывания и ConfigMap с именем foo-configmap. Вы хотите свернуть модули развертывания каждый раз, когда изменяется конфигурация. Вам нужно запустить Reloader с:

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

Затем укажите эту аннотацию в своем развертывании:

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

Ответ 5

Вы можете обновить метку метаданных, которая не относится к вашему развертыванию. это приведет к скользящему обновлению

например:

metadata:
  labels:
    configmap-version: 1

Ответ 6

Другой способ - вставить его в командную часть развертывания:

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

В качестве альтернативы, чтобы сделать его более похожим на ConfigMap, используйте дополнительное развертывание, которое будет просто размещать эту конфигурацию в разделе command и выполнять на kubectl create при добавлении к его имени уникальной "версии" (например, вычисления хеша содержимого) и изменяя все развертывания, которые используют этот конфиг:

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

Я, вероятно, kubectl-apply-config.sh если он закончит работу.

(не делайте этого, это выглядит слишком плохо)