主页 / server / 问题 / 1083392
Accepted
deHaar
Asked: 2021-11-13 07:17:35 +0800 CST

Kubernetes 集群上没有可访问或可调度的 Pod

  • 772

我在 IBM 云中有 2 个 Kubernetes 集群，一个有 2 个节点，另一个有 4 个。

一个有 4 个节点的节点工作正常，但在另一个节点上，由于金钱原因，我不得不暂时移除工作节点（不应该在空闲时支付）。

当我重新激活这两个节点时，一切似乎都正常启动，只要我不尝试与 Pod 交互，它表面上看起来仍然很好，没有关于不可用或严重健康状态的消息。好的，我删除了两个Namespace卡在Terminating状态中的过时的 s，但我可以通过重新启动集群节点来解决该问题（不再确切知道它是哪一个）。

当一切正常时，我尝试访问 kubernetes 仪表板（之前所做的一切都是在 IBM 管理级别或命令行中完成的），但令人惊讶的是，我发现它无法访问，浏览器中的错误页面显示：

503服务不可用

该页面底部有一条小的 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

然后我发现我既无法获取该集群中运行的任何 Pod日志，也无法部署任何需要调度的新自定义 kubernetes 对象（我实际上可以应用Services 或s ，ConfigMap但没有Pod,或类似的） .ReplicaSetDeployment

我已经尝试过

  • 重新加载工作池中的工作节点
  • 重启workerpool中的worker节点
  • 重新启动 kubernetes-dashboardDeployment

不幸的是，上述操作都没有改变Pods.

还有另一件事可能是相关的（虽然我不太确定它是否真的是）：

在另一个运行良好的集群中，有三个 calicoPod正在运行，并且所有三个都启动，而在有问题的集群中，三个 calicoPod中只有两个启动并运行，第三个保持Pending状态并且 akubectl 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.

有没有人知道该集群中发生了什么并可以指出可能的解决方案？我真的不想删除集群并生成一个新集群。

编辑

结果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>
port port-forwarding scheduling cluster kubernetes

1 个回答

  1. Best Answer

    问题解决了……

    问题的原因是集群更新到 kubernetes 版本 1.21，而我的集群满足以下条件：

    • 已启用私有和公共服务端点
    • 禁用 VRF

    根本原因：

    在 Kubernetes 版本 1.21 中，Konnectivity 取代 OpenVPN 作为网络代理，用于保护 Kubernetes API 服务器主节点与集群中的工作节点的通信。
    使用 Konnectivity 时，当满足上述所有条件时，主节点与集群节点之间的通信存在问题。

    解决步骤：

    • 使用命令禁用私有服务端点（公共端点似乎不是问题）
      ibmcloud ks cluster master private-service-endpoint disable --cluster <CLUSTER_NAME> （此命令是特定于提供商的，如果您在使用不同的提供商或本地安装时遇到相同的问题，请了解如何禁用该端点私有服务端点）
    • 刷新了集群主服务器 ibmcloud ks cluster master refresh --cluster <CLUSTER_NAME>，最后使用
    • 重新加载所有工作节点（在 Web 控制台中，也应该可以通过命令）
    • 等了大约30分钟：
      • 仪表板可用/可再次访问
      • Pods 可访问且可再次调度

    一般建议：

    在将任何集群更新到 Kubernetes 1.21 之前，请检查您是否启用了私有服务端点。如果有，请禁用它或延迟更新直到可以，或者启用 VRF（虚拟路由和转发），我不能但被告知它可能会解决问题。

    • 2

相关问题