Nous avons évité de mettre à jour tiller vers apps / v1 dans le passé en raison de la complexité helm init --upgrade réconciliation des déploiements extensions/v1beta1 et apps/v1 tiller. Il semble qu'une fois que nous aurons commencé à prendre en charge Kubernetes 1.16.0, nous devrons gérer ce cas à l'avenir et migrer vers la nouvelle version apiVersion.

Voici une solution de contournement à court terme:

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

En fait, ce n'est pas assez bon. J'obtiens toujours une erreur:

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

Cela peut être corrigé avec:

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

Agréable! Vous pourrez peut-être obtenir le même effet avec le drapeau --override qu'avec des hacks sed fous :)

Agréable! Vous pourrez peut-être obtenir le même effet avec le drapeau --override qu'avec des hacks sed fous :)

Oui, mais je peux copier et coller ses fous hacks sed, alors que ce helm init --override "apiVersion"="apps/v1" ne fonctionne tout simplement pas. Ok, le hack sed ne fonctionne pas non plus.

La solution de contournement actuelle semble être quelque chose comme ceci:

helm init --output yaml> tiller.yaml
et mettez à jour le fichier tiller.yaml:

• passer aux applications / v1
• ajouter le champ de sélection

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

Le sed suivant fonctionne pour moi:

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 -

Le problème avec la solution @mattymo (en utilisant le correctif kubectl --local) est qu'elle semble ne pas fonctionner lorsque son entrée contient plusieurs ressources (ici un déploiement et un service).

Kubernetes 1.16.0 est sorti hier: 18/09/2018.
Helm est cassé sur cette dernière version de Kubernetes à moins que la solution ci-dessus ne soit utilisée.

Quand ce problème sera-t-il résolu et quand Helm 2.15.0 sera-t-il publié?

Si vous voulez en utiliser un de moins :)
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 -

Merci!

Aujourd'hui j'ai rencontré le même problème, j'ai changé le label par moi-même. Je change le libellé en apps/v1 et ajoute selector part, à partir de maintenant, il fonctionne très bien, voici mon fichier 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 tu es mon héros! J'avais du mal avec la strophe selector .

Aujourd'hui j'ai rencontré le même problème, j'ai changé le label par moi-même. Je change le libellé en apps/v1 et ajoute selector part, à partir de maintenant, il fonctionne très bien, voici mon fichier 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: {}

comment changer ? pouvez-vous décrire plus de détails?

Aujourd'hui j'ai rencontré le même problème, j'ai changé le label par moi-même. Je change le libellé en apps/v1 et ajoute selector part, à partir de maintenant, il fonctionne très bien, voici mon fichier 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 comment changer et pouvez-vous décrire plus de détails?

Aujourd'hui j'ai rencontré le même problème, j'ai changé le label par moi-même. Je change le libellé en apps/v1 et ajoute selector part, à partir de maintenant, il fonctionne très bien, voici mon fichier 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 comment changer et pouvez-vous décrire plus de détails?

Par exemple, vous pouvez utiliser helm init --service-account tiller --tiller-namespace kube-system --debug pour imprimer les manifestes au format YAML, l'option --debug fera

@ gm12367 Oui, je peux voir l'impression mais juste la sortie. Alors, quelle commande je peux changer la sortie?

@ gm12367 Je veux changer apps / v1 et ajouter une partie de sélecteur

@ puww1010 Je viens de rediriger la sortie dans un fichier, puis j'ai utilisé VIM pour la modifier. Ci-dessous les commandes comme référence.

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

si votre environnement go est configuré et que vous ne pouvez pas attendre que le PR suivant qui corrige ce problème [Helm init compatible avec Kubernetes 1.16] # 6462 soit fusionné, vous pouvez toujours faire:

Construire

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

Test:

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 obtenir 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 Toujours le même problème après avoir suivi vos instructions

@jbrette Toujours le même problème après avoir suivi vos instructions

