@@ -9,16 +9,13 @@ weight: 20
99
1010ReplicaSetの目的は、どのような時でも安定したレプリカPodのセットを維持することです。これは、理想的なレプリカ数のPodが利用可能であることを保証するものとして使用されます。
1111
12-
13-
14-
1512<!-- body -->
1613
17- ## ReplicaSetがどのように動くか
14+ ## ReplicaSetがどのように動くか {#how-a-replicaset-works}
1815
1916ReplicaSetは、ReplicaSetが対象とするPodをどう特定するかを示すためのセレクターや、稼働させたいPodのレプリカ数、Podテンプレート(理想のレプリカ数の条件を満たすために作成される新しいPodのデータを指定するために用意されるもの)といったフィールドとともに定義されます。ReplicaSetは、指定された理想のレプリカ数にするためにPodの作成と削除を行うことにより、その目的を達成します。ReplicaSetが新しいPodを作成するとき、ReplicaSetはそのPodテンプレートを使用します。
2017
21- ReplicaSetがそのPod群と連携するためのリンクは、Podの[ metadata.ownerReferences] ( /ja/docs/concepts/workloads/controllers/ garbage-collection/#owners-and -dependents ) というフィールド(現在のオブジェクトが所有されているリソースを指定する)を介して作成されます。ReplicaSetによって所持された全てのPodは、それらの` ownerReferences ` フィールドにReplicaSetを特定する情報を保持します。このリンクを通じて、ReplicaSetは管理しているPodの状態を把握したり、その後の実行計画を立てます。
18+ ReplicaSetがそのPod群と連携するためのリンクは、Podの[ metadata.ownerReferences] ( /ja/docs/concepts/architecture/ garbage-collection/#owners-dependents ) というフィールド(現在のオブジェクトが所有されているリソースを指定する)を介して作成されます。ReplicaSetによって所持された全てのPodは、それらの` ownerReferences ` フィールドにReplicaSetを特定する情報を保持します。このリンクを通じて、ReplicaSetは管理しているPodの状態を把握したり、その後の実行計画を立てます。
2219
2320ReplicaSetは、そのセレクターを使用することにより、所有するための新しいPodを特定します。もし` ownerReference ` フィールドの値を持たないPodか、` ownerReference ` フィールドの値が {{< glossary_tooltip text="コントローラー" term_id="controller" >}}でないPodで、そのPodがReplicaSetのセレクターとマッチした場合に、そのPodは即座にそのReplicaSetによって所有されます。
2421
@@ -56,7 +53,7 @@ kubectl describe rs/frontend
5653```
5754
5855その結果は以下のようになります。
59- ``` shell
56+ ```
6057Name: frontend
6158Namespace: default
6259Selector: tier=frontend
@@ -104,7 +101,7 @@ kubectl get pods frontend-b2zdv -o yaml
104101```
105102
106103その表示結果は、以下のようになります。その` frontend ` ReplicaSetの情報が` metadata ` の` ownerReferences ` フィールドにセットされています。
107- ``` shell
104+ ``` yaml
108105apiVersion : v1
109106kind : Pod
110107metadata :
@@ -149,7 +146,7 @@ kubectl get pods
149146```
150147
151148その表示結果で、新しいPodがすでに削除済みか、削除中のステータスになっているのを確認できます。
152- ``` shell
149+ ```
153150NAME READY STATUS RESTARTS AGE
154151frontend-b2zdv 1/1 Running 0 10m
155152frontend-vcmts 1/1 Running 0 10m
@@ -175,7 +172,7 @@ kubectl get pods
175172```
176173
177174取得結果は下記のようになります。
178- ``` shell
175+ ```
179176NAME READY STATUS RESTARTS AGE
180177frontend-hmmj2 1/1 Running 0 9s
181178pod1 1/1 Running 0 36s
@@ -188,7 +185,6 @@ pod2 1/1 Running 0 36s
188185
189186他の全てのKubernetes APIオブジェクトのように、ReplicaSetは` apiVersion ` 、` kind ` と` metadata ` フィールドを必要とします。
190187ReplicaSetでは、` kind ` フィールドの値は` ReplicaSet ` です。
191- Kubernetes1.9において、ReplicaSetは` apps/v1 ` というAPIバージョンが現在のバージョンで、デフォルトで有効です。` apps/v1beta2 ` というAPIバージョンは廃止されています。先ほど作成した` frontend.yaml ` ファイルの最初の行を参考にしてください。
192188
193189ReplicaSetオブジェクトの名前は、有効な
194190[ DNSサブドメイン名] ( /ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names ) である必要があります。
@@ -197,10 +193,10 @@ ReplicaSetオブジェクトの名前は、有効な
197193
198194### Pod テンプレート
199195
200- ` .spec.template ` はラベルを持つことが必要な[ Pod テンプレート ] ( /ja/docs/concepts/workloads/pods/#podテンプレート ) です。先ほど作成した` frontend.yaml ` の例では、` tier: frontend ` というラベルを1つ持っています。
196+ ` .spec.template ` はラベルを持つことが必要な[ Podテンプレート ] ( /ja/docs/concepts/workloads/pods/#pod-template ) です。先ほど作成した` frontend.yaml ` の例では、` tier: frontend ` というラベルを1つ持っています。
201197他のコントローラーがこのPodを所有しようとしないためにも、他のコントローラーのセレクターでラベルを上書きしないように注意してください。
202198
203- テンプレートの[ 再起動ポリシー] ( /docs/concepts/workloads/Pods /pod-lifecycle/#restart-policy ) のためのフィールドである` .spec.template.spec.restartPolicy ` は` Always ` のみ許可されていて、そしてそれがデフォルト値です。
199+ テンプレートの[ 再起動ポリシー] ( /ja/ docs/concepts/workloads/pods /pod-lifecycle/#restart-policy ) のためのフィールドである` .spec.template.spec.restartPolicy ` は` Always ` のみ許可されていて、そしてそれがデフォルト値です。
204200
205201### Pod セレクター
206202
@@ -229,10 +225,9 @@ matchLabels:
229225# ## ReplicaSetとPodの削除
230226
231227ReplicaSetとそれが所有する全てのPod削除したいときは、[`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete)コマンドを使ってください。
232- [ガベージコレクター](/ja/docs/concepts/workloads/controllers /garbage-collection/)がデフォルトで自動的に全ての依存するPodを削除します。
228+ [ガベージコレクター](/ja/docs/concepts/architecture /garbage-collection/)がデフォルトで自動的に全ての依存するPodを削除します。
233229
234- REST APIもしくは`client-go`ライブラリーを使用するとき、ユーザーは`-d`オプションで`propagationPolicy`を`Background`か`Foreground`と指定しなくてはなりません。
235- 例えば下記のように実行します。
230+ REST APIもしくは`client-go`ライブラリーを使用するとき、ユーザーは`-d`オプションで`propagationPolicy`を`Background`か`Foreground`と指定しなくてはなりません。例えば下記のように実行します。
236231` ` ` shell
237232kubectl proxy --port=8080
238233curl -X DELETE 'localhost:8080/apis/apps/v1/namespaces/default/replicasets/frontend' \
@@ -244,6 +239,8 @@ curl -X DELETE 'localhost:8080/apis/apps/v1/namespaces/default/replicasets/fron
244239
245240ユーザーは[`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete)コマンドで`--cascade=false`オプションを付けることにより、所有するPodに影響を与えることなくReplicaSetを削除できます。
246241REST APIもしくは`client-go`ライブラリーを使用するとき、ユーザーは`-d`オプションで`propagationPolicy`を`Orphan`と指定しなくてはなりません。
242+ 例えば下記のように実行します :
243+
247244` ` ` shell
248245kubectl proxy --port=8080
249246curl -X DELETE 'localhost:8080/apis/apps/v1/namespaces/default/replicasets/frontend' \
@@ -253,7 +250,7 @@ curl -X DELETE 'localhost:8080/apis/apps/v1/namespaces/default/replicasets/fron
253250
254251一度元のReplicaSetが削除されると、ユーザーは新しいものに置き換えるため新しいReplicaSetを作ることができます。新旧のReplicaSetの`.spec.selector`の値が同じである間、新しいReplicaSetは古いReplicaSetで稼働していたPodを取り入れます。
255252しかし、存在するPodが新しく異なるPodテンプレートとマッチさせようとするとき、この仕組みは機能しません。
256- ユーザーのコントロール下において新しいspecのPodをアップデートしたい場合は、[ローリングアップデート](#rolling-updates )を使用してください。
253+ ReplicaSetはローリングアップデートを直接サポートしないため、ユーザーのコントロール下においてPodを新しいspecにアップデートしたい場合は、[Deployment](/ja/docs/concepts/workloads/controllers/deployment/#creating-a-deployment )を使用してください。
257254
258255# ## PodをReplicaSetから分離させる
259256
@@ -264,6 +261,36 @@ curl -X DELETE 'localhost:8080/apis/apps/v1/namespaces/default/replicasets/fron
264261
265262ReplicaSetは、ただ`.spec.replicas`フィールドを更新することによって簡単にスケールアップまたはスケールダウンできます。ReplicaSetコントローラーは、ラベルセレクターにマッチするような指定した数のPodが利用可能であり、操作可能であることを保証します。
266263
264+ スケールダウンする場合、ReplicaSetコントローラーは以下の一般的なアルゴリズムに基づき、利用可能なPodをソートし、スケールダウンするPodの優先順位を付け、削除するPodを選択します :
265+ 1. 保留している(またはスケジュール不可な)Podが先にスケールダウンされます。
266+ 1. `controller.kubernetes.io/pod-deletion-cost`アノテーションが設定されている場合、値の小さいPodが優先されます。
267+ 1. レプリカ数の多いノード上のPodが、レプリカ数の少ないノード上のPodより優先されます。
268+ 1. Podの作成時間が異なる場合、より新しく作成されたPodが古いPodより優先されます(`LogarithmicScaleDown`[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)が有効の場合、作成時間は整数対数スケールでバケット化されます)。
269+
270+ 上記条件のすべてに該当する場合は、ランダム選択となります。
271+
272+ # ## Pod削除コスト
273+
274+ {{< feature-state for_k8s_version="v1.22" state="beta" >}}
275+
276+ [`controller.kubernetes.io/pod-deletion-cost`](/docs/reference/labels-annotations-taints/#pod-deletion-cost)アノテーションを使用すると、ReplicaSetをスケールダウンする際に、どのPodを最初に削除するかについて、ユーザーが優先順位を設定することができます。
277+
278+ アノテーションはPodに設定する必要があり、範囲は[-2147483647, 2147483647]になります。同じReplicaSetに属する他のPodと比較して、Podを削除する際のコストを表しています。削除コストの低いPodは、削除コストの高いPodより優先的に削除されます。
279+
280+ このアノテーションを設定しないPodは暗黙的に0と設定され、負の値は許容されます。
281+ 無効な値はAPIサーバーによって拒否されます。
282+
283+ この機能はbeta版で、デフォルトで有効になっています。kube-apiserverとkube-controller-managerで[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)`PodDeletionCost`を設定することで無効にすることができます。
284+
285+ {{< note >}}
286+ - これはベストエフォートで実行されているもので、Pod削除の順番を保証するものではありません。
287+ - ユーザーは、メトリック値に基づいてアノテーションを更新するなど、頻繁に更新することは避けるべきです。APIサーバー上で大量のPodの更新操作を発生させることになるためです。
288+ {{< /note >}}
289+
290+ # ### 使用事例
291+
292+ アプリケーションの異なるPodは、異なる使用レベルになる可能性があります。スケールダウンする場合、アプリケーションは使用率の低いPodを削除することを優先しています。Podを頻繁に更新することを避けるため、アプリケーションはスケールダウンする前に一度`controller.kubernetes.io/pod-deletion-cost`を更新する必要があります(アノテーションをPod使用レベルに比例する値に設定します)。Spark DeploymentのドライバーPodのように、アプリケーション自体がスケールダウンを制御する場合も機能します。
293+
267294# ## HorizontalPodAutoscaler(HPA)のターゲットとしてのReplicaSet
268295
269296ReplicaSetはまた、[Horizontal Pod Autoscalers (HPA)](/docs/tasks/run-application/horizontal-pod-autoscale/)のターゲットにもなることができます。
@@ -296,11 +323,11 @@ ReplicaSetは単独で使用可能ですが、現在では、ReplicaSetは主に
296323
297324ユーザーがPodを直接作成するケースとは異なり、ReplicaSetはNodeの故障やカーネルのアップグレードといった破壊的なNodeのメンテナンスなど、どのような理由に限らず削除または停止されたPodを置き換えます。
298325このため、我々はもしユーザーのアプリケーションが単一のPodのみ必要とする場合でもReplicaSetを使用することを推奨します。プロセスのスーパーバイザーについても同様に考えると、それは単一Node上での独立したプロセスの代わりに複数のNodeにまたがった複数のPodを監視します。
299- ReplicaSetは、Node上のいくつかのエージェント(例えば、KubeletやDocker）に対して 、ローカルのコンテナ再起動を移譲します。
326+ ReplicaSetは、KubeletのようなNode上のいくつかのエージェントに対して 、ローカルのコンテナ再起動を移譲します。
300327
301328# ## Job
302329
303- PodをPodそれ自身で停止させたいような場合(例えば、バッチ用のジョブなど)は、ReplicaSetの代わりに[`Job`](/docs/concepts/workloads/controllers/job/)を使用してください。
330+ PodをPodそれ自身で停止させたいような場合(例えば、バッチ用のジョブなど)は、ReplicaSetの代わりに[`Job`](/ja/ docs/concepts/workloads/controllers/job/)を使用してください。
304331
305332# ## DaemonSet
306333
@@ -313,4 +340,10 @@ ReplicaSetは[_ReplicationControllers_](/docs/concepts/workloads/controllers/rep
313340この2つは、ReplicationControllerが[ラベルについてのユーザーガイド](/ja/docs/concepts/overview/working-with-objects/labels/#label-selectors)に書かれているように、集合ベース(set-based)のセレクター要求をサポートしていないことを除いては、同じ目的を果たし、同じようにふるまいます。
314341このように、ReplicaSetはReplicationControllerよりも好まれます。
315342
343+ # # {{% heading "whatsnext" %}}
316344
345+ * [Pod](/ja/docs/concepts/workloads/pods/)について学ぶ。
346+ * [Deployment](/ja/docs/concepts/workloads/controllers/deployment/)について学ぶ。
347+ * ReplicaSetsに依存した[Deploymentを使用してステートレスアプリケーションを実行する](/ja/docs/tasks/run-application/run-stateless-application-deployment/)。
348+ * `ReplicaSet`はKubernetes REST APIのトップレベルのリソースです。{{< api-reference page="workload-resources/replica-set-v1" >}}オブジェクトの定義を読み、レプリカセットのAPIを理解する。
349+ * [PodDisruptionBudget](/docs/concepts/workloads/pods/disruptions/)について、またPodDisruptionBudgetで障害発生時のアプリケーションの可用性を管理する方法について読む。
0 commit comments