fix: Address feedback from reviewers on styling and choice of words
Signed-off-by: Giri Kuncoro <giri.kuncoro@bytedance.com>pull/50760/head
Giri Kuncoro
parent
6e8001854a
commit
c75fdea641
|
|
@ -31,7 +31,7 @@ Alokasi sumber daya dinamis (_dynamic resource allocation_) adalah API untuk mem
|
|||
|
||||
_Driver_ sumber daya pihak ketiga bertanggung jawab untuk melacak dan mempersiapkan sumber daya, dengan alokasi sumber daya yang ditangani oleh Kubernetes melalui parameter terstruktur (diperkenalkan pada Kubernetes 1.30). Berbagai jenis sumber daya mendukung parameter sembarang untuk mendefinisikan kebutuhan dan inisialisasi.
|
||||
|
||||
Kubernetes versi 1.26 hingga 1.31 menyertakan implementasi (alpha) dari DRA klasik, yang sekarang sudah tidak didukung lagi. Dokumentasi ini, yang ditujukan untuk Kubernetes versi {{< skew currentVersion >}}, menjelaskan pendekatan terkini untuk alokasi sumber daya dinamis dalam Kubernetes.
|
||||
Kubernetes versi 1.26 hingga 1.31 menyertakan implementasi (alpha) dari DRA (_Dynamic Resource Allocation_) klasik, yang sekarang sudah tidak didukung lagi. Dokumentasi ini yang ditujukan untuk Kubernetes versi {{< skew currentVersion >}}, menjelaskan pendekatan terkini untuk alokasi sumber daya dinamis dalam Kubernetes.
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
|
|
@ -47,7 +47,7 @@ ResourceClaim
|
|||
: Menggambarkan permintaan akses ke sumber daya di dalam klaster untuk digunakan oleh beban kerja (_workload_). Misalnya, jika sebuah beban kerja membutuhkan perangkat akselerator dengan properti tertentu, permintaan tersebut diekspresikan melalui tipe ini. Bagian status melacak apakah klaim ini telah terpenuhi dan sumber daya spesifik apa yang telah dialokasikan.
|
||||
|
||||
ResourceClaimTemplate
|
||||
: Mendefinisikan spesifikasi dan beberapa metadata untuk membuat ResourceClaim. Dibuat oleh pengguna saat menerapkan beban kerja. ResourceClaim per-Pod kemudian dibuat dan dihapus secara otomatis oleh Kubernetes.
|
||||
: Mendefinisikan spesifikasi dan beberapa metadata untuk membuat ResourceClaim. Dibuat oleh pengguna saat menerapkan beban kerja. ResourceClaim untuk setiap Pod kemudian dibuat dan dihapus secara otomatis oleh Kubernetes.
|
||||
|
||||
DeviceClass
|
||||
: Berisi kriteria seleksi yang telah ditentukan untuk perangkat tertentu serta konfigurasi untuk perangkat tersebut. DeviceClass dibuat oleh administrator klaster saat menginstal _driver_ sumber daya. Setiap permintaan untuk mengalokasikan perangkat dalam ResourceClaim harus merujuk tepat satu DeviceClass.
|
||||
|
|
@ -56,15 +56,15 @@ ResourceSlice
|
|||
: Digunakan oleh _driver_ DRA untuk mempublikasikan informasi tentang sumber daya (biasanya perangkat) yang tersedia di klaster.
|
||||
|
||||
DeviceTaintRule
|
||||
: Digunakan oleh administrator atau komponen control plane untuk menambahkan _taint_ perangkat pada perangkat yang dijelaskan dalam ResourceSlice.
|
||||
: Digunakan oleh administrator atau komponen _control plane_ untuk menambahkan _taint_ perangkat pada perangkat yang dijelaskan dalam ResourceSlice.
|
||||
|
||||
Semua parameter yang memilih perangkat didefinisikan dalam ResourceClaim dan DeviceClass menggunakan tipe _in-tree_. Parameter konfigurasi dapat disematkan di sana. Parameter konfigurasi yang valid bergantung pada _driver_ DRA -- Kubernetes hanya meneruskannya tanpa memprosesnya.
|
||||
|
||||
`PodSpec` dari `core/v1` mendefinisikan ResourceClaim yang diperlukan untuk sebuah Pod dalam field `resourceClaims`. Entri dalam daftar tersebut merujuk pada ResourceClaim atau ResourceClaimTemplate. Ketika merujuk pada ResourceClaim, semua Pod yang menggunakan PodSpec ini (misalnya, di dalam Deployment atau StatefulSet) berbagi instans ResourceClaim yang sama. Ketika merujuk pada ResourceClaimTemplate, setiap Pod mendapatkan instans tersendiri.
|
||||
`PodSpec` dari `core/v1` mendefinisikan ResourceClaim yang diperlukan untuk sebuah Pod dalam _field_ `resourceClaims`. Entri dalam daftar tersebut merujuk pada ResourceClaim atau ResourceClaimTemplate. Ketika merujuk pada ResourceClaim, semua Pod yang menggunakan PodSpec ini (misalnya, di dalam Deployment atau StatefulSet) berbagi _instance_ ResourceClaim yang sama. Ketika merujuk pada ResourceClaimTemplate, setiap Pod mendapatkan _instance_ tersendiri.
|
||||
|
||||
Daftar `resources.claims` untuk sumber daya kontainer mendefinisikan apakah sebuah kontainer mendapatkan akses ke instans sumber daya tersebut, yang memungkinkan berbagi sumber daya antara satu atau lebih kontainer.
|
||||
Daftar `resources.claims` untuk sumber daya kontainer mendefinisikan apakah sebuah kontainer mendapatkan akses ke _instance_ sumber daya tersebut, yang memungkinkan berbagi sumber daya antara satu atau lebih kontainer.
|
||||
|
||||
Berikut adalah contoh untuk driver sumber daya fiksi. Dua objek ResourceClaim akan dibuat untuk Pod ini, dan setiap kontainer mendapatkan akses ke salah satu dari mereka.
|
||||
Berikut adalah contoh untuk _driver_ sumber daya fiksi. Dua objek ResourceClaim akan dibuat untuk Pod ini, dan setiap kontainer mendapatkan akses ke salah satu dari mereka.
|
||||
|
||||
```yaml
|
||||
apiVersion: resource.k8s.io/v1beta2
|
||||
|
|
@ -122,8 +122,8 @@ spec:
|
|||
|
||||
_Scheduler_ bertanggung jawab untuk mengalokasikan sumber daya ke ResourceClaim setiap kali sebuah Pod membutuhkannya. _Scheduler_ melakukan ini dengan mengambil daftar lengkap sumber daya yang tersedia dari objek ResourceSlice, melacak sumber daya mana yang sudah dialokasikan ke ResourceClaim yang ada, dan kemudian memilih dari sumber daya yang masih tersisa.
|
||||
|
||||
Saat ini, satu-satunya jenis sumber daya yang didukung adalah perangkat. Sebuah instans perangkat memiliki nama, beberapa atribut, dan kapasitas. Perangkat dipilih melalui ekspresi CEL yang memeriksa atribut dan kapasitas tersebut. Selain itu, perangkat yang dipilih juga dapat dibatasi pada kumpulan perangkat yang memenuhi batasan tertentu.
|
||||
Sumber daya yang dipilih dicatat dalam status ResourceClaim bersama dengan konfigurasi spesifik vendor, sehingga ketika sebuah pod akan dijalankan pada sebuah node, _driver_ sumber daya di node tersebut memiliki semua informasi yang diperlukan untuk mempersiapkan sumber daya tersebut.
|
||||
Saat ini, satu-satunya jenis sumber daya yang didukung adalah perangkat. Sebuah _instance_ perangkat memiliki nama, beberapa atribut, dan kapasitas. Perangkat dipilih melalui [ekspresi CEL (_Common Expression Language_)](/docs/reference/using-api/cel) yang memeriksa atribut dan kapasitas tersebut. Selain itu, perangkat yang dipilih juga dapat dibatasi pada kumpulan perangkat yang memenuhi batasan tertentu.
|
||||
Sumber daya yang dipilih dicatat dalam status ResourceClaim bersama dengan konfigurasi spesifik vendor, sehingga ketika sebuah pod akan dijalankan pada sebuah Node, _driver_ sumber daya di Node tersebut memiliki semua informasi yang diperlukan untuk mempersiapkan sumber daya tersebut.
|
||||
|
||||
Dengan menggunakan parameter terstruktur, _scheduler_ dapat mengambil keputusan tanpa berkomunikasi dengan _driver_ sumber daya DRA. _Scheduler_ juga dapat menjadwalkan beberapa Pod dengan cepat dengan menyimpan informasi tentang alokasi ResourceClaim di memori dan menuliskan informasi ini ke objek ResourceClaim di latar belakang sambil secara bersamaan mengikat pod ke sebuah Node.
|
||||
|
||||
|
|
@ -135,7 +135,7 @@ Kubelet menyediakan layanan gRPC untuk memungkinkan penemuan sumber daya dinamis
|
|||
|
||||
Ketika kamu - atau klien API lainnya - membuat sebuah Pod dengan `spec.nodeName` yang sudah diatur, _scheduler_ akan dilewati. Jika ada ResourceClaim yang dibutuhkan oleh Pod tersebut tetapi belum ada, belum dialokasikan, atau belum dipesan untuk Pod tersebut, maka kubelet akan gagal menjalankan Pod dan akan memeriksa ulang secara berkala karena persyaratan tersebut mungkin masih dapat dipenuhi di kemudian waktu.
|
||||
|
||||
Situasi semacam ini juga dapat terjadi ketika dukungan untuk alokasi sumber daya dinamis tidak diaktifkan di _scheduler_ pada saat Pod dijadwalkan (karena perbedaan versi, konfigurasi, fitur gate, dll.). kube-controller-manager mendeteksi hal ini dan mencoba membuat Pod dapat dijalankan dengan memesan ResourceClaim yang diperlukan. Namun, ini hanya berhasil jika ResourceClaim tersebut telah dialokasikan oleh _scheduler_ untuk Pod lain.
|
||||
Situasi semacam ini juga dapat terjadi ketika dukungan untuk alokasi sumber daya dinamis tidak diaktifkan di _scheduler_ pada saat Pod dijadwalkan (karena perbedaan versi, konfigurasi, _feature gate_, dll.). kube-controller-manager mendeteksi hal ini dan mencoba membuat Pod dapat dijalankan dengan memesan ResourceClaim yang diperlukan. Namun, ini hanya berhasil jika ResourceClaim tersebut telah dialokasikan oleh _scheduler_ untuk Pod lain.
|
||||
|
||||
Lebih baik untuk menghindari melewati _scheduler_ karena Pod yang ditugaskan ke sebuah Node akan memblokir sumber daya normal (RAM, CPU) yang tidak dapat digunakan untuk Pod lain sementara Pod tersebut terhenti. Untuk membuat sebuah Pod berjalan di Node tertentu sambil tetap melalui alur penjadwalan normal, buatlah Pod dengan `nodeSelector` yang secara tepat cocok dengan Node yang diinginkan:
|
||||
|
||||
|
|
@ -176,25 +176,25 @@ spec:
|
|||
|
||||
Jika fitur ini dinonaktifkan, _field_ `adminAccess` akan secara otomatis dihapus saat membuat ResourceClaim semacam itu.
|
||||
|
||||
Akses admin adalah mode istimewa dan tidak boleh diberikan kepada pengguna biasa dalam klaster _multi-tenant_. Mulai dari Kubernetes v1.33, hanya pengguna yang memiliki otorisasi untuk membuat objek ResourceClaim atau ResourceClaimTemplate di namespace yang diberi label `resource.k8s.io/admin-access: "true"` (_case-sensitive_) yang dapat menggunakan field `adminAccess`. Hal ini memastikan bahwa pengguna non-admin tidak dapat menyalahgunakan fitur tersebut.
|
||||
Akses admin adalah mode istimewa dan tidak boleh diberikan kepada pengguna biasa dalam klaster _multi-tenant_. Mulai dari Kubernetes v1.33, hanya pengguna yang memiliki otorisasi untuk membuat objek ResourceClaim atau ResourceClaimTemplate di namespace yang diberi label `resource.k8s.io/admin-access: "true"` (_case-sensitive_) yang dapat menggunakan _field_ `adminAccess`. Hal ini memastikan bahwa pengguna non-admin tidak dapat menyalahgunakan fitur tersebut.
|
||||
|
||||
## Status Perangkat ResourceClaim
|
||||
|
||||
{{< feature-state feature_gate_name="DRAResourceClaimDeviceStatus" >}}
|
||||
|
||||
_Driver_ dapat melaporkan data status perangkat spesifik driver untuk setiap perangkat yang dialokasikan dalam sebuah ResourceClaim. Misalnya, IP yang diberikan ke perangkat antarmuka jaringan dapat dilaporkan dalam status ResourceClaim.
|
||||
_Driver_ dapat melaporkan data status perangkat spesifik _driver_ untuk setiap perangkat yang dialokasikan dalam sebuah ResourceClaim. Misalnya, IP yang diberikan ke perangkat antarmuka jaringan dapat dilaporkan dalam status ResourceClaim.
|
||||
|
||||
_Driver_ yang menetapkan status, keakuratan informasi bergantung pada implementasi driver DRA tersebut. Oleh karena itu, status perangkat yang dilaporkan mungkin tidak selalu mencerminkan perubahan waktu nyata dari keadaan perangkat.
|
||||
_Driver_ yang menetapkan status, keakuratan informasi bergantung pada implementasi _driver_ DRA tersebut. Oleh karena itu, status perangkat yang dilaporkan mungkin tidak selalu mencerminkan perubahan waktu nyata dari keadaan perangkat.
|
||||
|
||||
Ketika fitur ini dinonaktifkan, field tersebut secara otomatis akan dihapus saat menyimpan ResourceClaim.
|
||||
Ketika fitur ini dinonaktifkan, _field_ tersebut secara otomatis akan dihapus saat menyimpan ResourceClaim.
|
||||
|
||||
Status perangkat ResourceClaim didukung ketika memungkinkan, dari _driver_ DRA, untuk memperbarui ResourceClaim yang ada di mana field `status.devices` diatur.
|
||||
Status perangkat ResourceClaim didukung ketika memungkinkan, dari _driver_ DRA, untuk memperbarui ResourceClaim yang ada di mana _field_ `status.devices` diatur.
|
||||
|
||||
### Daftar Prioritas
|
||||
|
||||
{{< feature-state feature_gate_name="DRAPrioritizedList" >}}
|
||||
|
||||
Kamu dapat menyediakan daftar prioritas sub-permintaan untuk permintaan dalam sebuah ResourceClaim. _Scheduler_ kemudian akan memilih sub-permintaan pertama yang dapat dialokasikan. Ini memungkinkan pengguna untuk menentukan perangkat alternatif yang dapat digunakan oleh workload jika pilihan utama tidak tersedia.
|
||||
Kamu dapat menyediakan daftar prioritas sub-permintaan untuk permintaan dalam sebuah ResourceClaim. _Scheduler_ kemudian akan memilih sub-permintaan pertama yang dapat dialokasikan. Ini memungkinkan pengguna untuk menentukan perangkat alternatif yang dapat digunakan oleh beban kerja jika pilihan utama tidak tersedia.
|
||||
|
||||
Dalam contoh di bawah ini, ResourceClaimTemplate meminta perangkat dengan warna hitam dan ukuran besar. Jika perangkat dengan atribut tersebut tidak tersedia, Pod tidak dapat dijadwalkan. Dengan fitur daftar prioritas, alternatif kedua dapat ditentukan, yang meminta dua perangkat dengan warna putih dan ukuran kecil. Perangkat hitam besar akan dialokasikan jika tersedia. Namun, jika tidak tersedia dan dua perangkat putih kecil tersedia, Pod masih dapat berjalan.
|
||||
|
||||
|
|
@ -270,37 +270,37 @@ spec:
|
|||
value: 6Gi
|
||||
```
|
||||
|
||||
## Taint dan Toleransi Perangkat
|
||||
## _Taint_ dan Toleransi Perangkat
|
||||
|
||||
{{< feature-state feature_gate_name="DRADeviceTaints" >}}
|
||||
{{< feature-state feature_gate_name="DynamicResourceAllocation" >}}
|
||||
|
||||
Taint perangkat mirip dengan taint pada Node: sebuah taint memiliki kunci string, nilai string, dan efek. Efek ini diterapkan pada ResourceClaim yang menggunakan perangkat yang telah ditaint dan pada semua Pod yang merujuk ke ResourceClaim tersebut. Efek "NoSchedule" mencegah penjadwalan Pod-Pod tersebut. Perangkat yang ditaint akan diabaikan saat mencoba mengalokasikan ResourceClaim karena penggunaannya akan mencegah penjadwalan Pod.
|
||||
__Taint__ perangkat mirip dengan _taint_ pada Node: sebuah _taint_ memiliki kunci _string_, nilai _string_, dan efek. Efek ini diterapkan pada ResourceClaim yang menggunakan perangkat yang telah ditaint dan pada semua Pod yang merujuk ke ResourceClaim tersebut. Efek "NoSchedule" mencegah penjadwalan Pod-Pod tersebut. Perangkat yang ditaint akan diabaikan saat mencoba mengalokasikan ResourceClaim karena penggunaannya akan mencegah penjadwalan Pod.
|
||||
|
||||
Efek "NoExecute" menyiratkan "NoSchedule" dan, selain itu, menyebabkan pengusiran semua Pod yang telah dijadwalkan sebelumnya. Pengusiran ini diimplementasikan dalam pengontrol pengusiran taint perangkat di kube-controller-manager dengan cara menghapus Pod yang terpengaruh.
|
||||
Efek "NoExecute" menyiratkan "NoSchedule" dan, selain itu, menyebabkan pengusiran semua Pod yang telah dijadwalkan sebelumnya. Pengusiran ini diimplementasikan dalam pengontrol pengusiran _taint_ perangkat di kube-controller-manager dengan cara menghapus Pod yang terpengaruh.
|
||||
|
||||
ResourceClaim dapat mentoleransi taint. Jika sebuah taint ditoleransi, efeknya tidak berlaku. Toleransi kosong cocok dengan semua taint. Toleransi dapat dibatasi pada efek tertentu dan/atau cocok dengan pasangan kunci/nilai tertentu. Toleransi dapat memeriksa keberadaan kunci tertentu, terlepas dari nilai apa yang dimilikinya, atau dapat memeriksa nilai spesifik dari sebuah kunci. Untuk informasi lebih lanjut tentang pencocokan ini, lihat konsep taint pada Node.
|
||||
ResourceClaim dapat mentoleransi _taint_. Jika sebuah _taint_ ditoleransi, efeknya tidak berlaku. Toleransi kosong cocok dengan semua _taint_. Toleransi dapat dibatasi pada efek tertentu dan/atau cocok dengan pasangan kunci/nilai tertentu. Toleransi dapat memeriksa keberadaan kunci tertentu, terlepas dari nilai apa yang dimilikinya, atau dapat memeriksa nilai spesifik dari sebuah kunci. Untuk informasi lebih lanjut tentang pencocokan ini, lihat konsep _taint_ pada Node.
|
||||
|
||||
Pengusiran dapat ditunda dengan mentoleransi taint untuk durasi tertentu. Penundaan tersebut dimulai saat taint ditambahkan ke perangkat, yang dicatat dalam sebuah field pada taint.
|
||||
Pengusiran dapat ditunda dengan mentoleransi _taint_ untuk durasi tertentu. Penundaan tersebut dimulai saat _taint_ ditambahkan ke perangkat, yang dicatat dalam sebuah _field_ pada _taint_.
|
||||
|
||||
Taint berlaku seperti yang dijelaskan di atas juga untuk ResourceClaim yang mengalokasikan "semua" perangkat pada sebuah node. Semua perangkat harus tidak ditaint atau semua taint mereka harus ditoleransi. Mengalokasikan perangkat dengan akses admin (dijelaskan di atas) juga tidak dikecualikan. Seorang admin yang menggunakan mode tersebut harus secara eksplisit mentoleransi semua taint untuk mengakses perangkat yang ditaint.
|
||||
_Taint_ berlaku seperti yang dijelaskan di atas juga untuk ResourceClaim yang mengalokasikan "semua" perangkat pada sebuah Node. Semua perangkat harus tidak ditaint atau semua _taint_ mereka harus ditoleransi. Mengalokasikan perangkat dengan akses admin (dijelaskan di atas) juga tidak dikecualikan. Seorang admin yang menggunakan mode tersebut harus secara eksplisit mentoleransi semua _taint_ untuk mengakses perangkat yang ditaint.
|
||||
|
||||
Taint dapat ditambahkan ke perangkat dengan dua cara berbeda:
|
||||
_Taint_ dapat ditambahkan ke perangkat dengan dua cara berbeda:
|
||||
|
||||
### Taint yang Ditetapkan oleh Driver
|
||||
### _Taint_ yang Ditetapkan oleh Driver
|
||||
|
||||
_Driver_ DRA dapat menambahkan taint ke informasi perangkat yang dipublikasikan dalam ResourceSlice. Konsultasikan dokumentasi driver DRA untuk mengetahui apakah _driver_ menggunakan taint dan apa kunci serta nilainya.
|
||||
_Driver_ DRA dapat menambahkan _taint_ ke informasi perangkat yang dipublikasikan dalam ResourceSlice. Konsultasikan dokumentasi _driver_ DRA untuk mengetahui apakah _driver_ menggunakan _taint_ dan apa kunci serta nilainya.
|
||||
|
||||
### Taint yang Ditetapkan oleh Admin
|
||||
### _Taint_ yang Ditetapkan oleh Admin
|
||||
|
||||
Seorang admin atau komponen control plane dapat menaint perangkat tanpa harus meminta driver DRA untuk menyertakan taint dalam informasi perangkatnya di ResourceSlice. Mereka melakukannya dengan membuat DeviceTaintRules. Setiap DeviceTaintRule menambahkan satu taint ke perangkat yang cocok dengan _selector_ perangkat. Tanpa _selector_ semacam itu, tidak ada perangkat yang ditaint. Hal ini membuat lebih sulit untuk secara tidak sengaja mengusir semua Pod yang menggunakan ResourceClaim karena kesalahan dalam menentukan _selector_.
|
||||
Seorang admin atau komponen _control plane_ dapat menaint perangkat tanpa harus meminta _driver_ DRA untuk menyertakan _taint_ dalam informasi perangkatnya di ResourceSlice. Mereka melakukannya dengan membuat DeviceTaintRules. Setiap DeviceTaintRule menambahkan satu _taint_ ke perangkat yang cocok dengan _selector_ perangkat. Tanpa _selector_ semacam itu, tidak ada perangkat yang ditaint. Hal ini membuat lebih sulit untuk secara tidak sengaja mengusir semua Pod yang menggunakan ResourceClaim karena kesalahan dalam menentukan _selector_.
|
||||
|
||||
Perangkat dapat dipilih dengan memberikan nama DeviceClass, driver, pool, dan/atau perangkat. DeviceClass memilih semua perangkat yang dipilih oleh _selector_ dalam DeviceClass tersebut. Dengan hanya nama _driver_, seorang admin dapat melakukan taint semua perangkat yang dikelola oleh _driver_ tersebut, misalnya saat melakukan pemeliharaan _driver_ di seluruh klaster. Menambahkan nama _pool_ dapat membatasi taint ke satu Node, jika _driver_ mengelola perangkat lokal Node.
|
||||
Perangkat dapat dipilih dengan memberikan nama DeviceClass, _driver_, pool, dan/atau perangkat. DeviceClass memilih semua perangkat yang dipilih oleh _selector_ dalam DeviceClass tersebut. Dengan hanya nama _driver_, seorang admin dapat melakukan _taint_ semua perangkat yang dikelola oleh _driver_ tersebut, misalnya saat melakukan pemeliharaan _driver_ di seluruh klaster. Menambahkan nama _pool_ dapat membatasi _taint_ ke satu Node, jika _driver_ mengelola perangkat lokal Node.
|
||||
|
||||
Terakhir, menambahkan nama perangkat dapat memilih satu perangkat spesifik. Nama perangkat dan nama _pool_ juga dapat digunakan sendiri, jika diinginkan. Misalnya, _driver_ untuk perangkat lokal Node didorong untuk menggunakan nama Node sebagai nama _pool_ mereka. Maka, melakukan taint dengan nama _pool_ tersebut secara otomatis melakukan taint semua perangkat pada sebuah node.
|
||||
Terakhir, menambahkan nama perangkat dapat memilih satu perangkat spesifik. Nama perangkat dan nama _pool_ juga dapat digunakan sendiri, jika diinginkan. Misalnya, _driver_ untuk perangkat lokal Node didorong untuk menggunakan nama Node sebagai nama _pool_ mereka. Maka, melakukan _taint_ dengan nama _pool_ tersebut secara otomatis melakukan _taint_ semua perangkat pada sebuah Node.
|
||||
|
||||
_Driver_ mungkin menggunakan nama stabil seperti "gpu-0" yang menyembunyikan perangkat spesifik mana yang saat ini ditugaskan ke nama tersebut. Untuk mendukung perlakuan taint ubstabs perangkat keras tertentu, _selector_ CEL dapat digunakan dalam DeviceTaintRule untuk mencocokkan atribut ID unik spesifik vendor, jika _driver_ mendukungnya untuk perangkat kerasnya.
|
||||
_Driver_ mungkin menggunakan nama stabil seperti "gpu-0" yang menyembunyikan perangkat spesifik mana yang saat ini ditugaskan ke nama tersebut. Untuk mendukung perlakuan _taint_ ubstabs perangkat keras tertentu, _selector_ CEL dapat digunakan dalam DeviceTaintRule untuk mencocokkan atribut ID unik spesifik vendor, jika _driver_ mendukungnya untuk perangkat kerasnya.
|
||||
|
||||
Taint berlaku selama DeviceTaintRule ada. Taint dapat dimodifikasi dan dihapus kapan saja. Berikut adalah contoh DeviceTaintRule untuk driver DRA fiksi:
|
||||
_Taint_ berlaku selama DeviceTaintRule ada. _taint_ dapat dimodifikasi dan dihapus kapan saja. Berikut adalah contoh DeviceTaintRule untuk _driver_ DRA fiksi:
|
||||
|
||||
```yaml
|
||||
apiVersion: resource.k8s.io/v1alpha3
|
||||
|
|
@ -313,7 +313,7 @@ spec:
|
|||
# Evict all pods and don't schedule new ones.
|
||||
deviceSelector:
|
||||
driver: dra.example.com
|
||||
taint:
|
||||
_taint_:
|
||||
key: dra.example.com/unhealthy
|
||||
value: Broken
|
||||
effect: NoExecute
|
||||
|
|
@ -344,7 +344,7 @@ error: the server doesn't have a resource type "deviceclasses"
|
|||
|
||||
Konfigurasi _default_ kube-scheduler mengaktifkan plugin "DynamicResources" hanya jika feature gate diaktifkan dan menggunakan API konfigurasi v1. Konfigurasi kustom mungkin perlu dimodifikasi untuk menyertakannya.
|
||||
|
||||
Selain mengaktifkan fitur di klaster, driver sumber daya juga harus diinstal. Silakan merujuk ke dokumentasi driver untuk detail lebih lanjut.
|
||||
Selain mengaktifkan fitur di klaster, _driver_ sumber daya juga harus diinstal. Silakan merujuk ke dokumentasi _driver_ untuk detail lebih lanjut.
|
||||
|
||||
### Mengaktifkan Akses Admin
|
||||
|
||||
|
|
@ -362,9 +362,9 @@ Selain mengaktifkan fitur di klaster, driver sumber daya juga harus diinstal. Si
|
|||
|
||||
[Perangkat yang dapat dipartisi](#perangkat-yang-dapat-dipartisi) adalah fitur _alpha_ dan hanya dapat diaktifkan jika [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) `DRAPartitionableDevices` diaktifkan di kube-apiserver dan kube-scheduler.
|
||||
|
||||
#### Mengaktifkan Taint dan Toleransi Perangkat
|
||||
#### Mengaktifkan _Taint_ dan Toleransi Perangkat
|
||||
|
||||
[Taint dan toleransi perangkat](#taint-dan-toleransi-perangkat) adalah fitur _alpha_ dan hanya dapat diaktifkan jika [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) `DRADeviceTaints` diaktifkan di kube-apiserver, kube-controller-manager, dan kube-scheduler. Untuk menggunakan DeviceTaintRules, versi API `resource.k8s.io/v1alpha3` harus diaktifkan.
|
||||
[_Taint_ dan toleransi perangkat](#taint-dan-toleransi-perangkat) adalah fitur _alpha_ dan hanya dapat diaktifkan jika [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) `DRADevice_Taint_s` diaktifkan di kube-apiserver, kube-controller-manager, dan kube-scheduler. Untuk menggunakan DeviceTaintRules, versi API `resource.k8s.io/v1alpha3` harus diaktifkan.
|
||||
|
||||
### {{% heading "whatsnext" %}}
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue