Overview

Until OpenShift Origin 3.6, it was possible to deploy a cluster with an embedded etcd. As of OpenShift Origin 3.7, this is no longer possible. Additionally, the etcd API version since OpenShift Origin 3.6 defaults to v3. Also, since OpenShift Origin 3.7, the v3 is the only version allowed. Therefore, older deployments with embedded etcd with the etcd API version v2 need to migrate to the external etcd first, followed by data migration, before they can be upgraded to OpenShift Origin 3.7.

This migration process performs the following steps:

  1. Stop the master service.

  2. Perform an etcd backup of embedded etcd.

  3. Deploy external etcd (on the master or new host).

  4. Perform a backup of the original etcd master certificates.

  5. Generate new etcd certificates for the master.

  6. Transfer the embedded etcd backup to the external etcd host.

  7. Start the external etcd from the transfered etcd backup.

  8. Re-configure master to use the external etcd.

  9. Start master.

Running the Automated Migration Playbook

Migration to external RPM etcd or external containerized etcd is currently supported.

A migration playbook is provided to automate all aspects of the process; this is the preferred method for performing the migration. You must have access to your existing inventory file with both the master and external etcd host defined in their separate groups.

In order to perform the migration on Red Hat Enterprise Linux Atomic Host, you must be running Atomic Host 7.4 or later.

  1. Ensure you have the latest version of the openshift-ansible packages installed:

    # yum upgrade openshift-ansible\*

    The inventory is expected to have exactly one host in the [etcd] group. In most scenarios, it is best to use your existing master, as there is no need for a separate host.

  2. Run the embedded2external.yml playbook using your inventory file:

    # ansible-playbook [-i /path/to/inventory] \
        ~/openshift-ansible/playbooks/byo/openshift-etcd/embedded2external.yml

Running the Manual Migration

Currently, manual migration is not recommended, as it requires a deployment of the new etcd cluster and re-deployment of etcd master certificates.