Replacing an unhealthy etcd member

This document describes the process to replace a single unhealthy etcd member.

This process depends on whether the etcd member is unhealthy because the machine is not running or the node is not ready, or whether it is unhealthy because the etcd pod is crashlooping.

If you have lost the majority of your control plane hosts, follow the disaster recovery procedure to restore to a previous cluster state instead of this procedure.

If the control plane certificates are not valid on the member being replaced, then you must follow the procedure to recover from expired control plane certificates instead of this procedure.

If a control plane node is lost and a new one is created, the etcd cluster Operator handles generating the new TLS certificates and adding the node as an etcd member.

Prerequisites

  • Take an etcd backup prior to replacing an unhealthy etcd member.

Identifying an unhealthy etcd member

You can identify if your cluster has an unhealthy etcd member.

Prerequisites

  • Access to the cluster as a user with the cluster-admin role.

Procedure

  1. Check the status of the EtcdMembersAvailable status condition using the following command:

    1. $ oc get etcd -o=jsonpath='{range .items[0].status.conditions[?(@.type=="EtcdMembersAvailable")]}{.message}{"\n"}'
  2. Review the output:

    1. 2 of 3 members are available, ip-10-0-131-183.ec2.internal is unhealthy

    This example output shows that the ip-10-0-131-183.ec2.internal etcd member is unhealthy.

Determining the state of the unhealthy etcd member

The steps to replace an unhealthy etcd member depend on which of the following states your etcd member is in:

  • The machine is not running or the node is not ready

  • The etcd pod is crashlooping

This procedure determines which state your etcd member is in. This enables you to know which procedure to follow to replace the unhealthy etcd member.

If you are aware that the machine is not running or the node is not ready, but you expect it to return to a healthy state soon, then you do not need to perform a procedure to replace the etcd member. The etcd cluster Operator will automatically sync when the machine or node returns to a healthy state.

Prerequisites

  • You have access to the cluster as a user with the cluster-admin role.

  • You have identified an unhealthy etcd member.

Procedure

  1. Determine if the machine is not running:

    1. $ oc get machines -A -ojsonpath='{range .items[*]}{@.status.nodeRef.name}{"\t"}{@.status.providerStatus.instanceState}{"\n"}' | grep -v running

    Example output

    1. ip-10-0-131-183.ec2.internal stopped (1)
    1This output lists the node and the status of the node’s machine. If the status is anything other than running, then the machine is not running.

    If the machine is not running, then follow the Replacing an unhealthy etcd member whose machine is not running or whose node is not ready procedure.

  2. Determine if the node is not ready.

    If either of the following scenarios are true, then the node is not ready.

    • If the machine is running, then check whether the node is unreachable:

      1. $ oc get nodes -o jsonpath='{range .items[*]}{"\n"}{.metadata.name}{"\t"}{range .spec.taints[*]}{.key}{" "}' | grep unreachable

      Example output

      1. ip-10-0-131-183.ec2.internal node-role.kubernetes.io/master node.kubernetes.io/unreachable node.kubernetes.io/unreachable (1)
      1If the node is listed with an unreachable taint, then the node is not ready.
    • If the node is still reachable, then check whether the node is listed as NotReady:

      1. $ oc get nodes -l node-role.kubernetes.io/master | grep "NotReady"

      Example output

      1. ip-10-0-131-183.ec2.internal NotReady master 122m v1.28.5 (1)
      1If the node is listed as NotReady, then the node is not ready.

    If the node is not ready, then follow the Replacing an unhealthy etcd member whose machine is not running or whose node is not ready procedure.

  3. Determine if the etcd pod is crashlooping.

    If the machine is running and the node is ready, then check whether the etcd pod is crashlooping.

    1. Verify that all control plane nodes are listed as Ready:

      1. $ oc get nodes -l node-role.kubernetes.io/master

      Example output

      1. NAME STATUS ROLES AGE VERSION
      2. ip-10-0-131-183.ec2.internal Ready master 6h13m v1.28.5
      3. ip-10-0-164-97.ec2.internal Ready master 6h13m v1.28.5
      4. ip-10-0-154-204.ec2.internal Ready master 6h13m v1.28.5
    2. Check whether the status of an etcd pod is either Error or CrashloopBackoff:

      1. $ oc -n openshift-etcd get pods -l k8s-app=etcd

      Example output

      1. etcd-ip-10-0-131-183.ec2.internal 2/3 Error 7 6h9m (1)
      2. etcd-ip-10-0-164-97.ec2.internal 3/3 Running 0 6h6m
      3. etcd-ip-10-0-154-204.ec2.internal 3/3 Running 0 6h6m
      1Since this status of this pod is Error, then the etcd pod is crashlooping.

    If the etcd pod is crashlooping, then follow the Replacing an unhealthy etcd member whose etcd pod is crashlooping procedure.

Replacing the unhealthy etcd member

Depending on the state of your unhealthy etcd member, use one of the following procedures:

Replacing an unhealthy etcd member whose machine is not running or whose node is not ready

This procedure details the steps to replace an etcd member that is unhealthy either because the machine is not running or because the node is not ready.

If your cluster uses a control plane machine set, see “Recovering a degraded etcd Operator” in “Troubleshooting the control plane machine set” for a more simple etcd recovery procedure.

Prerequisites

  • You have identified the unhealthy etcd member.

  • You have verified that either the machine is not running or the node is not ready.

    You must wait if the other control plane nodes are powered off. The control plane nodes must remain powered off until the replacement of an unhealthy etcd member is complete.

  • You have access to the cluster as a user with the cluster-admin role.

  • You have taken an etcd backup.

    It is important to take an etcd backup before performing this procedure so that your cluster can be restored if you encounter any issues.

