Wir haben es in der Vergangenheit aufgrund der Komplexität vermieden, die Pinne auf Apps / v1 zu aktualisieren, da helm init --upgrade sowohl extensions/v1beta1 als auch apps/v1 Pinnenbereitstellungen in Einklang gebracht hat. Es sieht so aus, als müssten wir, sobald wir Kubernetes 1.16.0 unterstützen, diesen Fall in Zukunft behandeln und auf die neuere API migrieren.

Hier ist eine kurzfristige Problemumgehung:

helm init --output yaml | sed 's<strong i="6">@apiVersion</strong>: extensions/v1beta1<strong i="7">@apiVersion</strong>: apps/v1@' | kubectl apply -f -

Eigentlich ist es nicht gut genug. Ich erhalte immer noch eine Fehlermeldung:

error validating data: ValidationError(Deployment.spec): missing required field "selector" in io.k8s.api.apps.v1.DeploymentSpec

Dies kann gepatcht werden mit:

/usr/local/bin/kubectl patch --local -oyaml -f - -p '{"spec":{"selector": {"app":"helm","name":"tiller"}}}'

Nett! Möglicherweise können Sie mit der Flagge --override den gleichen Effekt erzielen wie mit verrückten Sed-Hacks :)

Nett! Möglicherweise können Sie mit der Flagge --override den gleichen Effekt erzielen wie mit verrückten Sed-Hacks :)

Ja, aber seine verrückten Sed-Hacks kann ich kopieren und einfügen, während dieses helm init --override "apiVersion"="apps/v1" einfach nicht funktioniert. Ok, der sed hack funktioniert auch nicht.

Die aktuelle Problemumgehung scheint ungefähr so ​​zu sein:

helm init --output yaml> tiller.yaml
und aktualisieren Sie die tiller.yaml:

• Wechseln Sie zu Apps / v1
• Fügen Sie das Auswahlfeld hinzu

---
apiVersion: apps/v1
kind: Deployment
metadata:
  creationTimestamp: null
  labels:
    app: helm
    name: tiller
  name: tiller-deploy
  namespace: kube-system
spec:
  replicas: 1
  strategy: {}
  selector:
    matchLabels:
      app: helm
      name: tiller
....

Das folgende sed funktioniert für mich:

helm init --service-account tiller --output yaml | sed 's<strong i="6">@apiVersion</strong>: extensions/v1beta1<strong i="7">@apiVersion</strong>: apps/v1@' | sed 's@  replicas: 1@  replicas: 1\n  selector: {"matchLabels": {"app": "helm", "name": "tiller"}}@' | kubectl apply -f -

Das Problem mit der @attymo- Lösung (unter Verwendung des kubectl-Patches --local) ist, dass sie anscheinend nicht funktioniert, wenn ihre Eingabe mehrere Ressourcen enthält (hier eine Bereitstellung und ein Dienst).

Kubernetes 1.16.0 wurde gestern veröffentlicht: 18.09.2008.
Bei dieser neuesten Kubernetes-Version ist der Helm kaputt, es sei denn, die oben beschriebene Lösung wird verwendet.

Wann wird dieses Problem behoben und wann wird Helm 2.15.0 veröffentlicht?

Wenn du ein Sed weniger verwenden willst :)
helm init --service-account tiller --override spec.selector.matchLabels.'name'='tiller',spec.selector.matchLabels.'app'='helm' --output yaml | sed 's<strong i="6">@apiVersion</strong>: extensions/v1beta1<strong i="7">@apiVersion</strong>: apps/v1@' | kubectl apply -f -

Vielen Dank!

Heute bin ich auf das gleiche Problem gestoßen, ich habe das Label selbst geändert. Ich ändere die Bezeichnung in apps/v1 und füge selector Teil hinzu. Ab sofort funktioniert es hervorragend. Unten ist meine Yaml-Datei:

apiVersion: apps/v1
kind: Deployment
metadata:
  creationTimestamp: null
  labels:
    app: helm
    name: tiller
  name: tiller-deploy
  namespace: kube-system
spec:
  replicas: 1
  strategy: {}
  selector:
    matchLabels:
      app: helm
      name: tiller
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: helm
        name: tiller
    spec:
      automountServiceAccountToken: true
      containers:
      - env:
        - name: TILLER_NAMESPACE
          value: kube-system
        - name: TILLER_HISTORY_MAX
          value: "0"
        image: gcr.io/kubernetes-helm/tiller:v2.14.3
        imagePullPolicy: IfNotPresent
        livenessProbe:
          httpGet:
            path: /liveness
            port: 44135
          initialDelaySeconds: 1
          timeoutSeconds: 1
        name: tiller
        ports:
        - containerPort: 44134
          name: tiller
        - containerPort: 44135
          name: http
        readinessProbe:
          httpGet:
            path: /readiness
            port: 44135
          initialDelaySeconds: 1
          timeoutSeconds: 1
        resources: {}
      serviceAccountName: tiller
status: {}

@jbrette du bist mein Held! Ich hatte Probleme mit der Strophe selector .

Heute bin ich auf das gleiche Problem gestoßen, ich habe das Label selbst geändert. Ich ändere die Bezeichnung in apps/v1 und füge selector Teil hinzu. Ab sofort funktioniert es hervorragend. Unten ist meine Yaml-Datei:

apiVersion: apps/v1
kind: Deployment
metadata:
  creationTimestamp: null
  labels:
    app: helm
    name: tiller
  name: tiller-deploy
  namespace: kube-system
spec:
  replicas: 1
  strategy: {}
  selector:
    matchLabels:
      app: helm
      name: tiller
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: helm
        name: tiller
    spec:
      automountServiceAccountToken: true
      containers:
      - env:
        - name: TILLER_NAMESPACE
          value: kube-system
        - name: TILLER_HISTORY_MAX
          value: "0"
        image: gcr.io/kubernetes-helm/tiller:v2.14.3
        imagePullPolicy: IfNotPresent
        livenessProbe:
          httpGet:
            path: /liveness
            port: 44135
          initialDelaySeconds: 1
          timeoutSeconds: 1
        name: tiller
        ports:
        - containerPort: 44134
          name: tiller
        - containerPort: 44135
          name: http
        readinessProbe:
          httpGet:
            path: /readiness
            port: 44135
          initialDelaySeconds: 1
          timeoutSeconds: 1
        resources: {}
      serviceAccountName: tiller
status: {}

wie man sich ändert Kannst du mehr Details beschreiben?

Heute bin ich auf das gleiche Problem gestoßen, ich habe das Label selbst geändert. Ich ändere die Bezeichnung in apps/v1 und füge selector Teil hinzu. Ab sofort funktioniert es hervorragend. Unten ist meine Yaml-Datei:

apiVersion: apps/v1
kind: Deployment
metadata:
  creationTimestamp: null
  labels:
    app: helm
    name: tiller
  name: tiller-deploy
  namespace: kube-system
