Red Hat Training

A Red Hat training course is available for OpenShift Container Platform

第4章 マスターホストの置き換え

失敗したマスターホストを置き換えることができます。

まず、失敗したマスターホストをクラスターから削除し、次に置き換えマスターホストを追加します。失敗したマスターホストが etcd を実行していた場合、etcd を新規のマスターホストに追加して etcd を拡張します。

重要

このトピックのすべてのセクションを完了する必要があります。

4.1. マスターホストの使用の終了

マスターホストは OpenShift Container Platform API およびコントローラーサービスなどの重要なサービスを実行します。マスターホストの使用を終了するには、これらのサービスが停止している必要があります。

OpenShift Container Platform API サービスはアクティブ/アクティブサービスであるため、サービスを停止しても、要求が別のマスターサーバーに送信される限り環境に影響はありません。ただし、OpenShift Container Platform コントローラーサービスはアクティブ/パッシブサービスであり、サービスは etcd を利用してアクティブなマスターを判別します。

複数マスターアーキテクチャーでマスターホストの使用を終了するには、新しい接続でのマスターの使用を防ぐためにマスターをロードバランサープールから削除することが関係します。このプロセスは使用されるロードバランサーによって大きく異なります。以下の手順では、マスターの haproxy からの削除についての詳しく説明しています。OpenShift Container Platform がクラウドプロバイダーで実行されている場合や、F5 アプライアンスを使用する場合は、特定の製品ドキュメントを参照してマスターをローテーションから削除するようにしてください。

手順

  1. /etc/haproxy/haproxy.cfg 設定ファイルで backend セクションを削除します。たとえば、haproxy を使用してmaster-0.example.com という名前のマスターの使用を終了する場合、ホスト名が以下から削除されていることを確認します。

    backend mgmt8443
        balance source
        mode tcp
        # MASTERS 8443
        server master-1.example.com 192.168.55.12:8443 check
        server master-2.example.com 192.168.55.13:8443 check
  2. 次に、haproxy サービスを再起動します。

    $ sudo systemctl restart haproxy
  3. マスターがロードバランサーから削除される場合、定義ファイルを静的 Pod のディレクトリー /etc/origin/node/pods から移動して API およびコントローラーサービスを無効にします。

    # mkdir -p /etc/origin/node/pods/disabled
    # mv /etc/origin/node/pods/controller.yaml /etc/origin/node/pods/disabled/:
    +
  4. マスターホストはスケジュール可能な OpenShift Container Platform ノードであるため、「ノードホストの使用の終了」セクションの手順に従ってください。
  5. マスターホストを /etc/ansible/hosts Ansible インベントリーファイルの [masters] および [nodes] グループから削除し、このインベントリーファイルを使用して Ansible タスクを実行する場合の問題を回避できます。

    警告

    Ansible インベントリーファイルに一覧表示される最初のマスターホストの使用を終了するには、とくに注意が必要になります。

    /etc/origin/master/ca.serial.txt ファイルは Ansible ホストインベントリーに一覧表示される最初のマスターでのみ生成されます。最初のマスターホストの使用を終了する場合は、このプロセスの実行前に /etc/origin/master/ca.serial.txt ファイルを残りのマスターホストにコピーします。

    重要

    複数のマスターを実行する OpenShift Container Platform 3.11 クラスターでは、マスターノードの 1 つの /etc/origin/master/etc/etcd/ca および /etc/etcd/generated_certs に追加の CA 証明書が含まれます。これらはアプリケーションノードおよび etcd ノードのスケールアップ操作に必要であり、CA ホストマスターが非推奨になる場合に別のマスターで復元される必要があります。

  6. kubernetes サービスにはマスターホスト IP がエンドポイントとして含まれています。マスターの使用が適切に終了していることを確認するには、kubernetes サービスの出力を確認して、使用が終了したマスターが削除されているかどうかを確認します。

    $ oc describe svc kubernetes -n default
    Name:			kubernetes
    Namespace:		default
    Labels:			component=apiserver
    			provider=kubernetes
    Annotations:		<none>
    Selector:		<none>
    Type:			ClusterIP
    IP:			10.111.0.1
    Port:			https	443/TCP
    Endpoints:		192.168.55.12:8443,192.168.55.13:8443
    Port:			dns	53/UDP
    Endpoints:		192.168.55.12:8053,192.168.55.13:8053
    Port:			dns-tcp	53/TCP
    Endpoints:		192.168.55.12:8053,192.168.55.13:8053
    Session Affinity:	ClientIP
    Events:			<none>

    マスターの使用が正常に終了している場合、マスターが以前に実行されていたホストを安全に削除できます。