Procedure

  1. Remove the unhealthy member.

    1. Choose a pod that is not on the affected node:

      In a terminal that has access to the cluster as a cluster-admin user, run the following command:

      1. $ oc -n openshift-etcd get pods -l k8s-app=etcd

      Example output

      1. etcd-ip-10-0-131-183.ec2.internal 3/3 Running 0 123m
      2. etcd-ip-10-0-164-97.ec2.internal 3/3 Running 0 123m
      3. etcd-ip-10-0-154-204.ec2.internal 3/3 Running 0 124m
    2. Connect to the running etcd container, passing in the name of a pod that is not on the affected node:

      In a terminal that has access to the cluster as a cluster-admin user, run the following command:

      1. $ oc rsh -n openshift-etcd etcd-ip-10-0-154-204.ec2.internal
    3. View the member list:

      1. sh-4.2# etcdctl member list -w table

      Example output

      1. +------------------+---------+------------------------------+---------------------------+---------------------------+
      2. | ID | STATUS | NAME | PEER ADDRS | CLIENT ADDRS |
      3. +------------------+---------+------------------------------+---------------------------+---------------------------+
      4. | 6fc1e7c9db35841d | started | ip-10-0-131-183.ec2.internal | https://10.0.131.183:2380 | https://10.0.131.183:2379 |
      5. | 757b6793e2408b6c | started | ip-10-0-164-97.ec2.internal | https://10.0.164.97:2380 | https://10.0.164.97:2379 |
      6. | ca8c2990a0aa29d1 | started | ip-10-0-154-204.ec2.internal | https://10.0.154.204:2380 | https://10.0.154.204:2379 |
      7. +------------------+---------+------------------------------+---------------------------+---------------------------+

      Take note of the ID and the name of the unhealthy etcd member, because these values are needed later in the procedure. The $ etcdctl endpoint health command will list the removed member until the procedure of replacement is finished and a new member is added.

    4. Remove the unhealthy etcd member by providing the ID to the etcdctl member remove command:

      1. sh-4.2# etcdctl member remove 6fc1e7c9db35841d

      Example output

      1. Member 6fc1e7c9db35841d removed from cluster ead669ce1fbfb346
    5. View the member list again and verify that the member was removed:

      1. sh-4.2# etcdctl member list -w table

      Example output

      1. +------------------+---------+------------------------------+---------------------------+---------------------------+
      2. | ID | STATUS | NAME | PEER ADDRS | CLIENT ADDRS |
      3. +------------------+---------+------------------------------+---------------------------+---------------------------+
      4. | 757b6793e2408b6c | started | ip-10-0-164-97.ec2.internal | https://10.0.164.97:2380 | https://10.0.164.97:2379 |
      5. | ca8c2990a0aa29d1 | started | ip-10-0-154-204.ec2.internal | https://10.0.154.204:2380 | https://10.0.154.204:2379 |
      6. +------------------+---------+------------------------------+---------------------------+---------------------------+

      You can now exit the node shell.

  2. Turn off the quorum guard by entering the following command:

    1. $ oc patch etcd/cluster --type=merge -p '{"spec": {"unsupportedConfigOverrides": {"useUnsupportedUnsafeNonHANonProductionUnstableEtcd": true}}}'

    This command ensures that you can successfully re-create secrets and roll out the static pods.

    After you turn off the quorum guard, the cluster might be unreachable for a short time while the remaining etcd instances reboot to reflect the configuration change.

    etcd cannot tolerate any additional member failure when running with two members. Restarting either remaining member breaks the quorum and causes downtime in your cluster. The quorum guard protects etcd from restarts due to configuration changes that could cause downtime, so it must be disabled to complete this procedure.

  3. Delete the affected node by running the following command:

    1. $ oc delete node <node_name>
  4. Remove the old secrets for the unhealthy etcd member that was removed.

    1. List the secrets for the unhealthy etcd member that was removed.

      1. $ oc get secrets -n openshift-etcd | grep ip-10-0-131-183.ec2.internal (1)
      1Pass in the name of the unhealthy etcd member that you took note of earlier in this procedure.

      There is a peer, serving, and metrics secret as shown in the following output:

      Example output

      1. etcd-peer-ip-10-0-131-183.ec2.internal kubernetes.io/tls 2 47m
      2. etcd-serving-ip-10-0-131-183.ec2.internal kubernetes.io/tls 2 47m
      3. etcd-serving-metrics-ip-10-0-131-183.ec2.internal kubernetes.io/tls 2 47m
    2. Delete the secrets for the unhealthy etcd member that was removed.

      1. Delete the peer secret:

        1. $ oc delete secret -n openshift-etcd etcd-peer-ip-10-0-131-183.ec2.internal
      2. Delete the serving secret:

        1. $ oc delete secret -n openshift-etcd etcd-serving-ip-10-0-131-183.ec2.internal
      3. Delete the metrics secret:

        1. $ oc delete secret -n openshift-etcd etcd-serving-metrics-ip-10-0-131-183.ec2.internal
  1. Delete and re-create the control plane machine. After this machine is re-created, a new revision is forced and etcd scales up automatically.

    If you are running installer-provisioned infrastructure, or you used the Machine API to create your machines, follow these steps. Otherwise, you must create the new master using the same method that was used to originally create it.

    1. Obtain the machine for the unhealthy member.

      In a terminal that has access to the cluster as a cluster-admin user, run the following command:

      1. $ oc get machines -n openshift-machine-api -o wide

      Example output

      1. NAME PHASE TYPE REGION ZONE AGE NODE PROVIDERID STATE
      2. clustername-8qw5l-master-0 Running m4.xlarge us-east-1 us-east-1a 3h37m ip-10-0-131-183.ec2.internal aws:///us-east-1a/i-0ec2782f8287dfb7e stopped (1)
      3. clustername-8qw5l-master-1 Running m4.xlarge us-east-1 us-east-1b 3h37m ip-10-0-154-204.ec2.internal aws:///us-east-1b/i-096c349b700a19631 running
      4. clustername-8qw5l-master-2 Running m4.xlarge us-east-1 us-east-1c 3h37m ip-10-0-164-97.ec2.internal aws:///us-east-1c/i-02626f1dba9ed5bba running
      5. clustername-8qw5l-worker-us-east-1a-wbtgd Running m4.large us-east-1 us-east-1a 3h28m ip-10-0-129-226.ec2.internal aws:///us-east-1a/i-010ef6279b4662ced running
      6. clustername-8qw5l-worker-us-east-1b-lrdxb Running m4.large us-east-1 us-east-1b 3h28m ip-10-0-144-248.ec2.internal aws:///us-east-1b/i-0cb45ac45a166173b running
      7. clustername-8qw5l-worker-us-east-1c-pkg26 Running m4.large us-east-1 us-east-1c 3h28m ip-10-0-170-181.ec2.internal aws:///us-east-1c/i-06861c00007751b0a running
      1This is the control plane machine for the unhealthy node, ip-10-0-131-183.ec2.internal.
    2. Save the machine configuration to a file on your file system:

      1. $ oc get machine clustername-8qw5l-master-0 \ (1)
      2. -n openshift-machine-api \
      3. -o yaml \
      4. > new-master-machine.yaml
      1Specify the name of the control plane machine for the unhealthy node.
    3. Edit the new-master-machine.yaml file that was created in the previous step to assign a new name and remove unnecessary fields.

      1. Remove the entire status section:

        1. status:
        2. addresses:
        3. - address: 10.0.131.183
        4. type: InternalIP
        5. - address: ip-10-0-131-183.ec2.internal
        6. type: InternalDNS
        7. - address: ip-10-0-131-183.ec2.internal
        8. type: Hostname
        9. lastUpdated: "2020-04-20T17:44:29Z"
        10. nodeRef:
        11. kind: Node
        12. name: ip-10-0-131-183.ec2.internal
        13. uid: acca4411-af0d-4387-b73e-52b2484295ad
        14. phase: Running
        15. providerStatus:
        16. apiVersion: awsproviderconfig.openshift.io/v1beta1
        17. conditions:
        18. - lastProbeTime: "2020-04-20T16:53:50Z"
        19. lastTransitionTime: "2020-04-20T16:53:50Z"
        20. message: machine successfully created
        21. reason: MachineCreationSucceeded
        22. status: "True"
        23. type: MachineCreation
        24. instanceId: i-0fdb85790d76d0c3f
        25. instanceState: stopped
        26. kind: AWSMachineProviderStatus
      2. Change the metadata.name field to a new name.

        It is recommended to keep the same base name as the old machine and change the ending number to the next available number. In this example, clustername-8qw5l-master-0 is changed to clustername-8qw5l-master-3.

        For example:

        1. apiVersion: machine.openshift.io/v1beta1
        2. kind: Machine
        3. metadata:
        4. ...
        5. name: clustername-8qw5l-master-3
        6. ...
      3. Remove the spec.providerID field:

        1. providerID: aws:///us-east-1a/i-0fdb85790d76d0c3f
    4. Delete the machine of the unhealthy member:

      1. $ oc delete machine -n openshift-machine-api clustername-8qw5l-master-0 (1)
      1Specify the name of the control plane machine for the unhealthy node.
    5. Verify that the machine was deleted:

      1. $ oc get machines -n openshift-machine-api -o wide

      Example output

      1. NAME PHASE TYPE REGION ZONE AGE NODE PROVIDERID STATE
      2. clustername-8qw5l-master-1 Running m4.xlarge us-east-1 us-east-1b 3h37m ip-10-0-154-204.ec2.internal aws:///us-east-1b/i-096c349b700a19631 running
      3. clustername-8qw5l-master-2 Running m4.xlarge us-east-1 us-east-1c 3h37m ip-10-0-164-97.ec2.internal aws:///us-east-1c/i-02626f1dba9ed5bba running
      4. clustername-8qw5l-worker-us-east-1a-wbtgd Running m4.large us-east-1 us-east-1a 3h28m ip-10-0-129-226.ec2.internal aws:///us-east-1a/i-010ef6279b4662ced running
      5. clustername-8qw5l-worker-us-east-1b-lrdxb Running m4.large us-east-1 us-east-1b 3h28m ip-10-0-144-248.ec2.internal aws:///us-east-1b/i-0cb45ac45a166173b running
      6. clustername-8qw5l-worker-us-east-1c-pkg26 Running m4.large us-east-1 us-east-1c 3h28m ip-10-0-170-181.ec2.internal aws:///us-east-1c/i-06861c00007751b0a running
    6. Create the new machine using the new-master-machine.yaml file:

      1. $ oc apply -f new-master-machine.yaml
    7. Verify that the new machine has been created:

      1. $ oc get machines -n openshift-machine-api -o wide

      Example output

      1. NAME PHASE TYPE REGION ZONE AGE NODE PROVIDERID STATE
      2. clustername-8qw5l-master-1 Running m4.xlarge us-east-1 us-east-1b 3h37m ip-10-0-154-204.ec2.internal aws:///us-east-1b/i-096c349b700a19631 running
      3. clustername-8qw5l-master-2 Running m4.xlarge us-east-1 us-east-1c 3h37m ip-10-0-164-97.ec2.internal aws:///us-east-1c/i-02626f1dba9ed5bba running
      4. clustername-8qw5l-master-3 Provisioning m4.xlarge us-east-1 us-east-1a 85s ip-10-0-133-53.ec2.internal aws:///us-east-1a/i-015b0888fe17bc2c8 running (1)
      5. clustername-8qw5l-worker-us-east-1a-wbtgd Running m4.large us-east-1 us-east-1a 3h28m ip-10-0-129-226.ec2.internal aws:///us-east-1a/i-010ef6279b4662ced running
      6. clustername-8qw5l-worker-us-east-1b-lrdxb Running m4.large us-east-1 us-east-1b 3h28m ip-10-0-144-248.ec2.internal aws:///us-east-1b/i-0cb45ac45a166173b running
      7. clustername-8qw5l-worker-us-east-1c-pkg26 Running m4.large us-east-1 us-east-1c 3h28m ip-10-0-170-181.ec2.internal aws:///us-east-1c/i-06861c00007751b0a running
      1The new machine, clustername-8qw5l-master-3 is being created and is ready once the phase changes from Provisioning to Running.

      It might take a few minutes for the new machine to be created. The etcd cluster Operator will automatically sync when the machine or node returns to a healthy state.

  2. Turn the quorum guard back on by entering the following command:

    1. $ oc patch etcd/cluster --type=merge -p '{"spec": {"unsupportedConfigOverrides": null}}'
  3. You can verify that the unsupportedConfigOverrides section is removed from the object by entering this command:

    1. $ oc get etcd/cluster -oyaml
  4. If you are using single-node OpenShift, restart the node. Otherwise, you might encounter the following error in the etcd cluster Operator:

    Example output

    1. EtcdCertSignerControllerDegraded: [Operation cannot be fulfilled on secrets "etcd-peer-sno-0": the object has been modified; please apply your changes to the latest version and try again, Operation cannot be fulfilled on secrets "etcd-serving-sno-0": the object has been modified; please apply your changes to the latest version and try again, Operation cannot be fulfilled on secrets "etcd-serving-metrics-sno-0": the object has been modified; please apply your changes to the latest version and try again]