On dirait que vous avez tapé "helm" au lieu de "./bin/helm".... donc vous utilisez l'ancienne version du binaire.

Une fois l'initialisation réussie, vous ne pourrez pas installer un package de graphiques à partir du référentiel tant qu'il n'aura pas été remplacé par extensions / v1beta1.
Voici comment adapter n'importe quel graphique du référentiel pour k8s v1.16.0
L'exemple est basé sur le graphique de Prométhée.

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

Remplacez extensions / v1beta1 par 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}' {} +`

NetworkPolicy apiVersion est bien géré par _helpers.tpl pour les graphiques où il est utilisé.

Remplacez les extensions / v1beta1 par apps / v1 dans 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}' {} +`

Créez un nouveau package:

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

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

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

PS Pour certains graphiques avec des dépendances, vous devrez peut-être utiliser helm dependency update et remplacer les tgz dépendants par des correctifs, le cas échéant.

Obtenir la même erreur lors de l'exécution de helm init --history-max 200

production

$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

Cette branche fonctionne https://github.com/keleustes/helm/tree/kube16. Vous pouvez construire la branche vous-même. J'ai également téléchargé le binaire ici pour votre commodité https://s3-us-west-2.amazonaws.com/bin.cryptexlabs.com/github.com/keleustes/helm/kube16/darwin/helm. Une mise en garde est que vous devez utiliser l'indicateur d'image canary helm init --canary-image car la construction n'est pas publiée

Vous ne devriez pas avoir besoin de l'image canari pour faire ce travail. Je suggérerais d'utiliser helm init --tiller-image gcr.io/kubernetes-helm/tiller:v2.14.3 comme @jbrette mentionné plus tôt si vous voulez essayer # 6462.

Je recommande aux utilisateurs d'essayer l' une des solutions de contournement fournies plus tôt avant d'essayer un PR de toute façon; de cette façon, ils peuvent continuer à utiliser Helm 2.14.3 au lieu d'une branche de développement personnalisée qui est toujours en cours de révision.

Quand je fais la commande, il le déploie mais après cela peut le voir dans les pods et dit Erreur du serveur (NotFound): pods "tiller-deploy" non trouvés

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

Mais quand je fais kubectl obtenir des pods - tous les espaces de noms ne peuvent pas voir les pods
NAMESPACE NOM READY STATUS RESTARTS AGE
kube-system coredns-5644d7b6d9-559hw 1/1 Fonctionnement 0 23h
kube-system coredns-5644d7b6d9-xcmjd 1/1 Fonctionnement 0 23h
kube-system etcd-fmp 1/1 Fonctionnement 0 24h
kube-system kube-apiserver-fmp 1/1 Fonctionnement 0 24h
kube-system kube-controller-manager-fmp 1/1 Fonctionnement 1 24h
kube-system kube-flannel-ds-amd64-ffx2g 1/1 Fonctionnement 0 23h
kube-system kube-proxy-lfvrz 1/1 Fonctionnement 0 24h
kube-system kube-scheduler-fmp 1/1 Fonctionnement 0 24h

kubectl récupère tous --all-namespaces | fraise grep
service kube-system / déploiement de la barre 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 Je pense que vous n'avez pas de compte de service de barre franche. Veuillez le créer, puis le déploiement créera également le module de barre franche.

Merci!

@DanielIvaylov Je pense que vous n'avez pas de compte de service de barre franche. Veuillez le créer, puis le déploiement créera également le module de barre franche.

Merci!

Désolé, je suis nouveau, j'ai pensé que cela allait le démarrer. Comment démarrer le compte de service de barre franche?

@DanielIvaylov

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

Ajout du drapeau ci-dessous au serveur api (/etc/kubernetes/manifests/kube-apiserver.yaml) qui a temporairement réactivé ces API obsolètes.

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

Cela a corrigé la barre v2

