4.15 version information and update actions

Release timeline

The following table includes the expected release timeline for version 4.15. You can use this information for planning purposes, such as to estimate the general time that the version might become unsupported.

Dates that are marked with a dagger (†) are tentative and subject to change.

Preparing to update

Review changes that you might need to make when you update a cluster to version 4.15. This information summarizes updates that are likely to have an impact on deployed apps when you update.

The OpenShift Data Foundation and the cluster-autoscaler add-ons do not support Red Hat OpenShift on IBM Cloud version 4.15 with CoreOS worker nodes.

The backup and restore Helm chart is supported on Red Hat OpenShift on IBM Cloud 4.15 clusters. However, only the COS direct endpoints are supported. For example: s3.direct.us.cloud-object-storage.appdomain.cloud.

Portworx does not yet support Red Hat OpenShift on IBM Cloud version 4.15 clusters. Do not update your cluster to version 4.15 if Portworx is installed.

Red Hat OpenShift on IBM Cloud version 4.15 clusters do not yet support Rotating CA certificates in your cluster. Do not update your cluster to version 4.15 if this support is required.

Checking the Upgradeable status of your cluster

Run the following command to check the Upgradeable status of your cluster.

oc get clusterversion version -o json | jq '.status.conditions[] | select(.type == "Upgradeable")'

Example output where the Upgradeable status is False.

{
  "lastTransitionTime": "2023-10-04T15:55:54Z",
  "message": "Kubernetes 1.27 and therefore OpenShift 4.15 remove several APIs which require admin consideration. Please see the knowledge article https://access.redhat.com/articles/6958395 for details and instructions.",
  "reason": "AdminAckRequired",
  "status": "False",
  "type": "Upgradeable"
}

If the Upgradeable status is False, the condition information provides instructions that must be followed before upgrading. For more information, see Providing the administrator acknowledgment.

Important networking changes for VPC clusters created at version 4.15

Beginning with version 4.15, Red Hat OpenShift on IBM Cloud introduced a new security feature for VPC clusters called Secure by Default Cluster VPC Networking.

At a high-level, the security posture for Red Hat OpenShift on IBM Cloud VPC clusters has changed from allowing all outbound traffic then providing users with mechanisms to selectively block traffic as needed to now blocking all traffic that is not crucial to cluster functionality and providing users with mechanisms to selectively allow traffic as needed.

When you provision a new Red Hat OpenShift on IBM Cloud VPC cluster at version 4.15 or later, the default provisioning behavior is to allow only the traffic that is necessary for the cluster to function. All other access is blocked. To implement Secure by Default Networking, there are changes to the default VPC security groups settings as well as new Virtual Private Endpoints (VPEs) for common IBM services.

Some key notes for Secure by Default Networking are:

• Applies to VPC clusters only. Classic clusters are not impacted.

• Does not affect existing clusters. Existing clusters in your VPC will continue to function as they do today.

• Applies only to newly provisioned Red Hat OpenShift on IBM Cloud clusters at version 4.15. The security group configurations for existing Red Hat OpenShift on IBM Cloud clusters that are upgraded to version 4.15, including any customizations you've made, are not changed.

• The default behavior for clusters created at version 4.15 and later is to enable Secure by Default outbound traffic protection. However, new parameters in the UI, CLI, API, and Terraform allow you to disable this feature. You can also enable and disable outbound traffic protection after you create a cluster.

• If your VPC uses a custom DNS resolver, provisioning a new version 4.15 cluster automatically adds rules allowing traffic through the resolver IP addresses on your IKS-managed security group (kube-<clusterID>).

For an overview of Secure by Default Cluster VPC networking, including the security groups, rules, and VPEs that are created by default, see Understanding Secure by Default Cluster VPC Networking.

Allowing outbound traffic after creating a 4.15 cluster

If you created a version 4.15 cluster with outbound traffic protection enabled, your apps or services might experience downtime due to dependencies that require external network connections. Review the following options for enabling outbound traffic selectively or allowing all outbound traffic.

For more information, see Managing outbound traffic protection in VPC clusters.

Common issues and troubleshooting

• After enabling outbound traffic protection on my 4.15 cluster, my app no longer works.
• When I try to create version 4.15 cluster, I see a quota error.
• When I update my cluster to secure by default, my nodeport app no longer works.
• Why do I see DNS failures after adding a custom DNS resolver?.
• After creating a version 4.15 cluster, applications running in other clusters in my VPC are failing.