spec:
  replicas: 1
  strategy: {}
  selector:
    matchLabels:
      app: helm
      name: tiller
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: helm
        name: tiller
    spec:
      automountServiceAccountToken: true
      containers:
      - env:
        - name: TILLER_NAMESPACE
          value: kube-system
        - name: TILLER_HISTORY_MAX
          value: "0"
        image: gcr.io/kubernetes-helm/tiller:v2.14.3
        imagePullPolicy: IfNotPresent
        livenessProbe:
          httpGet:
            path: /liveness
            port: 44135
          initialDelaySeconds: 1
          timeoutSeconds: 1
        name: tiller
        ports:
        - containerPort: 44134
          name: tiller
        - containerPort: 44135
          name: http
        readinessProbe:
          httpGet:
            path: /readiness
            port: 44135
          initialDelaySeconds: 1
          timeoutSeconds: 1
        resources: {}
      serviceAccountName: tiller
status: {}

@ gm12367 wie zu ändern und können Sie weitere Details beschreiben?

Heute bin ich auf das gleiche Problem gestoßen, ich habe das Label selbst geändert. Ich ändere die Bezeichnung in apps/v1 und füge selector Teil hinzu. Ab sofort funktioniert es hervorragend. Unten ist meine Yaml-Datei:

apiVersion: apps/v1
kind: Deployment
metadata:
  creationTimestamp: null
  labels:
    app: helm
    name: tiller
  name: tiller-deploy
  namespace: kube-system
spec:
  replicas: 1
  strategy: {}
  selector:
    matchLabels:
      app: helm
      name: tiller
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: helm
        name: tiller
    spec:
      automountServiceAccountToken: true
      containers:
      - env:
        - name: TILLER_NAMESPACE
          value: kube-system
        - name: TILLER_HISTORY_MAX
          value: "0"
        image: gcr.io/kubernetes-helm/tiller:v2.14.3
        imagePullPolicy: IfNotPresent
        livenessProbe:
          httpGet:
            path: /liveness
            port: 44135
          initialDelaySeconds: 1
          timeoutSeconds: 1
        name: tiller
        ports:
        - containerPort: 44134
          name: tiller
        - containerPort: 44135
          name: http
        readinessProbe:
          httpGet:
            path: /readiness
            port: 44135
          initialDelaySeconds: 1
          timeoutSeconds: 1
        resources: {}
      serviceAccountName: tiller
status: {}

@ gm12367 wie zu ändern und können Sie weitere Details beschreiben?

Sie können beispielsweise helm init --service-account tiller --tiller-namespace kube-system --debug , um Manifeste im YAML-Format zu drucken. Die Option --debug erledigt dies

@ gm12367 Ja, ich kann den Druck sehen, aber nur ausgeben. Welchen Befehl kann ich also ändern?

@ gm12367 Ich möchte Apps / v1 ändern und einen Auswahlteil hinzufügen

@ puww1010 Ich habe gerade die Ausgabe in eine Datei umgeleitet und dann VIM verwendet, um sie zu ändern. Unten Befehle als Referenz.

# helm init --service-account tiller --tiller-namespace kube-system --debug >> helm-init.yaml
# vim helm-init.yaml
# kubectl apply -f helm-init.yaml

Wenn Ihre Go-Umgebung eingerichtet ist und Sie nicht warten können, bis der folgende PR, der dieses Problem behebt [Helm init kompatibel mit Kubernetes 1.16] # 6462, zusammengeführt wird, können Sie immer Folgendes tun:

Bauen

mkdir p ${GOPATH}/src/k8s.io
cd ${GOPATH}/src/k8s.io 
git clone -b kube16 https://github.com/keleustes/helm.git
cd helm
make bootstrap build

Prüfung:

kubectl version

Client Version: version.Info{Major:"1", Minor:"16", GitVersion:"v1.16.0", GitCommit:"2bd9643cee5b3b3a5ecbd3af49d09018f0773c77", GitTreeState:"clean", BuildDate:"2019-09-18T14:36:53Z", GoVersion:"go1.12.9", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"16", GitVersion:"v1.16.0", GitCommit:"2bd9643cee5b3b3a5ecbd3af49d09018f0773c77", GitTreeState:"clean", BuildDate:"2019-09-18T14:27:17Z", GoVersion:"go1.12.9", Compiler:"gc", Platform:"linux/amd64"}

/bin/helm init --wait --tiller-image gcr.io/kubernetes-helm/tiller:v2.14.3
Creating /home/xxx/.helm
Creating /home/xxx/.helm/repository
Creating /home/xxx/.helm/repository/cache
Creating /home/xxx/.helm/repository/local
Creating /home/xxx/.helm/plugins
Creating /home/xxx/.helm/starters
Creating /home/xxx/.helm/cache/archive
Creating /home/xxx/.helm/repository/repositories.yaml
Adding stable repo with URL: https://kubernetes-charts.storage.googleapis.com
Adding local repo with URL: http://127.0.0.1:8879/charts
$HELM_HOME has been configured at /home/xxx/.helm.

Tiller (the Helm server-side component) has been installed into your Kubernetes Cluster.

Please note: by default, Tiller is deployed with an insecure 'allow unauthenticated users' policy.
To prevent this, run `helm init` with the --tiller-tls-verify flag.
For more information on securing your installation see: https://docs.helm.sh/using_helm/#securing-your-helm-installation

`` `Bash
kubectl get deploy.apps / tiller-deploy -n kube-system -o yaml

```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  annotations:
    deployment.kubernetes.io/revision: "1"
  creationTimestamp: "2019-09-22T01:01:11Z"
  generation: 1
  labels:
    app: helm
    name: tiller
  name: tiller-deploy
  namespace: kube-system
  resourceVersion: "553"
  selfLink: /apis/apps/v1/namespaces/kube-system/deployments/tiller-deploy
  uid: 124001ca-6f31-417e-950b-2452ce70f522
spec:
  progressDeadlineSeconds: 600
  replicas: 1
  revisionHistoryLimit: 10
  selector:
    matchLabels:
      app: helm
      name: tiller
  strategy:
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 25%
    type: RollingUpdate
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: helm
        name: tiller
    spec:
      automountServiceAccountToken: true
      containers:
      - env:
        - name: TILLER_NAMESPACE
          value: kube-system
        - name: TILLER_HISTORY_MAX
          value: "0"
        image: gcr.io/kubernetes-helm/tiller:v2.14.3
        imagePullPolicy: IfNotPresent
        livenessProbe:
          failureThreshold: 3
          httpGet:
            path: /liveness
            port: 44135
            scheme: HTTP
          initialDelaySeconds: 1
          periodSeconds: 10
          successThreshold: 1
          timeoutSeconds: 1
        name: tiller
        ports:
        - containerPort: 44134
          name: tiller
          protocol: TCP
        - containerPort: 44135
          name: http
          protocol: TCP
        readinessProbe:
          failureThreshold: 3
          httpGet:
            path: /readiness
            port: 44135
            scheme: HTTP
          initialDelaySeconds: 1
          periodSeconds: 10
          successThreshold: 1
          timeoutSeconds: 1
        resources: {}
        terminationMessagePath: /dev/termination-log
        terminationMessagePolicy: File
      dnsPolicy: ClusterFirst
      restartPolicy: Always
      schedulerName: default-scheduler
      securityContext: {}
      terminationGracePeriodSeconds: 30
