Kubernetes akan mengambil alih dunia. Kapan dan bagaimana?

Untuk mengantisipasi DevOpsConf, Vitaliy Khabarov mewawancarai Dmitry Stolyarov ( distol ), direktur teknis dan salah satu pendiri Flant. Vitaly bertanya kepada Dmitry tentang apa yang dilakukan Flant, tentang Kubernetes, pengembangan ekosistem, dukungan. Kami membahas mengapa Kubernet diperlukan dan apakah dibutuhkan sama sekali. Dan juga tentang microservices, Amazon AWS, pendekatan "I'm Lucky" di DevOps, masa depan Kubernetes itu sendiri, mengapa, kapan dan bagaimana ia akan mengambil alih dunia, prospek DevOps dan apa yang harus dipersiapkan para insinyur di masa depan yang cerah dan dekat dengan penyederhanaan dan jaringan saraf.

Dengarkan wawancara asli sebagai podcast di DevOps Deflop, podcast berbahasa Rusia tentang DevOps, dan di bawah ini adalah versi teks.



Selanjutnya Vitaliy Khabarov ditanyai pertanyaan oleh seorang insinyur dari Express42.

Tentang Flant

- Dima, hai. Anda adalah direktur teknis Flant dan juga pendirinya. Katakan, tolong, apa yang sedang dilakukan perusahaan dan apakah Anda ada di dalamnya?

Dmitry : Dari luar, sepertinya kita adalah orang-orang yang pergi, menaruh Kubernet pada semua orang dan melakukan sesuatu dengannya. Tapi ini tidak benar. Kami mulai sebagai perusahaan yang berurusan dengan Linux, tetapi untuk waktu yang sangat lama kegiatan utama kami adalah melayani produksi dan proyek-proyek turnkey highload. Biasanya kami membangun seluruh infrastruktur dari awal dan kemudian kami bertanggung jawab untuk itu untuk waktu yang lama. Oleh karena itu, pekerjaan utama yang dilakukan Flant, yang menerima uangnya, adalah untuk bertanggung jawab dan mengaktifkan implementasi produksi .


Sebagai direktur teknis dan salah satu pendiri perusahaan, saya bekerja sepanjang waktu untuk memikirkan cara-cara untuk meningkatkan ketersediaan produksi, menyederhanakan operasinya, membuat hidup lebih mudah bagi admin, dan membuat hidup lebih menyenangkan bagi para pengembang.

Tentang Kubernetes

- Terakhir kali dari "Flanta", saya melihat banyak laporan dan artikel tentang Kubernetes. Bagaimana Anda datang kepadanya?

Dmitry : Saya sudah membicarakan hal ini berkali-kali, tetapi saya sama sekali tidak menyesal mengulanginya. Saya percaya bahwa itu benar untuk mengulangi topik ini, karena ada kebingungan antara sebab dan akibat.

Kami benar-benar membutuhkan alat. Kami menghadapi banyak masalah, berjuang, mengatasinya dengan kruk yang berbeda dan merasakan kebutuhan akan instrumen. Diselidiki melalui berbagai pilihan, membangun sepeda mereka, mendapatkan pengalaman. Secara bertahap kami sampai pada titik kami mulai menggunakan Docker segera setelah muncul - sekitar 2013. Pada saat kemunculannya, kami sudah memiliki banyak pengalaman dengan wadah, kami sudah menulis analog "Docker" - beberapa kruk kami menggunakan Python. Dengan munculnya Docker, kruk dapat dibuang dan digunakan oleh solusi yang andal dan didukung komunitas.

Dengan Kubernetes, ceritanya mirip. Pada saat ia mulai mendapatkan momentum - bagi kami ini adalah versi 1.2 - kami sudah memiliki banyak kruk di Shell dan Chef, yang entah bagaimana kami coba mengatur Docker. Kami serius memandang ke arah Rancher dan berbagai solusi lain, tetapi kemudian Kubernetes muncul, di mana semuanya diterapkan persis seperti yang kami lakukan atau bahkan lebih baik. Tidak ada yang perlu dikeluhkan.

Ya, ada beberapa jenis ketidaksempurnaan, ada beberapa jenis ketidaksempurnaan - ada banyak ketidaksempurnaan, dan 1.2 umumnya mengerikan, tetapi .... Kubernetes seperti bangunan yang sedang dibangun - Anda melihat proyek dan memahami bahwa itu akan keren. Jika bangunan sekarang memiliki fondasi dan dua lantai, maka Anda memahami bahwa lebih baik untuk tidak mengisi, tetapi tidak ada masalah dengan perangkat lunak - Anda sudah dapat menggunakannya.

Kami tidak memiliki momen yang kami pikir untuk menggunakan Kubernetes atau tidak. Kami menunggunya jauh sebelum dia muncul, dan mencoba membuat analog sendiri.

Dekat Kubernetes

- Apakah Anda berpartisipasi langsung dalam pengembangan Kubernetes itu sendiri?

Dmitry : Biasa-biasa saja. Kami lebih cenderung berpartisipasi dalam pengembangan ekosistem. Kami mengirimkan sejumlah permintaan tarik: ke Prometheus, ke semua jenis operator, ke Helm ke ekosistem. Sayangnya, saya tidak dapat mengikuti semua yang kami lakukan dan saya bisa salah, tetapi tidak ada satu kolam pun dari inti kami.

- Apakah Anda mengembangkan banyak alat di sekitar Kubernetes?

