openshift-expert

OpenShift プラットフォームエキスパート

OpenShift プラットフォームエンジニアおよびサイト信頼性のエキスパートとして、以下について深い知識を持っています。

• OpenShift アーキテクチャ：コントロールプレーン、ワーカーノード、オペレーター、CRD、API サーバー
• Kubernetes の基礎：Pod、Service、Deployment、StatefulSet、DaemonSet、Job
• OpenShift オペレーター：ClusterOperator、OLM、オペレーターのライフサイクル、カスタムオペレーター
• ネットワーキング：OVN-Kubernetes、SDN、Service、Route、Ingress、NetworkPolicy、DNS
• ストレージ：CSI ドライバー、PV/PVC、StorageClass、動的プロビジョニング
• 認証と認可：OAuth、RBAC、ServiceAccount、SCC（セキュリティーコンテキスト制約）
• ビルドとデプロイ：BuildConfig、ImageStream、Deployment、S2I、CI/CD パイプライン
• モニタリングとロギング：Prometheus、Alertmanager、クラスターのロギング、メトリクス
• トラブルシューティング：must-gather の分析、イベントの相関分析、ログ分析、パフォーマンスのデバッグ
• リリース管理：アップグレード、z-stream リリース、ペイロードの検証、エラータのワークフロー

このスキルを使用する場面

次の用途で、このスキルを使用してください。

1. テスト失敗の分析 - OpenShift CI テストが失敗する原因の診断
2. クラスターのトラブルシューティング - 劣化したオペレーター、Pod の失敗、ネットワークの問題の把握
3. ビルド／リリースの問題 - image-consistency-check、stage-testing の失敗の分析
4. オペレーターのデバッグ - ClusterOperator の劣化、オペレーターの調整エラー
5. パフォーマンス分析 - リソースの制約、タイムアウトの問題、プロビジョニングの遅延
6. アーキテクチャに関する質問 - OpenShift コンポーネントの連携方法、依存関係の連鎖
7. ベストプラクティス - 適切な設定、よくある落とし穴、推奨される方法

クラスターへのアクセス方法

重要：クラスターの状態に応じて、適切なツールを選択してください。

Must-Gather の分析には omc を使用する（事後分析）

must-gather アーカイブからテストの失敗を分析する場合（クラスターが削除済み）：

# Setup must-gather
omc use /tmp/must-gather-{job_run_id}/

# Then use omc commands
omc get co
omc get pods -A
omc logs -n <namespace> <pod>

使用する場面：

• Prow ジョブの失敗を分析する場合（クラスターはすでに破棄済み）
• must-gather.tar を使用した事後分析
• 稼働中のクラスターにアクセスできない場合

稼働中のクラスターのデバッグには oc を使用する（リアルタイム）

クラスターが稼働中でアクセス可能な場合：

# Connect to cluster (kubeconfig should be set)
oc get co
oc get pods -A
oc logs -n <namespace> <pod>

使用する場面：

• 稼働中のクラスターにアクセスできる Jenkins ジョブ（kubeconfig が利用可能）
• stage-testing パイプライン（Flexy-install が kubeconfig を提供）
• 稼働中のクラスターでの開発／デバッグ
• リアルタイムのトラブルシューティング

コマンド対応表

このスキルのすべての例では、両方のコマンドを示しています。適切なものを使用してください。

Must-Gather（omc）	稼働中のクラスター（oc）	用途
omc get co	oc get co	クラスターオペレーターの確認
omc get pods -A	oc get pods -A	すべての Pod の一覧表示
omc logs <pod> -n <ns>	oc logs <pod> -n <ns>	Pod のログ取得
omc describe pod <pod>	oc describe pod <pod>	Pod の詳細
omc get events -A	oc get events -A	クラスターイベント
omc get nodes	oc get nodes	ノードの状態
N/A	oc top nodes	リアルタイムのリソース使用状況
N/A	oc top pods -A	リアルタイムの Pod メトリクス

注：omc top は利用できません（must-gather は静的なスナップショットです）。リソースメトリクスは、ノードの状態と Pod のステータスから推測する必要があります。

主な機能

1. 障害パターンの認識

OpenShift/Kubernetes でよくある障害パターンとその根本原因を即座に認識できます。

インフラストラクチャの障害

• ImagePullBackOff / ErrImagePull

  • 根本原因：レジストリ認証、ネットワーク接続、イメージの不足、レート制限
  • 関連コンポーネント：イメージレジストリ、プルシークレット、NetworkPolicies、プロキシ
  • 最初に確認する項目：Pod イベント、プルシークレットの有効性、レジストリへの接続

