Red Hat Summit 红帽全球峰会支持控制台（Console）开发人员开始试用联系人

第 2 章 使用 pod

2.1. 使用 pod
复制链接

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

2.1.1. 了解 pod
复制链接

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

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

Red Hat OpenShift Service on AWS 将 pod 视为不可变，在 pod 运行时无法对 pod 定义进行更改。Red Hat OpenShift Service on AWS 通过终止现有的 pod 并使用修改后的配置、基础镜像或两者重新创建它来实现更改。Pod 也被视为是可抛弃的，不会在重新创建时保持原来的状态。因此，pod 通常应通过更高级别的控制器来管理，而不直接由用户管理。

警告

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

2.1.2. pod 配置示例
复制链接

Red Hat OpenShift Service on AWS 利用 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 重启策略，可能的值有 Always、OnFailure 和 Never。默认值为 Always。
3
Red Hat OpenShift Service on AWS 为容器定义了一个安全上下文，指定是否允许其作为特权容器运行，以所选用户身份运行，等等。默认上下文的限制性比较强，但管理员可以根据需要进行修改。
4
containers 指定包括一个或多个容器定义的数组。
5
容器指定在容器中挂载外部存储卷的位置。
6
指定要为 pod 提供的卷。卷挂载在指定路径上。不要挂载到容器 root、/ 或主机和容器中相同的任何路径。如果容器有足够权限，可能会损坏您的主机系统（如主机的 /dev/pts 文件）。使用 /host 挂载主机是安全的。
7
pod 中的每个容器使用自己的容器镜像进行实例化。
8
pod 定义了可供其容器使用的存储卷。

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

注意

此 pod 定义不包括在 Pod 创建并开始生命周期后，Red Hat OpenShift Service on AWS 填充的属性。Kubernetes pod 文档详细介绍了 pod 的功能和用途。

2.1.3. 了解资源请求和限值
复制链接

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

CPU 和内存请求 指定 Pod 需要运行最少的资源，帮助 Red Hat OpenShift Service on AWS 在具有足够资源的节点上调度 pod。

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

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

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

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

    注意

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

  • 内存限制由内核通过 OOM（out of memory）kill 来强制实施。当容器使用超过其内存限值时，内核可以终止该容器。但是，只有在内核检测到内存压力时，才会终止。因此，过度分配内存的容器可能不会立即被终止。这意味着，内存限制被强制实现。容器可以使用比其内存限值更多的内存。如果存在，容器可能会被终止。

    您可以使用这些数量后缀之一将内存表示为普通整数或固定点号：E, P, T, G, M, 或 k。您还可以使用两的指数：Ei, Pi, Ti, Gi, Mi, 或 Ki。

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

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

返回顶部
Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

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

让开源更具包容性

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

關於紅帽

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

Theme

© 2025 Red Hat