Helm: Los valores "nulos" anidados no eliminan las claves como se esperaba

Creado en 18 ene. 2019  ·  36Comentarios  ·  Fuente: helm/helm

https://github.com/helm/helm/pull/2648 permite la eliminación de claves configurando los valores null en un archivo values.yaml . Sin embargo, no funciona para valores anidados, por ejemplo:

web:
  livenessProbe:
    httpGet: null
    exec:
      command:
      - curl
      - -f
      - http://localhost:8080/api/v1/info

No eliminará web.livenessProbe.httpGet de los valores originales, sino que simplemente anula el valor con null e imprime la advertencia:

2019/01/18 11:30:07 Warning: Merging destination map for chart 'concourse'. Cannot overwrite table item 'httpGet', with non table value: map[path:/api/v1/info port:atc]

Irónicamente, arriba hay una pequeña variante del ejemplo dado en los documentos, que estoy bastante seguro de que en realidad no hace lo que dice: https://docs.helm.sh/chart_template_guide/#deleting-a-default-key

Sospecho que, dado que la representación de la plantilla no parece diferenciar mucho entre un valor nulo y un valor que no se especifica, estas advertencias se ignoran y no tienen mucho efecto.

Salida de helm version :

Client: &version.Version{SemVer:"v2.12.1", GitCommit:"02a47c7249b1fc6d8fd3b94e6b4babf9d818144e", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.12.1", GitCommit:"02a47c7249b1fc6d8fd3b94e6b4babf9d818144e", GitTreeState:"clean"}

Salida de kubectl version :

Client Version: version.Info{Major:"1", Minor:"13", GitVersion:"v1.13.1", GitCommit:"eec55b9ba98609a46fee712359c7b5b365bdd920", GitTreeState:"clean", BuildDate:"2018-12-13T10:39:04Z", GoVersion:"go1.11.2", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"11+", GitVersion:"v1.11.5-eks-6bad6d", GitCommit:"6bad6d9c768dc0864dab48a11653aa53b5a47043", GitTreeState:"clean", BuildDate:"2018-12-06T23:13:14Z", GoVersion:"go1.10.3", Compiler:"gc", Platform:"linux/amd64"}

Proveedor de nube / plataforma (AKS, GKE, Minikube, etc.):

EKS

bug

Comentario más útil

También nos topamos con este problema (similar al descrito por @vbuciuc) con no trabajar como "nulo" para los valores anulados cuando el subchart se enumera como una dependencia en requirements.yaml con 3.2.x. Las versiones anteriores (3.1.x) funcionan como se esperaba.

Todos 36 comentarios

@scottrigby , ¿por casualidad quieres echar un vistazo a este?

Marcar como pregunta / apoyo hasta que se confirme que se trata de un error según el autor original.

También veo esto en 2.12.3. Estoy viendo al intentar establecer el valor en nulo a través de -f y --set. De cualquier manera, simplemente lo establece en "nulo" como una cadena (sin las comillas) en lugar de eliminar el valor predeterminado.
Mi situación:

> helm get values grafana
admin:
  existingSecret: ""
chownDataImage:
  pullPolicy: null
  repository: null
  tag: null
<...>

> helm upgrade grafana stable/grafana --tls --reuse-values --set chownDataImage.pullPolicy=null
<output indicating it works>

> helm get values grafana
admin:
  existingSecret: ""
chownDataImage:
  pullPolicy: null
  repository: null
  tag: null
<...>

El caso de uso es restablecer estos valores para usar los valores predeterminados de la plantilla en lugar de los valores predeterminados que ahora están atrapados en el timón.

estable / filebeat

Con null o nil veo lo mismo ... la clave no se quita ... se sobrescribe como null/nil pero no se quita y cuando está reemplazando con una clave diferente, causa un problema:

---values.yml in the Chart
output.file:
  path: /var/log/foo.log

`` yaml
--- mis anulaciones
output.elasticsearch:
Hospedadores:
- ' http: // localhost : 9200'
archivo de salida: nulo

or
```yaml
---my overrides
output:
  elasticsearch:
     host:
      - 'http://localhost:9200'
  file: null

o

---my overrides
output:
  elasticsearch:
     hosts:
      - 'http://localhost:9200'
output.file: null
» k get secret filebeat -o jsonpath="{.data.filebeat\.yml}" | base64 -D
    filebeat.config:
      modules:
        path: ${path.config}/modules.d/*.yml
        reload.enabled: false
      prospectors:
        path: ${path.config}/prospectors.d/*.yml
        reload.enabled: false
    filebeat.prospectors:
    - enabled: true
      fields:
        apenv: dev
        app: kubernetes
        log_category: kubernetes
      fields_under_root: true
      paths:
      - /var/log/*.log
      - /var/log/messages
      - /var/log/syslog
      type: log
    - containers.ids:
      - '*'
      fields:
        apenv: dev
        app: kubernetes
        log_category: kubernetes
      fields_under_root: true
      processors:
      - add_kubernetes_metadata:
          in_cluster: true
      - drop_event:
          when:
            equals:
              kubernetes.container.name: filebeat
      type: docker
    http.enabled: true
    http.port: 5066
    output:
      elasticsearch:
        hosts:
        - http://localhost9200
    output.file: null
    processors:
    - add_cloud_metadata: null

errores de pod como:

Exiting: error unpacking config data: more than one namespace configured accessing 'output' (source:'filebeat.yml')

También me encuentro con este problema exacto con el gráfico filebeat.

@cdenneen Puede sortear la salida de archivos específicamente con config.output.file.enabled=false .

Me encuentro con un problema en el que quiero usar la nueva clave inputs para filebeat pero no puedo eliminar la clave prospectors .

Valores existentes:

config:
  filebeat.prospectors:
    - type: log
      enabled: true
      paths:
        - /var/log/*.log
        - /var/log/messages
        - /var/log/syslog

Mi anulación: --set config.filebeat.prospectors=null

Resultado: (la configuración se usa para establecer un valor secreto)

filebeat:
  prospectors: null

También encontré este problema con stable/kibana y stable/filebeat las claves se establecerán de forma predeterminada en los valores del gráfico incluso cuando se especifique !!null .

@aeijdenberg cree que su PR solo requiere que las etiquetas se actualicen para ser revisadas

Hola @bacongobbler, lo siento, me perdí tu pregunta en https://github.com/helm/helm/issues/5184#issuecomment -456138448. Puedo verificar que es un error. En el # 2648 debería haber agregado una prueba que coincidiera con el ejemplo documentado. Tenía la intención de volver a esto, ¡pero el número 5185 parece prometedor! 👏 responderé allí

Hola @scottrigby . ¿Puedo saber qué versión incluirá la solución # 5185? Acabo de encontrar este problema al intentar eliminar las definiciones de recursos en el gráfico istio.

Se supone que está en 2.14.2, pero no puedo hacer que funcione.

Estoy siguiendo un ejemplo muy similar al que se encuentra en la parte superior del problema; la única diferencia que puedo ver es que estoy tratando de eliminar un conjunto de valores en un subgráfico (en mi caso, logstash).

Yo he tratado:

  • configurando logstash.livenessProbe.httpGet en null , ~ y {} en el gráfico principal values.yaml, o en la línea de comando. En ambos casos, "helm template" muestra que el valor original todavía está allí (es decir, todavía estoy obteniendo httpGet set), y esto es consistente con lo que veo para "helm install"
  • configurando logstash.livenessProbe.httpGet en "nil" - en este caso, el valor se sobrescribe, pero en la cadena "nil", que no es un valor válido para usar aquí, por lo que kubernetes rechaza la plantilla.

¿He entendido mal y esto no se convirtió en 2.14.2, o todavía hay un problema?

(Gráfico que demuestra esto: demo.zip )

El parche se seleccionó en 2.14.2 de acuerdo con las notas de la versión, por lo que debería estar disponible.

En cuyo caso, no estoy seguro de que este error esté solucionado, ¿debería volver a abrirse o crearse un nuevo problema? ¿Alguien más puede echar un vistazo a la tabla que adjunto a la anterior y ver si ven diferente?

@ cc-stjm @bacongobbler : puedo reproducir el problema y creo que esta prueba lo demuestra:

func TestSubchartCoaleseWithNullValue(t *testing.T) {
    v, err := CoalesceValues(&chart.Chart{
        Metadata: &chart.Metadata{Name: "demo"},
        Dependencies: []*chart.Chart{
            {
                Metadata: &chart.Metadata{Name: "logstash"},
                Values: &chart.Config{
                    Raw: `livenessProbe: {httpGet: {path: "/", port: monitor}}`,
                },
            },
        },
        Values: &chart.Config{
            Raw: `logstash: {livenessProbe: {httpGet: null, exec: "/bin/true"}}`,
        },
    }, &chart.Config{})
    if err != nil {
        t.Errorf("Failed with %s", err)
    }
    result := v.AsMap()
    expected := map[string]interface{}{
        "logstash": map[string]interface{}{
            "global": map[string]interface{}{},
            "livenessProbe": map[string]interface{}{
                "exec": "/bin/true",
            },
        },
    }
    if !reflect.DeepEqual(result, expected) {
        t.Errorf("got %+v, expected %+v", result, expected)
    }
}

El problema, por lo que puedo decir, es que CoalesceValues() da como resultado más de una llamada a la función subyacente que fusiona los valores:
https://github.com/helm/helm/blob/e04fa72f6f211cae68c362f9b7c62f06dc51493e/pkg/chartutil/values.go#L164 -L180

es decir, la línea 173 anterior se llama con httpGet establecido en null , pero el valor que devuelve ha eliminado esa clave del mapa (como se pretendía). Pero luego esa salida se pasa una segunda vez como entrada al segundo conjunto de coalescencia (línea 179), y luego, dado que la clave ya no existe, toma el valor predeterminado en el gráfico.

Desafortunadamente, es poco probable que tenga tiempo disponible en un futuro cercano para ir más lejos; he cambiado de roles y actualmente no estoy usando Helm, y la respuesta sobre cómo resolverlo no es obvia para mí. Es de esperar que lo anterior sea útil para resolverlo.

De hecho, acabo de actualizar 2.14.0 => 2.14.2. No solo sigue existiendo la clave null ed, sino que también contiene el valor anterior. El comportamiento anterior simplemente lo hizo nulo, por lo que creo que esto realmente ha retrocedido.

@aeijdenberg, ¿ puede consultar la consulta de @sgillespie ? Si hay una regresión, entonces probablemente sea más seguro retroceder ese PR a menos que pueda determinar una solución. Si no puede ayudar, probablemente sea más seguro revertir su compromiso y volver al cuadro 1. Dígame cómo le gustaría proceder.

@bacongobbler , aunque no he probado explícitamente 2.14.0, lo que @sgillespie coincide con el comportamiento al que me referí en https://github.com/helm/helm/issues/5184#issuecomment-517059748 . Lamentablemente, creo que es un caso en el que las pruebas unitarias pasan, pero fallan de un extremo a otro, ya que los componentes individuales se utilizan en serie, lo que hace que la eliminación de una clave en una etapa anterior no tenga ningún efecto en las etapas posteriores (y es por eso que los valores originales están llegando).

Estoy de acuerdo en que es una regresión, aunque retroceder también es una regresión para cualquiera que confíe en el nuevo comportamiento.

Probé rápidamente un parche relativamente menor que creo que reducirá el impacto (y corrige la prueba que agregué anteriormente) en el n. ° 6146. Siento habernos equivocado en el último intento.

Esto podría haberse solucionado en https://github.com/helm/helm/pull/6080. Ese PR soluciona el caso en el que coalesceDeps se llama dos veces. ¿Alguien puede confirmar con el maestro?

Si es así, ¿se puede cerrar # 6146 o está intentando solucionar un problema por separado? Estoy tratando de entender el espacio del problema aquí, pero no está claro qué están tratando de resolver estos RP. Lo siento.

De hecho, esto parece solucionar el problema. Una prueba rápida e ingenua:

Valores de subcarta:

prop:
  nested:
    val: true

Valores del gráfico principal:

sub:
  prop:
    nested: null

La salida como se esperaba es {}

Hola,

Estoy usando helm 2.15.0 y todavía tengo este problema.

Dado un subgráfico con valores:

securityContext:
  runAsUser: 65534
  fsGroup: 65534

Donde los valores se usan con toYaml

Y en los valores de un gráfico principal:

sub:
  securityContext:
  runAsUser: null

Entonces la salida real es:

securityContext:
  runAsUser: 65534
  fsGroup: 65534

Si bien debería haber sido:

securityContext:
  fsGroup: 65534

No intento llover en tu desfile, pero sigo viendo esto con helm v3.0.1

version.BuildInfo {Versión: "v3.0.1", GitCommit: "7c22ef9ce89e0ebeb7125ba2ebf7d421f3e82ffa", GitTreeState: "clean", GoVersion: "go1.13.4"}

Al intentar instalar estable / ignite, tengo que anular el establecimiento de un valor, pero parece que helm simplemente establece el valor en nulo / nulo, lo que hace que k8s se bloquee en el paso de validación.

Para reproducirlo, guárdelo como bug5184-ignite.yaml (para anular los valores de los valores predeterminados del gráfico: https://github.com/helm/charts/blob/master/stable/ignite/values.yaml):

persistence:
  enabled: true   # <-- without this, the keys in question are ignored
  persistenceVolume:
    provisionerParameters:
      type: null  # <-- I want to unset this key
  walVolume:
    provisionerParameters:
      type: null  # <-- I want to unset this key

Luego utilícelo como archivo de valores para una instalación de encendido:

helm install runtimedb stable/ignite --version 1.0.1 --values bug5184-ignite.yaml --debug --dry-run | less

El resultado que obtengo es este mensaje de error, que muestra que el valor que quería desarmar se estableció en nil :

install.go:148: [debug] Original chart version: ""
install.go:165: [debug] CHART PATH: /home/creinig/.cache/helm/repository/ignite-1.0.1.tgz

Error: unable to build kubernetes objects from release manifest: error validating "": error validating data: unknown object type "nil" in StorageClass.parameters.type
helm.go:76: [debug] error validating "": error validating data: unknown object type "nil" in StorageClass.parameters.type
helm.sh/helm/v3/pkg/kube.scrubValidationError
        /home/circleci/helm.sh/helm/pkg/kube/client.go:520
helm.sh/helm/v3/pkg/kube.(*Client).Build
        /home/circleci/helm.sh/helm/pkg/kube/client.go:135
helm.sh/helm/v3/pkg/action.(*Install).Run
        /home/circleci/helm.sh/helm/pkg/action/install.go:229
[...]

Lo que también probé:

  • Establecer el valor en algo diferente / no anularlo en absoluto

    • => El PersistentVolumeClaim está bloqueado en "Pendiente" porque hay una opción de "tipo" adicional que no es compatible con el proveedor

    • => definitivamente es ese valor el que causa los problemas

  • Establecer el valor (es) en null través de --set

    • El mismo comportamiento que al configurarlo en el archivo

Cuando solo se establece un valor único en null través de la línea de comando, mientras que al mismo tiempo se mantiene la persistencia de encendido desactivada (para que no se genere la plantilla de la clase de almacenamiento y se ignore el parámetro en cuestión) ...

helm install myignite stable/ignite --version 1.0.1 --set persistence.persistenceVolume.provisionerParameters.type=null --debug --dry-run | less

... hay una salida de depuración adecuada en lugar de un error, pero muestra que el valor está establecido en null (comentarios agregados por mí):

NAME: myignite
LAST DEPLOYED: Tue Dec 10 09:43:40 2019
NAMESPACE: default
STATUS: pending-install
REVISION: 1
TEST SUITE: None
USER-SUPPLIED VALUES:
persistence:
  persistenceVolume:
    provisionerParameters:
      type: null   # <-- Set via the command line

COMPUTED VALUES:
affinity: {}
dataStorage:
  config: ""
env:
  IGNITE_QUIET: "false"
  JVM_OPTS: -Djava.net.preferIPv4Stack=true
  OPTION_LIBS: ignite-kubernetes,ignite-rest-http
fullnameOverride: ""
image:
  pullPolicy: IfNotPresent
  repository: apacheignite/ignite
  tag: 2.7.6
nameOverride: ""
nodeSelector: {}
peerClassLoadingEnabled: false
persistence:
  enabled: false
  persistenceVolume:
    provisioner: kubernetes.io/aws-ebs
    provisionerParameters:
      fsType: ext4
      type: null  # <-- Set to null instead of removed
    size: 8Gi
  walVolume:
    provisioner: kubernetes.io/aws-ebs
    provisionerParameters:
      fsType: ext4
      type: gp2  # <-- This is what the default looks like
    size: 8Gi
rbac:
  create: true
replicaCount: 2
resources: {}
serviceAccount:
  create: true
  name: null
tolerations: []

Me he encontrado exactamente con el mismo problema usando 3.0.1 , ¿podría ser bueno volver a abrir este problema?

Después de pasar de helm v2.16.1 a v3.0.2. He tenido este problema con anotaciones que se desarman y límites de CPU.

Acabo de encontrar este problema en 2.14.1 y 3.0.2 . ¿Algún avance en esto?

En los casos en los que sé que el gráfico de timón simplemente usa una prueba de verdadero / falso si, anulo el valor con un valor que no es de tabla como 0. Recibo muchas advertencias como Overwriting table item 'x', with non table value: 0 , pero al menos obtengo una solución en los casos en los que no quiero que se incluya una estrofa. Mi preferencia sería que null funcione, pero esta es una solución desagradable.

Establecí valores en nulos (y los dejé nulos en mis archivos de valores) e ignoro la larga lista de advertencias de la tabla que está bien por ahora, pero realmente me gustaría hacer una limpieza única de los antiguos valores incorrectos almacenados en kubernetes. Hasta que se solucione este error de eliminación de valores, ¿hay alguna forma manual de editar los valores en una implementación existente sin tiempo de inactividad?

Se encuentra con el mismo problema con las sondas liveness y readiness .
La eliminación de la clave predeterminada de la guía de plantillas no funciona.

Por favor, pruebe el número 7743. Parece que las confirmaciones realizadas en Helm 2 no se transfirieron a Helm 3, por lo que muchos usuarios verían este comportamiento allí.

Sigo viendo este problema con helm 2.16.3 pero solo cuando hay un requirements.yaml que enumera el subchart como dependencia.

boo es el subgráfico y foo es el gráfico principal:

vibu@item-ax35755:~/work$ cat boo/values.yaml 
object:
  fromSubchart:
    hello: from boo
vibu@item-ax35755:~/work$ cat foo/values.yaml 
boo:
  object:
    fromParent:
      hello: from foo
    fromSubchart: null
vibu@item-ax35755:~/work$ cat boo/templates/test.yaml 
{{ toYaml .Values.object }}
vibu@item-ax35755:~/work$ cat foo/requirements.yaml 
dependencies:
- name: boo
  repository: file://../boo
  version: 0.1.0
vibu@item-ax35755:~/work/foo$ helm version -c
Client: &version.Version{SemVer:"v2.16.3", GitCommit:"1ee0254c86d4ed6887327dabed7aa7da29d7eb0d", GitTreeState:"clean"}
vibu@item-ax35755:~/work/foo$ helm dep up
Hang tight while we grab the latest from your chart repositories...
...Successfully got an update from the "incubator" chart repository
...Successfully got an update from the "stable" chart repository
Update Complete.
Saving 1 charts
Deleting outdated charts

vibu@item-ax35755:~/work/foo$ helm template .
---
# Source: foo/charts/boo/templates/test.yaml
fromParent:
  hello: from foo
fromSubchart:
  hello: from boo


vibu@item-ax35755:~/work/foo$ mv requirements.yaml{,.bak}
vibu@item-ax35755:~/work/foo$ helm template .
---
# Source: foo/charts/boo/templates/test.yaml
fromParent:
  hello: from foo

Ambos gráficos aquí:

helm_5184.zip

@bacongobbler ¿hay alguna intención de abordar esto en 2.x?

También nos topamos con este problema (similar al descrito por @vbuciuc) con no trabajar como "nulo" para los valores anulados cuando el subchart se enumera como una dependencia en requirements.yaml con 3.2.x. Las versiones anteriores (3.1.x) funcionan como se esperaba.

@bacongobbler @technosophos También me encuentro con este problema con Helm 3.3.4 , ¿pueden volver a abrir;

Puedo confirmar que funcionó en 3.1.2 y dejó de funcionar después de 3.2.x como menciona @paleg . Por ahora, parece que la solución alternativa de @ tuzla0autopilot4 de establecerlo en un valor que no sea de mapa como false producirá el comportamiento previsto, pero dará advertencias de salida cuando se haga.

@ Chili-Man, acabo de probar con 3.1.3 y no parece funcionar. Se aplicará con null pero recibo una advertencia y no hace nada. Con cualquier otra cosa ( false , 0 , [] ) se niega con (por ejemplo,)

`` `coalesce.go: 196: advertencia: no se puede sobrescribir la tabla con no tabla para recursos (mapa [solicitudes: mapa [cpu: 250 m de memoria: 256 Mi]])
Error: ACTUALIZACIÓN FALLIDA: los valores no cumplen con las especificaciones de los esquemas en los siguientes cuadros:
postgresql:

  • recursos: tipo no válido. Esperado: objeto, dado: booleano
    `` (or what the type that I try that is not a dict/hash). With 3.3.4 I get just silence and it does nothing with null` e igualmente todo lo demás se niega a aplicar. El más molesto...

Sigo experimentando este problema en 3.4.2.

El problema sigue presente en 3.4.2, pero solo en determinadas situaciones.
Tengo un gráfico con varios subgráficos.
Al poner valores predeterminados en los subgráficos, null override no funciona. Si mueve los mismos valores a los valores del gráfico principal, funciona como se esperaba.
Esto es reproducible solo con sub-gráficos. Cuando lo pones en un solo gráfico (plano), todo funciona bien.

Estoy experimentando el mismo problema con 3.4.2 cuando uso subgráficos (como lo describe @BohdanKalytka arriba).
En mi caso, quiero sobrescribir el securityContext cuando uso el gráfico de timón ElasticSearch en un clúster de OpenShift.
¿Se volverá a abrir este número o deberíamos crear uno nuevo?

Criado # 9136

¿Fue útil esta página
0 / 5 - 0 calificaciones