【微服务】Kubernetes 对象之Pod（重点）

目录

Kubernetes Pod：

Pod：

Kubernetes中的Pod使用可分两种主要方式：

Pods：

Pods提供两种共享资源：网络和存储。

使用Pod：

Pod和Controller：

Pod模板：

Pod 安全策略：

Kubernetes Pod 生命周期：

容器探针：

Pod 和容器状态：

重启策略：

Pod 的生命：

状态示例：

Init 容器:

Pod操作：

 

Kubernetes Pod：

Pod：

Pod是Kubernetes创建或部署的最小/最简单的基本单位。
一个Pod代表集群上正在运行的一个进程。
一个Pod封装一个应用容器（也可以有多个容器），存储资源、一个独立的网络IP以及管理控制容器运行方式的策略选项。
Docker是Kubernetes Pod中最常见的runtime ，Pods也支持其他容器runtimes。
 

Kubernetes中的Pod使用可分两种主要方式：

Pod中运行一个容器。
“one-container-per-Pod”模式是Kubernetes最常见的用法
Pods中运行多个需要一起工作的容器。
Pod可以封装紧密耦合的应用，它们需要由多个容器组成，它们之间能够共享资源，这些容器可以形成一个单一的内部service单位一个容器共享文件

每个Pod都是运行应用的单个实例，如果需要水平扩展应用，则应该使用多个Pods。


 

Pods：

Pods的设计可用于支持多进程的协同工作，形成一个cohesive的Service单位。
Pod中的容器在集群中Node上被自动分配，容器之间可以共享资源、网络和相互依赖关系，并同时被调度使用。
在单个Pod中共同管理多个容器是一个相对高级的用法，应该只有在容器紧密耦合的特殊实例中使用此模式。
 

Pods提供两种共享资源：网络和存储。

网络：

• 每个Pod被分配一个独立的IP地址，Pod中的每个容器共享网络命名空间，包括IP地址和网络端口。
• Pod内的容器可以使用localhost相互通信。
• 当Pod中的容器与Pod 外部通信时，他们必须协调如何使用共享网络资源（如端口）。

存储：

• Pod可以指定一组共享存储volumes。
• Pod中的所有容器都可以访问共享volumes，允许这些容器共享数据。
• volumes 还用于Pod中的数据持久化，以防其中一个容器需要重新启动而丢失数据。
   

使用Pod：

很少会直接在kubernetes中创建单个Pod。
当Pod被创建后，都会被Kuberentes调度到集群的Node上。
直到Pod的进程终止、被删掉、因为缺少资源而被驱逐、或者Node故障之前这个Pod都会一直保持在那个Node上。
重启Pod中的容器跟重启Pod不是一回事。Pod只提供容器的运行环境并保持容器的运行状态，重启容器不会造成Pod重启。
Pod不会自愈。如果Pod运行的Node故障，或者是调度器本身故障，这个Pod就会被删除。
Pod所在Node缺少资源或者Pod处于维护状态，Pod也会被驱逐。
Kubernetes使用更高级的称为Controller的抽象层，来管理Pod实例。
Kubernetes中通常是使用Controller来管理Pod的。
 

Pod和Controller：

Controller可以创建和管理多个Pod，提供副本管理、滚动升级和集群级别的自愈能力。
如果一个Node故障，Controller就能自动将该节点上的Pod调度到其他健康的Node上。
 

Pod模板：

Pod模板是包含了其他对象中的pod定义 。
Controllers控制器使用Pod模板来创建实际需要的pod。


 

Pod 安全策略：

Pod 安全策略 是集群级别的资源，它能够控制 Pod 运行的行为，以及它具有访问什么的能力。
PodSecurityPolicy对象定义了一组条件，指示 Pod 必须按系统所能接受的顺序运行。
控制面 字段名称
已授权容器的运行 privileged
为容器添加默认的一组能力 defaultAddCapabilities
为容器去掉某些能力 requiredDropCapabilities
容器能够请求添加某些能力 allowedCapabilities
控制卷类型的使用 volumes
主机网络的使用 hostNetwork
主机端口的使用 hostPorts
主机 PID namespace 的使用 hostPID
主机 IPC namespace 的使用 hostIPC
主机路径的使用 allowedHostPaths
容器的 SELinux 上下文 seLinux
用户 ID runAsUser
配置允许的补充组 supplementalGroups
分配拥有 Pod 数据卷的 FSGroup fsGroup
必须使用一个只读的 root 文件系统 readOnlyRootFilesystem


