Nama saya Sergey, saya dari ITSumma, dan saya ingin memberi tahu Anda bagaimana kami mendekati reservasi di Kubernetes. Baru-baru ini, saya telah melakukan banyak pekerjaan sebagai penasihat dalam mengimplementasikan berbagai solusi devops untuk berbagai tim, dan, khususnya, saya bekerja erat pada proyek-proyek menggunakan K8. Pada konferensi Uptime hari ke-4, yang didedikasikan untuk redundansi dalam arsitektur kompleks, saya membuat presentasi tentang kubus redundan, dan ini adalah menceritakan kembali secara gratis. Saya hanya akan memperingatkan sebelumnya bahwa dia bukan panduan langsung untuk bertindak, tetapi lebih merupakan generalisasi pemikiran tentang topik ini.
Pada prinsipnya, pemantauan dan redundansi adalah dua alat utama untuk meningkatkan ketahanan proyek apa pun. Tetapi dalam cuber, semuanya seimbang dengan sendirinya, Anda mengatakan, semuanya diskalakan dengan sendirinya, dan jika sesuatu terjadi, itu akan naik dengan sendirinya ... Artinya, selama studi dangkal pertama dari topik tersebut, Internet menjawab pertanyaan saya, "Bagaimana cara kerja backup K8?" ? " Banyak orang berpikir bahwa cuber adalah hal ajaib yang menghilangkan semua masalah infrastruktur dan membuat proyek tidak pernah jatuh. Tapi ... dunia tidak seperti apa kelihatannya.
Bagaimana kami mendekati proses pencadangan sebelumnya? Kami memiliki platform yang sama untuk penempatan - baik itu mesin virtual, atau mereka adalah server besi, tempat kami menerapkan tiga praktik dasar:
- sinkronisasi kode dan statika
- sinkronisasi konfigurasi
- replikasi basis data
Dan voila: kapan saja kita beralih ke situs cadangan, semua orang senang, kita bangun, kita tidak setuju.
Dan apa yang mereka tawarkan kepada kami untuk meningkatkan ketersediaan aplikasi kubernet kami yang konstan? Hal pertama yang dikatakan oleh dokumentasi tidak resmi adalah menempatkan banyak mesin, menghasilkan banyak master - jumlah mereka harus memenuhi persyaratan untuk mencapai kuorum di dalam cluster, dan agar etcd, api, MC, scheduler dinaikkan pada masing-masing master ... Dan, tampaknya, semuanya baik-baik saja : ketika beberapa node atau master yang berfungsi gagal, cluster kami akan diseimbangkan kembali dan aplikasi akan terus bekerja. Tampak seperti sihir lagi! Tetapi seringkali cluster kami terletak di dalam pusat data yang sama dan ini dapat menimbulkan pertanyaan tertentu. Bagaimana jika ekskavator tiba dan menggali kabel, tersambar petir, ada banjir universal? Semuanya tercakup, kluster kami tidak lebih. Bagaimana cara mendekati reservasi dengan mempertimbangkan sisi masalah ini?
Pertama-tama, Anda harus memiliki kluster lain di cadangan panas, yaitu kluster yang dapat Anda gunakan kapan saja. Dalam hal ini, dari sudut pandang cuber, infrastruktur harus benar-benar identik. Artinya, jika ada plugin non-standar untuk bekerja dengan sistem file, solusi kustom untuk masuk, mereka harus benar-benar identik pada dua (atau tiga, atau sepuluh, Anda ada cukup banyak uang dan kekuatan administrator) cluster. Penting untuk mendefinisikan dengan jelas dua set aplikasi (deployment'ov, statefulset'ov, daemonset'ov, cronjob'ov, dll.): Yang mana dari mereka dapat bekerja dengan cadangan secara terus-menerus, dan mana yang lebih baik untuk tidak memulai sebelum beralih langsung.
Jadi haruskah cluster cadangan kami benar-benar identik dengan cluster tempur kami? Tidak. Sebelumnya, dalam rangka bekerja dengan proyek-proyek monolitik, dengan infrastruktur besi, kami menjaga lingkungan yang hampir sepenuhnya identik, tetapi dalam kerangka umbi, saya pikir ini seharusnya tidak. Mari kita lihat alasannya.
Sebagai contoh, mari kita mulai dengan entitas dasar kubernet - penyebaran - mereka harus identik. Aplikasi harus diluncurkan yang dapat mencegat pemrosesan lalu lintas kapan saja dan memungkinkan proyek kami untuk terus hidup. Jika kita berbicara tentang file konfigurasi, maka kita perlu melihat di sini apakah mereka harus identik atau tidak. Artinya, jika kita, orang pintar, tidak menggunakan zat terlarang dan tidak menjaga basis di K8, maka kita harus memiliki pengaturan akses di configmaps untuk pangkalan tempur (proses pencadangan yang dibangun secara terpisah). Karenanya, untuk memastikan akses ke instance database cadangan, kita harus memiliki file konfigurasi (configmap) terpisah. Sama persis dengan cara kita bekerja dengan rahasia: kata sandi untuk mengakses database, kunci api; pada waktu tertentu, baik rahasia pertempuran atau cadangan yang dapat digunakan bersama kami. Secara total, kami sudah memiliki dua entitas kubernet yang versi cadangannya tidak boleh identik dengan yang ada di tempur. Entitas selanjutnya yang perlu diperhatikan adalah cronjob. Cronjobs pada cadangan tidak boleh sama dengan kumpulan cluster produksi cronjob! Jika kami menaikkan cluster cadangan dan menaikkannya sepenuhnya dengan semua cronjob diaktifkan, maka, misalnya, orang akan menerima dua surat dari Anda pada saat yang sama, bukan satu. Atau semacam sinkronisasi data dengan sumber eksternal akan berlangsung dua kali, masing-masing, kita mulai terluka, menangis, menjerit dan bersumpah.
Tetapi bagaimana orang-orang dari Internet menawarkan kita untuk mengatur cluster cadangan? Jawaban paling populer kedua setelah "mengapa?" - Penggunaan Federasi Kubernetes.
Apa ini Ini, katakanlah, sebuah cluster meta besar. Jika kita membayangkan arsitektur cuber - di mana kita memiliki master, beberapa node - maka dari sudut pandang federasi, kita juga memiliki master dan beberapa node, hanya setiap node adalah cluster yang terpisah. Artinya, kita bekerja dengan entitas yang sama, dengan primitif yang sama seperti dengan cuber tunggal, tetapi kita memutar dan memutar bukan mesin fisik kita, tetapi seluruh cluster. Dalam kerangka federasi, kami berada dalam sinkronisasi lengkap sumber daya federal dari orang tua ke keturunan. Misalnya, jika kami meluncurkan beberapa penyebaran melalui federasi, itu akan digunakan pada masing-masing kluster anak perusahaan kami. Jika kita mengambil configmap apa pun, rahasianya adalah menggulungnya ke federasi - itu akan menyebar ke semua kelompok anak-anak kita; pada saat yang sama, federasi memungkinkan kami untuk menyesuaikan sumber daya kami untuk anak-anak. Yaitu, kami mengambil beberapa configmap, menyebarkannya melalui federasi, dan kemudian, jika kami perlu memperbaiki sesuatu pada cluster tertentu, kami pergi untuk mengedit pada cluster yang terpisah, dan perubahan ini tidak akan disinkronkan di mana pun.
Federasi Kubernetes belum lama ini merupakan alat yang ada, dan itu tidak mendukung seluruh rangkaian sumber daya yang disediakan oleh K8: pada saat penerbitan salah satu versi pertama dari dokumentasi, itu berbicara tentang mendukung hanya peta konfigurasi, penyebaran untuk set replika, masuk. Rahasia tidak didukung, bekerja dengan volume juga tidak didukung. Set yang terlalu terbatas. Terutama jika kita suka bersenang-senang, misalnya, melalui definisi sumber daya khusus untuk mentransfer sumber daya kita sendiri ke kubernet, kita tidak akan mendorong mereka ke dalam federasi. Artinya, seperti ... sebuah keputusan yang sangat mirip dengan kebenaran, tetapi itu membuat kita secara berkala menembak diri kita sendiri. Di sisi lain, federasi memungkinkan Anda mengelola replika kami secara fleksibel. Misalnya, kami ingin 10 replika aplikasi kami diluncurkan, secara default, federasi akan membagi jumlah ini secara proporsional antara jumlah cluster. Dan semua ini juga bisa dikonfigurasi! Artinya, Anda dapat menentukan bahwa Anda perlu menyimpan 6 replika aplikasi kami di cluster tempur, dan hanya 4 replika aplikasi kami di cluster cadangan, untuk menghemat sumber daya, atau untuk hiburan Anda sendiri. Yang juga cukup nyaman. Tetapi dengan federasi kita harus menggunakan beberapa solusi baru, menyelesaikan sesuatu saat bepergian, dan memaksa diri kita untuk berpikir sedikit lebih ...
Apakah mungkin untuk mendekati proses pemesanan cuber dengan cara yang lebih sederhana? Alat apa yang kita miliki?
Pertama, kami selalu memiliki beberapa jenis sistem ci / cd, yaitu, kami tidak secara manual berkeliling, jangan menulis buat / terapkan di server. Sistem ini menghasilkan yaml'ics untuk wadah kami.
Kedua, ada beberapa cluster, kami memiliki satu, atau beberapa (jika kami pintar) registri, yang kami juga ambil dan pesan. Dan ada utilitas kubectl yang luar biasa yang dapat bekerja dengan banyak kluster secara bersamaan.
Jadi: menurut saya, solusi paling sederhana dan paling tepat untuk membangun cluster cadangan adalah penerapan paralel primitif. Ada beberapa jenis pipa dalam sistem ci / cd; pertama kami membangun wadah kami, menguji dan meluncurkan aplikasi melalui kubectl ke beberapa cluster independen. Kami dapat membangun perhitungan simultan pada beberapa kluster. Karenanya, kami juga memutuskan untuk mengirimkan konfigurasi pada tahap ini. Anda dapat menentukan sebelumnya set konfigurasi untuk cluster tempur kami, set konfigurasi untuk cluster cadangan dan pada level ci / cd sistem roll pro-environment ke pro-cluster, lingkungan backup ke cluster cadangan. Dibandingkan dengan federasi, Anda tidak perlu pergi setelah mendefinisikan sumber daya federal untuk setiap kelompok anak dan mendefinisikan kembali sesuatu. Kami melakukan ini sebelumnya. Betapa bagusnya kita.
Tapi ... ada ... saya menulis, ada "akar dari semua kejahatan", tetapi sebenarnya ada dua dari mereka. Yang pertama adalah sistem file. Ada beberapa jenis PV, atau kami menggunakan penyimpanan eksternal. Jika kita menyimpan file di dalam cluster, maka kita harus mengikuti praktik lama yang tersisa dari saat infrastruktur besi: misalnya, menyinkronkan dengan lsync. Ya, atau kruk lain yang Anda sukai. Kami menggulung semuanya ke mobil lain dan hidup.
Kedua, dan, pada kenyataannya, batu sandungan yang bahkan lebih penting adalah database. Jika kita orang pintar dan tidak menyimpan basis data di dalam kubus, maka proses mencadangkan data sesuai dengan skema lama yang sama adalah replikasi master-slave, lalu beralih, kita akan mengejar replika dan kita akan hidup dengan baik. Tetapi jika kita menyimpan DB kita di dalam cluster, maka pada prinsipnya ada banyak solusi siap pakai untuk mengatur replika master-slave yang sama, banyak solusi untuk meningkatkan DB di dalam kubus.
Satu miliar laporan telah dibaca tentang cadangan basis data, satu miliar artikel telah ditulis, sebenarnya tidak diperlukan hal baru di sini. Secara umum, ikuti impian Anda, hidup sesuka Anda, ciptakan beberapa kruk yang rumit juga, tetapi pastikan untuk memikirkan bagaimana Anda akan menyimpan semua ini.
Dan sekarang tentang bagaimana, pada prinsipnya, kita akan memiliki proses beralih ke situs cadangan jika terjadi kebakaran. Pertama, kami menggunakan aplikasi stateless secara paralel. Mereka tidak memengaruhi logika bisnis aplikasi kita, proyek kita, kita dapat secara konstan menyimpan dua set aplikasi yang sedang berjalan, dan mereka dapat mulai menerima lalu lintas. Sangat penting dalam proses beralih ke situs cadangan untuk melihat apakah konfigurasi perlu didefinisikan ulang? Misalnya, kami memiliki kluster penjualan kubernet, ada kluster kubernet cadangan, ada database master eksternal, dan ada database master cadangan. Kami memiliki empat opsi untuk bagaimana aplikasi ini di prod dapat mulai berinteraksi satu sama lain. Basis kami dapat beralih, dan ternyata kami perlu mengalihkan lalu lintas ke basis baru di cluster prod, atau kami bisa mendapatkan cluster dan kami pindah ke cadangan, tetapi kami terus bekerja dengan basis pro, well, opsi ketiga, ketika kami mendapatkannya , maka itu kacau, dan kami beralih kedua aplikasi, mendefinisikan kembali konfigurasi kami sehingga aplikasi baru sudah berfungsi dengan database baru.
Sebenarnya kesimpulan apa yang bisa diambil dari semua ini?
Kesimpulan pertama: hidup dengan baik dengan cadangan. Tapi mahal Namun idealnya, hidup dengan lebih dari satu cadangan. Idealnya, Anda umumnya harus hidup dengan beberapa cadangan. Pertama, cadangan harus setidaknya tidak dalam satu DC, dan kedua, setidaknya, di hoster lain. Itu sering terjadi - dan dalam praktik saya, itu terjadi. Sayangnya, saya tidak dapat menyebutkan nama proyek, hanya ketika ada kebakaran di pusat data ... Saya seperti ini: kami beralih ke cadangan! Dan server cadangan di rak yang sama berdiri ...
Atau bayangkan Amazon dilarang di Rusia (dan itu). Dan semua: arti fakta bahwa di amazon lain terletak cadangan kita? Itu juga tidak tersedia. Jadi saya ulangi: kita menyimpan cadangan, setidaknya, di DC lain, dan lebih disukai dengan host lain.
Kesimpulan kedua: jika aplikasi Anda berkomunikasi dengan beberapa sumber eksternal (bisa berupa basis data atau api eksternal), pastikan untuk mendefinisikannya sebagai layanan dengan Endpoint eksternal sehingga Anda tidak perlu memperbaikinya kembali pada saat beralih 15 dari aplikasi Anda yang mengetuk di pangkalan yang sama. Tetapkan database sebagai layanan terpisah, ketuk seolah-olah itu ada di dalam cluster Anda: jika Anda memiliki database, Anda mengubah ip di satu tempat dan terus hidup bahagia.
Dan akhirnya: Saya suka "kubus", serta percobaan dengan itu. Saya juga suka membagikan hasil percobaan ini dan, secara umum, pengalaman pribadi saya. Oleh karena itu, saya merekam serangkaian webinar tentang K8, baik di
saluran youtube kami untuk detailnya.