kubernetes---pod

一、Pod

在Kubernetes中，最小的管理元素不是一个个独立的容器，而是Pod,Pod是最小的，管理，创建，计划的最小单元.

1.1、什么是pod?

一个Pod（就像一群鲸鱼，或者一个豌豆夹）相当于一个共享context的配置组，在同一个context下，应用可能还会有独立的cgroup隔离机制，一个Pod是一个容器环境下的“逻辑主机”，它可能包含一个或者多个紧密相连的应用，这些应用可能是在同一个物理主机或虚拟机上。

同一个Pod中的应用可以共享磁盘，磁盘是Pod级的，应用可以通过文件系统调用，额外的，一个Pod可能会定义顶级的cgroup隔离，这样的话绑定到任何一个应用（好吧，这句是在没怎么看懂，就是说Pod，应用，隔离）

和相互独立的容器一样，Pod是一种相对短暂的存在，而不是持久存在的，正如我们在Pod的生命周期中提到的，Pod被安排到结点上，并且保持在这个节点上直到被终止（根据重启的设定）或者被删除，当一个节点死掉之后，上面的所有Pod均会被删除。特殊的Pod永远不会被转移到的其他的节点，作为替代，他们必须被replace.

1.1.1 pod的管理

Pod通过提供一个高层次抽象而不是底层的接口简化了应用的部署及管理，Pod 作为最小的部署及管理单位，位置管理，拷贝复制，资源共享，依赖关系都是自动处理的。（fate sharing估计就说什么时候该死了，什么时候该新增一个了…）

1.2、pod的生命周期

1.2.1、Init 容器

Pod 能够具有多个容器，应用运行在容器里面，但是它也可能有一个或多个先于应用容器启动的 Init
容器

Init 容器与普通的容器非常像，除了如下两点：

Ø Init 容器总是运行到成功完成为止
Ø 每个 Init 容器都必须在下一个 Init 容器启动之前成功完成

特点:

如果 Pod 的 Init 容器失败，Kubernetes 会不断地重启该 Pod，直到 Init 容器成功为止。然而，
如果 Pod 对应的 restartPolicy 为 Never，它不会重新启动

1.2.2、Init 容器的作用

因为 Init 容器具有与应用程序容器分离的单独镜像，所以它们的启动相关代码具有如下优势：

Ø 它们可以包含并运行实用工具，但是出于安全考虑，是不建议在应用程序容器镜像中包含这
些实用工具的
Ø 它们可以包含使用工具和定制化代码来安装，但是不能出现在应用程序镜像中。例如，创建
镜像没必要 FROM 另一个镜像，只需要在安装过程中使用类似 sed、 awk、 python 或 dig
这样的工具。
Ø 应用程序镜像可以分离出创建和部署的角色，而没有必要联合它们构建一个单独的镜像。
Ø Init 容器使用 Linux Namespace，所以相对应用程序容器来说具有不同的文件系统视图。因
此，它们能够具有访问 Secret 的权限，而应用程序容器则不能。
Ø 它们必须在应用程序容器启动之前运行完成，而应用程序容器是并行运行的，所以 Init 容
器能够提供了一种简单的阻塞或延迟应用容器的启动的方法，直到满足了一组先决条件。

特殊说明

Ø 在 Pod 启动过程中，Init 容器会按顺序在网络和数据卷初始化之后启动。每个容器必须在下一个
容器启动之前成功退出
Ø 如果由于运行时或失败退出，将导致容器启动失败，它会根据 Pod 的 restartPolicy 指定的策略
进行重试。然而，如果 Pod 的 restartPolicy 设置为 Always，Init 容器失败时会使用
RestartPolicy 策略
Ø 在所有的 Init 容器没有成功之前，Pod 将不会变成 Ready 状态。Init 容器的端口将不会在
Service 中进行聚集。 正在初始化中的 Pod 处于 Pending 状态，但应该会将 Initializing 状
态设置为 true
Ø 如果 Pod 重启，所有 Init 容器必须重新执行
Ø # 对 Init 容器 spec 的修改被限制在容器 image 字段，修改其他字段都不会生效。更改 Init
容器的 image 字段，等价于重启该 Pod
Ø Init 容器具有应用容器的所有字段。除了 readinessProbe，因为 Init 容器无法定义不同于完成
（completion）的就绪（readiness）之外的其他状态。这会在验证过程中强制执行
Ø 在 Pod 中的每个 app 和 Init 容器的名称必须唯一；与任何其它容器共享同一个名称，会在验证
时抛出错误

1.2.3、容器探针

• 探针是由 kubelet 对容器执行的定期诊断。要执行诊断，kubelet 调用由容器实现的 Handler。有三
  种类型的处理程序：

Ø ExecAction：在容器内执行指定命令。如果命令退出时返回码为 0 则认为诊断成功。
Ø TCPSocketAction：对指定端口上的容器的 IP 地址进行 TCP 检查。如果端口打开，则诊断
被认为是成功的。
Ø HTTPGetAction：对指定的端口和路径上的容器的 IP 地址执行 HTTP Get 请求。如果响应的
状态码大于等于200 且小于 400，则诊断被认为是成功的

• 每次探测都将获得以下三种结果之一：

Ø 成功：容器通过了诊断。
Ø 失败：容器未通过诊断。
Ø 未知：诊断失败，因此不会采取任何行动

1.3、

1.4、

1.5、

---