Selamat datang di seri tutorial cepat Kubernetes. Ini adalah kolom reguler dengan pertanyaan paling menarik yang kami terima online dan di pelatihan kami. Pakar jawaban Kubernetes.
Pakar hari ini adalah Daniele Polencic . Daniel adalah instruktur dan pengembang perangkat lunak di Learnk8s .
Jika Anda ingin menjawab pertanyaan Anda di posting berikutnya, silakan hubungi kami melalui email atau di Twitter: @ learnk8s .
Melewati posting sebelumnya? Cari mereka di sini .
Bagaimana cara menghubungkan kluster Kubernetes di pusat data yang berbeda?
Secara singkat : Kubefed v2 akan segera hadir , dan saya juga menyarankan Anda untuk membaca tentang Shipper dan proyek multi-cluster-scheduler .
Cukup sering, infrastruktur direplikasi dan didistribusikan di berbagai daerah, terutama di lingkungan yang terkendali.
Jika satu wilayah tidak tersedia, lalu lintas dialihkan ke yang lain untuk menghindari gangguan.
Dengan Kubernetes, Anda dapat menggunakan strategi serupa dan mendistribusikan beban kerja di berbagai wilayah.
Anda dapat memiliki satu atau lebih cluster per tim, wilayah, lingkungan, atau kombinasi dari elemen-elemen ini.
Cluster Anda dapat di-host di awan yang berbeda dan di lingkungan lokal.
Tetapi bagaimana merencanakan infrastruktur untuk penyebaran geografis seperti itu?
Perlu membuat satu cluster besar di beberapa lingkungan cloud melalui satu jaringan?
Atau memulai banyak kelompok kecil dan menemukan cara untuk mengontrol dan menyinkronkannya?
Satu Cluster Timbal
Membuat satu cluster di satu jaringan tidak sesederhana itu.
Bayangkan Anda mengalami kecelakaan, kehilangan konektivitas antara segmen-segmen cluster.
Jika Anda memiliki satu server master, setengah dari sumber daya tidak akan dapat menerima perintah baru, karena mereka tidak akan dapat menghubungi master.
Dan pada saat yang sama, Anda memiliki tabel routing yang lama ( kube-proxy tidak dapat memuat yang baru) dan tidak ada pod tambahan (kubelet tidak dapat meminta pembaruan).
Lebih buruk lagi, jika Kubernetes tidak melihat node, itu menandainya hilang dan mendistribusikan pod yang hilang ke node yang ada.
Akibatnya, Anda memiliki polong dua kali lebih banyak.
Jika Anda membuat satu server master untuk setiap wilayah, akan ada masalah dengan algoritma konsensus di database dll. ( kira-kira Ed. - Sebenarnya, database etcd tidak harus terletak di server master. Dapat dijalankan pada kelompok server yang terpisah di wilayah yang sama. Namun, pada saat yang sama ia menerima titik kegagalan cluster. Tetapi dengan cepat. )
etcd menggunakan algoritma rakit untuk menegosiasikan nilai sebelum menulisnya ke disk.
Artinya, sebagian besar contoh harus mencapai konsensus sebelum negara dapat ditulis ke etcd.
Jika penundaan antara instance etcd meningkat secara dramatis, seperti halnya dengan tiga instance etcd di berbagai wilayah, dibutuhkan waktu yang lama untuk merekonsiliasi nilai dan menulisnya ke disk.
Ini tercermin dalam pengontrol Kubernetes.
Manajer pengontrol perlu lebih banyak waktu untuk mempelajari tentang perubahan dan menulis respons ke database.
Dan jika pengontrol bukan satu, tetapi beberapa, reaksi berantai diperoleh, dan seluruh kluster mulai bekerja sangat lambat .
etcd sangat sensitif terhadap latensi sehingga dokumentasi resmi merekomendasikan penggunaan SSD daripada hard drive biasa .
Saat ini tidak ada contoh yang baik dari jaringan besar untuk satu cluster.
Pada dasarnya, komunitas pengembangan dan kelompok SIG-cluster mencoba mencari cara untuk mengatur cluster dengan cara yang sama seperti Kubernet mengatur wadah.
Opsi 1: federasi klaster dengan kubefed
Jawaban resmi dari SIG-cluster adalah kubefed2, versi baru dari klien asli dan federasi operator kubus .
Untuk pertama kalinya, mereka mencoba mengelola kumpulan cluster sebagai objek tunggal menggunakan alat federasi kubus.
Awalnya memang bagus, tetapi pada akhirnya, federasi kubus tidak menjadi populer karena tidak mendukung semua sumber daya.
Dia mendukung pengiriman dan layanan bersama, tetapi, misalnya, bukan StatefulSets.
Dan konfigurasi federasi ditransmisikan dalam bentuk anotasi dan tidak berbeda dalam fleksibilitas.
Bayangkan bagaimana Anda bisa menggambarkan pemisahan replika untuk masing-masing klaster dalam federasi hanya menggunakan anotasi.
Ternyata berantakan total.
SIG-cluster melakukan pekerjaan dengan baik setelah kubefed v1 dan memutuskan untuk mendekati masalah dari sisi lain.
Alih-alih anotasi, mereka memutuskan untuk melepaskan pengontrol yang diinstal pada cluster. Itu dapat dikonfigurasi menggunakan Custom Resource Definition (CRD).
Untuk setiap sumber daya yang akan menjadi bagian dari federasi, Anda memiliki definisi CRD khusus tentang tiga bagian:
- definisi standar suatu sumber daya, seperti penyebaran;
- bagian
placement , tempat Anda menentukan bagaimana sumber daya akan didistribusikan di federasi; - bagian
override , di mana untuk sumber daya tertentu Anda dapat mengganti bobot dan parameter dari penempatan.
Berikut adalah contoh pengiriman gabungan dengan bagian penempatan dan penggantian.
apiVersion: types.federation.k8s.io/v1alpha1 kind: FederatedDeployment metadata: name: test-deployment namespace: test-namespace spec: template: metadata: labels: app: nginx spec: replicas: 3 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - image: nginx name: nginx placement: clusterNames: - cluster2 - cluster1 overrides: - clusterName: cluster2 clusterOverrides: - path: spec.replicas value: 5
Seperti yang Anda lihat, pasokan didistribusikan di dua cluster: cluster1 dan cluster2 .
Cluster pertama memberikan tiga replika, sedangkan yang kedua diatur ke 5.
Jika Anda membutuhkan kontrol lebih besar atas jumlah replika, kubefed2 menyediakan objek ReplicaSchedulingPreference baru, tempat replika dapat ditimbang:
apiVersion: scheduling.federation.k8s.io/v1alpha1 kind: ReplicaSchedulingPreference metadata: name: test-deployment namespace: test-ns spec: targetKind: FederatedDeployment totalReplicas: 9 clusters: A: weight: 1 B: weight: 2
Struktur CRD dan API belum siap, dan pekerjaan aktif sedang dilakukan di repositori proyek resmi.
Berhati-hatilah terhadap kubefed2, tetapi ingat bahwa itu belum cocok untuk lingkungan kerja.
Pelajari lebih lanjut tentang kubefed2 di artikel kubefed2 resmi di blog Kubernetes dan di repositori proyek kubefed resmi .
Opsi 2: pengelompokan kluster gaya Booking.com
Pengembang Booking.com tidak berurusan dengan kubefed v2, tetapi mereka datang dengan Shipper, operator untuk pengiriman pada beberapa cluster, di beberapa wilayah dan di beberapa cloud.
Pengirim adalah sesuatu yang mirip dengan kubefed2.
Kedua alat memungkinkan Anda untuk mengkonfigurasi strategi penyebaran untuk beberapa kluster (klaster mana yang digunakan dan berapa banyak replika yang mereka miliki).
Tetapi tujuan Shipper adalah untuk mengurangi risiko kesalahan pengiriman.
Di Pengirim, Anda dapat menentukan serangkaian langkah yang menjelaskan pemisahan replika antara penggunaan sebelumnya dan saat ini dan jumlah lalu lintas yang masuk.
Saat Anda mengirimkan sumber daya ke sebuah cluster, pengontrol Pengirim menyebarkan perubahan ini langkah demi langkah di semua cluster gabungan.
Dan Pengirim sangat terbatas.
Misalnya, ia menerima grafik Helm sebagai input dan tidak mendukung sumber daya vanilla.
Secara umum, Pengirim bekerja sebagai berikut.
Alih-alih pengiriman standar, Anda perlu membuat sumber daya aplikasi yang mencakup grafik Helm:
apiVersion: shipper.booking.com/v1alpha1 kind: Application metadata: name: super-server spec: revisionHistoryLimit: 3 template: chart: name: nginx repoUrl: https://storage.googleapis.com/shipper-demo version: 0.0.1 clusterRequirements: regions: - name: local strategy: steps: - capacity: contender: 1 incumbent: 100 name: staging traffic: contender: 0 incumbent: 100 - capacity: contender: 100 incumbent: 0 name: full on traffic: contender: 100 incumbent: 0 values: replicaCount: 3
Pengirim adalah pilihan yang baik untuk mengelola beberapa kluster, tetapi hubungannya yang dekat dengan Helm hanya mengganggu.
Bagaimana jika kita semua pindah dari Helm ke kustomize atau kapitan ?
Pelajari lebih lanjut tentang Pengirim dan filosofinya dalam siaran pers resmi ini .
Jika Anda ingin mempelajari kodenya, buka repositori proyek resmi .
Opsi 3: klaster "ajaib" bergabung
Kubefed v2 dan Shipper bekerja dengan federasi klaster, menyediakan cluster sumber daya baru melalui definisi sumber daya kustom.
Tetapi bagaimana jika Anda tidak ingin menulis ulang semua persediaan, StatefulSets, DaemonSets, dll untuk digabungkan?
Bagaimana cara memasukkan cluster yang ada ke dalam federasi tanpa mengubah YAML?
multi-cluster-scheduler adalah proyek Admirality yang menangani beban kerja perencanaan dalam cluster.
Tetapi alih-alih menemukan cara baru untuk berinteraksi dengan cluster dan membungkus sumber daya dalam definisi yang ditentukan pengguna, multi-cluster-scheduler tertanam dalam siklus hidup Kubernet standar dan memotong semua panggilan yang membuat pod.
Masing-masing yang dibuat di bawah segera diganti oleh boneka.
multi-cluster-scheduler menggunakan kait web untuk memodifikasi akses untuk mencegat panggilan dan membuat boneka pod menganggur.
Sumber pod melewati siklus perencanaan lain, di mana setelah survei seluruh federasi, keputusan dibuat pada penempatan.
Akhirnya, pod dikirim ke cluster target.
Akibatnya, Anda memiliki pod tambahan yang tidak melakukan apa-apa, hanya menghabiskan ruang.
Keuntungannya adalah Anda tidak perlu menulis sumber daya baru untuk menggabungkan persediaan.
Setiap sumber daya yang membuat pod siap digabung secara otomatis.
Ini menarik, karena Anda tiba-tiba memiliki pengiriman yang didistribusikan di beberapa daerah, tetapi Anda belum menyadarinya. Namun, ini cukup berisiko, karena di sini semuanya bertumpu pada sihir.
Tetapi jika Pengirim terutama mencoba untuk mengurangi efek persediaan, multi-cluster-scheduler melakukan tugas yang lebih umum dan mungkin lebih cocok untuk pekerjaan batch.
Itu tidak memiliki mekanisme pasokan bertahap maju.
Anda dapat mempelajari lebih lanjut tentang multi-cluster-scheduler di halaman repositori resmi .
Jika Anda ingin membaca tentang multi-cluster-scheduler yang sedang beraksi, Admiralty memiliki use case yang menarik dengan Argo - alur kerja, peristiwa, CI, dan CD Kubernetes.
Alat dan solusi lainnya
Menghubungkan dan mengelola banyak kluster adalah tugas yang rumit, tidak ada solusi universal.
Jika Anda ingin mempelajari lebih lanjut tentang topik ini, berikut adalah beberapa sumber:
Itu saja untuk hari ini
Terima kasih sudah membaca sampai akhir!
Jika Anda tahu cara menghubungkan banyak cluster secara lebih efisien, beri tahu kami .
Kami akan menambahkan metode Anda ke tautan.
Terima kasih khusus kepada Chris Nesbitt-Smith dan Vincent De Smet (insinyur keandalan di swatmobile.io ) untuk membaca artikel ini dan berbagi beberapa informasi berguna tentang cara kerja federasi.