k8s一个node跑多少pod，k8s的nodeport

K8S线上集群排查,实测排查Node节点NotReady异常状态

K8S线上集群Node节点NotReady异常状态的排查方法主要包括以下几点：检查硬件资源：使用df m命令检查磁盘空间，确保有足够的空间供Node节点和pod使用。使用free命令检查cpu使用率，确保CPU资源未被过度占用。使用top c命令查看CPU使用情况，确保无异常。

在项目中遇到的线上集群问题，特别是kubernetes （K8S）集群中Node节点状态变为NotReady，导致服务停止的问题，我们进行了一次深入的排查与解决。文章将聚焦于如何有效识别和解决这类问题。首先，让我们了解一下在K8S中POD的状态。

在搭建Kubernetes（k8s）集群过程中，若遇到节点一直处于NotReady状态问题，通过执行命令查看日志，发现提示信息为[failed to find plugin flannel in path [/opt/cni/bin]]。执行排查步骤，进入指定目录检查，确认flannel插件是否缺失。

如何查询K8s资源运行状态

首先，使用“kubectl get Pods -n xujianhua-gz”命令来查询指定namespace下的Pod状态，其中“-n”参数用于指定namespace，例如xujianhua-gz。通过命令输出，我们可以看到有6个处于running状态的Pod，其中2个运行nacos服务，2个运行nginx，还有2个部署了WordPress博客。

安装过程包括以下步骤：首先，下载部署文件，即 components.yaml 文件。随后，将部署文件中的镜像地址修改为国内的地址，位于部署文件的第 140 行。修改后的配置如下所示。在部署文件中，通过调整镜像地址，确保国内用户能够流畅访问。在部署完成后，查看 metrics server 的运行状态。

资源不足时，使用kubectl describe node命令检查节点资源状态。检查持久卷（PVC）状态，确保其STATUS为“Bound”，表明存储供应无问题。网络问题难以诊断，需检查CNI插件日志，如使用Calico，可查看Calico pod日志。安全上下文问题，使用kubectl get pod-o yaml命令查看pod安全上下文。

k8s一个pod加载多个containers,指定pod运行的node

- containerport： 80 nodeSelector Pod.spec.nodeSelector通过kubernetes的label-selector机制选择节点，由调度器调度策略匹配label，而后调度Pod到目标节点，该匹配规则属于强制约束。

PodAffinit是根据通过已运行在节点上的pod的标签而不是node的标签来决定被调度pod的运行节点，因为pod运行在指定的namespace所以需要自己指定运行pod的namesapce 上面这个例子中的 POD 需要调度到某个指定的主机上，至少有一个节点上运行了这样的 POD：这个 POD 有一个APP=busybox-pod的 label。

在Pod定义中添加nodeSelector。创建Pod并检查状态，验证其被调度至指定节点。方式二：通过指定NodeName。在Pod中配置nodeName字段，直接指派对应节点。示例如下：查看node名称。列出节点名称，例如k8s-master。在Pod中使用nodeName指定此节点。通过kubectl Apply创建Pod后，检查Pod是否调度至指定节点。

一种方法是在业务层处理。比如，通过共享的本地 Volume，使用文件锁的机制，可以实现多个并发的 Container 依次执行。但这需要在业务逻辑中，把并发强行改为同步，增加了开发复杂度。如果能使用 Kubernetes 本身的机制实现，则减免了很大的开发工作量。以下是另外的三种方案。

在K8s集群中，若要了解node、Pod、Service等资源的运行情况，可按照以下步骤进行。首先，使用“kubectl get pods -n xujianhua-gz”命令来查询指定namespace下的Pod状态，其中“-n”参数用于指定namespace，例如xujianhua-gz。