Red Hatの福岡オフィスでソリューションアーキテクトをしている田中司恩です。 この記事はOpenShift Advent Calendar 2019 - Qiita 9日目のエントリになります。*1
今回と次回、2回に分けてOCP4/UPIインストールにおけるWorkerノードの追加について説明します。 OCP4/UPIインストールについては下記記事を参照ください。
本記事の章立てはこのようになります。
- UPIにおけるWorkerノード追加の概要
- RHCOSノードの追加
- Workerノードの手動削除
UPIにおけるWorkerノード追加の概要
UPIインストールではインストールコンフィグ（install-config.yaml）にWorkerノードの台数を0と記載してインストールを行います。
インストール時に起動したWorkerノードの台数が、初期クラスター構築時のWorkerノードの台数となります。
また、クラスター構築時にWorkerノードに使用できるOSはRHCOSのみです。
それに対し、IPIで構築したクラスターにおいてノードは、Machineというリソースとしてノードが管理されます。
また、0個以上のMachineをグループ化したMachineSetにより、管理者はレプリカ数の増減によって容易にノードの追加/削除が行えます。
しかしながら、UPIで作成したクラスターにはMachine/MachineSetはありませんので同じ方法は使えません*2。 ですので、UPIクラスターにおいては手動作業でのWorkerノードの追加作業が必要となります。 OCP4では追加のWorkerノードとして、RHCOSとRHELノードが選択できます。 下記はRHCOSとRHELノードを使った場合の簡単な比較表です。
| RHCOSノード | RHELノード | |
|---|---|---|
| OSのインストール作業 | 不要 | 必要 |
| OSの管理 | 不要。OTAでアップデート。 | 必要。個別にパッチ適用必要。 |
| Masterノードでの利用 | 可能 | 不可 |
| OS用のサブスクリプション | 不要 | 不要 |
続いてRHCOSノードの追加方法について説明します。
RHCOSノードの追加
[図1]
RHCOSのノードの追加方法について、実はドキュメントに該当する記載がありません*3。その代わり、下記のナレッジに関連する記載があります。
要約すると下記の通りです。
- Workerノードはマスターノードと同じ手順で追加できる（vSphere/ベアメタルのドキュメントに説明がある）
- 新規のインストールと同様に
worker.ignを使用してインストールを行う。マシンの起動時に既存のOpenShiftクラスターのMachine Config Operator(MCO)と同期してクラスターに追加される- （※注意※）vSphere/ベアメタルのインストールドキュメントに記載されているように、ノードのCSR（証明書署名要求）を手動で承認する必要がある（場合がある）。
ナレッジにも「ドキュメントに書いてる通り」という表現がありますが、探してみてもRHCOSノードの追加を指している箇所はありません。現時点ではいくつかの情報を組み合わせるとなんとか上記のことが理解できます。 しかしながらやってみると手順は非常に簡単で、まとめると下記のようになります。
- 新しいWorkerノードマシンを用意する
- 新規クラスタ構築時と同様に、RHCOSのインストールを行う（またはPXE boot）。
- 起動処理が終わりクラスターと同期するとCSRの承認待ちになる
- CLIでCSRの承認を行う
- クラスターにノードが追加される
実際にテストしてみます。構成はいつものUPI検証環境で、3ノードクラスターにRHCOSのWorkerノード:worker-2を追加する、というシナリオで実行します。*4
検証環境の構成図は下記の通りです。
[図2]
ここではWorkerノード:worker-2の起動処理が終わった後からの手順を紹介します。
今回の手順そのものではないですが、CSRの承認に関連するドキュメントは下記にあります。
追加するWorkerノードを起動して、しばらく待ってからCSRの確認を行います
$ oc get csr NAME AGE REQUESTOR CONDITION csr-9ffrp 3m7s system:serviceaccount:openshift-machine-config-operator:node-bootstrapper Pending
Pendingのものが出てきました。
この時点ではクラスターからノードはまだ見えません
$ oc get nodes NAME STATUS ROLES AGE VERSION master-0 Ready master,worker 8d v1.14.6+31a56cf75 master-1 Ready master,worker 8d v1.14.6+31a56cf75 master-2 Ready master,worker 8d v1.14.6+31a56cf75
CSRの承認を行います
$ oc get csr -o name | xargs oc adm certificate approve certificatesigningrequest.certificates.k8s.io/csr-9mfxc approved
ノードの確認を行います
$ oc get nodes NAME STATUS ROLES AGE VERSION master-0 Ready master,worker 8d v1.14.6+31a56cf75 master-1 Ready master,worker 8d v1.14.6+31a56cf75 master-2 Ready master,worker 8d v1.14.6+31a56cf75 worker-2 NotReady worker 16s v1.14.6+31a56cf75
ノードは追加されているのですが、実は同時にCSRが追加されています*5。 再度CSRの確認をします。
$ oc get csr NAME AGE REQUESTOR CONDITION csr-9mfxc 3m51s system:serviceaccount:openshift-machine-config-operator:node-bootstrapper Approved,Issued csr-pvfms 34s system:node:worker-2 Pending
追加でPendingのものが出てきましたので、もう一度CSRの承認をします
$ oc get csr -o name | xargs oc adm certificate approve certificatesigningrequest.certificates.k8s.io/csr-9mfxc approved certificatesigningrequest.certificates.k8s.io/csr-pvfms approved $ oc get csr NAME AGE REQUESTOR CONDITION csr-9mfxc 7m45s system:serviceaccount:openshift-machine-config-operator:node-bootstrapper Approved,Issued csr-pvfms 4m28s system:node:worker-2 Approved,Issued
必要なCSRが承認され、無事にRHCOSのWorkerノード:worker-2がクラスターに追加されました。
RHCOSノードの追加については以上となります。
Workerノードの手動削除
Workerノードの追加ができたので、今度は手動での削除を行います。 手動削除に関するドキュメントは下記です。
（参考）ドキュメント上はRHCOSを対象としていますが、RHLEノードも同様の手順で削除が可能です
削除手順
oc adm cordonコマンドを実行して、ノードにスケジュール対象外 (unschedulable) のマークを付けます。<node_name>にはRHCOS コンピュートマシンのノード名を指定します。
$ oc adm cordon <node_name>
次に、ノードからすべての Pod をドレイン (解放) します。<node_name>には分離した RHCOS コンピュートマシンのノード名を指定します。
$ oc adm drain <node_name> --force --delete-local-data --ignore-daemonsets
最後にノードを削除します。<node_name>にはドレイン (解放) した RHCOS コンピュートマシンのノード名を指定します。
$ oc delete nodes <node_name>
以上の手順でWorkerノードの手動削除が行えます。
実行例
Workerノード:worker-2を削除する例です
$ oc get nodes NAME STATUS ROLES AGE VERSION master-0 Ready master,worker 8d v1.14.6+31a56cf75 master-1 Ready master,worker 8d v1.14.6+31a56cf75 master-2 Ready master,worker 8d v1.14.6+31a56cf75 worker-2 Ready worker 21m v1.14.6+31a56cf75 $ oc adm cordon worker-2 node/worker-2 cordoned $ oc adm drain worker-2 --force --delete-local-data --ignore-daemonsets node/worker-2 already cordoned WARNING: ignoring DaemonSet-managed Pods: openshift-cluster-node-tuning-operator/tuned-vtn7n, openshift-dns/dns-default-thxhj, openshift-image-registry/node-ca-v6qzq, openshift-machine-config-operator/machine-config-daemon-7m2k2, openshift-monitoring/node-exporter-wqqp9, openshift-multus/multus-wgwvx, openshift-sdn/ovs-c58jd, openshift-sdn/sdn-wcv8s node/worker-2 drained $ oc get nodes NAME STATUS ROLES AGE VERSION master-0 Ready master,worker 8d v1.14.6+31a56cf75 master-1 Ready master,worker 8d v1.14.6+31a56cf75 master-2 Ready master,worker 8d v1.14.6+31a56cf75 worker-2 Ready,SchedulingDisabled worker 22m v1.14.6+31a56cf75 $ oc delete nodes worker-2 node "worker-2" deleted $ oc get nodes NAME STATUS ROLES AGE VERSION master-0 Ready master,worker 8d v1.14.6+31a56cf75 master-1 Ready master,worker 8d v1.14.6+31a56cf75 master-2 Ready master,worker 8d v1.14.6+31a56cf75
Workerノードの削除については以上です。
まとめ
OCP4/UPIクラスターにRHCOSノードを追加、削除する方法をご紹介しました。特に複雑な手順は無いので、UPI環境でも自由にWorkerノードの追加/削除が行えます。IPIと違い自動的なノードの追加/削除の機能はありませんが、UPIでは自分で工夫して環境に合わせたカスタマイズを行うことができる点がメリットです。次回は引き続き、RHELノードの追加方法について説明します。
Let's get Big Ideas!
