SERVICE MESH 2.X 1.1. 关于 OPENSHIFT SERVICE MESH 1.2. SERVICE MESH 发行注记 1.3. 了解 SERVICE MESH 1.4. 服务网格部署模型 1.5. SERVICE MESH 和 ISTIO 的不同 1.6. 准备安装 SERVICE MESH 1.7. 安装 OPERATOR 1.8. 创建 SERVICEMESHCONTROLPLANE 注 第 第 1 章 章 SERVICE MESH 2.X 15 NONE 没有进行规范化。Envoy 接收的任何内容都会完全 按原样转发到任何后端服 务。 ../%2Fa../b 由授权策略 评估并发送到您的服务。 此设置会受到 CVE- 2021-31920 的影响。 BASE 这是目前 Istio 默 默认 认安装 中使用的选项。这在 Envoy 代理上应用 normalize_path 环境中安装 Red Hat OpenShift Service Mesh 。 1.4. 服务网格部署模型 Red Hat OpenShift Service Mesh 支持几种不同的部署模型，它们可以以不同的方式组合以满足您的业务 需求。 1.4.1. 单网格部署模型 最简单的 Istio 部署模型是一个网格。 网格中的服务名称必须是唯一的，因为 Kubernetes 只允许一个服务在 mynamespace

到 OpenShift Container Platform 4.14 后出现问题，其中已删除的 API 仍在由运行或与集群交互的工作负 载、工具或其他组件使用。管理员必须针对将要删除的任何 API 评估其集群，并迁移受影响的组件，以使 用适当的新 API 版本。完成此操作后，管理员可以向管理员提供确认。 所有 OpenShift Container Platform 4.13 集群都需要此管理员确认，然后才能升级到 念，并添加了新功能。 在 OpenShift Container Platform 4.14 中 OLM 1.0 的技术预览阶段，管理员可以探索以下功能： 支持 支持 GitOps 工作流的全声明性模型 工作流的全声明性模型 第 第 1 章 章 OPENSHIFT CONTAINER PLATFORM 4.14 发 发行注 行注记 记 21 OLM 1.0 通过两个 API 简化了 Operator 管理： 服务发现。 已更改 已更改 修改了 KubeAggregatedAPIDown 警报和 KubeAggregatedAPIErrors 警报，以仅评估 apiserver 作业的指标。 修改 KubeCPUOvercommit 警报，以仅评估 kube-state-metrics 作业的指标。 修改 NodeHighNumberConntrackEntriesUsed,NodeNetworkReceiveErrs

这些工具可组合使用，因此您可自由选择对您有用的工具。 2.1.3. Operator 成熟度模型 Operator 内部封装的管理逻辑的复杂程度各有不同。该逻辑通常还高度依赖于 Operator 所代表的服务类 型。 对于大部分 Operator 可能包含的特定功能集来说，可以大致推断出 Operator 封装操作的成熟度等级。就 此而言，以下 Operator 成熟度模型针对 Operator 的第二天通用操作定义了五个成熟度阶段： 的第二天通用操作定义了五个成熟度阶段： 图 2.1. Operator 成熟度模型 成熟度模型 以上模型还显示了如何通过 Operator SDK 的 Helm、Go 和 Ansible 功能更好地开发这些功能。 2.2. OPERATOR FRAMEWORK 打包格式 本指南概述了 OpenShift Container Platform 中 Operator Lifecycle Manager (OLM) 所支持的 Operator CSV 拥有自定义资源定义（CRD），则该 CRD 必须存在于捆绑包中。 2.2.1.1. 清 清单 捆绑包清单指的是一组 Kubernetes 清单，用于定义 Operator 的部署和 RBAC 模型。 捆绑包包括每个目录的一个 CSV，一般情况下，用来定义 CRD 所拥有的 API 的 CRD 位于 /manifest 目 录中。 捆绑包格式布局示例 包格式布局示例 额外支持的 外支持的对象

