Change kluster to klaster mentioned in https://github.com/jk8s/sig-docs-id/issues/20 (#18130)
This commit is contained in:
irvifa
committed by
Kubernetes Prow Robot
Kubernetes Prow Robot
parent
a7f6a78d55
commit
39fe327423
@@ -7,9 +7,9 @@ weight: 40
|
||||
{{% capture overview %}}
|
||||
|
||||
Penyediaan volume dinamis memungkinkan volume penyimpanan untuk dibuat sesuai permintaan (_on-demand_).
|
||||
Tanpa adanya penyediaan dinamis (_dynamic provisioning_), untuk membuat volume penyimpanan baru, admin kluster secara manual harus
|
||||
Tanpa adanya penyediaan dinamis (_dynamic provisioning_), untuk membuat volume penyimpanan baru, admin klaster secara manual harus
|
||||
memanggil penyedia layanan cloud atau layanan penyimpanan, dan kemudian membuat [objek PersistentVolume](/docs/concepts/storage/persistent-volumes/)
|
||||
sebagai representasi di Kubernetes. Fitur penyediaan dinamis menghilangkan kebutuhan admin kluster untuk menyediakan
|
||||
sebagai representasi di Kubernetes. Fitur penyediaan dinamis menghilangkan kebutuhan admin klaster untuk menyediakan
|
||||
penyimpanan sebelumnya (_pre-provision_). Dengan demikian, penyimpanan akan tersedia secara otomatis
|
||||
ketika diminta oleh pengguna.
|
||||
|
||||
@@ -21,13 +21,13 @@ ketika diminta oleh pengguna.
|
||||
## Latar Belakang
|
||||
|
||||
Penyediaan volume dinamis diimplementasi berdasarkan objek API StorageClass dari
|
||||
grup API `storage.k8s.io`. Seorang admin kluster dapat mendefinisikan berbagai macam
|
||||
grup API `storage.k8s.io`. Seorang admin klaster dapat mendefinisikan berbagai macam
|
||||
objek StorageClass sesuai kebutuhan, masing-masing menentukan *plugin volume* (disebut
|
||||
juga *provisioner*) yang menyediakan sebuah volume beserta kumpulan parameter untuk
|
||||
diteruskan oleh _provisioner_ ketika proses penyediaan.
|
||||
|
||||
Seorang kluster admin dapat mendefinisikan dan mengekspos berbagai templat penyimpanan
|
||||
(dari sistem penyimpanan yang sama maupun berbeda) di dalam kluster, masing-masing dengan
|
||||
Seorang klaster admin dapat mendefinisikan dan mengekspos berbagai templat penyimpanan
|
||||
(dari sistem penyimpanan yang sama maupun berbeda) di dalam klaster, masing-masing dengan
|
||||
kumpulan parameter tertentu. Desain ini memastikan bahwa pengguna tidak perlu khawatir betapa
|
||||
rumitnya mekanisme penyediaan penyimpanan, tapi tetap memiliki kemampuan untuk
|
||||
memilih berbagai macam pilihan penyimpanan.
|
||||
@@ -36,7 +36,7 @@ Info lebih lanjut mengenai _storage class_ dapat dilihat [di sini](/docs/concept
|
||||
|
||||
## Mengaktifkan Penyediaan Dinamis (_Dynamic Provisioning_)
|
||||
|
||||
Untuk mengaktifkan penyediaan dinamis, seorang admin kluster perlu untuk
|
||||
Untuk mengaktifkan penyediaan dinamis, seorang admin klaster perlu untuk
|
||||
terlebih dahulu membuat (_pre-create_) satu atau beberapa objek StorageClass
|
||||
untuk pengguna.
|
||||
Objek StorageClass mendefinisikan _provisioner_ mana yang seharusnya digunakan
|
||||
@@ -100,9 +100,9 @@ Ketika klaim dihilangkan, volume akan musnah.
|
||||
|
||||
## Perilaku _Default_
|
||||
|
||||
Penyediaan dinamis dapat diaktifkan pada setiap kluster supaya semua klaim
|
||||
Penyediaan dinamis dapat diaktifkan pada setiap klaster supaya semua klaim
|
||||
dapat disediakan secara dinamis jika tidak ada StorageClass yang dispesifikasikan.
|
||||
Seorang kluster admin dapat mengaktifkan perilaku ini dengan cara:
|
||||
Seorang klaster admin dapat mengaktifkan perilaku ini dengan cara:
|
||||
|
||||
- Menandai satu objek StorageClass sebagai _default_;
|
||||
- Memastikan bahwa [_admission controller_ `DefaultStorageClass`](/docs/reference/access-authn-authz/admission-controllers/#defaultstorageclass)
|
||||
@@ -110,17 +110,17 @@ Seorang kluster admin dapat mengaktifkan perilaku ini dengan cara:
|
||||
|
||||
Seorang admin dapat menandai StorageClass yang spesifik sebagai _default_ dengan menambahkan
|
||||
anotasi `storageclass.kubernetes.io/is-default-class`.
|
||||
Ketika StorageClass default tersebut ada pada kluster dan pengguna membuat PersistentVolumeClaim
|
||||
Ketika StorageClass default tersebut ada pada klaster dan pengguna membuat PersistentVolumeClaim
|
||||
tanpa menspesifikasikan `storageClassName`, _admission controller_ `DefaultStorageClass` secara
|
||||
otomatis menambahkan _field_ `storageClassName` dengan StorageClass _default_.
|
||||
|
||||
Perhatikan bahwa hanya bisa ada satu _default_ StorageClass pada sebuah kluster,
|
||||
Perhatikan bahwa hanya bisa ada satu _default_ StorageClass pada sebuah klaster,
|
||||
atau PersistentVolumeClaim tanpa menspesifikasikan `storageClassName` secara eksplisit
|
||||
tidak bisa terbuat.
|
||||
|
||||
## Kesadaran (_Awareness_) Topologi
|
||||
|
||||
Pada kluster [Multi-Zona](/docs/setup/multiple-zones), Pod dapat tersebar di banyak Zona
|
||||
Pada klaster [Multi-Zona](/docs/setup/multiple-zones), Pod dapat tersebar di banyak Zona
|
||||
pada sebuah Region. Penyimpanan dengan *backend* Zona-Tunggal seharusnya disediakan pada
|
||||
Zona-Zona dimana Pod dijalankan. Hal ini dapat dicapai dengan mengatur
|
||||
[Mode Volume Binding](/docs/concepts/storage/storage-classes/#volume-binding-mode).
|
||||
|
||||
@@ -22,13 +22,13 @@ Dokumen ini menjelaskan kondisi terkini dari `PersistentVolumes` pada Kubernetes
|
||||
|
||||
Mengelola penyimpanan adalah hal yang berbeda dengan mengelola komputasi. Sub-sistem `PersistentVolume` (PV) menyediakan API untuk para pengguna dan administrator yang mengabstraksi detail-detail tentang bagaimana penyimpanan disediakan dari bagaimana penyimpanan dikonsumsi. Untuk melakukan ini, kami mengenalkan dua sumber daya API baru: `PersistentVolume` (PV) dan `PersistentVolumeClaim` (PVC).
|
||||
|
||||
Sebuah `PersistentVolume` (PV) adalah suatu bagian dari penyimpanan pada kluster yang telah disediakan oleh seorang administrator. PV merupakan sebuah sumber daya pada kluster sama halnya dengan _node_ yang juga merupakan sumber daya kluster. PV adalah _volume plugin_ seperti _Volumes_, tetapi memiliki siklus hidup yang independen dari _pod_ individual yang menggunakan PV tersebut. Objek API ini menangkap detail-detail implementasi dari penyimpanan, seperti NFS, iSCSI, atau sistem penyimpanan yang spesifik pada penyedia layanan _cloud_.
|
||||
Sebuah `PersistentVolume` (PV) adalah suatu bagian dari penyimpanan pada klaster yang telah disediakan oleh seorang administrator. PV merupakan sebuah sumber daya pada klaster sama halnya dengan _node_ yang juga merupakan sumber daya klaster. PV adalah _volume plugin_ seperti _Volumes_, tetapi memiliki siklus hidup yang independen dari _pod_ individual yang menggunakan PV tersebut. Objek API ini menangkap detail-detail implementasi dari penyimpanan, seperti NFS, iSCSI, atau sistem penyimpanan yang spesifik pada penyedia layanan _cloud_.
|
||||
|
||||
Sebuah `PersistentVolumeClaim` (PVC) merupakan permintaan penyimpanan oleh pengguna. PVC mirip dengan sebuah _pod_. _Pod_ mengonsumsi sumber daya _node_ dan PVC mengonsumsi sumber daya PV. _Pods_ dapat meminta taraf-taraf spesifik dari sumber daya (CPU dan Memory). Klaim dapat meminta ukuran dan mode akses yang spesifik (seperti, dapat dipasang sekali sebagai _read/write_ atau lain kali sebagai _read-only_).
|
||||
|
||||
Meskipun `PersistentVolumeClaims` mengizinkan pengguna untuk mengkonsumsi sumber daya penyimpanan
|
||||
abstrak, pada umumnya para pengguna membutuhkan `PersistentVolumes` dengan properti yang
|
||||
bermacam-macam, seperti performa, untuk mengatasi masalah yang berbeda. Para administrator kluster
|
||||
bermacam-macam, seperti performa, untuk mengatasi masalah yang berbeda. Para administrator klaster
|
||||
harus dapat menawarkan berbagai macam `PersistentVolumes` yang berbeda tidak hanya pada ukuran dan
|
||||
mode akses, tanpa memaparkan detail-detail bagaimana cara volume tersebut diimplementasikan
|
||||
kepada para pengguna. Untuk mengatasi hal ini maka dibutuhkan sumber daya
|
||||
@@ -39,20 +39,20 @@ Silakan lihat [panduan mendetail dengan contoh-contoh yang sudah berjalan](/docs
|
||||
|
||||
## Siklus hidup dari sebuah volume dan klaim
|
||||
|
||||
PV adalah sumber daya dalam sebuah kluster. PVC adalah permintaan terhadap sumber daya tersebut dan juga berperan sebagai pemeriksaan klaim dari sumber daya yang diminta. Interaksi antara PV dan PVC mengikuti siklus hidup berikut ini:
|
||||
PV adalah sumber daya dalam sebuah klaster. PVC adalah permintaan terhadap sumber daya tersebut dan juga berperan sebagai pemeriksaan klaim dari sumber daya yang diminta. Interaksi antara PV dan PVC mengikuti siklus hidup berikut ini:
|
||||
|
||||
### Penyediaan
|
||||
|
||||
Ada dua cara untuk menyediakan PV: secara statis atau dinamis.
|
||||
|
||||
#### Statis
|
||||
Seorang administrator kluster membuat beberapa PV. PV yang telah dibuat membawa detail-detail dari penyimpanan yang sesungguhnya tersedia untuk digunakan oleh pengguna kluster. PV tersebut ada pada Kubernetes API dan siap untuk digunakan.
|
||||
Seorang administrator klaster membuat beberapa PV. PV yang telah dibuat membawa detail-detail dari penyimpanan yang sesungguhnya tersedia untuk digunakan oleh pengguna klaster. PV tersebut ada pada Kubernetes API dan siap untuk digunakan.
|
||||
|
||||
#### Dinamis
|
||||
Ketika tidak ada PV statis yang dibuat oleh administrator yang sesuai dengan `PersistentVolumeClaim` (PVC) yang dibuat oleh pengguna, kluster akan mencoba untuk menyediakan volume khusus sesuai permintaan PVC.
|
||||
Ketika tidak ada PV statis yang dibuat oleh administrator yang sesuai dengan `PersistentVolumeClaim` (PVC) yang dibuat oleh pengguna, klaster akan mencoba untuk menyediakan volume khusus sesuai permintaan PVC.
|
||||
Penyediaan dinamis ini berbasis `StorageClass`: artinya PVC harus meminta sebuah _storage class_ dan _storage class_ tersebut harus sudah dibuat dan dikonfigurasi oleh administrator agar penyediaan dinamis bisa terjadi. Klaim yang meminta PV dengan _storage class_ `""` secara efektif telah menonaktifkan penyediaan dinamis.
|
||||
|
||||
Untuk mengaktifkan penyediaan _storage_ dinamis berdasarkan _storage class_, administrator kluster harus mengaktifkan [_admission controller_](/docs/reference/access-authn-authz/admission-controllers/#defaultstorageclass)
|
||||
Untuk mengaktifkan penyediaan _storage_ dinamis berdasarkan _storage class_, administrator klaster harus mengaktifkan [_admission controller_](/docs/reference/access-authn-authz/admission-controllers/#defaultstorageclass)
|
||||
`DefaultStorageClass` pada API _server_. Hal ini dapat dilakukan, dengan cara memastikan `DefaultStorageClass` ada di antara urutan daftar _value_ yang dibatasi koma untuk _flag_ `--enable-admission-plugins` pada komponen API _server_. Untuk informasi lebih lanjut mengenai _flag_ perintah pada API _server_, silakan cek dokumentasi,
|
||||
[kube-apiserver](/docs/admin/kube-apiserver/).
|
||||
|
||||
@@ -60,11 +60,11 @@ Untuk mengaktifkan penyediaan _storage_ dinamis berdasarkan _storage class_, adm
|
||||
|
||||
Seorang pengguna membuat, atau telah membuat (dalam kasus penyediaan dinamis), sebuah `PersistentVolumeClaim` (PVC) dengan jumlah penyimpanan spesifik yang diminta dan dengan mode akses tertentu. Sebuah _control loop_ pada _master_ akan melihat adanya PVC baru, mencari PV yang cocok (jika memungkinkan), dan mengikat PVC dengan PV tersebut. Jika sebuah PV disediakan secara dinamis untuk sebuah PVC baru, _loop_ tersebut akan selalu mengikat PV tersebut pada PVC yang baru dibuat itu. Jika tidak, pengguna akan selalu mendapatkan setidaknya apa yang dimintanya, tetapi volume tersebut mungkin lebih dari apa yang diminta sebelumnya. Setelah terikat, ikatan `PersistentVolumeClaim` (PVC) bersifat eksklusif, terlepas dari bagaimana caranya mereka bisa terikat. Sebuah ikatan PVC ke PV merupakan pemetaan satu ke satu.
|
||||
|
||||
Klaim akan berada dalam kondisi tidak terikat tanpa kepastian jika tidak ada volume yang cocok. Klaim akan terikat dengan volume yang cocok ketika ada volume yang cocok. Sebagai contoh, sebuah kluster yang sudah menyediakan banyak PV berukuran 50Gi tidak akan cocok dengan PVC yang meminta 100Gi. PVC hanya akan terikat ketika ada PV 100Gi yang ditambahkan ke kluster.
|
||||
Klaim akan berada dalam kondisi tidak terikat tanpa kepastian jika tidak ada volume yang cocok. Klaim akan terikat dengan volume yang cocok ketika ada volume yang cocok. Sebagai contoh, sebuah klaster yang sudah menyediakan banyak PV berukuran 50Gi tidak akan cocok dengan PVC yang meminta 100Gi. PVC hanya akan terikat ketika ada PV 100Gi yang ditambahkan ke klaster.
|
||||
|
||||
### Penggunaan
|
||||
|
||||
_Pod_ menggunakan klaim sebagai volume. Kluster menginspeksi klaim untuk menemukan volume yang terikat dengan klaim tersebut dan memasangkan volume tersebut ke pada _pod_. Untuk volume yang mendukung banyak mode akses, pengguna yang menentukan mode yang diinginkan ketika menggunakan klaim sebagai volume dalam sebuah _pod_.
|
||||
_Pod_ menggunakan klaim sebagai volume. Klaster menginspeksi klaim untuk menemukan volume yang terikat dengan klaim tersebut dan memasangkan volume tersebut ke pada _pod_. Untuk volume yang mendukung banyak mode akses, pengguna yang menentukan mode yang diinginkan ketika menggunakan klaim sebagai volume dalam sebuah _pod_.
|
||||
|
||||
Ketika pengguna memiliki klaim dan klaim tersebut telah terikat, PV yang terikat menjadi hak penggunanya selama yang dibutuhkan. Pengguna menjadwalkan _pod_ dan mengakses PV yang sudah diklaim dengan menambahkan `persistentVolumeClaim` pada blok volume pada _Pod_ miliknya. [Lihat pranala di bawah untuk detail-detail mengenai sintaks](#claims-as-volumes).
|
||||
|
||||
@@ -117,7 +117,7 @@ Events: <none>
|
||||
|
||||
### Melakukan Reklaim
|
||||
|
||||
Ketika seorang pengguna telah selesai dengan volumenya, ia dapat menghapus objek PVC dari API yang memungkinkan untuk reklamasi dari sumber daya tersebut. Kebijakan reklaim dari sebuah `PersistentVolume` (PV) menyatakan apa yang dilakukan kluster setelah volume dilepaskan dari klaimnya. Saat ini, volume dapat dipertahankan (_Retained_), didaur ulang (_Recycled_), atau dihapus (_Deleted_).
|
||||
Ketika seorang pengguna telah selesai dengan volumenya, ia dapat menghapus objek PVC dari API yang memungkinkan untuk reklamasi dari sumber daya tersebut. Kebijakan reklaim dari sebuah `PersistentVolume` (PV) menyatakan apa yang dilakukan klaster setelah volume dilepaskan dari klaimnya. Saat ini, volume dapat dipertahankan (_Retained_), didaur ulang (_Recycled_), atau dihapus (_Deleted_).
|
||||
|
||||
#### _Retain_
|
||||
|
||||
@@ -266,7 +266,7 @@ Tipe-tipe `PersistentVolume` (PV) diimplementasikan sebagai _plugin_. Kubernete
|
||||
* Glusterfs
|
||||
* VsphereVolume
|
||||
* Quobyte Volumes
|
||||
* HostPath (Hanya untuk pengujian _single node_ -- penyimpanan lokal tidak didukung dan TIDAK AKAN BEKERJA pada kluster _multi-node_)
|
||||
* HostPath (Hanya untuk pengujian _single node_ -- penyimpanan lokal tidak didukung dan TIDAK AKAN BEKERJA pada klaster _multi-node_)
|
||||
* Portworx Volumes
|
||||
* ScaleIO Volumes
|
||||
* StorageOS
|
||||
@@ -419,7 +419,7 @@ Sebuah volume akan berada dalam salah satu fase di bawah ini:
|
||||
|
||||
* Available -- sumber daya bebas yang belum terikat dengan sebuah klaim
|
||||
* Bound -- volume sudah terikat dengan sebuah klaim
|
||||
* Released -- klaim sudah dihapus, tetapi sumber daya masih belum direklaim oleh kluster
|
||||
* Released -- klaim sudah dihapus, tetapi sumber daya masih belum direklaim oleh klaster
|
||||
* Failed -- volume gagal menjalankan reklamasi otomatis
|
||||
|
||||
CLI akan menunjukkan nama dari PVC yang terikat pada PV.
|
||||
@@ -481,7 +481,7 @@ PVC tidak harus meminta sebuah kelas. Sebuah PVC dengan `storageClassName` milik
|
||||
`""` akan selalu diinterpretasikan sebagai meminta PV tanpa kelas, jadi PVC
|
||||
hanya bisa terikat ke PV tanpa kelas (tanpa anotasi atau bernilai
|
||||
`""`). Sebuah PVC tanpa `storageClassName` tidaklah sama dan diperlakukan berbeda
|
||||
oleh kluster tergantung apakah
|
||||
oleh klaster tergantung apakah
|
||||
[_admission plugin_ `DefaultStorageClass`](/docs/reference/access-authn-authz/admission-controllers/#defaultstorageclass)
|
||||
dinyalakan.
|
||||
|
||||
@@ -490,7 +490,7 @@ dinyalakan.
|
||||
PVs standar. Menspesifikasikan `StorageClass` standar dapat dilakukan dengan mengatur
|
||||
anotasi `storageclass.kubernetes.io/is-default-class` menjadi "_true_" pada
|
||||
sebuah objek `StorageClass`. Jika administrator tidak menspesifikasikan standar apapun,
|
||||
kluster menanggapi pembuatan PVC sekan-akan _admission plugin_ dimatikan. Jika
|
||||
klaster menanggapi pembuatan PVC sekan-akan _admission plugin_ dimatikan. Jika
|
||||
ada lebih dari satu setelan standar dispesifikasikan, _admission plugin_ melarang pembuatan seluruh
|
||||
PVC.
|
||||
* Jika _admission plugin_ dimatikan, tidak ada pilihan menggunakan
|
||||
@@ -499,7 +499,7 @@ dinyalakan.
|
||||
sama seperti PVC yang memiliki `storageClassName` bernilai `""`.
|
||||
|
||||
Tergantung metode instalasi, sebuah StorageClass dari setelan standar dapat dibuat
|
||||
ke kluster Kubernetes oleh _addon manager_ pada saat instalasi.
|
||||
ke klaster Kubernetes oleh _addon manager_ pada saat instalasi.
|
||||
|
||||
Ketika sebuah PVC menspesifikasi sebuah `selector` selain meminta `StorageClass`,
|
||||
kebutuhan tersebut akan digabungkan dengan operasi AND bersama: hanya PV dari kelas yang diminta dan dengan
|
||||
@@ -515,7 +515,7 @@ akan dihilangkan sepenuhnya pada rilis Kubernetes mendatang.
|
||||
|
||||
## Klaim sebagai Volume
|
||||
|
||||
_Pod_ mengakses _storage_ dengan menggunakan klaim sebagai volume. Klaim harus berada pada _namespace_ yang sama dengan _pod_ yang menggunakan klaim tersebut. Kluster menemukan klaim pada _namespace_ yang sama dengan _pod_ dan menggunakannya untuk mendapatkan `PersistentVolume` (PV) yang ada di baliknya. Volume tersebut kemudian dipasangkan ke _host_ dan lalu ke _pod_.
|
||||
_Pod_ mengakses _storage_ dengan menggunakan klaim sebagai volume. Klaim harus berada pada _namespace_ yang sama dengan _pod_ yang menggunakan klaim tersebut. Klaster menemukan klaim pada _namespace_ yang sama dengan _pod_ dan menggunakannya untuk mendapatkan `PersistentVolume` (PV) yang ada di baliknya. Volume tersebut kemudian dipasangkan ke _host_ dan lalu ke _pod_.
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
@@ -669,7 +669,7 @@ spec:
|
||||
|
||||
## Menulis Konfigurasi Portabel
|
||||
|
||||
Jika kamu menulis templat konfigurasi atau contoh yang dapat berjalan pada berbagai macam kluster
|
||||
Jika kamu menulis templat konfigurasi atau contoh yang dapat berjalan pada berbagai macam klaster
|
||||
dan membutuhkan _persistent storage_, kami merekomendasikan agar kamu menggunakan pola berikut:
|
||||
|
||||
- Masukkan objek PersistentVolumeClaim (PVC) pada kumpulan _config_ (bersamaan dengan
|
||||
@@ -681,17 +681,17 @@ dan membutuhkan _persistent storage_, kami merekomendasikan agar kamu menggunaka
|
||||
- Jika pengguna menyediakan nama _storage class_, taruh nilai tersebut pada
|
||||
kolom `persistentVolumeClaim.storageClassName`.
|
||||
Hal ini akan membuat PVC agar sesuai dengan _storage class_
|
||||
yang tepat jika kluster memiliki banyak StorageClass yang diaktifkan oleh admin.
|
||||
yang tepat jika klaster memiliki banyak StorageClass yang diaktifkan oleh admin.
|
||||
- Jika pengguna tidak menyediakan nama _storage class_, biarkan
|
||||
kolom `persistentVolumeClaim.storageClassName` kosong.
|
||||
- Hal ini kakan membuat sebuah PV disediakan secara otomatis untuk pengguna dengan
|
||||
StorageClass standar pada kluster. Banyak lingkungan kluster memiliki
|
||||
StorageClass standar pada klaster. Banyak lingkungan klaster memiliki
|
||||
StorageClass standar yang sudah terpasang, atau administrator dapat membuat
|
||||
StorageClass standar sendiri.
|
||||
- Dalam pembuatan, perhatikan PVC yang tidak kunjung terikat setelah beberapa lama
|
||||
dan beritahukan hal ini pada pengguna, karena hal ini dapat mengindikasikan kluster tidak
|
||||
dan beritahukan hal ini pada pengguna, karena hal ini dapat mengindikasikan klaster tidak
|
||||
memiliki dukungan penyimpanan dinamis (di mana pengguna harus membuat PV yang sesuai)
|
||||
atau kluster tidak memiliki sistem penyimpanan (di mana penggun tidak dapat membuat
|
||||
atau klaster tidak memiliki sistem penyimpanan (di mana penggun tidak dapat membuat
|
||||
PVC yang membutuhkan _config_).
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
@@ -21,7 +21,7 @@ Sebuah StorageClass menyediakan cara bagi administrator untuk
|
||||
mendeskripsikan "kelas" dari penyimpanan yang mereka sediakan.
|
||||
Kelas yang berbeda bisa saja memiliki perbedaan dari segi kualitas
|
||||
servis yang disediakan, pemulihan (_backup_) kebijakan, atau kebijakan lain yang ditentukan
|
||||
oleh administrator kluster. Kubernetes sendiri tidak dipengaruhi oleh
|
||||
oleh administrator klaster. Kubernetes sendiri tidak dipengaruhi oleh
|
||||
kelas apakah yang digunakan pada mekanisme penyimpanan yang digunakan.
|
||||
Mekanisme ini seringkali disebut sebagai _"profiles"_ pada sistem penyimpanan
|
||||
yang lain.
|
||||
@@ -138,11 +138,11 @@ Secara _default_, ketika mode `Immediate` yang mengindikasikan
|
||||
terjadinya volume _binding_ dan _provisioning_ dinamis terjadi ketika
|
||||
PersistentVolumeClaim dibuat. Untuk _backend_ penyimpanan yang dibatasi oleh
|
||||
topologi tertentu dan tidak dapat diakses secara global dari semua Node
|
||||
yang ada di kluster, PersistentVolume akan di-_bound_ atau di-_provision_
|
||||
yang ada di klaster, PersistentVolume akan di-_bound_ atau di-_provision_
|
||||
tanpa perlu memenuhi persyaratan _scheduling_ dari Pod. Hal ini dapat menyebabkan
|
||||
adanya Pod yang tidak mendapatkan mekanisme _scheduling_.
|
||||
|
||||
Seorang administrator kluster dapat mengatasi hal tersebut dengan cara memberikan
|
||||
Seorang administrator klaster dapat mengatasi hal tersebut dengan cara memberikan
|
||||
spesifikasi mode `WaitForFirstConsumer` yang akan memperlambat mekanisme _provisioning_
|
||||
dan _binding_ dari sebuah PersistentVolume hingga sebuah Pod yang menggunakan
|
||||
PersistentVolumeClaim dibuat. PersistentVolume akan dipilih atau di-_provisioning_
|
||||
@@ -176,7 +176,7 @@ beserta contoh penggunaannya. _Feature gate_ `CSINodeInfo` haruslah diaktifkan.
|
||||
|
||||
### Topologi yang Diizinkan
|
||||
|
||||
Ketika sebuah operator kluster memberikan spesifikasi `WaitForFirstConsumer` pada
|
||||
Ketika sebuah operator klaster memberikan spesifikasi `WaitForFirstConsumer` pada
|
||||
mode `binding` volume, mekanisme pembatasan (restriksi) `provisioning` tidak lagi dibutuhkan
|
||||
pada sebagian besar kasus. Meskipun begitu, apabila hal tersebut masih dibutuhkan,
|
||||
`field` `allowedTopologies` dapat dispesifikasikan.
|
||||
@@ -230,12 +230,12 @@ parameters:
|
||||
untuk detail lebih lanjut. Nilai _default_: `gp2`.
|
||||
* `zone` (_deprecated_): zona AWS. Jika tidak terdapat nilai `zone` atau `zones`
|
||||
yang dispesifikasikan, volume secara generik dijadwalkan dengan menggunakan
|
||||
penjadwalan `round-robin-ed` pada semua zona aktif yang ada pada kluster Kubernetes
|
||||
penjadwalan `round-robin-ed` pada semua zona aktif yang ada pada klaster Kubernetes
|
||||
yang memiliki _node_.
|
||||
* `zones` (_deprecated_): Nilai terpisahkan koma yang merupakan barisan zona pada AWS.
|
||||
Jika tidak terdapat nilai `zone` atau `zones` yang dispesifikasikan,
|
||||
volume secara generik dijadwalkan dengan menggunakan penjadwalan
|
||||
`round-robin-ed` pada semua zona aktif yang ada pada kluster Kubernetes
|
||||
`round-robin-ed` pada semua zona aktif yang ada pada klaster Kubernetes
|
||||
yang memiliki _node_.
|
||||
* `iopsPerGB`: hanya untuk volume `io1`. Operasi per detik per GiB. Volume _plugin_
|
||||
AWS mengalikan nilai ini dengan ukuran volume yang dibutuhkan untuk menghitung IOPS
|
||||
@@ -271,12 +271,12 @@ parameters:
|
||||
* `type`: `pd-standard` atau `pd-ssd`. Nilai _default_: `pd-standard`
|
||||
* `zone` (_deprecated_): zona GCE. Jika tidak terdapat nilai `zone` atau `zones`
|
||||
yang dispesifikasikan, volume secara generik dijadwalkan dengan menggunakan
|
||||
penjadwalan `round-robin-ed` pada semua zona aktif yang ada pada kluster Kubernetes
|
||||
penjadwalan `round-robin-ed` pada semua zona aktif yang ada pada klaster Kubernetes
|
||||
yang memiliki _node_.
|
||||
* `zones` (_deprecated_): Nilai terpisahkan koma yang merupakan barisan zona.
|
||||
Jika tidak terdapat nilai `zone` atau `zones` yang dispesifikasikan,
|
||||
volume secara generik dijadwalkan dengan menggunakan penjadwalan
|
||||
`round-robin-ed` pada semua zona aktif yang ada pada kluster Kubernetes
|
||||
`round-robin-ed` pada semua zona aktif yang ada pada klaster Kubernetes
|
||||
yang memiliki _node_.
|
||||
* `replication-type`: `none` atau `regional-pd`. Nilai _default_: `none`.
|
||||
|
||||
@@ -291,7 +291,7 @@ tepat dua zona yang dispesifikasikan, PD Regional akan di-_provisioning_ pada
|
||||
zona replikasi yang diinginkan. Jika terdapat lebih dari 2 zona yang dispesifikasikan,
|
||||
Kubernetes akan memilih secara acak zona dari zona-zona yang dispesifikasikan. Jika
|
||||
parameter `zones` tidak diinisialisasi, Kubernetes akan memilih secara acak dari
|
||||
zona yang diatur oleh kluster Kubernetes.
|
||||
zona yang diatur oleh klaster Kubernetes.
|
||||
|
||||
{{< note >}}
|
||||
Parameter `zone` dan `zones` sudah _deprecated_ dan digantikan oleh
|
||||
@@ -351,7 +351,7 @@ parameters:
|
||||
Contoh Secret dapat ditemukan pada berkas berikut
|
||||
[glusterfs-provisioning-secret.yaml](https://github.com/kubernetes/examples/tree/master/staging/persistent-volume-provisioning/glusterfs/glusterfs-secret.yaml).
|
||||
|
||||
* `clusterid`: `630372ccdc720a92c681fb928f27b53f` merupakan ID dari kluster
|
||||
* `clusterid`: `630372ccdc720a92c681fb928f27b53f` merupakan ID dari klaster
|
||||
yang akan digunakan oleh Heketi ketikan melakukan _provisioning_ volume. ID ini juga
|
||||
dapat berupa serangkaian list, misalnya: `"8452344e2becec931ece4e33c4674e4e,42982310de6c63381718ccfa6d8cf397"`.
|
||||
Parameter ini merupakan parameter opsional.
|
||||
@@ -396,7 +396,7 @@ parameters:
|
||||
|
||||
* `availability`: Zona _Availability_. Jika tidak dispesifikasikan, secara umum volume akan
|
||||
diatur dengan menggunakan algoritma _round-robin_ pada semua zona aktif
|
||||
dimana kluster Kubernetes memiliki sebuah node.
|
||||
dimana klaster Kubernetes memiliki sebuah node.
|
||||
|
||||
{{< note >}}
|
||||
{{< feature-state state="deprecated" for_k8s_version="1.11" >}}
|
||||
@@ -581,9 +581,9 @@ parameters:
|
||||
* `skuName`: Akun penyimpanan Azure yang ada pada tingkatan Sku. Nilai _default_-nya adalah kosong.
|
||||
* `location`: Lokasi akun penyimpanan Azure. Nilai _default_-nya adalah kosong.
|
||||
* `storageAccount`: Nama akun penyimpanan Azure. Jika sebuan akun penyimpanan disediakan,
|
||||
akun tersebut haruslah berada pada grup sumber daya yang ada dengan kluster,
|
||||
akun tersebut haruslah berada pada grup sumber daya yang ada dengan klaster,
|
||||
dan `location` akan diabaikan. Jika sebuah akun penyimpanan tidak disediakan, sebuah akun penyimpanan
|
||||
baru akan dibuat pada grup sumber daya yang ada dengan kluster.
|
||||
baru akan dibuat pada grup sumber daya yang ada dengan klaster.
|
||||
|
||||
#### Kelas Penyimpanan Disk Azure yang Baru (mulai versi v1.7.2)
|
||||
|
||||
@@ -601,10 +601,10 @@ parameters:
|
||||
* `storageaccounttype`: Akun penyimpanan Azure yang ada pada tingkatan Sku. Nilai _default_-nya adalah kosong.
|
||||
* `kind`: Nilai yang mungkin adalah `shared` (default), `dedicated`, dan `managed`.
|
||||
Ketika `kind` yang digunakan adalah `shared`, semua disk yang tidak di-_manage_ akan
|
||||
dibuat pada beberapa akun penyimpanan yang ada pada grup sumber daya yang sama dengan kluster.
|
||||
dibuat pada beberapa akun penyimpanan yang ada pada grup sumber daya yang sama dengan klaster.
|
||||
Ketika `kind` yang digunakan adalah `dedicated`, sebuah akun penyimpanan
|
||||
baru akan dibuat pada grup sumber daya yang ada dengan kluster. Ketika `kind` yang digunakan adalah
|
||||
`managed`, semua disk yang dikelola akan dibuat pada grup sumber daya yang ada dengan kluster.
|
||||
baru akan dibuat pada grup sumber daya yang ada dengan klaster. Ketika `kind` yang digunakan adalah
|
||||
`managed`, semua disk yang dikelola akan dibuat pada grup sumber daya yang ada dengan klaster.
|
||||
|
||||
- VM premium dapat di-_attach_ baik pada Standard_LRS dan Premium_LRS disks, sementara Standard
|
||||
VM hanya dapat di-_attach_ pada disk Standard_LRS.
|
||||
@@ -631,9 +631,9 @@ parameters:
|
||||
tidak memiliki sebuah akun yang disediakan, semua akun penyimpanan yang diasosiasikan dengan
|
||||
grup sumber daya yang ada dan kemudian melakukan pencarian terhadap akun yang sesuai dengan
|
||||
`skuName` dan `location`. Jika sebuah akun penyimpanan disediakan, akun tersebut haruslah berada
|
||||
di dalam grup sumber daya yang sama dengan kluster, serta `skuName` dan `location` akan diabaikan.
|
||||
di dalam grup sumber daya yang sama dengan klaster, serta `skuName` dan `location` akan diabaikan.
|
||||
|
||||
Selama _provision_, sebuah secret dibuat untuk menyimpan _credentials_. Jika kluster
|
||||
Selama _provision_, sebuah secret dibuat untuk menyimpan _credentials_. Jika klaster
|
||||
menggunakan konsep [RBAC](/docs/reference/access-authn-authz/rbac/) dan
|
||||
[_Roles_ Controller](/docs/reference/access-authn-authz/rbac/#controller-roles),
|
||||
menambahkan kapabilitas `create` untuk sumber daya `secret` bagi clusterrole
|
||||
|
||||
@@ -39,7 +39,7 @@ Berhati-hatilah jika kamu menerapkan limit yang lebih besar dari limit _default_
|
||||
Perhatikan dokumentasi penyedia layanan cloud untuk hal ini, dan pastikan Node
|
||||
benar-benar dapat mendukung nilai limit yang kamu inginkan.
|
||||
|
||||
Limit ini diterapkan untuk seluruh kluster, jadi akan berdampak pada semua Node.
|
||||
Limit ini diterapkan untuk seluruh klaster, jadi akan berdampak pada semua Node.
|
||||
|
||||
## Limit volume dinamis
|
||||
|
||||
|
||||
@@ -18,11 +18,11 @@ Laman ini menjelaskan tentang fitur VolumeSnapshot pada Kubernetes. Sebelum lanj
|
||||
|
||||
Seperti halnya sumber daya API PersistentVolume dan PersistentVolumeClaim yang digunakan oleh para pengguna dan administrator untuk menyediakan volume, sumber daya API VolumeSnapshotContent dan VolumeSnapshot digunakan mereka untuk membuat _snapshot_ volume.
|
||||
|
||||
VolumeSnapshotContent merupakan suatu _snapshot_ yang diambil dari sebuah volume dari dalam kluster yang telah disediakan oleh administrator. Sepert layaknya PersistentVolume, VolumeSnapshotContent juga merupakan bagian dari sumber daya kluster.
|
||||
VolumeSnapshotContent merupakan suatu _snapshot_ yang diambil dari sebuah volume dari dalam klaster yang telah disediakan oleh administrator. Sepert layaknya PersistentVolume, VolumeSnapshotContent juga merupakan bagian dari sumber daya klaster.
|
||||
|
||||
VolumeSnapshot merupakan suatu permintaan _snapshot_ dari volume oleh pengguna. Mirip seperti halnya PersistentVolumeClaim.
|
||||
|
||||
Walaupun VolumeSnapshot membuat pengguna bisa mengonsumsi abstraksi dari sumber daya penyimpanan, administrator kluster tetap perlu
|
||||
Walaupun VolumeSnapshot membuat pengguna bisa mengonsumsi abstraksi dari sumber daya penyimpanan, administrator klaster tetap perlu
|
||||
menawarkan berbagai macam tipe VolumeSnapshotContent, tanpa perlu mengekspos pengguna pada detail bagaimana _snapshot_
|
||||
volume tersebut harus tersediakan. Bagi yang memerlukan hal ini, ada yang namanya sumber daya VolumeSnapshotClass.
|
||||
|
||||
@@ -36,17 +36,17 @@ Para pengguna tetap perlu mengetahui beberapa hal di bawah ketika menggunakan fi
|
||||
|
||||
## Siklus hidup VolumeSnapshot dan VolumeSnapshotContent
|
||||
|
||||
VolumeSnapshotContent merupakan bagian dari sumber daya kluster. VolumeSnapshot merupakan permintaan terhadap sumber daya tersebut. Interaksi antara VolumeSnapshotContent dan VolumeSnapshot mengikuti siklus hidup berikut ini:
|
||||
VolumeSnapshotContent merupakan bagian dari sumber daya klaster. VolumeSnapshot merupakan permintaan terhadap sumber daya tersebut. Interaksi antara VolumeSnapshotContent dan VolumeSnapshot mengikuti siklus hidup berikut ini:
|
||||
|
||||
### Penyediaan VolumeSnapshot
|
||||
|
||||
Ada dua cara untuk menyediakan _snapshot_: secara statis maupun dinamis.
|
||||
|
||||
#### Statis
|
||||
Seorang adminstrator kluster membuat beberapa VolumeSnapshotContent, yang masing-masing memiliki detail tentang penyimpanan sebenarnya yang dapat dipergunakan oleh para pengguna. VolumeSnapshotContent tersebut dapat dikonsumsi melalui API Kubernetes.
|
||||
Seorang adminstrator klaster membuat beberapa VolumeSnapshotContent, yang masing-masing memiliki detail tentang penyimpanan sebenarnya yang dapat dipergunakan oleh para pengguna. VolumeSnapshotContent tersebut dapat dikonsumsi melalui API Kubernetes.
|
||||
|
||||
#### Dinamis
|
||||
Ketika VolumeSnapshotContent yang dibuat oleh administrator tidak ada yang sesuai dengan VolumeSnapshot yang dibuat pengguna, kluster bisa saja
|
||||
Ketika VolumeSnapshotContent yang dibuat oleh administrator tidak ada yang sesuai dengan VolumeSnapshot yang dibuat pengguna, klaster bisa saja
|
||||
mencoba untuk menyediakan sebuah VolumeSnapshot secara dinamis, khususnya untuk objek VolumeSnapshot.
|
||||
Proses penyediaan ini berdasarkan VolumeSnapshotClasses: VolumeSnapshot harus meminta sebuah [VolumeSnapshotClass](/docs/concepts/storage/volume-snapshot-classes/)
|
||||
dan administrator harus membuat serta mengatur _class_ tersebut supaya penyediaan dinamis bisa terjadi.
|
||||
|
||||
@@ -83,7 +83,7 @@ Sebelum kamu dapat menggunakan sebuah volume EBS pada sebuah Pod, kamu harus mem
|
||||
aws ec2 create-volume --availability-zone=eu-west-1a --size=10 --volume-type=gp2
|
||||
```
|
||||
|
||||
Pastikan _availability zone_ yang kamu masukkan sama dengan _availability zone_ kluster kamu. (Dan pastikan juga ukuran dan jenis EBSnya sesuai dengan penggunaan yang kamu butuhkan!)
|
||||
Pastikan _availability zone_ yang kamu masukkan sama dengan _availability zone_ klaster kamu. (Dan pastikan juga ukuran dan jenis EBSnya sesuai dengan penggunaan yang kamu butuhkan!)
|
||||
|
||||
#### Contoh Konfigurasi AWS EBS
|
||||
|
||||
@@ -111,7 +111,7 @@ spec:
|
||||
|
||||
{{< feature-state for_k8s_version="v1.14" state="alpha" >}}
|
||||
|
||||
Pada saat fitur migrasi CSI (Container Storage Interface) untuk `awsElasticBlockStore` diaktifkan, fitur ini akan menterjemahkan semua operasi _plugin_ dari _plugin_ yang sudah ada di kode inti Kubernetes ke bentuk Driver CSI `ebs.csi.aws.com`. Untuk menggunakan fitur ini, [Driver CSI AWS EBS](https://github.com/kubernetes-sigs/aws-ebs-csi-driver) harus dinstal di kluster dan fitur Alpha `CSIMigration` serta `CSIMigrationAWS` harus diaktifkan.
|
||||
Pada saat fitur migrasi CSI (Container Storage Interface) untuk `awsElasticBlockStore` diaktifkan, fitur ini akan menterjemahkan semua operasi _plugin_ dari _plugin_ yang sudah ada di kode inti Kubernetes ke bentuk Driver CSI `ebs.csi.aws.com`. Untuk menggunakan fitur ini, [Driver CSI AWS EBS](https://github.com/kubernetes-sigs/aws-ebs-csi-driver) harus dinstal di klaster dan fitur Alpha `CSIMigration` serta `CSIMigrationAWS` harus diaktifkan.
|
||||
|
||||
### azureDisk {#azuredisk}
|
||||
|
||||
@@ -123,7 +123,7 @@ Selengkapnya dapat ditemukan [di sini](https://github.com/kubernetes/examples/tr
|
||||
|
||||
{{< feature-state for_k8s_version="v1.15" state="alpha" >}}
|
||||
|
||||
Pada saat fitur migrasi CSI untuk `azureDisk` diaktifkan, fitur ini akan menterjemahkan semua operasi _plugin_ dari _plugin_ yang sudah ada di kode inti Kubernetes ke bentuk Driver CSI `disk.csi.azure.com`. Untuk menggunakan fitur ini, [Driver CSI Azure Disk](https://github.com/kubernetes-sigs/azuredisk-csi-driver) harus dinstal di kluster dan fitur Alpha `CSIMigration` serta `CSIMigrationAzureDisk` harus diaktifkan.
|
||||
Pada saat fitur migrasi CSI untuk `azureDisk` diaktifkan, fitur ini akan menterjemahkan semua operasi _plugin_ dari _plugin_ yang sudah ada di kode inti Kubernetes ke bentuk Driver CSI `disk.csi.azure.com`. Untuk menggunakan fitur ini, [Driver CSI Azure Disk](https://github.com/kubernetes-sigs/azuredisk-csi-driver) harus dinstal di klaster dan fitur Alpha `CSIMigration` serta `CSIMigrationAzureDisk` harus diaktifkan.
|
||||
|
||||
### azureFile {#azurefile}
|
||||
|
||||
@@ -135,7 +135,7 @@ Selengkapnya dapat ditemukan [di sini](https://github.com/kubernetes/examples/tr
|
||||
|
||||
{{< feature-state for_k8s_version="v1.15" state="alpha" >}}
|
||||
|
||||
Pada saat fitur migrasi CSI untuk `azureFile` diaktifkan, fitur ini akan menterjemahkan semua operasi _plugin_ dari _plugin_ yang sudah ada di kode inti Kubernetes ke bentuk Driver CSI `file.csi.azure.com`. Untuk menggunakan fitur ini, [Driver CSI Azure File](https://github.com/kubernetes-sigs/azuredisk-csi-driver) harus dinstal di kluster dan fitur Alpha `CSIMigration` serta `CSIMigrationAzureFile` harus diaktifkan.
|
||||
Pada saat fitur migrasi CSI untuk `azureFile` diaktifkan, fitur ini akan menterjemahkan semua operasi _plugin_ dari _plugin_ yang sudah ada di kode inti Kubernetes ke bentuk Driver CSI `file.csi.azure.com`. Untuk menggunakan fitur ini, [Driver CSI Azure File](https://github.com/kubernetes-sigs/azuredisk-csi-driver) harus dinstal di klaster dan fitur Alpha `CSIMigration` serta `CSIMigrationAzureFile` harus diaktifkan.
|
||||
|
||||
### cephfs {#cephfs}
|
||||
|
||||
@@ -181,7 +181,7 @@ spec:
|
||||
|
||||
{{< feature-state for_k8s_version="v1.14" state="alpha" >}}
|
||||
|
||||
Pada saat fitur migrasi CSI untuk Cinder diaktifkan, fitur ini akan menterjemahkan semua operasi _plugin_ dari _plugin_ yang sudah ada di kode inti Kubernetes ke bentuk Driver CSI `cinder.csi.openstack.com`. Untuk menggunakan fitur ini, [Driver CSI Openstack Cinder](https://github.com/kubernetes/cloud-provider-openstack/blob/master/docs/using-cinder-csi-plugin.md) harus dinstal di kluster dan fitur Alpha `CSIMigration` serta `CSIMigrationOpenStack` harus diaktifkan.
|
||||
Pada saat fitur migrasi CSI untuk Cinder diaktifkan, fitur ini akan menterjemahkan semua operasi _plugin_ dari _plugin_ yang sudah ada di kode inti Kubernetes ke bentuk Driver CSI `cinder.csi.openstack.com`. Untuk menggunakan fitur ini, [Driver CSI Openstack Cinder](https://github.com/kubernetes/cloud-provider-openstack/blob/master/docs/using-cinder-csi-plugin.md) harus dinstal di klaster dan fitur Alpha `CSIMigration` serta `CSIMigrationOpenStack` harus diaktifkan.
|
||||
|
||||
### configMap {#configmap}
|
||||
|
||||
@@ -281,7 +281,7 @@ Lihat [Contoh FC](https://github.com/kubernetes/examples/tree/{{< param "githubb
|
||||
|
||||
### flocker {#flocker}
|
||||
|
||||
[Flocker](https://github.com/ClusterHQ/flocker) adalah sebuah proyek _open-source_ yg berfungsi sebagai pengatur _volume_ data Container yang diklusterkan. Flocker menyediakan pengelolaan dan orkestrasi _volume_ yang disokong oleh banyak jenis media penyimpanan.
|
||||
[Flocker](https://github.com/ClusterHQ/flocker) adalah sebuah proyek _open-source_ yg berfungsi sebagai pengatur _volume_ data Container yang diklasterkan. Flocker menyediakan pengelolaan dan orkestrasi _volume_ yang disokong oleh banyak jenis media penyimpanan.
|
||||
|
||||
Sebuah Volume `flockere` memungkinkan sebuah _dataset_ Flocker untuk ditambatkan ke dalam sebuah Pod. Jika _dataset_ tersebut belum ada di dalam Flocker, maka ia harus dibuat terlebih dahulu dengan menggunakan Flocker CLI atau menggunakan Flocker API. Jika _dataset_ tersebut sudah ada, ia akan ditambatkan kembali oleh Flocker ke Node di mana Pod tersebut dijadwalkan. Hal ini berarti data dapat dioper diantara Pod-pod sesuai dengan kebutuhan.
|
||||
|
||||
@@ -378,7 +378,7 @@ spec:
|
||||
|
||||
{{< feature-state for_k8s_version="v1.14" state="alpha" >}}
|
||||
|
||||
Pada saat fitur migrasi CSI untuk GCE PD diaktifkan, fitur ini akan menterjemahkan semua operasi _plugin_ dari _plugin_ yang sudah ada di kode inti Kubernetes ke bentuk Driver CSI `pd.csi.storage.gke.io`. Untuk menggunakan fitur ini, [Driver CSI GCE PD](https://github.com/kubernetes-sigs/gcp-compute-persistent-disk-csi-driver) harus dinstal di kluster dan fitur Alpha `CSIMigration` serta `CSIMigrationGCE` harus diaktifkan.
|
||||
Pada saat fitur migrasi CSI untuk GCE PD diaktifkan, fitur ini akan menterjemahkan semua operasi _plugin_ dari _plugin_ yang sudah ada di kode inti Kubernetes ke bentuk Driver CSI `pd.csi.storage.gke.io`. Untuk menggunakan fitur ini, [Driver CSI GCE PD](https://github.com/kubernetes-sigs/gcp-compute-persistent-disk-csi-driver) harus dinstal di klaster dan fitur Alpha `CSIMigration` serta `CSIMigrationGCE` harus diaktifkan.
|
||||
|
||||
### gitRepo (kedaluwarsa) {#gitrepo}
|
||||
|
||||
@@ -450,7 +450,7 @@ Nilai yang didukung untuk kolom `type` adalah:`
|
||||
Berhati-hatilah saat menggunakan tipe volume ini, karena:
|
||||
|
||||
* Pod-pod dengan konfigurasi identik (misalnya dibuat dari podTemplate) mungkin berperilaku berbeda pada Node-node yang berbeda oleh karena berkas-berkas yang berbeda pada Node-node tersebut.
|
||||
* Saat Kubernetes menambahkan penjadwalan yang sadar terhadap sumber-daya kluster, sesuai yang telah direncanakan, ia tidak dapat melakukan perhitungan terhadap sumber daya yang digunakan oleh sebuah `hostPath`
|
||||
* Saat Kubernetes menambahkan penjadwalan yang sadar terhadap sumber-daya klaster, sesuai yang telah direncanakan, ia tidak dapat melakukan perhitungan terhadap sumber daya yang digunakan oleh sebuah `hostPath`
|
||||
* Berkas-berkas atau direktori-direktori yang dibuat pada _host-host_ bersangkutan hanya dapat ditulis oleh `root`. Kamu butuh antara menjalankan proses aplikasi kamu sebagai `root` pada sebuah [privileged Container](/docs/user-guide/security-context) atau mengubah _permission_ berkas kamu pada _host_ tersebut agar dapat menulis pada Volume `hostPath`
|
||||
|
||||
#### Contoh Pod
|
||||
@@ -742,10 +742,10 @@ Lihat [contoh RBD](https://github.com/kubernetes/examples/tree/{{< param "github
|
||||
|
||||
### scaleIO {#scaleio}
|
||||
|
||||
ScaleIO adalah _platform_ penyimpanan berbasis perangkat lunak yang dapat menggunakan perangkat keras yang sudah tersedia untuk membuat kluster-kluster media penyimpanan terhubung jaringan yang _scalable_. _Plugin_ Volume `scaleIO` memungkinkan Pod-pod yang di-_deploy_ untuk mengakses Volume-volume ScaleIO yang telah tersedia (atau dapat menyediakan volume-volume untuk PersistentVolumeClaim secara dinamis, lihat [Persistent Volume ScaleIO](/docs/concepts/storage/persistent-volumes/#scaleio)).
|
||||
ScaleIO adalah _platform_ penyimpanan berbasis perangkat lunak yang dapat menggunakan perangkat keras yang sudah tersedia untuk membuat klaster-klaster media penyimpanan terhubung jaringan yang _scalable_. _Plugin_ Volume `scaleIO` memungkinkan Pod-pod yang di-_deploy_ untuk mengakses Volume-volume ScaleIO yang telah tersedia (atau dapat menyediakan volume-volume untuk PersistentVolumeClaim secara dinamis, lihat [Persistent Volume ScaleIO](/docs/concepts/storage/persistent-volumes/#scaleio)).
|
||||
|
||||
{{< caution >}}
|
||||
Kamu harus memiliki kluster ScaleIO yang berjalan dengan volume-volume yang sudah dibuat sebelum kamu dapat menggunakannya.
|
||||
Kamu harus memiliki klaster ScaleIO yang berjalan dengan volume-volume yang sudah dibuat sebelum kamu dapat menggunakannya.
|
||||
{{< /caution >}}
|
||||
|
||||
Berikut contoh konfigurasi sebuah Pod yang menggunakan ScaleIO:
|
||||
@@ -795,7 +795,7 @@ Secret dijelaskan lebih lanjut [di sini](/docs/user-guide/secrets).
|
||||
|
||||
Sebuah Volume `storageos` memungkinkan volume [StorageOS](https://www.storageos.com) yang sudah tersedia untuk ditambatkan ke dalam Pod kamu.
|
||||
|
||||
StorageOS berjalan sebagai sebuah COntainer di dalam lingkungan Kubernetes kamu, membuat penyimpanan yang lokal atau penyimpanan yang sedang dipasang untuk diakses dari Node manapun di dalam kluster Kubernetes.
|
||||
StorageOS berjalan sebagai sebuah COntainer di dalam lingkungan Kubernetes kamu, membuat penyimpanan yang lokal atau penyimpanan yang sedang dipasang untuk diakses dari Node manapun di dalam klaster Kubernetes.
|
||||
Data dapat direplikasikan untuk melindungi dari kegagalan Node. _Thin provisioning_ dan kompresi dapat meningkatkan utilisasi dan mengurangi biaya.
|
||||
|
||||
Di dalam intinya, StorageOS menyediakan penyimpanan blok kepada Container-container, yang dapat diakses melalui sebuah _filesystem_.
|
||||
@@ -804,7 +804,7 @@ Container StorageOS membutuhkan Linux 64-bit dan tidak memiliki ketergantungan t
|
||||
Tersedia pula sebuah lisensi gratis untuk _developer_.
|
||||
|
||||
{{< caution >}}
|
||||
Kamu harus menjalankan Container StorageOS pada setiap Node yang ingin mengakses volume-volume StorageOS atau yang akan berkontribusi pada kapasitas penyimpanan di kluster StorageOS. Untuk petunjuk instalasi, lihat [dokumentasi StorageOS](https://docs.storageos.com).
|
||||
Kamu harus menjalankan Container StorageOS pada setiap Node yang ingin mengakses volume-volume StorageOS atau yang akan berkontribusi pada kapasitas penyimpanan di klaster StorageOS. Untuk petunjuk instalasi, lihat [dokumentasi StorageOS](https://docs.storageos.com).
|
||||
{{< /caution >}}
|
||||
|
||||
```yaml
|
||||
@@ -972,7 +972,7 @@ spec:
|
||||
|
||||
Media penyimpanan (Disk, SSD, dll.) dari sebuah Volume `emptyDir` ditentukan oleh medium dari _filesystem_ yang menyimpan direktori _root_ dari Kubelet (biasanya `/var/lib/kubelet`). Tidak ada batasan berapa banyak ruang yang dapat digunakan oleh Volume `emptyDir` dan `hostPath`, dan tidak ada isolasi antara Container-container atau antara Pod-pod.
|
||||
|
||||
Ke depannya, kita mengharapkan Volume `emptyDir` dan `hostPath` akan dapat meminta jumlah ruangan penyimpanan tertentu dengan mengunakan spesifikasi [resource][resource](/docs/user-guide/compute-resources), dan memilih tipe media penyimpanan yang akan digunakan, untuk kluster yang memiliki beberapa jenis media penyimpanan.
|
||||
Ke depannya, kita mengharapkan Volume `emptyDir` dan `hostPath` akan dapat meminta jumlah ruangan penyimpanan tertentu dengan mengunakan spesifikasi [resource][resource](/docs/user-guide/compute-resources), dan memilih tipe media penyimpanan yang akan digunakan, untuk klaster yang memiliki beberapa jenis media penyimpanan.
|
||||
|
||||
## _Plugin_ Volume yang Out-of-Tree
|
||||
|
||||
@@ -980,7 +980,7 @@ _Plugin_ Volume yang Out-of-tree termasuk Container Storage Interface (CSI) dan
|
||||
|
||||
Sebelum dikenalkannya CSI dan Flexvolume, semua _plugin_ volume (seperti jenis-jenis volume yang terdaftar di atas) berada pada "in-tree", yang berarti bahwa mereka dibangun, di-_link_, di-_compile_, dan didistribusikan bersama-sama dengan kode inti Kubernetes dan mengekstensi inti dari Kubernetes API. Hal ini berarti menambah sistem penyimpanan baru ke dalam Kubernetes (sebuah _plugin_ volume) membutukan penambahan kode tersebut ke dalam _repository_ kode inti Kubernetes.
|
||||
|
||||
CSI dan Flexvolume memungkinkan _plugin_ volume untuk dikembangkan secara terpisah dari kode inti Kubernetes, dan diinstal pada kluster Kubernetes sebagai ekstensi.
|
||||
CSI dan Flexvolume memungkinkan _plugin_ volume untuk dikembangkan secara terpisah dari kode inti Kubernetes, dan diinstal pada klaster Kubernetes sebagai ekstensi.
|
||||
|
||||
Bagi _vendor-vendor_ penyimpanan yang ingin membuat sebuah _plugin_ volume yang out-of-tree, lihat [FAQ ini](https://github.com/kubernetes/community/blob/master/sig-storage/volume-plugin-faq.md).
|
||||
|
||||
@@ -1001,7 +1001,7 @@ _Driver-driver_ CSI mungkin tidak cocok pada semua rilis Kubernetes.
|
||||
Silahkan lihat dokumentasi _driver_ CSI yang bersangkutan untuk petunjuk penggunaan yang didukung untuk setiap rilis Kubernetes, dan untuk melihat matriks kompabilitasnya.
|
||||
{{< /note >}}
|
||||
|
||||
Saat sebuah _driver_ volume CSI dipasang pada kluster Kubernetes, pengguna dapat menggunakan tipe Volume `csi` untuk menambatkan volume-volume yang diekspos oleh _driver_ CSI tersebut.
|
||||
Saat sebuah _driver_ volume CSI dipasang pada klaster Kubernetes, pengguna dapat menggunakan tipe Volume `csi` untuk menambatkan volume-volume yang diekspos oleh _driver_ CSI tersebut.
|
||||
|
||||
Tipe Volume `csi` tidak mendukung referensi secara langsung dari Pod dan hanya dapat dirujuk di dalam sebuah Pod melalui sebuah objek `PersistentVolumeClaim`.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user