Estamos comenzando a administrar recursos de Kubernetes con Helm y tenemos algunos usuarios que están acostumbrados a administrar recursos con kubectl edit. Nos gustaría que Helm desinfecte los recursos implementados cada vez que se ejecuta, devolviéndolos a un buen estado conocido.
He observado que eso helm upgradeno sobrescribe mis ConfigMaps. En cambio, fusiona atributos entre el ConfigMap implementado y la plantilla de Helm, brindándome partes de mi ConfigMap con plantilla y partes del editado a mano. Si no hubo cambios en la plantilla Helm ConfigMap, Helm sínorestablecer cualquier parte de mi ConfigMap implementado a un estado correcto.
¿Cómo puedo indicarle a Helm que siempre restablezca todo mi recurso de Kubernetes a las versiones con plantilla de Helm?
Respuesta1
Este no es un objetivo de diseño de Helm y sigue sin serlo. No está dentro del alcance de Helm manipular objetos que no fueron creados por Helm, o ignorar los cambios fuera de banda en objetos bajo su "control"; esta es una característica que hace que Helm sea compatible con otros sistemas que pueden cambiar los manifiestos, y hace que Helm sea seguro de usar. Recuerde que es un sistema de renderizado YAML, no un sistema de gestión de configuración como Puppet o SaltStack. No "impone" configuraciones.
Si desea lograr el comportamiento que describe, puede eliminar los objetos en cuestión antes de volver a crearlos con Helm. Potencialmente, puede utilizar espacios de nombres de Kubernetes para lograr esto de manera confiable dándole a cada gráfico su propio espacio de nombres y eliminando el espacio de nombres antes de la instalación del gráfico como una forma de "restablecimiento completo".
O evite que los usuarios que están acostumbrados a editar manifiestos kubectllo hagan y, en su lugar, diríjalos para que introduzcan esos cambios en gráficos o valores. No parece razonable descartar sus cambios si es necesario realizarlos; para empezar, esta es exactamente la razón por la que Helm realiza operaciones de combinación de tres vías en los manifiestos. Entiendo el deseo de conservar la configuración en un único punto de orquestación, pero no espero lograrlo sin utilizar un único punto de orquestación.
Este problema surge constantemente cuando se aplican prácticas de orquestación de nivel superior a equipos que están acostumbrados a métodos de orquestación de nivel inferior y de ninguna manera está restringido conceptualmente a Helm. Helm es bueno para manejar la situación con elegancia al realizar operaciones de fusión, pero da como resultado un desorden funcional de metodologías de orquestación (al menos no rompe cosas o simplemente falla). Comience por no crear el desorden o limitarlo a un entorno borrador y recogerlo en gráficos Helm para producción.