Soon, all Red Hat OpenShift documentation will only be available on docs.redhat.com, the official location of all Red Hat product documentation. Get familiar with the updated experience today!
  1. Documentation
×

Differences between OKD 3 and 4

OKD 4.7 introduces architectural changes and enhancements. The procedures that you used to manage your OKD 3 cluster might not apply to OKD 4.

It is not possible to upgrade your existing OKD 3 cluster to OKD 4. You must start with a new OKD 4 installation. Tools are available to assist in migrating your control plane settings and application workloads.

Architecture

With OKD 3, administrators individually deployed Fedora hosts, and then installed OKD on top of these hosts to form a cluster. Administrators were responsible for properly configuring these hosts and performing updates.

OKD 4 represents a significant change in the way that OKD clusters are deployed and managed. OKD 4 includes new technologies and functionality, such as Operators, machine sets, and Fedora CoreOS (FCOS), which are core to the operation of the cluster. This technology shift enables clusters to self-manage some functions previously performed by administrators. This also ensures platform stability and consistency, and simplifies installation and scaling.

For more information, see OpenShift Container Platform architecture.

Immutable infrastructure

OKD 4 uses Fedora CoreOS (FCOS), which is designed to run containerized applications, and provides efficient installation, Operator-based management, and simplified upgrades. FCOS is an immutable container host, rather than a customizable operating system like Fedora. FCOS enables OKD 4 to manage and automate the deployment of the underlying container host. FCOS is a part of OKD, which means that everything runs inside a container and is deployed using OKD.

In OKD 4, control plane nodes must run FCOS, ensuring that full-stack automation is maintained for the control plane. This makes rolling out updates and upgrades a much easier process than in OKD 3.

For more information, see Fedora CoreOS (FCOS).

Operators

Operators are a method of packaging, deploying, and managing a Kubernetes application. Operators ease the operational complexity of running another piece of software. They watch over your environment and use the current state to make decisions in real time. Advanced Operators are designed to upgrade and react to failures automatically.

For more information, see Understanding Operators.

Installation and upgrade

Installation process

To install OKD 3.11, you prepared your Fedora hosts, set all of the configuration values your cluster needed, and then ran an Ansible playbook to install and set up your cluster.

In OKD 4.7, you use the OpenShift installation program to create a minimum set of resources required for a cluster. Once the cluster is running, you use Operators to further configure your cluster and to install new services. After first boot, Fedora CoreOS (FCOS) systems are managed by the Machine Config Operator (MCO) that runs in the OKD cluster.

For more information, see Installation process.

Infrastructure options

In OKD 3.11, you installed your cluster on infrastructure that you prepared and maintained. In addition to providing your own infrastructure, OKD 4 offers an option to deploy a cluster on infrastructure that the OKD installation program provisions and the cluster maintains.

For more information, see OpenShift Container Platform installation overview.

Upgrading your cluster

In OKD 3.11, you upgraded your cluster by running Ansible playbooks. In OKD 4.7, the cluster manages its own updates, including updates to Fedora CoreOS (FCOS) on cluster nodes. You can easily upgrade your cluster by using the web console or by using the oc adm upgrade command from the OpenShift CLI and the Operators will automatically upgrade themselves. If your OKD 4.7 cluster has Fedora worker machines, then you will still need to run an Ansible playbook to upgrade those worker machines.

For more information, see Updating clusters.

Migration considerations

Review the changes and other considerations that might affect your transition from OKD 3.11 to OKD 4.

Storage considerations

Review the following storage changes to consider when transitioning from OKD 3.11 to OKD 4.7.

Local volume persistent storage

Local storage is only supported by using the Local Storage Operator in OKD 4.7. It is not supported to use the local provisioner method from OKD 3.11.

For more information, see Persistent storage using local volumes.

FlexVolume persistent storage

The FlexVolume plug-in location changed from OKD 3.11. The new location in OKD 4.7 is /etc/kubernetes/kubelet-plugins/volume/exec. Attachable FlexVolume plug-ins are no longer supported.

For more information, see Persistent storage using FlexVolume.

