更新 更新 1.1. OPENSHIFT 更新简介 1.2. 集群更新如何工作 1.3. 了解更新频道和发行版本 1.4. 了解 OPENSHIFT CONTAINER PLATFORM 更新持续时间 第 第 2 章 章 准 准备 备更新集群 更新集群 2.1. 准备升级到 OPENSHIFT CONTAINER PLATFORM 4.14 2.2. 准备使用手动维护的凭证更新集群 2.3 Platform 集 群。以下列表提供有关更新可用性的常见问题： 每个更新 每个更新频 频道之 道之间 间有什么区 有什么区别 别？ ？ 一个新的发行版本最初添加到 candidate 频道中。 在成功测试后，candidate 频道的发行版本将提升到 fast 频道，则会发布勘误，并完全支持该发 行版本。 延迟后，fast 频道中的一个发行版本最终会提升到 stable 频道。这个延迟代表了 fast 可能存在的风险。 在这个延迟后，fast 频道中可用的发行版本始终在 stable 频道中可用。 如果一个更新被支持但不推荐使用意味着什么？ 如果一个更新被支持但不推荐使用意味着什么？ 红帽会持续评估来自多个源的数据，以确定从一个版本更新到另一个版本是否会导致问题。如果 确定了问题，用户可能不再建议更新路径。但是，即使不推荐更新路径，如果客户执行了更新， 仍然被支持。 红帽不会阻止用户升级

级，则可以持续改进应用程序，既不会造成停机，又能仍然 保持与当前版本的兼容性。 您还可以与现有版本一起部署和测试应用程序的新版本。在部署了当前版本的同时，还部署应用程序的新 第 第 1 章 章 OPENSHIFT CONTAINER PLATFORM 架 架构 构 3 您还可以与现有版本一起部署和测试应用程序的新版本。在部署了当前版本的同时，还部署应用程序的新 版本。容器通过测试后，只要部署更多新容器并删除旧容器便可。 Container Platform 中的主要组件源自 Red Hat Enterprise Linux 和 相关的红帽技术。OpenShift Container Platform 得益于红帽企业级优质软件的严格测试和认证 计划。 开源开发模型。开发以开放方式完成，源代码可从公共软件存储库中获得。这种开放协作促进了 快速创新和开发。 虽然 Kubernetes 擅长管理应用程序，但它并未指定或管理平台级要求或部署过程。强大而灵活的平台管 或裸机基础架构上进行受限网络安装，您的集群机器不需要直接访问互联网。 OpenShift Container Platform 4.x Tested Integrations 页面中提供了有关针对不同平台进行集成测试的详 细信息。 2.1.2. 安装过程 当安装 OpenShift Container Platform 集群时，从 Red Hat OpenShift Cluster Manager 站点上的相应的

PLATFORM CI/CD 概述 OpenShift Container Platform 是面向开发人员的企业就绪 Kubernetes 平台，使组织能够通过 DevOps 实践（如持续集成(CI)和持续交付(CD)）自动化应用程序交付流程。为了满足您的机构需求，OpenShift Container Platform 提供以下 CI/CD 解决方案： OpenShift 构建 OpenShift 发生命周期中一致地配置和部署基于 Kubernetes 的基础架构和应用程序。 如需更多信息，请参阅关于 Red Hat OpenShift GitOps 。 1.4. JENKINS Jenkins 自动化了构建、测试和部署应用和项目的过程。OpenShift 开发者工具提供 Jenkins 镜像，它直 接与 OpenShift Container Platform 集成。Jenkins 可通过使用 Samples ilder）。对于 docker 和 S2I 构建，生成的对象为可运行 的镜像。对于自定义构建，生成的对象是构建器镜像作者指定的任何事物。 此外，也可利用管道构建策略来实现复杂的工作流： 持续集成 持续部署 2.1.1.1. Docker 构 构建 建 OpenShift Container Platform 使用 Buildah 从 Dockerfile 构建容器镜像。有关使用 Dockerfile