4.2. ホストの追加

scaleup.yml Playbook を実行して新規ホストをクラスターに追加できます。この Playbook はマスターをクエリーし、新規ホストの新規証明書を生成し、配布してから、設定 Playbook を新規ホストにのみ実行します。scaleup.yml Playbook を実行する前に、前提条件となる「ホストの準備」手順をすべて完了してください。

重要

scaleup.yml の Playbook は新規ホストの設定のみを設定します。マスターサービスの NO_PROXY の更新やマスターサービスの再起動は行いません。

scaleup.yml Playbook を実行するには、現在のクラスター設定を表す既存のインベントリーファイル (/etc/ansible/hosts など) が必要です。以前に atomic-openshift-installer コマンドを使用してインストールを実行した場合は、~/.config/openshift/hosts を調べて、インストーラーによって生成された最新のインベントリーファイルを見つけ、そのファイルをインベントリーファイルとして使用することができます。このファイルは必要に応じて変更することができます。後で ansible-playbook を実行する際に -i オプションを使用してそのファイルの場所を指定する必要があります。

重要

ノードの推奨される最大数については、「cluster maximums」のセクションを参照してください。

手順

  1. openshift-ansible パッケージを更新して最新の Playbook を取得します。

    # yum update openshift-ansible
  2. /etc/ansible/hosts ファイルを編集し、new_<host_type>[OSEv3:children] セクションに追加します。たとえば、新規ノードホストを追加するには、new_nodes を追加します。

    [OSEv3:children]
    masters
    nodes
    new_nodes

    新規マスターホストを追加するには、new_masters を追加します。

  3. [new_<host_type>] セクションを作成して、新規ホストのホスト情報を指定します。以下の新規ノードの追加例で示されているように、既存のセクションと同じ様になフォーマットにこのセクションをフォーマットします。

    [nodes]
    master[1:3].example.com
    node1.example.com openshift_node_group_name='node-config-compute'
    node2.example.com openshift_node_group_name='node-config-compute'
    infra-node1.example.com openshift_node_group_name='node-config-infra'
    infra-node2.example.com openshift_node_group_name='node-config-infra'
    
    [new_nodes]
    node3.example.com openshift_node_group_name='node-config-infra'

    その他のオプションについては、「ホスト変数の設定」を参照してください。

    新規マスターを追加する場合は、[new_masters] セクションと [new_nodes] セクションの両方に新規ホストを追加して、新規マスターホストが OpenShift SDN の一部となるようにします。

    [masters]
    master[1:2].example.com
    
    [new_masters]
    master3.example.com
    
    [nodes]
    master[1:2].example.com
    node1.example.com openshift_node_group_name='node-config-compute'
    node2.example.com openshift_node_group_name='node-config-compute'
    infra-node1.example.com openshift_node_group_name='node-config-infra'
    infra-node2.example.com openshift_node_group_name='node-config-infra'
    
    [new_nodes]
    master3.example.com
    重要

    マスターホストに node-role.kubernetes.io/infra=true ラベルを付け、それ以外に専用インフラストラクチャーノードがない場合は、エントリーに openshift_schedulable=true を追加してホストにスケジュール可能であることを示すマークを明示的に付ける必要もあります。そうしないと、レジストリー Pod とルーター Pod をどこにも配置できなくなります。

  4. Playbook ディレクトリーに切り替え、openshift_node_group.yml Playbook を実行します。インベントリーファイルがデフォルトの /etc/ansible/hosts 以外の場所にある場合は、-i オプションで場所を指定します。

    $ cd /usr/share/ansible/openshift-ansible
    $ ansible-playbook [-i /path/to/file] \
      playbooks/openshift-master/openshift_node_group.yml

    これにより、新規ノードグループの ConfigMap が作成され、最終的にはホスト上のノードの設定ファイルが作成されます。

    注記

    openshift_node_group.yaml Playbook を実行しても、新規ノードのみが更新されます。これは、クラスター内の既存ノードを更新するために更新することはできません。

  5. scaleup.yml Playbook を実行します。インベントリーファイルがデフォルトの /etc/ansible/hosts 以外の場所にある場合は、-i オプションで場所を指定します。

    • ノードを追加する場合は、以下を指定します。

      $ ansible-playbook [-i /path/to/file] \
          playbooks/openshift-node/scaleup.yml
    • マスターを追加する場合は、以下を実行します。

      $ ansible-playbook [-i /path/to/file] \
          playbooks/openshift-master/scaleup.yml
  6. EFK スタックをクラスターにデプロイしている場合は、ノードラベルを logging-infra-fluentd=true に設定します。

    # oc label node/new-node.example.com logging-infra-fluentd=true
  7. Playbook の実行後に、「インストールの検証」を行います。
  8. [new_<host_type>] セクションで定義したホストを適切なセクションに移動します。このようにホストを移動することで、このインベントリーファイルを使用するその後の Playbook の実行で、正しくノードが処理されるようになります。[new_<host_type>] セクションは空のままにできます。たとえば、新規ノードを追加する場合は以下のように指定します。

    [nodes]
    master[1:3].example.com
    node1.example.com openshift_node_group_name='node-config-compute'
    node2.example.com openshift_node_group_name='node-config-compute'
    node3.example.com openshift_node_group_name='node-config-compute'
    infra-node1.example.com openshift_node_group_name='node-config-infra'
    infra-node2.example.com openshift_node_group_name='node-config-infra'
    
    [new_nodes]