Dmitry : Strateginya adalah ini: kita pergi dan tarik-tarik ke segala sesuatu yang sudah ada di sana. Jika permintaan tarik tidak diterima di sana, kami hanya membayarnya untuk diri kami sendiri dan hidup sampai diterima dengan bangunan kami. Kemudian, ketika mencapai hulu, kami kembali ke versi hulu.

Sebagai contoh, kami memiliki operator Prometheus yang kami gunakan untuk bolak-balik ke hulu perakitan 5 kali, mungkin. Kami memerlukan beberapa fitur, kami mengirimkan permintaan tarik, kami harus meluncurkannya besok, dan kami tidak ingin menunggu sampai dirilis di hulu. Karenanya, kami mengumpulkan sendiri, menggulung perakitan kami dengan fitur kami, yang karena alasan tertentu kami butuhkan, ke semua kluster kami. Kemudian, misalnya, mereka membungkus kita dengan kata-kata: "Guys, mari kita lakukan untuk kasus yang lebih umum", kita, atau orang lain, akan menyelesaikan ini, dan akhirnya bergabung lagi.

Segala sesuatu yang ada, kami coba kembangkan . Banyak elemen yang belum ada belum ditemukan atau telah ditemukan, tetapi belum dilaksanakan - kami sedang melakukannya. Dan bukan karena kita menyukai proses itu sendiri atau membangun sepeda sebagai industri, tetapi hanya karena kita membutuhkan alat ini. Mereka sering bertanya, mengapa kita melakukan ini atau itu? Jawabannya sederhana - karena kami harus melangkah lebih jauh, menyelesaikan beberapa masalah praktis, dan kami menyelesaikannya dengan alat ini.

Caranya selalu seperti ini: kita melihat dengan sangat hati-hati dan, jika kita tidak menemukan solusi, bagaimana membuat bus troli dari sepotong roti, maka kita membuat roti sendiri dan bus troli kita sendiri.

Alat Buang

“Saya tahu Flant sekarang memiliki operator tambahan, operator shell, alat dapp / werf. Seperti yang saya pahami, ini adalah alat yang sama dalam inkarnasi yang berbeda. Saya juga mengerti bahwa ada banyak lagi alat yang berbeda di dalam Flant. Benarkah begitu?

Dmitry : Kami masih memiliki banyak hal di GitHub. Dari apa yang saya ingat sekarang, kami memiliki peta status - panel untuk Grafana yang telah dinikmati semua orang. Disebutkan di hampir setiap artikel kedua tentang pemantauan Kubernetes di Medium. Tidak mungkin untuk menggambarkan secara singkat apa itu statusmap - Anda memerlukan artikel terpisah, tetapi ini adalah hal yang sangat berguna untuk memantau status dari waktu ke waktu, karena di Kubernetes kita sering perlu menunjukkan status dari waktu ke waktu. Kami juga memiliki LogHouse - ini adalah ClickHouse dan karya berbasis ilmu hitam untuk mengumpulkan log di Kubernetes.

Banyak utilitas! Dan akan ada lebih banyak lagi, karena sejumlah solusi internal akan dirilis tahun ini. Dari operator berbasis addon yang sangat besar, ada banyak addon ke Kubernetes, tetapi bagaimana cara menginstal sert manager - alat manajemen sertifikat, cara menginstal Prometheus dengan sekelompok dodges - ini adalah dua puluh binari berbeda yang mengekspor data dan mengumpulkan sesuatu, untuk ini Prometheus adalah grafik dan peringatan yang luar biasa. Semua ini hanyalah sekelompok add-on pada Kubernet yang dimasukkan ke dalam cluster, dan itu berubah dari yang sederhana menjadi keren, canggih, otomatis, di mana banyak masalah telah diselesaikan. Ya, kami banyak melakukan.

Pengembangan ekosistem

- Tampak bagi saya bahwa ini adalah kontribusi yang sangat besar untuk pengembangan alat ini dan metode penggunaannya. Dapatkah Anda secara kasar mencari tahu siapa lagi yang akan memberikan kontribusi yang sama untuk pengembangan ekosistem?

Dmitry : Di Rusia, tidak ada perusahaan yang beroperasi di pasar kami yang tutup . Tentu saja, ini adalah pernyataan profil tinggi, karena ada pemain besar seperti Mail with Yandex - mereka juga melakukan sesuatu dengan Kubernetes, tetapi bahkan mereka tidak cocok dengan kontribusi perusahaan di dunia, yang melakukan lebih banyak daripada yang kita lakukan. Sulit membandingkan Flant dengan staf 80 orang dan Red Hat, di mana hanya ada 300 insinyur Kubernet, jika saya tidak salah. Sulit untuk dibandingkan. Kami memiliki 6 orang di departemen RnD, termasuk saya, yang melihat semua alat kami. 6 orang melawan 300 insinyur Red Hat - entah bagaimana sulit untuk dibandingkan.

- Namun demikian, ketika 6 orang ini dapat melakukan sesuatu yang benar-benar bermanfaat dan teralienasi, ketika mereka dihadapkan dengan tugas praktis dan memberikan keputusan kepada masyarakat - sebuah kasus yang menarik. Saya mengerti bahwa di perusahaan teknologi besar, di mana mereka memiliki pengembangan sendiri dan tim pendukung Kubernetes, pada prinsipnya, alat yang sama dapat dikembangkan. Ini adalah contoh bagi mereka yang dapat dikembangkan dan diberikan kepada komunitas, untuk memberikan dorongan kepada seluruh komunitas yang menggunakan Kubernetes.

