Шлем: Ошибка: не найдено ни одного доступного имени выпуска
Я получаю пару ошибок с Helm, что я не могу найти объяснений в других местах. Две ошибки ниже.
Error: no available release name found
Error: the server does not allow access to the requested resource (get configmaps)
Более подробная информация о двух ошибках приведена ниже в блоке кода.
Я установил кластер Kubernetes на Ubuntu 16.04. У меня есть Мастер (K8SMST01) и два узла (K8SN01 и K8SN02).
Это было создано с использованием kubeadm с использованием сети Weave для 1.6 +.
Кажется, что все работает отлично, так как Deployments, Services, Pods и т.д. DNS, похоже, работает нормально, поскольку контейнеры могут обращаться к службам с использованием имени DNS (myservicename.default).
Использование работы "helm create" и "helm search", но взаимодействие с развертыванием румпеля похоже не работает. Тиллер устанавливается и работает в соответствии с инструкцией по установке Helm.
[email protected]:/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"}
[email protected]:/home/blah/charts# helm install ./mychart
Error: no available release name found
[email protected]:/home/blah/charts# helm ls
Error: the server does not allow access to the requested resource (get configmaps)
Здесь находятся запущенные модули:
[email protected]:/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
Ответы
Ответ 1
Я думаю, что это проблема RBAC. Похоже, что руль не готов к 1.6.1 RBAC.
Для Хелма Гитхуба существует проблема, открытая для этого.
https://github.com/kubernetes/helm/issues/2224
"При первоначальной установке кластера с использованием kubeadm v1.6.1 по умолчанию при инициализации настраивается контролируемый доступ RBAC, что мешает разрешениям, необходимым Tiller для выполнения установки, сканирования установленных компонентов и т.д. Helm init работает без проблем, но список helm, установка helm и т.д. все не работают, ссылаясь на пропущенное разрешение или другое. "
Временное решение было предложено:
"Мы" отключаем "RBAC с помощью команды kubectl create clusterrolebinding разрешающее связывание --clusterrole = cluster-admin --user = admin --user = kubelet --group = system: serviceaccounts;"
Но я не могу говорить за это обоснованность. Хорошей новостью является то, что это известная проблема, и ведется работа по ее устранению. Надеюсь это поможет.
Ответ 2
Решение, данное kujenga из выпуска GitHub, работало без каких-либо других изменений:
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"}}}}'
Ответ 3
У меня была такая же проблема с настройкой kubeadm на CentOS 7.
Шлем не делает учетную запись службы, когда вы "helm init", и по умолчанию у него нет разрешений на чтение из конфигурационных файлов, поэтому он не сможет запустить проверку, чтобы узнать, не указано ли имя развертывания он хочет использовать уникально.
Это заставило меня пройти мимо:
kubectl create clusterrolebinding add-on-cluster-admin \
--clusterrole=cluster-admin \
--serviceaccount=kube-system:default
Но это означает, что учетная запись по умолчанию не имеет силы, я просто сделал это, чтобы я мог продолжить работу. Шлему необходимо добавить создание собственной учетной записи службы в код "helm init".
Ответ 4
Все дополнения в kubernetes используют учетную запись службы "по умолчанию". Таким образом, Helm также работает с учетной записью "по умолчанию". Вы должны предоставить разрешения на это. Назначьте ему ролевые привязки.
Только для чтения:
kubectl create rolebinding default-view --clusterrole=view \ --serviceaccount=kube-system:default --namespace=kube-system
Для доступа администратора: например, для установки пакетов.
kubectl create clusterrolebinding add-on-cluster-admin \ --clusterrole=cluster-admin \ --serviceaccount=kube-system:default
Вы также можете установить сервер Tiller в другом пространстве имен, используя приведенную ниже команду.
- Сначала создайте namesapce
- Создайте служебную учетную запись для пространства имен
- установите румпель в этом соответствующем пространстве имен, используя приведенную ниже команду.
helm init --tiller-namespace test-namespace
Ответ 5
Это решение работает для меня: https://github.com/helm/helm/issues/3055#issuecomment-397296485
$ kubectl create serviceaccount --namespace kube-system tiller
$ kubectl create clusterrolebinding tiller-cluster-rule --clusterrole=cluster-admin --serviceaccount=kube-system:tiller
$ helm init --service-account tiller --upgrade
$ helm update repo
$ helm install stable/redis --version 3.3.5
Но после этого что-то изменилось; Я должен добавить --insecure-skip-tls-verify = true флаг в мои команды kubectl! Я не знаю, как это исправить, зная, что я взаимодействую с кластером контейнеров gcloud.
Ответ 6
Per https://github.com/kubernetes/helm/issues/2224#issuecomment-356344286, следующие команды также разрешили мне ошибку:
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"}}}}'
Ответ 7
По https://github.com/kubernetes/helm/issues/3055
helm init --service-account default
Это работало для меня, когда команды RBAC (serviceaccount) не работали.
Ответ 8
Это проблема RBAC. У вас должна быть служебная учетная запись с ролью администратора кластера. И вы должны передать эту учетную запись службы во время инициализации HELM.
Например, если вы создали учетную запись службы с именем tiller, ваша команда heml будет выглядеть следующим образом.
helm init --service-account=tiller
Я следил за этим блогом, чтобы решить эту проблему. https://scriptcrunch.com/helm-error-no-available-release/