Hemos evitado actualizar tiller a apps / v1 en el pasado debido a la complejidad de tener helm init --upgrade conciliando las implementaciones de extensions/v1beta1 y apps/v1 tiller. Parece que una vez que comencemos a admitir Kubernetes 1.16.0, tendremos que manejar ese caso en el futuro y migrar a la nueva apiVersion.

Aquí hay una solución temporal a corto plazo:

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

De hecho, no es lo suficientemente bueno. Sigo recibiendo un error:

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

Esto se puede parchear con:

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

¡Lindo! Es posible que pueda lograr el mismo efecto con la bandera --override que con los locos hacks de sed :)

¡Lindo! Es posible que pueda lograr el mismo efecto con la bandera --override que con los locos hacks de sed :)

Sí, pero puedo copiar y pegar sus locos sed hacks, mientras que este helm init --override "apiVersion"="apps/v1" simplemente no funciona. Ok, el truco sed tampoco funciona.

La solución actual parece ser algo como esto:

helm init --output yaml> tiller.yaml
y actualice el archivo tiller.yaml:

• cambiar a aplicaciones / v1
• agregar el campo selector

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

El siguiente sed funciona para mí:

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 -

El problema con la solución @mattymo (usando el parche kubectl --local) es que parece no funcionar cuando su entrada contiene múltiples recursos (aquí, una implementación y un servicio).

Kubernetes 1.16.0 se lanzó ayer: 18/9/2018.
Helm está roto en esta última versión de Kubernetes a menos que se utilice la solución anterior.

¿Cuándo se solucionará este problema y cuándo se lanzará Helm 2.15.0 ?

Si quieres usar uno menos sed :)
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 -

¡Gracias!

Hoy me encontré con el mismo problema, cambié la etiqueta yo mismo. Cambio la etiqueta a apps/v1 y agrego selector part, a partir de ahora funciona muy bien, a continuación se muestra mi archivo yaml:

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, ¡eres mi héroe! Estaba luchando con la estrofa selector .

Hoy me encontré con el mismo problema, cambié la etiqueta yo mismo. Cambio la etiqueta a apps/v1 y agrego selector part, a partir de ahora funciona muy bien, a continuación se muestra mi archivo yaml:

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: {}

como cambiar ¿Puede describir más detalles?

Hoy me encontré con el mismo problema, cambié la etiqueta yo mismo. Cambio la etiqueta a apps/v1 y agrego selector part, a partir de ahora funciona muy bien, a continuación se muestra mi archivo yaml:

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 ¿cómo cambiar y puede describir más detalles?

Hoy me encontré con el mismo problema, cambié la etiqueta yo mismo. Cambio la etiqueta a apps/v1 y agrego selector part, a partir de ahora funciona muy bien, a continuación se muestra mi archivo yaml:

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 ¿cómo cambiar y puede describir más detalles?

Por ejemplo, puede usar helm init --service-account tiller --tiller-namespace kube-system --debug para imprimir manifiestos en formato YAML, la opción --debug hará esto

@ gm12367 Sí, puedo ver la impresión pero solo la salida. Entonces, ¿qué comando puedo cambiar la salida?

@ gm12367 Quiero cambiar aplicaciones / v1 y agregar parte de selector

@ puww1010 Acabo de redirigir la salida en un archivo y luego usé VIM para cambiarlo. Debajo de los comandos como referencia.

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

Si su entorno de Go está configurado y no puede esperar hasta que se fusione el siguiente PR que soluciona este problema [Helm init compatible con Kubernetes 1.16] # 6462, siempre puede hacer lo siguiente:

Construir

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

Prueba:

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 obtener deployment.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 Sigue teniendo el mismo problema después de seguir sus instrucciones

@jbrette Sigue teniendo el mismo problema después de seguir sus instrucciones

Parece que escribiste "helm" en lugar de "./bin/helm".... así que estás usando la versión anterior del binario.

Después de una inicialización exitosa, no podrá instalar un paquete de gráficos desde el repositorio hasta que también reemplace las extensiones / v1beta1 en él.
Aquí se explica cómo adaptar cualquier gráfico del repositorio para k8s v1.16.0
El ejemplo se basa en el gráfico de Prometheus.

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

Reemplace las extensiones / v1beta1 por policy / 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}' {} +`

_Helpers.tpl maneja bien NetworkPolicy apiVersion para aquellos gráficos en los que se usa.

