第7章 ホストの既存クラスターへの追加


7.1. ホストの追加

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 オプションを使用してそのファイルを指定する必要があります。

重要

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

手順

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

    # yum update atomic-openshift-utils
  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. scaleup.yml Playbook を実行します。インベントリーファイルがデフォルトの /etc/ansible/hosts 以外の場所にある場合は、-i オプションで場所を指定します。

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

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

      # ansible-playbook [-i /path/to/file] \
          /usr/share/ansible/openshift-ansible/playbooks/openshift-master/scaleup.yml
  5. ノードラベルを logging-infra-fluentd: "true" に設定します。

    # oc label node/new-node.example.com logging-infra-fluentd: "true"
  6. Playbook の実行後に、インストールの検証を行います。
  7. [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]

7.2. etcd ホストの既存クラスターへの追加

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

etcd ホストを既存クラスターに追加するには、以下を実行します。

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

    $ yum update atomic-openshift-utils
  2. /etc/ansible/hosts ファイルを編集し、new_<host_type>[OSEv3:children] グループに、ホストを new_<host_type> グループに追加します。

    たとえば、新規 etcd を追加するには、new_etcd を追加します。

    [OSEv3:children]
    masters
    nodes
    etcd
    new_etcd
    
    [etcd]
    etcd1.example.com
    etcd2.example.com
    
    [new_etcd]
    etcd3.example.com
  3. etcd scaleup.yml Playbook を実行します。インベントリーファイルがデフォルトの /etc/ansible/hosts 以外の場所にある場合は、-i オプションで場所を指定します。

    $ ansible-playbook [-i /path/to/file] \
      /usr/share/ansible/openshift-ansible/playbooks/openshift-etcd/scaleup.yml
  4. Playbook が正常に完了したら、インストールの検証を行います。

7.3. 共存する etcd での既存のマスターの置き換え

マシンを別のデータセンターに移行し、割り当てられているネットワークと IP が変更される場合には、以下の手順を実行します。

  1. プライマリー「etcd」と「マスター」ノードをバックアップします。

    重要

    etcd バックアップ」の説明にあるように、/etc/etcd/ ディレクトリーがバックアップされていることを確認します。

  2. 置き換えるマスターの数だけ、新規マシンをプロビジョニングします。
  3. クラスターを追加または拡張します。たとえば、etcd が共存するマスターを 3 つ追加する場合には、マスターノード 3 つに拡張します。
重要

OpenShift Container Platform バージョン 3.11 の初期リリースについては、scaleup.yml Playbook は etcd をスケールアップしません。これについては、BZ#1628201 にて今後のリリースで修正されます。

  1. マスターを追加します。このプロセスのステップ 3 で、[new_masters][new_nodes] に新規データセンターのホストを追加して、マスターの scaleup.yml Playbook を実行します。
  2. 同じホストを「etcd」セクションに配置して、etcd scaleup.yml Playbook を実行します。
  3. ホストが追加されたことを確認します。

    # oc get nodes
  4. マスターホストの IP が追加されたことを確認します。

    # oc get ep kubernetes
  5. etcd が追加されたことを確認します。ETCDCTL_API の値は、使用するバージョンにより異なります。

    # source /etc/etcd/etcd.conf
    # ETCDCTL_API=2 etcdctl --cert-file=$ETCD_PEER_CERT_FILE --key-file=$ETCD_PEER_KEY_FILE \
      --ca-file=/etc/etcd/ca.crt --endpoints=$ETCD_LISTEN_CLIENT_URLS member list
  6. /etc/origin/master ディレクトリーから、インベントリーファイルの最初に記載されている新規マスターホストに、/etc/origin/master/ca.serial.txt をコピーします。デフォルトでは、これは /etc/ansible/hosts です。

    1. etcd ホストを削除します。
  7. /etc/etcd/ca ディレクトリーを、インベントリーファイルの最初に記載されている新規 etcd ホストにコピーします。デフォルトでは、これは /etc/ansible/hosts です。
  8. master-config.yaml ファイルから以前の etcd クライアントを削除します。

    # grep etcdClientInfo -A 11 /etc/origin/master/master-config.yaml
  9. マスターを再起動します。

    # master-restart api
    # master-restart controllers
  10. クラスターから以前の etcd メンバーを削除します。ETCDCTL_API の値は、使用するバージョンにより異なります。

    # source /etc/etcd/etcd.conf
    # ETCDCTL_API=2 etcdctl --cert-file=$ETCD_PEER_CERT_FILE --key-file=$ETCD_PEER_KEY_FILE \
      --ca-file=/etc/etcd/ca.crt --endpoints=$ETCD_LISTEN_CLIENT_URLS member list
  11. 上記のコマンドの出力から ID を取得して、この ID で以前のメンバーを削除します。

    # etcdctl --cert-file=$ETCD_PEER_CERT_FILE --key-file=$ETCD_PEER_KEY_FILE \
      --ca-file=/etc/etcd/ca.crt --endpoints=$ETCD_LISTEN_CLIENT_URL member remove 1609b5a3a078c227
  12. etcd Pod 定義を削除し、古い etcd ホストで etcd サービスを停止します。

    # mkdir -p /etc/origin/node/pods-stopped
    # mv /etc/origin/node/pods/* /etc/origin/node/pods-stopped/
    1. 定義ファイルを静的 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/:
    2. ネイティブのインストールプロセス時に、デフォルトでロードバランサーとしてインストールされていたマスターノードを、HA プロキシー設定から削除します。
    3. マシンの使用を停止します。
  13. etcd Pod 定義を削除し、ホストを再起動して、削除されるマスターでノードサービスを停止します。

    # mkdir -p /etc/origin/node/pods-stopped
    # mv /etc/origin/node/pods/* /etc/origin/node/pods-stopped/
    # reboot
  14. ノードリソースを削除します。

    # oc delete node

7.4. ノードの移行

ノード上のサービスの実行方法やスケーリング方法、慣れた方法により、ノードを個別での移行や、グループ (2、5、10 ずつなど) 単位での移行が可能です。

  1. 移行するノードについては、新規データセンターのノードで使用するために新規の仮想マシンをプロビジョニングします。
  2. 新規ノードを追加するには、インフラストラクチャーを拡張します。新規ノードのラベルが適切に設定されており、新規 API サーバーがロードバランサーに追加され、トラフィックを適切に送信していることを確認します。
  3. 評価および縮小を実行します。

    1. 現在のノード (古いデータセンター内にある) に「スケジュール対象外」のマークを付けます。
    2. ノードの退避を実行し、ノード上の Pod が他のノードにスケジュールされるようにします。
    3. 退避したサービスが新規ノードで実行されていることを確認します。
  4. ノードを削除します。

    1. ノードが空であり、実行中のプロセスがないことを確認します。
    2. サービスを停止するか、またはノードを削除します。
Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.