Diferencias entre Helm v2 y Helm v3 y soluciones de adaptación
Helm v2 se detiene en la versión 2.17.0. Actualmente, Helm v3 es el estándar en la comunidad Helm. Se le aconseja cambiar sus gráficos al formato de Helm v3 tan pronto como sea posible.
Cambios desde Helm v2:
- Remoción de timón
Helm v3 es más simple y más fácil de usar. Quita el timón y se conecta directamente al servidor de API usando kubeconfig, simplificando el modelo de seguridad.
- Estrategia de actualización mejorada: parches de fusión estratégica de 3 vías
Helm v2 usó un parche de fusión estratégica bidireccional. Durante una actualización, comparó el manifiesto del gráfico más reciente con el manifiesto del gráfico propuesto para determinar qué cambios debían aplicarse a los recursos en Kubernetes. Si se aplicaron cambios al clúster fuera de banda (como durante una edición de kubectl), esos cambios no se consideraron. Esto dio lugar a que los recursos no pudieran volver a su estado anterior.
Helm v3 utiliza un parche de fusión estratégica de tres vías. Helm considera el viejo manifiesto, su estado vivo, y el nuevo manifiesto cuando genera un parche. Helm compara el estado activo actual con el estado activo del manifiesto antiguo, comprueba si se modifica el nuevo manifiesto y complementa automáticamente el nuevo manifiesto para generar el parche final de actualización.
Para obtener más detalles y ejemplos, consulte https://v3.helm.sh/docs/faq/changes_since_helm2.
- Secretos como controlador de almacenamiento predeterminado
Helm v2 usaba ConfigMaps de forma predeterminada para almacenar información de lanzamiento. En Helm v3, los secretos ahora se utilizan como el controlador de almacenamiento predeterminado.
- Los nombres de versiones ahora están en el ámbito del espacio de nombres
En Helm v2, la información sobre cada versión se almacenaba en el mismo espacio de nombres que Tiller. En la práctica, esto significaba que una vez que un nombre fue utilizado por una versión, ninguna otra versión podría usar ese mismo nombre, incluso si se desplegó en un espacio de nombres diferente. En Helm v3, la información sobre una versión en particular se almacena ahora en el mismo espacio de nombres que la versión en sí. Esto significa que el nombre de la versión se puede usar en diferentes espacios de nombres. El espacio de nombres de la aplicación es el mismo que el de la versión.
- Cambio de modo de verificación
Helm v3 verifica el formato del gráfico más estrictamente. Por ejemplo, Helm v3 golpea la apiVersion en Chart.yaml de v1 a v2. Para el Chart.yaml de v2, apiVersion debe establecerse en v1. Después de instalar el cliente Helm v3, puede ejecutar el comando helm lint para comprobar si el formato del gráfico cumple con las especificaciones de Helm v3.
Solución de adaptación: Adapta el gráfico de Helm v3 basado en el documento oficial de Helm https://helm.sh/docs/topics/charts/. El campo apiVersion es obligatorio.
- Eliminación del gancho crd-install
El gancho crd-install se ha eliminado a favor del directorio crds/ en Helm v3. Tenga en cuenta que los recursos del directorio crds/ solo se desplieguen durante la instalación de la versión y no se actualizan durante la actualización. Cuando se eliminan los recursos, los recursos se conservan en el directorio crds/. Si el CRD ya existe, se omitirá con una advertencia durante la instalación repetida.
Solución de adaptación: De acuerdo con el documento de Helm, puede mantener su CRD en el directorio crds/ o en un gráfico separado. Helm no puede actualizar o eliminar el CRD. Por lo tanto, se recomienda poner el CRD en un gráfico y, a continuación, poner los recursos que utilizan ese CRD en otro gráfico.
- Los recursos que no se crean con Helm no se actualizan a la fuerza. Las versiones no se actualizan a la fuerza de forma predeterminada.
Se cambia la lógica de actualización forzada de Helm v3. Después de que la actualización falla, el sistema no elimina y reconstruye el Helm v3. En su lugar, el sistema utiliza directamente la lógica put. Por lo tanto, la actualización de la versión de CCE utiliza la lógica de actualización no forzada de forma predeterminada. Los recursos que no se pueden actualizar mediante parches harán que la versión no se pueda actualizar. Si existe una versión con el mismo nombre en el entorno y no tiene la etiqueta de inicio app.kubernetes.io/managed-by: Helm de Helm v3, se muestra un mensaje de conflicto.
Solución de adaptación: Eliminar recursos relacionados y crearlos usando Helm.
- Límite en los registros históricos de liberación
De forma predeterminada, solo se conservan las 10 versiones más recientes.
Para más cambios y detalles, consulte los documentos oficiales de Helm.
- Diferencias entre Helm v2 y Helm v3: https://v3.helm.sh/docs/faq/changes_since_helm2
- Cómo migrar de Helm v2 a Helm v3: https://helm.sh/docs/topics/v2_v3_migration
