Helm:错误:找不到可用的版本名称

时间:2017-04-19 15:25:25

标签: kubernetes kubernetes-helm

我在Helm遇到一些错误,我无法在其他地方找到解释。这两个错误如下。

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

这两个错误的更多细节在下面的代码块中。

我在Ubuntu 16.04上安装了Kubernetes集群。我有一个Master(K8SMST01)和两个节点(K8SN01& K8SN02)。

这是使用kubeadm使用Weave网络为1.6 +创建的。

就部署,服务,Pod等而言,一切似乎运行良好...... DNS似乎工作正常,这意味着pod可以使用DNS名称(myservicename.default)访问服务。

使用" helm create"和#34;掌舵搜索"工作,但与分蘖部署交互似乎不起作用。根据Helm安装文档安装并运行Tiller。

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)

以下是正在运行的播客:

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

9 个答案:

答案 0 :(得分:53)

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"}}}}'

答案 1 :(得分:20)

我认为这是一个RBAC问题。似乎掌舵还没有为1.6.1的RBAC做好准备。

Helm的Github上存在一个问题。

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

  

"使用kubeadm v1.6.1首次安装群集时,   初始化默认设置RBAC控制访问,   哪个与Tiller进行安装所需的权限相混淆,   扫描已安装的组件,等等。 helm init无需工作   问题,但掌舵列表,头盔安装,等等都不起作用,引用   一些遗失的许可或其他。"

有人建议临时解决:

  

"我们"禁用" RBAC使用命令kubectl创建clusterrolebinding   permissive-binding --clusterrole = cluster-admin --user = admin   --user = kubelet --group = system:serviceaccounts;"

但我不能说它的有效性。好消息是,这是一个已知问题,正在努力解决这个问题。希望这会有所帮助。

答案 2 :(得分:8)

我对CentOS 7上的kubeadm设置有同样的问题。

Helm在你" helm init"并且默认设置没有从配置映射中读取的权限 - 因此无法运行检查以查看它要使用的部署名称是否唯一。

这让我超越了它:

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

但是这给了默认帐户大量的权力,我只是这样做,所以我可以继续我的工作。 Helm需要将自己的服务帐户创建添加到" helm init"代码。

答案 3 :(得分:3)

此解决方案对我有效:https://github.com/helm/helm/issues/3055#issuecomment-397296485

issue = 222

但是在那之后,情况发生了变化;我必须在我的kubectl命令中添加-insecure-skip-tls-verify = true 标志!我不知道该如何解决与gcloud容器集群的交互问题。

答案 4 :(得分:2)

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"}}}}'

答案 5 :(得分:2)

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

helm init --service-account default

当RBAC(serviceaccount)命令没有用时,这对我有用。

答案 6 :(得分:2)

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

您还可以使用以下命令将分er服务器安装在其他名称空间中。

  1. 首先创建名称空间
  2. 为命名空间创建服务帐户
  3. 使用以下命令在相应的命名空间中安装分till。
  

helm init --tiller-namespace测试名称空间

答案 7 :(得分:0)

这是RBAC问题。您需要具有集群管理员角色的服务帐户。并且您应该在HELM初始化期间通过此服务帐户。

例如,如果您创建了一个名称为tiller的服务帐户,则heml命令将如下所示。

helm init --service-account=tiller

我关注了此博客以解决此问题。 https://scriptcrunch.com/helm-error-no-available-release/

答案 8 :(得分:0)

检查分till容器的日志:

kubectl logs tiller-deploy-XXXX --namespace=kube-system

如果您发现这样的内容:

Error: 'dial tcp 10.44.0.16:3000: connect: no route to host'

然后,here解决方案中所述的防火墙/ iptables可能会删除一些规则:

sudo iptables -D  INPUT -j REJECT --reject-with icmp-host-prohibited
sudo iptables -D  FORWARD -j REJECT --reject-with icmp-host-prohibited