Evitamos atualizar o tiller para apps / v1 no passado devido à complexidade de ter helm init --upgrade reconciliando as implantações de extensions/v1beta1 e apps/v1 tiller. Parece que assim que começarmos a oferecer suporte ao Kubernetes 1.16.0, teremos que lidar com esse caso no futuro e migrar para o apiVersion mais recente.

Esta é uma solução alternativa de curto prazo:

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

Na verdade, não é bom o suficiente. Ainda recebo um erro:

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

Isso pode ser corrigido com:

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

Legal! Você pode conseguir o mesmo efeito com o sinalizador --override que com hacks loucos de sed :)

Legal! Você pode conseguir o mesmo efeito com o sinalizador --override que com hacks loucos de sed :)

Sim, mas seus hacks loucos de sed eu posso copiar e colar, enquanto este helm init --override "apiVersion"="apps/v1" simplesmente não funciona. Ok, o hack do sed também não funciona.

a solução alternativa atual parece ser mais ou menos assim:

helm init --output yaml> tiller.yaml
e atualize o tiller.yaml:

• mudar para apps / v1
• adicione o campo seletor

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

O sed a seguir funciona para mim:

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 -

O problema com a solução @mattymo (usando o patch kubectl --local) é que parece não funcionar quando sua entrada contém vários recursos (aqui, uma implantação e um serviço).

O Kubernetes 1.16.0 foi lançado ontem: 18/09/2018.
O Helm está quebrado nesta última versão do Kubernetes, a menos que a solução alternativa acima seja usada.

Quando esse problema será corrigido e quando Helm 2.15.0 será lançado?

Se você quiser usar um sed a menos :)
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 -

Obrigado!

Hoje encontrei o mesmo problema, mudei o rótulo sozinho. Eu mudo o rótulo para apps/v1 e adiciono selector parte, a partir de agora ele tem um ótimo desempenho, abaixo está meu arquivo 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 você é meu herói! Eu estava lutando com a estrofe selector .

Hoje encontrei o mesmo problema, mudei o rótulo sozinho. Eu mudo o rótulo para apps/v1 e adiciono selector parte, a partir de agora ele tem um ótimo desempenho, abaixo está meu arquivo 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 mudar ? você pode descrever mais detalhes?

Hoje encontrei o mesmo problema, mudei o rótulo sozinho. Eu mudo o rótulo para apps/v1 e adiciono selector parte, a partir de agora ele tem um ótimo desempenho, abaixo está meu arquivo 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 como mudar e você pode descrever mais detalhes?

Hoje encontrei o mesmo problema, mudei o rótulo sozinho. Eu mudo o rótulo para apps/v1 e adiciono selector parte, a partir de agora ele tem um ótimo desempenho, abaixo está meu arquivo 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 como mudar e você pode descrever mais detalhes?

Por exemplo, você pode usar helm init --service-account tiller --tiller-namespace kube-system --debug para imprimir manifestos no formato YAML, --debug option fará isso

@ gm12367 Sim, posso ver a impressão, mas apenas a saída. Então, qual comando posso alterar a saída?

@ gm12367 Quero mudar apps / v1 e adicionar parte do seletor

@ puww1010 Acabei de redirecionar a saída em um arquivo e usei o VIM para alterá-la. Abaixo os comandos como referência.

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

se seu ambiente go estiver configurado e você não puder esperar até o seguinte PR que corrige esse problema [Helm init compatível com Kubernetes 1.16] # 6462 é mesclado, você sempre pode fazer:

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

Teste:

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 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 Ainda tendo o mesmo problema depois de seguir suas instruções

@jbrette Ainda tendo o mesmo problema depois de seguir suas instruções

Parece que você digitou "helm" em vez de "./bin/helm"..então está usando a versão antiga do binário.

Após o init bem-sucedido, você não será capaz de instalar um pacote de gráficos do repositório até substituir as extensões / v1beta1 nele também.
Aqui está como adaptar qualquer gráfico do repositório para k8s v1.16.0
O exemplo é baseado no gráfico Prometheus.

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

Substitua as extensões / 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}' {} +`

A apiVersion NetworkPolicy é bem tratada por _helpers.tpl para os gráficos em que é usada.