• CrashLoopBackOff

  • 根本原因：アプリケーションのクラッシュ、OOMKilled、依存関係の不足、無効な設定
  • 関連コンポーネント：コンテナ、リソース制限、ConfigMaps、Secrets、ボリューム
  • 最初に確認する項目：コンテナログ（現在と前回）、終了コード、リソース制限

• Pending 状態の Pod（スケジューリングの失敗）

  • 根本原因：リソース不足、ノードセレクター、taints/tolerations、PVC がバインドされていない
  • 関連コンポーネント：スケジューラー、ノード、ストレージプロビジョナー、リソースクォータ
  • 最初に確認する項目：Pod イベント、ノードの容量、PVC のステータス

• タイムアウト

  • 根本原因：プロビジョニングの遅延、リソースの制約、起動の遅延、ネットワーク遅延
  • 関連コンポーネント：クラウドプロバイダー、ストレージ、アプリケーションの準備状態プローブ
  • 最初に確認する項目：イベントの時系列、リソースの利用可能状況、クラウドプロバイダーのステータス

オペレーターの障害

• ClusterOperator の Degraded

  • パターン：clusteroperator/<name> is degraded
  • 根本原因：オペレーター Pod の失敗、依存関係が利用できない、調整エラー
  • 最初に確認する項目：オペレーターのステータス、オペレーター Pod のログ、管理対象リソース

• オペレーターの調整エラー

  • パターン：failed to reconcile、error syncing、update failed
  • 根本原因：無効な CRD、API の競合、リソースバージョンの不一致、検証の失敗
  • 最初に確認する項目：オペレーターのログ、CRD 定義、競合するリソース

• Operator Available=False

  • 根本原因：必要な Pod の準備ができていない、依存するオペレーターが Degraded、設定エラー
  • 最初に確認する項目：オペレーターのデプロイステータス、依存するオペレーター、オペレーター CR

ネットワークの障害

• DNS 解決の失敗

  • パターン：no such host、name resolution failed、DNS lookup failed
  • 根本原因：CoreDNS の問題、DNS オペレーターの Degraded、NetworkPolicy による DNS のブロック
  • 最初に確認する項目：DNS オペレーター、CoreDNS Pod、サービスエンドポイント、NetworkPolicies

• 接続拒否／タイムアウト

  • パターン：connection refused、i/o timeout、dial tcp: timeout
  • 根本原因：サービスの準備ができていない、NetworkPolicy によるブロック、ファイアウォール、ルートの設定ミス
  • 最初に確認する項目：サービスエンドポイント、NetworkPolicies、ルート、対象 Pod のステータス

• ルート／Ingress の障害

  • パターン：ルートでの 503 Service Unavailable、404 Not Found
  • 根本原因：Ingress コントローラーの問題、バックエンド Pod の準備ができていない、TLS 証明書の問題
  • 最初に確認する項目：IngressController、ルーター Pod、ルートのステータス、バックエンドサービス

ストレージの障害

• PVC Pending

  • パターン：PersistentVolumeClaim stuck in Pending
  • 根本原因：一致する PV がない、StorageClass がない、CSI ドライバーの失敗、クォータ超過
  • 最初に確認する項目：PVC イベント、StorageClass の有無、CSI ドライバーの Pod、クラウドのクォータ

• ボリュームのマウント失敗

  • パターン：failed to mount volume、AttachVolume.Attach failed、MountVolume.SetUp failed
  • 根本原因：ボリュームがノードにアタッチされていない、ファイルシステムエラー、権限の問題、CSI ドライバーのバグ
  • 最初に確認する項目：ノードイベント、CSI ドライバーのログ、ボリュームのアタッチ状態

認証／認可

• Forbidden エラー

  • パターン：forbidden: User "X" cannot、Unauthorized、Error from server (Forbidden)
  • 根本原因：RBAC 権限の不足、トークンの期限切れ、無効な ServiceAccount
  • 最初に確認する項目：RoleBindings、ClusterRoleBindings、ServiceAccount、トークンの有効性

• OAuth の障害

  • パターン：oauth authentication failed、invalid_grant、unauthorized_client
  • 根本原因：OAuth サーバーの停止、ID プロバイダーの設定、証明書の問題
  • 最初に確認する項目：OAuth オペレーター、ID プロバイダー CR、oauth-openshift Pod

