在 kubernetes 集群上无法访问或调度 Pods
No Pods reachable or schedulable on kubernetes cluster
我在IBM云中有2个kubernetes集群,一个有2个节点,另一个有4个。
有 4 个节点的那个工作正常,但在另一个上,由于金钱原因我不得不暂时删除工作节点(不应该在空闲时支付)。
当我重新激活这两个节点时,一切似乎都开始正常,只要我不尝试与 Pods 进行交互,它表面上看起来仍然很好,没有关于不可用或严重健康的消息状态。好的,我删除了两个卡在 Terminating
状态的过时 Namespace
s,但我可以通过重新启动集群节点来解决该问题(不再确切知道它是哪个)。
当一切看起来都正常时,我尝试访问 kubernetes 仪表板(之前所做的一切都是在 IBM 管理层或命令行中完成的)但令人惊讶的是我发现它无法访问,浏览器中的错误页面显示:
503: Service Unavailable
该页面底部有一条 JSON 小消息,上面写着:
{
"kind": "Status",
"apiVersion": "v1",
"metadata": { },
"status": "Failure",
"message": "error trying to reach service: read tcp 172.18.190.60:39946-\u003e172.19.151.38:8090: read: connection reset by peer",
"reason": "ServiceUnavailable",
"code": 503
}
我发送了一个kubectl logs kubernetes-dashboard-54674bdd65-nf6w7 --namespace=kube-system
,其中Pod
显示为运行,但结果不是要查看的日志,而是这条消息:
Error from server: Get "https://10.215.17.75:10250/containerLogs/kube-system/kubernetes-dashboard-54674bdd65-nf6w7/kubernetes-dashboard":
read tcp 172.18.135.195:56882->172.19.151.38:8090:
read: connection reset by peer
然后我发现我既无法在该集群中获取 any Pod
运行 的日志,也无法部署任何需要调度的新自定义 kubernetes 对象(我实际上可以应用 Service
s 或 ConfigMap
s,但不能应用 Pod
、ReplicaSet
、Deployment
或类似的)。
我已经试过了
- 重新加载工作池中的工作节点
- 重启工作池中的工作节点
- 重新启动了 kubernetes-dashboard
Deployment
不幸的是,上述 none 操作更改了 Pod
的可访问性。
还有一件事可能相关(尽管我不太确定它是否真的相关):
在另一个运行良好的集群中,有三个 calico Pod
s 运行 并且所有三个都已启动,而在有问题的集群中只有三个 calico Pod
s 中的 2 个起来 运行,第三个保持 Pending
状态,kubectl describe pod calico-blablabla-blabla
揭示原因,Event
Warning FailedScheduling 13s default-scheduler
0/2 nodes are available: 2 node(s) didn't have free ports for the requested pod ports.
有没有人知道该集群中发生的事情并可以指出可能的解决方案?我真的不想删除集群并生成一个新集群,但我无法使用用户界面(仪表板或 cli)。
编辑
kubectl describe pod kubernetes-dashboard-54674bdd65-4m2ch --namespace=kube-system
的结果:
Name: kubernetes-dashboard-54674bdd65-4m2ch
Namespace: kube-system
Priority: 2000000000
Priority Class Name: system-cluster-critical
Node: 10.215.17.82/10.215.17.82
Start Time: Mon, 15 Nov 2021 09:01:30 +0100
Labels: k8s-app=kubernetes-dashboard
pod-template-hash=54674bdd65
Annotations: cni.projectcalico.org/containerID: ca52cefaae58d8e5ce6d54883cb6a6135318c8db53d231dc645a5cf2e67d821e
cni.projectcalico.org/podIP: 172.30.184.2/32
cni.projectcalico.org/podIPs: 172.30.184.2/32
container.seccomp.security.alpha.kubernetes.io/kubernetes-dashboard: runtime/default
kubectl.kubernetes.io/restartedAt: 2021-11-10T15:47:14+01:00
kubernetes.io/psp: ibm-privileged-psp
Status: Running
IP: 172.30.184.2
IPs:
IP: 172.30.184.2
Controlled By: ReplicaSet/kubernetes-dashboard-54674bdd65
Containers:
kubernetes-dashboard:
Container ID: containerd://bac57850055cd6bb944c4d893a5d315c659fd7d4935fe49083d9ef8ae03e5c31
Image: registry.eu-de.bluemix.net/armada-master/kubernetesui-dashboard:v2.3.1
Image ID: registry.eu-de.bluemix.net/armada-master/kubernetesui-dashboard@sha256:f14f581d36b83fc9c1cfa3b0609e7788017ecada1f3106fab1c9db35295fe523
Port: 8443/TCP
Host Port: 0/TCP
Args:
--auto-generate-certificates
--namespace=kube-system
State: Running
Started: Mon, 15 Nov 2021 09:01:37 +0100
Ready: True
Restart Count: 0
Requests:
cpu: 50m
memory: 100Mi
Liveness: http-get https://:8443/ delay=30s timeout=30s period=10s #success=1 #failure=3
Readiness: http-get https://:8443/ delay=10s timeout=30s period=10s #success=1 #failure=3
Environment: <none>
Mounts:
/certs from kubernetes-dashboard-certs (rw)
/tmp from tmp-volume (rw)
/var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-sc9kw (ro)
Conditions:
Type Status
Initialized True
Ready True
ContainersReady True
PodScheduled True
Volumes:
kubernetes-dashboard-certs:
Type: Secret (a volume populated by a Secret)
SecretName: kubernetes-dashboard-certs
Optional: false
tmp-volume:
Type: EmptyDir (a temporary directory that shares a pod's lifetime)
Medium:
SizeLimit: <unset>
kube-api-access-sc9kw:
Type: Projected (a volume that contains injected data from multiple sources)
TokenExpirationSeconds: 3607
ConfigMapName: kube-root-ca.crt
ConfigMapOptional: <nil>
DownwardAPI: true
QoS Class: Burstable
Node-Selectors: <none>
Tolerations: node-role.kubernetes.io/master:NoSchedule
node.kubernetes.io/not-ready:NoExecute op=Exists for 600s
node.kubernetes.io/unreachable:NoExecute op=Exists for 600s
Events: <none>
问题已解决...
问题的原因是在我的集群满足以下条件时将集群更新到 kubernetes 版本 1.21:
- 私有和 public 启用服务端点
- VRF 已禁用
根本原因:
在 Kubernetes 1.21 版中,Konnectivity 取代了 OpenVPN 作为网络代理,用于保护 Kubernetes API 服务器主节点与集群中工作节点的通信。
使用 Konnectivity 时,当满足上述所有条件时,主节点到集群节点的通信存在问题。
求解步骤:
- 使用命令
禁用了私有服务端点(public 似乎不是问题)
ibmcloud ks cluster master private-service-endpoint disable --cluster <CLUSTER_NAME>
(此命令特定于提供者,如果您在使用不同的提供者或在本地安装时遇到相同的问题,请了解如何禁用该专用服务端点)
- 刷新集群主机使用
ibmcloud ks cluster master refresh --cluster <CLUSTER_NAME>
最后
- 重新加载所有工作节点(在 Web 控制台中,也应该可以通过命令实现)
- 等了大约30分钟:
- 仪表板可用/可再次访问
Pod
可以再次访问和安排
一般推荐:
在将任何集群更新到 kubernetes 1.21 之前,请检查您是否启用了私有服务端点。如果有,请禁用它或延迟更新直到可以,或者启用 VRF(虚拟路由和转发),我不能这样做,但被告知它可能会解决问题。
我在IBM云中有2个kubernetes集群,一个有2个节点,另一个有4个。
有 4 个节点的那个工作正常,但在另一个上,由于金钱原因我不得不暂时删除工作节点(不应该在空闲时支付)。
当我重新激活这两个节点时,一切似乎都开始正常,只要我不尝试与 Pods 进行交互,它表面上看起来仍然很好,没有关于不可用或严重健康的消息状态。好的,我删除了两个卡在 Terminating
状态的过时 Namespace
s,但我可以通过重新启动集群节点来解决该问题(不再确切知道它是哪个)。
当一切看起来都正常时,我尝试访问 kubernetes 仪表板(之前所做的一切都是在 IBM 管理层或命令行中完成的)但令人惊讶的是我发现它无法访问,浏览器中的错误页面显示:
503: Service Unavailable
该页面底部有一条 JSON 小消息,上面写着:
{
"kind": "Status",
"apiVersion": "v1",
"metadata": { },
"status": "Failure",
"message": "error trying to reach service: read tcp 172.18.190.60:39946-\u003e172.19.151.38:8090: read: connection reset by peer",
"reason": "ServiceUnavailable",
"code": 503
}
我发送了一个kubectl logs kubernetes-dashboard-54674bdd65-nf6w7 --namespace=kube-system
,其中Pod
显示为运行,但结果不是要查看的日志,而是这条消息:
Error from server: Get "https://10.215.17.75:10250/containerLogs/kube-system/kubernetes-dashboard-54674bdd65-nf6w7/kubernetes-dashboard":
read tcp 172.18.135.195:56882->172.19.151.38:8090:
read: connection reset by peer
然后我发现我既无法在该集群中获取 any Pod
运行 的日志,也无法部署任何需要调度的新自定义 kubernetes 对象(我实际上可以应用 Service
s 或 ConfigMap
s,但不能应用 Pod
、ReplicaSet
、Deployment
或类似的)。
我已经试过了
- 重新加载工作池中的工作节点
- 重启工作池中的工作节点
- 重新启动了 kubernetes-dashboard
Deployment
不幸的是,上述 none 操作更改了 Pod
的可访问性。
还有一件事可能相关(尽管我不太确定它是否真的相关):
在另一个运行良好的集群中,有三个 calico Pod
s 运行 并且所有三个都已启动,而在有问题的集群中只有三个 calico Pod
s 中的 2 个起来 运行,第三个保持 Pending
状态,kubectl describe pod calico-blablabla-blabla
揭示原因,Event
Warning FailedScheduling 13s default-scheduler
0/2 nodes are available: 2 node(s) didn't have free ports for the requested pod ports.
有没有人知道该集群中发生的事情并可以指出可能的解决方案?我真的不想删除集群并生成一个新集群,但我无法使用用户界面(仪表板或 cli)。
编辑
kubectl describe pod kubernetes-dashboard-54674bdd65-4m2ch --namespace=kube-system
的结果:
Name: kubernetes-dashboard-54674bdd65-4m2ch
Namespace: kube-system
Priority: 2000000000
Priority Class Name: system-cluster-critical
Node: 10.215.17.82/10.215.17.82
Start Time: Mon, 15 Nov 2021 09:01:30 +0100
Labels: k8s-app=kubernetes-dashboard
pod-template-hash=54674bdd65
Annotations: cni.projectcalico.org/containerID: ca52cefaae58d8e5ce6d54883cb6a6135318c8db53d231dc645a5cf2e67d821e
cni.projectcalico.org/podIP: 172.30.184.2/32
cni.projectcalico.org/podIPs: 172.30.184.2/32
container.seccomp.security.alpha.kubernetes.io/kubernetes-dashboard: runtime/default
kubectl.kubernetes.io/restartedAt: 2021-11-10T15:47:14+01:00
kubernetes.io/psp: ibm-privileged-psp
Status: Running
IP: 172.30.184.2
IPs:
IP: 172.30.184.2
Controlled By: ReplicaSet/kubernetes-dashboard-54674bdd65
Containers:
kubernetes-dashboard:
Container ID: containerd://bac57850055cd6bb944c4d893a5d315c659fd7d4935fe49083d9ef8ae03e5c31
Image: registry.eu-de.bluemix.net/armada-master/kubernetesui-dashboard:v2.3.1
Image ID: registry.eu-de.bluemix.net/armada-master/kubernetesui-dashboard@sha256:f14f581d36b83fc9c1cfa3b0609e7788017ecada1f3106fab1c9db35295fe523
Port: 8443/TCP
Host Port: 0/TCP
Args:
--auto-generate-certificates
--namespace=kube-system
State: Running
Started: Mon, 15 Nov 2021 09:01:37 +0100
Ready: True
Restart Count: 0
Requests:
cpu: 50m
memory: 100Mi
Liveness: http-get https://:8443/ delay=30s timeout=30s period=10s #success=1 #failure=3
Readiness: http-get https://:8443/ delay=10s timeout=30s period=10s #success=1 #failure=3
Environment: <none>
Mounts:
/certs from kubernetes-dashboard-certs (rw)
/tmp from tmp-volume (rw)
/var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-sc9kw (ro)
Conditions:
Type Status
Initialized True
Ready True
ContainersReady True
PodScheduled True
Volumes:
kubernetes-dashboard-certs:
Type: Secret (a volume populated by a Secret)
SecretName: kubernetes-dashboard-certs
Optional: false
tmp-volume:
Type: EmptyDir (a temporary directory that shares a pod's lifetime)
Medium:
SizeLimit: <unset>
kube-api-access-sc9kw:
Type: Projected (a volume that contains injected data from multiple sources)
TokenExpirationSeconds: 3607
ConfigMapName: kube-root-ca.crt
ConfigMapOptional: <nil>
DownwardAPI: true
QoS Class: Burstable
Node-Selectors: <none>
Tolerations: node-role.kubernetes.io/master:NoSchedule
node.kubernetes.io/not-ready:NoExecute op=Exists for 600s
node.kubernetes.io/unreachable:NoExecute op=Exists for 600s
Events: <none>
问题已解决...
问题的原因是在我的集群满足以下条件时将集群更新到 kubernetes 版本 1.21:
- 私有和 public 启用服务端点
- VRF 已禁用
根本原因:
在 Kubernetes 1.21 版中,Konnectivity 取代了 OpenVPN 作为网络代理,用于保护 Kubernetes API 服务器主节点与集群中工作节点的通信。
使用 Konnectivity 时,当满足上述所有条件时,主节点到集群节点的通信存在问题。
求解步骤:
- 使用命令
禁用了私有服务端点(public 似乎不是问题)ibmcloud ks cluster master private-service-endpoint disable --cluster <CLUSTER_NAME>
(此命令特定于提供者,如果您在使用不同的提供者或在本地安装时遇到相同的问题,请了解如何禁用该专用服务端点) - 刷新集群主机使用
ibmcloud ks cluster master refresh --cluster <CLUSTER_NAME>
最后 - 重新加载所有工作节点(在 Web 控制台中,也应该可以通过命令实现)
- 等了大约30分钟:
- 仪表板可用/可再次访问
Pod
可以再次访问和安排
一般推荐:
在将任何集群更新到 kubernetes 1.21 之前,请检查您是否启用了私有服务端点。如果有,请禁用它或延迟更新直到可以,或者启用 VRF(虚拟路由和转发),我不能这样做,但被告知它可能会解决问题。