Change:
image: nginx:1.16-alpine ``` <del> 上記2つのDeploymentが生成されると、3つのノードは以下のようになります。 </del> <ins> 上記2つのDeploymentが生成されると、以下のようなクラスター構成になり、各ウェブサーバーはキャッシュと同位置に、3つの別々のNodeに配置されます。 </ins> |       node-1         |       node-2        |       node-3       | |:--------------------:|:-------------------:|:------------------:| | *webserver-1*        |   *webserver-2*     |    *webserver-3*   | |  *cache-1*           |     *cache-2*       |     *cache-3*      | <del> このように、3つの`web-server`は期待通り自動的にキャッシュと共存しています。 ``` kubectl get pods -o wide ``` 出力は以下のようになります: ``` NAME                           READY     STATUS    RESTARTS   AGE       IP           NODE redis-cache-1450370735-6dzlj   1/1       Running   0          8m        10.192.4.2   kube-node-3 redis-cache-1450370735-j2j96   1/1       Running   0          8m        10.192.2.2   kube-node-1 redis-cache-1450370735-z73mh   1/1       Running   0          8m        10.192.3.1   kube-node-2 web-server-1287567482-5d4dz    1/1       Running   0          7m        10.192.2.3   kube-node-1 web-server-1287567482-6f7v5    1/1       Running   0          7m        10.192.4.3   kube-node-3 web-server-1287567482-s330j    1/1       Running   0          7m        10.192.3.2   kube-node-2 ``` ##### 同じNodeに共存させない場合 上記の例では `PodAntiAffinity`を`topologyKey: "kubernetes.io/hostname"`と合わせて指定することで、redisクラスター内の2つのインスタンスが同じホストにデプロイされない場合を扱いました。 同様の方法で、アンチアフィニティを用いて高可用性を実現したStatefulSetの使用例は[ZooKeeper tutorial](/docs/tutorials/stateful-application/zookeeper/#tolerating-node-failure)を参照してください。 </del> <ins> 全体的な効果として、各キャッシュインスタンスは、同じNode上で実行している単一のクライアントによってアクセスされる可能性が高いです。この方法は、スキュー(負荷の偏り)とレイテンシーの両方を最小化することを目的としています。 Podアンチアフィニティを使用する理由は他にもあります。 この例と同様の方法で、アンチアフィニティを用いて高可用性を実現したStatefulSetの使用例は[ZooKeeperチュートリアル](/docs/tutorials/stateful-application/zookeeper/#tolerating-node-failure)を参照してください。 </ins> ## nodeName <del> `nodeName`はNodeの選択を制限する最も簡単な方法ですが、制約があることからあまり使用されません。 `nodeName`はPodSpecのフィールドです。 ここに値が設定されると、schedulerはそのPodを考慮しなくなり、その名前が付与されているNodeのkubeletはPodを稼働させようとします。 そのため、PodSpecに`nodeName`が指定されると、上述のNodeの選択方法よりも優先されます。 </del> <ins> `nodeName`はアフィニティや`nodeSelector`よりも直接的なNode選択形式になります。`nodeName`はPod仕様(spec)内のフィールドです。`nodeName`フィールドが空でない場合、スケジューラーはPodを考慮せずに、指定されたNodeにあるkubeletがそのNodeにPodを配置しようとします。`nodeName`を使用すると、`nodeSelector`やアフィニティおよびアンチアフィニティルールを使用するよりも優先されます。 </ins> <del> `nodeName`を使用することによる制約は以下の通りです: </del> <ins> `nodeName`を使ってNodeを選択する場合の制約は以下の通りです: </ins> <del> -   その名前のNodeが存在しない場合、Podは起動されす、自動的に削除される場合があります。 -   その名前のNodeにPodを稼働させるためのリソースがない場合、Podの起動は失敗し、理由は例えばOutOfmemoryやOutOfcpuになります。 -   クラウド上のNodeの名前は予期できず、変更される可能性があります。 </del> <ins> -   指定されたNodeが存在しない場合、Podは実行されず、場合によっては自動的に削除されることがあります。 -   指定されたNodeがPodを収容するためのリソースを持っていない場合、Podの起動は失敗し、OutOfmemoryやOutOfcpuなどの理由が表示されます。 -   クラウド環境におけるNode名は、常に予測可能で安定したものではありません。 </ins> <del> `nodeName`を指定したPodの設定ファイルの例を示します: </del> <ins> {{< note >}} `nodeName`は、カスタムスケジューラーや、設定済みのスケジューラーをバイパスする必要がある高度なユースケースで使用することを目的としています。 スケジューラーをバイパスすると、割り当てられたNodeに過剰なPodの配置をしようとした場合には、Podの起動に失敗することがあります。 [Nodeアフィニティ](#node-affinity)または[`nodeSelector`フィールド](#nodeselector)を使用すれば、スケジューラーをバイパスせずに、特定のNodeにPodを割り当てることができます。 {{</ note >}} 以下は、`nodeName`フィールドを使用したPod仕様(spec)の例になります: </ins> ```yaml apiVersion: v1

Discussion:
This is a Feature Request <!-- Please only use this template for submitting feature/enhancement requests --<!-- See for guidance on writing an actionable issue description. --What would you like to be <!-- Describe as precisely as possible how this feature/enhancement should work from the user perspective. What should be changed, etc. --Updated Japanese translation for the file. Why is this needed There are several updates in and therefore this page is outdated. Comments <!-- Any additional related comments that might help. Drawings/mockups would be extremely helpful (if required). --/language ja /assign
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details