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

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

始める前に、クラスターのすべての名前空間内で、cluster-admin RBAC 役割に対応する cluster-admin サービス・アクセス役割を持っていることを確認してください。

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