发行注记

在 OpenShift Container Platform 4.1 中，红帽引进了升级频道的概念，用于为集群推荐适当的升级版本。升级频道分离升级策略，并可用来控制更新的节奏。频道与 OpenShift Container Platform 的次要版本关联。例如，OpenShift Container Platform 4.2 频道永远不会包括到版本 4.3 的升级。这可确保管理员明确决定升级到下一个 OpenShift Container Platform 次要版本。频道只控制更新，且不会影响到安装的集群版本；指定补丁级别的 OpenShift Container Platform 中的 openshift-install 二进制文件始终会安装该补丁级别。

有关更新类型和升级频道的更多信息，请参阅 OpenShift 4.2 升级分阶段部署。

因为把升级发布到频道的过程是根据 Red Hat Service Reliability engineering (SRE) 团队的数据向客户逐渐推出的，所以您可能不会在 web 控制台中马上看到从 4.1.z 升级到 4.2 的更新信息。

OpenShift Container Platform 4.2 引进了一个新的基于 CLI 的安装程序，名为 openshift-install。它使用一个互动式的指导工作流程，简化在不可变安装程序置备的基础架构中置备 OpenShift。整个安装过程应该会在 30 分钟内完成。这个方法为 OpenShift 部署提供了主机操作系统和平台更新及基础架构管理的完整堆栈自动化，而无需置备您自己的基础架构。用户只需要为非基本安装配置选项输入少量信息，这些选项现在会在安装后，通过组件操作员自定义资源定义 (Custom Resource Definitions，简称 CRD) 进行安装。

更新过程大体上是一样的。OpenShift 更新内容必须首先镜像到本地容器 registry，然后管理员使用 oc adm upgrade 来指定从哪里抓取更新内容。

OpenShift Container Platform 4.2 引进了对在有限网络环境中安装和更新 OpenShift Container Platform 集群的支持。它旨在使用任何符合 docker 2.2 规格的容器 registry 来托管 OpenShift Container Platform 的内容。

管理员必须首先将内容从 Quay.io 复制到其本地容器 registry。完成此操作后，可将 openshift-install 配置为生成 Ignition 配置来在本地提取内容，而不是从 Quay.io 中提取内容。这个方法只适用于用户置备的基础架构 (UPI) 部署 。

您仍可在受限网络中使用 OLM 目录中的 Operator。但是，您必须手动提取 Operator 源以便生成离线目录。这个手动过程只是针对 OpenShift Container Platform 4.2 的一个临时解决方案。在以后的版本中将提供一个相应的自动解决方案。

详情请查看在受限制的网络中安装和在受限网络中使用 Operator 生命周期管理器 。

在 OpenShift Container Platform 4.2 中，在裸机集群中部署一个没有不同计算或 worker 节点的集群的功能是一个技术预览功能。如果在您置备的裸机基础架构上安装集群时不创建 worker 机器，则所有 Pod（包括路由器 Pod）都部署在 control plane 或 master 机器上。请注意，OpenShift Container Platform 4.2 的基于云的集群中不支持这个部署方法。不建议在生产环境集群中使用技术预览功能。

OpenShift Container Platform 4.2 引进了对通过用户置备基础架构上的企业级代理服务器安装和更新 OpenShift Container Platform 集群的支持。代理信息（httpProxy 、httpsProxy 和 noProxy）可以在 install-config.yaml 文件中定义，它们会在安装过程中被使用，并可以在安装后通过 cluster Proxy 对象进行管理。

另外，现在还支持提供您自己的 CA 捆绑程序，允许企业代理到 MITM HTTPS。

OpenShift Container Platform 现在可以了解整个基础架构，并将操作系统置于管理之下。这样就可在平台和底层操作系统间无缝地安装和更新。所有都作为单个实体管理。

在 OpenShift Container Platform 4.2 中，有两个主要安装体验: Full stack automated (IPI) 和 pre-existing infrastructure (UPI) 。

通过完全的堆栈自动化，安装程序控制所有安装区域，包括根据最佳实践方案部署的 OpenShift Container Platform 置备的基础架构。通过预存在的基础架构部署，管理员将可以负责创建和管理自己的基础架构，从而提高了操作的灵活性。