Substitua extensions / v1beta1 por apps / v1 em 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}' {} +`

Crie um novo pacote:

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

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

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

PS Para alguns gráficos com dependências, você pode precisar usar helm dependency update e substituir o tgz dependente por outros corrigidos, se aplicável.

Obtendo o mesmo erro ao executar helm init --history-max 200

resultado

$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

Este ramo funciona https://github.com/keleustes/helm/tree/kube16. Você pode construir o galho sozinho. Eu também carreguei o binário aqui para sua conveniência https://s3-us-west-2.amazonaws.com/bin.cryptexlabs.com/github.com/keleustes/helm/kube16/darwin/helm. Uma ressalva é que você deve usar o sinalizador de imagem canário helm init --canary-image pois a versão não foi lançada

Você não deve precisar da imagem do canário para fazer este trabalho. Eu sugeriria usar helm init --tiller-image gcr.io/kubernetes-helm/tiller:v2.14.3 como @jbrette mencionado anteriormente se você quiser experimentar # 6462.

Eu recomendo que os usuários tentem uma das soluções alternativas fornecidas anteriormente, antes de tentar um PR de qualquer maneira; dessa forma, eles podem continuar a usar o Helm 2.14.3 em vez de um branch de desenvolvimento personalizado que ainda está em revisão.

Quando eu faço o comando, ele o implanta, mas depois disso posso vê-lo nos pods e diz Erro do servidor (NotFound): pods "tiller-deploy" não encontrado

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 criado
service / tiller-deploy criado

Mas quando eu faço kubectl get pods - todos os namespaces não consigo ver os pods
NAMESPACE NOME PRONTO STATUS RESTARTS IDADE
kube-system coredns-5644d7b6d9-559hw 1/1 Executando 0 23h
kube-system coredns-5644d7b6d9-xcmjd 1/1 Executando 0 23h
kube-system etcd-fmp 1/1 Executando 0 24h
kube-system kube-apiserver-fmp 1/1 Running 0 24h
kube-system kube-controller-manager-fmp 1/1 Executando 1 24h
kube-system kube-flannel-ds-amd64-ffx2g 1/1 Executando 0 23h
kube-system kube-proxy-lfvrz 1/1 Executando 0 24h
kube-system kube-scheduler-fmp 1/1 Running 0 24h

kubectl get all --all-namespaces | grep tiller
serviço do sistema kube / tiller-deploy ClusterIP xxx44134 / TCP 2m52s
kube-system deployment.apps / tiller-deploy 0/1 0 0 2m54s
kube-system replicaset.apps / tiller-deploy-77855d9dcf 1 0 0 2m54s

@DanielIvaylov Acho que você não tem a conta de serviço do Tiller. Crie-o e, em seguida, a implantação criará o pod do leme também.

Obrigado!

@DanielIvaylov Acho que você não tem a conta de serviço do Tiller. Crie-o e, em seguida, a implantação criará o pod do leme também.

Obrigado!

Desculpe, sou novo, pensei que isso iria começar. Como eu inicio a conta de serviço do Tiller?

@DanielIvaylov

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

Adicionada a sinalização abaixo ao servidor api (/etc/kubernetes/manifests/kube-apiserver.yaml) que reativou temporariamente a API obsoleta.

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

Isso consertou o leme v2

Para pessoas no Windows, fomos capazes de instalar / atualizar o timão via PowerShell assim:

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

Esta é uma solução alternativa de curto prazo:

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

Na verdade, não é bom o suficiente. Ainda recebo um erro:

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

Isso pode ser corrigido com:

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

para mim, o patch kubectl está pendurado
nenhuma mensagem no arquivo / var / log / syslog

contas de serviço já existem

kubeflow @ masternode : ~ $ kubectl --namespace kube-system create sa tiller
Erro do servidor (AlreadyExists): serviceaccounts "tiller" já existe
kubeflow @ masternode : ~ $ kubectl create clusterrolebinding tiller --clusterrole cluster-admin --serviceaccount = kube- system: tiller
Erro do servidor (AlreadyExists): clusterrolebindings.rbac.authorization.k8s.io "tiller" já existe

você pode por favor aconselhar

executando o abaixo

