Helm: Вложенные значения null не удаляют ключи должным образом

Созданный на 18 янв. 2019  ·  36Комментарии  ·  Источник: helm/helm

https://github.com/helm/helm/pull/2648 позволяет удалять ключи, устанавливая значения null в файле values.yaml . Однако это не работает для вложенных значений, например:

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

Не удаляет web.livenessProbe.httpGet из исходных значений, а просто переопределяет значение с помощью null и выводит предупреждение:

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]

По иронии судьбы, выше представлен небольшой вариант примера, приведенного в документации, который, я уверен, на самом деле не делает того, на что претендует: https://docs.helm.sh/chart_template_guide/#deleting-a-default-key

Я подозреваю, что, поскольку рендеринг шаблона, похоже, не сильно различает нулевое значение и значение, которое не указывается, эти предупреждения игнорируются и не имеют большого эффекта.

Вывод helm version :

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

Вывод 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"}

Облачный провайдер / платформа (AKS, GKE, Minikube и т. Д.):

EKS

Самый полезный комментарий

Мы также столкнулись с этой проблемой (аналогичной той, что описана в @vbuciuc), когда не работал "null" для переопределения значений, когда подграфик указан как зависимость в файле requirements.yaml с 3.2.x. Предыдущие версии (3.1.x) работают должным образом.

Все 36 Комментарий

@scottrigby , ты случайно не хочешь взглянуть на это?

Пометка как вопрос / поддержка до тех пор, пока не будет подтверждено, что это действительно ошибка, согласно первоначальному автору.

Я тоже это вижу 2.12.3. Я вижу, пытаясь установить значение null с помощью -f и --set. В любом случае он просто устанавливает значение «null» в виде строки (без кавычек), а не удаляет значение по умолчанию.
Моя ситуация:

> 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
<...>

Пример использования - сбросить эти значения, чтобы использовать значения по умолчанию из шаблона вместо значений по умолчанию, которые теперь застряли в штурвале.

стабильный / filebeat

С null или nil я вижу то же самое ... ключ не удален ... он перезаписывается как null/nil но не удаляется, и когда вы заменяете это с другим ключом вызывает проблему:

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

ямл
--- мои переопределения
output.elasticsearch:
хосты:
- ' http: // localhost : 9200'
output.file: нуль

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

или же

---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

ошибки пода как:

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

Я также сталкиваюсь с этой точной проблемой с диаграммой битов файлов.

@cdenneen Вы можете обойти вывод файла с помощью config.output.file.enabled=false .

У меня возникла проблема, когда я хочу использовать новый ключ inputs для filebeat, но не могу удалить ключ prospectors .

Существующие значения:

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

Мое переопределение: --set config.filebeat.prospectors=null

Результат: (для установки секретного значения используется конфигурация)

filebeat:
  prospectors: null

Я также столкнулся с этой проблемой с stable/kibana и stable/filebeat ключи по умолчанию будут иметь значения диаграммы, даже если указано !!null .

@aeijdenberg считает, что ваш PR просто требует обновления этикеток для

Привет, @bacongobbler, извини, я пропустил твой вопрос в https://github.com/helm/helm/issues/5184#issuecomment -456138448. Я могу убедиться, что это ошибка. В # 2648 мне действительно следовало добавить тест, соответствующий документированному примеру. Я хотел вернуться к этому, но # 5185 выглядит многообещающе! 👏 ответит там

Привет, @scottrigby . Могу ли я узнать, какой выпуск будет включать исправление # 5185? Я только что столкнулся с этой проблемой при попытке удалить определения ресурсов на диаграмме istio.

Это должно быть в 2.14.2, но я не могу заставить его работать.

Я следую примеру, очень похожему на приведенный в верхней части проблемы - единственное различие, которое я вижу, заключается в том, что я пытаюсь удалить значение, установленное в подграфике (в моем случае, logstash).

Я пытался:

  • установка logstash.livenessProbe.http Получите null , ~ и {} в файле values.yaml основной диаграммы или в командной строке. В обоих случаях "шаблон helm" показывает, что исходное значение все еще существует (т.е. я все еще получаю набор httpGet) - и это согласуется с тем, что я вижу для "helm install"
  • установка logstash.livenessProbe.http Получите значение «nil» - в этом случае значение действительно перезаписывается, но на строку «nil», которая здесь недопустима, поэтому kubernetes отклоняет шаблон.

Я неправильно понял, и это не вошло в 2.14.2 - или проблема все еще существует?

(Диаграмма, демонстрирующая это: demo.zip )

Патч был выбран для версии 2.14.2 в соответствии с примечаниями к выпуску, поэтому он должен быть доступен.

