在Kubernetes概念中，有以下五种概念：

• 容器container：镜像管理的最小单位
• 生产任务Pod：容器组，资源调度最小单位
• 节点Node：对应集群中的单台机器，是硬件单元的最小单位
• 集群Cluster：对应整个集 群，是处理元数据的最小单位
• 集群联邦Federation：对应多个集群，是满足跨可用区域多活、跨地域容灾的要求

其中Pod的概念是随Kubernetes一起推出的。
Kubernetes项目是基于Google内部的Borg系统的经验和设计理念创建的，其中Pod的概念就是一个关键部分。因此，可以说Pod是从2014年6月Kubernetes项目发布之初就存在的。
当当我们要理解Pod时，就需要先理解为什么需要Pod这个概念。

单容器单应用的原因

假设你有一个高流量的Web应用服务器，需要详细记录访问和错误日志。同时，你希望实时处理这些日志，例如进行分析、监控或立即警报异常情况。你会将应用服务器和日志代理服务作为两个进程， 但此时你需要思考，我能否将这2个进程放在一个容器中,例如写成下面这样的dockerfile：

FROM python:3.8

# 安装依赖
RUN pip install xxxxx

# 复制文件
COPY web_service.py /web_service.py
COPY log_processor.py /log_processor.py

# 启动脚本，同时运行web服务和日志处理（不推荐）
CMD python /web_service.py & python /log_processor.py

这是项目初期常见的方式，可能为了快速开发日志特性，直接就在一个dockefile里搞了。

但这是不推荐的实践。

首先，dockerfile只允许一个entrypoint。
这个“entrypoint”是一个指定的命令或脚本，这个命令或脚本在容器启动时运行，并且成为容器中的第一个进程（即PID为1的进程）。在Docker的设计中，每个容器通常运行一个主要的应用或服务，而这个应用或服务就是通过entrypoint启动的。

同时，容器中，PID为1的进程是当你运行一个容器时由Dockerfile中的ENTRYPOINT或CMD指令指定的进程。这个进程在容器的生命周期内扮演类似于init进程的角色。如果PID为1的进程终止，Docker知道容器已经完成了它的工作或因为某种原因失败了，然后Docker可以决定是重启容器还是简单地记录其退出状态。

基于以上两点，容器只能默认监控主进程（PID为1）的状态来决定是否需要重启容器。

此时如果第二个日志进程出问题了，在你未进行特制的健康处理时，是无法感知该状态，也无法让调度系统重新拉起这个容器。

因此为了容器监测的有效性，优选策略是始终保持单容器单应用的特点，一个应用做成一个容器。

空间共享，高效通信

上面那个例子的另一个问题在于，如果跨界点分配这2个容器， 会有什么后果？

一个是会产生网络延迟和带宽，因为两个节点之间的通信会经过网络，这会增加延迟。对于日志收集这样频繁的操作，即使是微小的延迟也会累积成显著的性能损失。
其次是数据一致性。网络问题可能导致日志数据在传输过程中丢失，特别是在没有适当可靠性保证的系统中。或者因为节点时间同步问题，导致日志记录与实际事件之间出现时间上的不一致。

所以我们必须要求这2个容器一定分配要在同一个节点

因此，POD的概念就出现了。 他用于封装2个容器，并始终保证调度到同一个节点上。

除了数据文件的读取和写入，同POD内的2个容器也支持基于操作系统的信号通信（不经过网络），则需要这2个容器依赖相同的IPC名称空间。

总之pod能共享以下内容：

• UTS名称空间：所有容器都有相同的主机名和域名
• 网络名称空间：所有容器都共享一样的网卡、网络栈、IP地址等。同一个Pod中容器占用的端口不能冲突
• IPC名称空间：可以用信号量或者POSIX共享内存
• 时间名称空间： 共享相同的系统时间
  注：但POD中PID名称空间和文件名称空间仍然是隔离的。

POD共享空间的原理

上面提到的POD能供共享名称空间，其能力是通过pause容器实现的。

Pause容器通常是一个非常小的容器镜像。它的主要任务是执行一个永久“暂停”操作，因此它不会消耗很多资源，同时也是每个Pod的第一个启动的容器。
Pause容器作为持续运行的进程，为Pod中的其他容器提供了一个共同的父进程。这使得所有的容器都可以共享同一个网络命名空间（即它们都可以看到相同的网络接口和IP地址等）和IPC命名空间

虽然它大部分时间处于暂停状态，Pause容器在Pod的生命周期中充当了状态传递和协调的角色。比如，在重新启动或移除Pod时，它协助协调和维护状态一致性。