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
@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).
Я пытался:
null
, ~
и {}
в файле values.yaml основной диаграммы или в командной строке. В обоих случаях "шаблон helm" показывает, что исходное значение все еще существует (т.е. я все еще получаю набор httpGet) - и это согласуется с тем, что я вижу для "helm install"Я неправильно понял, и это не вошло в 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
[...]
Что еще пробовал:
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
Обе диаграммы здесь:
@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
Самый полезный комментарий
Мы также столкнулись с этой проблемой (аналогичной той, что описана в @vbuciuc), когда не работал "null" для переопределения значений, когда подграфик указан как зависимость в файле requirements.yaml с 3.2.x. Предыдущие версии (3.1.x) работают должным образом.