Pod 安全策略 由设置和策略组成，它们能够控制 Pod 访问的安全特征。
设置分为如下三类：
基于布尔值控制：这种类型的字段默认为最严格限制的值。
基于被允许的值集合控制：这种类型的字段会与这组值进行对比，以确认值被允许。
基于策略控制：设置项通过一种策略提供的机制来生成该值，这种机制能够确保指定的值落在被允许的这组值中。
 

Kubernetes Pod 生命周期：

Pod phase：
Pod 的 status 定义在 PodStatus 对象中，其中有一个 phase 字段。
Pod 的相位（phase）是 Pod 在其生命周期中的简单宏观概述。
Pod 相位的数量和含义是严格指定的。
下面是 phase 可能的值：

• 挂起（Pending）： Pod 已被 Kubernetes 系统接受，但有一个或者多个容器镜像尚未创建。等待时间包括调度 Pod 的时间和通过网络下载镜像的时间，这可能需要花点时间。
• 运行中（Running）： 该 Pod 已经绑定到了一个节点上，Pod 中所有的容器都已被创建。至少有一个容器正在运行，或者正处于启动或重启状态。
• 成功（Succeeded）： Pod 中的所有容器都被成功终止，并且不会再重启。
• 失败（Failed）： Pod 中的所有容器都已终止了，并且至少有一个容器是因为失败终止。也就是说，容器以非0状态退出或者被系统终止。
• 未知（Unknown）： 因为某些原因无法取得 Pod 的状态，通常是因为与 Pod 所在主机通信失败。

Pod 状态：

• Pod 有一个 PodStatus 对象，其中包含一个 PodCondition 数组。
• PodCondition 数组的每个元素都有一个 type 字段和一个 status 字段。
• type 字段是字符串，可能的值有 PodScheduled、Ready、Initialized 和 Unschedulable。
• status 字段是一个字符串，可能的值有 True、False 和 Unknown。

 

容器探针：

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

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

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

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

 

Kubelet 可以选择是否执行在容器上运行的两种探针执行和做出反应：

• livenessProbe：指示容器是否正在运行。如果存活探测失败，则 kubelet 会杀死容器，并且容器将受到其 重启策略 的影响。如果容器不提供存活探针，则默认状态为 Success。
• readinessProbe：指示容器是否准备好服务请求。如果就绪探测失败，端点控制器将从与 Pod 匹配的所有 Service 的端点中删除该 Pod 的 IP 地址。初始延迟之前的就绪状态默认为 Failure。如果容器不提供就绪探针，则默认状态为 Success。

该什么时候使用存活（liveness）和就绪（readiness）探针?

• 如果容器中的进程能够在遇到问题或不健康的情况下自行崩溃，则不一定需要存活探针; kubelet 将根据 Pod 的restartPolicy 自动执行正确的操作。
• 如果您希望容器在探测失败时被杀死并重新启动，那么请指定一个存活探针，并指定restartPolicy 为 Always 或 OnFailure。
• 如果要仅在探测成功时才开始向 Pod 发送流量，请指定就绪探针。
• 如果您希望容器能够自行维护，您可以指定一个就绪探针，该探针检查与存活探针不同的端点。

 

Pod 和容器状态：

报告的 Pod 状态信息取决于当前的 ContainerState。
 

重启策略：

PodSpec 中有一个 restartPolicy 字段，可能的值为 Always、OnFailure 和 Never。
默认为 Always。 
restartPolicy 适用于 Pod 中的所有容器。
restartPolicy 仅指通过同一节点上的 kubelet 重新启动容器。
 

Pod 的生命：

一般来说，Pod 不会消失，直到人为销毁他们。
唯一例外是成功或失败的 phase 超过一段时间的Pod将过期并被自动销毁。
有三种可用的控制器：

