Dalam mengantisipasi Vitaly Khabarov diwawancarai Dmitry Stolyarov (), direktur teknis dan salah satu pendiri perusahaan Flant. Vitaly bertanya kepada Dmitry tentang apa yang dilakukan Flant, tentang Kubernetes, pengembangan ekosistem, dan dukungan. Kami membahas mengapa Kubernetes diperlukan dan apakah Kubernetes diperlukan sama sekali. Dan juga tentang layanan mikro, Amazon AWS, pendekatan “Saya akan beruntung” terhadap DevOps, masa depan Kubernetes itu sendiri, mengapa, kapan, dan bagaimana Kubernetes akan mengambil alih dunia, prospek DevOps, dan apa saja yang harus dipersiapkan para insinyur di masa depan. masa depan yang cerah dan dekat dengan penyederhanaan dan jaringan saraf.
dengarkan sebagai podcast di DevOps Deflop - podcast berbahasa Rusia tentang DevOps, dan di bawah ini adalah versi teksnya.
Di sini dan di bawah dia mengajukan pertanyaan insinyur dari Express42.
Tentang "Flant"
- Halo Dima. Anda adalah direktur teknis"" dan juga pendirinya. Tolong beritahu kami apa yang dilakukan perusahaan dan apa pekerjaan Anda di dalamnya?
Dmitry: Dari luar sepertinya kami adalah orang-orang yang menginstal Kubernetes untuk semua orang dan melakukan sesuatu dengannya. Tapi itu tidak benar. Kami memulai sebagai perusahaan yang menangani Linux, namun sejak lama aktivitas utama kami adalah melayani produksi dan proyek turnkey beban tinggi. Biasanya kami membangun seluruh infrastruktur dari awal dan kemudian bertanggung jawab untuk itu dalam jangka waktu yang sangat lama. Oleh karena itu, pekerjaan utama yang dilakukan “Flant”, yang menerima uang, adalah mengambil tanggung jawab dan menerapkan produksi turnkey.
Saya, sebagai direktur teknis dan salah satu pendiri perusahaan, menghabiskan siang dan malam mencoba mencari cara untuk meningkatkan aksesibilitas produksi, menyederhanakan operasinya, membuat kehidupan administrator lebih mudah, dan kehidupan pengembang lebih menyenangkan. .
Tentang Kubernet
— Akhir-akhir ini aku melihat banyak laporan dari Flant dan tentang Kubernet. Bagaimana Anda sampai ke sana?
Dmitry: Saya sudah membicarakan hal ini berkali-kali, tapi saya tidak keberatan mengulanginya sama sekali. Saya rasa tepat untuk mengulang topik ini karena ada kebingungan antara sebab dan akibat.
Kami sangat membutuhkan alat. Banyak permasalahan yang kita hadapi, kita perjuangkan, mengatasinya dengan berbagai tongkat penopang dan merasa membutuhkan sebuah alat. Kami melalui banyak pilihan berbeda, membuat sepeda sendiri, dan memperoleh pengalaman. Secara bertahap kami sampai pada titik di mana kami mulai menggunakan Docker segera setelah Docker muncul - sekitar tahun 2013. Pada saat kemunculannya, kami sudah memiliki banyak pengalaman dengan container, kami telah menulis analog dari "Docker" - beberapa kruk kami sendiri dengan Python. Dengan munculnya Docker, menjadi mungkin untuk membuang kruk dan menggunakan solusi yang dapat diandalkan dan didukung komunitas.
Dengan Kubernetes, ceritanya serupa. Pada saat ini mulai mendapatkan momentum - bagi kami ini adalah versi 1.2 - kami sudah memiliki banyak kruk di Shell dan Chef, yang entah bagaimana kami coba atur dengan Docker. Kami serius mencari Rancher dan berbagai solusi lainnya, tapi kemudian Kubernetes muncul, di mana semuanya diimplementasikan persis seperti yang kami inginkan atau bahkan lebih baik. Tidak ada yang perlu dikeluhkan.
Ya, ada semacam ketidaksempurnaan di sini, ada semacam ketidaksempurnaan di sana - ada banyak ketidaksempurnaan, dan 1.2 umumnya buruk, tapi... Kubernetes seperti bangunan yang sedang dibangun - Anda melihat proyeknya dan memahaminya bahwa itu akan menjadi keren. Jika bangunan tersebut sekarang memiliki fondasi dan dua lantai, maka Anda memahami bahwa lebih baik tidak pindah dulu, tetapi tidak ada masalah dengan perangkat lunaknya - Anda sudah dapat menggunakannya.
Kami tidak mempunyai momen untuk memikirkan apakah akan menggunakan Kubernetes atau tidak. Kami telah menunggunya jauh sebelum muncul, dan mencoba membuat analoginya sendiri.
Tentang Kubernet
— Apakah Anda terlibat langsung dalam pengembangan Kubernetes itu sendiri?
Dmitry: Biasa-biasa saja. Sebaliknya, kami berpartisipasi dalam pengembangan ekosistem. Kami mengirimkan sejumlah permintaan penarikan: ke Prometheus, ke berbagai operator, ke Helm - ke ekosistem. Sayangnya, saya tidak dapat melacak semua yang kami lakukan dan saya bisa saja salah, tetapi tidak ada satu pun kumpulan dari kami yang masuk ke dalam inti.
— Pada saat yang sama, apakah Anda mengembangkan banyak alat di sekitar Kubernetes?
Dmitry: Strateginya begini: kita pergi dan menarik permintaan ke semua yang sudah ada. Jika permintaan tarik tidak diterima di sana, kami cukup mem-forknya sendiri dan menunggu sampai permintaan tersebut diterima dengan build kami. Lalu kalau sudah sampai di upstream, kita kembali ke versi upstream.
Misalnya, kami memiliki operator Prometheus, yang dengannya kami beralih bolak-balik ke upstream perakitan kami mungkin sudah 5 kali. Kami memerlukan semacam fitur, kami mengirimkan permintaan tarik, kami perlu meluncurkannya besok, tetapi kami tidak ingin menunggu hingga fitur tersebut dirilis secara upstream. Oleh karena itu, kami merakit untuk diri kami sendiri, meluncurkan perakitan kami dengan fitur kami, yang kami perlukan karena alasan tertentu, ke semua cluster kami. Lalu, misalnya, mereka menyerahkannya kepada kita di hulu dengan kata-kata: “Guys, ayo kita lakukan untuk kasus yang lebih umum,” kita, atau orang lain, menyelesaikannya, dan lama kelamaan menyatu kembali.
Kami mencoba mengembangkan segala sesuatu yang ada. Banyak elemen yang belum ada, belum ditemukan, atau sudah ditemukan, tetapi belum sempat diimplementasikan - kami sedang melakukannya. Dan bukan karena kami menyukai proses atau pembuatan sepeda sebagai sebuah industri, tetapi hanya karena kami membutuhkan alat tersebut. Pertanyaan yang sering ditanyakan, mengapa kita melakukan hal ini atau itu? Jawabannya sederhana - ya, karena kami harus melangkah lebih jauh, memecahkan beberapa masalah praktis, dan kami menyelesaikannya dengan tula ini.
Jalannya selalu seperti ini: kami mencari dengan sangat hati-hati dan, jika kami tidak menemukan solusi tentang cara membuat bus listrik dari sepotong roti, maka kami membuat roti dan bus listrik kami sendiri.
Alat Flanta
— Saya tahu bahwa Flant sekarang memiliki operator tambahan, operator shell, dan alat dapp/werf. Sejauh yang saya pahami, ini adalah instrumen yang sama dalam inkarnasi yang berbeda. Saya juga memahami bahwa masih banyak lagi alat berbeda dalam Flaunt. Ini benar?
Dmitry: Kami memiliki lebih banyak lagi di GitHub. Dari apa yang saya ingat sekarang, kami memiliki peta status - panel untuk Grafana yang pernah ditemukan semua orang. Hal ini disebutkan di hampir setiap artikel kedua tentang pemantauan Kubernetes di Medium. Tidak mungkin menjelaskan secara singkat apa itu statusmap - peta status memerlukan artikel terpisah, namun ini sangat berguna untuk memantau status dari waktu ke waktu, karena di Kubernetes kita sering kali perlu menampilkan status dari waktu ke waktu. Kami juga memiliki LogHouse - ini adalah sesuatu yang didasarkan pada ClickHouse dan ilmu hitam untuk mengumpulkan log di Kubernetes.
Banyak utilitas! Dan akan lebih banyak lagi, karena sejumlah solusi internal akan dirilis tahun ini. Dari yang sangat besar berdasarkan operator addon, ada banyak add-on untuk Kubernetes, ala cara menginstal sert manager dengan benar - alat untuk mengelola sertifikat, cara menginstal Prometheus dengan benar dengan banyak aksesori - ada sekitar dua puluh berbeda biner yang mengekspor data dan mengumpulkan sesuatu, hingga Prometheus ini memiliki grafik dan peringatan paling menakjubkan. Semua ini hanyalah sekumpulan add-on untuk Kubernetes, yang dipasang di sebuah cluster, dan berubah dari yang sederhana menjadi keren, canggih, otomatis, di mana banyak masalah telah teratasi. Ya, kami melakukan banyak hal.
Pembangunan ekosistem
“Bagi saya, ini merupakan kontribusi yang sangat besar terhadap pengembangan instrumen ini dan metode penggunaannya.” Bisakah Anda memperkirakan secara kasar siapa lagi yang akan memberikan kontribusi yang sama terhadap pengembangan ekosistem?
Dmitry: Di Rusia, dari perusahaan yang beroperasi di pasar kami, tidak ada satu pun yang mendekati. Tentu saja, ini adalah pernyataan yang keras, karena ada pemain besar seperti Mail dan Yandex - mereka juga melakukan sesuatu dengan Kubernetes, namun mereka bahkan tidak bisa menandingi kontribusi perusahaan di seluruh dunia yang melakukan lebih dari kita. Sulit untuk membandingkan Flant, yang memiliki staf sebanyak 80 orang, dan Red Hat, yang memiliki 300 insinyur per Kubernetes saja, kalau saya tidak salah. Sulit untuk membandingkannya. Kami memiliki 6 orang di departemen RnD, termasuk saya, yang memotong semua peralatan kami. 6 orang versus 300 insinyur Red Hat - sulit untuk membandingkannya.
- Namun, ketika 6 orang ini bisa melakukan sesuatu yang sangat berguna dan mengasingkan diri, ketika mereka dihadapkan pada suatu permasalahan praktis dan memberikan solusinya kepada masyarakat - sebuah kasus yang menarik. Saya memahami bahwa di perusahaan teknologi besar, yang memiliki tim pengembangan dan dukungan Kubernetes sendiri, pada prinsipnya, alat yang sama dapat dikembangkan. Ini adalah contoh bagi mereka tentang apa yang bisa dikembangkan dan diberikan kepada komunitas, memberikan dorongan kepada seluruh komunitas pengguna Kubernetes.
Dmitry: Ini mungkin fitur integrator, kekhasannya. Kami memiliki banyak proyek dan kami melihat banyak situasi berbeda. Bagi kami, cara utama untuk menciptakan nilai tambah adalah dengan menganalisis kasus-kasus ini, menemukan kesamaan dan menjadikannya semurah mungkin bagi kami. Kami secara aktif mengerjakan hal ini. Sulit bagi saya untuk berbicara tentang Rusia dan dunia, tetapi kami memiliki sekitar 40 insinyur DevOps di perusahaan yang bekerja di Kubernetes. Saya rasa tidak banyak perusahaan di Rusia yang memiliki jumlah spesialis yang memahami Kubernetes, jikapun ada, sama sekali tidak ada.
Saya memahami segalanya tentang jabatan insinyur DevOps, semua orang memahami segalanya dan terbiasa memanggil insinyur DevOps sebagai insinyur DevOps, kami tidak akan membahas ini. Ke-40 insinyur DevOps luar biasa ini menghadapi dan memecahkan masalah setiap hari, kami hanya menganalisis pengalaman ini dan mencoba menggeneralisasikannya. Kami paham kalau masih ada di dalam diri kita, maka dalam satu atau dua tahun alat itu tidak akan ada gunanya, karena di suatu tempat di masyarakat akan muncul Tula yang sudah jadi. Tidak ada gunanya mengumpulkan pengalaman ini secara internal - ini hanya menghabiskan energi dan waktu hingga dev/null. Dan kami tidak merasa kasihan sama sekali. Kami mempublikasikan semuanya dengan senang hati dan memahami bahwa itu perlu dipublikasikan, dikembangkan, dipromosikan, dipromosikan, sehingga orang dapat menggunakannya dan menambah pengalaman mereka - kemudian semuanya tumbuh dan hidup. Kemudian setelah dua tahun instrumen tersebut tidak dibuang ke tempat sampah. Tidak sayang untuk terus menuangkan kekuatan, karena jelas ada yang menggunakan alat Anda, dan setelah dua tahun semua orang menggunakannya.
Ini adalah bagian dari strategi besar kami dengan dapp/werf. Saya tidak ingat kapan kami mulai membuatnya, sepertinya 3 tahun yang lalu. Awalnya, umumnya pada cangkang. Itu adalah bukti konsep yang luar biasa, kami memecahkan beberapa masalah khusus kami - berhasil! Tetapi ada masalah dengan shell, tidak mungkin untuk mengembangkannya lebih jauh, pemrograman pada shell adalah tugas lain. Kami memiliki kebiasaan menulis di Ruby, oleh karena itu, kami membuat ulang sesuatu di Ruby, mengembangkan, mengembangkan, mengembangkan, dan menemukan fakta bahwa komunitas, kerumunan yang tidak mengatakan “kami menginginkannya atau tidak menginginkannya, ” menengadahkan hidungnya ke arah Ruby, lucu sekali? Kami menyadari bahwa kami harus menulis semua hal ini di Go hanya untuk memenuhi poin pertama di daftar periksa: Alat DevOps harus berupa biner statis. Menjadi Go atau tidak tidak begitu penting, tetapi biner statis yang ditulis dalam Go lebih baik.
Kami menghabiskan energi kami, menulis ulang dapp di Go dan menyebutnya werf. Dapp tidak lagi didukung, tidak dikembangkan, berjalan di beberapa versi terbaru, tetapi ada jalur peningkatan mutlak ke atas, dan Anda dapat mengikutinya.
Mengapa dapp dibuat?
— Bisakah Anda memberi tahu kami secara singkat mengapa dapp dibuat, masalah apa yang dipecahkannya?
Dmitry: Alasan pertama adalah di majelis. Awalnya, kami mengalami masalah serius dengan build ketika Docker tidak memiliki kemampuan multi-tahap, jadi kami membuat multi-tahap sendiri. Lalu kami mengalami lebih banyak masalah saat membersihkan gambar. Setiap orang yang melakukan CI/CD, cepat atau lambat, akan dihadapkan pada masalah bahwa ada banyak gambar yang dikumpulkan, Anda perlu membersihkan apa yang tidak diperlukan dan meninggalkan apa yang diperlukan.
Alasan kedua adalah penerapan. Ya, ada Helm, tapi itu hanya menyelesaikan beberapa masalah. Lucunya, ada tertulis “Helm adalah Manajer Paket untuk Kubernetes.” Persisnya apa yang dimaksud dengan “itu”. Ada juga tulisan “Package Manager” – apa yang biasanya diharapkan dari seorang Package Manager? Kami berkata: "Manajer Paket - instal paketnya!" dan kami berharap dia memberi tahu kami: “Paket telah terkirim.”
Sangat menarik bahwa kita mengatakan: "Helm, instal paketnya," dan ketika dia menjawab bahwa dia menginstalnya, ternyata dia baru saja memulai instalasi - dia menunjukkan Kubernetes: "Luncurkan hal ini!", dan apakah itu dimulai atau tidak , berhasil atau tidak, Helm tidak menyelesaikan masalah ini sama sekali.
Ternyata Helm hanyalah sebuah preprosesor teks yang memuat data ke dalam Kubernetes.
Namun sebagai bagian dari penerapan apa pun, kami ingin mengetahui apakah aplikasi tersebut telah dirilis untuk produksi atau belum? Diluncurkan ke prod berarti aplikasi telah dipindahkan ke sana, versi baru telah diterapkan, dan setidaknya tidak mogok di sana dan merespons dengan benar. Helm tidak menyelesaikan masalah ini dengan cara apa pun. Untuk mengatasinya, Anda perlu mengeluarkan banyak upaya, karena Anda perlu memberikan perintah kepada Kubernetes untuk meluncurkan dan memantau apa yang terjadi di sana - apakah itu diterapkan atau diluncurkan. Dan ada juga banyak tugas yang terkait dengan penerapan, pembersihan, dan perakitan.
Rencana
Tahun ini kami akan memulai pembangunan lokal. Kami ingin mencapai apa yang sebelumnya ada di Vagrant - kami mengetik "vagrant up" dan kami menerapkan mesin virtual. Kami ingin mencapai titik di mana ada proyek di Git, kami menulis "werf up" di sana, dan itu menampilkan salinan lokal dari proyek ini, yang diterapkan di mini-Kub lokal, dengan semua direktori yang nyaman untuk pengembangan terhubung . Tergantung pada bahasa pengembangan, hal ini dilakukan secara berbeda, namun demikian, sehingga pengembangan lokal dapat dengan mudah dilakukan di bawah file yang di-mount.
Langkah selanjutnya bagi kami adalah berinvestasi dalam kenyamanan bagi pengembang. Untuk menerapkan proyek secara lokal dengan cepat menggunakan satu alat, kembangkan, dorong ke Git, dan proyek juga akan diluncurkan ke tahap atau pengujian, bergantung pada jalur pipa, lalu gunakan alat yang sama untuk masuk ke produksi. Kesatuan, penyatuan, reproduktifitas infrastruktur mulai dari lingkungan lokal hingga penjualan adalah poin yang sangat penting bagi kami. Namun hal ini belum dilakukan - kami hanya berencana untuk melakukannya.
Namun jalur menuju dapp/werf selalu sama seperti pada Kubernetes pada awalnya. Kami menemui masalah, menyelesaikannya dengan solusi - kami menemukan beberapa solusi untuk diri kami sendiri, pada apa pun. Kemudian mereka mencoba meluruskan solusi ini, menggeneralisasi dan mengkonsolidasikannya ke dalam biner dalam kasus ini, yang hanya kami bagikan.
Ada cara lain untuk melihat keseluruhan cerita ini, dengan analogi.
Kubernetes adalah kerangka mobil dengan mesin. Tidak ada pintu, kaca, radio, pohon Natal - tidak ada sama sekali. Hanya rangka dan mesinnya. Dan ada Helm - ini setirnya. Keren - ada roda kemudi, tetapi Anda juga memerlukan pin kemudi, rak kemudi, girboks, dan roda, dan Anda tidak dapat melakukannya tanpanya.
Dalam kasus werf, ini adalah komponen lain dari Kubernetes. Cuma sekarang di werf versi alpha misalnya Helm dikompilasi di dalam werf, karena kita capek melakukannya sendiri. Ada banyak alasan untuk melakukan ini, saya akan memberi tahu Anda secara detail mengapa kami menyusun seluruh helm bersama dengan anakan di dalam werf .
Sekarang werf menjadi komponen yang lebih terintegrasi. Kami mendapatkan roda kemudi yang sudah jadi, pin kemudi - Saya tidak pandai mobil, tapi ini adalah blok besar yang sudah memecahkan berbagai masalah. Kita tidak perlu menelusuri katalog sendiri, memilih satu bagian untuk bagian lainnya, memikirkan cara menyatukannya. Kami mendapatkan gabungan siap pakai yang memecahkan banyak masalah sekaligus. Namun di dalamnya dibangun dari komponen open source yang sama, masih menggunakan Docker untuk perakitannya, Helm untuk beberapa fungsinya, dan masih ada beberapa perpustakaan lainnya. Ini adalah alat terintegrasi untuk mengeluarkan CI/CD keren dengan cepat dan nyaman.
Apakah Kubernetes sulit dikelola?
— Anda berbicara tentang pengalaman saat Anda mulai menggunakan Kubernetes, ini adalah kerangka untuk Anda, sebuah mesin, dan Anda dapat menggantungkan banyak hal berbeda di dalamnya: bodi, roda kemudi, pedal sekrup, kursi. Timbul pertanyaan - seberapa sulitkah dukungan Kubernetes bagi Anda? Anda memiliki banyak pengalaman, berapa banyak waktu dan sumber daya yang Anda habiskan untuk mendukung Kubernetes secara terpisah dari hal lainnya?
Dmitry: Ini adalah pertanyaan yang sangat sulit dan untuk menjawabnya, kita perlu memahami apa itu dukungan dan apa yang kita inginkan dari Kubernetes. Mungkin Anda bisa mengungkapkannya?
— Sejauh yang saya tahu dan lihat, sekarang banyak tim yang ingin mencoba Kubernetes. Semua orang memanfaatkannya, meletakkannya di atas lututnya. Saya merasa orang tidak selalu memahami kompleksitas sistem ini.
Dmitry: Seperti itu.
— Seberapa sulitkah mengambil dan menginstal Kubernetes dari awal agar siap produksi?
Dmitry: Menurut Anda seberapa sulitkah melakukan transplantasi jantung? Saya memahami ini adalah pertanyaan yang membahayakan. Menggunakan pisau bedah dan tidak melakukan kesalahan tidaklah sulit. Jika mereka memberi tahu Anda di mana harus memotong dan menjahit, maka prosedurnya sendiri tidak rumit. Sulit untuk menjamin dari waktu ke waktu bahwa semuanya akan berhasil.
Menginstal Kubernetes dan menjalankannya sangatlah mudah: cewek! — terinstal, ada banyak metode instalasi. Namun apa jadinya bila masalah muncul?
Pertanyaan selalu muncul – apa yang belum kita perhitungkan? Apa yang belum kita lakukan? Parameter kernel Linux mana yang salah ditentukan? Tuhan, apakah kami menyebutkannya?! Komponen Kubernetes mana yang sudah kami kirimkan dan mana yang belum? Ribuan pertanyaan muncul, dan untuk menjawabnya, Anda perlu menghabiskan waktu 15-20 tahun di industri ini.
Saya memiliki contoh terbaru tentang topik ini yang mungkin dapat mengungkap arti dari masalah “Apakah Kubernetes sulit dipelihara?” Beberapa waktu lalu kami secara serius mempertimbangkan apakah kami harus mencoba mengimplementasikan Cilium sebagai jaringan di Kubernetes.
Izinkan saya menjelaskan apa itu Cilium. Kubernetes memiliki banyak implementasi subsistem jaringan yang berbeda, dan salah satunya yang sangat keren - Cilium. Apa artinya? Di kernel, beberapa waktu lalu menjadi mungkin untuk menulis hook untuk kernel, yang dengan satu atau lain cara menyerang subsistem jaringan dan berbagai subsistem lainnya, dan memungkinkan Anda melewati sebagian besar di kernel.
Kernel Linux secara historis memiliki ip rout, overfilter, bridge, dan banyak komponen lama lainnya yang berusia 15, 20, 30 tahun. Secara umum, mereka berfungsi, semuanya baik-baik saja, tetapi sekarang mereka telah menumpuk kontainer, dan itu tampak seperti menara yang terdiri dari 15 batu bata di atas satu sama lain, dan Anda berdiri di atasnya dengan satu kaki - perasaan yang aneh. Sistem ini secara historis berkembang dengan banyak nuansa, seperti usus buntu pada tubuh. Dalam beberapa situasi, ada masalah kinerja, misalnya.
Ada BPF yang luar biasa dan kemampuan untuk menulis kait untuk kernel - orang-orang menulis kait mereka sendiri untuk kernel. Paket tersebut masuk ke dalam kernel Linux, mereka mengeluarkannya langsung pada input, memprosesnya sendiri sebagaimana mestinya tanpa jembatan, tanpa TCP, tanpa tumpukan IP - singkatnya, melewati semua yang tertulis di kernel Linux, dan kemudian meludah itu keluar ke dalam wadah.
Apa yang telah terjadi? Performa sangat keren, fitur keren - keren! Namun kita melihat ini dan melihat bahwa di setiap mesin terdapat program yang terhubung ke API Kubernetes dan, berdasarkan data yang diterimanya dari API ini, menghasilkan kode C dan mengkompilasi biner yang dimuat ke dalam kernel sehingga hook ini berfungsi. di ruang kernel.
Apa yang terjadi jika terjadi kesalahan? Kami tidak tahu. Untuk memahami hal ini, Anda perlu membaca semua kode ini, memahami semua logikanya, dan sungguh menakjubkan betapa sulitnya hal ini. Namun, di sisi lain, ada jembatan, filter bersih, perutean ip - Saya belum membaca kode sumbernya, begitu pula 40 insinyur yang bekerja di perusahaan kami. Mungkin hanya sedikit yang memahami beberapa bagian.
Dan apa bedanya? Ternyata ada ip rout, kernel Linux, dan ada alat baru - apa bedanya, kami tidak mengerti satu atau yang lain. Namun kami takut menggunakan sesuatu yang baru - mengapa? Karena jika alat tersebut berumur 30 tahun, maka dalam 30 tahun semua bug telah ditemukan, semua kesalahan telah diinjak dan Anda tidak perlu mengetahui semuanya - alat ini berfungsi seperti kotak hitam dan selalu berfungsi. Semua orang tahu obeng diagnostik mana yang harus dipasang di tempat mana, tcpdump mana yang harus dijalankan pada saat apa. Semua orang mengetahui utilitas diagnostik dengan baik dan memahami cara kerja kumpulan komponen ini di kernel Linux - bukan cara kerjanya, tetapi cara menggunakannya.
Dan Cilium yang luar biasa keren ini belum berusia 30 tahun, belum tua. Kubernetes memiliki masalah yang sama, salin. Cilium terinstal dengan sempurna, Kubernetes terinstal dengan sempurna, tetapi ketika terjadi kesalahan dalam produksi, apakah Anda dapat dengan cepat memahami dalam situasi kritis apa yang salah?
Saat kami mengatakan sulitnya memelihara Kubernetes - tidak, ini sangat mudah, dan ya, ini sangat sulit. Kubernetes berfungsi dengan baik, tetapi dengan sejuta nuansa.
Tentang pendekatan “Saya akan beruntung”.
— Apakah ada perusahaan di mana nuansa ini hampir pasti akan muncul? Misalkan Yandex tiba-tiba mentransfer semua layanan ke Kubernetes, akan ada beban besar di sana.
Dmitry: Bukan, ini bukan pembicaraan tentang beban, tapi tentang hal yang paling sederhana. Misalnya, kami memiliki Kubernetes, kami menerapkan aplikasi di sana. Bagaimana Anda tahu ini berhasil? Tidak ada alat yang siap pakai untuk memahami bahwa aplikasi tidak mogok. Tidak ada sistem siap pakai yang mengirimkan peringatan; Anda perlu mengonfigurasi peringatan ini dan setiap jadwal. Dan kami memperbarui Kubernetes.
Saya memiliki Ubuntu 16.04. Bisa dibilang ini versi lama, tapi kami masih menggunakannya karena ini LTS. Ada systemd, nuansanya tidak membersihkan grup C. Kubernetes meluncurkan pod, membuat grup C, lalu menghapus pod, dan entah bagaimana ternyata - saya tidak ingat detailnya, maaf - potongan systemd tetap ada. Hal ini mengarah pada fakta bahwa seiring waktu, mobil mana pun mulai melambat secara signifikan. Ini bahkan bukan pertanyaan tentang beban tinggi. Jika pod permanen diluncurkan, misalnya jika ada Cron Job yang terus-menerus menghasilkan pod, maka mesin dengan Ubuntu 16.04 akan mulai melambat setelah seminggu. Akan ada rata-rata beban yang tinggi secara konstan karena fakta bahwa sekelompok grup C telah dibuat. Ini adalah masalah yang akan dihadapi oleh siapa pun yang baru saja menginstal Ubuntu 16 dan Kubernetes.
Katakanlah dia entah bagaimana memperbarui systemd atau sesuatu yang lain, tetapi di kernel Linux hingga 4.16 itu bahkan lebih lucu - ketika Anda menghapus grup C, grup tersebut bocor di kernel dan tidak benar-benar dihapus. Oleh karena itu, setelah sebulan mengerjakan mesin ini, tidak mungkin untuk melihat statistik memori perapian. Kami mengeluarkan sebuah file, menggulungnya ke dalam program, dan satu file bergulir selama 15 detik, karena kernel membutuhkan waktu yang sangat lama untuk menghitung satu juta grup C di dalamnya, yang tampaknya terhapus, tetapi tidak - mereka bocor .
Masih banyak hal-hal kecil di sana-sini. Ini bukan masalah yang kadang-kadang dihadapi oleh perusahaan-perusahaan raksasa di bawah beban yang sangat berat - bukan, ini adalah masalah sehari-hari. Orang-orang dapat hidup seperti ini selama berbulan-bulan - mereka menginstal Kubernetes, menerapkan aplikasi - tampaknya berhasil. Bagi banyak orang, hal ini normal. Mereka bahkan tidak akan tahu bahwa aplikasi ini akan mogok karena suatu alasan, mereka tidak akan menerima peringatan, tetapi bagi mereka ini adalah hal yang biasa. Dulu kita hidup di mesin virtual tanpa monitoring, sekarang kita pindah ke Kubernetes, juga tanpa monitoring - apa bedanya?
Pertanyaannya adalah ketika kita berjalan di atas es, kita tidak akan pernah mengetahui ketebalannya kecuali kita mengukurnya terlebih dahulu. Banyak orang berjalan dan tidak khawatir, karena mereka pernah berjalan sebelumnya.
Dari sudut pandang saya, nuansa dan kompleksitas pengoperasian sistem apa pun adalah untuk memastikan bahwa ketebalan es cukup untuk menyelesaikan masalah kita. Inilah yang sedang kita bicarakan.
Di bidang TI, menurut saya, ada terlalu banyak pendekatan “Saya akan beruntung”. Banyak orang menginstal perangkat lunak dan menggunakan perpustakaan perangkat lunak dengan harapan mendapatkan keberuntungan. Secara umum, banyak orang yang beruntung. Mungkin itulah sebabnya ini berhasil.
— Dari penilaian pesimistis saya, terlihat seperti ini: ketika risikonya tinggi, dan aplikasi harus berfungsi, maka diperlukan dukungan dari Flaunt, mungkin dari Red Hat, atau Anda memerlukan tim internal Anda sendiri yang didedikasikan khusus untuk Kubernetes, yang sudah siap untuk melakukannya.
Dmitry: Secara obyektif, memang demikian. Masuk ke dalam kisah Kubernetes untuk tim kecil melibatkan sejumlah risiko.
Apakah kita memerlukan kontainer?
— Bisakah Anda memberi tahu kami seberapa luas Kubernetes di Rusia?
Dmitry: Saya tidak memiliki data ini, dan saya tidak yakin orang lain memilikinya. Kami mengatakan: “Kubernetes, Kubernetes,” tetapi ada cara lain untuk melihat masalah ini. Saya juga tidak tahu seberapa luas container tersebut, namun saya mengetahui angka dari laporan di Internet bahwa 70% container diatur oleh Kubernetes. Itu adalah sumber terpercaya untuk sampel yang cukup besar di seluruh dunia.
Lalu pertanyaan lainnya - apakah kita memerlukan kontainer? Perasaan pribadi saya dan posisi perusahaan Flant secara keseluruhan adalah bahwa Kubernetes adalah standar de facto.
Tidak akan ada apa pun selain Kubernetes.
Hal ini benar-benar merupakan terobosan baru dalam bidang pengelolaan infrastruktur. Mutlak - itu saja, tidak ada lagi Ansible, Chef, mesin virtual, Terraform. Saya tidak berbicara tentang metode pertanian kolektif yang lama. Kubernetes adalah sebuah perubahan mutlak, dan sekarang hanya akan menjadi seperti ini.
Jelas bahwa bagi sebagian orang diperlukan waktu beberapa tahun, dan bagi sebagian lainnya memerlukan waktu beberapa dekade, untuk menyadari hal ini. Saya yakin tidak akan ada yang lain selain Kubernetes dan tampilan baru ini: kami tidak lagi merusak sistem operasi, tetapi menggunakan infrastruktur sebagai kode, tidak hanya dengan kode, tetapi dengan yml - infrastruktur yang dijelaskan secara deklaratif. Saya merasa akan selalu seperti ini.
— Artinya, perusahaan-perusahaan yang belum beralih ke Kubernetes pasti akan beralih ke Kubernetes atau tetap terlupakan. Saya memahami Anda dengan benar?
Dmitry: Ini juga tidak sepenuhnya benar. Misal kita mempunyai tugas menjalankan DNS server, maka bisa dijalankan di FreeBSD 4.10 dan bisa bekerja sempurna selama 20 tahun. Bekerja saja dan itu saja. Mungkin dalam 20 tahun ada sesuatu yang perlu diperbarui satu kali. Jika kita berbicara tentang perangkat lunak dalam format yang kami luncurkan dan benar-benar berfungsi selama bertahun-tahun tanpa pembaruan apa pun, tanpa melakukan perubahan, maka tentu saja tidak akan ada Kubernetes. Dia tidak dibutuhkan di sana.
Segala sesuatu yang berhubungan dengan CI/CD - di mana pun Pengiriman Berkelanjutan diperlukan, di mana Anda perlu memperbarui versi, membuat perubahan aktif, di mana pun Anda perlu membangun toleransi kesalahan - hanya Kubernetes.
Tentang layanan mikro
- Di sini saya mengalami sedikit disonansi. Untuk bekerja dengan Kubernetes, Anda memerlukan dukungan eksternal atau internal - ini adalah poin pertama. Kedua, ketika kami baru memulai pengembangan, kami adalah startup kecil, kami belum memiliki apa pun, pengembangan untuk Kubernetes atau arsitektur layanan mikro secara umum bisa jadi rumit dan tidak selalu dapat dibenarkan secara ekonomi. Saya tertarik dengan pendapat Anda - apakah startup harus segera mulai menulis untuk Kubernetes dari awal, atau apakah mereka masih bisa menulis monolit, lalu baru masuk ke Kubernetes?
Dmitry: Pertanyaan keren. Saya ingin berbicara tentang layanan mikro Berkali-kali saya menjumpai orang yang mencoba memalu paku dengan mikroskop. Pendekatannya sendiri sudah benar, kami sendiri yang mendesain perangkat lunak internal kami dengan cara ini. Namun ketika Anda melakukan ini, Anda perlu memahami dengan jelas apa yang Anda lakukan. Kata yang paling saya benci tentang layanan mikro adalah “mikro”. Secara historis, kata ini berasal dari sana, dan entah mengapa orang mengira mikro itu sangat kecil, kurang dari satu milimeter, seperti mikrometer. Ini salah.
Misalnya ada monolit yang ditulis oleh 300 orang, dan setiap orang yang ikut serta dalam pembangunan memahami bahwa ada permasalahan di sana, maka harus dipecah menjadi bagian-bagian mikro - sekitar 10 buah yang masing-masing ditulis oleh 30 orang. dalam versi minimum. Ini penting, perlu dan keren. Tetapi ketika sebuah startup datang kepada kami, di mana 3 orang yang sangat keren dan berbakat menulis 60 layanan mikro, setiap kali saya mencari Corvalol.
Tampaknya bagi saya hal ini telah dibicarakan ribuan kali - kami mendapatkan monolit yang didistribusikan dalam satu atau lain bentuk. Hal ini tidak dibenarkan secara ekonomi, secara umum sangat sulit dalam segala hal. Saya baru saja melihatnya berkali-kali sehingga itu sangat menyakitkan bagi saya, jadi saya terus membicarakannya.
Untuk pertanyaan awal, terdapat konflik antara fakta bahwa, di satu sisi, Kubernetes menakutkan untuk digunakan, karena tidak jelas apa yang mungkin rusak atau tidak berfungsi, di sisi lain, jelas semuanya berjalan di sana. dan hanya Kubernetes yang akan ada. Menjawab - pertimbangkan jumlah manfaat yang didapat, jumlah tugas yang dapat Anda selesaikan. Ini berada pada satu sisi skala. Di sisi lain, terdapat risiko yang terkait dengan waktu henti atau penurunan waktu respons, tingkat ketersediaan - dengan penurunan indikator kinerja.
Ini dia - apakah kita bergerak cepat, dan Kubernetes memungkinkan kita melakukan banyak hal dengan lebih cepat dan lebih baik, atau kita menggunakan solusi yang andal dan telah teruji waktu, tetapi bergerak lebih lambat. Ini adalah pilihan yang harus diambil oleh setiap perusahaan. Anda dapat menganggapnya sebagai jalan setapak di hutan - ketika Anda berjalan untuk pertama kalinya, Anda dapat bertemu dengan ular, harimau, atau musang gila, dan ketika Anda telah berjalan 10 kali, Anda telah menapaki jalan tersebut, menghilangkannya. dahan dan berjalan lebih mudah. Setiap saat jalannya semakin lebar. Kemudian jalan aspal, dan kemudian jalan raya yang indah.
Kubernetes tidak tinggal diam. Pertanyaan lagi: Kubernetes, di satu sisi, adalah 4-5 biner, di sisi lain, seluruh ekosistem. Ini adalah sistem operasi yang kami miliki di mesin kami. Apa ini? Ubuntu atau Curios? Ini adalah kernel Linux, sekumpulan komponen tambahan. Semua ini ada di sini, seekor ular berbisa dibuang dari jalan, sebuah pagar didirikan di sana. Kubernetes berkembang dengan sangat cepat dan dinamis, dan volume risiko, volume hal-hal yang tidak diketahui menurun setiap bulannya dan, oleh karena itu, skala-skala ini menjadi seimbang.
Menjawab pertanyaan tentang apa yang harus dilakukan sebuah startup, saya akan mengatakan - datang ke Flaunt, bayar 150 ribu rubel dan dapatkan layanan turnkey DevOps yang mudah. Jika Anda adalah startup kecil dengan beberapa pengembang, ini berhasil. Daripada mempekerjakan DevOps Anda sendiri, yang perlu mempelajari cara memecahkan masalah Anda dan membayar gaji saat ini, Anda akan mendapatkan solusi siap pakai untuk semua masalah. Ya, ada beberapa kelemahan. Kami sebagai agen outsourcing tidak bisa begitu saja terlibat dan merespon perubahan dengan cepat. Tapi kami memiliki banyak keahlian dan praktik siap pakai. Kami menjamin bahwa dalam situasi apa pun kami pasti akan segera mengetahuinya dan membangkitkan Kubernetes dari kematian.
Saya sangat menyarankan outsourcing ke perusahaan rintisan dan bisnis mapan hingga ukuran di mana Anda dapat mendedikasikan tim yang terdiri dari 10 orang untuk operasi, karena jika tidak, tidak ada gunanya. Sangat masuk akal untuk melakukan outsourcing ini.
Tentang Amazon dan Google
— Dapatkah host dari solusi dari Amazon atau Google dianggap sebagai outsourcing?
Dmitry: Ya, tentu saja, ini menyelesaikan sejumlah masalah. Tapi sekali lagi ada perbedaannya. Anda tetap perlu memahami cara menggunakannya. Misalnya, ada seribu hal kecil dalam pekerjaan Amazon AWS: Load Balancer perlu dihangatkan atau permintaan harus ditulis terlebih dahulu bahwa “teman-teman, kami akan menerima lalu lintas, hangatkan Load Balancer untuk kami!” Anda perlu mengetahui nuansa ini.
Ketika Anda beralih ke orang-orang yang berspesialisasi dalam hal ini, Anda hampir menutup semua hal yang umum. Kami sekarang memiliki 40 insinyur, pada akhir tahun mungkin akan ada 60 insinyur - kami pasti telah menemui semua hal ini. Bahkan jika kami menemui masalah ini lagi di suatu proyek, kami segera bertanya satu sama lain dan mengetahui cara mengatasinya.
Mungkin jawabannya adalah - tentu saja, cerita yang dihosting membuat beberapa bagian menjadi lebih mudah. Pertanyaannya adalah apakah Anda siap mempercayai hoster ini dan apakah mereka akan menyelesaikan masalah Anda. Amazon dan Google telah melakukannya dengan baik. Untuk semua kasus kami - tepatnya. Kami tidak memiliki pengalaman positif lainnya. Semua cloud lain yang kami coba kerjakan menciptakan banyak masalah - Ager, dan semua yang ada di Rusia, dan semua jenis OpenStack dalam implementasi berbeda: Headster, Overage - apa pun yang Anda inginkan. Semuanya menciptakan masalah yang tidak ingin Anda selesaikan.
Oleh karena itu, jawabannya adalah ya, namun kenyataannya, tidak banyak solusi host yang matang.
Siapa yang butuh Kubernetes?
— Namun, siapa yang butuh Kubernetes? Siapa yang seharusnya sudah beralih ke Kubernetes, siapakah tipikal klien Flaunt yang hadir khusus untuk Kubernetes?
Dmitry: Ini adalah pertanyaan yang menarik, karena saat ini, setelah Kubernetes, banyak orang mendatangi kami: “Teman-teman, kami tahu Anda sedang melakukan Kubernetes, lakukan untuk kami!” Kami menjawab mereka: “Tuan-tuan, kami tidak membuat Kubernetes, kami melakukan prod dan segala sesuatu yang berhubungan dengannya.” Karena saat ini tidak mungkin membuat suatu produk tanpa melakukan semua CI/CD dan keseluruhan cerita ini. Setiap orang telah menjauh dari pembagian yang kita miliki, pembangunan demi pembangunan, dan kemudian eksploitasi demi eksploitasi.
Klien kami mengharapkan hal yang berbeda, tetapi setiap orang menunggu keajaiban baik bahwa mereka memiliki masalah tertentu, dan sekarang - lompat! — Kubernetes akan menyelesaikannya. Orang-orang percaya pada keajaiban. Dalam pikiran mereka, mereka memahami bahwa tidak akan ada keajaiban, tetapi dalam jiwa mereka mereka berharap - bagaimana jika Kubernet ini sekarang akan menyelesaikan segalanya untuk kita, mereka banyak membicarakannya! Tiba-tiba dia sekarang - bersin! - dan peluru perak, bersin! — dan kami memiliki waktu aktif 100%, semua pengembang dapat merilis apa pun yang masuk ke produksi sebanyak 50 kali, dan tidak terjadi error. Secara umum, sebuah keajaiban!
Ketika orang-orang seperti itu datang kepada kita, kita berkata: “Maaf, tapi tidak ada yang namanya keajaiban.” Untuk menjadi sehat, Anda perlu makan dengan baik dan berolahraga. Untuk menghasilkan produk yang dapat diandalkan, produk tersebut harus dibuat dengan andal. Untuk memiliki CI/CD yang nyaman, Anda perlu membuatnya seperti ini. Banyak sekali pekerjaan yang perlu dilakukan.
Menjawab pertanyaan siapa yang membutuhkan Kubernetes - tidak ada yang membutuhkan Kubernetes.
Beberapa orang mempunyai kesalahpahaman bahwa mereka membutuhkan Kubernetes. Masyarakat membutuhkan, mereka memiliki kebutuhan yang mendalam untuk berhenti berpikir, belajar, dan tertarik pada semua masalah infrastruktur dan masalah menjalankan aplikasi mereka. Mereka ingin aplikasi berfungsi dan diterapkan. Bagi mereka, Kubernetes adalah harapan bahwa mereka akan berhenti mendengar cerita bahwa “kami terbaring di sana”, atau “kami tidak dapat meluncurkannya”, atau hal lainnya.
Direktur teknis biasanya mendatangi kami. Mereka menanyakan dua hal kepadanya: di satu sisi, memberi kita kekhasan, di sisi lain, stabilitas. Kami menyarankan Anda mengambil tindakan sendiri dan melakukannya. Solusi terbaiknya, atau lebih tepatnya berlapis perak, adalah Anda akan berhenti memikirkan masalah ini dan membuang-buang waktu. Anda akan memiliki orang-orang spesial yang akan menutup masalah ini.
Kata-kata yang mengatakan bahwa kita atau orang lain membutuhkan Kubernetes tidak benar.
Admin sangat membutuhkan Kubernetes, karena ini adalah mainan yang sangat menarik yang bisa kamu mainkan dan mainkan. Jujur saja - semua orang menyukai mainan. Kita semua adalah anak-anak di suatu tempat, dan ketika kita melihat sesuatu yang baru, kita ingin memainkannya. Bagi sebagian orang, hal ini tidak disarankan, misalnya di pemerintahan, karena mereka sudah cukup bermain dan sudah lelah sampai-sampai mereka tidak mau melakukannya. Namun hal ini tidak sepenuhnya hilang bagi siapa pun. Misalnya saya sudah lama bosan dengan mainan di bidang administrasi sistem dan DevOps, lalu saya tetap menyukai mainan itu, saya masih membeli yang baru. Semua orang, dengan satu atau lain cara, tetap menginginkan mainan.
Tidak perlu bermain-main dengan produksi. Apapun yang saya rekomendasikan untuk tidak dilakukan dan apa yang saya lihat sekarang secara massal: “Oh, mainan baru!” — mereka berlari untuk membelinya, membelinya dan: “Ayo kita bawa ke sekolah sekarang dan tunjukkan ke semua teman kita.” Jangan lakukan ini. Saya minta maaf, anak-anak saya baru saja tumbuh dewasa, saya terus-menerus melihat sesuatu pada anak-anak, memperhatikannya dalam diri saya, dan kemudian menggeneralisasikannya kepada orang lain.
Jawaban akhirnya adalah: Anda tidak memerlukan Kubernetes. Anda perlu menyelesaikan masalah Anda.
Yang dapat Anda capai adalah:
- dorongan tidak jatuh;
- bahkan jika dia mencoba untuk jatuh, kita mengetahuinya sebelumnya, dan kita dapat memasukkan sesuatu ke dalamnya;
- kita dapat mengubahnya sesuai dengan kebutuhan bisnis kita, dan kita dapat melakukannya dengan mudah; hal ini tidak menimbulkan masalah apa pun bagi kita.
Ada dua kebutuhan nyata: keandalan dan dinamisme/fleksibilitas peluncuran. Setiap orang yang saat ini melakukan beberapa jenis proyek TI, apa pun jenis bisnisnya - lunak untuk meringankan dunia, dan yang memahami hal ini, perlu menyelesaikan kebutuhan ini. Kubernetes dengan pendekatan yang tepat, dengan pemahaman yang tepat, dan pengalaman yang cukup memungkinkan Anda menyelesaikannya.
Tentang tanpa server
— Jika Anda melihat lebih jauh ke masa depan, kemudian mencoba memecahkan masalah tidak adanya masalah dengan infrastruktur, dengan kecepatan peluncuran dan kecepatan perubahan aplikasi, solusi baru muncul, misalnya, tanpa server. Apakah Anda merasakan adanya potensi ke arah ini dan, katakanlah, bahaya bagi Kubernetes dan solusi serupa?
Dmitry: Di sini kita perlu memberi komentar lagi bahwa saya bukanlah seorang pelihat yang melihat ke depan dan berkata - akan seperti ini! Meskipun saya baru saja melakukan hal yang sama. Saya melihat ke kaki saya dan melihat banyak masalah di sana, misalnya cara kerja transistor di komputer. Itu lucu, bukan? Kami menemukan beberapa bug di CPU.
Jadikan tanpa server cukup andal, murah, efisien, dan nyaman, menyelesaikan semua masalah ekosistem. Di sini saya setuju dengan Elon Musk bahwa planet kedua diperlukan untuk menciptakan toleransi kesalahan bagi umat manusia. Meskipun saya tidak tahu apa yang dia katakan, saya memahami bahwa saya sendiri belum siap untuk terbang ke Mars dan itu tidak akan terjadi besok.
Dengan tanpa server, jelas sekali bahwa ini adalah hal yang benar secara ideologis, seperti toleransi kesalahan bagi umat manusia - memiliki dua planet lebih baik daripada satu. Tapi bagaimana melakukannya sekarang? Mengirim satu ekspedisi tidak menjadi masalah jika Anda memusatkan upaya Anda padanya. Mengirim beberapa ekspedisi dan menempatkan beberapa ribu orang di sana, menurut saya, juga realistis. Tetapi untuk membuatnya benar-benar toleran terhadap kesalahan sehingga separuh umat manusia tinggal di sana, bagi saya sekarang tampaknya mustahil, jika tidak dipertimbangkan.
Dengan satu lawan satu tanpa server: hal itu keren, tetapi jauh dari masalah tahun 2019. Mendekati tahun 2030 - mari kita melihatnya secara langsung. Saya yakin kita akan hidup, kita pasti akan hidup (ulangi sebelum tidur), tapi sekarang kita perlu menyelesaikan masalah lain. Ini seperti mempercayai dongeng kuda poni Pelangi. Ya, beberapa persen kasus terselesaikan, dan terselesaikan dengan sempurna, namun secara subyektif, tanpa server adalah pelangi... Bagi saya, topik ini terlalu jauh dan tidak dapat dipahami. Saya belum siap untuk berbicara. Pada tahun 2019, Anda tidak dapat menulis satu aplikasi pun tanpa server.
Bagaimana Kubernetes akan berkembang
— Saat kita bergerak menuju masa depan yang berpotensi indah, menurut Anda bagaimana Kubernetes dan ekosistem di sekitarnya akan berkembang?
Dmitry: Saya sudah banyak memikirkan hal ini dan saya punya jawaban yang jelas. Yang pertama adalah statefull - lagipula, stateless lebih mudah dilakukan. Kubernetes awalnya berinvestasi lebih banyak dalam hal ini, semuanya dimulai dengan itu. Stateless berfungsi hampir sempurna di Kubernetes, tidak ada yang perlu dikeluhkan. Masih banyak masalah, atau lebih tepatnya, nuansa. Segala sesuatu di sana sudah bekerja dengan baik bagi kami, tapi itulah kami. Diperlukan setidaknya beberapa tahun lagi agar hal ini dapat diterapkan pada semua orang. Ini bukan indikator yang diperhitungkan, tapi perasaan saya dari kepala saya.
Singkatnya, statefull harus - dan akan - berkembang dengan sangat kuat, karena semua aplikasi kita menyimpan status; tidak ada aplikasi tanpa kewarganegaraan. Ini adalah ilusi; Anda selalu memerlukan semacam database dan sesuatu yang lain. Statefull adalah tentang meluruskan segala sesuatu yang mungkin, memperbaiki semua bug, memperbaiki semua masalah yang sedang dihadapi - sebut saja adopsi.
Tingkat ketidaktahuan, tingkat masalah yang belum terselesaikan, tingkat kemungkinan menghadapi sesuatu akan turun secara signifikan. Ini adalah cerita yang penting. Dan operator - segala sesuatu yang berkaitan dengan kodifikasi logika administrasi, logika kontrol untuk mendapatkan layanan yang mudah: layanan mudah MySQL, layanan mudah RabbitMQ, layanan mudah Memcache - secara umum, semua komponen yang kita butuhkan ini harus dijamin berfungsi kotak. Ini hanya mengatasi kesulitan karena kita menginginkan database, tetapi kita tidak ingin mengelolanya, atau kita menginginkan Kubernetes, tetapi kita tidak ingin mengelolanya.
Kisah pengembangan operator dalam satu atau lain bentuk akan menjadi penting dalam beberapa tahun mendatang.
Saya pikir kemudahan penggunaan akan meningkat pesat - kotak akan menjadi semakin hitam, semakin dapat diandalkan, dengan kenop yang semakin sederhana.
Saya pernah mendengarkan wawancara lama dengan Isaac Asimov dari tahun 80-an di YouTube pada acara Saturday Night Live - program seperti Urgant, hanya menarik. Mereka bertanya kepadanya tentang masa depan komputer. Ia mengatakan bahwa masa depan ada dalam kesederhanaan, seperti halnya radio. Penerima radio pada awalnya merupakan suatu hal yang kompleks. Untuk menangkap gelombang, Anda harus memutar kenop selama 15 menit, memutar tusuk sate dan secara umum mengetahui cara kerja semuanya, memahami fisika transmisi gelombang radio. Akibatnya, hanya tersisa satu kenop di radio.
Sekarang di tahun 2019 radio apa? Di dalam mobil, penerima radio menemukan semua gelombang dan nama stasiun. Proses fisikanya tidak berubah dalam 100 tahun, namun kemudahan penggunaannya tetap berubah. Sekarang, dan tidak hanya sekarang, pada tahun 1980, ketika ada wawancara dengan Azimov, semua orang menggunakan radio dan tidak ada yang memikirkan cara kerjanya. Itu selalu berhasil - itu sudah pasti.
Azimov kemudian mengatakan bahwa hal yang sama akan terjadi pada komputer - kemudahan penggunaan akan meningkat. Meskipun pada tahun 1980 Anda harus dilatih untuk menekan tombol di komputer, hal tersebut tidak akan terjadi di masa mendatang.
Saya merasa dengan Kubernetes dan infrastrukturnya juga akan ada peningkatan besar dalam kemudahan penggunaan. Menurut pendapat saya, ini jelas - itu terletak di permukaan.
Apa yang harus dilakukan dengan para insinyur?
— Lalu apa yang akan terjadi pada para insinyur dan administrator sistem yang mendukung Kubernetes?
Dmitry: Apa yang terjadi dengan akuntan setelah munculnya 1C? Hampir sama. Sebelumnya, mereka menghitung di atas kertas - sekarang dalam program. Produktivitas tenaga kerja telah meningkat berkali-kali lipat, namun tenaga kerja itu sendiri belum hilang. Jika sebelumnya dibutuhkan 10 insinyur untuk memasang sekrup pada sebuah bola lampu, kini satu saja sudah cukup.
Menurut saya, jumlah perangkat lunak dan jumlah tugas sekarang tumbuh lebih cepat daripada munculnya DevOps baru, dan efisiensinya meningkat. Ada kekurangan tertentu di pasar saat ini dan itu akan bertahan lama. Nanti semuanya akan kembali normal, di mana efisiensi kerja akan meningkat, akan ada lebih banyak serverless, sebuah neuron akan dilampirkan ke Kubernetes, yang akan memilih semua sumber daya persis seperti yang dibutuhkan, dan secara umum akan lakukan semuanya sendiri, sebagaimana mestinya - orang tersebut menjauh saja dan tidak ikut campur.
Namun seseorang masih perlu mengambil keputusan. Jelas bahwa tingkat kualifikasi dan spesialisasi orang tersebut lebih tinggi. Saat ini di bagian akuntansi tidak perlu 10 orang karyawan yang membuat pembukuan agar tangannya tidak cepat lelah. Itu tidak perlu. Banyak dokumen secara otomatis dipindai dan dikenali oleh sistem manajemen dokumen elektronik. Seorang kepala akuntan yang cerdas sudah cukup, sudah memiliki keterampilan yang jauh lebih baik, dan pemahaman yang baik.
Secara umum, ini adalah cara yang harus dilakukan di semua industri. Begitu pula dengan mobil: sebelumnya, sebuah mobil datang dengan seorang mekanik dan tiga orang pengemudi. Saat ini, mengendarai mobil adalah proses sederhana yang kita semua ikuti setiap hari. Tidak ada yang mengira bahwa mobil adalah sesuatu yang rumit.
DevOps atau rekayasa sistem tidak akan hilang - pekerjaan dan efisiensi tingkat tinggi akan meningkat.
— Saya juga mendengar gagasan menarik bahwa pekerjaan sebenarnya akan meningkat.
Dmitry: Tentu saja seratus persen! Karena jumlah perangkat lunak yang kami tulis terus bertambah. Jumlah masalah yang kami selesaikan dengan perangkat lunak terus bertambah. Jumlah pekerjaan semakin bertambah. Saat ini pasar DevOps sedang sangat panas. Hal ini terlihat dari ekspektasi gaji. Dalam arti yang baik, tanpa merinci, harusnya ada junior yang menginginkan X, middle yang menginginkan 1,5X, dan senior yang menginginkan 2X. Dan sekarang, jika Anda melihat pasar gaji DevOps Moskow, seorang junior menginginkan dari X menjadi 3X dan seorang senior menginginkan dari X menjadi 3X.
Tidak ada yang tahu berapa biayanya. Tingkat gaji diukur dengan kepercayaan diri Anda - benar-benar gila, sejujurnya, pasar yang sangat panas.
Tentu saja, situasi ini akan segera berubah - kejenuhan akan terjadi. Hal ini tidak terjadi dalam pengembangan perangkat lunak - terlepas dari kenyataan bahwa setiap orang membutuhkan pengembang, dan setiap orang membutuhkan pengembang yang baik, pasar memahami siapa yang bernilai - industri telah stabil. Tidak demikian halnya dengan DevOps saat ini.
— Dari apa yang saya dengar, saya menyimpulkan bahwa administrator sistem saat ini tidak perlu terlalu khawatir, tetapi inilah saatnya untuk meningkatkan keterampilannya dan bersiap menghadapi kenyataan bahwa besok akan ada lebih banyak pekerjaan, tetapi akan lebih berkualitas.
Dmitry: Seratus persen. Secara umum, kita hidup di tahun 2019 dan aturan hidupnya adalah sebagai berikut: pembelajaran seumur hidup - kita belajar sepanjang hidup kita. Bagi saya, sekarang semua orang sudah mengetahui dan merasakan hal ini, tetapi mengetahui saja tidak cukup - Anda harus melakukannya. Setiap hari kita harus berubah. Jika kita tidak melakukan hal ini, maka cepat atau lambat kita akan tersingkir dari profesi ini.
Bersiaplah untuk tikungan tajam 180 derajat. Saya tidak mengesampingkan situasi ketika sesuatu berubah secara radikal, sesuatu yang baru diciptakan - itu terjadi. Melompat! - dan kami sekarang bertindak berbeda. Penting untuk bersiap menghadapi hal ini dan tidak perlu khawatir. Bisa jadi besok semua yang saya lakukan menjadi tidak berguna - tidak ada apa-apa, saya telah belajar sepanjang hidup saya dan siap untuk mempelajari hal lain. Ini bukan masalah. Tidak perlu takut dengan keamanan kerja, namun Anda perlu bersiap untuk terus mempelajari sesuatu yang baru.
Keinginan dan satu menit iklan
- Apakah kamu punya keinginan?
Dmitry: Ya, saya punya beberapa keinginan.
Yang pertama dan pedagang - berlangganan . Pembaca yang budiman, buka YouTube dan berlangganan saluran kami. Dalam waktu sekitar satu bulan kami akan memulai ekspansi aktif pada layanan video. Kami akan memiliki banyak konten edukasi tentang Kubernetes, terbuka dan beragam: mulai dari hal-hal praktis, hingga laboratorium, hingga hal-hal teoritis mendasar yang mendalam dan cara menggunakan Kubernetes di tingkat prinsip dan pola.
Keinginan pedagang kedua adalah pergi ke dan memberi bintang karena kita memakannya. Jika Anda tidak memberi kami bintang, kami tidak akan punya apa pun untuk dimakan. Ini seperti mana dalam game komputer. Kami melakukan sesuatu, kami melakukan, kami mencoba, seseorang mengatakan bahwa ini adalah sepeda yang buruk, seseorang mengatakan bahwa semuanya salah, tetapi kami melanjutkan dan bertindak dengan jujur. Kami melihat masalah, menyelesaikannya, dan berbagi pengalaman. Oleh karena itu, berilah kami sebuah bintang, bintang itu tidak akan hilang darimu, tetapi bintang itu akan datang kepada kami, karena kami memakannya.
Ketiga, keinginan penting, dan bukan lagi keinginan dagang - berhenti percaya pada dongeng. Anda profesional. DevOps adalah profesi yang sangat serius dan bertanggung jawab. Berhenti bermain-main di tempat kerja. Biarkan itu diklik untuk Anda dan Anda akan memahaminya. Bayangkan Anda datang ke rumah sakit, dan di sana dokter sedang melakukan percobaan pada Anda. Saya memahami bahwa ini mungkin menyinggung seseorang, tetapi kemungkinan besar ini bukan tentang Anda, tetapi tentang orang lain. Beritahu yang lain untuk berhenti juga. Hal ini benar-benar menghancurkan kehidupan kita semua - banyak yang mulai memperlakukan operasi, admin, dan DevOps sebagai orang yang telah merusak sesuatu lagi. Ini "rusak" paling sering karena fakta bahwa kami pergi bermain, dan tidak melihat dengan kesadaran dingin bahwa memang begitulah adanya, dan memang begitulah adanya.
Ini tidak berarti Anda tidak boleh bereksperimen. Kita perlu bereksperimen, kita melakukannya sendiri. Sejujurnya, kita sendiri terkadang bermain game - ini tentu saja sangat buruk, tetapi tidak ada manusia yang asing bagi kita. Mari kita nyatakan tahun 2019 sebagai tahun eksperimen yang serius dan dipikirkan dengan matang, dan bukan permainan produksi. Mungkin begitu.
- Terima kasih banyak!
Dmitry: Terima kasih, Vitaly, atas waktunya dan wawancaranya. Pembaca yang budiman, terima kasih banyak jika Anda tiba-tiba mencapai titik ini. Saya harap kami memberi Anda setidaknya beberapa pemikiran.
Dalam wawancaranya, Dmitry menyinggung soal werf. Sekarang ini adalah pisau Swiss universal yang memecahkan hampir semua masalah. Namun tidak selalu demikian. Pada di festival tersebut Dmitry Stolyarov akan memberi tahu Anda tentang alat ini secara detail. dalam laporan akan ada segalanya: masalah dan nuansa tersembunyi Kubernetes, opsi untuk memecahkan kesulitan ini dan implementasi werf saat ini secara detail. Bergabunglah dengan kami pada tanggal 27 dan 28 Mei, kami akan menciptakan alat yang sempurna.
Sumber: www.habr.com