diff --git a/content/ja/docs/tasks/debug-application-cluster/debug-cluster.md b/content/ja/docs/tasks/debug-application-cluster/debug-cluster.md
new file mode 100644
index 0000000000..34803b2b6b
--- /dev/null
+++ b/content/ja/docs/tasks/debug-application-cluster/debug-cluster.md
@@ -0,0 +1,114 @@
+---
+title: クラスターのトラブルシューティング
+content_type: concept
+---
+
+<!-- overview -->
+
+このドキュメントはクラスターのトラブルシューティングに関するもので、あなたが経験している問題の根本原因として、アプリケーションをすでに除外していることを前提としています。
+アプリケーションのデバッグのコツは、[application troubleshooting guide](/docs/tasks/debug-application-cluster/debug-application)をご覧ください。
+また、[troubleshooting document](/docs/tasks/debug-application-cluster/troubleshooting/)にも詳しい情報があります。
+
+<!-- body -->
+
+## クラスターのリストアップ
+
+クラスターで最初にデバッグするのは、ノードがすべて正しく登録されているかどうかです。
+
+```shell
+kubectl get nodes
+```
+
+そして、期待するノードがすべて存在し、それらがすべて `Ready` 状態であることを確認します。
+
+クラスター全体の健全性に関する詳細な情報を得るには、以下を実行します。
+
+```shell
+kubectl cluster-info dump
+```
+## ログの確認
+
+今のところ、クラスターをより深く掘り下げるには、関連するマシンにログインする必要があります。
+以下は、関連するログファイルの場所です。
+(systemdベースのシステムでは、代わりに `journalctl` を使う必要があるかもしれないことに注意してください)
+
+### マスターノード
+
+   * `/var/log/kube-apiserver.log` - APIの提供を担当するAPIサーバーのログ
+   * `/var/log/kube-scheduler.log` - スケジューリング決定責任者であるスケジューラーのログ
+   * `/var/log/kube-controller-manager.log` - レプリケーションコントローラーを管理するコントローラーのログ
+
+### ワーカーノード
+
+   * `/var/log/kubelet.log` - ノード上でコンテナの実行を担当するKubeletのログ
+   * `/var/log/kube-proxy.log` - サービスのロードバランシングを担うKube Proxyのログ
+
+## クラスター障害モードの一般的な概要
+
+これは、問題が発生する可能性のある事柄と、問題を軽減するためにクラスターのセットアップを調整する方法の不完全なリストです。
+
+### 根本的な原因
+
+  - VMのシャットダウン
+  - クラスター内、またはクラスターとユーザー間のネットワークパーティション
+  - Kubernetesソフトウェアのクラッシュ
+  - データの損失や永続的ストレージ(GCE PDやAWS EBSボリュームなど)の使用不能
+  - Kubernetesソフトウェアやアプリケーションソフトウェアの設定ミスなど、オペレーターのミス
+
+### 具体的なシナリオ
+
+  - apiserver VMのシャットダウンまたはapiserverのクラッシュ
+    - 新しいPod、サービス、レプリケーションコントローラの停止、更新、起動ができない
+    - Kubernetes APIに依存していない限り、既存のPodやサービスは正常に動作し続けるはずです
+  - apiserverのバックアップストレージが失われた
+    - apiserverが立ち上がらない
+    - kubeletsは到達できなくなりますが、同じPodを実行し、同じサービスのプロキシを提供し続けます
+    - apiserverを再起動する前に、手動でapiserverの状態を回復または再現する必要がある
+  - サポートサービス(ノードコントローラ、レプリケーションコントローラーマネージャー、スケジューラーなど)VMのシャットダウンまたはクラッシュ
+    - 現在、これらはapiserverとコロケーションしており、使用できない場合はapiserverと同様の影響があります
+    - 将来的には、これらも複製されるようになり、同じ場所に配置されない可能性があります
+    - 独自の永続的な状態を持っていない。
+
+  - 個別ノード(VMまたは物理マシン)のシャットダウン
+    - そのノード上のPodの実行を停止
+  - ネットワークパーティション
+    - パーティションAはパーティションBのノードがダウンしていると考え、パーティションBはapiserverがダウンしていると考えています。(マスターVMがパーティションAで終了したと仮定)
+  - Kubeletソフトウェア障害
+    - クラッシュしたkubeletがノード上で新しいPodを起動できない
+    - kubeletがPodを削除するかどうか
+    - ノードが不健全と判定される
+    - レプリケーションコントローラーが別の場所で新しいPodを起動する
+  - クラスターオペレーターエラー
+    - PodやServiceなどの損失
+    - apiserverのバックエンドストレージの紛失
+    - ユーザーがAPIを読めなくなる
+    - その他
+
+### 軽減策
+
+- 対処法: IaaSプロバイダーの自動VM再起動機能をIaaS VMに使用する
+  - 異常: Apiserver VMのシャットダウンまたはApiserverのクラッシュ
+  - 異常: サポートサービスのVMシャットダウンまたはクラッシュ
+
+- 対処法: IaaSプロバイダーの信頼できるストレージ(GCE PDやAWS EBSボリュームなど)をapiserver+etcdを使用するVMに使用する
+  - 異常: Apiserverのバックエンドストレージが失われる
+
+- 対処法: [高可用性](/docs/setup/production-environment/tools/kubeadm/high-availability/)構成を使用します
+  - 異常: コントロールプレーンノードのシャットダウンまたはコントロールプレーンコンポーネント(スケジューラー、APIサーバー、コントローラーマネージャー)のクラッシュ
+    - 1つ以上のノードまたはコンポーネントの同時故障に耐えることができる
+  - 異常: APIサーバーのバックアップストレージ(etcdのデータディレクトリーなど)が消失
+    - HA(高可用性) etcdの構成を想定しています
+
+- 対処法: apiserver PDs/EBS-volumesを定期的にスナップショットする
+  - 異常: Apiserver のバックエンドストレージが失われる
+  - 異常: 操作ミスが発生する場合がある
+  - 異常: Kubernetesのソフトウェアに障害が発生する場合がある
+
+- 対処法：レプリケーションコントローラーとServiceをPodの前に使用する
+  - 異常: ノードのシャットダウン
+  - 異常: Kubeletソフトウェア障害
+
+- 対処法: 予期せぬ再起動に耐えられるように設計されたアプリケーション(コンテナ)
+  - 異常: ノードのシャットダウン
+  - 異常: Kubeletソフトウェア障害
+