Pour les utilisateurs de Windows, nous avons pu installer / mettre à niveau la barre franche via PowerShell comme ceci:

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

Voici une solution de contournement à court terme:

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

En fait, ce n'est pas assez bon. J'obtiens toujours une erreur:

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

Cela peut être corrigé avec:

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

pour moi le patch kubectl est suspendu
aucun message dans le fichier / var / log / syslog

les comptes de service existent déjà

kubeflow @ masternode : ~ $ kubectl --namespace kube-system créer une barre franche
Erreur du serveur (Déjàexiste): les comptes de service "tiller" existent déjà
kubeflow @ masternode : ~ $ kubectl create clusterrolebinding tiller --clusterrole cluster-admin --serviceaccount = kube- system: tiller
Erreur du serveur (alreadyExists): clusterrolebindings.rbac.authorization.k8s.io "tiller" existe déjà

pouvez-vous s'il vous plaît conseiller

exécution de ce qui suit

export PATH = $ PATH: / usr / local / bin
quelle barre
quelle barre
installation de la barre \
--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

revient avec

/ usr / local / bin / helm
/ usr / local / bin / tiller
Erreur: impossible de trouver la barre

apprécier toute aide car c'est maintenant un bouchon de spectacle

@cyrilthank Il semble que l'erreur de barre franche soit due au fait qu'il n'y a pas de déploiement de barre en cours d'exécution, essayez d'exécuter cette commande pour installer la barre:
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 devrait renvoyer la version du serveur (tiller) si elle fonctionne correctement

Merci Monsieur.
Vous nous avez aidés à nous permettre de passer à l'étape suivante de kubeflow

ok maintenant je pense que j'ai ce problème
https://github.com/kubeflow/kubeflow/issues/4184
de retour en tant que bloqueur

Je l'apprécierais beaucoup si vous pouviez m'aider avec des conseils sur la façon dont je peux obtenir de l'aide sur https://github.com/kubeflow/kubeflow/issues/4184

@cyrilthank essayez les étapes fournies ci-dessus: https://github.com/helm/helm/issues/6374#issuecomment -533853888
Vous devez remplacer les versions obsolètes de l'API par les nouvelles

kubeflow_workaround_and_error_traces.txt

Merci Monsieur pour les réponses de vos patients, en particulier en gardant ce problème ouvert

Désolé à ce sujet, mais il semble que je fasse quelque chose de mal dans les étapes de la solution de contournement

Merci si vous pouviez revoir les étapes des traces ci-jointes et me conseiller sur ce que je fais mal

@cyrilthank, il vous suffit d'exécuter les commandes sed sur vos yamls kubeflow pour remplacer l'ancienne extension api par la nouvelle (pas besoin de déployer du tout prometheus 😆). Désolé si je ne me suis pas assez bien exprimé.
Le correctif remplace essentiellement extensions/v1beta1 par apps/v1 dans votre kubeflow dpl yamls

ah alors j'ai fait une copie stupide :(

mon KFAPP = / nfsroot / kf-poc

je semble toujours recevoir quelques messages et l'erreur finale

pouvez-vous s'il vous plaît aider car je dépend de vous maintenant pour passer à l'étape suivante sur kubeflow

kubeflow_workaround_sed_and_error_traces.txt

@cyrilthank vous avez juste besoin d'exécuter les commandes sed sur vos yamls kubeflow pour remplacer l'ancienne extension api par la nouvelle (pas besoin de déployer prometheus en riant). Désolé si je ne me suis pas assez bien exprimé.
Le correctif remplace essentiellement extensions/v1beta1 par apps/v1 dans votre kubeflow dpl yamls

apps/v1beta2 aussi avec apps/v1

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

Merci beaucoup @uniuuu pour votre aide
Pouvez-vous s'il vous plaît indiquer où / comment obtenir les fichiers yaml référencés dans 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

