3.3. Pod 和服务
3.3.1. Pods
OpenShift Container Platform 利用 Kubernetes 的 pod 概念，它是共同部署在同一主机上的一个或多个容器，也是可被定义、部署和管理的最小计算单元。
对容器而言，Pod 大致相当于机器实例（物理或虚拟）。每个 pod 分配有自己的内部 IP 地址，因此拥有完整的端口空间，并且 pod 内的容器可以共享其本地存储和网络。
Pod 有生命周期，它们经过定义后，被分配到某一节点上运行，然后持续运行，直到容器退出或它们因为其他原因被删除为止。根据策略和退出代码，Pod 可在退出后删除，或被保留下来以启用对容器日志的访问。
OpenShift Container Platform 将 pod 基本上视为不可变；在运行期间无法更改 pod 定义。OpenShift Container Platform 通过终止现有的 pod，再利用修改后的配置和/或基础镜像重新创建 pod，从而实现更改。Pod 也被视为是可抛弃的，不会在重新创建时保持原来的状态。因此，pod 通常应由更高级别的 控制器 管理，而不是直接由用户管理。
有关每个 OpenShift Container Platform 节点主机的最大 pod 数量，请参阅集群 最大。
不受复制控制器管理的裸机 pod 不会在节点中断时重新调度。
以下是一个提供长时间运行的服务的 pod 示例定义，该服务实际上是 OpenShift Container Platform 基础架构的一部分，即集成的容器镜像 registry。它展示了 pod 的许多特性，其中大多数已在其他主题中阐述，因此这里仅简略提及：
Pod 对象定义 (YAML)
apiVersion: v1
kind: Pod
metadata:
annotations: { ... }
labels: 1
deployment: docker-registry-1
deploymentconfig: docker-registry
docker-registry: default
generateName: docker-registry-1- 2
spec:
containers: 3
- env: 4
- name: OPENSHIFT_CA_DATA
value: ...
- name: OPENSHIFT_CERT_DATA
value: ...
- name: OPENSHIFT_INSECURE
value: "false"
- name: OPENSHIFT_KEY_DATA
value: ...
- name: OPENSHIFT_MASTER
value: https://master.example.com:8443
image: openshift/origin-docker-registry:v0.6.2 5
imagePullPolicy: IfNotPresent
name: registry
ports: 6
- containerPort: 5000
protocol: TCP
resources: {}
securityContext: { ... } 7
volumeMounts: 8
- mountPath: /registry
name: registry-storage
- mountPath: /var/run/secrets/kubernetes.io/serviceaccount
name: default-token-br6yz
readOnly: true
dnsPolicy: ClusterFirst
imagePullSecrets:
- name: default-dockercfg-at06w
restartPolicy: Always 9
serviceAccount: default 10
volumes: 11
- emptyDir: {}
name: registry-storage
- name: default-token-br6yz
secret:
secretName: default-token-br6yz
- 1
- pod 可以被“标上(tag)”一个或多个标签（label），然后使用这些标签在一个操作中选择和管理多组 pod。标签以键/值格式保存在
metadata散列中。本例中的一个标签是 docker-registry=default。 - 2
- Pod 在其命名空间内需要具有唯一名称。一个 pod 定义可以使用
generateName属性指定名称的基础，并且会自动添加随机字符来生成唯一名称。 - 3
containers指定一组容器定义；本例中只有一个，与大多时候相同。- 4
- 可以指定环境变量以将必要的值传递给每个容器。
- 5
- pod 中的每个容器使用自己的Docker 格式的容器镜像进行安装。
- 6
- 容器可绑定至在 pod 的 IP 上提供的端口。
- 7
- OpenShift Container Platform 为容器定义了一个安全上下文，指定是否允许其作为特权容器来运行，或者以所选用户身份运行，等等。默认上下文的限制性比较强，但管理员可以根据需要进行修改。
- 8
- 容器指定在容器中挂载外部存储卷的位置。在本例中，一个卷用于存储 registry 的数据，另一个卷则提供凭证的访问途径，registry 需要这些凭证来向 OpenShift Container Platform API 发出请求。
- 9
- 10
- Pod 对 OpenShift Container Platform API 发出请求是一种比较常见的模式，它有一个
serviceAccount字段，用于指定 pod 在发出请求时使用哪个服务帐户用户进行身份验证。这可以为自定义基础架构组件提供精细的访问控制。 - 11
- pod 定义了可供其容器使用的存储卷。在本例中，它提供了一个用于存储 registry 的临时卷，以及一个包含服务帐户凭证的
secret卷。
此 pod 定义不包括 OpenShift Container Platform 在 pod 创建并开始其生命周期后自动填充的属性。Kubernetes pod 文档详细介绍了 pod 的功能和用途。
3.3.1.1. Pod 重启策略
Pod 重启策略决定了 OpenShift Container Platform 在该 pod 中的容器退出时如何响应。策略应用到该 Pod 中的所有容器。
可能的值有：
-
始终 - 在pod 重启前，按指数避退延时(10s，20s，40s)持续重启 pod 上成功退出的容器。默认值为Always。 -
OnFailure- 按规定的延时值（10s，20s，40s）不断尝试重启 pod 中失败的容器，上限为 5 分钟。 -
Never- 不尝试重启 pod 中已退出或失败的容器。Pod 立即失败并退出。
绑定到节点后，pod 永远不会绑定到另一个节点。这意味着，需要一个控制器才能使 pod 在节点失败后存活：
| 状况 | 控制器类型 | 重启策略 |
|---|---|---|
| 应该终止的 Pod（例如，批量计算） |
| |
| 不应该终止的 Pod（例如，Web 服务器） |
| |
| 需要在每台机器上运行一个的 Pod | Daemonset | 任意 |
如果 pod 上的容器失败，并且重启策略被设置为 OnFailure，则 pod 会保留在该节点上并重新启动容器。如果您不希望容器重启，请使用 Never 的重启策略。
如果整个 pod 失败，OpenShift Container Platform 会启动一个新 pod。开发人员需要解决应用程序可能会在新 pod 中重启的问题。特别是，应用程序需要处理由之前运行导致的临时文件、锁定、不完整的输出等。
Kubernetes 架构需要来自云提供商的可靠端点。当云提供商停机时，kubelet 会防止 OpenShift Container Platform 重启。
如果底层云提供商端点不可靠，请不要使用云提供商集成来安装集群。应像在非云环境中一样安装集群。不建议在已安装的集群中打开或关闭云提供商集成。
如需详细了解 OpenShift Container Platform 如何使用与失败容器相关的重启策略，请参阅 Kubernetes 文档中的示例状态。