status:
  availableReplicas: 1
  conditions:
  - lastTransitionTime: "2019-09-22T01:01:23Z"
    lastUpdateTime: "2019-09-22T01:01:23Z"
    message: Deployment has minimum availability.
    reason: MinimumReplicasAvailable
    status: "True"
    type: Available
  - lastTransitionTime: "2019-09-22T01:01:11Z"
    lastUpdateTime: "2019-09-22T01:01:23Z"
    message: ReplicaSet "tiller-deploy-568db6b69f" has successfully progressed.
    reason: NewReplicaSetAvailable
    status: "True"
    type: Progressing
  observedGeneration: 1
  readyReplicas: 1
  replicas: 1
  updatedReplicas: 1

@jbrette Immer noch das gleiche Problem, nachdem Sie Ihren Anweisungen

@jbrette Immer noch das gleiche Problem, nachdem Sie Ihren Anweisungen

Sieht so aus, als hätten Sie "helm" anstelle von "./bin/helm"...." eingegeben. Sie verwenden also die alte Version der Binärdatei.

Nach erfolgreicher Initialisierung können Sie ein Diagrammpaket erst dann aus dem Repository installieren, wenn Sie auch die Erweiterungen / v1beta1 darin ersetzen.
Hier erfahren Sie, wie Sie ein Diagramm aus dem Repository für k8s v1.16.0 anpassen
Das Beispiel basiert auf einem Prometheus-Diagramm.

git clone https://github.com/helm/charts
cd charts/stable

Ersetzen Sie die Erweiterungen / v1beta1 durch die Richtlinie / v1beta1 PodSecurityPolicy:

sed -i 's<strong i="11">@apiVersion</strong>: extensions/v1beta1<strong i="12">@apiVersion</strong>: policy/v1beta1@' `find . -iregex ".*yaml\|.*yml" -exec awk '/kind:\s+PodSecurityPolicy/ {print FILENAME}' {} +`

NetworkPolicy apiVersion wird von _helpers.tpl für die Diagramme, in denen es verwendet wird, gut verarbeitet.

Ersetzen Sie die Erweiterungen / v1beta1 durch Apps / v1 in Deployment, StatefulSet, ReplicaSet, DaemonSet

sed -i 's<strong i="17">@apiVersion</strong>: extensions/v1beta1<strong i="18">@apiVersion</strong>: apps/v1@' `find . -iregex ".*yaml\|.*yml" -exec awk '/kind:\s+(Deployment|StatefulSet|ReplicaSet|DaemonSet)/ {print FILENAME}' {} +`
sed -i 's<strong i="19">@apiVersion</strong>: apps/v1beta2<strong i="20">@apiVersion</strong>: apps/v1@' `find . -iregex ".*yaml\|.*yml" -exec awk '/kind:\s+(Deployment|StatefulSet|ReplicaSet|DaemonSet)/ {print FILENAME}' {} +`

Erstellen Sie ein neues Paket:

helm package ./prometheus
Successfully packaged chart and saved it to: /home/vagrant/charts/stable/prometheus-9.1.1.tgz

Es installieren:
helm install /home/vagrant/charts/stable/prometheus-9.1.1.tgz

Basierend auf https://kubernetes.io/blog/2019/07/18/api-deprecations-in-1-16/

PS Für einige Diagramme mit Abhängigkeiten müssen Sie möglicherweise helm dependency update und abhängige tgz gegebenenfalls durch gepatchte ersetzen.

Beim Ausführen von helm init --history-max 200 der gleiche Fehler

Ausgabe

$HELM_HOME has been configured at /Users/neil/.helm.
Error: error installing: the server could not find the requested resource

$ helm version
Client: &version.Version{SemVer:"v2.14.3", GitCommit:"0e7f3b6637f7af8fcfddb3d2941fcc7cbebb0085", GitTreeState:"clean"}
Error: could not find tiller

Dieser Zweig funktioniert unter https://github.com/keleustes/helm/tree/kube16. Sie können den Zweig selbst erstellen. Ich habe die Binärdatei auch hier hochgeladen: https://s3-us-west-2.amazonaws.com/bin.cryptexlabs.com/github.com/keleustes/helm/kube16/darwin/helm. Eine Einschränkung ist, dass Sie das kanarische Image-Flag helm init --canary-image da der Build unveröffentlicht ist

Sie sollten das Kanarienvogelbild nicht benötigen, damit dies funktioniert. Ich würde vorschlagen, helm init --tiller-image gcr.io/kubernetes-helm/tiller:v2.14.3 als @jbrette zu verwenden , wenn Sie helm init --tiller-image gcr.io/kubernetes-helm/tiller:v2.14.3 6462 ausprobieren möchten.

Ich würde Benutzern empfehlen, zuerst eine der zuvor bereitgestellten Problemumgehungen auszuprobieren, bevor Sie eine PR ausprobieren. Auf diese Weise können sie weiterhin Helm 2.14.3 anstelle eines benutzerdefinierten Entwicklungszweigs verwenden, der noch geprüft wird.

Wenn ich den Befehl ausführe, wird es bereitgestellt, aber danach können Sie es in Pods sehen und Fehler vom Server (NotFound) sagen: Pods "Tiller-Deployment" nicht gefunden

helm init --service-account tiller --override spec.selector.matchLabels.'name'='tiller',spec.selector.matchLabels.'app'='helm' --output yaml | sed 's<strong i="7">@apiVersion</strong>: extensions/v1beta1<strong i="8">@apiVersion</strong>: apps/v1@' | kubectl apply -f -

deploy.apps / tiller-deploy erstellt
Service / Pinne-Bereitstellung erstellt

Aber wenn ich kubectl mache, bekomme ich Pods - alle Namespaces können die Pods nicht sehen
NAMESPACE NAME BEREIT STATUS RESTARTS ALTER
kube-system coredns-5644d7b6d9-559hw 1/1 Running 0 23h
kube-system coredns-5644d7b6d9-xcmjd 1/1 Running 0 23h
kube-system etcd-fmp 1/1 Läuft 0 24h
kube-system kube-apiserver-fmp 1/1 Laufen 0 24h
kube-system kube-controller-manager-fmp 1/1 Läuft 1 24h
kube-system kube-flanell-ds-amd64-ffx2g 1/1 Laufen 0 23h
kube-system kube-proxy-lfvrz 1/1 Laufen 0 24h
kube-system kube-scheduler-fmp 1/1 Läuft 0 24h

kubectl get all --all-namespaces | Grep Pinne
kube-system service / tiller-deploy ClusterIP xxx44134 / TCP 2m52s
kube-system deploy.apps / tiller-deploy 0/1 0 0 2m54s
kube-system replicaset.apps / tiller-deploy-77855d9dcf 1 0 0 2m54s

@ DanielIvaylov Ich denke, Sie haben nicht das Pinnen-Service-Konto. Bitte erstellen Sie es, und dann wird durch die Bereitstellung auch der Pinnen-Pod erstellt.

