Keperluan untuk membangunkan aplikasi dalam Kubernetes

Hari ini saya merancang untuk bercakap tentang cara menulis aplikasi dan apakah keperluan untuk aplikasi anda berfungsi dengan baik dalam Kubernetes. Supaya tiada pening kepala dengan aplikasi itu, supaya anda tidak perlu mencipta dan membina sebarang "cratch" di sekelilingnya - dan semuanya berfungsi seperti yang dimaksudkan oleh Kubernetes sendiri.

Syarahan ini adalah sebahagian daripada "Sekolah Malam Slurm di Kubernetes" Anda boleh melihat kuliah teori terbuka Sekolah Petang di Youtube, dikumpulkan ke dalam senarai main. Bagi mereka yang lebih suka teks daripada video, kami telah menyediakan artikel ini.

Nama saya Pavel Selivanov, pada masa ini saya jurutera DevOps terkemuka di Mail.ru Cloud Solutions, kami membuat awan, kami membuat pengurusan kubernet dan sebagainya. Tugas saya kini termasuk bantuan dalam pembangunan, melancarkan awan ini, melancarkan aplikasi yang kami tulis dan terus membangunkan alatan yang kami sediakan untuk pengguna kami.

Saya telah melakukan DevOps, saya fikir selama ini, mungkin, tiga tahun. Tetapi, pada dasarnya, saya telah melakukan apa yang DevOps lakukan selama mungkin kira-kira lima tahun sekarang. Sebelum itu, saya banyak terlibat dalam urusan admin. Saya mula bekerja dengan Kubernetes lama dahulu - mungkin kira-kira empat tahun telah berlalu sejak saya mula bekerja dengannya.

Secara umum, saya bermula apabila Kubernetes adalah versi 1.3, mungkin, dan mungkin 1.2 - ketika ia masih di peringkat awal. Kini ia tidak lagi di peringkat awal - dan jelas bahawa terdapat permintaan yang besar dalam pasaran untuk jurutera yang ingin dapat melakukan Kubernetes. Dan syarikat mempunyai permintaan yang sangat tinggi untuk orang sedemikian. Oleh itu, sebenarnya, kuliah ini muncul.

Jika kita bercakap mengikut rancangan apa yang saya akan bincangkan, ia kelihatan seperti ini, dalam kurungan tertulis (TL;DR) - “terlalu panjang; jangan baca". Pembentangan saya hari ini akan terdiri daripada senarai yang tidak berkesudahan.

Sebenarnya, saya sendiri tidak suka pembentangan seperti itu apabila ia dibuat, tetapi ini adalah topik yang apabila saya menyediakan pembentangan ini, saya langsung tidak tahu bagaimana untuk menyusun maklumat ini secara berbeza.

Kerana, pada umumnya, maklumat ini ialah "ctrl+c, ctrl+v", daripada, antara lain, Wiki kami di bahagian DevOps, di mana kami mempunyai keperluan bertulis untuk pembangun: "guys, supaya kami melancarkan aplikasi anda dalam Kubernetes, ia sepatutnya seperti ini."

Itulah sebabnya persembahan itu ternyata menjadi senarai yang besar. Maaf. Saya akan cuba ceritakan sebanyak mungkin agar tidak membosankan jika boleh.

Apa yang kita akan lihat sekarang:

• ini adalah, pertama, log (log aplikasi?), apa yang perlu dilakukan dengan mereka dalam Kubernetes, apa yang perlu dilakukan dengan mereka, apa yang sepatutnya;
• apa yang perlu dilakukan dengan konfigurasi dalam Kubernetes, apakah cara terbaik dan paling teruk untuk mengkonfigurasi aplikasi untuk Kubernetes;
• Mari kita bincangkan tentang semakan kebolehaksesan secara umum, bagaimana rupanya;
• mari kita bincangkan tentang penutupan yang anggun;
• mari kita bercakap tentang sumber semula;
• Mari kita sentuh topik penyimpanan data sekali lagi;
• dan pada akhirnya saya akan memberitahu anda apakah istilah aplikasi asli awan yang misteri ini. Cloudnativeness, sebagai kata sifat bagi istilah ini.

Log

Saya cadangkan bermula dengan log - dengan tempat log ini perlu didorong dalam Kubernetes. Kini anda telah melancarkan aplikasi dalam Kubernetes. Menurut klasik, aplikasi sebelum ini sentiasa menulis log di suatu tempat dalam fail. Aplikasi buruk menulis log ke fail dalam direktori rumah pembangun yang melancarkan aplikasi itu. Aplikasi yang baik menulis log ke fail di suatu tempat /var/log.

Sehubungan itu, selanjutnya, pentadbir yang baik mempunyai beberapa perkara yang dikonfigurasikan dalam infrastruktur mereka yang log ini boleh diputar - rsyslog yang sama, yang melihat log ini dan apabila sesuatu berlaku kepada mereka, terdapat banyak daripada mereka, ia mencipta salinan sandaran , meletakkan log di sana , memadamkan fail lama, lebih daripada seminggu, enam bulan dan beberapa lagi. Secara teori, kita harus mempunyai peruntukan supaya hanya kerana aplikasi menulis log, ruang pada pelayan pengeluaran (pelayan pertempuran?) tidak kehabisan. Dan, oleh itu, keseluruhan pengeluaran tidak berhenti kerana balak.

Apabila kita beralih ke dunia Kubernetes dan menjalankan perkara yang sama di sana, perkara pertama yang anda boleh beri perhatian ialah hakikat bahawa orang, semasa mereka menulis log dalam fail, terus menulisnya.

Ternyata jika kita bercakap tentang Kubernetes, tempat yang tepat untuk menulis log di suatu tempat dari bekas docker adalah hanya dengan menulisnya dari aplikasi ke apa yang dipanggil Stdout/Stderr, iaitu, aliran keluaran standard sistem pengendalian, output ralat piawai. Ini adalah cara yang paling betul, paling mudah dan paling logik untuk meletakkan log secara prinsip dalam Docker dan khususnya dalam Kubernetis. Kerana jika aplikasi anda menulis log ke Stdout/Stderr, maka terpulang kepada Docker dan add-on Kubernetes untuk memutuskan perkara yang perlu dilakukan dengan log ini. Docker secara lalai akan membina fail khasnya dalam format JSON.

Di sini timbul persoalan, apakah yang akan anda lakukan seterusnya dengan log ini? Cara paling mudah adalah jelas, kita mempunyai keupayaan untuk melakukannya kubectl logs dan lihat log ini "pod" ini. Tetapi, mungkin, ini bukan pilihan yang sangat baik - sesuatu yang lain perlu dilakukan dengan log.

Buat masa ini, mari kita bercakap pada masa yang sama, memandangkan kita menyentuh topik log, tentang perkara yang sepatutnya kelihatan seperti log. Iaitu, ini tidak terpakai secara langsung kepada Kubernetes, tetapi apabila kita mula berfikir tentang apa yang perlu dilakukan dengan log, adalah baik untuk memikirkan perkara ini juga.

Kami memerlukan sejenis alat, dengan cara yang baik, yang akan membawa log ini yang docker kami masukkan ke dalam failnya dan menghantarnya ke suatu tempat. Pada umumnya, kami biasanya melancarkan beberapa jenis ejen di dalam Kubernetes dalam bentuk DaemonSet - pengumpul log, yang hanya diberitahu di mana log yang dikumpulkan oleh Docker berada. Dan ejen pengumpul ini hanya membawa mereka, mungkin juga entah bagaimana menghuraikan mereka sepanjang jalan, mungkin memperkaya mereka dengan beberapa meta-maklumat tambahan dan, akhirnya, menghantarnya untuk disimpan di suatu tempat. Variasi sudah ada di sana. Yang paling biasa ialah Elasticsearch, di mana anda boleh menyimpan log dan anda boleh mendapatkannya dengan mudah dari sana. Kemudian, menggunakan permintaan, menggunakan Kibana, sebagai contoh, bina graf berdasarkannya, bina makluman berdasarkannya, dan sebagainya.

Idea yang paling penting, saya ingin mengulanginya sekali lagi, ialah di dalam Docker, khususnya di dalam Kubernetes, menyimpan log anda dalam fail adalah idea yang sangat buruk.

Kerana pertama, sukar untuk mendapatkan log di dalam bekas dalam fail. Anda mesti terlebih dahulu masuk ke dalam bekas, laksanakan di sana, dan kemudian lihat pada log. Perkara seterusnya ialah jika anda mempunyai log dalam fail, maka bekas biasanya mempunyai persekitaran minimalis dan tiada utiliti yang biasanya diperlukan untuk kerja biasa dengan log. Kuburkan mereka, lihat mereka, buka mereka dalam editor teks. Detik seterusnya ialah apabila kita mempunyai log dalam fail di dalam bekas, jika bekas ini dipadamkan, anda faham, log akan mati bersama-sama dengannya. Sehubungan itu, sebarang permulaan semula bekas bermakna tiada lagi log. Sekali lagi, pilihan yang buruk.

