Merge pull request #40150 from s-kawamura-w664/remove_gc_pages
[ja] Remove two pages of garbage collectionpull/35113/head^2
Kubernetes Prow Robot
GitHub
commit
768d6ae49f
|
|
@ -1,67 +0,0 @@
|
|||
---
|
||||
title: コンテナイメージのガベージコレクション
|
||||
content_type: concept
|
||||
weight: 70
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
ガベージコレクションは、未使用の[イメージ](/ja/docs/concepts/containers/#container-images)と未使用の[コンテナ](/ja/docs/concepts/containers/)をクリーンアップするkubeletの便利な機能です。kubeletコンテナのガベージコレクションを1分ごとに行い、イメージのガベージコレクションは5分ごとに行います。
|
||||
|
||||
存在することが期待されているコンテナを削除してkubeletの動作を壊す可能性があるため、外部のガベージコレクションのツールは推奨されません。
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## イメージのガベージコレクション
|
||||
|
||||
Kubernetesでは、すべてのイメージのライフサイクルの管理はcadvisorと協調してimageManager経由で行います。
|
||||
|
||||
イメージのガベージコレクションのポリシーについて考えるときは、`HighThresholdPercent`および`LowThresholdPercent`という2つの要因について考慮する必要があります。ディスク使用量がhigh thresholdを超えると、ガベージコレクションがトリガされます。ガベージコレクションは、low
|
||||
thresholdが満たされるまで、最後に使われてから最も時間が経った(least recently used)イメージを削除します。
|
||||
|
||||
## コンテナのガベージコレクション
|
||||
|
||||
コンテナのガベージコレクションのポリシーは、3つのユーザー定義の変数を考慮に入れます。`MinAge`は、ガベージコレクションできるコンテナの最小の年齢です。`MaxPerPodContainer`は、すべての単一のPod(UID、コンテナ名)が保持することを許されているdead状態のコンテナの最大値です。`MaxContainers`はdead状態のコンテナの合計の最大値です。これらの変数は、`MinAge`は0に、`MaxPerPodContainer`と`MaxContainers`は0未満にそれぞれ設定することで個別に無効にできます。
|
||||
|
||||
kubeletは、未指定のコンテナ、削除されたコンテナ、前述のフラグにより設定された境界の外にあるコンテナに対して動作します。一般に、最も古いコンテナが最初に削除されます。`MaxPerPodContainer`と`MaxContainer`は、Podごとの保持するコンテナの最大値(`MaxPerPodContainer`)がグローバルのdead状態のコンテナの許容範囲(`MaxContainers`)外である場合には、互いに競合する可能性があります。このような状況では、`MaxPerPodContainer`が調整されます。最悪のケースのシナリオでは、`MaxPerPodContainer`が1にダウングレードされ、最も古いコンテナが強制退去されます。さらに、`MinAge`より古くなると、削除済みのPodが所有するコンテナが削除されます。
|
||||
|
||||
kubeletによって管理されないコンテナは、コンテナのガベージコレクションの対象にはなりません。
|
||||
|
||||
## ユーザー設定
|
||||
|
||||
イメージのガベージコレクションを調整するために、以下のkubeletのフラグを使用して次のようなしきい値を調整できます。
|
||||
|
||||
1. `image-gc-high-threshold`: イメージのガベージコレクションをトリガするディスク使用量の割合(%)。デフォルトは85%。
|
||||
2. `image-gc-low-threshold`: イメージのガベージコレクションが解放を試みるディスク使用量の割合(%)。デフォルトは80%。
|
||||
|
||||
ガベージコレクションのポリシーは、以下のkubeletのフラグを使用してカスタマイズできます。
|
||||
|
||||
1. `minimum-container-ttl-duration`: 完了したコンテナがガベージコレクションされる前に経過するべき最小期間。デフォルトは0分です。つまり、すべての完了したコンテナはガベージコレクションされます。
|
||||
2. `maximum-dead-containers-per-container`: コンテナごとに保持される古いインスタンスの最大値です。デフォルトは1です。
|
||||
3. `maximum-dead-containers`: グローバルに保持するべき古いコンテナのインスタンスの最大値です。デフォルトは-1です。つまり、グローバルなリミットは存在しません。
|
||||
|
||||
コンテナは役に立たなくなる前にガベージコレクションされる可能性があります。こうしたコンテナには、トラブルシューティングに役立つログや他のデータが含まれるかもしれません。そのため、期待されるコンテナごとに最低でも1つのdead状態のコンテナが許容されるようにするために、`maximum-dead-containers-per-container`には十分大きな値を設定することが強く推奨されます。同様の理由で、`maximum-dead-containers`にも、より大きな値を設定することが推奨されます。詳しくは、[こちらのissue](https://github.com/kubernetes/kubernetes/issues/13287)を読んでください。
|
||||
|
||||
## 廃止
|
||||
|
||||
このドキュメントにあるkubeletの一部のガベージコレクションの機能は、将来kubelet evictionで置換される予定です。
|
||||
|
||||
これには以下のものが含まれます。
|
||||
|
||||
| 既存のフラグ | 新しいフラグ | 理由 |
|
||||
| ------------- | -------- | --------- |
|
||||
| `--image-gc-high-threshold` | `--eviction-hard`または`--eviction-soft` | 既存のevictionのシグナルがイメージのガベージコレクションをトリガする可能性がある |
|
||||
| `--image-gc-low-threshold` | `--eviction-minimum-reclaim` | eviction reclaimが同等の動作を実現する |
|
||||
| `--maximum-dead-containers` | | 古いログがコンテナのコンテキストの外部に保存されるようになったら廃止 |
|
||||
| `--maximum-dead-containers-per-container` | | 古いログがコンテナのコンテキストの外部に保存されるようになったら廃止 |
|
||||
| `--minimum-container-ttl-duration` | | 古いログがコンテナのコンテキストの外部に保存されるようになったら廃止 |
|
||||
| `--low-diskspace-threshold-mb` | `--eviction-hard` or `eviction-soft` | evictionはディスクのしきい値を他のリソースに一般化している |
|
||||
| `--outofdisk-transition-frequency` | `--eviction-pressure-transition-period` | evictionはディスクのpressure transitionを他のリソースに一般化している |
|
||||
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
詳細については、[リソース不足のハンドリング方法を設定する](/docs/tasks/administer-cluster/out-of-resource/)を参照してください。
|
||||
|
||||
|
|
@ -1,147 +0,0 @@
|
|||
---
|
||||
title: ガベージコレクション
|
||||
content_type: concept
|
||||
weight: 60
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
Kubernetesのガベージコレクターの役割は、かつてオーナーがいたが、現時点でもはやオーナーがいないようなオブジェクトの削除を行うことです。
|
||||
|
||||
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## オーナーとその従属オブジェクト {#owners-and-dependents}
|
||||
|
||||
いくつかのKubernetesオブジェクトは他のオブジェクトのオーナーとなります。例えば、ReplicaSetはPodのセットに対するオーナーです。オーナーによって所有されたオブジェクトは、オーナーオブジェクトの*従属オブジェクト(Dependents)* と呼ばれます。全ての従属オブジェクトは、オーナーオブジェクトを指し示す`metadata.ownerReferences`というフィールドを持ちます。
|
||||
|
||||
時々、Kubernetesは`ownerReference`フィールドに値を自動的にセットします。例えば、ユーザーがReplicaSetを作成したとき、KubernetesはReplicaSet内の各Podの`ownerReference`フィールドに自動的に値をセットします。Kubernetes1.8において、KubernetesはReplicaController、ReplicaSet、StatefulSet、DaemonSet、Deployment、Job、CronJobによって作成され、適用されたオブジェクトの`ownerReference`フィールドに自動的にその値をセットします。
|
||||
|
||||
ユーザーはまた`ownerReference`フィールドに手動で値をセットすることにより、オーナーと従属オブジェクト間の関係を指定することができます。
|
||||
|
||||
下記の例は、3つのPodを持つReplicaSetの設定ファイルとなります。
|
||||
|
||||
{{< codenew file="controllers/replicaset.yaml" >}}
|
||||
|
||||
もしユーザーがReplicaSetを作成し、Podのメタデータを見る時、`ownerReference`フィールドの値を確認できます。
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/controllers/replicaset.yaml
|
||||
kubectl get pods --output=yaml
|
||||
```
|
||||
|
||||
その出力結果によると、そのPodのオーナーは`my-repset`という名前のReplicaSetです。
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
...
|
||||
ownerReferences:
|
||||
- apiVersion: apps/v1
|
||||
controller: true
|
||||
blockOwnerDeletion: true
|
||||
kind: ReplicaSet
|
||||
name: my-repset
|
||||
uid: d9607e19-f88f-11e6-a518-42010a800195
|
||||
...
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
ネームスペースをまたいだownerReferenceは意図的に許可されていません。これは以下のことを意味します。
|
||||
1) ネームスペース内のスコープの従属オブジェクトは、同一のネームスペース内のオーナーと、クラスターのスコープ内のオーナーのみ指定できます。
|
||||
2) クラスターのスコープ内の従属オブジェクトは、クラスターのスコープ内のオーナーオブジェクトのみ指定でき、ネームスペース内のスコープのオーナーオブジェクトは指定できません。
|
||||
{{< /note >}}
|
||||
|
||||
## ガベージコレクターがどのように従属オブジェクトの削除をするかを制御する
|
||||
|
||||
ユーザーがオブジェクトを削除するとき、それに紐づく従属オブジェクトも自動で削除するか指定できます。従属オブジェクトの自動削除は、*カスケード削除(Cascading deletion)* と呼ばれます。*カスケード削除* には2つのモードがあり、*バックグラウンド* と*フォアグラウンド* があります。
|
||||
|
||||
もしユーザーが、従属オブジェクトの自動削除なしにあるオブジェクトを削除する場合、その従属オブジェクトは*みなしご(orphaned)* と呼ばれます。
|
||||
|
||||
### フォアグラウンドのカスケード削除
|
||||
|
||||
*フォアグラウンドのカスケード削除* において、そのルートオブジェクトは最初に"削除処理中"という状態に遷移します。その*削除処理中* 状態において、下記の項目は正となります。
|
||||
|
||||
* そのオブジェクトはREST APIを介して確認可能です。
|
||||
* そのオブジェクトの`deletionTimestamp`がセットされます。
|
||||
* そのオブジェクトの`metadata.finalizers`フィールドは、`foregroundDeletion`という値を含みます。
|
||||
|
||||
一度"削除処理中"状態に遷移すると、そのガベージコレクターはオブジェクトの従属オブジェクトを削除します。一度そのガベージコレクターが全ての”ブロッキングしている”従属オブジェクトを削除すると(`ownerReference.blockOwnerDeletion=true`という値を持つオブジェクト)、それはオーナーのオブジェクトも削除します。
|
||||
|
||||
注意点として、"フォアグラウンドのカスケード削除"において、`ownerReference.blockOwnerDeletion=true`フィールドを持つ従属オブジェクトのみ、そのオーナーオブジェクトの削除をブロックします。
|
||||
Kubernetes1.7では、認証されていない従属オブジェクトがオーナーオブジェクトの削除を遅らせることができないようにするために[アドミッションコントローラー](/docs/reference/access-authn-authz/admission-controllers/#ownerreferencespermissionenforcement)が追加され、それは、オーナーオブジェクトの削除パーミッションに基づいて`blockOwnerDeletion`の値がtrueに設定してユーザーアクセスをコントロールします。
|
||||
|
||||
もしオブジェクトの`ownerReferences`フィールドがコントローラー(DeploymentやReplicaSetなど)によってセットされている場合、`blockOwnerDeletion`は自動的にセットされ、ユーザーはこのフィールドを手動で修正する必要はありません。
|
||||
|
||||
### バックグラウンドのカスケード削除
|
||||
|
||||
*バックグラウンドのカスケード削除* において、Kubernetesはそのオーナーオブジェクトを即座に削除し、ガベージコレクションはその従属オブジェクトをバックグラウンドで削除します。
|
||||
|
||||
### カスケード削除ポリシーの設定
|
||||
|
||||
カスケード削除ポリシーを制御するためには、オブジェクトをいつ設定するか`deleteOptions`引数上の`propagationPolicy`フィールドに設定してください。設定可能な値は`Orphan`、`Foreground`、もしくは`Background`のどれかです。
|
||||
|
||||
|
||||
下記のコマンドは従属オブジェクトをバックグラウンドで削除する例です。
|
||||
|
||||
```shell
|
||||
kubectl proxy --port=8080
|
||||
curl -X DELETE localhost:8080/apis/apps/v1/namespaces/default/replicasets/my-repset \
|
||||
-d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Background"}' \
|
||||
-H "Content-Type: application/json"
|
||||
```
|
||||
|
||||
下記のコマンドは従属オブジェクトをフォアグラウンドで削除する例です。
|
||||
|
||||
```shell
|
||||
kubectl proxy --port=8080
|
||||
curl -X DELETE localhost:8080/apis/apps/v1/namespaces/default/replicasets/my-repset \
|
||||
-d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Foreground"}' \
|
||||
-H "Content-Type: application/json"
|
||||
```
|
||||
|
||||
下記のコマンドは従属オブジェクトをみなしご状態になった従属オブジェクトの例です。
|
||||
|
||||
```shell
|
||||
kubectl proxy --port=8080
|
||||
curl -X DELETE localhost:8080/apis/apps/v1/namespaces/default/replicasets/my-repset \
|
||||
-d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Orphan"}' \
|
||||
-H "Content-Type: application/json"
|
||||
```
|
||||
|
||||
kubectlもまたカスケード削除をサポートしています。
|
||||
kubectlを使って従属オブジェクトを自動的に削除するためには、`--cascade`をtrueにセットしてください。
|
||||
従属オブジェクトを削除せず、みなしご状態にするには`--cascade`をfalseにセットしてください。
|
||||
`--cascade`オプションのデフォルト値はtrueになります。
|
||||
|
||||
下記のコマンドは、ReplicaSetを削除し、その従属オブジェクトをみなしご状態にします。
|
||||
|
||||
```shell
|
||||
kubectl delete replicaset my-repset --cascade=false
|
||||
```
|
||||
|
||||
### Deploymentsに関する追記事項
|
||||
|
||||
Kubernetes1.7以前では、Deploymentに対するカスケード削除において、作成されたReplicaSetだけでなく、それらのPodも削除するためには、ユーザーは`propagationPolicy: Foreground`と指定*しなくてはなりません* 。もしこのタイプの*propagationPolicy*が使われなかった場合、そのReplicaSetは削除されますが、そのPodは削除されずみなしご状態になります。
|
||||
さらなる詳細に関しては[kubeadm/#149](https://github.com/kubernetes/kubeadm/issues/149#issuecomment-284766613)を参照してください。
|
||||
|
||||
## 既知の問題について
|
||||
|
||||
[#26120](https://github.com/kubernetes/kubernetes/issues/26120)にてイシューがトラックされています。
|
||||
|
||||
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
[Design Doc 1](https://git.k8s.io/community/contributors/design-proposals/api-machinery/garbage-collection.md)
|
||||
|
||||
[Design Doc 2](https://git.k8s.io/community/contributors/design-proposals/api-machinery/synchronous-garbage-collection.md)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Loading…
Reference in New Issue