直入主题
开发反馈说他们起的任务一直在运行中，让我看一下，于是我去get了一眼，发现这个pod一直在Pending状态。首先kubectl describe pod -n nsname podname查看详细问题情况，发现是因为没有找到匹配的node资源不够。已经解决了所以找不到截图了总之就是 cpu 0/1之类的。按我这种小白的排查办法先top以下查看进程资源占用情况结果：
李奶奶的，这不是CPU还有很多资源吗，于是我kubectl describe nodes | grep -A6 Alloctaed
如上图不难发现，k8s集群中确实资源分配已经几乎不足了，于是我上网查了下有没有解决办法，结果并没有，这里我记录一个问题：（
k8s中node节点在kubelete的配置文件中是否可以修改Allocated资源>硬件资源的值），没办法没找到开发又着急只能临时解决了，将pod亲和度的标签打到Node1让node1来分担压力吧，就有了上图这样的资源占用情况：
kubectl lable nodes nodename key=true
不过我找到了总结很漂亮的话，在这里记录以下：
requests：需求，最低保障, 保证被调度的节点上至少有的资源配额
limits：限制，硬限制, 容器可以分配到的最大资源配额
如果Pod中所有Container的所有Resource的limit和request都相等且不为0，则这个Pod的QoS
Class就是Guaranteed。
注意，如果一个容器只指明了limit，而未指明request，则表明request的值等于limit的值。
Qos Class优先级排名
Guaranteed > Burstable > Best-Effort
可压缩资源与不可压缩资源
Pod 使用的资源最重要的是 CPU、内存和磁盘 IO，这些资源可以被分为可压缩资源（CPU）
和不可压缩资源（内存，磁盘 IO）。
可压缩资源(CPU)不会导致pod被驱逐
因为当 Pod 的 CPU 使用量很多时，系统可以通过重新分配权重来限制 Pod 的 CPU 使用
不可压缩资源(内存)则会导致pod被驱逐
于不可压缩资源来说，如果资源不足，也就无法继续申请资源（内存用完就是用完了），
此时 Kubernetes 会从该节点上驱逐一定数量的 Pod，以保证该节点上有充足的资源。k8s中node节点在kubelete的配置文件中是否可以修改Allocated资源>硬件资源的值：
关于这个资源问题已经找到答案，部署时决定k8s资源分配模式，具体配置文件以后找到再贴。修改对应pod的deploy中cpu.request值为0，limits值保持不变，即可