Vielen Dank!

@ DanielIvaylov Ich denke, Sie haben nicht das Pinnen-Service-Konto. Bitte erstellen Sie es, und dann wird durch die Bereitstellung auch der Pinnen-Pod erstellt.

Vielen Dank!

Sorry, ich bin neu, ich habe gelernt, dass dies damit beginnen wird. Wie starte ich das Pinnen-Service-Konto?

@ DanielIvaylov

kubectl --namespace kube-system create sa tiller
kubectl create clusterrolebinding tiller --clusterrole cluster-admin --serviceaccount=kube-system:tiller

Unter dem Flag zum API-Server (/etc/kubernetes/manifests/kube-apiserver.yaml) hinzugefügt, der diese veralteten APIs vorübergehend wieder aktiviert hat.

--runtime-config = apps / v1beta1 = true, apps / v1beta2 = true, Erweiterungen / v1beta1 / daemonsets = true, Erweiterungen / v1beta1 / deployments = true, Erweiterungen / v1beta1 / replicasets = true, Erweiterungen / v1beta1 / networkpolicies = true, extensions / v1beta1 / podsecuritypolicies = true

Dies reparierte das Ruder v2

Für Windows-Benutzer konnten wir die Pinne über Powershell wie folgt installieren / aktualisieren:

$(helm init --output yaml) -replace "extensions/v1beta1","apps/v1"

Hier ist eine kurzfristige Problemumgehung:

helm init --output yaml | sed 's<strong i="7">@apiVersion</strong>: extensions/v1beta1<strong i="8">@apiVersion</strong>: apps/v1@' | kubectl apply -f -

Eigentlich ist es nicht gut genug. Ich erhalte immer noch eine Fehlermeldung:

error validating data: ValidationError(Deployment.spec): missing required field "selector" in io.k8s.api.apps.v1.DeploymentSpec

Dies kann gepatcht werden mit:

/usr/local/bin/kubectl patch --local -oyaml -f - -p '{"spec":{"selector": {"app":"helm","name":"tiller"}}}'

für mich hängt der kubectl patch
Keine Nachrichten in der Datei / var / log / syslog

Dienstkonten existieren bereits

kubeflow @ masternode : ~ $ kubectl --namespace kube-system erstellt eine Pinne
Fehler vom Server (AlreadyExists): Servicekonten "Pinne" sind bereits vorhanden
kubeflow @ masternode : ~ $ kubectl create clusterrolebinding tiller --clusterrole cluster-admin --serviceaccount = kube- system: tiller
Fehler vom Server (AlreadyExists): clusterrolebindings.rbac.authorization.k8s.io "Pinne" existiert bereits

Könnten Sie mir bitte einen Ratschlag geben

Ausführen der folgenden

export PATH = $ PATH: / usr / local / bin
welches Ruder
welche Pinne
Helm installieren \.
--name nfs-client-provisor \
--set nfs.server = 10.0.0.4 \
--set nfs.path = / nfsroot \
--set storageClass.name = nfs \
--set storageClass.defaultClass = true \
Stable / NFS-Client-Provisioner

kehrt mit zurück

/ usr / local / bin / helm
/ usr / local / bin / pinne
Fehler: Pinne konnte nicht gefunden werden

Ich freue mich über jede Hilfe, da dies jetzt ein Show-Stopper ist

@cyrilthank Der Pinnenbereitstellung ausgeführt wird. Führen Sie diesen Befehl aus, um die Pinne zu installieren:
helm init --service-account tiller --override spec.selector.matchLabels.'name'='tiller',spec.selector.matchLabels.'app'='helm' --output yaml | sed 's<strong i="7">@apiVersion</strong>: extensions/v1beta1<strong i="8">@apiVersion</strong>: apps/v1@' | kubectl apply -f -

helm version -s sollte die Serverversion (Pinne) zurückgeben, wenn sie ordnungsgemäß funktioniert

Danke mein Herr.
Sie haben uns dabei geholfen, mit kubeflow mit dem nächsten Schritt fortzufahren

Ok, jetzt denke ich, ich habe dieses Problem
https://github.com/kubeflow/kubeflow/issues/4184
zurück als Blocker

Schätzen Sie es sehr, wenn Sie uns mit Ratschlägen helfen können, wie ich unter https://github.com/kubeflow/kubeflow/issues/4184 Hilfe bekommen kann

@cyrilthank Probieren Sie die oben angegebenen Schritte aus: https://github.com/helm/helm/issues/6374#issuecomment -533853888
Sie müssen die veralteten API-Versionen durch die neuen ersetzen

kubeflow_workaround_and_error_traces.txt

Vielen Dank, Sir, für Ihre geduldigen Antworten, insbesondere, um dieses Problem offen zu halten

Tut mir leid, aber es sieht so aus, als würde ich in den Umgehungsschritten etwas falsch machen

Schätzen Sie, ob Sie die Schritte in den beigefügten Spuren überprüfen und mich beraten können, was ich falsch mache

@cyrilthank Sie müssen nur die Befehle sed für Ihre kubeflow yamls ausführen, um die alte API-Erweiterung durch die neue zu ersetzen (Prometheus muss überhaupt nicht bereitgestellt werden 😆). Entschuldigung, wenn ich mich nicht gut genug ausgedrückt habe.
Das Update ersetzt im Grunde extensions/v1beta1 durch apps/v1 in Ihren kubeflow dpl yamls

