docker - 启动仪表板时，以Docker模式运行的Minikube返回503

Question

我已经开始使用some of this tutorial和a bit of this one学习Minikube。我的计划是使用“无”驱动程序来使用Docker，而不是标准的Virtual Box。

我的目的是学习一些比Docker Swarm更灵活的基础设施/操作技术。 Swarm不支持​​一些docker run开关，因此我正在寻找替代方案。

进行此设置时，由于我最初没有指定--vm-driver=none，所以我有几个错误的开始，而且我不得不执行sudo -rf ~/.minikube和/或sudo minikube delete才能不使用VirtualBox。 (尽管我认为这无关紧要，但出于长期的安全偏好，我还是要提到我正在VirtualBox Linux Mint VM内工作)。

因此，我认为我的Minikube安装大部分都是有效的，但仪表板中的某些功能是不正确的，并且由于“Hello World”教程要求我使其正常工作，因此我将继续坚持下去。

这是命令和错误:

$ sudo minikube dashboard
🔌  Enabling dashboard ...
🤔  Verifying dashboard health ...
🚀  Launching proxy ...
🤔  Verifying proxy health ...
💣  http://127.0.0.1:41303/api/v1/namespaces/kube-system/services/http:kubernetes-dashboard:/proxy/ is not responding properly: Temporary Error: unexpected response code: 503
Temporary Error: unexpected response code: 503
Temporary Error: unexpected response code: 503
Temporary Error: unexpected response code: 503
Temporary Error: unexpected response code: 503
Temporary Error: unexpected response code: 503
Temporary Error: unexpected response code: 503
{snipped many more of these}

Minikube本身看起来还不错:

$ sudo minikube status
host: Running
kubelet: Running
apiserver: Running
kubectl: Correctly Configured: pointing to minikube-vm at 10.0.2.15

但是，似乎某些组件无法启动，但没有迹象表明它们有问题的原因:

$ sudo kubectl get pods --all-namespaces
NAMESPACE     NAME                                    READY   STATUS             RESTARTS   AGE
kube-system   coredns-fb8b8dccf-2br2c                 0/1     CrashLoopBackOff   16         62m
kube-system   coredns-fb8b8dccf-nq4b8                 0/1     CrashLoopBackOff   16         62m
kube-system   etcd-minikube                           1/1     Running            2          60m
kube-system   kube-addon-manager-minikube             1/1     Running            3          61m
kube-system   kube-apiserver-minikube                 1/1     Running            2          61m
kube-system   kube-controller-manager-minikube        1/1     Running            3          61m
kube-system   kube-proxy-dzqsr                        1/1     Running            0          56m
kube-system   kube-scheduler-minikube                 1/1     Running            2          60m
kube-system   kubernetes-dashboard-79dd6bfc48-94c8l   0/1     CrashLoopBackOff   12         40m
kube-system   storage-provisioner                     1/1     Running            3          62m

我假设READY列中的数字为零表示某些内容无法启动。

我一直在发出带有或不带有sudo的命令，因此可能是相关的。有时，我的非根~/.minikube文件夹中有配置文件归root拥有，而我被迫使用sudo进行进一步开发。

这看起来不错:

Kubernetes master is running at https://10.0.2.15:8443
KubeDNS is running at https://10.0.2.15:8443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy

To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.

顺便说一句，我真的不知道这些各种状态命令的作用，或者它们是否相关-我在这里和GitHub上都找到了类似的文章，他们各自的作者使用这些命令来编写问题和错误报告。

这个API状态看起来像是在泡菜中，但是我不知道它是否相关(我是通过半随机挖掘发现的):

https://10.0.2.15:8443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy

{

    "kind": "Status",
    "apiVersion": "v1",
    "metadata": { },
    "status": "Failure",
    "message": "services \"kube-dns:dns\" is forbidden: User \"system:anonymous\" cannot get resource \"services/proxy\" in API group \"\" in the namespace \"kube-system\"",
    "reason": "Forbidden",
    "details": {
        "name": "kube-dns:dns",
        "kind": "services"
    },
    "code": 403

}

我也设法导致Go崩溃，如sudo minikube logs所示:

