kubernetes
/
website
mirror of https://github.com/kubernetes/website.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

Merge pull request #45919 from sftim/20240418_drop_federation_id 

Drop vestigial Federation page (Bahasa Indonesia)
pull/46061/head
Kubernetes Prow Robot 2024-04-28 20:11:19 -07:00 committed by GitHub
parent 06eb7df946 80433133be
commit e1ca4c8a46
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
1 changed files with 0 additions and 196 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

196
content/id/docs/concepts/cluster-administration/federation.md
View File

@ -1,196 +0,0 @@
---
title: Federation
content_type: concept
weight: 80
---
<!-- overview -->
{{< deprecationfilewarning >}}
{{< include "federation-deprecation-warning-note.md" >}}
{{< /deprecationfilewarning >}}
Laman ini menjelaskan alasan dan cara penggunaan _federation_ untuk melakukan manajemen
klaster Kubernetes.
<!-- body -->
## Kenapa _Federation_ ?
_Federation_ membuat proses manajemen klaster multipel menjadi lebih mudah.
_Federation_ mencapai hal ini dengan cara menyediakan 2 buah fondasi:
* Melakukan sinkronisasi _resource_ di seluruh klaster: _Federation_
menyediakan kemampuan untuk melakukan sinkronisasi _resources_ pada _multiple_
klaster. Sebagai contoh, kamu dapat memastikan _Deployment_ yang sama
tersedia pada klaster multipel.
* _Cross_ _cluster_ _Discovery_: _Federation_ menyediakan kemampuan untuk melakukan
konfigurasi otomatis server DNS dan _load balancer_ dari semua klaster.
Misalnya, kamu dapat memastikan bahwa sebuah VIP atau DNS global dapat digunakan
untuk mengakses _backend_ dari klaster multipel.
Beberapa penggunaan _federation_ adalah sebagai berikut:
* _High Availability_: Melakukan _load balance_ di seluruh klaster serta
melakukan konfigurasi otomatis server DNS dan _load balancer_, _federation_
meminimalisasi dampak yang terjadi apabila terjadi kegagalan klaster.
* Mencegah _lock-in_ yang terjadi akibat penyedia layanan: Dengan cara mempermudah
proses migrasi antar klaster.
Manfaat _federation_ tidak akan terlalu kelihatan kecuali kamu memiliki beberapa klaster.
Beberapa alasan kenapa kamu butuh beberapa klaster adalah:
* _Latency_ yang rendah: Memiliki klaster yang berada di _region_ yang berbeda
meminimalisasi _latency_ dengan cara menyajikan konten ke pengguna
berdasarkan _region_ yang paling dekat dengan pengguna tersebut.
* Isolasi _fault_: Akan lebih baik apabila kita memiliki beberapa klaster kecil
dibandingkan sebuah klaster besar untuk melakukan isolasi _fault_ (misalnya saja
klaster ini bisa saja berada di _availability_ zona dan penyedia layanan _cloud_
yang berbeda).
* Skalabilitas: Terdapat batasan skalabilitas untuk sebuah klaster Kubernetes,
hal ini sebenarnya tidak menjadi masalah bagi sebagian besar pengguna. Untuk informasi
lebih lanjut kamu bisa membaca
[_Kubernetes Scaling_ dan Perencanaan Performa](https://git.k8s.io/community/sig-scalability/goals.md)).
* [_Hybrid cloud_](#hybrid-cloud-capabilities): Kamu dapat memiliki _multiple_ klsuter
pada penyedia layanan _cloud_ yang berbeda ataupun menggunakan _on-premsie_.
### Kekurangan
Meskipun terdapat banyak kelebihan dari penggunaan _federation_,
terdapat beberapa kekurangan _federation_ yang dijabarkan sebagai berikut:
* Peningkatan _bandwidth_ dan biaya untuk jaringan: _control plane_ _federation_ bertugas mengawasi semua
kulster yang ada untuk menjamin _state_ yang ada saat ini sesuai dengan _state_ yang diinginkan. Hal ini dapat menyebabkan
peningkatan biaya jaringan apabila klaster yang ada dijalankan pada _region_ yang berbeda baik pada penyedia
layanan _cloud_ yang sama maupun berbeda.
* Berkurangnya isolasi antar klaster: Sebuah _bug_ yang ada pada _control plane_ _federation_ dapat
berdampak pada semua klaster. Hal ini dapat dihindari dengan cara mejaga logika yang ada pada _control plane_ _federation_
seminimum mungkin.
* Kematangan: Proyek _federation_ ini tergolong baru dan belum cukup matang.
Tidak semua _resource_ yang ada tersedia dan masih banyak feature _alpha_. [_Issue_
88](https://github.com/kubernetes/federation/issues/88) memberikan detail
isu-isu terkait sistem yang masih berusaha dicari solusinya.
### Kemampuan _Hybrid_ Penggunaan Layanan Penyedian _Cloud_
_Federation_ pada Kubernetes memungkinkan klaster untuk dijalankan
pada penyedia layanan _cloud_ yang berbeda (misalnya Google Cloud, AWS), dan _on-premise_
(misalnya OpenStack). [Kubefed](/docs/tasks/federation/set-up-cluster-federation-kubefed/)
adalah salah satu cara yang direkomendasikan untuk melakukan proses _deploy_
klaster _federation_.
Dengan demikian, [_resources_ API](#resources-api) yang kamu miliki
dapat berada di klaster atau bahkan penyedia layanan _cloud_ yang berbeda.
## Mengaktifkan _Federation_
Untuk bisa melakukan _federation_ pada klaster yang berbeda,
pertama kamu harus mengaktifkan _control plane_ _federation_.
Ikuti [petunjuk mengaktifkan _control plane_ _federation_](/docs/tutorials/federation/set-up-cluster-federation-kubefed/)
untuk informasi lebih lanjut.
## `Resources` API
Setelah kamu mengaktifkan _control plane_, kamu dapat menggunakan _resource_ API _federation_.
Berikut merupakan panduan yang akan menjelaskan masing-masing _resource_ secara mendetail:
* [Cluster](/docs/tasks/administer-federation/cluster/)
* [ConfigMap](/docs/tasks/administer-federation/configmap/)
* [DaemonSets](/docs/tasks/administer-federation/daemonset/)
* [Deployment](/docs/tasks/administer-federation/deployment/)
* [Events](/docs/tasks/administer-federation/events/)
* [Hpa](/docs/tasks/administer-federation/hpa/)
* [Ingress](/docs/tasks/administer-federation/ingress/)
* [Jobs](/docs/tasks/administer-federation/job/)
* [Namespaces](/docs/tasks/administer-federation/namespaces/)
* [ReplicaSets](/docs/tasks/administer-federation/replicaset/)
* [Secrets](/docs/tasks/administer-federation/secret/)
* [Services](/id/docs/concepts/cluster-administration/federation-service-discovery/)
[Referensi Dokumentasi API](/docs/reference/federation/) memberikan semua daftar
_resources_ yang disediakan _apiserver_ _federation_.
## Penghapusan Berantai
Kubernetes versi 1.6 menyediakan mekanisme penghapusan berantai
untuk _resource_ yang ada pada _federation_. Dengan penghapusan berantai,
ketika kamu menghapus sebuah _resource_ dari _control plane_ _federation_,
kamu juga akan menghapus segala _resource_ tersebut pada semua klaster yang ada.
Mekanisme penghapusan berantai ini tidak diaktifkan secara _default_
ketika menggunakan REST API. Untuk mengaktifkannya, ubah nilai dari opsi
`DeleteOptions.orphanDependents=false` ketika kamu menghapus sebuah _resource_
dari _control plane_ _federation_ dengan menggunakan REST API.
Penggunaan `kubectl delete`mengaktifkan penhapusan berantai secara _default_.
Kamu dapat menonaktifkannya dengan menggunakan `kubectl delete --cascade=false`
Catatan: Kubernetes versi 1.5 menyediakan penghapusan berantai
untuk sebagian _resource_ _federation_.
## Cakupan dari Sebuah Klaster
Pada penyedia IaaS seperti Google Compute Engine atau Amazon Web Services, sebuah VM ada di dalam
[zona](https://cloud.google.com/compute/docs/zones) atau [_availability
zone_](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html).
Kami menyarankan agar semua VM pada klaster Kubernetes berada pada _availability_ zona yang sama, karena:
- dibandingkan dengan sebuah klaster global Kubernetes, terdapat lebih sedikit _single-points of failure_.
- dibandingkan dengan sebuah klaster yang tersebar pada _availability zone_ yang mungkin berbeda, akan lebih mudah untuk merencanakan properti _availability_ dari sebuah
klaster yang berada pada satu zona.
- ketika pengembang Kubernetes mendesain sistem (misalnya, memperkirakan _latency_, _bandwidth_, atau
_failure_ yang mungkin terjadi) pengembang tersebut memperkirakan semua mesin akan berada pada sebuah _data center_ yang sama, atau setidaknya masih terdapat pada satu wilayah.
Sangat direkomendasikan untuk menjalankan sedikit klaster dengan lebih banyak VM pada setiap _availability_ zona;
meskipun begitu hal ini tidak menutup kemungkinan untuk menjalankan klaster multipel
pada setiap _availability_ zona.
Alasan kenapa menjalankan lebih sedikit klaster pada setiap _availability_ zona lebih dianjurkan:
- meningkatkan _bin packing_ _Pod_ pada beberapa kasus dimana terdapat lebih banyak _node_ dalam sebuah klaster (mengurangi terjadinya _fragmentation_ _resource_).
- mengurangi _overhead_ operasional (meskipun keuntungan ini akan berkurang seiring bertambah matangnya proses dan _tooling_ operasional).
- mengurangi biaya _resource_ tetap per klaster, misalnya VM _apiserver_.
Alasan untuk memiliki klaster multipel:
- _policy_ kemananan yang ketat membutuhkan isolasi antar _work_ _class_ (baca Partisi Klaster di bawah).
- melakukan penerapan Kubernetes dan/atau perangkat lunak lain yang versi baru ke salah satu klaster.
## Memilih jumlah klaster yang tepat
Pemilihan jumlah klaster yang tepat merupakan pilihan yang relatif statis, dan hanya akan ditinjau kembali sewaktu-waktu.
Sebaliknya, jumlah _node_ dan _pod_ dalam suatu _service_ dapat berubah secara cepat seiring bertambahnya _workload_.
Untuk memilih jumlah klaster, pertama, pilih _region_ yang memiliki _latency_ yang masih dapat dimaklumi untuk semua pengguna aplikasi kamu
(jika kamu menggunakan _Content Distribution Network_, kebutuhan informasi nilai _latency_ CDN tidak perlu diperhatikan).
Masalah legal juga perlu diperhitungkan. Misalnya sebuah perusahaan dengan pelanggan global bisa jadi memilih klaster di _region_
US, EU, AP, dan SA. Jumlah _region_ ini dimisalkan dengan `R`.
Kedua, pilih berapa banyak klaster yang bisa jadi _unavailable_ secara bersamaan tanpa membuat _service_ menjadi _unavailable_.
Misalkan jumlah klaster _unavailable_ ini sebagai `U`. Jika kamu tidak yakin, maka 1 merupakan pilihan yang tergolong
dapat diterima.
Jika aplikasimu memungkinkan trafik untuk di-_load balance_ ke _region_ mana saja ketika terjadi _failure_ pada klaster,
maka kamu setidaknya membutuhkan nilai yang lebih banyak dari jumlah `R` atau `U + 1` klaster. Jika tidak (misalnya, kamu
ingin menjamin stabilnya _latency_ ketika terjadi _failure_ pada klaster) maka kamu membutuhkan `R * (U + 1)` klaster
(`U + 1` di setiap _region_ yang ada pada `R`). Pada kasus lain, cobalah untuk menerapkan satu klaster
pada zona yang berbeda.
Terakhir, jika klaster yang kamu miliki membutuhkan jumlah _node_ yang melebihi nilai yang direkomendasikan untuk sebuah klaster Kubernetes,
maka kamu membutuhkan lebih banyak klaster. Kubernetes v1.3 mampu menangani hingga 1000 node untuk setiap klaster. Kubernetes v1.8
mampu menangani hingga 5000 node untuk tiap klaster. Baca [Membangun Klaster Besar](/docs/setup/cluster-large/) untuk petunjuk lebih lanjut.
## {{% heading "whatsnext" %}}
* Pelajari lebih lanjut tentang [proposal
_Federation_](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/design-proposals/multicluster/federation.md).
* Baca [petunjuk pengaktifan](/docs/tutorials/federation/set-up-cluster-federation-kubefed/) klaster _federation_.
* Lihat [seminar tentang _federation_ pada Kubecon2016](https://www.youtube.com/watch?v=pq9lbkmxpS8)
* Lihat [_update_ _federation_ pada Kubecon2017 Eropa](https://www.youtube.com/watch?v=kwOvOLnFYck)
* Lihat [_update_ _sig-multicluster_ pada Kubecon2018 Eropa](https://www.youtube.com/watch?v=vGZo5DaThQU)
* Lihat [presentasi prototipe _Federation-v2_ pada Kubecon2018 Eropa](https://youtu.be/q27rbaX5Jis?t=7m20s)
* Lihat [petunjuk penggunaan _Federation-v2_](https://github.com/kubernetes-sigs/federation-v2/blob/master/docs/userguide.md)