Ah, also habe ich eine dumme Kopie gemacht :(

mein KFAPP = / nfsroot / kf-poc

Ich scheine immer noch ein paar Nachrichten und den letzten Fehler zu bekommen

Kannst du mir bitte helfen, da ich jetzt auf dich angewiesen bin, um mit dem nächsten Schritt auf kubeflow fortzufahren?

kubeflow_workaround_sed_and_error_traces.txt

@cyrilthank Sie müssen nur die sed -Befehle für Ihre kubeflow yamls ausführen, um die alte API-Erweiterung durch die neue zu ersetzen (Prometheus muss überhaupt nicht lachend bereitgestellt werden). Entschuldigung, wenn ich mich nicht gut genug ausgedrückt habe.
Das Update ersetzt im Grunde extensions/v1beta1 durch apps/v1 in Ihren kubeflow dpl yamls

apps/v1beta2 auch mit apps/v1

https://kubernetes.io/blog/2019/07/18/api-deprecations-in-1-16/

Vielen Dank @uniuuu für Ihre Hilfe
Können Sie bitte beraten , wo / wie die yaml Dateien referenziert zu erhalten , in https://github.com/helm/helm/files/3662328/kubeflow_workaround_sed_and_error_traces.txt

https://github.com/helm/helm/issues/6374#issuecomment -533840097
https://github.com/helm/helm/issues/6374#issuecomment -533185074

Anfordern, da nach dem Vornehmen der sed-Änderungen immer noch die Fehler aufgetreten sind, auf die in verwiesen wird

Kannst du bitte mitteilen, ob der Schritt

kubectl convert -f--output-version/.

muss für jeden ausgeführt werdenDies ist jede Yaml-Datei am KFAPP-Speicherort, einschließlich .kache

Wenn Sie die oben erwähnte Problemumgehung angewendet haben, wenn Sie mit helm init , und dennoch die folgende Fehlermeldung erhalten, wenn Sie Dinge wie helm version ausprobieren, liegt dies daran, dass helm deployment kann nicht gefunden werden.

Error: could not find tiller

Sie müssen kubectl get events --all-namespaces | grep -i tiller ausführen, um zu wissen, warum es nicht fertig ist.

Zum Beispiel ist mein Problem einfach wie folgt, weil ich nicht serviceaccount "tiller" mit microk8s brauche.

microk8s.kubectl get events --all-namespaces | grep -i tiller
kube-system    23m         Warning   FailedCreate                   replicaset/tiller-deploy-77855d9dcf            Error creating: pods "tiller-deploy-77855d9dcf-" is forbidden: error looking up service account kube-system/tiller: serviceaccount "tiller" not found

Also habe ich die Arbeit ohne das Dienstkonto erledigt

- helm init --service-account tiller --override spec.selector.matchLabels.'name'='tiller',spec.selector.matchLabels.'app'='helm' --output yaml | sed 's<strong i="20">@apiVersion</strong>: extensions/v1beta1<strong i="21">@apiVersion</strong>: apps/v1@' | kubectl apply -f -
+ helm init spec.selector.matchLabels.'name'='tiller',spec.selector.matchLabels.'app'='helm' --output yaml | sed 's<strong i="22">@apiVersion</strong>: extensions/v1beta1<strong i="23">@apiVersion</strong>: apps/v1@' | kubectl apply -f -

@cyrilthank Ich habe Ihren Kommentar entfernt, da er für die Diskussion hier nicht relevant ist. Bitte fahren Sie mit der Weiterverfolgung in kubeflow / kubeflow # 4184 fort. Vielen Dank!

helm init spec.selector.matchLabels.'name'='tiller',spec.selector.matchLabels.'app'='helm' --output yaml | sed 's<strong i="6">@apiVersion</strong>: extensions/v1beta1<strong i="7">@apiVersion</strong>: apps/v1@' | kubectl apply -f -

Leichte Korrektur

helm init --override spec.selector.matchLabels.'name'='tiller',spec.selector.matchLabels.'app'='helm' --output yaml | sed 's<strong i="11">@apiVersion</strong>: extensions/v1beta1<strong i="12">@apiVersion</strong>: apps/v1@' | kubectl apply -f -

+1

@ puww1010 Ich habe gerade die Ausgabe in eine Datei umgeleitet und dann VIM verwendet, um sie zu ändern. Unten Befehle als Referenz.

# helm init --service-account tiller --tiller-namespace kube-system --debug >> helm-init.yaml
# vim helm-init.yaml
# kubectl apply -f helm-init.yaml

Ich habe es versucht. Nach dem Bearbeiten der Datei in VIM verwende ich den Befehl kubectl apply , aber es scheint nichts zu tun. Wenn ich helm init --service-account tiller --tiller-namespace kube-system --debug >> helm-init.yaml erneut oder helm init --output yaml ausführe, wurden die Änderungen nicht übernommen. Hat das noch jemand erlebt?

Wenn du ein Sed weniger verwenden willst :)
helm init --service-account tiller --override spec.selector.matchLabels.'name'='tiller',spec.selector.matchLabels.'app'='helm' --output yaml | sed 's<strong i="7">@apiVersion</strong>: extensions/v1beta1<strong i="8">@apiVersion</strong>: apps/v1@' | kubectl apply -f -

Vielen Dank!

Ich habe gerade unsere k8s aufgerüstet und bin auf dieses Problem gestoßen. Ich habe die obige Lösung verwendet. Es erstellt eine Bereitstellung, aber das Replikatset schlägt fehl und dies ist das, was ich von kubectl describe -n kube-system replicasets.apps tiller-deploy-77855d9dcf bekomme:

Events:
  Type     Reason        Age                 From                   Message
  ----     ------        ----                ----                   -------
  Warning  FailedCreate  41s (x14 over 82s)  replicaset-controller  Error creating: pods "tiller-deploy-77855d9dcf-" is forbidden: error looking up service account kube-system/tiller: serviceaccount "tiller" not found

Wo finde ich eine Yaml-Datei, um dieses Dienstkonto zu erstellen?

@ DanielIvaylov

kubectl --namespace kube-system create sa tiller
kubectl create clusterrolebinding tiller --clusterrole cluster-admin --serviceaccount=kube-system:tiller

Das hat mein Problem gelöst!

6462 wurde zusammengeführt und wird in der nächsten Version (2.15.0) verfügbar sein. Im Moment können Sie die oben angegebenen Problemumgehungen oder die kanarische Version verwenden .

Vielen Dank an alle!

Das kanarische Bild erzeugt immer noch den gleichen Fehler, es sei denn, es hat diese Zusammenführung noch nicht.

@ puww1010 Ich habe gerade die Ausgabe in eine Datei umgeleitet und dann VIM verwendet, um sie zu ändern. Unten Befehle als Referenz.

# helm init --service-account tiller --tiller-namespace kube-system --debug >> helm-init.yaml
# vim helm-init.yaml
# kubectl apply -f helm-init.yaml

Ich habe es versucht. Nach dem Bearbeiten der Datei in VIM verwende ich den Befehl kubectl apply , aber es scheint nichts zu tun. Wenn ich helm init --service-account tiller --tiller-namespace kube-system --debug >> helm-init.yaml erneut oder helm init --output yaml ausführe, wurden die Änderungen nicht übernommen. Hat das noch jemand erlebt?

Ja, das passiert auch für mich.

Möglicherweise müssen Sie den Bildspeicherort in gcr.azk8s.cn/kubernetes-helm/tiller:v2.14.3 ändern. Der Speicherort gcr.io scheint blockiert zu sein.

Möglicherweise müssen Sie den Speicherort des Bildes in gcr.azk8s.cn/kubernetes-helm/

Obwohl es sich um ein vollständig gültiges Problem handelt, ist dieses Problem leicht orthogonal zu dem in dieser Ausgabe enthaltenen Problem. In China ist gcr.io leider blockiert. Weitere Informationen finden Sie unter https://github.com/helm/charts/issues/14607 .

Wir konnten dieses Problem beheben, indem wir die kubernetes-Version auf 1.15.4 zurückgesetzt haben

Vielen Dank an @UmamaheshMaxwell für das Teilen.

Können Sie bitte die Schritte mitteilen, die Sie zum Zurücksetzen der Kubernetes-Version verwendet haben?

@cyrilthank, wenn es Minikube ist, minikube config set kubernetes-version v1.15.4

Vielen Dank an @UmamaheshMaxwell für das Teilen.

Können Sie bitte die Schritte mitteilen, die Sie zum Zurücksetzen der Kubernetes-Version verwendet haben?

@cyrilthank wir haben unsere eigenen VMs (Ubuntu 18+) verwendet, unten sind die Setps für die Installation der k8s-Version 1.15.4