exportar PATH = $ PATH: / usr / local / bin
qual leme
qual leme
Helm install \
--name nfs-client-provisioner \
--set nfs.server = 10.0.0.4 \
--set nfs.path = / nfsroot \
--set storageClass.name = nfs \
--set storageClass.defaultClass = true \
stable / nfs-client-provisioner

volta de volta com

/ usr / local / bin / helm
/ usr / local / bin / tiller
Erro: não foi possível encontrar o leme

agradecemos qualquer ajuda, pois isso agora é um empecilho

@cyrilthank Parece que o erro do leme é porque não há implantação do leme em execução, tente executar este comando para instalar o leme:
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 deve retornar a versão do servidor (tiller) se estiver instalado e funcionando corretamente

Obrigado senhor.
Você nos ajudou a prosseguir com o kubeflow para a próxima etapa

ok agora acho que entendi esse problema
https://github.com/kubeflow/kubeflow/issues/4184
de volta como bloqueador

Agradeço muito se você puder ajudar com conselhos sobre como posso obter ajuda em https://github.com/kubeflow/kubeflow/issues/4184

@cyrilthank, tente as etapas fornecidas acima: https://github.com/helm/helm/issues/6374#issuecomment -533853888
Você precisa substituir as versões obsoletas da API pelas novas

kubeflow_workaround_and_error_traces.txt

Obrigado, Senhor, pelas respostas dos seus pacientes, especialmente por manter este problema aberto

Desculpe, mas parece que estou fazendo algo errado nas etapas da solução alternativa

Agradeço se você puder revisar as etapas nos rastreios em anexo e me aconselhar sobre o que estou fazendo de errado

@cyrilthank você só precisa executar os comandos sed em seus yamls do kubeflow para substituir a extensão api antiga pela nova (não há necessidade de implantar o prometheus 😆). Desculpe se eu não me expressei bem o suficiente.
A correção consiste basicamente em substituir extensions/v1beta1 por apps/v1 em seu kubeflow dpl yamls

ah, então fiz uma cópia idiota :(

meu KFAPP = / nfsroot / kf-poc

Ainda estou recebendo algumas mensagens e o erro final

você pode ajudar, pois eu dependo de você agora para passar para a próxima etapa no kubeflow

kubeflow_workaround_sed_and_error_traces.txt

@cyrilthank, você só precisa executar os comandos sed em seus yamls do kubeflow para substituir a extensão api antiga pela nova (não há necessidade de implantar o prometheus, rindo). Desculpe se eu não me expressei bem o suficiente.
A correção consiste basicamente em substituir extensions/v1beta1 por apps/v1 em seu kubeflow dpl yamls

apps/v1beta2 também com apps/v1

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

Muito obrigado @uniuuu pela sua ajuda
Você pode informar onde / como obter os arquivos yaml mencionados em 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 desde depois de fazer as mudanças sed ainda encontramos os erros referenciados em

você pode aconselhar se o passo

kubectl convert -f--output-version/

precisa ser executado para cadasendo todos os arquivos yaml no local KFAPP incluindo .kache

Se você aplicou a solução alternativa mencionada acima ao trabalhar com helm init e ainda obtém o seguinte erro ao tentar coisas como helm version , é porque o helm deployment não pode ser encontrado.

Error: could not find tiller

Você precisa executar kubectl get events --all-namespaces | grep -i tiller para saber por que não está pronto.

Por exemplo, meu problema é simplesmente o seguinte, porque não preciso de serviceaccount "tiller" com 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

Então, eu fiz o trabalho e sem a conta de serviço

- 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 Removi seu comentário porque não é relevante para a discussão envolvida aqui. Continue o acompanhamento em kubeflow / kubeflow # 4184. Obrigado!

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 -

Ligeira correção

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 Acabei de redirecionar a saída em um arquivo e usei o VIM para alterá-la. Abaixo os comandos como referência.

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

Eu tentei fazer isso. Depois de editar o arquivo no VIM, eu uso o comando kubectl apply , mas ele parece não fazer nada. Quando executo helm init --service-account tiller --tiller-namespace kube-system --debug >> helm-init.yaml novamente ou helm init --output yaml as alterações não foram aplicadas. Alguém mais experimentou isso?

Se você quiser usar um sed a menos :)
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 -