4.3. etcd のスケーリング

etcd クラスターは、リソースを etcd ホストに追加して垂直的に拡張することも、etcd ホストを追加して水平的に拡張することもできます。

注記

etcd が使用する投票システムのために、クラスターには常に奇数のメンバーが含まれている必要があります。

奇数の etcd ホストを含むクラスターの場合、フォールトトレランスに対応できます。奇数の etcd ホストがあることで、クォーラム (定足数) に必要な数が変わることはありませんが、障害発生時の耐性が高まります。たとえば、クラスターが 3 メンバーで構成される場合、クォーラム (定足数) は 2 で、1 メンバーが障害耐性用になります。これにより、クラスターはメンバーの 2 つが正常である限り、機能し続けます。

3 つの etcd ホストで構成される実稼働クラスターの使用が推奨されます。

新規ホストには、新規の Red Hat Enterprise Linux version 7 専用ホストが必要です。etcd ストレージは最大のパフォーマンスを達成できるように SSD ディスクおよび /var/lib/etcd でマウントされる専用ディスクに置かれる必要があります。

前提条件

  1. 新規 etcd ホストを追加する前に、「etcd 設定およびデータのバックアップ」を行ってデータの損失を防ぎます。
  2. 現在の etcd クラスターステータスを確認し、新規ホストを正常でないクラスターに追加することを防ぎます。以下のコマンドを実行します。

    # ETCDCTL_API=3 etcdctl --cert="/etc/etcd/peer.crt" \
              --key=/etc/etcd/peer.key \
              --cacert="/etc/etcd/ca.crt" \
              --endpoints="https://*master-0.example.com*:2379,\
                https://*master-1.example.com*:2379,\
                https://*master-2.example.com*:2379"
                endpoint health
    https://master-0.example.com:2379 is healthy: successfully committed proposal: took = 5.011358ms
    https://master-1.example.com:2379 is healthy: successfully committed proposal: took = 1.305173ms
    https://master-2.example.com:2379 is healthy: successfully committed proposal: took = 1.388772ms
  3. scaleup Playbook を実行する前に、新規ホストが適切な Red Hat ソフトウェアチャンネルに登録されていることを確認します。

    # subscription-manager register \
        --username=*<username>* --password=*<password>*
    # subscription-manager attach --pool=*<poolid>*
    # subscription-manager repos --disable="*"
    # subscription-manager repos \
        --enable=rhel-7-server-rpms \
        --enable=rhel-7-server-extras-rpms

    etcd は rhel-7-server-extras-rpms ソフトウェアチャンネルでホストされています。

  4. 未使用の etcd メンバーがすべて etcd クラスターから削除されていることを確認します。これは、scaleup Playbook を実行する前に実行する必要があります。

    1. etcd メンバーを一覧表示します。

      # etcdctl --cert="/etc/etcd/peer.crt" --key="/etc/etcd/peer.key" \
        --cacert="/etc/etcd/ca.crt" --endpoints=ETCD_LISTEN_CLIENT_URLS member list -w table

      該当する場合は、未使用の etcd メンバー ID をコピーします。

    2. 以下のコマンドで ID を指定して、未使用のメンバーを削除します。

      # etcdctl --cert="/etc/etcd/peer.crt" --key="/etc/etcd/peer.key" \
        --cacert="/etc/etcd/ca.crt" --endpoints=ETCD_LISTEN_CLIENT_URL member remove UNUSED_ETCD_MEMBER_ID
  5. 現在の etcd ノードで etcd および iptables をアップグレードします。

    # yum update etcd iptables-services
  6. etcd ホストの /etc/etcd 設定をバックアップします。
  7. 新規 etcd メンバーが OpenShift Container Platform ノードでもある場合は、必要な数のホストをクラスターに追加します。
  8. この手順の残りでは 1 つのホストを追加していることを前提としていますが、複数のホストを追加する場合は、各ホストですべての手順を実行します。

