支持控制台（Console）开发人员开始试用联系人

1.6. 程序错误修复

裸机硬件置备
  • 在以前的版本中，当您试图在配置了 Integrated Lights-Out (iLO) 管理接口驱动程序的服务器上部署 OpenShift Container Platform 集群节点时，置备节点将失败。故障的原因是 iLO 驱动器中缺少 [ilo]/use_web_server_for_images 配置参数，这会导致驱动程序尝试使用对象存储作为默认存储机制。产品中不存在对象存储。在这个版本中，OpenShift Container Platform 4.13 及更新的版本在 iLO 驱动程序配置中包含 [ilo]/use_web_server_for_images，因此驱动程序使用 metal3 pod 中运行的 Web 服务器。(OCPBUGS-5068)
Cloud Compute

  • 对于 Google Cloud Platform 集群的一些配置，内部负载均衡器使用安装程序创建的实例组。在以前的版本中，当手动替换 control plane 机器时，新的 control plane 节点不会分配给 control plane 实例组。这导致节点无法通过内部负载均衡器访问。要解决这个问题，管理员必须使用 Google Cloud 控制台手动将 control plane 机器移到正确的实例组。

    在这个版本中，替换的 control plane 节点被分配给正确的实例组。(BZ#1970464, OCPCLOUD-1562)

  • 在以前的版本中，Google Cloud Platform 的计算机器集可能会尝试协调无效的机器，这会导致它们处于没有分配阶段。在这个版本中，具有无效配置的机器会进入 Failed 状态。(OCPBUGS-4574)
  • 在以前的版本中，当其后台机器进入 Running 状态时，control plane 机器集副本被视为是就绪状态，即使链接的节点也需要就绪才可将副本视为就绪。在这个版本中，节点及其机器必须处于 Ready 状态，以便 control plane 机器集副本被视为就绪。(OCPBUGS-8424)
  • 在以前的版本中，当 Microsoft Azure 集群上为加速网络功能出现错误时，mapi_instance_create_failed 警报指标不会启动。此发行版本添加了缺少的警报，以便启用加速网络的集群在需要时可以生成警报。(OCPBUGS-5235)
  • 在以前的版本中，当机器进入 Running 状态时，不会进一步检查节点的状态。以前 OCPBUGS-8424 的解析引入了节点及其机器处于 Ready 状态的要求，以便 control plane 机器集副本被视为就绪。因此，如果 control plane 机器集错过了节点和机器就绪的阶段，则其副本无法就绪。此行为导致 Control Plane Machine Set Operator 不可用，并无法进行升级。在这个版本中，当机器正在运行但节点未就绪时，会定期检查该节点，直到节点就绪为止。在这个版本中，解决了 Control Plane Machine Set Operator 无法正常工作并无法升级的问题。(OCPBUGS-10771)
  • 在以前的版本中，当机器健康检查超过 maxUnhealthy 阈值并生成警报时，当集群的健康足以成功协调机器健康检查时，指标不会被重置，警报将继续。在这个版本中，决定何时触发警报的逻辑有所改进，以便在集群健康时清除警报。(OCPBUGS-4725)
  • 以前针对 OCPBUGS-5546 的解决方案在机器配置对象中删除的 MachineConfig.Name 的 clusterName 分配。因此，参数的值是一个空字符串，当与 machineName 值相结合以创建 IP 地址名称时，会创建一个无效的值。无效的值会导致机器在置备过程中失败。在这个版本中，clusterName 的值从基础架构对象获取，以便它可以创建有效的 IP 地址名称。(OCPBUGS-7696)
  • Kubernetes 1.26 发行版本引入了对节点基础架构的更改，例如从公共负载均衡器中删除具有 NotReady 状态的不健康节点，以防止该节点接收路由流量。这些更改会影响在 Microsoft Azure 上运行的节点。因此，节点无法重新获得 Ready 状态并随后建立出站连接。在这个版本中，kube-proxy 健康探测会检测到标记为 NotReady 状态的节点，而无需将该节点从公共负载均衡器中分离。这意味着节点可以在这些阶段保留出站互联网连接。(OCPBUGS-7359)
Cloud Credential Operator
  • Amazon Simple Storage Service (Amazon S3) 更新了其 Amazon S3 存储桶配置，在 Amazon Web Services (AWS) 区域中创建的存储桶默认启用 S3 Block Public Access，并默认禁用访问控制限制 (ACL)。此配置将 S3 存储桶资源限制为私有使用。OpenShift Container Platform 4.13 更新了 CCO 实用程序(ccoctl) 和安装程序，现在可以正确考虑默认的 S3 存储桶配置，以便 S3 存储桶资源可以被公开可用。(OCPBUGS-11706 和 OCPBUGS-11661)
开发人员控制台
  • 在以前的版本中，OpenShift Container Platform 将 API 版本 v1alpha1 用于 Knative Serving 和 Eventing，但因为一个程序错误，API 版本 v1beta1 不被支持。在这个版本中，OpenShift Container Platform 支持这两个 API 版本。(OCPBUGS-5164)
  • 在以前的版本中，当在 OpenShift Container Platform 控制台中编辑任何管道时，Pipeline 构建器和YAML 视图配置选项中不会呈现正确的数据。因此，您无法在 Pipeline 构建器中编辑管道。在这个版本中，数据会被正确解析，您可以使用构建器编辑管道。(OCPBUGS-5016)
  • 在以前的版本中，拓扑侧边栏不会显示更新的信息。当您直接从拓扑边栏中更新资源时，您必须重新打开侧边栏来查看更改。在这个版本中，更新的资源会被正确显示。因此，您可以在拓扑侧边栏中直接看到最新的更改。(OCPBUGS-4691)
  • 在以前的版本中，OpenShift Container Platform 中的 Samples 页面无法区分列出的样本类型。在这个版本中，您可以通过 Samples 页面中显示的徽标来区分样本。(OCPBUGS-10679)
文档

在以前的版本中，OpenShift Container Platform 文档包括一个子部分，标题为"使用内部裸机节点扩展集群"。但是，这已被删除，以便保持准确的、最新的文档。

etcd Cluster Operator
  • 在以前的版本中，Control Plane Machine Set Operator 会尝试在集群引导完成前重新创建 control plane 机器。这会导致从 etcd 集群成员资格中删除 bootstrap 节点，并导致 etcd 仲裁丢失，集群离线。在这个版本中，Control Plane Machine Set Operator 仅在 etcd Cluster Operator 删除 bootstrap 节点后重新创建 control plane 机器。(OCPBUGS-10960)
托管 Control Plane
  • 在以前的版本中，managedControlPlane 对象无法识别由 HostedCluster 资源设置的调度程序配置集的更改。另外，managedControlPlane 不会向调度程序传播更改，因此调度程序不会重启 control plane pod，以便它们接收最新的调度程序配置集更改。在这个版本中，HostedControlPlane 会识别对调度程序配置集的更改，然后动态重启调度程序，以便调度程序可以将配置集更改应用到 pod。(OCPBUGS-7091)
  • 在以前的版本中，托管集群不会考虑 OpenID Connect (OIDC) 供应商 oidc 的不开用性，这会导致删除 machine 和 machineset 对象的操作无法完成。在这个版本中，托管集群可以检测一个不可用的 odic 供应商的状态，因此不会因为一个不可用的 oidc 供应商导致删除 machine 和 machineset 操作无法完成。(OCPBUGS-10227)
  • 在以前的版本中，Amazon Web Services (AWS) 计算机器集中的 spec.metadata.annotations 参数值没有从计算机器复制到其节点。这会导致节点缺少在计算机器集中指定的注解。在这个版本中，注解可以正确地应用到节点。(OCPBUGS-4566)
安装程序
  • 在以前的版本中，在卸载私有集群时，安装程序创建的 DNS 记录不会被删除。在这个版本中，安装程序可以正确地删除这些 DNS 记录。(OCPBUGS-7973)
  • 在以前的版本中，裸机安装程序置备的基础架构使用端口 80 向 Baseboard Management Controller (BMC) 和部署代理提供镜像。端口 80 可能会存在安全风险，因为此端口通常用于互联网通信。裸机安装程序置备的基础架构现在使用端口 6180 来提供部署的集群上 metal3 pod 使用的镜像。(OCPBUGS-8511)
  • 在以前的版本中，当堡垒主机在与集群节点相同的 VPC 网络中运行时，对 bootstrap 和集群节点的 SSH 访问会失败。另外，此配置会导致从临时 bootstrap 节点到集群节点的 SSH 访问失败。现在，通过更新 IBM Cloud 安全组规则来支持临时 bootstrap 节点和集群节点之间的 SSH 流量来解决这些问题，并支持从堡垒主机到同一 VPC 网络上的集群节点的 SSH 流量。可以在安装程序置备的基础架构失败时准确收集日志和调试信息以进行分析。(OCPBUGS-8035)
  • 在以前的版本中，如果您将 rendezvous IP 配置为其 role 参数设置为 worker 的主机的 IP 地址， 且您生成了 ISO 镜像，则基于代理的安装程序将无法安装集群。现在，当您尝试基于此配置生成 ISO 镜像时，您将收到验证失败信息。在收到此消息时，您必须更新 agent-config.yaml 文件中的 rendezvousIP 字段，以使用具有 master 角色的主机 IP。(OCPBUGS-2088)
  • 在以前的版本中，安装程序不接受 aws-sdk-go 库中定义的以下新区域：ap-south-2, ap-southeast-4, eu-central-2, eu-south-2, 和 me-central-1。当您使用安装程序创建安装配置文件时，安装程序不会列出这些新区域，或者接受这些区域的手动条目。在这个版本中，安装程序支持这些区域，您可以在创建安装配置文件时指定它们。(OCPBUGS-10213)
  • 在以前的版本中，代码库中有一个问题，它根据 install-config.yaml 文件中的 controlPlane.platform.openstack.failureDomain 字段设置 Machine.PrimaryNetwork。此问题会影响使用 Kuryr 运行的 OpenShift Container Platform，无法识别 control plane 机器用来在它们间通信的 Red Hat OpenStack Platform (RHOSP) 子网中的端口。在这个版本中，当您为技术预览组件 failureDomain 中的 portTarget 设置 control-plane 时，安装程序会在 Machine.PrimaryNetwork 字段中设置端口的信息，以便 OpenShift Container Platform 集群可以使用 Kuryr 成功运行。(OCPBUGS-10658)
  • 在以前的版本中，卸载部署到 us-gov-west-1 区域的 AWS 集群会失败，因为 AWS 资源无法取消标记。这会导致进程进入无限循环，安装程序会尝试取消标记资源。在这个版本中，不会进行重试。因此，卸载集群可以成功。(BZ#2070744)
  • 在以前的版本中，在 Google Cloud Platform (GCP) 上运行的私有 OpenShift Container Platform 集群会接收额外的防火墙规则，以便 GCP 能够对内部和外部负载均衡器执行健康检查。私有集群只使用内部负载均衡器，因此不需要对外部负载均衡器执行健康检查。在这个版本中，在 GCP 上运行的私有集群不再接收这些额外的防火墙规则，这些额外的防火墙规则会因为外部负载均衡器的健康检查而造成。(BZ#2110982)
Kubernetes 调度程序
  • 在以前的版本中，当 LifeCycleUtilization 配置集被用来测试命名空间过滤时，在 Descheduler Operator 日志中会出现以下记录：belowE0222 12:43:14.331258 1 target_config_reconciler.go:668] key failed with : only namespace exclusion supported with LowNodeUtilization。因此，descheduler 集群 pod 不会启动。在这个版本中，命名空间排除可用于 LifeCycleUtilization 配置集。(OCPBUGS-7876)
管理控制台
  • 在以前的版本中，在生成 Create Pod 按钮时不会检查用户权限，没有所需权限的用户也会看到这个按钮。在这个版本中，在生成 Create Pod 按钮时会检查用户权限，它只为具有所需权限的用户生成这个按钮。(BZ#2005232)
  • 在以前的版本中，Pod 资源在 Pod 资源操作菜单中有 PDBadd, edit, 和 remove 操作，它们并不需要。在这个版本中，删除了这些操作。(BZ#2110565)
  • 在以前的版本中，Details 页面中的 PodDisruptionBudget 字段有一个不正确的帮助信息。在这个版本中，帮助信息更加明确。(BZ#2084452)
  • 在以前的版本中，当进入到控制台的根路径时，即使禁用了指标且它们没有出现在导航菜单中，也会被重新定向到 Overview 页面。在这个版本中，当点 masthead 徽标或导航到控制台的根路径时，URL 会在禁用指标时重定向到项目列表页面。(OCPBUGS-3033)
  • 在以前的版本中，集群下拉菜单并不是始终可见，从而可能导致您不知道在查看哪个集群。在这个版本中，集群下拉菜单位于 masthead 中，因此集群下拉菜单始终可见，您可以看到您要查看的集群。(OCPBUGS-7089)
  • 在以前的版本中，当集群版本的状态为 Failing, UpdatingAndFailing, 和 Updating 时，节点进度条会显示，从而导致在集群没有更新时也会显示节点进度条。在这个版本中，只有在集群版本的状态为 UpdatingAndFailing 或 Updating 时，节点进度条才会显示。(OCPBUGS-6049)
  • 在以前的版本中，当为 ServiceAccount 下载 kubeconfig 文件时，会显示错误，并且无法访问 ServiceAccount 令牌。造成这个错误的原因是删除了自动生成的 secret。在这个版本中，下载 kubeconfig 操作已被删除，不再发生错误。(OCPBUGS-7308)
  • 在以前的版本中，Node 详情页上的 Terminal 选项卡会显示一个错误，因为缺少由 pod 安全措施导致的注解。如果没有所需的注解，节点调试 pod 无法启动。在这个版本中，OpenShift Container Platform 会添加这些注解，因此节点调试 pod 可以启动，并且重新加载 Terminal 选项卡而无需任何错误。(OCPBUGS-4252)
  • 在以前的版本中，如果在卸载 Operator 时尝试发出 oc delete csv 命令，Operator 的订阅会卡住。管理员无法重新安装 Operator，因为订阅存在冲突。在这个版本中，当管理员尝试重新安装卸载的 Operator 时，会显示详细的错误消息。(OCPBUGS-3822)
  • 在以前的版本中，如果一个或多个现有插件失败，Web 控制台不会显示提示刷新控制台的 toast 通知。需要此操作，以便在 Operator 将插件添加到控制台后查看插件。在这个版本中，Web 控制台会检查 Operator 添加插件的时间，然后在控制台中显示一个 toast 通知，而不考虑之前失败的插件。(OCPBUGS-10249)
  • 在以前的版本中，终止的容器会为每个终止的容器呈现 {{label}} 和 {{exitCode}} 代码。在这个版本中，国际化代码已被修复，以呈现可读的输出信息。(OCPBUGS-4206)
  • 在以前的版本中，因为一个回归的错误会导致，当 clusterversion status.availableUpdates 有 null 和 Upgradeable=False 值时，Cluster Settings 页面会返回一个错误。在这个版本中，status.availableUpdates 只允许 null 值。(OCPBUGS-6053)
监控
  • 在以前的版本中，Kubernetes 调度程序可以为接收多个重启操作的节点跳过调度某些 pod。OpenShift Container Platform 4.13 通过为在 30 分钟内无法调度的 pod 包括一个 KubePodNotScheduled 警报来解决这个问题。(OCPBUGS-2260)
  • 在以前的版本中，如果为 Thanos Ruler 定义了多个标签，则 statefulset 可能会进入重新创建循环，因为 prometheus-operator 每次协调自定义资源时不会以指定顺序添加标签。在这个版本中，prometheus-operator 会在将额外标签添加到 statefulset 前对额外的标签进行排序。(OCPBUGS-6055)
  • 在这个版本中，对于特定的只读 tmpfs 实例，FilesystemAlmostOutOfSpace 不再启动。这个变化可以解决一个问题：为已满的特定 tmpfs 挂载点启动警报。(OCPBUGS-6577)
网络
  • 在以前的版本中，当应该显示错误消息时，Ingress Operator 会为 updateIngressClass 功能日志显示一个成功信息。在这个版本中，Ingress Operator 的日志消息是准确的。(OCPBUGS-6700)
  • 在以前的版本中，Ingress Operator 没有指定 ingressClass.spec.parameters.scope，而 Ingress Class API 对象则默认指定类型 cluster。这会导致 Operator 启动时对所有 Ingress 类进行不必要的更新。在这个版本中，Ingress Operator 将 ingressClass.spec.parameters.scope 的类型指定为 指定类型为 cluster。(OCPBUGS-6701)
  • 在以前的版本中，Ingress Operator 在 ensureNodePortService 日志消息中存在一个不正确的服务名称，从而导致记录不正确的信息。在这个版本中，Ingress Operator 准确将服务记录在 ensureNodePortService 中。(OCPBUGS-6698)
  • 在以前的版本中，在 OpenShift Container Platform 4.7.0 和 4.6.20 中，Ingress Operator 为特定于 OpenShift Container Platform 的路由器 pod 使用注解。这是配置存活度探测的宽限期来修复程序错误的临时方法。因此，OpenShift Container Platform 需要执行补丁来实现这个修复。在这个版本中，Ingress Operator 使用 terminationGracePeriodSeconds API 字段，使之前的补丁可在以后的版本中移动。(OCPBUGS-4703)
  • 在以前的版本中，CoreDNS 使用旧的工具链来构建主二进制文件和旧基础镜像。在这个版本中，OpenShift Container Platform 对构建工具链和基础镜像使用 4.13。(OCPBUGS-6228)
节点
  • 在以前的版本中，由 LifecycleAndUtilization descheduler 配置集启用的 LowNodeUtilization 策略不支持命名空间排除。在这个版本中，当设置 LifecycleAndUtilization descheduler 配置集时，命名空间会被正确排除。(OCPBUGS-513)
  • 在以前的版本中，一个行为回归会导致 Machine Config Operator (MCO) 在 kubeletconfig 或 containerruntimeconfig 自定义资源 (CR)中创建重复的 MachineConfig 对象。重复的对象降级，集群无法升级。在这个版本中，kubeletconfig 和 containerruntimeconfig 控制器可以检测任何重复的对象，然后将其删除。此操作会删除降级的 MachineConfig 对象错误，不会影响集群升级操作。(OCPBUGS-7719)
Node Tuning Operator (NTO)
  • 在以前的版本中，Cloud-native Function (CNF) 测试镜像在启用了 CNF 的 OpenShift Container Platform 集群上运行延迟测试的 hwlatdetect 工具被配置为一个检测周期 10 秒。当与检测宽度配置为 0.95 时，这个配置会增加 hwlatdetect 的可能性缺少延迟激增，因为工具会在分配的检测周期内监控节点大约 9.5%。在这个版本中，检测周期被设置为 1 秒，因此工具现在可以在分配的检测周期内监控节点大约 95%。剩余的 5% 监控时间保留未分配，以便内核能够执行系统任务。(OCPBUGS-12433)
OpenShift CLI (oc)
  • 在以前的版本中，oc adm upgrade 命令在 ClusterVersion 中不会读取 Failing=True 状态。在这个版本中，oc adm upgrade 在总结集群状态时包括 Failing=True 条件信息。这会提高 ClusterOperators 的 Degraded=True 状态的可见性，以及其他可能会影响当前集群或将来的更新行为的问题。(OCPBUGS-3714)
  • 在以前的版本中，oc-mirror 命令在控制台中从镜像磁盘镜像中为 OCI 和 FBC Operator 构建目录内容。因此，不是目录的所有内容，因此目录中缺少一些内容。在这个版本中，在将目录镜像推送到目标 registry 前，会构建目录镜像来反映镜像的内容，从而获得更完整的目录。(OCPBUGS-5805)
  • 在以前的版本中，oc-mirror OpenShift CLI (oc) 插件将 Operator 目录作为 ImageContentSourcePolicy 资源中的一个条目添加。此资源并不需要此条目，因为 Operator 目录直接从 CatalogSource 资源的目标 registry 中使用。这个问题会影响集群接收发行版本镜像签名资源，因为 ImageContentSourcePolicy 资源中有一个意外的条目。在这个版本中，oc-mirror 插件从 ImageContentSourcePolicy 资源中删除了 Operator 目录条目，以便集群从 CatalogSource 资源中的 Operator 目录中接收签名资源。(OCPBUGS-10320)
Operator Lifecycle Manager (OLM)
  • Operator 自定义资源 (CR) 的状态包括了 Operator 拥有的组件列表。此列表根据 group/version/kind (GVK) 排序，但具有相同 GVK 的对象顺序可能会改变。如果 Operator 拥有许多具有相同 GVK 的组件，可能会导致 Operator Lifecycle Manager (OLM) 持续更新 Operator CR 的状态，因为其组件的顺序发生了变化。在这个版本中更新了 OLM，以便 Operator 组件引用的顺序是确定的。因此，当组件列表保持恒定时，OLM 不再尝试重复更新 CR。(OCPBUGS-2556)
  • Operator Lifecycle Manager (OLM) 管理一组 CatalogSource 对象，可以从中搜索和安装 Operator。这些目录源是此操作的默认源，由红帽管理。但是，可以使用不会被 OLM 系统注意到的方式更改这些默认目录源。如果通过这样的方式更改默认目录源导致它无法操作，则可能会进而造成 OLM 的问题，使用户无法在集群上安装新的或升级现有 Operator。在这个版本中更新了 catalog-operator 运行时，它会管理默认目录源，并会了解到对 CatalogSource spec 的其他更改。因此，当对默认目录源进行更改时，OLM 会检测到更改并将其重置回默认设置。(OCPBUGS-5466)
Red Hat Enterprise Linux CoreOS (RHCOS)
  • 在以前的版本中，在 Azure 上，SR-IOV 接口由 NetworkManager 在引导时配置，因为将它标记为 NM_UNMANAGED 的 udev 规则没有存在于 initramfs 文件中。在这个版本中，udev 规则位于 initramfs 文件中，SR-IOV 接口应该始终由 NetworkManager 管理。(OCPBUGS-7173)
Security Profiles Operator
  • 在以前的版本中，如果您选择了另外一个模板，如 net_container，Security Profiles Operator (SPO) SELinux 策略不会继承容器模板的低级别策略定义。因此策略将无法正常工作，因为它需要仅存在于容器模板中的低级别策略定义。当 SPO SELinux 策略试图将 SELinux 策略从 SPO 自定义格式转换为通用中间语言 (CIL) 格式时，会发生此问题。在这个版本中，容器模板会附加到需要从 SPO 转换到 CIL 的任何 SELinux 策略中。另外，SPO SELinux 策略可以从任何支持的策略模板中继承低级策略定义。(OCPBUGS-12879)
可伸缩性和性能

  • 在以前的版本中，当生成性能配置集时，自动创建的 CRI-O 运行时文件被配置为使用 runc 作为 CRI-O 运行时。

    现在，当生成性能配置集时，将 crun 设置为容器运行时通常可用，创建的运行时 CRI-O 文件与 ContainerRuntimeConfig CR 中配置的 defaultRuntime 匹配。这可以是 crun 或 runc。默认为 runc。(OCPBUGS-11813)

Storage
  • 在以前的版本中，openshift-manila-csi-driver 命名空间不包含管理工作负载分区所需的标签。这些缺少的标签会影响在所选 CPU 集合中运行 Manila CSI pod 的操作。在这个版本中，openshift-manila-csi-driver 命名空间现在包含了 workload.openshift.io/allowed 标签。(OCPBUGS-11341)
Windows 容器
  • 在以前的版本中，在 Windows 节点升级过程中，Microsoft Windows 容器工作负载不会被完全阻止。这会导致服务中断，因为工作负载在升级的节点上仍然存在。在这个版本中，Windows Machine Config Operator (WMCO) 会排空工作负载，然后对节点进行 cordon 操作，直到节点升级完成为止。此操作可确保 Microsoft Windows 实例无缝升级。(OCPBUGS-5732)
  • 在以前的版本中，Windows Machine Config Operator (WMCO) 无法排空 DaemonSet 工作负载。此问题导致 Windows DaemonSet pod 阻止 WMCO 试图删除或升级的 Windows 节点。在这个版本中，WMCO 包含了额外的基于角色的访问控制(RBAC) 权限，以便 WMCO 可以移除 DaemonSet 工作负载。WMCO 也可以删除任何使用 containerd shim 创建的进程，以便在 WMCO 从集群中删除节点后，Windows 实例中不存在 DaemonSet 容器。(OCPBUGS-5354)
  • 在以前的版本中，containerd 容器运行时在每个 Windows 节点上报告了一个不正确的版本，因为存储库标签没有传播到构建系统。此配置会导致 containerd 将其 Go 构建版本报告为每个 Windows 节点的版本。在这个版本中，在构建期间将正确的版本注入二进制文件，以便 containerd 报告每个 Windows 节点的正确版本。(OCPBUGS-5378)
Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务，以及可以信赖的内容，帮助红帽用户创新并实现他们的目标。

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情，请参阅红帽博客.

關於紅帽

我们提供强化的解决方案，使企业能够更轻松地跨平台和环境（从核心数据中心到网络边缘）工作。

© 2024 Red Hat, Inc.