1. 注意事項
1.18. コンテナ管理機能を使用する場合の注意事項
1.18.1. コンテナクラスタを構成するマシンをすべてシャットダウンする場
合について
コンテナクラスタでは、多くのプロセスが複雑に連携して動作しているため、不用意にすべて のマシンのシャットダウンを実施すると、再起動後のアプリケーションの動作に影響が出る可 能性がありますので注意してください。
コンテナクラスタを構成するすべてのマシンに対してシャットダウン操作を行う場合は、コンテ ナクラスタ内のアプリケーションの動作に影響が出ないように、シャットダウン方法を十分検 討して行ってください。
また、影響が発生した場合の対応のため、定期的にバックアップを実施することを推奨しま す。
関連情報： 以下のRed Hat社資料に、関連情報が記載されていますので、参照の上、検討 してください。
https://servicesblog.redhat.com/2019/05/29/how-to-stop-and-start-a-production-opens hift-cluster/
また、マシンのシャットダウンの際、SigmaSystemCenterを使用する場合は、次の事項につ いて注意してください。
Podの退去指示について
SigmaSystemCenter は、コンテナクラスタを構成する仮想マシンをシャットダウンする
際に、仮想マシン上のPod (コンテナ)(以降、Podと表記します。) を別の仮想マシンへ と退去させます。
しかし、コンテナクラスタを構成するすべての仮想マシンをシャットダウンする場合、Pod の退去先がないため、退去が行えない状態となります。結果的に、Pod の退去の失敗 に伴い、シャットダウンが失敗します。
コンテナクラスタを構成するすべての仮想マシンをシャットダウンする場合、
SigmaSystemCenterからのPodの退去指示を停止することで、Podの退去の失敗に
伴うシャットダウン失敗を回避することができます。
SigmaSystemCenter からの Pod の退去指示を停止する場合は、Pod の退去指示を
"off" (無効) に設定して、sscコマンド "ssc update environment" (環境設定の更新) を実行してください。
ssc update environment Pod_DoPodEviction off
ssc コマンドの詳細については、「ssc コマンドリファレンス」の「2.3.1. 環境設定の更新 (ssc update environment)」を参照してください。
注： SigmaSystemCenterからのPodの退去指示を再開する場合は、Podの退去指 示を "on" (有効) に設定して、sscコマンド "ssc update environment" (環境設定の更 新) を実行してください。
ssc update environment Pod_DoPodEviction on
1.18.2. Master ノードをすべてシャットダウンする場合について
Masterノードである仮想マシンをすべてシャットダウンしてしまうと、SigmaSystemCenterか らPod情報収集やPodの退去が行えない状態となります。
Masterノードが復旧するまでの間、以下の操作ができなくなりますので注意してください。
ノード (Master、Worker) の電源操作
ノード (Master、Worker) のメンテナンス操作時のPodスケジューリング設定 Openshiftに対する収集
マシン詳細画面で [コンテナリソース] を表示
Podを含むトポロジの表示
Podを含むタイムラインの表示
1.18.3. Worker ノードをすべてシャットダウンする場合について
Pod (コンテナ) の最小の有効状態や最大の無効状態を指定するPodDisruptionBudgetを 定義している場合、複数のWorkerノードをシャットダウンすることで、PodDisruptionBudget の定義を満たすことができない状態となり、Pod の退去がタイムアウトする可能性がありま す。
その際、以下のメッセージが表示されます。
「要求の試行回数が上限(10)を超えましたが、要求は成功しませんでした。」
関連情報： PodDisruptionBudgetについては、以下の資料を参照してください。
https://kubernetes.io/docs/concepts/workloads/pods/disruptions/
1.18.4. Workload Manager の Pod が動作するノードのシャットダウンに ついて
SigmaSystemCenterからWorkload ManagerのPodが動作するノードのシャットダウンを 行うと、Workload Manager の Pod が別のノードで再作成されるまでの間、Workload
Manager との通信が途絶えるため、SigmaSystemCenter のコンテナ管理機能を使用する
ことができなくなります。
そのため、SigmaSystemCenterではWorkload ManagerのPodが動作するノードのシャッ トダウンを行うと、以下のメッセージをジョブ履歴に記録し、シャットダウンを行いません。
「Workload Managerが動いているため、Podの退去指示が行えません。」
[対処方法]
Workload ManagerのPodが動作するノードのシャットダウンを行う場合は、以下の手順で
事前にWorkload ManagerのPodを別のノードに移動させてから、シャットダウンを行ってく
ださい。
1. Openshiftをインストールしている環境、またはOpenshiftが提供するocコマンドをイン ストールしている環境で、以下のocコマンドを実行してください。
oc adm drain --pod-selector='app=workload-manager' ノード名 oc adm uncordon ノード名
例)
oc adm drain --pod-selector='app=workload-manager' worker-0 oc adm uncordon worker-0
2. 以下のocコマンドを実行し、Workload ManagerのPodが別のノードに移動したことを 確認してください。
oc get pod -l 'app=workload-manager' -o wide
出力例)
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
workload-manager-6-vhhvl 4/4 Running 0 42h 10.66.0.10 master-1 <none> <none>
出力される内容から、以下の状態になっていることを確認してください。
- STATUSが "Running" になっている。
- NODEがシャットダウンするノードとは別のノードになっている。
上記の状態にならない場合、Workload Manager が何らかの理由で別のノードに移動 できていません。
考えられる理由として、ノードのスペック (CPU、メモリ、ストレージ容量) の不足が挙げ られます。別のノードの状態を確認した後、もう一度実施してください。
1.18.5. Worker ノードのシャットダウンについて
複数のWorkerノードが動作しているOpenShift環境で、一台のWorkerノードに対して、シ ャットダウンを行った場合、Openshiftの不具合により、まれに一時的にWorkload Manager と通信できなくなり、以下のSigmaSystemCenterの操作ができなくなる場合がありますので、
注意してください。
ノード (Master、Worker) の電源操作
ノード (Master、Worker) のメンテナンス操作時のPodスケジューリング設定 OpenShiftに対する収集
マシン詳細画面で [コンテナリソース] を表示
Podを含むトポロジの表示
Podを含むタイムラインの表示
本事象が発生しても 5～15分ほどで自動的に復旧しますので、しばらく経った後に、再度操 作を実施してください。
[原因]
1 台の Worker ノードのシャットダウンをきっかけに、他の Worker ノード上で動作している
kubeletが停止をしてしまうことが、まれに発生します。
kubeletが停止することで、他のPodがすべて停止され、結果としてOpenShiftのProxyで あるIngressのPodが停止してしまいます。
そのため、OpenShiftがIngressのPodを再作成するまでの間は、OpenShiftのネットワー ク に 接 続 で き ず 、 そ の ネ ッ ト ワ ー ク 内 の Workload Manager と 通 信 が で き な く な り 、
SigmaSystemCenterの前述の操作ができなくなります。