5.2. ノードの使用
管理者として、クラスターの効率をさらに上げる多数のタスクを実行することができます。
5.2.1. ノード上の Pod を退避させる方法
Pod を退避させると、所定のノードからすべての Pod または選択した Pod を移行できます。
退避させることができるのは、レプリケーションコントローラーが管理している Pod のみです。レプリケーションコントローラーは、他のノードに新しい Pod を作成し、指定されたノードから既存の Pod を削除します。
ベア Pod、つまりレプリケーションコントローラーが管理していない Pod はデフォルトで影響を受けません。Pod セレクターを指定すると Pod のサブセットを退避できます。Pod セレクターはラベルに基づくので、指定したラベルを持つすべての Pod を退避できます。
手順
Pod の退避を実行する前に、ノードをスケジュール対象外としてマークします。
ノードにスケジュール対象外 (unschedulable) のマークを付けます。
$ oc adm cordon <node1>
出力例
node/<node1> cordoned
ノードのステータスが
Ready,SchedulingDisabledであることを確認します。$ oc get node <node1>
出力例
NAME STATUS ROLES AGE VERSION <node1> Ready,SchedulingDisabled worker 1d v1.24.0
以下の方法のいずれかを使用して Pod を退避します。
1 つ以上のノードで、すべてまたは選択した Pod を退避します。
$ oc adm drain <node1> <node2> [--pod-selector=<pod_selector>]
--forceオプションを使用してベア Pod の削除を強制的に実行します。trueに設定されると、Pod がレプリケーションコントローラー、レプリカセット、ジョブ、デーモンセット、またはステートフルセットで管理されていない場合でも削除が続行されます。$ oc adm drain <node1> <node2> --force=true
--grace-periodを使用して、各 Pod を正常に終了するための期間 (秒単位) を設定します。負の値の場合には、Pod に指定されるデフォルト値が使用されます。$ oc adm drain <node1> <node2> --grace-period=-1
trueに設定された--ignore-daemonsetsフラグを使用してデーモンセットが管理する Pod を無視します。$ oc adm drain <node1> <node2> --ignore-daemonsets=true
--timeoutを使用して、中止する前の待機期間を設定します。値0は無限の時間を設定します。$ oc adm drain <node1> <node2> --timeout=5s
--delete-emptydir-dataフラグをtrueに設定して、emptyDirボリュームを使用する Pod がある場合にも Pod を削除します。ローカルデータはノードがドレイン (解放) される場合に削除されます。$ oc adm drain <node1> <node2> --delete-emptydir-data=true
trueに設定された--dry-runオプションを使用して、実際に退避を実行せずに移行するオブジェクトを一覧表示します。$ oc adm drain <node1> <node2> --dry-run=true
特定のノード名 (例:
<node1> <node2>) を指定する代わりに、--selector=<node_selector>オプションを使用し、選択したノードで Pod を退避することができます。
完了したら、ノードにスケジュール対象のマークを付けます。
$ oc adm uncordon <node1>
5.2.2. ノードでラベルを更新する方法について
ノード上の任意のラベルを更新できます。
ノードラベルは、ノードがマシンによってバックアップされている場合でも、ノードが削除されると永続しません。
MachineSet への変更は、マシンセットが所有する既存のマシンには適用されません。たとえば、編集されたか、または既存の MachineSet に追加されたラベルは、マシンセットに関連付けられた既存マシンおよびノードには伝播しません。
以下のコマンドは、ノードのラベルを追加または更新します。
$ oc label node <node> <key_1>=<value_1> ... <key_n>=<value_n>
以下に例を示します。
$ oc label nodes webconsole-7f7f6 unhealthy=true
以下のコマンドは、namespace 内のすべての Pod を更新します。
$ oc label pods --all <key_1>=<value_1>
以下に例を示します。
$ oc label pods --all status=unhealthy
5.2.3. ノードをスケジュール対象外 (Unschedulable) またはスケジュール対象 (Schedulable) としてマークする方法
デフォルトで、Ready ステータスの正常なノードはスケジュール対象としてマークされます。つまり、新規 Pod をこのノードに配置することができます。手動でノードをスケジュール対象外としてマークすると、新規 Pod のノードでのスケジュールがブロックされます。ノード上の既存 Pod には影響がありません。
以下のコマンドは、ノードをスケジュール対象外としてマークします。
出力例
$ oc adm cordon <node>
以下に例を示します。
$ oc adm cordon node1.example.com
出力例
node/node1.example.com cordoned NAME LABELS STATUS node1.example.com kubernetes.io/hostname=node1.example.com Ready,SchedulingDisabled
以下のコマンドは、現時点でスケジュール対象外のノードをスケジュール対象としてマークします。
$ oc adm uncordon <node1>
または、特定のノード名 (たとえば
<node>) を指定する代わりに、--selector=<node_selector>オプションを使用して選択したノードをスケジュール対象またはスケジュール対象外としてマークすることができます。
5.2.4. スケジュール対象としてのコントロールプレーンノードの設定
コントロールプレーンノード (別名マスターノード) をスケジュール対象 (Schedulable) に設定できます。つまり、新規 Pod はコントロールプレーンノードに配置できるようになりました。デフォルトでは、コントロールプレーンノードはスケジュール対象ではありません。
マスターをスケジュール対象 (Schedulable) に設定できますが、ワーカーノードを保持する必要があります。
ワーカーノードのない OpenShift Container Platform をベアメタルクラスターにデプロイできます。この場合、コントロールプレーンノードはデフォルトでスケジュール対象としてマークされます。
mastersSchedulable フィールドを設定することで、コントロールプレーンノードをスケジュール対象として許可または禁止できます。
+
コントロールプレーンノードをデフォルトのスケジュール不可からスケジュール可に設定するには、追加のサブスクリプションが必要です。これは、コントロールプレーンノードがワーカーノードになるためです。
手順
schedulers.config.openshift.ioリソースを編集します。$ oc edit schedulers.config.openshift.io cluster
mastersSchedulableフィールドを設定します。apiVersion: config.openshift.io/v1 kind: Scheduler metadata: creationTimestamp: "2019-09-10T03:04:05Z" generation: 1 name: cluster resourceVersion: "433" selfLink: /apis/config.openshift.io/v1/schedulers/cluster uid: a636d30a-d377-11e9-88d4-0a60097bee62 spec: mastersSchedulable: false 1 policy: name: "" status: {}- 1
- コントロールプレーンノードがスケジュール対象 (Schedulable) になることを許可する場合は
trueに設定し、コントロールプレーンノードがスケジュール対象になることを拒否する場合は、falseに設定します。
- 変更を適用するためにファイルを保存します。
5.2.5. ノードの削除
5.2.5.1. クラスターからのノードの削除
CLI を使用してノードを削除する場合、ノードオブジェクトは Kubernetes で削除されますが、ノード自体にある Pod は削除されません。レプリケーションコントローラーで管理されないベア Pod は、OpenShift Container Platform からはアクセスできなくなります。レプリケーションコントローラーで管理されるベア Pod は、他の利用可能なノードに再スケジュールされます。ローカルのマニフェスト Pod は削除する必要があります。
手順
OpenShift Container Platform クラスターからノードを削除するには、適切な MachineSet オブジェクトを編集します。
ベアメタルでクラスターを実行している場合、MachineSet オブジェクトを編集してノードを削除することはできません。マシンセットは、クラスターがクラウドプロバイダーに統合されている場合にのみ利用できます。代わりに、ノードを手作業で削除する前に、ノードをスケジュール解除し、ドレイン (解放) する必要があります。
クラスターにあるマシンセットを表示します。
$ oc get machinesets -n openshift-machine-api
マシンセットは <clusterid>-worker-<aws-region-az> の形式で一覧表示されます。
マシンセットをスケーリングします。
$ oc scale --replicas=2 machineset <machineset> -n openshift-machine-api
マシンセットを使用してクラスターをスケーリングする方法の詳細は、マシンセットの手動によるスケーリング を参照してください。
5.2.5.2. ベアメタルクラスターからのノードの削除
CLI を使用してノードを削除する場合、ノードオブジェクトは Kubernetes で削除されますが、ノード自体にある Pod は削除されません。レプリケーションコントローラーで管理されないベア Pod は、OpenShift Container Platform からはアクセスできなくなります。レプリケーションコントローラーで管理されるベア Pod は、他の利用可能なノードに再スケジュールされます。ローカルのマニフェスト Pod は削除する必要があります。
手順
以下の手順を実行して、ベアメタルで実行されている OpenShift Container Platform クラスターからノードを削除します。
ノードにスケジュール対象外 (unschedulable) のマークを付けます。
$ oc adm cordon <node_name>
ノード上のすべての Pod をドレイン (解放) します。
$ oc adm drain <node_name> --force=true
このステップは、ノードがオフラインまたは応答しない場合に失敗する可能性があります。ノードが応答しない場合でも、共有ストレージに書き込むワークロードを実行している可能性があります。データの破損を防ぐには、続行する前に物理ハードウェアの電源を切ります。
クラスターからノードを削除します。
$ oc delete node <node_name>
ノードオブジェクトはクラスターから削除されていますが、これは再起動後や kubelet サービスが再起動される場合にクラスターに再び参加することができます。ノードとそのすべてのデータを永続的に削除するには、ノードの使用を停止 する必要があります。
- 物理ハードウェアを電源を切っている場合は、ノードがクラスターに再度加わるように、そのハードウェアを再びオンに切り替えます。
5.2.6. SELinux ブール値の設定
OpenShift Container Platform を使用すると、Red Hat Enterprise Linux CoreOS(RHCOS) ノードで SELinux ブール値を有効または無効にできます。次の手順では、Machine Config Operator(MCO) を使用してノード上の SELinux ブール値を変更する方法について説明します。この手順では、ブール値の例として container_manage_cgroup を使用します。この値は、必要なブール値に変更できます。
前提条件
- OpenShift CLI (oc) がインストールされている。
手順
次の例に示すように、
MachineConfigオブジェクトを使用して新しい YAML ファイルを作成します。apiVersion: machineconfiguration.openshift.io/v1 kind: MachineConfig metadata: labels: machineconfiguration.openshift.io/role: worker name: 99-worker-setsebool spec: config: ignition: version: 2.2.0 systemd: units: - contents: | [Unit] Description=Set SELinux booleans Before=kubelet.service [Service] Type=oneshot ExecStart=/sbin/setsebool container_manage_cgroup=on RemainAfterExit=true [Install] WantedBy=multi-user.target graphical.target enabled: true name: setsebool.service次のコマンドを実行して、新しい
MachineConfigオブジェクトを作成します。$ oc create -f 99-worker-setsebool.yaml
MachineConfig オブジェクトに変更を適用すると、変更が適用された後、影響を受けるすべてのノードが正常に再起動します。
5.2.7. カーネル引数のノードへの追加
特殊なケースとして、クラスターのノードセットにカーネル引数を追加する必要がある場合があります。これは十分に注意して実行する必要があり、設定する引数による影響を十分に理解している必要があります。
カーネル引数を正しく使用しないと、システムが起動不可能になる可能性があります。
設定可能なカーネル引数の例には、以下が含まれます。
- enforcing=0: SELinux (Security Enhanced Linux) を Permissive モードで実行するように設定します。Permissive モードでは、システムは、SELinux が読み込んだセキュリティーポリシーを実行しているかのように動作します。これには、オブジェクトのラベル付けや、アクセスを拒否したエントリーをログに出力するなどの動作が含まれますが、いずれの操作も拒否される訳ではありません。Permissive モードは、実稼働システムでの使用はサポートされませんが、デバッグには役に立ちます。
-
nosmt: カーネルの対称マルチスレッド (SMT) を無効にします。マルチスレッドは、各 CPU の複数の論理スレッドを許可します。潜在的なクロススレッド攻撃に関連するリスクを減らすために、マルチテナント環境での
nosmtの使用を検討できます。SMT を無効にすることは、基本的にパフォーマンスよりもセキュリティーを重視する選択をしていることになります。
カーネル引数の一覧と説明については、Kernel.org カーネルパラメーター を参照してください。
次の手順では、以下を特定する MachineConfig オブジェクトを作成します。
- カーネル引数を追加する一連のマシン。この場合、ワーカーロールを持つマシン。
- 既存のカーネル引数の最後に追加されるカーネル引数。
- マシン設定の一覧で変更が適用される場所を示すラベル。
前提条件
- 作業用の OpenShift Container Platform クラスターに対する管理者権限が必要です。
手順
OpenShift Container Platform クラスターの既存の
MachineConfigを一覧表示し、マシン設定にラベルを付ける方法を判別します。$ oc get MachineConfig
出力例
NAME GENERATEDBYCONTROLLER IGNITIONVERSION AGE 00-master 52dd3ba6a9a527fc3ab42afac8d12b693534c8c9 3.2.0 33m 00-worker 52dd3ba6a9a527fc3ab42afac8d12b693534c8c9 3.2.0 33m 01-master-container-runtime 52dd3ba6a9a527fc3ab42afac8d12b693534c8c9 3.2.0 33m 01-master-kubelet 52dd3ba6a9a527fc3ab42afac8d12b693534c8c9 3.2.0 33m 01-worker-container-runtime 52dd3ba6a9a527fc3ab42afac8d12b693534c8c9 3.2.0 33m 01-worker-kubelet 52dd3ba6a9a527fc3ab42afac8d12b693534c8c9 3.2.0 33m 99-master-generated-registries 52dd3ba6a9a527fc3ab42afac8d12b693534c8c9 3.2.0 33m 99-master-ssh 3.2.0 40m 99-worker-generated-registries 52dd3ba6a9a527fc3ab42afac8d12b693534c8c9 3.2.0 33m 99-worker-ssh 3.2.0 40m rendered-master-23e785de7587df95a4b517e0647e5ab7 52dd3ba6a9a527fc3ab42afac8d12b693534c8c9 3.2.0 33m rendered-worker-5d596d9293ca3ea80c896a1191735bb1 52dd3ba6a9a527fc3ab42afac8d12b693534c8c9 3.2.0 33m
カーネル引数を識別する
MachineConfigオブジェクトファイルを作成します (例:05-worker-kernelarg-selinuxpermissive.yaml)。apiVersion: machineconfiguration.openshift.io/v1 kind: MachineConfig metadata: labels: machineconfiguration.openshift.io/role: worker1 name: 05-worker-kernelarg-selinuxpermissive2 spec: config: ignition: version: 3.2.0 kernelArguments: - enforcing=03新規のマシン設定を作成します。
$ oc create -f 05-worker-kernelarg-selinuxpermissive.yaml
マシン設定で新規の追加内容を確認します。
$ oc get MachineConfig
出力例
NAME GENERATEDBYCONTROLLER IGNITIONVERSION AGE 00-master 52dd3ba6a9a527fc3ab42afac8d12b693534c8c9 3.2.0 33m 00-worker 52dd3ba6a9a527fc3ab42afac8d12b693534c8c9 3.2.0 33m 01-master-container-runtime 52dd3ba6a9a527fc3ab42afac8d12b693534c8c9 3.2.0 33m 01-master-kubelet 52dd3ba6a9a527fc3ab42afac8d12b693534c8c9 3.2.0 33m 01-worker-container-runtime 52dd3ba6a9a527fc3ab42afac8d12b693534c8c9 3.2.0 33m 01-worker-kubelet 52dd3ba6a9a527fc3ab42afac8d12b693534c8c9 3.2.0 33m 05-worker-kernelarg-selinuxpermissive 3.2.0 105s 99-master-generated-registries 52dd3ba6a9a527fc3ab42afac8d12b693534c8c9 3.2.0 33m 99-master-ssh 3.2.0 40m 99-worker-generated-registries 52dd3ba6a9a527fc3ab42afac8d12b693534c8c9 3.2.0 33m 99-worker-ssh 3.2.0 40m rendered-master-23e785de7587df95a4b517e0647e5ab7 52dd3ba6a9a527fc3ab42afac8d12b693534c8c9 3.2.0 33m rendered-worker-5d596d9293ca3ea80c896a1191735bb1 52dd3ba6a9a527fc3ab42afac8d12b693534c8c9 3.2.0 33m
ノードを確認します。
$ oc get nodes
出力例
NAME STATUS ROLES AGE VERSION ip-10-0-136-161.ec2.internal Ready worker 28m v1.20.0 ip-10-0-136-243.ec2.internal Ready master 34m v1.20.0 ip-10-0-141-105.ec2.internal Ready,SchedulingDisabled worker 28m v1.20.0 ip-10-0-142-249.ec2.internal Ready master 34m v1.20.0 ip-10-0-153-11.ec2.internal Ready worker 28m v1.20.0 ip-10-0-153-150.ec2.internal Ready master 34m v1.20.0
変更が適用されているため、各ワーカーノードのスケジューリングが無効にされていることを確認できます。
ワーカーノードのいずれかに移動し、カーネルコマンドライン引数 (ホストの
/proc/cmdline内) を一覧表示して、カーネル引数が機能することを確認します。$ oc debug node/ip-10-0-141-105.ec2.internal
出力例
Starting pod/ip-10-0-141-105ec2internal-debug ... To use host binaries, run `chroot /host` sh-4.2# cat /host/proc/cmdline BOOT_IMAGE=/ostree/rhcos-... console=tty0 console=ttyS0,115200n8 rootflags=defaults,prjquota rw root=UUID=fd0... ostree=/ostree/boot.0/rhcos/16... coreos.oem.id=qemu coreos.oem.id=ec2 ignition.platform.id=ec2 enforcing=0 sh-4.2# exit
enforcing=0引数が他のカーネル引数に追加されていることを確認できるはずです。
5.2.8. 関連情報
- MachineSet を使用してクラスターをスケーリングする方法の詳細は、MachineSet の手動によるスケーリング を参照してください。