在 OpenShift Container Platform 4.2 中，增加了对完全堆栈自动化部署的支持，其中包括 AWS 、Microsoft Azure 、Google Cloud Platform (GCP) 和 Red Hat OpenStack Platform，以及将 GCP 添加到已包含 AWS 、Bare Metal 和 VMware vSphere 的现有用户置备的基础架构供应商列表中。

有关 CAM 和 CPMA 的信息，请参阅 OpenShift 4.2 发布 GA 版后可从哪里找到 Red Hat Cluster Application Migration Tool (CAM) 和 Red Hat Control Plane Migration Assistant (CPMA)。

与 Operator 相关的 OpenShift Container Platform 产品文档以前包括在应用程序指南中，现在包括在新的 Operators 指南中。这包括有关 Operators、Operator Lifecycle Manager 和 Operator SDK 的现有和更新信息，以及针对 OpenShift Container Platform 4.2 的新内容。

在以前的版本中，只有具有 cluster-admin 角色的用户才可以安装 Operator。在 OpenShift Container Platform 4.2 中，cluster-admin 可选择命名空间，这些命名空间的管理员将可自行安装 Operator。cluster-admin 在这个命名空间中定义 ServiceAccount，这个命名空间中的所有已安装的 Operators 都将获得这个 ServiceAccount 的相同权限或较低权限。

如需了解详细信息，请参阅为安装和升级 Operator 创建策略 。

Ingress Operator 支持 4.2 中所有带有 Azure 和 GCP 安装程序置备基础架构的入站网络数据功能。

Machine Config Operator (MCO) 提供集群级别的配置，启用滚动升级，并防止新节点和现有节点之间出现偏差。

Node Feature Discovery (NFD) Operator 会检测每个节点上可用的硬件功能，并使用节点标签（label）公告这些功能。

由 NFD 管理的 CPU 功能包括：

由 NFD 管理的内核功能包括：

由 NFD 管理的其他功能包括：

NFD Operator 管理 NFD DaemonSet 的安装和生命周期。在 OperatorHub 中访问 NFD Operator。

Node Tuning Operator 首次在 OpenShift Container Platform 4.1 中引进，以管理集群节点级别的性能调整。默认的 CR 可以提供标准节点级别的调整。OpenShift Container Platform 4.2 对这个功能进行了增强，它可以为特定的环境（如高性能环境）定制性能调整。

为了进行定制，需要创建自己的 tuned 自定义资源 (CR) 。新创建的 CR 将与默认的 CR 合并，并基于节点或 Pod 标签和配置文件优先级对节点应用自定义调整。

OpenShift Container Platform 4.2 提供了使用 Local Storage Operator 的持久性卷。

OpenShift Container Platform 4.2 现在提供了 Container Storage Interface (CSI)。CSI 在 Kubernetes 中引进，以便启用 Red Hat OpenShift Container Storage (OCS)，及合作伙伴的 CSI 插件。随着 CSI 的引入，Kubernetes 卷层真正成为可 扩展的。

目前，只有 API 可用。在以后的版本中，CSI 驱动程序将会包括在 Operator 中。

OpenShift Container Platform 4.2 现在全面支持下列原始块卷：

使用 iSCSI 的原始块卷现在还是一个技术预览功能。

针对 OpenShift Container Platform 4.2 的集群限制指导信息已更新。

使用 OpenShift Container Platform Limit Calculator 可以估算出您的环境的集群限制。

OpenShift Do (odo) 是开发人员在 OpenShift 上创建、构建和部署应用程序的 CLI 工具。odo 工具完全基于客户端，无需 OpenShift Container Platform 集群中的服务器即可进行部署。它会检测本地代码的更改，并自动将其部署到集群中，为实时验证更改提供即时反馈。它支持多种编程语言和框架。

CodeReady Containers 提供了最小 OpenShift Container Platform 4 或更新集群的本地桌面实例。此集群提供了一个最小的环境，供开发人员进行开发和测试。它包括 crc CLI，与运行 OpenShift 集群的 CodeReady Containers 虚拟机进行交互。

