Fix markdown. Rewrite some kanji to hiragana. Make parentheses half-width.

content/ja/docs/concepts/workloads/pods/init-containers.md

@@ -8,7 +8,7 @@ weight: 40
 このページでは、Initコンテナについて概観します。Initコンテナとは、{{< glossary_tooltip text="Pod" term_id="pod" >}}内でアプリケーションコンテナの前に実行される特別なコンテナです。
 Initコンテナにはアプリケーションコンテナのイメージに存在しないセットアップスクリプトやユーティリティーを含めることができます。
 
-Initコンテナは、Podの仕様のうち`containers`という配列（これがアプリケーションコンテナを示します）と並べて指定します。
+Initコンテナは、Podの仕様のうち`containers`という配列(これがアプリケーションコンテナを示します)と並べて指定します。
 
 <!-- body -->
 ## Initコンテナを理解する {#understanding-init-containers}
@@ -213,7 +213,7 @@ Podは全てのInitコンテナが完了するまで`Ready`状態となりませ
 Initコンテナの仕様の変更は、コンテナイメージのフィールドのみに制限されています。
 Initコンテナのイメージフィールド値を変更すると、そのPodは再起動されます。
 
-Initコンテナは何度も再起動およびリトライ可能なため、べき等（Idempotent）である必要があります。特に、`EmptyDirs`にファイルを書き込むコードは、書き込み先のファイルがすでに存在している可能性を考慮に入れる必要があります。
+Initコンテナは何度も再起動およびリトライ可能なため、べき等(Idempotent)である必要があります。特に、`EmptyDirs`にファイルを書き込むコードは、書き込み先のファイルがすでに存在している可能性を考慮に入れる必要があります。
 
 Initコンテナはアプリケーションコンテナの全てのフィールドを持っています。しかしKubernetesは、Initコンテナが完了と異なる状態を定義できないため`readinessProbe`が使用されることを禁止しています。これはバリデーションの際に適用されます。
 
@@ -230,11 +230,11 @@ Initコンテナの順序と実行を考えるとき、リソースの使用に
   * リソースに対する全てのアプリケーションコンテナのリクエスト／リミットの合計
   * リソースに対する有効なinitリクエスト／リミット
 * スケジューリングは有効なリクエスト／リミットに基づいて実行されます。つまり、InitコンテナはPodの生存中には使用されない初期化用のリソースを確保することができます。
-* Podの*有効なQos（quality of service）ティアー* は、Initコンテナとアプリケーションコンテナで同様です。
+* Podの*有効なQos(quality of service)ティアー* は、Initコンテナとアプリケーションコンテナで同様です。
 
 クォータとリミットは有効なPodリクエストとリミットに基づいて適用されます。
 
-Podレベルのコントロールグループ（cgroups）は、スケジューラーと同様に、有効なPodリクエストとリミットに基づいています。
+Podレベルのコントロールグループ(cgroups)は、スケジューラーと同様に、有効なPodリクエストとリミットに基づいています。
 
 ### Podの再起動の理由 {#pod-restart-reasons}