You are viewing documentation for Kubernetes version: v1.18

Kubernetes v1.18 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 klaster Kubernetes.

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).
  • Hybrid cloud: 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 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 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.

Mengaktifkan Federation

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 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 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 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 Klaster

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:

  • 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 untuk petunjuk lebih lanjut.

Selanjutnya