公开的就绪度和存活度探测指标会被抓取。这提供了容器的历史存活度和就绪度数 据，这在对容器问题进行故障排除时非常有用。 Thanos Ruler 的警报规则会被更新，在没有正确评估记录规则和警报规则时，会把警报进行分 页。在这个版本中，当 Thanos Ruler 中的规则及警报评估没有完成时，重要警报不会被丢失。 KubeStatefulSetUpdateNotRolledOut 警报被更新，以便在部署有状态的集合时不会触发。 CR。(BZ#1837156) 用户界面无法正确评估安全关闭，从而导致在关闭控制台时出现不正确的警告。现在，接口会等 待节点 Pod 加载，并在关闭时显示正确的警告。(BZ#1872893) 容器 容器 在以前的版本中，处理从构建上下文中复制内容的 COPY 或 ADD 指令的逻辑在 .dockerignore 文件存在时无法有效地过滤。如果评估源位置中的每个项目是否需要复制到目的地，那么会明显 DeploymentConfig 详情页面不会再崩溃。（BZ#1921603） 在以前的版本中，与触发器、订阅、频道和 IMC 事件源对应的静态模型使用 beta API 版本。在 Serverless 0.10 发行版本中，事件源的最新支持版本更新至 v1 版本。在这个版本中，更新了用户 界面模型，以指向最新支持的版本。(BZ#1896625) 在以前的版本中，当有条件任务失败时，完成的管道运行会显示每个失败条件任务。这个问题已

workload with dedicated resources (guaranteed policy)。 5. 点 Save。 8.15.9. 调度虚拟机 在确保虚拟机的 CPU 模型和策略属性与节点支持的 CPU 模型和策略属性兼容的情况下，可在节点上调度 虚拟机（VM）。 8.15.9.1. 策略属性 策略属性 您可以指定策略属性和在虚拟机调度到节点上时匹配的 CPU 功能来调度虚拟机（VM）。为虚拟机指定的 不支持虚拟机的 CPU，也是如 此。 require 在虚拟机没有使用特定 CPU 模型和功能规格配置时，应用于虚拟机的默认策 略。如果节点没有配置为支持使用此默认策略属性或其他策略属性的 CPU 节 点发现，则虚拟机不会调度到该节点上。主机 CPU 必须支持虚拟机的 CPU， 或者虚拟机监控程序必须可以模拟支持的 CPU 模型。 optional 如果主机物理机器 CPU 支持该虚拟机，则虚拟机会被添加到节点。 (VM) 配置 CPU 模型，将其调度到支持其 CPU 模型的节点。 流程 流程 编辑虚拟机配置文件的 domain spec。以下示例显示了为虚拟机定义的特定 CPU 模型： 虚拟机的 CPU 模型. 8.15.9.4. 使用主机模型 使用主机模型调度虚 度虚拟机 机 当将虚拟机（VM）的 CPU 模型设置为 host-model 时，虚拟机会继承调度节点的 CPU 模型。 流程 流程 编辑虚拟机配置文件的

5 Prometheus Prometheus 是 OpenShift Container Platform 监控堆 栈所依据的监控系统。Prometheus 是一个时间序列数 据库和用于指标的规则评估引擎。Prometheus 将警报 发送到 Alertmanager 进行处理。 Prometheus Adapter Prometheus Adapter（上图中的 PA）负责转换 Kubernetes Alertmanager 进行处 理。 Thanos Ruler Thanos Ruler 是 Prometheus 的一个规则评估引擎， 作为一个独立的进程来部署。在 OpenShift Container Platform 4.10 中，Thanos Ruler 为监控用户定义的项 目提供规则和警报评估。 组 组件 件 描述 描述 注意 注意 在为用户定义的项目启用监控后，会部署上表中的组件。 监控堆栈中的所有组件都由堆栈监控，并在 节点上运行。 Prometheus Prometheus 是 OpenShift Container Platform 监控堆栈所依据的监控系统。Prometheus 是一个时间 序列数据库和用于指标的规则评估引擎。Prometheus 将警报发送到 Alertmanager 进行处理。 Prometheus adapter Prometheus Adapter 会转换 Kubernetes 节点和 pod

有集群。要访问云 API 和安装介质时，仍需要访问互联网。 第 第 1 章 章 OPENSHIFT CONTAINER PLATFORM 4.6 文档 文档 3 检查 检查安装日志 安装日志 ：检查安装日志，评估在 OpenShift Container Platform 4.6 安装过程中发生的问 题。 访问 访问 OpenShift Container Platform：使用安装过程末尾的凭证输出，从命令行或 的扩展。您可以使用自定义资源自定义 Kubernetes 集群。Operator 是一 个软件扩展，它通过自定义资源来管理应用程序及其组件。当您希望在处理集群资源时具有固定的结果， 则 Kubernetes 会使用声明性模型。通过使用 Operator，Kubernetes 以声明性方式定义其状态。您可以 使用必需命令修改 Kubernetes 集群资源。Operator 充当控制循环，它可以持续将所需的资源状态与资源

pod 间共享。 Fiber 频道 道 用于在数据中心、计算机服务器、交换机和存储之间传输数据的联网技术。 FlexVolume FlexVolume 是一个树外插件接口，它使用基于 exec 的模型与存储驱动程序进行接口。您必须在每个 节点上在预定义的卷插件路径中安装 FlexVolume 驱动程序二进制文件，并在某些情况下是 control plane 节点。 fsGroup fsGroup 2. 访问模式 声明在请求带有特定访问权限的存储时，使用与卷相同的格式。 3.4.3. Resources 象 pod 一样，声明可以请求具体数量的资源。在这种情况下，请求用于存储。同样的资源模型适用于卷和 声明。 3.4.4. 声明作为卷 pod 通过将声明作为卷来访问存储。在使用声明时，声明需要和 pod 位于同一个命名空间。集群在 pod 的命名空间中找到声明，并使用它来使用这个声 OpenShift Container Platform 发行注记中已弃用和删除的功能部分。 OpenShift Container Platform 支持 FlexVolume，这是一个树外插件，使用可执行模型与驱动程序进行接 口。 要从没有内置插件的后端使用存储，您可以通过 FlexVolume 驱动程序来扩展 OpenShift Container Platform，并为应用程序提供持久性存储。 Pod

会自动检测每个拥有的资源上公开的绑定数据。 5.6.2. 数据模型 注释中使用的数据模型遵循特定的惯例。 服务绑定注解必须使用以下约定： 其中： 指定要公开的绑定值的名称。只有在将 objectType 参数设置为 Secret 或 ConfigMap 时， 才能将其排除。 指定没有设置 path 时公开的常量值。 数据模型详细介绍了 路径、elementType、objectType、sourceKey 路由用户可见的更改。其他高级策略，例如本节中描述的策略，结合使用路由器功能和 Deployment 对象 来影响特定的路由。 最常用的基于路由型策略是使用蓝绿部署。新版本（绿色版本）上线进行测试和评估，同时用户仍然使用 稳定版本（蓝色版本）。准备就绪后，用户切换到绿色版本。如果出现问题，您可以切回到蓝色版本。 一个常见的替代策略是使用同时活跃的 A/B 版本；一些用户使用一个版本，另一些用户使用另一个版本。 载时，可能需要扩展各个服务中的 pod 数，以提供预期的性 能。 除了升级软件外，您还可以使用此功能来试验用户界面的不同版本。由于部分用户会使用旧版本，而另外 的一部分用户会使用新版本，因此您可以评估用户对不同版本的反应，以做出明智的设计决策。 若要使此功能凑效，新旧两个版本必须足够相似，让两个版本能够同时运行。这常用于对程序错误修复的 发布，也适用于新功能不会影响到旧功能的情况。各个版本需要支持

(VM) CPU 模型取决于虚拟机和集群中的 CPU 模型的可用性。 如果虚拟机没有定义的 CPU 模型： defaultCPUModel 使用在集群范围级别上定义的 CPU 模型自动设置。 如果虚拟机和集群都有定义的 CPU 模型： 虚拟机的 CPU 模型具有优先权。 如果虚拟机或集群都没有定义的 CPU 模型： host-model 使用主机级别上定义的 CPU 模型自动设置。 10 OpenShift CLI（oc）。 流程 流程 1. 运行以下命令打开 HyperConverged CR： 2. 将 defaultCPUModel 字段添加到 CR，并将值设置为集群中存在的 CPU 模型的名称： error: hyperconvergeds.hco.kubevirt.io "kubevirt-hyperconverged" could not be patched: admission workload with dedicated resources (guaranteed policy)。 5. 点 Save。 10.15.9. 调度虚拟机 在确保虚拟机的 CPU 模型和策略属性与节点支持的 CPU 模型和策略属性兼容的情况下，可在节点上调度 虚拟机（VM）。 10.15.9.1. 策略属性 策略属性 您可以指定策略属性和在虚拟机调度到节点上时匹配的 CPU 功能来调度虚拟机（VM）。为虚拟机指定的