kubernetes 节点 没有 用于 请求 的 Pod 端口 的 可用 端口

9gm1akwq  于 2022-11-21  发布在  Kubernetes
关注(0)|答案(2)|浏览(508)

在默认名称空间中部署了ingress-controller,并尝试在另一个名称空间中部署,但一直出现此错误:

0/8个节点可用:8个节点没有用于请求的pod端口的可用端口。

但在一个解决方案中发现了类似的错误,指出 * 您不需要在集群中部署多个入口控制器。部署在命名空间中的入口控制器应能够跨集群为所有命名空间中的所有Pod工作。入口控制器通常具有clusterole,允许其跨集群为所有命名空间访问入口、服务和端点。*
0/3 nodes are available: 1 node(s) didn't have free ports for the requested pod ports, 2 node(s) didn't match node selector
那么,如果我让它在一个命名空间中工作,可以吗?

ygya80vv

ygya80vv1#

您 提到 的 链接 中 描述 的 问题 与 traefik 有关 。
总 的 来说 , 此类 错误 是 与 调度 相关 的 问题 。 它 是 由 kubernetes 调度 程序 产生 的 。 它 与 ingress-nginx 无关 。
您 应该 检查 使用 这些 端口 的 设备 。
看 一看 :是 的 。

    • 还 将 介绍 集群 中 的 多 个 入口 控制 器 。 * *

例如 , 如果 您 使用 NGINX Ingress Controller , 您 有 三 个 选项 可 供 选择 它 行程 哪些 配置 资源 :

      • 单 名称 空间 入口 控制 器 * * - 它 只 处理 来自 特定 名称 空间 的 配置 资源 , 该 名称 空间 通过 --watch-namespace 命令 行 标志 进行 控制 。 如果 您 希望 在 隔离 和/或 操作 方面 为 不同 的 应用 程序 使用 不同 的 NGINX 入口 控制 器 , 这 将 非常 有用 。
      • 集群 范围 的 入口 控制 器 * * - 它 处理 在 集群 的 任何 名称 空间 中 创建 的 配置 资源 。 由于 NGINX 是 一 个 高 性能 负载 平衡 器 , 能够 同时 为 许多 应用 程序 提供 服务 , 因此 * * 默认 情况 下 * * 使用 此 选项 。
      • 特定 入口 类 的 入口 控制 器 * * 。 它 与 上面 的 任一 选项 结合 使用 。 通过 配置 入口 控制 器 的 类 并 在 配置 资源 中 使用 该类 , 可以 进一步 定制 由 入口 控制 器 处理 的 配置 资源 。
    • 默认 情况 下 , 此类 控制 器 是 集群 范围 的 - 它们 可以 处理 在 任何 名称 空间 中 创建 的 资源 , 因此 无需 创建 多 个 控制 器 来 确保 它们 可以 处理 每个 名称 空间 中 的 资源 。 * *

阅读 更多 信息 : ingress-controllers

qacovj5a

qacovj5a2#

我也遇到了同样的问题,解题过程如下:

如何发现问题?

kubectl describe pods nginx-ingress-controller-f9d9cfd7c-q74h4
使用上述命令检查pod初始化过程的停滞位置,结果如下:

Events:
  Type     Reason            Age                 From               Message
  ----     ------            ----                ----               -------
  Warning  FailedScheduling  39s (x2 over 111s)  default-scheduler  0/1 nodes are available: 1 node(s) didn't have free ports for the requested pod ports.

问题原因分析

kubectl get all - n ingress nginx
我发现在同一个命名空间中启动了多个入口控制器,导致端口被前一个入口控制器占用。前一个入口控制器的状态为CrashLoopBackOff。详细信息如下

bogon:nginx-ingress$ kubectl get pods -n ingress-nginx
NAME                                        READY   STATUS             RESTARTS       AGE
nginx-ingress-controller-748d7f9c84-vd2pl   0/1     CrashLoopBackOff   21 (64s ago)   59m
nginx-ingress-controller-f9d9cfd7c-q74h4    0/1     Pending            0              4m39s

我的解决方案

我的解决方案是删除第一个处于CrashLoopBackOff状态的pod

# kubectl delete pod nginx-ingress-controller-748d7f9c84-vd2pl -n ingress-nginx
# kubectl apply -f mandatory.yaml

相关问题