Verification

  1. Verify that all etcd pods are running properly.

    In a terminal that has access to the cluster as a cluster-admin user, run the following command:

    1. $ oc -n openshift-etcd get pods -l k8s-app=etcd

    Example output

    1. etcd-ip-10-0-133-53.ec2.internal 3/3 Running 0 7m49s
    2. etcd-ip-10-0-164-97.ec2.internal 3/3 Running 0 123m
    3. etcd-ip-10-0-154-204.ec2.internal 3/3 Running 0 124m

    If the output from the previous command only lists two pods, you can manually force an etcd redeployment. In a terminal that has access to the cluster as a cluster-admin user, run the following command:

    1. $ oc patch etcd cluster -p='{"spec": {"forceRedeploymentReason": "recovery-'"$( date --rfc-3339=ns )"'"}}' --type=merge (1)
    1The forceRedeploymentReason value must be unique, which is why a timestamp is appended.
  2. Verify that there are exactly three etcd members.

    1. Connect to the running etcd container, passing in the name of a pod that was not on the affected node:

      In a terminal that has access to the cluster as a cluster-admin user, run the following command:

      1. $ oc rsh -n openshift-etcd etcd-ip-10-0-154-204.ec2.internal
    2. View the member list:

      1. sh-4.2# etcdctl member list -w table

      Example output

      1. +------------------+---------+------------------------------+---------------------------+---------------------------+
      2. | ID | STATUS | NAME | PEER ADDRS | CLIENT ADDRS |
      3. +------------------+---------+------------------------------+---------------------------+---------------------------+
      4. | 5eb0d6b8ca24730c | started | ip-10-0-133-53.ec2.internal | https://10.0.133.53:2380 | https://10.0.133.53:2379 |
      5. | 757b6793e2408b6c | started | ip-10-0-164-97.ec2.internal | https://10.0.164.97:2380 | https://10.0.164.97:2379 |
      6. | ca8c2990a0aa29d1 | started | ip-10-0-154-204.ec2.internal | https://10.0.154.204:2380 | https://10.0.154.204:2379 |
      7. +------------------+---------+------------------------------+---------------------------+---------------------------+

      If the output from the previous command lists more than three etcd members, you must carefully remove the unwanted member.

      Be sure to remove the correct etcd member; removing a good etcd member might lead to quorum loss.

