ノードの動的管理
本コンテンツは、MAD Workshop Ops Track の内容をベースに、一部変更しています。
演習の概要
Kubernetes Node はコンテナがオーケストレーションされ、Pod として実行される場所です。OpenShift 4は、Operator を使った自動化に重点を置いている点で、OpenShift 3とは根本的に異なります。Node に関しては、Node の作成と破壊を含め、クラスタサイズの状態を維持することに重点を置いた Operator とコントローラのセットがあります。
この演習では、クラスタサイズを保つために利用される Machineset と Machine について学びます。
オペレーションはコマンドラインからですが、Web コンソールから、Node の増減を見てみてください。
MachineSets と Machines
アプリケーション管理の演習で見たように、ReplicaSet/ReplicationController とそれが作成する Pod の間には基本的な関係があります。同様に、MachineSet と`Machine` の間にも関係があります。
MachineSet は、Machine オブジェクトのセットに対して希望する状態を定義します。IPIインストールを使用する場合、Operator の仕事は、各 Machine の基礎となるインスタンスが実際に存在することを確認し、最終的に各 Machine が Node になることを確認することです。
以下を実行します。
oc get machineset -n openshift-machine-api以下のように表示されます。
NAME DESIRED CURRENT READY AVAILABLE AGE cluster-8trtb-rlgsx-worker-us-east-2b 3 3 3 3 19h
OpenShiftがインストールされると、インストーラはクラウドプロバイダーに問い合わせて、利用可能なAZを得ます(この環境はAWS上にあるため)。そして、最終的に各AZの MachineSet を作成し、希望する Machine の数に達するまで、それらのセットを順番にスケーリングします。
デフォルトのインストールには3つのWorkerが一つのAZにいることを指しています。
（つまり、本番環境としてはやや冗長性に欠ける設計です。）
oc get machine -n openshift-machine-api以下のように表示されます。
NAME PHASE TYPE REGION ZONE AGE cluster-8trtb-rlgsx-master-0 Running c6in.2xlarge us-east-2 us-east-2b 19h cluster-8trtb-rlgsx-worker-us-east-2b-6cms8 Running m5a.4xlarge us-east-2 us-east-2b 19h cluster-8trtb-rlgsx-worker-us-east-2b-sx78t Running m5a.4xlarge us-east-2 us-east-2b 19h cluster-8trtb-rlgsx-worker-us-east-2b-w64fw Running m5a.4xlarge us-east-2 us-east-2b 19h
各 Machine には対応する INSTANCE があります。このIDに見覚えはないでしょうか?これはAWS EC2のインスタンスIDです。また、OpenShiftのMasterの Machine も表示されています。これらはある程度ステートフルであり、管理は別のOperatorが別のプロセスを介して処理するため、MachineSet の一部ではありません
現在、Masterの Machines は保護されていません。クラスタを壊す可能性があるので、誤って、または意図的に削除しないでください。
最後に以下を実行します。
oc get nodes以下のように表示されます。
NAME STATUS ROLES AGE VERSION ip-10-0-148-190.us-east-2.compute.internal Ready control-plane,master 4h25m v1.25.7+eab9cc9 ip-10-0-190-107.us-east-2.compute.internal Ready worker 4h9m v1.25.7+eab9cc9 ip-10-0-199-105.us-east-2.compute.internal Ready worker 4h9m v1.25.7+eab9cc9 ip-10-0-210-82.us-east-2.compute.internal Ready worker 4h9m v1.25.7+eab9cc9
各 Machine は、それぞれ Node に対応しています。
oc describe で様々な Machine オブジェクト、Node オブジェクトを調べれば、どれがどれと相関しているのかが分かるでしょう。
クラスタのスケーリング
Operator による管理と、それを使った Machine と Node の管理のおかげで、OpenShift 4でのクラスタのスケーリングは非常に簡単に行えます。
もう一度、MachineSet のリストを見てみましょう。
oc get machineset -n openshift-machine-apiそのリストの中で。MachineSet`のひとつを oc scaleコマンドでスケールしてみましょう。あなたの `MachineSet の名前はラボガイドの名前とは異なる可能性があるので、特に注意してください。
CLUSTERNAME=$(oc get infrastructures.config.openshift.io cluster -o jsonpath='{.status.infrastructureName}')
ZONENAME=$(oc get nodes -L topology.kubernetes.io/zone --no-headers | awk '{print $NF}' | tail -1)
oc scale machineset ${CLUSTERNAME}-worker-${ZONENAME} -n openshift-machine-api --replicas=4MachineSet が正常にスケーリングされたというメモが表示されているはずです。次に、Machine のリストを見てみましょう。
oc get machines -n openshift-machine-apiおそらく、STATE が Pending となっている Machine の新しいエントリがすでに存在していると思います。
cluster-zbwlg-cbgq7-worker-us-east-2a-s7l7s Provisioning m5a.4xlarge us-east-2 us-east-2a 7s
しばらくすると、対応するEC2インスタンスIDが表示され、以下のように表示されます。
cluster-f4a3-lpxbs-worker-us-east-2c-h7gdt i-0b9208ec47f0e206b running m5.2xlarge us-east-2 us-east-2c 47s
この時点では、バックグラウンドでは自動的にbootstrap 処理が行われています。数分後(最大で5分程度)の出力を見てみましょう。また Web コンソールを除いて、ノードの作成状況なども見ても良いでしょう。
oc get nodesage が非常に若いノードが見つかるはずです。
ip-10-0-210-82.us-east-2.compute.internal Ready worker 4h37m v1.25.7+eab9cc9
Machine が準備され、Node として追加されるまでには数分かかることがあります。
続ける前に、先程スケールアップした MachineSet を2から1にスケールダウンしてください。
${CLUSTERNAME}と${ZONENAME}変数が、数ステップ前のスケールアップ時に設定されていることを確認してください。
oc scale machineset ${CLUSTERNAME}-worker-${ZONENAME} -n openshift-machine-api --replicas=3