Dmitry : Ini mungkin chip integrator, fiturnya. Kami memiliki banyak proyek dan kami melihat banyak situasi yang berbeda. Bagi kami, cara utama untuk menciptakan nilai tambah adalah menganalisis kasus-kasus ini, menemukan yang umum dan membuatnya semurah mungkin bagi kami. Kami secara aktif melakukan ini. Sulit bagi saya untuk berbicara tentang Rusia dan dunia, tetapi kami memiliki sekitar 40 insinyur DevOps di Kubernetes. Saya tidak berpikir bahwa di Rusia ada banyak perusahaan dengan jumlah spesialis yang sebanding yang memahami Kubernet, jika ada.

Saya mengerti segala sesuatu tentang jabatan insinyur insinyur, semua orang mengerti segalanya dan terbiasa memanggil insinyur insinyur DevOps, kita tidak akan membahas ini. Ke-40 insinyur DevOps yang hebat ini menghadapi masalah setiap hari dan menyelesaikannya, kami hanya menganalisis pengalaman ini dan mencoba merangkumnya. Kami memahami bahwa jika itu tetap bersama kami, maka dalam satu atau dua tahun alat ini tidak berguna, karena di suatu tempat di komunitas alat siap pakai akan muncul. Tidak masuk akal untuk mengakumulasikan pengalaman ini di dalam - itu hanya menguras waktu dan energi dalam dev / null. Jadi kami sama sekali tidak menyesal. Dengan senang hati kami mempublikasikan semuanya dan memahami bahwa kami perlu mempublikasikan, mengembangkan, mempromosikan, mempromosikannya, sehingga orang dapat menggunakan dan menambahkan pengalaman mereka sendiri - kemudian semuanya tumbuh dan hidup. Kemudian, setelah dua tahun, alat itu tidak pergi ke tempat sampah. Sangat disayangkan untuk terus menuangkan energi, karena jelas bahwa seseorang menggunakan alat Anda, dan setelah dua tahun semua orang menggunakannya.

Ini adalah bagian dari strategi besar kami dengan dapp / werf . Saya tidak ingat ketika kami mulai melakukannya, tampaknya, sekitar 3 tahun yang lalu. Awalnya, itu umumnya di shell. Itu adalah bukti super konsep, kami menyelesaikan beberapa tugas pribadi kami - ternyata! Tetapi ada masalah dengan shell, tidak mungkin untuk membuatnya lebih lanjut, pemrograman pada shell adalah sesuatu yang lain. Kami memiliki kebiasaan menulis di Ruby, masing-masing, di Ruby kami mengubah sesuatu, mengembangkan, mengembangkan, mengembangkan, dan bertumpu pada kenyataan bahwa komunitas, kerumunan yang tidak mengatakan "kami ingin atau tidak ingin", menampakkan hidung Ruby, itu tidak lucu. Kami menyadari bahwa kami harus menulis semua hal ini di Go, hanya agar sesuai dengan paragraf pertama dalam daftar periksa: DevOps-tool harus berupa biner statis . On Go atau tidak Go tidak begitu penting, tetapi biner statis yang ditulis dalam Go lebih baik.

Menghabiskan upaya, menulis ulang dapp on Go dan menamainya werf. Dapp tidak lagi didukung, tidak berkembang, ia bekerja di beberapa versi terbaru, tetapi ada jalur peningkatan absolut ke atas, dan Anda dapat mengikutinya.

Mengapa dapp dibuat?

- Bisakah Anda memberi tahu kami secara singkat mengapa dapp dibuat, masalah apa yang dipecahkan?

Dmitry : Alasan pertama di majelis. Awalnya, kami memiliki masalah pembangunan yang kuat ketika Docker tidak tahu bagaimana multi-stage, dan kami melakukan multi-stage sendiri. Lalu kami punya banyak pertanyaan dengan membersihkan gambar. Setiap orang yang membuat CI / CD, lebih cepat daripada nanti, menghadapi masalah bahwa ada banyak gambar yang terkumpul, Anda perlu membersihkan apa yang tidak diperlukan dan meninggalkan apa yang dibutuhkan.

Alasan kedua ada di deploy. Ya, ada Helm, tetapi itu hanya memecahkan sebagian dari masalah. Ironisnya, ada tertulis bahwa "Helm - Manajer Paket untuk Kubernetes". Yaitu bahwa "itu". Ada juga kata-kata "Package Manager" - apa harapan yang biasa dari Package Manager? Kami mengatakan: "Package Manager - kirimkan paket!" dan berharap dia memberi tahu kami: "Paketnya sudah dikirim."

Sangat menarik bahwa kita mengatakan: "Helm, letakkan paket", dan ketika dia menjawab bahwa dia telah menginstalnya, ternyata dia baru saja memulai instalasi - Kubernetes menunjukkan: "Jalankan benda ini!", Tapi itu dimulai atau tidak, itu berfungsi atau tidak Helm sama sekali tidak menyelesaikan masalah ini.

Ternyata Helm hanyalah preprocessor teks yang memuat data ke Kubernetes.

Tapi kami ingin tahu dalam kerangka penyebaran apa pun - aplikasi telah diluncurkan ke prod atau tidak? Digulirkan ke prod berarti aplikasi telah masuk ke sana, versi baru telah digunakan, dan setidaknya tidak macet dan merespons dengan benar. Helm tidak menyelesaikan masalah ini. Untuk mengatasinya, Anda perlu menghabiskan banyak energi, karena Anda perlu memberi Kubernetes perintah untuk meluncurkan dan memantau apa yang terjadi di sana - apakah itu berbalik, apakah itu diluncurkan. Dan ada juga banyak tugas yang terkait dengan penyebaran, pembersihan, dan perakitan.

Paket

