kubernetes之pod

kubernetes之pod

1.介绍pod

pod是一组并置的容器，代表了Kubernetes中的基本构建模 块。在实际应用中我们并不会单独部署容器，更多的是针对组pod 的容器进行部署和操作。然而这并不意味着一个pod总是要包含多个容器---实际上只包含一个单独容器的pod也是非常常见的。值得注意的是，当一个pod 包含多个容器时 这些容器总是运行于同一个工作节点上----- pod绝不会跨越多个工作节点。（能跨越多个节点是多个pod，由控制器控制，概念不要搞混）

1.1 为何需要pod

关于为何需要pod这种容器？为何不直接使用容器？为何甚至需要同时运行多个容器？难道不能简单地把所有进程都放在一个单独的容器中吗？接下来将回答上述问题。

为何多个容器比单个容器中包含多个进程要好

想象一个由多个进程组成的应用程序，无论是通过ipc (进程间通信）还是本地存储文件进行通信，都要求它们运行于同一台机器上。在 Kubernetes中，我们经常在容器中运行进程，由于每一个容器都非常像一台独立的机器，此时你可能认为单个容器中运行多个进程是合乎逻辑的，然而在实践中这种做法并不合理。

容器被设计为每个容器只运行一个进程除非进程本身产生子进程）。如果在单个容器中运行多个不相关进程，那么保持所有进程运行、管理它们的日志等将会是我们的责任。例如，我们需要包含一种在进程崩溃时能够自动重启的机制。同时这些进程都将记录到相同的标准输出中，而此时我们将难确定每个进程分别记录了什么。

综上所述，我们需要让每个进程运行于自己的容器中，而这就是Docker和 Kuberneters期望使用的方式。

1.2 了解pod

由于不能将多个进程聚集在一个单独的容器中，我们需要另一种更高级结构来将容器绑定在一起，并将它们作为一个单元进行管理，这就是pod背后的根本原理。

在包含容器的pod 下，我们可以同时运行一些密切相关进程,并为它们提供(几乎相同的环境，此时这些进程就好像全部运行于单个容器中一样，同时又保持着一定的隔离。这样一来，我们便能全面地利用容器所提供的特性，同时对这些进程来说它们就像运行在一起一样，实现两全其美。

同一pod中容器之间的部分隔离

在上一章中，我们己经了解到容器之间彼此是完全隔离的，但此时我们期望的是隔离容器组，而不是单个容器，并让每个容器组内的容器共享一些资源，而不是全部（换句话说没有完全隔离）。Kubernetes 过配置Docker来让一个pod 内的所有容器共享相同的Linux命名空间，而不是每个容器都有自己的一组命名空间。

由于一个pod 中的所有容器都在相同的network和UTS 命名空间下运行（这里我们讨论的是Linux命名空间），所以它们都共享相同的主机名和网络接口。同样地，这些容器也都在相同的IPC 命名空间下运行，因此能够通过IPC 进行通信。在最新的Kubernetes和D ocker版本中，它们也能够共享相同的PID命名空间，但是该特征默认是未激活的。

注意: 当同一个pod中的容器使用单独 PID 命名空间时，在容器中执 ps aux 就只会看到容器自己的进程。

当涉及文件系统时，情况就有所不同。由于大多数容器的文件系统来自容器镜像，因此默认情况下，每个容器的文件系统与其他容器完全隔离。但我们可以使用名为VolumeKube rnetes资源来共享文件目录。这个会单独讲解。

容器如何共享相同的IP 和端口空间

这里需强调的一点是，由于一个pod 中的容器运行于相同的Network命名空间中，因此它们共享相同的IP 地址和端口空间。这意味着在同一 pod 中的容器运行的多个进程需要注意不能绑定到相同的端口号，否则导致端口冲突，但这只涉及同一pod 中的容器。由于每个pod 都有独立的端口空间，对于不同pod 中的容器来说则永远不会遇到端口冲突。此外，一个pod 中的所有容器也都具有相同的loopback 络接口，因此容器可以通过localhost与同一 pod 中的其他容器进行通信。

介绍平坦pod间网络

Kubernetes集群中的所有pod 都在同一个共享网络地址空间中（ 图3.2所示）,这意味着每个pod 都可以通过其他podIP地址来实现相互访问。换句话说，这也表示它们之间没 NAT( 网络地址转换）网关。当两个pod 彼此之间发送网络数据时，它们都会将对方的实际IP 地址看作数据包中的源IP。

因此，pod之间的通信其实是非常简单的。不论是将两个pod安排在单一的还是不同的工作节点上，同时不管实际节点间的网络拓扑结构如何，这些pod内的容器都能够像在无NAT的平坦网络中一样相互通信，就像局域网（LAN)上的计算机一样。此时，每个pod都有自己的IP地址，并且可以通过这个专门的网络实现pod之间互相访问。这个专门的网络通常是由额外的软件基于真实链路实现的。

总结本节涵盖的内容：pod是逻辑主机，其行为与非容器世界中的物理主机或虚拟机非常相似。此外，运行在同一个pod中的进程与运行在同一物理机或虚拟机上的进程相似，只是每个进程都封装在一个容器之中。

1.3 通过pod合理管理容器

将pod视为独立的机器，其中每个机器只托管一个特定的应用。过去我们习惯于将各种应用程序塞进同一台主机，但是pod不是这么干的。由于pod比较轻量,我们可以在几乎不导致任何额外开销的前提下拥有尽可能多的pod。与将所有内容填充到一个pod中不同，我们应该将应用程序组织到多个pod中，而每个pod只包含紧密相关的组件或进程。

说到这里，对于一个由前端应用服务器和后端数据库组成的多层应用程序，你认为应该将其配置为单个pod还是两个pod呢？下面我们将对该问题做进一步探讨。

将多层应用分散到多个pod中

虽然我们可以在单个pod中同时运行前端服务器和数据库这两个容器，但这种方式并不值得推荐。前面我们己经讨论过，同一pod的所有容器总是运行在一起，但对于Web服务器和数据库来说，它们真的需要在同一台计算机上运行吗？答案显然是否定的，它们不应该被放到同一个pod中。那假如你非要把它们放在一起，有错吗？某种程度上来说，是的。

如果前端和后端都在同一个容器中，那么两者将始终在同一台计算机上运行。 如果你有一个双节点Kubemetes集群，而只有一个单独的pod,那么你将始终只会用一个工作节点，而不会充分利用第二个节点上的计算资源（CPU和内存）。因此更合理的做法是将pod拆分到两个工作节点上，允许Kubemetes将前端安排到一个节点，将后端安排到另一个节点，从而提高基础架构的利用率。

基于扩缩容考虑而分割到多个pod

另一个不应该将应用程序都放到单一pod中的原因就是扩缩容。pod也是扩缩容的基本单位，对于Kubemetes来说，它不能横向扩缩单个容器，只能扩缩整个pod。这意味着如果你的pod由一个前端和一个后端容器组成，那么当你扩大pod的实例数量时，比如扩大为两个，最终会得到两个前端容器和两个后端容器。

通常来说，前端组件与后端组件具有完全不同的扩缩容需求，所以我们倾向于分别独立地扩缩它们。更不用说，像数据库这样的后端服务器，通常比无状态的前端web服务器更难扩展。因此，如果你需要单独扩缩容器，那么这个容器很明确地应该被部署在单独的pod中。

何时在pod中使用多个容器

将多个容器添加到单个pod的主要原因是应用可能由一个主进程和一个或多个 辅助进程组成，如图

例如，pod中的主容器可以是一个仅仅服务于某个目录中的文件的Web服务器，而另一个容器（所谓的sidecar容器）则定期从外部源-内容并将其存储在Web服务器目录中。也有需要使用Kubemetes Volume,并将其挂载到两个容器中。

sidecar容器的其他例子包括日志轮转器和收集器、数据处理器、通信适配器等。

决定何时pod 中使用多个容器

回顾一下容器应该如何分组到pod中：当决定是将两个容器放入一个pod还是两个单独的pod时，我们需要问自己以下问题：

它们需要一起运行还是可以在不同的主机上运行？它们代表的是一个整体还是相互独立的组件？它们必须一起进行扩缩容还是可以分别进行？

基本上，我们总是应该倾向于在单独 pod 中运行容器，除非有特定的原因要求它们是同一pod的一部分。图3.4将有助于我们记忆这一点。

尽管pod可以包含多个容器，但为了保持现在的简单性，这里仅讨论单容器pod有关的问题。其它文档讨论如何在一个pod中使用多个容器。

2.以YAML或jsON描述文件创建pod

pod和其他Kubernetes资源通常是通过向Kubernetes REST API提供JSON或YAML描述文件来创建的。此外还有其他更简单的创建资源的方法。使用的kubectl run命令，但这些方法通常只允许你配置一组有限的属性。另外， 通过YAML文件定义所有的Kubernetes对象之后，还可以将它们存储在版本控制系统中，充分利用版本控制所带来的便利性。

因此，为了配置每种类型资源的各种属性，我们需要了解并理解Kubernetes API对象定义。这里将会了解其中的大部分内容。需要注意的是，并不会解释每一个独立属性，且每个版本的api有些可能会不太相同。因此创建对象时还应参考 ​​检查现有pod的YAML描述文件

现在就来看看这些pod的YAML 文件是如何定义的。我们将使用带有yaml选项的kubectl get命令来获取 pod的整个YAML定义，正如下面的代码清单所示。

上述代码清单的内容看上去较为复杂，但一旦我们理解了基础知识并知道如何区分重要部分和细枝末节时，它就变得非常简单。此外，稍后我们将看到，当创建一个新的pod时，需要写的YAML相对来说则要短得多。

介绍pod定义的主要部分

pod定义由这么几个部分组成：首先是YAML中使用的Kubernetes API版本和YAML描述的资源类型;其次是几乎在所有Kubernetes资源中都可以找到的三大重要部分：

包括名称、命名空间、标签和关于该容器的其他信息。spec包含pod内容的实际说明，例如pod的容器、卷和其他数据。status包含运行中的pod的当前信息，例如pod所处的条件、每个容器的描述和状态，以及内部IP和其他基本信息。

上面的代码清单展示了一个正在运行的pod的完整描述，其中包含了它的状态。status部分包含只读的运行时数据，该数据展示了给定时刻的资源状态。而在创建新的pod时，永远不需要提供status部分。

上述三部分展示了Kubemetes API对象的典型结构。正如你看到的那样，其他对象也都具有相同的结构，这使得理解新对象相对来说更加容易。

对上述YAML中的每个属性进行深究的意义并不大，因此接下来我们将关注如何创建pod的最基本的YAML。

2.2 为pod创建一个简单 YAML描述文件

#代码3.2 一个基本的pod manifestapiVersion: v1 #描述文件遵循v1版本的Kubernetes APIkind: Pod #在描述一个podmetadata: name: kubia-manual #pod的名称spec: containers: - image: luksa/kubia #创建容器所用的镜像 name: kubia #容器的名称 ports: - containerPort: 8080 #应用监听端口

很明显，我们能够感受到该代码清单比代码清单3.1中的定义要简单得多。接下来我们就对整个描述文件进行深入探讨，该文件遵循Kubernetes API的v1版本。我们描述的资源类型是Pod，名称为kubia-manual;该pod由基于luksa/kubia 镜像的单个容器组成。此外我们还给该容器命名，并表示它正在监听8080端口。

指定容器端口

在pod 定义中指定端口纯粹是展示性的（informational)。忽略它们对于客户端是否可以通过端口连接到pod 不会带来任何影响。如果容器通过绑定到地址0.0.0.0的端口接收连接，那么即使端口未明确列出在pod spec中，其他pod也依旧能够连接该端口。但明确定义端口仍是有意义的，在端口定义下，每个使用集群的人都可以快速查看每个pod对外暴露的端口。此外，明确端口可以给端口指定名称，这样更加方便。

使用kubectl explain来发现可能的API对象字段在准备 manifest 时，可以转到 上的 Kubernetes参考文档查看每个API对象支持哪些属性，也可以使用kubectl explain命令。例如，当从头创建一个pod manifest时，可以从请 kubectl来解释pod 开始：

$ kubectl explain pods

DESCRIPTION:

Pod is a collection of containers that can run on a host. This resource

is created by clients and scheduled onto hosts.

FIELDS:

kind     

Kind is a string value representing the REST resource this object

represents...

metadata