4.3.1. Ansible を使用した新規 etcd ホストの追加

手順
  1. Ansible インベントリーファイルで、[new_etcd] という名前の新規グループおよび新規ホストを作成します。次に、new_etcd グループを [OSEv3] グループの子として追加します。

    [OSEv3:children]
    masters
    nodes
    etcd
    new_etcd 1
    
    ... [OUTPUT ABBREVIATED] ...
    
    [etcd]
    master-0.example.com
    master-1.example.com
    master-2.example.com
    
    [new_etcd] 2
    etcd0.example.com 3
    1 2 3
    これらの行を追加します。
  2. OpenShift Container Platform をインストールし、Ansible インベントリーファイルをホストするホストから、Playbook ディレクトリーに移動し、etcd scaleup Playbook を実行します。

    $ cd /usr/share/ansible/openshift-ansible
    $ ansible-playbook  playbooks/openshift-etcd/scaleup.yml
  3. Playbook が実行された後に、新規 etcd ホストを [new_etcd] グループから [etcd] グループに移行し、現在のステータスを反映するようにインベントリーファイルを変更します。

    [OSEv3:children]
    masters
    nodes
    etcd
    new_etcd
    
    ... [OUTPUT ABBREVIATED] ...
    
    [etcd]
    master-0.example.com
    master-1.example.com
    master-2.example.com
    etcd0.example.com
  4. Flannel を使用する場合には、OpenShift Container Platform のホストごとに、/etc/sysconfig/flanneld にある flanneld サービス設定を変更し、新しい etcd ホストを追加します。

    FLANNEL_ETCD_ENDPOINTS=https://master-0.example.com:2379,https://master-1.example.com:2379,https://master-2.example.com:2379,https://etcd0.example.com:2379
  5. flanneld サービスを再起動します。

    # systemctl restart flanneld.service

4.3.2. 新規 etcd ホストの手動による追加

etcd をマスターノードで静的 Pod として実行しない場合、別の etcd ホストを追加する必要が生じる場合があります。

手順
現在の etcd クラスターの変更