В этом случае я не уверен, что эта ошибка исправлена ​​- следует ли ее повторно открыть или создать новую проблему? Может ли кто-нибудь еще взглянуть на таблицу, которую я прикрепил к выше, и увидеть, видят ли они что-то другое?

@ cc-stjm @bacongobbler - я могу воспроизвести проблему, и я думаю, что этот тест демонстрирует это:

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)
    }
}

Насколько я могу судить, проблема в том, что CoalesceValues() приводит к более чем одному вызову базовой функции, которая объединяет значения:
https://github.com/helm/helm/blob/e04fa72f6f211cae68c362f9b7c62f06dc51493e/pkg/chartutil/values.go#L164 -L180

т.е. строка 173 выше вызывается с httpGet установленным в null , но возвращаемое значение удаляет этот ключ с карты (как и предполагалось). Но затем этот вывод передается второй раз в качестве ввода для второго набора объединения (строка 179), а затем, поскольку ключ больше не существует, по умолчанию используется значение, указанное в диаграмме.

К сожалению, в ближайшем будущем у меня вряд ли будет время, чтобы пойти дальше - я сменил роли и в настоящее время не использую Helm, и ответ о том, как решить, для меня не очевиден. Надеюсь, вышеизложенное поможет в решении.

Фактически, я только что обновил 2.14.0 => 2.14.2. Мало того, что ключ null ed все еще существует, он также содержит предыдущее значение. Предыдущее поведение просто сделало его нулевым, поэтому я считаю, что это действительно регресс.

@aeijdenberg, не могли бы вы изучить запрос @sgillespie ? Если есть регресс, то, вероятно, безопаснее поддержать этот PR, если вы не можете определить исправление. Если вы не можете помочь, то, вероятно, безопаснее отменить фиксацию и вернуться к квадрату 1. Дайте мне знать, как вы хотите действовать.

@bacongobbler , хотя я явно не тестировал 2.14.0, то, что @sgillespie соответствует поведению, о котором я упоминал в https://github.com/helm/helm/issues/5184#issuecomment-517059748 . К сожалению, я думаю, что это тот случай, когда модульные тесты проходят, но полностью не работают - поскольку отдельные компоненты используются последовательно, из-за чего удаление ключа на более раннем этапе не оказывает никакого влияния на более поздних этапах (и вот почему исходные значения проходят).

Я согласен, что это регресс, хотя отказ от него также является регрессом для любого, кто полагается на новое поведение.

Я быстро разработал относительно небольшой патч, который, я думаю, уменьшит влияние (и исправит тест, который я добавил выше) в # 6146 - мне жаль, что мы ошиблись в последней попытке.

Это могло быть исправлено в https://github.com/helm/helm/pull/6080. Этот PR исправляет случай, когда coalesceDeps вызывается дважды. Может кто-нибудь уточнить у мастера?

Если да, то можно ли закрыть # 6146 или пытается исправить отдельную проблему? Я пытаюсь осознать здесь проблемное пространство, но неясно, что эти PR пытаются решить. Извиняюсь.

Кажется, это действительно решает проблему. Быстрый наивный тест:

Значения подграфика:

prop:
  nested:
    val: true

Значения родительской диаграммы:

sub:
  prop:
    nested: null

Ожидаемый результат: {}

Привет,

Я использую helm 2.15.0 и все еще сталкиваюсь с этой проблемой.

Учитывая подграфик со значениями:

securityContext:
  runAsUser: 65534
  fsGroup: 65534

Где значения используются с toYaml

И в значениях родительской диаграммы:

sub:
  securityContext:
  runAsUser: null

Тогда фактический результат:

securityContext:
  runAsUser: 65534
  fsGroup: 65534

Хотя должно было быть:

securityContext:
  fsGroup: 65534

Не пытаюсь обрушить дождь на ваш парад, но я все еще вижу это с помощью helm v3.0.1

version.BuildInfo {Версия: "v3.0.1", GitCommit: "7c22ef9ce89e0ebeb7125ba2ebf7d421f3e82ffa", GitTreeState: "clean", GoVersion: "go1.13.4"}

При попытке установить stable / ignite мне нужно сбросить значение, но похоже, что helm просто устанавливает значение null / nil, в результате чего k8s блокируется на этапе проверки.