1. 使用 Job 运行预期会终止的 Pod，例如批量计算。Job 仅适用于重启策略为 OnFailure 或 Never 的 Pod。
2. 对预期不会终止的 Pod 使用 ReplicationController、ReplicaSet 和 Deployment ，例如 Web 服务器。 ReplicationController 仅适用于具有 restartPolicy 为 Always 的 Pod。
3. 提供特定于机器的系统服务，使用 DaemonSet 为每台机器运行一个 Pod 。

所有这三种类型的控制器都包含一个 PodTemplate。
建议创建适当的控制器，让它们来创建 Pod，而不是直接自己创建 Pod。
这是因为单独的 Pod 在机器故障的情况下没有办法自动复原，而控制器却可以。
 

状态示例：

Pod 中只有一个容器并且正在运行。容器成功退出。
记录完成事件。
如果 restartPolicy 为：

• Always：重启容器；Pod phase 仍为 Running。
• OnFailure：Pod phase 变成 Succeeded。
• Never：Pod phase 变成 Succeeded。

Pod 中只有一个容器并且正在运行。容器退出失败。
记录失败事件。
如果 restartPolicy 为：

• Always：重启容器；Pod phase 仍为 Running。
• OnFailure：重启容器；Pod phase 仍为 Running。
• Never：Pod phase 变成 Failed。

Pod 中有两个容器并且正在运行。有一个容器退出失败。
记录失败事件。
如果 restartPolicy 为：

• Always：重启容器；Pod phase 仍为 Running。
• OnFailure：重启容器；Pod phase 仍为 Running。
• Never：不重启容器；Pod phase 仍为 Running。

 

如果有一个容器没有处于运行状态，并且两个容器退出：
记录失败事件。
如果 restartPolicy 为：

• Always：重启容器；Pod phase 仍为 Running。
• OnFailure：重启容器；Pod phase 仍为 Running。
• Never：Pod phase 变成 Failed。

Pod 中只有一个容器并处于运行状态。容器运行时内存超出限制：
容器以失败状态终止。
记录 OOM 事件。
如果 restartPolicy 为：

• Always：重启容器；Pod phase 仍为 Running。
• OnFailure：重启容器；Pod phase 仍为 Running。
• Never: 记录失败事件；Pod phase 仍为 Failed。

Pod 正在运行，磁盘故障：

• 杀掉所有容器。
• 记录适当事件。
• Pod phase 变成 Failed。

如果使用控制器来运行，Pod 将在别处重建。


Pod 正在运行，其节点被分段。

• 节点控制器等待直到超时。
• 节点控制器将 Pod phase 设置为 Failed。

如果是用控制器来运行，Pod 将在别处重建。


 

Init 容器:

一种专用的容器，在应用程序容器启动之前运行，并包括一些应用镜像中不存在的实用工具和安装脚本。
Pod 能够具有多个容器，应用运行在容器里面，但是它也可能有一个或多个先于应用容器启动的 Init 容器。


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

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

如果 Pod 的 Init 容器失败，Kubernetes 会不断地重启该 Pod，直到 Init 容器成功为止。
指定容器为 Init 容器，在 PodSpec 中添加 initContainers 字段.
Init 容器的状态在 status.initContainerStatuses 字段中以容器状态数组的格式返回.
Init 容器支持应用容器的全部字段和特性，包括资源限制、数据卷和安全设置。
Init 容器不支持 Readiness Probe，因为它们必须在 Pod 就绪之前运行完成。
为一个 Pod 指定了多个 Init 容器，那些容器会按顺序一次运行一个。 
每个 Init 容器必须运行成功，下一个才能够运行。
当所有的 Init 容器运行完成时，Kubernetes 初始化 Pod 并像平常一样运行应用容器。
Init 容器具有与应用程序容器分离的单独镜像

优势：

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

 

Pod操作：

给容器和Pod分配内存资源
给容器和Pod分配CPU资源
给 Pod 配置服务质量等级

 

Pod 优先级和抢占

 

内容整理自Kubernetes中文社区：https://www.kubernetes.org.cn/