排查Pod卡在Terminating状态

pod已经被删除，并且卡在Terminated状态较长时间，可能是因为：

这个手册用于排查pod已经被删除，但长时间卡在Terminate状态，或者长于自己期望的时间。

当运行命令 kubect get pods ，你可以看到关于pod的输出：

1收集信息

2检查finalizers

3检查节点状态

4强制删除

首先检查一下是否有finalizers，如果有可能是无法完成的根本原因。

获取pod配置：

并且检查 metadata 下面有 finalizers ，如果有则跳到 方案A)。

pod可能运行在因为某种原因发生故障的节点。

如果从 /tmp/runbooks_pod_configurationtxt 文件里面所指定的节点上所有的pod都卡在Terminated状态，那么极有可能是因为node节点故障导致的，可以通过运行命令检查：

由于没有想用终止信号,pod可能不会终止，具体原因可能取决于程序的具体情况，常见原因可能包含：

如果没有其他效果，可以尝试在pod所在的节点上重启kubelet，查看 方案C

A) 删除finalizer

B) 强制删除pod

C) 重启kubelet

删除pod的finalizers，运行命令：

请注意，这是解决方法不是解决方案，请谨慎行事确保问题不会进一步恶化。另外请参与 Statefulset 有关的详细信息。

强制删除运行命令：

如果不生效，请重新参照排查手册，检查一下解决思路。

如果可以，SSH登陆到节点上重启kubelet进程，重启之前可以检查kubelet的日志是否有异常信息。

如果 kubectl get pod 没有显示pod存在那么问题就得到了解决:

如果问题进一步出现，你可能需要：

根据终结器需要完成的工作有所不同。

终结器未完成的常见情况包括

这将根据终结器的 *** 作有所不同，并且需要特定的上下文知识。

可以检查kubelet的日志，可能会包含一些有用的信息。

Finalizers

Container Lifecycle Hooks

Termination of Pods

Unofficial Kubernetes Pod Termination

Kubelet logs

原文: >

  一个pod是一组紧密相关的容器，是一起运行在同一个工作节点上，以及同一个Linux命名空间中。每个pod就像是一个独立的逻辑机器，拥有自己的IP、主机名、进程等，运行一个独立的应用程序。

  pod是逻辑主机，一个pod的所有容器都运行在同一个逻辑机器上，其他pod中的容器，即使运行在同一个工作节点上，也会出现在不同的节点上。即一个pod包含多个容器时，这些容器总是运行在同一个工作节点上，一个pod绝不可能跨多个工作节点。

举例 ：

  每个pod自有IP，包含1个或多个容器，每个容器运行一个应用进程

查看pod命令

$ kubectl get pods

READY：0/1 表示pod的单个容器显示为未就绪的状态；相反，1/1表示已就绪；

STATUS: Pending 表示pod处于挂起状态；相反，Running表示pod处于运行状态；

  运行应用两大步骤：1）构建镜像并推送至镜像仓库中；2）K8s创建pod进行调度；

流程：

1）本地构建镜像；

2）推送镜像至镜像仓库；

3）kubectl创建并部署应用；

4）kubectl发出REST请求至REST API服务器；

5）创建pod并调度到工作节点；

6）kubelet收到通知；

7）kubelet告知Docker运行镜像；

8）Docker从镜像仓库中拉取镜像；

9）Docker创建并运行容器；

  如果单个容器中运行多个不相关的进程，保持所有进程运行、管理它们的日志将很难，需要包含一种在进程崩溃时能够自动重启的机制，同事，这些进程都将记录到相同的标准输出中，很难确定每个进程分别记录的内容。

  不能讲多个进程聚集在一个单独的容器中，需要pod将容器绑定在一起，并将它们作为一个单元进行管理，在包含容器的pod下，可以同时运行一些密切现骨干的进程，并为其提供相同的环境，此时这些进程就好像全部运行于单独的容器中，同时保持一定的隔离性。

  k8s可以通过配置docker让一个pod内的所有容器共享相同的Linux命名空间（network、UTS命名空间、IPC命名空间），从而使容器都共享相同的主机名、网络名和IPC通信。

  同一个pod中的容器运行的多个进程不能绑定到相同的端口号，否则会端口冲突（每个pod都有独立的端口空间，不同pod中的容器不会有端口冲突现象。）

  同一个pod中的容器具有相同的loopback网络接口，所以容器可以通过localhost与同一个pod中的其他容器进行通信。

注意 ：

  容器不应该包含多个进程，pod也不应该包含多个并不需要运行在同一主机上的容器。如下图：

1）yaml中使用的kubernetes API版本和yaml描述的资源类型；

2）metadata：包括名称、命名空间、标签和关于该容器的其他信息；

3）spec：包含pod内容的实际说明，如pod的容器、卷和其他数据；