Obrigado!

Acabei de atualizar nosso k8s e enfrentei esse problema e usei a solução acima. Ele cria a implantação, mas o replicaset falha e é isso que obtenho 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

Onde posso encontrar um arquivo yaml para criar essa conta de serviço?

@DanielIvaylov

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

Isso resolveu meu problema!

6462 foi mesclado e estará disponível na próxima versão (2.15.0). Por enquanto, sinta-se à vontade para usar as soluções alternativas fornecidas acima ou usar a versão canário .

Obrigado a todos!

A imagem canário ainda produz o mesmo erro, a menos que ainda não tenha essa mesclagem,

@ puww1010 Acabei de redirecionar a saída em um arquivo e usei o VIM para alterá-la. Abaixo os comandos como referência.

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

Eu tentei fazer isso. Depois de editar o arquivo no VIM, eu uso o comando kubectl apply , mas ele parece não fazer nada. Quando executo helm init --service-account tiller --tiller-namespace kube-system --debug >> helm-init.yaml novamente ou helm init --output yaml as alterações não foram aplicadas. Alguém mais experimentou isso?

Sim, acontecendo para mim também.

Pode ser necessário alterar o local da imagem para gcr.azk8s.cn/kubernetes-helm/tiller:v2.14.3 o local gcr.io parece estar bloqueado.

Pode ser necessário alterar o local da imagem para gcr.azk8s.cn/kubernetes-helm/ tiller : v2.14.3 o local gcr.io parece estar bloqueado.

Embora seja um problema totalmente válido, esse problema é ligeiramente ortogonal ao problema presente neste problema, gcr.io está bloqueado na China, infelizmente. Consulte https://github.com/helm/charts/issues/14607 para obter mais informações.

conseguimos corrigir esse problema revertendo a versão do kubernetes para 1.15.4

Obrigado @UmamaheshMaxwell por compartilhar isso.

Você pode compartilhar as etapas usadas para reverter a versão do kubernetes?

@cyrilthank se for minikube, minikube config set kubernetes-version v1.15.4

Obrigado @UmamaheshMaxwell por compartilhar isso.

Você pode compartilhar as etapas usadas para reverter a versão do kubernetes?

@cyrilthank estamos usando nossas próprias VMs (Ubuntu 18+), abaixo estão os setps para instalar a versão k8s 1.15.4

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