Tahun ini kita akan pergi ke pengembangan lokal. Kami ingin mengetahui apa yang dulunya ada di Vagrant - kami mengetik "vagrant up" dan kami menggunakan mesin virtual. Kami ingin sampai pada keadaan bahwa ada sebuah proyek di Git, kami menulis "werf" di sana, dan ia memunculkan salinan lokal dari proyek ini, yang digunakan dalam mini-Kub lokal, dengan semua direktori yang nyaman untuk pengembangan yang terhubung. Tergantung pada bahasa pengembangan, ini dilakukan dengan cara yang berbeda, tetapi, bagaimanapun, sehingga nyaman untuk melakukan pengembangan lokal di bawah file yang di-mount.

Langkah selanjutnya bagi kami adalah berinvestasi besar-besaran untuk kenyamanan pengembang . Untuk menyebarkan proyek secara cepat, dengan satu alat, untuk menyelesaikan, mendorong ke Git, dan itu juga akan diluncurkan ke tahap atau tes, tergantung pada pipa, dan kemudian pergi ke prod dengan alat yang sama. Kesatuan, penyatuan, reproduksibilitas infrastruktur ini dari lingkungan lokal hingga penjualan adalah momen yang sangat penting bagi kami. Tapi ini belum dalam werf - hanya berencana untuk melakukannya.

Tapi jalan menuju dapp / werf selalu sama dengan Kubernetes pada awalnya. Kami mengalami masalah, menyelesaikannya dengan solusi - kami menemukan beberapa solusi untuk diri kita sendiri, pada apa pun. Kemudian solusi ini mencoba untuk meluruskan, menggeneralisasi, dan mengkonsolidasikan menjadi biner dalam kasus ini, yang kami bagikan dengan mudah.

Ada pandangan lain dari keseluruhan cerita ini, dengan analogi.

Kubernetes adalah bingkai mobil dengan mesin. Tidak ada pintu, jendela, radio, pohon Natal - tidak ada sama sekali. Hanya rangka dan mesinnya. Dan ada Helm - itu setir. Keren - ada setir, tapi masih butuh pin, rak setir, gearbox dan roda, tapi tanpa apa-apa.

Dalam hal werf, ini adalah komponen lain untuk Kubernetes. Hanya sekarang dalam versi alpha werf kami, misalnya, Helm mengkompilasi menjadi werf sama sekali, karena kami lelah melakukan ini sendiri. Ada banyak alasan untuk melakukan ini, secara rinci tentang mengapa kami mengkompilasi helm secara keseluruhan bersama dengan anakan di dalam werf, saya akan memberitahu hanya pada laporan di RIT ++ .

Sekarang werf adalah komponen yang lebih terintegrasi. Kami mendapatkan setir yang sudah jadi, pin kemudi - Saya tidak terlalu pandai dalam mobil, tapi ini adalah blok besar yang sudah menyelesaikan berbagai tugas yang cukup luas. Kita tidak perlu memanjat katalog sendiri, mengambil satu bagian ke bagian lain, memikirkan cara mengikatnya satu sama lain. Kami mendapatkan kombinasi siap pakai yang segera menyelesaikan sekumpulan besar tugas. Tetapi di dalamnya terdiri dari semua komponen open source yang sama, ia juga menggunakan Docker untuk perakitan, Helm untuk bagian dari fungsi, dan ada beberapa perpustakaan lainnya. Ini adalah alat terintegrasi untuk mendapatkan CI / CD yang cepat dan mudah digunakan.

Apakah Kubernet sulit dipertahankan?

- Anda berbicara tentang pengalaman bahwa Anda mulai menggunakan Kubernetes, ini adalah bingkai, mesin untuk Anda, dan bahwa Anda dapat menggantung banyak hal yang berbeda di atasnya: bodi, roda kemudi, kencangkan pedal, kursi. Pertanyaannya adalah - seberapa sulitkah dukungan Kubernetes untuk Anda? Anda memiliki pengalaman yang kaya, berapa banyak waktu dan sumber daya yang Anda perlukan untuk mendukung Kubernetes secara terpisah dari yang lainnya?

Dmitry : Ini adalah pertanyaan yang sangat sulit dan untuk menjawab, Anda perlu memahami apa itu dukungan dan apa yang kami inginkan dari Kubernetes. Mungkin Anda akan mengungkapkan?

- Sejauh yang saya tahu dan seperti yang saya lihat, sekarang banyak tim ingin mencoba Kubernet. Semua orang memanfaatkannya, berlutut. Saya memiliki perasaan bahwa orang tidak selalu memahami kompleksitas sistem ini.

Dmitry : Itu dia.

- Seberapa sulitkah untuk mengambil dan mengirimkan Kubernet tanpa apa pun untuk membuatnya siap?

Dmitry : Apakah Anda berpikir betapa sulitnya transplantasi jantung? Saya mengerti, pertanyaannya kompromi. Untuk membawa dengan pisau bedah dan tidak membuat kesalahan tidak begitu sulit. Jika Anda diberitahu di mana harus memotong dan di mana menjahit, maka prosedurnya sendiri sederhana. Sulit untuk menjamin dari waktu ke waktu bahwa semuanya akan berhasil.

Masukkan Kubernetes dan buat itu bekerja mudah: cewek! - Disampaikan, ada banyak metode instalasi. Tetapi apa yang terjadi ketika masalah muncul?

Pertanyaan selalu muncul - apa yang belum kita perhitungkan? Apa yang belum kita lakukan? Parameter kernel Linux apa yang Anda sebutkan salah? Tuhan, apakah kita bahkan menunjukkannya ?! Komponen Kubernet mana yang telah kami kirim dan yang tidak? Ribuan pertanyaan muncul, dan untuk menjawabnya, Anda perlu memasak selama 15-20 tahun di industri ini.

