Arsitektur Persistent Storage Berbasis CSI di ACK - Container Service for Kubernetes

Aplikasi Kubernetes sering memerlukan penyimpanan persisten untuk menyimpan data. Alibaba Cloud Container Service for Kubernetes (ACK) mengintegrasikan berbagai layanan penyimpanan Alibaba Cloud—seperti Elastic Block Storage (EBS), Object Storage Service (OSS), Network Attached Storage (NAS), dan Cloud Parallel File Storage (CPFS)—melalui Container Storage Interface (CSI) standar. ACK juga kompatibel dengan mekanisme penyimpanan native Kubernetes, sehingga menyediakan solusi penyimpanan yang disesuaikan dengan berbagai skenario bisnis. Integrasi ini memberikan opsi penyimpanan fleksibel baik untuk beban kerja sementara maupun persisten.

Pilih solusi penyimpanan

ACK menyediakan dua jenis solusi penyimpanan:

Volume native Kubernetes: Dirancang untuk data sementara, manajemen konfigurasi, atau interaksi tingkat node. Siklus hidupnya terikat pada Pod dan tidak mendukung persistensi data untuk aplikasi.
Volume persisten Alibaba Cloud: Diintegrasikan melalui komponen Container Storage Interface (CSI), volume ini menyediakan persistensi data yang stabil dan andal untuk beban kerja. Siklus hidupnya independen dari Pod dan mendukung aplikasi berstatus.

Sebelum menggunakan penyimpanan kontainer, pastikan Anda memahami konsep utama seperti volume, PersistentVolume (PV), dan PersistentVolumeClaim (PVC). Untuk informasi selengkapnya, lihat Dasar-dasar penyimpanan.

Volume native Kubernetes

Volume native Kubernetes memiliki siklus hidup yang terikat pada Pod dan tidak cocok untuk mempertahankan data aplikasi.

Type	Description	Key feature
emptyDir	Direktori kosong sementara yang siklus hidupnya sesuai dengan Pod-nya.	Data hilang ketika Pod dihapus. Gunakan ini untuk pertukaran data antar-kontainer atau caching sementara dalam satu Pod.
HostPath	Memasang file atau direktori dari node host ke dalam Pod. Anda dapat mengontrol pemeriksaan pra-pemasangan dan perilaku pembuatan menggunakan bidang `type` (misalnya, `DirectoryOrCreate`). Untuk informasi selengkapnya, lihat Volume HostPath	Data terikat pada node dan tidak berpindah bersama Pod. Tidak cocok untuk aplikasi berstatus yang memerlukan ketersediaan tinggi dan persistensi (misalnya, database atau cache).
ConfigMap/Secret	Memasang item konfigurasi atau kredensial sensitif sebagai file.	Hanya dirancang untuk data konfigurasi volume kecil—bukan data bisnis. Digunakan untuk memisahkan konfigurasi dari aplikasi.

Volume persisten Alibaba Cloud

Untuk aplikasi berstatus yang memerlukan penyimpanan data persisten, Anda dapat menggunakan volume persisten Alibaba Cloud. Volume ini memiliki siklus hidup yang independen dari Pod dan diintegrasikan dengan Kubernetes menggunakan CSI.

Perbandingan solusi

Untuk membantu Anda memilih opsi yang tepat dengan cepat, setiap solusi penyimpanan dalam tabel di bawah mencakup ikon referensi cepat untuk atribut inti. Sebagai contoh, untuk EBS:

Cloud disk: Detail solusi. Klik (view details) untuk melihat detail.
Static/Dynamic: Metode penyediaan volume yang didukung, termasuk penyediaan statis (PV/PVC) dan penyediaan dinamis (StorageClass/PVC). Klik tautan untuk instruksi langkah demi langkah.
RWO: mode akses (accessModes) yang didukung: RWO (ReadWriteOnce), RWX (ReadWriteMany), dan ROX (ReadOnlyMany).
Billing: Detail penagihan. Klik tautan untuk melihat detail.