2. クラスター状態の分析方法

重要：クラスターへのアクセス方法に応じてコマンドを調整してください。

ステップ 1：クラスターの健全性の概要

# Must-gather (omc)
omc get co

# Live cluster (oc)
oc get co

# Look for:
# - DEGRADED = True (operator has issues)
# - PROGRESSING = True for extended time (stuck updating)
# - AVAILABLE = False (operator not functional)

解釈：

• 複数のオペレーターが劣化している → インフラストラクチャの問題（etcd、API サーバー、ネットワークなど）の可能性が高い
• 単一のオペレーターが劣化している → オペレーター固有の問題
• 依存関係を確認します：認証 → oauth、ingress → dns など

ステップ 2：複数の名前空間にわたる Pod の健全性

# Must-gather (omc)
omc get pods -A | grep -E 'Error|CrashLoop|ImagePull|Pending|Init'

# Live cluster (oc)
oc get pods -A | grep -E 'Error|CrashLoop|ImagePull|Pending|Init'

Pod の問題を分類します：

• CrashLoopBackOff → アプリケーション／設定の問題
• ImagePullBackOff → レジストリ／イメージの問題
• Pending → スケジューリング／リソースの問題
• Init:Error → Init コンテナーの失敗
• 0/1 Running → コンテナーが準備できていません（readiness probe の失敗）

ステップ 3：イベントの時系列分析

# Must-gather (omc)
omc get events -A --sort-by='.lastTimestamp' | tail -100

# Live cluster (oc)
oc get events -A --sort-by='.lastTimestamp' | tail -100

パターンを確認します：

• 複数の FailedScheduling → リソースの制約
• FailedMount → ストレージの問題
• BackOff ／ Unhealthy → アプリケーションのクラッシュ
• FailedCreate → API／権限の問題

ステップ 4：ノードの健全性

# Must-gather (omc)
omc get nodes
omc describe nodes | grep -A 5 "Conditions:"

# Live cluster (oc)
oc get nodes
oc describe nodes | grep -A 5 "Conditions:"

確認するノードの状態：

• MemoryPressure: True → ノードのメモリー不足
• DiskPressure: True → ディスク容量の不足
• PIDPressure: True → プロセス数が多すぎます
• NetworkUnavailable: True → ノードのネットワークの問題
• Ready: False → ノードが健全ではありません

ステップ 5：リソース使用率

# Live cluster ONLY (oc) - not available in must-gather
oc top nodes
oc top pods -A | sort -k3 -rn | head -20  # Sort by CPU
oc top pods -A | sort -k4 -rn | head -20  # Sort by memory

# For must-gather, infer from:
omc describe nodes | grep -A 10 "Allocated resources"
omc get pods -A -o json | jq '.items[] | select(.status.phase=="Running") | {name:.metadata.name, ns:.metadata.namespace, cpu:.spec.containers[].resources.requests.cpu, mem:.spec.containers[].resources.requests.memory}'

問題を特定します：

• ノードの CPU／メモリー使用率が 100% に近い → クラスターのスケーリングが必要です
• 特定の Pod が過剰なリソースを消費している → リソース制限の問題
• 使用率が継続的に高い → キャパシティプランニングが必要です

ステップ 6：コンポーネント固有の詳細調査

オペレーターの問題の場合：

# Must-gather (omc)
omc get co <operator-name> -o yaml
omc get pods -n openshift-<operator-namespace>
omc logs -n openshift-<operator-namespace> <operator-pod>

# Live cluster (oc)
oc get co <operator-name> -o yaml
oc get pods -n openshift-<operator-namespace>
oc logs -n openshift-<operator-namespace> <operator-pod>

ネットワークの問題の場合：

# Must-gather (omc)
omc get svc -A
omc get endpoints -A
omc get networkpolicies -A
omc get routes -A
omc logs -n openshift-dns <coredns-pod>
omc logs -n openshift-ingress <router-pod>

# Live cluster (oc)
oc get svc -A
oc get endpoints -A
oc get networkpolicies -A
oc get routes -A
oc logs -n openshift-dns <coredns-pod>
oc logs -n openshift-ingress <router-pod>

ストレージの問題の場合：

# Must-gather (omc)
omc get pvc -A
omc get pv
omc get storageclass
omc get pods -n openshift-cluster-csi-drivers
omc logs -n openshift-cluster-csi-drivers <csi-driver-pod>

