Kubernetes API を使用したワーカー・ノードのデバッグ

クラスターに対するアクセス権限がある場合は、Node リソース上で Kubernetes API を使用してワーカー・ノードをデバッグすることができます。

開始する前に、すべてのネームスペースの Manager サービス・アクセス・ロール、または cluster-admin RBACロールに対応するクラスタの Administrator プラットフォーム・ロールがあることを確認してください。

Red Hat OpenShift クラスターにアクセスします。
クラスター内のワーカー・ノードをリストして、STATUS が Ready でないワーカー・ノードの NAME をメモします。この NAME はワーカー・ノードのプライベート IP アドレスであることに注意してください。
```
oc get nodes
```
各ワーカー・ノードを記述し、出力内の Conditions セクションを確認します。
- Type: ワーカー・ノードに影響する可能性がある状態のタイプ (メモリーやディスクの負荷など)。
- LastTransitionTime: 状況が最後に更新された時刻。この時刻を使用して、ワーカー・ノードの問題が始まった時刻を特定すると、問題をさらにトラブルシューティングする上で役立つことがあります。
```
oc describe node <name>
```
ワーカー・ノードの使用量を確認します。
1. 前述のコマンドの Allocated resources 出力で、ワーカー・ノードの CPU とメモリーのリソースを使用するワークロードを確認します。一部のポッドではリソース制限が設定されておらず、予期したよりも多くのリソースが消費される場合があります。その場合は、そのポッドのリソース使用量を調整します。
2. クラスター内の各ワーカー・ノードの CPU とメモリーの使用率がどの程度の割合であるかを確認します。使用率が常に80%を超える場合は、クラスタにワーカーノードを追加してワークロードをサポートします。
クラスター内にインストールされているカスタム・アドミッション・コントローラーがあるかどうかを確認します。アドミッション・コントローラーが必須ポッドの実行をブロックすることがよくあります。それが原因でワーカー・ノードが重大な状態になる場合があります。カスタム・アドミッション・コントローラーが存在する場合は、oc delete で削除してみてください。その後、ワーカー・ノードの問題が解決するかどうかを確認してください。
```
kubectl get mutatingwebhookconfigurations --all-namespaces
```
```
kubectl get validatingwebhookconfigurations --all-namespaces
```
ログの転送を構成した場合は、以下のパスにあるノード関連のログを確認します。
```
/var/log/kubelet.log
/var/log/syslog
/var/log/messages
```
ワークロードのデプロイメントがワーカー・ノードの問題の原因になっていないかを確認します。
1. 問題のあるワーカー・ノードにテイントを適用します。
```
oc taint node NODEIP ibm-cloud-debug-isolate-customer-workload=true:NoExecute
```
2. ステップ 5 の記述どおりにカスタム・アドミッション・コントローラーを削除したことを確認します。
3. ワーカー・ノードを再始動します。
  - クラシック: ワーカー・ノードを再ロードします。
```
ibmcloud oc worker reload -c <cluster_name_or_ID> --worker <worker_ID>
```
  - VPC: ワーカー・ノードを置換します。
```
ibmcloud oc worker replace -c <cluster_name_or_ID> --worker <worker_ID> --update
```
4. ワーカー・ノードの再始動が完了するまで待ちます。ワーカー・ノードが正常な状態になった場合、問題の原因はワークロードである可能性があります。
5. ワーカー・ノードに一度に 1 つのワークロードをスケジュールして、問題の原因になっているワークロードを確認します。ワークロードをスケジュールするには、以下の toleration を追加します。
```
tolerations:
- effect: NoExecute
  key: ibm-cloud-debug-isolate-customer-workload
  operator: Exists
```
6. 問題の原因であるワークロードを特定したら、アプリ・デプロイメントのデバッグに進みます。