From e372fd718f718e840ef33f047c8265c46a153929 Mon Sep 17 00:00:00 2001 From: FeLvi-zzz <34182539+FeLvi-zzz@users.noreply.github.com> Date: Mon, 23 Jan 2023 23:26:01 +0900 Subject: [PATCH] [ja] add docs for owners-dependents --- .../working-with-objects/owners-dependents.md | 63 +++++++++++++++++++ 1 file changed, 63 insertions(+) create mode 100644 content/ja/docs/concepts/overview/working-with-objects/owners-dependents.md diff --git a/content/ja/docs/concepts/overview/working-with-objects/owners-dependents.md b/content/ja/docs/concepts/overview/working-with-objects/owners-dependents.md new file mode 100644 index 0000000000..2f7315c9f8 --- /dev/null +++ b/content/ja/docs/concepts/overview/working-with-objects/owners-dependents.md @@ -0,0 +1,63 @@ +--- +title: オーナーと従属 +content_type: concept +weight: 90 +--- + + + +Kubernetesでは、いくつかのオブジェクトは他のオブジェクトの*オーナー*になっています。 +例えば、{{}}はPodの集合のオーナーです。 +これらの所有されているオブジェクトはオーナーに*従属*しています。 + +オーナーシップはいくつかのリソースでも使われている[ラベルとセレクター](/ja/docs/concepts/overview/working-with-objects/labels/)とは仕組みが異なります。 +例として、`EndpointSlice`オブジェクトを作成するServiceオブジェクトを考えてみます。 +Serviceはラベルを使ってどの`EndpointSlice`がどのServiceに利用されているかをコントロールプレーンに判断させています。 +ラベルに加えて、Serviceの代わりに管理される各`EndpointSlice`はオーナーリファレンスを持ちます。 +オーナーリファレンスは、Kubernetesの様々な箇所で管理外のオブジェクトに干渉してしまうのを避けるのに役立ちます。 + +## オブジェクト仕様におけるオーナーリファレンス + +従属オブジェクトはオーナーオブジェクトを参照するための`metadata.ownerReferences`フィールドを持っています。 +有効なオーナーリファレンスは従属オブジェクトと同じ名前空間に存在するオブジェクトの名前とUIDで構成されます。 +KubernetesはReplicaSet、DaemonSet、Deployment、Job、CronJob、ReplicationControllerのようなオブジェクトの従属オブジェクトに、自動的に値を設定します。 +このフィールドの値を手動で変更することで、これらの関係性を自分で設定することもできます。 +ただし、通常はその必要はなく、Kubernetesが自動で管理するようにすることができます。 + +従属オブジェクトは、オーナーオブジェクトが削除されたときにガベージコレクションをブロックするかどうかを管理する真偽値を取る`ownerReferences.blockOwnerDeletion`フィールドも持っています。 +Kubernetesは、{{}} +(例:Deploymentコントローラー)が`metadata.ownerReferences`フィールドに値を設定している場合、自動的にこのフィールドを`true`に設定します。 +`blockOwnerDeletion`フィールドに手動で値を設定することで、どの従属オブジェクトがガベージコレクションをブロックするかを設定することもできます。 + +Kubernetesのアドミッションコントローラーはオーナーの削除権限に基づいて、ユーザーが従属リソースのこのフィールドを変更できるかを管理しています。 +これにより、認証されていないユーザーがオーナーオブジェクトの削除を遅らせることを防ぎます。 + +{{< note >}} +名前空間をまたぐオーナーリファレンスは仕様により許可されていません。 +名前空間付き従属オブジェクトには、クラスタースコープ、または名前空間付きのオーナーを指定することができます。名前空間付きオーナーは**必ず**従属オブジェクトと同じ名前空間に存在していなければなりません。 +そうでない場合、オーナーリファレンスはないものとして扱われ、全てのオーナーがいなくなった時点で従属オブジェクトは削除対象となります。 + +クラスタースコープの従属オブジェクトはクラスタースコープのオーナーのみ指定できます。 +v1.20以降では、クラスタースコープの従属オブジェクトが名前空間付きのオブジェクトをオーナーとした場合、 +解決できないオーナーリファレンスを持っているものとして扱われ、ガベージコレクションの対象とすることができません。 + +v1.20以降で、ガベージコレクターが無効な名前空間またぎの`ownerReference`や名前空間付きのオーナーに依存するクラスタースコープのオブジェクトなどを検知した場合、`OwnerRefInvalidNamespace`を理由とした警告のEventを出し、`involvedObject`で無効な従属オブジェクトを報告します。 +`kubectl get events -A --field-selector=reason=OwnerRefInvalidNamespace`を実行することで、この種類のEventを確認することができます。 +{{< /note >}} + +## オーナーシップとファイナライザー + +Kubernetesでリソースを削除するとき、APIサーバーはリソースを管理するコントローラーに[ファイナライザールール](/ja/docs/concepts/overview/working-with-objects/finalizers/)を処理させることができます。 +{{}}はクラスターが正しく機能するために必要なリソースを誤って削除してしまうことを防ぎます。 +例えば、まだPodが使用中の`PersistentVolume`を削除しようとするとき、`PersistentVolume`が持っている`kubernetes.io/pv-protection`ファイナライザーにより、削除は即座には行われません。 +その代わり、Kubernetesがファイナライザーを削除するまでボリュームは`Terminating`ステータスのまま残り、`PersistentVolume`がPodにバインドされなくなった後で削除が行われます。 + +またKubernetesは[フォアグラウンド、孤立したオブジェクトのカスケード削除](/ja/docs/concepts/architecture/garbage-collection/#cascading-deletion)を行ったとき、オーナーリソースにファイナライザーを追加します。 +フォアグラウンド削除では、`foreground`ファイナライザーを追加し、オーナーを削除する前にコントローラーが`ownerReferences.blockOwnerDeletion=true`を持っている従属リソースを削除するようにします。 +孤立したオブジェクトの削除を行う場合、Kubernetesは`orphan`ファイナライザーを追加し、オーナーオブジェクトを削除した後にコントローラーが従属リソースを無視するようにします。 + +## {{% heading "whatsnext" %}} + +* [Kubernetesのファイナライザー](/ja/docs/concepts/overview/working-with-objects/finalizers/)についてさらに学習しましょう。 +* [ガベージコレクション](/ja/docs/concepts/architecture/garbage-collection)について学習しましょう。 +* [オブジェクトのメタデータ](/docs/reference/kubernetes-api/common-definitions/object-meta/#System)のAPIリファレンスをご覧ください。 \ No newline at end of file