Openshift-多集群管理秘籍-全-

Openshift 多集群管理秘籍（全）

原文：annas-archive.org/md5/34d330a854977743ac20d09dc6c9e828

译者：飞龙

协议：CC BY-NC-SA 4.0

前言

我们生活在一个变化巨大且快速的世界中。在 IT 行业，DevOps、云计算、数字化转型、容器和Kubernetes等技术在过去几年中相继出现，并且极大地改变了我们开发、构建、测试和部署应用程序的方式。

在这一系列新技术中，只有少数几项成为了行业的共识，包括云计算、容器和 Kubernetes。在过去的几年里，本书的作者与许多客户一起工作，这些客户正在进行云计算和容器的采用之旅——几乎所有客户都采用了某种 Kubernetes 发行版以及一个或多个云服务提供商。他们中的大多数都在体验这种采用带来的好处，但同时也面临着许多新挑战，例如维护标准环境、保持安全性和控制成本。

这也是我们决定将本书的重点不仅仅放在 OpenShift 上的原因，OpenShift 是企业 Kubernetes 市场的领导者之一，同时我们也关注多集群管理。本书是多年现场经验的结晶，涉及架构设计、OpenShift 集群的部署和运营，我们将这些经验转化为文字、页面和章节！

本书将解答一些问题，例如，使用 OpenShift 我有哪些不同的架构选择？我如何为我的情况设计合适的架构？与 OpenShift 相关的不同角色、他们的主要职责和面临的挑战是什么？ 我们还将讲解OpenShift 的部署、故障排除、网络和安全。CI/CD和GitOps也将在本书中通过一些实践案例进行讲解，帮助你了解它们如何帮助提高构建和部署过程的成熟度。最后，我们将介绍一些工具，如高级集群管理和高级集群安全，它们将帮助你从中央视角管理和保护多个 OpenShift 集群。

本书适用人群

本书旨在帮助所有与 Kubernetes 和 OpenShift 相关的专业人士。尤其适合软件工程师、基础设施运营人员、开发人员、站点可靠性工程师和安全工程师，但也应对企业架构师和 CXO 决策者具有一定的参考价值。你是否有兴趣了解更多关于 OpenShift 架构、部署、安全、GitOps、流水线、多集群管理和安全等内容？如果是这样，这本书是为你精心编写的！

本书内容

第一章，混合云之旅与策略，讨论了公共云采用的主要挑战，解释了什么是 OpenShift，以及它如何帮助应对这些挑战，从而在业务、文化和技术层面实现混合云的成功。

第二章，架构概述与定义，介绍了与 Kubernetes 和 OpenShift 架构相关的主要概念，帮助你决定最佳的路径。

第三章，多租户考虑事项，帮助你在 OpenShift 上处理多租户，为多个团队提供多个环境，并为每种情况提供适当的隔离。

第四章，OpenShift 用户角色与技能集，审视了在公司结构中可以做出的变化，帮助人们适应他们的角色和责任。

第五章，OpenShift 部署，是一个完整的动手指南，帮助你安装和使用 OpenShift。

第六章，OpenShift 故障排除、性能与最佳实践，展示了 OpenShift 使用中一些常见的问题。

第七章，OpenShift 网络，探讨了 OpenShift 的网络层，例如 Open vSwitch，以及南北向和东西向流量的概念，和 OpenShift 路由的不同 TLS 配置类型。

第八章，OpenShift 安全性，介绍了安全性的一些重要概念，例如容器安全性、身份验证与授权、身份提供者、基于角色的访问控制（RBAC）、证书、etcd 加密、容器与网络隔离、Red Hat 容器镜像目录以及漏洞保护等。

第九章，OpenShift Pipelines – Tekton，介绍了 OpenShift Pipelines，这是一个基于 Tekton 的 Kubernetes 原生 CI/CD 流水线工具。本章包含主要概念、安装过程，并通过实际操作实验室帮助你以实践方式学习。

第十章，OpenShift GitOps – ArgoCD，通过添加 GitOps 和 ArgoCD 扩展了部署能力。本章涵盖了 GitOps 概念、OpenShift GitOps 安装，以及一个动手实验室。

第十一章，OpenShift 多集群 GitOps 与管理，深入探讨了混合云/多云概念以及采用多个集群的主要问题。本章描述了什么是 Red Hat 高级集群管理、其安装过程，以及如何使用它从中央控制台管理多个 Kubernetes 集群。

第十二章，OpenShift 多集群安全性，扩展了 第八章，OpenShift 安全性 中的概念，重点关注多集群安全问题。本章介绍了 Red Hat 高级集群安全工具的功能，如风险管理、漏洞、违规、策略、合规性和配置管理，同时提供了安装、配置和使用说明。

第十三章，OpenShift Plus —— 一个多集群企业级解决方案，介绍了 Red Hat Quay 作为企业级镜像仓库选项，并讨论了 OpenShift Plus 作为一个适用于寻求在混合/多云环境中实现一致性和可移植性的企业的优秀选择的优势。

第十四章，在混合云环境中构建云原生用例，介绍了一个完整的实际示例。本章通过逐步动手指导，展示了如何使用本书中介绍的大部分功能（如 OpenShift 管道（Tekton）、OpenShift GitOps（ArgoCD）、高级集群管理、Quay 和高级集群安全）构建和部署应用程序。

第十五章，接下来做什么，提供了继续学习并通过培训和认证深入了解 OpenShift 的建议。

为了从本书中获得最大收益

在本书中，你将运行命令并使用命令行工具。我们建议你使用 Mac 或 Linux 工作站，例如 Fedora 或 Ubuntu——尽管一些 CLI 工具也有 Windows 版本，本书中使用的命令示例假设使用的是 Linux 工作站，Mac 也应该能够正常使用。

本书的某些部分需要一个 AWS 账户；不过，你应该可以轻松地将示例适应到其他云服务提供商。你可以在这里注册 AWS 的免费试用：aws.amazon.com/。

虽然我们尽力使本书尽可能具有教学性和包容性，但如果你已经具备基本的容器化和 Kubernetes 知识，你可能会从中获得更多——不过不需要高级知识。

下载彩色图像

我们还提供了一份包含本书中使用的截图/图表的彩色图像的 PDF 文件。你可以在这里下载：packt.link/C8KLC。

下载示例代码文件

你可以从 GitHub 下载本书的示例代码文件，网址为：github.com/PacktPublishing/OpenShift-Multi-Cluster-Management-Handbook。如果代码有更新，将会在现有的 GitHub 仓库中进行更新。

我们还提供了来自我们丰富书籍和视频目录的其他代码包，访问网址：github.com/PacktPublishing/。快来看看吧！

使用的约定

本书中使用了多种文本约定。

文本中的代码：表示文本中的代码词语、数据库表名、文件夹名、文件名、文件扩展名、路径名、虚拟网址、用户输入和 Twitter 用户名。例如：“在这一步，我们将使用quarkus-build管道，您可以在chapter14/Build/Pipeline/quarkus-build.yaml文件中找到它。”

代码块设置如下：

SELECT
     COUNT(DISTINCT Column1) AS Count_column1,
     System.TIMESTAMP() AS Time
FROM Input TIMESTAMP BY TIME
GROUP BY
     TumblingWindow(second, 2)

代码输出或命令行输入如下设置：

npm install applicationinsights

粗体：表示一个新术语、重要词语，或屏幕上出现的词语。例如，菜单或对话框中的词语通常以这种方式出现在文本中。举个例子：“在创建 AWS 凭证后，访问基础设施 | 集群功能并点击创建集群按钮。”

提示或重要说明。

如此显示。

与我们取得联系。

我们始终欢迎读者的反馈。

customercare@packtpub.com。

勘误表：虽然我们已经尽力确保内容的准确性，但难免会出现错误。如果您在本书中发现错误，请向我们报告。请访问 www.packtpub.com/support/errata，选择您的书籍，点击勘误表提交表单链接并输入详细信息。

copyright@packt.com，并附上材料链接。

如果您有兴趣成为作者：如果您在某个领域有专业知识，并且有兴趣撰写或参与书籍创作，请访问 authors.packtpub.com。

分享您的想法。

阅读完OpenShift 多集群管理手册后，我们很想听听您的想法！请点击这里直接访问亚马逊评论页面并分享您的反馈。

您的评价对我们和技术社区非常重要，它将帮助我们确保提供优质内容。

下载本书的免费 PDF 副本。

感谢购买本书！

您喜欢随时随地阅读，但无法携带纸质书籍吗？

您的电子书购买是否与您选择的设备不兼容？

别担心，现在每本 Packt 书籍，您都会免费获得该书的无 DRM 版 PDF。

可以在任何地方、任何设备上阅读。直接从您最喜欢的技术书籍中搜索、复制并粘贴代码到您的应用程序中。

特权不仅仅到此为止，您还可以每天在邮箱中获取独家折扣、时事通讯和极好的免费内容。

按照以下简单步骤获取福利：

扫描二维码或访问以下链接。

packt.link/free-ebook/9781803235288

提交您的购买证明。
就是这样！我们会直接把免费的 PDF 和其他福利发送到您的电子邮件。

第一部分 – 为 Red Hat OpenShift 设计架构。

本部分介绍了混合云之旅及其困境。深入了解在部署一个或多个 OpenShift 集群之前应该完成的最重要的架构概念和定义。

本书的这一部分包括以下章节：

第一章，混合云之旅与战略
第二章，架构概述与定义
第三章，多租户考虑因素
第四章，OpenShift 角色与技能

第一章：1

混合云之路与策略

你想在多个环境中学习和操作 OpenShift 吗？如果你正在阅读本书，我们假设你的答案是肯定的！但是，在深入技术细节之前，我们想先给你提个建议：任何房屋建设都从地基开始，对吧？在本书中，我们的方法也是如此。我们将从为你打下基础开始，帮助你理解并构建一个更强大的知识库——你将培养批判性思维，并能够为你的使用场景做出最佳决策。

这就是为什么我们决定从不直接讨论 OpenShift 本身开始，而是先揭示它所运作的最受欢迎（也是最重要！）的背景：混合云基础设施。因此，在本章中，你将被引导了解混合云的历程、挑战、困境，以及为什么许多组织在这方面遇到困难。从一开始就了解这些挑战是混合云采用的决定性成功因素。

如今，转型 IT 业务以实现敏捷、可扩展，同时保持稳定，已经成为必需，但这并非一件简单的事；相反，它是一个从一颗星到另一颗星的旅程，跨越我们目前所处的广袤 IT 宇宙。然而，为什么我们需要这些变化呢？为什么市场如此迅速地大规模采用云计算？我们将很快讨论这个问题！

这是一个 变化的世界！

我们正生活在一个变化迅速的时代！十年前，大多数现如今的大型科技公司还不存在，或者只是一些小型初创企业；许多今天存在的技术当时也只是大学研究小组中知道的领域，例如 3D 打印、人工智能和机器学习、5G、边缘计算等——而且未来还有更多技术会出现！像前面提到的这些技术正在变得越来越普及，并将催生许多今天尚不存在的需求、新的职位，以及更多的变化。

在这个快速变化的世界中，一些新的需求变得尤为重要。大多数公司被迫做出改变，以便比以往更快地发布新软件和新版本，迅速扩展资源，并拥有全球覆盖和响应迅速的应用程序。

正是在这个背景下，公共云服务提供商取得了巨大的成功。然而，许多在云计算上投入巨资的组织正在面临一些挑战。在 IDG 于 2020 年进行的一项研究中，来自不同产业和地区的大型公司中，40% 的受访者表示，控制云成本是充分利用云计算时面临的最大挑战。这项研究还显示，数据隐私和安全是主要障碍。在本章中，我们将讨论这些挑战的一些方面。

在本章中，我们将涵盖以下主题：

公共云的主要挑战
混合云策略如何帮助缓解这些挑战
容器、Kubernetes 和 OpenShift 如何帮助实现混合云
OpenShift 选项
OpenShift 安装类型
支持混合云采用的附加工具

公共云的主要挑战

从小型企业到大型科技公司，它们在使用公共云服务时，都面临一些共同的挑战。以下是一些主要挑战：

控制云成本：估算和管理在公共云服务商上运行的应用程序成本并非易事——云服务商的计费模式是多面的，有数百种不同的选项和组合，每个选项都有定价因素。找到一个应用程序的最佳成本效益可能需要相当长的时间。更复杂的是，云成本通常是动态和灵活的——根据类型、合同期限、计算资源类型等因素，这些成本可能会时常发生显著变化。
安全性：根据IDG的研究，数据隐私和安全性是公共云面临的主要问题之一——几乎 40%的人将其列为最大的挑战。也就是说，确保一个由多个不同供应商组成的 IT 环境比以前的时代要困难得多，那时 IT 部门通常只需要管理几个本地环境。
治理、合规性和配置管理：多个供应商意味着不同的产品和标准，可能有不同的团队在处理每个供应商的产品，因此会出现异构的环境。
集成：对于那些拥有遗留服务并希望与其托管在云中的应用程序集成的组织来说，通常会面临如何进行这些集成的最佳方式的困境。尽管云服务提供商几乎没有限制，但当你将应用程序集成到遗留基础设施时，可能会创建一个有害的依赖关系，这将限制其可扩展性。然而，主要对于大型企业来说，这些集成是不可避免的，那么我们如何防止依赖性问题（或至少将其最小化）呢？
供应商锁定：采用云服务商时，一个常见的担忧通常与被单一供应商锁定以及相关的业务风险有关。我会说，在从云服务商那里获得最优价格与被锁定在其服务之间，存在一条微妙的界限。如果云服务商决定在下一次合同谈判中提高价格，业务会面临什么样的影响？这是你的企业能够承担的风险吗？我们如何减轻这种风险？在这里，你得到的就是你支付的这个说法很合适！
人力资源和能力建设：在 IT 领域招聘和留住人才一直是一个难题；云技术也不例外。云工程师、架构师、SRE、云原生应用开发人员——这些职位每天都有空缺，而且大多数公司都在为填补这些职位而努力。招聘、培训和维护一支有技能的团队来开发和运营云中的应用程序是一项真正的挑战。

参考资料

你可以查看完整的IDG研究报告，地址是 www.idg.com/tools-for-marketers/2020-cloud-computing-study/ [访问日期：2021 年 8 月 30 日]。

公有云的好处

到目前为止，我们已经看到了一些复杂的挑战。所以，你可能会想，你不喜欢云服务提供商，想说服我避免使用 它们，对吧？

不，当然不是！我确信没有云服务提供商的出现，我们每天使用（并且喜爱！）的几家公司根本就不存在！那么让我们来看看其中的优点吧：

可扩展性：云服务提供商可以提供几乎无限且按需的计算资源。
更低的资本支出（CAPEX）：你无需购买任何硬件和设备就能开始操作——只需点击几下就可以完成。
弹性和全球覆盖：即使是小公司，也可以在不同的可用区和区域之间分发服务。
现代技术：公有云服务提供商总是在寻找新的现代化产品，这帮助企业始终处于技术的最前沿。

混合云是解决方案吗？

正如我们已经讨论过的，公有云虽然能解决一些挑战，但也带来了其他问题。在这种背景下，混合云应运而生：它旨在缓解一些挑战，并从每个提供商、从本地、私有或云服务提供商中取其精华。HashiCorp 云战略状态调查于 2021 年进行，涵盖了 3200 多名技术从业者，结果发现多云已经成为现实。76%的受访者表示他们正在使用多个云服务提供商，预计到 2023 年，这一比例将升至 86%。

参考资料

你可以查看完整的HashiCorp研究报告，地址是 www.hashicorp.com/state-of-the-cloud [访问日期：2021 年 8 月 31 日]。

那么，混合云有哪些特性能够帮助缓解公有云采用中的挑战呢？以下是其中的一些：

可以将不同供应商的顶级云服务进行结合，使公司能够为每个工作负载选择最佳的选项。
根据实际情况，在不同的公有云和私有云环境之间迁移工作负载的能力。
能够对所有提供商的所有环境进行单一、统一的编排和管理。

以下表格列出了部分挑战和混合云的缓解措施：

容器和 Kubernetes – 部分答案！

容器已成功成为推动应用程序与基础设施之间更好灵活性的最重要工具之一。容器可以将应用程序的依赖项封装在容器镜像中，从而帮助应用程序在不同环境之间轻松迁移。因此，容器是启用混合云的重要工具，尽管它们有其他许多应用。

下图展示了容器与传统虚拟机在这方面的不同：

Figure 1.1 – 容器提供灵活性

尽管容器有许多优点，但在没有编排层的情况下管理由数百个或数千个容器组成的大型环境几乎是不可能的。Kubernetes 成为常态，它是一个出色的编排工具。然而，它并不容易使用。根据 CNCF 2020 年调查，41% 的受访者认为复杂性是容器采用的最大障碍。当您决定选择原生 Kubernetes 实现时，以下内容（在大量选项中）需要由您来定义和管理：

安装和操作系统设置，包括配置管理
升级
安全访问和身份
监控和警报
存储和持久化
出口、入口和网络相关选项
镜像扫描和安全补丁
聚合日志工具

参考资料

您可以在这里查看完整的 CNCF 调查：www.cncf.io/blog/2020/11/17/cloud-native-survey-2020-containers-in-production-jump-300-from-our-first-survey/ [访问日期：2021 年 9 月 1 日]。

OpenShift - 一个完整的选项

OpenShift 是企业客户中最受欢迎的基于 Kubernetes 的平台之一。它于 2011 年首次发布，甚至在 Kubernetes 创建之前。可是，在 2015 年，随着 OpenShift 版本 3 的发布，Red Hat 决定将 Kubernetes 作为其容器编排层。从那时起，他们与 Kubernetes 社区积极合作——Red Hat 和 Google 是 Kubernetes 的主要贡献者。因此，OpenShift 成为基于 Kubernetes 构建的最成熟和完整的解决方案之一并不奇怪。

以下表格总结了 Red Hat OpenShift 容器平台 (OCP)（或易于插拔）随附的部分功能：

() 需要在* 第二天 安装

这些功能对任何拥有有效 Red Hat OpenShift 订阅的客户均可用。但是，如果您没有 Red Hat 订阅，仍有一些替代方案（用于学习目的）：

你可以使用红帽提供的一些试用选项——查看详情 www.redhat.com/en/technologies/cloud-computing/openshift/try-it。
使用 okd (okd.io/)，它是由红帽支持的 OpenShift 社区发行版。
在桌面上的虚拟机中使用 Red Hat CodeReady 容器（需要一个 Red Hat 门户的账户）。更多信息请访问 developers.redhat.com/products/codeready-containers/overview。

本书将详细展示这些出色的功能，并结合实际示例。

参考

关于 Kubernetes 项目贡献的最新统计数据，按公司分组，可以在 k8s.devstats.cncf.io/d/9/companies-table 找到。

OpenShift 产品 – 多种选择满足各种需求

OpenShift 的一个有趣特点是支持的广泛平台。使用 OpenShift 4.11 版本（本书撰写时的版本），你可以选择以下不同的组合：

图 1.2 – OpenShift 产品

本节中，我们将逐一介绍这些选项。

OpenShift 托管云服务

以前，当我们谈论使用某种技术时，我们也会考虑如何部署和管理它。如今，这种情况不再总是成立——几乎所有东西现在都可以以软件即服务（SaaS）的形式找到，你可以快速轻松地开始使用，而不必担心部署和管理。

对 OpenShift 同样适用：多个托管云服务使组织能够专注于应用程序的开发和业务，而红帽及云服务提供商则管理其余部分。

以下表格显示了本书写作时现有的托管产品（请查看红帽网站获取最新选项）：

重要提示

请注意，红帽管理的是完整技术栈，而不仅仅是 Kubernetes 控制平面。红帽为整个集群提供管理和版本维护，包括主节点、基础设施和工作节点，当然也不仅限于此：它还支持 CI/CD、日志记录、监控等。

市场上还有其他托管 Kubernetes 选项。虽然这本书的重点不在于此，但请记住，一些提供商并不管理和支持整个技术栈——例如，仅管理控制平面。在考虑 Kubernetes 托管解决方案时，请查看它是完全托管的还是仅管理部分技术栈。

托管还是自管理——哪个更好？

答案是：这取决于！你需要考虑几个因素，才能找出最适合你情况的方案，但一般来说，托管解决方案不是那些需要控制服务器和基础设施的组织的最佳选择。对于那些更专注于应用开发且不关心平台的组织，只要平台安全可靠，那么托管解决方案可能是一个不错的选择。

托管解决方案对于那些想要接触平台、评估它，并了解它是否符合需求的组织也可能有帮助，但这些组织可能还没有足够的技术人员来维护它。

本书的大部分内容是以自托管集群为基础写的。然而，除了专门讲解平台部署和故障排除的章节，其他内容基本适用于任何类型的 OpenShift 集群。

以下图示展示了一个工作流，旨在帮助你决定选择哪种策略：

图 1.3 – 托管或自托管决策工作流

OpenShift 安装方式

你可以使用以下三种安装方式，在任何支持的提供商环境中部署 OpenShift：

全栈自动化（安装程序提供的基础设施）：在此模式下，安装程序将自动启动所有所需的基础设施——安装程序将与底层虚拟化或云服务提供商进行集成，部署集群所需的所有机器。这是一个有主张的完全自动化解决方案，使部署过程变得更容易。
预先存在的基础设施（用户提供的基础设施）：在这种安装方式下，机器是通过遵循一些标准镜像和流程手动配置的，且配置在经过测试的虚拟化或云服务提供商之上。
供应商无关（也称为裸金属安装方式）：只要是 Red Hat Enterprise Linux (*) 支持的地方，OpenShift 都受支持，尽管这并不意味着安装程序和平台会在每种与 Red Hat Enterprise Linux 支持的基础设施层组合上进行测试（**）。在这种情况下，你可以使用供应商无关的安装方式，这是一种手动安装过程，安装程序和平台与虚拟化或云服务提供商之间没有集成。

(*) 你可以在access.redhat.com/certified-hypervisors找到支持的 Red Hat Enterprise Linux 虚拟化程序列表。

（**）请参阅此链接，了解与 OpenShift 集成的经过测试的供应商和集成列表：access.redhat.com/articles/4128421。

OpenShift 多集群工具 – 超越预期

在支持混合云或多云战略时，其他优秀工具提供统一的管理、安全和编排层，覆盖所有环境和所有提供商。我们将本书的最后部分留给这些工具的深入讲解，但你需要从一开始就接触它们，才能理解它们在混合云/多云中的作用。

Red Hat 高级集群管理 for Kubernetes – 统一管理

正如我们之前提到的，单一统一的管理层对于支持混合云/多云战略至关重要。Red Hat 高级集群管理使我们能够管理生命周期、使用策略确保合规性，并在多个 Kubernetes 集群上部署应用。以下是它的一些主要功能：

统一管理：在不同的云提供商之上创建、更新和删除 Kubernetes 集群。你还可以访问、查找并修改不同集群中的 Kubernetes 资源。
治理、风险和合规性：使用策略确保多个集群的合规性。快速查找策略违规并相应修复。
应用生命周期管理：一次性在多个集群中部署应用程序。通过将高级集群管理与 Red Hat Ansible 自动化平台集成，部署复杂应用，配置网络、负载均衡器和其他外部依赖。
多集群可观测性：通过现成的仪表盘和度量标准，从一个单一的视角检查多个集群的健康状态。

本书最后一部分我们将通过实际示例深入了解 Red Hat 高级集群管理。

Red Hat 高级集群安全 for Kubernetes – 在任何地方都能保障应用安全

对 Kubernetes 用户来说，安全性变得越来越重要。当你有多个分布在不同提供商之间的 Kubernetes 集群时，确保安全并及时了解当前的漏洞是一项真正的挑战。Red Hat 高级集群安全旨在帮助解决这一问题——通过它，你可以轻松地扫描容器镜像以查找已知漏洞，使用行业标准如 NIST、PCI 等审计工作负载和集群，分析网络流量，并相应地创建策略等多项强大功能。你可以将这些功能应用于多个不同的集群，帮助你确保所有环境的安全，无论它们位于何处。

本书最后一部分我们将通过实际示例深入了解 Red Hat 高级集群安全。

Red Hat Quay – 在中央仓库中存储和管理容器镜像

中央容器镜像仓库通常不是必需的工具。然而，在没有它的情况下，在多个集群上部署应用程序会使构建和部署工作变得有些挑战性。Red Hat Quay 是一个容器镜像仓库，它不仅提供了镜像仓库的常规功能（存储你的容器镜像），还提供镜像漏洞扫描、时间机器、复制、垃圾回收、自动构建、身份验证、授权等功能。

我们将在本书的最后部分学习如何使用 Red Hat Quay。

OpenShift Plus – 完整套餐

Red Hat OpenShift、Advanced Cluster Management、Advanced Cluster Security 和 Quay 是不同的产品。然而，通过 OpenShift Plus 套餐，你可以只需一份订阅即可拥有所有这些产品，如果你计划采用混合云或多云 Kubernetes 策略，这可能是最好的选择。

我们将在本书的最后部分通过实际示例更详细地介绍 OpenShift Plus。

摘要

本章我们探讨了公共云使用的主要挑战，以及混合云如何帮助缓解其中一些挑战。你现在理解了容器、Kubernetes 和 OpenShift 如何帮助你实施成功的混合云策略。最后，我们学习了不同类型的 OpenShift 产品和支持混合云采用的附加工具。

在下一章中，你将学习 OpenShift 集群的架构方面内容。

进一步阅读

如果你想了解本章中涵盖的概念，可以查看以下参考资料：

以下是本章中提到的与混合云和容器采用相关的公开研究和调查：
- IDG 2020 云计算研究报告: www.idg.com/tools-for-marketers/2020-cloud-computing-study/
- HashiCorp 云策略 调查报告: www.hashicorp.com/state-of-the-cloud
- 云原生调查 2020：容器在生产环境中的使用比我们的第一次 调查增加了 300% : www.cncf.io/blog/2020/11/17/cloud-native-survey-2020-containers-in-production-jump-300-from-our-first-survey/
Red Hat OpenShift 登陆 页面: www.redhat.com/en/technologies/cloud-computing/openshift
Red Hat 托管云服务登陆 页面: www.redhat.com/en/technologies/cloud-computing/openshift/managed-cloud-services
红帽高级集群安全性 Kubernetes 登录 页面: www.redhat.com/en/technologies/cloud-computing/openshift/advanced-cluster-security-kubernetes
红帽高级集群管理 Kubernetes 登录 页面: www.redhat.com/en/technologies/management/advanced-cluster-management
红帽 Quay 登录 页面: www.redhat.com/en/technologies/cloud-computing/quay
红帽 OpenShift Platform Plus 登录 页面: www.redhat.com/en/technologies/cloud-computing/openshift/platform-plus
OpenShift 容器平台 4.x 测试集成与支持性 矩阵: access.redhat.com/articles/4128421
OpenShift 容器平台安装概览（来自官方 文档）： docs.openshift.com/container-platform/latest/installing/index.html
不同平台的支持安装方法（来自官方 文档）： docs.openshift.com/container-platform/latest/installing/installing-preparing.html#supported-installation-methods-for-different-platforms
Kubernetes 统计 页面: k8s.devstats.cncf.io/

功能	OpenShift 容器平台 (OCP) 功能
内置 CI/CD 管道，应用控制台	OpenShift 管道()，OpenShift GitOps()，开发者控制台。
集成开发环境	OpenShift CodeReady 工作区(*) 和 IDE 扩展（VS Code 和 IntelliJ）。
无服务器中间件	OpenShift 无服务器(*)。
服务网格	OpenShift 服务网格(*)。
自动化容器构建	S2I，BuildConfig。
仪表盘	提供管理员和开发者仪表盘。

第二章：2

架构概述与定义

Kubernetes 是一项了不起的技术；然而，正如我们在上一章所看到的，它并不是一项简单的技术。我认为 Kubernetes 不仅仅是容器编排，除此之外，它还是一个具有标准接口的平台，用于将容器与更广泛的基础设施集成，包括存储、网络和虚拟化技术。因此，你必须考虑到 OpenShift 自管理集群中的所有先决条件和相关方面。

本章将介绍与 Kubernetes 和 OpenShift 架构相关的主要概念。这里的主要目的是让你 在行动之前思考 并做出重要决策，避免后续的返工。

本章将涵盖以下主要内容：

理解基础概念
OpenShift 架构概念与最佳实践
基础设施/云提供商
网络考虑事项
其他考虑事项
OpenShift 架构检查清单

开始吧！

技术要求

由于本章涉及的是 OpenShift 的架构部分，因此在本章中，你并不需要访问任何特定的硬件或软件，但这在后面的章节中会有所要求。不过，为了能够从本章获得最佳结果，建议你具备一定的 OpenShift 和 Kubernetes 基础知识。

先决条件

本章面向那些已经具备一定 Kubernetes 或 OpenShift 使用基础知识的 信息技术 (IT) 架构师。因此，本章不涉及诸如 Pod、Service 或 Persistent Volume 等基础概念的介绍。如果你还不了解这些基础概念，别担心！我们已经在本书最后一章准备了推荐的培训和参考资料。我们建议你在继续本章内容之前，先学习 Kubernetes 基础和 Kube by Example。

理解基础概念

让我们从理解 Kubernetes 和 OpenShift 组件与服务器的主要概念开始。首先，任何 OpenShift 集群都由两种类型的服务器组成：主节点和 工作节点。

主节点

该服务器包含 Kubernetes 集群的 控制平面。OpenShift 上的主服务器运行在 Red Hat Enterprise Linux CoreOS (RHCOS) 操作系统上，并由多个主要组件组成，例如以下内容：

kube-apiserver): 负责暴露所有的 Kubernetes API。所有在 Kubernetes 集群上执行的操作都是通过 API 调用进行的——无论是使用 命令行接口 (CLI) 还是 用户界面 (UI)，都会使用 API 调用。
etcd): 数据库存储所有集群数据。etcd 是一个高度可用的分布式键值数据库。有关 etcd 的详细信息，请参考其文档：etcd.io/docs/latest/。
kube-scheduler): kube-scheduler 负责为 Pod 分配一个节点来运行。它使用复杂的算法，考虑大量因素来决定哪个节点最适合承载 Pod，比如可用的计算资源与所需节点选择器、亲和性和反亲和性规则等。
kube-controller-manager): 控制器是一个无尽的循环，负责确保某个对象始终处于期望的状态。例如，可以将其比作智能家居自动化设备：控制器负责协调设备，确保环境始终处于预定的状态——例如，定期开关空调以保持温度尽可能接近期望值。Kubernetes 控制器具有相同的功能——它们负责监控对象并根据情况做出响应，以保持其处于预期状态。Kubernetes 集群中使用了许多控制器，如副本控制器、端点控制器、命名空间控制器和服务帐户控制器。有关控制器的更多信息，请查看此页面：kubernetes.io/docs/concepts/architecture/controller/

这些是运行在主节点上的 Kubernetes 控制平面组件；然而，OpenShift 还提供了一些额外的服务来扩展 Kubernetes 的功能，如下所述：

openshift-apiserver): 该服务负责验证和配置 OpenShift 独有资源的数据，如路由、模板和项目。
openshift-controler-manager): 该服务确保 OpenShift 独有资源达到预期状态。
openshift-oauth-apiserver): 负责验证并配置数据，用以认证用户、组和 OpenShift 的令牌。

下图展示了 Kubernetes 和 OpenShift 的主要控制平面组件：

图 2.1 – OpenShift 控制平面组件

这些组件可以在多个命名空间中找到，您可以在下表中看到：

什么是 Operators？

如果你从未听说过 Operators，你可能会想：Operators 究竟是什么？ Operators 其实就是一种标准方法，用于打包、部署和维护 Kubernetes 应用和对象。它们通过 自定义资源定义 (CRDs) 来扩展 Kubernetes API 功能，并且为应用的生命周期提供一些标准：部署、修补、保持期望状态，甚至自动化操作（如自动扩缩容、调优、故障检测等）。查看更多信息，请访问这个链接：kubernetes.io/docs/concepts/extend-kubernetes/operator/。

引导节点

引导节点是一个临时服务器——仅在集群部署期间使用——它负责将集群的组件注入到控制平面中。当引导过程成功完成时，安装程序会将其移除。由于它是一个只在部署过程中存在的临时服务器，通常不会被视为 OpenShift 架构的一部分。

工作节点

工作节点是承载工作负载的服务器。在 OpenShift 上，工作节点可以运行在 RHCOS 或 Red Hat 企业 Linux（RHEL）上。虽然 OpenShift 支持在 RHEL 上运行工作节点，但一般推荐使用 RHCOS，原因如下：

不可变：RHCOS 是一个精简的操作系统，旨在通过 OpenShift 容器平台远程管理。这增强了一致性，并使升级过程变得更加简单和安全，因为 OpenShift 始终能够了解并管理服务器的实际状态和期望状态。
rpm-ostree：RHCOS 使用 rpm-ostree 系统，它支持事务性升级并为基础设施增加一致性。有关更多信息，请查看此链接：coreos.github.io/rpm-ostree/。
podman 和 skopeo。在正常运行过程中，通常不鼓励直接访问和在工作节点上运行命令（因为它们由 OpenShift 平台本身管理）；然而，这些工具在故障排除时非常有用——正如我们将在本书的 第六章《OpenShift 故障排除、性能和最佳实践》中详细讨论的那样。
systemd，它确保了你使用标准 RHEL 操作系统时同样的安全性和质量。
使用 rpm-ostree 系统进行原子升级，使得升级和回滚（如有需要）变得更加安全和简便。

在下图中，您可以查看这些对象和概念在 OpenShift 工作节点中的使用方式：

图 2.2 – RHCOS 工作节点

工作节点类型

有一些常见类型的工作节点，最常见的包括以下几种：

应用程序工作节点：负责托管工作负载——即应用程序容器运行的地方。
基础设施工作节点：这种类型的服务器通常用于托管平台基础设施工具，如入口（路由器）、内部注册表、监控堆栈（Prometheus 和 Grafana），以及日志工具（Elasticsearch 和 Kibana）。
存储工作节点：容器存储解决方案，如Red Hat OpenShift 数据基础设施，通常需要一些专用的工作节点来托管其 Pods。在这种情况下，最佳实践是为它们使用专用的节点组。

在下一节中，我们将看到如何使用不同类型的工作节点来设计一个高度可用且有弹性的 OpenShift 集群。

高可用集群

OpenShift 集群对企业来说变得至关重要并不罕见——有时它们从小规模开始，但很快就变得庞大。因此，你在设计 OpenShift 集群架构时，应从第一天开始考虑非功能性需求（NFRs），如高可用性（HA）。一个高可用集群包含以下方面：

etcd 使用了一种名为Raft 协议的分布式共识算法，它要求至少有三个节点才能保持高可用性。本书的重点不在于解释 Raft 协议，但如果你想更好地理解它，可以参考以下链接：
- Raft 描述：raft.github.io/
- 说明示例：thesecretlivesofdata.com/raft/
基础设施工作节点：至少需要两个节点才能确保入口的高可用性。我们将在本章稍后讨论你应该考虑的其他基础设施组件，如监控和日志记录。
应用工作节点：至少需要两个节点才能被视为高可用；然而，你可以根据预期的工作负载需要，增加足够数量的节点。在本章中，我们将探讨一些容量规划指导，以帮助你确定所需的工作节点数量，如果你已经有了预估的容量需求。

以下图展示了高可用集群架构的样子：

图 2.3 – OpenShift 高可用集群

现在我们已经掌握了 Kubernetes 和 OpenShift 的基础概念，让我们进一步深入，了解 OpenShift 的架构及一些最佳实践。

OpenShift 架构概念和最佳实践

本节将讨论与 OpenShift 架构设计相关的主要概念以及一些你应考虑的最佳实践。一般来说，当我们为 OpenShift 集群设计架构时，以下表格中的方面需要相应地定义：

如何解决这些方面（如部署、配置等）的详细内容，将从第五章**, OpenShift 部署开始讨论。另一个关键点是，我们仍然专注于单一的 OpenShift 集群——这里的主要目标是帮助你定义一个最适合你情况的标准集群架构。在下一章中，我们将探讨在处理多个环境、集群和提供商时需要考虑的方面。

在接下来的章节中，我们将逐一介绍这些要点，重点讲解你需要涵盖的最重要项目。

安装模式

你在上一章中已经了解了 OpenShift 的三种安装模式，具体如下：

安装程序提供的 基础设施 (IPI)
用户提供的基础设施（UPI）
提供商无关（如果你还没看到，回顾一下上一章的OpenShift 安装模式部分）

在这里，我们将简要讨论你需要考虑的每个选项中的重要方面，以帮助你做出最佳决策。

IPI

这种模式是一种简化的、具有指导意见的方法，用于集群的配置，同时也是一种完全自动化的安装和升级方法。使用这种模型，你可以降低操作开销；然而，它的灵活性不如 UPI。

你可以在这里看到一个 IPI 的示例：

图 2.4 – IPI

图 2.4 显示了安装程序在集群部署过程中自动化的所有层级。

UPI

在这种模式下，你需要手动配置服务器——你也需要负责管理它们。因此，你在基础设施层面有更多的灵活性。在这种模式下，OpenShift 仍然与基础设施或云提供商有一定的集成，以提供平台的存储服务。

无关安装程序

这种模式与 UPI 类似；但是，OpenShift 与基础设施或云提供商之间没有集成。因此，在这种模式下，你不会在平台中安装任何存储插件——你需要在第二天部署一个内置的或容器存储接口（CSI）插件，以为你的工作负载提供持久卷（我们将在本章后面讲解与存储相关的内容）。

你可以在这里看到一个 UPI/无关安装程序的示例：

图 2.5 – UPI/无关安装程序

如你所见，图 2.5 中，在 UPI 或无关安装程序的情况下，你需要负责提供一些必备层级来部署集群（并在第二天进行维护），而与图 2.4 中完全自动化的 IPI 模式相反。

计算

从计算角度来看，以下是架构设计中必须考虑的重要属性：

节点和集群规模：定义工作节点的数量和大小，以承载平台预期的工作负载。在这里需要考虑一些重要因素，以确保集群的弹性——这一主题将在本章后面进行讲解。
环境划分：可能只需要一个集群，提供为特定目的而隔离的节点组。有时候，使用一个专门的节点组来为特定环境提供服务是有意义的——例如，一个集群中可能有为开发环境提供服务的节点组，为暂存环境提供服务的节点组，和为生产环境提供服务的节点组。因此，这是一个需要做出的关键决策——是为每个环境创建一个集群，还是使用一个集群来服务多个环境。我们将在下一章深入探讨这一点，并查看每种情况的利弊。

主节点的资源配置

为了定义主节点的大小，建议根据预期的集群负载和节点数量，遵循 Red Hat 的基准配置，具体如下：

基础设施节点的资源配置

同样，基础设施节点的大小也有一个基准，基于预期的集群大小，具体如下：

然而，前述表格并未考虑 OpenShift 日志记录。因此，如果你计划使用日志功能，请在托管 Elasticsearch 实例的节点上至少增加四个虚拟 CPU（vCPU）和 16GB 内存。

工作节点的资源配置

估算 OpenShift 集群大小并没有单一的算法。我们在这里列出的资源配置算法，基于我们多年来与 OpenShift 的实践经验，同时参考了我们所学到的优秀文章和资源——关于这个话题的一些优秀参考资料可在本章的进一步阅读部分找到。

可分配资源

计算资源配置的估算依据需要考虑节点的可分配资源。可分配资源是指节点上实际可用于工作负载的资源量，考虑到操作系统和kubelet所保留的资源。可分配资源的计算公式如下：

OpenShift 默认值

OpenShift 工作节点的默认值如下（截至本文写作时）：

CPU：

system-reserved = 500m (*)
kube-reserved = 0m (*)
hard-eviction = 0m (*)

内存：

system-reserved = 1Gi
kube-reserved = 0Gi
hard-eviction = 100Mi

() "m" 表示毫核*，是 Kubernetes 的标准单位，表示一个 vCPU 被划分为 1000 个部分。

示例

假设你使用 8 vCPU 和 32 GB 随机访问内存（RAM）的服务器作为默认规格。此规格的工作节点最终将具有以下推荐的可分配资源：

内存：

图例：

ar = 可分配资源

nc = 节点容量

kr = Kube 保留

sr = 系统保留

he = 硬驱逐阈值

因此，一个拥有 8 vCPU 和 32 GB RAM 的工作节点大约会有 5 vCPU 和 23 GB RAM 被视为可供应用使用的容量。假设某个应用 Pod 平均需要 200 毫核和 1 GB RAM，那么这样的工作节点大约可以承载 23 个 Pod（以内存为限制）。

聚合日志

你可以选择部署基于 Elasticsearch、Kibana 和 Fluentd 的 OpenShift Logging 工具。下图解释了该工具的工作原理：

图 2.6 – OpenShift 日志组件

你并不需要强制使用 OpenShift Logging，如果你已有日志解决方案并希望继续使用它，只需要配置 ClusterLogForwarder，正如本书后面章节（从 第五章，OpenShift 部署）所示。

监控

任何容器编排平台都必须配备一个监控工具，以便监控你的基础设施和应用程序。OpenShift 自带一个基于 Prometheus、AlertManager 和 Grafana 的监控解决方案。下图解释了监控组件：

图 2.7 – OpenShift 监控组件

OpenShift 监控并非可选项；许多内部平台组件都在使用它。然而，如果你打算使用其他监控工具而不是 OpenShift，你可以选择使用临时存储来保持其运行。另一方面，如果你计划使用 OpenShift 监控，我们建议你提供持久化存储以保存监控指标。

存储

容器本质上是无状态的，但这并不意味着在 OpenShift 上不可能有有状态的容器。有多种方法可以在容器内挂载存储卷并启用有状态的工作负载。在接下来的几节中，我们将详细介绍您在架构设计中应考虑的 OpenShift 集群的常见存储需求。

存储后端

存储实现有两种类型：in-tree 和 CSI 插件。

in-tree 卷插件

in-tree 插件是允许 Kubernetes 平台访问和使用外部存储后端的实现。in-tree 的名称源于这些实现是在主要 Kubernetes 仓库中开发和发布的，作为in-tree模块。以下是支持的几种in-tree插件类型：

(*) 本书编写时。请访问access.redhat.com/articles/4128421查看当前支持的选项。

CSI 驱动程序

随着越来越多的存储提供商支持 Kubernetes，开发和维护in-tree插件变得困难，并且不再是最有效的模型。在这种背景下创建了 CSI：通过使用 API 接口提供一种标准方式来扩展 Kubernetes 存储能力—因此，您可以轻松地为不同的存储提供商添加新的 CSI 插件，并在 OpenShift 中使用它们。使用 CSI，还可以拥有诸如快照、调整大小和卷克隆等有趣的功能；然而，是否实现这些功能取决于存储提供商，因此请与他们核实是否有可用的 CSI 驱动程序实现以及支持哪些操作。

重要提示

Red Hat 支持来自 OpenShift 方面的 CSI API 和实现；然而，支持存储端是存储供应商的责任。如果有支持的 OpenShift CSI 选项，请与您的存储供应商联系。

存储需求

现在您已经了解了可用于 OpenShift 的存储插件类型，让我们来审查一下通常在 OpenShift 集群中具有的存储需求。

服务器硬盘

默认情况下，OpenShift 服务器使用一块 120 GB 的硬盘。大型集群需要低延迟和高吞吐量的主节点，这些节点可以提供至少 500 个顺序输入/输出操作每秒（IOPS）（通常为固态硬盘（SSD）或非易失性内存扩展（NVMe）硬盘）。我们还将在第五章，OpenShift 部署中深入探讨这些细节。

OpenShift 内部注册表

这取决于要存储的应用程序镜像的数量和大小。如果你没有镜像的预估值，通常 200 GB 的初始大小足够支撑最初的几周。作为最佳实践，考虑设置镜像修剪策略，自动删除不再使用的镜像——我们将在第五章中通过示例讲解这些最佳实践，OpenShift 部署。

OpenShift 内部注册表使用的卷类型：RWX

OpenShift 日志

这取决于应用程序生成的日志数量。以下是一个示例，展示了每秒生成 10 行日志（每秒行数）的应用程序所需的卷大小；这些日志每行平均为 256 字节（每行字节数），假设日志的保留期为 7 天：

这意味着该应用程序的一个 Pod 在 7 天内将消耗接近 1.5 GB 的存储（这是日志存储在 Elasticsearch 上的时长）。另一个需要考虑的重要因素是 Elasticsearch 的复制因子，根据选择的复制因子，存储需求会有所不同。以下是可用的复制因子：

FullRedundancy：将每个索引的主分片复制到每个 Elasticsearch 节点
MultipleRedundancy：将每个索引的主分片复制到 50% 的 Elasticsearch 节点
SingleRedundancy：为每个索引的主分片创建一个副本
ZeroRedundancy：不创建主分片的副本

OpenShift 日志使用的卷类型：RWO

OpenShift 监控

OpenShift 监控默认情况下使用平台内的临时存储（也称为emptyDir），这意味着，如果由于某些原因，Prometheus Pod 被重新启动，所有的指标数据将丢失。为了避免丢失指标数据，考虑为 Prometheus 和 AlertManager Pods 配置持久卷。

Red Hat 基于执行的各种测试提供了基准，如图所示。这些经验数据是估算 Prometheus 所需存储的良好指南：

(*) 15 天是默认的保留期。

你还需要考虑 AlertManager 的卷：通常情况下，20 GB 的卷大小对大多数情况足够。

默认情况下，HA 配置由两个 Prometheus 副本和三个 AlertManager 副本组成。

使用前述的参考数据，我们可以估算 OpenShift 监控所需的卷大小。例如，假设我们计划部署一个不超过 50 个节点和 1,800 个 Pods 的集群。在这种情况下，我们需要使用以下公式：

OpenShift 监控使用的卷类型：RWO

注意

前述要求基于经验数据。实际观察到的消耗可能更高，具体取决于工作负载和资源使用情况。有关更多信息，请参阅官方文档：docs.openshift.com/container-platform/latest/scalability_and_performance/scaling-cluster-monitoring-operator.html。

目前，你不需要深入了解 OpenShift 组件，如日志或监控，因为我们仅在此讨论所需的（或估算的）存储量。有关这些工具的详细信息将在本书后面讲解。

示例

由于我们已经讨论了 OpenShift 集群的大小规范，接下来我们使用一个示例来使其更清晰。假设我们正在设计一个 OpenShift 集群架构，计划托管一个三层 Node.js 应用，具有以下容量：

前端最多 20 个 Pods 在峰值负载时每个需要 300 毫核心和 1 GB RAM。每个 Pod 每秒生成 30 行日志（每行 256 字节）。无状态 Pods。
后端最多 4 个 Pods 在峰值负载时每个需要 500 毫核心和 1 GB RAM。每个 Pod 每秒生成 10 行日志（每行 256 字节）。无状态 Pods。
一个 MongoDB 数据库实例，具有 8 GB RAM 和 2 个 vCPU。它每秒生成 1 行日志（每行 256 字节）。需要一个RWO卷，容量为 500 GB。

我们的日志堆栈配置为ZeroRedundancy（没有数据复制）。

计算大小

首先，让我们看看所需的 CPU 和内存总量（仅针对工作负载），如下所示：

CPU
内存
卷

我们默认假设节点具有 4 个 vCPU 和 16 GB RAM。如本章所示，我们需要应用以下公式来定义推荐的可分配资源：

注意

我们在此假设某些程度的 CPU 过载是可以接受的，因此我们在此不考虑额外的 25%容量（推荐的可分配资源）。

内存

因此，需要三个节点来托管此工作负载：

这意味着我们需要3 个节点，4 个 vCPU 和 16 GB RAM，以提供此应用所需的容量。

存储大小

现在，让我们计算所需的卷数量，如下所示：

虚拟机（VMs）：3（节点） * 120 GB（每台服务器推荐） = 360 GB 磁盘
工作负载：500 GB RWO
内部注册表：200 GB RWX
日志：106 GB RWO（见下文）**

前端：

后端：

MongoDB：

总计：

监控：248 GB RWO（如我们在上一节中看到的，针对最多 50 个节点和 1,800 个 Pod 的监控尺寸要求）

总结

以下表格总结了这个集群所需的服务器，考虑到有三台额外的服务器专门用于托管 OpenShift 基础设施组件（日志、监控、注册中心和Ingress）。

在之前的表格中，bootstrap 节点没有被考虑在内，因为它是一个临时节点，集群安装后会被移除。

最后，持久化存储卷的要求在以下表格中进行了总结：

既然我们已经了解了一些在 OpenShift 集群中需要遵循的最佳实践，接下来让我们讨论在设计 OpenShift 架构时，还需要考虑的一些其他方面。

基础设施/云提供商

由于 OpenShift 平台与基础设施或云提供商集成，因此也需要一些先决条件，但目前在架构设计阶段，你只需要定义选择哪个提供商，并意识到它们有特定的先决条件。我们在这一章中不会涉及这些先决条件，因为它将在第五章中深入讲解，OpenShift 部署。

在这一章中，我们将实际操作部署过程，从准备基础设施或云端先决条件、设置安装程序参数、存储、网络、虚拟化/云层等开始。然而，在架构设计阶段，通常不需要深入这些细节，只需要选择一个提供商，并记住一些你需要满足的提供商要求。

网络考虑事项

一个 OpenShift 集群使用 SDN 层来允许工作负载与集群对象之间的通信。本书编写时 OpenShift 使用的默认插件是 OpenvSwitch（OvS），但 OpenShift 也兼容（并支持）OVN-Kubernetes 插件。查看此链接以更好地理解插件之间的差异：docs.openshift.com/container-platform/latest/networking/openshift_sdn/about-openshift-sdn.html#nw-ovn-kubernetes-matrix_about-openshift-sdn。

在 SDN 中，有两个虚拟子网——第一个包含集群内部 Pod 使用的互联网协议（IP）地址，而第二个在创建服务对象时总是使用。以下表格列出了这些子网的默认值：

重要说明

以上范围仅在平台安装过程中可定制！安装后无法修改这些范围。

确保这两个范围与您物理基础设施中现有的范围不冲突。如果发生冲突，您可能会遇到 OpenShift 中的 Pods 与这些范围内具有真实 IP 的外部服务之间的路由问题。原因很简单：OpenShift SDN 始终认为任何在 Pods 范围内的 IP 都是集群内部的 pod——在这种情况下，SDN 永远不会将此数据包传递到外部网络（网络地址转换，NAT）。因此，OpenShift 上的 pod 永远无法与集群外部的真实服务进行通信，除非该服务的 IP 不在 Pods 或服务的范围内。所以，请小心定义这两个范围，确保它们永远不会在您的基础设施中被使用。

那么，让我们继续探讨从网络角度需要考虑的其他重要方面！

VPC/VNet

如果您正在 Amazon Web Services (AWS)、Azure 或 Google Cloud Platform (GCP) 上部署 OpenShift，您可以选择在新的或现有的 VPC/虚拟网络 (VNet) 中安装 OpenShift 集群。如果选择现有的 VPC/VNet 组件，例如子网、NAT、互联网网关、路由表等，安装程序将不再自动创建它们——您需要手动进行配置。

DNS

根据安装方法和提供商的不同，DNS 的要求也不同。我们将在本书稍后详细讨论这一点，但请记住，DNS 的要求集取决于您选择的提供商和安装方法。

负载均衡器

在本地环境中，IPI 已经包含了一个嵌入式的高可用负载均衡器。在云环境中，OpenShift 使用云提供商提供的负载均衡器（例如，AWS 弹性负载均衡（ELB）、Azure 的网络负载均衡器（Network LB）、GCP 的云负载均衡（Cloud Load Balancing））。使用 UPI 时，您需要提供一个外部负载均衡器并在集群部署之前进行配置。

DHCP/IPMI/PXE

如果您选择在裸金属上部署 OpenShift，请遵循此类环境下的其他要求。DHCP、IPMI 和 PXE 是可选的，但建议使用它们以提高自动化水平。因此，请在集群架构设计时考虑这一点。

网络访问

OpenShift 平台需要从一系列网站访问以下载所使用的镜像，包括 Red Hat 公共注册表，可以通过代理或直接访问。不过，也可以在受限网络上安装 OpenShift，但需要做额外的工作：您需要先建立一个内部注册表，并将所有所需镜像从 Red Hat 的注册表镜像到此。如果使用代理，请检查代理的性能，避免在 OpenShift 拉取镜像时发生超时错误。

到目前为止，我们已经涵盖了从基础概念到与安装模式、计算、网络和存储相关的最佳实践的大量内容。对于 OpenShift 集群架构的最重要方面，我们几乎完成了所有内容，但我们不能忽略与认证和安全相关的一些考虑。请查看本章后续部分，了解我们为此章节带来的一些最终考虑，以帮助您设计集群的架构。

其他考虑事项

最后，在设计您的 OpenShift 集群的过程中，还有一些您应考虑的事项。

SSL 证书

OpenShift 使用 SSL 用于所有集群通信。在平台安装期间，会生成自签名证书；但是，可以替换 API 和入口证书。在这一点上，您只需要知道这是可能的；在本书的后面部分，您将看到如何操作。

IdP

OpenShift 使用临时 kubeadmin 用户部署。强烈建议您配置新的 IdP 以允许用户使用便捷和安全的认证方法登录平台。OpenShift 支持多种 IdP；以下是本书撰写时支持的选项列表：

结束本章并为您提供快速参考指南，查看我们提供的 OpenShift 架构检查表。

OpenShift 架构检查表

这些检查表将帮助您在 OpenShift 架构设计过程中确定可能需要采取的主要决策，并可用作本章节涵盖的概念总结。

这里是安装模式和计算的检查列表：

这里是附加工具的检查列表：

这里是存储的检查列表：

这里是网络的检查列表：

这里是其他一些一般考虑事项的检查列表：

总结

在本章中，我们讨论了在开始集群部署之前，在架构设计阶段需要考虑和定义的一些最重要的方面。您现在了解了在平台上的不同选择以及如何估算节点和存储的数量和大小。

查看下一章节—第三章，多租户考虑—获取有关 OpenShift 架构多租户方面更多知识。

进一步阅读

如果你想深入了解本章涵盖的主题，请查看以下参考资料：

etcd 文档: etcd.io/docs/latest/
Kubernetes 官方 文档: kubernetes.io/docs/home/
关于 Kubernetes 操作符（Operators）： kubernetes.io/docs/concepts/extend-kubernetes/operator/
关于rpm-ostree的文档： coreos.github.io/rpm-ostree/
Open Container Platform (OCP) 支持的 CSI 驱动程序：docs.openshift.com/container-platform/4.8/storage/container_storage_interface/persistent-storage-csi.html#csi-drivers-supported_persistent-storage-csi
关于可分配资源的图形解释： learnk8s.io/allocatable-resources
如何根据应用程序 需求规划您的环境： docs.openshift.com/container-platform/latest/scalability_and_performance/planning-your-environment-according-to-object-maximums.html#how-to-plan-according-to-application-requirements_object-limits
推荐的主机实践、大小调整及 其他事项： docs.openshift.com/container-platform/latest/scalability_and_performance/recommended-host-practices.html

第三章：3

多租户注意事项

与几乎所有软件一样，随着数量和规模的扩展，事情会变得更加复杂。在上一章中，我们讨论了与 OpenShift 集群架构相关的最重要方面。在本章中，我们将讨论在一个或多个集群上处理多个环境时应了解的一些事项。

本章将讨论以下主题：

什么是多租户？
处理多个租户
OpenShift 上的多租户
多租户策略

什么是多租户？

多租户是指使用单一平台实例为多个用户或组（也称为租户）提供服务的能力。平台架构可以设计为单租户或多租户：

在单租户平台架构中，平台实例内没有隔离。这意味着实例内没有分隔，因此也无法隔离用户或组的对象。在这种情况下，要实现多租户，你需要为每个租户提供一个单独的平台实例。
在多租户平台架构中，可以在不同租户之间隔离对象和数据。因此，即使使用单一平台实例，也可以保护每个租户的数据和对象，从而提供足够的隐私和安全性。

根据架构设计和 OpenShift 的使用方式，你可以拥有两种类型的平台（单租户或多租户）。在本章中，你将学习如何在设计 OpenShift 集群时，考虑这一点的最佳方式。

处理多个租户

在 OpenShift 上处理多个租户有许多不同的方式，其中最明显的一种是为每个租户拥有一个单独的集群。然而，这并非总是可能的或最佳选择：为每个租户提供专用硬件和平台可能会很昂贵，维护起来也很困难，且效率不高。通过共享集群，不同租户的多个工作负载共享相同的计算资源，从而实现更高效的计算使用。

OpenShift 可以为每个租户提供对象、计算、网络和其他硬件资源的隔离，确保它们相互隔离。在下一节中，我们将探讨不同类型的隔离以及如何利用它们。

OpenShift 中的多租户

当谈到 OpenShift 上的多租户时，会涉及到多个对象。下表展示了一些提供多租户功能的重要资源，我们将在本章中讨论这些内容：

下图说明了这些资源如何组合在一起提供隔离并启用多租户：

图 3.1 – 多租户和隔离

现在，让我们来看一下这些对象是如何在 OpenShift 上提供多租户功能的。在接下来的第五章《OpenShift 开发》示例中，我们将使用它们，所以现在不用担心如何使用它们。相反，专注于理解它们如何提供隔离功能，以实现多租户。

命名空间

命名空间提供了一定程度的隔离。使用命名空间，你可以为以下内容定义一个有限的空间：

Kubernetes 工作负载：Pods、Secrets、ConfigMaps、Deployments等。
访问控制：通过为用户或组分配适当的角色（权限），来隔离命名空间资源的访问。
限制资源消耗：可以通过ResourceQuotas限制命名空间所消耗的资源数量。

基于角色的访问控制

在 OpenShift 上对资源的权限控制是通过对资源（如Pods、Services、Deployments、Jobs等）使用get、list、watch、create、upgrade等权限进行的，同时RoleBindings（或ClusterRoleBinding）用于将角色绑定到主体（如组、用户或ServiceAccounts）。

你需要使用角色和 RoleBindings 根据租户和你希望实现的隔离逻辑，为用户提供正确命名空间的权限。

资源配额（ResourceQuotas）

ResourceQuotas允许集群管理员将命名空间的资源限制为有限的资源集。它可以限制计算资源和/或对象数量。当你使用共享集群时，考虑 ResourceQuotas 非常重要，它可以确保每个租户的容量是有限的。如果没有 ResourceQuotas 的限制，可能会导致一个命名空间占用整个工作节点的容量。

nodeSelectors、污点（taints）和容忍度（tolerations）

通过nodeSelectors，你可以将工作节点专门分配给特定的用途或租户。使用 nodeSelectors，可以为每个租户隔离物理计算资源：例如，在一个 10 节点的集群中，你可以将五个节点分配给 QA，另外五个节点分配给开发。Taints和tolerations是实现这一目标的不同方式：使用 nodeSelectors 时，你指示 Pod 在包含特定标签的节点集合中调度，而使用 taints 时，你指示工作节点拒绝那些没有特定容忍度的 Pods 运行。

网络策略（NetworkPolicy）

网络策略提供了一种标准的方式来隔离 Pods 和命名空间之间的网络流量。它类似于防火墙，你可以定义入站和/或出站策略来接受/拒绝不同 Pods 和命名空间之间的流量。

Ingress/router 分片

在 OpenShift 上，你可以创建多个 Ingress 控制器，这将允许你在不同租户之间隔离入站流量。

多租户策略

重要的是要理解，在使用前面提到的多租户对象时，并没有物理隔离——隔离是由软件定义并实现的。然而，通过使用不同的多租户策略，如您现在将看到的，仍然有可能提供物理级别的隔离。最佳策略取决于您公司中的需求；有些公司更关注计算资源的高效利用，而其他公司则不在乎额外的资源开销，只要能获得最安全的隔离策略。

一些不同的策略如下：

每个租户拥有专用集群
没有物理资源隔离的共享集群
带有专用工作节点的共享集群
带有专用工作节点和入口控制器的共享集群

专用集群

正如我们之前提到的，最明显的策略是为每个租户提供不同的集群。下图展示了为两个租户（QA 和开发）提供服务的示例：

图 3.2 – 专用集群

下表总结了我们对这种策略的优缺点：

这种架构通常推荐给那些对物理隔离环境有严格要求，并且不想依赖多租户软件和流程来提供隔离的公司。

共享集群，无物理隔离

另一方面，您可能决定使用一个共享集群为多个租户提供服务，同时使用 OpenShift 对象来实现多租户（如命名空间、RBAC、资源配额和网络策略）。您可以在下图中看到该策略的简单示意图：

图 3.3 – 共享集群，无物理隔离

下表展示了这种策略的一些优缺点：

这种架构通常适用于非生产环境，在这些环境中，某些与性能下降相关的事件，例如，偶尔可以容忍。

共享集群，专用工作节点

如果您必须提供物理隔离的计算资源，这可能是正确的方向。在这种情况下，您将使用相同的对象来提供隔离，但为特定租户专用工作节点。以下是一个简单的示意图：

图 3.4 – 共享集群，专用工作节点

这种策略有以下优缺点：

这种架构通常适用于非生产环境，其中某些性能下降相关的事件（例如）有时是可以容忍的。该架构也适用于没有高 HTTP(S) 吞吐量和低延迟 HTTP(S) 要求的生产工作负载。以下链接提供了单个 OpenShift 入口控制器（HAProxy）的容量基准，供参考：docs.openshift.com/container-platform/latest/scalability_and_performance/routing-optimization.html。

共享集群、专用工作节点和入口控制器

最后，采用这种策略，你可以通过提供更高的隔离级别，在不同租户之间共享集群。下图展示了该集群的架构：

图 3.5 – 共享集群、专用工作节点和入口控制器

这种策略有以下优缺点：

这种架构通常适用于生产环境和非生产环境。如果定义明确并正确使用，它的效果与专用集群相同。这种策略与专用集群之间的唯一区别是，在这种情况下，配置错误可能导致应用部署到错误的租户（例如，在命名空间中使用错误的nodeSelector）。

OpenShift 多租户检查清单

为了总结本章，我们决定在前一章开始构建的检查清单中添加一些额外的项目，如下所示：

在下一章中，你将了解与 OpenShift 通常相关的各种角色，从 C 级高管到操作层级，以及每个角色所需的技能。你将能够理解应该期望每个角色的职责，并为自己和团队做好与 OpenShift 合作的准备。

总结

本章中，我们探讨了提供多租户服务的几种策略，适用于 OpenShift 集群。你现在应该理解，我们可以拥有专用或共享的 OpenShift 集群来托管租户。你还看到，对于共享集群，可以通过使用命名空间、资源配额（ResourceQuotas）、网络策略（NetworkPolicies）以及其他对象，提供一定程度的租户隔离，甚至实现工作节点和/或入口控制器的物理隔离；最适合你的用例的选择取决于组织的需求、工作负载和环境。

然而，我需要提醒你，在当前的混合云环境中，你可能需要与不同提供商和地区的集群进行协作，这可能导致集群数量的不断增加。但不用担心——正如我们在第一章中看到的，混合云之旅与策略，许多优秀的工具可以帮助我们管理多个集群，比如 Red Hat 高级集群管理、先进集群安全和 Quay；我们将在本书最后一部分深入探讨这些工具，并通过实际示例进行讲解，这一部分专门讲解这些工具。

在下一章中，我们将学习与 OpenShift 相关的角色和技能组合，它们的主要职责和任务，以及其他重要因素。

进一步阅读

如果你想了解更多关于本章所涉及的概念，请查阅以下参考资料：

什么是 多租户？ www.redhat.com/en/topics/cloud-computing/what-is-multitenancy
多租户网络隔离（OpenShift 文档）: docs.openshift.com/container-platform/4.8/networking/network_policy/multitenant-network-policy.html

第四章：4

OpenShift 人物角色与技能集

现在你已经了解了 OpenShift 集群架构的样子，那么如何理解与之合作的人们呢？在我的职业生涯中，我见证了许多不同软件、平台和流程的采用，其中一些进展顺利，而另一些则面临挑战。它们之间的区别是什么，决定了好的还是坏的采用？主要的区别就是人——也就是说，处理人们的方式在很大程度上决定了采用是否成功。

我们坚信，你需要像关心平台本身一样关心人们。因此，我们决定在本书中留出一些页面，讨论执行任务所需的主要人物角色和技能。

因此，在本章中，你将找到以下内容：

一些与 OpenShift 相关的人物角色
通常这些人物角色需要的主要职责和任务
他们通常面临的挑战
他们通常期望在容器平台中看到什么
一个包含资源所需主要能力的技能矩阵

本章涵盖的主要内容如下：

人物角色
技能矩阵

让我们深入了解！

人物角色

在这一部分，我们将讨论在职业生涯中通常与 OpenShift 打交道的专业角色（人物角色），这些角色通常都与 OpenShift 有某种程度的关系。

在下图中，你将看到 IT 部门的一些典型角色：

图 4.1 – 人物角色与 OpenShift

让我们回顾一下主要的技术角色，并学习有用的信息，以便更好地为组织准备 OpenShift 的采用。如果你从事协调角色，利用这个机会了解你应该期待你的技术团队做什么；如果你是个人贡献者，学习你每天可能需要处理的活动和技能。

一个系统/云/平台管理员

一个系统、云或平台管理员是一个个人贡献者，负责维护 OpenShift 集群的基础设施以及集群本身。根据组织的规模，这个角色可以有多个专业化领域，例如网络、操作系统和存储管理。

让我们看看他们需要执行的一些职责，以及在执行过程中面临的挑战。

关键职责和任务

支持网络、存储、虚拟化层和基础设施。
OpenShift 集群管理操作，如扩展节点、升级，以及授予用户和组权限。
配置 OpenShift 命名空间、网络策略、资源配额、节点选择器等。
平台容量管理。
云成本估算和报告。
向供应商提交支持票据以获得帮助，处理与集群底层基础设施和/或 OpenShift 相关的问题。
监控平台性能和稳定性。
主动分析和报告事件，尤其是在发现可能的问题时。
对用户的事件进行响应。
收集日志以调查问题。
报告运营指标，如事件数量、平均恢复时间（MTTR）和平均故障间隔时间（MTBF）。

他们通常面临的挑战

标准：随着集群规模的增长，管理变得越来越困难，主要是因为缺乏可以使用的标准。
可观测性：组织在建立全面且高效的应用程序和基础设施监控时常常遇到困难，这并不罕见。不高效的监控工具和实践使得做出正确决策变得更加困难。管理员在建立正确的工具和实践以适当监控环境方面遇到困难。
容量规划和管理：集群管理员通常面临正确管理集群容量的挑战。由于缺乏监控和容量规划，集群资源耗尽的情况并不少见。
云成本：随着云使用量的增加，控制成本也变得更加困难。
支持多个云环境：管理员通常需要处理和支持多个云环境，这使得管理和操作变得更加具有挑战性。
日志管理：一些公司在定义和维护高效的容器日志平台方面遇到困难，这影响了问题分析、问题根源检测等。
支持票据：管理供应商的支持票据通常会遇到困难，有时是因为缺乏收集日志等信息的知识，或者信息不足，无法让供应商进行审查，或者供应商的响应延迟。

用户希望在容器平台上看到什么？

一个成熟的企业级容器编排平台，用于托管开发团队开发的应用程序。
能提供出色支持体验并建立自己作为可信顾问合作伙伴的供应商。
与不同基础设施和/或云供应商兼容的平台。
如果已有监控和/或日志工具，平台需要能够与之集成。如果没有，平台需要提供开箱即用的日志和监控工具。
提供 GitOps 工具的平台，例如 Argo CD。
监控工具和仪表板可以协助集群的容量规划和管理。
提供高水平自动化的平台，或者能够使用像 Ansible 或 Terraform 这样的工具轻松实现自动化。
提供完整的产品文档和知识库。
来自供应商或合作伙伴的优质培训。

下一个通常与 OpenShift 有紧密关系的角色是 IT 架构师。让我们现在仔细看看它。

IT 架构师

在 OpenShift 的背景下，IT 架构师是负责为一个或多个集群设计高级架构和定义的个人贡献者。架构师收集业务需求，了解问题、难题以及其他参考，以定义最佳解决方案来解决这些问题。不同公司有不同的架构师角色，以下是一些常见角色：

应用架构师：设计并监督应用程序及相关技术任务的开发和发布。
解决方案架构师：通常是具有较强技术背景但也具备管理知识的架构师，负责领导整个项目。
企业架构师：与业务部门合作，定义公司整体 IT 战略的架构师。
基础设施/云架构师：设计并监督云服务提供商或本地硬件和基础设施上的项目。

如下所述的架构师角色更接近基础设施/云架构师，一般会与 OpenShift 的合作更加紧密。

主要职责和任务

与业务部门合作，获取容器编排平台的需求。
规划和设计集群架构，考虑到业务需求和最佳实践，例如高可用性、安全性以及任何关键平台的其他重要方面。
估算处理初始所需容量的规模。
估算部署和支持平台的工作量。
估算平台的初始和持续成本。
协助主管和其他副总裁级别的人员做出平台采购决策。
设计平台的监控和日志解决方案。
定义平台的安全性要求。
定义持续的政策和流程要求，例如备份和灾难恢复。
协助 DevOps 工程师定义使用容器平台的持续集成/持续部署（CI/CD）流程和管道。
将决策和规格交给开发和运维团队。协助部署和平台使用。

他们面临的挑战（通常）

知识：我曾多次看到 IT 架构师被推到为 OpenShift 集群设计架构，甚至有时连最基本的概念都不清楚。他们习惯于为其他较简单系统中的应用程序设计架构，而不是为像 Kubernetes 或 OpenShift 这样的平台设计架构，在这些平台中，你需要处理虚拟化、存储、网络等各方面的问题。
缺乏支持：架构师通常需要获取信息并与组织内部不同团队的人沟通，以理解并定义架构的某些方面——例如，他们可以使用的存储选项、将使用的网络特性等。当他们没有适当的支持来接触正确的人时，架构设计通常会变得耗时且令人沮丧。
需求定义：在许多组织中，平台的需求定义并不明确。某些公司甚至不知道他们想通过平台实现什么，仅仅因为某些竞争对手在使用该技术或其他类似原因而决定采用它。这使得架构定义变得更加困难，因为在决策过程中很难做到果断和准确。
供应商协助：架构师在平台的架构设计过程中需要大量的供应商协助。与供应商的互动有时会遇到挑战，原因包括供应商可用性不足、回复信息延迟等。

容器平台上，他们想看到什么？

一个成熟的企业级容器编排平台，用于托管开发团队开发的应用程序
能够满足服务级协议（SLA）要求的供应商
可以提供信息、演示和概念验证的可信供应商
与业务定义的基础设施和/或云供应商兼容的平台
一个能够与现有工具集成的平台，如应用性能管理（APM）、监控和日志记录
一个全面的平台，包括监控、日志记录、CI/CD、服务网格和无服务器工具。
开箱即用的 GitOps 工具
一个包含 IDE 插件、示例和其他开发工具的生态系统
一个开箱即用具有高度自动化的平台，和/或可以轻松通过像 Ansible 或 Terraform 这样的工具进行自动化
一个多集群的集中管理解决方案
提供完整产品文档和知识库
来自供应商或合作伙伴的优质培训

这个难题中非常重要的一部分是应用程序开发人员；没有他们，就没有应用程序可以在任何平台上托管！让我们现在来看看他们的角色。

应用程序开发人员

开发人员是使用容器平台构建和部署应用程序代码的个人贡献者。在一些公司中，应用程序开发人员可以直接访问容器平台，执行基础操作，如在开发和/或质量保证（QA）环境中部署和配置应用程序；而在其他公司中，他们仅能访问 CI/CD 系统，通过流水线自动检查和部署代码。

主要职责和任务

理解功能需求、用例或用户故事，以开发和测试代码
使用最佳实践（如测试驱动开发（TDD）、CI、基础设施即代码和 GitOps）开发代码
经常提交代码
开发和运行单元测试
构建容器应用
支持 QA 团队测试应用
修复生产问题的缺陷

他们面临的挑战（通常是）

知识：通常，组织并未给予开发者平台知识应有的关注。他们在代码语言、框架、IDE 和相关学科方面受过良好的教育，但对于托管应用的平台——在此案例中是 OpenShift——却不太了解。这是导致重新工作的一个常见原因，因为代码需要适应特定平台的要求
适当权限：开发人员没有适当的容器平台权限以执行职责并不罕见。这会影响他们的工作表现并带来挫败感
适当的流程和工具：一些开发人员没有适当的工具和流程来独立执行活动。通常，他们需要依赖其他团队来安装适当的 IDE 和运行时，更新 CI/CD 管道以反映新的变更，等等
日志管理：在一些公司，开发人员无法直接访问日志；他们需要向其他团队请求，有时这会耗费很长时间，影响缺陷修复问题。

他们希望在容器平台中看到什么？

最流行 IDE 的插件
提供桌面开发环境，并具备构建和测试容器化应用的工具
提供广泛软件开发栈的全面示例
提供不同支持的运行时（如 Java、Spring Boot、Node.js 和 Quarkus）的容器基础镜像
与 CI/CD 工具的无缝集成
UI 开发控制台，可以查看应用日志、监控和配置
提供完整的产品文档和知识库
提供供应商或合作伙伴提供的优质培训
配置了适当权限的平台，允许他们执行职责

一些新的角色也与 OpenShift 密切相关，如 DevOps 工程师和站点可靠性工程师（SRE）。在以下部分中，您将了解更多关于这些角色的信息

DevOps 工程师/SRE

DevOps 工程师通常是负责开发和维护 CI/CD 管道，以支持开发团队的个人贡献者。他们还分析应用构建和部署过程中可能出现的问题，使用 CI/CD 和容器平台工具。这个角色可能引发很多讨论，因为 DevOps 本身是一种文化和一套实践，旨在将基础设施和开发结合起来，使其更加灵活和高效，而不仅仅是一个职位角色

类似地，SRE 通常是将一些软件工程方面的知识引入基础设施，以自动化重复的操作任务，并使环境具有可扩展性和可靠性的人。

DevOps 和 SRE 紧密相关 —— SRE 可以看作是 DevOps 实践的一种具体实现，通常更关注基础设施和操作性问题与实现，而 DevOps 工程师通常更侧重于 CI/CD 过程，支持开发团队更高效地交付代码。

我们决定将这两个角色合并为一个身份，但要根据你的实际环境进行调整，并考虑以下信息，看看哪些最符合你在组织中的角色。

主要职责和义务

理解 CI/CD 流程并相应地开发管道。
持续改进支持开发团队的 CI/CD 管道。
定义、构建并部署容器和 CI/CD 管道的标准。
部署和支持与 CI/CD 过程相关的工具，如容器注册表和 Git 版本控制工具。
自动化与 CI/CD 相关的流程（如 DNS 和负载均衡器配置）。
支持开发团队解决关于 CI/CD 管道的问题和疑问。
自动化重复的操作任务，如服务器配置和网络配置。
定义和实施服务的可观测性。
容量规划。
计划并运行混沌测试。

他们面临的挑战（通常是）

知识：DevOps 工程师和 SRE 通常在自动化方面具有较好的教育背景，但不一定在容器平台及其底层基础设施方面具备相应的知识。
适当的流程和工具：开发所需的最佳 CI/CD、测试和自动化工具并不总是可以获得。在这些情况下，通常需要采用变通方法，付出更多的努力来开发等，这可能非常令人沮丧！
平台限制：这些专业人士通常需要在没有 API 的遗留系统上自动化流程，这使得自动化开发变得更加困难。

容器平台中他们希望看到什么？

与现有 CI/CD 工具的轻松集成
一个 UI 控制台，可以查看构建和部署日志，并检查部署对象
开箱即用的高水平自动化
一个帮助自动化手动步骤的 CLI 和 API
为 CI/CD 工具提供插件，促进管道开发
一个易于在多个集群上部署应用程序的方式
开箱即用的可观测性，或者是可以轻松接入现有工具的可观测性
一个帮助实现混沌测试扰动模型的平台

最后，我们有安全工程师，在任何过程中都非常重要，尤其是在如今的勒索软件和其他真正的安全问题时代。让我们检查接下来的部分，看看他们如何与 OpenShift 相关。

安全工程师

安全工程师是负责审查提供系统和数据安全的流程和工具的个人贡献者。他们始终在评估应用程序和系统，以控制来自已知威胁的环境，保护现有基础设施以最小化漏洞，最后，检测并响应攻击者。

主要职责和任务

评估平台可能存在的漏洞并制定缓解策略。
审查 CI/CD 流水线，并添加安全门控以最大化安全性。
建立容器镜像安全扫描工具，以检测镜像中的已知漏洞。
定义适用于所有集群的安全策略。
确保集群符合已定义的政策。

他们通常面临的挑战

知识：安全工程师与之前的角色没有区别。他们通常对 OpenShift 有真正的顾虑，主要是因为他们对此了解不够，因此不明白 OpenShift 中是如何实现安全性的。
秘密管理：密码和敏感数据的管理在 Kubernetes 上仍然是一个挑战。市场上已有多种保管库系统，但许多公司仍未建立成熟的实践和支持工具，这使得安全团队对此点产生了关注。
权限管理：定义正确的权限级别，以确保一个安全的、不会限制开发人员和其他团队的平衡平台，确实是一个挑战，这关乎生产力的影响。
漏洞扫描：容器和 Kubernetes 的安全工具相对较新，因此大多数公司没有任何可用的工具，这可能会给安全工程师带来真正的噩梦！

他们希望在容器平台中看到什么？

一个使用最安全的容器编排标准的平台，如 Linux 命名空间、cgroups、Linux 能力、seccomp 和 SELinux
一种允许他们轻松定义并强制执行多个集群之间的安全策略的工具
一个支持多租户并能够在不同工作负载之间进行网络隔离的安全平台
数据静态加密
一个安全的基于角色的访问控制（RBAC）平台可用
启用审计日志并进行日志记录
带有安全扫描的镜像注册表

我们已经覆盖了不同技术角色及其职责，这将帮助您和您的组织为 OpenShift 的采用做好准备。最后，我们将呈现一份技能矩阵，旨在帮助理解每个角色所需的主要技能。

技能矩阵

本节将提供一个建议的技能矩阵，适用于前面章节中列出的角色。这里列出的项目是我们根据经验观察到的、对专业人士来说重要的技术技能的子集。请注意，本书并未涉及软技能；这并不意味着我们不重视软技能——恰恰相反，我们非常重视！——但它们不是本书的重点。本技能矩阵按照以下标准分类：

查看下列技能表格，我们已将其拆分为多个部分，以提高可读性。

与架构、基础设施和自动化相关的技能

查阅下表，了解架构、基础设施和自动化任务所需的技能：

与开发、容器和 CI/CD 相关的技能

在下表中，您将找到与开发和 CI/CD 相关的技能：

与 OpenShift 相关的技能

最后，请参见下表，了解 OpenShift 所需的技能：

(*) 如果管理员在部署集群时得到咨询合作伙伴的帮助。如果他们需要部署新的集群，则应该至少具备高级的 OpenShift 安装技能。

总结

我们在本章中讨论了与 OpenShift 相关的主要角色、他们的关键职责、通常面临的挑战以及他们对容器平台的需求。现在，我们也对 OpenShift 专业人士需要具备的能力有了一定的了解。我们希望这能帮助您为自己将要执行的任务做好准备，或者如果您处于管理层职位，可以根据这些信息规划团队的能力建设和招聘政策。

本章总结了本书的第一部分，内容包括概念、架构和能力建设。现在，请继续阅读下一章，开始 OpenShift 集群部署之旅。在该章节中，我们将引导您完成准备安装、部署集群以及执行一些部署后任务的步骤。

进一步阅读

如果您想查看更多与本章内容相关的信息，请查阅以下参考资料：

什么是技能矩阵，我应该在 2021 年使用它吗？：www.skills-base.com/what-is-a-skills-matrix-and-should-i-use-one-in-2021
一切即代码：openpracticelibrary.com/practice/everything-as-code/
GitOps：openpracticelibrary.com/practice/gitops/
我的集群有多满？容量管理与监控在 OpenShift 上的应用*: cloud.redhat.com/blog/full-cluster-capacity-management-monitoring-openshift
容器和 Kubernetes 安全的分层方法: www.redhat.com/en/resources/layered-approach-container-kubernetes-security-whitepaper
OpenShift 容器平台架构: docs.openshift.com/container-platform/4.9/architecture/architecture.html

第二部分 – 利用 Red Hat OpenShift 的企业级产品

在这一部分，你将了解 OpenShift 的部署和 Day 2。你将学习如何构建一个 OpenShift 集群，并探索有助于执行管理任务的对象和 API。通过不同的场景，你将获得保护集群健康、授予适当的访问策略并避免常见错误的宝贵见解，这些错误常常导致过度承诺，进而影响集群的稳定性。

本书的这一部分包括以下章节：

第五章，OpenShift 部署
第六章，OpenShift 故障排除、性能优化与最佳实践
第七章，OpenShift 网络
第八章，OpenShift 安全性

第五章：5

OpenShift 部署

在本章中，我们将导航通过 Red Hat OpenShift 的部署过程。只有当您理解架构的需求、理解应用于基础架构的品牌技术，并了解您应该在 OpenShift 顶部拥有的工作负载时，才能实现成功的实施案例。

正如您在第一章，混合云旅程和策略中所见，这个多集群宇宙中有很多选择。那么，什么是最适合您的选择？您该如何选择？如果您开始准备部署的前提条件而没有妥善准备自己，可能会感到非常困惑。尽管如此，我们必须强调与所选择的架构保持一致的重要性，以确保预期的部署成功。运行时的更改和未计划的间隙可能会带来意外的结果，并导致平台充满缺陷，导致平台无法正常运行。与现实世界进行比较，这就像一艘不能顺利装载集装箱的船，因为它总是在维修，因此无法执行长途旅行甚至起航。

考虑本书第一部分的解释，现在有几种部署 OpenShift 集群的选择。接下来，我们将从问题清单开始，帮助您为自己的需求做出正确的决策。请记住，没有对与错的答案，但这将帮助您决定哪种方式最适合您。

本章涵盖以下内容：

需求
OpenShift 安装先决条件
准备安装
安装
接下来是什么？

那么，让我们开始吧！

需求

这是一个实用章节，您将使用我们认为是最复杂的部署程序之一部署 OpenShift 集群：用户提供的安装程序（UPI）/ 通用安装。

本章中使用的源代码可在 github.com/PacktPublishing/OpenShift-Multi-Cluster-Management-Handbook/tree/main/chapter05 获取。

正如我们在本书中已经涵盖的，有许多不同类型的安装和支持的提供者，几乎不可能涵盖每一种组合 - 我们也没有这个意图，因为有大量的文档、教程和互联网上的优秀参考资料，可以指导您完成各种安装类型。

也就是说，我们理解到，能够为您带来最大价值的部署流程是 UPI/通用部署方式；当您掌握了这种方式后，您将能够理解并轻松执行其他类型的安装。原因很简单：在 UPI/通用安装中，您需要负责提供 OpenShift 部署所需的所有前提条件，而在 安装程序提供的基础设施（IPI）部署中，安装程序本身将自动为您提供所需的前提条件，直接由底层服务商提供。

OpenShift 检查清单选择

您是否已经查看了我们在第二章，“架构概述与定义”，以及第三章，“多租户考虑事项”中提供的检查清单？如果您正在阅读本章以在企业中实现 OpenShift 集群，并且还没有阅读这些章节，我们强烈建议您回去阅读它们，因为它们包含了在部署集群之前您需要考虑和思考的重要方面。

实验室要求

要进行本章中的实验，您将需要以下资源：

一个可以启动实例的虚拟化平台或云提供商。如果您有条件，也可以使用裸金属服务器。
这是虚拟机的最低要求：
- 用于引导节点的临时服务器
- 三台用于主节点的服务器，每台配备 2 vCPU、8 GB RAM 和 50 GB 硬盘（最低要求）
- 两台用于工作节点的服务器，每台配备 2 vCPU、8 GB RAM 和 50 GB 硬盘（最低要求）
- 一台用于堡垒节点的服务器，配备 2 vCPU、4 GB RAM 和 20 GB 硬盘（最低要求）

如果您的环境中没有足够的资源，您还可以使用三节点集群，将主节点和工作节点共置于同一台服务器上。

重要提示

列出的要求仅适用于实验室环境。请参阅第二章，“架构概述与定义”，以获取适用于企业安装的可靠规格。

OpenShift 安装前提条件

在开始 OpenShift 部署之旅之前，您必须观察一些前提条件。首先，我们将根据您在选择表格中做出的决定，探索可选项。

如第一章，“混合云之旅与战略”中所述，OpenShift 有三种安装模式：安装程序提供的基础设施（IPI）、用户提供的基础设施（UPI）和通用（即裸金属安装程序）。需要特别记住的是，没有一个选项适用于所有情况，尽管最好的选项是最适合您先前设计架构的选项。

本章专注于部署以及所有与自己启动集群相关的内容，所以在搭建自己的实验室时请牢记这一点，并享受我们 GitHub 仓库中的提示和资料，这将成为你的一把真正的瑞士军刀。

下表显示了根据所选提供商，你可以使用的安装方法（截至本书编写时）：

关于前表中的术语，我们对每个基础设施提供商的部分可选项进行了分类，以便为你提供当前可能的选择概述（截至本书编写时）。当我们说推荐时，我们不仅仅是表达我们的观点，我们是试图说明这是一个常见且最佳选择。可能表示有效的选项，但会有一些缺点，例如丧失产品开箱即用的一些优秀自动化功能。因此，我们将它们分类为可能，但不是最佳选择。不可用是不言自明的。

由于安装方法不同，前提条件也有所不同，我们准备了一个矩阵，帮助你开始为基础设施做好准备，以启动集群部署：

UPI/无关安装程序

任何 OpenShift 安装都必须具有有效的 Red Hat 订阅、OpenShift 安装程序二进制文件、拉取密钥文件、公共安全外壳（SSH）密钥以及根据每个提供商可用的资源。

在本节中，我们将指导你完成一个可行且可靠的集群安装，无论你选择了哪个提供商。我们还将使用实际示例来设置所需的前提条件——随时可以根据需要多次使用这些配置。

请注意，本章中使用的文件也可以在我们的 GitHub 仓库中找到：github.com/PacktPublishing/OpenShift-Multi-Cluster-Management-Handbook/tree/main/chapter05

那么，让我们从 OpenShift 本身之外，但在部署过程中不可或缺的前提系统开始。

DNS

在本节中，我们将讨论为配置 OpenShift 集群所需的域名系统（DNS）要求。为了演示目的，我们将提供最小配置以确保一切正常工作；对于更深入的设置，请参考本书最后一章中提供的参考资料。

对于我们的实验环境，我们将使用在 Red Hat Enterprise Linux 8 虚拟机上运行的 BIND 工具；不过，你也可以在 Windows 或你偏好的 Linux 发行版上使用任何其他 DNS 服务器。从现在开始，我们将称这台 Linux 虚拟机为 bastion，这是 Red Hat 架构中的一种约定。如果你想严格遵循本章中的指示，建议你使用一个全新安装的 Red Hat Enterprise Linux 8，选择最小安装。

OpenShift 集群需要一个专用的子域名。为了帮助你理解，我们将使用一个假设的 混合云公司，它使用 hybridmycloud.com 作为其主要公共域名。OpenShift 集群的完整子域名将是 ocp.hybridmycloud.com。

要安装 BIND，请在你的堡垒虚拟机上运行以下命令：

$ sudo yum install bind bind-utils -y
$ sudo systemctl enable --now named
$ sudo firewall-cmd --permanent --add-port=53/tcp
$ sudo firewall-cmd --permanent --add-port=53/udp
$ sudo firewall-cmd --reload

现在，我们将配置 DNS 服务器以供 OpenShift 安装和应用程序使用。执行以下步骤来完成此操作：

通过在 named.conf 文件中添加以下代码来创建一个子域名区域。你也可以在我们的 GitHub 仓库 chapter05/named.conf 中下载一个可用的文件：

$ sudo cat << EOF >>  /etc/named.conf
zone "ocp.hybridmycloud.com" IN {
type master;
file "/var/named/ocp.hybridmycloud.com.db";
allow-query { any; };
allow-transfer { none; };
allow-update { none; };
};
zone "1.168.192.in-addr.arpa" IN {  
type master;  
file "/var/named/1.168.192.in-addr.arpa";
allow-update { none; };
};
EOF

在 /var/named/ocp.hybridmycloud.com.db 创建正向区域文件：

$ sudo cat <<EOF > /var/named/ocp.hybridmycloud.com.db
;[1] Begin Common Header Definition
\$TTL 86400
@ IN SOA bastion.ocp.hybridmycloud.com. root.ocp.hybridmycloud.com. (
202201010001 ;Serial
21600 ;Refresh
3600 ;Retry
604800 ;Expire
86400 ;Minimum TTL
)
;End Common Header Definition
;Name Server Information [2]
   IN NS bastion.ocp.hybridmycloud.com.
;IP address of Name Server [3]
bastion IN A 192.168.1.200
;api internal and external purposes [4]
api        IN    A    192.168.1.200 
api-int    IN    A    192.168.1.200 
;wildcard application [5]
*.apps     IN    A    192.168.1.200
;bootstrap node to start cluster install only [6]
bootstrap  IN    A    192.168.1.90 
;master nodes [7]
master1    IN    A    192.168.1.91 
master2    IN    A    192.168.1.92 
master3    IN    A    192.168.1.93
;worker nodes [8]
worker1    IN    A    192.168.1.101
worker2    IN    A    192.168.1.102
EOF

让我们更详细地查看这段代码：

[1]：常见的 DNS 区域头。

[2]：DNS 服务器将是其自己的堡垒服务器。

[3]：来自 DNS 服务器的 IP 地址（堡垒 IP）。

[4]：这些记录是强制性的，需要指向将用于 OpenShift API 功能的 VIP。在我们的案例中，我们使用堡垒服务器作为 VIP（仅适用于实验环境）。

[5]：用于运行 OpenShift 上的应用程序的通配符 VIP 记录。在我们的案例中，我们使用堡垒服务器作为 VIP（仅适用于实验环境）。

[6]：引导节点 IP 记录，仅用于集群安装，安装后可以删除。

[7]：主节点 IP 记录，控制平面对象将托管在此。

[8]：工作节点 IP 记录，工作负载将在此运行。如果你选择三节点集群，请忽略工作主机。

在 /var/named/1.168.192.in-addr.arpa 创建反向区域文件：

$ sudo cat <<EOF > /var/named/1.168.192.in-addr.arpa
\$TTL 1W @    IN    SOA    bastion.ocp.hybridmycloud.com.root (     
2019070700 ; serial 
3H         ; refresh (3 hours) 
30M        ; retry (30 minutes) 
2W         ; expiry (2 weeks) 
1W )       ; minimum (1 week) 
5.1.168.192.in-addr.arpa. IN PTR 
api.ocp.hybridmycloud.com.;
5.1.168.192.in-addr.arpa. IN PTR 
api-int.ocp.hybridmycloud.com.;
90.1.168.192.in-addr.arpa. IN PTR 
bootstrap.ocp.hybridmycloud.com.; 
91.1.168.192.in-addr.arpa. IN PTR 
master1.ocp.hybridmycloud.com.; 
92.1.168.192.in-addr.arpa. IN PTR 
master2.ocp.hybridmycloud.com.; 
93.1.168.192.in-addr.arpa. IN PTR 
master3.ocp.hybridmycloud.com.; 
101.1.168.192.in-addr.arpa. IN PTR 
worker1.ocp. hybridmycloud.com.; 
102.1.168.192.in-addr.arpa. IN PTR 
worker2.ocp. hybridmycloud.com.;
EOF

重要提示

不要为应用程序的通配符 VIP 创建反向区域记录，因为这将导致错误的 DNS 解析。

如果你为三节点集群创建了它，请忽略工作 A 和 PTR 记录。

重启 named 服务：
```
sudo systemctl restart named
```

验证 DNS，以确保所有 DNS 记录已正确设置，使用以下 dig 命令（将 192.168.1.200 替换为你的堡垒 IP）：

使用以下方式验证 OpenShift API：

dig +short @192.168.1.200 api.ocp.hybridmycloud.com
dig +short @192.168.1.200 api-int.ocp.hybridmycloud.com

对于我们在本节中描述的 BIND 示例，输出必须如下：

192.168.1.5
192.168.1.5

使用以下方式验证应用程序的通配符：

dig +short @192.168.1.200 joedoe.apps.ocp.hybridmycloud.com
dig +short @192.168.1.200 whatever.apps.ocp.hybridmycloud.com

所有结果必须指向 ingress 应用程序的通配符 VIP，如下所示：

192.168.1.6
192.168.1.6

验证节点，步骤如下：

dig +short @192.168.1.200 boostrap.ocp.hybridmycloud.com
dig +short @192.168.1.200 master1.ocp.hybridmycloud.com
dig +short @192.168.1.200 master2.ocp.hybridmycloud.com
dig +short @192.168.1.200 master3.ocp.hybridmycloud.com
dig +short @192.168.1.200 worker1.ocp.hybridmycloud.com
dig +short @192.168.1.200 worker2.ocp.hybridmycloud.com

答案必须如下：

192.168.1.90
192.168.1.91
192.168.1.92
192.168.1.93
192.168.1.101
192.168.1.102

最后，让我们验证反向记录，步骤如下：

dig +short @192.168.1.200 -x 192.168.1.90
dig +short @192.168.1.200 -x 192.168.1.91
dig +short @192.168.1.200 -x 192.168.1.92
dig +short @192.168.1.200 -x 192.168.1.93
dig +short @192.168.1.200 -x 192.168.1.101
dig +short @192.168.1.200 -x 192.168.1.102

结果大致如下：

bootstrap.ocp.hybridmycloud.com.
master1.ocp.hybridmycloud.com.
master2.ocp.hybridmycloud.com.
master3.ocp.hybridmycloud.com.
worker1.ocp.hybridmycloud.com.
worker2.ocp.hybridmycloud.com.

做得好！如果你的 DNS 服务器能够正确解析名称，你已经在准备前提条件方面迈出了重要的一步。现在，让我们继续探讨 OpenShift 安装过程中的另一个重要部分：动态主机配置协议 (DHCP)。

DHCP

DHCP 用于为 OpenShift 节点提供 IP 地址。在 UPI 或无关安装节点中，需要通过静态配置在 DHCP 中设置 IP 地址（使用 fixed-address 参数）。

确保 DNS 和 DHCP 中节点的 IP 地址和主机名匹配——DNS 和 DHCP 中的每个 IP 地址和主机名必须相同。在这个前提部分中，我们专注于创建一个简单的 DHCP 设置，以便后续学习和实验使用。如前所述，DHCP 将配置为在 192.168.1.x 子网下提供静态 IP 地址，因此，这个配置使用每个节点以太网接口的 媒体访问控制 (MAC) 地址：

在你的堡垒虚拟机上安装 DHCP：
```
$ sudo yum install dhcp-server -y
```

根据 DNS 使用的主机名和 IP 地址配置 dhcpd.conf 文件：

cat <<EOF > /etc/dhcp/dhcpd.conf
# DHCP Server Configuration file.
#[1]
ddns-update-style interim;
ignore client-updates;
authoritative;
allow booting;
allow bootp;
allow unknown-clients;
default-lease-time 3600;
default-lease-time 900;
max-lease-time 7200;
#[2]
subnet 192.168.1.0 netmask 255.255.255.0 {
option routers 192.168.1.254;
option domain-name-servers 192.168.1.200;
option ntp-servers 192.168.1.200;
next-server 192.168.1.200; #[2.1]
#filename "pxelinux.0";#[2.2]
#[3]
group {
host bootstrap {
hardware ethernet 50:6b:8d:aa:aa:aa;
fixed-address 192.168.1.90;
option host-name "bootstrap.ocp.hybridmycloud.com";
allow booting;
}
host master1 {
hardware ethernet 50:6b:8d:bb:bb:bb;
fixed-address 192.168.1.91;
option host-name "master1.ocp.hybridmycloud.com";
allow booting;
}
host master2 {
hardware ethernet 50:6b:8d:cc:cc:cc;
fixed-address 192.168.1.92 ;
option host-name "master2.ocp.hybridmycloud.com";
allow booting;
}
host master3 {
hardware ethernet 50:6b:8d:dd:dd:dd;
fixed-address 192.168.1.93 ;
option host-name "master3.ocp.hybridmycloud.com";
allow booting;
}
host worker1 {
hardware ethernet 50:6b:8d:11:11:11;
fixed-address 192.168.1.101;
option host-name "worker1.ocp.hybridmycloud.com";
allow booting;
}
host worker2 {
hardware ethernet 50:6b:8d:22:22:22;
fixed-address 192.168.1.102;
option host-name "worker2.ocp.hybridmycloud.com";
allow booting;
}
}
} 
EOF
$ sudo systemctl enable --now dhcpd
$ sudo firewall-cmd --add-service=dhcp --permanent
$ sudo firewall-cmd --reload

让我们更详细地看一下这段代码：

[1]：常见的设置，定义 DHCP 在该子网中作为权威服务器，并设置 IP 租用时间。

[2]：作用域子网定义：

以 # 字符开头的行。

[3]：一个包含所有节点的组，用于租用 IP 地址。如果你选择三节点集群，忽略工作主机。

重要提示

在你的虚拟化管理程序中创建虚拟机后，使用从网络接口获取的 MAC 地址相应地更新 dhcpd.conf 文件；否则，这个子网将无法分配 IP 地址。

Web 服务器

Web 服务器用于提供安装节点的操作系统镜像，同时也提供 Ignition 文件（Ignition 文件是编码为 base64 的清单文件）。在我们的场景中，我们将安装和配置 Apache Web 服务器，这是一种非常简单的方式，可以为集群安装提供所有必要的工具。

按照这份简短的步骤清单来完成这项任务：

安装 httpd 服务器：

$ sudo yum install httpd policycoreutils-python-utils –y

配置 /etc/httpd/conf/httpd.conf 文件，修改 Listen 指令：
```
$ sudo sed –i 's/80/81/g' /etc/httpd/conf/httpd.conf
```

应用 httpd 端口：

$ sudo semanage port -a -t http_port_t -p tcp 81

在 81 上创建规则：

$ sudo firewall-cmd --add-port 81/tcp --permanent
$ sudo firewall-cmd --reload

创建一个目录用于存放操作系统镜像和 Ignition 文件，并创建一个文件来测试连接性：

$ sudo mkdir –p /var/www/html/images
$ sudo mkdir –p /var/www/html/ignition
$ sudo touch /var/www/html/images/imageFileToTest.txt
$ sudo touch /var/www/html/ignition/ignitionFileToTest.txt

设置文件的权限和所有者：

$ sudo chown –R apache. /var/www/html/
$ sudo chmod 744 –R /var/www/html/

启动并启用 Apache Web 服务器：
```
$ sudo systemctl enable --now httpd 
```

使用 curl 命令测试连接性：

$ curl –O http://192.168.1.200:81/images/imageFileToTest.txt
$ curl –O http://192.168.1.200:81/ignition/ignitionFileToTest.txt

如果你能看到文件下载到当前文件夹，说明你已经正确配置了 Apache Web 服务器以提供 OpenShift 安装。

负载均衡器

负载均衡器是 OpenShift 集群架构中的另一个重要元素。它负责在一组节点中的池成员之间平衡连接。出于性能和弹性原因，建议在生产环境中使用专用的负载均衡硬件设备。

在我们的实验环境中，我们将使用 HAProxy 在堡垒机虚拟机中执行负载均衡功能，它是一款强大、轻量且易于使用的软件负载均衡器。

话虽如此，在我们开始配置之前，理解负载均衡方法的基本知识和与 OpenShift 平台匹配的最佳实践非常重要。

我认为负载均衡器就像是几杯水之间均匀分配的水滴，每一滴水都必须落入一只杯子，接着下一滴水必须落入下一只杯子，依此类推。然而，这些杯子会定期被清空，以避免浪费或超载。

因此，执行该任务有多种方法，这些方法被称为负载均衡方法。下表解释了 OpenShift 将会使用的场景：

一个典型的负载均衡器配置由四对前端和后端配置组成，这些配置将平衡不同类型的请求，并为平台提供可靠的容错能力。

第一个池成员是主节点；这些节点由三台服务器组成，应与“最少连接”方法一起使用，并且配置源地址。这个设置确保了在内部 API 调用负载均衡器时，请求会从发起调用请求的同一节点处理，从而保证正确的回调和异步功能。

你可以在这里找到 HAProxy 的前端和后端配置示例：（前端 openshift-api-server 和后端 openshift-api-server）。

图 5.1 – 主节点负载均衡器

第二组负载均衡器配置同样用于主节点的 OpenShift machine-config-server API。请参见前端 machine-config-server 和后端 machine-config-server 中的 HAProxy 配置。

第三组和第四组负载均衡器应该是至少由两台节点（工作节点）组成的池，这些节点将负责从外部到分布在集群工作节点上的应用的流量路由（一个用于 HTTP，另一个用于 HTTPS）。

图 5.2 – 入口负载均衡器

OpenShift 通常推荐在传输层（第 4 层）上运行最少连接与源地址的设置，这能为路由应用提供良好的性能。然而，当在负载均衡器中使用由公共证书授权机构（CA）签名的证书，而不是使用 OpenShift Ingress 控制器时，你必须最终将该池配置为在应用层（第 7 层）上工作。

重要提示

我们强烈建议禁用负载均衡器/防火墙层上的 SSL 检查，以避免数字证书问题和 OpenShift 集群故障。这是因为企业级负载均衡器/防火墙解决方案在启用 SSL 检查模式时，会解密每个 TCP 负载并用新的 SSL 头重新封装它们。OpenShift 将其视为证书错误，导致源/目标 TCP 数据包不正确，导致 TLS 终止时出现挂起。

总的来说，完整的 haproxy.cfg 将类似于以下内容：

$ sudo yum install haproxy -y
$ sudo cat <<EOF > /etc/haproxy/haproxy.cfg
# Global settings
global
  maxconn 20000
  log /dev/log local0 info
  chroot /var/lib/haproxy
  pidfile /var/run/haproxy.pid
  user haproxy
  group haproxy
  daemon
  # turn on stats unix socket
  stats socket /var/lib/haproxy/stats
defaults
  mode http
  log global
  option httplog
  option dontlognull
  option forwardfor except 127.0.0.0/8
  option redispatch
  retries 3
  timeout http-request 10s
  timeout queue 1m
  timeout connect 10s
  timeout client 300s
  timeout server 300s
  timeout http-keep-alive 10s
  timeout check 10s
  maxconn 20000
# Enable haproxy status endpoint
listen stats
  bind :9000
  mode http
  stats enable
  stats uri /
# OpenShift API (port 6443)
frontend openshift-api-server
  bind *:6443 
  default_backend openshift-api-server
  mode tcp
  option tcplog
backend openshift-api-server
  balance source
  mode tcp
# bootstrap line below can be removed after the cluster is deployed
  server bootstrap 192.168.1.90:6443 check
  server master1 192.168.1.91:6443 check
  server master2 192.168.1.92:6443 check
  server master3 192.168.1.93:6443 check
# machine-config-server API (port 22623)
frontend machine-config-server
  bind *:22623
  default_backend machine-config-server
  mode tcp
  option tcplog
backend machine-config-server
  balance source
  mode tcp
# bootstrap line below can be removed after the cluster is deployed
  server bootstrap 192.168.1.90:22623 check
  server master1 192.168.1.91:22623 check
  server master2 192.168.1.92:22623 check
  server master3 192.168.1.93:22623 check
# Applications HTTP (port 80)
frontend ingress-http
  bind *:80
  default_backend ingress-http
  mode tcp
  option tcplog
backend ingress-http
  balance source
  mode tcp
  server worker1 192.168.1.101:80 check # [1]
  server worker2 192.168.1.102:80 check # [1]
# Applications HTTPS (port 443)
frontend ingress-https
  bind *:443
  default_backend ingress-https
  mode tcp
  option tcplog
backend ingress-https
  balance source
  mode tcp
  server worker0 192.168.1.101:443 check # [1]
  server worker1 192.168.1.102:443 check # [1]
EOF

让我们更详细地看看这段代码：

[1]：如果您选择三节点集群，您还应指向这里的主节点。

之后，启动并启用服务以应用 HAProxy 配置，如下所示：

$ sudo setsebool -P haproxy_connect_any=1
$ sudo systemctl enable --now haproxy
$ sudo firewall-cmd --add-service=http --permanent
$ sudo firewall-cmd --add-service=https --permanent
$ sudo firewall-cmd --add-port=6443/tcp --permanent
$ sudo firewall-cmd --add-port=22623/tcp --permanent
$ sudo firewall-cmd --reload

启动后，您的负载均衡器可以接收传入连接并将其重定向到池中的某个成员。

注意

当 OpenShift 控制平面安装完成后，您将收到一条消息，提示可以安全地从负载均衡中移除 Bootstrap；然后，您可以打开 haproxy.cfg 文件，注释或删除引用 Bootstrap 服务器的行，并重启 HAProxy 服务器以应用配置。

防火墙

由于集群涉及到很多组件，因此在考虑 Red Hat OpenShift 与所有集成系统之间的安全性时非常重要。除非您正在处理一个与外界断开的环境（更多详细信息请参阅本章的 进一步阅读 部分），否则您需要从某些 URL 授予对端口 80 和 443 的访问权限。这些 URL 用于下载所需的容器镜像和其他资源。因此，在您的网络防火墙中将以下 URL 列入白名单：

参考

请参考此链接以获取最新的 URL 集合：docs.openshift.com/container-platform/4.9/installing/install_config/configuring-firewall.html。

PXE 服务器

PXE 服务器是一个组件，它能够轻松地让引导过程寻找安装文件。在 PXE 配置期间，您可以创建一个简单的 统一引导加载程序 (GRUB) 菜单，功能与操作系统安装程序完全相同，并包含所有必需的内核参数。

我们将部署一些包来安装 PXE 服务器，创建用于存储配置文件的目录，并开发一个简单而实用的启动菜单。现在，SSH 进入您的堡垒服务器并执行以下操作：

安装这些 syslinux 包：

$ sudo yum install –y syslinux-tftpboot syslinux-nonlinux syslinux tftp-server
$ firewall-cmd --add-service=tftp --permanent
$ firewall-cmd --reload
$ sudo systemctl enable --now tftp

创建以下目录：

$ mkdir -p /var/lib/tftpboot/networkboot/coreOS
$ mkdir -p /var/lib/tftpboot/pxelinux.cfg

复制所需的 PXE 服务器文件，如下所示：
```
$ cp /usr/share/syslinux/* /var/lib/tftpboot
```

复制 Red Hat CoreOS 镜像文件，如下所示（文件可以通过以下链接下载：console.redhat.com/openshift/install/platform-agnostic/user-provisioned）：

├── networkboot
│    └── coreOS
│          ├── rhcos-live-initramfs.x86_64.img
│          ├── rhcos-live-kernel-x86_64
│          └── rhcos-live-rootfs.x86_64.img

最后，创建启动加载程序菜单，以帮助您完成安装：

$ sudo cat <<EOF > /var/lib/tftpboot/pxelinux.cfg/default
UI vesamenu.c32
MENU COLOR sel 4 #ffffff std
MENU COLOR title 0 #ffffff
TIMEOUT 120
PROMPT 0
MENU TITLE OPENSHIFT 4.X AGNOSTIC PXE MENU
LABEL BOOTSTRAP NODE
  KERNEL networkboot/coreOS/rhcos-live-kernel-x86_64 
  APPEND initrd=networkboot/coreOS/rhcos-live-initramfs.x86_64.img,networkboot/coreOS/rhcos-live-rootfs.x86_64.img coreos.inst.install_dev=/dev/sda coreos.inst.ignition_url=http://192.168.1.200:81/ignition/bootstrap.ign 
LABEL MASTER NODE
  KERNEL networkboot/coreOS/rhcos-live-kernel-x86_64 
  APPEND initrd=networkboot/coreOS/rhcos-live-initramfs.x86_64.img,networkboot/coreOS/rhcos-live-rootfs.x86_64.img coreos.inst.install_dev=/dev/sdacoreos.inst.ignition_url=http://192.168.1.200:81/ignition/master.ign 
LABEL  WORKER NODE  
  KERNEL networkboot/coreOS/rhcos-live-kernel-x86_64 
  APPEND initrd=networkboot/coreOS/rhcos-live-initramfs.x86_64.img,networkboot/coreOS/rhcos-live-rootfs.x86_64.img coreos.inst.install_dev=/dev/sdacoreos.inst.ignition_url=http://192.168.1.200:81/ignition/worker.ign 
EOF

现在我们已经正确设置了所有先决组件，可以开始使用 UPI 或通用安装方法进行安装了！那么，开始你的引擎吧！

IPI

尽管我们尽力给你展示了如何创建所有必要的系统和服务器，但这仍然看起来像是一个繁重的过程。需要强调的是，虽然独立准备时可能会很累，但在大型企业中，这些基础设施通常已经在运行，只需要进行一些小的设置调整，就能达到所需的状态。

完成了所有 UPI 安装器的步骤后，你应该已经筋疲力尽了。好消息是，IPI 安装器更容易跟随！你可能已经将 install-config.yaml 文件中的所有必要内容比较过了，然后运行 OpenShift 安装二进制文件来创建集群。

由于 OpenShift 在背后有高度自动化的处理，这一过程相对简单，它使用云 API 根据你在 install-config.yaml 中设置的参数为你创建所有先决条件。显然，不同云平台之间会有一些差异。下面的代码展示了当为 AWS、Azure 和 GCP 准备 install-config.yaml 文件时的两个不同片段：

这是一个 AWS install-config 示例文件：

apiVersion: v1
baseDomain: hybridmycloud.com 
credentialsMode: Mint 
controlPlane: 
  hyperthreading: Enabled 
  name: master
  platform:
    aws:
      zones:
      - us-west-2a
      - us-west-2b
      rootVolume:
        iops: 4000
        size: 500
        type: io1 
        type: m5.xlarge
    replicas: 3
compute: 
  - hyperthreading: Enabled 
  name: worker
  platform:
    aws: 
      rootVolume:
        iops: 2000
        size: 500
        type: io1 
      type: c5.4xlarge
      zones:
      - us-west-2c
    replicas: 3
metadata:
  name: test-cluster 
  networking:
    clusterNetwork:
    - cidr: 10.128.0.0/14
    hostPrefix: 23
    machineNetwork:
    - cidr: 10.0.0.0/16
    networkType: OpenShiftSDN
    serviceNetwork:
    - 172.30.0.0/16
  platform:
    aws:
      region: us-west-2 
      userTags:
      adminContact: jdoe
    costCenter: 7536
    amiID: ami-96c6f8f7 
    serviceEndpoints: 
      - name: ec2
        url: https://vpce-id.ec2.us-west-2.vpce.amazonaws.com
fips: false 
sshKey: ssh-ed25519 AAAA... 
pullSecret: '{"auths": ...}'

接下来，让我们来看一个 Azure install-config 文件的示例：

apiVersion: v1 
baseDomain: hybridmycloud.com 
controlPlane: 
  hyperthreading: Enabled 
  name: master 
  platform: 
    azure: 
      osDisk: 
        diskSizeGB: 1024 
        type: Standard_D8s_v3 
        replicas: 3 
    compute: 
  - hyperthreading: Enabled 
  name: worker 
  platform: 
    azure: 
      type: Standard_D2s_v3 
      osDisk: diskSizeGB: 512 
      zones: 
      - "1" 
      - "2" 
      - "3" 
  replicas: 5 
metadata: 
  name: test-cluster 
  networking: 
  clusterNetwork: 
  - cidr: 10.128.0.0/14 
  hostPrefix: 23 
  machineNetwork: 
  - cidr: 10.0.0.0/16 
  networkType: OpenShiftSDN 
  serviceNetwork:
  - 172.30.0.0/16
platform: 
  azure: 
    BaseDomainResourceGroupName: resource_group 
    region: centralus 
    resourceGroupName: existing_resource_group 
    outboundType: Loadbalancer 
    cloudName: AzurePublicCloud 
pullSecret: '{"auths": ...}'

这里是一个 GCP install-config 示例：

apiVersion: v1
baseDomain: hybridmycloud.com
controlPlane:
  hyperthreading: Enabled
  name: master
  platform:
  gcp:
    type: n2-standard-4
    zones:
    - us-central1-a
    - us-central1-c
  osDisk:
    diskType: pd-ssd
    diskSizeGB: 1024
    encryptionKey:
      kmsKey:
      name: worker-key
      keyRing: test-machine-keys
      location: global
      projectID: project-id
  replicas: 3
compute:
- hyperthreading: Enabled
  name: worker
  platform:
  gcp:
    type: n2-standard-4
    zones:
    - us-central1-a
    - us-central1-c
    osDisk:
    diskType: pd-standard
    diskSizeGB: 128
    encryptionKey:
    kmsKey:
      name: worker-key
      keyRing: test-machine-keys
      location: global
      projectID: project-id
  replicas: 3
metadata:
name: test-cluster
networking:
  clusterNetwork:
  - cidr: 10.128.0.0/14
    hostPrefix: 23
  machineNetwork:
  - cidr: 10.0.0.0/16
  networkType: OpenShiftSDN
  serviceNetwork:
  - 172.30.0.0/16
platform:
gcp:
  projectID: openshift-production
  region: us-central1
pullSecret: '{"auths": ...}'
fips: false
sshKey: ssh-ed25519 AAAA...

做得好！现在你已经拥有了正确的 install-config.yaml 文件，可以与你的云服务提供商一起使用。继续进行安装，使用你偏好的安装方法启动 OpenShift。

准备安装

正如你在前面的部分中看到的，先决条件非常重要，任何错误都可能成为 OpenShift 集群安装和运行的 致命弱点。如果先决条件没有正确准备，会导致集群部署时出现错误，这些错误往往不容易排除并找到根本原因。因此，我们要强调，在开始集群部署之前，正确准备和验证先决条件的重要性。

要使用 UPI 方法启动安装，你需要以下内容：

一个 SSH 密钥对
一个集群的拉取密钥，你可以通过访问 console.redhat.com/openshift/install 并使用有效的用户订阅来生成
OpenShift 安装程序二进制文件
OpenShift 命令行工具
安装配置文件（install-config.yaml）

在接下来的部分中，我们将详细说明所有这些步骤。

一个 SSH 密钥对

从 OpenShift 版本 4 开始，Red Hat 开始使用 Red Hat CoreOS 作为主要操作系统，原因是其容器化和不可变特性。Red Hat CoreOS 需要一些 Ignition 文件来根据配置提供操作系统。这个过程为 OpenShift 节点提供了一种安全可靠的配置方式，允许实现标准的 零接触配置 (ZTP) 过程。

使用 SSH 直接访问节点，并且只能通过分配给用户名coreos的密钥对进行访问（无法使用简单的用户名/密码组合访问节点）。在集群部署过程中，务必保留一份使用的 SSH 密钥对，以便在集群出现问题时直接访问节点收集日志并进行故障排除。这是唯一能够直接访问节点的方式。此外，SSH 密钥对将成为 Ignition 文件的一部分，公钥对将分发到集群的所有节点上。

我们将使用我们的堡垒虚拟机来创建一个 SSH 密钥对，使用以下命令：

$ ssh-keygen -t ecdsa -N '' -f ~/.ssh/clusterOCP_key

在接下来的步骤中，我们将使用一个公钥，例如clusterOCP_key.pub。

重要提示

切勿暴露或共享 SSH 私钥；任何拥有私钥的恶意人员都可能获得节点的根权限，并且凭借一定的知识，能够提升权限为 OpenShift 的cluster-admin用户。

拉取密钥

拉取密钥是一个包含用户名和密码集合的文件，这些用户名和密码经过Base64编码，用于在镜像注册表中进行身份验证，例如quay.io和registry.redhat.io。你需要在console.redhat.com拥有有效的用户名才能下载或复制拉取密钥。

要做到这一点，请完成以下两步：

访问 https://console.redhat.com/openshift/create 并在侧边菜单中访问下载，如下面的图所示：

图 5.3 – 拉取密钥，下载菜单

向下滚动到令牌部分，并点击复制或下载按钮以获取拉取密钥，如下所示：

图 5.4 – 下载或复制拉取密钥

在此页面，你还可以找到命令行、开发工具和安装程序二进制文件下载链接。

OpenShift 安装程序二进制文件

要安装集群，你应该下载安装程序二进制文件，该文件可以从 Red Hat 混合云控制台下载，如图 5.3所示，或者你也可以浏览此处找到的公共仓库：mirror.openshift.com/pub/openshift-v4/x86_64/clients/ocp/latest/。

OpenShift 命令行工具

和安装程序二进制文件一样，你也可以在之前提到的相同公共仓库中下载命令行工具，或者通过你下载拉取密钥的 Red Hat 混合云控制台下载。

OpenShift 命令行工具包括oc和kubectl CLI，你将用它们来管理和运行集群上的命令，一旦集群启动。

安装配置文件（install-config.yaml）

安装的最后一步是创建一个名为install-config.yaml的清单文件。基本上，这个文件包括控制平面、工作节点和网络定义，以及一些元数据，如拉取密钥和公钥。

根据我们之前的配置，以下是可以与安装一起使用的install-config文件示例。你可以在我们的 GitHub 仓库中找到这个文件，路径为chapter05/none-install-config.yaml：

$ mkdir ~/ocp
$ cat <<EOF > ~/ocp/install-config.yaml
apiVersion: v1
baseDomain: hybridmycloud.com # [1]
compute:
- hyperthreading: Enabled 
  name: worker
  replicas: 2 # [2]
controlPlane:
  hyperthreading: Enabled 
  name: master 
  replicas: 3 # [3]
metadata:
  name: ocp # [4]
networking:
  clusterNetwork:
  - cidr: 10.148.0.0/14 # [5]
    hostPrefix: 23 
  networkType: OpenShiftSDN # [6]
  serviceNetwork: 
  - 10.153.0.0/16 # [7]
platform:
  none: {} # [8]
fips: false
pullSecret: '<YOUR-PULL-SECRET>' # [9]
sshKey: '<YOUR-SSH-KEY>' # [10]
EOF

让我们更详细地查看这段代码：

[1]：你的集群的基础域名。需要与前一部分中配置的 DNS 域名匹配。

[2]：你将与集群一起部署的初始工作节点数量。如果你选择的是三节点集群，则该值必须为零。

[3]：你将与集群一起部署的初始主节点数量。对于高可用集群，始终使用三个副本。

[4]：集群名称。它还需要与你在 DNS 中指定的名称匹配。

[5]：将用于 OpenShift SDN 内部 Pods 的 IP 地址块。我们在第二章中探讨了这个概念，架构概述和定义。

OpenShiftSDN或OVNKubernetes。

[7]：将用于 OpenShift SDN 内部网络服务的 IP 地址块。我们在第二章中探讨了这个概念，架构概述和定义。

none。

注意

你还可以使用openshift-installer二进制文件为你将要使用的提供商生成一个示例的install-config.yaml文件。使用以下命令即可：./openshift-install create install-config。

在此文件创建后，你可以继续进行下一个部分的安装步骤。

安装

现在，在部署集群之前需要执行一些进一步的步骤。安装的第一步是创建清单文件。我们强烈建议你在运行以下命令之前备份install-config.yaml文件，因为此命令会删除原始文件，如果你需要重新尝试安装，你将需要重新从头创建该文件：

$ ./openshift-install create manifests --dir=home/user/ocp/

在你喜欢的编辑器中打开~/ocp/manifests/cluster-scheduler-02-config.yml文件。如果你选择的是常规集群，请将mastersSchedulable参数设置为false；如果你决定配置一个三节点集群，则设置为true。

现在，你应该通过运行以下命令来生成 Ignition 文件：

$ ./openshift-install create ignition-configs --dir=home/user/ocp/

执行前面的命令后，你应该会得到三个新的 Ignition 文件：bootstrap.ign、master.ign和worker.ign。

将这三个文件复制到你在前一部分准备好的 HTTP 服务器中：

$ sudo cp ~/ocp/*.ign /var/www/html/ignition
$ sudo chown -R apache. /var/www/html
$ sudo chmod 744 /var/www/html

最后，你可以继续进行节点的配置。

阶段 1 – 配置服务器

首先，你需要配置服务器。具体过程会根据底层基础设施有所不同，但一般来说，虚拟化环境（例如 VMware、vSphere 和 RHV）的过程如下：

将 Red Hat CoreOS 模板导入到虚拟化管理程序中。
克隆该文件并根据提供商配置虚拟机参数。

另一方面，裸金属或无关安装的过程可以通过使用 Red Hat CoreOS ISO 或通过 PXE 启动来执行。

在我们的实验室中，我们将使用 Red Hat CoreOS ISO 启动。按照以下步骤进行：

从console.redhat.com下载 ISO 文件，如前所述，或者直接通过此链接：mirror.openshift.com/pub/openshift-v4/dependencies/rhcos/latest/rhcos-live.x86_64.iso。
在 Bastion 虚拟机中，运行以下命令以获取 Ignition 文件的SHA512摘要（这将在从 ISO 启动后用于验证文件的真实性）：
```
$ sha512sum ~/ocp/bootstrap.ign
$ sha512sum ~/ocp/master.ign
$ sha512sum ~/ocp/worker.ign
```

这是输出的示例：

a5a2d43879223273c9b60af66b44202a1d1248fc01cf156c46d4a79f552b6bad47bc8cc78ddf0116e80c59d2ea9e32ba53bc807afbca581aa059311def2c3e3b installation_directory/bootstrap.ign

使用 ISO 镜像启动，但在看到 shell 提示符之前，不要指定任何选项。

运行以下coreos-installer命令以启动 Ignition 过程，从而进行操作系统的配置：

$ sudo coreos-installer install --ignition-url= http://192.168.1.200:81/ignition/bootstrap.ign /dev/sda --ignition-hash=SHA512-
a5a2d43879223273c9b60af66b44202a1d1248fc01cf156c46d4a79f552b6bad47bc8cc78ddf0116e80c59d2ea9e32ba53bc807afbca581aa059311def2c3e3b

对每台服务器重复相同的过程，始终遵循coreos-installer命令的以下格式：

$ sudo coreos-installer install --ignition-url=http://192.168.1.200:81/<node_type>.ign <device> --ignition-hash=SHA512-<digest>

其中，<node_type>可以是bootstrap.ign、master.ign或worker.ign，<device>是用于安装操作系统的磁盘（例如/dev/sda），<digest>是先前提到的sha512sum命令的结果。

使用此程序启动引导和主节点后，您可以继续下一步，监控安装进度。

第 2 阶段 – 启动引导和控制平面

在此阶段，Bootstrap 将下载容器镜像，以提供控制平面组件。每个主节点中的容器启动后，控制平面组件将开始自我配置，直到 OpenShift 的etcd集群、API 和控制器同步。

从 Bastion 虚拟机运行以下命令，监视引导和控制平面部署的进度：

./openshift-install wait-for bootstrap-complete --dir= /home/user/ocp/ --log-level=debug

在命令触发后，您将在控制台上看到一些日志消息，类似于以下示例：

INFO Waiting up to 30m0s for the Kubernetes API at https://api.ocp.hybridmycloud.com:6443... INFO API v1.22.1 up INFO Waiting up to 30m0s for bootstrapping to complete... INFO It is now safe to remove the bootstrap resources

之后，您必须从负载均衡器中移除 Bootstrap 并重新启动haproxy服务。

注意

请记住，Bootstrap 服务器只能使用一次；因此，您可以完全从基础设施提供商处销毁 Bootstrap 服务器，因为即使集群安装过程中发生错误，它也不会再被使用。

第 3 阶段 – 检查待签名的证书 – 仅适用于 UPI 和无关安装

当引导过程完成后，Red Hat OpenShift 容器平台会为每个节点创建一系列证书签名请求（CSRs）。在我们的规划中，我们尝试为两个工作节点提供服务，因此我们必须接受证书以将工作节点加入集群。

我们需要使用oc客户端来批准证书。为此，请运行以下命令来导出kubeadmin凭据并访问集群：

$ export KUBECONFIG=~/ocp/auth/kubeconfig

通过一个简单的命令，可以列出待批准的证书并批准它们，直到没有待批准证书为止：

$ oc get csr | grep –i Pending 
NAME      AGE   REQUESTOR                             CONDITION 
csr-bfd72 5m26s system:node:worker0.ocp.hybridmycloud.com   Pending 
csr-c57lv 5m26s system:node:worker1.ocp.hybridmycloud.com   Pending 
...

然后，为了批准证书，请运行以下命令：

$ oc get csr -o name | xargs oc adm certificate approve
certificatesigningrequest.certificates.k8s.io/csr-bfd72 approved
certificatesigningrequest.certificates.k8s.io/csr-c57lv approved

为确认一切正常，请运行以下命令，直到所有节点保持Ready状态：

$ oc get nodes
NAME                        STATUS   ROLES    AGE   VERSION
ocp-7m9wx-master-0       Ready    master   77d   v1.21.1+9807387
ocp-7m9wx-master-1       Ready    master   77d   v1.21.1+9807387
ocp-7m9wx-master-2       Ready    master   77d   v1.21.1+9807387
ocp-7m9wx-worker-jds5s   Ready    worker   77d   v1.21.1+9807387
ocp-7m9wx-worker-kfr4d   Ready    worker   77d   v1.21.1+9807387

第 4 阶段 – 完成安装

我们的 UPI/平台无关安装接近尾声！现在，我们必须检查集群操作员，确保它们都可用。

使用以下命令，你将能够监控集群操作员的部署进度：

./openshift-install wait-for install-complete --dir= /home/user/ocp/ --log-level=debug
INFO Waiting up to 30m0s for the cluster to initialize...

当安装完成时，你将收到 kubeadmin 密码，最终可以访问你的 OpenShift 集群。

重要提示

kubeadmin 是一个具有 cluster-admin 权限的临时用户。强烈建议你在设置新的身份提供者后尽快移除 kubeadmin 用户，并将适当的 cluster-admin 权限赋予集群管理员。

现在，你可以使用你喜欢的浏览器访问 OpenShift 控制台 GUI。为此，浏览至 console-openshift-console.apps.ocp.hybridmycloud.com 并输入 kubeadmin 凭证：

图 5.5 – 访问控制台 UI

然后，放松并享受：

图 5.6 – 控制台 UI

恭喜！你成功部署了一个 OpenShift 集群！庆祝你的巨大成功，但请记住，你的旅程才刚刚开始！

接下来是什么？

现在，OpenShift 已经具备基本功能，这意味着你有一个可以调度 pods、处理 API 调用和控制器的控制平面，以及一个 etcd 集群，它为集群中的对象提供键/值存储。你还拥有一些已完全功能化的工作节点，能够承载一些工作负载。

但这还不是全部！现在，开始进入需要配置的活动（也称为第 2 天，或安装后活动）。在接下来的几章中，我们将讨论 Ingress 配置、网络、注册表配置、本地卷视图和持久卷。

我们还将讨论污点和容忍度、安全性及最佳实践——一切你需要的知识，帮助你从零到英雄，开始进行更复杂的实现。

常见问题解答

在部署阶段，无论你进行什么样的安装，遇到无法按预期工作的情况是常见的。我们将看看你在部署过程中可能遇到的一些错误案例。

为什么 openshift-install 执行时卡住，等待 API？

将显示以下消息：

Message: "INFO Waiting up to 20m0s for the Kubernetes API at https://api.ocp.hybridmycloud.com:6443..."

有时候，INFO信息可能会造成大麻烦。在这种情况下，即使你增加消息的调试级别，也不会得到很多输出以供排查。此时，你应该查看以下一些选项：

查找 API URL，并检查 DNS 解析；查询必须返回 install-config.yaml 中的 API IP。
尝试分别 ping 测试三个主节点，以确保它们已启动。
UPI 安装：检查虚拟化程序 VM 终端是否所有主节点都已启动并运行，并且位于登录提示屏幕上。启动菜单上的主节点或登录提示屏幕的任何其他不同情况可能会导致 API 等待消息。
IPI 安装：检查与前提条件相关的云凭证和权限。你的凭证可能没有创建对象所需的所有权限。不要为集群服务用户分配管理员权限，因为安装过程中会查找特定的权限名称。你可以根据云服务提供商（例如 VMware vCenter）在 docs.openshift.com/container-platform/4.9/installing/installing_vsphere/installing-vsphere-installer-provisioned.html 查看角色和权限表。

超时安装等待 Bootstrap 完成

将显示以下消息：

Message: "INFO Waiting up to 30m0s for bootstrapping to complete..."

当 openshift-install 二进制文件在等待 Bootstrap 过程完成时冻结，意味着它正在等待某些集群操作符变为可用。在这种情况下，执行以下操作：

检查是否有足够的工作节点（至少两个），以使 Ingress 操作符可用。
使用 SSH 登录到工作节点，检查 crictl 进程是否仍在创建 pod。
使用 SSH 登录到工作节点，并使用 journalctl 守护进程搜索与 kube-apiserver、kubelet、podman 或 crictl 相关的错误。

集群部署期间的 X509 消息

将显示以下消息：

Message: "x509 certificate signed by unknown authority.."

在创建 Ignition 文件时，OpenShift 会自动创建一个自签名证书，该证书将在集群内的每个 API 调用中进行验证。然而，即使你已经正确完成了所有前提步骤，有时也会遇到类似 x509 的消息，导致安装过程失败并未达到预期结果。尝试检查以下选项：

VSphere IPI 安装：确保你已从将扩展 OpenShift 到机器并启动集群安装的集群中导入 VMware CA 证书。
master.ign 中没有与负载均衡器上配置的 CA 证书相同的证书，该负载均衡器必须在 api-int 中响应。此外，验证外部负载均衡器是否已配置为使用第 4 层/TCP/透传。

openshift-install 创建的证书存储在 master.ign 中，有效期为 24 小时，且无法更新。如果你在前一天尝试安装且未成功，请删除安装目录，并重新开始创建清单和 Ignition 文件。

概要

在本章中，我们已经研究了一些安装和配置 OpenShift 容器平台解决方案的选项。从公共云到本地部署，我们涵盖了 UPI、IPI 和无关平台的实现方法。

现在你已经了解了公共云提供的完全支持的实现和文档，帮助你启动集群。

我们邀请你深入了解如何让你的 OpenShift 集群更强大、更可靠，并尽可能安全。我们鼓励你继续阅读下一章，和我们一起学到更多。

进一步阅读

如果你想查看更多与本章中概念相关的信息，请参考以下资料：

断开连接安装过程的安装指南: docs.openshift.com/container-platform/latest/installing/installing-mirroring-installation-images.html
OpenShift 容器平台 4.x: 由 Red Hat 和合作伙伴测试的集成：access.redhat.com/articles/4128421
OpenShift 容器平台 IPI: x509 证书由未知机构签名: access.redhat.com/solutions/5203431
OpenShift 容器平台裸金属: x509 证书由未知机构签名：access.redhat.com/solutions/4271572

第六章：6

OpenShift 故障排除、性能与最佳实践

第五章中解释的概念，OpenShift 部署，为你与 OpenShift 集群的首次接触提供了基础。在本章中，我们将给出一些如何执行集群健康检查的建议，深入分析一些根本原因分析（RCA），并提供一些让集群按照最佳实践运行的详细信息。我们在本章中的目的是为你提供一些关于故障排除的通用指导，但在进行任何更改之前，尤其是出于故障排除的目的，始终建议你向 Red Hat 提交支持票。

本章涵盖以下主题：

可能导致集群崩溃的因素
故障排除参考指南——如何开始
理解误导性的错误信息

注意

本章使用的源代码可以在github.com/PacktPublishing/OpenShift-Multi-Cluster-Management-Handbook/tree/main/chapter06找到。

可能导致集群崩溃的因素

每当我们开始学习某项技术时，通常会特别小心安装、配置或调整，以尽可能做到全面。有时，为了实现这些与故障排除、性能和最佳实践相关的目标，读者可能会转向多篇专家文章，或者经历不断试错的痛苦，这需要付出大量的努力才能成功。

OpenShift 是一项伟大且颠覆性的技术，但你将会面对与存储、计算、网络等相关的各种复杂问题。显然，在官方文档中——或者甚至在快速的互联网搜索中——你会找到从零开始的命令，但在许多情况下，即使有了必要的命令和参数，仍然很难从故障排除到达解决方案。

目前，OpenShift 有一个自动恢复系统，但这通常不足以确保环境的稳定。为了让这种自我修复成功发生，必须首先检查集群中的许多前提条件。因此，在我们理解可能导致崩溃的因素之前，让我们先了解一下这种自我调整机制是如何工作的。

运维人员

在技术世界中，有许多角色，部分角色与基础设施的管理相关。这个角色有很多名称，最常见的仍然是系统管理员，或称sysadmin，他们负责操作信息技术（IT）基础设施中的服务器和服务。同样，OpenShift 也有操作员，他们其实就是用于监控平台行为并维持操作的应用程序。

操作员是如何工作的？操作员被指定来完成维护应用程序及其所有组件的单一任务，遵循一个标准。要理解的是，操作员对于所有应用程序并不相同——即，操作员是独特的，每个操作员都有其独特的参数定义、必需和可选配置等。

操作员参数的契约在自定义资源定义（CRD）中描述。CRD 是一种扩展 Kubernetes 应用程序编程接口（API）功能的定义，它为集群提供了更多的灵活性，以便存储特定类型的对象集合。一旦定义了 CRD，你就可以创建一个自定义资源（CR），这将允许你将 Kubernetes 的自定义 API 添加到集群中。

操作员是保持集群或应用健康的工具，那么既然 OpenShift 可以自我修复，为什么我们还要关心 OpenShift 故障排除？的确，操作员是一个强大的工具，但正如我们之前提到的，OpenShift 是一个复杂的拼图，只有各个部分完美地拼接在一起，它才能正常工作。尽管它由准备好维护其完整性的操作员管理，但故障仍然可能发生，集群管理员的角色和他们解决问题的经验将有助于保持所有这些操作员的健康。

在接下来的章节中，我们将深入探讨 OpenShift 的主要组件以及需要关注的方面。

etcd

在 OpenShift 集群中，etcd 是一个分布式键值服务，负责存储集群的状态。通过它，集群中包含的所有对象以键值格式展示，因此在这个服务中，作为控制平面操作核心的组件，有三个重要因素需要考虑。请注意以下几点：

etcd 对基础设施的延迟和带宽高度敏感。
etcd 需要分布在所有主节点上——也就是说，要实现高可用，OpenShift 集群基础设施要求此服务分布在三个主节点上。
与许多高可用（HA）服务不同，在这些服务中你有一个主服务器和一个备用服务器，etcd 的概念是基于法定人数成员和领导权。

Red Hat 通过将主节点数量默认为3并使用一个管理 etcd 并报告其问题的集群操作员，使得 etcd 的复杂性变得更加简易；然而，若发生任何复杂问题，你仍然需要理解 etcd 的工作原理，以便进行故障排除。继续学习如何实现基于法定人数和领导者的 etcd 算法。

法定人数和基于领导者的方案是如何工作的？

Etcd 集群工作在领导者和跟随者的概念上，这被称为Raft 分布式共识协议。该协议实现了基于领导者选举的算法，以在整个 etcd 集群的所有成员之间建立分布式共识。一旦成员被添加到 etcd 集群并选出领导者，进程只需要定期发送心跳以确认领导者在合适的延迟时间内仍然响应。

如果在未答复的心跳时间范围内，成员开始新的选举以保证集群的弹性、自愈和服务的连续性。

建议 etcd 集群具有奇数节点数量，以便以下公式保证给定数量失败成员的容忍度。我们称之为法定人数：

法定人数 = (n/2)+1，其中“n”表示成员数量。

为了保持正常运行，集群必须始终至少具有法定人数的成员。为了明确起见，让我们查看一些场景，如下所示：

场景 1：三成员集群，全部运行中，如下图所示：

图 6.1 – 健康的 etcd 集群（三节点成员健康）

分析：法定人数是 OK 的，因为有大多数工作成员并确保领导权，所以集群是健康的。

场景 2：三成员集群中有两个成员工作，如下图所示：

图 6.2 – 健康的 etcd 集群（两节点成员健康；风险停机）

分析：法定人数是 OK 的，因为有大多数工作成员并确保领导权。如果再有一个节点中断，存在降级风险，但集群是健康的。

场景 3：三成员集群中有一个成员工作，如下图所示：

图 6.3 – 降级的 etcd 集群（一个节点成员健康；不健康的集群）

分析：由于大多数成员宕机，无法再选出新的领导者，集群降级。

故障排除 etcd

如前所述，OpenShift 由其运算符管理，这些运算符可以提供标准化、自愈和活动指标，但这并不总能保持集群完全功能。

由于与任何基础架构层相关的不同因素，可能会发生诸如场景 2 和 3 的情况。重要的是进行深入分析以将集群恢复到功能状态。以下是故障排除 etcd 的方法。

在故障排除时，重要的是考虑集群遇到的中断类型。如果我们仍然能够使用 OpenShift API 访问节点，则可以使用第一种方法。否则，如果 API 不可用，则必须参考第二种情境。

情境 1 – etcd 成员降级

在仍然可以执行oc或kubectl命令的情况下，使用rsh命令进入 etcd pod，通过etcdctl执行以下步骤是最快的方式。

etcd 降级可能由多种原因引起，例如存储或网络故障、主节点的在线迁移，甚至是操作系统（OS）的操作，这些都可能导致集群的即时中断。

如前所述，运行以下命令打开 etcd pod 中的终端并识别故障：

$ oc project openshift-etcd
$ oc get pods -n openshift-etcd | grep -v etcd-quorum-guard | grep etcd
etcd-ocp-master-0 3/3 Pending 0 14m
etcd-ocp-master-1 3/3 CrashLoopBackOff 6 17m
etcd-ocp-master-3 2/3 Running 0 9m11s

注意，在之前的输出中，三台主节点中的两台出现了问题，所以我们需要rsh进入master-3，进行备份，并重新创建 etcd 节点，具体步骤如下：

oc rsh etcd-ocp-master-3
Defaulting container name to etcdctl.
Use 'oc describe pod/etcd-ocp-master-3 -n openshift-etcd' to see all of the containers in this pod.
sh-4.4# etcdctl member list -w table
+------+------+------+------+------+------+
| ID | STATUS | NAME | PEER ADDRS | CLIENT ADDRS | IS LEARNER +------+------+------+------+------+------+
| 5bdacda4e0f48d91 | failed | ocp-master-1 | https://192.168.200.235:2380 | https://192.168.200.235:2379 | false |
| b50b656cba1b0122 | started | ocp-master-3 | https://192.168.200.14:2380 | https://192.168.200.14:2379 | false |
| cdc9d2f71033600a | failed | ocp-master-0 | https://192.168.200.234:2380 | https://192.168.200.234:2379 | false |
+------+------+------+------+------+------+
sh-4.4# etcdctl endpoint status -w table
+------+------+------+------+------+------+
| ENDPOINT | ID | VERSION | DB SIZE | IS LEADER | IS LEARNER | RAFT TERM | RAFT INDEX | RAFT APPLIED INDEX | ERRORS |
+------+------+------+------+------+------+
| https://192.168.200.14:2379 | b50b656cba1b0122 | 3.4.9 | 136 MB | true | false | 281 | 133213554 | 133213554 | |
| https://192.168.200.234:2379 | cdc9d2f71033600a | 3.4.9 | 137 MB | false | false | 281 | 133213554 | 133213554 | |
| https://192.168.200.235:2379 | 5bdacda4e0f48d91 | 3.4.9 | 136 MB | false | false | 281 | 133213554 | 133213554 | |
+------+------+------+------+------+------+

一旦确定了故障成员的标识符（IDs），下一步是移除 etcd 成员，留下唯一运行并作为集群一部分的节点。为此，首先运行 etcd 的备份，如下所示：

/usr/local/bin/cluster-backup.sh /home/core/assets/backup

注意

etcd 备份将保存在与 etcd pod 所在节点相同的core用户的home目录中。强烈建议你将其复制到节点外的位置，以避免丢失访问节点的风险，从而丢失 etcd 备份文件并使集群恢复处于风险中。

现在你已经识别出 etcd 集群的问题，接下来查看建议的步骤来恢复你的集群。

如何解决这个问题？

以前，在 OpenShift 3 版本中，解决这两种情况的常见方法是通过备份重新建立 etcd 集群。现在，在 OpenShift 4 中，您可以更轻松地在基础设施中配置新的主节点。也就是说，如果你的问题属于第一种情况（API 仍然可用）并且你的安装是安装程序配置基础设施（IPI）方法，我们建议你采取以下步骤，使用新的节点名称重新创建有问题的主节点：

通过运行以下命令获取当前主节点的YAML Ain’t Markup Language（YAML）机器描述符：

oc get machine <master-node> \
    -n openshift-machine-api \
    -o yaml \
    > new-master-machine.yaml

YAML 文件应如下所示：

new-master-machine.yaml
apiVersion: machine.openshift.io/v1beta1
kind: Machine
metadata:
  finalizers:
  - machine.machine.openshift.io
  labels:
    machine.openshift.io/cluster-api-cluster: ocp-sgw5f
(.. omitted ..)
  name: ocp-master-4
  namespace: openshift-machine-api
  selfLink: /apis/machine.openshift.io/v1beta1/namespaces/openshift-machine-api/machines/ocp-master-4
spec:
  metadata: {}
  providerSpec:
    value:
      apiVersion: vsphereprovider.openshift.io/v1beta1
      credentialsSecret:
        name: vsphere-cloud-credentials
      diskGiB: 120
      kind: VSphereMachineProviderSpec
(.. omitted ..)

在 YAML 文件中进行必要的更改以配置新的主节点，如下所示：
1. 移除以下部分或字段：
2. 整个status、metadata.annotations和metadata.generation部分。
3. 删除metadata.resourceVersion、metadata.uid和spec.providerId字段。
II. 将metadata.name字段更改为新名称（例如，<clustername>-<clusterid>-master-3）。
1. 还需要更新metadata.selfLink字段中的节点名称。

使用以下命令删除有问题的主节点：

$ oc delete machine <problematic-master-node-name> -n openshift-machine-api

使用以下命令来监控删除过程并确认已删除：
```
$ oc get machines -n openshift-machine-api -o wide
```
一旦有问题的主节点被删除，你现在可以使用我们之前准备好的 YAML 文件配置一个新的主节点。为此，运行以下命令：
```
oc apply –f new-master-machine.yaml
```

注意

如有必要，重复此过程，仅更改metadata.name和metadata.selfLink字段，以应对集群中每个有问题的主节点。

在新的主节点配置完成后，观察以下步骤以验证 etcd 集群是否健康：

检查所有 etcd Pod 是否正在运行，具体如下。你必须看到三个 Pod 在运行：
```
$ oc get pods -n openshift-etcd | grep -v etcd-quorum-guard | grep etcd
```
有些情况下，etcd Pod 不会在主节点配置时自动部署。如果你没有看到三个 Pod 在运行，你可以运行以下命令强制 etcd 操作员在新节点中部署 etcd Pod：
```
$ oc patch etcd cluster -p='{"spec": {"forceRedeploymentReason": "recovery-'"$( date --rfc-3339=ns )"'"}}' --type=merge
```

现在，让我们从 etcd 集群内部检查它是否按预期工作。为此，运行以下命令在其中一个 etcd Pod 内打开终端：

# Get the name of one etcd pod
$ oc get pods -n openshift-etcd | grep -v etcd-quorum-guard | grep etcd
$ oc rsh <etcd-pod-name> -n openshift-etcd

现在，检查集群成员列表，如下所示：
```
etcdctl member list -w table
```
在某些情况下，你仍然会看到我们已经移除的有问题的 etcd 节点作为集群成员。因此，如果前一个命令显示成员超过三个，请使用以下命令移除不正常的 etcd 成员：
```
$ etcdctl remove <member-id>
```

场景 2 - 集群 API 故障

如果 OpenShift API 故障，执行任何操作时需要更加谨慎，以避免对集群造成不可逆的损失。在这种情况下，你无法使用rsh命令，无法通过oc logs获取日志，也无法使用任何oc或kubectl命令，因为这些命令都依赖于 OpenShift API，这使得故障排除和找到解决方案变得更加困难和复杂。

因此，必须在集群发生故障之前定期进行 etcd 备份。如果没有之前的备份，第一步是对正在运行的节点进行直接备份。为此，请按以下步骤操作：

运行以下命令：

$ ssh -i ~/.ssh/id_rsa core@ocp-master-3

通过运行crictl命令检查 etcd 状态，如下所示：
```
$ sudo crictl | grep –i etcd
```

获取 etcd Pod ID，运行crictl exec命令以识别集群节点的状态，具体如下：

$ crictl exec bd077a3f1b211 etcdctl member list -w table
+---+---+---+---+---+---+
| ID | STATUS | NAME | PEER ADDRS | CLIENT ADDRS | IS LEARNER |
+---+---+---+---+---+---+
| 9e715067705c0f7c | unknown | ocp-master-4 | https://192.168.200.15:2380 | https://192.168.200.15:2379 | false |
| b50b656cba1b0122 | started | ocp-master-3 | https://192.168.200.14:2380 | https://192.168.200.14:2379 | false |
| cdc9d2f71033600a | failed  | ocp-master-0 | https://192.168.200.234:2380 | https://192.168.200.234:2379 | false |
+---+---+---+---+---+---+

注意，etcd 成员不可达，除了一个处于启动状态的成员。通过前往该节点并运行备份命令，进行备份，具体如下：
```
sudo /usr/local/bin/cluster-backup.sh /home/core/assets/backup
```

使用crictl获取 etcd 的 Pod ID，运行以下命令以识别集群节点及其状态：

$ crictl exec bd077a3f1b211 etcdctl endpoint status -w table
+-------+-------+-------+-------+-------+-------+
| ENDPOINT | ID | VERSION | DB SIZE | IS LEADER | IS LEARNER | RAFT TERM | RAFT INDEX | RAFT APPLIED INDEX | ERRORS |
+-------+-------+-------+-------+-------+-------+
| https://192.168.200.14:2379 | b50b656cba1b0122 | 3.4.9 | 136 MB | true | false | 491 | 133275501 | 133275501 | |
| https://192.168.200.15:2379 | 9e715067705c0f7c | 3.4.9 | 137 MB | false| false | 491 | 133275501 | 133275501 | |
+-------+-------+-------+-------+-------+-------+

在此阶段，可以得出一些结论。我们理解保持集群运行不需要最低法定人数，因此 API 变得不可用。接下来，请继续查看如何在这种情况下进行操作的建议。

如何解决？

一般来说，在这种情况下，要恢复集群，你将使用命令etcdctl member remove来移除所有有问题的 etcd 成员，然后按照我们在之前的如何解决？部分中描述的步骤移除有问题的主节点并配置新的节点。然而，故障排除集群在这种情况下要更具挑战性，建议与 Red Hat 支持团队合作，找到恢复的最佳方法。

既然我们已经讨论了 etcd 故障排除，现在让我们讨论它的另一个重要方面：性能分析。

etcd 性能分析

Kubernetes 集群对延迟和吞吐量非常敏感。因此，必须采取一些预防措施，以确保集群稳定并提供优异的性能。OpenShift 是一个为高可用性（HA）设计的平台，因此，etcd 的使用和消耗是流量密集型的。因此，遵循一些最佳实践以保持集群的稳定非常重要。让我们来看一些推荐的配置。

存储

etcd 的磁盘使用非常密集，因此建议使用固态硬盘（SSD）来实现快速的读/写响应时间。关于响应时间，我们可以说 50 次顺序输入/输出操作每秒（IOPS）是最低要求，但根据我们的经验，OpenShift 的使用会非常快速地增长，因此建议考虑能够提供至少 500 个并发 IOPS 的磁盘，以维持集群的健康和稳定。然而，请注意，某些提供商不发布顺序 IOPS 值，只发布共享 IOPS。在这种情况下，可以认为并发 IOPS 值等于顺序 IOPS 值的 10 倍。

这是一个如何使用定制版fio工具测量 etcd 磁盘性能的示例。在 OpenShift 集群中，运行debug命令来访问主节点，如下所示：

$ oc debug node/master1.ocp.hybridcloud.com

一旦命令执行完毕，以下信息将会显示。在 shell 之后执行chroot命令，以便在特权模式下执行命令：

Starting pod/ocp-master1hybridcloud-debug ...
 To use host binaries, run `chroot /host`
 chroot /host
Pod IP: 172.19.10.4
 If you don't see a command prompt, try pressing enter.
 sh-4.4# chroot /host
 sh-4.4#

创建一个容器，如下方代码片段所示。启动etcd-perf容器后，它将自动运行性能检查：

sh-4.4# podman run --volume /var/lib/etcd:/var/lib/etcd:Z quay.io/openshift-scale/etcd-perf Trying to pull quay.io/openshift-scale/etcd-perf:latest...
Getting image source signatures
(.. omitted ..)
------- Running fio ------{
"fio version" : "fio-3.7",
"timestamp" : 1631814461,
"timestamp_ms" : 1631814461780,
"time" : "Thu Sep 16 17:47:41 2021",
"global options" : {
"rw" : "write",
 "ioengine" : "sync",
"fdatasync" : "1",
 "directory" : "/var/lib/etcd",
"size" : "22m", [1]
"bs" : "2300" }, [2]
(.. omitted ..)
"write" : {
"io_bytes" : 23066700,
"io_kbytes" : 22526,
"bw_bytes" : 1319077,
"bw" : 1288, [3]
"iops" : 573.511752, [4]
(.. omitted ..)
"read_ticks" : 3309,
"write_ticks" : 29285,
"in_queue" : 32594,
"util" : 98.318751
} ]
}
---------
99th percentile of fsync is 5406720 ns
99th percentile of the fsync is within the recommended threshold - 10 ms, the disk can be used to host etcd [5]

在前面的代码片段中，我们使用了以下注释：

[1]: 22 兆字节（MB）的块大小通常足以分析性能结果。

[2]: 与使用 4k 块大小不同，etcd 使用小块的 2.3k 块大小，因此它能够保证性能，包括处理小的写入碎片。

[3]: 考虑到节点与底层存储之间的流量，所需的带宽。建议至少使用 1 千兆字节（GB）的网络接口。对于中型和大型集群，推荐使用 10 GB 的接口。

[4]: 推荐至少 500 个并发 IOPS，如前所述。

[5]：etcd IO 检查报告。在示例中，5.40 毫秒（ms）展示了可靠的性能——为了达到此标准，必须低于 10 毫秒。

除了使用etcd-perf检查磁盘性能外，您还可以根据需要完美地使用自定义参数，如块大小、块段大小等，使用fio二进制工具，该工具可通过标准的 Red Hat 包管理器获取（例如，执行 yum/dnf install fio）。

注释

出于教学目的，我们省略了一些结果，只保留了与我们分析相关的项。

etcd 规模化

为了避免与中央处理单元（CPU）相关的任何问题，您必须了解您的集群是否经过了良好的规模化。您需要考虑一些因素来检查集群规模化情况，如使用平台的客户数量、每秒请求的预期数量，以及为 etcd 提供的存储量。

首先，让我们为您的集群大小提供一些需要考虑的参数：

下表展示了根据集群大小关联的 CPU、内存、磁盘 IOPS 和带宽等参数，使用公共云和本地基础设施的一些用例：

总而言之，当您为集群进行规模化时，应该考虑这些阈值，因为这已由 etcd 社区进行了基准测试，如果遵循这些建议，它们的性能可能会是可接受的。关于 etcd 集群规模化的进一步信息，可以在本章的 进一步阅读 部分提供的链接中找到。

在这一部分，您已经看到了一些检查 etcd 性能和故障排除的方法，同时也获得了一些关于规模化最佳实践的重要信息。我们希望您喜欢这种方法，并且仔细查看接下来关于身份验证的部分，这将是另一个有趣的主题。

身份验证

OpenShift 集群的另一个重要方面是用户身份验证和授权流程。OpenShift 的灵活性和易用的身份验证插件是设置用户和组的智能方式。OpenShift 的身份验证服务可以通过多种方式验证用户——我们称之为身份提供者（IdP）。通过这种方式，OpenShift 负责信任 IdP，并根据提供者来允许或拒绝身份验证。在下图中，您可以看到验证用户的过程是如何工作的：

图 6.4 – 身份验证和授权流程

IdP 负责通知 OpenShift 用户名和密码是否有效，并将成功或失败的身份验证状态返回给 OpenShift。这个过程被称为身份验证（在一些文献中称为AuthN）。

我们提到过，身份验证过程使用 IdP 来验证用户与身份验证提供者的匹配，但更重要的是，你需要理解授权（也称为AuthZ）是如何发生的。最初，OpenShift 上的用户在任何项目中都没有任何权限；然而，他们可以登录。除非集群启用了自我创建者角色，否则他们无法执行任何任务，只能创建自己的新项目（自我创建者是一种允许任何已登录用户创建自己项目的角色）。要为用户添加权限，需要指派适当的角色。这可以通过将用户添加到用户组或直接分配给用户来实现。将角色分配给用户或组的过程被称为RoleBindings。

为了更好地了解哪个角色最适合某个用户或组，可以查看在 OpenShift 集群中已存在的默认角色，如下所示：

admin—这是一个项目管理员角色。它允许对所有项目范围内的资源进行修改，包括使用 ClusterRoles 创建 RoleBindings 的能力。它不允许修改配额、限制或集群资源。
edit—这是一个项目编辑器。它允许使用和操作所有项目范围内的资源，但不能更改授权对象。
view—这是一个项目查看器。它允许查看项目范围内的资源，类似于只读的 RoleBinding。禁止查看秘密信息。
cluster-admin—这是类 Unix 操作系统中的 root 用户的等价物。它允许对整个集群中的任何资源进行完全控制。
cluster-reader—这个角色对特别用户特别有用，尤其是那些负责集群监控的用户。该 RoleBinding 是只读的，不允许用户提升权限或操纵集群中的对象。

你还需要理解 RoleBinding 的作用范围，它可以是以下之一：

将edit角色分配给项目Z中的用户X。创建本地 RoleBindings 就像运行以下命令一样简单：
```
$ oc adm policy add-role-to-user <role> <user> -n <project>
```
将cluster-admin角色分配给用户X。要创建一个集群 RoleBinding，可以运行以下命令：
```
$ oc adm policy add-cluster-role-to-user <role> <user>
```

相似的命令也可以应用于组，只需将user替换为group（例如，add-role-to-group和add-cluster-role-to-group）。同样，要从用户或组中删除角色，使用remove-role-from-user/group，如下所示：

$ oc adm policy remove-role-from-user <role> <user> -n <project>
$ oc adm policy remove-role-from-group <role> <group> -n <project>
$ oc adm policy remove-cluster-role-from-user <role> <user>
$ oc adm policy remove-cluster-role-from-group <role> <group>

这些是与 OpenShift 一起使用的最常见的默认角色，但如果需要，你可以创建自定义角色。要创建自定义角色，你需要首先了解什么是动词和资源，以下是这些术语的定义：

get、list、create、update等。
pod、deployment、service、secret等。

也就是说，要定义自定义角色，你需要知道哪些动词可以让用户或组在哪些对象上执行。定义了动词和资源后，可以使用以下命令创建角色：

$ oc create role <role-name> --verb=<verbs-list> --resource=<resources-list>

看一下以下示例：

$ oc create role sample --verb=get,list,watch --resource=pods,pods/status

关于 OpenShift 的认证和授权，还有许多内容我们这里不打算详细介绍。我们尝试突出一些你需要了解的重要方面，并在本章的进一步阅读部分留下了一些链接，如果你希望更深入地了解这个话题，可以查阅。

通过这个步骤，我们已经稍微揭开了认证过程的神秘面纱，现在你可以执行AuthN和AuthZ的过程。前面的图表展示了认证过程步骤的一个简要视角。为每个用户或用户组授予适当的权限非常重要，而更重要的是要规划你需要为用户和用户组分配的角色，以便赋予他们执行工作所需的适当权限。在接下来的部分中，我们将讨论 OpenShift 运维人员需要了解的另一个重要方面：故障排除。

故障排除参考指南 – 如何开始

在本节中，你将看到一些故障排除 OpenShift 集群的方法，如果你遇到任何问题。由于oc 命令行界面（CLI）的强大功能，你将有多种方式来解决几乎所有的 OpenShift 集群故障排除场景。通过培训，你将积累经验，进一步提高使用和故障排除 OpenShift/Kubernetes 集群的能力。

描述对象

正如我们提到的，oc CLI 是一个强大的工具，可以帮助 OpenShift 用户进行多种操作，并且进行故障排除。故障排除的第一步之一是获取对象的详细信息和描述。假设你遇到了一个与 Pod 相关的问题，原因是 Pod 未能启动。让我们通过检查 Pod 的详细信息来开始我们的故障排除，具体操作如下：

$ oc describe pod sso-10-qm2hc

检查对象的Events部分输出，看看是什么阻止了 Pod 启动，如下代码片段所示：

Events:
  Type     Reason          Age                From               Message
  ----     ------          ----               ----               -------
  Normal   Scheduled       90s                default-scheduler  Successfully assigned rhsso/sso-10-qm2hc to ocp-hml4.hybridcloud.com
  Normal   AddedInterface  89s                multus             Add eth0 [10.242.22.12/23] from openshift-sdn
  Normal   Pulling         39s (x3 over 89s)  kubelet            Pulling image "image-registry.openshift-image-registry.svc:5000/rhsso/sso74-custom"
  Warning  Failed          33s (x3 over 83s)  kubelet            Failed to pull image "image-registry.openshift-image-registry.svc:5000/rhsso/sso74-custom": rpc error: code = Unknown desc = pinging container registry image-registry.openshift-image-registry.svc:5000: Get "https://image-registry.openshift-image-registry.svc:5000/v2/": dial tcp 10.244.109.169:5000: connect: no route to host
  Warning  Failed          33s (x3 over 83s)  kubelet            Error: ErrImagePull
  Normal   BackOff         8s (x4 over 83s)   kubelet            Back-off pulling image "image-registry.openshift-image-registry.svc:5000/rhsso/sso74-custom"
  Warning  Failed          8s (x4 over 83s)   kubelet            Error: ImagePullBackOff

在这种情况下，你可以通过oc describe命令快速查看到错误与节点和镜像注册表之间的连接有关（no route to host）。你可以相应地采取行动来修复连接问题，使 Pod 顺利启动。你还可以使用Events日志查看其他有意义的信息，正如接下来你将看到的那样。

事件

oc CLI 中另一个帮助问题排查的参数是oc get events命令。这个命令非常有用，可以展示最近执行的任务日志，同时呈现成功或错误信息。事件可以在整个集群或项目范围内执行。查看以下事件日志示例：

$ oc get events -n openshift-image-registry
LAST SEEN   TYPE      REASON              OBJECT                                                  MESSAGE
35m         Normal    Scheduled           pod/cluster-image-registry-operator-7456697c64-88hxc    Successfully assigned openshift-image-registry/cluster-image-registry-operator-7456697c64-88hxc to ocp-master2.hybridcloud.com
35m         Normal    AddedInterface      pod/cluster-image-registry-operator-7456697c64-88hxc    Add eth0 [10.242.0.37/23] from openshift-sdn
35m         Normal    Pulled              pod/cluster-image-registry-operator-7456697c64-88hxc    Container image "quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:6a78c524aab5bc95c671811b2c76d59a6c2d394c8f9ba3f2a92bc05a780c783a" already present on machine
(...omitted...)

如果 Pod 已启动并运行，但你在应用程序中仍然遇到问题，你也可以使用 OpenShift 检查应用程序日志，接下来你将看到如何操作。

Pod 日志

通常，Pod 日志提供与调度程序、Pod 亲和性/反亲和性、容器镜像和持久卷相关的重要信息。这里列出了几种检查 Pod 日志的方法：

常见方式——在命名空间内——如下所示：
```
$ oc project mynamespace
$ oc logs mypod
```
这是如何从任何命名空间中检查它们的方法：
```
$ oc –n mynamespace logs mypod
```
这是检查 Pod 中某个特定容器日志的方法：
```
$ oc -n mynamespace logs mypod -c kube_proxy
```
你还可以使用 OpenShift 控制台的Logs选项卡检查日志，选择所需的命名空间和 Pod，示例如下截图：

图 6.5 – Pod 日志示例（OpenShift 控制台图形用户界面（GUI））

在应用程序部署过程中，你也可能遇到问题。接下来，请查看你可以检查哪些内容以发现部署问题的证据。

部署日志

在某些情况下，Pod 无法启动并持续处于崩溃状态，这使得获取日志变得困难。在这种情况下，你可以检查deployment或deploymentconfig日志，这有助于你识别部署配置错误。

与 Pod 日志类似，deployment日志可以通过运行oc logs命令访问。对于deployment日志，运行以下命令：

$ oc –n mynamespace logs deployment/mydeploypods

对于deploymentconfigs日志，请使用以下命令：

$ oc –n  mynamespace logs dc/mydeploypods

通常，你不会找到确切的问题或根本原因和解决方案，但它会给你一个关于失败原因的良好指示——例如，缺失的依赖组件，如不可用的镜像；具有不正确权限的安全上下文约束；缺失的 configmaps、secrets 和 serviceaccounts 等。

另一种有用的故障排除方法是使用带有临时根权限的debug命令。有关更多信息，请参阅以下部分。

调试 Pods

另一个有趣的工具，用于排查持续崩溃的 Pod，可以通过执行oc debug deployment或oc debug deploymentconfig命令来使用。通过这个命令，你可以指示 OpenShift 在 Pod 崩溃时不要失败并重启它。Pod 将继续运行，你可以检查日志、访问 Pod 并在容器内部进行故障排除。要使用这个工具，请运行以下命令：

$ oc debug deployment/<deployment-name>

注意

oc debug命令提供了一些有趣的选项，例如使用--as-user以指定用户身份运行 Pod。要查看允许的参数和示例的完整列表，请运行oc debug -h命令。

操作符日志

正如我们在本书中已经提到的，OpenShift 使用多个操作符来部署和监控平台的关键功能。也就是说，操作符会提供有用的日志，以帮助识别配置问题和平台不稳定性。这些日志存储在以openshift-*开头的命名空间中，这是 OpenShift 中大多数工具的标准做法。

维护多个运维者 pod 作为项目 pod 的一部分，原因与用户可以应用于集群的某些亲和性/反亲和性规则以及污点/容忍策略有关。运维者 pod 是监视器，负责维持命名空间的健康，观察 CRD 及其标准、存活性和就绪性，防止 OpenShift 的关键命名空间受到不良变化的影响。

运维者为集群稳定性带来的主要好处之一是能够维护运维者命名空间对象的期望状态。换句话说，如果直接对命名空间的对象做出任何不希望发生的更改，它们将被运维者本身恢复。运维者的对象的每次更改都必须通过运维者本身进行，方法是编辑 ConfigMaps 或 CR 对象，按照运维者的规范进行。这也意味着，在这些更改被实际应用之前，它们会被运维者检查并确认。

要检查集群运维者的功能，你必须执行以下操作：

列出集群运维者，如下所示：
```
$ oc get co
```
描述集群运维者的详细信息，如下所示：
```
$ oc describe co <clusteroperatorName>
```

这是一个示例：

$ oc describe co storage

检查状态输出中的错误信息（如果存在），如下所示：

(...omitted...)
Status:
  Conditions:
    Last Transition Time:  2021-08-26T14:51:59Z
    Message:               All is well
    Reason:                AsExpected
    Status:                False
    Type:                  Degraded
    Last Transition Time:  2021-08-26T14:51:59Z
    Message:               All is well
    Reason:                AsExpected
    Status:                False
    Type:                  Progressing
    Last Transition Time:  2021-08-26T14:51:59Z
    Message:               DefaultStorageClassControllerAvailable: No default StorageClass for this platform
    Reason:                AsExpected
    Status:                True
    Type:                  Available
    Last Transition Time:  2021-08-26T14:52:00Z
    Message:               All is well
    Reason:                AsExpected
    Status:                True
    Type:                  Upgradeable
(...ommitted...)

在之前的示例中，仅显示了关于为集群设置默认存储类的警告信息。存储方面没有发现严重问题。如有问题，请查看运维人员命名空间中的事件和 pod 日志。

其他 oc CLI 命令和选项：

oc CLI 还有一些其他强大的命令用于故障排除。以下是一些有用且强大的故障排除命令：

这是一个用于高详细日志的示例命令：
```
$ oc –n <namespaceName> logs <podName> -v 8
```
这是一个用于集群事件的例子：
```
$ oc get events
```
这里，你可以看到一个关于命名空间事件的示例命令：
```
$ oc –n <namespaceName> get events
```
以下是在 pod 中执行单个命令的方式（需要双破折号）：
```
$ oc exec mypod -- date
```
以下是在特定容器中执行单个命令的方式（需要双破折号）：
```
$ oc exec mypod -c httpd-container -- date
```
创建迭代命令以生成伪终端，如下所示：
```
$ oc exec mypod -i -t -- ls -t /usr
```
类似于exec命令，rsh—如这里所示—在 pod 内打开一个终端：
```
$ oc -n <namespaceName> rsh  <podName>
```

所有前述命令都可以帮助你识别集群或甚至应用程序中的问题。此外，你还可以使用oc debug命令直接检查节点，如下所示：

$ oc debug node/<nodeName>

oc debug命令为你提供了非根用户权限访问，且在没有提升权限的情况下，你无法运行许多操作系统命令。为此，我们建议你运行chroot命令，如下所示。之后，你可以正常使用操作系统的 shell 命令：

$ chroot /host /bin/bash

正如你所看到的，OpenShift 有许多有用的调试命令，可以帮助你识别集群范围或特定范围的问题。虽然不推荐，但也可以直接通过ssh连接到节点。这种方式需要对Red Hat CoreOS操作系统、podman和crio有很好的了解，以避免节点中断。

在任何情况下，我们还建议你向 Red Hat 提交支持票，Red Hat 将为你提供指导，帮助你解决问题。Red Hat 支持团队通常会要求提供 must-gather 命令的结果，该命令会生成一个临时 pod，并将有意义的日志和配置串联起来，供 Red Hat 工程团队分析、关联事件，并找出问题或根本原因。

运行 must-gather 的最常见方法如下所示：

$ oc adm must-gather --dest-dir=/local/directory

这将在选定目录下创建一个 tar 文件，包含所有收集的日志，这对于识别问题非常有用。我们建议你在打开支持票时始终运行此命令并上传它，以加快问题分析的过程。

在本节中，你看到了不同的调试方法，它们肯定会在日常生活中对你有所帮助。在下一节中，你将看到 pod 启动时最常见的错误消息，通过这些信息，你将能够形成自己的推理方法，帮助你解决问题。

理解误导性错误信息

即使你已经学会了识别问题的不同方式，错误信息有时也不足以帮助你定位问题并修复它。考虑到这一点，我们决定在本节中突出一些非常常见的错误消息，并提供一些解决问题的建议。

ImagePullBackOff

这是一个常见的与缺失容器镜像相关的错误。查看以下代码行，了解当你遇到这种问题时如何处理：

NAMESPACE   NAME READY STATUS RESTARTS AGE
namespace1  backend-tfmqm 0/1 ImagePullBackOff 0 17h

这是你在调查 pod 日志时可能出现的消息：

$ oc -n namespace1 logs backend-tfmqm
Error from server (BadRequest): container " backend" in pod " backend-tfmqm" is waiting to start: trying and failing to pull image

从错误消息来看，它通常与镜像在镜像库中缺失有关。这可能是由于一些问题导致的，例如镜像及其标签在镜像库中不可用，或者在部署/部署配置中指向不正确。另一种可能是 pod 运行的节点无法访问镜像库。

CrashLoopBackOff

这是一个需要一定知识才能有效解决的错误。它发生是因为应用程序不断崩溃，因此根本原因可能有多个不同的原因。你可以在这里看到一个示例：

NAMESPACE NAME READY STATUS RESTARTS AGE
3scale backend-redis-1-9qs2q 0/1 CrashLoopBackOff 211 17h

这是你在调查 pod 日志时可能看到的消息：

$ oc logs backend-redis-1-9qs2q
1:M 11 Jan 13:02:19.042 # Bad file format reading the append only file: make a backup of your AOF file, then use ./redis-check-aof --fix <filename>

日志通常会给出一些有关问题根本原因的提示，但它也可能是一个陷阱，引导你得出错误的结论。需要考虑的是，当一个 pod 拥有持久卷，或者它有一个依赖于其他应用程序先启动并准备持久卷的优先顺序时，以及许多其他可能导致此错误的不同场景。

Init:0/1

当您收到Init:0/1错误消息时，通常意味着 Pod 正在等待另一个 Pod 或尚未满足的条件。以下代码行演示了可能导致此消息的条件，并说明如何解决：

NAMESPACE NAME READY STATUS RESTARTS AGE
3scale backend-cron-1-zmnpj 0/1 Init:0/1 0 17h

这是您在调查 Pod 日志时可能看到的一条消息：

$ oc logs backend-cron-1-zmnpj
Error from server (BadRequest): container "backend-cron" in pod "backend-cron-1-zmnpj" is waiting to start: PodInitializing

这是一个可能会让您在故障排除错误消息时感到困惑的状态。显然，它可能是命名空间中的某些问题，因此错误消息仅显示PodInitializing。您可以将其解读为 Pod 正在等待启动的条件；然而，这条消息意味着某个条件未得到满足。

为了帮助您，我们在这里列出了一些必须检查的项，这些项可能会阻止 Pod 启动：

检查 Pod 中使用的服务帐户是否存在于命名空间中，因为某些容器需要特定的服务帐户名称和策略才能启动。
检查安全上下文约束（SCCs），确保这些设置符合 Pod 所需的权限。
检查命名空间中的其他容器和 Pod：根据构建策略，可以定义 Pod 之间的依赖关系。

如果您还不熟悉 SCC，请不要担心。我们将在第八章中深入讲解，OpenShift 安全性。

总结

本章重点介绍了 OpenShift 的重要组件，如操作员及其在维护集群韧性中的作用，我们还讨论了可能对集群造成损害的情况。

我们已经深入探讨了 OpenShift 的核心部分，即其分布式数据库（称为 etcd），了解了它在集群中的重要性，以及如何准备它以接收大量流量，还验证了其大小和性能，并了解了在某些情况下如何进行故障排除。

我们还讨论了 AuthN 和 AuthZ 过程的一些内容，现在您已经了解了 OpenShift IDP 的强大和灵活性。最后，我们看到了几个重要的故障排除技巧和工具，它们肯定会帮助您在日常工作中操作 OpenShift 集群和应用程序。

在下一章中，我们将介绍关于 OpenShift 网络的其他重要信息。我们将讨论并举例说明 Pod 网络和服务网络之间的主要区别，以及了解南北流量（North-South）和东西流量（East-West）的区别。请继续关注我们这篇有趣的文章，并在第七章中了解更多内容，OpenShift 网络。

进一步阅读

如果您想查看更多关于本章内容的信息，可以查阅以下参考资料：

Red Hat 知识库——etcd 推荐：access.redhat.com/solutions/4770281
etcd 委员会模型：etcd.io/docs/v3.5/faq/
理解 etcd 的仲裁机制: thesecretlivesofdata.com/raft/
etcd 硬件规格建议: etcd.io/docs/v3.5/op-guide/hardware/
etcd 调优选项: etcd.io/docs/v3.5/tuning/
etcd 基准测试阈值: etcd.io/docs/v3.5/benchmarks/
etcd 基准测试 CLI 工具: etcd.io/docs/v3.5/op-guide/performance/#benchmarks
Kubernetes 身份验证流程: kubernetes.io/docs/reference/access-authn-authz/authentication/
Openshift 身份提供者（IDP）: docs.openshift.com/container-platform/4.7/authentication/understanding-identity-provider.html
了解更多关于 SCC 的信息: docs.openshift.com/container-platform/4.8/authentication/managing-security-context-constraints.html
更多关于故障排除的信息: docs.openshift.com/container-platform/4.7/support/troubleshooting/investigating-pod-issues.html
推荐的 etcd 实践: docs.openshift.com/container-platform/4.10/scalability_and_performance/recommended-host-practices.html#recommended-etcd-practices_recommended-host-practices
如何计算存储阵列中的 IOPS（博客文章）: www.techrepublic.com/article/calculate-iops-in-a-storage-array/

第七章：7

OpenShift 网络

正如我们所知，如果网络设计不当，可能会引发大问题。从传统的角度来看，网络是每个基础设施的脊梁。路由器、调制解调器、交换机、防火墙、Web 应用防火墙（WAFs）、入侵检测系统/入侵防御系统（IDSs/IPSs）、代理和虚拟专用网络（VPNs）等网络设备需要通过最佳实践进行完全集成、部署和维护，以确保高性能和可靠的网络基础设施。本章将讨论与 OpenShift 网络相关的重要概念，您需要考虑这些概念，以便做出最适合您情况的决策。

本章涵盖以下主题：

OpenShift 网络
网络策略
什么是 Ingress 控制器？
路由类型

OpenShift 网络

在本书中，我们将继续强调选择正确架构的重要性，因为它直接影响集群的工作方式。我们期望此时所有必要的网络决策都已经做出并实施——许多网络更改在集群部署后是无法进行的。

尽管我们已经在第二章《架构概览与定义》中讨论了网络，并且已部署了我们的集群，我们认为有必要进一步扩展此主题，并包括更多关于考虑网络使用时差异的细节。

Red Hat OpenShift 使用基于 Open vSwitch 的默认软件定义网络（SDN）（github.com/openvswitch/ovs），该网络创建了一个多层次的网络解决方案。这个额外的层次作为网络层之上的虚拟交换机，负责在虚拟局域网内创建、维护和隔离流量。

由于其多层网络能力，Open vSwitch 提供了一种控制进出集群流量的方式。请参阅以下图示以更好地理解网络层之间的流量：

图 7.1 – 网络层概览

在 OpenShift 集群安装过程中，会创建一些与网络功能相关的命名空间；基本上，最重要的网络项目是 openshift-sdn，它包含每个节点的一些 pod，负责节点之间的流量。还需要指出的是，流量在由 Open vSwitch 操作的虚拟局域网内运行。还有其他网络项目涉及其中，如 openshift-host-network 和 openshift-ingress。

Open vSwitch 上的流量是如何工作的？

为了回答这个问题，我们需要定义流量的起始点。让我们从内部流量开始，这意味着 OpenShift 集群内应用程序的 pod 之间的通信。

为了帮助理解，可以考虑在 OpenShift 上运行的两个应用程序；第一个名为 app-frontend，第二个名为 app-backend。顾名思义，app-frontend 通过 API 调用 app-backend 来处理用户请求。

因此，当 app-frontend 应用中的一个 pod 向 app-backend 应用发出请求时，该请求会被发送到内部服务，这里是 app-backend 服务。app-backend 服务负责将数据包传递给其中一个 app-backend pod。以同样的方式，应用程序处理请求并将结果数据包发送回服务网络，此时服务网络已经与 app-frontend 建立了连接。

图 7.2 – 服务网络层

通过上述内容，我们简要解释了集群内应用之间的流量。现在，让我们来看看外部到内部流量是如何处理的。当请求来自集群外部时，首先会进入外部负载均衡器。当负载均衡器接收到连接时，它将请求路由到其中一个 OpenShift Ingress pod，然后将请求转发到目标应用程序的服务，服务随后将请求路由到正确的应用程序 pod。

图 7.3 – 路由 SDN 网络

现在你已经了解了 OpenShift 集群中的流量是如何工作的，重要的是要强调，OpenShift 基本上有三个网络层：节点网络、服务网络和集群网络（也就是 pod 网络）。

节点网络是用于创建和维护机器的物理网络。服务网络是由 Open vSwitch 创建的虚拟层，负责在 pod 和服务之间路由流量。集群网络是另一个由 Open vSwitch 创建的虚拟层，负责为 pod 的通信创建子网 —— 它允许根据需要隔离项目之间的流量。

在接下来的章节中，我们将深入探讨 OpenShift 的主要网络插件。请记住，前面提到的插件之间存在细微的差异，因此在选择使用某一个插件时，必须根据其功能差异来做出决策，这些差异可能会影响集群的架构，同时也会影响应用程序可用的网络功能。这一决策需要与网络和软件架构团队共同商讨，以便了解当前的使用场景和未来计划的实施，旨在创建一个高效且功能齐全的集群。

网络类型 – OpenShift SDN 或 OVN-Kubernetes

OpenShift 是一个基于 Kubernetes 的完整 PaaS 解决方案，提供除了其默认组件之外的多种选项。例如，OpenShift 默认使用 Open vSwitch 网络插件（OpenShift SDN），但您也可以使用 OVN-Kubernetes 作为替代方案。

网络插件是一种功能，使用 Kubernetes 容器网络接口（CNI）创建覆盖网络，隔离虚拟机网络与 OpenShift 节点之间的流量。

这两种受支持的选项提供了良好的可靠网络性能，但您可以根据 OpenShift 部署的场景使用其他类型的 CNI。请查看本章“进一步阅读”部分中的 OpenShift 测试集成 链接，以查看由 Red Hat 测试和支持的选项。

网络策略

如我们之前提到的，OpenShift 使用软件定义网络（SDN），并且最好通过集群自身提供的功能来控制网络流量。在我们的经验中，已经在许多组织中实施了 OpenShift，我们常常听到关于如何控制集群内网络流量的疑问，因为大多数客户习惯于使用常规的防火墙设备来控制流量。在本节中，我们将向您介绍如何控制网络流量，以便根据需要允许或拒绝网络流量。在为您提供一些选项之前，我们首先需要区分集群中不同的流量方向。

南北向流量

OpenShift 的设计旨在覆盖最常见的场景，甚至包括网络。在一个应用程序的传入连接来自集群外部时，可以使用外部防火墙和/或 OpenShift Ingress 解决方案来控制集群内部的网络流量。

东西向流量

起初，可能会觉得东西向流量这个说法有点奇怪，但东西向网络流量实际上只是指在同一 OpenShift 集群中不同命名空间之间的应用程序之间的流量。

以下图表说明了这些不同类型的流量是如何在集群中发生的：

图 7.4 – 南北/东西向流量

您已经看到了可以控制网络流量的可能方向。在下一节中，您将看到如何控制集群内的网络流量。

控制网络流量

在 OpenShift 中控制流量有不同的选项：

对于南北向流量，您可以使用外部防火墙和负载均衡器在流量进入 OpenShift 集群之前控制流量，或者使用 OpenShift 路由对象中的注释来控制速率限制、超时和负载均衡算法等方面。
使用合适的 网络策略 根据需要允许或拒绝流量流动。
使用 ovs-multitenant 网络隔离模式。此模式曾在 OpenShift 3 版本中广泛使用，但在 4 版本中不再推荐使用，因为网络策略插件已成为标准。
如果您打算在 OpenShift 上使用微服务，您还可以选择使用 服务网格 来控制东西向流量，它使用 istio-proxy sidecar 提供最低粒度的隔离模式。服务网格不是本书的重点，但如果您想了解更多信息，请查看本章的 进一步阅读 部分。

注意

如果您曾在 OpenShift 3.x 上使用过 ovs-multitenant，并希望在 4.x 版本上获得类似的功能，我们建议您自定义项目模板，默认添加网络策略以阻止不同项目之间的流量。实现这一目标的过程很简单，可以在这个链接中找到描述：docs.openshift.com/container-platform/latest/networking/network_policy/default-network-policy.html。

在本章中，我们将重点讨论网络策略，因为它是 OpenShift 4 中的标准网络插件。接下来看看如何创建一个网络策略来控制网络流量。

创建网络策略

正如我们之前提到的，借助网络策略，您可以定义规则来允许或阻止集群中的入口网络流量。使用网络策略，您可以例如允许同一命名空间内的 pod 之间的流量，但拒绝来自其他命名空间的流量。您还可以仅允许特定端口上的流量等等。因此，为了更好地理解网络策略以及流量允许和不允许流动的方向，我们将提供多个图表和场景来阐明命名空间隔离的重要性。

为了学习目的，我们将使用三个命名空间，分别为 bluepets、greenpets 和 otherpets。在下面的图示中，我们展示了默认的 网络策略，该策略默认允许命名空间之间以及来自集群入口的流量：

图 7.5 – 默认网络策略 – 允许所有

所以，让我们继续演示这两个命名空间之间允许的连接：bluepets 和 greenpets。为了便于理解，我们在一个没有直接通向greenpets命名空间上rsh的外部网络中进行测试，并尝试在我们之前讨论的实验室场景中访问bluepets命名空间的服务 IP。

在深入之前，我们必须获取两个命名空间的服务 IP，以便稍后在 pod 终端中使用，并相应地检查结果。

图 7.6 – 服务 IP – bluepets 和 greenpets 命名空间

看一下下面的截图。我们在 greenpets 命名空间下执行 rsh 命令并在以下端点上运行 curl：

greenpets（同一命名空间）中的服务 IP：检查同一命名空间中 Pod 与服务之间的连接性（在下图中用绿色方框突出显示）。
bluepets（不同命名空间）中的服务 IP：我们类似地调用 bluepets 命名空间的服务 IP，它也能正常工作（在下图中用蓝色方框突出显示）。

图 7.7 – 测试两个命名空间之间的连接性

在下一个场景中，我们将阻止 greenpets 命名空间中的所有流量，图示如下：

图 7.8 – greenpets 命名空间 – 拒绝所有流量

为了完成这个场景，我们将在 greenpets 命名空间应用一个网络策略清单：

$ cat << EOF >> block-everything-to-namespace.yaml
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: deny-by-default
spec:
  podSelector:
  ingress: []
EOF
$ oc –n greenpets apply –f block-everything-to-namespace.yaml

现在，让我们再次执行相同的测试，以演示 greenpets 中的所有网络流量（路由和服务）都被拒绝连接：

图 7.9 – 拒绝所有流量测试

现在，我们将深入探讨并应用一条规则，只允许来自入口的流量流向greenpets命名空间下的 Pods。为此，我们将应用以下 YAML 文件：

$ cat << EOF >>allow-ingress-to-namespace.yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-from-openshift-ingress
spec:
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          network.openshift.io/policy-group: ingress
  podSelector: {}
  policyTypes:
  - Ingress
EOF
$ oc –n greenpets  apply –f allow-ingress-to-namespace.yaml

这个网络策略的作用是只允许入口命名空间中的 Pods 与 greenpets 命名空间中的 Pods 通信，所有其他流量将被阻止。请查看下图并注意，命名空间之间的东西向流量被拒绝，但南北向流量是允许的：

图 7.10 – 仅允许入口连接（外部路由）的 greenpets 命名空间流量

请注意，现在外部路由（入口）与服务之间的网络通信是正常的；然而，bluepets 与 greenpets 之间的流量被拒绝。

图 7.11 – 测试网络流量。1) 从 bluepets 命名空间到 greenpets 命名空间：连接被拒绝。2) 从外部路由（入口）到 greenpets 命名空间：连接被允许。

最后，我们将看看最常见的场景：最少隔离配置。这个网络策略场景基于一个命名空间标签，我们将在 greenpets 命名空间中应用该标签，并作为配置命名空间之间通信的关键。

图 7.12 – 已标记的命名空间允许流量

从前面的图示中，你可以看到三个不同的命名空间：bluepets、greenpets 和 otherpets。一个网络策略将应用于 greenpets 命名空间，并使用带有 join=greenpets 值的标签。换句话说，这意味着只有标记为 join=greenpets 的命名空间中的元素才能与 greenpets 命名空间中的应用进行通信。为了实现这一点，我们将应用以下清单和命令：

$ cat << EOF >> allow-namespace-by-label.yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-from-namespace-label
spec:
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          join: greenpets
  podSelector: {}
EOF
$ oc –n greenpets apply –f allow-namespace-by-label.yaml
$ oc label namespace bluepets join=greenpets

现在，通过运行以下测试检查 bluepets 和 greenpets 命名空间之间的连接性：

图 7.13 – 测试标记命名空间。连接到包含正确标签的命名空间 – 连接允许

在图 7.13中，你看到连接被允许，因为命名空间包含标签 join=greenpets。然而，在图 7.14中，你看到连接被拒绝，因为流量来自一个没有该标签的命名空间（otherpets）。

图 7.14 – 测试未标记命名空间拒绝流量

网络策略是隔离网络流量的重要工具。然而，你需要考虑某些类型的规则可能带来的挑战。如果没有设计好、标准化并采用，它们可能会让你头疼，既允许本应阻止的流量，又阻止本应允许的流量。

此外，你还需要考虑集群中将运行的工作负载类型。例如，对于面向微服务的应用，我们建议你查看Istio 服务网格，它通常更合适并且能提供更细粒度的网络访问控制。

到目前为止，你已经了解了 SDN 的定义和重要概念，比如通过使用标签应用策略来控制水平和垂直方向的流量。接下来，继续了解更多关于路由和 Ingress 控制器的内容，并学习如何在你的应用中使用它们。

什么是 Ingress 控制器？

Ingress 控制器是一个轻量级的自愈负载均衡器，将外部集群的网络流量分配到网络服务中。使用 Ingress 控制器是为容器化应用提供和管理入口流量的标准方法。OpenShift 中的默认 Ingress 控制器在后台使用成熟且稳定的HAProxy。在 OpenShift 中，当你部署一个集群时，Ingress 控制器会默认自动创建并托管在两个工作节点上。

Ingress 操作员是如何工作的？

Ingress 操作员的作用类似于 OpenShift 中几乎所有集群操作员的作用：保护集群操作中的重要设置。该操作员监控在openshift-ingress命名空间中运行的 ingress pods，并保护IngressController对象免受错误和不兼容设置的影响，这些设置可能导致集群网络出现问题。

否则，您可以创建其他IngressController对象，除了默认的 IngressController 外，用于隔离特定应用组的流量，这就是所谓的路由器分片。

与传统的网络配置不同，后者需要复杂的路由表和防火墙配置，OpenShift 抽象了这一复杂的网络层配置，使任务变得更加简单。

创建新的 ingress 控制器

创建新的 ingress 控制器，您必须按照以下步骤进行操作：

至少定义两个节点来托管新的 ingress 控制器。
将新标签应用于节点。
导出默认的IngressController对象。
更改新创建的 YAML 清单文件的名称和所需设置。
通过应用之前创建的 YAML 文件，部署新的IngressController对象。

在以下几行中，您可以看到之前提到的过程示例：

# Apply labels to nodes
$ oc label node <node1> <node2> .. <nodeN> new-ingress=true
$ oc get ingresscontroller default -n openshift-ingress-operator -o yaml > new-ingress.yaml
$ vi new-ingress.yaml
# Remove unnecessary fields to make the yaml looks like 
# the following one
apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  name: new-ingress [1]
  namespace: openshift-ingress-operator
spec:
  domain: apps.env.hybridmycloud.com [2]
  replicas: 2
  nodePlacement:
    nodeSelector:
      matchLabels:
        new-ingress: "true" [3]
  routeSelector: [4]
    matchLabels:
      type: sharded [5]

在之前的代码中，我们用数字突出显示了某些部分。我们来看一下：

命名空间或路由选择器？

您看到的示例使用了routeSelector。配置 IngressController 的另一种方法是使用namespaceSelector。定义适合您情况的选择器可能看起来令人困惑，但其实并不复杂——routeSelector是一种更细粒度的选择，允许您将路由发布到同一命名空间中的不同 IngressController。主要的决策因素是，如果您需要能够将单个命名空间的路由发布到不同的 IngressController 中，您必须使用routeSelectors。否则，您很可能会使用namespaceSelectors。

例如，考虑一个名为APP的命名空间，该命名空间包含两个不同的路由：

路由器 1 中发布的 Route A，URL 为app1.prod.hybridmycloud.com

在路由器 2 中发布的 Route B，URL 为app1.qa.hybridmycloud.com

该场景只有在使用routeSelector时才可能。然而，这是一个不常见的场景；通常，单一命名空间中的路由始终会发布到相同的 IngressController 中，因此通常使用namespaceSelector。

如前所述，路由分片是一种技术，允许为隔离流量创建入口，无论是由于需要在环境之间隔离，还是为了将给定应用程序的流量完全定向到这个新的入口。

测试新的入口

创建了节点上的入口 pod 后，您可以测试新创建的入口。我们将使用名为 hello-openshift 的示例应用程序创建路由，并应用适当的路由选择器标签。按照以下步骤完成此任务：

$ oc new-project hello-openshift
$ oc create -f https://raw.githubusercontent.com/openshift/origin/master/examples/hello-openshift/hello-pod.json
$ oc expose pod/hello-openshift
$ oc expose svc hello-openshift
$ oc label route hello-openshift type=sharded

上一个命令块的最后一行明确设置了 type=sharded 标签，我们在示例中用于 routeSelector。当 OpenShift 看到此标签时，它将自动在新的入口中发布此路由。

继续前往下一节，全面了解如何使用 OpenShift 中所称的路由使用最近创建的入口。

路由类型

路由是为了将 Kubernetes 服务暴露给 DNS 名称（例如 example.apps.env.hybridmycloud.com）而在入口内部负载均衡器上配置的特定应用程序的配置表示。创建路由时，OpenShift 会自动在入口的 HAProxy pod 中配置前端和后端，以发布 URL 并使外部世界的流量可用。

路由可以使用 HTTP 或 HTTPS 协议发布。对于 HTTPS，三种不同类型的路由定义了 TLS 终止在用户和 pod 之间的 SSL 流中的工作方式。在以下小节中，我们将逐一介绍每一种。

透传路由

透传路由，顾名思义，是一种配置，其中包裹直接转发到网络服务，而不进行 TLS 终止，充当第四层负载均衡器。透传通常与在应用程序的 pod 内提供其自身的 TLS 终止的应用程序一起使用，无论是通过在源代码中实现还是使用中间件层（如 JBoss 或 WebSphere）。

图 7.15 – 透传路由

接下来，您将看到您有的第二个选项：边缘路由。

边缘路由

在此路由中，TLS 终止由 OpenShift 入口处理，并作为明文转发到服务。这种类型的路由经常被使用，因为它易于使用：OpenShift 自动为入口生成的默认通配符域使用自签名证书，它签署所有使用默认自签名证书的路由 – 这是由 OpenShift 自动执行的；不需要额外的配置。但是，如果您不想使用默认自签名证书，您可以将其替换为自定义数字证书。

图 7.16 – 边缘路由

边缘路由是最常见且最容易实现的模型，因为证书链终止于 OpenShift 网络的边缘，即 ingress。需要强调的是，ingress 和应用程序 Pod 之间的流量没有加密，而是在 OpenShift SDN 内部进行传输，这意味着网络包是通过 OVS 封装的。最后一种方法是重新加密路由。接下来，你将看到它是如何工作的。

重新加密的路由

重新加密路由提供了两层 TLS 终止：流量首先使用外部 FQDN（例如 example.apps.env.hybridmycloud.com）的证书在集群边缘（OpenShift Ingress）解密，然后流量再次被重新加密，但这时使用的是不同的证书。虽然这是一种安全路由，但由于 ingress 执行终止和重新加密操作，它也带来了性能开销。

图 7.17 – 重新加密的路由

重新加密路由采用与边缘路由类似的方法，但它经过两层证书授权机构（CA）。第一层与外部公共域相关，例如 hybridcloud.com，然后第二层加密是内部的，由 OpenShift Ingress 和应用程序所知。

总结

在本章中，我们了解了与 OpenShift 网络相关的一些重要方面。现在，你已经熟悉了 OpenShift 支持的两种网络插件：OpenShift SDN 和 OVN-Kubernetes，以及在管理平台网络时需要关注的不同类型的流量。你还了解了 ingress 控制器的工作原理，如何创建一个新的控制器，以及你可能与应用程序一起使用的三种安全路由类型：透传路由、边缘路由和重新加密路由。

你通过网络策略了解了如何控制流量并提供网络隔离的一些知识。

如你所知，安全性在当今的数字化世界中是一个重要问题。在下一章中，我们将讨论你在 OpenShift 上需要考虑的安全方面。因此，继续阅读并查看吧！

进一步阅读

如果你想了解更多本章中涵盖的概念，可以查看以下参考资料：

Kubernetes Ingress 控制器: www.nginx.com/resources/glossary/kubernetes-ingress-controller
HAProxy 文档: www.haproxy.com/documentation/hapee/latest/onepage/
用于覆盖路由默认配置的注解: docs.openshift.com/container-platform/4.10/networking/routes/route-configuration.html#nw-route-specific-annotations_route-configuration
使用 Ingress 控制器配置入口集群流量: docs.openshift.com/container-platform/4.10/networking/configuring_ingress_cluster_traffic/configuring-ingress-cluster-traffic-ingress-controller.html
创建安全路由: docs.openshift.com/container-platform/4.10/networking/routes/secured-routes.html
OpenShift 测试过的集成: access.redhat.com/articles/4128421
服务网格: docs.openshift.com/container-platform/4.10/service_mesh/v2x/servicemesh-release-notes.html

第八章：8

OpenShift 安全

在本书中，您将能够跟随一些涉及流程、人员和所有技术的关键方面，以维护一个强大、具有韧性和容错能力的平台。如此大规模的产品，从其创建到保持其完全功能所需的定制，也需要在每个步骤中进行良好的责任和技能分工。

安全一直是任何企业最重要的关注点，尤其是在如今勒索病毒、恶意加密货币挖矿、恶意软件和其他类型的攻击层出不穷的情况下。根据Gartner的研究，到 2025 年，90%的未能妥善控制公共云使用的组织将无意中共享敏感数据。在 Kubernetes 安全方面，我们最近也看到了一些漏洞和攻击。在本章的进一步阅读部分，您可以查看一些近年来与 Kubernetes 相关的漏洞和安全事件。

基于此，我们决定专门用一章来讨论与 OpenShift 相关的安全方面。本章的主要目的是不是成为一份完整的安全指南，而是为您提供一系列最低限度的主题，供您考虑和审视，以确保拥有一个安全的容器战略。

本章将介绍以下主题：

容器安全
身份验证（AuthN）和授权（AuthZ）
OpenShift 中的证书
etcd 加密
容器隔离
网络隔离
Red Hat 容器目录

开始吧！

容器安全

容器的采用呈指数级增长，随之而来的是容器生态系统中各种漏洞和潜在攻击的增多。也就是说，安全是您在容器战略中需要考虑的重要方面。Red Hat 因其产品的高安全性而广受认可，这也是它们在行业中始终保持竞争力的特点之一，从坚实的Red Hat Enterprise Linux（RHEL）——公司发展的基础——到如 Red Hat OpenShift 这样的新兴技术。由于 Red Hat 在 OpenShift 中将许多安全特性设定为默认（且必需），这些特性在许多其他基于 Kubernetes 的平台中是可选的，这使得 OpenShift 在安全性方面优于其他选择。一个例子是安全增强 Linux（SELinux），它始终在任何 OpenShift 工作节点上启用，防止了许多漏洞和攻击。

您知道吗？

你知道吗？现在互联网上大约有 38 万个 Kubernetes 应用程序编程接口 (APIs) 对外开放，可能暴露于某种攻击或数据泄露的风险中？这就是The Shadowserver Foundation在其研究中发现的：www.shadowserver.org/news/over-380-000-open-kubernetes-api-servers/。

想了解更多吗？在这份容器安全报告中，你将找到一些与 Kubernetes 安全相关的重要研究：www.kuppingercole.com/reprints/b1e948f62d5394353f996e43a89cde4a#heading8.1。

在这里，你可以查看Kubernetes 安全状态报告：www.redhat.com/en/resources/kubernetes-adoption-security-market-trends-overview。

你还可以参考以下链接中的云安全性是否可靠？ Gartner 研究：www.gartner.com/smarterwithgartner/is-the-cloud-secure。

拥有安全环境和应用程序的关键在于公司能够做到以下几点：

控制：保护应用程序生命周期管理 (ALM)，以在发布前检测并修复漏洞。
保护：评估和保护平台与基础设施的能力，以避免漏洞被利用。
检测与响应：通过限制系统和环境的影响，检测和缓解漏洞。

在下图中，你将看到我们提到的这三个因素的一些方面：

图 8.1 – 容器安全策略

在本章中，我们将详细讲解关于这些因素的一些重要考虑事项。

控制

为了确保容器软件供应链的安全，可以执行以下几个常见步骤：

漏洞分析：扫描容器镜像以发现已知漏洞。这个主题将在第十二章 OpenShift 多集群安全中详细介绍。
受信任的镜像和内容：您知道容器和应用程序中运行的所有内容吗？如今每个应用程序都依赖于来自不同项目的许多依赖项，其中许多是开源的。使用受信任的来源至关重要，以避免运行被破坏的基础包和镜像。红帽提供了红帽 通用基础镜像（UBI），它是 RHEL 的强大、安全和稳定的版本，可以作为容器镜像的基础。红帽还通过其红帽容器目录提供了经过认证的容器镜像列表，这些镜像是安全可用的，并维护了一个容器健康指数，用于评估容器镜像的安全风险。
ALM 和持续集成/持续部署（CI/CD）管道：安全应成为开发工作流的一个重要组成部分。现代开发生命周期要求安全是所有团队之间的共同责任，从头到尾都要考虑到。开发-安全-运维（DevSecOps）已成为新常态，这意味着要自动化安全控制，确保将安全融入 开发-运维（DevOps）过程。诸如 集成开发环境（IDE）插件和 CI/CD 管道安全任务等工具是实现这一目标的必备条件。

当然，这些只是一个更大集合中的一部分。虽然本书的主要重点不是全面覆盖与安全相关的所有方面，但我们将突出一些您在容器策略中应该关注的重要因素。

保护

为了保护您的平台和基础设施，制定身份验证和授权、部署、证书管理、合规性评估以及政策执行等相关政策至关重要。在本章后续内容中，我们将深入探讨 OpenShift 集群的身份验证和授权方面。

检测与响应

即使采取了所有措施来控制和保护基础设施，您仍然需要能够检测和缓解安全风险。因此，制定监控措施以及其他可能限制漏洞或泄露影响的政策至关重要，例如容器和网络隔离。在本章中，您还将看到有关容器和网络隔离的更多信息。

让我们首先更详细地了解身份验证和授权。继续阅读以了解更多内容。

AuthN 和 AuthZ

AuthN 和 AuthZ 是相关的概念，但其目标不同。AuthN 是 身份验证（authentication）的缩写，涉及确认用户身份并验证其凭据以授予平台访问权限的过程。在此过程中，我们将与 OpenShift 上的 身份提供者（IdPs）打交道，配置将检查用户凭据的身份验证提供者，我们将在稍后详细介绍。

反过来，AuthZ代表授权（authorization），它与在认证过程之后仅授予用户他们真正应有的访问权限直接相关。

从仅仅登录 OpenShift 的角度来看，这两个概念被认为是混淆或相似的。为了澄清这些概念，我们将讨论与认证和授权相关的不同对象和过程。

认证

OpenShift 在认证过程中使用以下一组对象：

这些是 OpenShift 中用于组合验证用户的对象。为了理解认证如何工作，您需要在 OpenShift 上定义 IdP——接下来会有更多关于它们的信息。

IdP

IdP 是将 OpenShift 与认证提供者集成的实体，目的是创建一个追踪谁可以登录平台的链条。为了避免在管理用户时某个产品对另一个产品的特权，OpenShift 创建了一个非常灵活的选项，允许多个 IdP 同时与 OpenShift 集成。

以下表格列出了允许与 OpenShift 集成的受支持 IdP：

在 OpenShift 文档中，您将找到如何配置每个认证提供者的详细信息：docs.openshift.com/container-platform/latest/authentication/index.html。

OpenShift 使用基于角色的访问控制（RBAC）模型来执行授权过程，并授予用户他们应拥有的适当权限集，正如您现在看到的那样。

授权 – RBAC

在 RBAC 系统中，您将拥有一组权限，表示为角色，用户和组将使用这些角色来获得这些权限。在 OpenShift 中，我们有以下对象来配置 RBAC 权限：

角色可以是集群范围或本地范围，这意味着它可以应用于所有项目或仅应用于特定项目。在以下示例中，您可以看到一个命令来创建一个本地角色，允许用户在命名空间 test 中获取并更新一个 pod：

$ oc create role podmgmt --verb=get,update --resource=pod -n test

您可以通过运行以下命令来检查创建的角色：

$ oc describe role.rbac.authorization.k8s.io/podmgmt -n test
Name:         podmgmt
Labels:       <none>
Annotations:  <none>
PolicyRule:
  Resources  Non-Resource URLs  Resource Names  Verbs
  ---------  -----------------  --------------  -----
  pods       []                 []              [get update]

同样，要创建一个集群角色，您需要使用oc create role命令，如下所示：

$ oc create role clusterpodmgmt --verb=get,update --resource=pod

要创建角色绑定并将此角色添加到用户或组，您可以使用以下命令：

# For local role bindings
$ oc adm policy add-role-to-user <role> <username> -n <project>
$ oc adm policy add-role-to-group <role> <group> -n <project>
# For cluster role bindings
$ oc adm policy add-cluster-role-to-user <role> <username>
$ oc adm policy add-cluster-role-to-group <role> <group>

您还可以使用以下命令从用户或组中删除角色：

# For local role bindings
$ oc adm policy remove-role-to-user <role> <username> -n <project>
$ oc adm policy remove-role-to-group <role> <group> -n <project>
# For cluster role bindings
$ oc adm policy remove-cluster-role-to-user <role> <username>
$ oc adm policy remove-cluster-role-to-group <role> <group>

继续阅读以获取关于访问控制功能的故障排除提示。

访问控制故障排除

请注意，在更改集群 OAuth 自定义资源后，认证操作员将应用更改；因此，您可能会观察到 OpenShift 认证的暂时不可用。请等待几分钟，直到操作员完成应用更改。

即使您在使用 OpenShift 认证时遇到问题，我们仍建议您查看这篇有用的文章：access.redhat.com/articles/5900841。

OpenShift 中的证书

OpenShift 使用多个不同的证书来确保平台安全。在本节中，我们将介绍 OpenShift 使用的主要证书链。这些证书如下所示：

https://api.<cluster-name>.<domain>:6443/。
*.apps.<cluster-name>.<domain>。
节点证书：由集群自动管理，无需用户干预。自动轮换。
etcd 证书：用于加密 etcd 集群成员之间的通信。由集群自动管理和轮换。

OpenShift 在平台安装时会创建自签名证书。大多数企业要求将这些证书替换为自定义证书。为此，请参考 OpenShift 文档，具体如下：

要替换入口证书，请参阅：docs.openshift.com/container-platform/latest/security/certificates/replacing-default-ingress-certificate.html
要替换 API 服务器证书，请参阅：docs.openshift.com/container-platform/4.10/security/certificates/api-server.html

如果您替换证书，您可能还需要添加一个受信任的 证书颁发机构 (CA)，如果您使用的是私有 CA。下一部分将描述如何操作。

受信任的 CA

您可能需要添加您在组织中使用的自定义 CA，以便在 OpenShift 组件与其他外部系统之间进行 API 调用。为此，您需要在 openshift-config 命名空间中创建一个带有证书链的配置映射，如下所示：

$ oc create configmap custom-ca \
     --from-file=ca-bundle.crt=</path/to/example-ca.crt> \
     -n openshift-config

然后，更新集群范围的代理，使用刚刚创建的配置映射，具体如下：

$ oc patch proxy/cluster \
     --type=merge \
     --patch='{"spec":{"trustedCA":{"name":"custom-ca"}}}'

Kubernetes 集群中的一个重要部分是 etcd 数据库。您可以决定加密它，以保持数据库中的机密和其他对象加密。接下来请查看如何操作。

etcd 加密

默认情况下，etcd 数据库是未加密的。然而，您可以轻松启用 etcd 加密，在集群中增加一层数据安全性。当启用 etcd 加密时，诸如机密和配置映射等内容将以加密形式存储，这使您的集群更加安全。

要启用 etcd 加密，请按照以下步骤进行：

编辑 apiserver 对象，如下所示：
```
$ oc edit apiserver
```

设置 encryption 字段，具体如下：

spec:
  encryption:
    type: aescbc

保存文件以应用更改。

请注意，应用更改后启用加密可能需要大约 15 分钟的时间。

容器隔离

我们已经讨论了用户认证、权限以及证书等方面，但如何确保容器仅能执行其应有的操作，而无法在主机上提升权限呢？

本节将讨论作为操作系统（OS）一部分实现的一些概念，以安全地运行容器，同时也会讨论 OpenShift 中与此相关的一些实现。

在下表中，你将看到一些与容器相关的概念：

在下图中，你可以看到这些概念的图示：

图 8.2 – 容器隔离

虽然理解这些概念很重要，但你不需要直接操作其中任何一个，因为 OpenShift 会为你抽象化这些配置。相反，你需要理解什么是安全上下文约束（SCCs）——这些是你在需要时为容器授予更广泛权限所需使用的对象。继续阅读，了解什么是 SCCs 以及如何配置它们。

SCCs

SCCs 是 OpenShift 中的对象，用于控制 Pod 或容器与主机资源交互的权限。默认情况下，任何 Pod 使用restricted SCC，这是最受限制的权限，防止其作为 root 运行并提升主机上的权限。除了 restricted SCC，以下是常见的几种：

anyuid：具有与 restricted SCC 相同的权限，允许容器作为任何 0 UID（root 用户）运行。
hostaccess：授予容器访问所有主机命名空间的权限。只应与可信来源一起使用，因为它在工作节点中赋予了非常广泛的权限——仅在真正必要时使用。
hostnetwork：允许容器直接访问底层工作节点的网络。请谨慎使用，以降低网络漏洞的风险。
privileged：最放宽的 SCC，赋予主机所有权限。应避免使用，只有在绝对必要时才使用。

除了我们已经讨论的所有与安全相关的功能外，还有一个非常重要的话题：网络策略。网络策略是确保你的 Pods 和项目只能与它们应当通信的对象进行通信的一个极好功能。在接下来的章节中，你将了解网络策略的作用以及它们在网络安全中的重要性。

网络隔离

防火墙是众所周知并且在各种基础设施中被广泛使用的技术。在 OpenShift 中，我们需要牢记，当前我们所使用的是一个软件定义的平台，因此，我们拥有一些软件功能来实现数据中心中长期存在的概念——防火墙也不例外。正如我们在前一章中所看到的，网络策略实际上就是您定义的规则，用于允许或阻止 OpenShift 中不同 pod 和项目之间的网络通信，这与物理网络中的防火墙提供的功能类似。

默认情况下，项目中的所有 pod 都可以从任何项目中的其他 pod 和网络端点进行访问。为了隔离 pod 和项目，您需要创建网络策略，如下所示：

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: deny-by-default
spec:
  podSelector: {}
  ingress: []

前述的网络策略禁止项目中所有 pod 的流量。为了使一个项目能够通过 OpenShift 的入口从集群外部访问，您需要允许来自入口项目的连接，如下片段所示：

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-from-openshift-ingress
spec:
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          network.openshift.io/policy-group: ingress
  podSelector: {}
  policyTypes:
  - Ingress

您还可以使用标签为特定的 pod 创建自定义网络策略。例如，以下 YAML Ain’t Markup Language (YAML) 代码可以用来限制只有带有 app=web 标签的 pod 只能通过 HTTPS 端口（443）进行访问：

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-https
spec:
  podSelector:
    matchLabels:
      app: web
  ingress:
  - ports:
    - protocol: TCP
      port: 443

使用网络策略来为项目和 pod 设置适当的网络访问权限有着广阔的可能性。一个常见且推荐的做法是创建一套标准的网络策略，并配置 OpenShift 模板，使这些网络策略能够自动应用于任何新创建的项目。您可以在 OpenShift 文档中了解如何自定义 OpenShift 模板以添加这些网络策略：docs.openshift.com/container-platform/latest/networking/network_policy/default-network-policy.html。

另一件您可能会在安全策略中考虑的重要事项是使用安全的容器基础镜像。以下部分将介绍什么是 Red Hat 容器目录，以及它如何帮助您处理这个重要话题。

Red Hat 容器目录

大多数企业在某个阶段都需要使用来自不同来源的容器，这些容器可能是现成的产品，也可能仅仅是工作负载的依赖项。Red Hat 提供了一款有趣的工具，旨在帮助您确保使用安全的容器。Red Hat 容器目录是一个容器镜像库，里面的镜像经过 Red Hat 和合作伙伴的测试与认证，因此是可信的镜像。

作为容器目录的一部分，Red Hat 提供了容器健康指数（Container Health Index）。容器健康指数是 Red Hat 容器目录中可用容器镜像的评分系统，评分从 A 到 F，其中 A 代表在关键错误修复方面最为最新的镜像。你可以通过以下链接查看所有可用评分及其定义：access.redhat.com/articles/2803031。该功能有助于评估使用某个镜像版本时可能面临的安全风险。

在 Red Hat 容器目录中，你可以找到 Red Hat UBI，这可能是你容器策略中的一个重要方面。接下来你将了解更多内容。

Red Hat UBI

为你的容器定义基础镜像是一个重要步骤，这是你需要考虑的内容，以确保具有便携性和安全性的容器交付过程。根据你做出的决定，你可能会被锁定在某些特定的 Linux 版本和发行版中，而这些版本和发行版正是该容器基础镜像所支持的。基础镜像对于保持工作负载的安全性也至关重要——每周都有许多 Linux 漏洞被发现，但它们通常会得到非常快速的修复，使用像 RHEL 这样成熟且稳健的基础镜像，对于确保工作负载更加安全至关重要。

Red Hat UBI 基于 RHEL，免费提供，并且占用最小空间（大小介于 10 兆字节 (MB) 和 100 MB 之间，具体取决于镜像类型）。你可以根据需求从以下四种镜像类型中选择：

除了上述选项外，Red Hat 还提供了一些包含语言运行时的 UBI，例如 Node.js、.NET 和 Java。所有基础镜像都可以从 Red Hat 容器目录下载。

一旦你有了包含安全容器镜像的受信任源列表，我们建议你限制 OpenShift 仅运行来自这些受信任源的镜像。接下来你将看到如何操作。

限制镜像注册源

你可以通过以下程序轻松地阻止或允许 OpenShift 使用的镜像注册源：

运行以下命令编辑 image.config.openshift.io/cluster 对象：
```
$ oc edit image.config.openshift.io/cluster
```
在对象的 YAML 文件中，设置 allowedRegistriesForImport 和 registrySources 字段，指定所需的镜像注册源。AllowedRegistriesForImport 定义了用户可以通过镜像流（oc import-image 命令）导入镜像的镜像注册源。在 registrySources 块中，你可以定义允许的注册源（allowedRegistries）或阻止的注册源（blockedRegistries），但不能同时定义两者。请查看以下示例：
```
spec:
  allowedRegistriesForImport:
    - domainName: quay.io
      insecure: false
  additionalTrustedCA:
    name: myconfigmap
  registrySources:
    allowedRegistries:
    - quay.io
    - registry.redhat.io
    - image-registry.openshift-image-registry.svc:5000
    insecureRegistries:
    - insecure-reg.com
```

这总结了我们认为每个公司需要考虑的主要安全方面。我们鼓励你仔细审查我们在本章中讨论的内容，并定义/实施政策以确保你所有的集群都安全。

总结

我们在本章中已经看到了你可能考虑的一些使 OpenShift 集群安全的事项。虽然 OpenShift 被认为是基于 Kubernetes 的安全平台，但如何管理它当然至关重要。可以考虑为访问控制、证书、容器和网络隔离、开发及 CI/CD 流水线制定相关策略。

一个安全的平台始于适当的规划，以定义并实施高效的策略来控制平台中开发和部署的内容，保护其免受不必要的风险，并最终尽可能地隔离工作负载和网络，以减轻安全漏洞对环境造成的影响。在第十一章，OpenShift 多集群 GitOps 和管理，你将看到如何使用高级集群管理（ACM）对多个集群应用策略，并确保它们无论在哪个环境中运行，都符合安全要求。

在下一章中，我们将探索如何在 OpenShift 上使用 Tekton 项目与 Kubernetes 原生流水线进行协作，Tekton 项目不仅可以为你提供云原生 CI/CD 流程来构建和部署应用程序，还可以为你的应用程序供应链增加一层额外的安全防护。

进一步阅读

如果你想要更多与本章内容相关的信息，可以参考以下资源：

云安全吗？—Gartner研究：www.gartner.com/smarterwithgartner/is-the-cloud-secure
Kubernetes 漏洞和报告的攻击：
- thenewstack.io/unfixable-kubernetes-security-hole-means-potential-man-in-the-middle-attacks/
- threatpost.com/kubernetes-cyberattacks-argo-workflows/167997/
最常见的 Kubernetes 安全问题和关注点（博客文章）：cloud.redhat.com/blog/most-common-kubernetes-security-issues-and-concerns-to-address
容器安全报告：www.kuppingercole.com/reprints/b1e948f62d5394353f996e43a89cde4a#heading8.1
Kubernetes 安全状态报告：www.redhat.com/en/resources/kubernetes-adoption-security-market-trends-overview
OpenShift 身份验证指南：docs.openshift.com/container-platform/latest/authentication/index.html
故障排除 OpenShift 身份验证：access.redhat.com/articles/5900841
定义默认网络策略：docs.openshift.com/container-platform/4.10/networking/network_policy/default-network-policy.html
Red Hat 通用基础镜像：developers.redhat.com/products/rhel/ubi
容器健康指数等级：access.redhat.com/articles/2803031
关于 htpasswd（Apache 项目）的详细信息：httpd.apache.org/docs/2.4/programs/htpasswd.html
OpenID Connect：developers.google.com/identity/protocols/oauth2/openid-connect
容器隔离：www.nginx.com/blog/what-are-namespaces-cgroups-how-do-they-work/

第三部分 – 使用 GitOps 在 OpenShift 上实现多集群 CI/CD

在这一部分，你将了解与 CI/CD 和 GitOps 相关的新概念和技术。你将学习如何构建与企业战略相匹配的 CI/CD 管道，并且这些管道设计为易于维护，使用 Tekton 和 ArgoCD。你还将看到如何同时使用 Argo CD 和高级集群管理（ACM）将应用部署到多个集群中。

本书的这一部分包括以下章节：

第九章，OpenShift Pipelines – Tekton
第十章，OpenShift GitOps – Argo CD
第十一章，OpenShift 多集群 GitOps 与管理

第九章：9

OpenShift Pipelines – Tekton

到目前为止，我们已经讨论了与当前混合云世界相关的挑战，并介绍了 OpenShift 架构和部署的相关内容。现在，我们将转换话题，带来一个令人兴奋的 DevOps 相关功能：OpenShift Pipelines！

OpenShift Pipelines 是一个 Kubernetes 原生的 持续集成与持续交付（CI/CD）工具，基于 Tekton 开源项目，并且在 Red Hat OpenShift 订阅中无需额外费用。在本章中，我们将带你逐步了解如何安装和使用它。通过学习，你将明白它如何在 DevOps 流水线和自动化中发挥作用。

在 第五章，OpenShift 部署 后，你应该在环境中有一个正在运行的 OpenShift 集群。我们将在本章中使用该集群来实现一些练习。如果你没有可用的 OpenShift 集群，你可以使用 CodeReady Containers（CRC）作为实验室。在这里，你可以使用一个全功能的虚拟机快速本地运行 OpenShift 集群。

本章将涵盖以下主题：

什么是 OpenShift Pipelines？
安装 OpenShift Pipelines
从零开始创建 Tekton 流水线
使用 GitHub Webhook 触发器
修复由于 YAML 问题导致的 PipelineRun 失败

技术要求

如我们之前提到的，OpenShift Pipelines 是一个 Kubernetes 原生应用，因此它是一个轻量级工具，使用 自定义资源定义（CRDs）来扩展 OpenShift API 的功能。在接下来的章节中，你将看到安装过程非常简单，只需要安装一个 Operator——一种 “下一步，下一步，完成” 的体验。要能够安装并运行本章中的练习，你只需要一个具有以下可用资源的 OpenShift 集群：

2 vCPU
2 GB RAM

如果你没有可用的 OpenShift 集群，我们建议你尝试 CRC（CodeReady Containers），在你的机器上本地启动一个集群。要使用 CRC，你需要在工作站上满足以下系统要求：

4 个物理 CPU 核心（AMD64 或 Intel 64）
9 GB 可用内存
35 GB 存储空间
以下操作系统之一：
- Windows（Windows 10 Fall Creators 更新版或更高版本）
- macOS（10.14 Mojave 或更高版本）
- Linux（Red Hat Enterprise Linux/CentOS 7.5 或更高版本，以及最新两个稳定版 Fedora 发行版）
- Linux（Ubuntu 18.04 LTS 或更新版本以及 Debian 10 或更新版本 未正式支持，可能需要你手动设置主机）

本章使用的源代码可在 github.com/PacktPublishing/OpenShift-Multi-Cluster-Management-Handbook/tree/main/chapter09 中获取。

在本节中，我们将演示如何使用 Linux（Fedora）工作站安装和使用 CRC。有关 Windows 或 macOS 上安装过程的更多信息，请参考以下网站：crc.dev/crc/。

什么是 CRD？

CRD（自定义资源定义）是一个 Kubernetes 资源，它允许你通过定义自定义实体来扩展 Kubernetes API。CRD 由一个名称和一个指定 API 属性的模式组成。

安装和使用 CRC

CRC 安装过程很简单——你需要在你的系统中安装以下软件包：

$ sudo yum install NetworkManager libvirt –y

安装 CRC，请按照以下步骤操作：

在console.redhat.com/openshift/create/local下载适合你平台的 CRC 最新版本。
提取存档文件的内容。
在终端中，进入你提取存档文件的路径。
运行以下命令以设置 CRC：
```
$ ./crc setup
```
如果你想设置一些参数，例如可供 CRC 使用的 CPU 和内存数量，请运行以下代码：
```
$ ./crc config set cpus 4
$ ./crc config set memory 20480
```
通过运行以下命令启动 CRC：
```
$ ./crc start
```

完全启动集群可能需要最多 20 分钟。完成后，你将看到类似以下的屏幕：

图 9.1 – CRC 启动

现在你已经启动了 CRC 或其他 OpenShift 集群，我们准备介绍 OpenShift Pipelines，并了解你可以用它做些什么。

什么是 OpenShift Pipelines？

现在你已经有了一个实验环境，让我们启动引擎，驶向 OpenShift Pipelines！正如我们之前提到的，OpenShift Pipelines 是 Red Hat 对 Tekton 开源项目的实现。让我们了解一下 Tekton 是什么，它与市场上其他 CI/CD 流水线工具有何不同。

什么是 Tekton？

Tekton 提供了一个框架，使得快速且轻松地创建 Kubernetes 原生的 CI/CD 流水线成为可能。它通过 CRD 扩展了 Kubernetes API 功能，并添加了一些自定义对象，用于实现 CI/CD 流水线。你还可以将 Tekton 与行业标准的 CI/CD 流水线工具（如 Jenkins、GitLab CI 等）集成，以便为每种情况选择最佳技术。

Tekton 是 持续交付基金会 的一部分，该基金会得到了 AWS、Red Hat、Google、Netflix 等大型公司的支持。这通常是一个项目有长期生命力和稳定性的好兆头——这是企业在做投资决策时的重要因素。

主要优点

使用 Tekton 可以为你带来许多好处，具体包括以下几点：

Tekton 可以看作是一个无服务器的 CI/CD 流水线系统，通过按需消耗资源并使用隔离的容器，从而可能减少与 CI/CD 工具相关的基础设施或云端成本。
它与 Kubernetes 紧密集成，作为 Kubernetes 的扩展通过 CRD（自定义资源定义）进行工作。这意味着你无需在 CI/CD 工具与 OpenShift 之间进行复杂的集成，节省时间和资源。
上述两个方面还意味着，你不需要额外的人力资源来部署、支持和维护 CI/CD 工具。
作为一个 Kubernetes 原生工具，你可以通过将一个简单的 YAML 文件应用于 Kubernetes 来定义和运行管道（这与创建 Pod、Service 或 Deployment 的方式相同）。这使得 Tekton 易于使用，并能与其他工具集成，以便构建由多个组件（传统虚拟机、容器、微服务等）组成的复杂管道。
通过将 Tekton 与 Argo CD 集成，你可以构建一个非常强大的技术栈，在这个栈中，Tekton 位于 持续集成 侧，而 Argo CD 负责 持续交付 侧。我们将在 第十章 中详细讨论 Argo CD，OpenShift GitOps – Argo CD。
它是一个真正的开源解决方案，背后有强大的基础支持，这是它将得到持续支持并在未来几年发展的有力证据。

Tekton 组件

在本节中，我们将逐一介绍每个 Tekton 组件。简而言之，主要的 Tekton 组件如下：

Tekton 管道：它由多个 CRD 组成，这些 CRD 是开发和运行 CI/CD 管道的构建块。
Tekton 触发器：这些是监听事件并触发管道或任务的对象。它们通常用于在 GitHub 仓库中的拉取或推送请求后运行管道。
tkn) 与 Tekton 交互。
Tekton 目录：一个由社区驱动的任务仓库，任务可以直接在你的管道中使用。
Tekton 操作员：用于轻松地从 Kubernetes 集群中安装、管理和移除 Tekton。

概念

要学习 Tekton，你需要先理解一些概念：

步骤：一个包含输入集并产生输出集的操作。
任务：一组结构化的步骤，用于执行特定任务，例如克隆 GitHub 仓库或构建源代码。
管道：一组结构化任务，组成一个 CI/CD 管道。
TaskRun：这个对象代表任务的实例化。任务是其通用定义，而 TaskRun 则定义了输入参数及运行该任务所需的其他组件。
PipelineRun：这类似于 TaskRun，但用于管道。

为了深入理解这些概念，我们将通过一个示例，构建并运行一个有意义的管道。

安装 OpenShift Pipelines

安装过程非常简单，正如你将在以下步骤中看到的那样。

前提条件

你必须具有集群管理员权限才能访问 OpenShift 集群。

安装

按照以下步骤操作：

从管理员视角访问 OpenShift Web 控制台。
导航至 Operators | OperatorHub：

图 9.2 – OperatorHub

使用 按关键词过滤 框搜索 OpenShift Pipelines：

图 9.3 – Red Hat OpenShift Pipelines 在 OperatorHub 上

点击Red Hat OpenShift Pipelines图标，然后点击安装按钮，进入安装操作符界面：

图 9.4 – 安装 OpenShift Pipelines

现在，选择 openshift-operators 命名空间并允许操作符在任何目标命名空间中安装 OpenShift Pipelines 实例。
选择自动或手动作为升级的批准策略。如果选择自动，升级将在操作符生命周期管理器（OLM）发布后自动执行；而如果选择手动，则需要在应用之前批准它。
选择更新频道选项。推荐选择稳定频道，因为它包含最新的稳定且受支持版本的操作符。
点击安装按钮：

图 9.5 – 安装操作符

等待最多 5 分钟，直到看到以下消息：

图 9.6 – 操作符已安装

安装 OpenShift Pipelines 后，我们建议您安装 tkn CLI 来帮助完成常见任务。让我们学习如何安装 tkn CLI。

安装 tkn CLI

tkn 是一个 CLI 工具，它使得与 Tekton 的工作变得更加容易。通过它，您可以管理（列出、删除、描述、获取日志等）任务、流水线、触发器以及所有可用的 Tekton 对象。

要安装 tkn CLI，请按照以下步骤操作：

下载 tkn，方法是点击 OpenShift Web 控制台中的问号图标后提供的 URL 链接，如下所示：

图 9.7 – 帮助菜单 | 命令行工具

下载适用于您的工作站的客户端：

图 9.8 – tkn 下载链接

下载到您的机器后，您需要解压并将其添加到路径中：

$ tar -xvzf tkn-linux-amd64-0.17.2.tar.gz
$ sudo cp tkn /usr/local/bin

如果一切顺利，运行 tkn version 后将看到以下输出。忽略警告消息，它会提示流水线版本；这是预期中的消息，因为我们还没有登录任何 OpenShift 集群：
```
$ tkn version
Client version: 0.17.2
Pipeline version: unknown, pipeline controller may be installed in another namespace please use tkn version -n {namespace}
```

现在您已经安装了 OpenShift Pipelines 和 tkn，让我们利用它们从零开始创建一个流水线。在接下来的章节中，我们将通过实际操作学习 Tekton 的主要概念。

从零开始创建 Tekton 流水线

在本节中，我们将从零开始创建一个 Tekton 流水线，以便我们从中学习。我们将使用我们 GitHub 仓库中的一个示例：github.com/PacktPublishing/OpenShift-Multi-Cluster-Management-Handbook。为了实践我们将在此覆盖的概念，请将此仓库分叉到您的 GitHub 账户，并按照本章中的说明进行操作。

我们将要处理的流水线很简单，但很有帮助。它将由以下任务组成：

图 9.9 – 构建和部署流水线

在接下来的几个章节中，你将学习如何使用 Tasks、TaskRuns、Pipelines 和 PipelineRuns，这些是 Tekton 的主要对象。

任务

要创建这个流水线，你需要理解任务的基础概念。如前所述，任务提供了一组结构化的步骤来执行某个特定的操作，例如克隆 GitHub 仓库或构建源代码。现在，让我们更深入地了解它的一些重要方面。你需要理解的第一个重要方面是任务范围，它定义了你是否需要使用 Task 还是 ClusterTask：

任务：任务仅在特定的命名空间中可用。你通常会使用任务来执行特定于某个应用程序的操作。
ClusterTask：这与任务相同，但可以在任何命名空间中使用。它们通常用于可以应用于任何应用程序的通用操作。

在我们的示例中，我们将使用 Tasks 和 ClusterTasks 来理解它们是如何工作的以及它们之间的区别。一个任务包含以下元素，我们将在示例中使用它们：

参数：运行任务所需的参数。
资源：这包括由 PipelineResources 对象提供的输入或输出资源。我们建议你使用工作空间而不是 PipelineResources，因为后者更难以排查故障，使任务的重用性降低，限制更多。因此，我们在示例中不会使用 PipelineResources。
步骤：在这里你定义将在任务中执行的操作。你需要使用一个容器镜像来运行这些操作。
工作空间：这是一个用于定义流水线中不同任务之间共享存储卷的工件。工作空间可以用于不同的目的，例如在不同任务之间共享数据、配置的挂载点（使用 ConfigMaps）、凭证和敏感数据（使用 Secrets），以及存储在不同任务和流水线之间共享的可重用工件。工作空间对于缓存工件以加速构建和其他作业也非常有用。
结果：这些是字符串类型的结果变量，可以传递给流水线中的其他任务。

在我们的示例流水线中，我们将重用现有的任务来克隆 GitHub 仓库并构建源代码。最后两个任务我们将专门为流水线创建的自定义任务。

重用任务

首先，让我们学习如何搜索和重用任务来构建流水线。

第一个可以查看现有任务的地方是你的本地 OpenShift 集群。当你安装 OpenShift Pipelines 时，多个 tkn CLI 或 OpenShift UI 中会包含这些任务。

以下代码展示了如何使用 tkn：

# You need to login at the cluster first using "oc login"
$ oc login -u <user> https://<ocp-api-url>:6443
$ tkn clustertasks ls

以下是一些示例输出：

$ oc login -u kubeadmin https://api.crc.testing:6443
(.. omitted ..)
$ tkn clustertasks ls
NAME               DESCRIPTION              AGE
buildah            Buildah task builds...   2 days ago
buildah-1-5-0      Buildah task builds...   2 days ago
git-cli            This task can be us...   2 days ago
git-clone          These Tasks are Git...   2 days ago
(.. omitted ..)

要通过 OpenShift UI 执行相同操作，请转到 tkn CLI：

图 9.10 – 可重用的 ClusterTasks

另一个寻找并重用现有任务的好工具是 Tekton Hub。我们稍后将使用它来扩展我们的示例，并使用 YAML Lint 工具验证我们的 YAML 文件。

备注

Tekton Hub 是一个 Web 门户，您可以在其中获取 Tekton Catalog 中的可重用资产。可以通过 hub.tekton.dev/ 访问。

YAML Lint 是一个工具，用于验证 YAML 文件的语法，检查缩进、尾随空格以及其他许多可能的问题。了解更多信息，请访问 yamllint.readthedocs.io/en/stable/。

使用 ClusterTasks，我们决定重用以下内容：

git-clone：从 GitHub 仓库克隆源代码
buildah：构建源代码并生成容器镜像。

现在，让我们学习如何为需要特定功能时创建一个自定义任务。

创建一个新的（自定义）任务

定义一个新任务和创建一个 Pod 或部署一样简单。对于我们的示例，我们需要创建三个新任务：

apply-manifests：该任务将负责应用一些 K8s manifest 文件，这些文件将部署应用程序。
update-deployment：该任务将更新部署，用构建任务中生成的容器镜像替换现有镜像。
check-app-health：该任务检查应用程序 Pod 的状态和 URL，验证应用程序是否可以访问。

让我们创建这些任务，查看它们的内容，并从中学习：

apiVersion: tekton.dev/v1beta1 
kind: Task #[1]
metadata:
  name: apply-manifests #[2]
spec:
  workspaces: #[3]
  - name: source
  params: #[4]
  - name: manifest_dir
    description: The directory in the source that contains yaml manifests
    type: string
    default: "k8s"
  steps: #[5]
    - name: apply
      image: image-registry.openshift-image-registry.svc:5000/openshift/cli:latest #[6]
      workingDir: /workspace/source
#[7]
      command: ["/bin/bash", "-c"]
      args:
        - |-
          echo Applying manifests in $(inputs.params.manifest_dir) directory
          oc apply -f $(inputs.params.manifest_dir)
          echo -----------------------------------

在前面的代码中，我们用数字标出了某些部分。让我们来看看：

[1]: 这种对象定义了一个新的 Tekton 任务。
[2]: 任务的名称。
git-clone 任务（第一个任务）。
[4]: 运行任务所需的参数。
[5]: 执行任务时所执行的步骤。
step 命令。
[7]: 执行所需操作的命令 —— 在本例中，应用 k8s manifest 文件。

现在我们已经了解了任务的结构，让我们在示例环境中创建它，并使用另一个对象 —— TestRun 来运行它：

为我们的示例创建一个新项目：
```
$ oc new-project pipelines-sample
```

现在，检查管道的服务帐户是否已自动创建：

$ oc get serviceaccount pipeline 
NAME       SECRETS   AGE
pipeline   2         33s

在 pipelines-sample 命名空间中创建 apply-manifest 任务：

$ oc apply -f  https://github.com/PacktPublishing/OpenShift-Multi-Cluster-Management-Handbook/blob/main/chapter09/Tasks/apply-manifests.yaml
task.tekton.dev/apply-manifests created

使用 tkn 确认任务已创建：

$ tkn tasks ls
NAME              DESCRIPTION   AGE
apply-manifests                 17 seconds ago

现在，让我们创建其他自定义任务（update-image-version 和 check-route-health）：

$ oc apply -f  https://github.com/PacktPublishing/OpenShift-Multi-Cluster-Management-Handbook/blob/main/chapter09/Tasks/update-image-version.yaml
$ oc apply -f  https://github.com/PacktPublishing/OpenShift-Multi-Cluster-Management-Handbook/blob/main/chapter09/Tasks/check-route-health.yaml
$ tkn tasks ls
NAME              DESCRIPTION   AGE
apply-manifests                 17 seconds ago
heck-app-health                     10 seconds ago
update-deployment                 8 seconds ago

现在我们已经创建了自定义任务，让我们学习如何使用 TaskRun 对象来运行和测试它们。

TaskRun

我们的任务需要一个持久卷来存储来自 GitHub 的源代码。因此，在运行 TaskRun 之前，我们需要创建一个PersistentVolumeClaim。请注意，你需要一个StorageClass来自动为你提供PersistentVolume。如果没有，PersistentVolumeClaim 将处于待定状态，等待手动创建 PersistentVolume。

运行以下命令以创建 PersistentVolumeClaim：

$ oc apply -f https://github.com/PacktPublishing/OpenShift-Multi-Cluster-Management-Handbook/blob/main/chapter09/PipelineRun/pvc.yaml

现在，我们必须创建两个 TaskRuns。在第一个中，我们将使用git-clone集群任务克隆 GitHub 仓库，并将其存储在使用持久卷的工作区中。在第二个中，我们将使用之前创建的自定义任务，通过应用一些清单（apply-manifests任务）来部署应用。

以下代码展示了一个 TaskRun 的结构：

apiVersion: tekton.dev/v1beta1 
kind: TaskRun 
metadata: 
  name: git-clone #[1]
spec: 
  taskRef: 
    name: git-clone #[2]
    kind: ClusterTask #[3]
  params: #[4]
  - name: url 
    value: "https://github.com/PacktPublishing/OpenShift-Multi-Cluster-Management-Handbook"
  - name: subdirectory 
    value: "" 
  - name: deleteExisting 
    value: "true" 
  - name: revision 
    value: "main" 
  workspaces: #[5]
  - name: output 
    persistentVolumeClaim: 
      claimName: source-pvc

让我们更详细地看看这段代码：

TaskRun对象
[2]：将要运行的任务名称
ClusterTask，但对于常规任务可以省略
[4]：在任务执行过程中使用的参数值
[5]：要使用的工作区

运行以下命令以应用TaskRun对象：

$ oc apply -f https://github.com/PacktPublishing/OpenShift-Multi-Cluster-Management-Handbook/blob/main/chapter09/Tasks/git-clone-taskrun.yaml

一旦你创建了git-clone对象，就可以使用以下tkn命令查看日志：

$ tkn taskrun logs git-clone -f
[clone] + '[' false = true ']'
[clone] + '[' false = true ']'
[clone] + CHECKOUT_DIR=/workspace/output/
[clone] + '[' true = true ']'
[clone] + cleandir
[clone] + '[' -d /workspace/output/ ']'
(.. ommited ..)

最后，使用以下的 TaskRun 运行apply-manifests：

$ oc apply -f https://github.com/PacktPublishing/OpenShift-Multi-Cluster-Management-Handbook/blob/main/chapter09/Tasks/apply-manifests-taskrun.yaml

查看日志，如下所示：

$ tkn taskrun logs run-apply-manifests -f
[apply] Applying manifests in ./sample-go-app/articles-api/k8s directory
[apply] deployment.apps/clouds-api created
[apply] service/clouds-api created
[apply] route/clouds-api created

通过这个，你已经学会了如何使用TaskRun对象运行特定任务。你也知道如何重用并创建自定义任务。我们将利用这些知识来创建我们的第一个管道。

管道

在这一部分，我们将创建我们的第一个有意义的管道！我喜欢把管道的设计比作一个乐高®玩具套件，在组装之前，你需要手头有所有的零件。如果乐高套件太大，无法一次性组装完成，你需要将它分解成更小、更有意义的部分。在我们的管道中，乐高零件是我们已经构建的任务以及我们将要重用的任务。我们已经拥有所需的一切，那么让我们组装我们的乐高套件吧。

我们将通过我们的示例来理解如何定义一个管道对象。任何管道的第一部分是其元数据：

apiVersion: tekton.dev/v1beta1
kind: Pipeline
metadata:
  name: build-and-deploy

下一部分是它的规格（spec），包括以下项目：

工作区：这是一个共享工作区，用于存储源代码和需要在任务之间传递的其他管道工件：
```
spec:
  workspaces:
  - name: shared-workspace
```

参数：这些是运行管道所需的输入参数：

  params:
  - name: deployment-name
    type: string
    description: name of the deployment to be patched
  - name: git-url
    type: string
    description: url of the git repo for the code of deployment
  - name: git-revision
    type: string
    description: revision to be used from repo of the code for deployment
    default: "master"
  - name: IMAGE
    type: string
    description: image to be built from the code

taskRef（将使用的任务的引用），如下所示：

- name: apply-manifests
  taskRef:
    name: apply-manifests
  workspaces:
  - name: source
    workspace: shared-workspace
  runAfter:
  - build-image

对于taskRef组中的kind属性，如下所示：

- name: fetch-repository
  taskRef:
    name: git-clone
    kind: ClusterTask
  workspaces:
  - name: output
    workspace: shared-workspace
  params:
  - name: url
    value: $(params.git-url)
  - name: subdirectory
    value: ""
  - name: deleteExisting
    value: "true"
  - name: revision
    value: $(params.git-revision)

你可以在github.com/PacktPublishing/OpenShift-Multi-Cluster-Management-Handbook/blob/main/chapter06找到完整的管道。

现在，我们准备创建我们的管道。为此，运行以下命令：

$ oc apply -f https://github.com/PacktPublishing/OpenShift-Multi-Cluster-Management-Handbook/blob/main/chapter09/Pipeline/build-deploy.yaml
$ tkn pipelines ls
NAME               AGE            LAST RUN   STARTED   DURATION   STATUS
build-and-deploy   1 minute ago   ---        ---

现在我们已经定义了我们的管道，让我们运行它吧！

PipelineRun

有多种方法可以运行流水线：通过 OpenShift 控制台 UI、使用 tkn，或者手动创建并应用 PipelineRun 对象。归根结底，无论你使用哪种方式，都会创建一个 PipelineRun（唯一的区别是，当你使用 tkn 或 Web UI 时，PipelineRun 会自动为你创建）。为了教学目的，我们将通过使用 PipelineRun 对象来学习和理解它。

以下代码展示了我们的 PipelineRun 对象：

apiVersion: tekton.dev/v1beta1
kind: PipelineRun
metadata:
  name: build-deploy-api-pipelinerun #[1]
spec:
  pipelineRef:
    name: build-and-deploy #[2]
  params: #[3]
  - name: deployment-name
    value: clouds-api
  - name: git-url
    value: https://github.com/PacktPublishing/OpenShift-Multi-Cluster-Management-Handbook.git
  - name: IMAGE
    value:  image-registry.openshift-image-registry.svc:5000/pipelines-sample/clouds-api
  workspaces: #[4]
  - name: shared-workspace
    volumeClaimTemplate:
      spec:
        accessModes:
          - ReadWriteOnce
        resources:
          requests:
            storage: 500Mi

让我们更详细地看一下这段代码：

PipelineRun 对象
[2]：要运行的流水线
[3]：将与流水线一起使用的参数值
[4]：工作空间的定义

应用 PipelineRun 对象并检查日志，查看流水线的执行情况：

$ oc apply -f https://github.com/PacktPublishing/OpenShift-Multi-Cluster-Management-Handbook/blob/main/chapter09/PipelineRun/clouds-api-build-deploy.yaml
$ tkn pipelinerun logs build-deploy-api-pipelinerun -f
[fetch-repository : clone] + '[' false = true ']'
[fetch-repository : clone] + '[' false = true ']'
[fetch-repository : clone] + CHECKOUT_DIR=/workspace/output/
(.. omitted ..)
[check-app-health : apply] Waiting for application articles-api to be ready.
[check-app-health : apply] Checking if application is available at the route endpoint
[check-app-health : apply] Application is available at http://articles-api-pipelines-sample.apps.cluster-gf.gf.sandbox1171.opentlc.com/cloud
[check-app-health : apply] ----------------------------------

这样，你就有了自定义任务和已经经过测试并正常工作的流水线。现在，我们通过使用触发器，在仓库中发生 Git 推送时自动运行这个流水线，进一步提升它的效果。

使用 GitHub Webhook 触发器

在 CI/CD 工作流中，通常使用某个事件（如 Git 上的拉取或推送请求）来触发新的流水线运行。在 Tekton 中，你可以使用EventListeners来监听事件并运行一个或多个触发器。针对以下平台，提供了一些现成的事件处理器，称为拦截器：

GitHub：这允许你验证和筛选 GitHub Webhook。
GitLab：与之前提到的内容类似，不过是针对 GitLab 的设置。
Bitbucket：与之前提到的 Bitbucket 的设置相同。
CEL：这允许你使用 通用表达式语言（CEL）来筛选和修改有效负载。
Webhook：这允许你处理任何 Webhook 有效负载并应用任何业务逻辑。

在我们的示例中，我们将使用 GitHub 拦截器来处理 Webhook，筛选推送事件，并触发我们之前创建的流水线。你还可以通过实现一个名为 ClusterInterceptors 的对象来实现自定义拦截器。如果你需要创建 ClusterInterceptor 或使用除 GitHub 以外的任何拦截器，请查看“进一步阅读”部分中的链接。

请注意，GitHub Webhook 需要一个公开可访问的 URL 来发送 HTTP Webhook 请求。因此，你需要一个具有公网 IP 和域名的 OpenShift 集群，能够从互联网上访问。也就是说，在这种情况下，除非你将 CRC URL 路由公开到互联网上，否则无法使用 CRC 来测试 Tekton 触发器与 GitHub Webhook。

什么是 CEL？

CEL 是一种简单但快速且可移植的表达式评估语言。由一些谷歌工程师创建并维护，它是一个开源项目，已根据 Apache 许可证发布，并广泛应用于谷歌的许多项目和服务中。欲了解更多信息，请访问 opensource.google/projects/cel。

除了 EventListener，Tekton 触发器还由其他几个对象组成：

Trigger：这定义了在 EventListener 检测到新事件后将执行的操作。
TriggerTemplate：这指定了作为触发器结果应用的对象蓝图，通常使用 PipelineRun 对象，该对象将运行一个管道。
TriggerBinding：这定义了将从事件负载中提取的字段数据，用于与相关的 PipelineRun 一起使用。
ClusterTriggerBinding：这与 TriggerBinding 相同，但它是集群范围的。可以在不同命名空间之间重用。

以下对象将用于我们的示例：

图 9.11 – Tekton 触发器对象

现在，让我们将其付诸实践！你已经在实验室中创建了任务和管道，接下来让我们创建将使用现有管道的触发器对象。

TriggerBinding

TriggerBinding 将解析从 GitHub 负载中提取的数据，如下所示：

apiVersion: triggers.tekton.dev/v1beta1
kind: TriggerBinding
metadata:
  name: clouds-api-tb #[1]
spec:
  params: #[2]
  - name: git-repo-url
    value: $(body.repository.url)
  - name: git-repo-name
    value: $(body.repository.name)
  - name: git-revision
    value: $(body.head_commit.id)

让我们更详细地看看这段代码：

TriggerBinding 对象
[2]：将根据负载数据字段分配的参数。

使用以下命令创建 TriggerBinding：

$ oc apply -f https://raw.githubusercontent.com/

我们需要创建的下一个对象是 TriggerTemplate。让我们来看看。

TriggerTemplate

TriggerTemplate 将创建一个 PipelineRun 来执行我们的示例管道：

apiVersion: triggers.tekton.dev/v1beta1
kind: TriggerTemplate
metadata:
  name: clouds-api-tt #[1]
spec: 
  params: #[2]
  - name: git-repo-url
    description: The git repository url
  - name: git-revision
    description: The git revision
    default: master
  - name: git-repo-name
    description: The name of the deployment to be created / patched
  resourcetemplates: #[3]
  - apiVersion: tekton.dev/v1beta1
    kind: PipelineRun
    metadata:
      generateName: build-deploy-
    spec:
      serviceAccountName: pipeline
      pipelineRef:
        name: build-and-deploy
      params:
      - name: deployment-name
        value: clouds-api
      - name: git-url
        value: $(tt.params.git-repo-url)
      - name: git-revision
        value: $(tt.params.git-revision)
      - name: IMAGE
        value: image-registry.openshift-image-registry.svc:5000/pipelines-sample/clouds-api
      workspaces:
      - name: shared-workspace
        volumeClaimTemplate:
          spec:
            accessModes:
              - ReadWriteOnce
            resources:
              requests:
                storage: 500Mi

让我们更详细地看看这段代码：

TriggerTemplate 对象
TriggerBinding 对象
[3]：作为触发器结果将创建的对象。

使用以下命令创建 TriggerTemplate 对象：

$ oc apply -f https://github.com/PacktPublishing/OpenShift-Multi-Cluster-Management-Handbook/blob/main/chapter09/Trigger/clouds-api-tt.yaml

最后，我们可以创建 Trigger 对象，它将使用我们已经创建的所有对象。

Trigger

Trigger 对象将作为 GitHub 拦截器、TriggerBinding 和 TriggerTemplate 之间的连接：

apiVersion: triggers.tekton.dev/v1beta1
kind: Trigger
metadata:
  name: clouds-api-trigger #[1]
spec:
  serviceAccountName: pipeline
  interceptors: #[2]
    - ref:
        name: "github" #[3]
      params:
        - name: "secretRef" #[4]
          value:
            secretName: github-secret
            secretKey: secretToken
        - name: "eventTypes"
          value: ["push"] #[5]
  bindings:
    - ref: clouds-api-tb #[6]
  template:
    ref: clouds-api-tt #[7]

让我们更详细地看看这段代码：

Trigger 对象。
[2]：将用于触发操作的事件拦截器列表。
[3]：来自 GitHub 的拦截器。
[4]：在 GitHub webhook 中配置的 secret。
[5]：Tekton 将响应的触发事件类型。在此情况下，它将是 GitHub 的“push”事件。
将与此触发器一起使用的 TriggerBinding 对象。
将与此触发器一起使用的 TriggerTemplate 对象。

以下代码展示了 GitHub secret 的示例 ([4])：

apiVersion: v1
kind: Secret
metadata:
  name: github-secret
type: Opaque
stringData:
  secretToken: "tekton"

使用以下命令创建 secret 和触发器：

$ oc apply -f https://github.com/PacktPublishing/OpenShift-Multi-Cluster-Management-Handbook/blob/main/chapter09/Trigger/clouds-api-trigger.yaml

我们需要创建的最后一个对象是 EventListener，它将使触发器生效。让我们来看看。

EventListener

最后，我们需要创建一个 EventListener 对象，它将监听 HTTP 请求并与 GitHub webhook 配置一起使用。我们很快就会学习如何配置 GitHub webhook：

apiVersion: triggers.tekton.dev/v1beta1
kind: EventListener
metadata:
  name: clouds-api-el #[1]
spec:
  serviceAccountName: pipeline
  triggers:
    - triggerRef: vote-trigger #[2]

让我们更详细地看看这段代码：

EventListener 对象
EventListener 对象已激活

运行以下命令来创建 EventListener 对象：

$ oc apply -f https://github.com/PacktPublishing/OpenShift-Multi-Cluster-Management-Handbook/blob/main/chapter09/Trigger/clouds-api-el.yaml

EventListener 会在 OpenShift 上创建一个服务，你需要将其暴露到外部。生成的路由 URL 将在 GitHub webhook 配置过程中使用：

$ oc expose svc el-clouds-api-el

现在，我们准备配置一个新的 GitHub webhook，它将使用我们刚刚创建的 EventListener 对象来触发 Tekton 的 trigger。

创建 GitHub webhook

为了创建 webhook，你需要 fork 我们的 GitHub 仓库。如果你还没有 fork，可以在你的个人 GitHub 账户中现在就进行：github.com/PacktPublishing/OpenShift-Multi-Cluster-Management-Handbook。

打开 GitHub fork 的仓库并进入 Settings | Webhook。在接下来的页面上，点击 Add webhook 按钮：

图 9.12 – 在 GitHub 上添加 webhook

填写表单并提供以下信息：

Payload URL：我们在前一部分创建的路由 URL。你可以通过运行以下命令获取此 URL：
```
$ echo "$(oc  get route el-clouds-api-el --template='http://{{.spec.host}}')"
```
application/json。
tekton):

图 9.13 – 在 GitHub 上添加 webhook

几秒钟后，你应该能看到我们创建的 webhook 旁边出现一个绿色的勾号：

图 9.14 – 已添加 webhook

现在，我们已经在 Tekton 侧配置了 Trigger 对象，并在 GitHub 上配置了 webhook，接下来进行测试！

测试 Tekton trigger

执行 commit 并将 trigger 推送到 webhook 事件，如下所示：

$ git commit -m "empty-commit" --allow-empty && git push origin main

访问已运行 push 命令：

图 9.15 – 在 Red Hat 上的 PipelineRun

恭喜你！你已经成功在 Tekton 上创建了一个 CI/CD 管道，并在 Git push 事件触发后自动运行了它！为了总结本章内容，我们将通过使用 YAML linter 工具添加一个 YAML 文件验证任务来增强我们的管道。

为此，我们将使用 Tekton Hub 查找一个可重用的任务。访问 hub.tekton.dev/，并在屏幕右上角的搜索框中搜索 YAML：

图 9.16 – Tekton Hub

点击 YAML linter 任务以查看如何安装和使用它的说明：

图 9.17 – YAML linter

这一次，我们将使用 Pipeline Builder 页面来添加 YAML linter 任务。为此，访问 OpenShift UI 并选择 Developer 控制台：

图 9.18 – 开发者控制台

现在，执行以下步骤：

访问 build-and-deploy 管道：

图 9.19 – Pipelines 菜单

现在，点击 Actions 按钮，然后点击 Edit Pipeline：

图 9.20 – 构建和部署管道

在接下来的屏幕上，点击 fetch-repository 框，然后点击它旁边的 + 按钮：

图 9.21 – 流水线构建器功能

选择 yaml lint，然后点击 安装并添加 按钮：

图 9.22 – 使用流水线构建器功能添加新任务

新任务应该已经添加。你应该能看到它旁边有一个感叹号：

图 9.23 – 使用流水线构建器功能添加新任务

现在，点击它并输入 ./sample-go-app/clouds-api/k8s 作为 Workspaces 组中的 shared-workspace：

图 9.24 – 设置 yaml-lint 任务的参数

现在，点击保存。
此时，我们的流水线有了一个新步骤，用于验证 Kubernetes 清单文件的 YAML 内容。为了测试我们之前的更改，让我们从相同的 Web UI 中运行它。为此，请点击 Pipeline details 屏幕上的 Actions 菜单，并选择 Start 动作：

图 9.25 – 从开发者控制台运行流水线

使用以下值填写表单并点击 clouds-api：
git-url:
main
image-registry.openshift-image-registry.svc:5000/pipelines-sample/clouds-api
./sample-go-app/clouds-api/
VolumeClaimTemplate：

图 9.26 – PipelineRun 参数

检查以下屏幕上的 PipelineRun 对象，你会看到关于我们添加的新 yaml-lint 任务的错误：

图 9.27 – 因 YAML linter 校验失败而导致的 PipelineRun 失败

点击 yaml-lint 步骤并查看日志以找到问题：

图 9.28 – 因 YAML linter 校验失败而导致的 PipelineRun 失败

如你所见，YAML linter 检测到了一些 YAML 文件中的错误。这些错误是预期中的，特别为你准备，以模拟真实的 CI/CD 流水线。现在，运用你刚刚学到的技能，修复这些错误并重新让流水线工作起来（或者查看下一节的解决方案）！

修复由于 YAML 问题导致的 PipelineRun 失败

为了让你的流水线重新工作，按照以下步骤操作：

在 ./sample-go-app/clouds-api/k8s 文件夹中的所有 YAML 文件的第一行添加 ---。

修正 kustomization.yaml 文件的缩进，在 resources 后面的所有行前添加两个空格，如下所示：

---
resources:
  - deployment.yaml #add two spaces at the begging of the line
  - service.yaml #add two spaces at the begging of the line
  - route.yaml #add two spaces at the begging of the line

在 service.yaml 文件的末尾添加一行。

提交并推送更改：

$ git add *
$ git commit -m "fixed yaml files"
$ git push

一个新的 PipelineRun 应该自动触发并完成。

总结

本章中，我们深入了解了 Tekton，从在 OpenShift 上安装到使用它。你学习了如何创建自定义任务、重用现有任务、构建流水线并运行它。你还学习了如何设置触发器，在你的 GitHub 仓库中发生推送事件时运行流水线。本章中介绍的对象是你在创建大多数 Tekton 流水线时将使用的主要对象。

在下一章，我们将通过将Argo CD和GitOps添加到你的流水线中，进一步增强你的 CI/CD 流程。我们还将开始探索如何将应用程序一次性部署到多个集群中。让我们开始，并深入了解 OpenShift GitOps！

进一步阅读

如果你想了解更多关于本章内容的信息，可以查看以下参考资料：

OpenShift Pipelines 官方文档: docs.openshift.com/container-platform/4.9/cicd/pipelines/understanding-openshift-pipelines.html
Tekton 官方文档: tekton.dev/docs/
如何使用ClusterInterceptor创建自定义拦截器: tekton.dev/docs/triggers/clusterinterceptors/
Tekton Hub（可重用任务集合）: hub.tekton.dev/

第十章：OpenShift GitOps – Argo CD

在上一章中，我们学习了如何使用 Tekton 创建和运行管道，以构建和部署应用程序。虽然 Tekton 很适合构建和执行通常与 持续集成 (CI) 相关的其他操作，但 GitOps 正成为 持续部署 (CD) 的标准，尤其是在 Kubernetes 原生应用程序方面。在本章中，我们将深入探讨 GitOps，并讨论其中一个最适合 CD 的工具：Argo CD。

在本章中，我们将讨论以下内容：

什么是 GitOps？
什么是 Argo CD？
应用交付模型
安装 OpenShift GitOps
配置 Argo CD 以支持多个集群
Argo CD 定义和挑战
Argo CD 主要对象
使用 GitOps 部署应用程序
部署到多个集群

让我们开始吧！

注意

本章使用的源代码可以在 github.com/PacktPublishing/OpenShift-Multi-Cluster-Management-Handbook/tree/main/chapter10 获取。

什么是 GitOps？

GitOps 这一术语首次由 Lexis Richardson，Weaveworks 的 CEO，于 2017 年提出。当时，他提出了 GitOps 的四个原则，具体如下：

整个系统是声明性描述的：这意味着应用程序和基础设施的任何配置都需要作为代码来处理，而不是像脚本或自动化代码那样作为一组指令来处理。相反，您必须使用一组事实来描述系统的期望状态。这些声明文件在 Git 中进行版本控制，Git 是你唯一的真理源。这个原则的一个巨大好处是，你可以轻松地部署或回滚应用程序，更重要的是，如果发生灾难，你可以迅速恢复环境。
标准的期望系统状态在 Git 中有版本控制：Git 是你的真理源。它需要成为触发你系统中所有更改的唯一地方。理想情况下，不应直接对系统进行任何操作，而应通过 Git 上的配置更改来实现，这些更改将通过工具如 Argo CD 自动应用。
批准的更改会自动应用到系统中：由于你已经将系统的期望状态存储在 Git 中，任何更改都可以在推送到仓库时自动应用到系统中。
软件代理确保正确性并在偏差时提醒您：拥有确保系统处于所需状态的工具至关重要，这一状态在 Git 中有所描述。如果检测到任何漂移，工具需要能够自我修复应用程序，并将其恢复到所需状态。

GitOps 成为 Kubernetes 和云原生应用程序的标准，因其带来了以下好处：

标准流程和工具：Git 工作流允许团队以协作和可重现的方式工作，避免了与人类重复性任务相关的问题。
强大且安全的过程：通过在 Git 中使用拉取请求（PRs），所有更改都需要经过审查和批准。您还可以跟踪 Git 中的所有更改，并在需要时进行回退。
可审计的更改：所有更改都在 Git 历史中跟踪，并且可以轻松审计。
一致性：您可以在多个不同集群中一致地部署相同的应用程序：

图 10.1 – GitOps 工作流

现在您对 GitOps 有了更好的理解，接下来让我们学习如何将 GitOps 工作流付诸实践。

什么是 Argo CD？

理论上，采用 GitOps 不一定需要使用任何特定工具。您可以通过实现脚本和自动化来使用 Git 中描述系统的声明性文件部署和管理应用程序。然而，这样做会非常耗费成本和时间。幸运的是，目前有一些很棒的 Kubernetes 开源工具，它们稳定且效果良好。在本书撰写时，Kubernetes 的主要工具是Argo CD 和 Flux CD；这两者都是很棒的工具，但在本书中，我们将探索 Argo CD，它无需额外费用，已包含在 Red Hat OpenShift 订阅中。

简而言之，Argo CD 是一个工具，能够读取存储在 Git 仓库中的一组Kubernetes 清单、Helm 图表或 Jsonnet 文件，并将其应用到 Kubernetes 命名空间。虽然 Argo CD 不仅能够应用清单，还能自动化自愈、对象修剪等其他强大功能，正如我们在本章中将要探索的内容。

应用交付模型

现在，您可能会想知道 OpenShift Pipelines（Tekton）和 GitOps（Argo CD）之间有什么关系。Tekton 和 Argo CD 是相辅相成的工具，完美配合。虽然 Tekton 非常适合执行单元测试、构建和生成容器镜像的CI 流水线，但 Argo CD 更适合用于持续交付实践。下图总结了使用 Tekton 和 Argo CD 的 CI/CD 流水线的样子：

图 10.2 – 使用 Tekton 和 Argo CD 的应用交付模型

使用 GitOps 的 CD 意味着应该监控应用程序的实际状态，并且任何更改都需要恢复到应用程序在 Git 仓库中描述的期望状态：

图 10.3 – 使用 GitOps 进行持续交付

在本章中，我们将使用上一章的示例，利用 Argo CD 部署应用程序并实践这一应用交付模型。

安装 OpenShift GitOps

安装过程简单，类似于我们在上一章中讨论的 OpenShift Pipelines 安装过程。

先决条件

要安装 OpenShift GitOps，您需要一个具有集群管理员权限的 OpenShift 集群。

安装

按照以下步骤操作：

使用管理员视角访问OpenShift web 控制台。
导航至操作符 | OperatorHub：

图 10.4 – OperatorHub

使用关键字筛选框搜索 OpenShift GitOps：

图 10.5 – Red Hat OpenShift GitOps 在 OperatorHub 上

点击Red Hat OpenShift GitOps图标，然后点击安装按钮，进入安装页面：

图 10.6 – 安装 OpenShift GitOps

现在，选择 openshift-operators 命名空间，并允许操作符在任何目标命名空间中安装 OpenShift GitOps 实例。
选择自动或手动作为升级的审批策略。如果选择自动，升级将在 Red Hat 发布后，由操作符生命周期管理器(OLM)自动执行；而选择手动时，你需要批准后才能应用升级。
选择一个更新频道。推荐选择稳定频道，因为它包含了操作符的最新稳定和受支持版本。
点击安装按钮：

图 10.7 – 安装操作符

等待最多 5 分钟，直到你看到以下消息：

图 10.8 – 操作符已安装

OpenShift GitOps (Argo CD) 也有一个 CLI，帮助执行常见任务，如更新管理员密码、注册外部集群等。让我们来学习如何安装 argocd CLI。

安装 `argocd` CLI

argocd CLI 使得与 Argo CD 的工作更加便捷。通过它，你可以管理 Argo CD 项目、应用程序、集群凭据等。

要安装 argocd CLI，请按照以下步骤操作：

从 github.com/argoproj/argo-cd/releases/latest 下载最新的 Argo CD 二进制文件。

如果你使用的是 Linux，下载 CLI 并将其添加到你的路径中：

$ sudo curl -sSL -o /usr/local/bin/argocd https://github.com/argoproj/argo-cd/releases/latest/download/argocd-linux-amd64
$ sudo chmod +x /usr/local/bin/argocd

如果一切顺利，运行 argocd version 命令时你将看到如下输出。忽略最后一行的错误信息；它是预期中的消息，因为我们还没有登录到任何 OpenShift 集群：

$ argocd version
argocd: v2.2.1+122ecef
  BuildDate: 2021-12-17T01:31:40Z
  GitCommit: 122ecefc3abfe8b691a08d9f3cecf9a170cc8c37
  GitTreeState: clean
  GoVersion: go1.16.11
  Compiler: gc
  Platform: linux/amd64
FATA[0000] Argo CD server address unspecified

现在，让我们学习如何配置 Argo CD，以便在多个集群中部署应用程序。

配置 Argo CD 用于多个集群

如果你计划使用 Argo CD 将应用程序部署到外部集群，你需要使用 argocd CLI 添加新集群的凭据。如果你只想在安装了 Argo CD 的同一集群中部署应用程序（kubernetes.default.svc 文件已存在，并且应该在这种情况下使用），则可以跳过此步骤。

要注册新集群，请使用你之前安装的 argocd CLI 执行以下步骤：

登录到我们想要注册的新集群：

$ oc login -u <user> https://<api-newcluster>:6443

现在，使用 oc login 登录到安装了 Argo CD 的集群：
```
$ oc login -u <user> https://<api-argocluster>:6443
```

此时，您应该在 kubeconfig 文件中拥有两个集群：

$ oc config get-contexts
CURRENT NAME         CLUSTER    AUTHINFO NAMESPACE
        newcluster   newcluster admin
*       argocluster  argocluster

为新集群设置不同的上下文：

$ oc config set-context prd-cluster --cluster=newcluster --user=admin
Context "prd-cluster" created.

从 openshift-gitops 命名空间获取 Argo CD 公共 URL：

$ oc get route openshift-gitops-server -n openshift-gitops -o jsonpath='{.spec.host}'

获取管理员密码：

$ oc extract secret/openshift-gitops-cluster -n openshift-gitops --to=-

使用 argocd 登录：

$ argocd login --insecure openshift-gitops-server-openshift-gitops.apps.example.com
Username: admin
Password:
'admin:login' logged in successfully
Context ' openshift-gitops-server-openshift-gitops.apps.example.com' updated

现在，将新集群添加到 Argo CD：

argocd cluster add prd-cluster -y
INFO[0000] ServiceAccount "argocd-manager" created in namespace "kube-system"
INFO[0000] ClusterRole "argocd-manager-role" created
INFO[0001] ClusterRoleBinding "argocd-manager-role-binding" created
Cluster 'h https://<api-newcluster>:6443' added

有了这些，您就可以使用 Argo CD 将应用程序部署到本地或远程集群了！但在深入应用程序部署之前，我们先来看一下与 Argo CD 相关的一些重要方面。

Argo CD 定义和挑战

在我们讲解应用程序部署过程之前，我们需要讨论一些与 GitOps、决策和标准相关的重要挑战。

GitHub 仓库结构

GitOps 常见的第一个重要问题是关于 GitHub 仓库结构的。是否应该仅使用一个仓库来存放源代码和 Kubernetes 清单？如何处理不同环境（如开发、QA 和生产）的不同配置文件？

对这些问题没有标准的正确或错误答案，因为每种选项都有其优缺点。您需要找出最适合您的方法。我的建议是：尝试一下！没有什么比实际经验更好的了，所以请使用每个模型，找出最适合您应用程序和团队的方案。在接下来的部分中，我们将讨论一些 GitOps 定向应用程序中最流行的仓库结构。

单一仓库

在这种结构下，您将拥有一个仓库来存放所有 Kubernetes 清单和基础设施相关文件。尽管没有统一的标准来定义这种结构，但您可能会有一个类似以下的仓库：

├── config #[1]
├── environments #[2]
│   ├── dev #[3]
│   │   ├── apps #[4]
│   │   │   └── app-1
│   │   └── env #[5]
│   └── qa #[6]
│   │   ├── apps
│   │   │   └── app-1
│   │   └── env
(...)

让我们更详细地看看这些代码：

#[1]：此文件夹包含 CI/CD 流水线、Argo CD 以及其他相关的配置文件，这些文件对任何环境都是通用的
#[2]：此文件夹包含特定于每个环境的清单文件，如开发、QA 和生产
#[3]：这些是特定于开发环境的清单文件
#[4]：在这里，您可以找到部署应用程序的 Kubernetes 清单，这些应用程序在这个仓库中进行追踪和发布
RoleBinding 权限，Namespace 等等
#[6]：这些是特定于 QA 环境的清单文件

这种方法的主要好处是简洁性：在这种方法中，您只需管理一个仓库来存放一个或多个应用程序，这使得管理分支、标签、PR 以及与应用程序清单仓库相关的任何事务都变得更加容易。然而，这种策略的主要缺点是，所有贡献者都可以读取并更改生产清单。这意味着可能会很难发现对生产环境的无意更改，尤其是对于大型 PR 来说。

这引出了我们下一种方法，在这种方法中，每个环境都有一个不同的代码库。

每个环境一个代码库

使用这种策略，您将拥有多个代码库，每个环境一个。换句话说，您将为开发清单、QA清单等创建不同的代码库。在这种策略下，您可能会使用 PR（Pull Requests）在每个环境之间推广变更，并拥有一个精细的审查过程，从而减少错误的发生。在这种策略下，您还可以根据每个环境管理 Git 权限：

图 10.9 – 每个环境一个代码库

在本章中，我们将采用单一代码库策略，并使用 Git 推送请求和 PR 与多个分支，以减少无意更改的风险。

接下来，我们将讨论与 Kubernetes 上的 GitOps 相关的另一个重要方面：模板化 YAML 文件并避免重复。

模板化 Kubernetes 清单

无论您决定采用什么样的代码库结构，有一点是确定的：您将需要为每个您管理的环境创建单独的文件和文件夹。那么，如何避免到处重复 YAML 清单文件并将 GitOps 过程变成一场噩梦呢？

当前，最流行的做法如下：

Helm：依赖于 Helm Charts 和 Helm Templates 来打包和交付 Kubernetes 应用程序。通过 Helm Templates，您可以将值与模板结合，生成有效的 Kubernetes 清单文件。
Kustomize：使用 Kustomize，您可以通过补丁策略重用现有的清单文件。它采用层次结构，这样您可以灵活地重用共享配置，并创建只包含特定于环境的参数的配置层，这些参数将会覆盖基础参数。

虽然 Helm 是一个很好的打包工具，但由于以下原因，本章将重点讨论 Kustomize：

Kustomize 原生运行在 Kubernetes 和 OpenShift CLI（kubectl/oc）上
它是声明性的，这是 GitOps 的一个重要因素，正如我们之前提到的那样。
您可以使用远程基础代码库作为清单的起始集，并将覆盖存储在不同的代码库中。

让我们更详细地了解 Kustomize。

Kustomize

Kustomize 由层次化的清单文件组成：

Base：这是一个包含始终作为基础清单文件重用的资源的目录。这些资源以声明性方式描述应用程序和对象。
Overlays：这是一个仅包含每个覆盖特定配置的目录。例如，通常会有一个用于开发环境的覆盖，一个用于 QA 的覆盖，等等。存储在overlay目录中的配置会替换base目录中的值。

你可以有多个基础和覆盖层——可以根据需要使用任意数量。然而，为了保持应用清单文件的可读性和可维护性，不建议使用多个清单层次结构。以下图示展示了一个基础和两个覆盖层的示例，可能会与 Kustomize 一起使用：

图 10.10 – Kustomize 层次结构

以下是你在使用 Kustomize 时通常会看到的文件夹结构：

├── base
│   ├── deployment.yaml
│   ├── kustomization.yaml
│   ├── route.yaml
│   └── service.yaml
└── overlays
    ├── dev
    │   ├── deployment-patch.yaml
    │   ├── kustomization.yaml
    │   └── namespace.yaml
    ├── prod
    │   ├── deployment-patch.yaml
    │   ├── kustomization.yaml
    │   └── namespace.yaml
    └── qa
        ├── deployment-patch.yaml
        ├── kustomization.yaml
        └── namespace.yaml

在本章中，我们将在部署示例时进一步练习使用 Kustomize。

管理秘密

最后但同样重要的是，Kubernetes 的真正挑战是使用秘密管理敏感数据。虽然秘密在一定程度上是安全的，但根据用户权限的设置，它们并没有加密。当我们考虑将这些秘密存储在 GitHub 仓库中时，这就成为一个真实的问题。那么，我们该如何安全地处理秘密呢？

处理密码有两种方法：

使用外部保险库安全地存储秘密，避免存储在 Git 和集群中
在将秘密保存在 Git 中之前，使用加密工具（如 Bitnami Sealed Secrets）对其进行加密

备注

1. 密码以 Base64 编码呈现。例如，以下命令解密名为 db-root-password 的密码字段：

oc get secret db-root-password –o jsonpath="{.data.password}" | base64 -d

2. Bitnami Sealed Secrets 允许你将秘密加密为 SealedSecret 对象，并安全存储，即使是在公共 GitHub 仓库中，因为它使用公钥/私钥证书进行加密。欲了解更多信息，请查看 进一步阅读 部分中的链接。

通过这些，我们已经讨论了你在 GitOps 中需要考虑的主要问题。在我们实际示例之前，这些都是我们决定向你介绍的重要话题，但别太担心——你会通过实践和学习，找到最适合你和你团队的方法。在接下来的部分，我们将介绍一些你将在 Argo CD 中使用的主要对象。

Argo CD 主要对象

在本节中，我们将介绍一些你需要了解的主要 Argo CD 对象。Argo CD 相当简单，绝大多数操作可以归纳为两个对象：AppProject 和 Application。

在本节中，我们不会提及 Argo CD 的所有不同对象，因为这不是本书的主要焦点。请查阅 进一步阅读 部分了解更多。

AppProject

项目允许你将应用程序分组，并根据你需要的任何逻辑结构进行组织。使用项目，你可以执行以下操作：

限制可以用来部署应用程序的 Git 源仓库
限制应用程序可以部署到的 集群和命名空间目标
限制可以部署的对象类型（例如，Deployments、Secrets、DaemonSets 等）
设置角色以限制组和/或 JWTs 允许的权限

当安装 Argo CD 时，它会附带一个默认项目。如果在 Argo CD 应用程序中没有指定项目，则将使用默认选项。创建额外的项目是可选的，因为你可以选择使用 Argo CD 的默认项目。然而，建议创建额外的项目，以帮助你更好地组织 Argo CD 应用程序。

注意

Argo CD 的默认项目与 OpenShift 的默认命名空间之间没有关系。尽管它们的名称相同，但它们是没有关联的。

一个典型的AppProject规范如下：

apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
  name: clouds-api #[1]
  namespace: openshift-gitops
spec:
  sourceRepos: #[2]
    - '*'
  destinations: #[3]
    - namespace: '*'
      server: '*'
  clusterResourceWhitelist: #[4]
    - group: '*'
      kind: '*'

让我们更详细地查看这段代码：

[1]：项目的名称。
[2]：允许的 Git 源仓库。在这种情况下，允许任何源仓库。
[3]：允许的目标集群和命名空间。在这种情况下，允许任何集群和命名空间的组合。
[4]：可以部署的对象（例如 Deployments、Secrets、DaemonSets 等）。在这种情况下，没有任何限制。

正确调整代码，以实现清单文件。

应用程序

应用程序代表已由 Argo CD 部署和管理的应用程序实例。应用程序的规范由source和destination组成。source是存放指定应用程序期望状态的 Kubernetes 清单（Git 仓库）的地方，而destination则指定应用程序将要部署的集群和命名空间。此外，你还可以指定希望 Argo CD 应用的同步策略。

以下是一个应用程序规范的示例：

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: clouds-app-dev #[1]
  namespace: openshift-gitops #[2]
spec:
  project: clouds-api #[3]
  source: #[4]
    repoURL: `https://github.com/PacktPublishing/OpenShift-Multi-Cluster-Management-Handbook.git'
    path: chapter10/clouds-api-gitops/overlays/dev
    targetRevision: dev
  destination: #[5]
    server: 'https://kubernetes.default.svc'
    namespace: default
  syncPolicy: #[6]
    automated:
      selfHeal: true

让我们更详细地查看这段代码：

应用程序名称。
openshift-gitops。
AppProject对象。不要将其与 OpenShift 项目混淆，它们没有关系。
[4]：关于 Kubernetes 清单所在位置的 Git 源仓库信息。
[5]：应用程序将要部署的集群和命名空间。
[6]：Argo CD 将使用的同步策略。我们将在下一节中了解这些策略。

重要提示

Argo CD 的命名空间（openshift-gitops）在集群中具有执行所有必要活动的特殊权限。因此，你必须保护对该命名空间的访问，以避免不必要的部署或更改。

同步策略

你可以配置 Argo CD 在 Git 中的清单指定的期望状态与实际应用状态之间出现任何偏差时，自动同步应用程序。你可以使用 Argo CD 提供以下选项：

如果是true，Argo CD 会在检测到 Git 中的清单与实际状态之间的任何差异时自动同步。默认情况下，此标志为false。
将prune标志设置为true。

同步顺序

对于标准的 Kubernetes 清单，Argo CD 已经知道需要应用的正确顺序，以避免优先级问题。例如，考虑一个包含三个清单的应用，分别用于命名空间创建、部署和角色绑定。在这种情况下，Argo CD 将始终按照以下顺序应用这些对象：

命名空间
角色绑定
部署

话虽如此，你不必为此担心，因为 Argo CD 足够智能，能够按照正确的顺序应用它们。

然而，在一些特定的情况下，你可能需要指定对象的优先级。例如，假设你想部署一个由一个 StatefulSet（用于部署数据库）和一个部署（用于使用数据库的应用）组成的应用。在这种情况下，你可以使用资源钩子来指定正确的应用顺序。

可以使用以下类型的资源钩子：

PreSync：标记为PreSync的对象将在任何其他清单之前执行。
Sync：此操作在PreSync完成后运行。你还可以使用sync-wave来设置在Sync阶段中对象的同步优先级。
PostSync：在所有Sync对象应用完并处于健康状态后运行。
SyncFail：带有此注释的清单仅在同步操作失败时执行。

以下是一个资源钩子规范的示例：

apiVersion: apps/v1
kind: Deployment
metadata:
  annotations:
    argocd.argoproj.io/hook: Sync
    argocd.argoproj.io/sync-wave: "1"
(.. omitted ..)

你可以在清单中包含不同类型的注释，以执行更复杂的任务。请查看进一步阅读部分了解更多信息。

到此为止，我们已经涵盖了 GitOps 和 Argo CD 背后最重要的概念和理论。现在，事不宜迟，让我们来看看我们的示例，并实践迄今为止所讨论的内容！

使用 GitOps 部署应用

在这个实际操作中，我们将在三个不同的命名空间中构建并部署我们的示例应用，以模拟由开发、QA 和生产环境组成的应用生命周期。下图展示了我们将在本次练习中使用的交付模型，以便实践 Argo CD 部署。你可以将其作为起点，根据自己的需求构建全面且复杂的 ALM 工作流：

图 10.11 – 使用 Tekton、Argo CD 和 Git 的应用交付模型

再次提醒，我们将使用本书 GitHub 仓库中准备的内容。为此，你必须将此仓库 fork 到你的 GitHub 账号：github.com/PacktPublishing/OpenShift-Multi-Cluster-Management-Handbook。一旦你完成 fork，请按照本节中的说明操作，将此工作流付诸实践。

构建一个新的镜像版本

在本节中，我们将构建一个新的容器镜像版本 1.0，并将其推送到 OpenShift 内部注册表，如下图所示：

图 10.12 – 构建新镜像版本

为此，请执行以下步骤：

在你的机器上克隆该仓库：

$ GITHUB_USER=<your_user>
$ git clone https://github.com/PacktPublishing/OpenShift-Multi-Cluster-Management-Handbook.git

运行以下脚本并按照指示将引用从原始仓库（PacktPublishing）更改为你自己的分叉仓库：

$ cd OpenShift-Multi-Cluster-Management-Handbook/chapter10
$ ./change-repo-urls.sh
# Go back to the root dir
$ cd ..

为开发创建一个新分支：
```
$ git checkout -b dev
```

使用你喜欢的文本编辑器打开./sample-go-app/clouds-api/clouds.go文件，并在第 147 行添加version=1.0：

$ vim ./sample-go-app/clouds-api/clouds.go
func homePage(w http.ResponseWriter, r *http.Request) {
fmt.Fprintf(w, "Welcome to the HomePage! Version=1.0")
fmt.Println("Endpoint Hit: homePage")
}

提交并推送更改到dev分支：

$ git add ./sample-go-app/clouds-api/clouds.go
$ git commit -m 'Version 1.0 changes'
$ git push -u origin dev

运行以下命令来部署所需的先决条件和构建版本为 1.0 的镜像管道，稍后我们将在开发命名空间中部署它。确保你已经登录到 OpenShift 集群（使用oc login命令）：
```
$ oc apply -k ./chapter10/config/cicd
```

现在，运行管道并查看日志：

$ oc apply -f ./chapter10/config/cicd/pipelinerun/build-v1.yaml -n cicd
$ tkn pipelinerun logs build-v1-pipelinerun -f -n cicd
[fetch-repository : clone] + '[' false = true ']'
[fetch-repository : clone] + '[' false = true ']'
[fetch-repository : clone] + CHECKOUT_DIR=/workspace/output/
[fetch-repository : clone] + '[' true = true ']'
(.. omitted ..)
[build-image : push] Writing manifest to image destination
[build-image : push] Storing signatures
 [build-image : digest-to-results] + cat /workspace/source/image-digest
[build-image : digest-to-results] + tee /tekton/results/IMAGE_DIGEST
[build-image : digest-to-results] sha256:5cc65974414ff904f28f92a0deda96b08f4ec5a98a09c59d81eb59459038b547

这样，你就构建了clouds-api:v1.0容器镜像，并将其推送到 OpenShift 的内部注册表中。现在，让我们使用Kustomize和Argo CD来部署此镜像。

在开发环境中部署

在本节中，我们将使用 Kustomize 覆盖部署 YAML 文件中的镜像标签，使其使用我们在上一节中构建的v1.0。我们还将为开发分支创建一个名为clouds-api-dev的新命名空间。

以下图表显示了我们将执行的步骤：

图 10.13 – 在开发环境中部署

执行以下步骤：

更改我们开发环境kustomization.yaml文件中的镜像版本。为此，将第 18 行的changeme改为v1.0：

$ vim ./chapter10/clouds-api-gitops/overlays/dev/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
commonLabels:
  environment: dev
namespace: clouds-api-dev
bases:
  - ../../base
resources:
  - namespace.yaml
images:
- name: quay.io/gfontana/clouds-api
  newName: image-registry.openshift-image-registry.svc:5000/cicd/clouds-api
  newTag: v1.0 # Change this line

另外，你也可以使用sed命令来替换这一行：

sed -i 's/changeme/v1.0/' ./chapter10/clouds-api-gitops/overlays/dev/kustomization.yaml

现在，将此更改推送到dev分支：

$ git add chapter10/clouds-api-gitops/overlays/dev/kustomization.yaml
$ git commit -m 'updating kustomization file for v1.0'
$ git push -u origin dev

现在，我们来创建一个新的 Argo CD 项目：

$ oc apply -f ./chapter10/config/argocd/argocd-project.yaml

创建一个新的 Argo CD 应用程序，将应用部署到开发命名空间中：
```
$ oc apply -f ./chapter10/config/argocd/argocd-app-dev.yaml
```

使用以下命令获取 Argo CD 的 URL 和管理员密码：

# Get the Argo CD url:
$ echo "$(oc  get route openshift-gitops-server -n openshift-gitops --template='https://{{.spec.host}}')"
# Get the Admin password
$ oc extract secret/openshift-gitops-cluster -n openshift-gitops --to=-

使用之前提供的 URL 和管理员用户访问 Argo CD UI。你应该能看到一个名为clouds-app-dev的新应用程序：

图 10.14 – 在开发中部署的 Argo CD 应用

点击clouds-app-dev以了解更多关于该应用程序的信息：

图 10.15 – Argo CD 应用

运行curl命令来检查版本 1.0 的应用程序是否正在运行，并已通过 Argo CD 成功部署：
```
$ curl $(oc get route clouds-api -n clouds-api-dev --template='http://{{.spec.host}}')
```

你应该会看到以下响应：

Welcome to the HomePage! Version=1.0

这样，我们的示例应用程序就运行在开发命名空间中了。现在，让我们学习如何将这个应用程序提升到下一个阶段：QA。

提升到 QA

我们已经在开发环境中运行了 1.0 版本的应用程序。现在，让我们再次使用 Kustomize 和 Argo CD 将其部署到一个新的命名空间，该命名空间专用于 QA，如下图所示：

图 10.16 – 推送到 QA 环境

按照以下步骤操作：

为 QA 创建一个新分支：
```
$ git checkout -b qa
```

通过复制 dev 覆盖层来为 QA 创建一个覆盖层：

$ cp -r ./chapter10/clouds-api-gitops/overlays/dev/ ./chapter10/clouds-api-gitops/overlays/qa/

将所有 dev 的引用替换为 qa：

$ sed -i 's/dev/qa/' ./chapter10/clouds-api-gitops/overlays/qa/namespace.yaml ./chapter10/clouds-api-gitops/overlays/qa/kustomization.yaml

将更改推送到 Git：

$ git add ./chapter10/clouds-api-gitops/overlays/qa
$ git commit -m 'Promoting v1.0 to QA'
$ git push -u origin qa

将清单文件部署到生产环境，以便使用 Argo CD 推送到环境：
```
$ oc apply -f ./chapter10/config/argocd/argocd-app-qa.yaml
```
再次访问 Argo CD UI。此时，你应该在 Argo CD 上看到两个应用程序：

图 10.17 – Argo CD 应用程序

让我们访问正在 QA 命名空间中运行的应用程序：

$ curl $(oc get route clouds-api -n clouds-api-qa --template='http://{{.spec.host}}')

你应该看到与之前相同的响应：

Welcome to the HomePage! Version=1.0

至此，我们已经将应用程序推送到 QA 环境！现在，让我们学习如何将它迁移到最后一个阶段，即生产环境。

推送到生产环境

对于生产环境，我们将使用不同的方法——我们将使用 PR 而不是简单的 Git 推送。我们将使用一个名为 pre-prod 的临时分支来提交将用于生产的覆盖清单，如下图所示：

图 10.18 – 推送到生产环境

按照这些步骤将我们的应用程序版本 1.0 推送到生产环境：

创建一个新分支，为生产环境做准备：
```
$ git checkout -b pre-prod
```

为生产环境创建一个覆盖层，类似于你在 QA 环境中所做的：

$ cp -r chapter10/clouds-api-gitops/overlays/dev/ chapter10/clouds-api-gitops/overlays/prod/
$ sed -i 's/dev/prod/' ./chapter10/clouds-api-gitops/overlays/prod/namespace.yaml ./chapter10/clouds-api-gitops/overlays/prod/kustomization.yaml

将更改推送到 pre-prod 分支：

$ git add ./chapter10/clouds-api-gitops/overlays/prod
$ git commit -m 'Promoting v1.0 to Prod'
$ git push -u origin pre-prod

现在，在 GitHub 上创建一个 PR 并将其与主分支合并。访问你 GitHub 仓库的 Pull requests 标签页并点击 New pull request 按钮：

图 10.19 – 创建 PR

由于你正在使用分叉的代码库，GitHub 建议你为源代码库创建一个 PR（在本例中是从 PacktPublishing）。我们想要创建一个从我们的 pre-prod 分支到 main 分支的 PR，这两个分支都位于我们分叉的代码库中。因此，将基础代码库更改为我们的分叉代码库：

图 10.20 – 创建 PR

然后，在 compare 字段中选择 pre-prod：

图 10.21 – 创建 PR

现在，填写表单并点击 Create pull request：

图 10.22 – 创建 PR

在实际场景中，这个 PR 会被审查、同事审批并合并。我们目前还在练习阶段，因此让我们点击 Merge pull request 按钮：

图 10.23 – 审批 PR

生产环境版本 1.0 的覆盖清单已经存在于我们 Git 仓库的 main 分支中。这意味着我们可以使用 Argo CD 部署它：
```
$ git checkout main
$ oc apply -f ./chapter10/config/argocd/argocd-app-prod.yaml
```
到此为止，你应该在 Argo CD 上有三个应用程序：

图 10.24 – Argo CD 应用程序

让我们访问应用程序，查看运行在生产环境中的应用版本 1.0：

$ curl $(oc get route clouds-api -n clouds-api-prod --template='http://{{.spec.host}}')

你应该看到和之前一样的响应：

Welcome to the HomePage! Version=1.0

恭喜！我们已经使用 Argo CD 将应用程序部署到三个不同的命名空间，每个命名空间代表一个不同的环境：开发、QA 和生产。由于本书旨在讲解多集群，我们必须学习如何执行相同的过程，但将应用部署到多个集群，而不是仅仅部署到一个集群。在下一节中，你将看到整个过程相同，唯一的不同是你必须在 Argo CD 的 Application 对象中更改一个参数。

部署到多个集群

我们在 配置 Argo CD 以支持多集群 章节中学习了如何注册外部集群。一旦你在 Argo CD 中注册了多个外部集群，部署应用到其中一个集群就变得简单——你只需要在 Argo CD 的 Application 中的 destination 字段引用你注册的外部集群。以下清单中展示了一个示例：

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: clouds-app-dev-external-cluster
  namespace: openshift-gitops
spec:
  project: clouds-api
  source:
    repoURL: `https://github.com/PacktPublishing/OpenShift-Multi-Cluster-Management-Handbook'
    path: chapter10/clouds-api-gitops/overlays/dev
    targetRevision: dev
  destination:
    server: 'https://api.<external-cluster>:6443'
    namespace: default
  syncPolicy:
    automated:
      selfHeal: true

你可以根据需要创建多个 Application 对象，将应用部署到本地集群或多个外部集群。如你所见，部署过程本身是相似的，无论你是将应用部署到本地集群还是外部集群。

重要说明

当你与多个集群一起工作时，你需要特别关注 容器镜像注册表。正如其名称所示，OpenShift 内部注册表应该只在单个集群内使用；它不适合用于多个集群。在这种情况下，建议使用企业级容器镜像注册表。市场上有多种选择，例如 Nexus、Quay、Harbor 等等。在本书中，我们将在 第十三章 中介绍 Quay，OpenShift Plus - 一种多集群企业级解决方案。

总结

在本章中，你学习了与 GitOps 相关的各种概念。你还学习了 Argo CD 以及如何在 OpenShift 上安装并使用它。你还构建并部署了一个示例应用程序到三个不同的命名空间，以模拟开发、QA 和生产环境。最后，你了解到，无论是部署到本地集群还是外部集群，过程类似——你只需要更改目标服务器字段。

Argo CD 允许你使用 GitOps 建立高效且强大的应用交付模型，在这种模型中，无论你将应用部署到哪里，都能确保一致性、可审计的变更和安全的过程。而最棒的是，它的使用没有额外费用，因为它已经包含在 Red Hat OpenShift 的订阅中。也就是说，如果你在 OpenShift 上部署容器化应用，我强烈建议你尝试 OpenShift GitOps，并使用我们在本章中探讨的概念。

在下一章，我们将探讨一个极好的工具，它将帮助你通过单一统一界面部署和管理多个 OpenShift 集群 —— Red Hat 高级集群管理。这个工具可以让你监控、管理、定义和执行策略，并向多个集群部署应用。

让我们继续，深入了解 Red Hat 高级集群管理！

深入阅读

要了解本章所涵盖的主题，请查看以下资源：

GitOps 的历史： www.weave.works/blog/the-history-of-gitops
Argo CD 官方文档： argo-cd.readthedocs.io/
关于 Kustomize 的优秀教程：blog.stack-labs.com/code/kustomize-101/
Bitnami 的 Sealed Secrets 概述： github.com/bitnami-labs/sealed-secret。

第十一章：OpenShift 多集群 GitOps 和管理

在本书的第一章中，我们讨论了大多数组织在多云或混合云环境中扩展 Kubernetes 基础设施时面临的主要挑战。当您在不同的提供商上部署多个集群时，会出现新的挑战，具体如下：

不一致的安全策略：具有不同访问规则、用户配置文件、允许/阻止的网络流、证书和其他安全方面配置的集群，会使组织更容易遭受数据泄露和其他安全事件的风险。
高运营工作量以管理所有集群：管理多个集群的配置、组件、合规性和政策是非常繁重的。
应用程序的部署和管理：当您需要跨多个集群进行部署时，部署过程变得更加复杂。监控和管理这些集群也非常复杂，并且需要大量人工努力。

在本章中，我们将介绍一个很好的工具，帮助您解决这些挑战，并减轻您和/或您的团队在管理多个集群时可能需要处理的工作量：Red Hat 高级集群管理（ACM）。

因此，您将在本章中找到以下主题：

什么是 Red Hat ACM？
Red Hat ACM 安装
使用 Red Hat ACM 管理集群
使用 Red Hat ACM 管理应用程序
使用 Red Hat ACM 进行治理
使用 Red Hat ACM 进行多集群可观察性

注意

本章中使用的源代码可以在 github.com/PacktPublishing/OpenShift-Multi-Cluster-Management-Handbook/tree/main/chapter11 获取。

什么是 Red Hat ACM？

Red Hat ACM 是一个完整的 Kubernetes 多集群管理解决方案，通过单一面板实现，包括一些其他出色的功能，使得复杂和耗时的任务变得更加容易。Red Hat ACM 提供了几个主要功能，列举如下：

Kubernetes 多集群管理：在本地和云端创建、更新和删除 Kubernetes 集群。
多集群可观察性：ACM 还可以从单一视角提供所有集群的可观察性，使管理员能够读取、汇总并接收集群的警报。
通过策略进行治理：通过 Red Hat ACM，您可以审核和强制执行政策，在集群中应用您想要的任何内容，从安全到基础设施以及与应用程序相关的内容。这包括角色和访问控制、必须安装的操作员和安全合规规则。
应用程序管理：从 Git 仓库或 Helm 同时部署应用程序到多个集群，并且可以从单一面板查看它们。

ACM 的一个重要特点是其多集群架构——它旨在从单一视角管理多个集群，正如下图所示。

图 11.1 – ACM 中心集群和受管集群

为此，它使用了中心集群和受管集群的概念，如下所示：

中心集群：运行 ACM 中央控制器的 OpenShift 集群，包含 Web 控制台、API 和其他构成产品功能的组件。在本章中，我们将多次使用“中心集群”一词来指代承载 ACM 的 OpenShift 集群。OpenShift 是唯一支持的中心集群选项。
受管集群：由 ACM 管理的集群。ACM 可以管理 OpenShift 以及其他基于 Kubernetes 的发行版。请查看本章末尾的进一步阅读部分，查找 ACM 支持的 Kubernetes 发行版的完整列表（支持矩阵）。

我们将在本章接下来的部分深入探讨所有这些功能。

Red Hat ACM 安装

在本节中，我们将指导您安装和配置 ACM。

重要说明

需要注意的是，ACM 使用中心集群的计算、内存和存储资源，因此建议为 ACM 配备一个专用集群作为中心集群，避免并发工作负载和资源使用。这是推荐的做法，但不是必需的；您可以在任何具有足够容量的 OpenShift 集群中运行 ACM。

安装过程很简单，类似于我们在前几章中使用 OpenShift Pipelines 和 GitOps 时所遵循的过程，您可以在本节中看到。

前提条件

需要访问具有集群管理员权限的 OpenShift 集群。

安装

按照以下步骤安装 Red Hat 高级集群管理：

使用集群管理员用户访问 OpenShift Web 控制台。
导航到操作符 | OperatorHub 菜单项。

图 11.2 – OperatorHub

使用按关键字筛选...框搜索Kubernetes 的高级集群管理。

图 11.3 – OperatorHub 上的 Kubernetes 高级集群管理

点击Kubernetes 的高级集群管理图标，然后点击安装按钮，进入安装操作符屏幕。

图 11.4 – 安装 Kubernetes 的高级集群管理

请勿更改默认命名空间（open-cluster-management）。
选择自动或手动作为更新批准选项。如果选择自动，升级将在操作符生命周期管理器（OLM）发布后自动执行，而选择手动时，您需要在应用之前进行批准。
选择正确的更新通道。推荐选择稳定通道，因为它包含最新的稳定版本和受支持版本的操作符。
点击安装按钮。

图 11.5 – 安装操作员

等待最多 5 分钟，直到你看到以下消息：

图 11.6 – 操作员已安装

现在我们已经安装了操作员，可以继续部署一个新的MultiClusterHub实例：

点击创建 MultiClusterHub按钮。
通常不需要更改任何设置；保持默认值并点击创建按钮。如果需要配置一些高级设置，可以查看本章进一步阅读部分中的链接，获取产品文档以获得更多信息。

图 11.7 – 创建 MultiClusterHub

在安装过程中，你将看到状态Phase: Installing。

图 11.8 – 安装 MultiClusterHub

等待一会儿，直到你看到Phase: Running状态。

图 11.9 – MultiClusterHub 运行中

点击屏幕左上方的组合框，然后点击高级集群管理。

图 11.10 – 高级集群管理选项

你应该看到 ACM 登录页面。使用与登录 OpenShift 相同的管理员凭据。

图 11.11 – Red Hat ACM 登录

现在你已经安装并准备使用 Red Hat ACM。

图 11.12 – Red Hat ACM 初始页面

继续到下一部分，了解更多关于 ACM 集群管理功能的信息。

使用 Red Hat ACM 管理集群

如前所述，ACM 提供的功能之一是集群管理。以下是使用 ACM 可以执行的一些操作：

集群配置
导入现有集群
销毁集群
升级集群
扩展或缩小集群节点

请查看本章的进一步阅读部分，了解链接到完整支持操作列表的信息。

本书不会涵盖你可以使用 ACM 执行的所有操作，但我们将指导你通过使用 ACM 在 AWS 上配置一个新的 OpenShift 集群的过程，帮助你了解使用该工具的简便性。

集群配置

当前，在版本 2.5 中，ACM 可以在 AWS、Azure、Google Cloud、VMware vSphere、裸机、Red Hat OpenStack 和 Red Hat Virtualization 上部署集群。为此，你需要先输入 ACM 在配置过程中使用的提供商凭据。以下步骤展示了如何添加将与我们的示例一起使用的 AWS 凭据：

访问凭据菜单并点击添加凭据按钮。

图 11.13 – 添加提供商凭据

点击 AWS 凭证。

图 11.14 – 选择凭证类型

在下一页中，输入一个名称并选择存储凭证的命名空间以及用于部署集群的基础 DNS 域。点击下一步按钮。

图 11.15 – 基本凭证信息

推荐实践

提供商凭证存储在指定命名空间中的密钥中。因此，强烈建议为此创建一个专门的命名空间，并限制其访问。

输入 AWS 访问密钥和密钥对，点击下一步。

图 11.16 – AWS 访问密钥和密钥对

如果你使用代理，输入代理配置并点击下一步。

图 11.17 – 代理配置

使用你的 Red Hat 凭证登录 console.redhat.com 门户，进入OpenShift | 下载菜单。滚动到令牌部分，点击复制按钮，复制拉取密钥。

图 11.18 – 获取拉取密钥

返回到 ACM，并将拉取密钥粘贴到相应字段。使用现有的 SSH 密钥或创建一个新的 SSH 密钥，并将其粘贴到SSH 私钥和SSH 公钥字段。

图 11.19 – 输入拉取密钥和 SSH 密钥

注意

如果需要，你可以在 Linux 工作站中使用以下命令生成新的 SSH 密钥：

ssh-keygen -t ed25519 -N '' -f new-ssh-key

最后，点击添加按钮，查看你的新凭证。

图 11.20 – 添加凭证

现在，让我们使用这个凭证部署一个新集群。按照以下过程通过 ACM 部署集群：

访问基础设施 | 集群菜单，然后点击创建集群按钮。

图 11.21 – 创建集群

选择 AWS，选择我们刚才创建的凭证，然后点击下一步。

图 11.22 – 选择安装类型

填写表单中的必填字段，然后点击下一步按钮。

图 11.23 – 填写集群详情

输入 AWS 区域、机器数量和大小。

图 11.24 – 节点池

如果你想自定义集群网络配置，可以在此页面进行配置。

图 11.25 – 网络配置

如果需要，输入代理配置。

图 11.26 – 代理配置

你还可以使用 Ansible 运行 playbook，自动化你在部署过程中可能遇到的基础设施需求。我们不会在本书中深入探讨 Ansible 集成，但你可以在本章的进一步阅读部分找到相关的参考资料。

图 11.27 – Ansible 自动化钩子

审查提供的信息，如果一切正确，请点击创建按钮。

图 11.28 – 审查一个集群

你将被重定向到概览页面，在那里你可以检查安装过程。部署过程通常需要 30 到 60 分钟，具体取决于提供商和区域。

图 11.29 – 集群概览

建议你根据某些组织结构在集群中添加标签，稍后可以在此集群中使用env=dev标签，并在下一节中使用它，通过 ACM 将应用部署到远程集群中。为此，点击标签部分旁边的铅笔图标。

图 11.30 – 添加新标签

然后，添加新的标签，env=dev.

图 11.31 – 在集群中添加标签

如你所见，OpenShift 集群部署过程非常简单！在下一节中，你将看到 ACM 如何帮助你通过其嵌入式部署机制，或结合 OpenShift GitOps（Argo CD）将应用部署到多个集群中。

使用 Red Hat ACM 管理应用

ACM 的最大优势之一是提供了一种简单统一的方式来查看部署在不同集群中的应用。你还可以使用两种不同的方法将应用部署到多个集群中：

使用嵌入式应用订阅部署模型
使用 OpenShift GitOps（Argo CD）和ApplicationSets

我们将在本节中逐一介绍每种方法的过程。

应用订阅模型

该模型嵌入在 ACM 中，不依赖于除 ACM 本身以外的任何其他组件。在应用订阅模型中，你将定义一个应用对象，该对象订阅（订阅）一个或多个 Kubernetes 资源（通道），这些资源包含描述如何部署应用的清单。应用将根据放置规则部署到指定的集群中。

以下是一个图示，解释该模型的工作原理：

图 11.32 – ACM 应用订阅模型

让我们回到上一章中使用的示例应用程序，创建 ACM 对象以查看应用程序部署模型的样子。

通道（部署内容）

定义用于部署应用程序的源代码库。它可以是 Git 代码库、Helm 发布或对象存储库。我们将使用以下 YAML 清单来指向我们的 Git 代码库：

apiVersion: apps.open-cluster-management.io/v1
kind: Channel
metadata:
  name: cloud-api-github
  namespace: clouds-api-dev
spec:
  pathname: https://github.com/PacktPublishing/OpenShift-Multi-Cluster-Management-Handbook.git #[1]
  type: Git

#[1] 突出显示了包含应用程序部署清单的 Git 代码库 URL。

在Channel对象之后，我们需要创建PlacementRule对象，它将与应用程序部署一起使用。

部署规则（部署位置）

部署规则定义了应用程序将部署到的目标集群。它们也与策略一起使用。记得我们之前为已配置的集群添加了env=dev标签。我们现在将使用它来定义我们的PlacementRule对象：

apiVersion: apps.open-cluster-management.io/v1
kind: PlacementRule
metadata:
  name: cloud-api-placement
  namespace: clouds-api-dev
  labels:
    app: cloud-api
spec:
  clusterSelector:
    matchLabels:
      env: dev #[1]

env=dev标签。

现在我们准备好创建Subscription对象了。

apiVersion: apps.open-cluster-management.io/v1
kind: Subscription
metadata:
  name: cloud-api-subscription
  namespace: clouds-api-dev
  annotations:
    apps.open-cluster-management.io/git-path: sample-go-app/clouds-api/k8s/ #[1]
  labels:
    app: cloud-api #[2]
spec:
  channel: clouds-api-dev/cloud-api-github #[3]
  placement:
    placementRef: #[4]
      name: cloud-api-placement
      kind: PlacementRule

在前面的代码中，我们用数字突出显示了一些部分。让我们看一下：

#[1]：Git 上的部署清单路径。
Application对象。
#[3]：包含 Git 代码库、Helm 或对象存储的通道。
PlacementRule，描述应用程序将部署到何处。

最后，我们现在可以创建 ACM 的Application对象了。

应用程序

应用程序是用于描述一组 ACM 资源的对象，这些资源是部署应用程序所必需的。以下是我们示例中的Application对象：

apiVersion: app.k8s.io/v1beta1
kind: Application
metadata:
  name: cloud-api
  namespace: clouds-api-dev
spec:
  componentKinds:
    - group: apps.open-cluster-management.io
      kind: Subscription
  descriptor: {}
  selector:
    matchExpressions: #[1]
      - key: app
        operator: In
        values:
          - cloud-api

将使用app=cloud-api标签。

现在我们了解了应用程序部署过程中涉及的对象，接下来让我们在 ACM 上创建它们。

部署应用程序

部署对象就像从集群中心运行oc apply命令一样简单。从集群中心运行以下命令以部署应用程序：

$ git clone https://github.com/PacktPublishing/OpenShift-Multi-Cluster-Management-Handbook.git
$ cd OpenShift-Multi-Cluster-Management-Handbook/
$ oc apply -k chapter11/acm-model
namespace/clouds-api-dev created
application.app.k8s.io/cloud-api created
channel.apps.open-cluster-management.io/cloud-api-github created
placementrule.apps.open-cluster-management.io/cloud-api-placement created
subscription.apps.open-cluster-management.io/cloud-api-subscription created

你可以通过运行以下命令检查应用程序状态：

$ oc get application -n clouds-api-dev
NAME        TYPE   VERSION   OWNER   READY   AGE
cloud-api                                    5m48s

你也可以通过 ACM 网页控制台来部署应用程序。为此，请执行以下过程：

访问应用程序 | 创建应用程序 | 订阅菜单选项。

图 11.33 – 使用 ACM 部署应用程序

填写包含应用程序数据的表单，包括名称和命名空间，选择Git代码库，然后点击创建按钮。

图 11.34 – 填写应用数据

输入以下部署配置，并点击创建按钮。

图 11.35 – Placement 配置详情

点击拓扑选项卡查看已部署的应用程序概览。

图 11.36 – 应用程序拓扑

现在您已经了解了如何使用内嵌的 ACM 订阅部署应用程序，我们来看看如何使用 OpenShift GitOps（Argo CD）进行同样的操作。

OpenShift GitOps（Argo CD）和 ApplicationSets

如前所述，您也可以通过与 OpenShift GitOps（Argo CD）集成的 ACM 来部署应用程序，通过名为argocd的命令行选项将托管集群添加到 Argo CD。当您使用 ACM 时，无需手动执行此操作，因为 ACM 会管理外部集群并为您将它们添加到 Argo CD 中。相反，在 ACM 中，您需要在集群中定义以下对象，以指示 ACM 配置 Argo CD 并为您添加托管集群：

ManagedClusterSet：共享一些公共配置的集群组，如用户访问控制和多集群网络。
ManagedClusterSetBinding：将ManagedClusterSet绑定到命名空间。在此特定情况下，我们需要将ManagedClusterSet绑定到openshift-gitops命名空间。
Placement：定义谓词以从ManagedClusterSets中选择ManagedCluster，并将其绑定到GitOpsCluster的资源。
GitOpsCluster：注册到 OpenShift GitOps 的托管集群组。

我们在 GitHub 仓库的chapter11/argocd文件夹中提供了所有之前列出的对象的示例 YAML。请继续使用以下命令将这些对象应用到您的集群中：

$ git clone https://github.com/PacktPublishing/OpenShift-Multi-Cluster-Management-Handbook.git
$ cd OpenShift-Multi-Cluster-Management-Handbook/
$ oc apply -k chapter11/argocd
gitopscluster.apps.open-cluster-management.io/argo-acm-clusters created
managedclusterset.cluster.open-cluster-management.io/all-clusters created
managedclustersetbinding.cluster.open-cluster-management.io/all-clusters created
placement.cluster.open-cluster-management.io/all-clusters created

现在，访问您的 ACM，进入集群 | 集群集（选项卡）| 所有集群 | 托管集群（选项卡），然后点击管理资源分配按钮。在此页面上，选择所有集群，点击查看按钮，然后点击保存。

图 11.37 – 向集群集添加集群

最后，我们可以继续创建一个使用Placement对象的 ApplicationSet，将应用程序部署到所有具有env=dev标签的集群中：

$ oc apply -f chapter11/argocd/applicationset.yaml
applicationset.argoproj.io/cloud-api created
placement.cluster.open-cluster-management.io/cloud-api-placement created

几分钟后，您应该能够在应用程序的概览/拓扑视图中看到已部署的应用程序。

图 11.38 – ApplicationSet 拓扑

拓扑视图允许您从一个界面查看已部署到多个集群中的应用程序。这一功能对于部署在多个集群上的应用程序特别有用，因为您可以轻松查看应用程序在所有集群中的运行状况。

本节结束了我们对 Red Hat ACM 应用生命周期管理功能的概述。在这一部分，你已经看到 ACM 如何帮助你使用应用程序订阅模型或 OpenShift GitOps（Argo CD）将应用程序部署到多个托管集群中。接下来，你将看到如何在 ACM 上使用策略来确保集群符合你组织的业务和安全需求。

使用 Red Hat ACM 进行治理

本书中，我们已经多次讨论了大企业在保持不同环境一致性方面面临的挑战。ACM 治理功能在你的策略中可以发挥关键作用，帮助你维护安全且一致的环境，无论这些环境运行在哪个地方。ACM 治理功能允许你为一组集群定义策略，并在集群不符合规范时通知或执行强制措施。

要在 ACM 中定义策略，你需要创建三个对象：

策略：定义策略以及将要执行的修复操作（通知或强制执行）。
PlacementBinding：将策略绑定到 PlacementRule。
PlacementRule：定义该策略将应用于哪些集群的规则。

你可以在我们的 GitHub 上看到一个检查所有托管集群中 etcd 加密的策略示例。以下图示展示了 ACM 策略对象之间的交互方式：

图 11.39 – ACM 策略模型

运行以下命令来创建策略：

$ git clone https://github.com/PacktPublishing/OpenShift-Multi-Cluster-Management-Handbook.git
$ cd OpenShift-Multi-Cluster-Management-Handbook/
$ oc apply -k chapter11/governance
namespace/acm-policies-sample created
placementrule.apps.open-cluster-management.io/placement-policy-etcdencryption created
placementbinding.policy.open-cluster-management.io/binding-policy-etcdencryption created
policy.policy.open-cluster-management.io/policy-etcdencryption created

现在，访问 ACM Web 控制台中的治理功能，查看我们刚刚制定的策略。

图 11.40 – ACM 治理控制台

点击策略，然后访问policy-etcdencryption查看详细信息。

图 11.41 – ACM 治理 – 违规详情

在本章的进一步阅读部分，你将找到一个链接，指向一个包含多个可重用策略的仓库，你可以直接使用这些策略或作为样本创建你自己的策略。

正如你所看到的，ACM 治理功能简单易懂且易于使用。现在想一想你希望在集群中监控或执行哪些策略，并开始部署你自己的策略吧！

使用 Red Hat ACM 进行多集群可观察性

多集群可观察性是 ACM 的一项功能，旨在作为所有集群（无论是中心集群还是托管集群）度量、警报和监控系统的中心枢纽。

由于该工具处理大量数据，建议为其存储后端提供快速磁盘。Red Hat 已经过测试，并且完全支持在与 Red Hat OpenShift Data Foundation 配合使用的情况下采用该解决方案。

尽管 Red Hat 推荐这么做，但前提是需要一个提供对象/S3 类型存储的存储解决方案，例如大多数云服务提供商常见的存储方式（如 Amazon S3）。

先决条件

由于可观察性是 ACM 操作员的一个特性，因此没有太多前提条件。以下是所需的要求：

在连接的 Red Hat OpenShift 集群上启用可观察性功能。
从存储提供商配置对象存储。以下是一些支持的对象存储类型：
- Red Hat 容器存储
- AWS S3
- Red Hat Ceph（与 S3 兼容的 API）
- Google Cloud Storage
- Azure 存储
- IBM 云上的 Red Hat

重要提示

当你有敏感数据需要持久化时，配置加密非常重要。Thanos 文档中有对支持的对象存储的定义。请查看本章末尾的进一步阅读部分中的链接。

启用可观察性服务

由于可观察性运行在 ACM 之上，它的创建依赖于一个自定义资源（CR），它将触发多集群可观察性实例的创建。

下图展示了参与可观察性解决方案的对象的高级架构。这是启用可观察性服务时创建对象的参考：

图 11.42 – 创建 MultiClusterHub

按照以下指示启用多集群可观察性：

对于此示例，我们使用了部署在 Microsoft Azure 上的 OpenShift Hub 集群，因此你需要在终端中设置一些变量，这些变量将帮助你配置 Azure 动态存储作为存储解决方案：

$ LOCATION=eastus #[1]
$ RESOURCEGROUP=aro-rg #[2]
$ CLUSTER=MyHubCluster #[3]
$ STORAGEBLOB=observsto #[4]
$ az storage account create --name $STORAGEBLOB --resource-group $RESOURCEGROUP --location $LOCATION --sku Standard_ZRS --kind StorageV2 #[5]
$ az ad signed-in-user show --query objectID –o tsv | az role assignment create --role "Storage Blob Data Contributor" --assignee @- --scope "subscriptions/11111111-2222-a1a1-d3d3-12mn12mn12mn/resourceGroups/$RESOURCEGROUP/providers/Microsoft.Storage/storageAccountes/$STORAGEBLOB" #[6]
$ az storage container create --account-name $STORAGEBLOB --name container-observ --auth-mode login #[7]
     "created": true
$ az storage account show-connection-string –name $STORAGEBLOB
"connectionString": "DefaultEndpointsProtocol=https;EndpointSuffix=conre.windows.net;AccountName=observsto;AccountKey=sfsfoefoosdfojevntoaa/dsafojosjfsodfsafdsaf==" #[8]

让我们来看看这些高亮数字的含义：

#[1]：Microsoft Azure 的 Hub 集群区域
#[2]：Microsoft Azure 的资源组名称
#[3]：Hub 集群的集群名称
#[4]：存储账户名称
#[5]：在 Microsoft Azure 上创建存储的命令
#[6]：OpenShift 的属性存储角色，用于处理可观察性的存储操作
#[7]：此命令将在存储 Blob 账户中创建一个容器，用于存储 ACM 可观察性数据
#[8]：获取存储连接字符串的 Azure CLI 指令

在 Hub 集群中创建一个命名空间以供可观察性使用。我们将通过终端创建该命名空间；否则，你也可以在 OpenShift Web 控制台 UI 中创建：
```
$ oc create namespace open-cluster-management-observability
```

现在，是时候创建一个包含我们在上一步中获得的连接字符串的密钥（指令 #[8]）。完整的 YAML 文件已上传到我们的 GitHub 仓库，供你参考和使用：

$DOCKER_CONFIG_JSON='oc extract secret/pull-secret –n openshift-config --to=.' #[1]
.dockerconfigjson
$ oc create secret generic multiclusterhub-operator-pull-secret –n open-cluster-management-observability --from-literal=.dockerconfigjson="DOCKER_CONFIG_JSON" --type= kubernetes.io/dockerconfigjson #[2]
(.. omitted ..)
  thanos.yaml: |
    type: AZURE
    config:
      storage_account: observsto  #[3]
      storage_account_key: sfsfoefoosdfojevntoaa/dsafojosjfsodfsafdsaf== #[3]
      container: container-observ #[3]
      endpoint: blob.core.windows.net
      max_retries: 0
(.. omitted ..)

让我们来看看这些高亮数字的含义：

#[1]：当前 Docker 拉取密钥的环境变量。
将 dockerconfigjson 文件添加到 multiclusterhub 的密钥中
#[3]：来自前面命令的数据

配置文件可在 github.com/PacktPublishing/OpenShift-Multi-Cluster-Management-Handbook/blob/main/chapter11/acm-observability/thanos-object-storage.yaml 中找到。

现在，您已经拥有了用于可观察性的必要存储，接下来是创建 MulticlusterObservability 对象。返回到我们在本章开头安装的 Kubernetes 高级集群管理 操作器，访问 MultiClusterObservability 标签页，然后点击 创建 MultiClusterObservability 按钮。

图 11.43 – 创建 MultiClusterObservability

保持 CR 为默认设置，然后点击创建。

图 11.44 – MultiClusterObservability

等待直到可观察性实例的状态变为准备就绪。

图 11.45 – 为 MultiClusterObservability 配置实例

现在，您可以在导航到 主菜单 | 概览后看到 Grafana 可观察性仪表盘的路由。

图 11.46 – 为 MultiClusterObservability 配置实例

#[1]：请注意，现在可以在 Grafana 链接中看到可观察性选项。

点击 Grafana 查看一些汇总来自多个集群的度量的精彩仪表盘。

图 11.47 – MultiClusterObservability 仪表盘视图示例

现在，您可以依赖这个令人惊叹的 ACM 功能，帮助您和您的组织通过一个中央面板监控所有 Kubernetes 管理的集群，无论它们运行在哪种基础设施或云提供商上。在接下来的小节中，我们将展示一个选项，让您对集群拥有更多控制权。

配置 AlertManager 以发送警报

正如我们到目前为止所见，可观察性可以是监控所有集群的强大盟友，通过中央视图管理它们，但接下来我们将更进一步，展示给您锦上添花的部分，这将是您管理集群的另一个有力帮助。

如图 11.42所示，AlertManager 是可观察性架构中的一个资源。我们将展示一个示例，您可以使用它启用此功能并从所有管理的集群接收警报。

AlertManager 是一款可以将警报发送到其他系统的工具，诸如电子邮件、PagerDuty、Opsgenie、微信、Telegram、Slack，甚至您的自定义 Webhook。在这个示例中，我们将使用 Slack 作为所有警报的接收工具，它是一个简短消息工具。

前提条件

首先，您需要安装 Slack 应用来设置警报，然后访问api.slack.com/messaging/webhooks，并按照说明创建并配置一个频道。配置完成后，您将获得一个类似以下的 webhook 端点：https://hooks.slack.com/services/T03ECLDORAS04/B03DVP1Q91D/R4Oabcioek。请将该 webhook 地址保存在安全的地方，因为接下来的步骤中将使用它。

配置 AlertManager

要配置 AlertManager，您需要创建一个名为alertmanager.yaml的新文件。此文件将包含您之前保存的 webhook。完整的 YAML 文件可以在我们的 GitHub 仓库中找到，供您参考和使用（GitHub 仓库：github.com/PacktPublishing/OpenShift-Multi-Cluster-Management-Handbook/blob/main/chapter11/acm-observability/alertmanager.yaml）：

global:
  slack_api_url: 'https://hooks.slack.com/services/T03ECLDORAS04/B03DVP1Q91D/R4Oabcioek' #[1]
  resolve_timeout: 1m
route:
  receiver: 'slack-notifications'
(.. omitted ..)
  routes:
    - receiver: slack-notifications #[2]
      match:
        severity: critical|warning #[3]
receivers:
- name: 'slack-notifications'
  slack_configs:
  - channel: '#alertmanager-service' #[4]
    send_resolved: true
    icon_url: https://avatars3.githubusercontent.com/u/3380462
    title: |-
     [{{ .Status | toUpper }}{{ if eq .Status "firing" }}:{{ .Alerts.Firing | len }}{{ end }}] {{ .CommonLabels.alertname }} for {{ .CommonLabels.job }}
(.. omitted ..)

在前面的代码中，我们用数字标记了一些部分。让我们一起来看看：

#[1]：Webhook Slack API URL
#[2]：警报接收者的名称
#[3]：过滤关键或警告警报
#[4]：工作区中的 Slack 频道

下一步是将新的alertmanager.yaml文件应用到 ACM 可观察性命名空间：

$ oc -n open-cluster-management-observability create secret generic alertmanager-config --from-file=alertmanager.yaml --dry-run=client -o=yaml |  oc -n open-cluster-management-observability replace secret --filename=-

alertmanager.yaml文件必须位于相同的执行目录下。等到新的 AlertManager Pod 被创建后，您将在配置的频道上收到新的[Firing]或[Resolved]警报。以下是一个示例截图：

图 11.48 – AlertManager 多集群警报

好的，我们已经设置了 AlertManager 并将警报发送到 Slack 频道！因此，在本节中，您已了解可观察性功能，从安装到配置和使用。希望这能帮助您在多集群管理的旅程中，监控所有集群，无论它们运行在哪个提供商环境中。

总结

在本章中，您已经了解了 Red Hat ACM，并看到了其功能概述及如何帮助您管理多个集群。现在您明白了 Red Hat ACM 提供了多集群管理功能，能够确保它们符合您为其定义的策略，同时还能一次性部署工作负载到多个集群，并从一个中心面板监控所有集群。

我们还介绍了 ACM 的安装过程，在 AWS 上使用 ACM 配置了一个新集群，演示了如何通过嵌入的 ACM 应用订阅模型或与 Argo CD 集成来部署应用，简要概述了 ACM 的治理功能，最后启用了可观察性功能，以监控多个集群并聚合 ACM 上的指标。

在今天的世界中，管理多个集群跨多个提供商，无论是在本地还是在云端，已经成为大多数公司现实的一部分；因此，多集群管理工具是必不可少的。Red Hat ACM 可以为你提供所需的功能，从一个集中位置管理所有集群。我们鼓励你现在就开始使用 ACM，享受这个伟大工具带来的所有好处。

继续阅读下一章节，了解 Red Hat Advanced Cluster Security 如何帮助你保持 Kubernetes 和 OpenShift 集群的安全。

进一步阅读

想了解更多信息吗？查看以下参考资料，获取有关 Red Hat ACM 的更多信息：

Red Hat Advanced Cluster Management 文档： access.redhat.com/documentation/en-us/red_hat_advanced_cluster_management_for_kubernetes/2.5
Red Hat ACM 可支持性矩阵： access.redhat.com/articles/6663461
Red Hat Advanced Cluster Management 可观察性先决条件： access.redhat.com/documentation/en-us/red_hat_advanced_cluster_management_for_kubernetes/2.3/html-single/observability/index#prerequisites-observability
Thanos 支持的对象存储： thanos.io/tip/thanos/storage.md/#supported-clients
Red Hat ACM 策略集合： github.com/open-cluster-management/policy-collection
将 Red Hat ACM 与 Ansible 集成进行集群部署和升级： access.redhat.com/documentation/en-us/red_hat_advanced_cluster_management_for_kubernetes/2.5/html/clusters/managing-your-clusters#ansible-config-cluster
将 Red Hat ACM 与 Ansible 集成进行应用程序管理： access.redhat.com/documentation/en-us/red_hat_advanced_cluster_management_for_kubernetes/2.5/html/applications/managing-applications#setting-up-ansible
使用 Ansible 创建策略违规自动化： access.redhat.com/documentation/en-us/red_hat_advanced_cluster_management_for_kubernetes/2.5/html/governance/governance#configuring-governance-ansible

第四部分 – 多集群实施和安全合规性的简介

在这一部分，你将深入了解一些用于管理多个集群的优秀工具，以及如何使一个组织在混合云环境中扩展其实施。

本书的这一部分包含以下章节：

第十二章，OpenShift 多集群安全性
第十三章，OpenShift Plus – 一种面向企业的多集群解决方案
第十四章，在混合云环境中构建云原生用例

第十二章：OpenShift 多集群安全

在第八章《OpenShift 安全》一章中，我们讨论了在为您的 OpenShift 集群定义和实施安全策略时可能需要考虑的一些重要方面。我们涵盖了身份验证和授权、证书和加密、容器与网络隔离等方面。如果您还没有阅读该章节，建议在阅读本章之前先看一下。

在 OpenShift 上实施安全策略很重要，但一般来说并不复杂——大多数策略的配置是直接且有良好文档的。然而，当您将基础设施扩展到多个集群时，事情就变得更加复杂了。那么，如何确保在多个集群上运行的所有容器都使用安全且经过认证的基础镜像呢？您是否知道所有环境在行业和监管标准（如 PCI 和 HIPAA）下的合规性情况？为了帮助您监控和最大化 OpenShift 和 Kubernetes 集群的安全性，本章将介绍红帽高级集群安全（ACS）。

因此，本章将涵盖以下主题：

什么是红帽高级集群安全？
红帽高级集群安全安装
添加安全集群
策略和违规
漏洞管理
风险评估
配置管理
网络分段

让我们现在深入了解吧！

什么是红帽高级集群安全？

红帽高级集群安全，也称为 StackRox，是一款原生 Kubernetes 安全工具，提供以下功能：

策略和违规：定义安全策略，并实时报告所有违规事件。您可以定义自己的策略和/或使用内置的数十个策略。
漏洞管理：检测集群中的已知漏洞，提供修复和预防安全问题所需的工具。
风险评估：评估您的环境风险，并根据安全风险对应用程序进行分类。
合规性：根据一些行业标准的安全配置文件报告集群的合规性。
配置管理：帮助您确保部署符合安全最佳实践。
网络分段：查看不同命名空间之间的网络流量，并允许您创建网络策略以限制和隔离流量。

最近，KuppingerCole进行的研究将红帽高级集群安全评为 Kubernetes 安全领域的领导者。它确实是一款优秀的产品，并包含在Red Hat OpenShift Plus产品中，下一章我们将更详细地讨论这个产品。在本章的进一步阅读部分，您可以找到指向KuppingerCole研究的链接。

如果你有有效的 OpenShift Plus 订阅，或者可以联系覆盖你公司地区的 Red Hat 账户团队获取更多信息，我们鼓励你尝试使用 ACS。

Red Hat 高级集群安全安装

ACS 的安装过程与上一章你在 ACM 中看到的类似：通过一个操作员。然而，你也可以使用Helm charts或roxctl CLI 进行安装。在本书中，我们将使用操作员安装；如果你想了解更多关于 Helm 或 roxctl 安装过程的信息，请参考官方文档。你可以在本章的Further reading部分找到官方文档的链接。

要使用操作员安装 ACS，请按以下步骤进行。

前提条件

你需要访问具有集群管理员权限的 OpenShift 集群。

操作员安装

按照以下步骤准备 ACS 操作员：

使用管理员视角访问 OpenShift Web 控制台。
导航到Operators | OperatorHub菜单项。

图 12.1 – OperatorHub

使用Filter by keyword...框搜索Advanced Cluster Security for Kubernetes。

图 12.2 – OperatorHub 上的高级集群安全

点击Advanced Cluster Security for Kubernetes模块并点击Install按钮以查看Install Operator界面。

图 12.3 – 为 Kubernetes 安装高级集群安全

不要更改默认命名空间（rhacs-operator）。
选择Automatic或Manual作为升级批准策略。如果选择Automatic，升级将在 Red Hat 发布后由Operator Lifecycle Manager（OLM）自动执行，而选择Manual时，你需要在升级应用之前进行批准。
选择正确的更新通道。建议选择最新通道，因为它包含操作员的最新稳定版和支持的版本。
点击Install按钮。

图 12.4 – 安装操作员

等待最多 5 分钟，直到你看到以下消息：

图 12.5 – 操作员已安装

现在我们已经安装了操作员，下一步是部署 ACS Central 自定义资源。请参见下一步如何操作。

ACS Central 安装

我们现在可以继续部署一个新的 ACSCentral实例：

点击View Operator按钮，或导航到Operators | Installed Operators菜单，点击Advanced Cluster Security for Kubernetes。
访问Central标签页并点击Create Central按钮。

图 12.6 – 创建新的 ACS 中央实例

通常无需更改任何设置，因此保留默认值并点击 Create 按钮。如果您需要配置一些高级设置，请查看本章 Further reading 部分的链接，获取更多产品文档信息。

图 12.7 – 创建 ACS 中央

等待几秒钟，直到您看到 Conditions: Deployed, Initialized 状态。

图 12.8 – ACS 中央已安装

要访问最近创建的 ACS 中央门户，您首先需要获取管理员凭证。为此，请导航至 rhacs-operator 项目并点击 central-htpasswd 密钥。

图 12.9 – 管理员凭证密钥

向下滚动并点击 Reveal values。复制 password 字段中的值。

图 12.10 – 复制管理员密码

现在，转到 Networking | Routes 获取 ACS 中央 URL：

图 12.11 – ACS 中央 URL

使用管理员用户名和从密钥中复制的密码。

图 12.12 – Red Hat ACS 登录页面

您现在已经安装了 Red Hat 高级集群安全。您会注意到，当前 ACS 下没有任何集群。我们将在接下来的步骤中添加一个受管理集群（也叫受保护集群）。

图 12.13 – Red Hat ACS 初始页面

继续阅读，了解如何在 ACS 上添加受保护集群。

添加受保护集群

Secured cluster 是指受 ACS 管理的集群。ACS 中央作为控制平面，您将在其中创建策略并可视化违规、合规性及本章后续将介绍的所有功能；而 ACS 受保护集群是一组在受管集群上运行的 ACS 进程（AdmissionControl、Scanner、Sensor 和 Collector），用于监控和执行策略。

图 12.14 – ACS 中央/受保护集群

在 ACS 中央添加受保护集群的过程包括以下步骤：

在 ACS 中央生成 init 捆绑包。
运行 init 捆绑包。
在 ACS 操作员中创建 SecuredCluster 自定义资源。

要执行前面的步骤并添加受保护集群，请在 ACS 中央 中执行以下步骤：

访问 Platform Configuration | Integrations 菜单：

图 12.15 – 生成初始化捆绑包

向下滚动并点击 Authentication Tokens | Cluster Init Bundle。

图 12.16 – 生成初始化包

点击 生成包，为其命名，并点击 下载 Kubernetes 秘密文件 按钮：

图 12.17 – 生成初始化包

现在，访问你想要添加为受保护集群的 OpenShift 集群（不是 ACS Central）。

使用带有 oc CLI 的终端，运行以下命令。请注意，你需要在受保护集群中运行此命令，而不是在 ACS Central 上运行：

$ oc create namespace rhacs-operator
$ oc create –f <cluster-init-secrets>.yaml -n rhacs-operator
secret/collector-tls created
secret/sensor-tls created
secret/admission-control-tls created

按照本章 操作员安装 部分中我们执行的相同步骤，在受保护集群中安装 ACS 操作员。请注意，这次我们是在受保护集群中安装操作员。

图 12.18 – ACS 操作员安装在 ACS 受保护集群中

仍然在 OpenShift 受保护集群中，导航至 操作员 | 已安装操作员，点击 Kubernetes 高级集群安全。在此页面上，访问 受保护集群 标签页：

图 12.19 – 创建一个新的受保护集群

点击 创建 SecuredCluster 按钮。在此页面中，给集群命名，添加 ACS Central URL，并点击创建按钮：

图 12.20 – 添加受保护集群

重要提示

始终在 Central Endpoint 中添加 port (:443)。如果没有指定端口，受保护集群的传感器和扫描器可能会失败。

等待最多 10 分钟，直到 ACS Collector、Sensor 和 AdmissionControl 在管理集群中启动。要检查 ACS 管理集群的状态，访问 ACS Central 并导航到 平台配置 | 集群。该集群应以绿色标记为 Healthy（健康状态）：

图 12.21 – 受保护集群健康状态

提示

在受保护集群部署期间，看到 集群状态 为 Degraded（降级）是正常的。等待最多 10 分钟，直到它变为 Healthy（健康）。刷新浏览器以检查最新状态。

现在我们拥有了开始使用 ACS 所需的所有内容：ACS Central 正在监控一个受保护的集群。继续阅读下一部分，了解更多关于 ACS 策略和违规功能的信息。

策略与违规

ACS 提供了多个开箱即用的安全策略，你可以直接使用，也可以为你的 Kubernetes 集群定义自定义安全策略。你还可以轻松检查哪些策略被违反，使用 Violations 功能。

在本节中，我们将学习如何查看和创建策略，并深入了解 Violations 功能。

安全策略

要访问安全策略，请导航至 平台配置 | 策略。所有开箱即用的策略将在此视图中列出：

图 12.22 – 安全策略

让我们使用一个简单的策略来了解安全策略如何在 ACS 上工作。输入Policy并按Enter，然后输入admin secret并再次按Enter，以查找OpenShift: Advanced Cluster Security Central Admin Secret Accessed策略：

图 12.23 – 最新标签策略

现在点击链接查看策略详情页面：

图 12.24 – 策略详情

在此页面上，您将找到策略详细信息，例如描述、类型等。让我们点击操作 | 编辑策略，查看我们可以作为策略一部分设置的内容。

图 12.25 – 编辑策略详情

我们看到的第一个屏幕是策略详情。在此页面上，您可以更改一般策略信息，如名称、严重性级别、类别和描述。

MITRE ATT&CK

MITRE ATT&CK® 是一个关于战术和技术的知识库，这些战术和技术常常在针对 Kubernetes 的网络攻击中被使用。该知识库于 2020 年 4 月由微软首次发布，是 Kubernetes 安全最佳实践的重要来源。ACS 允许您根据 MITRE ATT&CK® 矩阵对安全策略进行分类。如果你想了解更多关于该框架的信息，可以查看本章末尾的进一步阅读部分中的链接。

下一个屏幕是策略行为，它定义了策略应该如何应用：

图 12.26 – 策略行为

生命周期阶段定义了策略应用于哪个阶段：

构建：在容器镜像构建过程中应用的策略。通常作为 CI 流水线的一部分，用于对 YAML Kubernetes 清单或 Dockerfile 指令进行静态分析。
部署：此阶段的策略将在应用程序部署时触发，并根据您在响应方法中配置的内容，在策略违规时会通知或甚至阻止部署。
运行时：在运行时应用的策略。对于运行时策略，您可以定义事件来源是来自部署还是审计日志。选择部署事件来源时，您可以通知并阻止违反策略的应用程序部署，而审计日志用于监控 Kubernetes API 调用与机密和配置映射，以查找可疑活动，如敏感密码被读取——这正是我们在本示例中使用的策略所执行的任务。

您还可以为以下之一设置响应方法：

通知：仅通过将违规项添加到违规功能中来通知违规。
通知并强制执行：除了将其添加到违规列表中外，还会根据生命周期阶段选择的内容强制执行以下行为：
- 如果选择构建阶段，则会失败 CI 构建。
- 阻止违反策略的应用部署，如果选择了部署阶段。
- 终止违反策略的 pod，如果选择了运行时阶段。

下一步描述将定义该策略的标准：

图 12.27 – 编辑策略标准

策略标准根据事件源的不同而有所不同。当事件源为部署时，您可以根据与图像、容器配置、元数据、存储、网络、容器运行时进程和 Kubernetes 事件相关的大量实体创建布尔逻辑。我们鼓励您访问不同的策略，以检查现有策略中可用的不同类型的策略标准。

当事件源为审计日志时，标准根据 Kubernetes API 事件来定义。让我们检查一下我们作为示例使用的策略，以了解基于审计日志的策略标准是如何工作的。在我们的示例中，使用了以下标准：

Kubernetes 资源：密钥
Kubernetes API 动词：GET、PATCH或UPDATE
Kubernetes 资源名称：central-htpasswd
Kubernetes 用户名不是：system:serviceaccount:openshift-authentication-operator:rhacs-operator-controller-manager

这意味着当central-htpasswd密钥被任何非rhacs-operator-controller-manager service account的用户GET、PATCH或UPDATE时，将会触发违规。

如果需要，您还可以设置策略范围：

将策略限制为特定的集群、命名空间或标签。
或者，排除策略中的实体。
在构建阶段排除需要检查的图像：

图 12.28 – 从策略中排除或限制实体和图像

这就是您在策略中会找到的配置。其实并不难，对吧？我们鼓励您创建一些自定义策略来练习并从中学习。

违规

违规功能列出了 ACS 监控的集群中所有违反的安全策略：

图 12.29 – 违规列表

请记住，我们在ACS Central 安装部分的步骤 15中读取了central-htpasswd，以获取 ACS Central 管理员密码。由于我们之前使用的策略（GET API 的 central-htpasswd 密钥），这引发了一个违规。在此页面上点击一些违规项，探索此功能并了解 ACS 违规功能所捕获和显示的事件和数据：

图 12.30 – 违规示例

在本节中，我们学习了如何在 ACM 上定义安全策略，以及如何轻松查看集群中发生的违规行为。继续阅读以了解更多关于 ACS 的漏洞管理功能，以及如何使用它来识别、优先处理和修复漏洞。

漏洞管理

通常认为，任何系统都有漏洞；其中一些是已知的，而一些尚未被识别。漏洞管理是识别和管理已知漏洞的过程，这意味着有计划地修复或减轻漏洞的影响。导航到漏洞管理 | 仪表板查看此功能的界面：

图 12.31 – 漏洞管理

通过此功能，你可以浏览 ACS 检测到的所有漏洞，并决定采取哪些措施：

通过删除应用程序中易受攻击的软件包或更新到已修复该漏洞的较新版本来修复漏洞。
接受风险。
将其标记为误报。

漏洞按照以下方式进行检测和分组：

组件：容器使用的软件包。此组帮助你检测包含更多漏洞的软件包以及它们的使用位置，从而可以相应地升级应用程序以修复这些漏洞。
镜像：按镜像分组漏洞。类似地，你可以查看哪些镜像更容易受到攻击，检查是否有修复方案，并相应地进行规划。
节点：按节点分组的漏洞。
部署：按部署查看漏洞。更容易检查特定应用程序的漏洞。
命名空间：按命名空间分组的漏洞。
集群：按集群分组的所有漏洞。

这些组可以通过漏洞管理仪表板顶部的按钮访问；点击它们以探索你可以查看和筛选漏洞的不同方式：

图 12.32 – 按实体分组

我们现在将部署一个示例应用程序，以检查漏洞管理功能的实际效果。为此，请在 OpenShift 安全集群中运行以下命令：

$ oc new-project acs-test
$ oc run samba --labels=app=rce \
  --image=vulnerables/cve-2017-7494 -n acs-test
$ oc run shell --labels=app=shellshock,team=test-team \
  --image=vulnerables/cve-2014-6271 -n acs-test

现在，再次访问漏洞管理仪表板。你可能会注意到现在仪表板中有一些有趣的内容：

图 12.33 – 风险最高的镜像和部署

在上面的截图中，你可以看到以下内容：

我们刚刚部署的应用程序的容器镜像被列为风险最高的镜像。
在图表中，应用程序部署显示为 CVEs 数量和 CVSS 分数方面最为关键的。

点击应用程序与基础设施 | 命名空间，查看按命名空间分组的漏洞：

图 12.34 – 应用程序与基础设施菜单

现在你会注意到我们的acs-test命名空间列出了超过 400 个 CVE，其中 150 多个是可修复的：

图 12.35 – 按命名空间划分的漏洞

点击acs-test命名空间，深入查看详细信息。

图 12.36 – 命名空间摘要视图

探索samba部署、通过或未通过命名空间的策略、镜像及其漏洞列表，以及所有包含 CVE 的组件（软件包），最后是该命名空间中检测到的所有 CVE 列表。你可以通过探索该命名空间发现，它包含两个应用程序（部署），其中一个已知有 498 个 CVE，其中 169 个是可修复的：

图 12.37 – 检测到的 CVE

通过深入分析部署和组件，你可以检查正在使用的包版本以及在哪个版本中修复了 CVE：

图 12.38 – 组件与 CVE

这为你提供了大量有助于识别漏洞包和镜像并进行修复的信息。你也可以选择接受风险（延期）或将其标记为假阳性；为此，访问镜像，向下滚动并选择你想要延期的 CVE，然后点击延期 CVE或标记为假阳性：

图 12.39 – 接受 CVE 风险

你可以在漏洞管理 | 风险接受功能中查看和批准 CVE，也可以列出已批准的延期和假阳性：

图 12.40 – 风险接受

漏洞管理功能还包括报告功能，你可以设置安全报告，并每周或每月将其发送到一个分发列表。定期报告组织中的漏洞非常有帮助。我们在本书中不会覆盖此功能，但你可以在本章的进一步阅读部分找到一个链接，帮助你进行配置。

风险分析

风险视图是一个将所有运行中部署按安全风险分类的功能。进入风险菜单访问该功能并从中学习：

图 12.41 – 风险功能

点击samba部署，探索风险指标、部署详情和进程发现：

图 12.42 – 风险详情

我们不会逐一讲解其中的每个选项，而是会重点介绍过程发现标签页，它提供了一些有趣的见解，正如下所示：

图 12.43 – 过程发现

在此标签页中，你可以看到容器中正在运行的所有进程，包括详细信息，还有一张显示进程活动随时间变化的图表。点击查看图表链接以查看它：

图 12.44 – 过程图

这个风险功能对于你按安全风险对部署进行排序并根据优先级列表采取行动非常有帮助。

合规性

合规性功能扫描你的集群并根据一些现成的合规行业标准报告它们，例如 Docker 和 Kubernetes 的 CIS 基准、健康保险携带与责任法案（HIPAA）、国家标准与技术研究所（NIST）特别出版物 800-190 和 800-53，以及支付卡行业数据安全标准（PCI DSS）。

要运行合规扫描，导航到合规性功能并点击扫描环境按钮：

图 12.45 – 合规功能

几秒钟后，你将看到合规报告，如下所示：

图 12.46 – 合规报告

我们不会深入探讨这些行业标准，因为它们非常具体于不同的行业。我们鼓励你探索该功能，点击每个图表，深入分析，检查哪些控制是合规的，哪些不合规，并了解原因。如果你想了解更多关于该合规功能的信息，可以阅读我们在进一步阅读中留下的参考资料。

配置管理

配置管理功能是以另一种方式查看违反的政策，它将这些政策与构成集群配置和使用的各种对象相关联。使用此功能，你可以列出所有集群的失败政策，并深入检查所有命名空间、部署等。你可能会想，这些信息也可以在违规和漏洞管理中找到，没错！这些信息也在那里；不过，在这里，你会看到它按集群实体分组，并且展示每个实体的汇总数据，这有助于你关联不同实体，了解它们之间的关系。

要访问此功能，导航到配置管理菜单：

图 12.47 – 配置管理功能

你将首先看到一个仪表盘，汇总以下信息：

按严重程度分类的策略违规：按严重程度（关键、高、普通和低）对策略违规进行分组，并以饼图形式显示。你可以通过点击饼图右侧的链接深入查看并检查策略：

图 12.48 – 按严重程度分类的策略违规饼图

CIS DOCKER/Kubernetes：另一个按 CIS Docker 或 CIS Kubernetes 控制分组的饼图：

图 12.49 – CIS DOCKER/KUBERNETES 饼图

接下来是此饼图的描述：

该饼图总结了考虑 CIS Docker 或 Kubernetes 标准下的控制合规性。
点击这里在 CIS Docker 和 CIS Kubernetes 之间切换。
点击扫描按钮，在环境中执行新的扫描。
点击查看标准，获取所有 CIS 控制及其状态（通过、失败或N/A）的列表。
深入查看已通过、失败或 N/A 的控制列表。

拥有最多集群管理员角色的用户：显而易见，你可以使用此列表查看用户的权限，并确保他们拥有适当的权限：

图 12.50 – 拥有最多集群管理员角色的用户

在部署中最常用的机密：同样是显而易见的。使用此列表查找敏感数据及其如何通过环境访问，并查找可疑活动：

图 12.51 – 在部署中最常用的机密

你还可以使用此页面顶部的条形图按集群、命名空间、节点、部署、镜像、机密、用户和组、服务账户及角色检查策略和控制：

图 12.52 – 按实体查看策略和控制

点击菜单选项，探索你从每个选项中获得的不同列表。还要注意，你可以从集群深入到部署、镜像等，前后导航分析实体：

图 12.53 – 从集群深入到命名空间

这总结了配置管理功能的概述。继续阅读，查看 ACS 带来的一个很棒功能，帮助你检查集群的网络通信。

网络分段

Kubernetes 集群中的一个重要安全方面是 Pod 之间的通信方式，以及进入和离开通信。目前，Kubernetes 中没有图形化视图来实时检查网络通信如何执行，也无法查看允许的或被阻止的流量。为了解决这个问题，ACS 提供了网络图功能，允许您实时查看活动通信，并定义和应用网络策略（NP）以允许或阻止网络流量。点击网络图菜单以访问该功能：

图 12.54 – 网络图功能

选择rhacs-operator命名空间查看网络图的样子：

图 12.55 – rhacs-operator 命名空间的网络图

您可以更改视图，仅查看活动连接、允许的连接或所有类型的连接流量。

网络流量

Red Hat 高级集群安全可以学习应用程序使用的网络流量，并应用所有网络流量的基线。检测到的任何与基线不同的网络流量都会被标记为异常，以供您审核。在查看网络流量和基线时，访问任何部署，您将看到异常流量以红色标记：

图 12.56 – 网络流量 – 异常和基线

点击基线设置标签页以查看当前基线：

图 12.57 – 配置基线

通过基线设置标签页，您可以执行以下操作：

查看网络流量的基线。
配置当 ACS 检测到异常流量时发送警报。
模拟将基线作为网络策略在环境中的影响。

接下来将展示如何使用网络图功能生成仅允许应用程序所需通信的网络策略列表。

网络策略模拟器

您知道您的集群的网络策略配置是否仅允许必要的通信吗？带有宽松网络策略集的集群非常常见，ACS 网络策略模拟器可以帮助避免这种情况。ACS 监控集群中所有 Pod 和命名空间之间的网络流量，创建防火墙规则矩阵。您可以使用 ACS 基于它从环境中学到的信息生成一组仅允许所需通信的网络策略。要使用此功能，请点击网络策略模拟器按钮，然后点击生成并模拟网络策略：

图 12.58 – 生成并模拟网络策略

您将看到一个详尽的 NP 列表，这些 NP 仅允许 ACS 从正在使用的环境中学到的通信。您可以在环境中应用这些 NP，或者通过电子邮件分享它们。我们强烈建议您在生产环境中应用之前，先在开发或测试环境中审查和测试这些 NP。

图 12.59 – 应用或共享 NPs

很有帮助吧？现在再深入了解一下网络图功能，并设想这个功能如何帮助您和您的组织更好地了解网络流量，并仅允许您的应用程序真正需要的通信。

总结

在本章中，我们介绍了很多关于红帽高级集群安全（ACS）的内容。在本章中，我们概述了 ACS 的功能，帮助您了解 ACS 如何确保集群的安全性，识别已知漏洞，并制定行动计划。

我们了解了如何使用和定义安全策略，并使用违规功能列出所有政策违规情况。我们还看到，漏洞管理功能非常有助于列出所有已知漏洞，审查它们，并采取适当的行动：修复（修复易受攻击的包）、接受风险或将其标记为误报。

我们还了解到，风险分析功能帮助您评估应用部署的风险，并优先处理需要采取的补救措施和行动，以增强安全性。合规性根据行业标准（如 CIS Docker、HIPAA、NIST、PCI 等）报告集群、命名空间和部署情况。

最后，我们看到了通过配置管理功能按集群的实体汇总的策略和控制列表，帮助将不同的实体关联到集群中。网络图功能则为我们提供了网络流量的实时视图，并附加了一些有用的功能，帮助生成和模拟 NP，确保只允许必要的通信，而不会有多余的通信。

我们希望本章能帮助您理解红帽高级集群安全。我们鼓励您继续下一章，了解如何将 ACM、ACS 和其他组件结合起来，构建一个完整且全面的多云或混合云平台：OpenShift Platform Plus。

进一步阅读

寻找更多信息？请查看以下参考资料，获取更多关于红帽高级集群安全的信息：

KuppingerCole 报告领导者指南：容器安全：www.redhat.com/en/resources/kuppingercole-container-security-report-analyst-material
使用 Operator 安装 ACM：docs.openshift.com/acs/3.70/installing/install-ocp-operator.html
使用 Helm 安装 ACM: docs.openshift.com/acs/3.70/installing/installing_helm/install-helm-quick.html
使用 roxctl CLI 安装 ACM: docs.openshift.com/acs/3.70/installing/install-quick-roxctl.html
Kubernetes 的威胁矩阵 – 微软关于 MITRE ATT&CK®的文章：www.microsoft.com/security/blog/2020/04/02/attack-matrix-kubernetes/
保护 Kubernetes 免受 MITRE ATT&CK：初始访问 – 一系列关于 MITRE ATT&CK®框架的文章之一：cloud.redhat.com/blog/protecting-kubernetes-against-mitre-attck-initial-access
MITRE ATT&CK®知识库: attack.mitre.org/
配置漏洞报告: docs.openshift.com/acs/3.70/operating/manage-vulnerabilities.html#vulnerability-management-reporting_acs-operating-manage-vulnerabilities
管理合规性: docs.openshift.com/acs/3.70/operating/manage-compliance.html

第十三章：OpenShift Plus – 一个多集群企业级解决方案

在本书中，我们在第一章，混合云之旅与策略，讨论了与公共云使用相关的主要挑战，例如如何控制云成本，以及无论使用哪个云服务提供商，都能够保持一致、安全和合规的平台。我们还介绍了一些有助于多集群工作的工具，并从技术角度帮助解决这些挑战。

在第九章，OpenShift Pipelines – Tekton，和第十章，OpenShift GitOps – ArgoCD，我们讨论了使用 OpenShift 的CI/CD 管道和GitOps，包括部署到多个集群中。

在第十一章，OpenShift 多集群 GitOps 与管理，我们看到了如何使用Red Hat 高级集群管理从单一视图管理和观察多个集群，同时将工作负载部署到多个集群，并使用策略确保所有集群符合合规要求。

最后，在上一章—第十二章，OpenShift 多集群安全—我们介绍了Red Hat 高级集群安全工具，它通过实施安全策略、管理已知漏洞、评估安全风险和合规性，以及管理网络流量，帮助增强所有集群的安全性。

现在，我们在这一章中有两个不同的重点，第一是介绍混合云策略中的最后一个重要部分：Red Hat Quay，它将所有容器镜像存储在一个中央镜像注册表中，并使您的 CI/CD 过程更简单、更稳健；第二是讨论Red Hat OpenShift Plus产品，它将所有这些部分捆绑在一起，为您提供一个全面且具竞争力的解决方案。

因此，您将在本章中找到以下内容：

介绍 Red Hat Quay
使用 Quay Operator 部署 Red Hat
使用 Red Hat Quay
什么是 OpenShift Plus？
OpenShift Plus: 一个实际用例

那我们现在开始吧！

介绍 Red Hat Quay

Red Hat Quay 是一个企业级容器注册表平台，可以在 Red Hat Enterprise Linux 或 OpenShift 上运行，无论是本地还是云端。Red Hat Quay 提供了许多出色的镜像注册表功能，如下所示：

镜像漏洞扫描：使用 Clair 项目在镜像推送到注册表后，扫描镜像以查找已知漏洞。有关 Clair 的更多信息，请参见本章的进一步阅读部分。
地理复制：在两个或多个 Quay 实例之间同步镜像注册表内容，允许多个地理分布的 Quay 部署看起来像一个单一的注册表。这对于分布在遥远地区且延迟较高的环境特别有帮助。Quay 处理不同实例之间的异步数据同步，使得镜像对最终用户透明可用。
仓库镜像：同步两个或多个仓库到两个 Quay 实例之间。
访问控制：精细的权限控制允许您定义谁能读取、写入和管理组和仓库。您还可以利用机器人账户通过 Quay API 允许组织和仓库的自动化访问。

Red Hat Quay可在quay.io门户上作为托管服务使用，或者您可以选择自行管理，在这种情况下，您需要部署和维护它。

使用 Quay Operator 部署 Red Hat Quay

有多种部署 Quay 的方式，您可以在本章进一步阅读部分中找到产品的官方文档链接。出于教学目的，我们决定使用完全托管组件的 Quay Operator 来部署。

安装 Quay 作为企业容器注册表需要满足一些先决条件。

先决条件

使用 Operator 安装 Quay 的先决条件如下：

一个具有特权账户的 OpenShift 集群，用于部署和设置 Quay。
对象存储：支持的对象存储包括 Red Hat OpenShift Data Foundation、AWS S3、Google Cloud Storage、Azure Storage、Ceph/RadosGW Storage/Hitachi HCP Storage、Swift Storage 和 NooBaa。
集群容量可托管以下服务：
- PostgreSQL 或 MySQL 数据库。由于 Clair 安全扫描的增强功能，推荐使用 PostgreSQL。
- 代理服务器。
- 键值数据库。Redis 是存储非关键 Red Hat Quay 配置的默认选项。
- Quay，应用程序服务本身。

所有先决条件准备就绪后，我们可以安装 Quay Operator。请查看如何安装它的下一步骤。

操作员安装

部署 Quay Operator 的过程很简单。请按照下一步的说明操作：

转到Red Hat Quay。

图 13.1 – 搜索 Red Hat Quay Operator

点击磁贴，然后点击安装按钮。

图 13.2 – 安装 Red Hat Quay

保留默认选项，然后点击安装按钮。

图 13.3 – 操作员安装

安装操作员后，访问Quay 注册表选项卡，然后点击创建实例。

图 13.4 – 创建 Quay 注册表实例

可选地，在适当的字段更改名称并保留所有默认选项。

图 13.5 – Quay 实例创建

检查 Quay 注册表 选项卡。你将看到类似下面截图的状态列。

图 13.6 – Quay 实例已创建

一旦完成，点击刚创建的注册表并检查 注册表终端点 URL。

图 13.7 – Quay 终端点

点击注册表终端点地址。Quay 注册表应用程序将显示以配置你的多集群注册表。

配置 Quay

安装过程完成后，你将能够访问一些重要的终端点，这些终端点用于配置 Quay 操作员、Quay 注册表实例与 OpenShift 之间的集成。要使用它们，你需要按照以下步骤进行操作：

在安装 Quay 的命名空间中（在我们的例子中是 openshift-operators 命名空间），导航到 <objectInstanceName>-quay-config-editor-credentials-<randomPodId>。

图 13.8 – 检查 Quay 配置凭证

点击它并选择 显示值。

图 13.9 – Quay 凭证值

记下凭证并返回到 Quay 注册表操作员实例中的 配置编辑终端点。

图 13.10 – Quay 配置终端点

点击链接访问 配置编辑工具。使用你在上一步获得的凭证。

图 13.11 – Quay UI 配置工具

在此页面上，你可以更改许多 Quay 配置，例如 SSL 证书等——在我们的例子中，我们更改了 时间机器 过期时间。完成更改后，点击 验证配置更改。

图 13.12 – Quay 设置配置工具

配置验证完成后，选择 重新配置 Quay。

图 13.13 – Quay 配置工具验证

重要说明

此步骤将重启操作员 Pod，Quay 可能会在短时间内不可用。

Quay 配置编辑工具将自动更新 quay-config-bundle 密钥，用于存储配置参数。要查看它，导航到 quay-config-bundle 密钥并点击 显示值。之前所做的更改应已反映在该密钥中。

图 13.14 – 配置工具更改后的 Quay 密钥

如果一切看起来正常，你将能够开始使用你的 Quay 实例。请继续下一部分查看如何使用 Quay 的说明。

使用 Red Hat Quay

Red Hat Quay 的使用非常简单。一个用户友好的界面将帮助你配置额外的全局和安全设置。我们建议你创建一个组织，以按部门、区域或任何其他你想要的方式来组织你的 Quay 注册表：

在这个例子中，我们创建了一个名为multiclusterbook的组织。

图 13.15 – Quay 组织

接下来，我们创建了一个私有仓库来上传我们的镜像。

图 13.16 – Quay 仓库

学习如何使用 Red Hat Quay 的一个非常有用的方法是通过教程。你将看到如何操作。

运行教程

在 Quay UI 中提到的运行教程不是必需的，但它可以作为理解 Red Hat Quay 作为企业容器注册表的一个良好起点。本教程的第一步是通过终端登录到 Quay 注册表端点。我们使用docker login而不是podman login，使用docker run而不是podman run，等等：

$ podman login enterprise-registry-quay-openshift-operators.apps.vqdlv2pu.eastus.aroapp.io

你应该已经成功登录，否则请检查所使用的凭据。然后，尝试运行一个BusyBox容器镜像。

图 13.17 – Quay 教程

现在，运行以下命令为该仓库创建一个示例容器镜像：

$ podman run busybox echo "fun" > newfile
$ podman ps -l
CONTAINER ID  IMAGE                             COMMAND     CREATED         STATUS                     PORTS       NAMES
fd3b51f4c383  docker.io/library/busybox:latest  echo fun    16 seconds ago  Exited (0) 17 seconds ago              zealous_pascal
$ podman commit fd3b51f4c383 enterprise-registry-quay-openshift-operators.apps.vqdlv2pu.eastus.aroapp.io/multiclusterbook/openshift-gitops
$ podman push enterprise-registry-quay-openshift-operators.apps.vqdlv2pu.eastus.aroapp.io/multiclusterbook/openshift-gitops

很简单吧？！现在你的 Quay 容器注册表实例已配置好、测试通过并准备使用。开始在你的 CI/CD 流水线中探索它，向其中推送镜像，并将其作为你 DevOps 和 DevSecOps 流水线的企业容器注册表。

既然我们已经讨论了 Quay，让我们再深入了解一下 OpenShift Plus。接下来，你将继续发现为什么在你的混合云或多云战略中，应该关注并考虑 OpenShift Plus。

什么是 OpenShift Plus？

OpenShift Plus 是 Red Hat 的一项服务，将 OpenShift 平台与以下图中所示的产品捆绑在一起：

图 13.18 – OpenShift Plus 产品服务

以下产品包含在此服务中（除了 OpenShift 本身）：

高级集群管理：提供管理多个 OpenShift 和 Kubernetes 集群的功能。这些功能包括集群管理、可观测性、策略和合规性以及工作负载部署。我们在第十一章中深入探讨了这个产品，OpenShift 多集群 GitOps 与管理。如果你还没有看过这一章，我们强烈建议你回去阅读并逐步学习。
高级集群安全：通过漏洞管理、网络管理等功能增强你的 Kubernetes 和 OpenShift 集群的安全性。本产品在第十二章中有详细介绍，OpenShift 多集群安全。如果你还没有阅读这一章，我们也建议你现在去看看。
Quay 企业版注册中心：全球企业版注册中心在本章开头已经介绍过。
RWX 持久卷) 使用 RWO 持久卷) 使用 Ceph RBD 和由名为 Noobaa 的解决方案提供的对象存储。该产品在本书中未作详细介绍。如果您想了解更多信息，请查看我们在本章的 进一步阅读 部分中留下的链接。

如果您从本书一开始就跟随阅读，这些信息对您来说并不新鲜。我们现在将重点提供更多的额外信息，帮助您理解 OpenShift Plus 背后的价值主张，并解释为什么您应该考虑 OpenShift Plus，而不仅仅是仅仅考虑 OpenShift 平台。

价值主张：优势

OpenShift Plus 为您的多集群战略增加了一些极好的优势：

一致性：ACM 提供了治理功能，帮助您在所有集群中保持一致的配置。在安全性方面，ACS 还实现了可以定义的安全策略，这些策略将有助于确保所有集群都遵循这些策略。
可移植性：Quay 提供了一个全球镜像注册中心，所有集群都从中拉取镜像。ACM 还可以帮助您同时在多个集群上部署应用，并检查和监控它们的状态。通过与 OpenShift GitOps 一起使用，您可以利用ArgoCD实现GitOps部署实践，并保持应用程序的期望状态，无论您在哪个 OpenShift 集群和云提供商上运行它们。当然，集群之间的可移植性也取决于应用程序，因为应用程序解耦越多，迁移到不同的 OpenShift 集群和提供商之间就越容易。需要理解的重要一点是，ACM 和 Quay 有助于使您的应用程序更容易实现可移植性。OpenShift 数据基础也有助于使有状态工作负载更容易迁移，通过提供一种标准的方式，让应用程序能够访问持久卷，无论集群运行在哪种基础设施或云提供商上。
管理：管理多个不同环境中的集群通常不是一项简单的任务。公司通常会有很多人专门从事这一工作。通过使用 ACM，您可以将这项任务变得稍微轻松一些，并且可能会降低与此相关的成本。集群管理、可观察性和治理（策略）等功能有助于通过一个面板管理多个集群。
安全性：正如我们在第十二章中讨论的，OpenShift 多集群安全性，使少数几个集群在一般情况下安全且符合规范并不是一项困难任务，然而，当我们扩展到多个集群时，问题变得更加复杂。ACS 增加了轻松强制执行安全策略、检测漏洞并规划修复措施的能力。

除了 OpenShift Plus，红帽还为任何 OpenShift 客户提供一些额外增值产品，可在红帽混合云门户（cloud.redhat.com）上找到：

OpenShift 集群管理：这允许您查看高级别的集群信息，使用辅助安装程序创建新的集群，配置红帽订阅，基本级别的监控等。
成本管理：成本管理是一个有趣的工具，用于跟踪 AWS、Google Cloud、Azure 云提供商和 OpenShift 集群的成本和使用情况。它帮助您综合查看与多个云帐户相关的成本，并查看混合云基础架构的成本趋势，甚至可以用作按部门或团队使用量计费的依据。有关此工具的更多信息，请参阅本章的 Further reading 部分链接。

在下一个屏幕截图中，您可以看到 成本管理概述 屏幕的示例。

图 13.19 – 成本管理功能

开发者沙盒：这是一个免费的 OpenShift 环境，位于共享的多租户 OpenShift 集群中，预先配置了一组开发工具。用它作为您的测试沙盒和学习如何为 OpenShift 开发的环境。您将在本章的 Further reading 部分找到其链接。

除了前面列出的项目，从订阅成本的角度来看，OpenShift Plus 也许更合理。任何套餐通常价格优于单独购买每个部分。话虽如此，如果您对本章提到的 Plus 堆栈中的任何软件感兴趣，购买 OpenShift Plus 而不是仅购买 OpenShift 和软件可能更合适。请咨询您的红帽客户团队，并要求 OpenShift Plus 的报价。

现在我们已经讨论了拥有 OpenShift Plus 堆栈的一些好处，以及其何时真正引人注目的考虑因素，让我们使用一个虚构的用例作为示例，使其更具体化。

OpenShift Plus – 一个实际的用例

让我们考虑以下用例。尝试使用本书涵盖的概念，找出每个需求可以使用的工具。

用例：公司 HybridMyCloud 正在开发一个具有以下要求的 AI/ML 应用：

应用生命周期包括开发（Development）、质量保证（QA）、预生产（Pre-prod）和生产（Production）环境。
开发和 QA 可以共享相同的基础平台。由于监管需求，预生产和生产需要分开。生产应用需要在私有子网中，从互联网无法直接访问。
HybridMyCloud的 C 级管理层和采购部门与 AWS 签订了合同，因此希望将大多数资源托管在那里。然而，他们不希望被锁定在 AWS 上，并希望在需要时能够将应用程序迁移到 Azure。
这个 AI/ML 应用基于容器并且是无状态的，但它将图像存储在 S3 对象存储中。它接收 X 光图像，存储到 S3 对象存储中，并使用经过 ML 训练的模型对肺炎进行风险评估。
该应用程序处理受保护健康信息（PHI），因此HybridMyCloud希望符合健康保险流通与问责法案（HIPAA）。
这是一个关键任务应用程序，因此HybridMyCloud的企业架构师决定将该应用程序不仅部署在多个可用区，还要在 AWS 上使用多个区域。
HybridMyCloud定义的其他政策如下：
- 所有容器都需要为 CPU 和内存设置资源请求和限制。
- 切勿使用最新标签的镜像。
- 所有使用的镜像必须来自企业注册中心。严格禁止从企业注册中心以外的任何其他来源拉取镜像，包括非 Red Hat 认证的镜像注册中心。

那么，如何满足所有这些要求呢？有许多不同的选项可以匹配这些要求；OpenShift Plus 无疑是一个可以符合所有要求的好选择。让我们讨论一下基础设施应该是什么样的，以及如何在这个用例中使用 OpenShift Plus 工具：

需要多个 OpenShift 集群来满足这些要求：

一个开发和 QA 用的集群
一个预生产集群
两个生产集群，每个集群位于不同的 AWS 区域
一个备用集群在 Azure 上，可以在任何时候托管应用程序

你可以首先使用高级集群管理的集群生命周期管理功能，在 AWS 和 Azure 上部署这些集群。对于 S3 存储，可以使用本地云服务提供商的服务，或者选择使用OpenShift 数据基础设施与多云对象网关，这将带来以下好处：

使用对象桶声明（Object Bucket Claims）创建 S3 卷。
使用多云对象网关在 AWS 和 Azure 之间镜像卷。

部署完集群后，高级集群管理也可以用于以下操作：

高级集群管理与OpenShift GitOps结合使用，可以同时在多个集群中部署应用程序。
可以创建策略，将image.config.openshift.io/cluster自定义资源的allowedRegistries字段设置为仅允许来自企业注册中心的镜像运行。
使用可观察性功能来监控应用程序和集群的健康状况。

Quay 可以作为企业注册表，而嵌入式图像漏洞扫描工具可以作为发现已知漏洞的来源之一。ACS 可用于检测所有集群中的已知漏洞，并使用 HIPAA 政策评估这些漏洞。它还可以用于 CI/CD 流水线，执行清单的静态安全分析，并找出反模式，例如使用最新标签的镜像。

这些只是一些例子。我们在本书中涵盖的其他工具也可以使用，例如 OpenShift Pipelines 来实现 CI/CD 流水线，Cost Management 来跟踪与云服务商的成本，Red Hat 容器目录提供最佳容器基础镜像，等等。

总结

本章简要概述了 Red Hat Quay，这是一个有趣的容器镜像注册表选项。我们讨论了 OpenShift Plus 的主要优势，并说明了为何至少在混合云或多云战略中考虑使用 OpenShift Plus 是有意义的。最后，我们通过一个虚构的使用案例，思考了 OpenShift Plus 堆栈在实际场景中的应用。

哇，到目前为止真是一次伟大的旅程！我们在本书中已经涵盖了很多内容，非常高兴你能和我们一起走到这里。我们的长途旅程即将结束，但最精彩的部分即将到来：在下个章节中，我们将通过一个实际的案例，练习书中学到的大部分内容。我们将通过一个示例对 OpenShift Pipelines、GitOps 以及本书中涵盖的所有工具进行全面回顾，动手实践这些概念和工具，从零开始，并最终在多个集群中部署一个真实的功能应用。

我们鼓励你继续前进，尝试我们在下个章节中提出的练习。

进一步阅读

想要获取更多信息？请查阅以下参考资料，了解更多关于 Red Hat Quay 的内容：

Quay 产品文档: access.redhat.com/documentation/en-us/red_hat_quay/3.7
Quay 对象存储前提条件: access.redhat.com/documentation/en-us/red_hat_quay/3.7/html/deploy_red_hat_quay_on_openshift_with_the_quay_operator/operator-preconfigure#operator-storage-preconfig
Clair – 容器的漏洞静态分析: github.com/quay/clair

查阅以下参考资料以获取更多关于 Red Hat OpenShift 数据基础的相关信息：

OpenShift 数据基础智能页面: www.redhat.com/en/technologies/cloud-computing/openshift-data-foundation
OpenShift 数据基础产品页面: access.redhat.com/documentation/en-us/red_hat_openshift_data_foundation

查阅以下参考资料以获取有关 Red Hat OpenShift Plus 的更多信息：

OpenShift Plus 智能页面: www.redhat.com/en/technologies/cloud-computing/openshift/platform-plus

查阅以下参考资料以获取有关 Red Hat 成本管理的更多信息：

官方文档: access.redhat.com/documentation/en-us/cost_management_service/2022
上游项目: project-koku.github.io/

查阅以下参考资料以获取有关 OpenShift 开发者沙箱的更多信息：

入门指南: developers.redhat.com/developer-sandbox

第十四章：在混合云环境中构建云原生用例

到目前为止，这是一次美妙的旅程！我们已经通过这本书了解了很多内容，从 OpenShift 架构到 Pipelines、GitOps 和多云工具！现在我们即将达到本书的主要目标——帮助您做出最佳决策，并为您的 OpenShift 平台实施一个好的混合云/多云策略。为了以有用的内容总结本书，我们将采取一种实践的方法，全面回顾并构建和部署一个应用程序，涵盖本书中讨论的大部分功能：OpenShift Pipelines（Tekton）、OpenShift GitOps（ArgoCD）、高级集群管理、Quay 和高级集群安全。

因此，您将在本章中找到以下内容：

用例描述
使用 OpenShift Pipelines 和 S2I 构建应用程序
使用 OpenShift Pipelines 和 GitOps 进行应用程序部署
在构建和部署过程中添加安全检查
提供和管理多个集群
将应用程序部署到多个集群中

那么，我们在等待什么呢？现在就开始吧！

注意

本章中使用的源代码可以在github.com/PacktPublishing/OpenShift-Multi-Cluster-Management-Handbook/tree/main/chapter14获取。

用例描述

为了更贴近实际情况，这次我们将使用 Java 应用程序，使用Quarkus，它是构建现代云原生 Java 应用程序的绝佳选择。有关Quarkus的更多信息，请参阅本章的进一步阅读部分中的参考资料。

我们的应用程序源代码来自Quarkus 入门示例；请参考本章的进一步阅读部分了解更多信息。在本章中，我们将创建一个 CI/CD 管道，执行以下操作：

使用 s2i 构建应用程序，生成 Java 二进制文件。
将容器镜像推送到 Quay。
使用高级集群安全对镜像进行安全扫描。
使用 ArgoCD 在本地集群上部署应用程序。
使用 ArgoCD 和高级集群管理将应用程序部署到多个远程集群。

我们将使用高级集群管理来使所有 OpenShift 集群符合我们为它们定义的标准策略。为了便于学习和简化操作，我们将按顺序构建管道和其他对象，就像构建房屋时逐步添加构件一样。

图 14.1 – 综合回顾 - 构建块

我们假设您可以访问一个 OpenShift 集群，我们称之为 Hub 集群，该集群具有足够的资源，并且已经安装了以下工具：

OpenShift Pipelines
OpenShift GitOps
高级集群管理
高级集群安全
Quay
已安装并连接到 Hub 集群的oc命令行工具

我们还将在 AWS 上部署额外的单节点集群，作为托管的远程集群，进行多集群的应用程序部署。如果您还没有安装这些工具，请参考本书第9到13章中的安装过程。

本章中使用的源代码可以在我们的 GitHub 仓库中找到：github.com/PacktPublishing/OpenShift-Multi-Cluster-Management-Handbook/tree/main/chapter14。

让我们从深入了解第一个构建模块开始：应用程序构建。

使用 OpenShift Pipelines 和 S2I 进行应用程序构建

对于此步骤，我们将使用quarkus-build管道，您可以在chapter14/Build/Pipeline/quarkus-build.yaml文件中找到该管道。这个管道非常简单，并在下面的图中进行了解释：

图 14.2 – 用于构建 Java Quarkus 应用程序的管道

在这个管道中，我们使用了现有的 ClusterTasks 来完成所有工作：

git-clone：用于克隆 Git 仓库。
s2i-java：使用 S2I 和 Buildah 构建 Java 源代码，生成镜像并推送到 Quay 注册表。S2I 是一种非常便捷的方式，用于从许多不同语言（如 Java、Python、Node.js 等）构建代码。有关 S2I 的更多信息，请参见本章的进一步阅读部分。
openshift-client：用于运行部署应用程序的清单。应用程序清单使用Kustomize来声明 Kubernetes 清单。我们在本书的第十章《OpenShift GitOps – ArgoCD》中介绍了Kustomize；如果您还没有阅读，强烈建议您先阅读该章节，然后再回来执行本章中的步骤。

现在让我们创建并运行这个管道。如果您还没有操作过，请将此仓库分叉到您的 GitHub 账户：github.com/PacktPublishing/OpenShift-Multi-Cluster-Management-Handbook。分叉后，按照本节中的说明创建并运行此管道：

在您的机器上克隆该仓库：

$ GITHUB_USER=<your_user>
$ git clone https://github.com/PacktPublishing/OpenShift-Multi-Cluster-Management-Handbook.git

运行以下脚本并按照说明将原始仓库（PacktPublishing）的引用更改为您分叉的仓库：

$ cd OpenShift-Multi-Cluster-Management-Handbook/chapter14
$ ./change-repo-urls.sh
# Go to the Build folder
$ cd Build

运行以下命令来创建命名空间和管道：

$ oc apply -f Pipeline/namespace.yaml
$ oc apply -f Pipeline/quarkus-build-pi.yaml

您应该能够在 OpenShift 控制台中看到该管道，路径为Pipelines | Pipelines | Project: chap14-review-cicd，如以下截图所示：

图 14.3 – 创建的构建管道

你现在可以通过 Web 界面或终端运行管道。要通过终端运行，请执行以下命令：
```
$ oc create -f PipelineRun/quarkus-build-pr.yaml
```

关于镜像注册表的说明

该管道使用外部注册表来推送结果镜像。为了能够将镜像推送到注册表，你需要将包含注册表凭证的密钥与 pipeline ServiceAccount 链接。如果在运行管道之前没有这样做，你会发现它会在 build 任务中失败。在本章中我们使用的是 Quay，但你也可以使用任何外部镜像注册表，如 Nexus、Amazon Elastic Container Registry、Docker Hub 或其他。如果你决定使用 Quay，你需要创建一个机器人账户，给它在镜像仓库中的写权限，并将密钥导入到命名空间。接下来，你将了解如何操作。

接下来请查看如何配置你的 Quay 仓库，并将凭证与 pipeline ServiceAccount 链接。

配置镜像注册表

在 Quay 上创建新仓库后，按照以下步骤配置它：

访问仓库的设置标签，并进入用户和机器人权限部分，点击创建机器人账户链接：

图 14.4 – 创建机器人账户

给它任意名称并点击创建机器人账户按钮：

图 14.5 – 创建机器人账户

然后，修改权限为写并点击添加权限：

图 14.6 – 设置写权限

点击机器人账户链接，下载我们将用来与管道 ServiceAccount 链接的密钥：

图 14.7 – 机器人账户

通过点击下载 -secret.yml链接，下载密钥文件，位置在Kubernetes 密钥标签中：

图 14.8 – 下载 Quay 凭证

拿到密钥的 YAML 文件后，你可以继续在 OpenShift 上创建它。接下来将展示如何操作。

链接镜像注册凭证

既然我们已经在工作区中拥有密钥文件，现在可以运行以下命令来创建密钥并将其链接到管道 ServiceAccount。或者，你也可以直接运行我们为你准备的 GitHub 仓库中的 link-image-registry-secret.sh 脚本，它会执行同样的操作：

$ SECRET_FILE=<secret-file-which-contains-image-registry-credentials>
$ SECRET_NAME=<secret-name>
$ oc create -f $SECRET_FILE --namespace=chap14-review-cicd
$ oc patch serviceaccount pipeline -p '{"secrets": [{"name": "$SECRET_NAME"}]}' --namespace=chap14-review-cicd
$ oc secrets link default $SECRET_NAME --for=pull -n chap14-review-cicd

如果你在管道的构建任务中遇到错误，现在可以通过运行以下命令再次运行它：

$ oc create -f PipelineRun/quarkus-build-pr.yaml

现在你应该能看到管道成功完成，如下截图所示：

图 14.9 – 构建管道成功运行

管道成功运行后，你可能想查看镜像在 Quay 上的样子。

查看 Quay 上的镜像

如果您使用的是 Quay，此时您应该能够在其中查看并检查镜像：

图 14.10 – Quay 上的镜像，已自动检测到已知漏洞

如我们所见，Quay 自动检测到此镜像存在一些已知的漏洞。我们将在本章中进一步修复这些漏洞，但现在重要的是，您要观察并理解推送镜像并自动检查已知漏洞是多么容易。

现在，我们已经让应用的构建管道正常工作，接下来让我们将其演变为使用 ArgoCD 作为部署工具，并利用 GitOps 实践。

使用 OpenShift 管道和 GitOps 进行应用部署

这次，我们将使用 ArgoCD 来部署应用，而不是直接运行 Kubernetes 清单。管道基本相同，但现在部署任务将运行一个 YAML 文件，创建一个 ArgoCD 应用，并等待应用变为健康状态。

图 14.11 – 用于构建 Java Quarkus 应用并使用 ArgoCD 部署的管道

运行以下命令以创建并运行管道：

$ cd OpenShift-Multi-Cluster-Management-Handbook/chapter14/Deploy
$ oc apply -f Rolebindings/ # Permission required for Tekton to create an ArgoCD application
$ oc apply -f Pipeline/quarkus-build-and-deploy-pi.yaml
$ oc create -f PipelineRun/quarkus-build-and-deploy-pr.yaml

将创建一个新的PipelineRun，用于构建容器镜像并创建 ArgoCD 应用程序来部署应用。只要一切正常，您将看到如下所示：

图 14.12 – 使用 ArgoCD 的任务部署

访问 ArgoCD 控制台，检查那里的应用部署；您应该能看到类似于下面的截图：

图 14.13 – ArgoCD 中的应用

您可以在第十章中找到关于如何访问 ArgoCD 控制台的说明，OpenShift GitOps – ArgoCD。提醒一下，以下是获取 ArgoCD URL 和管理员密码的命令：

# Get the ArgoCD URL:
$ echo "$(oc get route openshift-gitops-server -n openshift-gitops --template='https://{{.spec.host}}')"
# Get the Admin password
$ oc extract secret/openshift-gitops-cluster -n openshift-gitops --to=-

现在，我们的管道已经构建了应用，推送到了 Quay，并通过 ArgoCD 进行了部署。下一步是将高级集群安全引入，以便在管道中添加一个安全检查步骤。接下来看看如何操作。

在构建和部署过程中添加安全检查

这次，我们将在已经构建的镜像中添加一个新的步骤进行安全检查。我们将使用高级集群安全（Advanced Cluster Security）来实现这一点。要成功使用它，您应该已经安装了高级集群安全，并将本地集群配置为安全集群。请参考第十二章，OpenShift 多集群安全，查看如何操作。

接下来查看我们现在的管道是什么样的：

图 14.14 – 带有安全检查的管道

因此，以下任务已添加到管道中：

security-check：使用 ACS API 检查镜像是否符合 ACS 中定义的现有安全策略。

为了模拟安全问题，我们还将使用一个自定义的 s2i-java 任务，该任务使用一个旧版本的 ubi-openjdk，该版本包含许多已知漏洞。为了解决这些问题，我们将构建策略更改为使用一个 Dockerfile，该文件使用最新版本的 RHEL UBI 镜像并附加了安全修复。

按照本节中的说明创建并运行此流水线：

在我们进入流水线之前，需要配置流水线与 ACS 之间的集成。为此，访问 高级集群安全 仪表盘，导航到 平台配置 | 集成 | 身份验证令牌，然后点击 API 令牌：

图 14.15 – 创建 ACS API 令牌

点击 生成令牌 按钮：

图 14.16 – 生成令牌

填写名称并在角色字段中选择 持续集成：

图 14.17 – 为 CI 生成令牌

复制已生成的令牌。我们将在一个机密中使用它，该机密将被流水线任务用来在 ACS API 上进行身份验证：

图 14.18 – 复制 API 令牌

现在让我们创建机密。使用上一步中的令牌和 ACS 中央端点运行以下命令。请不要在 rox_central_endpoint 主机中使用 http(s)：

oc create secret generic acs-secret --from-literal=rox_api_token='<token from previous step>' --from-literal=rox_central_endpoint='<host-for-rhacs-central-server>:443' --namespace=chap14-review-cicd

现在我们已经准备好创建并运行我们的流水线。运行以下命令：

$ cd OpenShift-Multi-Cluster-Management-Handbook/chapter14/DevSecOps
$ oc apply -f Task/ # Create the custom S2I and stackrox-image-check tasks
$ oc apply -f Pipeline/quarkus-devsecops-v1-pi.yaml
$ oc create -f PipelineRun/quarkus-devsecops-v1-pr.yaml

你应该看到 security-check 任务失败，因为我们故意使用了包含许多已知漏洞的旧版基础镜像：

图 14.19 – 安全检查失败

让我们简要看一下由于此任务而产生的错误。失败的策略如下：

至少重要的可修复严重性：如预期的那样（记住我们现在使用的是旧版本的基础镜像），镜像中有多个组件存在重要和关键的已知 CVE。
ubi-minimal，其中包括 microdnf 作为包管理器。

现在我们将演示如何使用一个 Dockerfile 来修复这些安全问题，该文件解决了所有这些问题。

修复安全问题

为了解决这些问题，我们将修改流水线，使用 Dockerfile 而不是 S2I。为此，我们将 build 任务更改为使用 buildah 集群任务，而不是 s2i-java：

    - name: build
      params:
        - name: IMAGE
          value: $(params.IMAGE_NAME)
        - name: CONTEXT
          value: $(params.PATH_CONTEXT)
        - name: DOCKERFILE
          value: src/main/docker/Dockerfile.multistage #[1]
        - name: TLSVERIFY
          value: 'false'
      runAfter:
        - fetch-repository
      taskRef:
        kind: ClusterTask
        name: buildah #[2]
      workspaces:
        - name: source
          workspace: workspace

让我们看一下突出显示的数字表示的含义：

[1]：包含安全修复的 Dockerfile 的路径
buildah 集群任务将使用给定的 Dockerfile 构建应用程序

让我们还看一下 Dockerfile 以理解安全修复。这个文件位于 quarkus-getting-started/src/main/docker/Dockerfile.multistage，在我们的 GitHub 上：

## Stage 1: build with maven builder image with native capabilities
FROM quay.io/quarkus/ubi-quarkus-native-image:22.2-java17 AS build
(.. omitted ..)
RUN ./mvnw package -Pnative
FROM registry.access.redhat.com/ubi8/ubi-minimal #[1]
WORKDIR /work/
COPY --from=build /code/target/*-runner /work/application
RUN chmod 775 /work /work/application \
  && chown -R 1001 /work \
  && chmod -R "g+rwX" /work \
  && chown -R 1001:root /work \
  && microdnf update -y \ #[2]
  && rpm -e --nodeps $(rpm -qa '*rpm*' '*dnf*' '*libsolv*' '*hawkey*' 'yum*') #[3]
EXPOSE 8080
USER 1001
CMD ["./application", "-Dquarkus.http.host=0.0.0.0"]

让我们来看一下高亮的数字表示什么意思：

ubi-minimal 作为基础镜像。
[2]：将操作系统包更新到最新版本。
[3]：从镜像中移除包管理器。

高亮的行确保了使用的是最新的组件，这些组件包含了最新的安全修复，同时包管理器在打包前已经从镜像中移除。

现在，让我们创建这个新的管道版本并运行它，检查安全问题是否已解决。为此，运行以下命令：

$ oc apply -f Pipeline/quarkus-devsecops-v2-pi.yaml
$ oc create -f PipelineRun/quarkus-devsecops-v2-pr.yaml

这次，管道应该能够成功完成，因为我们的容器镜像中再也没有检测到安全问题：

图 14.20 – 安全问题已修复

现在，您可以选择检查 ACS，看看是否还有其他可以稍后修复的违规问题。如果您想这么做，请导航到 Namespace: chap14-review-cicd 和 Deployment: quarkus-quickstarts。您仍然应该看到一些小的违规问题，具体如下：

图 14.21 – ACS 违规

你还记得之前 Quay 报告过我们镜像中的一些漏洞吗？现在看看它，看看我们新版本的镜像：

图 14.22 – Quay 安全扫描

如您所见，较新的镜像没有检测到安全问题。在本节中，我们在管道中添加了安全检查，并修复了通过此管道检测到的一些漏洞。在下一节中，我们的管道将能够使用 ArgoCD 和高级集群管理来部署我们的应用程序到多个集群中。

创建和管理多个集群

到目前为止，我们还没有涉及混合集群或多集群方面的内容。接下来我们将要添加的是：部署到多个远程集群。为此，我们将使用高级集群管理来创建新集群，并帮助我们在这些集群中部署应用程序。

创建新集群

我们将使用 AWS 来托管两个新集群，这些集群将作为远程集群用于测试我们的管道。为了节省资源，我们将使用单节点集群，因此我们不需要为此练习购买多个服务器。如果您已经有可用的集群，可以选择导入现有的集群，而不是创建新的集群。您可以在本章的 进一步阅读 部分找到一个链接，里面包含了如何在高级集群管理中导入集群的说明。

要使用 ACM 创建单节点集群，您需要添加 AWS 凭证，进入凭证菜单，然后点击 添加凭证 按钮：

图 14.23 – 添加 AWS 凭证

跟随向导并填写所有必填字段。你需要提供拉取密钥，可以在console.redhat.com/openshift/downloads找到：

图 14.24 – 添加新凭证

创建 AWS 凭证后，访问 基础设施 | 集群功能并点击 创建集群 按钮：

图 14.25 – 配置新集群

选择 AWS 作为基础设施提供者，并填写向导中的以下数据，但在最后一步不要点击创建按钮：

基础设施提供者：Amazon Web Services
基础设施提供者凭证：aws（你在上一步创建的凭证名称）
ocp-prd1
集群组：默认
基础 DNS 域名：你在 AWS 上的公共域名（例如，example.com）
发布镜像：选择最新的
env=prod
m5.2xlarge
网络：保持不变
代理：保持未选中
自动化：保持空白

在审核页面上，选择 YAML：开启 按钮：

图 14.26 – 编辑 YAML

在 YAML 文件中，编辑 MachinePool 并添加语句 skipMachinePool: true，如下所示：

图 14.27 – 编辑 MachinePool

点击 install-config 标签，并将主节点副本数更改为 1，计算节点副本数更改为 0：

图 14.28 – 编辑 install-config

现在使用之前相同的参数，点击ocp-prd2。最终，你应该能看到两个集群正在被配置，如下图所示：

图 14.29 – 集群创建中

配置过程大约需要 40 分钟。当你看到两个集群标记为已就绪时，继续下一步。

集群治理

ACM 提供的一个有用功能是使用策略进行集群治理。我们已经在第十一章《OpenShift 多集群 GitOps 和管理》中介绍了这个功能。如果你还没有阅读，强烈建议你查看那一章。我们将部署位于 GitHub 仓库中Governance文件夹下的策略，以便检查托管集群的 etcd 密钥存储是否加密。为此，请运行以下命令：

$ cd OpenShift-Multi-Cluster-Management-Handbook/chapter14/Governance
$ oc apply -k .

等待几秒钟，访问 ACM 上的治理功能，检查集群的合规性：

图 14.30 – 集群合规性

移动到下一部分，查看如何将我们的示例应用同时部署到多个远程集群中。

将应用部署到多个集群中

现在我们已经拥有多个远程集群，我们可以继续使用 ACM 和 ArgoCD 使我们的流水线能够同时部署到所有集群中。我们将修改部署任务，使用一个 ApplicationSet 对象，它将负责将我们的应用程序同时部署到两个 OpenShift 远程集群中。

图 14.31 – 支持多集群部署的流水线

为了让 ArgoCD 识别 ACM 管理的集群，我们首先需要创建一些对象，比如 GitOpsCluster 自定义资源。我们在第十一章，《OpenShift 多集群 GitOps 与管理》中详细讲解了这些对象。请运行以下命令来创建这些对象：

$ cd OpenShift-Multi-Cluster-Management-Handbook/chapter14/Multicluster-Deployment
$ oc apply -f GitOpsCluster/

现在，让我们创建并运行流水线，使用 ApplicationSet 对象将应用程序部署到具有 env=prod 标签的受管集群中。记住，我们在使用 ACM 配置集群时已经使用了这个标签。如果你是在 ACM 中导入的集群，请确保为这些集群添加 env=prod 标签：

$ oc apply -f Rolebindings/ # Permissions required for pipeline to be able to create an ApplicationSet
$ oc apply -f Pipeline/quarkus-multicluster-pi.yaml
$ oc create -f PipelineRun/quarkus-multicluster-pr.yaml

当流水线完成时，你应该已经有了两个新的 ArgoCD 应用程序，这些应用程序是通过 ApplicationSet 机制自动创建的：

图 14.32 – ArgoCD 和 ApplicationSet

就这样，我们成功了！我们从一个简单的构建流水线开始，现在它已经能够执行安全检查，并且能同时部署到多个远程集群！

总结

感谢你成为我们旅程中的伙伴！我们希望这本书的内容对你有所帮助，现在你应该对书中涉及的主题有了很好的理解。我们涵盖了架构、人员、部署、故障排除、多集群管理、使用和安全等内容。这么多内容，起初我们还以为无法写完！如果你还在这里，我们觉得自己这本书的使命已经完成！

有一句来自约翰·沃尔夫冈·冯·歌德的名言：“知道是不够的，我们必须应用。愿意是不够的，我们必须做。” 阅读完这本书后，我们希望你不仅学到了新知识，还能将其付诸实践。通过这段混合云之旅，你有机会通过生动的示例和我们倾注心血的内容，快速提升你的知识水平。

我们希望这本书能够成为你的一本手册，并对你在规划和执行适合企业的模型时有所帮助，提供多种可用选项、实现方案以及良好的洞察，助力你的知识积累和职业发展。

为了总结本章的内容，我们设计了以下图表，作为每一章核心主题的快捷方式，帮助你回顾我们一起走过的整个旅程：

图 14.33 – 本书旅程

本书已接近尾声，但我们还没有完全结束。我们为您准备了最后一章，提供了一些建议，帮助您在本书之后继续学习和提升您的 OpenShift 和 Kubernetes 技能。

我们鼓励您继续阅读下一章，查看我们在其中建议的培训和其他内容。

进一步阅读

想获取更多信息吗？请查看以下参考资料以获取更多信息：

Quarkus：
- 主页: quarkus.io/
- Quarkus 入门示例: github.com/quarkusio/quarkus-quickstarts/tree/main/getting-started
S2i：
- GitHub 页面：github.com/openshift/source-to-image
- 如何创建 S2I Builder 镜像（博客文章）：cloud.redhat.com/blog/create-s2i-builder-image
- 在 Tekton 中使用 Source 2 Image 构建（博客文章）：cloud.redhat.com/blog/guide-to-openshift-pipelines-part-2-using-source-2-image-build-in-tekton
- Tekton Hub - S2I: hub.tekton.dev/tekton/task/s2i
高级集群管理 – 导入集群: access.redhat.com/documentation/en-us/red_hat_advanced_cluster_management_for_kubernetes/2.5/html/clusters/managing-your-clusters#importing-a-target-managed-cluster-to-the-hub-cluster
高级集群安全 – 来自 Tekton Hub 的镜像检查: hub.tekton.dev/tekton/task/stackrox-image-check

第五部分 – 持续学习

在这一部分中，您将获得一些额外的内容，继续您的 OpenShift 专家之路。在这里，您将看到市场上可用的培训总结，帮助您深入了解 OpenShift 的启用。

本书的这一部分包括以下章节：

第十五章，接下来做什么？

第十五章：下一步

学习永远不会使大脑感到疲倦。

– 列奥纳多·达·芬奇

最后一章！在我们写这本书时，我们曾思考过什么样的最后一章会比较合适。我们坚信，学习永无止境！话虽如此，我们得出结论，好的最后一章应该涉及一些关于培训的建议，以及你可以采取的下一步行动，帮助你持续学习和深化知识——我们希望你喜欢我们在这里介绍的选项。

我们特别关注以下领域：

Red Hat 培训
在线学习平台
免费培训和参考资料

Red Hat 培训

很明显，任何组织都能从培训和赋能中获益。简而言之，培训能够提高生产力、减少浪费、标准化流程，并激发内在动力。国际数据公司（IDC）2020 年在五个不同国家及拥有超过 11,000 名员工的公司所做的研究发现，接受 Red Hat 提供的培训的公司获得了以下益处：

开发运维（DevOps）团队的生产力提高了 44%。
接受培训的信息技术（IT）基础设施团队的效率比未接受培训的团队高出 34%。
团队部署新 IT 资源的速度比以前快 59%。
新员工能以比以前快 76%的速度实现完全生产力。

然而，市场上有大量不同的培训和资源可供选择，适合每个预算！因此，我们在这里提供了一些关于在哪里寻找赋能的建议，帮助你和你的团队了解 OpenShift。将本章中找到的参考资料与在第四章中看到的角色（OpenShift Personas and Skillset）结合，你们很可能会成功且顺利地实现 OpenShift 的采纳！

本章内容包括：

建议的培训资源列表
互联网上的参考资料，你可以在其中查找有关 OpenShift 的文档、教程和帖子
有助于你和你的团队成为 OpenShift 专家的认证列表

参考资料

请查看前文提到的完整 IDC 研究，网址：red.ht/IDCTraining。

培训和认证

本书旨在成为 OpenShift 的全面参考资料，我们涵盖了一些关于架构、部署、操作和多集群工具的重要话题。然而，我们可以自信地说，OpenShift 是一个充满不同文化的世界！因此，尽管本书将帮助你在学习旅程中取得进展，但我们强烈建议你通过培训进一步自我提升。在本节中，你将找到我们建议给那些想要深入了解 OpenShift 知识的专业人士的技能路径。

技能路径

我们在此为你提供了三种不同的建议技能路径：

DevOps 转型：针对希望在 OpenShift 上使用 DevOps 和敏捷实践及工具的 DevOps 和站点可靠性工程（SRE）工程师。正如我们在第四章中看到的，OpenShift 角色与技能集，这一角色通常涉及自动化和流程，因此在此技能路径中，您将找到涵盖 DevOps 相关人员、流程和技术的课程。
Kubernetes：这是一个针对那些想要深入了解 Kubernetes 本身的人的路径。由于 OpenShift 是基于 Kubernetes 运行的，因此本路径中的培训对 OpenShift 也很有价值；然而，它是独立于任何 Kubernetes 发行版的，不专注于如 OpenShift 等特定发行版。
OpenShift：涵盖 OpenShift 使用、开发和管理的培训。在本节中，您将看到为每个角色建议的培训和认证列表。

请查看以下各部分，了解每个技能路径的更多信息。

DevOps 转型

在本节中，我们建议进行涉及人员、流程和技术相关方面的培训。

DevOps 文化和实践赋能

我们知道 DevOps 已经被广泛采用并且几乎在各个领域都有应用；然而，根据我们的个人经验，许多公司不幸没有意识到其实施的好处。这主要是因为这些公司常常忽视文化转变的实现：文化转变是 DevOps 中最具挑战性的部分——从我们的角度来看，远远超出了其他方面。如果您感觉自己和团队需要一次文化上的刷新，那么这门课程非常适合您。它采用实践性的方法，提供为期 5 天的沉浸式培训，我们建议您与您的团队一起参加，以便使用敏捷方法论和 DevOps 实践体验接近真实世界的交付。以下是课程概览：

适用于 DevOps 旅程的开放实践

前一个培训专注于文化，而本次培训则专注于流程。它带领学员完成由 DevOps 实践驱动的项目的发现、规划和交付过程。以下是课程概览：

红帽 DevOps 流水线和流程：使用 Jenkins、Git 和测试驱动开发进行 CI/CD

为了闭合人（文化）、流程和技术之间的循环，本培训将围绕持续集成/持续交付（CI/CD）技术，使用 Git、Jenkins 和测试驱动开发（TDD）来培养 DevOps 团队的技术技能。这是一个实践性强的培训课程，使用示例应用来学习如何使用这些列出的技术。可以在这里查看课程概览：

Kubernetes

市面上有很多关于 Kubernetes 的培训课程，包括收费和免费的。我们在这里列出了一些好的参考资料，帮助你更深入地了解 Kubernetes。

Kubernetes 基础

我们首先要提到的是来自官方 kubernetes.io 门户的教程。在这个教程中，你将通过一些基本课程进行学习，例如使用 minikube 创建 Kubernetes 集群、应用部署、扩展和更新。它使用互动环境，让你可以一步一步地以实践的方式进行练习。以下是该课程的概览：

另一个很好的实践参考是名为 Kube by Example 的项目，接下来我们将详细介绍。

Kube by Example

这个项目包含了多个实践示例，帮助你更好地学习 Kubernetes。你可以学习关于基本概念的课程，例如什么是 pod、部署、服务、命名空间等，同时也有与应用开发相关的学习路径等。请看一下该课程的概览：

认证

有三个官方 Kubernetes 认证，每个认证侧重于验证不同的技能集，具体可以参考下表：

OpenShift

红帽公司提供了许多优秀的培训课程和认证，可以帮助你深入学习 OpenShift 的实用知识。以下图示展示了红帽推荐的培训和认证，能够全面深入地了解 Linux、容器以及 OpenShift 管理和开发：

图 15.1 – OpenShift 培训和认证

访问此网站，了解更多关于培训课程和认证的详细信息：www.redhat.com/en/services/training/all-courses-exams

红帽学习订阅（7 天免费试用）

如果你有兴趣参加上述 OpenShift 技能路径，红帽学习订阅（RHLS）是一个不错的选择！通过这个订阅，你可以访问数百个在线课程和实践实验室。某些选项仅包含课程，而其他选项还包括认证。欲了解更多信息，请访问该网站：www.redhat.com/en/services/training/learning-subscription。

你还可以参考在线学习平台，了解更多内容；更多建议请见下一部分。

在线学习平台

我们也不能忘记提到一些在线学习平台。如今，在线学习平台上有大量优质的学习资源，你可以在这里找到一些平台的列表：

A Cloud Guru: acloudguru.com/browse-training
Pluralsight: www.pluralsight.com/
Cloud Academy: cloudacademy.com/search/
Whizlabs: www.whizlabs.com/

如果您正在寻找更多免费的培训内容，可以查看下面展示的几个选择。

免费培训和参考资料

如果我的钱包空空如也，负担不起培训费用怎么办？我们没有忘记你！接下来，我们将看到一些可以免费学习 OpenShift 的选项。

OpenShift 容器平台演示与研讨会指南

一个很好的免费参考是OpenShift 容器平台演示与研讨会指南页面。在这里，您将找到一些演示视频记录，还可以找到实验文档的链接等。您将发现各种各样的演示内容，涵盖集群安装、人工智能（AI）/机器学习（ML）、应用开发、GitOps 和安全等内容。您可以在这里找到更多信息：

OpenShift 4 101 研讨会

Red Hat 服务团队在记录关于 Red Hat 产品的精彩研讨会方面做得非常出色。其中之一是 OpenShift 4 101 研讨会，这是一个非常好的 OpenShift 培训，涵盖了应用开发、部署和管理、CI/CD 流水线等内容。更多信息如下：

Open Demos

一个很好的技术信息来源是网络研讨会和演示。在Open Demos页面，您可以找到下一个免费网络研讨会的时间表，任何人都可以参加。更多信息请点击此处：

Red Hat 开发者门户

Red Hat 开发者门户还包含大量的优秀免费参考资料，从免费教程到开发者沙箱都有。欲了解更多信息，请访问：

YouTube 和 Twitch

您将在YouTube和Twitch上找到精彩的内容。例如，Red Hat 产品管理团队每个季度都会举办一次OpenShift 新功能的会议，详细介绍下一版本将引入的主要创新。这是了解产品未来发展方向的绝佳信息来源。欲了解更多信息，请访问：

博客

博客是保持更新并找到一些精彩演示和实验的绝佳参考。以下是一些关于 OpenShift 的优秀博客：

产品文档

始终参考 OpenShift 文档以了解其功能并解答任何疑问。官方文档可以在以下网站找到：docs.openshift.com。

摘要

在本章中，我们已经列出了推荐的培训、技能路径和认证，以帮助你深入了解 OpenShift。我们还提供了一些免费的参考资料，如果你不想（或者不能！）支付培训费用。如果你有兴趣在此领域成为主题专家(SME)，我们鼓励你考虑这些资源。

结束语

恭喜你——你已经完成了本书的学习！我们做到了！我们真心希望你现在对在云端、本地甚至是从一个集群到多个集群的 OpenShift 工作感到更加准备充分和自信！感谢你在这本书中的陪伴，我们期待不久后能再见到你！

我们衷心感谢你，正如我们所说，学习是一个持续的过程，信息的来源是无穷无尽的。为了帮助你在无数机会的道路上不迷失方向，我们为你提供一些建议：

看一看如今可用的技术选项。
研究那些在易用性、学习、文档、就业和职业机会等方面被广泛采用和吸收的技术。
选择前进的道路，并保持专注。
新兴技术可以是一个不错的选择，但往往伴随着风险。如果你想采用新技术，别忘了考虑你制定的路径和计划，因为这将帮助你持续理解你所在的位置以及你想去的地方。
把你的发现记录下来——它们很快就会对你有所帮助。
在学习过程中，腾出时间与家人和朋友一起休闲。
定期锻炼——健康的身体也能孕育健康的心灵。

“Mens sana in corpore sano.” – 德基穆斯·尤努斯·尤文纳利斯

随着 Kubernetes 和 OpenShift 生态系统每天都在不断发展，务必查看 OpenShift 官网和博客，了解最新的功能，并保持对更新和路线图的关注。如果你所在的公司有 Red Hat 账户团队提供支持，记得与他们保持频繁联系。Red Hat 拥有一支出色的团队来协助客户，他们始终致力于让客户在使用产品时感到舒适和满意，所以不要犹豫，利用他们作为你的盟友。

现在，是时候说再见了——或者更好地说：在外面见！如果你有任何问题或改进的建议，或者只是想打个招呼，可以通过我们的社交网络、GitHub，或者Packt 社区平台与我们联系。再次感谢你，我们希望你喜欢《OpenShift 多集群管理手册》！

posted @ 2025-07-08 12:23 绝不原创的飞龙阅读(8) 评论(0) 收藏举报

刷新页面返回顶部

龙哥盟

掠夺·扩张·投机·博弈

Openshift-多集群管理秘籍-全-

Openshift 多集群管理秘籍（全）

前言

本书适用人群

本书内容

为了从本书中获得最大收益

下载彩色图像

下载示例代码文件

使用的约定

与我们取得联系。

分享您的想法。

下载本书的免费 PDF 副本。

第一部分 – 为 Red Hat OpenShift 设计架构。

第一章：1

混合云之路与策略

公共云的主要挑战

公有云的好处

混合云是解决方案吗？

容器和 Kubernetes – 部分答案！

OpenShift - 一个完整的选项

OpenShift 产品 – 多种选择满足各种需求

OpenShift 托管云服务

托管还是自管理——哪个更好？

OpenShift 安装方式

OpenShift 多集群工具 – 超越预期

Red Hat 高级集群管理 for Kubernetes – 统一管理

Red Hat 高级集群安全 for Kubernetes – 在任何地方都能保障应用安全

Red Hat Quay – 在中央仓库中存储和管理容器镜像

OpenShift Plus – 完整套餐

摘要

进一步阅读

第二章：2

架构概述与定义

技术要求

先决条件

理解基础概念

主节点

引导节点

工作节点

工作节点类型

高可用集群

OpenShift 架构概念和最佳实践

安装模式

IPI

UPI

无关安装程序

计算

主节点的资源配置

基础设施节点的资源配置

工作节点的资源配置

可分配资源

推荐的可分配资源

示例

聚合日志

监控

存储

存储后端

in-tree 卷插件

CSI 驱动程序

存储需求

服务器硬盘

OpenShift 内部注册表

OpenShift 日志

OpenShift 监控

示例

计算大小

存储大小

总结

基础设施/云提供商

网络考虑事项

VPC/VNet

DNS

负载均衡器

DHCP/IPMI/PXE

网络访问

其他考虑事项

SSL 证书

IdP