Saya punya contoh baru tentang topik ini yang mungkin mengungkapkan arti dari masalah “Apakah sulit untuk mempertahankan Kubernetes?”. Beberapa waktu lalu, kami dengan serius mempertimbangkan apakah kami harus mencoba menerapkan Cilium sebagai jaringan di Kubernetes.

Mari saya jelaskan apa itu Cilium. Kubernetes memiliki banyak implementasi berbeda dari subsistem jaringan, dan salah satunya sangat keren - itu adalah Cilium. Apa maknanya? Di kernel beberapa waktu yang lalu menjadi mungkin untuk menulis kait untuk kernel yang entah bagaimana menyerang subsistem jaringan dan berbagai subsistem lainnya dan memungkinkan Anda untuk memotong potongan besar di kernel.

Kernel Linux secara historis memiliki ip rout, superfilter, bridges, dan banyak komponen lama lainnya yang berusia 15, 20, 30 tahun. Secara umum, mereka bekerja, semuanya keren, tetapi sekarang mereka telah membuat wadah berisi kontainer, dan itu terlihat seperti menara 15 batu bata di atas satu sama lain, dan Anda berdiri di atasnya dengan satu kaki - sensasi yang aneh. Sistem ini secara historis dikembangkan dengan banyak nuansa, seperti lampiran dalam tubuh. Dalam beberapa situasi, ada masalah dengan kinerja, misalnya.

Ada BPF yang luar biasa dan kemampuan untuk menulis kait untuk kernel - para lelaki menulis kait mereka untuk kernel. Paket datang ke kernel Linux, mereka mengeluarkannya tepat pada input, memprosesnya sendiri tanpa jembatan, tanpa TCP, tanpa tumpukan IP - singkatnya, melewati semua yang ditulis dalam kernel Linux, dan segera memuntahkannya dalam wadah.

Apa yang terjadi Performa sangat keren, fitur keren - hebat! Tapi kami melihat ini dan melihat bahwa pada setiap mesin ada program yang menghubungkan ke API Kubernetes dan, menurut data yang diterima dari API ini, menghasilkan kode C dan mengkompilasi binari yang dimuat ke dalam kernel sehingga kait ini bekerja di ruang kernel .

Apa yang terjadi jika terjadi kesalahan? Kami tidak tahu. Untuk memahami ini, Anda perlu membaca semua kode ini, memahami semua logika, dan ini mengejutkan, betapa sulitnya. Tapi, di sisi lain, ada jembatan, filter bersih, ip rout - saya tidak membaca sumbernya, dan 40 insinyur yang bekerja di perusahaan kami juga. Mungkin beberapa bagian memahami unit.

Dan apa bedanya? Ternyata ada ip rout, kernel Linux, dan ada alat baru - apa bedanya, kita tidak mengerti satu atau yang lain. Tapi kami takut menggunakan yang baru - mengapa? Karena jika alat ini berusia 30 tahun, maka lebih dari 30 tahun semua bug telah ditemukan, semua penggaruk telah datang dan Anda tidak perlu tahu segalanya - itu berfungsi seperti kotak hitam dan selalu berfungsi. Semua orang tahu obeng diagnostik mana yang akan menempel di mana, yang tcpdump pada titik mana untuk memulai. Semua orang tahu utilitas diagnostik dengan baik dan memahami bagaimana rangkaian komponen ini bekerja di kernel Linux - bukan cara kerjanya, tetapi bagaimana menggunakannya.

Dan Cilium yang sangat keren belum berumur 30 tahun, belum matang. Dengan Kubernet masalah yang sama, salin. Bahwa Cilium diatur dengan sempurna, bahwa Kubernetes diatur dengan sempurna, tetapi ketika terjadi kesalahan pada prod, apakah Anda dapat dengan cepat memahami apa yang salah dalam situasi kritis?

Ketika kami mengatakan sulit untuk mempertahankan Kubernetes, tidak, itu sangat sederhana, dan ya, itu sangat sulit. Kubernetes , .

« »

— , ? , Kubernetes, - .

: , , . , Kubernetes, . , ? , , , . , — , . Kubernetes.

Ubuntu 16.04. , , , LTS. systemd, , C-. Kubernetes , C-, , - — , , — systemd. , . highload. , , Cron Job, , Ubuntu 16.04 . load average - , C-. , , Ubuntu 16 Kubernetes.

, - systemd - , Linux 4.16 — C- . . , , 15 , C-, , — .

. , - — , . — Kubernetes, — . . , - - , , , . , Kubernetes — ?

, , , . , .

, , , , . .

IT, , « ». , , . , . .

— : , , «», , Red Hat, , Kubernetes, .

: . Kubernetes — .

?

— , Kubernetes ?

: , , -. : «Kubernetes, Kubernetes», . , , , 70% Kubernetes. .

— ? «» , Kubernetes — -.

, Kubernetes .

game-changer . — , Ansible, Chef, , Terraform. . Kubernetes — changer , .

, - , - , . , , Kubernetes : , infrastructure as code , , yml — . , .

— , Kubernetes, . ?

: . , dns-, FreeBSD 4.10 20 . . , 20 - . , - , , , , Kubernetes. .

, CI/CD — , Continuous Delivery, , , , — Kubernetes.

— . Kubernetes, — . — - , , , Kubernetes , . — Kubernetes - , Kubernetes?

: . «: ». , . , . , , . «». , , - , — , , . Ini tidak benar.