Dan perkara terakhir ialah di dalam bekas anda biasanya mempunyai aplikasi anda dan itu sahaja - ia biasanya satu-satunya proses yang berjalan. Tiada perbincangan sama sekali tentang sebarang proses yang akan memutarkan fail dengan log anda. Sebaik sahaja log mula ditulis pada fail, ini bermakna, maafkan saya, kami akan mula kehilangan pelayan pengeluaran. Kerana, pertama, mereka sukar dicari, tiada siapa menjejakinya, ditambah tiada siapa yang mengawalnya - sewajarnya, fail itu berkembang tanpa henti sehingga ruang pada pelayan hanya kehabisan. Oleh itu, saya katakan sekali lagi bahawa log masuk Docker, khususnya dalam Kubernetes, ke fail adalah idea yang tidak baik.

Perkara seterusnya, di sini saya ingin bercakap tentang perkara ini sekali lagi - kerana kita menyentuh topik log, adalah baik untuk bercakap tentang bagaimana log harus kelihatan untuk memudahkan untuk bekerja dengan mereka. Seperti yang saya katakan, topik itu tidak berkaitan secara langsung dengan Kubernetes, tetapi ia sangat berkaitan dengan topik DevOps. Mengenai topik budaya pembangunan dan persahabatan antara dua jabatan berbeza ini - Dev dan Ops, supaya semua orang selesa.

Ini bermakna bahawa idealnya, hari ini, log harus ditulis dalam format JSON. Jika anda mempunyai beberapa aplikasi anda sendiri yang tidak dapat difahami, yang menulis log dalam format yang tidak dapat difahami kerana anda memasukkan beberapa jenis cetakan atau sesuatu seperti itu, maka sudah tiba masanya untuk google beberapa jenis rangka kerja, beberapa jenis pembungkus yang membolehkan anda melaksanakan pembalakan biasa; dayakan parameter pengelogan dalam JSON di sana, kerana JSON ialah format yang mudah, menghuraikannya adalah mudah.

Jika JSON anda tidak berfungsi mengikut beberapa kriteria, tiada siapa yang tahu, maka sekurang-kurangnya tulis log dalam format yang boleh dihuraikan. Di sini, sebaliknya, patut difikirkan tentang hakikat bahawa, sebagai contoh, jika anda menjalankan sekumpulan bekas atau hanya memproses dengan nginx, dan masing-masing mempunyai tetapan pembalakan sendiri, maka nampaknya ia akan menjadi sangat menyusahkan anda untuk menghuraikan mereka. Kerana untuk setiap contoh nginx baru anda perlu menulis parser anda sendiri, kerana mereka menulis log secara berbeza. Sekali lagi, mungkin patut difikirkan untuk memastikan semua contoh nginx ini mempunyai konfigurasi pengelogan yang sama dan menulis semua log mereka secara seragam. Perkara yang sama berlaku untuk semua aplikasi.

Pada akhirnya, saya juga ingin menambah bahan api kepada api yang, idealnya, log format berbilang baris harus dielakkan. Inilah perkaranya, jika anda pernah bekerja dengan pengumpul log, kemungkinan besar anda telah melihat apa yang mereka janjikan kepada anda, bahawa mereka boleh bekerja dengan log berbilang baris, tahu cara mengumpulnya, dan sebagainya. Malah, pada pendapat saya, tiada seorang pengumpul hari ini boleh mengumpul log berbilang talian secara normal, sepenuhnya dan tanpa ralat. Dengan cara manusia, supaya ia mudah dan bebas daripada kesilapan.

Tetapi jejak tindanan sentiasa log berbilang baris dan cara mengelakkannya. Persoalannya di sini ialah log ialah rekod peristiwa, dan stactrace sebenarnya bukan log. Jika kami mengumpul log dan meletakkannya di suatu tempat dalam Elasticsearch dan kemudian melukis graf daripadanya, membina beberapa laporan aktiviti pengguna di tapak anda, kemudian apabila anda mendapat jejak tindanan, ini bermakna sesuatu yang tidak dijangka sedang berlaku. situasi yang tidak dapat dikendalikan dalam aplikasi anda. Dan masuk akal untuk memuat naik surih tindanan secara automatik di suatu tempat ke dalam sistem yang boleh menjejakinya.

Ini adalah perisian (Sentri yang sama) yang dibuat khusus untuk berfungsi dengan surih tindanan. Ia boleh membuat tugasan automatik dengan serta-merta, menyerahkannya kepada seseorang, memberi amaran apabila stacttraces berlaku, mengumpulkan stacttraces ini mengikut satu jenis, dan sebagainya. Pada dasarnya, tidak masuk akal untuk bercakap tentang stactraces apabila kita bercakap tentang log, kerana ini, selepas semua, perkara yang berbeza dengan tujuan yang berbeza.

Konfigurasi

Seterusnya kita bercakap tentang konfigurasi dalam Kubernetes: apa yang perlu dilakukan dengannya dan bagaimana aplikasi dalam Kubernetes harus dikonfigurasikan. Secara umum, saya biasanya mengatakan bahawa Docker bukan tentang bekas. Semua orang tahu bahawa Docker adalah mengenai kontena, malah mereka yang tidak banyak bekerja dengan Docker. Saya ulangi, Docker bukan tentang kontena.

Docker, pada pendapat saya, adalah mengenai piawaian. Dan terdapat piawaian untuk hampir semua perkara: piawaian untuk membina aplikasi anda, piawaian untuk memasang aplikasi anda.

Dan perkara ini - kami menggunakannya sebelum ini, ia menjadi sangat popular dengan kemunculan bekas - perkara ini dipanggil pembolehubah ENV (persekitaran), iaitu pembolehubah persekitaran yang terdapat dalam sistem pengendalian anda. Ini biasanya merupakan cara yang ideal untuk mengkonfigurasi aplikasi anda, kerana jika anda mempunyai aplikasi dalam JAVA, Python, Go, Perl, Allah melarang, dan mereka semua boleh membaca hos pangkalan data, pengguna pangkalan data, pembolehubah kata laluan pangkalan data, maka ia adalah ideal. Anda mempunyai aplikasi dalam empat bahasa berbeza yang dikonfigurasikan dalam pelan pangkalan data dengan cara yang sama. Tiada lagi konfigurasi yang berbeza.

Semuanya boleh dikonfigurasikan menggunakan pembolehubah ENV. Apabila kita bercakap tentang Kubernetes, terdapat cara terbaik untuk mengisytiharkan pembolehubah ENV terus di dalam Deployment. Sehubungan itu, jika kita bercakap tentang data rahsia, maka kita boleh segera menolak data rahsia daripada pembolehubah ENV (kata laluan ke pangkalan data, dll.) menjadi rahsia, mencipta kluster rahsia dan menunjukkan dalam penerangan ENV dalam Deployment bahawa kita tidak mengisytiharkan secara langsung nilai pembolehubah ini, dan nilai pembolehubah kata laluan pangkalan data ini akan dibaca dari rahsia. Ini adalah tingkah laku Kubernetes standard. Dan ini adalah pilihan yang paling ideal untuk mengkonfigurasi aplikasi anda. Hanya pada peringkat kod, sekali lagi ini terpakai kepada pembangun. Jika anda DevOps, anda boleh bertanya: “Kawan-kawan, sila ajar aplikasi anda membaca pembolehubah persekitaran. Dan kita semua akan gembira."

Jika semua orang dalam syarikat membaca pembolehubah persekitaran bernama yang sama, maka itu bagus. Supaya tidak berlaku bahawa ada yang menunggu pangkalan data postgres, yang lain sedang menunggu nama pangkalan data, yang lain sedang menunggu sesuatu yang lain, yang lain sedang menunggu sejenis dbn, supaya, dengan itu, terdapat keseragaman.

Masalahnya timbul apabila anda mempunyai begitu banyak pembolehubah persekitaran sehingga anda hanya membuka Deployment - dan terdapat lima ratus baris pembolehubah persekitaran. Dalam kes ini, anda telah melampaui pembolehubah persekitaran - dan anda tidak perlu lagi menyeksa diri anda. Dalam kes ini, masuk akal untuk mula menggunakan konfigurasi. Iaitu, latih aplikasi anda untuk menggunakan konfigurasi.

