第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
オプションを使用してそのファイルを指定する必要があります。
推奨される最大ノード数については、「クラスターの制限」のセクションを参照してください。
手順
atomic-openshift-utils パッケージを更新して最新の Playbook を取得します。
# yum update atomic-openshift-utils
/etc/ansible/hosts ファイルを編集し、 new_<host_type> を [OSEv3:children] セクションに追加します。
たとえば、新規ノードホストを追加するには、new_nodes を追加します。
[OSEv3:children] masters nodes new_nodes
新規マスターホストを追加するには、new_masters を追加します。
[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 をどこにも配置できなくなります。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
ノードラベルを
logging-infra-fluentd: "true"
に設定します。# oc label node/new-node.example.com logging-infra-fluentd: "true"
- Playbook の実行後に、インストールの検証を行います。
[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 ホストを既存クラスターに追加するには、以下を実行します。
atomic-openshift-utils パッケージを更新して最新の Playbook を取得します。
$ yum update atomic-openshift-utils
/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
etcd scaleup.yml Playbook を実行します。インベントリーファイルがデフォルトの /etc/ansible/hosts 以外の場所にある場合は、
-i
オプションで場所を指定します。$ ansible-playbook [-i /path/to/file] \ /usr/share/ansible/openshift-ansible/playbooks/openshift-etcd/scaleup.yml
- Playbook が正常に完了したら、インストールの検証を行います。
7.3. 共存する etcd での既存のマスターの置き換え
マシンを別のデータセンターに移行し、割り当てられているネットワークと IP が変更される場合には、以下の手順を実行します。
プライマリー「etcd」と「マスター」ノードをバックアップします。
重要「etcd バックアップ」の説明にあるように、/etc/etcd/ ディレクトリーがバックアップされていることを確認します。
- 置き換えるマスターの数だけ、新規マシンをプロビジョニングします。
- クラスターを追加または拡張します。たとえば、etcd が共存するマスターを 3 つ追加する場合には、マスターノード 3 つに拡張します。
OpenShift Container Platform バージョン 3.11 の初期リリースについては、scaleup.yml Playbook は etcd をスケールアップしません。これについては、BZ#1628201 にて今後のリリースで修正されます。
-
マスターを追加します。このプロセスのステップ 3 で、
[new_masters]
と[new_nodes]
に新規データセンターのホストを追加して、マスターの scaleup.yml Playbook を実行します。 - 同じホストを「etcd」セクションに配置して、etcd scaleup.yml Playbook を実行します。
ホストが追加されたことを確認します。
# oc get nodes
マスターホストの IP が追加されたことを確認します。
# oc get ep kubernetes
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
/etc/origin/master ディレクトリーから、インベントリーファイルの最初に記載されている新規マスターホストに、/etc/origin/master/ca.serial.txt をコピーします。デフォルトでは、これは /etc/ansible/hosts です。
- etcd ホストを削除します。
- /etc/etcd/ca ディレクトリーを、インベントリーファイルの最初に記載されている新規 etcd ホストにコピーします。デフォルトでは、これは /etc/ansible/hosts です。
master-config.yaml ファイルから以前の etcd クライアントを削除します。
# grep etcdClientInfo -A 11 /etc/origin/master/master-config.yaml
マスターを再起動します。
# master-restart api # master-restart controllers
クラスターから以前の 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
上記のコマンドの出力から 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
etcd Pod 定義を削除し、古い etcd ホストで etcd サービスを停止します。
# mkdir -p /etc/origin/node/pods-stopped # mv /etc/origin/node/pods/* /etc/origin/node/pods-stopped/
定義ファイルを静的 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/:
- ネイティブのインストールプロセス時に、デフォルトでロードバランサーとしてインストールされていたマスターノードを、HA プロキシー設定から削除します。
- マシンの使用を停止します。
etcd Pod 定義を削除し、ホストを再起動して、削除されるマスターでノードサービスを停止します。
# mkdir -p /etc/origin/node/pods-stopped # mv /etc/origin/node/pods/* /etc/origin/node/pods-stopped/ # reboot
ノードリソースを削除します。
# oc delete node
7.4. ノードの移行
ノード上のサービスの実行方法やスケーリング方法、慣れた方法により、ノードを個別での移行や、グループ (2、5、10 ずつなど) 単位での移行が可能です。
- 移行するノードについては、新規データセンターのノードで使用するために新規の仮想マシンをプロビジョニングします。
- 新規ノードを追加するには、インフラストラクチャーを拡張します。新規ノードのラベルが適切に設定されており、新規 API サーバーがロードバランサーに追加され、トラフィックを適切に送信していることを確認します。
評価および縮小を実行します。
ノードを削除します。
- ノードが空であり、実行中のプロセスがないことを確認します。
- サービスを停止するか、またはノードを削除します。