[ja]update: /docs/concepts/policy/pid-limiting.md into Japanese

Author: Kei-Ta

content/ja/docs/concepts/policy/pid-limiting.md

@@ -8,19 +8,19 @@ weight: 40
 
 {{< feature-state for_k8s_version="v1.20" state="stable" >}}
 
-Kubernetesでは、{{< glossary_tooltip term_id="Pod" text="Pod" >}}が使用できるプロセスID(PIDs)数を制限することができます。また、オペレーティングシステムやデーモンによる使用のために、Podだけではなく{{< glossary_tooltip term_id="node" text="ノード" >}}ごとに割り当て可能なPID数を予約することができます。
+Kubernetesでは、{{< glossary_tooltip term_id="Pod" text="Pod" >}}が使用できるプロセスID(PID)数を制限することができます。また、オペレーティングシステムやデーモンによる使用のために、Podだけではなく{{< glossary_tooltip term_id="node" text="ノード" >}}ごとに割り当て可能なPID数を予約することができます。
 
 <!-- body -->
 
-プロセスID(PIDs)はノードの基本的なリソースです。他のリソース制限に達することなくタスク制限に達することは容易であり、それがホストマシンの不安定性を引き起こす可能性があります。
+プロセスID(PID)はノードの基本的なリソースです。他のリソース制限に達することなくタスク制限に達することは容易であり、それがホストマシンの不安定性を引き起こす可能性があります。
 
-クラスター管理者はクラスター内で実行しているPodがホストデーモン({{< glossary_tooltip text="kubelet" term_id="kubelet" >}}や{{< glossary_tooltip text="kube-proxy" term_id="kube-proxy" >}}や場合によってはコンテナランタイムなど)の実行を妨げるPID枯渇を引き起こさないことを保証するメカニズムを必要とします。それに加えて、同ノード上の他のワークロードへの影響を制限するためにPod間でPIDが制限されていることも重要です。
+クラスター管理者はクラスター内で実行しているPodがホストデーモン({{< glossary_tooltip text="kubelet" term_id="kubelet" >}}や{{< glossary_tooltip text="kube-proxy" term_id="kube-proxy" >}}や場合によってはコンテナランタイムなど)の実行を妨げる、PIDの枯渇を引き起こさないことを保証するメカニズムを必要とします。それに加えて、同ノード上の他のワークロードへの影響を制限するためにPod間でPIDが制限されていることも重要です。
 
 {{< note >}}
 特定のLinuxのインストール時に、オペレーティングシステムはPID制限の値を`32768`のような低いデフォルト値に設定することがあります。`/proc/sys/kernel/pid_max`の値を上げることを検討してください。
 {{< /note >}}
 
-Podが使用できるPID数の制限をkubeletに設定できます。例えば、ノードのホストOSがPIDの最大値を`262144`を設定し、250未満のPodをホストする場合、各Podに`1000`PIDを割り当てることで、そのノードで利用可能なPIDを使い切ることを防ぐことができます。管理者がCPUやメモリのようにPIDでもオーバーコミットを行いたい場合、同様にいくつかの追加のリスクがあります。いずれにしても、単一のPodがマシン全体をダウンさせることはできません。このようなリソース制限は単純なフォーク爆弾がクラスター全体の運用に影響を与えるのを防ぐのに役立ちます。
+Podが使用できるPID数の制限をkubeletに設定できます。例えば、ノードのホストOSがPIDの最大値を`262144`に設定し、250未満のPodをホストします。この場合、各Podに`1000`PIDを割り当てることで、そのノードで利用可能なPIDを使い切ることを防ぐことができます。管理者がCPUやメモリのようにPIDでもオーバーコミットを行いたい場合、同様にいくつかの追加のリスクがあります。いずれにしても、単一のPodがマシン全体をダウンさせることはできません。このようなリソース制限は単純なフォーク爆弾がクラスター全体の運用に影響を与えるのを防ぐのに役立ちます。
 
 PodごとのPID制限により、管理者はあるPodを他のPodから保護できますが、ホスト上にスケジュールされたすべてのPodがノード全体に影響を与えないことを保証するものではありません。Podごとの制限は、ノードエージェント自体をPID枯渇から保護するものでもありません。
 
@@ -44,7 +44,7 @@ KubernetesはPodで実行するプロセス数を制限することができま
 
 Podが誤操作していたり、異常なリソースを消費している時にPodの終了を実行することをkubeletに設定できます。この機能はEvictionと呼ばれています。様々なEvictionシグナルのために[リソース不足への対処の設定](/docs/concepts/scheduling-eviction/node-pressure-eviction/)ができます。`pid.available`Evictionシグナルを使用して、Podによって使用されるPIDの数の閾値を設定します。ソフトとハードのEvictionポリシーを設定できます。しかし、ハードEvictionポリシーを使用しても、PIDの数が非常に速く増加している場合、ノードはPID制限に達することで不安定な状態になる可能性があります。Evictionシグナルの値は定期的に計算されますが、この値は制限を強制するものではありません。
 
-PID制限 - Pod毎、ノード毎にハード制限を設定できます。一度制限に達すると、ワークロードは新しいPIDを取得しようとする際に失敗し始めます。これがPodの再スケジューリングにつながるかどうかは、ワークロードがこれらの失敗にどのように反応するか、PodのLiveness ProbeとReadiness Probeがどのように設定されているかに依存します。しかし、リミットが正しく設定されていれば、あるPodが誤動作している場合でも、他のPodのワークロードやシステムプロセスがPIDを使い果たすことはないと保証することができます。
+PIDの制限、つまりPod毎、ノード毎にハード制限を設定できます。一度制限に達すると、ワークロードは新しいPIDを取得しようとする際に失敗し始めます。これがPodの再スケジューリングにつながるかどうかは、ワークロードがこれらの失敗にどのように反応するか、PodのLiveness ProbeとReadiness Probeがどのように設定されているかに依存します。しかし、リミットが正しく設定されていれば、あるPodが誤動作している場合でも、他のPodのワークロードやシステムプロセスがPIDを使い果たすことはないと保証することができます。
 
 ## {{% heading "whatsnext" %}}