Storage option	Description	Trade-offs and limits
cloud disk ^Static^/^Dynamic^{\| RWO (multi-attach disabled) \|}^Billing	Description: Layanan penyimpanan blok yang memberikan keandalan data tinggi (99,9999999%) dan kinerja I/O konsisten. Data disimpan secara redundan di tiga replika di backend. EBS mendukung mode sistem file (`volumeMode: Filesystem`) dan mode perangkat blok mentah (`volumeMode: Block`). EBS menawarkan beberapa tingkat kinerja (ESSD AutoPL, ESSD, dan ESSD Entry) serta enkripsi data statis. Use case: Ideal untuk aplikasi berstatus single-instance dengan persyaratan I/O dan keandalan data ketat, seperti database MySQL atau PostgreSQL serta middleware Redis atau Elasticsearch.	Batas `accessModes`: Disk EBS tanpa multi-attach yang diaktifkan hanya dapat dipasang ke satu Pod sekaligus. Solusi ini tidak dapat memenuhi kebutuhan bisnis yang memerlukan berbagi data lintas beberapa instans, seperti berbagi konten dalam kluster web. Kami merekomendasikan penggunaan EBS untuk StatefulSet atau penyebaran single-Pod. Jangan gunakan EBS untuk Deployments multi-replika. Untuk informasi selengkapnya, lihat panduan operasi. Pengikatan zona: Kecuali untuk disk regional Enterprise SSD (ESSD), semua tipe disk EBS lainnya hanya dapat dipasang ke Pod dalam zona yang sama. Kami merekomendasikan penggunaan StorageClass `WaitForFirstConsumer` untuk mengaktifkan penjadwalan sadar topologi. Kompatibilitas instans: Tipe disk EBS harus kompatibel dengan keluarga instans ECS yang didukung. Untuk informasi selengkapnya, lihat keluarga instans.
NAS ^Static^/^Dynamic^{\| RWX, RWO, ROX \|}^Billing	Description: Layanan penyimpanan file bersama yang mendukung protokol NFS. NAS memungkinkan akses baca/tulis konkuren oleh beberapa Pod. Layanan ini menyediakan skalabilitas elastis untuk kapasitas dan kinerja serta fitur perlindungan data seperti keranjang daur ulang, snapshot, dan backup. Use case: Berbagi konten lintas kluster web, pipeline CI/CD, penyimpanan log terpusat, dan skenario apa pun di mana beberapa instans aplikasi memerlukan akses baca/tulis konkuren ke dataset yang sama.	Overhead I/O jaringan: Semua operasi baca dan tulis melewati jaringan, yang menambah latensi ekstra dalam skala milidetik dibandingkan EBS. Solusi ini tidak direkomendasikan untuk aplikasi sensitif latensi seperti database. Keberisikan tetangga: Pada instans bersama subpath atau sharepath, PV yang disediakan secara dinamis dipetakan ke subdirektori dari backend NAS yang sama. Hal ini dapat menyebabkan persaingan bandwidth dan IOPS bersama. Batas protokol dan jaringan: Hanya mendukung protokol NFS dan tidak mengizinkan pemasangan lintas-VPC.
OSS ^Static ^{ossfs 1.0}^/^{ossfs 2.0} ^Dynamic ^{ossfs 1.0}^/^{ossfs 2.0} ^{RWX, ROX \|}^Billing	Description: Layanan penyimpanan objek skala besar berbiaya rendah. Menggunakan alat `ossfs`, Anda dapat memasang bucket OSS sebagai sistem file di dalam Pod. OSS menawarkan dua opsi pemasangan: `ossfs 1.0`, yang memprioritaskan kepatuhan POSIX, dan `ossfs 2.0`, yang dioptimalkan untuk throughput dan konkurensi tinggi. Use case: Data lake analitik AI dan big data, aset media statis seperti gambar dan video untuk situs web, serta backup dan arsip data aplikasi.	Kinerja non-native: Diimplementasikan menggunakan Filesystem in Userspace (FUSE), yang mengonversi operasi sistem file menjadi panggilan API HTTP. Hal ini menghasilkan latensi tinggi dan kinerja I/O acak yang buruk. Solusi ini tidak direkomendasikan untuk database atau beban kerja tulis frekuensi tinggi. Kepatuhan POSIX tidak lengkap: Tidak sepenuhnya mendukung semua operasi sistem file standar. Misalnya, `chmod` dan `chown` pada path root dibatasi. Hal ini dapat menyebabkan masalah kompatibilitas aplikasi.
CPFS for Lingjun ^Static^/^Dynamic^{\| RWX \|}^Billing	Description: Sistem file paralel berkinerja tinggi yang dibangun khusus untuk komputasi AI dan cerdas. Memberikan throughput dan IOPS luar biasa untuk beban kerja I/O paralel. Use case: Pelatihan dan inferensi model besar AI-Generated Content (AIGC) serta simulasi kendaraan otonom. Skenario ini menuntut kinerja I/O paralel ekstrem.	Biaya dan ketersediaan: Ini adalah solusi berbiaya tinggi yang dirancang untuk kasus penggunaan berkinerja tinggi tertentu. Solusi ini saat ini dalam pratinjau undangan dan hanya tersedia di wilayah tertentu. Batas pemasangan: Tidak mendukung pemasangan lintas-VPC.
CPFS General Edition ^Static^{\| RWX \|}^Billing	Description: Sistem file bersama yang dibangun untuk beban kerja komputasi kinerja tinggi (HPC). Memberikan IOPS dan throughput lebih tinggi daripada NAS tujuan umum. Use case: Komputasi genomik, analitik big data, dan akselerasi cache data di domain HPC tradisional.	Biaya dan ketersediaan: Solusi ini memiliki biaya lebih tinggi daripada NAS tujuan umum dan hanya tersedia di wilayah tertentu. Batas pemasangan: Hanya mendukung protokol NFS dan tidak mengizinkan pemasangan lintas-VPC.

