尽管容器镜像和从中运行的容器是现代应用程序开发的主要构建块，但要大规模运行它们，则需要可靠且灵活的分发系统。Kubernetes 是编配容器的事实标准。

Kubernetes 是一个开源容器编配引擎，用于自动化容器化应用程序的部署、扩展和管理。Kubernetes 的一般概念比较简单：

短短数年，Kubernetes 已在大量的云和本地环境中被采用。借助开源开发模型，拥护和可以通过为组件（如网络、存储和身份验证）实施不同的技术来扩展 Kubernetes 的功能。

与使用传统部署方法相比，使用容器化应用程序具有许多优势。过去应用程序要安装到包含所有依赖项的操作系统上，容器能让一个应用程序随身携带自己的依赖项。创建容器化应用程序有很多好处。

Red Hat OpenShift Service on AWS 为 Kubernetes 提供企业级的改进，包括以下改进：

虽然 Kubernetes 擅长管理应用程序，但它并未指定或管理平台级要求或部署过程。强大而灵活的平台管理工具和流程是 Red Hat OpenShift Service on AWS 4 具备的重要优势。以下小节描述了 Red Hat OpenShift Service on AWS 的一些独特功能和优势。

使用 HCP 的 ROSA，您可以在公共或私有网络上创建集群。以下镜像描述了公共和专用网络的架构。

图 3.2. 在公共网络上部署带有 HCP 的 ROSA

图 3.3. 在私有网络上部署带有 HCP 的 ROSA

使用 ROSA Classic，您可以创建可通过公共或私有网络访问的集群。

您可以使用以下方法自定义 API 服务器端点和 Red Hat SRE 管理的访问模式：

下图描述了在公共和私有网络上部署的 ROSA Classic 集群架构。

图 3.4. 在公共和私有网络上部署的 ROSA Classic

ROSA Classic 集群包括部署 OpenShift 组件的基础架构节点，如入口控制器、镜像 registry 和监控。基础架构节点及其上部署的 OpenShift 组件由 ROSA Service SREs 管理。

ROSA Classic 提供了以下类型的集群：

创建 AWS PrivateLink 集群的 Red Hat 受管基础架构托管在专用子网上。红帽与用户提供的基础架构之间的连接通过 AWS PrivateLink VPC 端点创建。

下图显示了 PrivateLink 集群的网络连接。

图 3.5. 在私有子网中部署的 Multi-AZ AWS PrivateLink 集群

ROSA 支持使用 AWS Local Zones，这些区域可以满足ropolis-centralized availability 区域，客户可在 VPC 中放置对延迟敏感的应用程序工作负载。本地区是 AWS 区域的扩展，默认情况下不启用。启用并配置 Local Zones 时，流量将扩展到 Local Zones，以获得更大的灵活性和较低延迟。如需更多信息，请参阅"在本地区中配置机器池"。

下图显示了没有路由到 Local Zone 的 ROSA 集群。

图 3.6. 没有流量路由到本地区域的 ROSA 集群

下图显示了将流量路由到 Local Zone 的 ROSA 集群。

图 3.7. 将流量路由到本地区域的 ROSA 集群

在 Kubernetes 集群中，worker 节点运行和管理 Kubernetes 用户请求的实际工作负载。worker 节点公告其容量，以及 control plane 服务调度程序，决定在哪些节点上启动 pod 和容器。以下重要服务在每个 worker 节点上运行：

在 Red Hat OpenShift Service on AWS 中，计算机器集控制分配了 worker 机器的计算机器。具有 worker 角色的机器驱动计算工作负载，这些工作负载由自动扩展它们的特定机器池管理。因为 Red Hat OpenShift Service on AWS 有支持多个机器类型的能力，所以具有 worker 角色的机器被归类为 计算机器。在本发行版本中，worker 机器和 计算机器是可以被互换使用的术语，因为计算机器的唯一默认类型是 worker 机器。在以后的 Red Hat OpenShift Service on AWS 版本中，默认可能会使用不同类型的计算机器，如基础架构机器。

在 Kubernetes 集群中，master 节点运行控制 Kubernetes 集群所需的服务。在 Red Hat OpenShift Service on AWS 中，control plane 由具有 master 机器角色的 control plane 机器组成。它们不仅仅包含用于管理 Red Hat OpenShift Service on AWS 集群的 Kubernetes 服务。

对于大多数 Red Hat OpenShift Service on AWS 集群，control plane 机器由一系列独立的机器 API 资源定义。control plane 使用 control plane 机器集管理。额外的控件应用到 control plane 机器，以防止您删除所有 control plane 机器并破坏集群。

control plane 上属于 Kubernetes 类别的服务包括 Kubernetes API 服务器、etcd、Kubernetes 控制器管理器和 Kubernetes 调度程序。