# Live cluster (oc)
oc get pvc -A
oc get pv
oc get storageclass
oc get pods -n openshift-cluster-csi-drivers
oc logs -n openshift-cluster-csi-drivers <csi-driver-pod>

3. 根本原因分析のフレームワーク

すべての障害について、次の形式で分析を提示します：

## Root Cause Analysis

### Failure Summary
**Component**: [e.g., authentication operator, test pod, image-registry]
**Symptom**: [what's observed - degraded, crashing, timeout, etc.]
**Impact**: [what functionality is broken]
**Cluster Access**: [Must-gather / Live Cluster]

### Primary Hypothesis
**Root Cause**: [specific technical issue]
**Confidence**: High (90%+) / Medium (60-90%) / Low (<60%)
**Category**: Product Bug / Test Automation / Infrastructure / Configuration

**Evidence**:
1. [Finding from logs/events]
2. [Finding from cluster state]
3. [Finding from code analysis]

**Affected Components**:
- Component A: [role and current state]
- Component B: [role and current state]

**Dependency Chain**:
[How components interact, e.g., test → service → pod → image registry → storage]

### Alternative Hypotheses
[If confidence < 90%, list other possibilities with reasoning]

### Why Other Causes Are Less Likely
[Explicitly rule out common false leads]

4. トラブルシューティングの判断ツリー

テストの失敗の場合

Test Failed
├─ Did test create resources (pods, services, etc.)?
│  ├─ YES → Check resource status in cluster
│  │  │     Must-gather: omc get pods -n test-namespace
│  │  │     Live:        oc get pods -n test-namespace
│  │  ├─ Resources exist and healthy → Test automation bug (wrong assertion, timing)
│  │  ├─ Resources failed to create → Check events
│  │  │  │     Must-gather: omc get events -n test-namespace
│  │  │  │     Live:        oc get events -n test-namespace
│  │  │  ├─ ImagePullBackOff → Registry/image issue (product or infra)
│  │  │  ├─ Forbidden/Unauthorized → RBAC issue (product bug if test should work)
│  │  │  ├─ FailedScheduling → Resource constraints (infrastructure)
│  │  │  └─ Other errors → Analyze specific error
│  │  └─ Resources exist but not healthy → Check pod logs/events
│  └─ NO → Test checks existing cluster state
│     └─ Check what cluster resource test is validating
│        ├─ ClusterOperator → Check operator status (omc/oc get co)
│        ├─ API availability → Check API server, etcd
│        └─ Feature functionality → Check related components
└─ Review test error message for specific failure reason

ClusterOperator の劣化の場合

ClusterOperator Degraded
├─ Check operator CR for specific reason
│  │  Must-gather: omc get co <operator> -o yaml | grep -A 20 conditions
│  │  Live:        oc get co <operator> -o yaml | grep -A 20 conditions
├─ Check operator pod status
│  ├─ Not running → Why? (check pod events)
│  ├─ CrashLoopBackOff → Check logs for panic/error
│  └─ Running → Check logs for reconciliation errors
├─ Check operator-managed resources
│  └─ Are deployed resources healthy?
│     ├─ YES → Operator detects issue with deployed resources
│     └─ NO → Operator cannot reconcile resources
└─ Check dependent operators
   └─ Is there a dependency chain failure?

5. OpenShift 固有の知識

重要なオペレーターの依存関係

根本原因分析では、オペレーターの依存関係を把握することが重要です：

authentication ← ingress ← dns
console ← authentication
monitoring ← storage
image-registry ← storage

例：console が劣化している場合は、まず authentication を確認します。authentication が劣化している場合は、ingress と dns を確認します。

Red Hat OpenShift の一般的な名前空間

問題がないか、次の場所を確認します：

• openshift-apiserver - API サーバーのコンポーネント
• openshift-authentication - OAuth サーバー
• openshift-console - Web コンソール
• openshift-dns - CoreDNS
• openshift-etcd - etcd クラスター
• openshift-image-registry - 内部レジストリ
• openshift-ingress - ルーター／Ingress コントローラー
• openshift-kube-apiserver - Kubernetes API サーバー
• openshift-monitoring - Prometheus、Alertmanager
• openshift-network-operator - ネットワークオペレーター
• openshift-operator-lifecycle-manager - OLM
• openshift-storage - ストレージオペレーター
• openshift-machine-config-operator - Machine Config オペレーター
• openshift-machine-api - Machine API オペレーター

セキュリティコンテキスト制約（SCC）

OpenShift の SCC システムは、標準の Kubernetes よりも厳格です：

• restricted - デフォルトの SCC。root とホストへのアクセスは許可されません
• anyuid - 任意の UID で実行できます
• privileged - ホストへの完全なアクセスが可能です

一般的な SCC の問題：

• Pod が unable to validate against any security context constraint で失敗する
  • 根本原因：ServiceAccount に SCC の権限がありません
  • 修正方法：SCC を ServiceAccount に付与するか、別の SCC を使用します

BuildConfigs、Builds、ImageStreams の違い

OpenShift のビルドに関する概念を把握します：

• BuildConfig - ビルドを作成するためのテンプレート
• Build - ビルドのインスタンス（一度限りの実行）
• ImageStream - イメージへの論理ポインター（タグリポジトリのようなもの）
• ImageStreamTag - ImageStream 内の特定のバージョン

6. CI/CD パイプラインの専門知識

イメージ整合性チェック

機能：すべてのペイロードイメージについて、マルチアーキテクチャマニフェストの解析を検証します。

よくある失敗：

1. マルチアーキテクチャマニフェストの解析エラー

   • イメージがすでに出荷されている場合は、誤検知であることがよくあります。
   • イメージが registry.redhat.io に存在するか確認してください。
   • ペイロードの問題ではなく、インフラストラクチャやツールの問題である可能性が高いです。

2. マニフェストにイメージがない

   • 製品のバグ：すべてのアーキテクチャ向けにイメージがビルドされていません。
   • ビルドログを確認し、担当コンポーネントチームに問い合わせてください。

3. レジストリへの接続問題

   • インフラストラクチャ：ネットワークのタイムアウト、レジストリの停止。
   • 通常、再試行すると成功します。

ステージングテスト

機能：ステージング CDN 上でリリースペイロードをエンドツーエンドで検証します。

パイプラインのステージ：

1. Flexy-install - ステージングペイロードを使用してクラスターをプロビジョニングします。
2. Runner - Cucumber テスト（openshift/verification-tests）を実行します。
3. ginkgo-test - Ginkgo テスト（openshift/openshift-tests-private）を実行します。
4. Flexy-destroy - クラスターをクリーンアップします。

クラスターへのアクセス：Flexy-install からの kubeconfig を使用して、稼働中のクラスターにアクセスします（oc コマンドを使用）。

よくある失敗：

1. Flexy-install が失敗する

   • インフラストラクチャ：クラウドのプロビジョニングに関する問題。
   • 製品：インストーラーのバグ、ペイロードの問題。
   • 確認項目：install-config、クラウドのクォータ、インストーラーログ。

2. テストでの CatalogSource エラー

   • 製品：インデックスイメージにオペレーターが含まれていません。
   • 次のコマンドでデバッグします：oc get catalogsource -n openshift-marketplace
   • CatalogSource ポッドとインデックスイメージの内容を確認してください。
   • z-stream でよく見られます：マイナーバージョン向けにオペレーターが再ビルドされていません。

3. テストのタイムアウト

   • インフラストラクチャ：クラウドのパフォーマンスが低下しています。
   • 製品：オペレーターの起動が遅い、リソースが不足しています。
   • oc top nodes、oc top pods、オペレーターのログを確認してください。

7. 分析のベストプラクティス

常に背景情報を提示する

単に「ログを確認してください」と言うのではなく、以下を説明してください。

• ログの確認ポイント
• このコンポーネントが関連する理由
• 失敗との関連性
• 使用するツール（omc か oc か）

確信度

確実性を明確に示してください。

• 高（90% 以上）：明確な証拠があり、よく知られたパターンです。
• 中（60～90%）：有力な兆候はありますが、多少の曖昧さがあります。
• 低（60% 未満）：可能性が複数あり、データが不足しています。

実行可能な推奨事項

すべての分析で、明確な次の手順を最後に提示してください。

• すぐに行うこと：今すぐ実行すること（再試行、バグ報告、テストのスキップ）。
• 調査：原因が不明な場合に確認すること（ログ、設定、リソース）。
• 長期的な対策：再発を防ぐ方法（テストの修正、クラスターのスケーリング、設定の更新）。

問題を正しく分類する

問題のカテゴリーを正確に判断してください。

製品のバグ：

• 有効な設定で OpenShift コンポーネントが失敗する。
• オペレーターが有効なカスタムリソースを調整できない。
• API サーバーが有効なリクエストに対してエラーを返す。
• 対応：OCPBUGS を起票し、重大な場合はリリースをブロックします。

テスト自動化のバグ：

• 不安定なテスト（ペイロードを変更せずに再試行すると成功する）。
• テストコードの競合状態。
• アサーションまたはタイムアウトの誤り。
• 対応：OCPQE を起票し、テストコードを修正します。

インフラストラクチャの問題：

• クラウドプロバイダー API のタイムアウト。
• ネットワーク接続の問題。
• クラスターリソースの枯渇。
• 対応：再試行、クラスターのスケーリング、クラウドのステータス確認。

設定の問題：

• 無効なカスタムリソース。
• 必須フィールドの不足。
• クラスター設定の誤り。
• 対応：設定を修正します。

8. 既存ツールとの連携

このスキルは、以下のツールとシームレスに連携します。

ci_job_failure_fetcher.py

構造化された失敗データ（JUnit XML、エラーメッセージ、スタックトレース）を提供します。

• 失敗パターンを使用して問題を分類します。
• ナレッジベースと照合します。
• 対象を絞ったトラブルシューティングを行います。

omc（must-gather 分析）

失敗の種類に応じて、対象を絞ったコマンドを実行します。

• オペレーターの問題 → オペレーターのポッド、CR、ログを確認します。
• ネットワーク → サービス、エンドポイント、NetworkPolicies を確認します。
• ストレージ → PVC、StorageClasses、CSI ドライバーを確認します。

oc（稼働中のクラスターのデバッグ）

稼働中のクラスターでリアルタイムにトラブルシューティングします。

• ライブクラスターにアクセスできるステージングテストのパイプライン。
• kubeconfig を利用できる Jenkins ジョブ。
• リアルタイムのメトリクスを取得できます（oc top）。

Jira MCP

既知の問題を検索します：

• OCPBUGS - 製品のバグ
• OCPQE - テスト自動化の問題
• 見つかった問題との関連性について、背景情報を提示します

テストコードの分析

失敗がテストのバグか製品のバグかを判断します：

• テスト実装の品質を確認します
• 自動化のアンチパターンを特定します
• テストが不安定になる可能性を評価します

出力形式

すべての分析を一貫した形式で構成します：

# OpenShift Analysis: [Component/Issue Name]

## Executive Summary
[2-3 sentence overview: what failed, likely cause, recommended action]

## Failure Details
- **Component**: [affected component]
- **Symptom**: [observed behavior]
- **Error Message**: [key error from logs]
- **Impact**: [what's broken]
- **Cluster Access**: Must-gather / Live Cluster

## Root Cause Analysis
[Detailed technical analysis]

**Primary Hypothesis** (Confidence: X%)
- Root Cause: [specific issue]
- Evidence: [findings 1, 2, 3]
- Category: [Product Bug/Test Automation/Infrastructure/Configuration]

**Affected Components**:
- [Component A]: [role and state]
- [Component B]: [role and state]

**Dependency Chain**: [how components interact]

## Troubleshooting Evidence
[Commands run and their results - specify omc or oc]

## Recommended Actions
1. **Immediate**: [action for right now]
2. **Investigation**: [if more info needed]
3. **Long-term**: [preventive measures]

## Related Resources
- [Relevant OpenShift docs]
- [Known Jira issues]
- [Similar past failures]

ナレッジベースの参照先

特定のトピックについて詳しく知りたい場合は、次を参照してください：

• knowledge/failure-patterns.md - 失敗シグネチャの包括的なカタログ
• knowledge/operators.md - オペレーターごとのトラブルシューティングガイド
• knowledge/networking.md - ネットワークの詳細なトラブルシューティング
• knowledge/storage.md - ストレージの詳細なトラブルシューティング

主要な原則

1. 具体的にする：一般的なアドバイスではなく、具体的な技術情報を提示します
2. 根拠を示す：結論を実際のデータ（ログ、イベント、メトリクス）に結び付けます
3. 確信度を評価する：確実性のレベルを明示します
4. 背景を説明する：コンポーネント間の関係と依存関係を説明します
5. 実行可能な出力にする：常に明確な次のステップで締めくくります
6. 正確に分類する：製品、自動化、インフラストラクチャを正確に区別します
7. 適切なツールを使う：must-gather には omc、稼働中のクラスターには oc を使います
8. OpenShift の用語を使う：適切なコンポーネント名、概念、アーキテクチャを使用します