Reemplace las extensiones / v1beta1 por aplicaciones / v1 en Implementación, 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}' {} +`

Crea un nuevo paquete:

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

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

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

PD Para algunos gráficos con dependencias, es posible que deba usar helm dependency update y reemplazar tgz dependiente con parches si corresponde.

Obteniendo el mismo error al ejecutar helm init --history-max 200

producción

$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

Esta rama funciona https://github.com/keleustes/helm/tree/kube16. Puedes construir la rama tú mismo. También subí el binario aquí para su conveniencia https://s3-us-west-2.amazonaws.com/bin.cryptexlabs.com/github.com/keleustes/helm/kube16/darwin/helm. Una advertencia es que debe usar la bandera de imagen canaria helm init --canary-image ya que la compilación no se lanzó

No debería necesitar la imagen del canario para que esto funcione. Sugeriría usar helm init --tiller-image gcr.io/kubernetes-helm/tiller:v2.14.3 como @jbrette mencionó anteriormente si desea probar # 6462.

Recomiendo a los usuarios que prueben primero una de las soluciones proporcionadas anteriormente antes de probar un PR de todos modos; de esa manera, pueden continuar usando Helm 2.14.3 en lugar de una rama de desarrollo personalizada que aún está en revisión.

Cuando hago el comando, lo implemento, pero después de eso, puede verlo en las vainas y dice Error del servidor (NotFound): las vainas "tiller-deploy" no se encuentran

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 -

deployment.apps / tiller-deploy creado
servicio / despliegue de timón creado

Pero cuando hago kubectl get pods, todos los espacios de nombres no pueden ver los pods
NOMBRE NOMBRE ESTADO LISTO REINICIE EDAD
kube-system coredns-5644d7b6d9-559hw 1/1 En funcionamiento 0 23h
kube-system coredns-5644d7b6d9-xcmjd 1/1 En ejecución 0 23h
kube-system etcd-fmp 1/1 En ejecución 0 24 h
kube-system kube-apiserver-fmp 1/1 En funcionamiento 0 24h
kube-system kube-controller-manager-fmp 1/1 En ejecución 1 24h
kube-system kube-flannel-ds-amd64-ffx2g 1/1 Running 0 23h
kube-system kube-proxy-lfvrz 1/1 En ejecución 0 24 h
kube-system kube-planificador-fmp 1/1 En ejecución 0 24 h

kubectl obtiene todo --todos los espacios de nombres | cultivador grep
servicio del sistema kube / tiller-deploy ClusterIP xxx44134 / TCP 2 min 52 s
kube-system deployment.apps / tiller-deploy 0/1 0 0 2m54s
kube-system replicaset.apps / tiller-deploy-77855d9dcf 1 0 0 2m54s

@DanielIvaylov Creo que no tienes la cuenta de servicio del timón. Créelo y, a continuación, la implementación también creará la vaina del timón.

¡Gracias!

@DanielIvaylov Creo que no tienes la cuenta de servicio del timón. Créelo y, a continuación, la implementación también creará la vaina del timón.

¡Gracias!

Lo siento, soy nuevo, pensé que esto lo va a iniciar. ¿Cómo inicio la cuenta de servicio del timón?

@DanielIvaylov

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

Se agregó la siguiente marca al servidor api (/etc/kubernetes/manifests/kube-apiserver.yaml) que reactivó temporalmente esas API obsoletas.

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

Esto arregló el timón v2

Para las personas en Windows, pudimos instalar / actualizar tiller a través de PowerShell de la siguiente manera:

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

Aquí hay una solución temporal a corto plazo:

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

De hecho, no es lo suficientemente bueno. Sigo recibiendo un error:

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

Esto se puede parchear con:

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

para mi el parche de kubectl esta colgando
no hay mensajes en el archivo / var / log / syslog

las cuentas de servicio ya existen

kubeflow @ masternode : ~ $ kubectl - espacio de nombres kube-system crea un timón
Error del servidor (AlreadyExists): las cuentas de servicio "tiller" ya existen
kubeflow @ masternode : ~ $ kubectl create clusterrolebinding tiller --clusterrole cluster-admin --serviceaccount = kube- system: tiller
Error del servidor (AlreadyExists): clusterrolebindings.rbac.authorization.k8s.io "tiller" ya existe

Puede aconsejarme

ejecutando lo siguiente

