Konsep

Kubernetes v1.14 dokumentasi sudah tidak dirawat lagi. Versi yang kamu lihat ini hanyalah snapshot statis. Untuk dokumentasi terkini, lihat versi terkini.

Edit This Page

Federation

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 kluster Kubernetes.

Kenapa Federation ?

Federation membuat proses manajemen kluster 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 kluster. Beberapa alasan kenapa kamu butuh beberapa kluster adalah:

Kekurangan

Meskipun terdapat banyak kelebihan dari penggunaan federation, terdapat beberapa kekurangan federation yang dijabarkan sebagai berikut:

Kemampuan Hybrid Penggunaan Layanan Penyedian Cloud

Federation pada Kubernetes memungkinkan kluster 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 kluster federation.

Dengan demikian, resources API yang kamu miliki dapat berada di kluster atau bahkan penyedia layanan cloud yang berbeda.

Mengaktifkan Federation

Untuk bisa melakukan federation pada kluster yang berbeda, pertama kamu harus mengaktifkan control plane federation. Ikuti petunjuk mengaktifkan control plane federation 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:

Referensi Dokumentasi API 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 kluster 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 deletemengaktifkan 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 Kluster

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 kluster Kubernetes berada pada availability zona yang sama, karena:

Sangat direkomendasikan untuk menjalankan sedikit kluster dengan lebih banyak VM pada setiap availability zona; meskipun begitu hal ini tidak menutup kemungkinan untuk menjalankan kluster multipel pada setiap availability zona.

Alasan kenapa menjalankan lebih sedikit kluster pada setiap availability zona lebih dianjurkan:

Alasan untuk memiliki kluster multipel:

Memilih jumlah kluster yang tepat

Pemilihan jumlah kluster 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 kluster, 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 kluster di region US, EU, AP, dan SA. Jumlah region ini dimisalkan dengan R.

Kedua, pilih berapa banyak kluster yang bisa jadi unavailable secara bersamaan tanpa membuat service menjadi unavailable. Misalkan jumlah kluster 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 kluster, maka kamu setidaknya membutuhkan nilai yang lebih banyak dari jumlah R atau U + 1 kluster. Jika tidak (misalnya, kamu ingin menjamin stabilnya latency ketika terjadi failure pada kluster) maka kamu membutuhkan R * (U + 1) kluster (U + 1 di setiap region yang ada pada R). Pada kasus lain, cobalah untuk menerapkan satu kluster pada zona yang berbeda.

Terakhir, jika kluster yang kamu miliki membutuhkan jumlah node yang melebihi nilai yang direkomendasikan untuk sebuah kluster Kubernetes, maka kamu membutuhkan lebih banyak kluster. Kubernetes v1.3 mampu menangani hingga 1000 node untuk setiap kluster. Kubernetes v1.8 mampu menangani hingga 5000 node untuk tiap kluster. Baca Membangun Kluster Besar untuk petunjuk lebih lanjut.

Selanjutnya

Masukan