Additional resources

Replacing an unhealthy etcd member whose etcd pod is crashlooping

This procedure details the steps to replace an etcd member that is unhealthy because the etcd pod is crashlooping.

Prerequisites

  • You have identified the unhealthy etcd member.

  • You have verified that the etcd pod is crashlooping.

  • You have access to the cluster as a user with the cluster-admin role.

  • You have taken an etcd backup.

    It is important to take an etcd backup before performing this procedure so that your cluster can be restored if you encounter any issues.

Procedure

  1. Stop the crashlooping etcd pod.

    1. Debug the node that is crashlooping.

      In a terminal that has access to the cluster as a cluster-admin user, run the following command:

      1. $ oc debug node/ip-10-0-131-183.ec2.internal (1)
      1Replace this with the name of the unhealthy node.
    2. Change your root directory to /host:

      1. sh-4.2# chroot /host
    3. Move the existing etcd pod file out of the kubelet manifest directory:

      1. sh-4.2# mkdir /var/lib/etcd-backup
      1. sh-4.2# mv /etc/kubernetes/manifests/etcd-pod.yaml /var/lib/etcd-backup/
    4. Move the etcd data directory to a different location:

      1. sh-4.2# mv /var/lib/etcd/ /tmp

      You can now exit the node shell.

  2. Remove the unhealthy member.

    1. Choose a pod that is not on the affected node.

      In a terminal that has access to the cluster as a cluster-admin user, run the following command:

      1. $ oc -n openshift-etcd get pods -l k8s-app=etcd

      Example output

      1. etcd-ip-10-0-131-183.ec2.internal 2/3 Error 7 6h9m
      2. etcd-ip-10-0-164-97.ec2.internal 3/3 Running 0 6h6m
      3. etcd-ip-10-0-154-204.ec2.internal 3/3 Running 0 6h6m
    2. Connect to the running etcd container, passing in the name of a pod that is not on the affected node.

      In a terminal that has access to the cluster as a cluster-admin user, run the following command:

      1. $ oc rsh -n openshift-etcd etcd-ip-10-0-154-204.ec2.internal
    3. View the member list:

      1. sh-4.2# etcdctl member list -w table

      Example output

      1. +------------------+---------+------------------------------+---------------------------+---------------------------+
      2. | ID | STATUS | NAME | PEER ADDRS | CLIENT ADDRS |
      3. +------------------+---------+------------------------------+---------------------------+---------------------------+
      4. | 62bcf33650a7170a | started | ip-10-0-131-183.ec2.internal | https://10.0.131.183:2380 | https://10.0.131.183:2379 |
      5. | b78e2856655bc2eb | started | ip-10-0-164-97.ec2.internal | https://10.0.164.97:2380 | https://10.0.164.97:2379 |
      6. | d022e10b498760d5 | started | ip-10-0-154-204.ec2.internal | https://10.0.154.204:2380 | https://10.0.154.204:2379 |
      7. +------------------+---------+------------------------------+---------------------------+---------------------------+

      Take note of the ID and the name of the unhealthy etcd member, because these values are needed later in the procedure.

    4. Remove the unhealthy etcd member by providing the ID to the etcdctl member remove command:

      1. sh-4.2# etcdctl member remove 62bcf33650a7170a

      Example output

      1. Member 62bcf33650a7170a removed from cluster ead669ce1fbfb346
    5. View the member list again and verify that the member was removed:

      1. sh-4.2# etcdctl member list -w table

      Example output

      1. +------------------+---------+------------------------------+---------------------------+---------------------------+
      2. | ID | STATUS | NAME | PEER ADDRS | CLIENT ADDRS |
      3. +------------------+---------+------------------------------+---------------------------+---------------------------+
      4. | b78e2856655bc2eb | started | ip-10-0-164-97.ec2.internal | https://10.0.164.97:2380 | https://10.0.164.97:2379 |
      5. | d022e10b498760d5 | started | ip-10-0-154-204.ec2.internal | https://10.0.154.204:2380 | https://10.0.154.204:2379 |
      6. +------------------+---------+------------------------------+---------------------------+---------------------------+

      You can now exit the node shell.

  3. Turn off the quorum guard by entering the following command:

    1. $ oc patch etcd/cluster --type=merge -p '{"spec": {"unsupportedConfigOverrides": {"useUnsupportedUnsafeNonHANonProductionUnstableEtcd": true}}}'

    This command ensures that you can successfully re-create secrets and roll out the static pods.

  4. Remove the old secrets for the unhealthy etcd member that was removed.

    1. List the secrets for the unhealthy etcd member that was removed.

      1. $ oc get secrets -n openshift-etcd | grep ip-10-0-131-183.ec2.internal (1)
      1Pass in the name of the unhealthy etcd member that you took note of earlier in this procedure.

      There is a peer, serving, and metrics secret as shown in the following output:

      Example output

      1. etcd-peer-ip-10-0-131-183.ec2.internal kubernetes.io/tls 2 47m
      2. etcd-serving-ip-10-0-131-183.ec2.internal kubernetes.io/tls 2 47m
      3. etcd-serving-metrics-ip-10-0-131-183.ec2.internal kubernetes.io/tls 2 47m
    2. Delete the secrets for the unhealthy etcd member that was removed.

      1. Delete the peer secret:

        1. $ oc delete secret -n openshift-etcd etcd-peer-ip-10-0-131-183.ec2.internal
      2. Delete the serving secret:

        1. $ oc delete secret -n openshift-etcd etcd-serving-ip-10-0-131-183.ec2.internal
      3. Delete the metrics secret:

        1. $ oc delete secret -n openshift-etcd etcd-serving-metrics-ip-10-0-131-183.ec2.internal
  1. Force etcd redeployment.

    In a terminal that has access to the cluster as a cluster-admin user, run the following command:

    1. $ oc patch etcd cluster -p='{"spec": {"forceRedeploymentReason": "single-master-recovery-'"$( date --rfc-3339=ns )"'"}}' --type=merge (1)
    1The forceRedeploymentReason value must be unique, which is why a timestamp is appended.

    When the etcd cluster Operator performs a redeployment, it ensures that all control plane nodes have a functioning etcd pod.

  2. Turn the quorum guard back on by entering the following command:

    1. $ oc patch etcd/cluster --type=merge -p '{"spec": {"unsupportedConfigOverrides": null}}'
  3. You can verify that the unsupportedConfigOverrides section is removed from the object by entering this command:

    1. $ oc get etcd/cluster -oyaml
  4. If you are using single-node OpenShift, restart the node. Otherwise, you might encounter the following error in the etcd cluster Operator:

    Example output

    1. EtcdCertSignerControllerDegraded: [Operation cannot be fulfilled on secrets "etcd-peer-sno-0": the object has been modified; please apply your changes to the latest version and try again, Operation cannot be fulfilled on secrets "etcd-serving-sno-0": the object has been modified; please apply your changes to the latest version and try again, Operation cannot be fulfilled on secrets "etcd-serving-metrics-sno-0": the object has been modified; please apply your changes to the latest version and try again]