章 触 触发 发和修改 和修改构 构建 建 8.1. 构建触发器 8.2. 构建 HOOK 第 第 9 章 章 执 执行高 行高级构 级构建 建 9.1. 设置构建资源 9.2. 设置最长持续时间 4 4 6 6 8 8 9 9 10 19 19 22 23 25 26 30 31 32 32 32 33 34 34 35 42 44 51 52 53 53 53 Docker 和 S2I 构建，生成的对象为可运行 的镜像。对于 Custom 构建，生成的对象是构建器镜像作者指定的任何事物。 此外，也可利用 Pipeline 构建策略来实现复杂的工作流： 持续集成 持续部署 1.1.1. Docker 构建 Docker 构建策略调用 docker build 命令，它需要一个含有 Dockerfile 的存储库并且其中包含所有必要的 工件，从而能生成可运行的镜像。 4. 再次运行 s2i build，以验证 save-artifacts 和 assemble 脚本的保存和 恢复工件功能（可选）。 5. 运行镜像，以验证测试应用程序是否正常工作。 注意 注意 建议将 test/run 脚本构建的测试应用程序放置到镜像存储库中 的 test/test-app 目录。如需更多信息，请参阅 S2I 文档。 脚本 脚本 描述 描述 5.2.5.2.1. S2I

如果您在应用程序的主要版本之间进行滚动升级，则可以持续改进应用程序，既不会造成停机，又能仍然 保持与当前版本的兼容性。 您还可以与现有版本一起部署和测试应用程序的新版本。容器通过测试后，只要部署更多新容器并删除旧 OpenShift Container Platform 4.7 架 架构 构 6 您还可以与现有版本一起部署和测试应用程序的新版本。容器通过测试后，只要部署更多新容器并删除旧 容器便可。 Platform 中的主要组件源自 Red Hat Enterprise Linux（RHEL） 和相关的红帽技术。OpenShift Container Platform 得益于红帽企业级优质软件 的严格测试和认证计划。 开源开发模型。开发以开放方式完成，源代码可从公共软件存储库中获得。这种开放协作促进了 快速创新和开发。 虽然 Kubernetes 擅长管理应用程序，但它并未指定或管理平台级要求或部署过程。强大而灵活的平台管 或裸机基础架构上进行受限网络安装，您的集群机器不需要直接访问互联网。 OpenShift Container Platform 4.x Tested Integrations 页面中提供了有关针对不同平台进行集成测试的详 细信息。 3.1.2. 安装过程 安装 OpenShift Container Platform 集群时，您可以从 OpenShift Cluster Manager 站点的适当 Infrastructure

无需争用 这些资产。 2.1.2.2. 部署和 部署和扩 扩展 展优势 优势 如果您在应用程序的主要版本之间进行滚动升级，则可以持续改进应用程序，既不会造成停机，又能仍然 保持与当前版本的兼容性。 您还可以与现有版本一起部署和测试应用程序的新版本。容器通过测试后，只要部署更多新容器并删除旧 容器便可。 由于应用程序的所有软件依赖项都在容器本身内解决，因此数据中心的每台主机上都能使用标准的操作系 Platform 中的主要组件源自 Red Hat Enterprise Linux（RHEL） 和相关的红帽技术。OpenShift Container Platform 得益于红帽企业级优质软件 的严格测试和认证计划。 开源开发模型。开发以开放方式完成，源代码可从公共软件存储库中获得。这种开放协作促进了 快速创新和开发。 虽然 Kubernetes 擅长管理应用程序，但它并未指定或管理平台级要求或部署过程。强大而灵活的平台管 或裸机基础架构上进行受限网络安装，您的集群机器不需 要直接访问互联网。 OpenShift Container Platform 4.x Tested Integrations 页面中提供了有关针对不同平台进行集成测试的详 细信息。 3.1.2. 安装过程 安装 OpenShift Container Platform 集群时，您可以从 OpenShift Cluster Manager 站点的适当 Infrastructure

InfiniBand 设备支持 1.2.8.4. 增加了置备网络的 DHCP 范围 1.2.8.5. Pod 网络连接检查 1.2.8.6. 辅助设备指标可与网络附加关联 1.2.8.7. CNF 测试可以在发现模式下运行 1.2.8.8. HAProxy 版本升级 1.2.8.9. Control over X-Forwarded header 1.2.8.10. 修改路由路径 1.2.8 或被管理员删除。 1.2.3.4. File Integrity Operator 现 现已正式 已正式发 发布 布 File Integrity Operator 现已可用，它是在集群节点上持续运行文件完整性的 OpenShift Container Platform Operator。它部署一个守护进程集，在每个节点上初始化并运行特权高级入侵检测环境 (AIDE) 容器，从而提供一个状态 如需更多信息，请参阅将二级接口指标与网络附加关联。 1.2.8.7. CNF 测试 测试可以在 可以在发现 发现模式下 模式下运 运行 行 这是一个可选模式，Cloud-native Network Function（CNF）测试会试图在集群上查找配置而不是应用新 的配置。CNF 测试镜像是 CNF conformance 测试套件的容器化版本。它旨在针对启用了 CNF 的 OpenShift Container

