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

第 2 章 使用 pod

2.1. 使用 pod
复制链接

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

2.1.1. 了解 pod
复制链接

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

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

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

注意

如需了解每个 OpenShift Container Platform 节点主机的最大 pod 数，请参阅“集群限制”。

警告

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

2.1.2. pod 配置示例
复制链接

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

以下是来自 Rails 应用的容器集定义示例。它展示了 pod 的许多特性，其中大多数已在其他主题中阐述，因此这里仅简略提及：

Pod 对象定义（YAML）

kind: Pod
apiVersion: v1
metadata:
  name: example
  namespace: default
  selfLink: /api/v1/namespaces/default/pods/example
  uid: 5cc30063-0265780783bc
  resourceVersion: '165032'
  creationTimestamp: '2019-02-13T20:31:37Z'
  labels:
    app: hello-openshift
1 

  annotations:
    openshift.io/scc: anyuid
spec:
  restartPolicy: Always
2 

  serviceAccountName: default
  imagePullSecrets:
    - name: default-dockercfg-5zrhb
  priority: 0
  schedulerName: default-scheduler
  terminationGracePeriodSeconds: 30
  nodeName: ip-10-0-140-16.us-east-2.compute.internal
  securityContext:
3 

    seLinuxOptions:
      level: 's0:c11,c10'
  containers:
4 

    - resources: {}
      terminationMessagePath: /dev/termination-log
      name: hello-openshift
      securityContext:
        capabilities:
          drop:
            - MKNOD
        procMount: Default
      ports:
        - containerPort: 8080
          protocol: TCP
      imagePullPolicy: Always
      volumeMounts:
5 

        - name: default-token-wbqsl
          readOnly: true
          mountPath: /var/run/secrets/kubernetes.io/serviceaccount
6 

      terminationMessagePolicy: File
      image: registry.redhat.io/openshift4/ose-ogging-eventrouter:v4.3
7 

  serviceAccount: default
8 

  volumes:
9 

    - name: default-token-wbqsl
      secret:
        secretName: default-token-wbqsl
        defaultMode: 420
  dnsPolicy: ClusterFirst
status:
  phase: Pending
  conditions:
    - type: Initialized
      status: 'True'
      lastProbeTime: null
      lastTransitionTime: '2019-02-13T20:31:37Z'
    - type: Ready
      status: 'False'
      lastProbeTime: null
      lastTransitionTime: '2019-02-13T20:31:37Z'
      reason: ContainersNotReady
      message: 'containers with unready status: [hello-openshift]'
    - type: ContainersReady
      status: 'False'
      lastProbeTime: null
      lastTransitionTime: '2019-02-13T20:31:37Z'
      reason: ContainersNotReady
      message: 'containers with unready status: [hello-openshift]'
    - type: PodScheduled
      status: 'True'
      lastProbeTime: null
      lastTransitionTime: '2019-02-13T20:31:37Z'
  hostIP: 10.0.140.16
  startTime: '2019-02-13T20:31:37Z'
  containerStatuses:
    - name: hello-openshift
      state:
        waiting:
          reason: ContainerCreating
      lastState: {}
      ready: false
      restartCount: 0
      image: openshift/hello-openshift
      imageID: ''
  qosClass: BestEffort
Copy to Clipboard Toggle word wrap

1
pod 可以被“标上”一个或多个标签，然后使用这些标签在一个操作中选择和管理多组 pod。标签以键/值格式保存在 metadata 散列中。
2
pod 重启策略，可能的值有 Always、OnFailure 和 Never。默认值为 Always。
3
OpenShift Container Platform 为容器定义了一个安全上下文，指定是否允许其作为特权容器来运行，或者以所选用户身份运行，等等。默认上下文的限制性比较强，但管理员可以根据需要进行修改。
4
containers 指定包括一个或多个容器定义的数组。
5
容器指定在容器中挂载外部存储卷的位置。在本例中，有一个卷可用来存储对凭证的访问，该卷是根据 registry 对 OpenShift Container Platform API 发出请求所需的。
6
指定要为 pod 提供的卷。卷挂载在指定路径上。不要挂载到容器 root、/ 或主机和容器中相同的任何路径。如果容器有足够权限，可能会损坏您的主机系统（如主机的 /dev/pts 文件）。使用 /host 挂载主机是安全的。
7
pod 中的每个容器使用自己的容器镜像进行实例化。
8
pod 对 OpenShift Container Platform API 发出请求是一种比较常见的模式，利用一个 serviceAccount 字段指定 pod 在发出请求时使用哪个服务帐户用户来进行身份验证。这可以为自定义基础架构组件提供精细的访问控制。
9
pod 定义了可供其容器使用的存储卷。在本例中，它为包含默认服务帐户令牌的 secret 卷提供一个临时卷。

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

注意

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

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

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

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

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

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

  • 使用 CPU 节流强制实施 CPU 限制。当容器接近其 CPU 限制时，内核会限制对指定为容器限制的 CPU 的访问。因此，CPU 限制是内核强制执行的硬限制。OpenShift Container Platform 可以允许容器在一定的时间段内超过其 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 强制实施限制。

对于 Linux 工作负载，您可以指定巨页资源。巨页是一个特定于 Linux 的功能，节点内核会分配大于默认页面大小的内存块。例如，在默认页面大小为 4KiB 的系统上，您可以指定更高的限制。有关巨页的更多信息，请参阅 "巨页"。

返回顶部
Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

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

让开源更具包容性

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

關於紅帽

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

Theme

© 2025 Red Hat