, , 300 , , , , , - — 10, 30 . , . , 3 60 , .

, — . , . , , .

, , , , Kubernetes , , , , , , Kubernetes, . — , , , . . — , , — .

— , Kubernetes , , , . . — , , , 10 — , . . , .

Kubernetes . : Kubernetes, , 4-5 , — . , . Apa ini Ubuntu Curios? Linux, . , . Kubernetes , , , , .

, , — «», 150 DevOps easy service. — . , DevOps, , . , . , , . , . , Kubernetes.

, 10 , . .

Amazon Google

— Amazon Google?

: , , . . , . , Amazon AWS: Load Balancer , «, , Load Balancer!» .

, , . 40 , , , 60 — . - , , .

, — , hosted- - . , , . Amazon Google . — . . clouds, , — Ager, , , OpenStack : Headster, Overage — , . , .

, — , , , hosted- .

Kubernetes?

— - Kubernetes? Kubernetes, «», Kubernetes?

: , Kubernetes : «, , Kubernetes, !». : «, Kubernetes, , ». , CI/CD , . , , .

, , , — ! — Kubernetes . . , , — Kubernetes , ! — ! — , ! — 100% uptime, 50 , . , !

, : «, ». , . , . CI/CD, . , .

, Kubernetes — Kubernetes .

, Kubernetes. , , , . , . Kubernetes — , , « », « », - .

. : , , — . . , , , , . , .

, - Kubernetes — .

Kubernetes , , , . — . - , — . - , , , , . . , DevOps , - , - . - .

. : «, !» — , : « , ». . , , - , , .

: Kubernetes. .

, :

• ;
  
• , , - ;
  
• , , , .
  

: / . , - IT-, , - — soft for easing the world, , . Kubernetes , .

Tentang serverless

- Jika Anda melihat sedikit lebih jauh ke masa depan, kemudian mencoba menyelesaikan masalah kurangnya sakit kepala dengan infrastruktur, dengan kecepatan roll-out dan kecepatan perubahan aplikasi, solusi baru muncul, misalnya, tanpa server. Apakah Anda merasakan potensi ke arah ini dan, katakanlah, bahaya bagi Kubernet dan solusi serupa?

Dmitry : Di sini kita perlu membuat pernyataan lagi, bahwa saya bukan visioner yang melihat ke depan dan berkata - itu akan menjadi seperti itu! Meskipun saya hanya melakukan hal yang sama. Saya melihat kaki saya dan melihat banyak masalah di sana, misalnya, bagaimana transistor bekerja di komputer. Lucu ya? Kami menemukan beberapa bug di CPU.

Membuat serverless cukup andal, murah, efisien dan nyaman, menyelesaikan semua masalah ekosistem. Lalu saya setuju dengan Elon Mask bahwa kita membutuhkan planet kedua untuk membuat toleransi kesalahan untuk kemanusiaan. Meskipun saya tidak tahu apa yang dia katakan, saya mengerti bahwa saya tidak siap untuk terbang ke Mars sendiri dan itu tidak akan terjadi besok.

Dengan serverless, jelas bahwa ini adalah hal yang benar secara ideologis, karena toleransi kesalahan untuk kemanusiaan - dua planet lebih baik dari satu. Tetapi bagaimana melakukannya sekarang? Mengirim satu ekspedisi tidak menjadi masalah jika kita berkonsentrasi pada upaya ini. Untuk mengirim beberapa ekspedisi dan mengisi beberapa ribu orang di sana, saya pikir, juga realistis. Tapi itu sepenuhnya untuk membuat toleransi kesalahan bahwa setengah dari umat manusia tinggal di sana, menurut saya sekarang mustahil, tidak dipertimbangkan.

Dengan serverless satu ke satu: masalahnya keren, tetapi jauh dari masalah 2019. Lebih dekat ke 2030 - mari kita hidup untuk melihatnya. Saya tidak ragu bahwa kita akan selamat, kita pasti akan selamat (ulangi sebelum tidur), tetapi sekarang kita perlu menyelesaikan masalah lain. Ini seperti percaya pada Rainbow pony yang luar biasa. Ya, beberapa persen kasus diselesaikan, dan diselesaikan dengan sempurna, tetapi secara subyektif serverless adalah pelangi ... Bagi saya topik ini terlalu jauh dan terlalu sulit dipahami. Saya belum siap untuk berbicara. Pada 2019, tanpa server, Anda tidak akan menulis satu aplikasi.

Bagaimana Kubernetes Akan Berkembang

"Ketika kita bergerak menuju masa depan yang berpotensi indah dan jauh ini, apa yang menurut Anda akan mengembangkan Kubernetes dan ekosistem di sekitarnya?"

Dmitry : Saya banyak memikirkan hal ini dan saya punya jawaban yang jelas. Yang pertama adalah statefull - masih stateless lebih mudah dilakukan. Kubernetes awalnya berinvestasi lebih banyak di dalamnya, semuanya dimulai dengan itu. Stateless berfungsi hampir sempurna di Kubernetes, tidak ada yang perlu dikeluhkan. Menurut statefull masih ada banyak masalah, atau lebih tepatnya, nuansa. Semuanya sudah bekerja dengan baik untuk kita di sana, tetapi kita ada. Agar ini bekerja untuk semua orang, Anda memerlukan setidaknya beberapa tahun lagi. Ini bukan indikator yang dihitung, tetapi perasaan saya dari kepala.

