第 2 章 使用 pod


2.1. 使用 pod

pod 是共同部署在同一主机上的一个或多个容器,也是可被定义、部署和管理的最小计算单元。

2.1.1. 了解 pod

对容器而言,Pod 大致相当于一个机器实例(物理或虚拟)。每个 pod 分配有自己的内部 IP 地址,因此拥有完整的端口空间,并且 pod 内的容器可以共享其本地存储和网络。

Pod 有生命周期,它们经过定义后,被分配到某一节点上运行,然后持续运行,直到容器退出或它们因为其他原因被删除为止。根据策略和退出代码,Pod 可在退出后删除,或被保留下来以启用对容器日志的访问。

OpenShift Dedicated 将 pod 视为不可变;在运行时无法更改 pod 定义。OpenShift Dedicated 通过终止现有的 pod,再利用修改后的配置和/或基础镜像重新创建 pod,从而实现更改。Pod 也被视为是可抛弃的,不会在重新创建时保持原来的状态。因此,pod 通常应通过更高级别的控制器来管理,而不直接由用户管理。

警告

不受复制控制器管理的裸机 pod 不能在节点中断时重新调度。

2.1.2. pod 配置示例

OpenShift Dedicated 利用 Kubernetes 的 pod 概念,它是共同部署在同一主机上的一个或多个容器,也是可被定义、部署和管理的最小计算单元。

以下是 pod 的示例定义。它展示了 pod 的许多特性,其中大多数已在其他主题中阐述,因此这里仅简略提及:

Pod 对象定义(YAML)

kind: Pod
apiVersion: v1
metadata:
  name: example
  labels:
    environment: production
    app: abc 
1

spec:
  restartPolicy: Always 
2

  securityContext: 
3

    runAsNonRoot: true
    seccompProfile:
      type: RuntimeDefault
  containers: 
4

    - name: abc
      args:
      - sleep
      - "1000000"
      volumeMounts: 
5

       - name: cache-volume
         mountPath: /cache 
6

      image: registry.access.redhat.com/ubi7/ubi-init:latest 
7

      securityContext:
        allowPrivilegeEscalation: false
        runAsNonRoot: true
        capabilities:
          drop: ["ALL"]
      resources:
        limits:
          memory: "100Mi"
          cpu: "1"
        requests:
          memory: "100Mi"
          cpu: "1"
  volumes: 
8

  - name: cache-volume
    emptyDir:
      sizeLimit: 500Mi
Copy to Clipboard Toggle word wrap

1
pod 可以被“标上”一个或多个标签,然后使用这些标签在一个操作中选择和管理多组 pod。标签以键/值格式保存在 metadata 散列中。
2
pod 重启策略,可能的值有 AlwaysOnFailureNever。默认值为 Always
3
OpenShift Dedicated 为容器定义了一个安全上下文,指定是否允许它们作为特权容器运行,以所选用户身份运行,等等。默认上下文的限制性比较强,但管理员可以根据需要进行修改。
4
containers 指定包括一个或多个容器定义的数组。
5
容器指定在容器中挂载外部存储卷的位置。
6
指定要为 pod 提供的卷。卷挂载在指定路径上。不要挂载到容器 root、/ 或主机和容器中相同的任何路径。如果容器有足够权限,可能会损坏您的主机系统(如主机的 /dev/pts 文件)。使用 /host 挂载主机是安全的。
7
pod 中的每个容器使用自己的容器镜像进行实例化。
8
pod 定义了可供其容器使用的存储卷。

如果将具有高文件数的持久性卷附加到 pod,则这些 pod 可能会失败,或者可能需要很长时间才能启动。如需更多信息,请参阅在 OpenShift 中使用具有高文件计数的持久性卷时,为什么 pod 无法启动或占用大量时间来实现"Ready"状态?

注意

此 pod 定义不包括 OpenShift Dedicated 在 pod 创建并开始其生命周期后自动填充的属性。Kubernetes pod 文档详细介绍了 pod 的功能和用途。

2.1.3. 了解资源请求和限值

您可以使用 pod 规格为 pod 指定 CPU 和内存请求和限值,如 "Example pod 配置" 或 pod 控制对象的规格所示。

CPU 和内存请求 指定 pod 需要运行的最小资源量,帮助 OpenShift Dedicated 在具有足够资源的节点上调度 pod。

CPU 和内存限值 定义 pod 可消耗的资源的最大数量,防止 pod 消耗过多的资源,并可能影响同一节点上的其他 pod。

使用以下原则处理 CPU 和内存请求和限值:

  • 使用 CPU 节流强制实施 CPU 限制。当容器接近其 CPU 限制时,内核会限制对指定为容器限制的 CPU 的访问。因此,CPU 限制是内核强制执行的硬限制。OpenShift Dedicated 可以允许容器延长时间超过其 CPU 限值。但是,容器运行时不会终止 pod 或容器过量 CPU 用量。

    CPU 限制和请求以 CPU 单位计算。一个 CPU 单元相当于 1 个物理 CPU 内核或 1 个虚拟内核,具体取决于节点是物理主机还是在物理机中运行的虚拟机。允许部分请求。例如,当您定义 CPU 请求为 0.5 的容器时,您将请求一半个 CPU 时间,而不是请求 1.0 CPU 的 CPU 时间。对于 CPU 单元,0.1 等同于 100m,它可以被读取 为一百个 millicpu一百 millicores。CPU 资源始终是绝对数量的资源,不是相对数量。

    注意

    默认情况下,可分配给 pod 的最小 CPU 量为 10 个 mCPU。您可以在 pod 规格中请求低于 10 mCPU 的资源限值。但是,pod 仍然会被分配 10 个 mCPU。

  • 内存限制由内核使用内存不足(OOM)终止来强制实施。当容器使用超过其内存限值时,内核可以终止该容器。但是,只有在内核检测到内存压力时,才会终止。因此,通过分配内存的容器可能不会立即终止。这意味着会重新强制实施内存限制。容器可以使用的内存超过其内存限值。如果存在,容器可能会被终止。

    您可以使用其中一个数量后缀将内存表示为普通整数或固定点号: EPTGMk。您还可以使用两类等效功能: EiPiTiGiMiKi

如果运行 pod 的节点有足够的可用资源,则容器可以使用比请求更多的 CPU 或内存资源。但是,容器不能超过对应的限制。例如,如果您将容器内存请求设置为 256 MiB,并且该容器位于调度到具有 8GiB 内存且没有其他 pod 的节点的 pod 中,则容器可以尝试使用超过请求的 256 MiB 的内存。

这个行为不适用于 CPU 和内存限值。这些限制由 kubelet 和容器运行时应用,并由内核实施。在 Linux 节点上,内核使用 cgroups 强制实施限制。

返回顶部
Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务,以及可以信赖的内容,帮助红帽用户创新并实现他们的目标。 了解我们当前的更新.

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情,请参阅红帽博客.

關於紅帽

我们提供强化的解决方案,使企业能够更轻松地跨平台和环境(从核心数据中心到网络边缘)工作。

Theme

© 2025 Red Hat