k8s将pod指定node运行（k8s的pod和node）
k8s一个pod加载多个containers,指定POD运行的node
- containerport： 80 nodeSelector Pod.spec.nodeSelector通过kubernetes的label-selector机制选择节点，由调度器调度策略匹配label，而后调度Pod到目标节点，该匹配规则属于强制约束。
在Pod定义中添加nodeSelector。创建Pod并检查状态，验证其被调度至指定节点。方式二：通过指定NodeName。在Pod中配置nodeName字段，直接指派对应节点。示例如下：查看node名称。列出节点名称，例如k8s-master。在Pod中使用nodeName指定此节点。通过kubectl APPly创建Pod后，检查Pod是否调度至指定节点。
PodAffinit是根据通过已运行在节点上的pod的标签而不是node的标签来决定被调度pod的运行节点，因为pod运行在指定的namespace所以需要自己指定运行pod的namesapce 上面这个例子中的 POD 需要调度到某个指定的主机上，至少有一个节点上运行了这样的 POD：这个 POD 有一个App=busybox-pod的 label。
一种方法是在业务层处理。比如，通过共享的本地 Volume，使用文件锁的机制，可以实现多个并发的 Container 依次执行。但这需要在业务逻辑中，把并发强行改为同步，增加了开发复杂度。如果能使用 Kubernetes 本身的机制实现，则减免了很大的开发工作量。以下是另外的三种方案。
如何指定pod的运行节点?
1、方式二：通过指定NodeName。在Pod中配置nodeName字段，直接指派对应节点。示例如下：查看node名称。列出节点名称，例如k8s-master。在Pod中使用nodeName指定此节点。通过kubectl apply创建Pod后，检查Pod是否调度至指定节点。使用nodeName选择节点方式存在局限性。方式三：亲和性和反亲和性。
2、假设以下场景：有三个Node，分别为1010109，创建Deployments来部署Tomcat应用，指定在107节点上创建Pod。解决方案 nodeName Pod.spec.nodeName将Pod直接调度到指定的Node节点上，会跳过Scheduler的调度策略，该匹配规则是强制匹配。
3、通过实战操作，可以更直观地理解这些概念。以nodeName调度为例，指定Pod必须运行在特定的节点上。nodeSelector调度则是基于特定的标签选择节点。Node亲和调度则更进一步，通过标签选择特定的Node进行Pod部署。同样，Pod亲和调度则关注Pod之间的关系。
4、首先，团队使用装有Docker的机器，构建并运行了一个自定义的jenkins-jnlp-agent镜像，以固定节点的形式接入Jenkins。在流水线项目中绑定该节点，使用Docker运行该镜像并连接到Jenkins。
5、实战步骤如下： 在集群中为节点添加标签。例如，设置app： goweb-node。 编写goweb应用的Deployment文件。设置Pod的定义，确保与应用需求相匹配。 为Deployment添加nodeSelector字段，指定Pod应部署在具有特定标签的节点上，如app=goweb-node。 验证Pod是否成功调度到具有所需标签的节点。
6、在实践中，可以通过以下步骤查看特定 pod 的日志。首先，前往运行该 pod 的节点，查找 kubelet 存放的日志文件。这些文件通过数字表示重启次数，例如 2393 和 2394，分别代表第 2393 次和第 2394 次重启后的日志。这些日志文件实际上是链接文件，指向 docker 容器的日志文件。
k8s将pod调度到指定节点的几种方式
1、方式二：通过指定NodeName。在Pod中配置nodeName字段，直接指派对应节点。示例如下：查看node名称。列出节点名称，例如k8s-master。在Pod中使用nodeName指定此节点。通过kubectl apply创建Pod后，检查Pod是否调度至指定节点。使用nodeName选择节点方式存在局限性。方式三：亲和性和反亲和性。
2、假设以下场景：有三个Node，分别为1010109，创建Deployments来部署Tomcat应用，指定在107节点上创建Pod。解决方案 nodeName Pod.spec.nodeName将Pod直接调度到指定的Node节点上，会跳过Scheduler的调度策略，该匹配规则是强制匹配。
3、在集群中为节点添加标签。例如，设置app： goweb-node。 编写goweb应用的Deployment文件。设置Pod的定义，确保与应用需求相匹配。 为Deployment添加nodeSelector字段，指定Pod应部署在具有特定标签的节点上，如app=goweb-node。 验证Pod是否成功调度到具有所需标签的节点。
K8S调度:实战完nodeSelector后,再谈应用场景。
nodeSelector是Kubernetes中用于将Pod调度到具有特定标签的节点上的机制。例如，可以设置app： my-app，Kubernetes调度器会寻找标签为app=my-app的节点，将Pod部署在其上。这提供了基本的调度能力，还有更复杂的特性如Node Affinity、podAffinity、Taints and Tolerations。
调度流程包括过滤和打分两个步骤。过滤阶段，调度器筛选出满足条件的节点；打分阶段，对筛选出的节点进行评分，最终选择得分最高的节点部署 Pod。节点选择器（nodeSelector）允许用户基于特定标签选择节点。例如，确保某些 Pod 落实在具有特定属性（如 SSD 硬盘）的节点上。
在 Kubernetes 的调度机制中，nodeSelector 和 nodeAffinity 是两种用于决定 Pod 部署到哪个节点的关键规则。nodeSelector：定义：允许用户基于特定标签选择节点。用途：确保 Pod 被部署到具有特定属性的节点上，例如具有 SSD 硬盘的节点。限制：相对简单，只支持基于标签的精确匹配。
k8s环境下，将REST Service部署至指定node list，需借助Node Selector、Affinity、nodeName等机制实现精准控制。基本策略包含三类：Node Selector、Affinity、nodeName。其中，Node Selector通过Pod中的nodeSelector属性直接指定目标node，通过key-value pairs匹配，仅需一对即可。
K8S线上集群排查,实测排查Node节点NotReady异常状态
1、K8S线上集群Node节点NotReady异常状态的排查方法主要包括以下几点：检查硬件资源：使用df m命令检查磁盘空间，确保有足够的空间供Node节点和Pod使用。使用free命令检查cpu使用率，确保CPU资源未被过度占用。使用top c命令查看CPU使用情况，确保无异常。
2、在项目中遇到的线上集群问题，特别是Kubernetes （K8S）集群中Node节点状态变为NotReady，导致服务停止的问题，我们进行了一次深入的排查与解决。文章将聚焦于如何有效识别和解决这类问题。首先，让我们了解一下在K8S中Pod的状态。
3、在搭建Kubernetes（k8s）集群过程中，若遇到节点一直处于NotReady状态问题，通过执行命令查看日志，发现提示信息为[failed to find plugin flannel in path [/opt/cni/bin]]。执行排查步骤，进入指定目录检查，确认flannel插件是否缺失。
4、一次K8S集群中遇到的Too Many Open Files问题排查，起因是一个运行机器学习推理服务的节点出现Node NotReady异常，通过查看日志发现是因为dockerd进程打开的文件数过多导致。初步怀疑是由于root用户文件限制较小，将限制调整为655360后重启docker进程，但问题并未解决，而是陆续在其他节点上重复出现。
