kubernetes - the - Helm: Error: no se encontró el nombre de la versión disponible

helm version (6)

Estoy recibiendo un par de errores con Helm que no puedo encontrar explicaciones para otros lugares. Los dos errores están abajo.

Error: no available release name found Error: the server does not allow access to the requested resource (get configmaps)

Más detalles de los dos errores se encuentran en el bloque de código más abajo.

He instalado un cluster Kubernetes en Ubuntu 16.04. Tengo un maestro (K8SMST01) y dos nodos (K8SN01 y K8SN02).

Esto fue creado usando kubeadm usando Weave network para 1.6+.

Todo parece funcionar perfectamente bien en lo que respecta a Despliegues, Servicios, Pods, etc ... El DNS parece funcionar bien, lo que significa que los pods pueden acceder a los servicios usando el nombre DNS (myservicename.default).

El uso de "helm create" y "helm search" funciona, pero la interacción con la implementación del timón no parece funcionar. Tiller se instala y ejecuta de acuerdo con la documentación de instalación de Helm.

root@K8SMST01:/home/blah/charts# helm version Client: &version.Version{SemVer:"v2.3.0", GitCommit:"d83c245fc324117885ed83afc90ac74afed271b4", GitTreeState:"clean"} Server: &version.Version{SemVer:"v2.3.0", GitCommit:"d83c245fc324117885ed83afc90ac74afed271b4", GitTreeState:"clean"} root@K8SMST01:/home/blah/charts# helm install ./mychart Error: no available release name found root@K8SMST01:/home/blah/charts# helm ls Error: the server does not allow access to the requested resource (get configmaps)

Aquí están las vainas para correr:

root@K8SMST01:/home/blah/charts# kubectl get pods -n kube-system -o wide NAME READY STATUS RESTARTS AGE IP NODE etcd-k8smst01 1/1 Running 4 1d 10.139.75.19 k8smst01 kube-apiserver-k8smst01 1/1 Running 3 19h 10.139.75.19 k8smst01 kube-controller-manager-k8smst01 1/1 Running 2 1d 10.139.75.19 k8smst01 kube-dns-3913472980-dm661 3/3 Running 6 1d 10.32.0.2 k8smst01 kube-proxy-56nzd 1/1 Running 2 1d 10.139.75.19 k8smst01 kube-proxy-7hflb 1/1 Running 1 1d 10.139.75.20 k8sn01 kube-proxy-nbc4c 1/1 Running 1 1d 10.139.75.21 k8sn02 kube-scheduler-k8smst01 1/1 Running 3 1d 10.139.75.19 k8smst01 tiller-deploy-1172528075-x3d82 1/1 Running 0 22m 10.44.0.3 k8sn01 weave-net-45335 2/2 Running 2 1d 10.139.75.21 k8sn02 weave-net-7j45p 2/2 Running 2 1d 10.139.75.20 k8sn01 weave-net-h279l 2/2 Running 5 1d 10.139.75.19 k8smst01

Creo que es un problema de RBAC. Parece que el timón no está listo para el RBAC de 1.6.1.

Hay un problema abierto para esto en Helm''s Github.

https://github.com/kubernetes/helm/issues/2224

"Al instalar un clúster por primera vez con kubeadm v1.6.1, la inicialización establece de manera predeterminada la configuración del acceso controlado por RBAC, que confunde con los permisos que necesita Tiller para realizar instalaciones, buscar componentes instalados, etc. Helm init funciona sin problemas. , pero la lista de timones, la instalación de timones, etc., no funcionan, citando algún permiso faltante u otro ".

Un trabajo temporal alrededor ha sido sugerir:

"Nosotros" deshabilitamos "RBAC usando el comando kubectl create clusterrolebinding permissive-binding --clusterrole = cluster-admin --user = admin --user = kubelet --group = system: serviceaccounts;"

Pero no puedo hablar por su validez. La buena noticia es que este es un problema conocido y se está trabajando para solucionarlo. Espero que esto ayude.

Según https://github.com/kubernetes/helm/issues/2224#issuecomment-356344286 , los siguientes comandos resolvieron el error también para mí:

kubectl create serviceaccount --namespace kube-system tiller kubectl create clusterrolebinding tiller-cluster-rule --clusterrole=cluster-admin --serviceaccount=kube-system:tiller kubectl patch deploy --namespace kube-system tiller-deploy -p ''{"spec":{"template":{"spec":{"serviceAccount":"tiller"}}}}''

Según github.com/kubernetes/helm/issues/3055

helm init --service-account default

Esto me funcionó cuando los comandos RBAC (serviceaccount) no funcionaron.

Solución dada por kujenga de la cuestión github, funcionó sin ningún otro cambio.

Tuve el mismo problema con la configuración de kubeadm en CentOS 7.

Helm no crea una cuenta de servicio cuando "helm init" y la cuenta predeterminada no tiene permisos para leer de los mapas de configuración, por lo que no podrá ejecutar una comprobación para ver si el nombre de implementación que desea El uso es único.

Esto me hizo pasarlo

kubectl create clusterrolebinding add-on-cluster-admin / --clusterrole=cluster-admin / --serviceaccount=kube-system:default

Pero eso le da a la cuenta predeterminada toneladas de energía, simplemente lo hice para poder continuar con mi trabajo. Helm necesita agregar la creación de su propia cuenta de servicio al código "helm init".

Todos los complementos en los kubernetes utilizan la cuenta de servicio "por defecto". Así que Helm también se ejecuta con la cuenta de servicio "predeterminada". Usted debe proporcionar permisos para ello. Asígnele rolebindings.

Para permisos de solo lectura:

kubectl create rolebinding default-view --clusterrole=view / --serviceaccount=kube-system:default --namespace=kube-system

Para acceso de administrador: Ej .: para instalar paquetes.

kubectl create clusterrolebinding add-on-cluster-admin / --clusterrole=cluster-admin / --serviceaccount=kube-system:default

También puede instalar el servidor Tiller en un espacio de nombres diferente usando el comando a continuación.

Primero crea el espacio de nombres
Crear la cuenta de servicio para el espacio de nombres
instale el timón en este espacio de nombres respectivo usando el siguiente comando.

timm init --tiller-namespace test-namespace