Update content/ja/docs/concepts/scheduling-eviction/assign-pod-node.md

Co-authored-by: Toshiaki Inukai <[email protected]>

Author: ziyi-xie

content/ja/docs/concepts/scheduling-eviction/assign-pod-node.md

@@ -228,7 +228,7 @@ Podアフィニティとアンチアフィニティの`operator`フィールド
 
 Pod間アフィニティとアンチアフィニティは、ReplicaSet、StatefulSet、Deploymentなどのより高レベルなコレクションと併せて使用するとさらに有用です。これらのルールにより、ワークロードのセットが同じ定義されたトポロジーに併置されるように設定できます。たとえば、2つの関連するPodを同じNodeに配置することが好ましい場合です。
 
-例えば、3つのNodeで構成されるクラスターを想像してください。クラスターを使用してウェブアプリケーションを実行し、さらにインメモリキャッシュ（Redisなど）を使用します。この例では、ウェブアプリケーションとメモリキャッシュの間のレイテンシーは実用的な範囲の低さも想定しています。Pod間アフィニティやアンチアフィニティを使って、ウェブサーバーとキャッシュをなるべく同じ場所に配置することができます。
+例えば、3つのNodeで構成されるクラスターを想像してください。そのクラスターを使用してウェブアプリケーションを実行し、さらにインメモリーキャッシュ(Redisなど)を使用します。この例では、ウェブアプリケーションとメモリーキャッシュの間のレイテンシーは実用的な範囲の低さも想定しています。Pod間アフィニティやアンチアフィニティを使って、ウェブサーバーとキャッシュをなるべく同じ場所に配置することができます。
 
 以下のRedisキャッシュのDeploymentの例では、各レプリカはラベル`app=store`が付与されています。`podAntiAffinity`ルールは、`app=store`ラベルを持つ複数のレプリカを単一Nodeに配置しないよう、スケジューラーに指示します。これにより、各キャッシュが別々のNodeに作成されます。