export PATH = $ PATH: / usr / local / bin
cual timón
que timón
helm install \
--nombre nfs-client-provisioner \
--set nfs.server = 10.0.0.4 \
--set nfs.path = / nfsroot \
--set storageClass.name = nfs \
--set storageClass.defaultClass = true \
estable / nfs-client-provisioner

regresa con

/ usr / local / bin / helm
/ usr / local / bin / tiller
Error: no se pudo encontrar el timón

agradezco cualquier ayuda, ya que ahora es un tapón de espectáculo

@cyrilthank Parece que el error de
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 debería devolver la versión del servidor (tiller) si está funcionando correctamente

Gracias Señor.
Ha sido útil para permitirnos continuar con kubeflow al siguiente paso

ok ahora creo que tengo este problema
https://github.com/kubeflow/kubeflow/issues/4184
volver como bloqueador

Le agradecería mucho si pudiera ayudarme con un consejo sobre cómo puedo obtener ayuda en https://github.com/kubeflow/kubeflow/issues/4184

@cyrilthank, pruebe los pasos indicados anteriormente: https://github.com/helm/helm/issues/6374#issuecomment -533853888
Necesita reemplazar las versiones de API obsoletas por las nuevas

kubeflow_workaround_and_error_traces.txt

Gracias, señor, por las respuestas de su paciente, especialmente para mantener abierto este problema.

Lo siento, pero parece que estoy haciendo algo mal en los pasos de solución.

Le agradecería que pudiera revisar los pasos en los seguimientos adjuntos y aconsejarme sobre lo que estoy haciendo mal

@cyrilthank , solo necesita ejecutar los comandos sed contra sus yamls de kubeflow para reemplazar la extensión api antigua por la nueva (no es necesario implementar prometheus en absoluto 😆). Lo siento si no me expresé lo suficientemente bien.
La solución es básicamente reemplazar extensions/v1beta1 con apps/v1 en sus yamls dpl de kubeflow

ah, entonces hice una copia tonta :(

mi KFAPP = / nfsroot / kf-poc

todavía parece que recibo algunos mensajes y el error final

¿Pueden ayudarme, ya que dependo de ustedes ahora para pasar al siguiente paso en kubeflow?

kubeflow_workaround_sed_and_error_traces.txt

@cyrilthank , solo necesita ejecutar los comandos sed contra sus yamls de kubeflow para reemplazar la antigua extensión api con la nueva (no es necesario implementar prometheus para reírse). Lo siento si no me expresé lo suficientemente bien.
La solución es básicamente reemplazar extensions/v1beta1 con apps/v1 en sus yamls dpl de kubeflow

apps/v1beta2 también con apps/v1

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

Muchas gracias @uniuuu por tu ayuda
¿Puede indicar dónde / cómo obtener los archivos yaml a los que se hace referencia en 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

solicitando, ya que después de realizar los cambios sed todavía hemos encontrado los errores a los que se hace referencia en

¿Puede avisarme si el paso

kubectl convertir -f--versión de salida/

debe ejecutarse para cadasiendo cada archivo yaml en la ubicación de KFAPP, incluido .kache

Si ha aplicado la solución alternativa mencionada anteriormente al trabajar con helm init , y aún obtiene el siguiente error al intentar cosas como helm version , es porque el helm deployment no pudo ser encontrado.

Error: could not find tiller

Necesita ejecutar kubectl get events --all-namespaces | grep -i tiller para saber por qué no está listo.

Por ejemplo, mi problema es simplemente el siguiente, porque no necesito serviceaccount "tiller" con microk8s .

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

Así que hice el trabajo sin la cuenta de servicio.

- 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 Eliminé su comentario porque no es relevante para la discusión involucrada aquí. Continúe con el seguimiento en kubeflow / kubeflow # 4184. ¡Gracias!

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 -

Leve corrección

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 Acabo de redirigir la salida en un archivo y luego usé VIM para cambiarlo. Debajo de los comandos como referencia.

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

Intenté hacer esto. Después de editar el archivo en VIM, uso el comando kubectl apply , pero parece que no hace nada. Cuando ejecuto helm init --service-account tiller --tiller-namespace kube-system --debug >> helm-init.yaml nuevamente o helm init --output yaml los cambios no se han aplicado. ¿Alguien más experimenta esto?

Si quieres usar uno menos sed :)
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 -

¡Gracias!

