Helm: Helm dice que el timón está instalado Y no pudo encontrarlo

¿Cuál es la salida de kubectl -n kube-system get pods ?

helm init solo comprueba que el manifiesto de implementación se envió a kubernetes. Si desea verificar si la cultivadora está activa y lista, use helm init --wait . :)

También recibo el mensaje Error: could not find tiller , usando Kubernetes en Docker para escritorio (Mac).

helm version
Client: &version.Version{SemVer:"v2.10.0", GitCommit:"9ad53aac42165a5fadc6c87be0dea6b115f93090", GitTreeState:"clean"}
Error: could not find tiller

Ejecutar kubectl -n kube-system get pods en el contexto docker-for-desktop me da:

etcd-docker-for-desktop                      1/1       Running   1          8m
kube-apiserver-docker-for-desktop            1/1       Running   1          8m
kube-controller-manager-docker-for-desktop   1/1       Running   1          8m
kube-dns-86f4d74b45-t8pq8                    3/3       Running   0          11m
kube-proxy-d6c4q                             1/1       Running   0          9m
kube-scheduler-docker-for-desktop            1/1       Running   1          8m

$ helm init --wait
$HELM_HOME has been configured at /home/ubuntu/.helm.
Warning: Tiller is already installed in the cluster.
(Use --client-only to suppress this message, or --upgrade to upgrade Tiller to the current version.)

Simplemente se cuelga ... Presiono ctrl-c después de 2 minutos

$ kubectl -n kube-system get pods
NAME                                                                 READY     STATUS    RESTARTS   AGE
coredns-59558d567-6qgbv                                              1/1       Running   0          7d
coredns-59558d567-s6w7t                                              1/1       Running   0          7d
dns-controller-b76dfc754-f9vlj                                       1/1       Running   0          7d
etcd-server-events-ip-10-132-1-49.us-west-2.compute.internal         1/1       Running   3          7d
etcd-server-events-ip-10-132-2-171.us-west-2.compute.internal        1/1       Running   0          7d
etcd-server-events-ip-10-132-3-80.us-west-2.compute.internal         1/1       Running   0          7d
etcd-server-ip-10-132-1-49.us-west-2.compute.internal                1/1       Running   3          7d
etcd-server-ip-10-132-2-171.us-west-2.compute.internal               1/1       Running   0          7d
etcd-server-ip-10-132-3-80.us-west-2.compute.internal                1/1       Running   0          7d
kube-apiserver-ip-10-132-1-49.us-west-2.compute.internal             1/1       Running   1          7d
kube-apiserver-ip-10-132-2-171.us-west-2.compute.internal            1/1       Running   1          7d
kube-apiserver-ip-10-132-3-80.us-west-2.compute.internal             1/1       Running   1          7d
kube-controller-manager-ip-10-132-1-49.us-west-2.compute.internal    1/1       Running   0          7d
kube-controller-manager-ip-10-132-2-171.us-west-2.compute.internal   1/1       Running   0          7d
kube-controller-manager-ip-10-132-3-80.us-west-2.compute.internal    1/1       Running   0          7d
kube-proxy-ip-10-132-1-103.us-west-2.compute.internal                1/1       Running   0          7d
kube-proxy-ip-10-132-1-49.us-west-2.compute.internal                 1/1       Running   0          7d
kube-proxy-ip-10-132-2-171.us-west-2.compute.internal                1/1       Running   0          7d
kube-proxy-ip-10-132-2-175.us-west-2.compute.internal                1/1       Running   0          7d
kube-proxy-ip-10-132-3-115.us-west-2.compute.internal                1/1       Running   0          7d
kube-proxy-ip-10-132-3-80.us-west-2.compute.internal                 1/1       Running   0          7d
kube-scheduler-ip-10-132-1-49.us-west-2.compute.internal             1/1       Running   0          7d
kube-scheduler-ip-10-132-2-171.us-west-2.compute.internal            1/1       Running   0          7d
kube-scheduler-ip-10-132-3-80.us-west-2.compute.internal             1/1       Running   0          7d

Interesante. ¿Qué pasa con kubectl -n kube-system get deployments ? Tal vez haya algo mal en el que no se programen nuevas cápsulas. Verifique el estado de esa implementación y vea si algo está sucediendo.

Si ejecuto helm init --wait en mi configuración simple de Docker para escritorio k8s, simplemente se cuelga sin salida.