另外，在 control plane 上运行的 OpenShift 服务包括 OpenShift API 服务器、OpenShift 控制器管理器、OpenShift OAuth API 服务器和 OpenShift OAuth 服务器。

control plane 机器上的某些服务作为 systemd 服务运行，另一些则作为静态 pod 运行。

systemd 服务适合需要始终在特定系统启动后不久出现的服务。对于 control plane 机器，这包括允许远程登录的 sshd。它还包括以下服务：

CRI-O 和 Kubelet 必须作为 systemd 服务直接在主机上运行，因为它们必须先运行，然后您才能运行其他容器。

installer-* 和 revision-pruner-* control plane pod 必须使用 root 权限运行，因为它们需要写入属于 root 用户的 /etc/kubernetes 目录。这些 pod 位于以下命名空间中：

Operator Lifecycle Manager (OLM)和 OperatorHub 是 Red Hat OpenShift Service on AWS 中的默认组件，可帮助将 Kubernetes 原生应用程序作为 Operator 管理。它们一起提供用于发现、安装和管理集群中可用的可选附加组件 Operator 的系统。

在 Red Hat OpenShift Service on AWS Web 控制台中使用 OperatorHub，具有 dedicated-admin 角色和授权用户可以选择要从 Operator 目录安装的 Operator。在从 OperatorHub 安装 Operator 后，可以以全局的方式或针对特定命名空间，在用户应用程序中运行。

提供默认目录源，其中包括 Red Hat Operator、经过认证的 Operator 和社区 Operator。具有 dedicated-admin 角色的管理员也可以添加自己的自定义目录源，这些源可以包含一组自定义 Operator。

开发人员可以使用 Operator SDK 来帮助编写利用 OLM 功能的自定义 Operator。然后，可以将它们的 Operator 捆绑并添加到自定义目录源中，该源可以添加到集群中，并可供用户使用。

通过使用 etcd，您可以以多种方式获益：

为确保集群配置和管理的可靠方法，etcd 使用 etcd Operator。Operator 简化了在 Red Hat OpenShift Service on AWS 等 Kubernetes 容器平台上使用 etcd。使用 etcd Operator，您可以创建和删除 etcd 成员、重新定义集群大小、执行备份和升级 etcd。

etcd Operator 会观察、分析和操作：

etcd 会维持集群状态，它会持续更新。这个状态会被持续保留，这会导致高频率的、大量的小更改。因此，Red Hat Site Reliability Engineering (SRE)使用快速、低延迟 I/O 支持 etcd 集群成员。

Compute Unified Device Architecture (CUDA) 是由 NVIDIA 开发的并行计算平台和编程模型，用于 GPU 上的常规计算。

流是 GPU 上问题顺序执行的操作序列。CUDA 命令通常在默认流中按顺序执行，任务在前面的任务完成后才会启动。

跨不同流的异步处理操作允许并行执行任务。在一个流中发布的任务之前、期间或另一个任务签发到另一个流后运行。这允许 GPU 以任何规定的顺序同时运行多个任务，从而提高性能。

当您运行多个 CUDA 应用程序时，在超载 GPU 上调度 GPU 时间的交集工作负载。

您可以通过为 GPU 定义一组副本来启用 Kubernetes 上的 GPU 的时间，每个副本都可以独立分发到 pod 来运行工作负载。与多实例 GPU (MIG) 不同，在副本之间不存在内存或故障隔离，但对于某些工作负载，这优于根本不进行共享。在内部，GPU 时间分片用于从同一底层 GPU 将多个工作负载分配到不同的副本。

对于时间分片，您可以应用一个集群范围的默认配置。您还可以应用特定于节点的配置。例如，您只能将时间分片配置应用到具有 Tesla T4 GPU 的节点，而不能将节点改为使用其他 GPU 模型。

您可以通过应用集群范围的默认配置来组合这两种方法，然后标记节点以授予这些节点接收特定于节点的配置。

CUDA 多进程服务 (MPS) 允许单个 GPU 使用多个 CUDA 进程。进程在 GPU 上并行运行，消除了 GPU 计算资源的饱和。MPS 还支持并发执行或重叠内核操作和从不同进程复制的内存，以增强利用率。

使用多实例 GPU (MIG)，您可以将 GPU 计算单元和内存分成多个 MIG 实例。每个实例都代表了从系统的角度来看的独立 GPU 设备，并可连接到节点上运行的任何应用程序、容器或虚拟机。使用 GPU 的软件将每个 MIG 实例视为单独的 GPU。

当您有一个不需要整个 GPU 完全功能的应用程序时，MIG 很有用。新的 NVIDIA Ampere 架构的 MIG 功能允许您将硬件资源分成多个 GPU 实例，每个实例都可作为独立的 CUDA GPU 提供给操作系统。

