This is a cache of https://docs.okd.io/4.6/migrating_from_ocp_3_to_4/planning-considerations-3-4.html. It is a snapshot of the page at 2024-11-18T03:16:56.632+0000.
Planning considerations | Migrating from version 3 to 4 | OKD 4.6
  1. Documentation
×

Planning considerations

This section describes considerations and strategies for planning your migration from OKD 3 to 4.

dns considerations

The dns domain of the OKD 4 target cluster is different from the domain of the OKD 3 source cluster. By default, applications get FQdns of the OKD 4 cluster after migration.

To preserve the source dns domain of migrated applications, select one of the two options described below.

Isolating the dns domain of the target cluster from the clients

You can allow the clients' requests sent to the dns domain of the source cluster to reach the dns domain of the target cluster without exposing the target cluster to the clients.

Procedure

  1. Place an exterior network component, such as an application load balancer or a reverse proxy, between the clients and the OpenShift Container Platform 4 cluster.

  2. Update the original application FQDN (app1.apps.ocp3.example.com) in the dns server to return the IP address of the exterior network component.

  3. Configure the network component to send requests received for the application in the source domain to the load balancer in the target OKD 4 cluster domain.

  4. Create a wildcard dns record for the *.apps.ocp3.example.com domain that points to the IP address of the load balancer of the source cluster.

  5. Create a specific dns record for each application that points to the IP address of the exterior network component in front of the target cluster. A specific dns record has higher priority than a wildcard record, so no conflict arises when the application FQDN is resolved.

  • The exterior network component must terminate all secure TLS connections. If the connections pass through to the OKD 4 load balancer, the FQDN of the target application is exposed to the client and certificate errors occur.

  • The applications must not return links referencing the target cluster domain to the clients. Otherwise, parts of the application might not load or work properly.

Setting up the target cluster to accept the source dns domain

You can set up the target cluster to accept requests for migrated applications in the dns domain of the source cluster.

Procedure

For both non-secure HTTP access and secure HTTPS access, perform the following steps:

  1. Create a route in the application’s project for the hostname that applications used in the source cluster:

    $ oc expose svc app1-svc --hostname app1.apps.ocp3.example.com \
 -n app1-namespace

    With this new route in place, the server accepts any request for that FQDN and sends it to the corresponding application pods. In addition, when you migrate the application, another route is created in the target cluster domain (app1.apps.ocp4.example.com). Requests can reach the migrated application using both of these hostnames.

  2. Create a specific dns record for the FQDN in the route hostname parameter that points to the IP address of the default load balancer of the target cluster. Specific dns records take priority over wildcard records.

    The FQDN of the application resolves to the load balancer of the target cluster. The default ingress controller router accept requests for that FQDN because a route for that hostname is exposed.

For secure HTTPS access, perform the following additional step:

  1. Replace the x509 certificate of the default ingress controller created during the installation process with a custom certificate.

  2. Configure this certificate to include the wildcard dns domains for both the source and target clusters in the subjectAltName field.

    The new certificate is valid for securing connections made using either of the two dns domains.

Additional resources