对象限制 象限制规 规划您的 划您的环 环境 境 8.1. OPENSHIFT CONTAINER PLATFORM 为主发行版本测试了集群最大值 8.2. 测试集群最大值的 OPENSHIFT CONTAINER PLATFORM 环境和配置 8.3. 如何根据经过测试的集群限制规划您的环境 8.4. 如何根据应用程序要求规划您的环境 第 第 9 章 章 优 优化存 化存储 储 9.1. 可用的持久性存储选项 为平台 平台验证执 验证执行延 行延迟测试 迟测试 15.1. 运行延迟测试的先决条件 15.2. 关于延迟测试的发现模式 15.3. 测量延迟 15.4. 运行延迟测试 15.5. 生成延迟测试失败报告 15.6. 生成 JUNIT 延迟测试报告 15.7. 在单节点 OPENSHIFT 集群上运行延迟测试 15.8. 在断开连接的集群中运行延迟测试 15.9. 对 CNF-TESTS 节点数量，而不影响在集群中运行的应 用程序。 1.4. CONTROL PLANE 节点大小 控制平面节点资源要求取决于集群中的节点和对象的数量和类型。以下控制平面节点大小是基于控制平面 密度测试的结果，或 Clusterdensity。此测试会在给定很多命名空间中创建以下对象： 1 个镜像流 1 个构建 5 个部署，其中 2 个 pod 副本处于睡眠 睡眠状态，每个状态都挂载 4 个 secret、4 个配置映射和

级，则可以持续改进应用程序，既不会造成停机，又能仍然 保持与当前版本的兼容性。 您还可以与现有版本一起部署和测试应用程序的新版本。在部署了当前版本的同时，还部署应用程序的新 第 第 1 章 章 OPENSHIFT CONTAINER PLATFORM 架 架构 构 3 您还可以与现有版本一起部署和测试应用程序的新版本。在部署了当前版本的同时，还部署应用程序的新 版本。容器通过测试后，只要部署更多新容器并删除旧容器便可。 Container Platform 中的主要组件源自 Red Hat Enterprise Linux 和 相关的红帽技术。OpenShift Container Platform 得益于红帽企业级优质软件的严格测试和认证 计划。 开源开发模型。开发以开放方式完成，源代码可从公共软件存储库中获得。这种开放协作促进了 快速创新和开发。 虽然 Kubernetes 擅长管理应用程序，但它并未指定或管理平台级要求或部署过程。强大而灵活的平台管 或裸机基础架构上进行受限网络安装，您的集群机器不需要直接访问互联网。 OpenShift Container Platform 4.x Tested Integrations 页面中提供了有关针对不同平台进行集成测试的详 细信息。 2.1.2. 安装过程 当安装 OpenShift Container Platform 集群时，从 Red Hat OpenShift Cluster Manager 站点上的相应的

2. 创建 daemonset 4.2. 使用任务在 POD 中运行任务 4.2.1. 了解作业和 cron 作业 4.2.1.1. 了解如何创建作业 4.2.1.2. 了解如何为作业设置最长持续时间 4.2.1.3. 了解如何为 pod 失败设置作业避退策略 4.2.1.4. 了解如何配置 Cron Job 以移除工件 4.2.1.5. 已知限制 4.2.2. 创建作业 4.2.3. 大致相当于一个机器实例（物理或虚拟）。每个 pod 分配有自己的内部 IP 地址，因此 拥有完整的端口空间，并且 pod 内的容器可以共享其本地存储和网络。 Pod 有生命周期，它们经过定义后，被分配到某一节点上运行，然后持续运行，直到容器退出或它们因为 其他原因被删除为止。根据策略和退出代码，Pod 可在退出后删除，或被保留下来以启用对容器日志的访 问。 OpenShift Container Platform 将 pod 需要的。 如果有 80 个 pod 副本，在第一次迭代时 HPA 会将 pod 减少 8 个，即 80 个 pod 的 10%（根据 type: Percent 和 value: 10 参数），持续一分钟（periodSeconds: 60）。对于下一个迭代，pod 的数量为 72。HPA 计算剩余 pod 的 10% 为 7.2，这个数值被舍入到 8，这会缩减 8 个 pod。在每一后续迭代中，将