Minikube 运行 处于 Docker 模式 returns 503 启动仪表板时
Minikube running in Docker mode returns 503 when launching the dashboard
我已经开始使用 some of this tutorial and a bit of this one 学习 Minikube。我的计划是使用"none"驱动来使用Docker而不是标准的Virtual Box。
我的目的是学习一些 infra/operations 比 Docker Swarm 更灵活的技术。 Swarm 不支持一些 docker run
开关,因此我正在寻找替代方案。
设置时,我有几个错误的开始,因为我最初没有指定 --vm-driver=none
,我不得不做一个 sudo -rf ~/.minikube
and/or a sudo minikube delete
不使用 VirtualBox。 (尽管我认为这无关紧要,但我还是会提到我正在 inside 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
的命令,因此 可能 是相关的。有时我的非 root ~/.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
的集群,出于其他原因我已经这样做了。
接下来我可以尝试什么来调试它?
看来我需要回避这个问题才能找到答案。 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
然后我们需要获取仪表板的系统 pod 的名称:
$ sudo kubectl get pods -n kube-system
最后,使用仪表板 pod 的 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 并不 au fait。错误报告已被 CI 机器人自动关闭,多次尝试重新打开它似乎都失败了。
我猜测,我本可以通过设置角色配置来避免这种痛苦。然而,Hello World 教程中并没有注明这一点,因此希望初学者不要踏入这个陷阱是不合理的:
sudo minikube start --vm-driver=none --extra-config='apiserver.Authorization.Mode=RBAC'
我已经开始使用 some of this tutorial and a bit of this one 学习 Minikube。我的计划是使用"none"驱动来使用Docker而不是标准的Virtual Box。
我的目的是学习一些 infra/operations 比 Docker Swarm 更灵活的技术。 Swarm 不支持一些 docker run
开关,因此我正在寻找替代方案。
设置时,我有几个错误的开始,因为我最初没有指定 --vm-driver=none
,我不得不做一个 sudo -rf ~/.minikube
and/or a sudo minikube delete
不使用 VirtualBox。 (尽管我认为这无关紧要,但我还是会提到我正在 inside 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
的命令,因此 可能 是相关的。有时我的非 root ~/.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
的集群,出于其他原因我已经这样做了。
接下来我可以尝试什么来调试它?
看来我需要回避这个问题才能找到答案。 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
然后我们需要获取仪表板的系统 pod 的名称:
$ sudo kubectl get pods -n kube-system
最后,使用仪表板 pod 的 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 并不 au fait。错误报告已被 CI 机器人自动关闭,多次尝试重新打开它似乎都失败了。
我猜测,我本可以通过设置角色配置来避免这种痛苦。然而,Hello World 教程中并没有注明这一点,因此希望初学者不要踏入这个陷阱是不合理的:
sudo minikube start --vm-driver=none --extra-config='apiserver.Authorization.Mode=RBAC'