--pod-network-cidr=10.244.10.0/16 - flanela
--apiserver-advertise-address=x.x.x.x - IP privado da sua VM (Mestre)
--apiserver-cert-extra-sans=x.x.x.x - IP público de sua VM (Master) (Isso é necessário, se você estiver tentando acessar seu Master a partir de sua máquina local.

Observação: siga o link abaixo para configurar um arquivo kubeconfig para um cluster Kubernetes auto-hospedado (http://docs.shippable.com/deploy/tutorial/create-kubeconfig-for-self-hosted-kubernetes-cluster/)

Deixe-me saber se você ainda tiver alguma dúvida.

@cyrilthank se for minikube, minikube config set kubernetes-version v1.15.4

Obrigado @MrSimonEmms, o meu não é mini acho que terei que seguir os passos de @UmamaheshMaxwell

Obrigado @UmamaheshMaxwell por compartilhar isso.
Você pode compartilhar as etapas usadas para reverter a versão do kubernetes?

@cyrilthank estamos usando nossas próprias VMs (Ubuntu 18+), abaixo estão os setps para instalar o k8s versão 1.15.4

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

--pod-network-cidr = 10.244.10.0 / 16 - flanela
--apiserver-advertise-address = xxxx - IP privado de sua VM (mestre)
--apiserver-cert-extra-sans = xxxx - IP público de sua VM (Master) (Isso é necessário, se você está tentando acessar seu Master a partir de sua máquina local.
Observação: siga o link abaixo para configurar um arquivo kubeconfig para um cluster Kubernetes auto-hospedado (http://docs.shippable.com/deploy/tutorial/create-kubeconfig-for-self-hosted-kubernetes-cluster/)
Deixe-me saber se você ainda tiver alguma dúvida.

Obrigado @UmamaheshMaxwell pela sua resposta paciente

Eu tenho uma configuração existente do kubernetes 1.16, você pode confirmar se posso tentar executar essas etapas?

Obrigado @UmamaheshMaxwell por compartilhar isso.
Você pode compartilhar as etapas usadas para reverter a versão do kubernetes?
@cyrilthank estamos usando nossas próprias VMs (Ubuntu 18+), abaixo estão os setps para instalar o k8s versão 1.15.4
kubeadm reset
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-advertise-address = xxxx --apiserver-cert-extra-sans = xxxx --kubernetes-version "1.15.4"
--pod-network-cidr = 10.244.10.0 / 16 - flanela
--apiserver-advertise-address = xxxx - IP privado de sua VM (mestre)
--apiserver-cert-extra-sans = xxxx - IP público de sua VM (Master) (Isso é necessário, se você está tentando acessar seu Master a partir de sua máquina local.
Observação: siga o link abaixo para configurar um arquivo kubeconfig para um cluster Kubernetes auto-hospedado (http://docs.shippable.com/deploy/tutorial/create-kubeconfig-for-self-hosted-kubernetes-cluster/)
Deixe-me saber se você ainda tiver alguma dúvida.

Obrigado @UmamaheshMaxwell pela sua resposta paciente

Eu tenho uma configuração existente do kubernetes 1.16, você pode confirmar se posso tentar executar essas etapas?

Sim @cyrilthank , até tínhamos o kubernetes 1.16.1, mas tivemos que reverter para 1.15.4 , abaixo está o link se você quiser configurá-lo do zero.

Versão do sistema operacional da VM

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

Limpe kuberenetes

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

Configurar Kubernetes (_Both Master e Node_)
https://www.howtoforge.com/tutorial/how-to-install-kubernetes-on-ubuntu/
(é melhor automatizar as etapas sugeridas no link acima o máximo que puder, para economizar seu tempo)

Deixe-me saber se você ainda precisar de mais ajuda. Happy Journey with roll back :), espero que você tenha uma jornada tranquila com ele.

Pode ser necessário alterar o local da imagem para gcr.azk8s.cn/kubernetes-helm/ tiller : v2.14.3 o local gcr.io parece estar bloqueado.

Embora seja um problema totalmente válido, esse problema é ligeiramente ortogonal ao problema presente neste problema, gcr.io está bloqueado na China, infelizmente. Consulte o leme / cartas # 14607 para obter mais informações.

Não estou na China, mas nos Estados Unidos. Mas acho que minha VPN bloqueou esse site. De qualquer forma, segui todas as etapas descritas neste tópico e não consegui fazê-lo funcionar até que tentei obter a imagem manualmente e vi que não estava respondendo - apenas outra coisa para tentar no caso de alguém ficar preso no mesmo lugar que Eu.

Também estou recebendo o erro:

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

Estou tentando uma solução proposta neste problema, especialmente este . No entanto, depois de modificar o arquivo tiller.yaml de acordo, não consigo atualizar a configuração. Estou tentando o seguinte comando para aplicar as alterações / atualizar a configuração:

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

Mas então, se eu correr:

$ helm init --output yaml > tiller2.yaml

O arquivo tiller2.yaml mostra:

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

Basicamente, as mudanças não são refletidas. Portanto, presumo que não estou atualizando a configuração corretamente. Qual seria a forma correta de fazer isso?

EDIT : eu consegui colocá-lo em execução. Estou usando o Minikube e, para colocá-lo em execução, primeiro fiz o downgrade da versão do Kubernetes para 1.15.4.

minikube delete
minikube start --kubernetes-version=1.15.4

Então, eu estava usando um proxy, então tive que adicionar o IP do Minikube à lista NO_PROXY: 192.168.99.101 no meu caso. Consulte: https://minikube.sigs.k8s.io/docs/reference/networking/proxy/

Observação: depois de mais alguns testes, talvez o downgrade não seja necessário e talvez tudo o que me faltou foi a etapa NO_PROXY. Eu adicionei todos os 192.168.99.0/24 , 192.168.39.0/24 e 10.96.0.0/12 à configuração NO_PROXY e agora parece funcionar bem.

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 -

Funcionou para mim, muito obrigado

Conforme a API do Kubernetes evolui, as APIs são reorganizadas ou atualizadas periodicamente. Quando as APIs evoluem, a API antiga é descontinuada e eventualmente removida.

A versão v1.16 deixará de veicular as seguintes versões de API obsoletas em favor de versões de API mais novas e estáveis:

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.

A versão v1.20 deixará de servir as seguintes versões de API obsoletas em favor de versões de API mais novas e estáveis:

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.

O que fazer

• Altere os arquivos YAML para fazer referência às APIs mais recentes
• Atualize integrações e controladores personalizados para chamar as APIs mais recentes
• Atualize as ferramentas de terceiros (controladores de entrada, sistemas de entrega contínua) para chamar as APIs mais recentes

Referir-se :

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

Como leme n00b que usa minikube, consegui contornar esse problema definindo uma versão do kubernetes assim:

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

Espero que ajude!

@PierreF Usei sua solução (https://github.com/helm/helm/issues/6374#issuecomment-533186177) com k8s v1.16.1 e helm v2.15.0 e o leme não está funcionando.

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

@ joshprzybyszewski-wf eu usei o seguinte 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

E agora pegue,

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

Esta é uma solução alternativa de curto prazo:

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

Na verdade, não é bom o suficiente. Ainda recebo um erro:

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

Isso pode ser corrigido com:

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

você esqueceu de adicionar macthLabels seletor de postagem.

Fui encaminhado para a solução de @jbrette . Isso é o que eu recebi quando o executei

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

Isso foi corrigido no Helm 2.16.0 .

Fui encaminhado para a solução de @jbrette . Isso é o que eu recebi quando o executei

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

Verifique os arquivos yaml, na maioria dos casos a linha referenciada tem {} ou [] e ainda tem outras coisas definidas sob ele que causam o erro. Na maioria dos casos, o problema está em values.yaml, caso contrário, verifique a seção de modelos do gráfico.

Apenas uma observação sobre a solução de @mihivagyok . Eles não funcionaram para mim quando eu uso repositórios de leme privados.

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

Acho que isso acontece porque o helm init não é executado, apenas gera o arquivo yaml. Corrigi isso executando helm init -c como um extra.

no k8s v1.16.6, o leme init otput requer spec.selector fyi.

a solução alternativa atual parece ser mais ou menos assim:

helm init --output yaml> tiller.yaml
e atualize o tiller.yaml:

• mudar para apps / v1
• adicione o campo seletor

---
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, uma vez que os kubernetes alteram apiVersion apps / v1 para para implantação, há uma coisa que precisa ser alterada é adicionar o seletor matchLabels para especificação

Outra solução alternativa pode ser usar o leme 3, que não usa o timão.

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

Oi, ao tentar isso, recebo o seguinte:

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

Comando 'kubectl' não encontrado, mas pode ser instalado com:

snap install kubectl
Pergunte ao seu administrador.

jenkins @ jenkin : ~ / .kube $

Resultado de helm version : v2.14.3
Saída de kubectl version : cliente: v1.15.3, servidor: v1.16.0-rc.1
Provedor / plataforma de nuvem (AKS, GKE, Minikube etc.): Serviço IBM Cloud Kubernetes

$ 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 o helm está tentando criar uma implantação tiller com: apiVersion: extensions/v1beta1
De acordo com: https://kubernetes.io/blog/2019/07/18/api-deprecations-in-1-16
que não é mais suportado.

estou recebendo este erro: como posso resolver isso ??

root @ jenkin : ~ # helm init --service-account tiller
$ HELM_HOME foi configurado em /root/.helm.
Erro: erro de instalação: desconhecido (post deployments.extensions)
root @ jenkin : ~ #

Esta é uma solução alternativa de curto prazo:

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

Na verdade, não é bom o suficiente. Ainda recebo um erro:

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

Isso pode ser corrigido com:

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

Estou recebendo este erro :

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

Comando 'kubectl' não encontrado, mas pode ser instalado com:

snap install kubectl
Pergunte ao seu administrador.

jenkins @ jenkin : ~ / .helm $

Solução 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 -

Solução 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 -

Você não pode atualizar o recurso com kubectl create

@ikarlashov fácil de substituir 'criar' por 'aplicar'. O one-liner acima presume que você ainda não tentou criar os recursos.