ProHoster > Blog > Pentadbiran > Cara menyambungkan kluster Kubernetes dalam pusat data yang berbeza
Cara menyambungkan kluster Kubernetes dalam pusat data yang berbeza
Selamat datang ke siri Mula Pantas Kubernetes kami. Ini adalah lajur biasa dengan soalan paling menarik yang kami terima dalam talian dan dalam latihan kami. Jawapan pakar Kubernetes.
Pakar hari ini ialah Daniel Polenchik (Daniele Polencic). Daniel bekerja sebagai pengajar dan pembangun perisian di Learnk8s.
Selalunya, infrastruktur direplikasi dan diedarkan ke seluruh wilayah yang berbeza, terutamanya dalam persekitaran terkawal.
Jika satu wilayah tidak tersedia, lalu lintas diubah hala ke kawasan lain untuk mengelakkan gangguan.
Dengan Kubernetes, anda boleh menggunakan strategi yang serupa dan mengagihkan beban kerja ke seluruh wilayah yang berbeza.
Anda boleh mempunyai satu atau lebih kelompok bagi setiap pasukan, wilayah, persekitaran atau gabungan elemen ini.
Kelompok anda boleh dihoskan di awan dan di premis yang berbeza.
Tetapi bagaimana anda merancang infrastruktur untuk penyebaran geografi sedemikian?
Adakah anda perlu mencipta satu kluster besar untuk beberapa persekitaran awan melalui satu rangkaian?
Atau mempunyai banyak gugusan kecil dan mencari cara untuk mengawal dan menyegerakkannya?
Satu kluster kepimpinan
Mewujudkan satu kluster melalui satu rangkaian tidak begitu mudah.
Bayangkan anda mengalami kemalangan, ketersambungan antara segmen kluster hilang.
Jika anda mempunyai satu pelayan induk, separuh daripada sumber tidak akan dapat menerima arahan baharu kerana mereka tidak akan dapat menghubungi induk.
Dan pada masa yang sama anda mempunyai jadual penghalaan lama (kube-proxy tidak boleh memuat turun yang baharu) dan tiada pod tambahan (kubelet tidak boleh meminta kemas kini).
Lebih memburukkan keadaan, jika Kubernetes tidak melihat nod, ia menandakannya sebagai yatim piatu dan mengedarkan pod yang hilang ke nod sedia ada.
Akibatnya, anda mempunyai dua kali lebih banyak pod.
Jika anda membuat satu pelayan induk untuk setiap rantau, akan ada masalah dengan algoritma konsensus dalam pangkalan data etcd. (lebih kurang ed. β Sebenarnya, pangkalan data etcd tidak semestinya perlu ditempatkan pada pelayan induk. Ia boleh dijalankan pada kumpulan pelayan yang berasingan di rantau yang sama. Benar, pada masa yang sama mendapat titik kegagalan kelompok. Tetapi dengan cepat.)
kegunaan etcd algoritma rakituntuk merundingkan nilai sebelum menulisnya ke cakera.
Iaitu, majoriti contoh mesti mencapai konsensus sebelum negeri boleh ditulis kepada etcd.
Jika kependaman antara kejadian etcd meningkat secara mendadak, seperti halnya dengan tiga kejadian etcd di kawasan berbeza, ia mengambil masa yang lama untuk merundingkan nilai dan menulisnya ke cakera.
Ini ditunjukkan dalam pengawal Kubernetes.
Pengurus pengawal memerlukan lebih banyak masa untuk mengetahui tentang perubahan dan menulis respons kepada pangkalan data.
Dan kerana tidak ada satu pengawal, tetapi beberapa, tindak balas berantai terhasil dan keseluruhan kluster mula berfungsi dengan sangat perlahan.
Buat pertama kalinya, kami cuba menguruskan koleksi kluster sebagai objek tunggal menggunakan alat persekutuan kube.
Permulaannya bagus, tetapi akhirnya persekutuan kube tidak pernah menjadi popular kerana ia tidak menyokong semua sumber.
Ia menyokong penghantaran dan perkhidmatan bersekutu, tetapi bukan StatefulSets, sebagai contoh.
Selain itu, konfigurasi persekutuan telah dihantar dalam bentuk anotasi dan tidak fleksibel.
Bayangkan bagaimana anda boleh menerangkan pembahagian replika untuk setiap kelompok dalam persekutuan hanya menggunakan anotasi.
Ia benar-benar huru-hara.
Kluster SIG melakukan banyak kerja selepas kubefed v1 dan memutuskan untuk mendekati masalah dari sudut yang berbeza.
Daripada anotasi, mereka memutuskan untuk mengeluarkan pengawal yang dipasang pada kelompok. Ia boleh disesuaikan menggunakan Definisi Sumber Tersuai (CRD).
Untuk setiap sumber yang akan menjadi sebahagian daripada persekutuan, anda mempunyai definisi CRD tersuai dengan tiga bahagian:
takrifan standard sumber, contohnya penempatan;
seksyen placement, di mana anda menentukan cara sumber itu akan diagihkan dalam persekutuan;
seksyen override, di mana untuk sumber tertentu anda boleh mengatasi berat dan parameter daripada peletakan.
Berikut ialah contoh penghantaran gabungan dengan bahagian peletakan dan ganti.
Seperti yang anda lihat, bekalan diedarkan di dua kelompok: cluster1 ΠΈ cluster2.
Kelompok pertama membekalkan tiga replika, dan yang kedua ditetapkan kepada 5.
Jika anda memerlukan lebih kawalan ke atas bilangan replika, kubefed2 menyediakan objek ReplicaSchedulingPreference baharu di mana replika boleh ditimbang:
Pilihan 2: menggabungkan kluster dalam gaya Booking.com
Pembangun Booking.com tidak berfungsi pada kubefed v2, tetapi mereka menghasilkan Shipper - pengendali untuk penghantaran pada beberapa kluster, di beberapa wilayah dan di beberapa awan.
Kedua-dua alatan membolehkan anda menyesuaikan strategi penggunaan berbilang kelompok anda (kelompok yang digunakan dan bilangan replika yang mereka ada).
Tetapi Matlamat penghantar adalah untuk mengurangkan risiko ralat semasa penghantaran.
Dalam Shipper, anda boleh menentukan satu siri langkah yang menerangkan pembahagian replika antara penggunaan sebelumnya dan semasa dan jumlah trafik masuk.
Apabila anda menolak sumber ke kluster, pengawal Pengirim secara berperingkat melancarkan perubahan itu merentas semua kluster yang dicantumkan.
Juga, Penghantar adalah sangat terhad.
Sebagai contoh, ia menerima carta helm sebagai input dan tidak menyokong sumber vanila.
Secara umum, Shipper berfungsi seperti ini.
Daripada penghantaran standard, anda perlu mencipta sumber aplikasi yang merangkumi carta Helm:
Tetapi bukannya menghasilkan cara baharu untuk berinteraksi dengan kluster dan membungkus sumber dalam definisi tersuai, penjadual berbilang kluster dibenamkan dalam kitaran hayat Kubernetes standard dan memintas semua panggilan yang mencipta pod.
Setiap pod yang dibuat segera digantikan dengan dummy.
Pod asal melalui kitaran perancangan lain di mana, selepas mengundi seluruh persekutuan, keputusan penempatan dibuat.
Akhirnya, pod dihantar ke kluster sasaran.
Akibatnya, anda mempunyai pod tambahan yang tidak melakukan apa-apa, hanya mengambil ruang.
Kelebihannya ialah anda tidak perlu menulis sumber baharu untuk menggabungkan bekalan.
Setiap sumber yang mencipta pod sedia secara automatik untuk digabungkan.
Ini menarik, kerana tiba-tiba anda mempunyai bekalan yang diedarkan di beberapa wilayah, dan anda tidak menyedarinya. Walau bagaimanapun, ini agak berisiko, kerana segala-galanya di sini bergantung pada sihir.
Tetapi sementara Shipper cuba untuk mengurangkan kesan penghantaran, penjadual berbilang kelompok mengendalikan tugas yang lebih umum dan mungkin lebih sesuai untuk kerja kelompok.
Ia tidak mempunyai mekanisme penghantaran berperingkat lanjutan.
Lebih lanjut mengenai multi-cluster-scheduler boleh didapati di halaman repositori rasmi.
Jika anda ingin membaca tentang penjadual berbilang kelompok dalam tindakan, Admiralty ada kes penggunaan yang menarik dengan Argo β aliran kerja, acara, CI dan CD Kubernetes.
Alat dan penyelesaian lain
Menyambung dan mengurus berbilang kluster adalah tugas yang kompleks, dan tiada penyelesaian universal.
Jika anda ingin meneroka topik ini dengan lebih lanjut, berikut ialah beberapa sumber:
Kapal selam oleh Penternak ialah alat yang menghubungkan rangkaian tindanan bagi kelompok Kubernetes yang berbeza.
Cilium, pemalam antara muka rangkaian kontena, menawarkan fungsi jaringan kluster, yang membolehkan anda menggabungkan beberapa kluster
Itu sahaja untuk hari ini
Terima kasih kerana membaca sehingga habis!
Jika anda tahu cara menyambung berbilang kluster dengan lebih cekap, beritahu kami.
Kami akan menambah kaedah anda pada pautan.
Terima kasih khas kepada Chris Nesbitt-Smith (Chris Nesbitt-Smith) dan Vincent de Sme (Vincent De Smet) (jurutera kebolehpercayaan dalam swatmobile.io) untuk membaca artikel dan berkongsi maklumat berguna tentang cara persekutuan berfungsi.