Для воспроизведения сохраните это как bug5184-ignite.yaml (чтобы переопределить значения по умолчанию для диаграммы: 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

Затем используйте его как файл значений для установки ignite:

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

В результате я получаю это сообщение об ошибке, показывающее, что значение, которое я хотел сбросить, было установлено на 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
[...]

Что еще пробовал:

  • Установка значения на что-то другое / без его отмены

    • => PersistentVolumeClaim застрял в состоянии «Ожидание», потому что есть дополнительная опция «типа», которая не поддерживается поставщиком

    • => определенно это значение вызывает проблемы

  • Установка значений null через --set

    • Такое же поведение, как и при установке в файл

При установке только одного значения в null через командную строку, при этом сохраняя отключенное постоянство зажигания (так что шаблон storageclass не создается, а рассматриваемый параметр игнорируется) ...

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

... вместо ошибки отображается правильный вывод отладки, но он показывает, что значение просто установлено на null (комментарии добавлены мной):

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: []

Я столкнулся с той же проблемой, используя 3.0.1 Может быть, стоит снова открыть эту проблему?

После перехода с helm v2.16.1 на v3.0.2. У меня была эта проблема с отключением аннотаций и ограничениями процессора.

Я просто сталкиваюсь с этой проблемой в 2.14.1 и 3.0.2 . Есть новости по этому поводу?

В тех случаях, когда я знаю, что диаграмма руля просто использует и true / false при проверке, я заменяю значение значением, отличным от таблицы, например 0. Я получаю много предупреждений, например Overwriting table item 'x', with non table value: 0 , но я, по крайней мере, получаю обходной путь в тех случаях, когда я не хочу включать строфу. Я бы предпочел, чтобы null работал, но это уродливый обходной путь.

Я установил значения на null (и оставил их пустыми в моих файлах значений) и игнорирую длинный список предупреждений таблицы, что на данный момент в порядке, но я действительно просто хотел бы выполнить одноразовую очистку старых неправильных значений, хранящихся в кубернетес. Пока эта ошибка удаления значения не будет исправлена, существует ли способ вручную изменить значения в существующем развертывании без простоя?

Возникла та же проблема с зондами liveness и readiness .
Удаление ключа по умолчанию из руководства по шаблону не работает.

Пожалуйста, попробуйте # 7743. Похоже, что коммиты, сделанные в Helm 2, не были перенесены в Helm 3, поэтому многие пользователи увидят такое поведение там.

По-прежнему наблюдается эта проблема с helm 2.16.3, но только тогда, когда есть файл requirements.yaml, в котором поддиаграмма указывается как зависимость.

boo - это под-диаграмма, а foo - это родительская диаграмма:

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

Обе диаграммы здесь:

helm_5184.zip

@bacongobbler, есть ли какие-либо намерения

Мы также столкнулись с этой проблемой (аналогичной той, что описана в @vbuciuc), когда не работал "null" для переопределения значений, когда подграфик указан как зависимость в файле requirements.yaml с 3.2.x. Предыдущие версии (3.1.x) работают должным образом.

@bacongobbler @technosophos Я тоже сталкиваюсь с этой проблемой с Helm 3.3.4 , не могли бы вы снова открыть;

Я могу подтвердить, что он работал в 3.1.2 и перестал работать после 3.2.x как упоминает @paleg . На данный момент кажется, что обходной путь @ tuzla0autopilot4, устанавливающий для него значение, не относящееся к карте, например false приведет к предполагаемому поведению, но выдает предупреждения, когда это будет сделано.

@ Chili-Man, я только что пробовал использовать 3.1.3 но, похоже, это не сработало. Он будет применяться с null но я получаю предупреждение, и он ничего не делает. От чего-либо еще ( false , 0 , [] ) он отказывается (например,)

`` coalesce.go: 196: предупреждение: невозможно перезаписать таблицу не таблицей для ресурсов (карта [запросы: карта [cpu: 250m memory: 256Mi]])
Ошибка: ОБНОВЛЕНИЕ НЕ выполнено: значения не соответствуют спецификациям схем в следующих диаграммах:
postgresql:

  • ресурсы: недопустимый тип. Ожидается: объект, задано: логическое
    `` (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` и аналогично все остальное отказывается применяться. Самое неприятное ...

Я все еще испытываю эту проблему в версии 3.4.2.

Проблема все еще присутствует в 3.4.2, но только в определенных ситуациях.
У меня есть диаграмма с несколькими поддиаграммами.
При установке значения по умолчанию в значения поддиаграммы null переопределение не работает. Если вы переместите те же значения в значения родительской диаграммы, все будет работать должным образом.
Это воспроизводимо только с суб-диаграммами. Когда вы помещаете его в единый (плоский) график, все работает нормально.

У меня такая же проблема с 3.4.2 при использовании поддиаграмм (как описано выше @BohdanKalytka ).
В моем случае я хочу перезаписать securityContext при использовании Helm-диаграммы ElasticSearch в кластере OpenShift.
Будет ли эта проблема открыта повторно, или мы должны создать новую?

Повышено # 9136

Была ли эта страница полезной?
0 / 5 - 0 рейтинги