$ helm init --wait
$HELM_HOME has been configured at ~/.helm.
Warning: Tiller is already installed in the cluster.
(Use --client-only to suppress this message, or --upgrade to upgrade Tiller to the current version.)

Ejecutar kubectl -n kube-system get deployments da:

kubectl -n kube-system get deployments
NAME            DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
kube-dns        1         1         1            1           10h
tiller-deploy   1         0         0            0           10h

$ kubectl -n kube-system get deployments
NAME             DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
coredns          2         2         2            2           7d
dns-controller   1         1         1            1           7d
tiller-deploy    1         0         0            0           7d

Perdón por esto. ¿Pueden ambos probar kubectl -n kube-system describe deployment tiller-deploy ? Es probable que obtenga más información sobre por qué no se está programando un grupo. si no, puede intentar depurar el conjunto de réplicas que implementó la implementación de Kubernetes (jeje: sonrisa :).

https://kubernetes.io/docs/tasks/debug-application-cluster/debug-application/#debugging -replication-controllers

kubectl -n kube-system describe deployment tiller-deploy devuelve:

kubectl -n kube-system describe deployment tiller-deploy
Name:                   tiller-deploy
Namespace:              kube-system
CreationTimestamp:      Tue, 25 Sep 2018 23:36:14 +0100
Labels:                 app=helm
                        name=tiller
Annotations:            deployment.kubernetes.io/revision=2
Selector:               app=helm,name=tiller
Replicas:               1 desired | 0 updated | 0 total | 0 available | 1 unavailable
StrategyType:           RollingUpdate
MinReadySeconds:        0
RollingUpdateStrategy:  1 max unavailable, 1 max surge
Pod Template:
  Labels:           app=helm
                    name=tiller
  Service Account:  tiller
  Containers:
   tiller:
    Image:       gcr.io/kubernetes-helm/tiller:v2.10.0
    Ports:       44134/TCP, 44135/TCP
    Host Ports:  0/TCP, 0/TCP
    Command:
      /tiller
      --listen=localhost:44134
    Liveness:   http-get http://:44135/liveness delay=1s timeout=1s period=10s #success=1 #failure=3
    Readiness:  http-get http://:44135/readiness delay=1s timeout=1s period=10s #success=1 #failure=3
    Environment:
      TILLER_NAMESPACE:    kube-system
      TILLER_HISTORY_MAX:  0
    Mounts:                <none>
  Volumes:                 <none>
Conditions:
  Type             Status  Reason
  ----             ------  ------
  Available        True    MinimumReplicasAvailable
  ReplicaFailure   True    FailedCreate
  Progressing      False   ProgressDeadlineExceeded
OldReplicaSets:    <none>
NewReplicaSet:     tiller-deploy-55bfddb486 (0/1 replicas created)
Events:            <none>

y el juego de réplicas? Básicamente, vaya a la lista de ese documento y vea si encuentra algo útil.

gracias por mí, obtuve el mismo error al describir el conjunto de réplicas que dio el error de que no había creado la cuenta de servicio. Eliminé la implementación (tiller), creé la cuenta de servicio y luego volví a ejecutar y funcionó

el cierre como un problema de grupo, no un problema de timón

El clúster de Kubernetes funciona muy bien, tengo numerosos servicios ejecutándose bajo él. Lo que no funciona es timón / caña.

Usé kubectl -n kube-system delete deployment tiller-deploy y kubectl -n kube-system delete service/tiller-deploy . Entonces helm --init funcionó. Me faltaba eliminar el servicio anteriormente.

¡La solución mabushey funciona!

La solución helm init lugar de helm --init

También me encontré con el problema de @psychemedia .

Después de ejecutar kubectl -n kube-system describe deployment tiller-deploy tuve la misma salida. Y si lees con atención la salida de @psychemedia , dice

...

Conditions:
  Type             Status  Reason
  ----             ------  ------
  Available        True    MinimumReplicasAvailable
  ReplicaFailure   True    FailedCreate
  Progressing      False   ProgressDeadlineExceeded
OldReplicaSets:    <none>
NewReplicaSet:     tiller-deploy-55bfddb486 (0/1 replicas created)
Events:            <none>

El bit importante es ReplicaFailure True FailedCreate y el siguiente NewReplicaSet: tiller-deploy-55bfddb486 (0/1 replicas created) .

Para encontrar cuál es el problema, debería haber corrido.

kubectl -n kube-system describe replicaser tiller-deploy-55bfddb486