4）status：包含运行中的pod的当前信息，如pod所处的条件、每个容器的描述和状态，以及内部IP和其他基本信息。

描述信息：

1）该文件遵循Kubernetes API的v1版本；

2）描述的资源类型是pod；

3）资源名称为kubia-manual；

4）该pod由基于luksa/kubia镜像的单个容器组成；

5）容器名称为kubia；

6）容器监听的端口是8080；

按名称删除

$ kubectl delete po pod_name

其中， pod_name 为pod名称；删除命令指示uk8s终止该pod中所有容器，k8s向进程发送一个SIGTERM信号并等待一定的秒数（默认30s）,使得其正常关闭，若未及时关闭，则通过SIGKILL终止进程。

删除多个pod

$ kubectl delete po pod_name1 pod_name2

多个pod删除使用空格隔开；

按照标签删除

$ kubectl depete po -l tag_key=tag_value

其中， tag_key 为标签健， tag_value 为标签值；

按照整个命名空间删除

$ kubectl delete ns namespace_name

其中， namespace_name 为命名空间名称

Namespace是kubernetes系统中的一种非常重要资源，它的主要作用是用来实现 多套环境的资源隔离 或者 多租户的资源隔离 。

默认情况下，kubernetes集群中的所有的Pod都是可以相互访问的。但是在实际中，可能不想让两个Pod之间进行互相的访问，那此时就可以将两个Pod划分到不同的namespace下。kubernetes通过将集群内部的资源分配到不同的Namespace中，可以形成逻辑上的组，以方便不同的组的资源进行隔离使用和管理。

可以通过kubernetes的授权机制，将不同的namespace交给不同租户进行管理，这样就实现了多租户的资源隔离。此时还能结合kubernetes的资源配额机制，限定不同租户能占用的资源，例如CPU使用量、内存使用量等等，来实现租户可用资源的管理。

然后就可以执行对应的创建和删除命令了：

Pod是kubernetes集群进行管理的最小单元，程序要运行必须部署在容器中，而容器必须存在于Pod中。

Pod可以认为是容器的封装，一个Pod中可以存在一个或者多个容器。

kubernetes在集群启动之后，集群中的各个组件也都是以Pod方式运行的。可以通过下面命令查看：

创建并运行

kubernetes没有提供单独运行Pod的命令，都是通过Pod控制器来实现的

查看pod信息

访问Pod

删除指定Pod

配置 *** 作

创建一个pod-nginxyaml，内容如下：

然后就可以执行对应的创建和删除命令了：

Label是kubernetes系统中的一个重要概念。它的作用就是在资源上添加标识，用来对它们进行区分和选择。

Label的特点：

可以通过Label实现资源的多维度分组，以便灵活、方便地进行资源分配、调度、配置、部署等管理工作。

标签定义完毕之后，还要考虑到标签的选择，这就要使用到Label Selector，即：

当前有两种Label Selector：

标签的选择条件可以使用多个，此时将多个Label Selector进行组合，使用逗号","进行分隔即可。例如：

name=slave，env!=production

name not in (frontend)，env!=production

命令方式

配置方式

然后就可以执行对应的更新命令了：kubectl apply -f pod-nginxyaml

在kubernetes中，Pod是最小的控制单元，但是kubernetes很少直接控制Pod，一般都是通过Pod控制器来完成的。Pod控制器用于pod的管理，确保pod资源符合预期的状态，当pod的资源出现故障时，会尝试进行重启或重建pod。

在kubernetes中Pod控制器的种类有很多，本文只介绍一种：Deployment。

命令 *** 作

查看创建的Pod

查看deployment的信息

查看deployment的详细信息

删除

配置 *** 作

创建一个deploy-nginxyaml，内容如下：

然后就可以执行对应的创建和删除命令了：

前面已经能够利用Deployment来创建一组Pod来提供具有高可用性的服务。

虽然每个Pod都会分配一个单独的Pod IP，然而却存在如下两问题：

这样对于访问这个服务带来了难度。因此，kubernetes设计了Service来解决这个问题。

Service可以看作是一组同类Pod 对外的访问接口 。借助Service，应用可以方便地实现服务发现和负载均衡。

*** 作一：创建集群内部可访问的Service

*** 作二：创建集群外部也可访问的Service

删除Service

配置方式

创建一个svc-nginxyaml，内容如下：

然后就可以执行对应的创建和删除命令了：

至此，介绍了Namespace、Pod、Deployment、Service资源的基本 *** 作，有了这些 *** 作，就可以在kubernetes集群中实现一个服务的简单部署和访问了，但是如果想要更好的使用kubernetes，就需要深入学习这几种资源的细节和原理。

以上就是关于排查Pod卡在Terminating状态全部的内容，包括:排查Pod卡在Terminating状态、k8s-pod之DaemonSet、Kubernetes-Pod基本概念（六）等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！