Rename ID Docs "Scheduling: concept as "Scheduling and Eviction"

* Rename `docs/concepts/scheduling` to `docs/concepts/scheduling-eviction` * Retitle concept header to "Penjadwalan dan Pengusiran" * Update redirects * Update internal links (id only) Part of proposal #19081
2021-04-13 17:55:48 +07:00
parent 1eddc8bfed
commit af5a179182
7 changed files with 14 additions and 9 deletions
@@ -0,0 +1,5 @@
+---
+title: "Penjadwalan dan Pengusiran"
+weight: 90
+---
+
@@ -94,7 +94,7 @@ penilaian oleh penjadwal:

 ## {{% heading "whatsnext" %}}

-* Baca tentang [penyetelan performa penjadwal](/id/docs/concepts/scheduling/scheduler-perf-tuning/)
+* Baca tentang [penyetelan performa penjadwal](/id/docs/concepts/scheduling-eviction/scheduler-perf-tuning/)
 * Baca tentang [pertimbangan penyebarang topologi pod](/id/docs/concepts/workloads/pods/pod-topology-spread-constraints/)
 * Baca [referensi dokumentasi](/docs/reference/command-line-tools-reference/kube-scheduler/) untuk _kube-scheduler_
 * Pelajari tentang [mengkonfigurasi beberapa penjadwal](/docs/tasks/administer-cluster/configure-multiple-schedulers/)