(o solo kubectl describe replicaser tiller-deploy-55bfddb486 dependiendo de si el espacio de nombres está configurado o no ... puede encontrarlo enumerando todos los _replicasets_ kubectl get replicaset --all-namespaces ).

La razón por la que no se creó el _replicaset_ debería aparecer en Events: .

De hecho, tuve el mismo problema ejecutándose en un espacio de nombres diferente al de kube-system .
Ver https://github.com/helm/helm/issues/3304#issuecomment -468997006

AVISO: Este ticket no debe cerrarse ya que no hay una solución publicada para este problema, solo una exageración egoísta que los pocos miembros de este hilo dedujeron del estado ReplicaFailure y se reconocen tácitamente entre sí, pero nunca se proporcionaron explícitamente al registro. No se publicaron pasos de reproducción / solución.

Este problema se cerró originalmente porque no se proporcionaron pasos para reproducir el problema original. solución @mabushey 's en https://github.com/helm/helm/issues/4685#issuecomment -433209134 aparece para solucionar los problemas que estaba teniendo con su grupo, pero sin una serie de pasos para reproducir el problema, no podemos identificar qué causa esta situación en primer lugar y, por lo tanto, la cerramos como un ticket de soporte resuelto sin una resolución procesable.

Han pasado 6 meses desde que se abrió este número, así que dudo que podamos averiguar los pasos exactos para reproducir el entorno de @mabushey y @psychemedia . Sin embargo, si puede reproducir el problema de manera confiable, no dude en responder aquí con sus pasos para que podamos comprender mejor cómo ocurre este error y brindar una mejor solución (o mejor aún, identificar una solución para abordar el problema). Luego, podemos volver a abrir este problema para determinar si se puede proporcionar un parche.

Si va a seguir teniendo problemas y la solución @mabushey 's en https://github.com/helm/helm/issues/4685#issuecomment -433 209 134 no funciona para usted, por favor, abra un nuevo ticket de soporte referencia a este tema.

@bacongobbler
El problema ocurre cuando se crea Tiller sin una cuenta de servicio adecuada. Esto sucede por dos razones a. el guión de inicio de helm no hace esto como debería hacerlo. b. el espacio de nombres en cuestión no coincide con una definición de cuenta de servicio existente.

Para recorrerlo, primero debe ejecutar "helm delete" y luego crear un rbac-config.yaml:

'
apiVersion: v1
tipo: ServiceAccount
metadatos:
nombre: timón

espacio de nombres: kube-system

apiVersion: rbac.authorization.k8s.io/v1
tipo: ClusterRoleBinding
metadatos:
nombre: timón
roleRef:
apiGroup: rbac.authorization.k8s.io
tipo: ClusterRole
nombre: cluster-admin
asignaturas:

• tipo: ServiceAccount
  nombre: timón
  espacio de nombres: kube-system
  '

Si necesita usar un espacio de nombres diferente, asegúrese de que más adelante coincida con su instalación de Tiller y de que exista el rol de administrador de clúster (¡generalmente lo hace!)

Luego
$ kubectl crear -f rbac-config.yaml
cuenta de servicio "tiller" creada
"Tiller" de clusterrolebinding creado
$ helm init - tiller de cuenta de servicio --history-max 200

Y estás listo para irte.

Así que traté de crear la cuenta de servicio como lo describe @ datascienceteam01 , lo

Pero el despliegue parece simplemente ... girar. Sin eventos, en particular:

$ kubectl -n kube-system describe deployment tiller-deploy
Name:                   tiller-deploy
Namespace:              kube-system
CreationTimestamp:      Sun, 28 Apr 2019 10:26:24 -0700
Labels:                 app=helm
                        name=tiller
Annotations:            <none>
Selector:               app=helm,name=tiller
Replicas:               1 desired | 0 updated | 0 total | 0 available | 0 unavailable
StrategyType:           RollingUpdate
MinReadySeconds:        0
RollingUpdateStrategy:  1 max unavailable, 1 max surge
Pod Template:
  Labels:           app=helm
                    name=tiller
  Service Account:  tiller
  Containers:
   tiller:
    Image:       gcr.io/kubernetes-helm/tiller:v2.13.1
    Ports:       44134/TCP, 44135/TCP
    Host Ports:  0/TCP, 0/TCP
    Liveness:    http-get http://:44135/liveness delay=1s timeout=1s period=10s #success=1 #failure=3
    Readiness:   http-get http://:44135/readiness delay=1s timeout=1s period=10s #success=1 #failure=3
    Environment:
      TILLER_NAMESPACE:    kube-system
      TILLER_HISTORY_MAX:  200
    Mounts:                <none>
  Volumes:                 <none>
