注意事项 佩雷夫 ：本文延续了来自Google的技术作家，Kubernetes（Andrew Chen）的文档工作以及SAP（Dominik Tornow）的软件工程总监的材料循环。 他们的目标是清楚清晰地解释Kubernetes的基础知识。 上次我们翻译了一篇有关高可用性的文章 ，现在我们将在Kubernetes中讨论诸如pod之类的基本概念。
Kubernetes是一个容器编排引擎，旨在在通常称为集群的多个节点上运行容器化的应用程序。 在这些出版物中，我们使用系统建模方法来提高对Kubernetes及其基本概念的理解。 鼓励读者已经对Kubernetes有了基本的了解。
Pod是Kubernetes的基本构建块，但是即使是经验丰富的Kubernetes用户也不能总是解释它是什么。
该出版物提供了简洁的思想模型，阐明了Kubernetes吊舱的定义特征。 为了简洁起见，我不得不省略Pod的其他一些功能，例如
活动性和就绪性探针 ，资源共享
（包括最近出现的名称空间共享 - 大约Transl。 ） ，与网络一起使用。
定义
吊舱是一种在单个节点上运行一个或多个容器的请求。
通过提出在单个节点上
执行一个或多个容器的请求来定义Pod，并且这些容器共享对资源（例如存储卷和网络堆栈）的访问。
但是，在日常生活中，术语“豆荚”既可以用于该
请求 ，也可以用于
收集响应该请求而启动
的容器 。 因此，在出版物中，当我们谈论请求时，将使用单词“ pod”，在第二种情况下，将使用表达式“容器集”。
Pod被视为Kubernetes的基本构建块，因为Kubernetes中的所有工作负载（例如
Deployments ，
ReplicaSets和
Jobs ）都可以表示为Pod。
Pod是Kubernetes中导致容器运行的
唯一对象。
没有吊舱-没有容器！
方案1.部署，ReplicaSet，pod和容器Kubernetes体系结构
方案2. Pod，Scheduler和Kubelet在此图中，突出显示了相应的对象和组件。
Pod表示为
Kubernetes Pod对象 ，并与它们一起使用：
Kubernetes对象
图3. Kubernetes对象下图显示了负责使用Pod的Kubernetes对象：
- 实际的pod对象（Pod Object） ；
- 绑定对象
- 节点对象
Pod Object设置将启动的容器集，以及在容器崩溃的情况下所需的
重新启动策略 ，并监视启动状态。
绑定对象将
Pod对象 绑定到
Node对象 ，即 将主机分配给主机以供以后启动。
节点对象代表Kubernetes集群中的一个节点。
豆荚加工
方案4.处理豆荚由用户或诸如
ReplicaSet Controller或
Job Controller之类的
控制器创建
Pod时 ，Kubernetes将分两步处理Pod：
- 调度程序正在计划一个广告连播，
- Kubelet启动吊舱。
吊舱规划
图5. Kubernetes Scheduler控制周期Kubernetes中的
Scheduler的任务是调度一个pod，即在Kubernetes集群中为其分配合适的节点以进行后续启动。
将Pod对象与节点对象相关联当且仅当存在具有以下内容的绑定对象时，才会将Pod分配给节点（或
绑定到该节点）：
- 名称空间等于pod名称空间，
- 名称等于广告连播的名称，
- 目标类型等于
Node ， - 目标的名称等于节点的名称。
（冒险爱好者可以看看Kelsey Hightower的GitHub主题，标题为“
手动创建和计划Pod ”，这是有关如何手动创建绑定对象的分步指南。）
吊舱发射
图6. Kubelet控制周期Kubelet的任务是启动Pod，这实际上意味着启动一组Pod容器。 Kubelet Pod的启动分为两个阶段：初始化和主要阶段。
通常，在初始化阶段，一组容器会进行准备工作，例如准备必要的目录和文件结构。 并且在主阶段的容器集已经执行了“最重要的”任务。
在日常生活中，尽管这并不完全正确，但“豆荚”一词通常意味着在主阶段包含一组容器，或者在主阶段的“最重要”容器中甚至具有更狭义的含义。
方案7.1。 启动Pod，初始化阶段（init）和主阶段（main）在初始化期间，Kubelet会根据
.Spec.InitContainers的规范并以列表中指定的顺序依次启动容器。 要成功启动pod并考虑重启策略，其init容器必须启动并成功完成。
在主要阶段，Kubelet会根据
.Spec.Containers的规范同时启动容器。 在这里，要成功启动Pod，并考虑到重新启动策略，必须启动其主容器，并且其成功完成或工作时间不受限制。
方案7.2。 正在运行的pod，此过程的详细信息如果发生容器故障，则当容器停止使用非零（0）
退出代码工作时 ，Kubelet可以根据pod重启策略来重启容器。 该策略具有以下含义之一：
Always ，
OnFailure ，
Never 。
容器重新启动策略对于初始化容器和主容器具有不同的语义：如果启动初始化容器必须导致完成，则主容器可能不会结束。
重新启动初始化容器的策略仅当满足以下条件时，才会在其工作完成后重新启动初始容器（即，它将启动具有相同规格的新容器）：
- 容器退出代码报告错误，并且
OnFailure重启策略为Always或OnFailure 。
重新启动主容器的策略仅在满足以下条件时，主容器才会在工作完成后重新启动（即，启动具有相同规格的新容器）：
- 重新启动策略定义为
Always或 - 重新启动策略定义为
OnFailure ，并且容器退出代码报告错误。
图8.带红点的时间轴示例，表示容器故障该图显示了可能的容器启动时间线，其中包含两个初始化容器规范和两个主要容器规范。 它还显示在
主容器1.1启动出现问题之后（根据重新启动策略）新的
主容器1.2容器的创建。
吊舱阶段
图9. Kubelet与pod对象和容器运行时的交互（容器运行时）Kubelet接收
.Spec.InitContainers和
.Spec.Containers的容器规范，启动指定的容器集，并相应地更新
.Status.InitContainerStatuses和
.Status.ContainerStatuses的
.Status.InitContainerStatuses值。
Kubelet将
.Status.InitContainerStatuses和
.Status.ContainerStatuses折叠为一个值
.Status.Phase 。
pod阶段是一组容器中容器状态的投影，它取决于：
- 初始化容器的状态和退出代码，
- 主要容器的状态和退出代码。
方案10.吊舱的阶段待定
待定阶段当且仅在以下情况下，吊舱处于等待阶段：
- 没有一个Pod init容器处于
Terminated状态且有错误（ Failure ）； - 所有主要的容器容器都处于“
Waiting状态。
跑步
运行阶段只有在以下情况下，Pod才能进入工作阶段：
- 所有pod init容器均成功处于“已
Terminated状态； - 至少一个主容器处于
Running状态； - 没有一个主Pod容器处于带有
Failure的Terminated状态。
成功的
成功阶段Pod处于以下情况的成功阶段：
- 所有pod init容器均成功处于“已
Terminated状态； - 所有主要的容器容器都已成功地处于“已
Terminated状态。
失败的
失败阶段当且仅当以下情况，吊舱处于故障阶段：
- 所有吊舱容器均处于“已
Terminated状态； - 至少一个容器容器处于“已
Terminated状态，并显示错误（“ Failure ）。
不明
除了上述阶段之外，吊舱可能处于未知阶段，这表明无法确定其当前阶段。
豆荚垃圾收集
图11. Pod垃圾收集器控制周期在计划和启动
Pod之后 ，Kubernetes中的特殊控制器-Pod
Garbage Collector Controller-负责从
Kubernetes Object Store中删除pod对象。
结论
Pod是Kubernetes的基本构建块：Pod定义为在单个节点上启动一个或多个容器的请求的表示。 创建Pod之后，Kubernetes分两个阶段对其进行处理：首先，
调度程序调度Pod，然后Kubelet启动它。 吊舱在其整个生命周期中会经历不同的阶段，并向用户和系统报告状态（或更准确地说是其容器组的状态）。
译者的PS
另请参阅我们的博客：