NVIDIA GPU Operator 版本 1.7.0 及更高版本为 A100 和 A30 Ampere 卡提供 MIG 支持。这些 GPU 实例旨在支持最多 7 个独立的 CUDA 应用程序，以便它们与专用硬件资源完全隔离。

虚拟机 (VM) 可以使用 NVIDIA vGPU 直接访问单个物理 GPU。您可以创建虚拟 GPU，供虚拟机在企业之间共享，并由其他设备访问。

此功能将 GPU 性能与 vGPU 提供的管理和安全优势相结合。vGPU 提供的其他好处包括虚拟机环境的主动管理和监控、混合 VDI 和计算工作负载的工作负载平衡以及多个虚拟机之间的资源共享。

使用 buildah、podman 和 skopeo 构建和管理容器会导致行业标准容器镜像，其中包含专门在 Red Hat OpenShift Service on AWS 或其他 Kubernetes 环境中部署容器的功能。这些工具是无守护进程的，可在没有 root 权限的情况下运行，运行它们所需的开销更少。

最终在 Red Hat OpenShift Service on AWS 上运行容器时，您可以使用 CRI-O 容器引擎。CRI-O 在 Red Hat OpenShift Service on AWS 集群中的每一 worker 和 control plane 机器上运行，但 CRI-O 尚不支持作为 Red Hat OpenShift Service on AWS 以外的独立运行时。

选择用来构建应用程序的基础镜像包含一组软件，这些软件为应用程序提供一个 Linux 系统。在您构建自己的镜像时，您的软件将放置到该文件系统中，可以像对待操作系统一样看待该文件系统。基础镜像的选择会对容器未来的安全性、效率和可升级性产生重大影响。

红帽提供了一组新的基础镜像，称为红帽通用基础镜像 (UBI)。这些镜像基于 Red Hat Enterprise Linux，与红帽过去提供的基础镜像相似，但有一个主要区别：无需红帽订阅就能自由重新分发。因此，您可以在 UBI 镜像上构建应用程序，不必担心如何共享它们或需要为不同的环境创建不同的镜像。

这些 UBI 镜像具有标准、初始和最低版本。您还可以将 Red Hat Software Collections 镜像用作依赖特定运行时环境（如 Node.js、Perl 或 Python）的应用程序的基础。其中一些运行时基础镜像的特殊版本称为 Source-to-Image (S2I) 镜像。使用 S2I 镜像时，您可以将代码插入到可随时运行该代码的基础镜像环境中。

S2I 镜像可用于直接从 Red Hat OpenShift Service on AWS Web UI 中使用。在 Developer 视角中，进入到 +Add 视图，并在 Developer Catalog 标题中查看 Developer Catalog 中的所有可用服务。

图 6.2. 为需要特定运行时的应用选择 S2I 基础镜像

容器镜像仓库（registry）是存储容器镜像的位置，以便您可以与他人共享，并将它们提供给最终运行的平台。您可以选择提供免费帐户的大型公共容器 registry，也可选择提供更多存储和特殊功能的高级版本。您还可以安装自己的 registry，供您的组织专用或有选择地共享给他人。

要获取红帽和认证合作伙伴提供的镜像，您可以从 Red Hat Registry 中提取。Red Hat Registry 存在于两个位置：registry.access.redhat.com（无需身份验证，但已弃用）和 registry.redhat.io（需要身份验证）。您可以在红帽生态系统目录的容器镜像部分了解 Red Hat Registry 中的红帽及合作伙伴的镜像。除了列出红帽容器镜像外，它还显示有关这些镜像的内容和质量的广泛信息，包括基于已应用安全更新的健康分数。

大型公共 registry 包括 Docker Hub 和 Quay.io。Quay.io registry由红帽所有和管理。Red Hat OpenShift Service on AWS 中使用的许多组件都存储在 Quay.io 中，包括容器镜像和用于在 AWS 本身上部署 Red Hat OpenShift Service 的 Operator。Quay.io 还提供了存储其他类型内容的方法，包括 Helm Charts。

如果您希望自己的私有容器 registry，Red Hat OpenShift Service on AWS 本身包括一个私有容器 registry，随 Red Hat OpenShift Service on AWS 一起安装，并在其集群上运行。红帽也提供 Quay.io registry 的私有版本，称为 Red Hat Quay。Red Hat Quay 包括跨地域复制、Git 构建触发器、Clair 镜像扫描和许多其他功能。

此处提到的所有 registry 都可能需要凭证才能从中下载镜像。其中一些凭证会根据 AWS 上的 Red Hat OpenShift Service，而其他凭证可以分配给个人。

容器镜像是 docker 的基本单元，而 Kubernetes 使用的基本单元称为 pods。Pod 代表构建应用程序的下一步。pod 可以包含一个或多个容器。关键之处在于 pod 是您部署、扩展和管理的单个单元。