Verification

  • Verify that the new member is available and healthy.

    1. Connect to the running etcd container again.

      In a terminal that has access to the cluster as a cluster-admin user, run the following command:

      1. $ oc rsh -n openshift-etcd etcd-ip-10-0-154-204.ec2.internal
    2. Verify that all members are healthy:

      1. sh-4.2# etcdctl endpoint health

      Example output

      1. https://10.0.131.183:2379 is healthy: successfully committed proposal: took = 16.671434ms
      2. https://10.0.154.204:2379 is healthy: successfully committed proposal: took = 16.698331ms
      3. https://10.0.164.97:2379 is healthy: successfully committed proposal: took = 16.621645ms

Replacing an unhealthy bare metal etcd member whose machine is not running or whose node is not ready

This procedure details the steps to replace a bare metal etcd member that is unhealthy either because the machine is not running or because the node is not ready.

If you are running installer-provisioned infrastructure or you used the Machine API to create your machines, follow these steps. Otherwise you must create the new control plane node using the same method that was used to originally create it.

Prerequisites

  • You have identified the unhealthy bare metal etcd member.

  • You have verified that either the machine is not running or the node is not ready.

  • You have access to the cluster as a user with the cluster-admin role.

  • You have taken an etcd backup.

    You must take an etcd backup before performing this procedure so that your cluster can be restored if you encounter any issues.

