Change:
This is tracking issue of our progress from Q1 2021 onwards. In the beginning of this milestone, as per our , we have translated 220 pages from 84 contributors (the script from main repo shows 260+ pages), with around 8,000 views per month. In this milestone, we still continuing on updating the obsolete pages. We are not officially listing down target pages to translate, but feel free if you have spare time to translate some. Please check this documentation about which gives step-by-step on how to start to contribute and translate using official guidelines. There is a list of outdated pages (40 out of 162 pages for this milestone) and please feel free if you want to take part on this work. [X] removed [X] removed content/en//docs/tasks/tools/install- [X] removed [X] removed content/en//docs/tasks/example-task- [X] removed content/en//docs/tasks/administer-cluster/cluster- [X] removed content/en//docs/setup/learning- [X] removed content/en//docs/concepts/configuration/assign-pod- [X] removed content/en//docs/concepts/configuration/pod- [ ] removed content/en//docs/concepts/configuration/manage-compute-resources- [X] moved content/en//docs/concepts/configuration/resource-bin- [X] moved content/en//docs/concepts/configuration/taint-and- [X] renamed content/en//docs/concepts/scheduling/scheduling- [X] renamed content/en//docs/concepts/scheduling/scheduler-perf- [X] renamed content/en//docs/concepts/scheduling/kube- [X] renamed [ ] removed content/en//docs/concepts/workloads/pods/pod-[ ] removed [ ] removed content/en//docs/concepts/workloads/controllers/jobs-run-to- [ ] removed content/en//docs/concepts/extend-kubernetes/poseidon-firmament-alternate- [ ] removed [ ] removed content/en//docs/concepts/cluster-administration/cluster-administration- [ ] removed content/en//docs/concepts/cluster- [ ] removed content/en//docs/concepts/cluster-administration/cloud- [ ] removed content/en//docs/concepts/cluster-administration/controller-[X] removed content/en//docs/concepts/cluster- [X] removed [X] removed [X] removed [X] modified content/en/includes/task-tutorial- [X] modified content/en/docs/home/supported-doc- [ ] modified [ ] modified content/en/docs/tasks/debug-application-cluster/resource-usage-[ ] modified content/en/docs/tasks/run-application/horizontal-pod-autoscale- [ ] modified content/en/docs/tasks/run-application/horizontal-pod- [ ] modified content/en/docs/tasks/run-application/run-stateless-application- [ ] modified content/en/docs/tasks/run-application/force-delete-stateful-set- [ ] modified content/en/docs/tasks/tools/install- [ ] modified [ ] modified content/en/docs/tasks/configure-pod-container/configure-service- [ ] modified content/en/docs/tasks/configure-pod-container/configure-persistent-volume- /language id /cc
/triage accepted
I'm taking the 4th part, as I've done the in
Thanks .. it is updated.
is moved to as mentioned here
is removed and redirect to official minikube webpage , as mentioned here
The whole pages are move into including as mentioned here
The whole are removed in , I'm going to remove the directory as well as it's unused now.
is moved to via
is removed via
Just sharing a useful trick for finding related PR which delete/modified a file: e.g. The output will be similar with this: Please note the commit hash in the output (, in the case of the example above). You can use the same command to find which commit modified a file by changing the filter from to (refer to for more filters). In case of modified file, you might get multiple commit hashes, pick the latest one (contains the recent changes), or just pick ones that suit your needs. Go to, e.g., (replace with your commit hash in step 1). Find the related PR with the commit, e.g. via web UI: ! In bottom left hand corner near the branch name, in this case , you can see the PR id . Click on the link and you will be redirected to the respective PR page, then you can analyse what changes has been made and what actions needed to incorporate it to our localization.
is removed here together with others.
is removed here
Hi ... it seems this issue is automatically closed. Do you have any idea how to re-opened it?
/reopen
Reopened this issue. <detailsIn response to : /reopen Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Thanks :)
/reopen
Reopened this issue. <detailsIn response to : /reopen Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Hi .... I think we need to close this issue, because it has already behind the schedule. Do we need to complete all within 1-2 weeks? or we need to carry forward to next quarter?
Hi All, I have opened Q2 2021 tracking issue

