包含runningpod的词条
k8s中pod状态及问题排查方法
含义：调度器未能将 POD 调度到可用节点。可能原因：节点资源不足或 Pod 依赖的资源未准备好。排查方法：检查节点资源使用情况及资源预留情况，确保集群有足够的 cpu 和其他资源。CrashLoopBackOff 状态：含义：容器在启动后立即崩溃或退出。可能原因：容器配置错误、应用程序错误、内存不足或权限问题。
解决方法：仔细检查Pod的YAML配置文件，确保语法正确且配置合理。可以使用kubectl describe pod 命令查看Pod的详细信息，以获取更多关于错误的信息。总结：Pod状态一直处于Pending通常是由于资源不足、调度问题、镜像拉取问题、权限问题或配置错误等原因导致的。
如果原因是Pod无法安装请求的卷，请确保清单适当地指定其详细信息并确保Pod可以访问存储卷。或者，如果该节点没有足够的资源，则手动从该节点删除Pod，以便将Pod调度到另一个节点上。否则，可以扩展节点资源容量。如果使用nodeSelector安排Pod在kubernetes集群中的特定节点上运行，就会发生这种情况。
要排查镜像拉取问题，可使用kubectl describe pod命令检查pod事件，寻找“Failed to pull image”或“ImagePullBackOff”事件，表明镜像拉取存在问题。资源不足时，使用kubectl describe node命令检查节点资源状态。检查持久卷（PVC）状态，确保其STATUS为“Bound”，表明存储供应无问题。
在面临Docker容器被频繁kill掉，以及k8s中该节点pod被驱赶的情况时，要找出问题的根源，关键在于深入分析容器的运行状态、内存使用情况以及系统资源的分配状况。以下为解决此类问题时，可以采取的步骤与工具，帮助您更直观地找出问题所在。首先，要从容器输出和状态详情入手。
K8S故障检查-Pod处于CONTAINERCreating状态
1、常见导致pod长时间处于“ContainerCreating”状态的原因包括镜像拉取问题、资源不足、持久卷问题、网络问题以及安全上下文或Docker/运行时问题。要排查镜像拉取问题，可使用kubectl describe pod命令检查pod事件，寻找“Failed to pull image”或“ImagePullBackOff”事件，表明镜像拉取存在问题。
2、面对k8s应用卡在ContainerCreating状态的困扰，我通过kubectl describe po命令获取到了关键的日志信息。
3、问题描述：Pod处于终止状态或状态未知，通常与节点故障或删除操作相关。解决办法：强制删除Pod；检查节点的健康状态，必要时重启节点组件；检查集群的删除操作是否正确执行。UnexpectEDAdmISSionError：问题描述：Pod因节点磁盘空间不足而无法正常创建或运行。
4、ContainerCreating：这种情况表示容器正在创建中，常见于配置问题导致的容器创建失败。例如，当使用docker服务时，可能会遇到节点上的kube-proxy、kubelet或docker服务重启后容器仍无法创建的情况。解决这类问题，通常需要检查服务的运行状态，确认资源是否充足，或者是否存在网络、存储配置问题。
5、一个pod的完整创建，通常会伴随着各种事件的产生，k8s种事件的种类总共只有4种：PodStatus 有一组PodConditions。PodCondition中的ConditionStatus，它代表了当前pod是否处于某一个阶段（PodScheduled，Ready，Initialized，Unschedulable），“true” 表示处于，“false”表示不处于。
如何查询K8s资源运行状态
在K8s集群中，查询资源运行状态的方法主要包括以下几步：查询指定namespace下的Pod状态：使用命令kubectl get pods n [namespace]，其中[namespace]替换为具体的命名空间名称，例如xujianhuagz。此命令将列出该命名空间下所有Pod的状态。
首先，使用“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 的运行状态。
仅需关注任务执行结果。总结： Pod 的状态反映了其在 Kubernetes 集群中的运行情况。 针对不同状态，需要采取不同的排查方法，以快速定位并解决问题。 合理分配资源、监控资源使用情况、检查容器配置和日志等是排查问题的关键步骤。
资源不足时，使用kubectl describe node命令检查节点资源状态。检查持久卷（PVC）状态，确保其STATUS为“Bound”，表明存储供应无问题。网络问题难以诊断，需检查CNI插件日志，如使用Calico，可查看Calico pod日志。安全上下文问题，使用kubectl get pod-o yaml命令查看pod安全上下文。
首先，要从容器输出和状态详情入手。通过运行`docker logs $container_id`，您可以直接查看容器内的应用程序输出，以获取实时运行信息。接着，`docker inspect $container_id`可提供容器的详细状态信息，其中特别要注意“OOMKilled”信息，该信息表示容器因内存不足而被Docker自动终止。
[kubernetes]Endpoints详解
Endpoints 是 Kubernetes 中一个重要的资源对象，它表示一个 Service 对应的所有 Pod 副本的访问地址。以下是关于 Endpoints 的详细解释：Endpoints 的定义与功能 Endpoints 是可被访问的服务端点，它通常指向一个状态为 Running 的 Pod。
kubernetes提供了多种控制器来满足不同的集群管理需求，本文将介绍其中的六大控制器：EndPoints、Ingress、DaemonSet、StatefulSet、Job、cronJob，通过理解它们的特性与应用场景，可以更高效地构建和管理容器化应用。EndPoints控制器负责将外部服务接入集群，使得服务能在集群内部被发现与访问。
服务注册的过程大致如下：将服务配置文件上传给apisever，服务对象生成，同时自动生成endpoints对象，配置网络，服务注册。Kubernetes 自动创建一个 Endpoints 对象（或 Endpoint slices）用于每个服务。这些对象包含匹配标签选择器的 Pod 列表，并将接收来自服务的流量。