在决定 pod 中要放入的内容时，可扩展性和命名空间或许是要考虑的主要项目。为便于部署，您可能需要将容器部署到 pod 中，并在 pod 中包含其本身的日志记录和监控容器。以后，在您运行 pod 并需要扩展额外的实例时，其他那些容器也会随之扩展。对于命名空间，pod 中的容器共享相同的网络接口、共享存储卷和资源限制（如内存和 CPU）。这样一来，将 pod 内容作为一个单元进行管理变得更加轻松。pod 中的容器还可以使用标准的进程间通信（如 System V 信号或 POSIX 共享内存）相互通信。

虽然单个 pod 代表 Kubernetes 中的一个可扩展单元，但服务提供了一个途径，能够将一系列 pod 分组到一起以创造完整且稳定的应用程序，完成诸如负载均衡之类的任务。 服务也比 pod 更持久，因为服务可以一直从同一 IP 地址使用，直到您删除为止。使用该服务时，按名称请求该服务，Red Hat OpenShift Service on AWS 会将该名称解析为您可访问组成该服务的 pod 的 IP 地址和端口。

从本质上讲，容器化应用程序与运行它们的操作系统是隔开的，进而与其用户隔开。Kubernetes 清单的一部分描述了如何通过定义网络策略将应用程序公开给内部和外部网络，对您的容器化应用的通信进行精细的控制。要将来自集群外部的 HTTP、HTTPS 和其他服务的传入请求连接到集群内部的服务，可以使用 Ingress 资源。

如果容器需要磁盘存储而不是数据库存储（可以通过服务提供），则可以将卷添加到清单中，使该存储可供 pod 使用。您可以配置清单以创建持久性卷 (PV)，或动态创建添加到 Pod 定义中的卷。

在定义了组成应用程序的一组 pod 后，您可以在 Deployment 和 DeploymentConfig 对象中定义这些 pod。

接下来，考虑您的应用程序类型对其运行方式的影响。

Kubernetes 定义了适用于不同类型应用程序的不同工作负载。要确定适合应用程序的工作负载，请考虑该应用程序是否：

您编写的应用程序可能需要支持组件，如数据库或日志记录组件。为了满足这一需求，您可以从 Red Hat OpenShift Service on AWS Web 控制台中提供的以下目录获取所需的组件：

您可以根据开发团队的特定需求，配置支持的 Operator 和模板，然后在开发人员开展工作的命名空间中提供它们。 许多人将共享模板添加到 openshift 命名空间中，因为可以从所有其他命名空间访问这个命名空间。

借助 Kubernetes 清单（manifest），您可以更加全面地了解组成 Kubernetes 应用程序的组件。您可以将这些清单编写为 YAML 文件，并通过应用到集群来部署它们，例如通过运行 oc apply 命令。

此时，请考虑对容器开发过程进行自动化的方法。理想情况下，您可以使用某种 CI 管道来构建镜像并将其推送到 registry。特别是，GitOps 管道可将容器开发与 Git 存储库集成在一起，您将使用 Git 存储库来存储构建应用程序所需的软件。

到目前为止的工作流程可能如下所示：

变异（mutating）准入插件在准入过程的变异期间被调用，这允许在保留资源内容前修改资源内容。一个可通过变异准入插件调用的 webhook 示例是 Pod Node Selector 功能，它使用命名空间上的注解来查找标签选择器并将其添加到 pod 规格中。

apiVersion: admissionregistration.k8s.io/v1beta1
kind: MutatingWebhookConfiguration 1
metadata:
  name: <webhook_name> 2
webhooks:
- name: <webhook_name> 3
  clientConfig: 4
    service:
      namespace: default 5
      name: kubernetes 6
      path: <webhook_url> 7
    caBundle: <ca_signing_certificate> 8
  rules: 9
  - operations: 10
    - <operation>
    apiGroups:
    - ""
    apiVersions:
    - "*"
    resources:
    - <resource>
  failurePolicy: <policy> 11
  sideEffects: None

在准入过程的验证阶段会调用验证准入插件。在此阶段，可以在特定的 API 资源强制不能改变，以确保资源不会再次更改。Pod Node Selector 也是一个 webhook 示例，它由验证准入插件调用，以确保所有 nodeSelector 字段均受命名空间的节点选择器限制。

apiVersion: admissionregistration.k8s.io/v1beta1
kind: ValidatingWebhookConfiguration 1
metadata:
  name: <webhook_name> 2
webhooks:
- name: <webhook_name> 3
  clientConfig: 4
    service:
      namespace: default  5
      name: kubernetes 6
      path: <webhook_url> 7
    caBundle: <ca_signing_certificate> 8
  rules: 9
  - operations: 10
    - <operation>
    apiGroups:
    - ""
    apiVersions:
    - "*"
    resources:
    - <resource>
  failurePolicy: <policy> 11
  sideEffects: Unknown