Skip to content

Commit 38db6f1

Browse files
authored
Merge pull request #24017 from girikuncoro/reserve-compute-id
Translate reserve compute resource page to Bahasa Indonesia
2 parents 64c015b + 557f95d commit 38db6f1

File tree

1 file changed

+231
-0
lines changed

1 file changed

+231
-0
lines changed
Lines changed: 231 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,231 @@
1+
---
2+
title: Melakukan Reservasi Sumber Daya Komputasi untuk Daemon Sistem
3+
content_type: task
4+
min-kubernetes-server-version: 1.8
5+
---
6+
7+
<!-- overview -->
8+
9+
Node Kubernetes dapat dijadwalkan sesuai dengan kapasitas. Secara bawaan, Pod dapat menggunakan
10+
semua kapasitas yang tersedia pada sebuah Node. Ini merupakan masalah karena Node
11+
sebenarnya menjalankan beberapa _daemon_ sistem yang diperlukan oleh OS dan Kubernetes itu sendiri.
12+
Jika sumber daya pada Node tidak direservasi untuk _daemon-daemon_ tersebut, maka
13+
Pod dan _daemon_ akan berlomba-lomba menggunakan sumber daya yang tersedia, sehingga
14+
menyebabkan _starvation_ sumber daya pada Node.
15+
16+
Fitur bernama `Allocatable` pada Node diekspos oleh kubelet yang berfungsi untuk melakukan
17+
reservasi sumber daya komputasi untuk _daemon_ sistem. Kubernetes merekomendasikan admin
18+
klaster untuk mengatur `Allocatable` pada Node berdasarkan tingkat kepadatan (_density_) beban kerja setiap Node.
19+
20+
21+
22+
## {{% heading "prerequisites" %}}
23+
24+
25+
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
26+
Kamu harus menjalankan Kubernetes server dengan versi 1.17 atau yang lebih baru
27+
untuk menggunakan perintah baris kubelet dengan opsi `--reserved-cpus` untuk
28+
menyetel [daftar reservasi CPU secara eksplisit](#melakukan-reservasi-daftar-cpu-secara-eksplisit).
29+
30+
31+
32+
<!-- steps -->
33+
34+
## _Allocatable_ pada Node
35+
36+
```text
37+
Kapasitas Node
38+
------------------------------
39+
| kube-reserved |
40+
|----------------------------|
41+
| system-reserved |
42+
|----------------------------|
43+
| eviction-threshold |
44+
| (batas pengusiran) |
45+
|----------------------------|
46+
| |
47+
| allocatable |
48+
| (dapat digunakan oleh Pod) |
49+
| |
50+
| |
51+
------------------------------
52+
```
53+
54+
`Allocatable` atau sumber daya yang dialokasikan pada sebuah Node Kubernetes merupakan
55+
jumlah sumber daya komputasi yang dapat digunakan oleh Pod. Penjadwal tidak
56+
dapat melakukan penjadwalan melebihi `Allocatable`. Saat ini dukungan terhadap
57+
`CPU`, `memory` dan `ephemeral-storage` tersedia.
58+
59+
`Allocatable` pada Node diekspos oleh objek API `v1.Node` dan merupakan
60+
bagian dari baris perintah `kubectl describe node`.
61+
62+
Sumber daya dapat direservasi untuk dua kategori _daemon_ sistem melalui kubelet.
63+
64+
### Mengaktifkan QoS dan tingkatan cgroup dari Pod
65+
66+
Untuk menerapkan batasan `Allocatable` pada Node, kamu harus mengaktifkan
67+
hierarki cgroup yang baru melalui _flag_ `--cgroups-per-qos`. Secara bawaan, _flag_ ini
68+
telah aktif. Saat aktif, kubelet akan memasukkan semua Pod pengguna di bawah
69+
sebuah hierarki cgroup yang dikelola oleh kubelet.
70+
71+
### Mengonfigurasi _driver_ cgroup
72+
73+
Manipulasi terhadap hierarki cgroup pada hos melalui _driver_ cgroup didukung oleh kubelet.
74+
_Driver_ dikonfigurasi melalui _flag_ `--cgroup-driver`.
75+
76+
Nilai yang didukung adalah sebagai berikut:
77+
78+
* `cgroupfs` merupakan _driver_ bawaan yang melakukan manipulasi secara langsung
79+
terhadap _filesystem_ cgroup pada hos untuk mengelola _sandbox_ cgroup.
80+
* `systemd` merupakan _driver_ alternatif yang mengelola _sandbox_ cgroup menggunakan
81+
bagian dari sumber daya yang didukung oleh sistem _init_ yang digunakan.
82+
83+
Tergantung dari konfigurasi _runtime_ Container yang digunakan,
84+
operator dapat memilih _driver_ cgroup tertentu untuk memastikan perilaku sistem yang tepat.
85+
Misalnya, jika operator menggunakan _driver_ cgroup `systemd` yang disediakan oleh
86+
_runtime_ docker, maka kubelet harus diatur untuk menggunakan _driver_ cgroup `systemd`.
87+
88+
### Kube Reserved
89+
90+
- **_Flag_ Kubelet**: `--kube-reserved=[cpu=100m][,][memory=100Mi][,][ephemeral-storage=1Gi][,][pid=1000]`
91+
- **_Flag_ Kubelet**: `--kube-reserved-cgroup=`
92+
93+
`kube-reserved` berfungsi untuk mengambil informasi sumber daya reservasi
94+
untuk _daemon_ sistem Kubernetes, seperti kubelet, _runtime_ Container, detektor masalah pada Node, dsb.
95+
`kube-reserved` tidak berfungsi untuk mereservasi sumber daya untuk _daemon_ sistem yang berjalan
96+
sebagai Pod. `kube-reserved` merupakan fungsi dari kepadatan Pod pada Node.
97+
98+
Selain dari `cpu`, `memory`, dan `ephemeral-storage`,`pid` juga dapat
99+
diatur untuk mereservasi jumlah ID proses untuk _daemon_ sistem Kubernetes.
100+
101+
Secara opsional, kamu dapat memaksa _daemon_ sistem melalui setelan `kube-reserved`.
102+
Ini dilakukan dengan menspesifikasikan _parent_ cgroup sebagai nilai dari _flag_ `--kube-reserved-cgroup` pada kubelet.
103+
104+
Kami merekomendasikan _daemon_ sistem Kubernetes untuk ditempatkan pada
105+
tingkatan cgroup yang tertinggi (contohnya, `runtime.slice` pada mesin systemd).
106+
Secara ideal, setiap _daemon_ sistem sebaiknya dijalankan pada _child_ cgroup
107+
di bawah _parent_ ini. Lihat [dokumentasi](https://git.k8s.io/community/contributors/design-proposals/node/node-allocatable.md#recommended-cgroups-setup)
108+
untuk mengetahui rekomendasi hierarki cgroup secara detail.
109+
110+
Catatan: kubelet **tidak membuat** `--kube-reserved-cgroup` jika cgroup
111+
yang diberikan tidak ada pada sistem. Jika cgroup yang tidak valid diberikan,
112+
maka kubelet akan mengalami kegagalan.
113+
114+
### System Reserved
115+
116+
- **_Flag_ Kubelet**: `--system-reserved=[cpu=100m][,][memory=100Mi][,][ephemeral-storage=1Gi][,][pid=1000]`
117+
- **_Flag_ Kubelet**: `--system-reserved-cgroup=`
118+
119+
120+
`system-reserved` berfungsi untuk mengetahui reservasi sumber daya untuk
121+
_daemon_ sistem pada OS, seperti `sshd`, `udev`, dan lainnya. `system-reserved` sebaiknya
122+
mereservasi memori untuk kernel juga, karena memori kernel tidak termasuk dalam
123+
hitungan kalkulasi Pod pada Kubernetes. Kami juga merekomendasikan reservasi sumber daya
124+
untuk sesi (_session_) login pengguna (contohnya, `user.slice` di dalam dunia systemd).
125+
126+
### Melakukan Reservasi Daftar CPU secara Eksplisit
127+
{{< feature-state for_k8s_version="v1.17" state="stable" >}}
128+
129+
- **_Flag_ Kubelet**: `--reserved-cpus=0-3`
130+
131+
`reserved-cpus` berfungsi untuk mendefinisikan [cpuset](https://www.kernel.org/doc/Documentation/cgroup-v1/cpusets.txt) secara eksplisit untuk
132+
_daemon_ sistem OS dan _daemon_ sistem Kubernetes. `reserved-cpus` dimaksudkan untuk
133+
sistem-sistem yang tidak mendefinisikan tingkatan cgroup tertinggi secara terpisah untuk
134+
_daemon_ sistem OS dan _daemon_ sistem Kubernetes yang berkaitan dengan sumber daya cpuset.
135+
136+
Jika kubelet **tidak memiliki** `--system-reserved-cgroup` dan `--kube-reserved-cgroup`,
137+
cpuset akan diberikan secara eksplisit oleh `reserved-cpus`, yang akan menimpa definisi
138+
yang diberikan oleh opsi `--kube-reserved` dan `--system-reserved`.
139+
140+
Opsi ini dirancang secara spesifik untuk kasus-kasus Telco/NFV, di mana _interrupt_ atau _timer_
141+
yang tidak terkontrol bisa memengaruhi performa dari beban kerja. Kamu dapat menggunakan
142+
opsi untuk untuk mendefinisikan cpuset secara eksplisit untuk _daemon_ sistem/Kubernetes dan
143+
_interrupt_/_timer_, sehingga CPU sisanya dalam sistem akan digunakan untuk beban kerja saja,
144+
dengan dampak yang sedikit terhadap _interrupt_/_timer_ yang tidak terkontrol. Untuk
145+
memindahkan _daemon_ sistem, _daemon_ Kubernetes serta _interrrupt_/_timer_ Kubernetes supaya
146+
menggunakan cpuset yang eksplisit didefinisikan oleh opsi ini, sebaiknya digunakan mekanisme lain di luar Kubernetes. Contohnya: pada Centos, kamu dapat melakukan ini dengan menggunakan
147+
toolset yang sudah disetel.
148+
149+
### Batas Pengusiran (_Eviction Threshold_)
150+
151+
- **_Flag_ Kubelet**: `--eviction-hard=[memory.available<500Mi]`
152+
153+
Tekanan memori pada tingkatan Node menyebabkan sistem OOM (_Out Of Memory_) yang
154+
berdampak pada Node secara keseluruhan dan semua Pod yang dijalankan di dalamnya.
155+
Node dapat berubah menjadi _offline_ sementara sampai memori berhasil diklaim kembali.
156+
Untuk menghindari sistem OOM, atau mengurangi kemungkinan terjadinya OOM, kubelet
157+
menyediakan fungsi untuk pengelolaan saat [Kehabisan Sumber Daya (_Out of Resource_)](/docs/tasks/administer-cluster/out-of-resource/).
158+
Pengusiran dapat dilakukan hanya untuk kasus kehabisan `memory` dan `ephemeral-storage`. Dengan mereservasi
159+
sebagian memori melalui _flag_ `--eviction-hard`, kubelet akan berusaha untuk "mengusir" (_evict_)
160+
Pod ketika ketersediaan memori pada Node jatuh di bawah nilai yang telah direservasi.
161+
Dalam bahasa sederhana, jika _daemon_ sistem tidak ada pada Node, maka Pod tidak dapat menggunakan
162+
memori melebihi nilai yang ditentukan oleh _flag_ `--eviction-hard`. Karena alasan ini,
163+
sumber daya yang direservasi untuk pengusiran tidak tersedia untuk Pod.
164+
165+
### Memaksakan _Allocatable_ pada Node
166+
167+
- **_Flag_ Kubelet**: `--enforce-node-allocatable=pods[,][system-reserved][,][kube-reserved]`
168+
169+
Penjadwal menganggap `Allocatable` sebagai kapasitas yang tersedia untuk digunakan oleh Pod.
170+
171+
Secara bawaan, kubelet memaksakan `Allocatable` untuk semua Pod. Pemaksaan dilakukan
172+
dengan cara "mengusir" Pod-Pod ketika penggunaan sumber daya Pod secara keseluruhan telah
173+
melewati nilai `Allocatable`. Lihat [bagian ini](/docs/tasks/administer-cluster/out-of-resource/#eviction-policy)
174+
untuk mengetahui kebijakan pengusiran secara detail. Pemaksaan ini dikendalikan dengan
175+
cara memberikan nilai Pod melalui _flag_ `--enforce-node-allocatable` pada kubelet.
176+
177+
Secara opsional, kubelet dapat diatur untuk memaksakan `kube-reserved` dan
178+
`system-reserved` dengan memberikan nilai melalui _flag_ tersebut. Sebagai catatan,
179+
jika kamu mengatur `kube-reserved`, maka kamu juga harus mengatur `--kube-reserved-cgroup`. Begitu pula
180+
jika kamu mengatur `system-reserved`, maka kamu juga harus mengatur `--system-reserved-cgroup`.
181+
182+
## Panduan Umum
183+
184+
_Daemon_ sistem dilayani mirip seperti Pod `Guaranteed` yang terjamin sumber dayanya.
185+
_Daemon_ sistem dapat melakukan _burst_ di dalam jangkauan cgroup. Perilaku ini
186+
dikelola sebagai bagian dari penggelaran (_deployment_) Kubernetes. Sebagai contoh,
187+
kubelet harus memiliki cgroup sendiri dan membagikan sumber daya `kube-reserved` dengan
188+
_runtime_ Container. Namun begitu, kubelet tidak dapat melakukan _burst_ dan menggunakan
189+
semua sumber daya yang tersedia pada Node jika `kube-reserved` telah dipaksakan pada sistem.
190+
191+
Kamu harus berhati-hati ekstra ketika memaksakan reservasi `system-reserved` karena dapat
192+
menyebabkan layanan sistem yang terpenting mengalami CPU _starvation_, OOM _killed_, atau tidak
193+
dapat melakukan _fork_ pada Node. Kami menyarankan untuk memaksakan `system-reserved` hanya
194+
jika pengguna telah melakukan _profiling_ sebaik mungkin pada Node mereka untuk
195+
mendapatkan estimasi yang akurat dan percaya diri terhadap kemampuan mereka untuk
196+
memulihkan sistem ketika ada grup yang terkena OOM _killed_.
197+
198+
* Untuk memulai, paksakan `Allocatable` pada Pod.
199+
* Ketika _monitoring_ dan _alerting_ telah cukup dilakukan untuk memonitor _daemon_
200+
dari sistem Kubernetes, usahakan untuk memaksakan `kube-reserved` berdasarkan penggunakan heuristik.
201+
* Jika benar-benar diperlukan, paksakan `system-reserved` secara bertahap.
202+
203+
Sumber daya yang diperlukan oleh _daemon_ sistem Kubernetes dapat tumbuh seiring waktu dengan
204+
adanya penambahan fitur-fitur baru. Proyek Kubernetes akan berusaha untuk menurunkan penggunaan sumber daya
205+
dari _daemon_ sistem Node, tetapi belum menjadi prioritas untuk saat ini.
206+
Kamu dapat berekspektasi bahwa fitur kapasitas `Allocatable` ini akan dihapus pada versi yang akan datang.
207+
208+
209+
210+
<!-- discussion -->
211+
212+
## Contoh Skenario
213+
214+
Berikut ini merupakan contoh yang menggambarkan komputasi `Allocatable` pada Node:
215+
216+
* Node memiliki 16 CPU, memori sebesar 32Gi, dan penyimpanan sebesar 100Gi.
217+
* `--kube-reserved` diatur menjadi `cpu=1,memory=2Gi,ephemeral-storage=1Gi`
218+
* `--system-reserved` diatur menjadi `cpu=500m,memory=1Gi,ephemeral-storage=1Gi`
219+
* `--eviction-hard` diatur menjadi `memory.available<500Mi,nodefs.available<10%`
220+
221+
Dalam skenario ini, `Allocatable` akan menjadi 14.5 CPU, memori 28.5Gi, dan penyimpanan
222+
lokal 88Gi.
223+
Penjadwal memastikan bahwa semua Pod yang berjalan pada Node ini secara total tidak meminta memori melebihi
224+
28.5Gi dan tidak menggunakan penyimpanan lokal melebihi 88Gi.
225+
Pengusiran Pod akan dilakukan kubelet ketika penggunaan memori keseluruhan oleh Pod telah melebihi 28.5Gi,
226+
atau jika penggunaan penyimpanan keseluruhan telah melebihi 88Gi. Jika semua proses pada Node mengonsumsi
227+
CPU sebanyak-banyaknya, Pod-Pod tidak dapat mengonsumsi lebih dari 14.5 CPU.
228+
229+
Jika `kube-reserved` dan/atau `system-reserved` tidak dipaksakan dan _daemon_ sistem
230+
melebihi reservasi mereka, maka kubelet akan mengusir Pod ketika penggunaan memori pada Node
231+
melebihi 31.5Gi atau penggunaan penyimpanan melebihi 90Gi.

0 commit comments

Comments
 (0)