Black lives matter.
We stand in solidarity with the Black community.
Racism is unacceptable.
It conflicts with the core values of the Kubernetes project and our community does not tolerate it.
We stand in solidarity with the Black community.
Racism is unacceptable.
It conflicts with the core values of the Kubernetes project and our community does not tolerate it.
Sudah usang
Penggunaan
Federation V1
sangat tidak disarankan.Federation V1
tidak pernah masuk dalam GA dan tidak lagi dikembangkan secara aktif. Dokumentasi hanya disediakan sebatas data artefak saja.Untuk informasi lebih lanjut mengenai hal ini dan penggantinya kamu dapat membaca Kubernetes Federation v2.
Laman ini menjelaskan alasan dan cara penggunaan federation untuk melakukan manajemen klaster Kubernetes.
Federation membuat proses manajemen klaster multipel menjadi lebih mudah. Federation mencapai hal ini dengan cara menyediakan 2 buah fondasi:
Beberapa penggunaan federation adalah sebagai berikut:
Manfaat federation tidak akan terlalu kelihatan kecuali kamu memiliki beberapa klaster. Beberapa alasan kenapa kamu butuh beberapa klaster adalah:
Meskipun terdapat banyak kelebihan dari penggunaan federation, terdapat beberapa kekurangan federation yang dijabarkan sebagai berikut:
Federation pada Kubernetes memungkinkan klaster untuk dijalankan pada penyedia layanan cloud yang berbeda (misalnya Google Cloud, AWS), dan on-premise (misalnya OpenStack). Kubefed adalah salah satu cara yang direkomendasikan untuk melakukan proses deploy klaster federation.
Dengan demikian, resources API yang kamu miliki dapat berada di klaster atau bahkan penyedia layanan cloud yang berbeda.
Untuk bisa melakukan federation pada klaster yang berbeda, pertama kamu harus mengaktifkan control plane federation. Ikuti petunjuk mengaktifkan control plane federation untuk informasi lebih lanjut.
Resources
APISetelah kamu mengaktifkan control plane, kamu dapat menggunakan resource API federation. Berikut merupakan panduan yang akan menjelaskan masing-masing resource secara mendetail:
Referensi Dokumentasi API memberikan semua daftar resources yang disediakan apiserver federation.
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.
Pada penyedia IaaS seperti Google Compute Engine atau Amazon Web Services, sebuah VM ada di dalam zona atau availability zone. Kami menyarankan agar semua VM pada klaster Kubernetes berada pada availability zona yang sama, karena:
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:
Alasan untuk memiliki klaster multipel:
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 untuk petunjuk lebih lanjut.