Selain kinerja dasar, opsi penyimpanan berbeda dalam aspek operasional seperti pemulihan kesalahan, manajemen kapasitas, dan perlindungan data. Pertimbangkan pertanyaan berikut untuk memperhalus pemilihan Anda.

Bagaimana aplikasi dan data pulih ketika node yang menghosting Pod mengalami kegagalan?

Pemulihan aplikasi cepat dan keamanan data selama kegagalan node merupakan inti dari arsitektur ketersediaan tinggi.

EBS: Driver CSI secara otomatis melepas disk dari node yang gagal dan memasangnya ke node baru.
NAS, OSS, dan CPFS: Sebagai penyimpanan bersama, Pod dapat segera dipasang ulang setelah mulai di node baru. Anda tidak perlu menunggu failover penyimpanan. Kecepatan pemulihan hanya bergantung pada waktu startup aplikasi.
HostPath: Data terikat pada node tertentu. Jika node tersebut gagal, Pod tidak dapat dimulai di node lain dan mengakses data aslinya. Replikasi data lintas-node dan ketersediaan tinggi harus ditangani sendiri oleh aplikasi.

Panduan pemilihan: Kami merekomendasikan penggunaan EBS jika aplikasi Anda, seperti database single-instance, dapat mentolerir gangguan tingkat menit. Untuk failover cepat, seperti layanan web berketersediaan tinggi, prioritaskan penyimpanan bersama dengan penyebaran multi-replika. Pilih disk lokal hanya jika aplikasi Anda menangani replikasi data dan ketersediaan tinggi, serta Anda memerlukan kinerja maksimum.

Bagaimana Anda merencanakan dan mengelola kapasitas penyimpanan untuk aplikasi Anda?

Perencanaan kapasitas yang matang membantu mengendalikan biaya dan mencegah gangguan layanan akibat kehabisan penyimpanan. Efek permintaan kapasitas PVC bervariasi di berbagai tipe penyimpanan.

