总算写到k8s的重头戏pod，我打算用三篇文章来说明pod，首先讲下pod的基础原理，然后讲pod的生命周期，最后结合实际环境做下pod的演练，当然pod不只是知识，还有pod拓扑分布约束，干扰等等，但是我第一系列的文章，想让大家初步的了解k8s，能够初步的有维护k8s集群，在k8s集群上生成的能力，首选完成这个目标，后续的再继续扩展。好吧，那我们开始今天的文章，pod的基础原理。

一. 什么是pod

Pod 是可以在 Kubernetes 中创建和管理的、最小的可部署的计算单元。这个感念是k8s 的基础。它是是一组（一个或多个）容器，为这些容器共享存储、网络、运行方式提供声明。Pod 中的内容总是并置（colocated）的并且一同调度，在共享的上下文中运行。 Pod 所建模的是特定于应用的“逻辑主机”，其中包含一个或多个应用容器， 他们是相对紧密的耦合在一起的。 在非云环境中，在相同的物理机或虚拟机上运行的应用类似于 在同一逻辑主机上运行的云应用。除了应用容器，Pod 还可以包含在 Pod 启动期间运行的Init容器。

Pod 的共享上下文包括一组 Linux 名字空间、控制组（cgroup）和可能一些其他的隔离 方面，即用来隔离 Docker 容器的技术。 在 Pod 的上下文中，每个独立的应用可能会进一步实施隔离。就 Docker 概念的术语而言，Pod 类似于共享名字空间和文件系统卷的一组 Docker 容器。

二.使用 Pod

通常不需要直接创建 Pod，一般会使用诸如Deployment 或 Job 这类工作负载资源 来创建 Pod。因为 Pod 被设计成了相对临时性的、用后即抛的一次性实体。 当 Pod 由你或者间接地由控制器创建时，它被调度在集群中的节点上运行。 Pod 会保持在该节点上运行，直到 Pod 结束执行、Pod 对象被删除、Pod 因资源不足而被 驱逐 或者节点失效为止。如果 Pod 需要跟踪状态， 可以考虑 StatefulSet 资源。Kubernetes 集群中的 Pod 主要有两种用法：

• 运行单个容器的 Pod。"每个 Pod 一个容器"模型是最常见的 Kubernetes 用例； 在这种情况下，可以将 Pod 看作单个容器的包装器，并且 Kubernetes 直接管理 Pod，而不是容器。

• 运行多个协同工作的容器的 Pod。 Pod 可能封装由多个紧密耦合且需要共享资源的共处容器组成的应用程序。 这些位于同一位置的容器可能形成单个内聚的服务单元 —— 一个容器将文件从共享卷提供

每个 Pod 都旨在运行给定应用程序的单个实例。如果希望横向扩展应用程序（例如，运行多个实例 以提供更多的资源），则应该使用多个 Pod，每个实例使用一个 Pod。 在 Kubernetes 中，这通常被称为 副本（Replication）。 通常使用一种工作负载资源及其控制器来创建和管理一组 Pod 副本

1. Pod 怎样管理多个容器

Pod 被设计成支持形成内聚服务单元的多个协作过程（形式为容器）。 Pod 中的容器被自动安排到集群中的同一物理机或虚拟机上，并可以一起进行调度。 容器之间可以共享资源和依赖、彼此通信、协调何时以及何种方式终止自身。 Pod 具有Init容器和应用容器。 Init 容器会在启动应用容器之前运行并完成，并为成员容器提供了两种共享资源：网络和存储。

2. Pod 和控制器

可以使用工作负载资源来创建和管理多个 Pod。 资源的控制器能够处理副本的管理、上线，并在 Pod 失效时提供自愈能力。 例如，如果一个节点失败，控制器注意到该节点上的 Pod 已经停止工作， 就可以创建替换性的 Pod。调度器会将替身 Pod 调度到健康的节点执行

下面是管理一个或者多个 Pod 的工作负载资源的示例：

• Deployment
• StatefulSet
• DaemonSet

3. Pod 模版

负载资源的控制器通常使用 Pod 模板（Pod Template）来创建和管理Pod。Pod 模板是包含在工作负载对象中的规范，这类负载资源包括 Deployment、 Job 和 DaemonSets等。工作负载的控制器会使用负载对象中的 PodTemplate 来生成实际的 Pod。 PodTemplate 是用来运行应用时指定的负载资源的目标状态的一部分。厦门Wie具体实例，

apiVersion: batch/v1
kind: Job
metadata:
  name: hello
