具体环境中的性能会有所不同，我们的实验室在一个有 4 个 vCPU/16GB RAM，一个单独的 HAProxy 路 由器处理 100 个路由来提供后端的 1kB 静态页面的公共云实例中进行测试，其每秒的交易数如下。 在 HTTP 的 keep-alive 模式下： Encryption ROUTER_THREADS unset ROUTER_THREADS=4 none 23681 24327 HAProxy 路由器请求缓冲区配置限制了传入的请求和来自应用程序响应中 的标头大小。可以增加 HAProxy 参数 tune.bufsize 以允许处理更大的标头，并允许具有非常大 Cookie 的应用程序正常工作，如许多公共云提供商提供的负载均衡器接受的应用程序。但是，这会影响内存使用 总量，特别是在打开大量连接时。使用大量打开连接时，内存用量就与这个可调参数增长几乎成比例。 8.1.2.5. HAProxy

分类，以便您可以使用相同的分类来汇总二级 设备的指标。 kubelet 已发布一组网络可观察相关指标。这些指标中的标签包括： Pod 名称 Pod 命名空间 接口名称，如 eth0 这可以正常工作直到在将新接口添加到 pod（例如通过 Multus）时，因为无法清楚接口名称引用的内容。 interface 标签指向接口名称，但它不知道接口的作用是什么。如果使用很多不同的接口，就无法理解我们 API 控制器仅运行指定 数量的实例。(BZ#1861896) 在 Red Hat Virtualization（RHV）集群上，手动机器扩展可能会失败。从 Web 控制台或 CLI 扩展 机器现在可以正常工作。(BZ#1817853) 在以前的版本中，must-gather 不会收集 BareMetalHost 记录。因此，调试信息可能不完整。现 在，must-gather 可以收集BareMetalHost Operator 领导选举机制使用来自 controller-runtime 的默认 值，因此每 2 秒写入一次 etcd。此发行版本实施了自定义的领导选举机制，该选举机制现在每 90 秒写一次，并在正常关闭时立即释放锁定。(BZ#1858403) Cluster Version Operator Cluster Version Operator 使用 HTTP 而不是 HTTPS 提供指标，并会受到

确保 OpenShift Container Platform 集群已更新至版本 4.12.X 的最新稳定版本，请参阅 更新集 群。 确保 OpenShift Data Foundation 集群正常运行，数据具有弹性。 进入到 Storage → Data Foundation → Storage Systems 选项卡，然后点存储系统名称。 检查 Overview - Block and openshift-storage 项目。 升级完成后，新版本会更新到 OpenShift 数据基础的新版本号，并通过绿色勾号更改 Succeeded 状态。 验证 OpenShift Data Foundation 集群是否正常运行并且数据具有弹性。 进入到 Storage → Data Foundation → Storage Systems 选项卡，然后点存储系统名称。 检查 Overview - Block 和 和 确保 OpenShift Container Platform 集群已更新至版本 4.12.X 的最新稳定版本，请参阅 更新集 群。 确保 OpenShift Data Foundation 集群正常运行，数据具有弹性。 进入到 Storage → Data Foundation → Storage Systems 选项卡，然后点存储系统名称。 检查 Overview - Block 和 和

OSSM-1168 当以单个 YAML 文件形式创建服务网格资源时，Envoy proxy sidecar 不会可靠地注 入 pod。当单独创建 SMCP、SMMR 和 Deployment 资源时，部署可以正常工作。 OSSM-1052 在为服务网格 control plane 中为 ingressgateway 配置 Service ExternalIP 时，不会 创建该服务。SMCP 的 schema 上部署的网格不兼容。 MAISTRA-1959 迁移到 2.0 Prometheus 提取（spec.addons.prometheus.scrape 设置为 true）在启用 mTLS 时无法正常工作。另外，当禁用 mTLS 时，Kiali 会显示无关的图形数据。 可通过将端口 15020 从代理配置中排除来解决这个问题，例如： MAISTRA-1314 Red Hat OpenShift istiod pod 崩溃并显示以下出错信息：fatal error: concurrent map iteration and map write。 OSSM-1211 为故障转移配置联邦服务网格无法正常工作。 Istiod pilot 日志显示以下错误： envoy connection [C289] TLS error: 337047686:SSL routines:tls_process_s

Operator 会定期重试，或看起来并没有重试它们。 openshift 命名空间中的许多模板都引用镜像流。因此，使用 Removed 清除镜像流和模板，将 避免在因为缺少镜像流而导致镜像流和模板无法正常工作时使用它们。 3.4.1. 协助镜像的 Cluster Samples Operator 在安装过程中，OpenShift Container Platform 在 openshift-cl wrapper 脚本，继而启动您的进程。如果要使用 CTRL+C 关闭容器。如果您的 wrapper 脚本使用 了 exec 来启动服务器进程，则 podman 会将 SIGINT 发送至服务器进程，一切都可以正常工作。如果您 没有在 wrapper 脚本中使用 exec，则 podman 会将 SIGINT 发送至 wrapper 脚本的进程，并且您的进程 不会象任何情况一样继续运行。 另请注意，您的进程在容器中运行时，将作为 LABEL io.openshift.non-scalable true io.openshift.min- memory 和 io.openshift.min-cpu 该标签建议容器镜像正常工作可能需要的资源量。UI 可能会警告用户：部署此容 器镜像可能会超出其用户配额。值必须与 Kubernetes 数量兼容。 LABEL io.openshift.min-memory 16Gi LABEL

/opt/registry 文件夹中保存数据并在 podman 容器中运行。您可以使用不同的 registry 解决方案，例如 Red Hat Quay。检查以下流程以 确保 registry 可以正常工作。 先决条件 先决条件 网络上有一个 Red Hat Enterprise Linux (RHEL) 服务器充当 registry 主机。 registry 主机可以访问互联网。 流程 流程 Operator 报告Degraded 状 态。 OpenShift 命名空间中的多个模板都引用镜像流。因此，使用 Removed 清除镜像流和模板，将 避免在因为缺少镜像流而导致镜像流和模板无法正常工作时使用它们。 第 第 2 章 章 使用 使用带 带有一个 有一个备 备用 用 REGISTRY 的 的 SAMPLES OPERATOR 15 第 3 章 了解容器、镜像和镜像流 开始创 LABEL io.openshift.non-scalable true io.openshift.min- memory 和 io.openshift.min-cpu 该标签建议容器镜像正常工作可能需要的资源量。UI 可能会警告用户：部署此容 器镜像可能会超出其用户配额。值必须与 Kubernetes 数量兼容。 LABEL io.openshift.min-memory 8Gi LABEL

版本的限制，目前有一 些应用程序与 Service Mesh 还不兼容。详参阅社区的相关链接。 MAISTRA-858 Envoy 日志中以下与 与 Istio 1.1.x 相关的弃用选项和配置 相关的信息是正常的： [2019-06-03 07:03:28.943][19][warning][misc] [external/envoy/source/common/protobuf/utility.cc:129] Mesh 0.12.TechPreview 提供的 Jaeger 版本 1.13.1 不匹配。 MAISTRA-622 在 Maistra 0.12.0/TP12 中，permissive 模式无法正常工作。用户可以使用 Plain text 模式或 Mutual TLS 模式，但不能使用 permissive 模式。 MAISTRA-572 Jaeger 无法与 Kiali 一起使用。在这个版本中，Jaeger 如果您在安装 Operators 时选择了 Automatic 批准策略 ，那么 Operator 会自动更新 control plane ，但 不会更新您的应用程序。现有的应用程序将仍是网格的一部分并可以正常工作。应用程序管理员必须重启 应用程序来升级 sidecar。 如果您的部署使用了自动 sidecar 注入功能，则可以通过添加或修改注解来更新部署中的 pod 模板。运行 以下命令来重新部署 pod：

Operator 会定期重试，或看起来并没有重试它们。 openshift 命名空间中的许多模板都引用镜像流。因此，使用 Removed 清除镜像流和模板，将 避免在因为缺少镜像流而导致镜像流和模板无法正常工作时使用它们。 3.4.1. 协助镜像的 Cluster Samples Operator 在安装过程中，OpenShift Container Platform 在 openshift-cl wrapper 脚本，继而启动您的进程。如果要使用 CTRL+C 关闭容器。如果您的 wrapper 脚本使用 了 exec 来启动服务器进程，则 podman 会将 SIGINT 发送至服务器进程，一切都可以正常工作。如果您 没有在 wrapper 脚本中使用 exec，则 podman 会将 SIGINT 发送至 wrapper 脚本的进程，并且您的进程 不会象任何情况一样继续运行。 另请注意，您的进程在容器中运行时，将作为 LABEL io.openshift.non-scalable true io.openshift.min- memory 和 io.openshift.min-cpu 该标签建议容器镜像正常工作可能需要的资源量。UI 可能会警告用户：部署此容 器镜像可能会超出其用户配额。值必须与 Kubernetes 数量兼容。 LABEL io.openshift.min-memory 16Gi LABEL

守护进程插件 5.6. 了解节点重新引导 5.6.1. 关于重新引导运行关键基础架构的节点 5.6.2. 使用 pod 反关联性重新引导节点 5.6.3. 了解如何重新引导运行路由器的节点 5.6.4. 正常重新引导节点 195 197 198 200 202 203 205 206 209 209 209 210 213 214 216 217 217 217 218 218 220 的结果在逻辑上是联合 的。 2. 运行以下命令，将对象添加到项目中： 2.3.4. 使用关键 pod 防止删除 pod 有不少核心组件对于集群完全正常工作而言至关重要，但它们在常规集群节点而非主节点上运行。如果一 个关键附加组件被驱除，集群可能会停止正常工作。 标记为关键 (critical) 的 Pod 不允许被驱除。 流程 流程 使 pod 成为关键 pod： 1. 创建 Pod spec below target OpenShift Container Platform 4.6 节 节点 点 38 1 True 条件表示指 条件表示指标 标工作正常。 工作正常。 False 条件通常表示 条件通常表示获 获取指 取指标时 标时出 出现问题 现问题。 。 ScalingLimited