etcd 証明書を作成するには、値を環境の値に置き換えて openssl コマンドを実行します。

  1. 環境変数を作成します。

    export NEW_ETCD_HOSTNAME="*etcd0.example.com*"
    export NEW_ETCD_IP="192.168.55.21"
    
    export CN=$NEW_ETCD_HOSTNAME
    export SAN="IP:${NEW_ETCD_IP}, DNS:${NEW_ETCD_HOSTNAME}"
    export PREFIX="/etc/etcd/generated_certs/etcd-$CN/"
    export OPENSSLCFG="/etc/etcd/ca/openssl.cnf"
    注記

    etcd_v3_ca_* として使用されるカスタムの openssl 拡張には、subjectAltName としての $SAN 環境変数が含まれます。詳細は、/etc/etcd/ca/openssl.cnf を参照してください。

  2. 設定および証明書を保存するディレクトリーを作成します。

    # mkdir -p ${PREFIX}
  3. サーバー証明書要求を作成し、これに署名します (server.csr および server.crt)。

    # openssl req -new -config ${OPENSSLCFG} \
        -keyout ${PREFIX}server.key  \
        -out ${PREFIX}server.csr \
        -reqexts etcd_v3_req -batch -nodes \
        -subj /CN=$CN
    
    # openssl ca -name etcd_ca -config ${OPENSSLCFG} \
        -out ${PREFIX}server.crt \
        -in ${PREFIX}server.csr \
        -extensions etcd_v3_ca_server -batch
  4. ピア証明書要求を作成し、これに署名します (peer.csr および peer.crt)。

    # openssl req -new -config ${OPENSSLCFG} \
        -keyout ${PREFIX}peer.key \
        -out ${PREFIX}peer.csr \
        -reqexts etcd_v3_req -batch -nodes \
        -subj /CN=$CN
    
    # openssl ca -name etcd_ca -config ${OPENSSLCFG} \
      -out ${PREFIX}peer.crt \
      -in ${PREFIX}peer.csr \
      -extensions etcd_v3_ca_peer -batch
  5. 後で変更できるように、現在の etcd 設定および ca.crt ファイルをサンプルとして現在のノードからコピーします。

    # cp /etc/etcd/etcd.conf ${PREFIX}
    # cp /etc/etcd/ca.crt ${PREFIX}
  6. 存続する etcd ホストから、新規ホストをクラスターに追加します。etcd メンバーをクラスターに追加するには、まず最初のメンバーの peerURLs 値のデフォルトの localhost ピアを調整する必要があります。

    1. member list コマンドを使用して最初のメンバーのメンバー ID を取得します。

      # etcdctl --cert-file=/etc/etcd/peer.crt \
          --key-file=/etc/etcd/peer.key \
          --ca-file=/etc/etcd/ca.crt \
          --peers="https://172.18.1.18:2379,https://172.18.9.202:2379,https://172.18.0.75:2379" \ 1
          member list
      1
      --peers パラメーター値でアクティブな etcd メンバーのみの URL を指定するようにしてください。
    2. etcd がクラスターピアについてリッスンする IP アドレスを取得します。

      $ ss -l4n | grep 2380
    3. 直前の手順で取得されたメンバー ID および IP アドレスを渡して、etcdctl member update コマンドを使用してpeerURLs の値を更新します。

      # etcdctl --cert-file=/etc/etcd/peer.crt \
          --key-file=/etc/etcd/peer.key \
          --ca-file=/etc/etcd/ca.crt \
          --peers="https://172.18.1.18:2379,https://172.18.9.202:2379,https://172.18.0.75:2379" \
          member update 511b7fb6cc0001 https://172.18.1.18:2380
    4. member list コマンドを再実行し、ピア URL に localhost が含まれなくなるようにします。
  7. 新規ホストを etcd クラスターに追加します。新規ホストはまだ設定されていないため、新規ホストを設定するまでステータスが unstarted のままであることに注意してください。

    警告

    各メンバーを追加し、1 回に 1 つずつメンバーをオンライン状態にします。各メンバーをクラスターに追加する際に、現在のピアの peerURL 一覧を調整する必要があります。peerURL 一覧はメンバーが追加されるたびに拡張します。etcdctl member add コマンドは、以下に説明されているように、メンバーを追加する際に etcd.conf ファイルで設定する必要のある値を出力します。

    # etcdctl -C https://${CURRENT_ETCD_HOST}:2379 \
      --ca-file=/etc/etcd/ca.crt     \
      --cert-file=/etc/etcd/peer.crt     \
      --key-file=/etc/etcd/peer.key member add ${NEW_ETCD_HOSTNAME} https://${NEW_ETCD_IP}:2380 1
    
    Added member named 10.3.9.222 with ID 4e1db163a21d7651 to cluster
    
    ETCD_NAME="<NEW_ETCD_HOSTNAME>"
    ETCD_INITIAL_CLUSTER="<NEW_ETCD_HOSTNAME>=https://<NEW_HOST_IP>:2380,<CLUSTERMEMBER1_NAME>=https:/<CLUSTERMEMBER2_IP>:2380,<CLUSTERMEMBER2_NAME>=https:/<CLUSTERMEMBER2_IP>:2380,<CLUSTERMEMBER3_NAME>=https:/<CLUSTERMEMBER3_IP>:2380"
    ETCD_INITIAL_CLUSTER_STATE="existing"
    1
    この行で、10.3.9.222 は etcd メンバーのラベルです。ホスト名、IP アドレスまたは単純な名前を指定できます。
  8. サンプル ${PREFIX}/etcd.conf ファイルを更新します。

    1. 以下の値を直前の手順で生成された値に置き換えます。

      • ETCD_NAME
      • ETCD_INITIAL_CLUSTER
      • ETCD_INITIAL_CLUSTER_STATE
    2. 以下の変数は、直前の手順で出力された新規ホストの IP に変更します。${NEW_ETCD_IP} は、値として使用できます。

      ETCD_LISTEN_PEER_URLS
      ETCD_LISTEN_CLIENT_URLS
      ETCD_INITIAL_ADVERTISE_PEER_URLS
      ETCD_ADVERTISE_CLIENT_URLS
    3. メンバーシステムを etcd ノードとして使用していた場合には、/etc/etcd/etcd.conf ファイルの現在の値を上書きする必要があります。
    4. ファイルで構文エラーや欠落している IP アドレスがないかを確認します。エラーや欠落がある場合には、etced サービスが失敗してしまう可能性があります。

      # vi ${PREFIX}/etcd.conf
  9. インストールファイルをホストするノードでは、/etc/ansible/hosts インベントリーファイルの [etcd] ホストグループを更新します。古い etcd ホストを削除し、新規ホストを追加します。
  10. 証明書、サンプル設定ファイル、および ca を含む tgz ファイルを作成し、これを新規ホストにコピーします。

    # tar -czvf /etc/etcd/generated_certs/${CN}.tgz -C ${PREFIX} .
    # scp /etc/etcd/generated_certs/${CN}.tgz ${CN}:/tmp/
