Change kluster to klaster mentioned in https://github.com/jk8s/sig-docs-id/issues/20 (#18130)
This commit is contained in:
irvifa
committed by
Kubernetes Prow Robot
Kubernetes Prow Robot
parent
a7f6a78d55
commit
39fe327423
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: Memperluas Kluster Kubernetes Kamu
|
||||
title: Memperluas Klaster Kubernetes Kamu
|
||||
content_template: templates/concept
|
||||
weight: 10
|
||||
---
|
||||
@@ -9,9 +9,9 @@ weight: 10
|
||||
Kubernetes sangat mudah dikonfigurasi dan diperluas. Sehingga,
|
||||
jarang membutuhkan _fork_ atau menambahkan _patch_ ke kode proyek Kubernetes.
|
||||
|
||||
Panduan ini menjelaskan pilihan untuk menyesuaikan kluster Kubernetes.
|
||||
Dokumen ini ditujukan kepada {{< glossary_tooltip text="operator kluster" term_id="cluster-operator" >}} yang ingin
|
||||
memahami bagaimana menyesuaikan kluster Kubernetes dengan kebutuhan lingkungan kerja mereka.
|
||||
Panduan ini menjelaskan pilihan untuk menyesuaikan klaster Kubernetes.
|
||||
Dokumen ini ditujukan kepada {{< glossary_tooltip text="operator klaster" term_id="cluster-operator" >}} yang ingin
|
||||
memahami bagaimana menyesuaikan klaster Kubernetes dengan kebutuhan lingkungan kerja mereka.
|
||||
|
||||
Developer yang prospektif {{< glossary_tooltip text="Developer Platform" term_id="platform-developer" >}} atau {{< glossary_tooltip text="Kontributor" term_id="contributor" >}} Proyek Kubernetes juga mendapatkan manfaat dari
|
||||
dokumen ini sebagai pengantar apa saja poin-poin dan pola-pola perluasan yang ada, untung-rugi, dan batasan-batasannya.
|
||||
@@ -34,26 +34,26 @@ _Flag-flag_ dan _berkas-berkas konfigurasi_ didokumentasikan di bagian Referensi
|
||||
* [kube-controller-manager](/docs/admin/kube-controller-manager/)
|
||||
* [kube-scheduler](/docs/admin/kube-scheduler/).
|
||||
|
||||
_Flag-flag_ dan berkas-berkas konfigurasi mungkin tidak selalu dapat diubah pada layanan Kubernetes yang _hosted_ atau pada distribusi dengan instalasi yang dikelola. Ketika mereka dapat diubah, mereka biasanya hanya dapat diubah oleh Administrator Kluster. Dan juga, mereka dapat sewaktu-waktu diubah dalam versi Kubernetes di masa depan, dan menyetel mereka mungkin memerlukan proses pengulangan kembali. Oleh karena itu, mereka harus digunakan hanya ketika tidak ada pilihan lain.
|
||||
_Flag-flag_ dan berkas-berkas konfigurasi mungkin tidak selalu dapat diubah pada layanan Kubernetes yang _hosted_ atau pada distribusi dengan instalasi yang dikelola. Ketika mereka dapat diubah, mereka biasanya hanya dapat diubah oleh Administrator Klaster. Dan juga, mereka dapat sewaktu-waktu diubah dalam versi Kubernetes di masa depan, dan menyetel mereka mungkin memerlukan proses pengulangan kembali. Oleh karena itu, mereka harus digunakan hanya ketika tidak ada pilihan lain.
|
||||
|
||||
*API kebijakan bawaan*, seperti [ResourceQuota](/docs/concepts/policy/resource-quotas/), [PodSecurityPolicy](/docs/concepts/policy/pod-security-policy/), [NetworkPolicy](/docs/concepts/services-networking/network-policies/) dan Role-based Access Control ([RBAC](/docs/reference/access-authn-authz/rbac/)), adalah API bawaan Kubernetes. API biasanya digunakan oleh layanan Kubernetes yang _hosted_ dan diatur oleh instalasi Kubernetes. Mereka bersifat deklaratif dan menggunakan konvensi yang sama dengan sumber daya Kubernetes lainnya seperti pod-pod, jadi konfigurasi kluster baru dapat diulang-ulang dan dapat diatur dengan cara yang sama dengan aplikasi. Dan, ketika mereka stabil, mereka mendapatkan keuntungan dari [kebijakan pendukung yang jelas](/docs/reference/deprecation-policy/) seperti API Kubernetes lainnya. Oleh karena itu, mereka lebih disukai daripada _berkas konfigurasi_ dan _flag-flag_ saat mereka cocok dengan situasi yang dibutuhkan.
|
||||
*API kebijakan bawaan*, seperti [ResourceQuota](/docs/concepts/policy/resource-quotas/), [PodSecurityPolicy](/docs/concepts/policy/pod-security-policy/), [NetworkPolicy](/docs/concepts/services-networking/network-policies/) dan Role-based Access Control ([RBAC](/docs/reference/access-authn-authz/rbac/)), adalah API bawaan Kubernetes. API biasanya digunakan oleh layanan Kubernetes yang _hosted_ dan diatur oleh instalasi Kubernetes. Mereka bersifat deklaratif dan menggunakan konvensi yang sama dengan sumber daya Kubernetes lainnya seperti pod-pod, jadi konfigurasi klaster baru dapat diulang-ulang dan dapat diatur dengan cara yang sama dengan aplikasi. Dan, ketika mereka stabil, mereka mendapatkan keuntungan dari [kebijakan pendukung yang jelas](/docs/reference/deprecation-policy/) seperti API Kubernetes lainnya. Oleh karena itu, mereka lebih disukai daripada _berkas konfigurasi_ dan _flag-flag_ saat mereka cocok dengan situasi yang dibutuhkan.
|
||||
|
||||
## Perluasan
|
||||
|
||||
Perluasan adalah komponen perangkat lunak yang memperluas dan berintegrasi secara mendalam dengan Kubernetes.
|
||||
Mereka mengadaptasi Kubernetes untuk mendukung perangkat keras tipe baru dan jenis baru.
|
||||
|
||||
Kebanyakan administrator kluster akan menggunakan instansi Kubernetes yang didistribusikan atau yang _hosted_.
|
||||
Kebanyakan administrator klaster akan menggunakan instansi Kubernetes yang didistribusikan atau yang _hosted_.
|
||||
Sebagai hasilnya, kebanyakan pengguna Kubernetes perlu menginstal perluasan dan lebih sedikit yang perlu untuk membuat perluasan-perluasan yang baru.
|
||||
|
||||
## Pola-pola Perluasan
|
||||
|
||||
Kubernetes didesain untuk dapat diotomasi dengan menulis program-program klien. Program apapun yang membaca dan/atau menulis ke API Kubernetes dapat menyediakan otomasi yang berguna.
|
||||
|
||||
*Otomasi* dapat berjalan di dalam kluster atau di luar kluster. Dengan mengikuti panduan
|
||||
*Otomasi* dapat berjalan di dalam klaster atau di luar klaster. Dengan mengikuti panduan
|
||||
di dalam dokumen ini, kamu dapat menulis otomasi yang sangat tersedia dan kuat.
|
||||
Otomasi pada umumnya dapat bekerja dengan berbagai macam kluster Kubernetes, termasuk
|
||||
kluster yang _hosted_ dan instalasi yang dikelola.
|
||||
Otomasi pada umumnya dapat bekerja dengan berbagai macam klaster Kubernetes, termasuk
|
||||
klaster yang _hosted_ dan instalasi yang dikelola.
|
||||
|
||||
Ada pola spesifik untuk menulis program klien yang bekerja dengan baik bersama Kubernetes yang disebut pola _Controller_. _Controller-controller_ biasanya membaca kolom `.spec` milik sebuah objek, kemungkinan melakukan sesuatu, dan kemudian memperbarui objek milik `.status`.
|
||||
|
||||
@@ -86,7 +86,7 @@ Diagram berikut menunjukkan titik-titik perluasan di sebuah Kubernetes.
|
||||
3. apiserver melayani berbagai macam sumber daya, _tipe-tipe sumber daya bawaan_, seperti `pod`, didefinisikan oleh proyek kubernetes dan tidak dapat diubah. kamu juga dapat menambahkan sumber daya yang kamu definisikan sendiri, atau yang proyek lain definisikan, disebut _Custom Resources_, seperti dijelaskan di bagian [Sumber Daya _Custom_](/docs/concepts/overview/extending#tipe-tipe-yang-ditentukan-pengguna). Sumber daya _Custom_ sering digunakan dengan Perluasan Akses API.
|
||||
4. Penjadwal Kubernetes memutuskan ke Node mana Pod akan ditempatkan. Ada beberapa cara untuk memperluas penjadwalan. Hal ini dibahas pada bagian [Perluasan-perluasan Penjadwal](/docs/concepts/overview/extending#perluasan-perluasan-penjadwal).
|
||||
5. Sebagian besar perilaku Kubernetes diimplementasi oleh program yang disebut *Controller-controller* yang merupakan klien dari API-Server. *Controller-controller* sering digunakan bersama dengan Sumber Daya _Custom_.
|
||||
6. Kubelet berjalan di server, dan membantu Pod-pod terlihat seperti server virtual dengan IP mereka sendiri di jaringan kluster. [_Plugin_ Jaringan](/docs/concepts/overview/extending#plugin-plugin-jaringan) memungkinkan adanya perbedaan implementasi pada jaringan Pod.
|
||||
6. Kubelet berjalan di server, dan membantu Pod-pod terlihat seperti server virtual dengan IP mereka sendiri di jaringan klaster. [_Plugin_ Jaringan](/docs/concepts/overview/extending#plugin-plugin-jaringan) memungkinkan adanya perbedaan implementasi pada jaringan Pod.
|
||||
7. Kubelet juga melakukan penambatan dan pelepasan tambatan volume untuk kontainer. Tipe-tipe penyimpanan baru dapat didukung via [_Plugin_ Penyimpanan](/docs/concepts/overview/extending#plugin-plugin-penyimpanan).
|
||||
|
||||
Jika kamu tidak yakin untuk memulai dari mana, diagram alir di bawah ini dapat membantu kamu. Ingat lah bahwa beberapa solusi mungkin melibatkan beberapa tipe perluasan.
|
||||
|
||||
+6
-6
@@ -17,7 +17,7 @@ Penjadwal Poseidon-Firmament adalah penjadwal alternatif yang dapat digunakan be
|
||||
|
||||
## Pengenalan
|
||||
|
||||
Poseidon adalah sebuah layanan yang berperan sebagai pemersatu antara [Penjadwal Firmament](https://github.com/Huawei-PaaS/firmament) dengan Kubernetes. Penjadwal Poseidon-Firmament menambah kapabilitas penjadwal Kubernetes saat ini. Penjadwal ini menggabungkan kemampuan penjadwalan berbasis grafik jaringan grafis (_flow network graph_) baru bersama penjadwal Kubernetes bawaan. Penjadwal Firmament memodelkan beban-beban kerja dan kluster-kluster sebagai jaringan aliran dan menjalankan optimisasi aliran biaya-minimum kepada jaringan ini untuk membuat keputusan penjadwalan.
|
||||
Poseidon adalah sebuah layanan yang berperan sebagai pemersatu antara [Penjadwal Firmament](https://github.com/Huawei-PaaS/firmament) dengan Kubernetes. Penjadwal Poseidon-Firmament menambah kapabilitas penjadwal Kubernetes saat ini. Penjadwal ini menggabungkan kemampuan penjadwalan berbasis grafik jaringan grafis (_flow network graph_) baru bersama penjadwal Kubernetes bawaan. Penjadwal Firmament memodelkan beban-beban kerja dan klaster-klaster sebagai jaringan aliran dan menjalankan optimisasi aliran biaya-minimum kepada jaringan ini untuk membuat keputusan penjadwalan.
|
||||
|
||||
Penjadwal ini memodelkan masalah penjadwalan sebagai optimasi berbasis batasan atas grafik jaringan aliran. Hal ini dicapai dengan mengurangi penjadwalan ke masalah optimisasi biaya-minimum aliran-maksimum. Penjadwal Poseidon-Firmament secara dinamis memperbaiki penempatan beban kerja.
|
||||
|
||||
@@ -28,8 +28,8 @@ Penjadwal Poseidon-Firmament berjalan bersamaan dengan penjadwal Kubernetes bawa
|
||||
### Penjadwalan grafik jaringan (_network graph_) berbasis penjadwalan Poseidon-Firmament memberikan beberapa keuntungan utama sebagai berikut:
|
||||
|
||||
- Beban kerja (Pod) dijadwalkan secara kolektif untuk memungkinkan penjadwalan dalam skala besar.
|
||||
- Berdasarkan hasil tes kinerja yang ekstensif, skala Poseidon-Firmament jauh lebih baik daripada penjadwal bawaan Kubernetes dilihat dari jumlah node meningkat dalam sebuah kluster. Hal ini disebabkan oleh fakta bahwa Poseidon-Firmament mampu mengamortisasi lebih banyak pekerjaan di seluruh beban kerja.
|
||||
- Penjadwal Poseidon-Firmament mengungguli penjadwal bawaan Kubernetes dengan margin lebar ketika menyangkut jumlah kinerja _throughput_ untuk skenario di mana kebutuhan sumber daya komputasi agak seragam di seluruh pekerjaan (Replicaset / Deployment / Job). Angka kinerja _throughput_ _end-to-end_ penjadwal Poseidon-Firmament , termasuk waktu _bind_, secara konsisten menjadi lebih baik seiring jumlah Node dalam sebuah kluster meningkat. Misalnya, untuk kluster 2.700 Node (ditampilkan dalam grafik [di sini](https://github.com/kubernetes-sigs/poseidon/blob/master/docs/benchmark/README.md)), penjadwal Poseidon-Firmament berhasil mencapai 7X atau lebih _throughput_ _end-to-end_ yang lebih besar dibandingkan dengan penjadwal bawaan Kubernetes, yang mencakup waktu _bind_.
|
||||
- Berdasarkan hasil tes kinerja yang ekstensif, skala Poseidon-Firmament jauh lebih baik daripada penjadwal bawaan Kubernetes dilihat dari jumlah node meningkat dalam sebuah klaster. Hal ini disebabkan oleh fakta bahwa Poseidon-Firmament mampu mengamortisasi lebih banyak pekerjaan di seluruh beban kerja.
|
||||
- Penjadwal Poseidon-Firmament mengungguli penjadwal bawaan Kubernetes dengan margin lebar ketika menyangkut jumlah kinerja _throughput_ untuk skenario di mana kebutuhan sumber daya komputasi agak seragam di seluruh pekerjaan (Replicaset / Deployment / Job). Angka kinerja _throughput_ _end-to-end_ penjadwal Poseidon-Firmament , termasuk waktu _bind_, secara konsisten menjadi lebih baik seiring jumlah Node dalam sebuah klaster meningkat. Misalnya, untuk klaster 2.700 Node (ditampilkan dalam grafik [di sini](https://github.com/kubernetes-sigs/poseidon/blob/master/docs/benchmark/README.md)), penjadwal Poseidon-Firmament berhasil mencapai 7X atau lebih _throughput_ _end-to-end_ yang lebih besar dibandingkan dengan penjadwal bawaan Kubernetes, yang mencakup waktu _bind_.
|
||||
- Tersedianya pembatasan aturan yang kompleks.
|
||||
- Penjadwalan dalam Poseidon-Firmament bersifat dinamis; ini membuat sumber daya klaster dalam keadaan optimal secara global selama setiap berjalannya penjadwalan.
|
||||
- Pemanfaatan sumber daya yang sangat efisien.
|
||||
@@ -53,7 +53,7 @@ Untuk detail tentang desain proyek ini, lihat [dokumen desain](https://github.co
|
||||
|
||||
## Kemungkinan Skenario Kasus Penggunaan - Kapan menggunakannya
|
||||
|
||||
Seperti yang disebutkan sebelumnya, penjadwal Poseidon-Firmament memungkinkan lingkungan penjadwalan dengan _throughput_ yang sangat tinggi bahkan pada ukuran kluster dengan beban kerja besar, dikarenakan pendekatan penjadwalannya yang sekaligus dalam jumlah besar, dibandingkan dengan pendekatan bawaan _pod-at-a-time_ Kubernetes. Dalam pengujian ekstensif kami, kami telah mengamati manfaat _throughput_ substansial selama kebutuhan sumber daya (CPU / Memori) untuk Pod yang masuk seragam di seluruh tugas (Replicaset / Deployment / Job), terutama karena amortisasi pekerjaan yang efisien di seluruh tugas.
|
||||
Seperti yang disebutkan sebelumnya, penjadwal Poseidon-Firmament memungkinkan lingkungan penjadwalan dengan _throughput_ yang sangat tinggi bahkan pada ukuran klaster dengan beban kerja besar, dikarenakan pendekatan penjadwalannya yang sekaligus dalam jumlah besar, dibandingkan dengan pendekatan bawaan _pod-at-a-time_ Kubernetes. Dalam pengujian ekstensif kami, kami telah mengamati manfaat _throughput_ substansial selama kebutuhan sumber daya (CPU / Memori) untuk Pod yang masuk seragam di seluruh tugas (Replicaset / Deployment / Job), terutama karena amortisasi pekerjaan yang efisien di seluruh tugas.
|
||||
|
||||
Meskipun penjadwal Poseidon-Firmament mampu menjadwalkan berbagai jenis beban kerja, seperti layanan-layanan, _batch_, dll., berikut ini adalah beberapa kasus penggunaan yang paling unggul:
|
||||
|
||||
@@ -85,14 +85,14 @@ Meskipun penjadwal Poseidon-Firmament mampu menjadwalkan berbagai jenis beban ke
|
||||
| Dukungan untuk Penjadwalan Volume Persisten Pra-terikat | Y | Y ||
|
||||
| Dukungan untuk Volume Lokal & Penjadwalan _Binding_ Volume Persisten Dinamis | Y | N** | Direncanakan. |
|
||||
| Ketersediaan Tinggi | Y | N** | Direncanakan. |
|
||||
| Penjadwalan berbasis metrik _real-time_ | N | Y** | Awalnya didukung menggunakan Heapster (sekarang tidak digunakan lagi) untuk menempatkan Pod menggunakan statistik penggunaan kluster aktual ketimbang reservasi. Rencananya akan dialihkan ke "server metrik". |
|
||||
| Penjadwalan berbasis metrik _real-time_ | N | Y** | Awalnya didukung menggunakan Heapster (sekarang tidak digunakan lagi) untuk menempatkan Pod menggunakan statistik penggunaan klaster aktual ketimbang reservasi. Rencananya akan dialihkan ke "server metrik". |
|
||||
| Dukungan untuk _Max-Pod_ per Node | Y | Y | Penjadwal Poseidon-Firmament secara mulus berdampingan dengan penjadwal bawaan Kubernetes.
|
||||
| Dukungan untuk Penyimpanan _Ephemeral_, selain CPU / Memori | Y | Y ||
|
||||
|
||||
|
||||
## Instalasi
|
||||
|
||||
Untuk instalasi Poseidon dalam-kluster, silakan mulai dari [Petunjuk Instalasi](https://github.com/kubernetes-sigs/poseidon/blob/master/docs/install/README.md).
|
||||
Untuk instalasi Poseidon dalam-klaster, silakan mulai dari [Petunjuk Instalasi](https://github.com/kubernetes-sigs/poseidon/blob/master/docs/install/README.md).
|
||||
|
||||
## Pengembangan
|
||||
|
||||
|
||||
Reference in New Issue
Block a user