Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Penyimpanan
## Gambaran Umum
Ada skenario di mana Anda mungkin ingin menjalankan aplikasi yang perlu menyimpan data untuk jangka pendek atau jangka panjang. Untuk kasus penggunaan seperti itu, volume dapat ditentukan dan dipasang oleh Pod sehingga kontainernya dapat memanfaatkan mekanisme penyimpanan yang berbeda. Kubernetes mendukung berbagai jenis [volume untuk penyimpanan sementara](https://kubernetes.io/docs/concepts/storage/volumes/) dan persisten. Pilihan penyimpanan sangat tergantung pada persyaratan aplikasi. Untuk setiap pendekatan, ada implikasi biaya, dan praktik yang dirinci di bawah ini yang akan membantu Anda mencapai efisiensi biaya untuk beban kerja yang membutuhkan beberapa bentuk penyimpanan di lingkungan EKS Anda.
## Volume Ephemeral
Volume fana adalah untuk aplikasi yang memerlukan volume lokal sementara tetapi tidak memerlukan data untuk bertahan setelah restart. Contohnya termasuk persyaratan untuk ruang awal, caching, dan data input hanya-baca seperti data konfigurasi dan rahasia. [Anda dapat menemukan detail lebih lanjut tentang volume fana Kubernetes di sini.](https://kubernetes.io/docs/concepts/storage/ephemeral-volumes/) Sebagian besar volume fana (misalnya EmptyDir, ConfigMap, DownwardApi, secret, hostpath) didukung oleh perangkat yang dapat ditulis secara lokal (biasanya disk root) atau RAM, jadi penting untuk memilih volume host yang paling hemat biaya dan berkinerja.
### Menggunakan Volume EBS
*Sebaiknya mulai dengan [gp3](https://aws.amazon.com/ebs/general-purpose/) sebagai volume root host.* Ini adalah volume SSD tujuan umum terbaru yang ditawarkan oleh Amazon EBS dan juga menawarkan harga yang lebih rendah (hingga 20%) per GB dibandingkan dengan volume gp2.
### Menggunakan Toko EC2 Instans Amazon
[Toko EC2 instans Amazon](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/InstanceStorage.html) menyediakan penyimpanan tingkat blok sementara untuk instans Anda EC2 . Penyimpanan yang disediakan oleh toko EC2 instans dapat diakses melalui disk yang secara fisik terpasang ke host. Tidak seperti Amazon EBS, Anda hanya dapat melampirkan volume penyimpanan instans saat instance diluncurkan, dan volume ini hanya ada selama masa pakai instance. Mereka tidak dapat dilepaskan dan dilampirkan kembali ke instance lain. Anda dapat mempelajari lebih lanjut tentang toko EC2 instans Amazon [di sini](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/InstanceStorage.html). *Tidak ada biaya tambahan yang terkait dengan volume penyimpanan instans.* Hal ini membuat mereka (volume penyimpanan instance) *lebih hemat biaya* daripada EC2 instance umum dengan volume EBS yang besar.
Untuk menggunakan volume penyimpanan lokal di Kubernetes, Anda harus mempartisi, mengonfigurasi, dan memformat disk menggunakan [ EC2 data pengguna Amazon](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instancedata-add-user-data.html) sehingga volume dapat dipasang sebagai spesifikasi pod. [HostPath](https://kubernetes.io/docs/concepts/storage/volumes/#hostpath) Atau, Anda dapat memanfaatkan [Penyedia Statis Volume Persisten Lokal](https://github.com/kubernetes-sigs/sig-storage-local-static-provisioner) untuk menyederhanakan manajemen penyimpanan lokal. Penyedia statis Volume Persisten Lokal memungkinkan Anda mengakses volume penyimpanan instans lokal melalui antarmuka Kubernetes PersistentVolumeClaim (PVC) standar. Selanjutnya, ia akan menyediakan PersistentVolumes (PVs) yang berisi informasi afinitas node untuk menjadwalkan Pod ke node yang benar. Meskipun menggunakan Kubernetes PersistentVolumes, volume penyimpanan EC2 instance bersifat fana. Data yang ditulis ke disk fana hanya tersedia selama masa hidup instance. Ketika instance dihentikan, begitu juga datanya. Silakan merujuk ke [blog](https://aws.amazon.com/blogs/containers/eks-persistent-volumes-for-instance-store/) ini untuk lebih jelasnya.
Perlu diingat bahwa saat menggunakan volume penyimpanan EC2 instans Amazon, total batas IOPS dibagikan dengan host dan mengikat Pod ke host tertentu. Anda harus meninjau persyaratan beban kerja Anda secara menyeluruh sebelum mengadopsi volume penyimpanan EC2 instans Amazon.
## Volume Persisten
Kubernetes biasanya dikaitkan dengan menjalankan aplikasi stateless. Namun, ada skenario di mana Anda mungkin ingin menjalankan layanan mikro yang perlu menyimpan data atau informasi persisten dari satu permintaan ke permintaan berikutnya. Database adalah contoh umum untuk kasus penggunaan semacam itu. Namun, Pod, dan wadah atau proses di dalamnya, bersifat fana. Untuk mempertahankan data di luar masa pakai Pod, Anda dapat menggunakan PVs untuk menentukan akses ke penyimpanan di lokasi tertentu yang independen dari Pod. *Biaya yang terkait dengan PVs sangat tergantung pada jenis penyimpanan yang digunakan dan bagaimana aplikasi mengkonsumsinya.*
[Ada berbagai jenis opsi penyimpanan yang mendukung Kubernetes di PVs Amazon EKS yang tercantum di sini.](https://docs.aws.amazon.com/eks/latest/userguide/storage.html) Opsi penyimpanan yang tercakup di bawah ini adalah Amazon EBS, Amazon EFS, Amazon FSx untuk Lustre, Amazon FSx untuk ONTAP. NetApp
### Volume Amazon Elastic Block Store (EBS)
Volume Amazon EBS dapat digunakan sebagai Kubernetes PVs untuk menyediakan volume penyimpanan tingkat blok. Ini sangat cocok untuk database yang mengandalkan pembacaan & penulisan acak dan aplikasi intensif throughput yang melakukan pembacaan dan penulisan yang panjang dan berkelanjutan. [Driver Amazon Elastic Block Store Container Storage Interface (CSI)](https://docs.aws.amazon.com/eks/latest/userguide/ebs-csi.html) memungkinkan kluster Amazon EKS mengelola siklus hidup volume Amazon EBS untuk volume persisten. Container Storage Interface memungkinkan dan memfasilitasi interaksi antara Kubernetes dan sistem penyimpanan. Ketika driver CSI di-deploy ke kluster EKS Anda, Anda dapat mengakses kemampuannya melalui sumber daya penyimpanan Kubernetes asli seperti Persistent Volume (PVs), Persistent Volume Claims () dan Storage Classes (PVCs). SCs [Tautan](https://github.com/kubernetes-sigs/aws-ebs-csi-driver/tree/master/examples/kubernetes) ini memberikan contoh praktis tentang cara berinteraksi dengan volume Amazon EBS dengan driver Amazon EBS CSI.
#### Memilih volume yang tepat
*Kami merekomendasikan penggunaan penyimpanan blok generasi terbaru (gp3) karena memberikan keseimbangan yang tepat antara harga dan kinerja*. Ini juga memungkinkan Anda untuk menskalakan IOPS volume dan throughput secara independen dari ukuran volume tanpa perlu menyediakan kapasitas penyimpanan blok tambahan. Jika saat ini Anda menggunakan volume gp2, kami sangat menyarankan untuk bermigrasi ke volume gp3. [Posting blog [Migrasi kluster Amazon EKS dari gp2 ke gp3 volume EBS menjelaskan cara bermigrasi dari gp2](https://aws.amazon.com/blogs/containers/migrating-amazon-eks-clusters-from-gp2-to-gp3-ebs-volumes/)*di gp3* di kluster Amazon EKS dengan pencadangan dan *pemulihan dengan menggunakan* fitur CSI Volume Snapshots, yang memerlukan waktu henti aplikasi.](https://kubernetes.io/docs/concepts/storage/volume-snapshots/)
Amazon EBS memungkinkan perubahan karakteristik volume seperti ukuran volume, IOPS, dan throughput online. [https://kubernetes.io/docs/concepts/storage/volume-attributes-classes/](https://kubernetes.io/docs/concepts/storage/volume-attributes-classes/)
Jika Anda memiliki aplikasi yang membutuhkan kinerja lebih tinggi dan membutuhkan volume yang lebih besar dari yang [dapat didukung oleh satu volume gp3](https://aws.amazon.com/ebs/general-purpose/), Anda harus mempertimbangkan untuk menggunakan [io2](https://aws.amazon.com/ebs/provisioned-iops/) block express. Jenis penyimpanan ini sangat ideal untuk penyebaran terbesar, paling I/O intensif, dan misi kritis Anda seperti SAP HANA atau database besar lainnya dengan persyaratan latensi rendah. Perlu diingat bahwa kinerja EBS instans dibatasi oleh batas kinerja instans, jadi tidak semua instance mendukung volume ekspres blok io2. Anda dapat memeriksa jenis instans yang didukung dan pertimbangan lain di [dokumen](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/provisioned-iops.html) ini.
*Volume gp3 tunggal dapat mendukung hingga 16.000 IOPS maks, 1.000 throughput maks, MiB/s maks 16TiB. Volume SSD IOPS Provisioned generasi terbaru yang menyediakan hingga 256.000 IOPS, 4.000 MiB/s, throughput, dan 64TiB.*
Di antara opsi-opsi ini, Anda sebaiknya menyesuaikan kinerja dan biaya penyimpanan Anda dengan kebutuhan aplikasi Anda.
#### Memantau dan mengoptimalkan dari waktu ke waktu
Penting untuk memahami kinerja dasar aplikasi Anda dan memantaunya untuk volume yang dipilih untuk memeriksa apakah itu memenuhi kebutuhan Anda requirements/expectations atau jika terlalu banyak disediakan (misalnya skenario di mana IOPS yang disediakan tidak sepenuhnya digunakan).
Alih-alih mengalokasikan volume besar dari awal, Anda dapat secara bertahap meningkatkan ukuran volume saat Anda mengumpulkan data. Anda dapat mengukur ulang volume secara dinamis menggunakan fitur [pengubahan ukuran volume](https://github.com/kubernetes-sigs/aws-ebs-csi-driver/tree/master/examples/kubernetes/resizing) di driver Amazon Elastic Block Store CSI (). aws-ebs-csi-driver *Perlu diingat bahwa Anda hanya dapat meningkatkan ukuran volume EBS.*
Untuk mengidentifikasi dan menghapus volume EBS yang menggantung, Anda dapat menggunakan kategori pengoptimalan [biaya penasihat AWS tepercaya](https://docs.aws.amazon.com/awssupport/latest/user/cost-optimization-checks.html). Fitur ini membantu Anda mengidentifikasi volume atau volume yang tidak terikat dengan aktivitas tulis yang sangat rendah untuk jangka waktu tertentu. Ada alat cloud-native open-source, read-only yang disebut [Popeye](https://github.com/derailed/popeye) yang memindai klaster Kubernetes langsung dan melaporkan potensi masalah dengan sumber daya dan konfigurasi yang diterapkan. Misalnya, dapat memindai yang tidak digunakan PVs dan PVCs dan memeriksa apakah mereka terikat atau apakah ada kesalahan pemasangan volume.
Untuk penyelaman mendalam tentang pemantauan, silakan merujuk ke [panduan observabilitas pengoptimalan biaya EKS](https://docs.aws.amazon.com/eks/latest/best-practices/cost-opt-observability.html).
Satu opsi lain yang dapat Anda pertimbangkan adalah rekomendasi volume [AWS Compute Optimizer Amazon EBS](https://docs.aws.amazon.com/compute-optimizer/latest/ug/view-ebs-recommendations.html). Alat ini secara otomatis mengidentifikasi konfigurasi volume optimal dan tingkat kinerja yang benar yang diperlukan. Misalnya, dapat digunakan untuk pengaturan optimal yang berkaitan dengan IOPS yang disediakan, ukuran volume, dan jenis volume EBS berdasarkan pemanfaatan maksimum selama 14 hari terakhir. Ini juga mengukur potensi penghematan biaya bulanan yang berasal dari rekomendasinya. Anda dapat meninjau [blog](https://aws.amazon.com/blogs/storage/cost-optimizing-amazon-ebs-volumes-using-aws-compute-optimizer/) ini untuk lebih jelasnya.
#### Kebijakan retensi cadangan
Anda dapat mencadangkan data pada volume Amazon EBS Anda dengan mengambil point-in-time snapshot. Driver Amazon EBS CSI mendukung snapshot volume. [Anda dapat mempelajari cara membuat snapshot dan memulihkan EBS PV menggunakan langkah-langkah yang diuraikan di sini.](https://github.com/kubernetes-sigs/aws-ebs-csi-driver/blob/master/examples/kubernetes/snapshot/README.md)
Snapshot berikutnya adalah backup tambahan, yang berarti bahwa hanya blok pada perangkat yang telah berubah setelah snapshot terbaru Anda disimpan. Hal ini meminimalkan waktu yang diperlukan untuk membuat snapshot dan menghemat biaya penyimpanan dengan tidak menduplikasi data. Namun, bertambahnya jumlah snapshot EBS lama tanpa kebijakan retensi yang tepat dapat menyebabkan biaya tak terduga saat beroperasi dalam skala besar. Jika Anda langsung mencadangkan volume Amazon EBS melalui AWS API, Anda dapat memanfaatkan [Amazon Data](https://aws.amazon.com/ebs/data-lifecycle-manager/) Lifecycle Manager (DLM) yang menyediakan solusi manajemen siklus hidup berbasis kebijakan otomatis untuk Amazon Elastic Block Store (EBS) Snapshots dan Amazon Machine Images () yang didukung EBS. AMIs Konsol membuatnya lebih mudah untuk mengotomatiskan pembuatan, retensi, dan penghapusan Snapshots EBS dan. AMIs
**catatan**
Saat ini tidak ada cara untuk menggunakan Amazon DLM melalui driver Amazon EBS CSI.
Di lingkungan Kubernetes, Anda dapat memanfaatkan alat sumber terbuka yang disebut [Velero](https://velero.io/) untuk membuat cadangan Volume Persisten EBS Anda. Anda dapat mengatur tanda TTL saat menjadwalkan pekerjaan untuk kedaluwarsa cadangan. Berikut adalah [panduan](https://velero.io/docs/v1.12/how-velero-works/#set-a-backup-to-expire) dari Velero sebagai contoh.
### Amazon Elastic File System (EFS)
[Amazon Elastic File System (EFS)](https://aws.amazon.com/efs/) adalah sistem file tanpa server dan sepenuhnya elastis yang memungkinkan Anda berbagi data file menggunakan antarmuka sistem file standar dan semantik sistem file untuk spektrum beban kerja dan aplikasi yang luas. Contoh beban kerja dan aplikasi termasuk Wordpress dan Drupal, alat pengembang seperti JIRA dan Git, dan sistem notebook bersama seperti Jupyter serta direktori rumah.
Salah satu manfaat utama Amazon EFS adalah dapat dipasang oleh beberapa kontainer yang tersebar di beberapa node dan beberapa zona ketersediaan. Manfaat lain adalah Anda hanya membayar untuk penyimpanan yang Anda gunakan. Sistem file EFS akan secara otomatis tumbuh dan menyusut saat Anda menambah dan menghapus file yang menghilangkan kebutuhan untuk perencanaan kapasitas.
Untuk menggunakan Amazon EFS di Kubernetes, Anda perlu menggunakan Driver Amazon Elastic File System Container Storage Interface (CSI),. [aws-efs-csi-driver](https://github.com/kubernetes-sigs/aws-efs-csi-driver) Saat ini, pengemudi dapat secara dinamis membuat [titik akses](https://docs.aws.amazon.com/efs/latest/ug/efs-access-points.html). Namun, sistem file Amazon EFS harus disediakan terlebih dahulu dan disediakan sebagai input ke parameter kelas penyimpanan Kubernetes.
#### Memilih kelas penyimpanan EFS yang tepat
Amazon EFS menawarkan [empat kelas penyimpanan](https://docs.aws.amazon.com/efs/latest/ug/storage-classes.html).
Dua kelas penyimpanan standar:
+ Amazon EFS Standar
+ [Amazon EFS Standar-Jarang Akses (EFS Standard-IA)](https://aws.amazon.com/blogs/aws/optimize-storage-cost-with-reduced-pricing-for-amazon-efs-infrequent-access/)
Dua kelas penyimpanan satu zona:
+ [Amazon EFS Satu Zona](https://aws.amazon.com/blogs/aws/new-lower-cost-one-zone-storage-classes-for-amazon-elastic-file-system/)
+ Amazon EFS Satu Zona Akses Jarang (EFS One Zone-IA)
Kelas penyimpanan Infrequent Access (IA) dioptimalkan biaya untuk file yang tidak diakses setiap hari. Dengan manajemen siklus hidup Amazon EFS, Anda dapat memindahkan file yang belum diakses selama durasi kebijakan siklus hidup (7, 14, 30, 60, atau 90 hari) ke kelas penyimpanan IA *yang dapat mengurangi biaya penyimpanan hingga 92 persen dibandingkan dengan kelas penyimpanan EFS Standard dan EFS One Zone masing-masing*.
Dengan EFS Intelligent-Tiering, manajemen siklus hidup memantau pola akses sistem file Anda dan secara otomatis memindahkan file ke kelas penyimpanan yang paling optimal.
**catatan**
aws-efs-csi-driver saat ini tidak memiliki kontrol untuk mengubah kelas penyimpanan, manajemen siklus hidup, atau Intelligent-Tiering. Itu harus diatur secara manual di konsol AWS atau melalui EFS APIs.
**catatan**
aws-efs-csi-driver tidak kompatibel dengan gambar kontainer berbasis Windows.
**catatan**
Ada masalah memori yang diketahui ketika *vol-metrics-opt-in*(untuk memancarkan metrik volume) diaktifkan karena [DiskUsage](https://github.com/kubernetes/kubernetes/blob/ee265c92fec40cd69d1de010b477717e4c142492/pkg/volume/util/fs/fs.go#L66)fungsi yang mengkonsumsi sejumlah memori yang sebanding dengan ukuran sistem file Anda. *Saat ini, kami sarankan untuk menonaktifkan* *opsi vol-metrics-opt-in `-- `pada sistem file besar untuk menghindari terlalu banyak memori. Berikut adalah [tautan](https://github.com/kubernetes-sigs/aws-efs-csi-driver/issues/1104) masalah github untuk lebih jelasnya.*
### Amazon FSx untuk Lustre
Lustre adalah sistem file paralel berkinerja tinggi yang biasa digunakan dalam beban kerja yang membutuhkan throughput hingga ratusan dan sub-milidetik latensi per operasi GB/s . Ini digunakan untuk skenario seperti pelatihan pembelajaran mesin, pemodelan keuangan, HPC, dan pemrosesan video. [Amazon FSx for Lustre](https://aws.amazon.com/fsx/lustre/) menyediakan penyimpanan bersama yang dikelola sepenuhnya dengan skalabilitas dan kinerja, terintegrasi dengan mulus dengan Amazon S3.
Anda dapat menggunakan volume penyimpanan persisten Kubernetes yang didukung oleh FSx for Lustre menggunakan [driver for Lustre CSI dari Amazon FSx EKS](https://github.com/kubernetes-sigs/aws-fsx-csi-driver) atau cluster Kubernetes yang dikelola sendiri di AWS. Lihat [dokumentasi Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/fsx-csi.html) untuk detail dan contoh selengkapnya.
#### Tautan ke Amazon S3
Disarankan untuk menautkan repositori data jangka panjang yang sangat tahan lama yang berada di Amazon S3 dengan sistem file for Lustre Anda FSx . Setelah ditautkan, kumpulan data besar dimuat dengan lambat sesuai kebutuhan dari Amazon S3 hingga untuk sistem file Lustre. FSx Anda juga dapat menjalankan analisis dan hasil Anda kembali ke S3, dan kemudian menghapus sistem file Lustre Anda.
#### Memilih opsi penyebaran dan penyimpanan yang tepat
FSx untuk Lustre menyediakan opsi penerapan yang berbeda. Opsi pertama disebut *scratch* dan tidak mereplikasi data, sedangkan opsi kedua disebut *persisten* yang, seperti namanya, mempertahankan data.
Opsi pertama (*awal*) dapat digunakan *untuk mengurangi biaya pemrosesan data jangka pendek sementara*. Opsi penerapan persisten *dirancang untuk penyimpanan jangka panjang* yang secara otomatis mereplikasi data dalam AWS Availability Zone. Ini juga mendukung penyimpanan SSD dan HDD.
Anda dapat mengonfigurasi jenis penerapan yang diinginkan di bawah parameter di Kubernetes FSx for lustre filesystem. StorageClass Berikut adalah [link](https://github.com/kubernetes-sigs/aws-fsx-csi-driver/tree/master/examples/kubernetes/dynamic_provisioning#edit-storageclass) yang menyediakan contoh template.
**catatan**
Untuk beban kerja atau beban kerja yang sensitif terhadap latensi yang membutuhkan tingkat IOP/throughput tertinggi, Anda harus memilih penyimpanan SSD. Untuk beban kerja yang berfokus pada throughput yang tidak sensitif terhadap latensi, Anda harus memilih penyimpanan HDD.
#### Aktifkan kompresi data
Anda juga dapat mengaktifkan kompresi data pada sistem file Anda dengan menentukan "LZ4" sebagai Jenis Kompresi Data. Setelah diaktifkan, semua file yang baru ditulis akan secara otomatis dikompresi FSx untuk Lustre sebelum ditulis ke disk dan tidak dikompresi saat dibaca. LZ4 algoritma kompresi data lossless sehingga data asli dapat sepenuhnya direkonstruksi dari data terkompresi.
Anda dapat mengonfigurasi tipe kompresi data seperti LZ4 di bawah parameter di Kubernetes FSx for lustre filesystem. StorageClass Kompresi dinonaktifkan ketika nilai diatur ke NONE, yang merupakan default. [Tautan](https://github.com/kubernetes-sigs/aws-fsx-csi-driver/tree/master/examples/kubernetes/dynamic_provisioning#edit-storageclass) ini menyediakan contoh templat.
**catatan**
Amazon FSx for Lustre tidak kompatibel dengan gambar kontainer berbasis Windows.
### Amazon FSx untuk NetApp ONTAP
[Amazon FSx untuk NetApp ONTAP](https://aws.amazon.com/fsx/netapp-ontap/) adalah penyimpanan bersama yang dikelola sepenuhnya yang dibangun di atas sistem NetApp file ONTAP. FSx untuk ONTAP menyediakan penyimpanan file bersama yang kaya fitur, cepat, dan fleksibel yang dapat diakses secara luas dari instans komputasi Linux, Windows, dan macOS yang berjalan di AWS atau di tempat.
Amazon FSx untuk NetApp ONTAP mendukung dua tingkatan penyimpanan: *1/tier primer dan *2/kapasitas* pool tier*.
Tingkat *utama adalah tingkat* berbasis SSD berkinerja tinggi yang disediakan untuk data aktif dan sensitif latensi. *Tingkat kolam kapasitas* yang sepenuhnya elastis dioptimalkan biaya untuk data yang jarang diakses, secara otomatis diskalakan saat data berjenjang, dan menawarkan kapasitas petabyte yang hampir tidak terbatas. Anda dapat mengaktifkan kompresi dan deduplikasi data pada penyimpanan kolam kapasitas dan selanjutnya mengurangi jumlah kapasitas penyimpanan yang dikonsumsi data Anda. NetApp FabricPool Fitur asli berbasis kebijakan terus memantau pola akses data, secara otomatis mentransfer data dua arah antara tingkatan penyimpanan untuk mengoptimalkan kinerja dan biaya.
NetAppAstra Trident menyediakan orkestrasi penyimpanan dinamis menggunakan driver CSI yang memungkinkan kluster Amazon EKS mengelola siklus hidup PVs volume persisten yang didukung oleh Amazon untuk sistem file ONTAP. FSx NetApp Untuk memulai, lihat [Menggunakan Astra Trident dengan Amazon FSx untuk NetApp ONTAP](https://docs.netapp.com/us-en/trident/trident-use/trident-fsx.html) di dokumentasi Astra Trident.
## Pertimbangan lainnya
### Minimalkan ukuran gambar kontainer
Setelah kontainer diterapkan, gambar kontainer di-cache pada host sebagai beberapa lapisan. Dengan mengurangi ukuran gambar, jumlah penyimpanan yang dibutuhkan pada host dapat dikurangi.
Dengan menggunakan gambar dasar ramping seperti gambar awal atau gambar kontainer [distroless](https://github.com/GoogleContainerTools/distroless) (yang hanya berisi aplikasi Anda dan dependensi runtime-nya) dari awal, *Anda dapat mengurangi biaya penyimpanan selain manfaat tambahan lainnya seperti mengurangi luas permukaan serangan dan waktu tarik gambar yang lebih pendek*.
Anda juga harus mempertimbangkan untuk menggunakan alat open source, seperti [Slim.ai](https://www.slim.ai/docs/quickstart) yang menyediakan cara mudah dan aman untuk membuat gambar minimal.
Beberapa lapisan paket, alat, dependensi aplikasi, pustaka dapat dengan mudah membengkak ukuran gambar wadah. Dengan menggunakan build multi-tahap, Anda dapat menyalin artefak secara selektif dari satu tahap ke tahap lainnya, tidak termasuk semua yang tidak diperlukan dari gambar akhir. [Anda dapat memeriksa lebih banyak praktik terbaik pembuatan gambar di sini.](https://docs.docker.com/get-started/09_image_best/)
Hal lain yang perlu dipertimbangkan adalah berapa lama untuk mempertahankan gambar yang di-cache. Anda mungkin ingin membersihkan gambar basi dari cache gambar ketika sejumlah disk digunakan. Melakukannya akan membantu memastikan Anda memiliki cukup ruang untuk operasi host. Secara default, [kubelet](https://kubernetes.io/docs/reference/generated/kubelet) melakukan pengumpulan sampah pada gambar yang tidak digunakan setiap lima menit dan pada wadah yang tidak digunakan setiap menit.
*Untuk mengonfigurasi opsi untuk penampung yang tidak terpakai dan pengumpulan sampah gambar, atur kubelet menggunakan [file konfigurasi](https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/) dan ubah parameter yang terkait dengan pengumpulan sampah menggunakan tipe sumber daya. [https://kubernetes.io/docs/reference/config-api/kubelet-config.v1beta1/](https://kubernetes.io/docs/reference/config-api/kubelet-config.v1beta1/)*
[Anda dapat mempelajarinya lebih lanjut di dokumentasi Kubernetes.](https://kubernetes.io/docs/concepts/architecture/garbage-collection/#containers-images)