OldReplicaSets:            <none>
NewReplicaSet:             <none>
Events:                    <none>

Lamento resucitar un hilo muerto y los síntomas se ven un poco diferentes. Mi configuración es un poco frankenconfig: Docker Desktop ejecutándose en Windows 10, helm instalado bajo el shell de Ubuntu (Servicios para Linux). Kubernetes parece feliz; Puedo hacer todas las cosas habituales de kubectl. Solo estoy teniendo algunos problemas para hacer que helm init funcione.

¿Alguna idea sobre cómo solucionar problemas?

Voy a probar el inicio de helm en Windows (¡si puedo averiguar cómo instalar helm en Windows!) Si no puedo resolverlo en el shell de Ubuntu bash, pero realmente me gustaría asegurarme de que esté funcionando bajo el shell de Linux, porque ese es mi entorno de desarrollo "real".

Además, lo siento por deving en Windows. Ahora mismo, al menos, no tengo otras opciones :)

este problema es un dolor durante mucho tiempo. Pensando en mudarse de Helm. ¡¡suspiro!!. Cada vez que mis tuberías fallan debido a esto.

@Tenseiga ¿Podría explicarnos el tema para que podamos ayudarlo? Puede darnos información como helm version salida, kubectl version output, and also check anything relating to the tiller pod logs, tiller deployment, tiller replica set using kubectl describe`. ¡Haremos todo lo posible para solucionarlo!

@tomcanham, usted también podría ayudar aquí, para reproducir el problema, ¡si todavía lo enfrenta!

¿Algún avance en esto?

helm init (sin opciones adicionales) fue el boleto para mí que instaló / configuró Tiller. todo va bien después de eso.

Este problema me sucede cada vez que trato de cambiar de un clúster a otro usando "config set-context", el Kubernetes cambia el contexto muy bien pero el timón no, en su lugar emite "Error: no se pudo encontrar el timón", cuando intento "helm init" me sale "Advertencia: Tiller ya está instalado en el clúster".
Si vuelvo a cambiar, el timón de contexto funciona de nuevo. No estoy seguro de si es relevante, pero el clúster en el que está trabajando es PKS y en el que no está trabajando es EKS.

Después de mucho golpearme la cabeza contra la pared, descubrí por qué estaba viendo este problema ... De acuerdo con la documentación de aws para EKS AQUÍ , estableces la variable de entorno TILLER_NAMESPACE en tiller . Esto estaba causando que el binario de helm implementara tiller en el espacio tiller nombres

Después de desarmar esa variable y volver a implementar, todo estuvo bien ...

También puede anular esas configuraciones con argumentos de línea de comando documentados AQUÍ

HTH

¿Por qué está cerrado si tanta gente tiene problemas con esto?

Abrí una pregunta en stackoverflow: https://stackoverflow.com/questions/57906429/helm-init-says-tiller-is-already-on-cluster-but-its-not

¿Habéis probado todos?

kubectl apply -f tiller.yaml
helm init --service-account tiller --upgrade

tiller.yaml:

kind: ServiceAccount
apiVersion: v1
metadata:
  name: tiller
  namespace: kube-system
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: tiller
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
  - kind: ServiceAccount
    name: tiller
    namespace: kube-system

Esto es parte de mi script up.sh para iniciar mi clúster de desarrollo desde cero. La bandera --upgrade era necesaria para permitir su ejecución varias veces. Creo que el error original de no poder encontrar el timón está relacionado con la instalación, pero el pod tiller-deploy-* no se encuentra en kube-system .

Funcionó para mí siguiendo https://helm.sh/docs/using_helm/#tiller -and-role-based-access-control
Simplemente crea el yaml y ejecuta el comando

El caso es que el error es engañoso. Ese es el problema en mis ojos.

me sale el siguiente error

kubeflow @ masternode : ~ $ helm init --service-account tiller --upgrade
$ HELM_HOME se ha configurado en /home/kubeflow/.helm.
Error: error de instalación: el servidor no pudo encontrar el recurso solicitado
kubeflow @ masternode : ~ $

agradecería cualquier ayuda

kubectl -n kube-system eliminar implementación tiller-deploy

Funciona pero con un pequeño cambio.

usar $ helm init