Satu-satunya soalan ialah konfigurasi bukan seperti yang anda fikirkan. Config.pi bukan konfigurasi yang mudah digunakan. Atau beberapa konfigurasi dalam format anda sendiri, sebagai alternatif berbakat - ini juga bukan konfigurasi yang saya maksudkan.

Apa yang saya bincangkan ialah konfigurasi dalam format yang boleh diterima, iaitu, setakat ini standard yang paling popular ialah standard .yaml. Jelas cara membacanya, ia boleh dibaca oleh manusia, jelas cara membacanya dari aplikasi.

Sehubungan itu, sebagai tambahan kepada YAML, anda juga boleh, sebagai contoh, menggunakan JSON, penghuraian adalah semudah YAML dari segi membaca konfigurasi aplikasi dari sana. Ia nyata lebih menyusahkan orang untuk membaca. Anda boleh mencuba formatnya, ala ini. Ia agak mudah untuk dibaca, dari sudut pandangan manusia, tetapi mungkin menyusahkan untuk memprosesnya secara automatik, dalam erti kata jika anda ingin menjana konfigurasi anda sendiri, format ini mungkin sudah menyusahkan untuk dijana.

Tetapi dalam apa jua keadaan, apa jua format yang anda pilih, maksudnya ialah dari sudut pandangan Kubernetes ia sangat mudah. Anda boleh meletakkan keseluruhan konfigurasi anda di dalam Kubernetes, dalam ConfigMap. Dan kemudian ambil peta konfigurasi ini dan minta ia dipasang di dalam pod anda dalam beberapa direktori tertentu, di mana aplikasi anda akan membaca konfigurasi daripada peta konfigurasi ini seolah-olah ia hanya fail. Ini, sebenarnya, adalah perkara yang baik untuk dilakukan apabila anda mempunyai banyak pilihan konfigurasi dalam aplikasi anda. Atau ia hanya sejenis struktur kompleks, terdapat sarang.

Jika anda mempunyai peta konfigurasi, maka anda boleh mengajar aplikasi anda dengan baik, sebagai contoh, untuk mengesan perubahan secara automatik dalam fail di mana peta konfigurasi dipasang, dan juga memuatkan semula aplikasi anda secara automatik apabila konfigurasi berubah. Ini biasanya merupakan pilihan yang ideal.

Sekali lagi, saya sudah bercakap tentang ini - maklumat rahsia tiada dalam peta konfigurasi, maklumat rahsia tidak dalam pembolehubah, maklumat rahsia bukan dalam rahsia. Dari situ, sambungkan maklumat rahsia ini kepada diplomasi. Biasanya kami menyimpan semua perihalan objek Kubernetes, penempatan, peta konfigurasi, perkhidmatan dalam git. Oleh itu, meletakkan kata laluan ke pangkalan data dalam git, walaupun ia adalah git anda, yang anda ada secara dalaman dalam syarikat, adalah idea yang tidak baik. Kerana, sekurang-kurangnya, git mengingati segala-galanya dan hanya mengalih keluar kata laluan dari sana tidak begitu mudah.

Pemeriksaan kesihatan

Perkara seterusnya ialah perkara yang dipanggil pemeriksaan Kesihatan. Secara umum, pemeriksaan Kesihatan hanyalah menyemak sama ada aplikasi anda berfungsi. Pada masa yang sama, kami paling kerap bercakap tentang aplikasi web tertentu, yang, oleh itu, dari sudut pandangan pemeriksaan kesihatan (lebih baik tidak menterjemah di sini dan seterusnya) ini akan menjadi beberapa URL khas, yang mereka proses sebagai standard, biasanya mereka lakukan /health.

Apabila mengakses URL ini, sewajarnya, aplikasi kami berkata sama ada "ya, okey, semuanya baik-baik saja dengan saya, 200" atau "tidak, semuanya tidak baik dengan saya, kira-kira 500." Oleh itu, jika aplikasi kami bukan http, bukan aplikasi web, kami kini bercakap tentang sejenis daemon, kami boleh memikirkan cara melakukan pemeriksaan kesihatan. Iaitu, tidak perlu, jika permohonan itu bukan http, maka semuanya berfungsi tanpa pemeriksaan kesihatan dan ini tidak boleh dilakukan dengan cara apa pun. Anda boleh mengemas kini beberapa maklumat dalam fail secara berkala, anda boleh menghasilkan beberapa arahan khas untuk daemon anda, seperti, daemon status, yang akan berkata "ya, semuanya baik-baik saja, daemon berfungsi, ia masih hidup."

Untuk apa itu? Perkara pertama dan paling jelas adalah mengapa pemeriksaan kesihatan diperlukan - untuk memahami bahawa aplikasi itu berfungsi. Maksud saya, ia hanya bodoh, apabila ia muncul sekarang, ia kelihatan seperti ia berfungsi, jadi anda boleh yakin bahawa ia berfungsi. Dan ternyata aplikasi sedang berjalan, bekas sedang berjalan, contoh berfungsi, semuanya baik-baik saja - dan kemudian pengguna telah memotong semua nombor telefon daripada sokongan teknikal dan berkata "apakah anda..., anda tertidur, tiada apa yang berfungsi.”

Pemeriksaan kesihatan hanyalah satu cara untuk melihat dari sudut pandangan pengguna bahawa ia berfungsi. Salah satu kaedah. Mari kita letakkannya seperti ini. Dari sudut pandangan Kubernetes, ini juga merupakan satu cara untuk memahami apabila aplikasi bermula, kerana kami memahami bahawa terdapat perbezaan antara apabila bekas itu dilancarkan, dicipta dan dimulakan, dan apabila aplikasi itu dilancarkan terus dalam bekas ini. Kerana jika kita mengambil beberapa aplikasi java purata dan cuba melancarkannya di dok, maka selama empat puluh saat, atau seminit, atau sepuluh, ia boleh bermula dengan baik. Dalam kes ini, anda sekurang-kurangnya boleh mengetuk pelabuhannya, ia tidak akan menjawab di sana, iaitu, ia belum bersedia untuk menerima lalu lintas.

Sekali lagi, dengan bantuan pemeriksaan kesihatan dan dengan bantuan fakta bahawa kita beralih ke sini, kita dapat memahami di Kubernetes bahawa bukan sahaja bekas telah meningkat dalam aplikasi, tetapi aplikasi itu sendiri telah bermula, ia sudah bertindak balas kepada pemeriksaan kesihatan, bermakna kita boleh menghantar trafik ke sana.

Apa yang saya bincangkan sekarang dipanggil ujian Kesediaan/Kehidupan dalam Kubernetes; oleh itu, ujian kesediaan kami bertanggungjawab untuk ketersediaan aplikasi dalam pengimbangan. Iaitu, jika ujian kesediaan dilakukan dalam aplikasi, maka semuanya ok, lalu lintas pelanggan akan pergi ke aplikasi. Sekiranya ujian kesediaan tidak dilakukan, maka aplikasi itu tidak mengambil bahagian, contoh khusus ini tidak mengambil bahagian dalam pengimbangan, ia dikeluarkan daripada pengimbangan, lalu lintas pelanggan tidak mengalir. Sehubungan itu, ujian Liveness dalam Kubernetes diperlukan supaya jika aplikasi tersekat, ia boleh dimulakan semula. Jika ujian liveness tidak berfungsi untuk aplikasi yang diisytiharkan dalam Kubernetes, maka aplikasi itu bukan sahaja dialih keluar daripada pengimbangan, ia dimulakan semula.

Dan inilah perkara penting yang ingin saya nyatakan: dari sudut praktikal, ujian kesediaan biasanya digunakan lebih kerap dan lebih kerap diperlukan daripada ujian keaktifan. Iaitu, hanya mengisytiharkan ujian kesediaan dan keaktifan secara tidak sengaja, kerana Kubernetes boleh melakukannya, dan mari kita gunakan semua yang boleh dilakukannya, bukanlah idea yang sangat baik. Saya akan menerangkan sebabnya. Kerana perkara nombor dua dalam ujian ialah idea yang baik untuk memeriksa perkhidmatan asas dalam pemeriksaan kesihatan anda. Ini bermakna jika anda mempunyai aplikasi web yang memberikan beberapa maklumat, yang pada gilirannya, secara semula jadi, mesti diambil dari suatu tempat. Dalam pangkalan data, sebagai contoh. Nah, ia menyimpan maklumat yang masuk ke dalam REST API ini ke dalam pangkalan data yang sama. Kemudian, sewajarnya, jika pemeriksaan kesihatan anda bertindak balas seperti slashhealth yang dihubungi, aplikasi menyatakan "200, okey, semuanya baik-baik saja," dan pada masa yang sama pangkalan data aplikasi anda tidak boleh diakses dan aplikasi pemeriksaan kesihatan berkata "200, okey, semuanya baik-baik saja. ” - Ini adalah pemeriksaan kesihatan yang tidak baik. Ini bukan cara ia sepatutnya berfungsi.

