fix /content/ja/docs/concepts/configuration/manage-resources-containers.md

Author: Akito Kobayashi

content/ja/docs/concepts/configuration/manage-resources-containers.md

@@ -10,10 +10,10 @@ feature:
 
 <!-- overview -->
 
-{{< glossary_tooltip term_id="pod" >}}を指定する際に、{{{< glossary_tooltip text="コンテナ" term_id="container" >}}が必要とする各リソースの量をオプションで指定することができます。
+{{< glossary_tooltip term_id="pod" >}}を指定する際に、{{< glossary_tooltip text="コンテナ" term_id="container" >}}が必要とする各リソースの量をオプションで指定することができます。
 指定する最も一般的なリソースはCPUとメモリ(RAM)ですが、他にもあります。
 
-Pod内のコンテナのリソース_要求_を指定すると、スケジューラはこの情報を使用して、どのNodeにPodを配置するかを決定します。コンテナに _制限_ リソースを指定すると、kubelet はその制限を適用し、実行中のコンテナが設定した制限を超えてリソースを使用することができないようにします。また、kubelet は、少なくともそのシステムリソースのうち、 _要求_ の量を、そのコンテナが使用するために特別に確保します。
+Pod内のコンテナのリソース*要求*を指定すると、スケジューラはこの情報を使用して、どのNodeにPodを配置するかを決定します。コンテナに*制限*ソースを指定すると、kubeletはその制限を適用し、実行中のコンテナが設定した制限を超えてリソースを使用することができないようにします。また、kubeletは、少なくともそのシステムリソースのうち、*要求*の量を、そのコンテナが使用するために特別に確保します。
 
 <!-- body -->
 
@@ -34,14 +34,14 @@ Podが動作しているNodeに利用可能なリソースが十分にある場
 *CPU*と*メモリー*はいずれも*リソースタイプ*です。リソースタイプには基本単位があります。
 CPUは計算処理を表し、[Kubernetes CPUs](#meaning-of-cpu)の単位で指定されます。
 メモリはバイト単位で指定されます。
-Kubernetes v1.14以降を使用している場合は、_huge page_リソースを指定することができます。
+Kubernetes v1.14以降を使用している場合は、*huge page*リソースを指定することができます。
 Huge PageはLinux固有の機能であり、Nodeのカーネルはデフォルトのページサイズよりもはるかに大きいメモリブロックを割り当てます。
 
 たとえば、デフォルトのページサイズが4KiBのシステムでは、`hugepages-2Mi: 80Mi`という制限を指定できます。
 コンテナが40を超える2MiBの巨大ページ(合計80 MiB)を割り当てようとすると、その割り当ては失敗します。
 
 {{< note >}}
-`hugepages- *`リソースをオーバーコミットすることはできません。
+`hugepages-*`リソースをオーバーコミットすることはできません。
 これは`memory`や`cpu`リソースとは異なります。
 {{< /note >}}
 
@@ -61,7 +61,7 @@ Podの各コンテナは、次の1つ以上を指定できます。
 * `spec.containers[].resources.requests.memory`
 * `spec.containers[].resources.requests.hugepages-<size>`
 
-要求と制限はそれぞれのコンテナでのみ指定できますが、Podリソースの要求と制限について説明すると便利です。
+要求と制限はそれぞれのコンテナでのみ指定できますが、このPodリソースの要求と制限の関係性について理解すると便利です。
 特定のリソースタイプの*Podリソース要求/制限*は、Pod内の各コンテナに対するそのタイプのリソース要求/制限の合計です。
 
 ## Kubernetesにおけるリソースの単位
@@ -141,7 +141,7 @@ kubeletがPodのコンテナを開始すると、CPUとメモリーの制限が
 
 Dockerを使用する場合:
 
-- `spec.containers[].resources.requests.cpu`は、潜在的に小数であるコア値に変換され、1024倍されます。 
+- `spec.containers[].resources.requests.cpu`は、潜在的に小数であるコア値に変換され、1024倍されます。
   `docker run`コマンドの[`--cpu-shares`](https://docs.docker.com/engine/reference/run/#cpu-share-constraint)フラグの値は、この数値と2のいずれか大きい方が用いられます。
 
 - `spec.containers[].resources.limits.cpu`はミリコアの値に変換され、100倍されます。
@@ -155,8 +155,9 @@ Dockerを使用する場合:
 
 - `spec.containers[].resources.limits.memory`は整数に変換され、`docker run`コマンドの[`--memory`](https://docs.docker.com/engine/reference/run/#/user-memory-constraints)フラグの値として使用されます。
 
-コンテナがメモリー制限を超過すると、終了する場合があります。 
+コンテナがメモリー制限を超過すると、終了する場合があります。
 コンテナが再起動可能である場合、kubeletは他のタイプのランタイム障害と同様にコンテナを再起動します。
+
 コンテナがメモリー要求を超過すると、Nodeのメモリーが不足するたびにそのPodが排出される可能性があります。
 
 コンテナは、長時間にわたってCPU制限を超えることが許可される場合と許可されない場合があります。
@@ -344,7 +345,7 @@ Kubernetesでは、`1048576`から始まるプロジェクトIDを使用しま
 Kubernetesが使用しないようにする必要があります。
 
 クォータはディレクトリスキャンよりも高速で正確です。
-ディレクトリがプロジェクトに割り当てられると、ディレクトリ配下に作成されたファイルはすべてそのプロジェクト内に作成され、カーネルはそのプロジェクト内のファイルによって使用されているブロックの数を追跡するだけです。 
+ディレクトリがプロジェクトに割り当てられると、ディレクトリ配下に作成されたファイルはすべてそのプロジェクト内に作成され、カーネルはそのプロジェクト内のファイルによって使用されているブロックの数を追跡するだけです。  
 ファイルが作成されて削除されても、開いているファイルディスクリプタがあれば、スペースを消費し続けます。
 クォータトラッキングはそのスペースを正確に記録しますが、ディレクトリスキャンは削除されたファイルが使用するストレージを見落としてしまいます。
 
@@ -353,8 +354,8 @@ Kubernetesが使用しないようにする必要があります。
 * kubelet設定で、`LocalocalStorpactionCapactionIsolationFSQuotaMonitoring=true`[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gate/)を有効にします。
 
 * ルートファイルシステム(またはオプションのランタイムファイルシステム))がプロジェクトクォータを有効にしていることを確認してください。
-  すべての XFS ファイルシステムはプロジェクトクォータをサポートしています。  
-  ext4 ファイルシステムでは、ファイルシステムがマウントされていない間は、プロジェクトクォータ追跡機能を有効にする必要があります。
+  すべてのXFSファイルシステムはプロジェクトクォータをサポートしています。  
+  ext4ファイルシステムでは、ファイルシステムがマウントされていない間は、プロジェクトクォータ追跡機能を有効にする必要があります。
   ```bash
   # ext4の場合、/dev/block-deviceがマウントされていません
   sudo tune2fs -O project -Q prjquota /dev/block-device