pod 是 Kubernetes 中最为重要的核心概念，而其他对象仅仅用于 pod 管理、 pod 暴露或被 pod 使用。 pod 是一组并置的容器，代表了 Kubernetes 中的基本构建模块。 P53
当一个 pod 包含多个容器时，这些容器总是运行于同一个工作节点上——一个 pod 绝不会跨越多个工作节点。 P54
为何多个容器比单个容器中包含多个进程要好 P54
假设一个由多个进程组成的应用程序，无论是通过 IPC （进程间通信）还是本地存储文件进行通信，都要求它们运行于同一台机器上。如果在单个容器中运行多个不相关的进程，那么保持所有进程运行、管理它们的日志等将会是我们的责任。例如，我们需要包含一种在进程奔溃时能够自动重启的机制；同时这些进程都将记录到相同的标准输出中，而此时我们将很难确定每个进程分别记录了什么。 P54
了解 pod P55由于不能将多个进程聚集在一个单独的容器中，我们需要另一种更高级的结构来将容器绑定在一起，并将它们作为一个单元进行管理，这就是 pod 背后的真正原因。 P55
在包含容器的 pod 下，我们可以同时运行一些密切相关的进程，并为它们提供（几乎）相同的环境，此时这些进程就好像全部运行于单个容器中一样，同时又保持着一定的距离。这样一来，我们便能全面地利用容器所提供的特性，同时对这些进程来说它们就像运行在一起一样。 P55
同一 pod 中容器之间的部分隔离 P55
Kubernetes 通过配置 Docker 来让一个 pod 内的所有容器共享相同的 Linux 命名空间，而不是每个容器都有自己的一组命名空间。 P55
由于一个 pod 中的所有容器都在相同的 Network 和 UTS 命名空间下运行（[01. Kubernetes 介绍](https://mp.weixin.qq.com/s/nfZPrWPHr3OXKb2Poefo-w），所以它们都共享相同的主机名和网络接口。同样地，这些容器也都在相同的 IPC 命名空间下运行，因此能够通过 IPC 进行通信。在最新的 Kubernetes 和 Docker 版本中，它们也能够共享相同的 PID 命名空间，但是该特性默认未开启。 P55
注意：当一个 pod 中的容器使用单独的 PID 命名空间时，在容器中执行 ps aux 就只会看到容器自己的进程。 P55
由于大多数容器的文件系统来自容器镜像，因此默认情况下，每个容器的文件系统与其他容器完全隔离。但我们可以使用名为 Volume 的 Kubernetes 资源来共享文件目录。 P55
容器如何共享相同的 IP 和端口空间 P55
由于同一个 pod 中的容器运行于相同的 Network 命名空间中，因此在同一个 pod 中的容器运行的多个进程需要注意不能绑定到相同的端口号，否则会导致端口冲突。同一个 pod 中的所有容器具有相同的 loopback 网络接口，因此容器可以通过 localhost 与同一 pod 中的其他容器进行通信。 P55
由于每个 pod 都有独立的端口空间，对于不同 pod 中的容器来说则永远不会遇到端口冲突。 P55
介绍扁平化 pod 间网络 P56
Kubernetes 集群中的所有 pod 都在同一个共享网络地址空间中，每个 pod 都可以通过其他 pod 的 IP 地址来实现相互访问，即这些 pod 之间没有 NAT （网络地址转换）网关。当两个 pod 彼此之间发送网络数据包时，它们都会将对方的实际 IP 地址看作数据包中的源 IP 。 P56
总结： pod 是逻辑主机，其行为与非容器世界中的物理主机或虚拟机非常相似。运行在同一个 pod 中的进程与运行在同一物理机或虚拟机上的进程相似，只是每个进程都封装在一个容器之中。 P56
通过 pod 合理管理容器 P56将多层应用分散到多个 pod 中 P57
基于扩缩容考虑而分割到多个 pod 中： Kubernetes 不能横向扩缩单个容器，只能扩缩整个 pod P57
紧密耦合到容器组可以添加到同一个 pod 中：通常为一个主容器和若干个支持容器 P57
主容器：可以是 Web 服务器
支持容器：可以是日志轮转器、收集器、数据处理器、通信适配器等