Acabo de actualizar nuestro k8 y enfrenté este problema y utilicé la solución anterior. Crea la implementación pero el conjunto de réplicas falla y esto es lo que obtengo de kubectl describe -n kube-system replicasets.apps tiller-deploy-77855d9dcf :

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

¿Dónde puedo encontrar un archivo yaml para crear esa cuenta de servicio?

@DanielIvaylov

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

¡Esto resolvió mi problema!

6462 se ha fusionado y estará disponible en la próxima versión (2.15.0). Por ahora, no dude en utilizar las soluciones provisionales proporcionadas anteriormente o utilice la versión canary .

¡Gracias a todos!

La imagen de Canary sigue produciendo el mismo error a menos que aún no tenga esta combinación,

@ puww1010 Acabo de redirigir la salida en un archivo y luego usé VIM para cambiarlo. Debajo de los comandos como referencia.

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

Intenté hacer esto. Después de editar el archivo en VIM, uso el comando kubectl apply , pero parece que no hace nada. Cuando ejecuto helm init --service-account tiller --tiller-namespace kube-system --debug >> helm-init.yaml nuevamente o helm init --output yaml los cambios no se han aplicado. ¿Alguien más experimenta esto?

Sí, me está pasando a mí también.

Es posible que deba cambiar la ubicación de la imagen a gcr.azk8s.cn/kubernetes-helm/tiller:v2.14.3 la ubicación gcr.io parece estar bloqueada.

Es posible que deba cambiar la ubicación de la imagen a gcr.azk8s.cn/kubernetes-helm/ tiller : v2.14.3 la ubicación de gcr.io parece estar bloqueada.

Si bien es un problema completamente válido, ese problema es ligeramente ortogonal al problema presente en este número, gcr.io está bloqueado en China, desafortunadamente. Consulte https://github.com/helm/charts/issues/14607 para obtener más información.

hemos podido solucionar este problema al revertir la versión de kubernetes a 1.15.4

Gracias @UmamaheshMaxwell por compartir esto.

¿Puede compartir los pasos que utilizó para revertir la versión de Kubernetes?

@cyrilthank si es minikube, minikube config set kubernetes-version v1.15.4

Gracias @UmamaheshMaxwell por compartir esto.

¿Puede compartir los pasos que utilizó para revertir la versión de Kubernetes?

@cyrilthank hemos estado usando nuestras propias máquinas virtuales (Ubuntu 18+), a continuación se muestran los ajustes para instalar la versión de k8s 1.15.4

1. reinicio de kubeadm
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-publicidad-address = xxxx --apiserver-cert-extra-sans = xxxx --kubernetes-version "1.15.4"