CRI-O 是一个 kubernetes 特定的容器引擎，它的版本和 Kubernetes 相同，简化了对支持的比较。因为所有现有的 Docker 和 OCI 容器都被 CRI-O 支持并可正常运行，所以改为使用 CRI-O 的过程会非常简单。CRI-O 是一个简洁的、kubernetes 原生的、OCI 兼容的容器运行时，它由 OpenShift Container Platform 进行生命周期管理。您将不需要担心使用什么容器运行时。在 OpenShift Container Platform 中，它总会被正确使用，并提供一个 Kubernetes Container Runtime Interface (CRI) 的完整实现。另外，您不需要单独管理容器引擎。CRI-O 带有一些微调功能，可根据情况为 CRI-O 提供控制和安全性。它们可在 CRD 中被方便地配置，并在集群间推广设置。

系统管理员可以基于每个节点设置 sysctl 白名单。所有安全的 sysctls 都是默认启用的，默认禁用所有不安全的 sysctl。详情请参考在容器中使用 sysctls。

在 OpenShift Container Platform 4.2 中，master 节点是可调度的。如需了解更多信息，请参阅使用节点 。

OpenShift Container Platform 4.2 引进了在 Red Hat OpenStack 上部署 OpenShift Container Platform 集群的完整自动化支持。

安装程序与 Kubernetes OpenStack Cloud Provider 一起使用 OpenStack API 来创建所有所需的 OpenStack 资源，如虚拟机、网络、安全组以及部署 OpenShift Container Platform 所需的对象存储，并将集群正确配置为在 Red Hat OpenStack Platform 上运行。

OpenShift Container Platform 4.2 可以在 Red Hat OpenStack 版本 13 上部署。

Open vSwitch 的开源虚拟联网 (OVN) 目前为 技术预览，它有很多优点，包括加速客户驱动的功能要求，其中的一些功能是预启用的，其中包括：

当在云平台上创建 Ingress Controller 时，Ingress Controller 默认由一个公共云负载均衡器发布。

用户现在可以使用内部云负载均衡器发布 Ingress Controller。例如：

apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  namespace: openshift-ingress-operator
  name: internal
spec:
  endpointPublishingStrategy:
    type: LoadBalancerService
    loadBalancer:
      scope: Internal

apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  namespace: openshift-ingress-operator
  name: internal
spec:
  endpointPublishingStrategy:
    type: LoadBalancerService
    loadBalancer:
      scope: Internal

有关实现详情请查看 Kubernetes Services 文档 。

设定后， .spec.endpointPublishingStrategy.loadBalancer.scope 将不能被修改。如需改变范围，需要删除并重新创建 Ingress Controller。

默认的 Ingress Controller 可以通过删除并重新创建来使它为内部的。

如需了解更多信息，请参阅 OpenShift Container Platform 中的 Ingress Operator 。

在 OpenShift Container Platform 4.2 中添加或改进了一些 Kubernetes CNI 插件。

在 OpenShift Container Platform 4.2 中，这些 SR-IOV 解决方案仍为技术预览：

新的 CNI 插件：

现在，Red Hat Enterprise Linux (RHEL) 7 节点支持 GPU。因为缺少对 CUDA 驱动程序和驱动程序容器的支持，现在在 RHEL CoreOS 节点上还不支持 GPU。

您可以定制 OpenShift Container Platform web 控制台来设置自定义徽标、链接、通知标语和命令行下载。这在您需要定制 Web 控制台以满足具体公司或政府要求时特别有用。

如需更多信息，请参阅自定义 Web 控制台。

现在，您可以在位于 Home → Explore 的 Explore API Resources dashboard 中轻松搜索和管理 API 资源 。

查看每个 API 的 schema 以及支持的参数，管理 API 的实例，并查看每个 API 的访问情况。

现在，您可以使用 Machine Autoscaler 扩展集群。Machine Autoscaler 调整在集群中部署的机器集（MachineSets）中的机器数量。当集群没有足够资源来支持更多的部署时，会增加机器。任何修改，比如实例的最小或者最大数量，都会立即应用于 MachineAutoscalers 的目标 MachineSet。

