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 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.

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.

VPE gateway creation information

When a VPC cluster is created at or updated to version 4.15, the following VPE gateways are created if they do not exist.

• For clusters updated to 4.15, these VPE Gateways should already exist since they would have been created when the cluster was at 4.14.

These VPE Gateways are shared by all resources in the VPC, and when they are first created, they change the IP addresses associated with these services as well as restrict access to them.

If any resources in the VPC are using any of these services where the VPE Gateway does not yet exist, you must take the actions described below both before and possibly during the update to ensure the resources still have access.

The steps you take are different depending on if you are creating a new 4.15 cluster, or upgrading the master of an existing 4.14 cluster.

• New 4.15 clusters get the Secure by Default configurations described above.
• Upgraded existing 4.14 clusters continue to use the old security group model.

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.