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 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. 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 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 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. 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 sehingga volume dapat dipasang sebagai spesifikasi pod. HostPath Atau, Anda dapat memanfaatkan Penyedia Statis Volume Persisten Lokal 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 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. 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) 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 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 gp2di gp3 di kluster Amazon EKS dengan pencadangan dan pemulihan dengan menggunakan fitur CSI Volume Snapshots, yang memerlukan waktu henti aplikasi.

Amazon EBS memungkinkan perubahan karakteristik volume seperti ukuran volume, IOPS, dan throughput online. Memanfaatkan fitur ini seseorang dapat bermigrasi dari gp2 di gp3 tanpa downtime aplikasi menggunakan anotasi PVC seperti yang dijelaskan di blog ini, yang memerlukan driver EBS CSI v1.19.0+, atau dimulai dengan Amazon EKS v1.31 dan driver EBS CSI 1.35 dengan menggunakan API seperti yang dijelaskan di sini. VolumeAttributesClass

Jika Anda memiliki aplikasi yang membutuhkan kinerja lebih tinggi dan membutuhkan volume yang lebih besar dari yang dapat didukung oleh satu volume gp3, Anda harus mempertimbangkan untuk menggunakan io2 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 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 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. 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 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.

Satu opsi lain yang dapat Anda pertimbangkan adalah rekomendasi volume AWS Compute Optimizer Amazon EBS. 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 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.

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 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

Di lingkungan Kubernetes, Anda dapat memanfaatkan alat sumber terbuka yang disebut Velero untuk membuat cadangan Volume Persisten EBS Anda. Anda dapat mengatur tanda TTL saat menjadwalkan pekerjaan untuk kedaluwarsa cadangan. Berikut adalah panduan dari Velero sebagai contoh.

Amazon Elastic File System (EFS)

Amazon Elastic File System (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 Saat ini, pengemudi dapat secara dinamis membuat titik akses. 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.

Dua kelas penyimpanan standar:

Dua kelas penyimpanan satu zona:

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.

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 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 atau cluster Kubernetes yang dikelola sendiri di AWS. Lihat dokumentasi Amazon EKS 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 yang menyediakan contoh template.

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 ini menyediakan contoh templat.

Amazon FSx untuk NetApp ONTAP

Amazon FSx untuk 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 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 (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 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.

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 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 dan ubah parameter yang terkait dengan pengumpulan sampah menggunakan tipe sumber daya. KubeletConfiguration

Anda dapat mempelajarinya lebih lanjut di dokumentasi Kubernetes.