开发者视角在 web 控制台中添加了面向开发者的视角。它为针对开发人员的用例提供了相应的工作流，比如使用多个选项在 OpenShift Container Platform 中创建和部署应用程序。它为某个项目中的应用程序、构建状态以及与其关联的组件和服务提供了一个可视化的界面，这可以方便地进行互动和监控。它整合了无服务器功能（技术预览），以及创建工作空间以使用 Eclipse Che 编辑应用程序代码的能力。

现在，您可以在 Web 控制台中直接运行 Prometheus 查询。进入 Monitoring → Metrics。

在集群 OAuth 配置页中，为用户提供了更多的身份供应商 (IDP) 来登录集群。它包括 GitHub 、GitLab 、Google 、LDAP 、Keystone 等等。

要将现有 OpenShift Container Platform 4.2 集群升级到此最新版本，请参阅使用 CLI 更新集群以获取相关说明。

要将现有 OpenShift Container Platform 4.2 集群升级到此最新版本，请参阅使用 CLI 更新集群以获取相关说明。

要将现有 OpenShift Container Platform 4.2 集群升级到此最新版本，请参阅使用 CLI 更新集群以获取相关说明。

要将现有 OpenShift Container Platform 4.2 集群升级到此最新版本，请参阅使用 CLI 更新集群以获取相关说明。

要将现有 OpenShift Container Platform 4.2 集群升级到此最新版本，请参阅使用 CLI 更新集群以获取相关说明。

在这个版本中，IBM System Z 与 OpenShift Container Platform 4.2 兼容。有关安装说明，请参阅在 IBM Z 上安装集群。

限制

请注意，IBM System Z 上的 OpenShift Container Platform 有以下的限制：

要将现有 OpenShift Container Platform 4.2 集群升级到此最新版本，请参阅使用 CLI 更新集群以获取相关说明。

要将现有 OpenShift Container Platform 4.2 集群升级到此最新版本，请参阅使用 CLI 更新集群以获取相关说明。

要将现有 OpenShift Container Platform 4.2 集群升级到此最新版本，请参阅使用 CLI 更新集群以获取相关说明。

要将现有 OpenShift Container Platform 4.2 集群升级到此最新版本，请参阅使用 CLI 更新集群以获取相关说明。

要将现有 OpenShift Container Platform 4.2 集群升级到此最新版本，请参阅使用 CLI 更新集群以获取相关说明。

要将现有 OpenShift Container Platform 4.2 集群升级到此最新版本，请参阅使用 CLI 更新集群以获取相关说明。

NFD Operator 的默认更新频道是 4.3。如果使用默认的更新频道 4.3，NFD Operator 将无法部署。您必须将更新频道设置为 4.2，才能成功进行部署。

要将现有 OpenShift Container Platform 4.2 集群升级到此最新版本，请参阅使用 CLI 更新集群以获取相关说明。

要将现有 OpenShift Container Platform 4.2 集群升级到此最新版本，请参阅使用 CLI 更新集群以获取相关说明。

要将现有 OpenShift Container Platform 4.2 集群升级到此最新版本，请参阅使用 CLI 更新集群以获取相关说明。

要使 NFD Operator 部署成功，您必须使用默认的 4.3 更新频道，并选择默认命名空间，而不是自定义命名空间。(BZ#1808503)

要将现有 OpenShift Container Platform 4.2 集群升级到此最新版本，请参阅使用 CLI 更新集群以获取相关说明。

要将现有 OpenShift Container Platform 4.2 集群升级到此最新版本，请参阅使用 CLI 更新集群以获取相关说明。

要将现有 OpenShift Container Platform 4.2 集群升级到此最新版本，请参阅使用 CLI 更新集群以获取相关说明。

要将现有 OpenShift Container Platform 4.2 集群升级到此最新版本，请参阅使用 CLI 更新集群以获取相关说明。

要将现有 OpenShift Container Platform 4.2 集群升级到此最新版本，请参阅使用 CLI 更新集群以获取相关说明。

要将现有 OpenShift Container Platform 4.2 集群升级到此最新版本，请参阅使用 CLI 更新集群以获取相关说明。

要将现有 OpenShift Container Platform 4.2 集群升级到此最新版本，请参阅使用 CLI 更新集群以获取相关说明。

要将现有 OpenShift Container Platform 4.2 集群升级到此最新版本，请参阅使用 CLI 更新集群以获取相关说明。