【k8s】节点无法调度

最新推荐文章于 2024-01-30 21:41:46 发布
原创 最新推荐文章于 2024-01-30 21:41:46 发布 · 6.2k 阅读 · 1 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#kubernetes

在部署Kubernetes Pod时遇到调度问题，错误显示为0/3nodesareavailable:1node(s)wereunschedulable,2node(s)didn’tmatchnodeselector。解决方法包括检查节点状态，确认master节点是否被设置为不可调度，并考虑将Pod部署到其他节点或调整nodeselector策略。如果必须，可以联系管理员解除master的调度限制。

【问题】部署pod任务，报错
0/3 nodes are available: 1 node(s) were unschedulable, 2 node(s) didn’t match node selector.

【解决方法】
1.查看节点是否可调度

kubectl get nodes

2.如图，master被限制不可用
在这里插入图片描述
3.将pod部署到其他节点或者
4.联系root更改master的调度限制（一般不可取）

k8s-生产实例 常见pod 状态代码 以及错误问题原因
m0_66705547的博客
01-18 1533
云原生-k8s-pod状态
K8s集群节点调度禁用
weixin_42925911的博客
05-06 1035
也可以用kubectl describe pod pod_name -n namespace去查看，这个命令显示的信息更加详细一些，除了显示被分配到哪个节点，还会显示该pod的配置、状态及event等。如果pod异常，event会显示异常的原因。应用的场景：当k8s集群的某些节点压力过高时，可以暂时将这些节点禁用，使新启动的pod不再分配到这些节点上来(不会影响该节点上已存在的pod)node这一列显示每个pod被分配到哪个k8s集群节点上。4.怎么查看pod被调度到哪个k8s节点。
aws eks 理解和使用 karpenter 根据负载动态置备节点
zhaojiew的学习笔记
01-12 1203
karpenter的主要目的是根据pod的调度请求，动态预置节点来满足无法调度的pod。清空pod时快速删除节点释放资源
k8s设置node不可调度
魏志标的博客
03-22 2859
k8s设置节点不可调度
k8s Pod调度失败（NoExecute）排查及分析
u012516914的专栏
11-23 1万+
问题背景k8s集群，总共5个节点，信息如下所示：集群污点k8s版本系统版本master无1.14Centos 7.1work1有1.14Centos 7.1work2无1.14Cento...
实战：k8s之Descheduler-2022.2.19
weixin_39246554的博客
02-19 809
目录 文章目录目录实验环境实验软件1、Descheduler2、安装???? 案例演示：descheduler安装(测试成功)3、PDB4、策略1.PodLifeTime2.RemoveDuplicates3.LowNodeUtilization4.RemovePodsViolatingInterPodAntiAffinity5.RemovePodsViolatingNodeTaints6.RemovePodsViolatingNodeAffinity7.RemovePodsViolatingTopolog
基于真实场景解读 K8s Pod 的各种异常
因上努力，果上随缘。但行好事，莫问前程。
11-18 1240
在 K8s 中，Pod 作为工作负载的运行载体，是最为核心的一个资源对象。Pod 具有复杂的生命周期，在其生命周期的每一个阶段，可能发生多种不同的异常情况。K8s 作为一个复杂系统，异常诊断往往要求强大的知识和经验储备。结合实战经历以及 EDAS 用户真实场景的归纳，我们总结了 K8s Pod 的 13 种常见异常场景，给出各个场景的常见错误状态，分析其原因和排查思路。
k8s 指定节点调度标签
qq_36270681的博客
12-15 4597
nodeSelector 强制匹配 指定pod 调度到标签 ssd [root@k8s-master cka3]# cat ssd.yaml apiVersion: v1 kind: Pod metadata: name: nginx-kusc00401 spec: containers: - name: nginx image: nginx imagePullPolicy: IfNotPresent nodeSelector: disktype: s..
K8S故障临时设置节点为不可调度
weixin_45432833的博客
01-30 1811
k8s中节点故障处理方式
K8S的集群调度
2301_79410672的博客
01-08 1292
List-watch(监听)---会在每一步把监听的消息（先监听apiserver：6443）----每个组件（controller manager，scheduler，kubelet，etcd）都会监听apiserver：6443端口，都会获取消息。创建pod搭配节点时，由两个策略，先执行预选策略，再执行优选策略，这两步的操作都必须成功，否则立刻返回报错，也就是说，部署的node，必须满足这两个策略。选择pod时，申明了node01，我是硬策略，必须满足硬策略的条件，必须部署在node01，强制性要求。
k8s资源调度（节点选择、亲和性、污点）
m0_67758799的博客
09-12 2787
2.第二阶段：优选过程，节点优先级打分，对第一步筛选出的符合要求的主机进行打分，在主机打分阶段，调度器会考虑一些整体优化策略，比如把容一个Replication Controller的副本分布到不同的主机上，使用最低负载的主机等。注意，在节点故障情况下，为了保持现存的pod驱逐的限速设置，系统将会以限速的模式逐步给node设置Taint，这就能防止在一些特定情况下（比如master暂时失联）造成的大量pod被驱逐的后果。比如Pod指定了所需要的资源量，那么可用资源比Pod需要的资源量少的主机会被过滤掉。
Warning FailedScheduling 30s default-scheduler 0/1 nodes are available: 1 node(s) had untolerat
guoguangwu的专栏
10-25 3209
Warning FailedScheduling 30s default-scheduler 0/1 nodes are available: 1 node(s) had untolerat
node(s) didn‘t match node selector.
以梦为马|越骑越傻
03-07 8575
k8s集群中，有pod出现了 Pending ，通过 kubectl describe pod 命令，发现了如下报错 0/4 nodes are available: 1 node(s) had taint {node.kubernetes.io/disk-pressure: }, that the pod didn't tolerate, 3 node(s) didn't match node selector. 这是因为节点被打上了污点（pod的yaml文件中配置了 node selector .
jenkins构建pod是异常nodes are available: 4 node(s) didn‘t match node selector.
qq_35478580的博客
07-13 3132
在尝试jenkins+k8s集群时，构建pod到服务抛一下异常： Warning FailedScheduling 11s (x3 over 3m) default-scheduler 0/4 nodes are available: 4 node(s) didn’t match node selector. 网上找了好久，没有找到能解决问题的，自己慢慢比对配置文件，终于被我找到了问题所在； 创建服务的yaml文件中配置了： spec: nodeSelector: application: “tr
部署Pod非Running状态，describe查看显示node资源不足
大数据
05-03 1581
一、node 节点资源不足的几种情况： 1、执行kubectl top node 查看是否真的资源不足。 2、报资源不足有多种情况: 第一种是真的资源不足，第二种可能是Node上没有打Pod的yaml中定义的nodeSelector: 标签所以导致Pod找不到合适的Node就报此错误。 第二种node上是否无Pod Yaml中nodeSelector: 所需标签的确认法： 2.1、对Pod或者Pod的rc执行 kubectl get pod -n $namespace $Pod名 -o ya
0/1 nodes are available: 1 node(s) had taints that the pod didn‘t tolerate.
苦逼码农的博客
10-20 3912
k8s ，默认不允许主节点上部署pod 允许master节点部署pod kubectl taint nodes --all node-role.kubernetes.io/master- 如果不允许调度 kubectl taint nodes master1 node-role.kubernetes.io/master=:NoSchedule 污点可选参数 NoSchedule: 一定不能被调度 PreferNoSchedule: 尽量不要调度 NoExecute: 不仅不
K8S学习之污点容忍
weixin_60092693的博客
01-22 8567
污点：使节点能够排斥一类特定的 pod。Taint 和 toleration 相互配合，可以用来避免pod 被分配到不合适的节点上。 节点亲和性：是pod的一种属性（偏好或硬性要求），它使pod被吸引到一类特定的节点。 taints：污点，定义在节点上，是键值数据 tolerations：容忍度，定义在pod上，可以定义能容忍哪些污点 污点的查看 [root@master ~]# kubectl describe nodes master | grep Taints Taints:
0/1 nodes are available: 1 node(s) had taints that the pod didn't tolerate.
热门推荐
weixin_43224068的博客
01-21 2万+
允许master节点部署pod kubectl taint nodes --all node-role.kubernetes.io/master-
【力扣】返回倒数第k个节点
weixin_44764207的博客
10-12 372
实现一种算法，找出单向链表中倒数第 k 个节点。返回该节点的值。 示例： 输入： 1->2->3->4->5 和 k = 2 输出： 4 实现 /** * Definition for singly-linked list. * public class ListNode { * int val; * ListNode next; * ListNode(int x) { val = x; } * } */ class Solution {
k8s不调度节点
最新发布
05-29
### Kubernetes 节点不可调度的原因及解决方案 Kubernetes 集群中的节点不可调度问题可能由多种原因引起，包括资源不足、亲和性规则限制、网络插件异常等。以下是详细的原因分析及解决方案： #### 1. 节点状态为 NotReady 当节点状态显示为 `NotReady` 时，意味着该节点无法正常工作，这可能是由于以下原因之一： - **kubelet 服务未运行**：kubelet 是 Kubernetes 节点的核心组件，负责管理 Pod 和容器的生命周期。如果 kubelet 服务未启动或崩溃，节点将无法正常工作[^1]。 - **网络插件异常**：CNI（Container Network Interface）插件负责为 Pod 提供网络功能。如果 CNI 插件未正确安装或配置，可能导致节点进入 `NotReady` 状态[^1]。 - **磁盘压力或内存不足**：当节点上的磁盘使用率过高或内存不足时，Kubernetes 会标记该节点为 `NotReady`。 **解决方案**： - 检查 kubelet 服务是否正常运行，并尝试重启服务： ```bash systemctl restart kubelet ``` - 查看 CNI 插件的状态，确保其正常运行： ```bash kubectl get pods --namespace kube-system ``` - 如果是资源问题，可以释放磁盘空间或增加节点的计算能力。 #### 2. 资源不足 节点上可用资源不足（如 CPU、内存）可能导致新的 Pod 无法调度到该节点。即使节点状态为 `Ready`，但如果资源已耗尽，Pod 将无法被调度。 **解决方案**： - **释放资源**：删除不必要的 Pod 或减少其他 Pod 的资源请求： ```bash kubectl delete pod <unnecessary-pod> ``` - **调整资源请求**：修改 Pod 的资源配置文件，降低资源请求（requests）和限制（limits），以适应节点的实际可用资源[^2]。 #### 3. 亲和性和污点规则限制 Kubernetes 支持通过亲和性规则和污点（Taints）来控制 Pod 的调度位置。如果节点上设置了不匹配的污点或亲和性规则，可能会导致 Pod 无法调度到该节点。 **解决方案**： - 检查节点上的污点配置，并根据需要添加容忍规则（Tolerations）到 Pod 的配置中： ```yaml tolerations: - key: "key" operator: "Exists" effect: "NoSchedule" ``` - 确认亲和性规则是否正确设置，确保节点满足 Pod 的调度条件。 #### 4. 网络插件异常 如果 Kubernetes 集群使用的网络插件（如 Calico、Flannel）出现问题，可能导致节点无法正常通信，从而影响调度。 **解决方案**： - 检查网络插件的状态，确保其正常运行： ```bash kubectl get pods --namespace kube-system ``` - 如果发现网络插件相关 Pod 处于异常状态，可以尝试重启相关组件或重新部署网络插件[^1]。 #### 5. 应用程序错误或依赖问题 Pod 的 `CrashLoopBackOff` 状态通常是由于应用程序错误、配置问题或资源限制引起的。如果节点上存在大量处于此状态的 Pod，可能会影响整个节点的调度能力。 **解决方案**： - 查看 Pod 日志，定位问题所在： ```bash kubectl logs <pod-name> ``` - 检查配置文件，确保所有依赖项正确配置[^3]。 --- ### 示例代码 以下是一个示例 YAML 文件，用于调整 Pod 的资源请求和限制： ```yaml resources: requests: memory: "64Mi" cpu: "250m" limits: memory: "128Mi" cpu: "500m" ``` ---
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值