Procedure

  1. Verify and remove the unhealthy member.

    1. Choose a pod that is not on the affected node:

      In a terminal that has access to the cluster as a cluster-admin user, run the following command:

      1. $ oc -n openshift-etcd get pods -l k8s-app=etcd -o wide

      Example output

      1. etcd-openshift-control-plane-0 5/5 Running 11 3h56m 192.168.10.9 openshift-control-plane-0 <none> <none>
      2. etcd-openshift-control-plane-1 5/5 Running 0 3h54m 192.168.10.10 openshift-control-plane-1 <none> <none>
      3. etcd-openshift-control-plane-2 5/5 Running 0 3h58m 192.168.10.11 openshift-control-plane-2 <none> <none>
    2. Connect to the running etcd container, passing in the name of a pod that is not on the affected node:

      In a terminal that has access to the cluster as a cluster-admin user, run the following command:

      1. $ oc rsh -n openshift-etcd etcd-openshift-control-plane-0
    3. View the member list:

      1. sh-4.2# etcdctl member list -w table

      Example output

      1. +------------------+---------+--------------------+---------------------------+---------------------------+---------------------+
      2. | ID | STATUS | NAME | PEER ADDRS | CLIENT ADDRS | IS LEARNER |
      3. +------------------+---------+--------------------+---------------------------+---------------------------+---------------------+
      4. | 7a8197040a5126c8 | started | openshift-control-plane-2 | https://192.168.10.11:2380/ | https://192.168.10.11:2379/ | false |
      5. | 8d5abe9669a39192 | started | openshift-control-plane-1 | https://192.168.10.10:2380/ | https://192.168.10.10:2379/ | false |
      6. | cc3830a72fc357f9 | started | openshift-control-plane-0 | https://192.168.10.9:2380/ | https://192.168.10.9:2379/ | false |
      7. +------------------+---------+--------------------+---------------------------+---------------------------+---------------------+

      Take note of the ID and the name of the unhealthy etcd member, because these values are required later in the procedure. The etcdctl endpoint health command will list the removed member until the replacement procedure is completed and the new member is added.

    4. Remove the unhealthy etcd member by providing the ID to the etcdctl member remove command:

      Be sure to remove the correct etcd member; removing a good etcd member might lead to quorum loss.

      1. sh-4.2# etcdctl member remove 7a8197040a5126c8

      Example output

      1. Member 7a8197040a5126c8 removed from cluster b23536c33f2cdd1b
    5. View the member list again and verify that the member was removed:

      1. sh-4.2# etcdctl member list -w table

      Example output

      1. +------------------+---------+--------------------+---------------------------+---------------------------+-------------------------+
      2. | ID | STATUS | NAME | PEER ADDRS | CLIENT ADDRS | IS LEARNER |
      3. +------------------+---------+--------------------+---------------------------+---------------------------+-------------------------+
      4. | 7a8197040a5126c8 | started | openshift-control-plane-2 | https://192.168.10.11:2380/ | https://192.168.10.11:2379/ | false |
      5. | 8d5abe9669a39192 | started | openshift-control-plane-1 | https://192.168.10.10:2380/ | https://192.168.10.10:2379/ | false |
      6. +------------------+---------+--------------------+---------------------------+---------------------------+-------------------------+

      You can now exit the node shell.

      After you remove the member, the cluster might be unreachable for a short time while the remaining etcd instances reboot.

  2. Turn off the quorum guard by entering the following command:

    1. $ oc patch etcd/cluster --type=merge -p '{"spec": {"unsupportedConfigOverrides": {"useUnsupportedUnsafeNonHANonProductionUnstableEtcd": true}}}'

    This command ensures that you can successfully re-create secrets and roll out the static pods.

  3. Remove the old secrets for the unhealthy etcd member that was removed by running the following commands.

    1. List the secrets for the unhealthy etcd member that was removed.

      1. $ oc get secrets -n openshift-etcd | grep openshift-control-plane-2

      Pass in the name of the unhealthy etcd member that you took note of earlier in this procedure.

      There is a peer, serving, and metrics secret as shown in the following output:

      1. etcd-peer-openshift-control-plane-2 kubernetes.io/tls 2 134m
      2. etcd-serving-metrics-openshift-control-plane-2 kubernetes.io/tls 2 134m
      3. etcd-serving-openshift-control-plane-2 kubernetes.io/tls 2 134m
    2. Delete the secrets for the unhealthy etcd member that was removed.

      1. Delete the peer secret:

        1. $ oc delete secret etcd-peer-openshift-control-plane-2 -n openshift-etcd
        2. secret "etcd-peer-openshift-control-plane-2" deleted
      2. Delete the serving secret:

        1. $ oc delete secret etcd-serving-metrics-openshift-control-plane-2 -n openshift-etcd
        2. secret "etcd-serving-metrics-openshift-control-plane-2" deleted
      3. Delete the metrics secret:

        1. $ oc delete secret etcd-serving-openshift-control-plane-2 -n openshift-etcd
        2. secret "etcd-serving-openshift-control-plane-2" deleted
  1. Delete the control plane machine.

    If you are running installer-provisioned infrastructure, or you used the Machine API to create your machines, follow these steps. Otherwise, you must create the new control plane node using the same method that was used to originally create it.

    1. Obtain the machine for the unhealthy member.

      In a terminal that has access to the cluster as a cluster-admin user, run the following command:

      1. $ oc get machines -n openshift-machine-api -o wide

      Example output

      1. NAME PHASE TYPE REGION ZONE AGE NODE PROVIDERID STATE
      2. examplecluster-control-plane-0 Running 3h11m openshift-control-plane-0 baremetalhost:///openshift-machine-api/openshift-control-plane-0/da1ebe11-3ff2-41c5-b099-0aa41222964e externally provisioned (1)
      3. examplecluster-control-plane-1 Running 3h11m openshift-control-plane-1 baremetalhost:///openshift-machine-api/openshift-control-plane-1/d9f9acbc-329c-475e-8d81-03b20280a3e1 externally provisioned
      4. examplecluster-control-plane-2 Running 3h11m openshift-control-plane-2 baremetalhost:///openshift-machine-api/openshift-control-plane-2/3354bdac-61d8-410f-be5b-6a395b056135 externally provisioned
      5. examplecluster-compute-0 Running 165m openshift-compute-0 baremetalhost:///openshift-machine-api/openshift-compute-0/3d685b81-7410-4bb3-80ec-13a31858241f provisioned
      6. examplecluster-compute-1 Running 165m openshift-compute-1 baremetalhost:///openshift-machine-api/openshift-compute-1/0fdae6eb-2066-4241-91dc-e7ea72ab13b9 provisioned
      1This is the control plane machine for the unhealthy node, examplecluster-control-plane-2.
    2. Save the machine configuration to a file on your file system:

      1. $ oc get machine examplecluster-control-plane-2 \ (1)
      2. -n openshift-machine-api \
      3. -o yaml \
      4. > new-master-machine.yaml
      1Specify the name of the control plane machine for the unhealthy node.
    3. Edit the new-master-machine.yaml file that was created in the previous step to assign a new name and remove unnecessary fields.

      1. Remove the entire status section:

        1. status:
        2. addresses:
        3. - address: ""
        4. type: InternalIP
        5. - address: fe80::4adf:37ff:feb0:8aa1%ens1f1.373
        6. type: InternalDNS
        7. - address: fe80::4adf:37ff:feb0:8aa1%ens1f1.371
        8. type: Hostname
        9. lastUpdated: "2020-04-20T17:44:29Z"
        10. nodeRef:
        11. kind: Machine
        12. name: fe80::4adf:37ff:feb0:8aa1%ens1f1.372
        13. uid: acca4411-af0d-4387-b73e-52b2484295ad
        14. phase: Running
        15. providerStatus:
        16. apiVersion: machine.openshift.io/v1beta1
        17. conditions:
        18. - lastProbeTime: "2020-04-20T16:53:50Z"
        19. lastTransitionTime: "2020-04-20T16:53:50Z"
        20. message: machine successfully created
        21. reason: MachineCreationSucceeded
        22. status: "True"
        23. type: MachineCreation
        24. instanceId: i-0fdb85790d76d0c3f
        25. instanceState: stopped
        26. kind: Machine
  1. Change the metadata.name field to a new name.

    It is recommended to keep the same base name as the old machine and change the ending number to the next available number. In this example, examplecluster-control-plane-2 is changed to examplecluster-control-plane-3.

    For example:

    1. apiVersion: machine.openshift.io/v1beta1
    2. kind: Machine
    3. metadata:
    4. ...
    5. name: examplecluster-control-plane-3
    6. ...
    1. Remove the spec.providerID field:

      1. providerID: baremetalhost:///openshift-machine-api/openshift-control-plane-2/3354bdac-61d8-410f-be5b-6a395b056135
    2. Remove the metadata.annotations and metadata.generation fields:

      1. annotations:
      2. machine.openshift.io/instance-state: externally provisioned
      3. ...
      4. generation: 2
    3. Remove the spec.conditions, spec.lastUpdated, spec.nodeRef and spec.phase fields:

      1. lastTransitionTime: "2022-08-03T08:40:36Z"
      2. message: 'Drain operation currently blocked by: [{Name:EtcdQuorumOperator Owner:clusteroperator/etcd}]'
      3. reason: HookPresent
      4. severity: Warning
      5. status: "False"
      6. type: Drainable
      7. lastTransitionTime: "2022-08-03T08:39:55Z"
      8. status: "True"
      9. type: InstanceExists
      10. lastTransitionTime: "2022-08-03T08:36:37Z"
      11. status: "True"
      12. type: Terminable
      13. lastUpdated: "2022-08-03T08:40:36Z"
      14. nodeRef:
      15. kind: Node
      16. name: openshift-control-plane-2
      17. uid: 788df282-6507-4ea2-9a43-24f237ccbc3c
      18. phase: Running
  2. Ensure that the Bare Metal Operator is available by running the following command:

    1. $ oc get clusteroperator baremetal

    Example output

    1. NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE MESSAGE
    2. baremetal 4.0 True False False 3d15h
  3. Remove the old BareMetalHost object by running the following command:

    1. $ oc delete bmh openshift-control-plane-2 -n openshift-machine-api

    Example output

    1. baremetalhost.metal3.io "openshift-control-plane-2" deleted
  4. Delete the machine of the unhealthy member by running the following command:

    1. $ oc delete machine -n openshift-machine-api examplecluster-control-plane-2

    After you remove the BareMetalHost and Machine objects, then the Machine controller automatically deletes the Node object.

    If deletion of the machine is delayed for any reason or the command is obstructed and delayed, you can force deletion by removing the machine object finalizer field.

    Do not interrupt machine deletion by pressing Ctrl+c. You must allow the command to proceed to completion. Open a new terminal window to edit and delete the finalizer fields.

    1. Edit the machine configuration by running the following command:

      1. $ oc edit machine -n openshift-machine-api examplecluster-control-plane-2
    2. Delete the following fields in the Machine custom resource, and then save the updated file:

      1. finalizers:
      2. - machine.machine.openshift.io

      Example output

      1. machine.machine.openshift.io/examplecluster-control-plane-2 edited
  5. Verify that the machine was deleted by running the following command:

    1. $ oc get machines -n openshift-machine-api -o wide

    Example output

    1. NAME PHASE TYPE REGION ZONE AGE NODE PROVIDERID STATE
    2. examplecluster-control-plane-0 Running 3h11m openshift-control-plane-0 baremetalhost:///openshift-machine-api/openshift-control-plane-0/da1ebe11-3ff2-41c5-b099-0aa41222964e externally provisioned
    3. examplecluster-control-plane-1 Running 3h11m openshift-control-plane-1 baremetalhost:///openshift-machine-api/openshift-control-plane-1/d9f9acbc-329c-475e-8d81-03b20280a3e1 externally provisioned
    4. examplecluster-compute-0 Running 165m openshift-compute-0 baremetalhost:///openshift-machine-api/openshift-compute-0/3d685b81-7410-4bb3-80ec-13a31858241f provisioned
    5. examplecluster-compute-1 Running 165m openshift-compute-1 baremetalhost:///openshift-machine-api/openshift-compute-1/0fdae6eb-2066-4241-91dc-e7ea72ab13b9 provisioned
  6. Verify that the node has been deleted by running the following command:

    1. $ oc get nodes
    2. NAME STATUS ROLES AGE VERSION
    3. openshift-control-plane-0 Ready master 3h24m v1.28.5
    4. openshift-control-plane-1 Ready master 3h24m v1.28.5
    5. openshift-compute-0 Ready worker 176m v1.28.5
    6. openshift-compute-1 Ready worker 176m v1.28.5
  7. Create the new BareMetalHost object and the secret to store the BMC credentials:

    1. $ cat <<EOF | oc apply -f -
    2. apiVersion: v1
    3. kind: Secret
    4. metadata:
    5. name: openshift-control-plane-2-bmc-secret
    6. namespace: openshift-machine-api
    7. data:
    8. password: <password>
    9. username: <username>
    10. type: Opaque
    11. ---
    12. apiVersion: metal3.io/v1alpha1
    13. kind: BareMetalHost
    14. metadata:
    15. name: openshift-control-plane-2
    16. namespace: openshift-machine-api
    17. spec:
    18. automatedCleaningMode: disabled
    19. bmc:
    20. address: redfish://10.46.61.18:443/redfish/v1/Systems/1
    21. credentialsName: openshift-control-plane-2-bmc-secret
    22. disableCertificateVerification: true
    23. bootMACAddress: 48:df:37:b0:8a:a0
    24. bootMode: UEFI
    25. externallyProvisioned: false
    26. online: true
    27. rootDeviceHints:
    28. deviceName: /dev/disk/by-id/scsi-<serial_number>
    29. userData:
    30. name: master-user-data-managed
    31. namespace: openshift-machine-api
    32. EOF

    The username and password can be found from the other bare metal host’s secrets. The protocol to use in bmc:address can be taken from other bmh objects.

    If you reuse the BareMetalHost object definition from an existing control plane host, do not leave the externallyProvisioned field set to true.

    Existing control plane BareMetalHost objects may have the externallyProvisioned flag set to true if they were provisioned by the OKD installation program.

    After the inspection is complete, the BareMetalHost object is created and available to be provisioned.

  8. Verify the creation process using available BareMetalHost objects:

    1. $ oc get bmh -n openshift-machine-api
    2. NAME STATE CONSUMER ONLINE ERROR AGE
    3. openshift-control-plane-0 externally provisioned examplecluster-control-plane-0 true 4h48m
    4. openshift-control-plane-1 externally provisioned examplecluster-control-plane-1 true 4h48m
    5. openshift-control-plane-2 available examplecluster-control-plane-3 true 47m
    6. openshift-compute-0 provisioned examplecluster-compute-0 true 4h48m
    7. openshift-compute-1 provisioned examplecluster-compute-1 true 4h48m
    1. Create the new control plane machine using the new-master-machine.yaml file:

      1. $ oc apply -f new-master-machine.yaml
    2. Verify that the new machine has been created:

      1. $ oc get machines -n openshift-machine-api -o wide

      Example output

      1. NAME PHASE TYPE REGION ZONE AGE NODE PROVIDERID STATE
      2. examplecluster-control-plane-0 Running 3h11m openshift-control-plane-0 baremetalhost:///openshift-machine-api/openshift-control-plane-0/da1ebe11-3ff2-41c5-b099-0aa41222964e externally provisioned (1)
      3. examplecluster-control-plane-1 Running 3h11m openshift-control-plane-1 baremetalhost:///openshift-machine-api/openshift-control-plane-1/d9f9acbc-329c-475e-8d81-03b20280a3e1 externally provisioned
      4. examplecluster-control-plane-2 Running 3h11m openshift-control-plane-2 baremetalhost:///openshift-machine-api/openshift-control-plane-2/3354bdac-61d8-410f-be5b-6a395b056135 externally provisioned
      5. examplecluster-compute-0 Running 165m openshift-compute-0 baremetalhost:///openshift-machine-api/openshift-compute-0/3d685b81-7410-4bb3-80ec-13a31858241f provisioned
      6. examplecluster-compute-1 Running 165m openshift-compute-1 baremetalhost:///openshift-machine-api/openshift-compute-1/0fdae6eb-2066-4241-91dc-e7ea72ab13b9 provisioned
      1The new machine, clustername-8qw5l-master-3 is being created and is ready after the phase changes from Provisioning to Running.

      It should take a few minutes for the new machine to be created. The etcd cluster Operator will automatically sync when the machine or node returns to a healthy state.

    3. Verify that the bare metal host becomes provisioned and no error reported by running the following command:

      1. $ oc get bmh -n openshift-machine-api

      Example output

      1. $ oc get bmh -n openshift-machine-api
      2. NAME STATE CONSUMER ONLINE ERROR AGE
      3. openshift-control-plane-0 externally provisioned examplecluster-control-plane-0 true 4h48m
      4. openshift-control-plane-1 externally provisioned examplecluster-control-plane-1 true 4h48m
      5. openshift-control-plane-2 provisioned examplecluster-control-plane-3 true 47m
      6. openshift-compute-0 provisioned examplecluster-compute-0 true 4h48m
      7. openshift-compute-1 provisioned examplecluster-compute-1 true 4h48m
    4. Verify that the new node is added and in a ready state by running this command:

      1. $ oc get nodes

      Example output

      1. $ oc get nodes
      2. NAME STATUS ROLES AGE VERSION
      3. openshift-control-plane-0 Ready master 4h26m v1.28.5
      4. openshift-control-plane-1 Ready master 4h26m v1.28.5
      5. openshift-control-plane-2 Ready master 12m v1.28.5
      6. openshift-compute-0 Ready worker 3h58m v1.28.5
      7. openshift-compute-1 Ready worker 3h58m v1.28.5
  9. Turn the quorum guard back on by entering the following command:

    1. $ oc patch etcd/cluster --type=merge -p '{"spec": {"unsupportedConfigOverrides": null}}'
  10. You can verify that the unsupportedConfigOverrides section is removed from the object by entering this command:

    1. $ oc get etcd/cluster -oyaml
  11. If you are using single-node OpenShift, restart the node. Otherwise, you might encounter the following error in the etcd cluster Operator:

    Example output

    1. EtcdCertSignerControllerDegraded: [Operation cannot be fulfilled on secrets "etcd-peer-sno-0": the object has been modified; please apply your changes to the latest version and try again, Operation cannot be fulfilled on secrets "etcd-serving-sno-0": the object has been modified; please apply your changes to the latest version and try again, Operation cannot be fulfilled on secrets "etcd-serving-metrics-sno-0": the object has been modified; please apply your changes to the latest version and try again]

