4.3. 为 OpenShift Container Platform 创建 Kubernetes 清单

尽管容器镜像是容器化应用程序的基本构建块，但需要更多信息才能在 Kubernetes 环境（如 OpenShift Container Platform）中管理和部署该应用程序。创建镜像后的典型后续步骤：

  • 了解 Kubernetes 清单中使用的不同资源
  • 就您将运行的应用程序做出一些决策
  • 收集支持组件
  • 创建清单并将该清单存储到 Git 存储库中，以便您可以将其存储在源版本控制系统中，对其进行审核、跟踪和升级，并将其部署到下一环境中，在必要时回滚到旧版本，以及与他人共享

4.3.1. 关于 Kubernetes Pod 和服务

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

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

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

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

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

在确定了组成应用程序的一组 Pod 后，您可以在 deployments 和 deploymentconfigs 中定义这些 Pod。

4.3.2. 应用程序类型

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

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

  • 运行结束后即告完成。 例如，启动某个应用程序以生成报告，并在报告完成时退出。之后一个月内可能不会再次运行这个应用程序。对于这些类型的应用程序，合适的 OpenShift Container Platform 对象包括 Job 和 CronJob 对象。
  • 预计将持续运行。 对于长期运行的应用程序，您可以编写 Deployment 或 DeploymentConfig。
  • 需要高度可用。 如果应用程序需要高可用性，那么您需要调整部署的大小，使其包含不止一个实例。Deployment 或 DeploymentConfig 可以融合适于该类应用程序的 ReplicaSet。借助 ReplicaSet，Pod 可以跨越多个节点运行，确保即使在 worker 中断时该应用程序也始终可用。
  • 需要在每个节点上运行。 某些类型的 Kubernetes 应用程序设计为在集群中的每个 master 节点或 worker 节点上运行。例如，DNS 和监控应用程序需要在每个节点上持续运行。您可以将这类应用程序作为 DaemonSet 运行。您还可以基于节点标签（label），在节点的一个子集上运行 DaemonSet。
  • 需要生命周期管理。 当您要移交应用程序供其他人使用时，请考虑创建 Operator。Operator 可帮助您构建智能功能，自动处理备份和升级之类的事务。与 Operator Lifecycle Manager (OLM) 相结合，集群管理器可以将 Operator 公开给选定命名空间，以便集群中的用户可以运行它们。
  • 具有标识或编号要求。应用程序可能具有标识或编号要求。 例如，您可能需要运行应用程序的三个实例，并将这些实例命名为 0、1 和 2。StatefulSet 适合此应用程序。 StatefulSet 对于需要独立存储的应用程序最有用处，如数据库和 zookeeper 集群。

4.3.3. 可用的支持组件

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

  • OperatorHub，可在每个 OpenShift Container Platform 4.2 集群中使用。借助 OperatorHub，集群操作员可以使用来自红帽、红帽认证合作伙伴和社区成员的 Operator。集群操作员可以在集群中的所有命名空间或选定命名空间中提供这些 Operator，让开发人员能够通过他们的应用程序启动并配置这些 Operator。
  • 服务目录，提供 Operator 的替代方案。尽管部署 Operator 是在 OpenShift Container Platform 中获取打包应用程序的首选方法，但出于某些原因，您可能想要使用服务目录来获取自己应用程序的支持应用程序。如果您是现有的 OpenShift Container Platform 3 客户并且已投入于服务目录应用程序，或者您已拥有 Cloud Foundry 环境，并且您有兴趣使用来自其他生态系统的代理，则可能要使用服务目录。
  • 模板，对于一次性类型的应用程序很有用。在该应用程序中，组件的生命周期在安装后并不重要。模板提供了一种简便方式，可以从最小的开销开始开发 Kubernetes 应用程序。模板可以是资源定义的列表，这包括部署、服务、路由或其他对象。如果要更改名称或资源，可通过参数形式在模板中设置这些值。Template Service Broker Operator 是一个服务代理，可供您用于实例化自己的模板。您也可以直接从命令行安装模板。

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

4.3.4. 应用清单

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

4.3.5. 后续步骤

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

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

  • 第 1 天：编写一些 YAML。然后，运行 oc apply 命令将 YAML 应用于集群并测试其是否正常工作。
  • 第 2 天：将 YAML 容器配置文件放进您的 Git 存储库中。想要安装该应用或协助您改进的人可以从那里拉取 YAML，并应用到他们用于运行应用程序的集群中。
  • 第 3 天：考虑为应用程序编写 Operator。