--pod-network-cidr=10.244.10.0/16 - franela
--apiserver-advertise-address=x.x.x.x - IP privada de su VM (Master)
--apiserver-cert-extra-sans=x.x.x.x - IP pública de su VM (Master) (Esto es necesario si está intentando acceder a su Master desde su máquina local.

Nota: Siga el enlace a continuación para configurar un archivo kubeconfig para un clúster de Kubernetes autohospedado (http://docs.shippable.com/deploy/tutorial/create-kubeconfig-for-self-hosted-kubernetes-cluster/)

Avíseme si todavía tiene alguna pregunta.

@cyrilthank si es minikube, conjunto de configuración de minikube kubernetes-versión v1.15.4

Gracias @MrSimonEmms el mío no es mini, creo que tendré que seguir los pasos de @UmamaheshMaxwell

Gracias @UmamaheshMaxwell por compartir esto.
¿Puede compartir los pasos que utilizó para revertir la versión de Kubernetes?

@cyrilthank hemos estado usando nuestras propias máquinas virtuales (Ubuntu 18+), a continuación se muestran los ajustes para instalar k8s versión 1.15.4

reinicio de kubeadm
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-publicidad-address = xxxx --apiserver-cert-extra-sans = xxxx --kubernetes-version "1.15.4"

--pod-network-cidr = 10.244.10.0 / 16 - franela
--apiserver-publicidad-address = xxxx - IP privada de su VM (Master)
--apiserver-cert-extra-sans = xxxx - IP pública de su VM (Master) (Esto es necesario, si está intentando acceder a su Master desde su máquina local.
Nota: Siga el enlace a continuación para configurar un archivo kubeconfig para un clúster de Kubernetes autohospedado (http://docs.shippable.com/deploy/tutorial/create-kubeconfig-for-self-hosted-kubernetes-cluster/)
Avíseme si todavía tiene alguna pregunta.

Gracias @UmamaheshMaxwell por su paciente respuesta

Tengo una configuración de kubernetes 1.16 existente. ¿Puede confirmar si puedo intentar ejecutar estos pasos?

Gracias @UmamaheshMaxwell por compartir esto.
¿Puede compartir los pasos que utilizó para revertir la versión de Kubernetes?
@cyrilthank hemos estado usando nuestras propias máquinas virtuales (Ubuntu 18+), a continuación se muestran los ajustes para instalar k8s versión 1.15.4
reinicio de kubeadm
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-publicidad-address = xxxx --apiserver-cert-extra-sans = xxxx --kubernetes-version "1.15.4"
--pod-network-cidr = 10.244.10.0 / 16 - franela
--apiserver-publicidad-address = xxxx - IP privada de su VM (Master)
--apiserver-cert-extra-sans = xxxx - IP pública de su VM (Master) (Esto es necesario, si está intentando acceder a su Master desde su máquina local.
Nota: Siga el enlace a continuación para configurar un archivo kubeconfig para un clúster de Kubernetes autohospedado (http://docs.shippable.com/deploy/tutorial/create-kubeconfig-for-self-hosted-kubernetes-cluster/)
Avíseme si todavía tiene alguna pregunta.

Gracias @UmamaheshMaxwell por su paciente respuesta

Tengo una configuración de kubernetes 1.16 existente. ¿Puede confirmar si puedo intentar ejecutar estos pasos?

Sí @cyrilthank , incluso teníamos kubernetes 1.16.1 pero tuvimos que revertirlo a 1.15.4 , a continuación se muestra el enlace si desea configurarlo desde cero.

Versión del sistema operativo de la máquina virtual

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

Limpiar kuberenetes

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

Configurar Kubernetes (_Tanto maestro como nodo_)
https://www.howtoforge.com/tutorial/how-to-install-kubernetes-on-ubuntu/
(es mejor que automatice los pasos sugeridos en el enlace anterior tanto como pueda, para ahorrar tiempo)

Avísame si aún necesitas más ayuda. Happy Journey con retroceso :), espero que tengas un buen viaje con él.

Es posible que deba cambiar la ubicación de la imagen a gcr.azk8s.cn/kubernetes-helm/ tiller : v2.14.3 la ubicación de gcr.io parece estar bloqueada.

Si bien es un problema completamente válido, ese problema es ligeramente ortogonal al problema presente en este número, gcr.io está bloqueado en China, desafortunadamente. Consulte timón / gráficos n. ° 14607 para obtener más información.

No estoy en China, sino en Estados Unidos. Pero creo que mi VPN bloqueó ese sitio. De todos modos, seguí todos los pasos descritos en este hilo y no pude hacerlo funcionar hasta que intenté obtener la imagen manualmente y vi que no respondía, solo algo más para probar en caso de que alguien más se quede atascado en el mismo lugar que me.

También recibo el error:

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

Estoy probando una solución propuesta en este problema, particularmente en este . Sin embargo, después de modificar el archivo tiller.yaml en consecuencia, no puedo actualizar la configuración. Estoy probando el siguiente comando para aplicar los cambios / actualizar la configuración:

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

Pero luego, si corro:

$ helm init --output yaml > tiller2.yaml

El archivo tiller2.yaml muestra:

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

Básicamente, los cambios no se reflejan. Así que supongo que no estoy actualizando la configuración correctamente. ¿Cuál sería la forma correcta de hacerlo?

EDITAR : Me las arreglé para hacerlo funcionar. Estoy usando Minikube y, para que funcione, primero bajé la versión de Kubernetes a 1.15.4.

minikube delete
minikube start --kubernetes-version=1.15.4

Luego, estaba usando un proxy, así que tuve que agregar la IP de Minikube a la lista NO_PROXY: 192.168.99.101 en mi caso. Ver: https://minikube.sigs.k8s.io/docs/reference/networking/proxy/

Nota: Después de algunas pruebas adicionales, tal vez la degradación no sea necesaria, y tal vez todo lo que me faltaba era el paso NO_PROXY. Agregué todos los 192.168.99.0/24 , 192.168.39.0/24 y 10.96.0.0/12 a la configuración NO_PROXY y ahora parece funcionar bien.

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

Funcionó para mí, muchas gracias

A medida que la API de Kubernetes evoluciona, las API se reorganizan o actualizan periódicamente. Cuando las API evolucionan, la API anterior queda obsoleta y finalmente se elimina.

La versión v1.16 dejará de ofrecer las siguientes versiones de API obsoletas en favor de versiones de API más nuevas y estables:

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.

La versión v1.20 dejará de ofrecer las siguientes versiones de API obsoletas en favor de versiones de API más nuevas y estables:

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.

Qué hacer

• Cambie los archivos YAML para hacer referencia a las API más nuevas
• Actualice las integraciones y los controladores personalizados para llamar a las API más nuevas
• Actualice las herramientas de terceros (controladores de ingreso, sistemas de entrega continua) para llamar a las API más nuevas

Referirse a :

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

Como helm n00b que está usando minikube, pude solucionar este problema configurando una versión de kubernetes así:

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

¡Espero eso ayude!

@PierreF Usé su solución (https://github.com/helm/helm/issues/6374#issuecomment-533186177) con k8s v1.16.1 y helm v2.15.0 y el timón no funciona.

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

@ joshprzybyszewski-wf utilicé el siguiente comando

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

Y ahora consigue

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

Aquí hay una solución temporal a corto plazo:

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

De hecho, no es lo suficientemente bueno. Sigo recibiendo un error:

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

Esto se puede parchear con:

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

te perdiste agregar macthLabels selector de publicaciones.

Me remitieron a la solución de @jbrette . Esto es lo que obtuve cuando lo ejecuté

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

Esto se ha solucionado en Helm 2.16.0 .

Me remitieron a la solución de @jbrette . Esto es lo que obtuve cuando lo ejecuté

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

Verifique los archivos yaml, en la mayoría de los casos la línea de referencia tiene {} o [] y aún tiene otras cosas definidas debajo que causan el error. En la mayoría de los casos, el problema está dentro de values.yaml; de lo contrario, consulte la sección de plantillas del gráfico.

Solo una nota al margen de la solución de @PierreF y

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

Supongo que eso sucede porque helm init no se ejecuta, solo genera un archivo yaml. Lo arreglé ejecutando helm init -c como extra.

en k8s v1.16.6, helm init otput requiere spec.selector fyi.

La solución actual parece ser algo como esto:

helm init --output yaml> tiller.yaml
y actualice el archivo tiller.yaml:

• cambiar a aplicaciones / v1
• agregar el campo selector

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

Funciona, dado que kubernetes cambia apiVersion apps / v1 a Deployment, hay una cosa que debe cambiarse es que necesitamos agregar selector matchLabels para especificaciones

Otra solución alternativa puede ser utilizar timón 3, que no utiliza caña de timón.

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

Hola, mientras intento esto, obtengo esto:

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

El comando 'kubectl' no se encuentra, pero se puede instalar con:

Instalar kubectl a presión
Pregúntele a su administrador.

jenkins @ jenkin : ~ / .kube $

Salida de helm version : v2.14.3
Salida de kubectl version : cliente: v1.15.3, servidor: v1.16.0-rc.1
Proveedor / plataforma de nube (AKS, GKE, Minikube, etc.): 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:
. 
.
.

Parece que helm está intentando crear tiller Implementación con: apiVersion: extensions/v1beta1
Según: https://kubernetes.io/blog/2019/07/18/api-deprecations-in-1-16
que ya no es compatible.

Recibo este error: ¿cómo puedo solucionarlo?

root @ jenkin : ~ # helm init - tiller de cuenta de servicio
$ HELM_HOME se ha configurado en /root/.helm.
Error: error al instalar: desconocido (post deployments.extensions)
root @ jenkin : ~ #

Aquí hay una solución temporal a corto plazo:

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

De hecho, no es lo suficientemente bueno. Sigo recibiendo un error:

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

Esto se puede parchear con:

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

Recibo este error:

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

El comando 'kubectl' no se encuentra, pero se puede instalar con:

Instalar kubectl a presión
Pregúntele a su administrador.

jenkins @ jenkin : ~ / .helm $

Solución alternativa, usando 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 -

Solución alternativa, usando 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 -

No puede actualizar el recurso con kubectl create

@ikarlashov es bastante fácil de reemplazar "crear" con "aplicar". La frase de arriba supone que uno aún no ha intentado crear los recursos.