Helm: Patch konnte nicht erstellt werden: VersionedObject konnte nicht abgerufen werden

Erstellt am 27. Juni 2018 · 3Kommentare · Quelle: helm/helm

Ausgabe von helm version :

Client: &version.Version{SemVer:"v2.9.1", GitCommit:"20adb27c7c5868466912eebdf6664e7390ebe710", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.9.1", GitCommit:"20adb27c7c5868466912eebdf6664e7390ebe710", GitTreeState:"clean"}

Ausgabe von kubectl version :

Client Version: version.Info{Major:"1", Minor:"10", GitVersion:"v1.10.5", GitCommit:"32ac1c9073b132b8ba18aa830f46b77dcceb0723", GitTreeState:"clean", BuildDate:"2018-06-21T11:46:00Z", GoVersion:"go1.9.3", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"9", GitVersion:"v1.9.5", GitCommit:"f01a2bf98249a4db383560443a59bed0c13575df", GitTreeState:"clean", BuildDate:"2018-03-19T15:50:45Z", GoVersion:"go1.9.3", Compiler:"gc", Platform:"linux/amd64"}

Cloud-Anbieter / Plattform: AWS

Beim Upgrade werden zeitweise Fehler angezeigt. In diesem Fall ein DaemonSet mit apiVersion: apps/v1 bei dem ich spec.template.spec.resources geändert habe:
Helm:

Error: UPGRADE FAILED: failed to create patch: failed to get versionedObject: Object 'apiVersion' is missing in 'unstructured object has no version' && failed to create patch: unable to find api field in struct PodSpec for the json field "resources"

Pinne:

[tiller] 2018/06/27 13:29:42 creating updated release for k8s-efk-filebeat-fix
[storage] 2018/06/27 13:29:42 creating release "k8s-efk-filebeat-fix.v2"
[tiller] 2018/06/27 13:29:42 performing update for k8s-efk-filebeat-fix
[tiller] 2018/06/27 13:29:42 executing 1 pre-upgrade hooks for k8s-efk-filebeat-fix
[tiller] 2018/06/27 13:29:42 hooks complete for pre-upgrade k8s-efk-filebeat-fix
[kube] 2018/06/27 13:29:42 building resources from updated manifest
[kube] 2018/06/27 13:29:42 checking 23 resources for changes
[kube] 2018/06/27 13:29:42 error updating the resource "k8s-efk-filebeat-fix-ci-filebeat":
     failed to create patch: failed to get versionedObject: Object 'apiVersion' is missing in 'unstructured object has no version'
[kube] 2018/06/27 13:29:42 error updating the resource "k8s-efk-filebeat-fix-ci-filebeat":
     failed to create patch: unable to find api field in struct PodSpec for the json field "resources"
[tiller] 2018/06/27 13:29:43 warning: Upgrade "k8s-efk-filebeat-fix" failed: failed to create patch: failed to get versionedObject: Object 'apiVersion' is missing in 'unstructured object has no version' && failed to create patch: unable to find api field in struct PodSpec for the json field "resources"
[storage] 2018/06/27 13:29:43 updating release "k8s-efk-filebeat-fix.v1"
[storage] 2018/06/27 13:29:43 updating release "k8s-efk-filebeat-fix.v2"

Dies scheint ähnlich zu # 3382 zu sein, aber dies ist keine CRD.

questiosupport

Quelle

hobti01

Hilfreichster Kommentar

Die Hauptursache dafür ist das Templating.

# some comment
{{- if .Values.global.rbacEnable -}}
apiVersion: v1
kind: ServiceAccount
...

Ratet mal, was passiert?

# some comment apiVersion: v1
kind: ServiceAccount
...

Helm versucht glücklich, das ungültige Objekt zu verwenden und schlägt fehl:
Error: failed to create patch: failed to get versionedObject: Object 'apiVersion' is missing in 'unstructured object has no version'

Eine Möglichkeit, die Objekte zu validieren, ist kubectl. Ich würde mich über eine Alternative freuen:

TMP_DIR=/tmp/manifests
mkdir -p $TMP_DIR
helm template $HELM_OPTS $HELM_CHART_PATH \
      | csplit -f $TMP_DIR/ --suppress-matched -q -z - '/^---$/' '{*}'
for f in $TMP_DIR/*;  do
  kubectl apply --dry-run -f $f || exit 1
done

hobti01 am 2. Juli 2018

👍3 😄1

Alle 3 Kommentare

Es sieht so aus, als wäre dies ein fehlerhaftes Daemonset (Ressourcen wurden nicht richtig eingerückt). Gibt es eine Möglichkeit, die Kubernetes-Validierung verfügbar zu machen, die dies erfasst?

error: error validating "/tmp/test.yaml": error validating data: ValidationError(DaemonSet.spec.template.spec): unknown field "resources" in io.k8s.api.core.v1.PodSpec; if you choose to ignore these errors, turn validation off with --validate=false

hobti01 am 27. Juni 2018

Hi @ hobti01

Können wir dieses Problem schließen, um eine Funktionsanforderung zum Offenlegen der k8s-Validierung zu öffnen?

jascott1 am 28. Juni 2018