6.2. ノードの使用
管理者は、複数のタスクを実行して、クラスターを効率化できます。
6.2.1. ノード上の Pod を退避させる方法
Pod を退避させると、所定のノードからすべての Pod または選択した Pod を移行できます。
退避させることができるのは、レプリケーションコントローラーが管理している Pod のみです。レプリケーションコントローラーは、他のノードに新しい Pod を作成し、指定されたノードから既存の Pod を削除します。
ベア Pod、つまりレプリケーションコントローラーが管理していない Pod はデフォルトで影響を受けません。Pod セレクターを指定すると Pod のサブセットを退避できます。Pod セレクターはラベルに基づくので、指定したラベルを持つすべての Pod を退避できます。
手順
Pod の退避を実行する前に、ノードをスケジュール対象外としてマークします。
ノードをスケジューリング対象外としてマークします。
oc adm cordon <node1>
$ oc adm cordon <node1>
Copy to Clipboard Copied! 出力例
node/<node1> cordoned
node/<node1> cordoned
Copy to Clipboard Copied! ノードのステータスが
Ready,SchedulingDisabled
であることを確認します。oc get node <node1>
$ oc get node <node1>
Copy to Clipboard Copied! 出力例
NAME STATUS ROLES AGE VERSION <node1> Ready,SchedulingDisabled worker 1d v1.29.4
NAME STATUS ROLES AGE VERSION <node1> Ready,SchedulingDisabled worker 1d v1.29.4
Copy to Clipboard Copied!
以下の方法のいずれかを使用して Pod を退避します。
1 つ以上のノードで、すべてまたは選択した Pod を退避します。
oc adm drain <node1> <node2> [--pod-selector=<pod_selector>]
$ oc adm drain <node1> <node2> [--pod-selector=<pod_selector>]
Copy to Clipboard Copied! --force
オプションを使用してベア Pod の削除を強制的に実行します。true
に設定されると、Pod がレプリケーションコントローラー、レプリカセット、ジョブ、デーモンセット、またはステートフルセットで管理されていない場合でも削除が続行されます。oc adm drain <node1> <node2> --force=true
$ oc adm drain <node1> <node2> --force=true
Copy to Clipboard Copied! --grace-period
を使用して、各 Pod を正常に終了するための期間 (秒単位) を設定します。負の値の場合には、Pod に指定されるデフォルト値が使用されます。oc adm drain <node1> <node2> --grace-period=-1
$ oc adm drain <node1> <node2> --grace-period=-1
Copy to Clipboard Copied! true
に設定された--ignore-daemonsets
フラグを使用してデーモンセットが管理する Pod を無視します。oc adm drain <node1> <node2> --ignore-daemonsets=true
$ oc adm drain <node1> <node2> --ignore-daemonsets=true
Copy to Clipboard Copied! --timeout
を使用して、中止する前の待機期間を設定します。値0
は無限の時間を設定します。oc adm drain <node1> <node2> --timeout=5s
$ oc adm drain <node1> <node2> --timeout=5s
Copy to Clipboard Copied! --delete-emptydir-data
フラグをtrue
に設定して、emptyDir
ボリュームを使用する Pod がある場合にも Pod を削除します。ローカルデータはノードがドレイン (解放) される場合に削除されます。oc adm drain <node1> <node2> --delete-emptydir-data=true
$ oc adm drain <node1> <node2> --delete-emptydir-data=true
Copy to Clipboard Copied! true
に設定された--dry-run
オプションを使用して、実際に退避を実行せずに移行するオブジェクトをリスト表示します。oc adm drain <node1> <node2> --dry-run=true
$ oc adm drain <node1> <node2> --dry-run=true
Copy to Clipboard Copied! 特定のノード名 (例:
<node1> <node2>
) を指定する代わりに、--selector=<node_selector>
オプションを使用し、選択したノードで Pod を退避することができます。
完了したら、ノードにスケジュール対象のマークを付けます。
oc adm uncordon <node1>
$ oc adm uncordon <node1>
Copy to Clipboard Copied!
6.2.2. ノードでラベルを更新する方法について
ノード上の任意のラベルを更新できます。
ノードラベルは、ノードがマシンによってバックアップされている場合でも、ノードが削除されると永続しません。
MachineSet
への変更は、コンピュートマシンセットが所有する既存のマシンには適用されません。たとえば、編集されたか、既存の MachineSet
に追加されたラベルは、マシンセットに関連付けられた既存マシンおよびノードには伝播しません。
以下のコマンドは、ノードのラベルを追加または更新します。
oc label node <node> <key_1>=<value_1> ... <key_n>=<value_n>
$ oc label node <node> <key_1>=<value_1> ... <key_n>=<value_n>
Copy to Clipboard Copied! 以下に例を示します。
oc label nodes webconsole-7f7f6 unhealthy=true
$ oc label nodes webconsole-7f7f6 unhealthy=true
Copy to Clipboard Copied! ヒント以下の YAML を適用してラベルを適用することもできます。
kind: Node apiVersion: v1 metadata: name: webconsole-7f7f6 labels: unhealthy: 'true' #...
kind: Node apiVersion: v1 metadata: name: webconsole-7f7f6 labels: unhealthy: 'true' #...
Copy to Clipboard Copied! 以下のコマンドは、namespace 内のすべての Pod を更新します。
oc label pods --all <key_1>=<value_1>
$ oc label pods --all <key_1>=<value_1>
Copy to Clipboard Copied! 以下に例を示します。
oc label pods --all status=unhealthy
$ oc label pods --all status=unhealthy
Copy to Clipboard Copied!
OpenShift Container Platform 4.12 以降の新しくインストールされたクラスターには、コントロールプレーンノードに node-role.kubernetes.io/control-plane
ラベルと node-role.kubernetes.io/master
ラベルの両方がデフォルトで含まれています。
OpenShift Container Platform バージョン 4.12 より前では、node-role.kubernetes.io/control-plane
ラベルはデフォルトでは追加されません。したがって、以前のバージョンからアップグレードしたクラスターのコントロールプレーンノードに、node-role.kubernetes.io/control-plane
ラベルを手動で追加する必要があります。
6.2.3. ノードをスケジュール対象外 (Unschedulable) またはスケジュール対象 (Schedulable) としてマークする方法
デフォルトで、Ready
ステータスの正常なノードはスケジュール対象としてマークされます。つまり、新規 Pod をこのノードに配置できます。手動でノードをスケジュール対象外としてマークすると、新規 Pod のノードでのスケジュールがブロックされます。ノード上の既存 Pod には影響がありません。
以下のコマンドは、ノードをスケジュール対象外としてマークします。
出力例
oc adm cordon <node>
$ oc adm cordon <node>
Copy to Clipboard Copied! 以下に例を示します。
oc adm cordon node1.example.com
$ oc adm cordon node1.example.com
Copy to Clipboard Copied! 出力例
node/node1.example.com cordoned NAME LABELS STATUS node1.example.com kubernetes.io/hostname=node1.example.com Ready,SchedulingDisabled
node/node1.example.com cordoned NAME LABELS STATUS node1.example.com kubernetes.io/hostname=node1.example.com Ready,SchedulingDisabled
Copy to Clipboard Copied! 以下のコマンドは、現時点でスケジュール対象外のノードをスケジュール対象としてマークします。
oc adm uncordon <node1>
$ oc adm uncordon <node1>
Copy to Clipboard Copied! または、特定のノード名 (たとえば
<node>
) を指定する代わりに、--selector=<node_selector>
オプションを使用して選択したノードをスケジュール対象またはスケジュール対象外としてマークすることができます。
6.2.4. アプリケーション Pod をドレインせずにノードを再起動した場合の単一ノード OpenShift クラスターでのエラーの処理
単一ノードの OpenShift クラスターおよび OpenShift Container Platform クラスター一般では、最初にノードをドレインせずにノードの再起動が発生してしまう可能性があります。これは、デバイスを要求するアプリケーション Pod が UnexpectedAdmissionError
エラーで失敗した場合に発生する可能性があります。Deployment
、ReplicaSet
、または DaemonSet
エラーが報告されるのは、これらのデバイスを必要とするアプリケーション Pod が、それらのデバイスにサービスを提供する Pod より前に開始されるためです。Pod の再起動の順序を制御できません。
この動作は想定範囲内ですが、正常にデプロイできなかった場合でも、Pod がクラスター上に残る可能性があります。Pod は、引き続き UnexpectedAdmissionError
を報告します。この問題は、アプリケーション Pod が通常 Deployment
、ReplicaSet
、または DaemonSet
に含まれるため、軽減されます。Pod がこのエラー状態にある場合は、別のインスタンスが実行されているはずなので、ほとんど問題はありません。Deployment
、ReplicaSet
、または DaemonSet
に Pod が属していれば、後続の Pod の正常な作成と実行が保証され、アプリケーションのデプロイも正常に行われます。
このような Pod が正常に終了するように、アップストリームで作業が進行されます。この作業が解決されるまで、単一ノードの OpenShift クラスターで失敗した Pod を削除するには、以下のコマンドを実行します。
oc delete pods --field-selector status.phase=Failed -n <POD_NAMESPACE>
$ oc delete pods --field-selector status.phase=Failed -n <POD_NAMESPACE>
単一ノードの OpenShift クラスターでは、ノードをドレインするオプションは利用できません。
6.2.5. ノードの削除
6.2.5.1. クラスターからのノードの削除
OpenShift Container Platform クラスターからノードを削除するには、適切な MachineSet
オブジェクトをスケールダウンします。
クラスターがクラウドプロバイダーと統合されている場合、ノードを削除するには対応するマシンを削除する必要があります。このタスクに oc delete node
コマンドは使用しないでください。
CLI を使用してノードを削除する場合、ノードオブジェクトは Kubernetes で削除されますが、ノード自体にある Pod は削除されません。レプリケーションコントローラーで管理されていないベア Pod は、OpenShift Container Platform からアクセスできなくなります。レプリケーションコントローラーで管理されるベア Pod は、他の利用可能なノードに再スケジュールされます。ローカルのマニフェスト Pod は削除する必要があります。
ベアメタルでクラスターを実行している場合、MachineSet
オブジェクトを編集してノードを削除することはできません。コンピュートマシンセットは、クラスターがクラウドプロバイダーに統合されている場合にのみ利用できます。代わりに、ノードを手作業で削除する前に、ノードをスケジュール解除し、ドレイン (解放) する必要があります。
手順
次のコマンドを実行して、クラスター内のコンピュートマシンセットを表示します。
oc get machinesets -n openshift-machine-api
$ oc get machinesets -n openshift-machine-api
Copy to Clipboard Copied! コンピュートマシンセットは、
<cluster-id>-worker-<aws-region-az>
の形式で一覧表示されます。次のいずれかの方法で、コンピュートマシンセットをスケールダウンします。
次のコマンドを実行して、スケールダウンするレプリカの数を指定します。
oc scale --replicas=2 machineset <machine-set-name> -n openshift-machine-api
$ oc scale --replicas=2 machineset <machine-set-name> -n openshift-machine-api
Copy to Clipboard Copied! 次のコマンドを実行して、コンピュートマシンセットのカスタムリソースを編集します。
oc edit machineset <machine-set-name> -n openshift-machine-api
$ oc edit machineset <machine-set-name> -n openshift-machine-api
Copy to Clipboard Copied! 出力例
apiVersion: machine.openshift.io/v1beta1 kind: MachineSet metadata: # ... name: <machine-set-name> namespace: openshift-machine-api # ... spec: replicas: 2 # ...
apiVersion: machine.openshift.io/v1beta1 kind: MachineSet metadata: # ... name: <machine-set-name> namespace: openshift-machine-api # ... spec: replicas: 2
1 # ...
Copy to Clipboard Copied! - 1
- スケールダウンするレプリカの数を指定します。
6.2.5.2. ベアメタルクラスターからのノードの削除
CLI を使用してノードを削除する場合、ノードオブジェクトは Kubernetes で削除されますが、ノード自体にある Pod は削除されません。レプリケーションコントローラーで管理されないベア Pod は、OpenShift Container Platform からはアクセスできなくなります。レプリケーションコントローラーで管理されるベア Pod は、他の利用可能なノードに再スケジュールされます。ローカルのマニフェスト Pod は削除する必要があります。
手順
以下の手順を実行して、ベアメタルで実行されている OpenShift Container Platform クラスターからノードを削除します。
ノードをスケジューリング対象外としてマークします。
oc adm cordon <node_name>
$ oc adm cordon <node_name>
Copy to Clipboard Copied! ノード上のすべての Pod をドレイン (解放) します。
oc adm drain <node_name> --force=true
$ oc adm drain <node_name> --force=true
Copy to Clipboard Copied! このステップは、ノードがオフラインまたは応答しない場合に失敗する可能性があります。ノードが応答しない場合でも、共有ストレージに書き込むワークロードを実行している可能性があります。データの破損を防ぐには、続行する前に物理ハードウェアの電源を切ります。
クラスターからノードを削除します。
oc delete node <node_name>
$ oc delete node <node_name>
Copy to Clipboard Copied! ノードオブジェクトはクラスターから削除されていますが、これは再起動後や kubelet サービスが再起動される場合にクラスターに再び参加することができます。ノードとそのすべてのデータを永続的に削除するには、ノードの使用を停止 する必要があります。
- 物理ハードウェアを電源を切っている場合は、ノードがクラスターに再度加わるように、そのハードウェアを再びオンに切り替えます。