Container Storage Interface (CSI) persistent storage

Persistent storage using the Container Storage Interface (CSI) was Technology Preview in OKD 3.11. OKD 4.7 ships with several CSI drivers. You can also install your own driver.

For more information, see Persistent storage using the Container Storage Interface (CSI).

Red Hat OpenShift Container Storage

Red Hat OpenShift Container Storage 3, which is available for use with OKD 3.11, uses Red Hat Gluster Storage as the backing storage.

Red Hat OpenShift Container Storage 4, which is available for use with OKD 4, uses Red Hat Ceph Storage as the backing storage.

For more information, see Persistent storage using Red Hat OpenShift Container Storage and the interoperability matrix article.

Unsupported persistent storage options

Support for the following persistent storage options from OKD 3.11 has changed in OKD 4.7:

  • GlusterFS is no longer supported.

  • CephFS as a standalone product is no longer supported.

  • Ceph RBD as a standalone product is no longer supported.

If you used one of these in OKD 3.11, you must choose a different persistent storage option for full support in OKD 4.7.

For more information, see Understanding persistent storage.

Networking considerations

Review the following networking changes to consider when transitioning from OKD 3.11 to OKD 4.7.

Network isolation mode

The default network isolation mode for OKD 3.11 was ovs-subnet, though users frequently switched to use ovn-multitenant. The default network isolation mode for OKD 4.7 is controlled by a network policy.

If your OKD 3.11 cluster used the ovs-subnet or ovs-multitenant mode, it is recommended to switch to a network policy for your OKD 4.7 cluster. Network policies are supported upstream, are more flexible, and they provide the functionality that ovs-multitenant does. If you want to maintain the ovs-multitenant behavior while using a network policy in OKD 4.7, follow the steps to configure multitenant isolation using network policy.

For more information, see About network policy.

Logging considerations

Review the following logging changes to consider when transitioning from OKD 3.11 to OKD 4.7.

Deploying OpenShift Logging

OKD 4 provides a simple deployment mechanism for OpenShift Logging, by using a Cluster Logging custom resource.

For more information, see Installing OpenShift Logging.

Aggregated logging data

You cannot transition your aggregate logging data from OKD 3.11 into your new OKD 4 cluster.

For more information, see About OpenShift Logging.

Unsupported logging configurations

Some logging configurations that were available in OKD 3.11 are no longer supported in OKD 4.7.

For more information on the explicitly unsupported logging cases, see Maintenance and support.

Security considerations

Review the following security changes to consider when transitioning from OKD 3.11 to OKD 4.7.

Unauthenticated access to discovery endpoints

In OKD 3.11, an unauthenticated user could access the discovery endpoints (for example, /api/* and /apis/*). For security reasons, unauthenticated access to the discovery endpoints is no longer allowed in OKD 4.7. If you do need to allow unauthenticated access, you can configure the RBAC settings as necessary; however, be sure to consider the security implications as this can expose internal cluster components to the external network.

Identity providers

Configuration for identity providers has changed for OKD 4, including the following notable changes:

  • The request header identity provider in OKD 4.7 requires mutual TLS, where in OKD 3.11 it did not.

  • The configuration of the OpenID Connect identity provider was simplified in OKD 4.7. It now obtains data, which previously had to specified in OKD 3.11, from the provider’s /.well-known/openid-configuration endpoint.

For more information, see Understanding identity provider configuration.

OAuth token storage format

Newly created OAuth HTTP bearer tokens no longer match the names of their OAuth access token objects. The object names are now a hash of the bearer token and are no longer sensitive. This reduces the risk of leaking sensitive information.

Monitoring considerations

Review the following monitoring changes to consider when transitioning from OKD 3.11 to OKD 4.7.

Alert for monitoring infrastructure availability

The default alert that triggers to ensure the availability of the monitoring structure was called DeadMansSwitch in OKD 3.11. This was renamed to Watchdog in OKD 4. If you had PagerDuty integration set up with this alert in OKD 3.11, you must set up the PagerDuty integration for the Watchdog alert in OKD 4.

For more information, see Applying custom Alertmanager configuration.