Iaitu, permohonan anda, apabila permintaan datang kepadanya /health, ia bukan sahaja bertindak balas, "200, ok", ia mula-mula pergi, sebagai contoh, ke pangkalan data, cuba menyambung kepadanya, melakukan sesuatu yang sangat asas di sana, seperti pilih satu, hanya menyemak sama ada terdapat sambungan dalam pangkalan data dan anda boleh menanyakan pangkalan data. Jika semua ini berjaya, maka jawapannya ialah "200, ok." Jika ia tidak berjaya, ia mengatakan bahawa terdapat ralat, pangkalan data tidak tersedia.

Oleh itu, dalam hal ini, saya sekali lagi kembali kepada ujian Kesediaan/Kehidupan - mengapa anda berkemungkinan besar memerlukan ujian kesediaan, tetapi ujian keaktifan menjadi persoalan. Kerana jika anda menerangkan pemeriksaan kesihatan dengan tepat seperti yang saya katakan tadi, maka ternyata ia tidak tersedia di bahagian contohв или со всех instancedalam pangkalan data, contohnya. Apabila anda mengisytiharkan ujian kesediaan, pemeriksaan kesihatan kami mula gagal, dan oleh itu semua aplikasi yang pangkalan datanya tidak boleh diakses, ia hanya dimatikan daripada pengimbangan dan sebenarnya "hang" hanya dalam keadaan diabaikan dan menunggu pangkalan data mereka untuk kerja.

Jika kami telah mengisytiharkan ujian liveness, maka bayangkan, pangkalan data kami telah rosak, dan dalam Kubernetes anda separuh daripada segala-galanya mula dimulakan semula kerana ujian liveness gagal. Ini bermakna anda perlu memulakan semula. Ini sama sekali bukan apa yang anda mahukan, malah saya mempunyai pengalaman peribadi dalam amalan. Kami mempunyai aplikasi sembang yang ditulis dalam JS dan dimasukkan ke dalam pangkalan data Mongo. Dan masalahnya ialah pada permulaan kerja saya dengan Kubernetes, kami menerangkan kesediaan, keaktifan ujian berdasarkan prinsip bahawa Kubernetes boleh melakukannya, jadi kami akan menggunakannya. Sehubungan itu, pada satu ketika Mongo menjadi sedikit "membosankan" dan sampel mula gagal. Oleh itu, mengikut ujian hujan, buah mula "membunuh".

Seperti yang anda faham, apabila mereka "dibunuh", ini adalah sembang, iaitu, terdapat banyak sambungan daripada pelanggan yang bergantung padanya. Mereka juga "dibunuh" - tidak, bukan pelanggan, hanya sambungan - bukan semua pada masa yang sama, dan disebabkan fakta bahawa mereka tidak dibunuh pada masa yang sama, beberapa lebih awal, beberapa kemudian, mereka tidak bermula pada masa yang sama masa. Selain rawak standard, kami tidak boleh meramalkan dengan ketepatan milisaat masa mula aplikasi setiap kali, jadi mereka melakukannya satu kejadian pada satu masa. Satu titik info meningkat, ditambah kepada pengimbangan, semua pelanggan datang ke sana, ia tidak dapat menahan beban sedemikian, kerana ia bersendirian, dan, secara kasarnya, terdapat sedozen daripada mereka bekerja di sana, dan ia jatuh. Yang seterusnya naik, seluruh beban ditanggungnya, dia juga jatuh. Nah, air terjun ini terus mengalir. Pada akhirnya, bagaimana perkara ini diselesaikan - kami hanya perlu menghentikan trafik pengguna ke aplikasi ini dengan ketat, biarkan semua kejadian meningkat dan kemudian mulakan semua trafik pengguna sekaligus supaya ia telah diedarkan dalam kesemua sepuluh kejadian.

Jika bukan kerana ujian keceriaan ini diumumkan, yang akan memaksa semuanya untuk dimulakan semula, aplikasi akan mengendalikannya dengan baik. Tetapi segala-galanya daripada pengimbangan dilumpuhkan untuk kami, kerana pangkalan data tidak boleh diakses dan semua pengguna telah "jatuh". Kemudian, apabila pangkalan data ini tersedia, semuanya termasuk dalam pengimbangan, tetapi aplikasi tidak perlu dimulakan semula, dan tidak perlu membuang masa dan sumber untuk perkara ini. Mereka semua sudah berada di sini, mereka sudah bersedia untuk lalu lintas, jadi trafik hanya dibuka, semuanya baik-baik saja - aplikasi sudah ada, semuanya terus berfungsi.

Oleh itu, ujian kesediaan dan keceriaan adalah berbeza, malah lebih-lebih lagi, anda secara teorinya boleh melakukan pemeriksaan kesihatan yang berbeza, satu jenis jejari, satu jenis liv, contohnya, dan memeriksa perkara yang berbeza. Semasa ujian kesediaan, semak hujung belakang anda. Dan pada ujian keaktifan, sebagai contoh, anda tidak menyemak dari sudut pandangan bahawa ujian keaktifan secara amnya hanyalah aplikasi yang bertindak balas, jika ia dapat bertindak balas sama sekali.

Kerana ujian keaktifan, pada umumnya, adalah apabila kita "terperangkap." Gelung tidak berkesudahan telah bermula atau sesuatu yang lain - dan tiada lagi permintaan diproses. Oleh itu, masuk akal untuk memisahkannya - dan melaksanakan logik yang berbeza di dalamnya.

Mengenai apa yang anda perlu jawab apabila anda menjalani ujian, apabila anda melakukan pemeriksaan kesihatan. Ia benar-benar sakit. Mereka yang biasa dengan ini mungkin akan ketawa - tetapi serius, saya telah melihat perkhidmatan dalam hidup saya yang menjawab "200" dalam XNUMX% kes. Iaitu, siapa yang berjaya. Tetapi pada masa yang sama dalam badan respons mereka menulis "ralat ini dan itu."

Iaitu, status respons datang kepada anda - semuanya berjaya. Tetapi pada masa yang sama, anda mesti menghuraikan badan, kerana badan itu berkata "maaf, permintaan itu berakhir dengan ralat" dan ini hanya realiti. Saya melihat ini dalam kehidupan sebenar.

Dan supaya sesetengah orang tidak menganggapnya lucu, dan yang lain merasa sangat menyakitkan, ia masih berbaloi untuk mematuhi peraturan mudah. Dalam pemeriksaan kesihatan, dan pada dasarnya apabila bekerja dengan aplikasi web.

Jika semuanya berjalan lancar, balas dengan dua ratus jawapan. Pada dasarnya, mana-mana jawapan dua ratus akan sesuai dengan anda. Jika anda membaca ragsy dengan baik dan mengetahui bahawa sesetengah status respons berbeza daripada yang lain, jawab dengan yang sesuai: 204, 5, 10, 15, apa sahaja. Jika ia tidak begitu baik, maka hanya "dua sifar sifar." Jika semuanya berjalan dengan teruk dan pemeriksaan kesihatan tidak bertindak balas, maka jawab dengan mana-mana lima ratus. Sekali lagi, jika anda memahami cara membalas, bagaimana status respons berbeza berbeza antara satu sama lain. Jika anda tidak faham, maka 502 ialah pilihan anda untuk bertindak balas kepada pemeriksaan kesihatan jika berlaku masalah.

Ini adalah satu lagi perkara, saya ingin kembali sedikit tentang menyemak perkhidmatan asas. Jika anda mula, sebagai contoh, menyemak semua perkhidmatan asas yang berdiri di belakang aplikasi anda - semuanya secara umum. Apa yang kami dapat dari sudut pandangan seni bina perkhidmatan mikro, kami mempunyai konsep seperti "gandingan rendah" - iaitu, apabila perkhidmatan anda bergantung pada satu sama lain secara minimum. Jika salah satu daripadanya gagal, semua yang lain tanpa fungsi ini hanya akan terus berfungsi. Sesetengah fungsi tidak berfungsi. Oleh itu, jika anda mengikat semua pemeriksaan kesihatan antara satu sama lain, maka anda akan berakhir dengan satu perkara yang jatuh dalam infrastruktur, dan kerana ia jatuh, semua pemeriksaan kesihatan semua perkhidmatan juga mula gagal - dan terdapat lebih banyak infrastruktur secara umum untuk keseluruhan seni bina perkhidmatan mikro No. Semuanya menjadi gelap di sana.