新規 etcd ホストの変更
  1. iptables-services をインストールして etcd の必要なポートを開くために iptables ユーティリティーを指定します。

    # yum install -y iptables-services
  2. etcd の通信を許可する OS_FIREWALL_ALLOW ファイアウォールルールを作成します。

    • クライアントのポート 2379/tcp
    • ピア通信のポート 2380/tcp

      # systemctl enable iptables.service --now
      # iptables -N OS_FIREWALL_ALLOW
      # iptables -t filter -I INPUT -j OS_FIREWALL_ALLOW
      # iptables -A OS_FIREWALL_ALLOW -p tcp -m state --state NEW -m tcp --dport 2379 -j ACCEPT
      # iptables -A OS_FIREWALL_ALLOW -p tcp -m state --state NEW -m tcp --dport 2380 -j ACCEPT
      # iptables-save | tee /etc/sysconfig/iptables
      注記

      この例では、新規チェーン OS_FIREWALL_ALLOW が作成されます。これは、OpenShift Container Platform インストーラーがファイアウォールルールに使用する標準の名前になります。

      警告

      環境が IaaS 環境でホストされている場合には、インスタンスがこれらのポートに入ってくるトラフィックを許可できるように、セキュリティーグループを変更します。

  3. etcd をインストールします。

    # yum install -y etcd

    バージョン etcd-2.3.7-4.el7.x86_64 以降がインストールされていることを確認します。

  4. etcd Pod 定義を削除して、etcd サービスが実行されていない状態にします。

    # mkdir -p /etc/origin/node/pods-stopped
    # mv /etc/origin/node/pods/* /etc/origin/node/pods-stopped/
  5. etcd 設定およびデータを削除します。

    # rm -Rf /etc/etcd/*
    # rm -Rf /var/lib/etcd/*
  6. 証明書および設定ファイルを展開します。

    # tar xzvf /tmp/etcd0.example.com.tgz -C /etc/etcd/
  7. 新規ホストで etcd を起動します。

    # systemctl enable etcd --now
  8. ホストがクラスターの一部であることと現在のクラスターの正常性を確認します。

    • v2 etcd api を使用する場合は、以下のコマンドを実行します。

      # etcdctl --cert-file=/etc/etcd/peer.crt \
                --key-file=/etc/etcd/peer.key \
                --ca-file=/etc/etcd/ca.crt \
                --peers="https://*master-0.example.com*:2379,\
                https://*master-1.example.com*:2379,\
                https://*master-2.example.com*:2379,\
                https://*etcd0.example.com*:2379"\
                cluster-health
      member 5ee217d19001 is healthy: got healthy result from https://192.168.55.12:2379
      member 2a529ba1840722c0 is healthy: got healthy result from https://192.168.55.8:2379
      member 8b8904727bf526a5 is healthy: got healthy result from https://192.168.55.21:2379
      member ed4f0efd277d7599 is healthy: got healthy result from https://192.168.55.13:2379
      cluster is healthy
    • v3 etcd api を使用する場合は、以下のコマンドを実行します。

      # ETCDCTL_API=3 etcdctl --cert="/etc/etcd/peer.crt" \
                --key=/etc/etcd/peer.key \
                --cacert="/etc/etcd/ca.crt" \
                --endpoints="https://*master-0.example.com*:2379,\
                  https://*master-1.example.com*:2379,\
                  https://*master-2.example.com*:2379,\
                  https://*etcd0.example.com*:2379"\
                  endpoint health
      https://master-0.example.com:2379 is healthy: successfully committed proposal: took = 5.011358ms
      https://master-1.example.com:2379 is healthy: successfully committed proposal: took = 1.305173ms
      https://master-2.example.com:2379 is healthy: successfully committed proposal: took = 1.388772ms
      https://etcd0.example.com:2379 is healthy: successfully committed proposal: took = 1.498829ms