spec:
  template:
    # 这里是 Pod 模版
    spec:
      containers:
      - name: hello
        image: busybox
        command: ['sh', '-c', 'echo "Hello, Kubernetes!" && sleep 3600']
      restartPolicy: OnFailure
    # 以上为 Pod 模版

修改 Pod 模版或者切换到新的 Pod 模版都不会对已经存在的 Pod 起作用。 Pod 不会直接收到模版的更新。相反， 新的 Pod 会被创建出来，与更改后的 Pod 模版匹配。例如，Deployment 控制器针对每个 Deployment 对象确保运行中的 Pod 与当前的 Pod 模版匹配。如果模版被更新，则 Deployment 必须删除现有的 Pod，基于更新后的模版 创建新的 Pod。每个工作负载资源都实现了自己的规则，用来处理对 Pod 模版的更新。在节点上，kubelet并不直接监测 或管理与 Pod 模版相关的细节或模版的更新，这些细节都被抽象出来。 这种抽象和关注点分离简化了整个系统的语义，并且使得用户可以在不改变现有代码的 前提下就能扩展集群的行为

三.Pod 更新与替换

上章节已经提过当某工作负载的 Pod 模板被改变时，控制器会基于更新的模板 创建新的 Pod 对象而不是对现有 Pod 执行更新或者修补操作。Kubernetes 并不禁止直接管理 Pod。对运行中的 Pod 的某些字段执行就地更新操作 还是可能的。不过，类似patch 和 replace这类更新操作有一些限制：

• Pod 的绝大多数元数据都是不可变的。例如，不可以改变其 namespace、name、 uid 或者 creationTimestamp 字段；generation 字段是比较特别的，如果更新 该字段，只能增加字段取值而不能减少。

• 如果 metadata.deletionTimestamp 已经被设置，则不可以向 metadata.finalizers 列表中添加新的条目。

• Pod 更新不可以改变除 spec.containers[*].image、spec.initContainers[*].image、 spec.activeDeadlineSeconds 或 spec.tolerations 之外的字段。 对于 spec.tolerations，只被允许添加新的条目到其中。

• 在更新spec.activeDeadlineSeconds 字段时，以下两种更新操作是被允许的：

  1. 如果该字段尚未设置，可以将其设置为一个正数；
  2. 如果该字段已经设置为一个正数，可以将其设置为一个更小的、非负的整数

1. Pod 中的存储

Pod 可以设置一组共享的存储卷，所有容器都可以访问该共享卷，从而允许这些容器共享数据。 卷还允许 Pod 中的持久数据保留下来，即使其中的容器需要重新启动。 

2. Pod 联网

每个 Pod 都在每个地址族中获得唯一的 IP 地址。 Pod 中的每个容器共享网络名字空间，包括 IP 地址和网络端口。 Pod 内 的容器可以使用 localhost 互相通信， 当内部容器与外部实体通信时，它们必须协调如何使用共享的网络资源。在同一个 Pod 内，所有容器共享一个 IP 地址和端口空间，并且可以通过 localhost 发现对方。 他们也能通过如 SystemV 信号量或 POSIX 共享内存这类标准的进程间通信方式互相通信。 不同 Pod 中的容器的 IP 地址互不相同，没有特殊配置就不能使用 IPC 进行通信。 如果某容器希望与运行于其他 Pod 中的容器通信，可以通过 IP 联网的方式实现。

四. 容器的特权模式

Pod 中的任何容器都可以使用容器规约中安全上下文中的 privileged 参数启用特权模式。 这对于想要使用使用操作系统管理权能（Capabilities，如操纵网络堆栈和访问设备） 的容器很有用。 容器内的进程几乎可以获得与容器外的进程相同的特权。

五. 静态 Pod

静态 Pod（Static Pod）直接由特定节点上的 kubelet 守护进程管理， 不需要API看到它们。 尽管大多数 Pod 都是通过控制面（例如，Deployment） 来管理的，对于静态 Pod 而言，kubelet 直接监控每个 Pod，并在其失效时重启.静态 Pod 通常绑定到某个节点上的 kubelet。 其主要用途是运行自托管的控制面。 在自托管场景中，使用 kubelet 来管理各个独立的 控制面组件。kubelet 自动尝试为每个静态 Pod 在 Kubernetes API 服务器上创建一个 镜像 Pod。 这意味着在节点上运行的 Pod 在 API 服务器上是可见的，但不可以通过 API 服务器来控制。