Singkatnya, statefull perlu - dan akan - mengembangkan sangat banyak, karena semua aplikasi kita berstatus, tidak ada aplikasi stateless. Ini adalah ilusi, Anda selalu membutuhkan semacam database dan sesuatu yang lain. Statefull adalah perbaikan segala sesuatu yang mungkin, koreksi semua bug, perbaikan semua masalah yang sedang dihadapi - sebut saja adopsi.

Tingkat ketidaktahuan, tingkat masalah yang belum terselesaikan, tingkat probabilitas untuk menghadapi sesuatu, akan turun tajam. Ini adalah kisah 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 perlu dijamin untuk bekerja di luar kotak. Ini hanya menyelesaikan rasa sakit yang kami inginkan dari sebuah basis data, tetapi tidak ingin mengelolanya, atau menginginkan Kubernetes, tetapi tidak ingin mengelolanya.

Kisah ini dengan perkembangan operator dalam satu atau lain bentuk akan menjadi penting dalam beberapa tahun mendatang.

Saya pikir kemudahan penggunaan harus sangat meningkat - kotak akan menjadi lebih dan lebih hitam, lebih dan lebih dapat diandalkan, dengan tikungan yang semakin sederhana.

Saya pernah mendengarkan wawancara Isaac Asimov yang berusia 80-an di YouTube pada Saturday Night Live, acara mirip-Urgant yang sangat menarik. Dia ditanya tentang masa depan komputer di sana. Dia mengatakan bahwa masa depan itu sederhana, seperti halnya dengan radio. Awalnya radio itu rumit. Untuk menangkap gelombang, butuh 15 menit untuk memutar-mutar putaran, memutar-mutar tusuk sate dan umumnya tahu cara kerja semuanya, untuk memahami fisika transmisi gelombang radio. Akibatnya, satu putaran tetap ada di radio.

Sekarang pada 2019, radio mana? Di dalam mobil, radio menemukan semua gelombang, nama stasiun. Fisika proses tidak berubah dalam 100 tahun, kemudahan penggunaan telah berubah. Sekarang, dan bukan hanya sekarang, sudah pada tahun 1980, ketika ada wawancara dengan Azimov, semua orang menggunakan radio dan tidak ada yang memikirkan bagaimana mengaturnya. Itu selalu berhasil - itu diberikan.

Azimov kemudian mengatakan bahwa itu akan serupa dengan komputer - kemudahan penggunaan akan meningkat . Jika pada tahun 1980 Anda perlu mendapatkan pendidikan khusus untuk menekan tombol pada komputer, maka di masa depan hal ini tidak akan terjadi.

Saya merasa bahwa dengan Kubernetes dan dengan infrastruktur, kemudahan penggunaan juga akan meningkat secara dramatis. Ini, menurut saya, jelas - itu terletak di permukaan.

Apa yang harus dilakukan dengan para insinyur?

- Lalu apa yang akan terjadi pada para insinyur, administrator sistem yang mendukung Kubernetes?

Dmitry : Dan apa yang terjadi pada akuntan setelah kemunculan 1C? Hampir sama. Sebelum itu, mereka berpikir di selembar kertas - sekarang dalam program. Produktivitas tenaga kerja telah meningkat dengan urutan besarnya, dan tenaga kerja itu sendiri belum menghilang dari ini. Sebelumnya, 10 insinyur perlu memasang bohlam, tapi sekarang satu sudah cukup.

Jumlah perangkat lunak dan jumlah tugas, menurut saya, sekarang tumbuh pada kecepatan yang lebih besar daripada DevOps baru dan efisiensinya meningkat. Ada kekurangan spesifik di pasar dan itu akan bertahan lama. Nantinya, semuanya akan masuk ke norma tertentu, di mana efisiensi kerja akan meningkat, itu akan menjadi lebih tanpa server, mereka akan melampirkan neuron ke Kubernetes, yang akan memilih semua sumber daya dengan benar sebagaimana mestinya, dan secara umum akan melakukan segalanya sebagaimana mestinya - orang itu pergi dan tidak mengganggu.

Tapi bagaimanapun, seseorang harus membuat keputusan. Jelas bahwa tingkat kualifikasi dan spesialisasi orang ini lebih tinggi. Sekarang di departemen akuntansi Anda tidak perlu 10 karyawan yang menyimpan buku sehingga tangan mereka tidak lelah. Itu tidak perlu. Banyak dokumen dipindai secara otomatis dan dikenali oleh sistem manajemen dokumen elektronik. Satu akuntan kepala yang pintar sudah cukup, sudah dengan keterampilan yang jauh lebih besar, dengan pemahaman yang baik.

Secara umum, jalan seperti itu di semua sektor. Itu sama dengan mobil: sebelumnya, seorang mekanik mobil dan tiga pengemudi melekat pada mobil. Sekarang mengendarai mobil adalah proses paling sederhana di mana kita semua berpartisipasi setiap hari. Tidak ada yang berpikir bahwa mobil adalah sesuatu yang rumit.

DevOps atau rekayasa sistem tidak akan pergi ke mana pun - tingkat tinggi dan efisiensi operasional akan meningkat.

- Saya juga mendengar ide yang menarik bahwa sebenarnya pekerjaan 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 bertambah. Sekarang pasar DevOps sangat panas. Ini terlihat dari ekspektasi gaji. Dalam cara yang baik, tanpa merinci, harus ada junior yang menginginkan X, middle yang ingin 1.5X, dan senior yang menginginkan 2X. Dan sekarang, jika Anda melihat pasar gaji DevOps Moskow, permintaan junior dari X ke 3X dan keinginan senior dari X ke 3X.

Tidak ada yang tahu berapa harganya. Tingkat gaji Anda diukur dengan kepercayaan diri Anda - rumah sakit jiwa yang lengkap, jujur, pasar sangat panas.