Oleh itu, saya ingin mengulangi ini sekali lagi bahawa anda perlu menyemak perkhidmatan asas, yang tanpanya permohonan anda dalam seratus peratus kes tidak dapat menjalankan tugasnya. Iaitu, adalah logik bahawa jika anda mempunyai API REST di mana pengguna menyimpan ke pangkalan data atau mendapatkan semula dari pangkalan data, maka jika tiada pangkalan data, anda tidak dapat menjamin berfungsi dengan pengguna anda.

Tetapi jika pengguna anda, apabila anda mengeluarkan mereka daripada pangkalan data, diperkayakan dengan beberapa metadata lain, daripada bahagian belakang yang lain, yang anda masukkan sebelum menghantar respons kepada bahagian hadapan - dan bahagian belakang ini tidak tersedia, ini bermakna anda memberikan anda jawab tanpa sebarang bahagian metadata.

Seterusnya, kami juga mempunyai salah satu isu yang menyakitkan apabila melancarkan aplikasi.

Sebenarnya, ini bukan sahaja terpakai kepada Kubernetes pada umumnya; kebetulan budaya beberapa jenis pembangunan besar-besaran dan DevOps khususnya mula merebak pada masa yang sama seperti Kubernetes. Oleh itu, secara keseluruhannya, ternyata anda perlu menutup aplikasi anda dengan anggun tanpa Kubernetes. Walaupun sebelum Kubernetes, orang ramai melakukan ini, tetapi dengan kemunculan Kubernetes, kami mula bercakap mengenainya secara besar-besaran.

Penutupan Anggun

Secara umum, apakah itu Graceful Shutdown dan mengapa ia diperlukan? Ini mengenai apabila aplikasi anda ranap atas sebab tertentu, anda perlu lakukan app stop - atau anda menerima, sebagai contoh, isyarat daripada sistem pengendalian, aplikasi anda mesti memahaminya dan melakukan sesuatu mengenainya. Senario kes terburuk, sudah tentu, adalah apabila permohonan anda menerima SIGTERM dan seperti "SIGTERM, mari kita teruskan, bekerja, tidak melakukan apa-apa." Ini adalah pilihan yang sangat buruk.

Pilihan yang hampir sama buruk ialah apabila permohonan anda menerima SIGTERM dan seperti "mereka berkata segterm, itu bermakna kita akan tamat, saya tidak melihat, saya tidak tahu apa-apa permintaan pengguna, saya tidak tahu apa jenis permintaan yang saya sedang usahakan sekarang, mereka berkata SIGTERM, itu bermakna kita akan tamat " Ini juga merupakan pilihan yang tidak baik.

Pilihan mana yang bagus? Perkara pertama adalah untuk mengambil kira penyiapan operasi. Pilihan yang baik adalah untuk pelayan anda masih mengambil kira tindakan yang dilakukan jika ia menerima SIGTERM.

SIGTERM adalah soft shutdown, ia direka khas, ia boleh dipintas pada tahap kod, ia boleh diproses, katakan sekarang, tunggu, kita akan selesaikan kerja yang kita ada, kemudian kita akan keluar.

Dari perspektif Kubernetes, inilah rupanya. Apabila kita berkata kepada pod yang berjalan dalam gugusan Kubernetes, "sila berhenti, pergi," atau mulakan semula berlaku, atau kemas kini berlaku apabila Kubernetes mencipta semula pod, Kubernetes menghantar hanya mesej SIGTERM yang sama kepada pod, menunggu beberapa masa, dan , ini adalah masa yang dia tunggu, ia juga dikonfigurasikan, terdapat parameter khas dalam diploma dan ia dipanggil Graceful ShutdownTimeout. Seperti yang anda faham, ia tidak dipanggil begitu sahaja, dan bukan sia-sia kita bercakap mengenainya sekarang.

Di sana kami secara khusus boleh menyatakan berapa lama kami perlu menunggu antara masa kami menghantar SIGTERM ke aplikasi dan apabila kami memahami bahawa aplikasi itu kelihatan gila untuk sesuatu atau "terperangkap" dan tidak akan tamat - dan kami perlu hantar SIGKILL, iaitu, selesaikan kerjanya dengan susah payah. Iaitu, sewajarnya, kami mempunyai sejenis daemon yang sedang berjalan, ia memproses operasi. Kami faham bahawa secara purata operasi kami yang daemon berfungsi tidak bertahan lebih daripada 30 saat pada satu masa. Sehubungan itu, apabila SIGTERM tiba, kami faham bahawa daemon kami boleh, paling banyak, menamatkan 30 saat selepas SIGTERM. Kami menulisnya, sebagai contoh, 45 saat untuk berjaga-jaga dan mengatakan bahawa SIGTERM. Selepas itu kita tunggu 45 saat. Secara teori, pada masa ini syaitan sepatutnya telah menyelesaikan kerjanya dan menamatkan dirinya sendiri. Tetapi jika tiba-tiba ia tidak dapat, ini bermakna ia kemungkinan besar tersekat-ia tidak lagi memproses permintaan kami seperti biasa. Dan dalam 45 saat anda boleh dengan selamat, sebenarnya, memaku dia.

Dan di sini, sebenarnya, 2 aspek pun boleh diambil kira. Pertama, fahami bahawa jika anda menerima permintaan, anda mula bekerja dengannya entah bagaimana dan tidak memberikan respons kepada pengguna, tetapi anda menerima SIGTERM, sebagai contoh. Masuk akal untuk memperhalusinya dan memberikan jawapan kepada pengguna. Ini adalah perkara nombor satu dalam hal ini. Perkara nombor dua di sini ialah jika anda menulis aplikasi anda sendiri, secara amnya membina seni bina sedemikian rupa sehingga anda menerima permintaan untuk aplikasi anda, kemudian anda memulakan kerja, mula memuat turun fail dari suatu tempat, memuat turun pangkalan data, dan sebagainya. - Itu. Secara umum, pengguna anda, permintaan anda digantung selama setengah jam dan menunggu anda menjawabnya - maka, kemungkinan besar, anda perlu mengusahakan seni bina. Iaitu, hanya mengambil kira walaupun akal fikiran bahawa jika operasi anda pendek, maka masuk akal untuk mengabaikan SIGTERM dan mengubah suainya. Jika operasi anda panjang, maka tidak masuk akal untuk mengabaikan SIGTERM dalam kes ini. Adalah wajar untuk mereka bentuk semula seni bina untuk mengelakkan operasi yang begitu lama. Supaya pengguna tidak hanya berdiam diri dan menunggu. Saya tidak tahu, buat beberapa jenis websocket di sana, buat cangkuk terbalik yang pelayan anda akan hantar kepada pelanggan, apa-apa lagi, tetapi jangan paksa pengguna untuk menggantung selama setengah jam dan hanya menunggu sesi sehingga anda jawab dia. Kerana ia tidak dapat diramalkan di mana ia mungkin pecah.

Apabila permohonan anda ditamatkan, anda harus memberikan beberapa kod keluar yang sesuai. Iaitu, jika permohonan anda diminta untuk menutup, berhenti, dan ia dapat berhenti sendiri secara normal, maka anda tidak perlu mengembalikan beberapa jenis kod keluar 1,5,255 dan seterusnya. Apa-apa sahaja yang bukan kod sifar, sekurang-kurangnya dalam sistem Linux, saya pasti ini, dianggap tidak berjaya. Iaitu, dianggap bahawa permohonan anda dalam kes ini berakhir dengan ralat. Oleh itu, dengan cara yang baik, jika permohonan anda selesai tanpa ralat, anda menyebut 0 pada output. Jika aplikasi anda gagal atas sebab tertentu, anda katakan bukan 0 dalam output. Dan anda boleh bekerja dengan maklumat ini.

Dan pilihan terakhir. Ia buruk apabila pengguna anda menghantar permintaan dan digantung selama setengah jam semasa anda memprosesnya. Tetapi secara umum, saya juga ingin mengatakan tentang perkara yang secara amnya berbaloi dari pihak pelanggan. Tidak kira jika anda mempunyai aplikasi mudah alih, bahagian hadapan, dsb. Adalah perlu untuk mengambil kira bahawa sesi pengguna boleh ditamatkan, apa-apa boleh berlaku. Permintaan mungkin dihantar, contohnya, kurang diproses dan tiada balasan dikembalikan. Bahagian hadapan anda atau aplikasi mudah alih anda - mana-mana bahagian hadapan secara umum, katakan seperti itu - harus mengambil kira perkara ini. Jika anda menggunakan soket web, ini biasanya kesakitan yang paling teruk pernah saya alami.

