排查Pod卡在Terminating状态

本文将介绍 k8s 中的一些最基本的命令，并辅以解释一些基本概念来方便理解，也就是说，本文是一篇偏向实用性而非学术性的文章，如果你想提前了解一下 k8s 相关的知识的话，可以通过以下链接进行学习：

k8s 是经典的一对多模型，有一个主要的管理节点 master 和许多的工作节点 slaver 。当然，k8s 也可以配置多个管理节点，拥有两个以上的管理节点被称为 高可用 。k8s 包括了许多的组件，每个组件都是单运行在一个 docker 容器中，然后通过自己规划的虚拟网络相互访问。你可以通过 kubectl get pod -n kube-system 查看所有节点上的组件容器。

在管理节点中会比工作节点运行更多的 k8s 组件，我们就是靠着这些多出来的组件来对工作节点发号施令。他们都叫什么这里就不详细提了。反正对于”基本使用“来说，这些名字并不重要。

要想理解一个东西就要先明白它的内在理念。通俗点就是，k8s 做了什么？为了提供更加可靠的服务，就要增加服务器的数量，减少每个服务器的体量来平摊负载，而越来越多的虚拟机就会带来越来越高的运维成本。如何让少量的运维人员就可以管理数量众多的服务器及其上的服务呢？这就是 k8s 做的工作。

k8s 把数量众多的服务器重新抽象为一个统一的资源池 ，对于运维人员来说，他们面前没有服务器1、服务器2的概念，而是一个统一的资源池，增加新的服务器对运维人员来说，只是增加自资源池的可用量。不仅如此，k8s 把所有能用的东西都抽象成了资源的概念，从而提供了一套更统一，更简洁的管理方式。

接下来，我会把每个基本命令当做一节来进行介绍，并辅以介绍一些基本概念。本文介绍的命令涵盖了增删改查四方面，可参加下面表格，因为篇幅较长，我们将 create 及之后的不那么常用的命令放在下一篇文章 k8s 基本使用（下） 里讲：

接下来进入正题，首先来了解一下 k8s 中最最最常用的命令 kubectl get ，要记住，k8s 把所有的东西都抽象成了资源，而 kubectl get 就是用来查看这些资源的。最常见的资源就是 pod 。

不仅我们自己的服务是要包装成 pod 的，就连 k8s 自己也是运行在一堆 pod 上。接下来就让我们查看一下 k8s 的 pod ：

-n 参数指定了要查看哪个命名空间下的 pod 。 k8s 所有的 pod 都被放置在 kube-system 命名空间下。

执行了 kubectl get pod -n kube-system 命令后，你就可以看到如下内容：

其中每一行就是一个资源，这里我们看到的资源是 pod 。你看到的 pod 数量可能和我的不一致，因为这个列表里包含了 k8s 在所有节点上运行的 pod ，你加入的节点越多，那么显示的 pod 也就越多。我们来一列一列的看：

kubectl get 可以列出 k8s 中所有资源

这里只介绍了如何用 kubectl 获取 pod 的列表。但是不要把 get 和 pod 绑定在一起，pod 只是 k8s 中的一种服务，你不仅可以 get pod ，还可以 get svc ( 查看服务 )、 get rs ( 查看副本控制器 )、 get deploy ( 查看部署 )等等等等，虽然说 kubectl get pod 是最常用的一个，但是如果想查看某个资源而又不知道命令是什么， kbuectl get <资源名> 就对了。

如果你想看更多的信息，就可以指定 -o wide 参数，如下：

加上这个参数之后就可以看到资源的所在 ip 和所在节点 node 了。

记得加上 -n

-n 可以说是 kubectl get 命令使用最频繁的参数了，在正式使用中，我们永远不会把资源发布在默认命名空间。所以，永远不要忘记在 get 命令后面加上 -n 。

kubectl get 命令可以列出 k8s 中的资源，而 kubectl get pod 是非常常用的查看 pod 的命令。而 -n 参数则可以指定 pod 所在的命名空间。

kubectl describe 命令可以用来查看某一资源的具体信息，他同样可以查看所有资源的详情， 不过最常用的还是查看 pod 的详情 。他也同样可以使用 -n 参数指定资源所在的命名空间。

举个例子，我们可以用下面命令来查看刚才 pod 列表中的某个 pod，注意不要忘记把 pod 名称修改成自己的：