Discussion:
{{< glossary_tooltip term_id="pod" >}}, atau mungkin beberapa Pod sekaligus, untuk melakukan sebuah pekerjaan dan kemudian berhenti. <del> (Setelah [dijadwalkan](../../../../en/docs/concepts/scheduling/), objek Pod </del> <ins> (Setelah [dijadwalkan](../../../../en/docs/concepts/scheduling-eviction/), objek Pod </ins> akan menjadi bagian dari keadaan yang diinginkan oleh kubelet). Ketika _controller job_ melihat tugas baru, maka _controller_ itu memastikan bahwa,

<ins> --- title: "Penjadwalan dan Pengusiran" weight: 90 --- </ins>

## {{% heading "whatsnext" %}} <del> * Baca tentang [penyetelan performa penjadwal](/id/docs/concepts/scheduling/scheduler-perf-tuning/) </del> <ins> * Baca tentang [penyetelan performa penjadwal](/id/docs/concepts/scheduling-eviction/scheduler-perf-tuning/) </ins> * 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/)

<ins> --- 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. </ins>

<ins> --- 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). </ins>

<del> --- title: "Penjadwalan" weight: 90 --- </del>

<del> --- 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/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/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. </del>

<del> --- 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). </del>

/docs/concepts/configuration/manage-compute-resources-container/ /docs/concepts/configuration/manage-resources-containers/ 301 /docs/concepts/configuration/resource-bin-packing/      /docs/concepts/scheduling-eviction/resource-bin-packing/ 301 /docs/concepts/configuration/scheduler-perf-tuning/      /docs/concepts/scheduling-eviction/scheduler-perf-tuning/    301 <ins> /id/docs/concepts/configuration/scheduler-perf-tuning/      /id/docs/concepts/scheduling-eviction/scheduler-perf-tuning/    301 </ins> /docs/concepts/configuration/scheduling-framework/     /docs/concepts/scheduling-eviction/scheduling-framework/    301 <ins> /id/docs/concepts/configuration/scheduling-framework/     /id/docs/concepts/scheduling-eviction/scheduling-framework/    301 </ins> /docs/concepts/configuration/taint-and-toleration/     /docs/concepts/scheduling-eviction/taint-and-toleration/ 301 /id/docs/concepts/configuration/taint-and-toleration/     /id/docs/concepts/scheduling-eviction/taint-and-toleration/ 301 /docs/concepts/extend-kubernetes/extend-cluster/      /docs/concepts/extend-kubernetes/ 301

/docs/concepts/policy/container-capabilities/     /docs/tasks/configure-pod-container/security-context/#set-capabilities-for-a-container/ 301 /docs/concepts/policy/security-context/     /docs/tasks/configure-pod-container/security-context/ 301 /docs/concepts/scheduling/kube-scheduler/     /docs/concepts/scheduling-eviction/kube-scheduler/ 301 <ins> /id/docs/concepts/scheduling/kube-scheduler/     /id/docs/concepts/scheduling-eviction/kube-scheduler/ 301 </ins> /docs/concepts/scheduling/scheduler-perf-tuning/     /docs/concepts/scheduling-eviction/scheduler-perf-tuning/ 301 <ins> /id/docs/concepts/scheduling/scheduler-perf-tuning/     /id/docs/concepts/scheduling-eviction/scheduler-perf-tuning/ 301 </ins> /docs/concepts/scheduling/scheduling-framework/     /docs/concepts/scheduling-eviction/scheduling-framework/ 301 <ins> /id/docs/concepts/scheduling/scheduling-framework/     /id/docs/concepts/scheduling-eviction/scheduling-framework/ 301 </ins> /docs/concepts/service-catalog/     /docs/concepts/extend-kubernetes/service-catalog/ 301 /docs/concepts/services-networking/networkpolicies/     /docs/concepts/services-networking/network-policies/ 301 /docs/concepts/storage/etcd-store-api-object/     /docs/tasks/administer-cluster/configure-upgrade-etcd/ 301