Cloud disk: Kapasitas yang dideklarasikan dalam PVC berkorespondensi satu-ke-satu dengan kapasitas disk cloud yang dialokasikan. Batas kapasitas diberlakukan, dan ekspansi online didukung. Cocok untuk skenario yang memerlukan persyaratan kapasitas jelas dan isolasi resource ketat.
OSS: Tidak ada batas kapasitas keras. Anda hanya membayar berdasarkan penggunaan aktual. Kapasitas PVC hanya digunakan untuk pencocokan PV, bukan untuk membatasi penggunaan.
NAS dan CPFS:
- Volume statis: Kapasitas PVC hanya digunakan untuk pencocokan PV, bukan untuk membatasi penggunaan aktual. Kapasitas tersedia bergantung pada kapasitas total instans backend, yang dibagi di semua Pod.
- Volume dinamis: Untuk NAS (hanya subpath, dengan allowVolumeExpansion diatur ke true) dan CPFS for Lingjun, kapasitas PVC diterjemahkan menjadi kuota pada direktori yang sesuai, yang memberlakukan batas kapasitas aktual. Dalam semua kasus lain, perilakunya sama dengan volume statis.

Panduan pemilihan: Kami merekomendasikan penggunaan EBS untuk aplikasi yang memerlukan anggaran kapasitas tepat dan isolasi kuat, seperti database multi-tenant. Kami merekomendasikan penggunaan penyimpanan bersama untuk beban kerja dengan banyak Pod yang berbagi data dan kebutuhan kapasitas variabel, seperti log atau file web statis.

Bagaimana Anda mencadangkan data aplikasi untuk mencegah penghapusan atau korupsi tidak disengaja?

EBS: Anda dapat menggunakan snapshot untuk membuat dan memulihkan seluruh volume dalam hitungan detik. EBS juga mendukung jadwal backup dan backup on-demand untuk mengurangi risiko kehilangan data.
NAS: Menawarkan keranjang daur ulang melalui Container Network File System (CNFS), yang mendukung pemulihan file atau direktori individual, serta snapshot, yang didukung pada beberapa tipe NAS.
OSS: Menyediakan versioning dan manajemen siklus hidup untuk mencegah operasi tidak disengaja dan mendukung arsip data.
HostPath: Perlindungan data sepenuhnya bergantung pada replikasi dan ketersediaan tinggi di lapisan aplikasi.

Panduan pemilihan: Kami merekomendasikan penggunaan snapshot EBS untuk backup dan pemulihan volume penuh yang cepat dan konsisten. Kami merekomendasikan penggunaan fitur NAS atau OSS untuk arsip jangka panjang, audit kepatuhan, atau pemulihan file individual. Jika Anda menggunakan HostPath, pastikan aplikasi Anda menerapkan perlindungan data yang kuat.

Komponen dan konsep utama

Komponen CSI (csi-plugin, csi-provisioner)
Komponen ini merupakan implementasi plugin penyimpanan yang direkomendasikan komunitas Kubernetes. Komponen ini telah dipra-instal dan diaktifkan secara default di kluster ACK. Komponen ini berinteraksi dengan API penyimpanan Alibaba Cloud untuk mengelola siklus hidup penuh volume, termasuk pembuatan otomatis, pemasangan, dan pelepasan pemasangan. Untuk informasi selengkapnya, lihat Kelola komponen csi-plugin dan csi-provisioner.
Container Network File System (CNFS)
CNFS adalah kemampuan penyimpanan tingkat lanjut yang tersedia di kluster ACK Pro. CNFS mengabstraksikan NAS, OSS, dan CPFS sebagai Custom Resource Definitions (CRD) Kubernetes untuk memungkinkan manajemen detail halus, seperti pembuatan subdirektori dinamis, manajemen kuota, pemantauan kinerja I/O, manajemen keranjang daur ulang, dan caching terdistribusi. Untuk informasi selengkapnya, lihat Container Network File System (CNFS).

Catatan penggunaan

Saat menggunakan CSI, perhatikan batasan berikut.

