查看pod节点，节点和pod

K8S——Pod入门理解

个人理解：pod是容器组的一个抽象，类似于一栋出租楼里面的房子，房子的其他小房间像容器，房间里的水，电充当应用服务。出租屋内的小房间门跟容器端口差不多，出租屋大门像POD上的端口，整栋楼大门像Service对外暴露的端口。2使用Pod的原因？pod是K8s最小的运行，部署单位。

普通pod：最常见的pod类型，用于运行一个或多个容器。静态pod：一种特殊的pod类型，通常由kubelet直接在节点上管理，不通过K8S API服务器进行调度。pod的定义与创建：yaml文件：定义pod较为简单，通过编写yaml文件实现。yaml文件包含容器的配置信息，如镜像、端口、环境变量等。

K8S POD控制器从基础到高级实战技巧的核心要点如下：基础概念： Kubernetes的POD控制器：是容器编排的关键，负责维护Pod的生命周期。 主要类型： ReplicaSet：确保指定数量的Pod副本运行，提供高可用性。 Deployment：支持版本控制和滚动更新，适用于大多数应用。

K8s的网络理解，特别是Pods、Services和Ingress，可以总结如下：Pods： 定义：Pods是构成Kubernetes应用的基本单元，包含了一个或多个容器以及它们共享的网络栈。 网络命名空间：Pods的网络命名空间与宿主机的物理网络命名空间独立，通过自定义桥接与宿主机相连。

k8s中Pod状态及问题排查方法

1、含义：调度器未能将 Pod 调度到可用节点。可能原因：节点资源不足或 Pod 依赖的资源未准备好。排查方法：检查节点资源使用情况及资源预留情况，确保集群有足够的 CPU 和其他资源。CrashLoopBackoff 状态：含义：容器在启动后立即崩溃或退出。可能原因：容器配置错误、应用程序错误、内存不足或权限问题。

2、要排查镜像拉取问题，可使用kubectl describe pod命令检查pod事件，寻找“Failed to pull image”或“ImagePullBackOff”事件，表明镜像拉取存在问题。资源不足时，使用kubectl describe Node命令检查节点资源状态。检查持久卷（PVC）状态，确保其STATUS为“Bound”，表明存储供应无问题。

3、Pod驱逐 节点资源不足时，K8s驱逐内存敏感型Pod。优化资源配额和限制值，避免资源被耗尽。Pod失联 Pod处于Unknown状态，无法获取信息。检查Kubelet状态，修复节点问题。无法被删除 Pod执行删除操作后长时间处于Terminating状态。排查删除操作和集群状态，确保删除流程顺利。

4、在Pod调度到目标节点后，节点需要拉取Pod所需镜像。镜像拉取失败可能由镜像地址配置错误、集群免密配置缺失、网络问题（如访问控制策略未配置、专有网络连接问题、拉取海外镜像未配置镜像加速服务）、带宽限制或镜像体积过大导致拉取超时、或同时大量Pod并发拉取镜像时的资源竞争引起。

如何指定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是否成功调度到具有所需标签的节点。

排查Pod卡在Terminating状态

1、首先检查一下是否有finalizers，如果有可能是无法完成的根本原因。获取pod配置：并且检查 metadata 下面有 finalizers ，如果有则跳到 方案A）。pod可能运行在因为某种原因发生故障的节点。

2、在后续重试过程中，再次执行runc kill时，发现容器已不存在，导致cri删除容器失败，并无法umount容器rootfs。这一问题最终导致Pod卡在Terminating状态。通过修复代码，如在调用runc kill后添加特殊判断，我们解决了这个问题。尽管修复代码本身相对简单，但整个问题的发现和分析过程耗时数天。

3、在处理现网问题时，经常遇到Pod在terminating状态下停滞不前的状况，这可能是由于多种原因导致的，比如containerd错误信息处理不当或umount失败等。这类问题的排查通常需要借助kubelet或dockerd日志、容器和Pod状态、堆栈信息等手段。

4、在节点出现不可用状态，如“NotReady”，Deployment控制器会迁移容器实例，并将运行中的Pod置为“Terminating”。这种情况下，Terminating状态的Pod会在节点恢复后自动删除。然而，有时部分Pod会长期停留在Terminating状态，表明它们未能得到重新调度，导致服务中断。

5、我这里的pod是与nfs有关，nfs挂载有问题导致pod有问题，执行完删除命令以后看到pod一直处于terminating的状态。这种情况下可以使用强制删除命令：kubectl delete pod [pod name] --force --grace-period=0 -n [namespace]注意：必须加-n参数指明naMESpace，否则可能报错pod not found。

6、Pod处于Unknown状态，无法获取信息。检查Kubelet状态，修复节点问题。无法被删除 Pod执行删除操作后长时间处于Terminating状态。排查删除操作和集群状态，确保删除流程顺利。为解决上述异常，EDAS提供了应用变更预检、事件追踪观测和诊断工具箱等解决方案。