demandant car après avoir apporté les modifications sed, nous avons toujours rencontré les erreurs référencées dans

pouvez-vous s'il vous plaît aviser si l'étape

kubectl convertir -f--output-version/

doit être exécuté pour chaqueétant chaque fichier yaml dans l'emplacement KFAPP, y compris .kache

Si vous avez appliqué la solution de contournement mentionnée ci-dessus lorsque vous travaillez avec helm init et que vous obtenez toujours l'erreur suivante lorsque vous essayez des choses comme helm version , c'est parce que helm deployment ne peut être trouvé.

Error: could not find tiller

Vous devez exécuter kubectl get events --all-namespaces | grep -i tiller pour savoir pourquoi il n'est pas prêt.

Par exemple, mon problème est simplement comme ci-dessous, car je n'ai pas besoin de serviceaccount "tiller" avec 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

J'ai donc fait le travail sans le compte de service

- 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 J'ai supprimé votre commentaire car il n'est pas pertinent pour la discussion impliquée ici. Veuillez continuer le suivi dans kubeflow / kubeflow # 4184. Merci!

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 -

Légère correction

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 Je viens de rediriger la sortie dans un fichier, puis j'ai utilisé VIM pour la modifier. Ci-dessous les commandes comme référence.

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

J'ai essayé de faire ça. Après avoir édité le fichier dans VIM, j'utilise la commande kubectl apply , mais cela ne semble rien faire. Lorsque j'exécute à nouveau helm init --service-account tiller --tiller-namespace kube-system --debug >> helm-init.yaml ou helm init --output yaml les modifications n'ont pas été appliquées. Quelqu'un d'autre a-t-il vécu cela?

Si vous voulez en utiliser un de moins :)
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 -

Merci!

Je viens de mettre à niveau nos k8 et j'ai fait face à ce problème et j'ai utilisé la solution ci-dessus. Il crée un déploiement mais le réplicaset échoue et c'est ce que j'obtiens 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

Où puis-je trouver un fichier yaml pour créer ce compte de service?

@DanielIvaylov

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

Cela a résolu mon problème!

6462 a été fusionné et sera disponible dans la prochaine version (2.15.0). Pour l'instant, n'hésitez pas à utiliser les solutions de contournement fournies ci-dessus ou à utiliser la version Canary .

Merci tout le monde!

L'image Canary produit toujours la même erreur sauf si elle n'a pas encore cette fusion,

@ puww1010 Je viens de rediriger la sortie dans un fichier, puis j'ai utilisé VIM pour la modifier. Ci-dessous les commandes comme référence.

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

J'ai essayé de faire ça. Après avoir édité le fichier dans VIM, j'utilise la commande kubectl apply , mais cela ne semble rien faire. Lorsque j'exécute à nouveau helm init --service-account tiller --tiller-namespace kube-system --debug >> helm-init.yaml ou helm init --output yaml les modifications n'ont pas été appliquées. Quelqu'un d'autre a-t-il vécu cela?

Ouais, ça arrive aussi pour moi.

Vous devrez peut-être changer l'emplacement de l'image en gcr.azk8s.cn/kubernetes-helm/tiller:v2.14.3 l'emplacement gcr.io semble être bloqué.

Vous devrez peut-être changer l'emplacement de l'image en gcr.azk8s.cn/kubernetes-helm/ tiller: v2.14.3 l'emplacement gcr.io semble être bloqué.

Bien qu'il s'agisse d'un problème tout à fait valide, ce problème est légèrement orthogonal au problème présent dans ce numéro, gcr.io est malheureusement bloqué en Chine. Voir https://github.com/helm/charts/issues/14607 pour plus d'informations.

nous avons pu résoudre ce problème en rétrogradant la version de kubernetes à 1.15.4

Merci @UmamaheshMaxwell pour ce partage.

Pouvez-vous s'il vous plaît partager les étapes que vous avez utilisées pour restaurer la version de Kubernetes?