然后你就可以看到很多的信息，咱们分开说，首先是基本属性，你可以在详细信息的开头找到它：

基本属性

其中几个比较常用的，例如 Node 、 labels 和 Controlled By 。通过 Node 你可以快速定位到 pod 所处的机器，从而检查该机器是否出现问题或宕机等。通过 labels 你可以检索到该 pod 的大致用途及定位。而通过 Controlled By ，你可以知道该 pod 是由那种 k8s 资源创建的，然后就可以使用 kubectl get <资源名> 来继续查找问题。例如上文 DaemonSet/kube-flannel-ds-amd64 ，就可以通过 kubectl get DaemonSet -n kube-system 来获取上一节资源的信息。

内部镜像信息

在中间部分你可以找到像下面一样的 Containers 段落。该段落详细的描述了 pod 中每个 docker 容器的信息，常用的比如 Image 字段，当 pod 出现 ImagePullBackOff 错误的时候就可以查看该字段确认拉取的什么镜像。其他的字段名都很通俗，直接翻译即可。

事件

在 describe 查看详情的时候，最常用的信息获取处就是这个 Event 段落了，你可以在介绍内容的末尾找到它，如下：

是的，如果你看到上面这样，没有任何 Events 的话，就说明该 pod 一切正常。当 pod 的状态不是 Running 时，这里一定会有或多或少的问题，长得像下面一样，然后你就可以通过其中的信息分析 pod 出现问题的详细原因了：

kubectl describe <资源名> <实例名> 可以查看一个资源的详细信息，最常用的还是比如 kubectl describe pod <pod名> -n <命名空间> 来获取一个 pod 的基本信息。如果出现问题的话，可以在获取到的信息的末尾看到 Event 段落，其中记录着导致 pod 故障的原因。

如果你想查看一个 pod 的具体日志，就可以通过 kubectl logs <pod名> 来查看。注意，这个只能查看 pod 的日志。通过添加 -f 参数可以持续查看日志。例如，查看 kube-system 命名空间中某个 flannel pod 的日志，注意修改 pod 名称：

然后就可以看到如下输出：

如果你发现某个 pod 的服务有问题，但是状态还是显示 Running ，就可以使用 kubectl logs 来查看其详细日志。

在本篇文章里，我们了解了 k8s 的宗旨和一些基本概念，并知道了最为常用的 get 、 descibe 及 logs 命令，知道了这三条命令之后就几乎可以从 k8s 中获取所有常用信息了。接下来的 k8s 基本使用（下） 里，我们会更深一步，来了解 k8s 中如何创建、修改及删除资源。

Clifton F Vaughn 答案: 确实如此，在这个方面 C# 与 C++ 是有差别的。在 C++ 中，如果你从构造函数或者析构函数中调用虚拟函数，编译器调用的虚拟函数是定义在这个正在被构造的类实例中的（例如，如果从 Base::Base 中调用 Base::SomeVirtFn ），不是最底层派生的实例（the most derived instance），正像你说的那样，因为在最底层派生的构造函数执行之前，虚表还没有完全被初始化。另一种说法是派生类还没有被创建。

Figure 2 虚拟函数 TestSimilarly

正如你所指出的那样，在 C# 有所不同。托管对象——无论是在 C#，托管 C++ 中，还是任何其它的 NET 兼容语言中——是作为其最终类型被创建的，也就是说，如果你从构造函数或析构函数中调用虚函数，系统调用的是最末层派生的函数。Figure 1 所示程序举例说明了这一点。如果你编译并运行这个程序，你会看到 Figure 2 所示输出。

这种行为对于 C++ 程序员来说似乎有些奇特。它意味着在派生类被初始化之前，你可以调用某个派生类型的虚拟函数——也就是说在其构造函数运行之前。同样，如果你从基类析构函数中调用虚函数，该函数是在派生类被销毁之后运行的——也就是说在析构函数被调用之后。那么先不说这种差别存在的原因，刚才不是还说从构造函数/析构函数中调用虚函数被认为是糟糕的实践。

