Beklentisiyle Vitali Habarov röportaj yapıldı Dmitry Stolyarov (), teknik direktör ve Flant şirketinin kurucu ortağı. Vitaly, Dmitry'ye Flant'ın Kubernetes, ekosistem gelişimi ve destek hakkında ne yaptığını sordu. Kubernetes'e neden ihtiyaç duyulduğunu ve gerekli olup olmadığını tartıştık. Ayrıca mikro hizmetler, Amazon AWS, DevOps'a yönelik “Şanslı olacağım” yaklaşımı, Kubernetes'in geleceği, neden, ne zaman ve nasıl dünyayı ele geçireceği, DevOps'un beklentileri ve mühendislerin bu süreçte neye hazırlanmaları gerektiği hakkında da bilgiler basitleştirme ve sinir ağları ile parlak ve yakın bir gelecek.
DevOps hakkında Rusça bir podcast olan DevOps Deflop'ta podcast olarak dinleyin ve aşağıda metin versiyonu bulunmaktadır.
Burada ve aşağıda sorular soruyor Express42'den mühendis.
"Flant" hakkında
- Merhaba Dima. Sen teknik direktörsün""ve aynı zamanda kurucusu. Lütfen bize şirketin ne yaptığını ve içinde ne olduğunuzu söyleyin?
Dmitry: Dışarıdan bakıldığında biz Kubernetes'i herkes için kuran ve onunla bir şeyler yapan adamlarmışız gibi görünüyor. Ama bu doğru değil. Linux ile uğraşan bir şirket olarak yola çıktık ancak çok uzun bir süredir ana faaliyet alanımız üretim ve yüksek yüklü anahtar teslimi projelere hizmet vermek oldu. Genellikle tüm altyapıyı sıfırdan inşa ederiz ve uzun bir süre boyunca bunun sorumluluğunu üstleniriz. Bu nedenle “Flant”ın yaptığı ve karşılığında para aldığı asıl iş Sorumluluk almak ve anahtar teslimi üretim uygulamak.
Ben, teknik direktör ve şirketin kurucularından biri olarak, tüm günümü ve gecemi üretimin erişilebilirliğini nasıl artıracağımı, işleyişini nasıl basitleştireceğimi, yöneticilerin hayatını nasıl kolaylaştıracağımı ve geliştiricilerin hayatını nasıl daha keyifli hale getireceğimi bulmaya çalışarak geçiriyorum. .
Kubernetes hakkında
— Son zamanlarda Flant'tan çok sayıda rapor görüyorum ve Kubernetes hakkında. Bu noktaya nasıl geldiniz?
Dmitry: Bunu zaten defalarca anlattım ama tekrarlamaktan hiç çekinmiyorum. Sebep-sonuç arasında bir karışıklık olduğu için bu konuyu tekrarlamanın doğru olduğunu düşünüyorum.
Gerçekten bir araca ihtiyacımız vardı. Pek çok sorunla karşılaştık, mücadele ettik, çeşitli koltuk değnekleriyle bunların üstesinden geldik ve bir araca ihtiyaç duyduk. Birçok farklı seçeneği denedik, kendi bisikletlerimizi yaptık ve deneyim kazandık. Yavaş yavaş, Docker'ı neredeyse ortaya çıktığı anda - 2013 civarında - kullanmaya başladığımız noktaya geldik. Ortaya çıktığı sırada, konteynerler konusunda zaten çok fazla deneyimimiz vardı, Python'da kendi koltuk değneklerimizden bazıları olan “Docker”ın bir analogunu zaten yazmıştık. Docker'ın gelişiyle koltuk değneklerini bir kenara bırakıp güvenilir ve topluluk destekli bir çözüm kullanmak mümkün hale geldi.
Kubernetes'te de hikaye benzer. Hız kazanmaya başladığında - bizim için bu sürüm 1.2 - zaten hem Shell hem de Chef üzerinde bir takım desteklerimiz vardı ve bunları bir şekilde Docker ile düzenlemeye çalıştık. Rancher'a ve diğer çeşitli çözümlere ciddi bir şekilde bakıyorduk, ancak sonra her şeyin tam olarak bizim yapacağımız gibi veya hatta daha iyi bir şekilde uygulandığı Kubernetes ortaya çıktı. Şikayet edecek bir şey yok.
Evet, burada bir tür kusur var, burada bir tür kusur var - pek çok kusur var ve 1.2 genel olarak berbat, ama... Kubernetes inşaat halindeki bir bina gibidir - projeye bakarsınız ve anlarsınız harika olacak. Binanın artık bir temeli ve iki katı varsa, o zaman henüz taşınmamanın daha iyi olduğunu anlıyorsunuz, ancak yazılımda böyle bir sorun yok - onu zaten kullanabilirsiniz.
Kubernetes kullanıp kullanmamayı düşündüğümüz bir an bile olmadı. Ortaya çıkmadan çok önce onu bekliyorduk ve kendimiz analoglar yaratmaya çalıştık.
Kubernetes hakkında
— Kubernetes'in geliştirilmesinde doğrudan yer alıyor musunuz?
Dmitry: Vasat. Bunun yerine ekosistemin gelişimine katkıda bulunuyoruz. Belirli sayıda çekme isteği gönderiyoruz: Prometheus'a, çeşitli operatörlere, Helm'e - ekosisteme. Ne yazık ki yaptığımız her şeyi takip edemiyorum ve yanılıyor da olabilirim ama bizden çekirdeğe doğru tek bir havuz yok.
— Aynı zamanda araçlarınızın çoğunu Kubernetes etrafında mı geliştiriyorsunuz?
Dmitry: Strateji şu: gidip istekleri zaten var olan her şeye çekiyoruz. Çekme istekleri orada kabul edilmezse, bunları kendimiz çatallarız ve yapılarımızda kabul edilene kadar yaşarız. Daha sonra yukarı akışa ulaştığında, yukarı akış versiyonuna geri dönüyoruz.
Örneğin, montajımızın yukarı akışına muhtemelen 5 kez ileri geri geçiş yaptığımız bir Prometheus operatörümüz var. Bir tür özelliğe ihtiyacımız var, bir çekme isteği gönderdik, onu yarın kullanıma sunmamız gerekiyor, ancak bunun yukarı yönde yayınlanmasını beklemek istemiyoruz. Buna göre kendimiz için montaj yapıyoruz, bazı nedenlerden dolayı ihtiyaç duyduğumuz özelliğimizle montajımızı tüm kümelerimize yayıyoruz. Sonra örneğin, "Arkadaşlar, hadi daha genel bir durum için yapalım" sözleriyle bunu bize teslim ediyorlar, biz veya bir başkası bitiriyoruz ve zamanla tekrar eski haline dönüyor.
Var olan her şeyi geliştirmeye çalışıyoruz. Henüz var olmayan, henüz icat edilmemiş veya icat edilmiş, ancak uygulamaya vakti olmayan birçok unsur - biz yapıyoruz. Ve endüstri olarak süreci veya bisiklet yapımını sevdiğimiz için değil, sadece bu araca ihtiyacımız olduğu için. Şu soru sıklıkla soruluyor: Bunu veya bunu neden yaptık? Cevap basit - evet, çünkü daha ileri gitmemiz, bazı pratik sorunları çözmemiz gerekiyordu ve bunu bu tula ile çözdük.
Yol hep böyle: Çok dikkatli araştırıyoruz ve bir somun ekmekten troleybüs nasıl yapılır diye bir çözüm bulamazsak o zaman kendi ekmeğimizi, kendi troleybüsümüzü yaparız.
Flanta araçları
— Flant'ın artık eklenti operatörleri, kabuk operatörleri ve dapp/werf araçlarına sahip olduğunu biliyorum. Anladığım kadarıyla bu, farklı enkarnasyonlardaki aynı enstrümandır. Ayrıca Flaunt'ta çok daha farklı araçların bulunduğunu da anlıyorum. Bu doğru?
Dmitry: GitHub'da çok daha fazlası var. Şimdi hatırladığım kadarıyla Grafana için herkesin karşılaştığı bir durum haritamız var. Medium'da Kubernetes izlemeyle ilgili neredeyse her ikinci makalede bundan bahsediliyor. Durum haritasının ne olduğunu kısaca açıklamak imkansızdır; ayrı bir makaleye ihtiyaç duyar, ancak zaman içindeki durumu izlemek için çok yararlı bir şeydir, çünkü Kubernetes'te genellikle zaman içindeki durumu göstermemiz gerekir. Ayrıca LogHouse'umuz da var - bu, Kubernetes'te günlük toplamak için ClickHouse ve kara büyüye dayanan bir şey.
Çok sayıda yardımcı program! Ve daha da fazlası olacak çünkü bu yıl bir takım dahili çözümler piyasaya sürülecek. Eklenti operatörüne dayalı çok büyük olanlardan Kubernetes için bir sürü eklenti var, ala sert yöneticisinin nasıl düzgün şekilde kurulacağı - sertifikaları yönetmek için bir araç, Prometheus'un bir grup aksesuarla doğru şekilde nasıl kurulacağı - bunlar yaklaşık yirmi farklı Verileri dışa aktaran ve bir şeyler toplayan ikili dosyalar, bu Prometheus'ta en muhteşem grafiklere ve uyarılara sahiptir. Bütün bunlar, bir kümeye yüklenen Kubernetes'e yapılan bir dizi eklentiden ibarettir ve basitten havalı, karmaşık, otomatik hale gelir ve birçok sorun zaten çözülmüştür. Evet, çok şey yapıyoruz.
Ekosistem gelişimi
"Bana öyle geliyor ki bu, bu enstrümanın ve kullanım yöntemlerinin geliştirilmesine çok büyük bir katkı." Ekosistemin gelişimine aynı katkıyı başka kimlerin yapabileceğini kabaca tahmin edebilir misiniz?
Dmitry: Rusya'da pazarımızda faaliyet gösteren şirketlerin hiçbiri yakın bile değil. Elbette bu yüksek sesli bir açıklama, çünkü Mail ve Yandex gibi büyük oyuncular da var; onlar da Kubernetes ile bir şeyler yapıyorlar ama onlar bile dünya çapında bizden çok daha fazlasını yapan şirketlerin katkısının yanına yaklaşamıyorlar. 80 kişilik bir kadroya sahip olan Flant ile yalnızca Kubernetes başına 300 mühendise sahip olan Red Hat'i yanılmıyorsam karşılaştırmak zor. Karşılaştırmak zor. Ar-Ge departmanımızda ben de dahil olmak üzere tüm takımlarımızı kesen 6 kişimiz var. 6 kişiye karşı 300 Red Hat mühendisi; bunu karşılaştırmak bir şekilde zor.
- Ancak bu 6 kişi bile gerçekten yararlı ve yabancılaştırıcı bir şey yapabildiğinde, pratik bir sorunla karşı karşıya kaldıklarında ve topluluğa çözüm sunduklarında, ilginç bir durum. Kendi Kubernetes geliştirme ve destek ekibine sahip olan büyük teknoloji şirketlerinin prensipte aynı araçların geliştirilebileceğini anlıyorum. Bu onlar için nelerin geliştirilip topluluğa verilebileceğine dair bir örnek olup Kubernetes kullanan tüm topluluğa ivme kazandırıyor.
Dmitry: Bu muhtemelen entegratörün bir özelliği, tuhaflığıdır. Pek çok projemiz var ve pek çok farklı durum görüyoruz. Bizim için katma değer yaratmanın temel yolu bu durumları analiz edip ortak noktalar bulmak ve bunları bizim için mümkün olduğunca ucuz hale getirmektir. Bu konuda aktif olarak çalışıyoruz. Rusya ve dünya hakkında konuşmak benim için zor ama şirkette Kubernetes üzerinde çalışan 40'a yakın DevOps mühendisimiz var. Rusya'da Kubernetes'i anlayan benzer sayıda uzmana sahip çok fazla şirket olduğunu sanmıyorum.
DevOps mühendisi iş unvanıyla ilgili her şeyi anlıyorum, herkes her şeyi anlıyor ve DevOps mühendislerine DevOps mühendisleri demeye alışkın, bunu tartışmayacağız. Bu 40 harika DevOps mühendisinin tümü her gün sorunlarla karşılaşıyor ve çözüyor; biz sadece bu deneyimi analiz edip genelleştirmeye çalışıyoruz. İçimizde kalırsa, bir veya iki yıl içinde aracın işe yaramaz hale geleceğini anlıyoruz, çünkü topluluğun bir yerinde hazır bir Tula ortaya çıkacak. Bu deneyimi dahili olarak biriktirmenin bir anlamı yok; bu sadece enerjiyi ve zamanı dev/null'a tüketmektir. Ve bundan hiç de üzgün değiliz. Her şeyi büyük bir zevkle yayınlıyoruz ve insanların bunu kullanması ve deneyimlerini katması için yayınlanması, geliştirilmesi, tanıtılması, tanıtılması gerektiğini anlıyoruz - sonra her şey büyür ve yaşar. Daha sonra iki yıl sonra enstrüman çöpe gitmez. Güç kazanmaya devam etmek üzücü değil çünkü birisinin aletinizi kullandığı açık ve iki yıl sonra herkes onu kullanıyor.
Bu dapp/werf ile olan büyük stratejimizin bir parçası. Ne zaman yapmaya başladığımızı hatırlamıyorum, sanki 3 yıl olmuş gibi geliyor. Başlangıçta genellikle kabuğun üzerindeydi. Bu, konseptin süper bir kanıtıydı; bazı özel sorunlarımızı çözdük; işe yaradı! Ancak kabukta sorunlar var, onu daha da genişletmek imkansız, kabuk üzerinde programlama yapmak başka bir iş. Ruby'de yazma alışkanlığımız vardı, buna göre Ruby'de bir şeyleri yeniden yaptık, geliştirdik, geliştirdik, geliştirdik ve şununla karşılaştık ki “istiyoruz, istemiyoruz” diyen topluluk, kalabalık, Ruby'ye burnunu kaldırıyor, bu ne kadar komik? Kontrol listesindeki ilk noktayı karşılamak için tüm bunları Go'da yazmamız gerektiğini fark ettik: DevOps aracı statik bir ikili dosya olmalıdır. Go olmak ya da olmamak o kadar önemli değil, ancak Go'da yazılmış statik bir ikili dosya daha iyidir.
Enerjimizi harcadık, dapp'i Go'da yeniden yazdık ve werf adını verdik. Dapp artık desteklenmiyor, geliştirilmiyor ve en son sürümlerde çalışıyor ancak en üst seviyeye giden mutlak bir yükseltme yolu var ve onu takip edebilirsiniz.
Dapp neden oluşturuldu?
— Dapp'in neden yaratıldığını, hangi sorunları çözdüğünü bize kısaca anlatabilir misiniz?
Dmitry: Birinci sebep meclistedir. Başlangıçta Docker'ın çok aşamalı yetenekleri olmadığı için build konusunda ciddi sorunlar yaşadık, bu yüzden çok aşamalı çalışmayı kendi başımıza yaptık. Daha sonra görüntüyü temizlemeyle ilgili bir sürü sorun daha yaşadık. CI/CD yapan herkes, eninde sonunda, bir sürü toplanan görüntünün olması sorunuyla karşı karşıya kalır; bir şekilde ihtiyaç duyulmayanları temizlemeniz ve ihtiyaç duyulanları bırakmanız gerekir.
İkinci neden ise dağıtımdır. Evet Helm var ama sorunların yalnızca bir kısmını çözüyor. Yeterince komiktir ki, "Helm, Kubernetes'in Paket Yöneticisidir" diye yazılmıştır. Tam olarak ne "o". Bir de “Paket Yöneticisi” ifadesi var; bir Paket Yöneticisinden genel beklenti nedir? Biz diyoruz ki: “Paket Yöneticisi – paketi kurun!” ve bize şunu söylemesini bekliyoruz: “Paket teslim edildi.”
"Dümen, paketi kur" dememiz ilginç ve kurduğunu söylediğinde, kurulumu yeni başlattığı ortaya çıktı - Kubernetes'i belirtti: "Bu şeyi başlat!" ve başlayıp başlamadığını. Çalışsa da çalışmasa da Helm bu sorunu hiç çözmüyor.
Helm'in yalnızca verileri Kubernetes'e yükleyen bir metin ön işlemcisi olduğu ortaya çıktı.
Ancak herhangi bir dağıtımın parçası olarak uygulamanın üretim için yayınlanıp yayınlanmadığını bilmek istiyoruz. Prod'a dağıtılmak, uygulamanın oraya taşındığı, yeni sürümün dağıtıldığı ve en azından orada kilitlenmediği ve doğru yanıt verdiği anlamına gelir. Helm bu sorunu hiçbir şekilde çözmüyor. Bunu çözmek için çok fazla çaba harcamanız gerekiyor, çünkü Kubernetes'e dağıtılması ve orada olup bitenleri izlemesi için komut vermeniz gerekir - ister dağıtılmış ister dağıtılmış olsun. Ayrıca dağıtım, temizleme ve montajla ilgili birçok görev de vardır.
Planlar
Bu yıl yerel kalkınmaya başlayacağız. Daha önce Vagrant'ta olanı elde etmek istiyoruz; "vagrant up" yazdık ve sanal makineleri konuşlandırdık. Git'te bir projenin olduğu noktaya ulaşmak istiyoruz, oraya "werf up" yazıyoruz ve bu, bu projenin yerel bir mini-Kub'da konuşlandırılan ve geliştirmeye uygun tüm dizinlerin birbirine bağlı olduğu yerel bir kopyasını getiriyor. . Geliştirme diline bağlı olarak bu farklı şekilde yapılır, ancak yine de yerel geliştirmenin monte edilmiş dosyalar altında rahatlıkla gerçekleştirilebilmesi için.
Bizim için bir sonraki adım geliştiricilere kolaylık sağlamak için yatırım yapın. Bir projeyi tek bir araçla hızlı bir şekilde yerel olarak dağıtmak için, onu geliştirin, Git'e aktarın; işlem hatlarına bağlı olarak aşamaya veya testlere de sunulacak ve ardından üretime geçmek için aynı aracı kullanacaktır. Yerel ortamdan satışa kadar altyapının bu birliği, bütünleşmesi, tekrarlanabilirliği bizim için çok önemli bir nokta. Ancak bu henüz Werf'te değil; biz sadece bunu yapmayı planlıyoruz.
Ancak dapp/werf'e giden yol her zaman başlangıçta Kubernetes ile aynıydı. Sorunlarla karşılaştık, bunları geçici çözümlerle çözdük - kabukta, herhangi bir konuda kendimiz için bazı çözümler bulduk. Daha sonra bu geçici çözümleri bir şekilde düzeltmeye, genelleştirmeye ve bu durumda ikili dosyalar halinde birleştirmeye çalıştılar ki bunu basitçe paylaşıyoruz.
Bütün bu hikayeye benzetmelerle bakmanın başka bir yolu daha var.
Kubernetes, motorlu bir araba çerçevesidir. Kapı yok, cam yok, radyo yok, Noel ağacı yok; hiçbir şey yok. Sadece şasi ve motor. Ve Helm var - bu direksiyon simidi. Harika - bir direksiyon simidi var, ancak aynı zamanda bir direksiyon pimine, direksiyon kremayerine, vites kutusuna ve tekerleklere de ihtiyacınız var ve onlarsız yapamazsınız.
Werf durumunda bu, Kubernetes'in başka bir bileşenidir. Ancak şimdi werf'in alfa versiyonunda, örneğin Helm werf'in içinde derleniyor çünkü bunu kendimiz yapmaktan yorulduk. Bunu yapmanın pek çok nedeni var, size neden dümenin tamamını yeke ile birlikte werf içinde derlediğimizi detaylı olarak anlatacağım. .
Artık werf daha entegre bir bileşendir. Bitmiş bir direksiyon simidi, bir direksiyon pimi alıyoruz - arabalarda pek iyi değilim, ancak bu zaten oldukça geniş bir sorun yelpazesini çözen büyük bir blok. Kataloğu kendimiz incelememize, bir parçayı diğerine seçmemize, bunları nasıl bir araya getireceğimizi düşünmemize gerek yok. Aynı anda çok sayıda sorunu çözen hazır bir birleştirme elde ediyoruz. Ancak içinde aynı açık kaynak bileşenlerden oluşturulmuştur, montaj için hala Docker'ı, bazı işlevler için Helm'i kullanır ve başka birçok kütüphane vardır. Bu, harika CI/CD'yi kutudan hızlı ve rahat bir şekilde çıkarmak için entegre bir araçtır.
Kubernetes'in bakımı zor mu?
— Kubernetes'i kullanmaya başladığınız deneyimden bahsediyorsunuz, bu sizin için bir çerçeve, bir motor ve üzerine birçok farklı şey asabilirsiniz: gövde, direksiyon simidi, vidalı pedallar, koltuklar. Şu soru ortaya çıkıyor: Kubernetes desteği sizin için ne kadar zor? Çok fazla deneyiminiz var; diğer her şeyden ayrı olarak Kubernetes'i desteklemek için ne kadar zaman ve kaynak harcıyorsunuz?
Dmitry: Bu çok zor bir soru ve cevaplamak için desteğin ne olduğunu ve Kubernetes'ten ne istediğimizi anlamamız gerekiyor. Belki açığa vurabilirsin?
— Bildiğim ve gördüğüm kadarıyla artık birçok ekip Kubernetes'i denemek istiyor. Herkes ona koşuyor, dizlerinin üstüne koyuyor. İnsanların bu sistemin karmaşıklığını her zaman anlayamadıklarını hissediyorum.
Dmitry: O gibi.
— Kubernetes'i sıfırdan alıp üretime hazır hale getirmek ne kadar zor?
Dmitry: Sizce kalp nakli ne kadar zor? Bunun uzlaşmacı bir soru olduğunu anlıyorum. Neşter kullanmak ve hata yapmamak o kadar da zor değil. Size nerede keseceğinizi ve nerede dikeceğinizi söylerlerse, prosedürün kendisi karmaşık değildir. Her seferinde her şeyin yoluna gireceğini garanti etmek zordur.
Kubernetes'i kurmak ve çalıştırmaya başlamak çok kolay: piliç! — yüklü, birçok kurulum yöntemi var. Peki sorunlar ortaya çıktığında ne olur?
Her zaman sorular ortaya çıkar - henüz neyi hesaba katmadık? Henüz ne yapmadık? Hangi Linux çekirdeği parametreleri yanlış belirtildi? Tanrım, onlardan bahsetmiş miydik? Hangi Kubernetes bileşenlerini teslim ettik, hangilerini teslim etmedik? Binlerce soru ortaya çıkıyor ve bunları cevaplamak için bu sektörde 15-20 yıl harcamanız gerekiyor.
Bu konuyla ilgili "Kubernetes'in bakımı zor mu?" sorununun anlamını ortaya çıkarabilecek güncel bir örneğim var. Bir süre önce Cilium'u Kubernetes'te bir ağ olarak uygulamaya çalışıp çalışmamamız gerektiğini ciddi olarak düşündük.
Cilium'un ne olduğunu açıklayayım. Kubernetes'in ağ alt sisteminin birçok farklı uygulaması vardır ve bunlardan biri çok harikadır: Cilium. Anlamı nedir? Çekirdekte, bir süre önce çekirdek için, bir şekilde ağ alt sistemini ve diğer çeşitli alt sistemleri istila eden ve çekirdekteki büyük parçaları atlamanıza izin veren kancalar yazmak mümkün hale geldi.
Linux çekirdeği tarihsel olarak bir ip yönlendirmesine, bir aşırı filtreye, köprülere ve 15, 20, 30 yıllık birçok farklı eski bileşene sahiptir. Genel olarak çalışıyorlar, her şey harika, ama şimdi konteynerleri yığdılar ve üst üste 15 tuğladan oluşan bir kuleye benziyor ve tek ayak üzerinde duruyorsunuz - tuhaf bir duygu. Bu sistem tarihsel olarak vücuttaki apandis gibi birçok nüansla gelişmiştir. Örneğin bazı durumlarda performans sorunları yaşanabilir.
Harika bir BPF ve çekirdek için kanca yazma yeteneği var - adamlar çekirdek için kendi kancalarını yazdılar. Paket Linux çekirdeğine gelir, onu doğrudan girişte çıkarırlar, köprüler olmadan, TCP olmadan, IP yığını olmadan olması gerektiği gibi kendileri işlerler - kısacası, Linux çekirdeğinde yazılan her şeyi atlayarak ve sonra tükürürler. konteynere boşaltın.
Ne oldu? Çok harika performans, harika özellikler - tek kelimeyle harika! Ancak buna bakıyoruz ve her makinede Kubernetes API'sine bağlanan ve bu API'den aldığı verilere dayanarak C kodu üreten ve bu kancaların çalışması için çekirdeğe yüklediği ikili dosyaları derleyen bir program olduğunu görüyoruz. çekirdek alanında.
Bir şeyler ters giderse ne olur? Biz bilmiyoruz. Bunu anlamak için tüm bu kodu okumanız, tüm mantığı anlamanız gerekir ve bunun ne kadar zor olduğu şaşırtıcıdır. Ama öte yandan köprüler, ağ filtreleri, ip yönlendirmeleri var; bunların kaynak kodlarını okumadım ve şirketimizde çalışan 40 mühendisin de okuması mümkün değil. Belki sadece birkaçı bazı kısımları anlıyor.
Peki fark nedir? Görünüşe göre ip yönlendirmesi, Linux çekirdeği ve yeni bir araç var - ne fark eder, birini veya diğerini anlamıyoruz. Ama yeni bir şey kullanmaktan korkuyoruz - neden? Çünkü araç 30 yaşındaysa, 30 yılda tüm hatalar bulunur, tüm hatalar giderilir ve her şeyi bilmenize gerek kalmaz - bir kara kutu gibi çalışır ve her zaman çalışır. Hangi teşhis tornavidasının hangi yere yapıştırılacağını, hangi tcpdump'un hangi anda çalıştırılacağını herkes bilir. Herkes tanılama yardımcı programlarını iyi biliyor ve bu bileşen kümesinin Linux çekirdeğinde nasıl çalıştığını anlıyor - nasıl çalıştığını değil, nasıl kullanılacağını.
Ve müthiş havalı Cilium 30 yaşında değil, henüz yaşlanmadı. Kubernetes'te de aynı sorun var, kopyalama. Cilium'un mükemmel bir şekilde kurulduğunu, Kubernetes'in mükemmel bir şekilde kurulduğunu, ancak üretimde bir şeyler ters gittiğinde, kritik bir durumda neyin yanlış gittiğini hızlı bir şekilde anlayabiliyor musunuz?
Kubernetes'in bakımını yapmak zor mu dediğimizde - hayır, çok kolay ve evet inanılmaz derecede zor. Kubernetes tek başına harika çalışıyor ancak milyarlarca nüansa sahip.
“Şanslı olacağım” yaklaşımı hakkında
— Bu nüansların ortaya çıkmasının neredeyse garanti olduğu şirketler var mı? Diyelim ki Yandex aniden tüm hizmetleri Kubernetes'e aktardı, orada çok büyük bir yük olacak.
Dmitry: Hayır, bu yük hakkında değil, en basit şeyler hakkında bir konuşma. Mesela Kubernetes’imiz var, uygulamayı oraya konuşlandırdık. Çalıştığını nereden biliyorsun? Uygulamanın çökmediğini anlamak için hazır bir araç yoktur. Uyarı gönderen hazır bir sistem yoktur; bu uyarıları ve her takvimi yapılandırmanız gerekir. Ve Kubernetes'i güncelliyoruz.
Ubuntu'm 16.04'tür. Bunun eski bir sürüm olduğunu söyleyebilirsiniz ancak LTS olduğu için hala üzerinde çalışıyoruz. Systemd var, bunun nüansı C gruplarını temizlememesidir. Kubernetes pod'ları başlatır, C grupları oluşturur, ardından pod'ları siler ve bir şekilde ortaya çıktı ki - ayrıntıları hatırlamıyorum, kusura bakmayın - systemd dilimleri kalıyor. Bu, zamanla herhangi bir arabanın güçlü bir şekilde yavaşlamaya başlamasına yol açar. Bu, aşırı yük ile ilgili bir soru bile değil. Kalıcı podlar başlatılırsa örneğin sürekli pod üreten bir Cron Job varsa Ubuntu 16.04 yüklü makine bir hafta sonra yavaşlamaya başlayacaktır. Bir grup C grubunun oluşturulmuş olması nedeniyle sürekli olarak yüksek bir yük ortalaması olacaktır. Bu, Ubuntu 16 ve Kubernetes'i basitçe yükleyen herkesin karşılaşacağı sorundur.
Diyelim ki bir şekilde systemd'yi veya başka bir şeyi güncelliyor, ancak 4.16'ya kadar Linux çekirdeğinde bu daha da komik - C gruplarını sildiğinizde çekirdeğe sızıyorlar ve aslında silinmiyorlar. Dolayısıyla bu makinede bir ay çalıştıktan sonra ocakların hafıza istatistiklerine bakmak imkansız hale gelecektir. Bir dosyayı çıkarıyoruz, programda yuvarlıyoruz ve bir dosya 15 saniye boyunca yuvarlanıyor, çünkü çekirdeğin kendi içinde silinmiş gibi görünen bir milyon C grubunu sayması çok uzun zaman alıyor, ancak hayır - sızdırıyorlar .
Burada ve orada hala pek çok küçük şey var. Bu, dev şirketlerin bazen çok ağır yükler altında karşılaşabileceği bir sorun değil - hayır, gündelik bir mesele. İnsanlar aylarca bu şekilde yaşayabilirler - Kubernetes'i kurdular, uygulamayı dağıttılar - işe yarıyor gibi görünüyor. Birçok insan için bu normaldir. Bu uygulamanın herhangi bir nedenle çökeceğini bile bilmeyecekler, uyarı almayacaklar ama bu onlar için norm. Daha önce sanal makinelerde izleme olmadan yaşıyorduk, şimdi yine izleme olmadan Kubernetes'e geçtik - fark nedir?
Sorun şu ki, buz üzerinde yürüdüğümüzde önceden ölçmediğimiz sürece kalınlığını asla bilemeyiz. Birçok insan yürür ve endişelenmez çünkü daha önce de yürümüşlerdir.
Benim bakış açıma göre, herhangi bir sistemi çalıştırmanın nüansı ve karmaşıklığı, buzun kalınlığının sorunlarımızı çözmeye tam olarak yeterli olmasını sağlamaktır. Bahsettiğimiz şey bu.
Bana öyle geliyor ki BT'de çok fazla "Şanslı olacağım" yaklaşımı var. Pek çok kişi, şanslarının yaver gideceğini umarak yazılım yükler ve yazılım kitaplıklarını kullanır. Genel olarak birçok insan şanslıdır. Muhtemelen bu yüzden işe yarıyor.
— Kötümser değerlendirmeme göre şu şekilde görünüyor: Riskler yüksek olduğunda ve uygulamanın çalışması gerektiğinde, o zaman Flaunt'tan, belki de Red Hat'ten desteğe ihtiyaç duyulur veya özel olarak Kubernetes'e adanmış, hazır olan kendi dahili ekibinize ihtiyacınız vardır. onu çıkarmak için.
Dmitry: Objektif olarak bu böyledir. Küçük bir ekip için Kubernetes hikayesine kendi başınıza girmek bir dizi risk içerir.
Konteynerlere ihtiyacımız var mı?
— Kubernetes'in Rusya'da ne kadar yaygın olduğunu bize anlatabilir misiniz?
Dmitry: Bu verilere sahip değilim ve başka kimsenin de bu verilere sahip olduğundan emin değilim. “Kubernetes, Kubernetes” diyoruz ama bu konuya başka bir açıdan bakmanın yolu daha var. Ayrıca konteynerlerin ne kadar yaygın olduğunu bilmiyorum ama internetteki raporlardan konteynerlerin %70'inin Kubernetes tarafından yönetildiğine dair bir rakam biliyorum. Dünya çapında oldukça geniş bir örneklem için güvenilir bir kaynaktı.
Sonra başka bir soru: konteynerlere ihtiyacımız var mı? Benim kişisel görüşüm ve Flant şirketinin genel tutumu Kubernetes'in fiili bir standart olduğu yönünde.
Kubernetes'ten başka hiçbir şey olmayacak.
Bu, altyapı yönetimi alanında oyunun kurallarını tamamen değiştirecek bir gelişmedir. Sadece mutlak - işte bu kadar, artık Ansible, Chef, sanal makineler, Terraform yok. Eski kolektif çiftlik yöntemlerinden bahsetmiyorum. Kubernetes mutlak bir değiştiricidirve artık sadece bu şekilde olacak.
Bazılarının bunu fark etmesinin birkaç yıl, bazılarının ise birkaç on yıl alacağı açıktır. Kubernetes'ten ve bu yeni görünümden başka bir şey olmayacağına hiç şüphem yok: artık işletim sistemine zarar vermiyoruz, ancak kullanıyoruz kod olarak altyapı, yalnızca kodla değil, bildirimsel olarak tanımlanmış bir altyapı olan yml ile. Bu hep böyle olacakmış gibi bir his var içimde.
— Yani henüz Kubernetes'e geçmemiş şirketler mutlaka ona geçecek veya unutulmaya devam edecek. Seni doğru anladım mı?
Dmitry: Bu da tamamen doğru değil. Örneğin bir DNS sunucusu çalıştırma görevimiz varsa o zaman FreeBSD 4.10 üzerinde çalıştırılabilir ve 20 yıl boyunca kusursuz şekilde çalışabilir. Sadece çalış ve bu kadar. Belki 20 yıl sonra bir şeyin bir kez güncellenmesi gerekecek. Piyasaya sürdüğümüz formattaki yazılımlardan bahsediyorsak ve aslında uzun yıllar hiçbir güncelleme yapmadan, değişiklik yapmadan çalışıyorsa o zaman elbette Kubernetes olmayacaktır. Orada ona ihtiyaç yok.
CI/CD ile ilgili her şey - Sürekli Teslimatın gerekli olduğu, sürümleri güncellemeniz, etkin değişiklikler yapmanız gereken ve hata toleransı oluşturmanız gereken her yerde - yalnızca Kubernetes.
Mikro hizmetler hakkında
- Burada hafif bir uyumsuzluk var. Kubernetes ile çalışmak için harici veya dahili desteğe ihtiyacınız var - bu ilk nokta. İkincisi, geliştirmeye yeni başladığımızda, küçük bir girişimiz, henüz hiçbir şeyimiz yok, genel olarak Kubernetes veya mikro hizmet mimarisi için geliştirme karmaşık olabilir ve her zaman ekonomik olarak haklı olmayabilir. Fikrinizle ilgileniyorum - yeni başlayanların Kubernetes için hemen sıfırdan yazmaya başlaması mı gerekiyor, yoksa yine de bir monolit yazıp sonra yalnızca Kubernetes'e gelebilirler mi?
Dmitry: Güzel soru. Mikro hizmetler hakkında konuşacağım Çoğu zaman mikroskopla çivi çakmaya çalışan insanlarla karşılaştım. Yaklaşımın kendisi doğru; biz kendi iç yazılımımızı bu şekilde tasarlıyoruz. Ancak bunu yaptığınızda ne yaptığınızı açıkça anlamanız gerekir. Mikro hizmetler hakkında en nefret ettiğim kelime "mikro"dur. Tarihsel olarak bu kelimenin kökeni buradan çıkmıştır ve bazı nedenlerden dolayı insanlar mikronun mikrometre gibi çok küçük, bir milimetreden daha küçük olduğunu düşünürler. Bu yanlış.
Örneğin, 300 kişi tarafından yazılan bir monolit var ve geliştirmeye katılan herkes orada sorunlar olduğunu anlıyor ve mikro parçalara bölünmesi gerektiğini anlıyor - her biri 10 kişi tarafından yazılan yaklaşık 30 parça. minimum versiyonda. Bu önemli, gerekli ve güzel. Ama bize bir startup geldiğinde, 3 çok havalı ve yetenekli adam dizlerinin üstüne 60 mikro hizmet yazmış, Corvalol'u her aradığımda.
Bana öyle geliyor ki bu zaten binlerce kez konuşuldu - şu ya da bu şekilde dağıtılmış bir monolitimiz var. Bu ekonomik olarak haklı değil, genel olarak her şeyde çok zor. Bunu o kadar çok gördüm ki gerçekten canımı acıtıyor, bu yüzden bunun hakkında konuşmaya devam ediyorum.
İlk soruya göre, bir yandan Kubernetes'in kullanımının korkutucu olması, çünkü orada neyin kırılıp çalışamayacağı belli olmaması, diğer yandan her şeyin oraya gideceğinin açık olması arasında bir çelişki var. ve Kubernetes'ten başka hiçbir şey var olmayacak. Cevap - elde edeceğiniz fayda miktarını, çözebileceğiniz görev miktarını tartın. Bu terazinin bir tarafındadır. Öte yandan, performans göstergelerinin azalmasıyla birlikte kesinti süresi veya yanıt süresindeki azalma, kullanılabilirlik düzeyi ile ilgili riskler de vardır.
İşte burada; ya hızlı hareket ederiz ve Kubernetes birçok şeyi çok daha hızlı ve daha iyi yapmamıza olanak tanır ya da güvenilir, zaman içinde test edilmiş çözümler kullanırız ancak çok daha yavaş hareket ederiz. Bu her şirketin yapması gereken bir seçimdir. Bunu ormandaki bir patika gibi düşünebilirsiniz; ilk kez yürüdüğünüzde bir yılanla, bir kaplanla ya da deli bir porsukla karşılaşırsınız ve 10 kez yürüdüğünüzde o yolu yürümüş, ortadan kaldırılmış olursunuz. dallar ve daha kolay yürüyün. Her seferinde yol daha da genişliyor. Önce asfalt yol, sonra güzel bir bulvar.
Kubernetes yerinde durmuyor. Tekrar soru: Kubernetes bir yandan 4-5 ikili, diğer yandan ekosistemin tamamıdır. Bu, makinelerimizde bulunan işletim sistemidir. Bu nedir? Ubuntu mu yoksa Curios mu? Bu, bir dizi ek bileşenden oluşan Linux çekirdeğidir. Bütün bunlar burada, zehirli bir yılan yoldan atıldı, oraya çit çekildi. Kubernetes çok hızlı ve dinamik bir şekilde gelişiyor ve risklerin hacmi, bilinmeyenlerin hacmi her geçen ay azalıyor ve buna bağlı olarak bu ölçekler yeniden dengeleniyor.
Bir startup'ın ne yapması gerektiği sorusuna yanıt olarak şunu söyleyebilirim: Flaunt'a gelin, 150 bin ruble ödeyin ve anahtar teslimi kolay DevOps hizmeti alın. Birkaç geliştiriciye sahip küçük bir girişimseniz, bu işe yarar. Sorunlarınızı nasıl çözeceğinizi öğrenmesi ve bu sırada maaş ödemesi gereken kendi DevOps'unuzu işe almak yerine, tüm sorunlara anahtar teslim bir çözüm elde edeceksiniz. Evet bazı dezavantajları var. Biz bir dış kaynak şirketi olarak bu kadar müdahil olamayız ve değişikliklere hızlı bir şekilde yanıt veremeyiz. Ama bizim çok fazla uzmanlığımız ve hazır uygulamamız var. Her durumda, sorunu kesinlikle hızlı bir şekilde çözeceğimizi ve herhangi bir Kubernet'i ölümden dirilteceğimizi garanti ediyoruz.
Operasyonlara 10 kişilik bir ekip ayırabilecek büyüklükteki start-up'lara ve kurulu işletmelere dış kaynak kullanmanızı şiddetle tavsiye ediyorum, çünkü aksi takdirde hiçbir anlamı yok. Bunu dışarıdan temin etmek kesinlikle mantıklıdır.
Amazon ve Google hakkında
— Amazon veya Google'ın sunduğu bir çözümdeki ana bilgisayar, dış kaynak olarak değerlendirilebilir mi?
Dmitry: Evet, elbette bu birçok sorunu çözüyor. Ama yine nüanslar var. Hala onu nasıl kullanacağınızı anlamanız gerekiyor. Örneğin, Amazon AWS'nin çalışmasında binlerce küçük şey var: Load Balancer'ın ısıtılması gerekiyor veya önceden "arkadaşlar, trafik alacağız, Load Balancer'ı bizim için ısıtın!" şeklinde bir istek yazılmalıdır. Bu nüansları bilmeniz gerekiyor.
Bu konuda uzmanlaşmış insanlara başvurduğunuzda neredeyse tüm tipik şeylerin kapandığını görürsünüz. Şu anda 40 mühendisimiz var, yıl sonuna kadar muhtemelen 60 olacak, bütün bunlarla mutlaka karşılaştık. Bir projede bu sorunla tekrar karşılaşsak bile hemen birbirimize soruyoruz ve nasıl çözeceğimizi biliyoruz.
Muhtemelen cevap şudur: Elbette, barındırılan bir hikaye bazı kısımları kolaylaştırır. Soru, bu barındırıcılara güvenmeye hazır olup olmadığınız ve sorunlarınızı çözüp çözmeyecekleridir. Amazon ve Google iyi iş çıkardı. Tüm durumlarımız için - tam olarak. Artık olumlu deneyimlerimiz yok. Üzerinde çalışmaya çalıştığımız tüm diğer bulutlar pek çok sorun yaratıyor - Ager ve Rusya'daki her şey ve farklı uygulamalardaki her türlü OpenStack: Headster, Overage - ne istersen. Hepsi çözmek istemediğiniz sorunlar yaratır.
Bu nedenle cevap evet, ancak aslında çok fazla olgun barındırılan çözüm yok.
Kubernetes'e kimin ihtiyacı var?
— Peki Kubernetes'e kimin ihtiyacı var? Kubernetes için özel olarak gelen tipik Flaunt istemcisi olan Kubernetes'e kim geçiş yapmalı?
Dmitry: Bu ilginç bir soru çünkü şu anda Kubernetes'in ardından birçok kişi bize geliyor: "Arkadaşlar, Kubernetes yaptığınızı biliyoruz, bunu bizim için yapın!" Onlara cevap veriyoruz: "Beyler, biz Kubernetes yapmıyoruz, prod ve onunla bağlantılı her şeyi yapıyoruz." Çünkü şu anda tüm CI/CD'yi ve tüm bu hikayeyi yapmadan bir ürün yapmak kesinlikle imkansız. Herkes kalkınarak kalkınma, sonra sömürüyle sömürüye sahip olduğumuz bölünmeden uzaklaştı.
Müşterilerimiz farklı şeyler bekliyor, ancak herkes belirli sorunları olduğuna dair iyi bir mucize bekliyor ve şimdi - hop! — Kubernetes bunları çözecek. İnsanlar mucizelere inanır. Zihinlerinde bir mucize olmayacağını anlıyorlar ama ruhlarında umuyorlar - ya bu Kubernetes artık bizim için her şeyi çözerse, bunun hakkında o kadar çok konuşuyorlar ki! Aniden şimdi - hapşır! - ve sihirli bir değnek, hapşır! — ve %100 çalışma süremiz var, tüm geliştiriciler üretime giren her şeyi 50 kez yayınlayabilir ve çökmez. Genel olarak bir mucize!
Böyle insanlar bize geldiğinde “Kusura bakmayın ama mucize diye bir şey yoktur” deriz. Sağlıklı olmak için iyi beslenmeli ve egzersiz yapmalısınız. Güvenilir bir ürüne sahip olmak için güvenilir bir şekilde yapılması gerekir. Kullanışlı bir CI/CD'ye sahip olmak için bunu bu şekilde yapmanız gerekir. Bu yapılması gereken çok fazla iş var.
Kimin Kubernetes'e ihtiyacı olduğu sorusunu yanıtlamak - kimsenin Kubernetes'e ihtiyacı yok.
Bazı insanlar Kubernetes'e ihtiyaç duydukları konusunda yanılgıya sahipler. İnsanların, altyapının tüm sorunları ve uygulamalarını çalıştırma sorunlarıyla düşünmeyi, çalışmayı ve ilgilenmeyi bırakmaya derin bir ihtiyaçları var. Uygulamaların yalnızca çalışmasını ve dağıtılmasını istiyorlar. Onlar için Kubernetes, "orada yatıyorduk" veya "dışarı çıkamıyoruz" veya başka bir hikayeyi duymayı bırakacakları umudu.
Teknik direktör genellikle yanımıza geliyor. Ondan iki şey istiyorlar: Bir yandan bize özellikler ver, diğer yandan istikrar. Bunu kendinize üstlenmenizi ve yapmanızı öneririz. Sihirli çözüm, daha doğrusu gümüş kaplama, bu sorunları düşünmeyi ve zaman kaybetmeyi bırakmanızdır. Bu konuyu kapatacak özel insanlar olacak.
Bizim veya bir başkasının Kubernetes'e ihtiyacı olduğu ifadesi yanlıştır.
Yöneticilerin Kubernetes'e gerçekten ihtiyacı var çünkü bu, oynayabileceğiniz ve kurcalayabileceğiniz çok ilginç bir oyuncak. Dürüst olalım; oyuncakları herkes sever. Hepimiz bir yerlerde çocuğuz ve yenisini gördüğümüzde oynamak istiyoruz. Bazıları için bu, örneğin yönetim tarafından cesaretlendirilmedi çünkü onlar zaten yeterince oynadılar ve artık oynamak istemeyecek kadar yoruldular. Ancak bu hiç kimse için tamamen kaybedilmiş değil. Mesela sistem yönetimi ve DevOps alanındaki oyuncaklardan uzun süredir bıktıysam oyuncakları hâlâ seviyorum, yine de yenilerini alıyorum. Öyle ya da böyle tüm insanlar hala bir tür oyuncak istiyor.
Üretimle oynamaya gerek yok. Kategorik olarak yapmamayı önerdiğim ve şu anda topluca gördüğüm şey: "Ah, yeni bir oyuncak!" — koşup satın aldılar ve: “Şimdi okula götürelim, bütün arkadaşlarımıza gösterelim” dediler. Bunu yapma. Özür dilerim, çocuklarım yeni büyüyor, çocuklarda sürekli bir şeyler görüyorum, bunu kendimde fark ediyorum ve sonra bunu başkalarına genelliyorum.
Son cevap şu: Kubernetes'e ihtiyacınız yok. Sorunlarınızı çözmeniz gerekiyor.
Elde edebileceğiniz şey şudur:
- dürtü düşmez;
- Düşmeye çalışsa bile bunu önceden biliyoruz ve içine bir şeyler koyabiliyoruz;
- işimizin gerektirdiği hızda ve rahatlıkla değiştirebiliriz, bize sorun yaratmaz.
İki gerçek ihtiyaç vardır: kullanıma sunmanın güvenilirliği ve dinamizmi/esnekliği. Hangi iş kolunda olursa olsun, şu anda bir tür BT projesi yapan, dünyayı kolaylaştıran ve bunu anlayan herkesin bu ihtiyaçları çözmesi gerekiyor. Kubernetes doğru yaklaşımla, doğru anlayışla ve yeterli deneyimle bunları çözmenize olanak sağlar.
Sunucusuz hakkında
— Geleceğe biraz daha bakarsanız, altyapıda baş ağrısı olmaması sorununu, kullanıma sunma hızı ve uygulama değişikliklerinin hızıyla çözmeye çalışırsanız, örneğin sunucusuz yeni çözümler ortaya çıkar. Bu yönde bir potansiyel ve diyelim ki Kubernetes ve benzeri çözümler için bir tehlike hissediyor musunuz?
Dmitry: Burada bir kez daha belirtmemiz gerekiyor ki ben ileriye bakıp -bu böyle olacak! diyen bir kahin değilim! Gerçi ben de aynı şeyi yaptım. Ayaklarıma bakıyorum ve orada bir sürü sorun görüyorum, örneğin transistörlerin bilgisayardaki nasıl çalıştığı gibi. Komik, değil mi? CPU'da bazı hatalarla karşılaşıyoruz.
Tüm ekosistem sorunlarını çözerek sunucusuz sistemi oldukça güvenilir, ucuz, verimli ve kullanışlı hale getirin. Burada insanlığın hata toleransını yaratmak için ikinci bir gezegene ihtiyaç olduğu konusunda Elon Musk'a katılıyorum. Ne dediğini bilmesem de Mars'a uçmaya hazır olmadığımı ve bunun yarın olmayacağını anlıyorum.
Sunucusuz durumda bunun ideolojik olarak doğru bir şey olduğu, insanlığın hata toleransı gibi, iki gezegene sahip olmanın bir gezegenden daha iyi olduğu açıkça açıktır. Ama şimdi nasıl yapmalı? Çabalarınızı buna yoğunlaştırırsanız, bir sefer göndermek sorun olmaz. Birkaç sefer göndermek ve binlerce insanı oraya yerleştirmek de bence gerçekçi. Ancak insanlığın yarısının orada yaşamasını sağlayacak şekilde tamamen hataya dayanıklı hale getirmek, artık dikkate alınmadan bana imkansız görünüyor.
Sunucusuz bire bir: harika bir şey ama 2019'un sorunlarından çok uzak. 2030'a yaklaştık; bunu görmek için yaşayalım. Yaşayacağımıza hiç şüphem yok, mutlaka yaşayacağız (yatmadan önce tekrar edin), ama şimdi başka sorunları çözmemiz gerekiyor. Masal midillisi Rainbow'a inanmak gibi bir şey bu. Evet, vakaların yüzde birkaçı çözüldü ve mükemmel bir şekilde çözüldü, ancak öznel olarak sunucusuz bir gökkuşağı... Benim için bu konu çok uzak ve anlaşılmaz. Konuşmaya hazır değilim. 2019 yılında sunucusuz olarak tek bir uygulama yazamazsınız.
Kubernetes nasıl gelişecek?
— Potansiyel olarak harika olan bu uzak geleceğe doğru ilerlerken Kubernetes'in ve çevresindeki ekosistemin nasıl gelişeceğini düşünüyorsunuz?
Dmitry: Bunu çok düşündüm ve net bir cevabım var. İlki durum bilgisi olandır; sonuçta durum bilgisi olmayan işlemi yapmak daha kolaydır. Kubernetes başlangıçta buna daha fazla yatırım yaptı, her şey onunla başladı. Durum bilgisi Kubernetes'te neredeyse mükemmel çalışıyor, şikayet edilecek bir şey yok. Hala pek çok sorun var, daha doğrusu nüanslar. Orada her şey bizim için zaten harika çalışıyor, ama bu biziz. Bunun herkes için işe yaraması en az birkaç yıl daha alacak. Bu hesaplanmış bir gösterge değil, kafamdan gelen hislerim.
Kısacası, durum bilgisi olan çok güçlü bir şekilde gelişmelidir ve gelişecektir, çünkü tüm uygulamalarımız durum saklar; durum bilgisi olmayan uygulama yoktur. Bu bir yanılsama; her zaman bir çeşit veritabanına ve başka bir şeye ihtiyacınız var. Durum bilgisi mümkün olan her şeyi düzeltmekle, tüm hataları düzeltmekle, şu anda karşı karşıya olunan tüm sorunları iyileştirmekle ilgilidir - hadi buna benimseme diyelim.
Bilinmeyenlerin düzeyi, çözülmeyen sorunların düzeyi, bir şeyle karşılaşma olasılığı düzeyi önemli ölçüde düşecek. Bu önemli bir hikaye. Ve operatörler - yönetim mantığının kodlanmasıyla ilgili her şey, kolay bir hizmet almak için kontrol mantığı: MySQL kolay hizmet, RabbitMQ kolay hizmet, Memcache kolay hizmet - genel olarak, üzerinde çalışacağımızı garanti etmemiz gereken tüm bu bileşenler kutu. Bu sadece bir veritabanı istediğimiz ancak onu yönetmek istemediğimiz veya Kubernetes istediğimiz ancak yönetmek istemediğimiz acıyı çözer.
Operatör gelişiminin şu veya bu şekildeki hikayesi önümüzdeki birkaç yıl içinde önemli olacaktır.
Kullanım kolaylığının büyük ölçüde artması gerektiğini düşünüyorum - kutu giderek daha basit düğmelerle giderek daha siyah, daha güvenilir hale gelecektir.
Bir keresinde YouTube'da Saturday Night Live'da Isaac Asimov ile 80'lerden eski bir röportajı dinlemiştim - Urgant gibi bir program, sadece ilginç. Ona bilgisayarların geleceği hakkında sorular sordular. Geleceğin tıpkı radyo gibi basitlikte olduğunu söyledi. Radyo alıcısı başlangıçta karmaşık bir şeydi. Bir dalgayı yakalamak için düğmeleri 15 dakika çevirmeniz, şişleri çevirmeniz ve genel olarak her şeyin nasıl çalıştığını bilmeniz, radyo dalgası iletiminin fiziğini anlamanız gerekiyordu. Sonuç olarak radyoda tek bir düğme kalmıştı.
Şimdi 2019'da hangi radyo? Arabada radyo alıcısı tüm dalgaları ve istasyonların adlarını bulur. Sürecin fiziği 100 yıldır değişmedi ama kullanım kolaylığı değişti. Şimdi ve sadece şimdi değil, 1980'de Azimov ile röportaj yapıldığında herkes radyoyu kullanıyordu ve kimse onun nasıl çalıştığını düşünmüyordu. Her zaman işe yaradı; bu kesin.
Azimov daha sonra bilgisayarlarda da aynı durumun geçerli olacağını söyledi. Kullanım kolaylığı artacak. 1980'de bilgisayardaki tuşlara basmak için eğitilmeniz gerekirken, gelecekte durum böyle olmayacak.
Kubernetes ve altyapıyla birlikte kullanım kolaylığında da büyük bir artış yaşanacağına dair bir his var içimde. Bana göre bu çok açık; yüzeyde yatıyor.
Mühendislerle ne yapmalı?
— Peki Kubernetes'i destekleyen mühendislere ve sistem yöneticilerine ne olacak?
Dmitry: 1C'nin gelişinden sonra muhasebeciye ne oldu? Aynı sayılır. Bundan önce kağıt üzerinde sayıyorlardı - şimdi programda. İşgücü üretkenliği büyük miktarlarda arttı, ancak emeğin kendisi yok olmadı. Daha önce bir ampulü takmak için 10 mühendis gerekiyordu, şimdi bir tane yeterli olacak.
Bana öyle geliyor ki, yazılım miktarı ve görev sayısı artık yeni DevOps'un ortaya çıkmasından ve verimliliğin artmasından daha hızlı artıyor. Şu anda piyasada belirli bir kıtlık var ve uzun süre devam edecek. Daha sonra her şey bir tür normale dönecek, iş verimliliği artacak, giderek daha fazla sunucusuz olacak, Kubernetes'e tüm kaynakları tam olarak gerektiği gibi seçecek bir nöron eklenecek ve genel olarak her şeyi olması gerektiği gibi yapın; kişi sadece uzaklaşın ve müdahale etmeyin.
Ancak yine de birisinin karar vermesi gerekecek. Bu kişinin vasıf ve uzmanlık düzeyinin daha yüksek olduğu açıktır. Günümüzde muhasebe bölümünde 10 çalışanın elleri yorulmasın diye defter tutmasına gerek kalmıyor. Kesinlikle gerekli değil. Birçok belge elektronik belge yönetim sistemi tarafından otomatik olarak taranır ve tanınır. Zaten çok daha fazla beceriye sahip, iyi anlayışa sahip, akıllı bir baş muhasebeci yeterlidir.
Genel olarak tüm sektörlerde gidilecek yol budur. Arabalarda da durum aynı: Daha önce bir araba, bir tamirci ve üç sürücüyle birlikte geliyordu. Günümüzde araba kullanmak hepimizin her gün katıldığı basit bir süreçtir. Kimse arabanın karmaşık bir şey olduğunu düşünmüyor.
DevOps veya sistem mühendisliği ortadan kalkmayacak; üst düzey çalışma ve verimlilik artacak.
— İşin aslında artacağına dair ilginç bir fikir de duydum.
Dmitry: Elbette yüzde yüz! Çünkü yazdığımız yazılımların miktarı sürekli artıyor. Yazılımla çözdüğümüz sorunların sayısı sürekli artıyor. İş miktarı artıyor. Artık DevOps pazarı aşırı derecede ısınmış durumda. Bunu maaş beklentilerinde de görmek mümkün. İyi bir şekilde, ayrıntılara girmeden, X isteyen gençlerin, 1,5X isteyen orta oyuncuların ve 2X isteyen büyüklerin olması gerekir. Ve şimdi, Moskova DevOps maaş piyasasına bakarsanız, bir genç X'ten 3X'e, kıdemli biri X'ten 3X'e kadar istiyor.
Kimse ne kadara mal olduğunu bilmiyor. Maaş seviyesi güveninizle ölçülür - dürüst olmak gerekirse tam bir tımarhane, aşırı ısınmış bir pazar.
Elbette bu durum çok yakında değişecek; bir miktar doygunluğun meydana gelmesi gerekiyor. Yazılım geliştirmede durum böyle değil - herkesin geliştiricilere ve herkesin iyi geliştiricilere ihtiyacı olmasına rağmen, pazar kimin neye değer olduğunu anlıyor - sektör yerleşti. Bugünlerde DevOps'ta durum böyle değil.
— Duyduklarıma göre, mevcut sistem yöneticisinin çok fazla endişelenmemesi gerektiği, ancak becerilerini yükseltme ve yarın daha fazla iş olacağı ancak daha nitelikli olacağı gerçeğine hazırlanma zamanının geldiği sonucuna vardım.
Dmitry: Yüzde yüz. Genel olarak 2019 yılında yaşıyoruz ve hayatın kuralı şudur: yaşam boyu öğrenme - yaşamlarımız boyunca öğreniriz. Bana öyle geliyor ki artık herkes bunu zaten biliyor ve hissediyor, ancak bilmek yeterli değil - yapmalısınız. Her gün değişmeliyiz. Eğer bunu yapmazsak er ya da geç mesleğin bir kenara atılacağız.
180 derecelik keskin dönüşlere hazırlıklı olun. Bir şeyin kökten değiştiği, yeni bir şeyin icat edildiği bir durumu göz ardı etmiyorum - oluyor. Hop! - ve artık farklı davranıyoruz. Buna hazırlıklı olmak ve endişelenmemek önemlidir. Yarın yaptığım her şeyin gereksiz olduğu ortaya çıkabilir - hiçbir şey, hayatım boyunca çalıştım ve başka bir şey öğrenmeye hazırım. Problem değil. İş güvenliğinden korkmanıza gerek yok ama sürekli yeni bir şeyler öğrenmeye hazırlıklı olmanız gerekiyor.
Dilekler ve bir dakikalık reklam
- Bir dileğin var mı?
Dmitry: Evet, birkaç dileğim var.
İlk ve ticari - abone olun . Sevgili okuyucular, YouTube'a gidin ve kanalımıza abone olun. Yaklaşık bir ay içinde video hizmetini aktif olarak genişletmeye başlayacağız. Kubernetes hakkında açık ve çeşitli pek çok eğitici içeriğimiz olacak: pratik şeylerden laboratuvarlara, derin temel teorik konulara ve Kubernetes'in okulda nasıl kullanılacağına kadar. ilkeler ve kalıplar düzeyi.
İkinci ticari dilek - git ve yıldızları koyuyoruz çünkü onlardan besleniyoruz. Bize yıldız vermezseniz yiyecek hiçbir şeyimiz kalmayacak. Bir bilgisayar oyunundaki mana gibi. Bir şeyler yapıyoruz, yapıyoruz, deniyoruz, birisi bunların berbat bisikletler olduğunu söylüyor, biri her şeyin tamamen yanlış olduğunu söylüyor ama biz devam ediyoruz ve kesinlikle dürüst davranıyoruz. Bir sorunu görüyoruz, çözüyoruz ve deneyimlerimizi paylaşıyoruz. Bu nedenle bize bir yıldız verin, sizden gitmeyecek ama bize gelecektir çünkü biz onlardan besleniyoruz.
Üçüncüsü, önemli ve artık ticari olmayan arzu - masallara inanmayı bırak. Siz profesyonelsiniz. DevOps çok ciddi ve sorumluluk gerektiren bir meslektir. İşyerinde oynamayı bırakın. Bırakın sizin için tıklasın, anlayacaksınız. Hastaneye geldiğinizi ve orada doktorun sizin üzerinizde deney yaptığını hayal edin. Bunun birisine saldırgan olabileceğini anlıyorum, ancak büyük olasılıkla bu sizinle ilgili değil, başka biriyle ilgili. Başkalarına da durmalarını söyleyin. Bu gerçekten hepimizin hayatını mahvediyor; çoğu kişi operasyonlara, yöneticilere ve DevOps'a bir şeyleri yeniden bozan adamlar gibi davranmaya başlıyor. Bu, çoğu zaman oynamaya gitmemiz ve bunun böyle olduğuna soğuk bir bilinçle bakmamamız nedeniyle "kırıldı".
Bu, deneme yapmamanız gerektiği anlamına gelmez. Denememiz gerekiyor, kendimiz yapıyoruz. Dürüst olmak gerekirse, bazen kendimiz de oyun oynarız - bu elbette çok kötü, ama insani hiçbir şey bize yabancı değil. 2019'u üretimdeki oyunların değil, ciddi, iyi düşünülmüş deneylerin yılı ilan edelim. Muhtemelen.
- Çok teşekkür ederim!
Dmitry: Hem zaman ayırdığınız hem de röportaj için teşekkürler Vitaly. Sevgili okuyucular, birdenbire bu noktaya geldiyseniz çok teşekkür ederim. Umarım size en azından birkaç fikir getirmişizdir.
Röportajda Dmitry werf konusuna değindi. Şimdi bu neredeyse tüm sorunları çözen evrensel bir İsviçre bıçağı. Ama her zaman böyle değildi. Açık festivalde Dmitry Stolyarov size bu aracı detaylı olarak anlatacak. raporda Her şey olacak: Kubernetes'in sorunları ve gizli nüansları, bu zorlukları çözme seçenekleri ve werf'in mevcut uygulaması ayrıntılı olarak. 27 ve 28 Mayıs'ta bize katılın, mükemmel araçları yaratalım.
Kaynak: habr.com