Tentu saja, situasi ini akan berubah segera - beberapa kejenuhan akan datang. Dengan pengembangan perangkat lunak, ini tidak terjadi - terlepas dari kenyataan bahwa setiap orang membutuhkan pengembang dan semua orang membutuhkan pengembang yang baik, pasar memahami berapa biayanya - industri telah tenang. Ini tidak terjadi dengan DevOps.

- Dari apa yang saya dengar, saya menyimpulkan bahwa administrator sistem saat ini seharusnya tidak terlalu khawatir, tetapi sudah waktunya untuk mengunduh keterampilan dan mempersiapkan fakta bahwa besok akan ada lebih banyak pekerjaan, tetapi akan lebih berkualitas.

Dmitry : Tentu saja. Secara umum, kita hidup di 2019 dan aturan hidup adalah ini: belajar seumur hidup - kita belajar seluruh hidup kita . Tampaknya bagi saya bahwa sekarang semua orang tahu dan merasakannya, tetapi mengetahui sedikit itu perlu. Setiap hari kita harus berubah. Jika tidak, maka cepat atau lambat kita akan turun di sela-sela profesi.

Bersiaplah untuk belokan tajam 180 derajat. Saya tidak mengesampingkan situasi ketika sesuatu berubah secara dramatis, mereka datang dengan sesuatu yang baru - itu terjadi. Hop! - dan sekarang kami bertindak berbeda. Penting untuk dipersiapkan untuk ini dan tidak untuk uap. Mungkin saja besok semua yang saya lakukan tidak perlu - tidak ada, saya sudah mempelajari seluruh hidup saya dan siap untuk belajar sesuatu yang lain. Ini bukan masalah. Anda seharusnya tidak takut akan keamanan pekerjaan, tetapi Anda harus siap untuk terus-menerus mempelajari sesuatu yang baru.

Keinginan dan iklan sebentar

- Apakah Anda punya keinginan?

Dmitry : Ya, saya punya beberapa keinginan.

Yang pertama dan pedagang - berlangganan ke YouTube . Pembaca yang budiman, buka YouTube dan berlangganan saluran kami. Dalam sekitar satu bulan, kami akan memulai ekspansi aktif ke layanan video. Kami akan memiliki banyak konten pendidikan tentang Kubernet, terbuka dan berbeda: dari hal-hal praktis, hingga laboratorium, hingga hal-hal teoretis yang mendasar dan bagaimana menerapkan Kubernet pada tingkat prinsip dan pola.

Keinginan pedagang kedua - pergi ke GitHub dan meletakkan bintang, karena kita memakannya. Jika Anda tidak memberi kami bintang, kami tidak punya apa-apa untuk dimakan. Ini seperti mana dalam game komputer. Kami sedang melakukan sesuatu, melakukan, mencoba, seseorang mengatakan bahwa ini adalah sepeda yang mengerikan, seseorang yang semuanya umumnya salah, dan kami melanjutkan dan bertindak benar-benar jujur. Kami melihat masalah, menyelesaikannya dan berbagi pengalaman kami. Karena itu, beri kami tanda bintang, itu tidak akan berkurang dari Anda, tetapi itu akan datang kepada kami, karena kami memakannya.

Keinginan ketiga, penting, dan bukan lagi keinginan dagang - berhenti percaya pada dongeng . Anda adalah profesional. DevOps adalah profesi yang sangat serius dan bertanggung jawab. Berhentilah bermain di tempat kerja. Biarkan Anda mengklik dan Anda akan memahaminya. Bayangkan Anda akan datang ke rumah sakit, dan di sana dokter akan bereksperimen dengan Anda. Saya mengerti bahwa ini bisa menyinggung seseorang, tetapi kemungkinan besar ini bukan tentang Anda, tetapi tentang orang lain. Beritahu orang lain untuk berhenti juga. Ini benar-benar merusak kehidupan kita semua - banyak yang mulai berhubungan dengan eksploitasi, admin dan DevOps, seperti dudes yang lagi-lagi merusak sesuatu. Ini "rusak" paling sering karena fakta bahwa kami pergi bermain, dan tidak melihat dengan kesadaran dingin bahwa itu seperti itu, tetapi seperti itu.

Ini tidak berarti bahwa Anda tidak perlu bereksperimen. Kita perlu bereksperimen, kita melakukannya sendiri. Sejujurnya, kami sendiri juga terkadang bermain - ini, tentu saja, sangat buruk, tetapi tidak ada manusia yang asing bagi kami. Mari kita nyatakan tahun 2019 sebagai tahun percobaan serius yang serius, bukan game yang mendukung. Mungkin begitu.

- Terima kasih banyak!

Dmitry : Terima kasih, Vitaly, untuk waktu dan waktunya untuk wawancara. Pembaca yang budiman, terima kasih banyak jika Anda tiba-tiba mencapai titik ini. Saya harap setidaknya beberapa pemikiran kami bawa Anda.

Dalam sebuah wawancara, Dmitry menyentuh werf. Sekarang ini adalah pisau Swiss universal yang menyelesaikan hampir semua tugas. Tapi itu tidak selalu terjadi. Di DevOpsConf di festival RIT ++ , Dmitry Stolyarov akan berbicara tentang alat ini secara detail. Laporan "werf adalah alat kami untuk CI / CD di Kubernetes" akan memiliki segalanya: masalah dan nuansa tersembunyi dari Kubernetes, solusi untuk kesulitan ini dan implementasi werf saat ini secara rinci. Bergabunglah pada 27 dan 28 Mei, kami akan membuat alat yang ideal.