@@ -0,0 +1,160 @@
+---
+title: Penyetelan Kinerja Penjadwal
+content_type: concept
+weight: 70
+---
+
+<!-- overview -->
+
+{{< feature-state for_k8s_version="v1.14" state="beta" >}}
+
+[kube-scheduler](/id/docs/concepts/scheduling-eviction/kube-scheduler/#kube-scheduler)
+merupakan penjadwal (_scheduler_) Kubernetes bawaan yang bertanggung jawab
+terhadap penempatan Pod-Pod pada seluruh Node di dalam sebuah klaster.
+
+Node-Node di dalam klaster yang sesuai dengan syarat-syarat penjadwalan dari
+sebuah Pod disebut sebagai Node-Node layak (_feasible_). Penjadwal mencari Node-Node
+layak untuk sebuah Pod dan kemudian menjalankan fungsi-fungsi untuk menskor Node-Node tersebut, memilih sebuah Node dengan skor tertinggi di antara
+Node-Node layak lainnya, di mana Pod akan dijalankan. Penjadwal kemudian memberitahu
+API server soal keputusan ini melalui sebuah proses yang disebut _Binding_.
+
+Laman ini menjelaskan optimasi penyetelan (_tuning_) kinerja yang relevan
+untuk klaster Kubernetes berskala besar.
+
+
+
+<!-- body -->
+
+Pada klaster berskala besar, kamu bisa menyetel perilaku penjadwal
+untuk menyeimbangkan hasil akhir penjadwalan antara latensi (seberapa cepat Pod-Pod baru ditempatkan)
+dan akurasi (seberapa akurat penjadwal membuat keputusan penjadwalan yang tepat).
+
+Kamu bisa mengonfigurasi setelan ini melalui pengaturan `percentageOfNodesToScore` pada kube-scheduler.
+Pengaturan KubeSchedulerConfiguration ini menentukan sebuah ambang batas untuk
+penjadwalan Node-Node di dalam klaster kamu.
+
+### Pengaturan Ambang Batas
+
+Opsi `percentageOfNodesToScore` menerima semua angka numerik antara 0 dan 100.
+Angka 0 adalah angka khusus yang menandakan bahwa kube-scheduler harus menggunakan
+nilai bawaan.
+Jika kamu mengatur `percentageOfNodesToScore` dengan angka di atas 100, kube-scheduler
+akan membulatkan ke bawah menjadi 100.
+
+Untuk mengubah angkanya, sunting berkas konfigurasi kube-scheduler (biasanya `/etc/kubernetes/config/kube-scheduler.yaml`),
+lalu _ulang kembali_ kube-scheduler.
+
+Setelah kamu selesai menyunting, jalankan perintah
+```bash
+kubectl get componentstatuses
+```
+untuk memverifikasi komponen kube-scheduler berjalan dengan baik (_healthy_). Keluarannya kira-kira seperti ini:
+```
+NAME                 STATUS    MESSAGE             ERROR
+controller-manager   Healthy   ok
+scheduler            Healthy   ok
+...
+```
+
+## Ambang Batas Penskoran Node {#persentase-penskoran-node}
+
+Untuk meningkatan kinerja penjadwalan, kube-scheduler dapat berhenti mencari
+Node-Node yang layak saat sudah berhasil menemukannya. Pada klaster berskala besar,
+hal ini menghemat waktu dibandingkan dengan pendekatan awam yang mengecek setiap Node.
+
+Kamu bisa mengatur ambang batas untuk menentukan berapa banyak jumlah Node minimal yang dibutuhkan, sebagai
+persentase bagian dari seluruh Node di dalam klaster kamu. kube-scheduler akan mengubahnya menjadi
+bilangan bulat berisi jumlah Node. Saat penjadwalan, jika kube-scheduler mengidentifikasi
+cukup banyak Node-Node layak untuk melewati jumlah persentase yang diatur, maka kube-scheduler
+akan berhenti mencari Node-Node layak dan lanjut ke [fase penskoran] (/id/docs/concepts/scheduling-eviction/kube-scheduler/#kube-scheduler-implementation).
+
+[Bagaimana penjadwal mengecek Node](#bagaimana-penjadwal-mengecek-node) menjelaskan proses ini secara detail.
+
+### Ambang Batas Bawaan
+
+Jika kamu tidak mengatur sebuah ambang batas, maka Kubernetes akan
+menghitung sebuah nilai menggunakan pendekatan linier, yaitu 50% untuk klaster dengan 100 Node,
+serta 10% untuk klaster dengan 5000 Node.
+
+Artinya, kube-scheduler selalu menskor paling tidak 5% dari klaster kamu, terlepas dari
+seberapa besar klasternya, kecuali kamu secara eksplisit mengatur `percentageOfNodesToScore`
+menjadi lebih kecil dari 5.
+
+Jika kamu ingin penjadwal untuk memasukkan seluruh Node di dalam klaster ke dalam penskoran,
+maka aturlah `percentageOfNodesToScore` menjadi 100.
+
+## Contoh
+
+Contoh konfigurasi di bawah ini mengatur `percentageOfNodesToScore` menjadi 50%.
+
+```yaml
+apiVersion: kubescheduler.config.k8s.io/v1alpha1
+kind: KubeSchedulerConfiguration
+algorithmSource:
+  provider: DefaultProvider
+
+...
+
+percentageOfNodesToScore: 50
+```
+
+
+##  Menyetel percentageOfNodesToScore
+
+`percentageOfNodesToScore` merupakan angka 1 sampai 100 dengan
+nilai bawaan yang dihitung berdasarkan ukuran klaster. Di sini juga terdapat
+batas bawah yang telah ditetapkan, yaitu 50 Node.
+
+{{< note >}}Pada klaster dengan kurang dari 50 Node layak, penjadwal masih
+terus memeriksa seluruh Node karena Node-Node layak belum mencukupi supaya
+penjadwal dapat menghentikan proses pencarian lebih awal.
+
+Pada klaster kecil, jika kamu mengatur `percentageOfNodesToScore` dengan angka kecil,
+pengaturan ini hampir atau sama sekali tidak berpengaruh, karena alasan yang sama.
+
+Jika klaster kamu punya ratusan Node, gunakan angka bawaan untuk opsi konfigurasi ini.
+Mengubah angkanya kemungkinan besar tidak akan mengubah kinerja penjadwal secara berarti.
+{{< /note >}}
+
+Sebuah catatan penting yang perlu dipertimbangkan saat mengatur angka ini adalah
+ketika klaster dengan jumlah Node sedikit diperiksa untuk kelayakan, beberapa Node
+tidak dikirim untuk diskor bagi sebuah Pod. Hasilnya, sebuah Node yang mungkin memiliki
+nilai lebih tinggi untuk menjalankan Pod tersebut bisa saja tidak diteruskan ke fase penskoran.
+Hal ini berdampak pada penempatan Pod yang kurang ideal.
+
+Kamu sebaiknya menghindari pengaturan `percentageOfNodesToScore` menjadi sangat rendah,
+agar kube-scheduler tidak seringkali membuat keputusan penempatan Pod yang buruk.
+Hindari pengaturan persentase di bawah 10%, kecuali _throughput_ penjadwal sangat penting
+untuk aplikasi kamu dan skor dari Node tidak begitu penting. Dalam kata lain, kamu
+memilih untuk menjalankan Pod pada Node manapun selama Node tersebut layak.
+
+## Bagaimana Penjadwal Mengecek Node
+
+Bagian ini ditujukan untuk kamu yang ingin mengerti bagaimana fitur ini bekerja secara internal.
+
+Untuk memberikan semua Node di dalam klaster sebuah kesempatan yang adil untuk
+dipertimbangkan dalam menjalankan Pod, penjadwal mengecek Node satu persatu
+secara _round robin_. Kamu dapat membayangkan Node-Node ada di dalam sebuah array.
+Penjadwal mulai dari indeks array pertama dan mengecek kelayakan dari Node sampai
+jumlahnya telah mencukupi sesuai dengan `percentageOfNodesToScore`. Untuk Pod berikutnya,
+penjadwal melanjutkan dari indeks array Node yang terhenti ketika memeriksa
+kelayakan Node-Node untuk Pod sebelumnya.
+
+Jika Node-Node berada di beberapa zona, maka penjadwal akan mengecek Node satu persatu
+pada seluruh zona untuk memastikan bahwa Node-Node dari zona berbeda masuk dalam pertimbangan
+kelayakan. Sebagai contoh, ada 6 Node di dalam 2 zona:
+
+```
+Zona 1: Node 1, Node 2, Node 3, Node 4
+Zona 2: Node 5, Node 6
+```
+
+Penjadwal mempertimbangkan kelayakan dari Node-Node tersebut dengan urutan berikut:
+
+```
+Node 1, Node 5, Node 2, Node 6, Node 3, Node 4
+```
+
+Setelah semua Node telah dicek, penjadwal akan kembali pada Node 1.
+
+
@@ -0,0 +1,257 @@
+---
+title: Kerangka Kerja Penjadwalan (Scheduling Framework)
+content_type: concept
+weight: 60
+---
+
+<!-- overview -->
+
+{{< feature-state for_k8s_version="1.15" state="alpha" >}}
+
+Kerangka kerja penjadwalan (_Scheduling Framework_) adalah arsitektur yang dapat 
+dipasang (_pluggable_) pada penjadwal Kubernetes untuk membuat kustomisasi 
+penjadwal lebih mudah. Hal itu dilakukan dengan menambahkan satu kumpulan "plugin" 
+API ke penjadwal yang telah ada. _Plugin_ dikompilasi ke dalam penjadwal. 
+Beberapa API memungkinkan sebagian besar fitur penjadwalan diimplementasikan 
+sebagai _plugin_, sambil tetap mempertahankan penjadwalan "inti" sederhana dan 
+terpelihara. Silahkan merujuk pada [proposal desain dari kerangka penjadwalan]
+[kep] untuk informasi teknis lebih lanjut tentang desain kerangka kerja 
+tersebut.
+
+[kep]: https://github.com/kubernetes/enhancements/blob/master/keps/sig-scheduling/20180409-scheduling-framework.md
+
+
+
+<!-- body -->
+
+# Alur kerja kerangka kerja
+
+Kerangka kerja penjadwalan mendefinisikan beberapa titik ekstensi. _Plugin_ penjadwal
+mendaftar untuk dipanggil di satu atau lebih titik ekstensi. Beberapa _plugin_ ini
+dapat mengubah keputusan penjadwalan dan beberapa hanya bersifat informasi.
+
+Setiap upaya untuk menjadwalkan satu Pod dibagi menjadi dua fase, **Siklus Penjadwalan (_Scheduling Cycle_)** dan **Siklus Pengikatan (_Binding Cycle_)**.
+
+## Siklus Penjadwalan dan Siklus Pengikatan
+
+Siklus penjadwalan memilih sebuah Node untuk Pod, dan siklus pengikatan menerapkan
+keputusan tersebut ke klaster. Secara bersama-sama, siklus penjadwalan dan siklus 
+pengikatan diartikan sebagai sebuah "konteks penjadwalan (_scheduling context_)".
+
+Siklus penjadwalan dijalankan secara serial, sementara siklus pengikatan dapat 
+berjalan secara bersamaan.
+
+Siklus penjadwalan atau pengikatan dapat dibatalkan jika Pod telah ditentukan 
+untuk tidak terjadwalkan atau jika terdapat kesalahan internal. Pod akan 
+dikembalikan ke antrian dan dicoba lagi.
+
+## Titik-titik ekstensi
+
+Gambar berikut menunjukkan konteks penjadwalan Pod dan titik-titik ekstensi
+yang diperlihatkan oleh kerangka penjadwalan. Dalam gambar ini "Filter"
+setara dengan "Predicate" dan "Scoring" setara dengan "Priority Function".
+
+Satu _plugin_ dapat mendaftar di beberapa titik ekstensi untuk melakukan pekerjaan
+yang lebih kompleks atau _stateful_.
+
+{{< figure src="/images/docs/scheduling-framework-extensions.png" title="Titik-titik ekstensi dari kerangka kerja Penjadwalan" >}}
+
+### QueueSort {#queue-sort}
+
+_Plugin_ ini digunakan untuk mengurutkan Pod-Pod dalam antrian penjadwalan. _Plugin_
+QueueSort pada dasarnya menyediakan fungsi `Less (Pod1, Pod2)`. Hanya satu jenis
+_plugin_ QueueSort yang dapat diaktifkan dalam waktu yang bersamaan.
+
+### PreFilter {#pre-filter}
+
+_Plugin_ ini digunakan untuk melakukan pra-proses informasi tentang Pod, atau untuk 
+memeriksa tertentu kondisi yang harus dipenuhi oleh klaster atau Pod. Jika 
+_plugin_ PreFilter menghasilkan hasil yang salah, siklus penjadwalan dibatalkan.
+
+### Filter
+
+_Plugin_ ini digunakan untuk menyaring Node yang tidak dapat menjalankan Pod. 
+Untuk setiap Node, penjadwal akan memanggil _plugin_ Filter sesuai dengan urutan
+mereka dikonfigurasi. Jika ada _plugin_ Filter menandai Node menjadi _infeasible_,
+maka _plugin_ yang lainnya tidak akan dipanggil untuk Node itu. Node-Node dapat dievaluasi 
+secara bersamaan.
+
+### PostFilter {#post-filter}
+
+Plugin ini disebut setelah fase Filter, tetapi hanya ketika tidak ada node yang layak
+ditemukan untuk pod. Plugin dipanggil dalam urutan yang dikonfigurasi. Jika
+plugin postFilter menandai node sebagai 'Schedulable', plugin yang tersisa
+tidak akan dipanggil. Implementasi PostFilter yang khas adalah preemption, yang
+mencoba membuat pod dapat di menjadwalkan dengan mendahului Pod lain.
+
+### PreScore {#pre-score}
+
+_Plugin_ ini digunakan untuk melakukan pekerjaan "pra-penilaian", yang 
+menghasilkan keadaan yang dapat dibagi untuk digunakan oleh _plugin-plugin_ Score. 
+Jika _plugin_ PreScore mengeluarkan hasil salah, maka siklus penjadwalan dibatalkan.
+
+### Score {#score}
+
+_Plugin_ ini digunakan untuk menentukan peringkat Node yang telah melewati fase
+penyaringan. Penjadwal akan memanggil setiap _plugin_ Score untuk setiap Node. 
+Akan ada kisaran bilangan bulat yang telah ditetapkan untuk mewakili skor
+minimum dan maksimum. Setelah fase [NormalizeScore](#normalize-scoring), 
+penjadwal akan menggabungkan skor Node dari semua _plugin_ sesuai dengan bobot 
+_plugin_ yang telah dikonfigurasi.
+
+### NormalizeScore {#normalize-score}
+
+_Plugin_ ini digunakan untuk memodifikasi skor sebelum penjadwal menghitung 
+peringkat akhir Node-Node. _Plugin_ yang mendaftar untuk titik ekstensi ini akan 
+dipanggil dengan hasil [Score](#score) dari _plugin_ yang sama. Hal ini dilakukan
+sekali untuk setiap _plugin_ dan setiap siklus penjadwalan.
+
+Sebagai contoh, anggaplah sebuah _plugin_ `BlinkingLightScorer` memberi peringkat 
+pada Node-Node berdasarkan berapa banyak kedipan lampu yang mereka miliki.
+
+```go
+func ScoreNode(_ *v1.pod, n *v1.Node) (int, error) {
+    return getBlinkingLightCount(n)
+}
+```
+
+Namun, jumlah maksimum kedipan lampu mungkin kecil jika dibandingkan dengan
+`NodeScoreMax`. Untuk memperbaikinya, `BlinkingLightScorer` juga harus mendaftar
+untuk titik ekstensi ini.
+
+```go
+func NormalizeScores(scores map[string]int) {
+    highest := 0
+    for _, score := range scores {
+        highest = max(highest, score)
+    }
+    for node, score := range scores {
+        scores[node] = score*NodeScoreMax/highest
+    }
+}
+```
+
+Jika ada _plugin_ NormalizeScore yang menghasilkan hasil yang salah, maka siklus 
+penjadwalan dibatalkan.
+
+{{< note >}}
+_Plugin_ yang ingin melakukan pekerjaan "pra-pemesanan" harus menggunakan
+titik ekstensi NormalizeScore.
+{{< /note >}}
+
+### Reserve
+
+Ini adalah titik ekstensi yang bersifat informasi. _Plugin_ yang mempertahankan
+keadaan _runtime_ (alias "_stateful plugins_") harus menggunakan titik ekstensi ini
+untuk diberitahukan oleh penjadwal ketika sumber daya pada suatu Node dicadangkan
+untuk Pod yang telah disiapkan. Proses ini terjadi sebelum penjadwal benar-benar
+mengikat Pod ke Node, dan itu ada untuk mencegah kondisi balapan (_race conditions_)
+ketika penjadwal menunggu agar pengikatan berhasil.
+
+Ini adalah langkah terakhir dalam siklus penjadwalan. Setelah Pod berada dalam 
+status dicadangkan, maka itu akan memicu _plugin_ [Unreserve](#unreserve)
+(apabila gagal) atau _plugin_ [PostBind](#post-bind) (apabila sukses) 
+di akhir siklus pengikatan.
+
+### Permit
+
+_Plugin_ Permit dipanggil pada akhir siklus penjadwalan untuk setiap Pod
+untuk mencegah atau menunda pengikatan ke Node kandidat. _Plugin_ Permit dapat 
+melakukan salah satu dari ketiga hal ini:
+
+1. **approve** \
+     Setelah semua _plugin_ Permit menyetujui sebuah Pod, Pod tersebut akan dikirimkan untuk diikat.
+
+2. **deny** \
+     Jika ada _plugin_ Permit yang menolak sebuah Pod, Pod tersebut akan dikembalikan ke 
+     antrian penjadwalan. Hal ini akan memicu _plugin_ [Unreserve](#unreserve).
+
+3. **wait** (dengan batas waktu) \
+     Jika _plugin_ Permit menghasilkan "wait", maka Pod disimpan dalam
+     daftar Pod "yang menunggu" internal, dan siklus pengikatan Pod ini dimulai tetapi akan langsung diblokir
+     sampai mendapatkan [_approved_](#frameworkhandle). Jika waktu tunggu habis, ** wait ** menjadi ** deny **
+     dan Pod dikembalikan ke antrian penjadwalan, yang memicu _plugin_ [Unreserve](#unreserve).
+
+{{< note >}}
+Ketika setiap _plugin_ dapat mengakses daftar Pod-Pod "yang menunggu" dan menyetujuinya
+(silahkan lihat [`FrameworkHandle`](#frameworkhandle)), kami hanya mengharapkan
+_plugin_ Permit untuk menyetujui pengikatan Pod dalam kondisi "menunggu" yang 
+telah dipesan. Setelah Pod disetujui, akan dikirim ke fase [PreBind](#pre-bind).
+{{< /note >}}
+
+### PreBind {#pre-bind}
+
+_Plugin_ ini digunakan untuk melakukan pekerjaan apa pun yang diperlukan sebelum
+Pod terikat. Sebagai contoh, _plugin_ PreBind dapat menyediakan _network volume_ 
+dan melakukan _mounting_ pada Node target sebelum mengizinkan Pod berjalan di 
+sana.
+
+Jika ada _plugin_ PreBind yang menghasilkan kesalahan, maka Pod [ditolak](#unreserve)
+dan kembali ke antrian penjadwalan.
+
+### Bind
+
+_Plugin_ ini digunakan untuk mengikat Pod ke Node. _Plugin-plugin_ Bind tidak akan
+dipanggil sampai semua _plugin_ PreBind selesai. Setiap _plugin_ Bind dipanggil 
+sesuai urutan saat dikonfigurasi. _Plugin_ Bind dapat memilih untuk menangani 
+atau tidak Pod yang diberikan. Jika _plugin_ Bind memilih untuk menangani Pod, 
+** _plugin_ Bind yang tersisa dilewati **.
+
+### PostBind {#post-bind}
+
+Ini adalah titik ekstensi bersifat informasi. _Plugin-plugin_ PostBind dipanggil
+setelah sebuah Pod berhasil diikat. Ini adalah akhir dari siklus pengikatan, dan
+dapat digunakan untuk membersihkan sumber daya terkait.
+
+### Unreserve
+
+Ini adalah titik ekstensi bersifat informasi. Jika sebuah Pod telah dipesan dan 
+kemudian ditolak di tahap selanjutnya, maka _plugin-plugin_ Unreserve akan 
+diberitahu. _Plugin_ Unreserve harus membersihkan status yang terkait dengan Pod
+yang dipesan.
+
+_Plugin_ yang menggunakan titik ekstensi ini sebaiknya juga harus digunakan
+[Reserve](#unreserve).
+
+## _Plugin_ API
+
+Ada dua langkah untuk _plugin_ API. Pertama, _plugin_ harus mendaftar dan mendapatkan
+konfigurasi, kemudian mereka menggunakan antarmuka titik ekstensi. Antarmuka (_interface_)
+titik ekstensi memiliki bentuk sebagai berikut.
+
+```go
+type Plugin interface {
+    Name() string
+}
+
+type QueueSortPlugin interface {
+    Plugin
+    Less(*v1.pod, *v1.pod) bool
+}
+
+type PreFilterPlugin interface {
+    Plugin
+    PreFilter(context.Context, *framework.CycleState, *v1.pod) error
+}
+
+// ...
+```
+
+## Konfigurasi _plugin_
+
+Kamu dapat mengaktifkan atau menonaktifkan _plugin_ dalam konfigurasi penjadwal.
+Jika kamu menggunakan Kubernetes v1.18 atau yang lebih baru, kebanyakan 
+[plugin-plugin penjadwalan](/docs/reference/scheduling/profiles/#scheduling-plugins)
+sudah digunakan dan diaktifkan secara bawaan.
+
+Selain _plugin-plugin_ bawaan, kamu juga dapat mengimplementasikan _plugin-plugin_ penjadwalan 
+kamu sendiri dan mengonfigurasinya bersama-sama dengan _plugin-plugin_ bawaan.
+Kamu bisa mengunjungi [plugin-plugin penjadwalan](https://github.com/kubernetes-sigs/scheduler-plugins) 
+untuk informasi lebih lanjut.
+
+Jika kamu menggunakan Kubernetes v1.18 atau yang lebih baru, kamu dapat 
+mengonfigurasi sekumpulan _plugin_ sebagai profil penjadwal dan kemudian menetapkan 
+beberapa profil agar sesuai dengan berbagai jenis beban kerja. Pelajari lebih 
+lanjut di [multi profil](/docs/reference/scheduling/profiles/#multiple-profiles).
+
+