Merge pull request #20588 from ariscahyadi/id-local-flow-control
ID Localization for Flow Control (API Priority and Fairness)pull/20947/head
Kubernetes Prow Robot
GitHub
commit
bb67fbf28c
|
|
@ -0,0 +1,374 @@
|
|||
---
|
||||
title: Prioritas dan Kesetaraan API (API Priority and Fairness)
|
||||
content_template: templates/concept
|
||||
min-kubernetes-server-version: v1.18
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
{{< feature-state state="alpha" for_k8s_version="v1.18" >}}
|
||||
|
||||
Mengontrol perilaku server API dari Kubernetes pada situasi beban berlebih
|
||||
merupakan tugas utama dari administrator klaster. {{< glossary_tooltip term_id="kube-apiserver" text="kube-apiserver" >}} memiliki beberapa kontrol yang tersedia
|
||||
(seperti opsi `--max-request-inflight` dan `--max-mutating-request-inflight`
|
||||
pada baris perintah atau _command-line_) untuk membatasi jumlah pekerjaan luar biasa yang akan
|
||||
diterima, untuk mencegah banjirnya permintaan masuk dari beban berlebih
|
||||
yang berpotensi untuk menghancurkan server API. Namun opsi ini tidak cukup untuk memastikan
|
||||
bahwa permintaan yang paling penting dapat diteruskan pada saat kondisi lalu lintas (_traffic_) yang cukup tinggi.
|
||||
|
||||
Fitur Prioritas dan Kesetaraan API atau _API Priority and Fairness_ (APF) adalah alternatif untuk meningkatkan
|
||||
batasan _max-inflight_ seperti yang disebutkan di atas. APF mengklasifikasi
|
||||
dan mengisolasi permintaan dengan cara yang lebih halus. Fitur ini juga memperkenalkan
|
||||
jumlah antrian yang terbatas, sehingga tidak ada permintaan yang ditolak
|
||||
pada saat terjadi lonjakan permintaan dalam waktu yang sangat singkat. Permintaan dibebaskan dari antrian dengan menggunakan
|
||||
teknik antrian yang adil (_fair queuing_) sehingga, sebagai contoh, perilaku buruk dari satu
|
||||
{{<glossary_tooltip text="controller" term_id="controller">}} tidak seharusnya
|
||||
mengakibatkan _controller_ yang lain menderita (meskipun pada tingkat prioritas yang sama).
|
||||
|
||||
{{< caution >}}
|
||||
Permintaan yang diklasifikasikan sebagai "long running" - terutama _watch_ - tidak
|
||||
mengikuti filter prioritas dan kesetaraan API. Dimana ini juga berlaku pada
|
||||
opsi `--max-request-inflight` tanpa mengaktifkan APF.
|
||||
|
||||
{{< /caution >}}
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
## Mengaktifkan prioritas dan kesetaraan API
|
||||
|
||||
Fitur APF dikontrol oleh sebuah gerbang fitur (_feature gate_)
|
||||
dan fitur ini tidak diaktifkan secara bawaan. Silahkan lihat
|
||||
[gerbang fitur](/docs/reference/command-line-tools-reference/feature-gates/)
|
||||
untuk penjelasan umum tentang gerbang fitur dan bagaimana cara mengaktifkan dan menonaktifkannya.
|
||||
Nama gerbang fitur untuk APF adalah "APIPriorityAndFairness".
|
||||
Fitur ini melibatkan sebuah {{<glossary_tooltip term_id="api-group"
|
||||
text="Grup API">}} yang harus juga diaktifkan. Kamu bisa melakukan ini dengan
|
||||
menambahkan opsi pada baris perintah berikut pada permintaan ke `kube-apiserver` kamu:
|
||||
|
||||
```shell
|
||||
kube-apiserver \
|
||||
--feature-gates=APIPriorityAndFairness=true \
|
||||
--runtime-config=flowcontrol.apiserver.k8s.io/v1alpha1=true \
|
||||
# …dan opsi-opsi lainnya seperti biasa
|
||||
```
|
||||
|
||||
Opsi pada baris perintah `--enable-priority-and-fairness=false` akan menonaktifkan fitur
|
||||
APF, bahkan ketika opsi yang lain telah mengaktifkannya.
|
||||
|
||||
## Konsep
|
||||
Ada beberapa fitur lainnya yang terlibat dalam fitur APF. Permintaan yang masuk diklasifikasikan berdasarkan atribut permintaan dengan menggunakan
|
||||
FlowSchema, dan diserahkan ke tingkat prioritas. Tingkat prioritas menambahkan tingkat
|
||||
isolasi dengan mempertahankan batas konkurensi yang terpisah, sehingga permintaan yang diserahkan
|
||||
ke tingkat prioritas yang berbeda tidak dapat membuat satu sama lain menderita. Dalam sebuah tingkat prioritas,
|
||||
algoritma _fair-queuing_ mencegah permintaan dari _flows_ yang berbeda akan memberikan penderitaan
|
||||
kepada yang lainnya, dan memperbolehkan permintaan untuk dimasukkan ke dalam antrian untuk mencegah pelonjakan lalu lintas
|
||||
yang akan menyebabkan gagalnya permintaan, walaupun pada saat beban rata-ratanya cukup rendah.
|
||||
|
||||
### Tingkat prioritas (_Priority Level_)
|
||||
Tanpa pengaktifan APF, keseluruhan konkurensi dalam
|
||||
server API dibatasi oleh opsi pada `kube-apiserver`
|
||||
`--max-request-inflight` dan `--max-mutating-request-inflight`. Dengan pengaktifan APF,
|
||||
batas konkurensi yang ditentukan oleh opsi ini akan dijumlahkan dan kemudian jumlah tersebut dibagikan
|
||||
untuk sekumpulan tingkat prioritas (_priority level_) yang dapat dikonfigurasi. Setiap permintaan masuk diserahkan
|
||||
ke sebuah tingkat prioritas, dan setiap tingkat prioritas hanya akan meneruskan sebanyak mungkin
|
||||
permintaan secara bersamaan sesuai dengan yang diijinkan dalam konfigurasi.
|
||||
|
||||
Konfigurasi bawaan, misalnya, sudah mencakup tingkat prioritas terpisah untuk
|
||||
permintaan dalam rangka pemilihan pemimpin (_leader-election_), permintaan dari _controller_ bawaan, dan permintaan dari
|
||||
Pod. Hal ini berarti bahwa Pod yang berperilaku buruk, yang bisa membanjiri server API
|
||||
dengan permintaan, tidak akan mampu mencegah kesuksesan pemilihan pemimpin atau tindakan yang dilakukan oleh _controller_ bawaan.
|
||||
|
||||
### Antrian (_Queuing_)
|
||||
|
||||
Bahkan dalam sebuah tingkat prioritas mungkin akan ada sumber lalu lintas yang berbeda dalam jumlah besar.
|
||||
Dalam situasi beban berlebih, sangat penting untuk mencegah satu aliran
|
||||
permintaan dari penderitaan karena aliran yang lainnya (khususnya, dalam kasus yang relatif umum dari sebuah
|
||||
klien tunggal bermasalah (_buggy_) yang dapat membanjiri _kube-apiserver_ dengan permintaan, klien bermasalah itu
|
||||
idealnya tidak memiliki banyak dampak yang bisa diukur terhadap klien yang lainnya). Hal ini
|
||||
ditangani dengan menggunakan algoritma _fair-queuing_ untuk memproses permintaan yang diserahkan
|
||||
oleh tingkat prioritas yang sama. Setiap permintaan diserahkan ke sebuah _flow_, yang diidentifikasi berdasarkan
|
||||
nama FlowSchema yang sesuai, ditambah dengan _flow distinguisher_ - yang
|
||||
bisa saja didasarkan pada pengguna yang meminta, sumber daya Namespace dari target, atau tidak sama sekali - dan
|
||||
sistem mencoba untuk memberikan bobot yang hampir sama untuk permintaan dalam _flow_ yang berbeda dengan tingkat prioritas yang sama.
|
||||
|
||||
Setelah mengklasifikasikan permintaan ke dalam sebuah _flow_, fitur APF kemudian
|
||||
dapat menyerahkan permintaan ke dalam sebuah antrian. Penyerahan ini menggunakan
|
||||
teknik yang dikenal sebagai {{<glossary_tooltip term_id="shuffle-sharding"
|
||||
text="_shuffle sharding_">}}, yang membuat penggunaan antrian yang relatif efisien
|
||||
untuk mengisolasi _flow_ dengan intensitas rendah dari _flow_ dengan intensitas tinggi.
|
||||
|
||||
Detail dari algoritma antrian dapat disesuaikan untuk setiap tingkat prioritas, dan
|
||||
memperbolehkan administrator untuk menukar (_trade off_) dengan penggunaan memori, kesetaraan (properti dimana
|
||||
_flow_ yang independen akan membuat semua kemajuan ketika total dari lalu lintas sudah melebihi kapasitas),
|
||||
toleransi untuk lonjakan lalu lintas, dan penambahan latensi yang dihasilkan oleh antrian.
|
||||
|
||||
### Permintaan yang dikecualikan (_Exempt Request_)
|
||||
Beberapa permintaan dianggap cukup penting sehingga mereka tidak akan mengikuti
|
||||
salah satu batasan yang diberlakukan oleh fitur ini. Pengecualian ini untuk mencegah
|
||||
konfigurasi _flow control_ yang tidak terkonfigurasi dengan baik sehingga tidak benar-benar menonaktifkan server API.
|
||||
|
||||
## Bawaan (_Default_)
|
||||
|
||||
Fitur APF dikirimkan dengan konfigurasi yang disarankan
|
||||
dimana konfigurasi itu seharusnya cukup untuk bereksperimen; jika klaster kamu cenderung
|
||||
mengalami beban berat maka kamu harus mempertimbangkan konfigurasi apa yang akan bekerja paling baik.
|
||||
Kelompok konfigurasi yang disarankan untuk semua permintaan terbagi dalam lima prioritas
|
||||
kelas:
|
||||
|
||||
* Tingkat prioritas `system` diperuntukkan bagi permintaan dari grup `system:nodes`,
|
||||
mis. Kubelet, yang harus bisa menghubungi server API agar
|
||||
mendapatkan _workload_ untuk dijadwalkan.
|
||||
|
||||
* Tingkat prioritas `leader-election` diperuntukkan bagi permintaan dalam pemilihan pemimpin (_leader election_)
|
||||
dari _controller_ bawaan (khususnya, permintaan untuk `endpoint`, `configmaps`,
|
||||
atau `leases` yang berasal dari `system:kube-controller-manager` atau pengguna
|
||||
`system:kube-scheduler` dan akun Service di Namespace `kube-system`). Hal ini
|
||||
penting untuk mengisolasi permintaan ini dari lalu lintas yang lain karena
|
||||
kegagalan dalam pemilihan pemimpin menyebabkan _controller_ akan gagal dan memulai kembali (_restart_),
|
||||
yang pada akhirnya menyebabkan lalu lintas yang lebih mahal karena _controller_
|
||||
yang baru perlu menyinkronkan para informannya.
|
||||
|
||||
* Tingkat prioritas `workload-high` diperuntukkan bagi permintaan yang lain dari _controller_ bawaan.
|
||||
|
||||
* Tingkat prioritas `workload-low` diperuntukkan bagi permintaan dari akun Service yang lain,
|
||||
yang biasanya mencakup semua permintaan dari _controller_ yang bekerja didalam Pod.
|
||||
|
||||
* Tingkat prioritas `global-default` menangani semua lalu lintas lainnya, mis.
|
||||
perintah interaktif `kubectl` yang dijalankan oleh pengguna yang tidak memiliki hak khusus.
|
||||
|
||||
Kemudian, ada dua PriorityLevelConfiguration dan dua FlowSchema yang telah
|
||||
dibangun dan tidak mungkin ditimpa ulang:
|
||||
|
||||
* Tingkat prioritas khusus `exempt` diperuntukkan bagi permintaan yang tidak akan dikenakan
|
||||
_flow control_ sama sekali: permintaan itu akan selalu diteruskan sesegera mungkin.
|
||||
FlowSchema `exempt` khusus mengklasifikasikan semua permintaan dari kelompok `system:masters`
|
||||
ke dalam tingkat prioritas khusus ini. Kamu juga dapat menentukan FlowSchema lain yang mengarahkan
|
||||
permintaan lain ke tingkat prioritas ini juga, apabila permintaan tersebut sesuai.
|
||||
|
||||
* Tingkat prioritas khusus `catch-all` digunakan secara kombinasi dengan spesial
|
||||
FlowSchema `catch-all` untuk memastikan bahwa setiap permintaan mendapatkan proses
|
||||
klasifikasi. Biasanya kamu tidak harus bergantung pada konfigurasi _catch-all_ ini,
|
||||
dan kamu seharusnya membuat FlowSchema _catch-all_ dan PriorityLevelConfiguration kamu sendiri
|
||||
(atau gunakan konfigurasi `global-default` yang sudah diinstal secara bawaan) secara benar.
|
||||
Untuk membantu menemukan kesalahan konfigurasi yang akan melewatkan beberapa klasifikasi
|
||||
permintaan, maka tingkat prioritas `catch-all` hanya wajib mengijinkan satu konkurensi
|
||||
bersama dan tidak melakukan memasukkan permintaan dalam antrian, sehingga membuat lalu lintas
|
||||
yang secara relatif hanya sesuai dengan FlowSchema `catch-all` akan ditolak dengan kode kesalahan HTTP 429.
|
||||
|
||||
## Sumber daya (_Resource_)
|
||||
_Flow control_ API melibatkan dua jenis sumber daya.
|
||||
[PriorityLevelConfiguration](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io)
|
||||
yang menentukan kelas isolasi yang tersedia, bagian dari konkurensi anggaran yang tersedia
|
||||
yang masing-masing dapat menangani bagian tersebut, dan memperbolehkan untuk melakukan _fine-tuning_ terhadap perilaku antrian.
|
||||
[FlowSchema](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#flowschema-v1alpha1-flowcontrol-apiserver-k8s-io)
|
||||
yang digunakan untuk mengklasifikasikan permintaan individu yang masuk, mencocokkan masing-masing dengan setiap
|
||||
PriorityLevelConfiguration.
|
||||
|
||||
### PriorityLevelConfiguration
|
||||
Sebuah PriorityLevelConfiguration merepresentasikan sebuah kelas isolasi tunggal. Setiap
|
||||
PriorityLevelConfiguration memiliki batas independensi dalam hal jumlah
|
||||
permintaan yang belum diselesaikan, dan batasan dalam hal jumlah permintaan yang mengantri.
|
||||
|
||||
Batas konkurensi untuk PriorityLevelConfiguration tidak disebutkan dalam
|
||||
jumlah permintaan secara mutlak, melainkan dalam "concurrency shares." Total batas konkurensi
|
||||
untuk server API didistribusikan di antara PriorityLevelConfiguration yang ada
|
||||
secara proporsional dengan "concurrency shares" tersebut. Ini mengizinkan seorang
|
||||
administrator klaster untuk meningkatkan atau menurunkan jumlah total lalu lintas ke sebuah
|
||||
server dengan memulai kembali `kube-apiserver` dengan nilai opsi
|
||||
`--max-request-inflight` (atau `--max-mutating-request-inflight`) yang berbeda, dan semua
|
||||
PriorityLevelConfiguration akan melihat konkurensi maksimum yang diizinkan kepadanya untuk menaikkan (atau
|
||||
menurunkan) dalam fraksi yang sama.
|
||||
|
||||
{{< caution >}}
|
||||
Dengan fitur Prioritas dan Kesetaraan yang diaktifkan, batas total konkurensi untuk
|
||||
server diatur pada nilai penjumlahan dari `--max-request-inflight` dan
|
||||
`--max-mutating-request-inflight`. Tidak akan ada lagi perbedaan
|
||||
antara permintaan yang bermutasi dan permintaan yang tidak bermutasi; jika kamu ingin melayaninya
|
||||
secara terpisah untuk suatu sumber daya yang ada, maka perlu membuat FlowSchema terpisah yang sesuai dengan
|
||||
masing-masing kata kerja dari permintaan yang bermutasi dan yang tidak bermutasi tersebut.
|
||||
{{< /caution >}}
|
||||
|
||||
Ketika jumlah permintaan masuk yang diserahkan kepada sebuah
|
||||
PriorityLevelConfiguration melebihi dari tingkat konkurensi yang diizinkan,
|
||||
bagian `type` dari spesifikasinya menentukan apa yang akan terjadi pada permintaan selanjutnya.
|
||||
Tipe `Reject` berarti bahwa kelebihan lalu lintas akan segera ditolak
|
||||
dengan kode kesalahan HTTP 429 (yang artinya terlalu banyak permintaan). Tipe `Queue` berarti permintaan
|
||||
di atas batas tersebut akan mengantri, dengan teknik _sharding shuffle_ dan _fair queuing_ yang digunakan
|
||||
untuk menyelaraskan kemajuan antara _flow_ permintaan.
|
||||
|
||||
Konfigurasi antrian memungkinkan mengatur algoritma _fair queuing_ untuk sebuah
|
||||
tingkat prioritas. Detail algoritma dapat dibaca di [proposal pembaharuan](#what-s-next), namun secara singkat:
|
||||
|
||||
* Meningkatkan `queue` (antrian) berarti mengurangi tingkat tabrakan antara _flow_ yang berbeda,
|
||||
sehingga berakibat pada biaya untuk meningkatkan penggunaan memori. Nilai 1 di sini secara
|
||||
efektif menonaktifkan logika _fair-queuing_, tetapi masih mengizinkan permintaan untuk
|
||||
dimasukkan kedalam antrian.
|
||||
|
||||
* Meningkatkan `queueLengthLimit` berarti memperbolehkan lonjakan yang lebih besar dari lalu lintas
|
||||
untuk berkelanjutan tanpa menggagalkan permintaan apa pun, dengan konsekuensi akan meningkatkan
|
||||
latensi dan penggunaan memori.
|
||||
|
||||
* Mengubah `handSize` berarti memperbolehkan kamu untuk menyesuaikan probabilitas tabrakan antara
|
||||
_flow_ yang berbeda dan keseluruhan konkurensi yang tersedia untuk satu _flow_ tunggal
|
||||
dalam situasi beban berlebih.
|
||||
|
||||
{{< note >}}
|
||||
`HandSize` yang lebih besar membuat dua _flow_ individual berpeluang kecil untuk bertabrakan
|
||||
(dan dimana _flow_ yang satu bisa membuat _flow_ yang lain menderita), tetapi akan lebih memungkinkan
|
||||
bahwa _flow_ dalam jumlah kecil akan dapat mendominasi apiserver. `HandSize` yang lebih besar juga
|
||||
berpotensi meningkatkan jumlah latensi yang diakibatkan oleh satu _flow_ lalu lintas tunggal
|
||||
yang tinggi. Jumlah maksimum permintaan dalam antrian yang diijinkan dari sebuah _flow_ tunggal
|
||||
adalah `handSize * queueLengthLimit`.
|
||||
{{< /note >}}
|
||||
|
||||
Berikut ini adalah tabel yang menunjukkan koleksi konfigurasi _shuffle sharding_
|
||||
yang menarik, dimana setiap probabilitas _mouse_ (_flow_ dengan intensitas rendah)
|
||||
yang diberikan akan dimampatkan oleh _elephant_ (_flow_ dengan intensitas tinggi) dalam sebuah koleksi ilustratif
|
||||
dari jumlah _elephant_ yang berbeda. Silahkan lihat pada
|
||||
https://play.golang.org/p/Gi0PLgVHiUg, yang digunakan untuk menghitung nilai-nilai dalam tabel ini.
|
||||
|
||||
{{< table caption="Contoh Konfigurasi Shuffle Sharding" >}}
|
||||
|HandSize| Queues| 1 elephant| 4 elephants| 16 elephants|
|
||||
|--------|-----------|------------|----------------|--------------------|
|
||||
| 12| 32| 4.428838398950118e-09| 0.11431348830099144| 0.9935089607656024|
|
||||
| 10| 32| 1.550093439632541e-08| 0.0626479840223545| 0.9753101519027554|
|
||||
| 10| 64| 6.601827268370426e-12| 0.00045571320990370776| 0.49999929150089345|
|
||||
| 9| 64| 3.6310049976037345e-11| 0.00045501212304112273| 0.4282314876454858|
|
||||
| 8| 64| 2.25929199850899e-10| 0.0004886697053040446| 0.35935114681123076|
|
||||
| 8| 128| 6.994461389026097e-13| 3.4055790161620863e-06| 0.02746173137155063|
|
||||
| 7| 128| 1.0579122850901972e-11| 6.960839379258192e-06| 0.02406157386340147|
|
||||
| 7| 256| 7.597695465552631e-14| 6.728547142019406e-08| 0.0006709661542533682|
|
||||
| 6| 256| 2.7134626662687968e-12| 2.9516464018476436e-07| 0.0008895654642000348|
|
||||
| 6| 512| 4.116062922897309e-14| 4.982983350480894e-09| 2.26025764343413e-05|
|
||||
| 6| 1024| 6.337324016514285e-16| 8.09060164312957e-11| 4.517408062903668e-07|
|
||||
|
||||
### FlowSchema
|
||||
|
||||
FlowSchema mencocokkan beberapa permintaan yang masuk dan menetapkan permintaan ke dalam sebuah
|
||||
tingkat prioritas. Setiap permintaan masuk diuji dengan setiap
|
||||
FlowSchema secara bergiliran, dimulai dari yang terendah secara numerik ---
|
||||
yang kita anggap sebagai yang tertinggi secara logis --- `matchingPrecedence` dan
|
||||
begitu seterusnya. FlowSchema yang cocok pertama kali akan menang.
|
||||
|
||||
{{< caution >}}
|
||||
Hanya FlowSchema yang pertama kali cocok untuk permintaan yang diberikan yang akan dianggap penting. Jika ada banyak
|
||||
FlowSchema yang cocok dengan sebuah permintaan masuk, maka akan ditetapkan berdasarkan salah satu
|
||||
yang mempunyai `matchingPrecedence` tertinggi. Jika ada beberapa FlowSchema dengan nilai
|
||||
`matchingPrecedence` yang sama dan cocok dengan permintaan yang sama juga, permintaan dengan leksikografis
|
||||
`name` yang lebih kecil akan menang, tetapi akan lebih baik untuk tidak mengandalkan metode ini, dan sebaiknya
|
||||
perlu memastikan bahwa tidak ada dua FlowSchema yang memiliki `matchingPrecedence` yang sama.
|
||||
{{< /caution >}}
|
||||
|
||||
Sebuah FlowSchema dianggap cocok dengan sebuah permintaan yang diberikan jika setidaknya salah satu dari `rules` nya
|
||||
ada yang cocok. Sebuah aturan (_rule_) cocok jika setidaknya satu dari `subject` *dan*
|
||||
ada salah satu dari `resourceRules` atau` nonResourceRules` (tergantung dari apakah permintaan
|
||||
yang masuk adalah untuk URL sumber daya atau non-sumber daya) yang cocok dengan permintaan tersebut.
|
||||
|
||||
Untuk bagian `name` dalam subjek, dan bagian `verbs`, `apiGroups`, `resources`,
|
||||
`namespaces`, dan `nonResourceURLs` dalam aturan sumber daya dan non-sumber daya,
|
||||
_wildcard_ `*` mungkin bisa ditetapkan untuk mencocokkan semua nilai pada bagian yang diberikan,
|
||||
sehingga secara efektif menghapusnya dari pertimbangan.
|
||||
|
||||
Sebuah `DistinguisherMethod.type` dari FlowSchema menentukan bagaimana permintaan
|
||||
yang cocok dengan Skema itu akan dipisahkan menjadi _flow_. Nilai tipe itu bisa jadi `ByUser`, dalam
|
||||
hal ini satu pengguna yang meminta tidak akan bisa menghabiskan kapasitas dari pengguna lain,
|
||||
atau bisa juga `ByNamespace`, dalam hal ini permintaan sumber daya
|
||||
di salah satu Namespace tidak akan bisa menyebabkan penderitaan bagi permintaan akan sumber daya
|
||||
dalam kapasitas Namespace yang lain, atau bisa juga kosong (atau `distinguisherMethod`
|
||||
dihilangkan seluruhnya), dalam hal ini semua permintaan yang cocok dengan FlowSchema ini akan
|
||||
dianggap sebagai bagian dari sebuah _flow_ tunggal. Pilihan yang tepat untuk FlowSchema yang diberikan
|
||||
akan bergantung pada sumber daya dan lingkungan khusus kamu.
|
||||
|
||||
## Diagnosis
|
||||
Setiap respons HTTP dari server API dengan fitur prioritas dan kesetaraan
|
||||
yang diaktifkan memiliki dua _header_ tambahan: `X-Kubernetes-PF-FlowSchema-UID` dan
|
||||
`X-Kubernetes-PF-PriorityLevel-UID`, yang mencatat skema _flow_ yang cocok dengan permintaan
|
||||
dan tingkat prioritas masing-masing. Name Objek API tidak termasuk dalam _header_ ini jika pengguna peminta tidak
|
||||
memiliki izin untuk melihatnya, jadi ketika melakukan _debugging_ kamu dapat menggunakan perintah seperti ini
|
||||
|
||||
```shell
|
||||
kubectl get flowschema -o custom-columns="uid:{metadata.uid},name:{metadata.name}"
|
||||
kubectl get prioritylevelconfiguration -o custom-columns="uid:{metadata.uid},name:{metadata.name}"
|
||||
```
|
||||
|
||||
untuk mendapatkan pemetaan UID ke names baik untuk FlowSchema maupun PriorityLevelConfiguration.
|
||||
|
||||
## Observabilitas
|
||||
Saat kamu mengaktifkan fitur Prioritas dan Kesetaraan API atau APF, kube-apiserver
|
||||
akan mengeluarkan metrik tambahan. Dengan memantau metrik ini dapat membantu kamu untuk menentukan apakah
|
||||
konfigurasi kamu tidak tepat dalam membatasi lalu lintas yang penting, atau menemukan
|
||||
beban kerja yang berperilaku buruk yang dapat membahayakan kesehatan dari sistem.
|
||||
|
||||
* `apiserver_flowcontrol_rejected_requests_total` menghitung permintaan yang
|
||||
ditolak, mengelompokkannya berdasarkan nama dari tingkat prioritas yang ditetapkan,
|
||||
nama FlowSchema yang ditetapkan, dan alasan penolakan tersebut.
|
||||
Alasan penolakan akan mengambil dari salah satu alasan-alasan berikut:
|
||||
* `queue-full`, yang mengindikasikan bahwa sudah terlalu banyak permintaan
|
||||
yang menunggu dalam antrian,
|
||||
* `concurrency-limit`, yang mengindikasikan bahwa PriorityLevelConfiguration
|
||||
telah dikonfigurasi untuk menolak, bukan untuk memasukan permintaan berlebih ke
|
||||
dalam antrian, atau
|
||||
* `time-out`, yang mengindikasikan bahwa permintaan masih dalam antrian
|
||||
ketika batas waktu antriannya telah berakhir.
|
||||
|
||||
* `apiserver_flowcontrol_dispatched_requests_total` menghitung permintaan
|
||||
yang sudah mulai dieksekusi, mengelompokkannya berdasarkan nama dari tingkat
|
||||
prioritas yang ditetapkan, dan nama dari FlowSchema yang ditetapkan.
|
||||
|
||||
* `apiserver_flowcontrol_current_inqueue_requests` memberikan
|
||||
jumlah total sesaat secara instan dari permintaan dalam antrian (bukan yang dieksekusi),
|
||||
dan mengelompokkannya berdasarkan tingkat prioritas dan FlowSchema.
|
||||
|
||||
* `apiserver_flowcontrol_current_executing_requests` memberikan
|
||||
jumlah total yang instan dari permintaan yang dieksekusi, dan mengelompokkannya
|
||||
berdasarkan tingkat prioritas dan FlowSchema.
|
||||
|
||||
* `apiserver_flowcontrol_request_queue_length_after_enqueue` memberikan
|
||||
histogram dari panjang antrian untuk semua antrian yang ada, mengelompokkannya berdasarkan
|
||||
tingkat prioritas dan FlowSchema, berdasarkan pengambilan sampel oleh permintaan
|
||||
_enqueued_. Setiap permintaan yang mendapatkan antrian berkontribusi ke satu sampel
|
||||
dalam histogramnya, pelaporan panjang antrian dilakukan setelah permintaan yang
|
||||
mengantri tersebut ditambahkan. Perlu dicatat bahwa ini akan menghasilkan statistik
|
||||
yang berbeda dengan survei yang tidak bias.
|
||||
{{< note >}}
|
||||
Nilai asing atau tidak biasa dalam histogram akan berarti ada kemungkinan sebuah _flow_
|
||||
(misalnya, permintaan oleh satu pengguna atau untuk satu _namespace_, tergantung pada
|
||||
konfigurasinya) telah membanjiri server API, dan sedang dicekik. Sebaliknya, jika
|
||||
histogram dari satu tingkat prioritas menunjukkan bahwa semua antrian dalam prioritas
|
||||
level itu lebih panjang daripada level prioritas yang lainnya, mungkin akan sesuai
|
||||
untuk meningkatkan _concurrency shares_ dari PriorityLevelConfiguration itu.
|
||||
{{< /note >}}
|
||||
|
||||
* `apiserver_flowcontrol_request_concurrency_limit` memberikan hasil perhitungan
|
||||
batas konkurensi (berdasarkan pada batas konkurensi total dari server API dan
|
||||
_concurrency share_ dari PriorityLevelConfiguration) untuk setiap
|
||||
PriorityLevelConfiguration.
|
||||
|
||||
* `apiserver_flowcontrol_request_wait_duration_seconds` memberikan histogram tentang bagaimana
|
||||
permintaan yang panjang dihabiskan dalam antrian, mengelompokkannya berdasarkan FlowSchema
|
||||
yang cocok dengan permintaan, tingkat prioritas yang ditetapkan, dan apakah permintaan
|
||||
tersebut berhasil dieksekusi atau tidak.
|
||||
{{< note >}}
|
||||
Karena setiap FlowSchema selalu memberikan permintaan untuk satu
|
||||
PriorityLevelConfiguration, kamu dapat menambahkan histogram untuk semua
|
||||
FlowSchema dalam satu tingkat prioritas untuk mendapatkan histogram yang efektif
|
||||
dari permintaan yang ditetapkan ke tingkat prioritas tersebut.
|
||||
{{< /note >}}
|
||||
|
||||
* `apiserver_flowcontrol_request_execution_seconds` memberikan histogram tentang bagaimana
|
||||
caranya permintaan yang panjang diambil untuk benar-benar dieksekusi, mengelompokkannya
|
||||
berdasarkan FlowSchema yang cocok dengan permintaan dan tingkat prioritas yang ditetapkan pada
|
||||
permintaan tersebut.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
Untuk latar belakang informasi mengenai detail desain dari prioritas dan kesetaraan API, silahkan lihat
|
||||
[proposal pembaharuan](https://github.com/kubernetes/enhancements/blob/master/keps/sig-api-machinery/20190228-priority-and-fairness.md).
|
||||
Kamu juga dapat membuat saran dan permintaan akan fitur melalui [SIG API
|
||||
Machinery](https://github.com/kubernetes/community/tree/master/sig-api-machinery).
|
||||
|
||||
{{% /capture %}}
|
||||
Loading…
Reference in New Issue