为什么微软的家伙们要像这样来设计 C# 呢？因为它简化了内存管理。垃圾收集器为了释放内存，它需要知道对象有多大。如果 C# 像 C++ 那样构造对象，那么你可能会碰到这样一种情况：有两个对象，Obj1 和 Obj2，下面这两条语句都为真：typeof(Obj1)==typeof(Obj2) sizeof(Obj1)!= sizeof(Obj2) 因为对象之一是被部分构造。（不要忘了垃圾收集器是异步运行的。）通过将对象构造成最终类型，垃圾收集器能从其类型决定对象的大小。如果 C# 像 C++ 那样进行部分构造，则垃圾收集器将需要更多的代码来决定部分构造对象的真实大小。这样将带来复杂性和性能下降，首先要解决这个问题很让人气馁，所以为了较快的垃圾收集利益，微软的家伙们决定像上面那样来实现 C#。有关这方面的讨论参见 Raymond Chen 的 blog：“The Old New Thing”。

问题: 在2004 三月的专栏中，你展示了如何改变文件打开对话框的最新视图状态设置，但没有涉及到保存这个用户使用的最新视图设置。我遇到的问题是读取用户已有的打开文件对话框设置。我只找到直接读取列表框信息的方法，但当用户选择缩略图模式时，那样做不能得到正确的信息。对此你有没有解决办法？ Maarten van Dillen 问题: 我正在用公共的 CFileDialog 类做开发，应该不是很难，但事情似乎并不是那样。我想强制文件打开对话框的视图模式为缩略图。我要用 Visual C++ 来做，你能否提供一些建议？ Elliot Leonard

答案: 有几个读者都在问文件打开对话框中的缩略图问题。在我三月份的专栏中，我示范了如果向文件打开对话框中的 SHELLDLL_DefView 专用窗口发送 WM_COMMAND 消息以设置不同的视图模式——但你如何知道当前所处的模式是哪一个呢？你必须获取列表控件并调用 CListCtrl::GetView：// in dialog class HWND hlc = ::FindWindowEx(m_hWnd, NULL, _T("SysListView32"), NULL); CListCtrl plc = (CListCtrl)CWnd::FromHandle(hlc); DWORD dwView = plc->GetView(); CListCtrl::GetView 返回 LV_XXX 代码之一，但正像 Maarten 发现的那样，Windows 对图标模式和缩略图模式都返回 LV_VIEW_ICON。