Versi kluster: Kluster Anda harus menjalankan Kubernetes 1.14 atau lebih baru. Untuk meningkatkan kluster Anda, lihat Tingkatkan kluster secara manual.
Lingkungan kluster: CSI telah diuji dan divalidasi sepenuhnya di kluster ACK. Untuk kluster non-ACK, seperti kluster di lingkungan non-Alibaba Cloud atau kluster yang dikelola sendiri di Alibaba Cloud, CSI mungkin tidak menyediakan fungsionalitas out-of-the-box karena perbedaan konfigurasi, izin, dan jaringan.
Kami merekomendasikan Anda meninjau kode sumber alibaba-cloud-csi-driver dan menyesuaikannya dengan lingkungan Anda.
Konfigurasi node: Parameter kubelet --enable-controller-attach-detach harus diatur ke true.
Sistem operasi: Node Windows tidak didukung.
Izin RBAC: PersistentVolume (PV) adalah resource berlingkup kluster. PersistentVolumeClaim (PVC) berlingkup namespace. Saat memberikan izin RBAC, perhatikan tingkat akses berbeda yang diperlukan untuk kedua tipe resource ini.
Jika peran ACK default, seperti administrator dan insinyur O&M, tidak memenuhi kebutuhan Anda, Anda dapat mengonfigurasi izin kustom. Misalnya, peran insinyur O&M default memberikan akses baca dan tulis ke PVC di namespace yang diotorisasi tetapi hanya akses read-only ke PV di seluruh kluster. Oleh karena itu, Anda tidak dapat menggunakan peran ini untuk membuat PV secara manual. Untuk informasi selengkapnya, lihat Berikan izin RBAC kepada Pengguna RAM atau Peran RAM.

FAQ

Bagaimana cara memeriksa plugin penyimpanan yang digunakan oleh kluster saya?

Anda dapat menggunakan salah satu metode berikut.

Periksa anotasi node di Konsol ACK

Pada halaman Kluster ACK , klik nama kluster Anda. Pada halaman detail kluster, di panel navigasi kiri, klik Nodes > Nodes.
Pada daftar node, temukan node yang ingin Anda kelola dan klik Details di kolom Actions. Pada tab Overview, lihat Annotations node tersebut.
Jika volumes.kubernetes.io/controller-managed-attach-detach: true ada, plugin penyimpanan adalah CSI. Jika tidak ada, plugin tersebut adalah FlexVolume.

Lihat parameter kubelet dengan perintah

Masuk ke node dan periksa parameter kubelet.

ps -ef | grep kubelet

Output yang diharapkan:

--enable-controller-attach-detach=true

true: Plugin penyimpanan adalah CSI.
false: Plugin penyimpanan adalah FlexVolume.

Bagaimana cara memberikan izin secara manual ke plugin CSI?

Plugin CSI memerlukan izin untuk mengakses resource cloud lain saat memasang, melepas pemasangan, membuat, atau menghapus volume. Secara default, CSI diinstal dan dikonfigurasi dengan izin yang diperlukan di kluster ACK. Untuk menyiapkan izin secara manual, lakukan langkah-langkah berikut.

Berikan izin menggunakan peran RAM (default): Plugin CSI menggunakan AliyunCSManagedCsiRole untuk mengakses resource di layanan Alibaba Cloud lainnya. Untuk informasi selengkapnya, lihat Peran layanan ACK.
- Kluster ACK yang dikelola: Untuk kluster ACK yang dikelola, token untuk peran RAM yang digunakan oleh CSI disimpan dalam Secret bernama addon.csi.token. Anda dapat memasang Secret ini untuk memberikan izin dan mengaktifkan akses API.
- Kluster khusus ACK: Untuk kluster khusus ACK, CSI mewarisi peran RAM yang ditetapkan ke node ECS tempat Pod-nya berjalan.
Untuk informasi selengkapnya tentang cara memberikan izin kepada peran RAM, lihat Kelola izin untuk peran RAM.
Berikan izin menggunakan Pasangan Kunci Akses
- Gunakan variabel lingkungan: Anda dapat membuat Pasangan Kunci Akses sebagai Secret Kubernetes dan menyuntikkannya ke Pod CSI sebagai variabel lingkungan. Hal ini mencegah kredensial terekspos dalam teks biasa di template penyebaran.
- Gunakan entri YAML langsung: Anda dapat menyematkan Pasangan Kunci Akses langsung di file YAML CSI. Metode ini tidak direkomendasikan untuk lingkungan produksi.

Container Service for Kubernetes:Ikhtisar penyimpanan