01.Pod
Pod
Pod 是 K8s 可以部署和管理的最小的可部署单元。换句话说，如果您需要在 K8s 中运行单个容器，则需要为该容器创建一个 Pod。同时，如果这些容器相对紧密地耦合，则 Pod 可以包含多个容器。在 Pod 里面，Container 之间可以共享网络（IP/Port）、共享存储（Volume）、共享 Hostname。另外，Pod 可以理解成一个逻辑主机，它与非容器领域的物理主机或者 VM 有着类似的行为。在同一个 Pod 运行的进程就像在同一物理主机或 VM 上运行的进程一样，只是这些进程被单独的放到单个 container 内。
从容器到 Pod
这里的 Docker 指的是 Docker engine（也叫做 Docker daemon，或最新的名字：Moby），它是一种容器运行时（container runtime）的实现，而且是最主流的实现，几乎就是容器业界的事实标准。Docker 是用来创建和管理容器的，它和容器的关系就好比 Hypervisor（比如：KVM）和虚拟机之间的关系。当然，Docker 公司对 Docker engine 本身的定位和期望不仅仅在于在单机上管理容器，所以近年来一直在向 Docker engine 中加入各种各样的高级功能，比如：组建多节点的 Docker 集群、容器编排、服务发现，等等。
而 K8s，是搭建容器集群和进行容器编排的主流开源项目（由 Google 发起并维护），适合搭建 PaaS 平台。容器是 K8s 管理的核心目标对象，它和容器的关系就好比 OpenStack 和虚拟机之间的关系，而它和 Docker 的关系就好比 OpenStack 和 Hypervisor 之间的关系。一般来说，K8s 是和 Docker 配合使用的，K8s 调用每个节点上的 Docker 去创建和管理容器，所以，你可以认为 K8s 是大脑，而 Docker 是四肢。因此，在这样的背景下，Docker 逐渐式微，而 K8s 崛起，就毫不奇怪了。
K8s 与 Docker 最典型而直接的差异，即 Docker 中是以容器为最小单元，而 K8s 中是以 Pod 为最小执行单元，下面我们就简要讨论下两种设计在实际环境中的差异。
为什么需要 Pod？
-
为什么 K8s 使用 Pod 作为最小的可部署单元而不是单个容器？容器是现有实体，表示特定的事物，例如 Docker 容器。要管理容器，K8s 需要其他信息，例如重启策略或实时探测。重新启动策略定义了终止容器时的处理方式。实时探针定义了一种操作，以从应用程序的角度检测容器中的进程是否仍处于活动状态，例如，Web 服务器是否响应 HTTP 请求。K8s 架构师决定使用一个新实体 Pod 逻辑上包含（包装）一个或多个容器，而应将其作为一个实体进行管理，而不是使用其他属性来使现有事物过载。
-
为什么 K8s 在一个 Pod 中允许多个容器？Pod 中的容器在“逻辑主机”上运行：它们使用相同的网络名称空间（相同的 IP 地址和端口空间），IPC 名称空间，并且可以选择使用共享卷。因此，这些容器可以有效地进行通信，从而确保数据的局部性。此外，Pod 允许将多个紧密耦合的应用程序容器作为一个单元进行管理。
因此，如果应用程序需要在同一主机上运行多个容器，为什么不使用这些容器中的所有内容制作一个容器？首先，将许多东西放到一个容器中可能会违反“每个容器一个进程”的原则。其次，为应用程序使用多个容器更易于使用，更透明，并允许将软件依赖关系解耦。同样，团队之间可以重复使用更多的细粒度容器。
使用案例
多容器 Pod 的主要目的是为主程序支持位于同一地点，受共同管理的帮助程序。在 Pod 中有一些使用辅助过程的一般模式：
-
Sidecar 容器“帮助”主容器。例如，日志或数据更改监视程序，监视适配器等。例如，日志观察者可以由不同的团队构建一次，并可以在不同的应用程序中重复使用。边车容器的另一个示例是为主容器生成数据的文件或数据加载器。
-
代理，网桥，适配器将主容器与外部环境连接起来。例如，Apache HTTP 服务器或 Nginx 可以提供静态文件，并充当主容器中 Web 应用程序的反向代理，以记录和限制 HTTP 请求。另一个示例是一个帮助容器，该容器将请求从主容器重新路由到外部世界，因此主容器连接到本地主机以访问例如外部数据库，而没有发现任何服务。
虽然您可以在单个 Pod 中托管多层应用程序（例如 WordPress），但建议的方法是为每个层使用单独的 Pod。这样做的原因很简单：您可以独立地扩展层并在群集节点之间分布它们。