1.7. Known issues

  • When upgrading to a new OpenShift Container Platform z-stream release, connectivity to the API server might be interrupted as nodes are upgraded, causing API requests to fail. (BZ#1845411)
  • When upgrading to a new OpenShift Container Platform z-stream release, connectivity to routers might be interrupted as router Pods are updated. For the duration of the upgrade, some applications might not be consistently reachable. (BZ#1809665)
  • When upgrading to a new OpenShift Container Platform release with the default CNI network provider set to OVN-Kubernetes, the upgrade fails and the cluster is left in an unusable state. (BZ#1854175)
  • Because the ImageContentSourcePolicy for image registry pull-through is not yet supported, the deployment Pod cannot mirror images by using a digest ID if the imagestream has the pull-through policy enabled. In this case, an ImagePullBackOff error displays. (BZ#1787112)

  • If you scale up with a RHEL worker while running a cluster on RHOSP that uses user-provisioned infrastructure, all routes are inaccessible if the Ingress port VIP is on the RHEL worker. As a workaround, you must reschedule the router Pod to an RHCOS node and make the Ingress VIP migrate to the RHCOS node. To do this, add the node.openshift.io/os_id: rhcos label to the Ingress Controller before upgrade: 

    $ oc -n openshift-ingress-operator edit ingresscontroller/default -o yaml
spec:
  nodePlacement:
    nodeSelector:
      matchLabels:
        kubernetes.io/os: linux
        node-role.kubernetes.io/worker: ""
        node.openshift.io/os_id: rhcos

    (BZ#1848945)

  • The Che Workspace Operator was updated to use the DevWorkspace custom resource instead of the Workspace custom resource. However, the OpenShift web terminal continues to use the Workspace custom resource. Because of this, the OpenShift web terminal fails to work with the latest version of the Che Workspace Operator. (BZ#1846969)
  • A basic-user is unable to view the Dashboard and Metrics tabs in the Monitoring view of the Developer perspective. (BZ#1846409)
  • In the Topology view, when you right-click a Knative service, the Edit Application Grouping option is displayed twice in the context menu. (BZ#1849107)
  • The Special Resources Operator (SRO) cannot be deployed successfully on OpenShift Container Platform 4.5. This prevents the deployment of NVIDIA drivers, which are required by the cluster to run workloads requiring GPU resources. Also, the Topology Manager feature could not be tested with GPU resources as a result of this known issue. (BZ#1847805)
  • The web console includes the option to create VM vNICS with a SLIRP binding, but this is not supported. Attempting to use this option will cause the VM to fail to boot. Do not select this option. (BZ#1828744)
  • There is an issue where Pods that use the OpenShift SDN default CNI network provider in a node can lose network communication, causing the Pods to crash. This can sometimes happen when upgrading a cluster. As a workaround, you can delete and re-create the Pods. (BZ#1855118)
  • There is a known issue where the custom pool is not supported on the master node. The command oc label node applies the new custom role to the target master node, but the Machine Config Operator does not apply changes specific to the custom pool. This results in an error, which can be seen in the Machine Config Controller Pod logs. As a suggested workaround to ensure that control plane nodes remain stable, it is recommended to not apply multiple roles on master. (BZ#1797687)
  • The logging performance for clusters is degraded compared to past versions of OpenShift Container Platform. This is being actively investigated and will be updated in a future release of OpenShift Container Platform. (BZ#1833486)
  • You might receive a message that the system is unable to mount a volume when the volume contains a large number of files. This can happen when a Pod mounts a volume that is set with FSGroup SecurityContext because the GID ownership of the files must be recursively updated for all files on the volume. Users should expect that Pods using volumes with a large number of files and the FSGroup SecurityContext setting can take considerable time to start. (BZ#1515907)
  • Running Pods with frequent probes can cause the number of conmon processes to grow quickly. A conmon process is a program that detaches from its parent, CRI-O, and is used to exec the container runtime. If the probes happen frequently enough, systemd has trouble reaping all of its new children, and some conmon processes can become zombies. (BZ#1852064)
  • On Microsoft Azure when upgrading from 4.4 to 4.5, the Ingress Operator can fail to ensure a DNSRecord due to errors refreshing the token. Restarting the Ingress Operator fixes the issue. (BZ#1854383)
  • When running OpenShift Container Platform on Azure with installer-provisioned infrastructure, there is a known issue where oc commands fail intermittently with TLS handshake timeout errors. (BZ#1851549)
  • For clusters on VMware vSphere instances using installer-provisioned infrastructure, bootstrap workers fail. The default resource pool resolves to multiple instances. (BZ#1852545)