Apabila pembangun beberapa sembang biasa tidak tahu itu, ternyata, soket web boleh pecah. Bagi mereka, apabila sesuatu berlaku pada proksi, kami hanya menukar konfigurasi, dan ia melakukan muat semula. Sememangnya, semua sesi berpanjangan terkoyak dalam kes ini. Pembangun datang berlari kepada kami dan berkata: "Kawan-kawan, apa yang anda lakukan, sembang telah rosak untuk semua pelanggan kami!" Kami memberitahu mereka: “Apa yang kamu lakukan? Adakah pelanggan anda tidak dapat menyambung semula? Mereka berkata: "Tidak, kami memerlukan sesi untuk tidak dikoyakkan." Pendek kata, ini sebenarnya mengarut. Pihak pelanggan perlu diambil kira. Terutama, seperti yang saya katakan, dengan sesi berpanjangan seperti websocket, ia boleh pecah dan, tanpa disedari oleh pengguna, anda perlu dapat memasang semula sesi tersebut. Dan kemudian semuanya sempurna.

Ресурсы

Sebenarnya, di sini saya hanya akan memberitahu anda cerita lurus. Sekali lagi dari kehidupan sebenar. Perkara paling menyakitkan yang pernah saya dengar tentang sumber.

Sumber dalam kes ini, maksud saya, beberapa jenis permintaan, had yang boleh anda letakkan pada pod dalam kelompok Kubernetes anda. Perkara paling kelakar yang saya dengar daripada pembangun... Salah seorang rakan pembangun saya di tempat kerja sebelumnya pernah berkata: "Aplikasi saya tidak akan bermula dalam kelompok." Saya melihat untuk melihat bahawa ia tidak bermula, tetapi sama ada ia tidak sesuai dengan sumber, atau mereka telah menetapkan had yang sangat kecil. Ringkasnya, aplikasi tidak boleh dimulakan kerana sumber. Saya berkata: "Ia tidak akan bermula kerana sumber, anda tentukan jumlah yang anda perlukan dan tetapkan nilai yang mencukupi." Dia berkata: "Apakah jenis sumber?" Saya mula menerangkan kepadanya bahawa Kubernetes, had pada permintaan dan bla,bla,bla perlu ditetapkan. Lelaki itu mendengar selama lima minit, mengangguk dan berkata: “Saya datang ke sini untuk bekerja sebagai pemaju, saya tidak mahu tahu apa-apa tentang sebarang sumber. Saya datang ke sini untuk menulis kod dan itu sahaja." memang sedih. Ini adalah konsep yang sangat menyedihkan dari sudut pandangan pemaju. Terutamanya dalam dunia moden, boleh dikatakan, devops progresif.

Mengapa sumber diperlukan sama sekali? Terdapat 2 jenis sumber dalam Kubernetes. Ada yang dipanggil permintaan, yang lain dipanggil had. Dengan sumber kita akan memahami bahawa pada dasarnya hanya terdapat dua sekatan asas. Iaitu, had masa CPU dan had RAM untuk bekas yang berjalan dalam Kubernetes.

Had meletakkan had atas tentang cara sumber boleh digunakan dalam aplikasi anda. Iaitu, sewajarnya, jika anda mengatakan 1GB RAM dalam had, maka aplikasi anda tidak akan dapat menggunakan lebih daripada 1GB RAM. Dan jika dia tiba-tiba mahu dan cuba melakukan ini, maka proses yang dipanggil oom killer, kehabisan ingatan, iaitu, akan datang dan membunuh aplikasi anda - iaitu, ia hanya akan dimulakan semula. Aplikasi tidak akan dimulakan semula berdasarkan CPU. Dari segi CPU, jika aplikasi cuba menggunakan banyak, lebih daripada yang ditentukan dalam had, CPU hanya akan dipilih dengan ketat. Ini tidak membawa kepada dimulakan semula. Ini adalah had - ini adalah had atas.

Dan ada permintaan. Permintaan ialah cara Kubernetes memahami cara nod dalam kelompok Kubernetes anda diisi dengan aplikasi. Iaitu, permintaan adalah sejenis komitmen permohonan anda. Ia menyatakan perkara yang saya mahu gunakan: "Saya ingin anda menempah CPU sebanyak ini dan memori sebanyak ini untuk saya." Analogi yang begitu mudah. Bagaimana jika kita mempunyai nod yang mempunyai, saya tidak tahu, 8 CPU secara keseluruhan. Dan pod tiba di sana, yang permintaannya menyatakan 1 CPU, yang bermaksud nod mempunyai 7 CPU yang tinggal. Iaitu, dengan sewajarnya, sebaik sahaja 8 pod tiba di nod ini, setiap satunya mempunyai 1 CPU dalam permintaan mereka, nod itu, seolah-olah dari sudut pandangan Kubernetes, telah kehabisan CPU dan lebih banyak pod dengan permintaan tidak boleh dilancarkan pada nod ini. Jika semua nod kehabisan CPU, maka Kubernetes akan mula mengatakan bahawa tiada nod yang sesuai dalam kluster untuk menjalankan pod anda kerana CPU telah kehabisan.

Mengapa permintaan diperlukan dan mengapa tanpa permintaan, saya rasa tidak perlu melancarkan apa-apa dalam Kubernetes? Mari kita bayangkan situasi hipotesis. Anda melancarkan aplikasi anda tanpa permintaan, Kubernetes tidak tahu berapa banyak yang anda ada, nod apa yang boleh anda tolak. Nah, dia menolak, menolak, menolak ke nod. Pada satu ketika, anda akan mula mendapat trafik ke aplikasi anda. Dan salah satu aplikasi tiba-tiba mula menggunakan sumber sehingga had yang ada mengikut had. Ternyata terdapat aplikasi lain yang berdekatan dan ia juga memerlukan sumber. Nod sebenarnya mula kehabisan sumber secara fizikal, contohnya, OP. Nod sebenarnya mula kehabisan sumber secara fizikal, contohnya, memori akses rawak (RAM). Apabila nod kehabisan kuasa, pertama sekali docker akan berhenti bertindak balas, kemudian cubelet, kemudian OS. Mereka hanya akan tidak sedarkan diri dan SEMUANYA pasti akan berhenti bekerja untuk anda. Iaitu, ini akan menyebabkan nod anda tersekat dan anda perlu memulakannya semula. Pendek kata, keadaan tidak begitu baik.

Dan apabila anda mempunyai permintaan, hadnya tidak begitu berbeza, sekurang-kurangnya tidak berkali-kali lebih daripada had atau permintaan, maka anda boleh mempunyai pengisian aplikasi yang biasa dan rasional merentas nod kelompok Kubernetes. Pada masa yang sama, Kubernetes lebih kurang mengetahui berapa banyak perkara yang ia letakkan di mana, berapa banyak perkara yang digunakan di mana. Iaitu, ia hanya seketika. Adalah penting untuk memahaminya. Dan adalah penting untuk mengawal bahawa ini ditunjukkan.

Simpanan data

Perkara seterusnya ialah mengenai penyimpanan data. Apa yang perlu dilakukan dengan mereka dan secara umum, apa yang perlu dilakukan dengan kegigihan dalam Kubernetes?

Saya fikir, sekali lagi, dalam kita Sekolah Petang, terdapat topik tentang pangkalan data dalam Kubernetes. Dan saya rasa saya tahu secara kasar apa yang rakan sekerja anda memberitahu anda apabila ditanya: "Adakah mungkin untuk menjalankan pangkalan data dalam Kubernetes?" Atas sebab tertentu, nampaknya rakan sekerja anda sepatutnya memberitahu anda bahawa jika anda bertanya soalan sama ada mungkin untuk menjalankan pangkalan data dalam Kubernetes, maka adalah mustahil.

Logiknya di sini adalah mudah. Untuk berjaga-jaga, saya akan menerangkan sekali lagi, jika anda seorang lelaki yang sangat hebat yang boleh membina sistem storan rangkaian teragih yang cukup bertolak ansur, memahami cara untuk memuatkan pangkalan data ke dalam kes ini dan cara asli awan dalam bekas harus berfungsi dalam pangkalan data secara umum. Kemungkinan besar, anda tidak mempunyai soalan tentang cara menjalankannya. Jika anda mempunyai soalan sedemikian, dan anda ingin memastikan bahawa semuanya terungkap dan bertahan hingga mati dalam pengeluaran dan tidak pernah jatuh, maka ini tidak berlaku. Anda dijamin akan menembak kaki anda sendiri dengan pendekatan ini. Oleh itu, lebih baik tidak.

Apakah yang perlu kami lakukan dengan data yang ingin disimpan oleh aplikasi kami, beberapa gambar yang dimuat naik oleh pengguna, beberapa perkara yang dijana oleh aplikasi kami semasa operasinya, pada permulaan, contohnya? Apa yang perlu dilakukan dengan mereka di Kubernetes?

