Mempelajari Panduan Dasar Kubernetes

Konsep

Kubernetes v1.16 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:

  • Melakukan sinkronisasi resource di seluruh kluster: Federation menyediakan kemampuan untuk melakukan sinkronisasi resources pada multiple kluster. Sebagai contoh, kamu dapat memastikan Deployment yang sama tersedia pada kluster multipel.
  • Cross cluster Discovery: Federation menyediakan kemampuan untuk melakukan konfigurasi otomatis server DNS dan load balancer dari semua kluster. Misalnya, kamu dapat memastikan bahwa sebuah VIP atau DNS global dapat digunakan untuk mengakses backend dari kluster multipel.

Beberapa penggunaan federation adalah sebagai berikut:

  • High Availability: Melakukan load balance di seluruh kluster serta melakukan konfigurasi otomatis server DNS dan load balancer, federation meminimalisasi dampak yang terjadi apabila terjadi kegagalan kluster.
  • Mencegah lock-in yang terjadi akibat penyedia layanan: Dengan cara mempermudah proses migrasi antar kluster.

Manfaat federation tidak akan terlalu kelihatan kecuali kamu memiliki beberapa kluster. Beberapa alasan kenapa kamu butuh beberapa kluster adalah:

  • Latency yang rendah: Memiliki kluster 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 kluster kecil dibandingkan sebuah kluster besar untuk melakukan isolasi fault (misalnya saja kluster ini bisa saja berada di availability zona dan penyedia layanan cloud yang berbeda).
  • Skalabilitas: Terdapat batasan skalabilitas untuk sebuah kluster 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 kluster yang ada dijalankan pada region yang berbeda baik pada penyedia layanan cloud yang sama maupun berbeda.
  • Berkurangnya isolasi antar kluster: Sebuah bug yang ada pada control plane federation dapat berdampak pada semua kluster. 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 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:

  • dibandingkan dengan sebuah kluster global Kubernetes, terdapat lebih sedikit single-points of failure.
  • dibandingkan dengan sebuah kluster yang tersebar pada availability zone yang mungkin berbeda, akan lebih mudah untuk merencanakan properti availability dari sebuah kluster 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 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:

  • meningkatkan bin packing Pod pada beberapa kasus dimana terdapat lebih banyak node dalam sebuah kluster (mengurangi terjadinya fragmentation resource).
  • mengurangi overhead operasional (meskipun keuntungan ini akan berkurang seiring bertambah matangnya proses dan tooling operasional).
  • mengurangi biaya resource tetap per kluster, misalnya VM apiserver.

Alasan untuk memiliki kluster multipel:

  • policy kemananan yang ketat membutuhkan isolasi antar work class (baca Partisi Kluster di bawah).
  • melakukan penerapan Kubernetes dan/atau perangkat lunak lain yang versi baru ke salah satu kluster.

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