envfrom - ¿Reiniciar los pods cuando configmap se actualiza en Kubernetes?
kubernetes envfrom (6)
Sé que se ha hablado sobre 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 deployment asociado con los pods que consumen el mapa de configuración. ¿Es posible, y si es así, 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 mejor manera de hacerlo es ejecutar Reloader
Le permite definir mapas de configuración o secretos para ver, cuando se actualizan, se realiza una actualización continua de su implementación. Aquí hay un ejemplo:
Tiene un despliegue
foo
y 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
...
La mejor solución actual para este problema (referenciada en profundidad en https://github.com/kubernetes/kubernetes/issues/22368 vinculada en la respuesta entre hermanos) 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 se rompe, la implementación se negará a reducir su ReplicaSet de trabajo. Si la nueva configuración funciona, su antiguo ReplicaSet se escalará a 0 réplicas y se eliminará, y se iniciarán nuevos pods con la nueva configuración.
No es tan rápido como simplemente editar el ConfigMap en su lugar, pero es mucho más seguro.
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 el 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 comprobación de estado http en el segundo contenedor que falla si cambia el hash del contenido del mapa de configuración, y empujarlo como la sonda de vida del primer contenedor (porque los contenedores en un Pod compartir 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 están los pods, simplemente puede eliminarlos y el controlador de replicación los "reiniciará" por usted.
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 albergará esa configuración en la sección de
command
y ejecutará
kubectl create
mientras agrega una ''versión'' única a su nombre (como calcular un hash del contenido) y modificando todas las implementaciones que usan esa configuración:
...
command: [ "/usr/sbin/kubectl-apply-config.sh", "
option = value/n
other_option = value/n
" ]
...
Probablemente publicaré
kubectl-apply-config.sh
si termina funcionando.
(no hagas eso; se ve muy mal)
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
Muchas veces los mapas de configuración o los secretos se inyectan como archivos de configuración en contenedores.
Dependiendo de la aplicación, puede ser necesario reiniciar si se actualizan con una
helm upgrade
posterior, pero si la especificación de implementación en sí no cambió, la aplicación sigue ejecutándose con la configuración anterior, lo que resulta en una implementación inconsistente.
La función
sha256sum
se puede usar junto con la función de
include
para garantizar que se actualice una sección de plantilla de despliegues 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.BasePath
no funcionó pero
$.Chart.Name
sí:
spec:
replicas: 1
template:
metadata:
labels:
app: admin-app
annotations:
checksum/config: {{ include (print $.Chart.Name "/templates/" $.Chart.Name "-configmap.yaml") . | sha256sum }}