Secara umum, idealnya, ya, sudah tentu, Kubernetes direka dengan sangat baik dan pada umumnya pada mulanya difikirkan untuk aplikasi tanpa kewarganegaraan. Iaitu, untuk aplikasi yang tidak menyimpan maklumat sama sekali. Ini adalah ideal.

Tetapi, tentu saja, pilihan yang ideal tidak selalu wujud. Jadi apa? Perkara pertama dan paling mudah ialah mengambil beberapa jenis S3, cuma bukan yang buatan sendiri, yang juga tidak jelas cara ia berfungsi, tetapi daripada beberapa pembekal. Pembekal yang baik dan biasa - dan ajar aplikasi anda menggunakan S3. Iaitu, apabila pengguna anda ingin memuat naik fail, sebut "di sini, sila muat naik ke S3." Apabila dia ingin menerimanya, katakan: "Ini adalah pautan ke S3 kembali dan ambil dari sini." Ini adalah ideal.

Jika tiba-tiba atas sebab tertentu pilihan ideal ini tidak sesuai, anda mempunyai aplikasi yang anda tidak tulis, anda tidak membangunkan, atau ia adalah sejenis warisan yang dahsyat, ia tidak boleh menggunakan protokol S3, tetapi mesti berfungsi dengan direktori tempatan dalam folder tempatan. Ambil sesuatu yang lebih atau kurang mudah, gunakan Kubernetes. Iaitu, segera memagar Ceph untuk beberapa tugas yang minimum, nampaknya saya, adalah idea yang tidak baik. Kerana Ceph, sudah tentu, baik dan bergaya. Tetapi jika anda tidak benar-benar memahami apa yang anda lakukan, maka sebaik sahaja anda meletakkan sesuatu pada Ceph, anda boleh dengan mudah dan tidak akan dapat keluar dari sana lagi. Kerana, seperti yang anda tahu, Ceph menyimpan data dalam kelompoknya dalam bentuk binari, dan bukan dalam bentuk fail mudah. Oleh itu, jika tiba-tiba kluster Ceph rosak, maka terdapat kebarangkalian yang lengkap dan tinggi bahawa anda tidak akan mendapat data anda dari sana lagi.

Kami akan mengadakan kursus tentang Ceph, anda boleh membiasakan diri dengan program dan mengemukakan permohonan.

Oleh itu, adalah lebih baik untuk melakukan sesuatu yang mudah seperti pelayan NFS. Kubernetes boleh bekerja dengan mereka, anda boleh melekapkan direktori di bawah pelayan NFS - aplikasi anda sama seperti direktori tempatan. Pada masa yang sama, secara semulajadi, anda perlu memahami bahawa, sekali lagi, anda perlu melakukan sesuatu dengan NFS anda, anda perlu memahami bahawa kadang-kadang ia mungkin menjadi tidak dapat diakses dan mempertimbangkan persoalan tentang apa yang akan anda lakukan dalam kes ini. Mungkin ia perlu disandarkan di suatu tempat pada mesin yang berasingan.

Perkara seterusnya yang saya bincangkan ialah apa yang perlu dilakukan jika aplikasi anda menjana beberapa fail semasa operasi. Contohnya, apabila ia bermula, ia menjana beberapa fail statik, yang berdasarkan beberapa maklumat yang diterima aplikasi hanya pada masa pelancaran. sekejap je. Sekiranya tidak banyak data sedemikian, maka anda tidak perlu bersusah payah sama sekali, hanya pasang aplikasi ini untuk diri sendiri dan bekerja. Satu-satunya soalan di sini ialah apa, lihat. Selalunya, semua jenis sistem warisan, seperti WordPress dan sebagainya, terutamanya dengan beberapa jenis pemalam pintar yang diubah suai, pembangun PHP yang bijak, mereka sering tahu cara membuatnya supaya mereka menjana beberapa jenis fail untuk diri mereka sendiri. Sehubungan itu, satu menjana satu fail, yang kedua menjana fail kedua. Mereka berbeza. Pengimbangan berlaku dalam kelompok Kubernetes pelanggan secara kebetulan. Oleh itu, ternyata mereka tidak tahu bagaimana untuk bekerja bersama sebagai contoh. Satu memberikan satu maklumat, yang lain memberi pengguna maklumat lain. Ini adalah sesuatu yang anda harus elakkan. Iaitu, dalam Kubernetes, semua yang anda lancarkan dijamin boleh berfungsi dalam beberapa keadaan. Kerana Kubernetes adalah sesuatu yang bergerak. Oleh itu, dia boleh memindahkan apa sahaja, bila-bila masa dia mahu, tanpa meminta sesiapa pun. Oleh itu, anda perlu mengira ini. Semua yang dilancarkan dalam satu kejadian lambat laun akan gagal. Lebih banyak tempahan anda, lebih baik. Tetapi sekali lagi, saya katakan, jika anda mempunyai beberapa fail sedemikian, maka anda boleh meletakkannya betul-betul di bawah anda, ia mempunyai berat sedikit. Jika terdapat lebih sedikit daripadanya, anda mungkin tidak sepatutnya menolaknya ke dalam bekas.

Saya akan menasihatkan bahawa terdapat perkara yang menarik di Kubernetes, anda boleh menggunakan kelantangan. Khususnya, terdapat kelantangan jenis dir kosong. Maksudnya, Kubernetes akan membuat direktori secara automatik dalam direktori perkhidmatannya pada pelayan tempat anda bermula. Dan dia akan memberikannya kepada anda supaya anda boleh menggunakannya. Hanya ada satu perkara penting. Iaitu, data anda tidak akan disimpan di dalam bekas, sebaliknya pada hos yang anda jalankan. Selain itu, Kubernetes boleh mengawal dir kosong tersebut di bawah konfigurasi biasa dan dapat mengawal saiz maksimumnya dan tidak membenarkannya dilampaui. Satu-satunya perkara ialah apa yang anda tulis dalam dir kosong tidak hilang semasa pod dimulakan semula. Iaitu, jika pod anda jatuh secara tidak sengaja dan naik semula, maklumat dalam dir kosong tidak akan ke mana-mana. Dia boleh menggunakannya semula pada permulaan baharu - dan itu bagus. Jika pod anda pergi ke suatu tempat, maka secara semula jadi dia akan pergi tanpa data. Iaitu, sebaik sahaja pod dari nod di mana ia dilancarkan dengan dir kosong hilang, dir kosong dipadamkan.

Apa lagi yang bagus tentang dir kosong? Sebagai contoh, ia boleh digunakan sebagai cache. Mari bayangkan bahawa aplikasi kami menjana sesuatu dengan cepat, memberikannya kepada pengguna, dan melakukannya untuk masa yang lama. Oleh itu, aplikasi, sebagai contoh, menjana dan memberikannya kepada pengguna, dan pada masa yang sama menyimpannya di suatu tempat, supaya pada masa akan datang pengguna datang untuk perkara yang sama, ia akan menjadi lebih cepat untuk memberikannya dengan segera dijana. Dir kosong boleh diminta kepada Kubernetes untuk mencipta dalam ingatan. Oleh itu, cache anda secara amnya boleh berfungsi pada kelajuan kilat - dari segi kelajuan akses cakera. Iaitu, anda mempunyai dir kosong dalam ingatan, dalam OS ia disimpan dalam memori, tetapi untuk anda, untuk pengguna di dalam pod, ia kelihatan seperti hanya direktori tempatan. Anda tidak memerlukan aplikasi untuk mengajar sebarang sihir secara khusus. Anda hanya terus mengambil dan meletakkan fail anda dalam direktori, tetapi, sebenarnya, dalam ingatan pada OS. Ini juga merupakan ciri yang sangat mudah dari segi Kubernetes.

Apakah masalah yang dihadapi oleh Minio? Masalah utama dengan Minio ialah agar perkara ini berfungsi, ia perlu berjalan di suatu tempat, dan mesti ada beberapa jenis sistem fail, iaitu penyimpanan. Dan di sini kita menghadapi masalah yang sama yang dihadapi oleh Ceph. Iaitu, Minio mesti menyimpan failnya di suatu tempat. Ia hanyalah antara muka HTTP untuk fail anda. Selain itu, fungsinya jelas lebih lemah daripada S3 Amazon. Sebelum ini, ia tidak dapat memberi kebenaran kepada pengguna dengan betul. Sekarang, setakat yang saya tahu, ia sudah boleh membuat baldi dengan kebenaran yang berbeza, tetapi sekali lagi, nampaknya saya masalah utama, boleh dikatakan, sistem storan asas sekurang-kurangnya.