1. kubeadm zurücksetzen
2. sudo apt-get install kubelet = 1.15.4-00 kubectl = 1.15.4-00 kubeadm = 1.15.4-00
3. sudo kubeadm init --pod-network-cidr = 10.244.10.0 / 16 --apiserver-werbeadresse = xxxx --apiserver-cert-extra-sans = xxxx --kubernetes-version "1.15.4"

--pod-network-cidr=10.244.10.0/16 - Flanell
--apiserver-advertise-address=x.x.x.x - private IP Ihrer VM (Master)
--apiserver-cert-extra-sans=x.x.x.x - Öffentliche IP Ihrer VM (Master) (Dies ist erforderlich, wenn Sie versuchen, von Ihrem lokalen Computer aus auf Ihren Master zuzugreifen.

Hinweis: Folgen Sie dem folgenden Link, um eine kubeconfig-Datei für einen selbst gehosteten Kubernetes-Cluster einzurichten (http://docs.shippable.com/deploy/tutorial/create-kubeconfig-for-self-hosted-kubernetes-cluster/).

Lassen Sie mich wissen, wenn Sie noch Fragen haben.

@cyrilthank Wenn es Minikube ist, setzt Minikube Config Kubernetes-Version v1.15.4

Danke @MrSimonEmms meins ist nicht mini Ich denke, ich muss mit @UmamaheshMaxwells Schritten gehen

Vielen Dank an @UmamaheshMaxwell für das Teilen.
Können Sie bitte die Schritte mitteilen, die Sie zum Zurücksetzen der Kubernetes-Version verwendet haben?

@cyrilthank wir haben unsere eigenen VMs (Ubuntu 18+) verwendet, unten sind die Setps für die Installation von k8s Version 1.15.4

kubeadm zurücksetzen
sudo apt-get install kubelet = 1.15.4-00 kubectl = 1.15.4-00 kubeadm = 1.15.4-00
sudo kubeadm init --pod-network-cidr = 10.244.10.0 / 16 --apiserver-werbeadresse = xxxx --apiserver-cert-extra-sans = xxxx --kubernetes-version "1.15.4"

--pod-network-cidr = 10.244.10.0 / 16 - Flanell
--apiserver-Advertise-Address = xxxx - private IP Ihrer VM (Master)
--apiserver-cert-extra-sans = xxxx - Öffentliche IP Ihrer VM (Master) (Dies ist erforderlich, wenn Sie versuchen, von Ihrem lokalen Computer aus auf Ihren Master zuzugreifen.
Hinweis: Folgen Sie dem folgenden Link, um eine kubeconfig-Datei für einen selbst gehosteten Kubernetes-Cluster einzurichten (http://docs.shippable.com/deploy/tutorial/create-kubeconfig-for-self-hosted-kubernetes-cluster/).
Lassen Sie mich wissen, wenn Sie noch Fragen haben.

Vielen Dank an @UmamaheshMaxwell für Ihre geduldige Antwort

Ich habe ein vorhandenes Kubernetes 1.16-Setup. Können Sie bitte bestätigen, ob ich versuchen kann, diese Schritte auszuführen?

Vielen Dank an @UmamaheshMaxwell für das Teilen.
Können Sie bitte die Schritte mitteilen, die Sie zum Zurücksetzen der Kubernetes-Version verwendet haben?
@cyrilthank wir haben unsere eigenen VMs (Ubuntu 18+) verwendet, unten sind die Setps für die Installation von k8s Version 1.15.4
kubeadm zurücksetzen
sudo apt-get install kubelet = 1.15.4-00 kubectl = 1.15.4-00 kubeadm = 1.15.4-00
sudo kubeadm init --pod-network-cidr = 10.244.10.0 / 16 --apiserver-werbeadresse = xxxx --apiserver-cert-extra-sans = xxxx --kubernetes-version "1.15.4"
--pod-network-cidr = 10.244.10.0 / 16 - Flanell
--apiserver-Advertise-Address = xxxx - private IP Ihrer VM (Master)
--apiserver-cert-extra-sans = xxxx - Öffentliche IP Ihrer VM (Master) (Dies ist erforderlich, wenn Sie versuchen, von Ihrem lokalen Computer aus auf Ihren Master zuzugreifen.
Hinweis: Folgen Sie dem folgenden Link, um eine kubeconfig-Datei für einen selbst gehosteten Kubernetes-Cluster einzurichten (http://docs.shippable.com/deploy/tutorial/create-kubeconfig-for-self-hosted-kubernetes-cluster/).
Lassen Sie mich wissen, wenn Sie noch Fragen haben.

Vielen Dank an @UmamaheshMaxwell für Ihre geduldige Antwort

Ich habe ein vorhandenes Kubernetes 1.16-Setup. Können Sie bitte bestätigen, ob ich versuchen kann, diese Schritte auszuführen?

Ja @cyrilthank , sogar wir hatten Kubernetes 1.16.1, aber wir mussten es auf 1.15.4 zurücksetzen. Unten ist der Link, wenn Sie es von Grund auf neu einrichten möchten.

VMs Betriebssystemversion

Distributor ID: Ubuntu
Description:    Ubuntu 18.04.3 LTS
Release:    18.04
Codename:   bionic

Kubereneten aufräumen

kubeadm reset
sudo apt-get purge kubeadm kubectl kubelet kubernetes-cni kube*   
sudo apt-get autoremove  
sudo rm -rf ~/.kube

Kubernetes einrichten (sowohl Master als auch Node)
https://www.howtoforge.com/tutorial/how-to-install-kubernetes-on-ubuntu/
(Sie sollten die im obigen Link vorgeschlagenen Schritte so weit wie möglich automatisieren, um Zeit zu sparen.)

Lassen Sie mich wissen, wenn Sie weitere Hilfe benötigen. Happy Journey mit Rollback :), hoffe du hast eine reibungslose Reise damit.

Möglicherweise müssen Sie den Speicherort des Bildes in gcr.azk8s.cn/kubernetes-helm/

Obwohl es sich um ein vollständig gültiges Problem handelt, ist dieses Problem leicht orthogonal zu dem in dieser Ausgabe enthaltenen Problem. In China ist gcr.io leider blockiert. Weitere Informationen finden Sie unter Ruder / Charts Nr. 14607 .

Ich bin nicht in China, sondern in den USA. Aber ich denke, mein VPN hat diese Seite blockiert. Wie auch immer, ich habe alle in diesem Thread beschriebenen Schritte befolgt und konnte es nicht zum Laufen bringen, bis ich versuchte, das Bild manuell abzurufen und feststellte, dass es nicht reagierte - nur etwas anderes, um es zu versuchen, falls jemand anderes an der gleichen Stelle wie stecken bleibt mich.

Ich bekomme auch den Fehler:

$ helm init
$HELM_HOME has been configured at C:\Users\user\.helm.
Error: error installing: the server could not find the requested resource

Ich versuche eine in dieser Ausgabe vorgeschlagene Lösung, insbesondere diese . Nachdem ich die Datei tiller.yaml entsprechend geändert habe, kann ich die Konfiguration jedoch nicht aktualisieren. Ich versuche den folgenden Befehl, um die Änderungen zu übernehmen / die Konfiguration zu aktualisieren:

$ kubectl apply -f tiller.yaml
deployment.apps/tiller-deploy configured
service/tiller-deploy configured

Aber wenn ich renne:

$ helm init --output yaml > tiller2.yaml

Die Datei tiller2.yaml zeigt:

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  creationTimestamp: null
  labels:
    app: helm
    name: tiller
  name: tiller-deploy
  namespace: kube-system
spec:
  replicas: 1
  strategy: {}
  template:

Grundsätzlich spiegeln sich die Änderungen nicht wider. Ich gehe also davon aus, dass ich die Konfiguration nicht richtig aktualisiere. Was wäre der richtige Weg, um es zu tun?

EDIT : Ich habe es geschafft, es zum Laufen zu bringen. Ich verwende Minikube und um es zum Laufen zu bringen, habe ich zuerst die Kubernetes-Version auf 1.15.4 heruntergestuft.

minikube delete
minikube start --kubernetes-version=1.15.4

Dann benutzte ich einen Proxy, also musste ich die IP von Minikube zur NO_PROXY-Liste hinzufügen: 192.168.99.101 in meinem Fall. Siehe: https://minikube.sigs.k8s.io/docs/reference/networking/proxy/

Hinweis: Nach einigen weiteren Tests ist das Downgrade möglicherweise nicht erforderlich, und möglicherweise fehlte mir nur der Schritt NO_PROXY. Ich habe alle 192.168.99.0/24 , 192.168.39.0/24 und 10.96.0.0/12 zur NO_PROXY-Einstellung hinzugefügt und jetzt scheint es gut zu funktionieren.

helm init --service-account tiller --override spec.selector.matchLabels.'name '=' tiller ', spec.selector.matchLabels.'app' = 'helm' --output yaml | sed ' s @ apiVersion : extensions / v1beta1 @ apiVersion : apps / v1 @' | kubectl apply -f -

Es hat bei mir funktioniert. Vielen Dank

Während sich die Kubernetes-API weiterentwickelt, werden APIs regelmäßig neu organisiert oder aktualisiert. Wenn sich APIs weiterentwickeln, ist die alte API veraltet und wird schließlich entfernt.

In Version v16 werden die folgenden veralteten API-Versionen nicht mehr zugunsten neuerer und stabilerer API-Versionen bereitgestellt:

NetworkPolicy (in the extensions/v1beta1 API group)
    Migrate to use the networking.k8s.io/v1 API, available since v1.8. Existing persisted data can be retrieved/updated via the networking.k8s.io/v1 API.
PodSecurityPolicy (in the extensions/v1beta1 API group)
    Migrate to use the policy/v1beta1 API, available since v1.10. Existing persisted data can be retrieved/updated via the policy/v1beta1 API.
DaemonSet, Deployment, StatefulSet, and ReplicaSet (in the extensions/v1beta1 and apps/v1beta2 API groups)
    Migrate to use the apps/v1 API, available since v1.9. Existing persisted data can be retrieved/updated via the apps/v1 API.

Die Version 1.20 stellt die Bereitstellung der folgenden veralteten API-Versionen zugunsten neuerer und stabilerer API-Versionen ein:

Ingress (in the extensions/v1beta1 API group)
    Migrate to use the networking.k8s.io/v1beta1 API, serving Ingress since v1.14. Existing persisted data can be retrieved/updated via the networking.k8s.io/v1beta1 API.

Was zu tun ist

• Ändern Sie YAML-Dateien, um auf die neueren APIs zu verweisen
• Aktualisieren Sie benutzerdefinierte Integrationen und Controller, um die neueren APIs aufzurufen
• Aktualisieren Sie Tools von Drittanbietern (Ingress Controller, Continuous Delivery-Systeme), um die neueren APIs aufzurufen

Beziehen auf :

• https://kubernetes.io/docs/setup/release/notes/#deprecations -and-removeals
• https://kubernetes.io/blog/2019/07/18/api-deprecations-in-1-16/

Als Helm n00b, der Minikube verwendet, konnte ich dieses Problem umgehen, indem ich eine Kubernetes-Version wie folgt einstellte:

$ minikube delete
$ minikube start --kubernetes-version=1.15.4

Ich hoffe es hilft!

@PierreF Ich habe Ihre Lösung (https://github.com/helm/helm/issues/6374#issuecomment-533186177) mit k8s v1.16.1 und helm v2.15.0 verwendet und die Pinne funktioniert nicht.

Readiness probe failed: Get http://10.238.128.95:44135/readiness: dial tcp 10.238.128.95:44135: connect: connection refused

@ joshprzybyszewski-wf Ich habe folgenden Befehl verwendet

minikube start --memory=16384 --cpus=4 --kubernetes-version=1.15.4
kubectl create -f istio-1.3.3/install/kubernetes/helm/helm-service-account.yaml
helm init --service-account tiller
helm install istio-1.3.3/install/kubernetes/helm/istio-init --name istio-init --namespace istio-system
helm install istio-1.3.3/install/kubernetes/helm/istio --name istio --namespace istio-system

Und jetzt bekommen,

Error: validation failed: [unable to recognize "": no matches for kind "DestinationRule" in version "networking.istio.io/v1alpha3", unable to recognize "": no matches for kind "DestinationRule" in version "networking.istio.io/v1alpha3", unable to recognize "": no matches for kind "attributemanifest" in version "config.istio.io/v1alpha2", unable to recognize "": no matches for kind "attributemanifest" in version "config.istio.io/v1alpha2", unable to recognize "": no matches for kind "handler" in version "config.istio.io/v1alpha2", unable to recognize "": no matches for kind "handler" in version "config.istio.io/v1alpha2", unable to recognize "": no matches for kind "instance" in version "config.istio.io/v1alpha2", unable to recognize "": no matches for kind "instance" in version "config.istio.io/v1alpha2", unable to recognize "": no matches for kind "instance" in version "config.istio.io/v1alpha2", unable to recognize "": no matches for kind "instance" in version "config.istio.io/v1alpha2", unable to recognize "": no matches for kind "instance" in version "config.istio.io/v1alpha2", unable to recognize "": no matches for kind "instance" in version "config.istio.io/v1alpha2", unable to recognize "": no matches for kind "instance" in version "config.istio.io/v1alpha2", unable to recognize "": no matches for kind "instance" in version "config.istio.io/v1alpha2", unable to recognize "": no matches for kind "instance" in version "config.istio.io/v1alpha2", unable to recognize "": no matches for kind "rule" in version "config.istio.io/v1alpha2", unable to recognize "": no matches for kind "rule" in version "config.istio.io/v1alpha2", unable to recognize "": no matches for kind "rule" in version "config.istio.io/v1alpha2", unable to recognize "": no matches for kind "rule" in version "config.istio.io/v1alpha2", unable to recognize "": no matches for kind "rule" in version "config.istio.io/v1alpha2", unable to recognize "": no matches for kind "rule" in version "config.istio.io/v1alpha2"]

Hier ist eine kurzfristige Problemumgehung:

helm init --output yaml | sed 's<strong i="7">@apiVersion</strong>: extensions/v1beta1<strong i="8">@apiVersion</strong>: apps/v1@' | kubectl apply -f -

Eigentlich ist es nicht gut genug. Ich erhalte immer noch eine Fehlermeldung:

error validating data: ValidationError(Deployment.spec): missing required field "selector" in io.k8s.api.apps.v1.DeploymentSpec

Dies kann gepatcht werden mit:

/usr/local/bin/kubectl patch --local -oyaml -f - -p '{"spec":{"selector": {"app":"helm","name":"tiller"}}}'

Sie haben es versäumt, macthLabels Post Selector hinzuzufügen.

Ich wurde zu @jbrettes Lösung weitergeleitet. Das habe ich bekommen, als ich es laufen ließ

error: error parsing STDIN: error converting YAML to JSON: yaml: line 11: mapping values are not allowed in this context

Dies wurde in Helm 2.16.0 behoben .

Ich wurde zu @jbrettes Lösung weitergeleitet. Das habe ich bekommen, als ich es laufen ließ

error: error parsing STDIN: error converting YAML to JSON: yaml: line 11: mapping values are not allowed in this context

Überprüfen Sie die Yaml-Dateien. In den meisten Fällen enthält die referenzierte Zeile {} oder [] und noch andere Dinge, die den Fehler verursachen. In den meisten Fällen liegt das Problem in der Datei values.yaml. Überprüfen Sie andernfalls den Vorlagenabschnitt des Diagramms.

Nur eine Randnotiz zur Lösung von @mihivagyok . Diese haben bei mir nicht funktioniert, wenn ich private Helm-Repos benutze.

$ helm repo add companyrepo https://companyrepo
Error: Couldn't load repositories file (/home/username/.helm/repository/repositories.yaml).

Ich denke, das passiert, weil helm init nicht ausgeführt wird, sondern nur eine yaml-Datei generiert. Ich habe das behoben, indem ich helm init -c als Extra ausgeführt habe.

in k8s v1.16.6 erfordert helm init otput spec.selector fyi.

Die aktuelle Problemumgehung scheint ungefähr so ​​zu sein:

helm init --output yaml> tiller.yaml
und aktualisieren Sie die tiller.yaml:

• Wechseln Sie zu Apps / v1
• Fügen Sie das Auswahlfeld hinzu

---
apiVersion: apps/v1
kind: Deployment
metadata:
  creationTimestamp: null
  labels:
    app: helm
    name: tiller
  name: tiller-deploy
  namespace: kube-system
spec:
  replicas: 1
  strategy: {}
  selector:
    matchLabels:
      app: helm
      name: tiller
....

Es funktioniert, da kubernetes apiVersion apps / v1 für Deployment in ändert. Es muss eine Sache geändert werden: Wir müssen Selector matchLabels für spec hinzufügen

Eine andere Problemumgehung kann darin bestehen, Helm 3 zu verwenden, bei dem keine Pinne verwendet wird.

helm init --output yaml | sed ' s @ apiVersion : extensions / v1beta1 @ apiVersion : apps / v1 @' | kubectl apply -f -

Hallo, während ich das versuche, bekomme ich folgendes:

jenkins @ jenkin : ~ / .kube $ helm init --output yaml | sed ' s @ apiVersion : extensions / v1beta1 @ apiVersion : apps / v1 @' | kubectl apply -f -

Befehl 'kubectl' nicht gefunden, kann aber installiert werden mit:

Schnellinstallation kubectl
Bitte fragen Sie Ihren Administrator.

jenkins @ jenkin : ~ / .kube $

Ausgabe von helm version : v2.14.3
Ausgabe von kubectl version : Client: v1.15.3, Server: v1.16.0-rc.1
Cloud-Anbieter / Plattform (AKS, GKE, Minikube usw.): IBM Cloud Kubernetes Service

$ helm init --service-account tiller
$HELM_HOME has been configured at /Users/xxxx/.helm.
Error: error installing: the server could not find the requested resource

$ helm init --debug --service-account tiller
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  creationTimestamp: null
  labels:
    app: helm
    name: tiller
  name: tiller-deploy
  namespace: kube-system
spec:
. 
.
.

Es sieht so aus, als würde das Ruder versuchen, eine Bereitstellung von tiller zu erstellen mit: apiVersion: extensions/v1beta1
Laut: https://kubernetes.io/blog/2019/07/18/api-deprecations-in-1-16
das wird nicht mehr unterstützt.

bekomme diesen Fehler: Wie kann ich ihn lösen ???

root @ jenkin : ~ # helm init - Service-Account-Pinne
$ HELM_HOME wurde unter /root/.helm konfiguriert.
Fehler: Fehler bei der Installation: unbekannt (post deployments.extensions)
root @ jenkin : ~ #

Hier ist eine kurzfristige Problemumgehung:

helm init --output yaml | sed 's<strong i="7">@apiVersion</strong>: extensions/v1beta1<strong i="8">@apiVersion</strong>: apps/v1@' | kubectl apply -f -

Eigentlich ist es nicht gut genug. Ich erhalte immer noch eine Fehlermeldung:

error validating data: ValidationError(Deployment.spec): missing required field "selector" in io.k8s.api.apps.v1.DeploymentSpec

Dies kann gepatcht werden mit:

/usr/local/bin/kubectl patch --local -oyaml -f - -p '{"spec":{"selector": {"app":"helm","name":"tiller"}}}'

Ich erhalte diesen Fehler:

jenkins @ jenkin : ~ / .helm $ helm init --output yaml | sed ' s @ apiVersion : extensions / v1beta1 @ apiVersion : apps / v1 @' | kubectl apply -f -

Befehl 'kubectl' nicht gefunden, kann aber installiert werden mit:

Schnellinstallation kubectl
Bitte fragen Sie Ihren Administrator.

jenkins @ jenkin : ~ / .helm $

Problemumgehung mit jq :

helm init -o json | jq '(select(.apiVersion == "extensions/v1beta1") .apiVersion = "apps/v1")' | jq '(select(.kind == "Deployment") .spec.selector.matchLabels.app = "helm")' | jq '(select(.kind == "Deployment") .spec.selector.matchLabels.name = "tiller")' | kubectl create -f -

Problemumgehung mit jq :

helm init -o json | jq '(select(.apiVersion == "extensions/v1beta1") .apiVersion = "apps/v1")' | jq '(select(.kind == "Deployment") .spec.selector.matchLabels.app = "helm")' | jq '(select(.kind == "Deployment") .spec.selector.matchLabels.name = "tiller")' | kubectl create -f -

Sie können die Ressource nicht mit kubectl create aktualisieren

@ikarlashov einfach genug, um 'create' durch 'apply' zu ersetzen. Der obige Einzeiler setzt voraus, dass man noch nicht versucht hat, die Ressourcen zu erstellen.