Merge pull request #22111 from shuuji3/fix-markdown-format

Fix Markdown syntax, rewrite some kanji to hiragana, and several minor errors
This commit is contained in:
Kubernetes Prow Robot
2020-07-27 23:17:08 -07:00
committed by GitHub
46 changed files with 206 additions and 286 deletions
@@ -196,7 +196,7 @@ kubectl delete pod cpu-demo-2 --namespace=cpu-example
クラスターで動作するコンテナにCPU要求と制限を設定することで、クラスターのノードで利用可能なCPUリソースを効率的に使用することができます。PodのCPU要求を低く保つことで、Podがスケジュールされやすくなります。CPU要求よりも大きい制限を与えることで、次の2つを実現できます:
* Podは利用可能なCPUリソースを、突発的な活動バーストに使用することができます。
* Podは利用可能なCPUリソースを、突発的な活動(バースト)に使用することができます。
* バースト中のPodのCPUリソース量は、適切な量に制限されます。
@@ -97,7 +97,7 @@ resources:
kubectl top pod memory-demo --namespace=mem-example
```
この出力では、Podが約162,900,000バイト約150MiBのメモリーを使用していることを示しています。Podの100MiBの要求を超えていますが、200MiBの制限には収まっています。
この出力では、Podが約162,900,000バイト(約150MiB)のメモリーを使用していることを示しています。Podの100MiBの要求を超えていますが、200MiBの制限には収まっています。
```
NAME CPU(cores) MEMORY(bytes)
@@ -278,7 +278,7 @@ kubectl delete pod memory-demo-3 --namespace=mem-example
クラスターで動作するコンテナにメモリー要求と制限を設定することで、クラスターのノードで利用可能なメモリーリソースを効率的に使用することができます。Podのメモリー要求を低く保つことで、Podがスケジュールされやすくなります。メモリー要求よりも大きい制限を与えることで、次の2つを実現できます:
* Podは利用可能なメモリーを、突発的な活動バーストに使用することができます。
* Podは利用可能なメモリーを、突発的な活動(バースト)に使用することができます。
* バースト中のPodのメモリー使用量は、適切な量に制限されます。
## クリーンアップ
@@ -5,7 +5,7 @@ weight: 70
---
<!-- overview -->
このページでは、[`projected`](/docs/concepts/storage/volumes/#projected)投影ボリュームを使用して、既存の複数のボリュームソースを同一ディレクトリ内にマウントする方法を説明します。
このページでは、[`projected`](/docs/concepts/storage/volumes/#projected)(投影)ボリュームを使用して、既存の複数のボリュームソースを同一ディレクトリ内にマウントする方法を説明します。
現在、`secret``configMap``downwardAPI`および`serviceAccountToken`ボリュームを投影できます。
{{< note >}}
@@ -87,7 +87,7 @@ weight: 50
root@redis:/data/redis# kill <pid>
```
ここで`<pid>`はRedisプロセスIDPIDです。
ここで`<pid>`はRedisプロセスID(PID)です。
1. 元の端末で、Redis Podへの変更を監視します。最終的には、このようなものが表示されます:
@@ -97,7 +97,7 @@ Podは多くのリソースを共有するため、プロセスの名前空間
ただし、一部のコンテナイメージは他のコンテナから分離されることが期待されるため、これらの違いを理解することが重要です:
1. **コンテナプロセスは PID 1ではなくなります。**
一部のコンテナイメージは、PID 1なしで起動することを拒否したとえば、`systemd`を使用するコンテナ、`kill -HUP 1`などのコマンドを実行してコンテナプロセスにシグナルを送信します。
一部のコンテナイメージは、PID 1なしで起動することを拒否し(たとえば、`systemd`を使用するコンテナ)、`kill -HUP 1`などのコマンドを実行してコンテナプロセスにシグナルを送信します。
共有プロセス名前空間を持つPodでは、`kill -HUP 1`はPodサンドボックスにシグナルを送ります。(上の例では`/pause`)
1. **プロセスはPod内の他のコンテナに表示されます。**