Verification

  1. Verify that all etcd pods are running properly.

    In a terminal that has access to the cluster as a cluster-admin user, run the following command:

    1. $ oc -n openshift-etcd get pods -l k8s-app=etcd

    Example output

    1. etcd-openshift-control-plane-0 5/5 Running 0 105m
    2. etcd-openshift-control-plane-1 5/5 Running 0 107m
    3. etcd-openshift-control-plane-2 5/5 Running 0 103m

    If the output from the previous command only lists two pods, you can manually force an etcd redeployment. In a terminal that has access to the cluster as a cluster-admin user, run the following command:

    1. $ oc patch etcd cluster -p='{"spec": {"forceRedeploymentReason": "recovery-'"$( date --rfc-3339=ns )"'"}}' --type=merge (1)
    1The forceRedeploymentReason value must be unique, which is why a timestamp is appended.

    To verify there are exactly three etcd members, connect to the running etcd container, passing in the name of a pod that was not on the affected node. In a terminal that has access to the cluster as a cluster-admin user, run the following command:

    1. $ oc rsh -n openshift-etcd etcd-openshift-control-plane-0
  2. View the member list:

    1. sh-4.2# etcdctl member list -w table

    Example output

    1. +------------------+---------+--------------------+---------------------------+---------------------------+-----------------+
    2. | ID | STATUS | NAME | PEER ADDRS | CLIENT ADDRS | IS LEARNER |
    3. +------------------+---------+--------------------+---------------------------+---------------------------+-----------------+
    4. | 7a8197040a5126c8 | started | openshift-control-plane-2 | https://192.168.10.11:2380 | https://192.168.10.11:2379 | false |
    5. | 8d5abe9669a39192 | started | openshift-control-plane-1 | https://192.168.10.10:2380 | https://192.168.10.10:2379 | false |
    6. | cc3830a72fc357f9 | started | openshift-control-plane-0 | https://192.168.10.9:2380 | https://192.168.10.9:2379 | false |
    7. +------------------+---------+--------------------+---------------------------+---------------------------+-----------------+

    If the output from the previous command lists more than three etcd members, you must carefully remove the unwanted member.

  3. Verify that all etcd members are healthy by running the following command:

    1. # etcdctl endpoint health --cluster

    Example output

    1. https://192.168.10.10:2379 is healthy: successfully committed proposal: took = 8.973065ms
    2. https://192.168.10.9:2379 is healthy: successfully committed proposal: took = 11.559829ms
    3. https://192.168.10.11:2379 is healthy: successfully committed proposal: took = 11.665203ms
  4. Validate that all nodes are at the latest revision by running the following command:

    1. $ oc get etcd -o=jsonpath='{range.items[0].status.conditions[?(@.type=="NodeInstallerProgressing")]}{.reason}{"\n"}{.message}{"\n"}'
    1. AllNodesAtLatestRevision

Additional resources