@cyrilthank si c'est minikube, minikube config set kubernetes-version v1.15.4

Merci @UmamaheshMaxwell pour ce partage.

Pouvez-vous s'il vous plaît partager les étapes que vous avez utilisées pour restaurer la version de Kubernetes?

@cyrilthank nous avons utilisé nos propres machines virtuelles (Ubuntu 18+), voici les réglages pour installer la version k8s 1.15.4

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

--pod-network-cidr=10.244.10.0/16 - flanelle
--apiserver-advertise-address=x.x.x.x - IP privée de votre VM (maître)
--apiserver-cert-extra-sans=x.x.x.x - IP publique de votre VM (Master) (Ceci est obligatoire, si vous essayez d'accéder à votre Master depuis votre machine locale.

Remarque: suivez le lien ci-dessous pour configurer un fichier kubeconfig pour un cluster Kubernetes auto-hébergé (http://docs.shippable.com/deploy/tutorial/create-kubeconfig-for-self-hosted-kubernetes-cluster/)

Faites-moi savoir si vous avez encore des questions.

@cyrilthank si c'est minikube, jeu de configuration minikube kubernetes-version v1.15.4

Merci @MrSimonEmms le mien n'est pas mini Je pense que je vais devoir suivre les pas de @UmamaheshMaxwell

Merci @UmamaheshMaxwell pour ce partage.
Pouvez-vous s'il vous plaît partager les étapes que vous avez utilisées pour restaurer la version de Kubernetes?

@cyrilthank nous utilisons nos propres machines virtuelles (Ubuntu 18+), voici les réglages pour installer la version 1.15.4 de k8s

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

--pod-network-cidr = 10.244.10.0 / 16 - flanelle
--apiserver-advertise-address = xxxx - IP privée de votre VM (maître)
--apiserver-cert-extra-sans = xxxx - IP publique de votre VM (Master) (Ceci est obligatoire, si vous essayez d'accéder à votre Master depuis votre machine locale.
Remarque: suivez le lien ci-dessous pour configurer un fichier kubeconfig pour un cluster Kubernetes auto-hébergé (http://docs.shippable.com/deploy/tutorial/create-kubeconfig-for-self-hosted-kubernetes-cluster/)
Faites-moi savoir si vous avez encore des questions.

Merci @UmamaheshMaxwell pour la réponse de votre patient

J'ai une configuration kubernetes 1.16 existante. Pouvez-vous confirmer si je peux essayer d'exécuter ces étapes?

Merci @UmamaheshMaxwell pour ce partage.
Pouvez-vous s'il vous plaît partager les étapes que vous avez utilisées pour restaurer la version de Kubernetes?
@cyrilthank nous utilisons nos propres machines virtuelles (Ubuntu 18+), voici les réglages pour installer la version 1.15.4 de k8s
réinitialisation 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-advertise-address = xxxx --apiserver-cert-extra-sans = xxxx --kubernetes-version "1.15.4"
--pod-network-cidr = 10.244.10.0 / 16 - flanelle
--apiserver-advertise-address = xxxx - IP privée de votre VM (maître)
--apiserver-cert-extra-sans = xxxx - IP publique de votre VM (Master) (Ceci est obligatoire, si vous essayez d'accéder à votre Master depuis votre machine locale.
Remarque: suivez le lien ci-dessous pour configurer un fichier kubeconfig pour un cluster Kubernetes auto-hébergé (http://docs.shippable.com/deploy/tutorial/create-kubeconfig-for-self-hosted-kubernetes-cluster/)
Faites-moi savoir si vous avez encore des questions.

Merci @UmamaheshMaxwell pour la réponse de votre patient

J'ai une configuration kubernetes 1.16 existante. Pouvez-vous confirmer si je peux essayer d'exécuter ces étapes?

Ouais @cyrilthank , même nous avions kubernetes 1.16.1 mais nous avons dû le ramener à 1.15.4 , ci-dessous le lien si vous voulez le configurer à partir de zéro.

Version du système d'exploitation de VM

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

Nettoyer les kuberenetes

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

Configurer Kubernetes (_Both Master et Node_)
https://www.howtoforge.com/tutorial/how-to-install-kubernetes-on-ubuntu/
(vous feriez mieux d'automatiser les étapes suggérées dans le lien ci-dessus autant que vous le pouvez, pour gagner du temps)

Faites-moi savoir si vous avez encore besoin d'aide. Happy Journey avec roll back :), j'espère que vous avez un bon voyage avec lui.

Vous devrez peut-être changer l'emplacement de l'image en gcr.azk8s.cn/kubernetes-helm/ tiller: v2.14.3 l'emplacement gcr.io semble être bloqué.

Bien qu'il s'agisse d'un problème tout à fait valide, ce problème est légèrement orthogonal au problème présent dans ce numéro, gcr.io est malheureusement bloqué en Chine. Voir helm / charts # 14607 pour plus d'informations.

Je ne suis pas en Chine, mais aux États-Unis. Mais je pense que mon VPN a bloqué ce site. Quoi qu'il en soit, j'ai suivi toutes les étapes décrites dans ce fil et je ne pouvais pas le faire fonctionner jusqu'à ce que j'essaie d'obtenir l'image manuellement et que je vois qu'elle ne répond pas - juste quelque chose d'autre à essayer au cas où quelqu'un d'autre se retrouverait coincé au même endroit que moi.

J'obtiens également l'erreur:

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

J'essaie une solution proposée dans ce numéro, en particulier celui-ci . Cependant, après avoir modifié le fichier tiller.yaml en conséquence, je ne suis pas en mesure de mettre à jour la configuration. J'essaye la commande suivante afin d'appliquer les changements / mettre à jour la configuration:

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

Mais alors, si je cours:

$ helm init --output yaml > tiller2.yaml

Le fichier tiller2.yaml affiche:

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

Fondamentalement, les changements ne sont pas reflétés. Je suppose donc que je ne mets pas à jour correctement la configuration. Quelle serait la bonne façon de procéder?

EDIT : j'ai réussi à le faire fonctionner. J'utilise Minikube, et pour le faire fonctionner, j'ai d'abord rétrogradé la version Kubernetes à 1.15.4.

minikube delete
minikube start --kubernetes-version=1.15.4

Ensuite, j'utilisais un proxy, j'ai donc dû ajouter l'IP de Minikube à la liste NO_PROXY: 192.168.99.101 dans mon cas. Voir: https://minikube.sigs.k8s.io/docs/reference/networking/proxy/

Remarque: après quelques tests supplémentaires, peut-être que la rétrogradation n'est pas nécessaire, et peut-être qu'il ne me manquait que l'étape NO_PROXY. J'ai ajouté tous les 192.168.99.0/24 , 192.168.39.0/24 et 10.96.0.0/12 au paramètre NO_PROXY et maintenant cela semble fonctionner correctement.

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

Cela a fonctionné pour moi, merci beaucoup

À mesure que l'API Kubernetes évolue, les API sont périodiquement réorganisées ou mises à niveau. Lorsque les API évoluent, l'ancienne API est obsolète et finalement supprimée.

La version v1.16 cessera de servir les versions d'API obsolètes suivantes au profit de versions d'API plus récentes et plus stables:

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 version v1.20 cessera de servir les versions d'API obsolètes suivantes au profit de versions d'API plus récentes et plus stables:

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.

Que faire

• Modifier les fichiers YAML pour référencer les nouvelles API
• Mettez à jour les intégrations et les contrôleurs personnalisés pour appeler les nouvelles API
• Mettre à jour les outils tiers (contrôleurs d'entrée, systèmes de livraison continue) pour appeler les nouvelles API

Faire référence à :

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

En tant que helm n00b qui utilise minikube, j'ai pu contourner ce problème en définissant une version de kubernetes comme ceci:

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

J'espère que cela aide!

@PierreF J'ai utilisé votre solution (https://github.com/helm/helm/issues/6374#issuecomment-533186177) avec k8s v1.16.1 et helm v2.15.0 et le timon ne fonctionne pas.

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

@ joshprzybyszewski-wf J'ai utilisé la commande suivante

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

Et maintenant,

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

Voici une solution de contournement à court terme:

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

En fait, ce n'est pas assez bon. J'obtiens toujours une erreur:

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

Cela peut être corrigé avec:

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

vous avez manqué d'ajouter le sélecteur de publication macthLabels .

J'ai été redirigé vers la solution de

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

Ce problème a été corrigé dans Helm

J'ai été redirigé vers la solution de

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

Vérifiez les fichiers yaml, dans la plupart des cas, cette ligne référencée a {} ou [] et a encore d'autres éléments définis en dessous qui provoquent l'erreur. Dans la plupart des cas, le problème se situe dans le fichier values.yaml, sinon vérifiez la section des modèles du graphique.

Juste un petit mot sur la @PierreF et @mihivagyok . Celles-ci ne fonctionnaient pas pour moi lorsque j'utilise des repos de barre privés.

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

Je suppose que cela se produit parce que helm init n'est pas exécuté, génère simplement un fichier yaml. J'ai corrigé cela en exécutant helm init -c en supplément.

dans k8s v1.16.6, la sortie d'initialisation de la barre nécessite un sélecteur de spécifications fyi.

La solution de contournement actuelle semble être quelque chose comme ceci:

helm init --output yaml> tiller.yaml
et mettez à jour le fichier tiller.yaml:

• passer aux applications / v1
• ajouter le champ de sélection

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

Cela fonctionne, puisque kubernetes change apiVersion apps / v1 en pour le déploiement, il y a une chose à changer est que nous devons ajouter le sélecteur matchLabels pour les spécifications

Une autre solution de contournement peut être d'utiliser la barre 3, qui n'utilise pas de barre franche.

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

Salut, en essayant ceci, j'obtiens ceci:

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

La commande 'kubectl' est introuvable, mais peut être installée avec:

snap installer kubectl
Veuillez demander à votre administrateur.

jenkins @ jenkin : ~ / .kube $

Sortie de helm version : v2.14.3
Sortie de kubectl version : client: v1.15.3, serveur: v1.16.0-rc.1
Fournisseur / plate-forme de cloud (AKS, GKE, Minikube, etc.): Service 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:
. 
.
.

On dirait que helm essaie de créer tiller Déploiement avec: apiVersion: extensions/v1beta1
Selon: https://kubernetes.io/blog/2019/07/18/api-deprecations-in-1-16
qui n'est plus pris en charge.

j'obtiens cette erreur: comment puis-je le résoudre ???

root @ jenkin : ~ # helm init - tiller de compte de service
$ HELM_HOME a été configuré dans /root/.helm.
Erreur: erreur d'installation: inconnue (post deployments.extensions)
racine @ jenkin : ~ #

Voici une solution de contournement à court terme:

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

En fait, ce n'est pas assez bon. J'obtiens toujours une erreur:

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

Cela peut être corrigé avec:

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

J'obtiens cette erreur:

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

La commande 'kubectl' est introuvable, mais peut être installée avec:

snap installer kubectl
Veuillez demander à votre administrateur.

jenkins @ jenkin : ~ / .helm $

Solution de contournement, en utilisant 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 -

Solution de contournement, en utilisant 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 -

Vous ne pouvez pas mettre à jour la ressource avec kubectl create

@ikarlashov est assez simple pour remplacer «créer» par «appliquer». Le one-line ci-dessus suppose que l'on n'a pas encore essayé de créer les ressources.