所以最终会发生的情况是,一切都会正常运转,有时会持续数天。但是,偶尔当我部署代码时(所有代码都包含在自己的 Docker 容器中,图像存储在 Dockerhub 上),它会导致 Kubernetes 崩溃,从而导致其他一切都崩溃。我还没能找出其中的原因。而且在大多数情况下,我还没有找到任何真正有助于解决问题的方法。通常,它会因为某种原因再次开始工作 - 尽管我知道至少有一次我删除了整个实例组并重新开始。这有效。
现在,当我进行部署时,我所做的就是运行命令kubectl set image deployment
。这在大多数情况下都有效,只是偶尔会发生奇怪的事情。
现在,更具体地说,发生的奇怪的事情是,如果我尝试去,https://<master node>/ui
我会得到这样的错误:
{
"kind": "Status",
"apiVersion": "v1",
"metadata": {},
"status": "Failure",
"message": "no endpoints available for service \"kubernetes-dashboard\"",
"reason": "ServiceUnavailable",
"code": 503
}
这是输出kubectl cluster-info
Kubernetes master is running at https://104.198.207.42
GLBCDefaultBackend is running at https://104.198.207.42/api/v1/proxy/namespaces/kube-system/services/default-http-backend
Heapster is running at https://104.198.207.42/api/v1/proxy/namespaces/kube-system/services/heapster
KubeDNS is running at https://104.198.207.42/api/v1/proxy/namespaces/kube-system/services/kube-dns
kubernetes-dashboard is running at https://104.198.207.42/api/v1/proxy/namespaces/kube-system/services/kubernetes-dashboard
在写这篇文章的时候,它又神奇地开始工作了,所以我实际上无法再粘贴任何输出(或者,至少我不知道在哪里寻找它)。
但如果有人知道是什么原因造成的,以及下次发生这种情况时我该如何尝试修复它,那就太好了。部署可能会随机破坏一些东西,导致我几个小时的停机时间,而我却漫无目的地、毫无意义地尝试修复它,这真是令人沮丧。只是让它随机决定再次工作。
谢谢阅读!
答案1
因此,为了便于记录,以防其他人遇到此问题。我不得不升级到更大的实例,最终是因为我遇到了 OOM(内存不足)错误。
我不记得我是如何发现这些错误的,无论是通过kubectl logs
还是通过gcloud
命令行实用程序。但其中一个最终说有“OOM”错误。
答案2
我也遇到了同样的问题,每当 CPU 利用率接近 100% 时,kubernetes 仪表板就会出现相同的错误
{
"kind": "Status",
"apiVersion": "v1",
"metadata": {},
"status": "Failure",
"message": "no endpoints available for service \"kubernetes-dashboard\"",
"reason": "ServiceUnavailable",
"code": 503
}
当我删除一些虚拟吊舱时,它将自动再次开始工作。
最主要的是,我有 4 个节点,但大多数 pod 仅在 1-2 个节点上进行调度。