Bagaimanakah dir Kosong dalam ingatan menjejaskan had? Tidak menjejaskan had dalam apa cara sekalipun. Ia terletak pada ingatan hos, dan bukan dalam ingatan bekas anda. Iaitu, bekas anda tidak melihat dir kosong dalam ingatan sebagai sebahagian daripada memori yang didudukinya. Tuan rumah melihat ini. Oleh itu, ya, dari sudut pandangan kubernetes, apabila anda mula menggunakan ini, adalah baik untuk memahami bahawa anda menumpukan sebahagian daripada ingatan anda untuk mengosongkan dir. Dan sewajarnya, fahami bahawa memori boleh kehabisan bukan sahaja kerana aplikasi, tetapi juga kerana seseorang menulis kepada dir kosong ini.

Cloudnativeness

Dan subtopik terakhir ialah Cloudnative. Mengapa ia diperlukan? Cloudnativeness dan sebagainya.

Iaitu, aplikasi yang berkebolehan dan bertulis untuk berfungsi dalam infrastruktur awan moden. Tetapi, sebenarnya, Cloudnative mempunyai satu lagi aspek sedemikian. Bahawa ini bukan sahaja aplikasi yang mengambil kira semua keperluan infrastruktur awan moden, tetapi juga tahu cara bekerja dengan infrastruktur awan moden ini, mengambil kesempatan daripada kelebihan dan kekurangan fakta bahawa ia berfungsi dalam awan ini. Jangan hanya melampaui batas dan bekerja di awan, tetapi manfaatkan faedah bekerja di awan.

Mari kita ambil Kubernetes sebagai contoh. Aplikasi anda berjalan dalam Kubernetes. Aplikasi anda sentiasa boleh, atau sebaliknya pentadbir untuk aplikasi anda, sentiasa boleh membuat akaun perkhidmatan. Iaitu, akaun untuk kebenaran dalam Kubernetes sendiri dalam pelayannya. Tambah beberapa hak yang kita perlukan di sana. Dan anda boleh mengakses Kubernetes dari dalam aplikasi anda. Apa yang anda boleh lakukan dengan cara ini? Sebagai contoh, daripada aplikasi, terima data tentang tempat aplikasi anda yang lain, contoh lain yang serupa berada, dan bersama-sama entah bagaimana berkelompok di atas Kubernetes, jika terdapat keperluan sedemikian.

Sekali lagi, kami benar-benar mempunyai kes baru-baru ini. Kami mempunyai seorang pengawal yang memantau baris gilir. Dan apabila beberapa tugas baharu muncul dalam baris gilir ini, ia pergi ke Kubernetes - dan di dalam Kubernetes ia mencipta pod baharu. Memberi pod ini beberapa tugas baharu dan dalam rangka kerja pod ini, pod melaksanakan tugas, menghantar respons kepada pengawal itu sendiri, dan pengawal kemudian melakukan sesuatu dengan maklumat ini. Sebagai contoh, ia menambah pangkalan data. Iaitu, sekali lagi, ini adalah tambahan daripada fakta bahawa aplikasi kami berjalan dalam Kubernetes. Kami boleh menggunakan kefungsian Kubernetes terbina dalam itu sendiri untuk mengembangkan dan menjadikan kefungsian aplikasi kami lebih mudah. Iaitu, jangan sembunyikan sejenis sihir tentang cara melancarkan aplikasi, cara melancarkan pekerja. Dalam Kubernetes, anda hanya menghantar permintaan dalam apl jika aplikasi itu ditulis dalam Python.

Perkara yang sama berlaku jika kita melampaui Kubernetes. Kami mempunyai Kubernetes kami berjalan di suatu tempat - adalah baik jika ia berada dalam beberapa jenis awan. Sekali lagi, kita boleh menggunakan, dan juga, saya percaya, harus menggunakan keupayaan awan itu sendiri di mana kita sedang berjalan. Daripada perkara asas yang awan berikan kepada kita. Mengimbangi, iaitu, kita boleh mencipta pengimbang awan dan menggunakannya. Ini adalah kelebihan langsung daripada apa yang boleh kita gunakan. Kerana pengimbangan awan, pertama sekali, secara bodohnya mengalih keluar tanggungjawab daripada kami untuk cara ia berfungsi, cara ia dikonfigurasikan. Selain itu, ia sangat mudah, kerana Kubernetes biasa boleh berintegrasi dengan awan.

Perkara yang sama berlaku untuk penskalaan. Kubernetes biasa boleh berintegrasi dengan penyedia awan. Tahu bagaimana untuk memahami bahawa jika kluster kehabisan nod, iaitu, ruang nod telah kehabisan, maka anda perlu menambah - Kubernetes sendiri akan menambah nod baharu pada kluster anda dan mula melancarkan pod padanya. Iaitu, apabila beban anda datang, bilangan perapian mula meningkat. Apabila nod dalam kluster kehabisan untuk pod ini, Kubernetes melancarkan nod baharu dan, oleh itu, bilangan pod masih boleh meningkat. Dan ia sangat mudah. Ini adalah peluang langsung untuk skala kelompok dengan cepat. Tidak terlalu pantas, dalam erti kata ia bukan satu saat, ia lebih seperti satu minit untuk menambah nod baharu.

Tetapi dari pengalaman saya, sekali lagi, ia adalah perkara paling hebat yang pernah saya lihat. Apabila gugusan Cloudnative berskala berdasarkan masa dalam hari. Ia adalah perkhidmatan bahagian belakang yang digunakan oleh orang di pejabat belakang. Iaitu, mereka datang untuk bekerja pada pukul 9 pagi, mula log masuk ke sistem, dan oleh itu, kluster Cloudnative, di mana semuanya berjalan, mula membengkak, melancarkan pod baharu supaya semua orang yang datang bekerja boleh bekerja dengan aplikasi. Apabila mereka meninggalkan tempat kerja pada pukul 8 malam atau 6 petang, kluster Kubernetes mendapati tiada sesiapa yang menggunakan aplikasi itu lagi dan mula mengecut. Penjimatan sehingga 30 peratus dijamin. Ia berfungsi di Amazon pada masa itu; pada masa itu tidak ada sesiapa di Rusia yang boleh melakukannya dengan baik.

Saya akan memberitahu anda terus, penjimatan adalah 30 peratus hanya kerana kami menggunakan Kubernetes dan memanfaatkan keupayaan awan. Sekarang ini boleh dilakukan di Rusia. Saya tidak akan mengiklankan kepada sesiapa, sudah tentu, tetapi katakan sahaja bahawa terdapat penyedia yang boleh melakukan ini, berikannya terus dari kotak dengan butang.

Terdapat satu perkara terakhir yang saya juga ingin menarik perhatian anda. Agar aplikasi anda, infrastruktur anda menjadi Cloudnative, masuk akal untuk akhirnya mula menyesuaikan pendekatan yang dipanggil Infrastruktur sebagai Kod. Maksudnya, ini bermakna aplikasi anda, atau lebih tepatnya infrastruktur anda, diperlukan dengan cara yang sama seperti kod Terangkan aplikasi anda, logik perniagaan anda dalam bentuk kod. Dan gunakannya sebagai kod, iaitu, uji, gulungkannya, simpan dalam git, gunakan CICD padanya.

Dan inilah yang membolehkan anda, pertama sekali, untuk sentiasa mengawal infrastruktur anda, untuk sentiasa memahami keadaannya. Kedua, elakkan operasi manual yang menyebabkan ralat. Ketiga, elakkan hanya apa yang dipanggil pusing ganti, apabila anda sentiasa perlu melakukan tugas manual yang sama. Keempat, ia membolehkan anda pulih lebih cepat sekiranya berlaku kegagalan. Di Rusia, setiap kali saya bercakap tentang perkara ini, selalu ada sebilangan besar orang yang berkata: "Ya, ia jelas, tetapi anda mempunyai pendekatan, ringkasnya, tidak perlu membetulkan apa-apa." Tetapi ia benar. Jika ada sesuatu yang rosak dalam infrastruktur anda, maka dari sudut pandangan pendekatan Cloudnative dan dari sudut pandangan Infrastruktur sebagai Kod, daripada membetulkannya, pergi ke pelayan, memikirkan apa yang rosak dan membetulkannya, lebih mudah untuk memadam pelayan dan menciptanya semula. Dan saya akan memulihkan semua ini.

Semua isu ini dibincangkan dengan lebih terperinci di Kursus video Kubernetes: Junior, Asas, Mega. Dengan mengikuti pautan, anda boleh membiasakan diri dengan program dan syarat. Perkara yang mudah ialah anda boleh menguasai Kubernetes dengan belajar dari rumah atau bekerja selama 1-2 jam sehari.

Sumber: www.habr.com