panic: secrets is forbidden: User "system:serviceaccount:kube-system:default" cannot create resource "secrets" in API group "" in the namespace "kube-system"

goroutine 1 [running]:
github.com/kubernetes/dashboard/src/app/backend/auth/jwe.(*rsaKeyHolder).init(0xc42011c2e0)
    /home/travis/build/kubernetes/dashboard/.tmp/backend/src/github.com/kubernetes/dashboard/src/app/backend/auth/jwe/keyholder.go:131 +0x35e
github.com/kubernetes/dashboard/src/app/backend/auth/jwe.NewRSAKeyHolder(0x1367500, 0xc4200d0120, 0xc4200d0120, 0x1213a6e)
    /home/travis/build/kubernetes/dashboard/.tmp/backend/src/github.com/kubernetes/dashboard/src/app/backend/auth/jwe/keyholder.go:170 +0x64
main.initAuthManager(0x13663e0, 0xc420301b00, 0xc4204cdcd8, 0x1)
    /home/travis/build/kubernetes/dashboard/.tmp/backend/src/github.com/kubernetes/dashboard/src/app/backend/dashboard.go:185 +0x12c
main.main()
    /home/travis/build/kubernetes/dashboard/.tmp/backend/src/github.com/kubernetes/dashboard/src/app/backend/dashboard.go:103 +0x26b

我希望那与我得到的503相对应，这是某种服务器错误。

一些版本:

$ minikube version
minikube version: v1.0.0
$ docker --version
Docker version 18.09.2, build 6247962
$ sudo kubectl version
Client Version: version.Info{Major:"1", Minor:"14", GitVersion:"v1.14.1", GitCommit:"b7394102d6ef778017f2ca4046abbaa23b88c290", GitTreeState:"clean", BuildDate:"2019-04-08T17:11:31Z", GoVersion:"go1.12.1", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"14", GitVersion:"v1.14.0", GitCommit:"641856db18352033a0d96dbc99153fa3b27298e5", GitTreeState:"clean", BuildDate:"2019-03-25T15:45:25Z", GoVersion:"go1.12.1", Compiler:"gc", Platform:"linux/amd64"}
$ kubeadm version
kubeadm version: &version.Info{Major:"1", Minor:"14", GitVersion:"v1.14.0", GitCommit:"641856db18352033a0d96dbc99153fa3b27298e5", GitTreeState:"clean", BuildDate:"2019-03-25T15:51:21Z", GoVersion:"go1.12.1", Compiler:"gc", Platform:"linux/amd64"}

相关链接:

503 dashboard errors on a Mac with Hyperkit-我在Linux Mint上，未使用Hyperkit。

Lots of folks with 503 dashboard errors-这里的主要建议是使用minikube delete删除集群，出于其他原因，我已经这样做了。

接下来我可以尝试调试什么？

Answer 1

看来我需要费力地想着这个问题才能找到答案。 Go崩溃是要研究的东西，它是documented in this bug report。

创建缺少角色的命令是:

$ kubectl create clusterrolebinding kube-system-cluster-admin --clusterrole=cluster-admin --serviceaccount=kube-system:default
clusterrolebinding.rbac.authorization.k8s.io/kube-system-cluster-admin created

然后，我们需要获取仪表板的系统 Pane 的名称:

$ sudo kubectl get pods -n kube-system

最后，使用仪表板容器的ID代替kubernetes-dashboard-5498ccf677-dq2ct:

$ kubectl delete pods -n kube-system  kubernetes-dashboard-5498ccf677-dq2ct
pod "kubernetes-dashboard-5498ccf677-dq2ct" deleted

我认为这将删除配置错误的仪表板，当您发出以下命令时，会在其位置生成一个新的仪表板:

sudo minikube dashboard

在我看来，Go错误看起来非常裸露且无法处理，需要捕获，但是我对Go并不满意。该错误报告已由CI机器人自动关闭，尝试重新打开该错误报告似乎失败了。

凭猜测，我可以通过设置角色配置开始来避免这种痛苦。但是，“Hello World”教程中未对此进行说明，因此，期望初学者不要进入此陷阱是不合理的:

sudo minikube start --vm-driver=none --extra-config='apiserver.Authorization.Mode=RBAC'