各 OpenShift Container Platform マスターの変更
  1. すべてのマスターの /etc/origin/master/master-config.yaml ファイルの etcClientInfo セクションでマスター設定を変更します。新規 etcd ホストを、データを保存するために OpenShift Container Platform が使用する etcd サーバーの一覧に追加し、失敗したすべての etcd ホストを削除します。

    etcdClientInfo:
      ca: master.etcd-ca.crt
      certFile: master.etcd-client.crt
      keyFile: master.etcd-client.key
      urls:
        - https://master-0.example.com:2379
        - https://master-1.example.com:2379
        - https://master-2.example.com:2379
        - https://etcd0.example.com:2379
  2. マスター API サービスを再起動します。

    • 全マスターのインストールに対しては、以下を実行します。

      # master-restart api
      # master-restart controllers
      警告

      etcd ノードの数は奇数でなければなりません。そのため、2 つ以上のホストを追加する必要があります。

  3. Flannel を使用する場合、新規 etcd ホストを組み込むために、すべての OpenShift Container Platform ホストの /etc/sysconfig/flanneld にある flanneld サービス設定を変更します。

    FLANNEL_ETCD_ENDPOINTS=https://master-0.example.com:2379,https://master-1.example.com:2379,https://master-2.example.com:2379,https://etcd0.example.com:2379
  4. flanneld サービスを再起動します。

    # systemctl restart flanneld.service