翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # [Storage (ストレージ)] ## 概要 短期または長期でデータを保存する必要があるアプリケーションを実行するシナリオがあります。このようなユースケースでは、ポッドによってボリュームを定義およびマウントして、コンテナが異なるストレージメカニズムを利用できるようにします。Kubernetes は、エフェメラルストレージと永続ストレージのさまざまなタイプの[ボリューム](https://kubernetes.io/docs/concepts/storage/volumes/)をサポートしています。ストレージの選択は、アプリケーションの要件に大きく依存します。各アプローチにはコストへの影響があり、以下に説明するプラクティスは、EKS 環境で何らかの形式のストレージを必要とするワークロードのコスト効率を実現するのに役立ちます。 ## エフェメラルボリューム エフェメラルボリュームは、一時的なローカルボリュームを必要とするが、再起動後にデータを保持する必要がないアプリケーション用です。これには、スクラッチスペース、キャッシュ、設定データやシークレットなどの読み取り専用入力データの要件が含まれます。Kubernetes エフェメラルボリュームの詳細については、[こちらを参照してください](https://kubernetes.io/docs/concepts/storage/ephemeral-volumes/)。ほとんどのエフェメラルボリューム (例: emptyDir、configMap、downwardAPI、シークレット、ホストパス) は、ローカルにアタッチされた書き込み可能デバイス (通常はルートディスク) または RAM によってバックアップされるため、最もコスト効率が高くパフォーマンスの高いホストボリュームを選択することが重要です。 ### EBS ボリュームの使用 *ホストルートボリュームとして [gp3](https://aws.amazon.com/ebs/general-purpose/) から開始することをお勧めします。*これは Amazon EBS が提供する最新の汎用 SSD ボリュームであり、gp2 ボリュームと比較して GB あたり低価格 (最大 20%) を提供します。 ### Amazon EC2 インスタンスストアの使用 [Amazon EC2 インスタンスストア](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/InstanceStorage.html)は、EC2 インスタンスに一時的なブロックレベルのストレージを提供します。EC2 インスタンスストアが提供するストレージは、ホストに物理的にアタッチされたディスクからアクセスできます。Amazon EBS とは異なり、インスタンスストアボリュームはインスタンスの起動時にのみアタッチでき、これらのボリュームはインスタンスの存続期間中にのみ存在します。他のインスタンスにデタッチおよび再アタッチすることはできません。Amazon EC2 インスタンスストアの詳細については、[こちらを参照してください](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/InstanceStorage.html)。*インスタンスストアボリュームには追加料金はかかりません。*これにより、EBS ボリュームが大きい一般的な EC2 インスタンスよりも*コスト効率が高くなります* (インスタンスストアボリューム）。 Kubernetes でローカルストアボリュームを使用するには、[Amazon EC2 ユーザーデータを使用してディスクを](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instancedata-add-user-data.html)パーティション化、設定、フォーマットし、ポッド仕様でボリュームを [HostPath](https://kubernetes.io/docs/concepts/storage/volumes/#hostpath) としてマウントできるようにする必要があります。または、[Local Persistent Volume Static Provisioner](https://github.com/kubernetes-sigs/sig-storage-local-static-provisioner) を活用して、ローカルストレージ管理を簡素化することもできます。Local Persistent Volume 静的プロビジョナーを使用すると、標準の Kubernetes PersistentVolumeClaim (PVC) インターフェイスを介してローカルインスタンスストアボリュームにアクセスできます。さらに、ノードアフィニティ情報を含む PersistentVolumes (PVs) をプロビジョニングして、Pod を正しいノードにスケジュールします。Kubernetes PersistentVolumes を使用していますが、EC2 インスタンスストアボリュームは本質的にエフェメラルです。エフェメラルディスクに書き込まれたデータは、インスタンスの存続期間中にのみ使用できます。インスタンスが終了すると、 もデータになります。詳細については、この[ブログ](https://aws.amazon.com/blogs/containers/eks-persistent-volumes-for-instance-store/)を参照してください。 Amazon EC2 インスタンスストアボリュームを使用する場合、合計 IOPS 制限はホストと共有され、ポッドを特定のホストにバインドすることに注意してください。Amazon EC2 インスタンスストアボリュームを採用する前に、ワークロードの要件を徹底的に確認する必要があります。 ## 永続ボリューム Kubernetes は通常、実行中のステートレスアプリケーションに関連付けられます。ただし、1 つのリクエストから次のリクエストまで永続的なデータや情報を保持する必要があるマイクロサービスを実行するシナリオがあります。データベースは、このようなユースケースの一般的な例です。ただし、ポッドとその中のコンテナまたはプロセスは、本質的にエフェメラルです。Pod の存続期間を超えてデータを保持するには、PVs を使用して、Pod から独立した特定の場所にあるストレージへのアクセスを定義できます。*PVs に関連するコストは、使用されているストレージのタイプとアプリケーションによる消費方法に大きく依存します。* Amazon EKS の Kubernetes PVs をサポートするストレージオプションには、さまざまなタイプ[があります](https://docs.aws.amazon.com/eks/latest/userguide/storage.html)。以下に説明するストレージオプションは、Amazon EBS、Amazon EFS、Amazon FSx for Lustre、Amazon FSx for NetApp ONTAP です。 ### Amazon Elastic Block Store (EBS) ボリューム Amazon EBS ボリュームは、Kubernetes PVs として使用して、ブロックレベルのストレージボリュームを提供できます。これらは、ランダムな読み取りと書き込みに依存するデータベースや、長時間の継続的な読み取りと書き込みを実行するスループットを多用するアプリケーションに適しています。[Amazon Elastic Block Store Container Storage Interface (CSI) ドライバー](https://docs.aws.amazon.com/eks/latest/userguide/ebs-csi.html)を使用すると、Amazon EKS クラスターは永続的ボリュームの Amazon EBS ボリュームのライフサイクルを管理できます。Container Storage Interface は、Kubernetes とストレージシステム間のインタラクションを有効にし、容易にします。CSI ドライバーを EKS クラスターにデプロイすると、永続ボリューム (PVs)、永続ボリュームクレーム (PVCs)、ストレージクラス (SCs) などのネイティブ Kubernetes ストレージリソースを介してその機能にアクセスできます。この[リンク](https://github.com/kubernetes-sigs/aws-ebs-csi-driver/tree/master/examples/kubernetes)では、Amazon EBS ボリュームを Amazon EBS CSI ドライバーとやり取りする方法の実例を示します。 #### 適切なボリュームの選択 *価格とパフォーマンスの適切なバランスを実現するため、最新世代のブロックストレージ (gp3) を使用することをお勧めします*。また、追加のブロックストレージ容量をプロビジョニングすることなく、ボリュームサイズに関係なくボリューム IOPS とスループットをスケールすることもできます。現在 gp2 ボリュームを使用している場合は、gp3 ボリュームへの移行を強くお勧めします。ブログ記事[「Amazon EKS クラスターを gp2 から gp3 EBS ボリュームに移行する](https://aws.amazon.com/blogs/containers/migrating-amazon-eks-clusters-from-gp2-to-gp3-ebs-volumes/)[」では、アプリケーションのダウンタイムを必要とする CSI ボリュームスナップショット](https://kubernetes.io/docs/concepts/storage/volume-snapshots/)機能を使用して、バックアップと復元を使用して Amazon EKS クラスターの *gp3* 上の gp*2* から移行する方法について説明します。 Amazon EBS では、ボリュームサイズ、IOPS、スループットなどのボリューム特性をオンラインで変更できます。この機能を使用すると、この[ブログ](https://aws.amazon.com/blogs/storage/simplifying-amazon-ebs-volume-migration-and-modification-using-the-ebs-csi-driver/)で説明されているように、EBS CSI ドライバー v1.19.0 以降を必要とする PVC 注釈を使用するか、[ここで](https://aws.amazon.com/blogs/containers/modify-amazon-ebs-volumes-on-kubernetes-with-volume-attributes-classes/)説明されている [VolumeAttributesClass API](https://kubernetes.io/docs/concepts/storage/volume-attributes-classes/) を使用して Amazon EKS v1.31 および EBS CSI ドライバー 1.35 から始めることで、アプリケーションのダウンタイムなしで ***gp*3 上の gp2 から移行できます。 1 つの [gp3 ボリュームがサポートできる](https://aws.amazon.com/ebs/general-purpose/)以上のパフォーマンスとボリュームを必要とするアプリケーションがある場合は、[io2 ブロックエクスプレス](https://aws.amazon.com/ebs/provisioned-iops/)の使用を検討する必要があります。このタイプのストレージは、SAP HANA や低レイテンシー要件の他の大規模なデータベースなど、最大、最も I/O 負荷の高いミッションクリティカルなデプロイに最適です。インスタンスの EBS パフォーマンスはインスタンスのパフォーマンス制限によって制限されるため、すべてのインスタンスが io2 Block Express ボリュームをサポートしているわけではありません。この[ドキュメント](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/provisioned-iops.html)では、サポートされているインスタンスタイプやその他の考慮事項を確認できます。 *単一の gp3 ボリュームは、最大 16,000 IOPS、最大スループット 1,000 MiB/秒、最大 16TiB をサポートできます。最大 256,000 IOPS、4,000 MiB/秒、スループット、64TiB を提供する最新世代のプロビジョンド IOPS SSD ボリューム。* これらのオプションのうち、ストレージのパフォーマンスとコストをアプリケーションのニーズに最も合わせる必要があります。 #### 時間の経過に伴うモニタリングと最適化 アプリケーションのベースラインパフォーマンスを理解し、選択したボリュームを監視して、それが要件/期待を満たしているかどうか、または過剰にプロビジョニングされているかどうかを確認することが重要です (プロビジョニングされた IOPS が完全に活用されていないシナリオなど）。 最初から大量のボリュームを割り当てる代わりに、データを蓄積するにつれてボリュームのサイズを徐々に増やすことができます。Amazon Elastic Block Store CSI ドライバー (aws-ebs-csi-driver) のボリューム[サイズ変更機能を使用して、ボリューム](https://github.com/kubernetes-sigs/aws-ebs-csi-driver/tree/master/examples/kubernetes/resizing)のサイズを動的に変更できます。*EBS ボリュームサイズは増やすことしかできないことに注意してください。* ダングリング EBS ボリュームを特定して削除するには、[AWS の信頼されたアドバイザーのコスト最適化カテゴリ](https://docs.aws.amazon.com/awssupport/latest/user/cost-optimization-checks.html)を使用できます。この機能は、アタッチされていないボリュームや、一定期間の書き込みアクティビティが非常に少ないボリュームを特定するのに役立ちます。ライブ Kubernetes クラスターをスキャンし、デプロイされたリソースと設定に関する潜在的な問題をレポートする、[Popeye](https://github.com/derailed/popeye) と呼ばれるクラウドネイティブのオープンソースの読み取り専用ツールがあります。たとえば、未使用の PVs と PVCs をスキャンして、それらがバインドされているかどうか、またはボリュームマウントエラーがあるかどうかを確認できます。 モニタリングの詳細については、[EKS コスト最適化オブザーバビリティガイド](https://docs.aws.amazon.com/eks/latest/best-practices/cost-opt-observability.html)を参照してください。 考慮すべきもう 1 つのオプションは、[AWS Compute Optimizer Amazon EBS ボリュームのレコメンデーション](https://docs.aws.amazon.com/compute-optimizer/latest/ug/view-ebs-recommendations.html)です。このツールは、最適なボリューム設定と必要な適切なパフォーマンスレベルを自動的に特定します。例えば、過去 14 日間の最大使用率に基づいて、プロビジョニングされた IOPS、ボリュームサイズ、EBS ボリュームのタイプに関する最適な設定に使用できます。また、レコメンデーションから得られる月間コスト削減の可能性も定量化します。詳細については、この[ブログ](https://aws.amazon.com/blogs/storage/cost-optimizing-amazon-ebs-volumes-using-aws-compute-optimizer/)を参照してください。 #### バックアップの保持ポリシー point-in-timeスナップショットを作成することで、Amazon EBS ボリュームのデータをバックアップできます。Amazon EBS CSI ドライバーはボリュームスナップショットをサポートします。ここで説明するステップを使用して、スナップショットを作成し、EBS PV を復元する方法について説明します[https://github.com/kubernetes-sigs/aws-ebs-csi-driver/blob/master/examples/kubernetes/snapshot/README.md](https://github.com/kubernetes-sigs/aws-ebs-csi-driver/blob/master/examples/kubernetes/snapshot/README.md)。 後続のスナップショットは増分バックアップです。つまり、最新のスナップショットの後に変更されたデバイスのブロックのみが保存されます。これにより、スナップショットを作成するのに要する時間が最小限に抑えられ、データを複製しないことで、ストレージコストが節約されます。ただし、適切な保持ポリシーなしで古い EBS スナップショットの数を増やすと、大規模な運用時に予期しないコストが発生する可能性があります。AWS API を使用して Amazon EBS ボリュームを直接バックアップする場合は、Amazon Elastic Block Store (EBS) スナップショットと EBS-backed Amazon マシンイメージ (AMIs) 用の自動化されたポリシーベースのライフサイクル管理ソリューションを提供する Amazon [Data Lifecycle Manager](https://aws.amazon.com/ebs/data-lifecycle-manager/) (DLM) を活用できます。コンソールを使用すると、EBS スナップショットと AMIs。 **注記** 現在、Amazon EBS CSI ドライバーを介して Amazon DLM を使用する方法はありません。 Kubernetes 環境では、[Velero](https://velero.io/) というオープンソースツールを使用して EBS 永続ボリュームをバックアップできます。バックアップの有効期限が切れるようにジョブをスケジュールするときに TTL フラグを設定できます。以下は、例として Velero からの[ガイド](https://velero.io/docs/v1.12/how-velero-works/#set-a-backup-to-expire)です。 ### Amazon Elastic File System (EFS) [Amazon Elastic File System (EFS)](https://aws.amazon.com/efs/) は、サーバーレスで完全に伸縮自在なファイルシステムです。標準のファイルシステムインターフェイスとファイルシステムのセマンティクスを使用してファイルデータを共有し、幅広いワークロードやアプリケーションに対応します。ワークロードやアプリケーションの例としては、Wordpress や Drupal、JIRA や Git などの開発者ツール、Jupyter などの共有ノートブックシステム、ホームディレクトリなどがあります。 Amazon EFS の主な利点の 1 つは、複数のノードと複数のアベイラビリティーゾーンにまたがる複数のコンテナにマウントできることです。もう 1 つの利点は、使用したストレージに対してのみ料金を支払うことです。EFS ファイルシステムは、ファイルを追加および削除すると自動的に拡張および縮小されるため、容量計画が不要になります。 Kubernetes で Amazon EFS を使用するには、Amazon Elastic File System Container Storage Interface (CSI) ドライバー、[aws-efs-csi-driver](https://github.com/kubernetes-sigs/aws-efs-csi-driver) を使用する必要があります。現在、ドライバーは[アクセスポイント](https://docs.aws.amazon.com/efs/latest/ug/efs-access-points.html)を動的に作成できます。ただし、Amazon EFS ファイルシステムを最初にプロビジョニングし、Kubernetes ストレージクラスパラメータへの入力として提供する必要があります。 #### 適切な EFS ストレージクラスの選択 Amazon EFS には [4 つのストレージクラス](https://docs.aws.amazon.com/efs/latest/ug/storage-classes.html)があります。 2 つの標準ストレージクラス： + Amazon EFS 標準 + [Amazon EFS Standard-Infrequent Access](https://aws.amazon.com/blogs/aws/optimize-storage-cost-with-reduced-pricing-for-amazon-efs-infrequent-access/) (EFS Standard-IA) 2 つの 1 ゾーンストレージクラス： + [Amazon EFS 1 ゾーン](https://aws.amazon.com/blogs/aws/new-lower-cost-one-zone-storage-classes-for-amazon-elastic-file-system/) + Amazon EFS 1 ゾーン低頻度アクセス (EFS 1 ゾーン - IA) 低頻度アクセス (IA) ストレージクラスは、毎日アクセスされないファイルに対してコスト最適化されています。Amazon EFS ライフサイクル管理を使用すると、ライフサイクルポリシーの期間 (7、14、30、60、または 90 日間) アクセスされなかったファイルを IA ストレージクラスに移動できます。*これにより、EFS 標準ストレージクラスと EFS 1 ゾーンストレージクラスと比較して、ストレージコストがそれぞれ最大 92% EFS 削減*されます。 EFS Intelligent-Tiering を使用すると、ライフサイクル管理はファイルシステムのアクセスパターンを監視し、ファイルを最適なストレージクラスに自動的に移動します。 **注記** aws-efs-csi-driver は現在、ストレージクラス、ライフサイクル管理、または Intelligent-Tiering の変更を制御できません。これらは、AWS コンソールまたは EFS APIs を使用して手動でセットアップする必要があります。 **注記** aws-efs-csi-driver は、Window ベースのコンテナイメージと互換性がありません。 **注記** ファイルシステムのサイズに比例する量のメモリを消費する [DiskUsage](https://github.com/kubernetes/kubernetes/blob/ee265c92fec40cd69d1de010b477717e4c142492/pkg/volume/util/fs/fs.go#L66) 関数が原因で、*vol-metrics-opt-in* (ボリュームメトリクスを出力するため) が有効になっている場合、メモリに既知の問題があります。*現在、大量のメモリを消費しないように、大きなファイルシステムでは「--vol-metrics-opt-in」オプションを無効にすることをお勧めします**。vol-metrics-opt-in 詳細については、GitHub の問題[リンク](https://github.com/kubernetes-sigs/aws-efs-csi-driver/issues/1104)を参照してください。* ### Amazon FSx for Lustre Lustre は、最大数百 GB/秒のスループットとオペレーションごとのミリ秒未満のレイテンシーを必要とするワークロードで一般的に使用される高性能の並列ファイルシステムです。これは、機械学習トレーニング、財務モデリング、HPC、ビデオ処理などのシナリオに使用されます。[Amazon FSx for Lustre](https://aws.amazon.com/fsx/lustre/) は、スケーラビリティとパフォーマンスを備えたフルマネージド共有ストレージを提供し、Amazon S3 とシームレスに統合されています。 Amazon EKS の FSx for Lustre [CSI ドライバーまたは AWS のセルフマネージド Kubernetes クラスターを使用して、FSx for Lustre](https://github.com/kubernetes-sigs/aws-fsx-csi-driver) でバックアップされた Kubernetes 永続ストレージボリュームを使用できます。詳細と例については、[Amazon EKS ドキュメント](https://docs.aws.amazon.com/eks/latest/userguide/fsx-csi.html)を参照してください。 #### Amazon S3 へのリンク Amazon S3 に存在する耐久性の高い長期データリポジトリを FSx for Lustre ファイルシステムにリンクすることをお勧めします。リンクされると、大きなデータセットは必要に応じて Amazon S3 から FSx for Lustre ファイルシステムに遅延ロードされます。分析と結果を S3 に戻し、Lustre ファイルシステムを削除することもできます。 #### 適切なデプロイとストレージオプションの選択 FSx for Lustre にはさまざまなデプロイオプションがあります。最初のオプションは*スクラッチ*と呼ばれ、データはレプリケートされません。2 番目のオプションは*永続*と呼ばれ、名前が示すように、データは保持されます。 最初のオプション (*スクラッチ*) *を使用して、一時的な短期データ処理のコストを削減できます。*永続デプロイオプション*は、AWS アベイラビリティーゾーン内のデータを自動的にレプリケートする長期ストレージ用に設計されています*。また、SSD ストレージと HDD ストレージの両方をサポートしています。 必要なデプロイタイプは、FSx for lustre ファイルシステムの Kubernetes StorageClass のパラメータで設定できます。サンプルテンプレートを提供する[リンク](https://github.com/kubernetes-sigs/aws-fsx-csi-driver/tree/master/examples/kubernetes/dynamic_provisioning#edit-storageclass)を次に示します。 **注記** レイテンシーの影響を受けやすいワークロードや、最高レベルの IOPS/スループットを必要とするワークロードの場合は、SSD ストレージを選択する必要があります。レイテンシーの影響を受けないスループット重視のワークロードの場合は、HDD ストレージを選択する必要があります。 #### データ圧縮を有効にする また、「LZ4」をデータ圧縮タイプとして指定することで、ファイルシステムでデータ圧縮を有効にすることもできます。有効にすると、新しく書き込まれたすべてのファイルは、ディスクに書き込まれる前に FSx for Lustre で自動的に圧縮され、読み取り時に解凍されます。LZ4 データ圧縮アルゴリズムは可逆であるため、元のデータは圧縮されたデータから完全に再構築できます。 データ圧縮タイプは、FSx for lustre ファイルシステムの Kubernetes StorageClass のパラメータで LZ4 として設定できます。値がデフォルトで NONE に設定されている場合、圧縮は無効になります。この[リンク](https://github.com/kubernetes-sigs/aws-fsx-csi-driver/tree/master/examples/kubernetes/dynamic_provisioning#edit-storageclass)にはサンプルテンプレートが用意されています。 **注記** Amazon FSx for Lustre は、Window ベースのコンテナイメージと互換性がありません。 ### Amazon FSx for NetApp ONTAP [Amazon FSx for NetApp ONTAP](https://aws.amazon.com/fsx/netapp-ontap/) は、NetApp の ONTAP ファイルシステム上に構築されたフルマネージド共有ストレージです。FSx for ONTAP は、AWS またはオンプレミスで実行されている Linux、Windows、macOS コンピューティングインスタンスから幅広くアクセスできる、機能豊富で高速、柔軟な共有ファイルストレージを提供します。 Amazon FSx for NetApp ONTAP は、*1/プライマリ階層と 2/キャパシティプール階層の **2 つのストレージ階層をサポートしています。* *プライマリ階層*は、アクティブでレイテンシーの影響を受けやすいデータ用のプロビジョニングされた高性能 SSD ベースの階層です。完全に伸縮自在な*キャパシティプール階層*は、アクセス頻度の低いデータに対してコスト最適化されており、データが階層化されると自動的にスケールされ、事実上無制限のペタバイトの容量を提供します。キャパシティープールストレージでデータ圧縮と重複排除を有効にして、データが消費するストレージ容量をさらに削減できます。NetApp のポリシーベースのネイティブ FabricPool 機能は、データアクセスパターンを継続的にモニタリングし、ストレージ層間で双方向にデータを自動的に転送して、パフォーマンスとコストを最適化します。 NetApp の Astra Trident は、CSI ドライバーを使用して動的ストレージオーケストレーションを提供します。これにより、Amazon EKS クラスターは、Amazon FSx for NetApp ONTAP ファイルシステムによってバックアップされた永続ボリューム PVs のライフサイクルを管理できます。開始するには、Astra Trident ドキュメントの「[Amazon FSx for NetApp ONTAP で Astra Trident を使用](https://docs.netapp.com/us-en/trident/trident-use/trident-fsx.html)」を参照してください。 ## その他の考慮事項 ### コンテナイメージのサイズを最小限に抑える コンテナがデプロイされると、コンテナイメージは複数のレイヤーとしてホストにキャッシュされます。イメージのサイズを減らすことで、ホストに必要なストレージの量を減らすことができます。 最初からスクラッチイメージや[ディストリビューション](https://github.com/GoogleContainerTools/distroless)コンテナイメージ (アプリケーションとそのランタイム依存関係のみを含む) などのスラムダウンされたベースイメージを使用することで、*攻撃領域の削減やイメージのプル時間の短縮など、その他の補助的な利点に加えて、ストレージコストを削減できます。* また、最小限のイメージを作成する簡単で安全な方法を提供する [Slim.ai](https://www.slim.ai/docs/quickstart) などのオープンソースツールの使用も検討する必要があります。 パッケージ、ツール、アプリケーションの依存関係、ライブラリの複数のレイヤーは、コンテナイメージサイズを簡単に肥大化できます。マルチステージビルドを使用すると、あるステージから別のステージにアーティファクトを選択的にコピーでき、最終イメージから不要なものをすべて除外できます。イメージ構築のベストプラクティスについては、[こちら](https://docs.docker.com/get-started/09_image_best/)を参照してください。 もう 1 つの考慮事項は、キャッシュされたイメージを保持する期間です。一定量のディスクが使用されているときに、古いイメージをイメージキャッシュからクリーンアップできます。これにより、ホストのオペレーションに十分なスペースを確保できます。デフォルトでは、[kubelet](https://kubernetes.io/docs/reference/generated/kubelet) は未使用のイメージのガベージコレクションを 5 分ごとに、未使用のコンテナのガベージコレクションを 1 分ごとに実行します。 *未使用のコンテナとイメージガベージコレクションのオプションを設定するには、[設定ファイル](https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/)を使用して kubelet を調整し、[https://kubernetes.io/docs/reference/config-api/kubelet-config.v1beta1/](https://kubernetes.io/docs/reference/config-api/kubelet-config.v1beta1/)リソースタイプを使用してガベージコレクションに関連するパラメータを変更します。* 詳細については、Kubernetes [ドキュメント](https://kubernetes.io/docs/concepts/architecture/garbage-collection/#containers-images)を参照してください。