¿Reiniciar los pods cuando se actualice el mapa de configuración en Kubernetes?

¿Cómo reinicio automáticamente los pods de Kubernetes y los pods asociados con las implementaciones cuando se cambia / actualiza su mapa de configuración?

Sé que se ha hablado de la capacidad de reiniciar automáticamente los pods cuando cambia un mapa de configuración, pero que yo sepa, esto aún no está disponible en Kubernetes 1.2.

Entonces, lo que (creo) me gustaría hacer es un "reinicio continuo" del recurso de implementación asociado con los pods que consumen el mapa de configuración. ¿Es posible, y de ser así, cómo, forzar un reinicio continuo de una implementación en Kubernetes sin cambiar nada en la plantilla real? ¿Es esta actualmente la mejor manera de hacerlo o hay una mejor opción?

La señalización de un pod en la actualización del mapa de configuración es una característica en proceso ( https://github.com/kubernetes/kubernetes/issues/22368 ).

Siempre puede escribir un pid1 personalizado que note que confimap ha cambiado y reinicie su aplicación.

También puede, por ejemplo: montar el mismo mapa de configuración en 2 contenedores, exponer una verificación de estado http en el segundo contenedor que falla si el hash del contenido del mapa de configuración cambia, y empujar eso como la sonda de vida del primer contenedor (porque los contenedores en un pod comparten el mismo espacio de nombres de red). El kubelet reiniciará su primer contenedor cuando la sonda falle.

Por supuesto, si no le importa en qué nodos se encuentran los pods, simplemente puede eliminarlos y el controlador de replicación los "reiniciará" por usted.

La mejor solución actual para este problema (a la que se hace referencia en https://github.com/kubernetes/kubernetes/issues/22368 vinculado en la respuesta del hermano) es usar Implementaciones y considerar que sus ConfigMaps son inmutables.

Cuando desee cambiar su configuración, cree un nuevo ConfigMap con los cambios que desea realizar y apunte su implementación al nuevo ConfigMap. Si la nueva configuración está rota, la implementación se negará a reducir su ReplicaSet en funcionamiento. Si la nueva configuración funciona, su antiguo ReplicaSet se escalará a 0 réplicas y se eliminará, y los nuevos pods se iniciarán con la nueva configuración.

No es tan rápido como editar el ConfigMap en su lugar, pero es mucho más seguro.

La mejor manera que he encontrado para hacerlo es ejecutar Reloader

Le permite definir mapas de configuración o secretos para observar, cuando se actualizan, se realiza una actualización continua de su implementación. He aquí un ejemplo:

Tiene una implementación fooy un ConfigMap llamado foo-configmap. Desea rodar los pods de la implementación cada vez que se cambia el mapa de configuración. Necesita ejecutar Reloader con:

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

Luego, especifique esta anotación en su implementación:

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

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

A menudo, los mapas de configuración o los secretos se inyectan como archivos de configuración en contenedores. Dependiendo de la aplicación, es posible que sea necesario reiniciar si se actualizan con unahelm upgrade , pero si la especificación de implementación en sí no cambió, la aplicación se seguirá ejecutando con la configuración anterior, lo que dará como resultado una implementación inconsistente.

La sha256sumfunción se puede usar junto con la includefunción para garantizar que una sección de la plantilla de implementaciones se actualice si cambia otra especificación:

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

En mi caso, por algunas razones, $.Template.BasePathno funcionó pero $.Chart.Namesí:

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

Puede actualizar una etiqueta de metadatos que no sea relevante para su implementación. activará una actualización continua

por ejemplo:

metadata:
  labels:
    configmap-version: 1

Tuve este problema donde la implementación estaba en un sub-gráfico y los valores que lo controlaban estaban en el archivo de valores del gráfico principal. Esto es lo que usamos para activar el reinicio:

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

Obviamente, esto activará el reinicio en cualquier cambio de valor, pero funciona para nuestra situación. Lo que estaba originalmente en el gráfico secundario solo funcionaría si el config.yaml en el gráfico secundario cambiara:

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

Hago la solución de los cuantos y funciona perfectamente. Pero lo que no entiendo es que el pod no se está reiniciando ... El pod sigue siendo el mismo, ¡pero hay cambios!

Por ejemplo: el pod se está ejecutando desde 50min y cambio algo y el cambio está en línea. Puedo verlo en mi navegador y el pod todavía se está ejecutando + 50min !! Estoy usando Helm3 ... ¿Sabes qué hace esto posible sin reiniciar la actualización de configmap?

Otra forma es pegarlo en la sección de comandos de la implementación:

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

Alternativamente, para hacerlo más parecido a ConfigMap, use una implementación adicional que solo alojará esa configuración en la commandsección y la ejecutará kubectl createmientras agrega una 'versión' única a su nombre (como calcular un hash del contenido) y modifica todos los implementaciones que usan esa configuración:

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

Probablemente lo publique kubectl-apply-config.shsi termina funcionando.

(no hagas eso; se ve muy mal)