那么如何区分到底是哪种视图模式呢？我绞尽脑汁并钻进头文件查找，最后发现一个叫 LVM_GETITEMSPACING 的消息，该消息是作什么用的呢——用来获取图标间隔。顾名思义，图标间隔是图标视图模式中图标之间的像素间隔。LVM_GETITEMSPACING 不是很好使用，以至于 MFC 都没有对之进行包装（比如说 MFC 中并没有 CListCtrl::GetIconSpacing 这样的函数）。所以在 MFC 中你得自己发送消息：CSize sz = CSize(plc->SendMessage(LVM_GETITEMSPACING)); Windows 按照通常方式返回尺寸，在高位和低位字中编码的 cx/cy，然后CSize很礼貌地为你进行解码。一旦有了图标间隔，你便可以将它与 GetSystemMetrics(SM_CXICONSPACING) 返回的系统间隔值进行比较。如果列表视图的图标间隔与系统的一样，则视图是图标模式。如果大于系统间隔，则视图为缩略图模式：if (szcx > GetSystemMetrics(SM_CXICONSPACING)) { // thumbnail view } else { // icon view } 讲了那么多缩略图，接下来的问题是如何持续化不同用户会话的视图状态？对此，当程序终止时，你需要用 Profile 函数在用户配置文件中保存最后使用的模式，并在下一次启动程序时再次恢复它。我写了一个小示范程序，DlgTest。程序使用了一个实现持续化程序行为的类 CPersistOpenDlg。这个类又借助另外一个类 CListViewShellWnd，用它来封装 SHELLDLL_DefView 窗口（参见三月份专栏）。CListViewShellWnd 包含获取和设置视图模式的函数，由这些函数来区分图标和缩略图模式：CListViewShellWnd m_wndLVSW; m_wndLVSWSetViewMode(ODM_VIEW_THUMBS); CListViewShellWnd 的 OnDestroy 处理器在某个数据成员 m_lastViewMode 中保存视图模式。当对话框被销毁时，CPersistOpenDlg 的析构函数调用 WriteProfileInt 将这个值写入用户配置文件。对话框启动时，CPersistOpenDlg 给自己送一个初始化消息；该消息处理例程调用 GetProfileInt 从磁盘读取存储在配置文件中的值并设置视图模式。PostMessage 是必须调用的，因为常规初始化消息 WM_INITDIALOG 和 CDN_INITDONE 在文件对话框被完全初始化之前就会到来——有关这一点的解释参见三月份专栏。

顺便说一下，任何时候你都应该使用 GetProfileXxx 和 WriteProfileXxx 来持续化应用程序的设置。MFC 用 CWinApp 包装了这些函数。如果你在应用程序启动时调用（一般都是在 InitInstance 函数中） CMyApp::SetRegistryKey("KeyName")，MFC 使用注册表来存储用户配置信息，而不是 INI 文件。下面是 DlgTest 用的 INI 文件： [settings] ViewMode=28717问题: 偶尔在一些文字资料和 C++ 文档以及 Microsoft NET 框架中看到术语“POD 类型”。这个术语是什么意思？

Shelby Nagwitz 答案: 你可以将 POD 类型看作是一种来自外太空的用绿色保护层包装的数据类型，POD 意为“Plain Old Data”（译者：如果一定要译成中文，那就叫“彻头彻尾的老数据”怎么样！）这就是 POD 类型的含义。其确切定义相当粗糙（参见 C++ ISO 标准），其基本意思是 POD 类型包含与 C 兼容的原始数据。例如，结构和整型是 POD 类型，但带有构造函数或虚拟函数的类则不是。 POD 类型没有虚拟函数，基类，用户定义的构造函数，拷贝构造，赋值 *** 作符或析构函数。

为了将 POD 类型概念化，你可以通过拷贝其比特来拷贝它们。此外， POD 类型可以是非初始化的。例如：struct RECT r; // value undefined POINT ppoints = new POINT[100]; // ditto CString s; // calls ctor ==> not POD 非POD 类型通常需要初始化，不论是调用缺省的构造函数（编译器提供的）还是自己写的构造函数。

过去， POD 对于编写编译器或与C 兼容的 C++ 程序的人来说很重要。现在，POD 来到 NET 的环境中。在托管 C++ 中，托管类型（包括 __value 和 __gc 两者）能包含嵌入的原生 POD 类型。 Figure 3 展示了例举说明代码。托管的 Circle 类能包含 POINT，但无法包含 CPoint 类。如果你尝试编译 podcpp 会报一个 C3633 错误：“Cannot define ''m_center'' as a member of managed ''Circle'' because of the presence of default constructor ''CPoint::CPoint'' on class ''CPoint''”（译者：意思是由于类 CPoint 有缺省的构造函数‘CPoint::CPoint’，所以不能将‘m_center’定义为托管类‘Circle’的一个成员）

NET 限定嵌入的本地对象只能为 POD 类型的理由是这样做能安全地拷贝它们，不用担心调用构造函数，初始化虚表，或任何非 POD 类型需要的其它机制。

向Paul 提问和评论请发到 cppqa@microsoftcom

作者简介 Paul DiLascia 是一名自由作家，顾问和 Web/UI 设计者。他是《Writing Reusable Windows Code in C++》书（Addison-Wesley, 1992）的作者。

Pod的 重启策略（RestartPolicy ）应用于 Pod内！！！ 的 所有容器 ，并且 仅在Pod所处的Node！！！ 上由 kubelet 进行 判断和重启 *** 作。

当 某个容器！！！ 异常退出或者健康检查（详见下节）失败时，kubelet将根据 RestartPolicy的设置 来进行相应的 *** 作。

Pod的重启策略包括Always、OnFailure和Never，默认值为Always。

kubelet 重启失效容器 的 时间间隔 以 sync-frequency 乘以 2n 来计算，例如1、2、4、8倍等， 最长延时5min ，并且在成功重启后的10min后重置该时间。

Pod的重启策略与控制方式息息相关，当前 可用于管理Pod的控制器 包括 ReplicationController 、 Job 、 DaemonSet 及 直接通过kubelet 管理（ 静态Pod ）。

每种控制器 对Pod的 重启策略要求！！！ 如下。

以上就是关于排查Pod卡在Terminating状态全部的内容，包括:排查Pod卡在Terminating状态、cephfs目录共享给多个pod使用、k8s系列(二):Pods与Nodes等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！