Gözləmə ilə Vitali Xabarov müsahibə verdi Dmitri Stolyarov (), Flant şirkətinin texniki direktoru və həmtəsisçisi. Vitali Dmitridən Flantın nə etdiyi, Kubernetes, ekosistemin inkişafı, dəstək haqqında soruşdu. Kubernetesin nə üçün lazım olduğunu və ümumiyyətlə lazım olub olmadığını müzakirə etdik. Həm də mikroservislər, Amazon AWS, DevOps-a “bəxtəvər olacağam” yanaşması, Kubernetes-in gələcəyi, dünyanı niyə, nə vaxt və necə ələ keçirəcəyi, DevOps-un perspektivləri və mühəndislərin bu sahədə nəyə hazırlaşmalıdırlar. sadələşdirmə və neyron şəbəkələri ilə parlaq və yaxın gələcək.
DevOps Deflop-da podcast kimi dinləyin - DevOps haqqında rusdilli podkast və aşağıda mətn versiyasıdır.
Burada və aşağıda suallar verir Express42-dən mühəndis.
"Flant" haqqında
- Salam Dima. Sən texniki direktorsan”" və həm də onun yaradıcısı. Zəhmət olmasa bizə deyin ki, şirkət nə edir və siz nə ilə məşğulsunuz?
Dmitri: Kənardan belə görünür ki, biz hər kəs üçün Kubernetes quraşdıran və onunla nəsə edən adamlarıq. Amma bu doğru deyil. Biz Linux ilə məşğul olan bir şirkət kimi başlamışıq, lakin çox uzun müddətdir əsas fəaliyyətimiz istehsal və yüksək yüklü açar təslim layihələrə xidmət göstərməkdir. Adətən biz bütün infrastrukturu sıfırdan qururuq və sonra uzun, uzun müddət buna cavabdehik. Ona görə də “Flant”ın gördüyü, pul aldığı əsas iş budur məsuliyyət götürmək və açar təslim istehsalı həyata keçirmək.
Mən, texniki direktor və şirkətin təsisçilərindən biri kimi, bütün gecə-gündüz istehsalın əlçatanlığını necə artırmaq, onun işini sadələşdirmək, idarəçilərin həyatını asanlaşdırmaq, tərtibatçıların həyatını daha xoş etmək üçün çalışıram. .
Kubernetes haqqında
- Son vaxtlar mən Flantdan çoxlu hesabatlar görürəm Kubernetes haqqında. Buna necə gəldin?
Dmitri: Mən artıq bu barədə dəfələrlə danışmışam, amma təkrar etməkdən qətiyyən çəkinmirəm. Səbəb-nəticə arasında çaşqınlıq olduğu üçün bu mövzunu təkrar etməyi düzgün hesab edirəm.
Həqiqətən bir alətə ehtiyacımız var idi. Çox problemlərlə üzləşdik, mübarizə apardıq, müxtəlif qoltuqağaqlarla onların öhdəsindən gəldik və alətə ehtiyac duyduq. Bir çox fərqli variantdan keçdik, öz velosipedlərimizi düzəltdik və təcrübə qazandıq. Tədricən biz Docker-dən demək olar ki, görünən kimi - təxminən 2013-cü ildə istifadə etməyə başladıq. Göründüyü zaman bizim konteynerlərlə bağlı çoxlu təcrübəmiz var idi, biz artıq "Docker" in analoqunu - Python-da öz qoltuqlarımızın bəzilərini yazmışdıq. Docker-in gəlişi ilə qoltuq dəyənəklərini atmaq və etibarlı və cəmiyyət tərəfindən dəstəklənən bir həlldən istifadə etmək mümkün oldu.
Kubernetes ilə hekayə oxşardır. O, sürət qazanmağa başlayanda - bizim üçün bu versiya 1.2-dir - həm Shell, həm də Chef-də artıq bir dəstə qoltuqağacı var idi, hansısa şəkildə Docker ilə orkestrləşdirməyə çalışdıq. Rancher və digər müxtəlif həlləri ciddi şəkildə axtarırdıq, lakin sonra hər şeyin bizim etdiyimiz kimi və ya daha yaxşı həyata keçirildiyi Kubernetes ortaya çıxdı. Şikayət ediləcək bir şey yoxdur.
Bəli, burada bir növ qüsur var, orada bir növ qüsur var - çox qüsurlar var və 1.2 ümumiyyətlə dəhşətlidir, amma... Kubernetes tikilməkdə olan binaya bənzəyir - layihəyə baxıb başa düşürsən. ki, sərin olacaq. Binanın indi təməli və iki mərtəbəsi varsa, o zaman başa düşürsünüz ki, hələ köçməmək daha yaxşıdır, lakin proqram təminatı ilə bağlı belə problemlər yoxdur - artıq istifadə edə bilərsiniz.
Kubernetes-dən istifadə edib-etməməyi düşündüyümüz bir anımız olmadı. Biz onu görünməmişdən xeyli əvvəl gözləyirdik və özümüz də analoqlar yaratmağa çalışırdıq.
Kubernetes haqqında
— Kubernetesin özünün hazırlanmasında birbaşa iştirak edirsiniz?
Dmitri: Orta. Əksinə, biz ekosistemin inkişafında iştirak edirik. Biz müəyyən sayda çəkmə sorğuları göndəririk: Prometeyə, müxtəlif operatorlara, Helm-ə - ekosistemə. Təəssüf ki, etdiyimiz hər şeyi izləyə bilmirəm və səhv edə bilərəm, amma bizdən nüvəyə bir dənə də olsun hovuz yoxdur.
— Eyni zamanda, alətlərinizin çoxunu Kubernetes ətrafında inkişaf etdirirsinizmi?
Dmitri: Strategiya belədir: biz gedib artıq mövcud olan hər şeyə müraciət edirik. Çəkmə istəkləri orada qəbul edilmirsə, biz onları sadəcə özümüz çəngəlləyirik və tikintilərimizlə qəbul edilənə qədər yaşayırıq. Sonra, yuxarıya çatdıqda, yuxarı versiyaya qayıdırıq.
Məsələn, bizim Prometheus operatorumuz var, onunla artıq 5 dəfə məclisimizin yuxarı axınına geri-geri keçdik. Bir növ xüsusiyyətə ehtiyacımız var, çəkmə sorğusu göndərdik, onu sabah yaymalıyıq, lakin onun yuxarı axınında buraxılmasını gözləmək istəmirik. Buna uyğun olaraq özümüz üçün yığırıq, nədənsə ehtiyac duyduğumuz xüsusiyyətimizlə montajımızı bütün klasterlərimizə yayırıq. Sonra, məsələn, onu yuxarıda bizə təhvil verirlər: "Uşaqlar, gəlin bunu daha ümumi bir iş üçün edək", biz və ya başqası bunu bitirir və zaman keçdikcə yenidən birləşir.
Biz mövcud olan hər şeyi inkişaf etdirməyə çalışırıq. Hələ mövcud olmayan, hələ icad edilməmiş və ya icad edilmiş, lakin həyata keçirməyə vaxtı olmayan bir çox elementlər - biz bunu edirik. Həm də bir sənaye olaraq prosesi və ya velosiped qurmağı bəyəndiyimiz üçün deyil, sadəcə olaraq bu alətə ehtiyacımız olduğu üçün. Tez-tez belə bir sual verilir ki, biz niyə bu və ya digər işi etdik? Cavab sadədir - bəli, çünki biz daha da irəli getməli, hansısa praktiki problemi həll etməli idik və biz bunu bu tula ilə həll etdik.
Yol həmişə belədir: biz çox diqqətlə axtarırıq və bir çörəkdən trolleybus düzəltmək üçün heç bir həll tapmasaq, öz bulkamızı və öz trolleybusumuzu düzəldirik.
Flanta alətləri
— Bilirəm ki, Flant indi addon operatorları, shell operatorları və dapp/werf alətlərinə malikdir. Mən başa düşdüyüm kimi, bu, müxtəlif inkarnasiyalarda eyni alətdir. Mən də başa düşürəm ki, Flaunt daxilində daha çox müxtəlif alətlər var. Bu doğrudur?
Dmitri: GitHub-da daha çox şeyimiz var. İndi xatırladığım qədər, bizim status xəritəmiz var - hər kəsin rast gəldiyi Grafana paneli. Mediumda Kubernetes monitorinqi haqqında demək olar ki, hər ikinci məqalədə qeyd olunur. Status xəritəsinin nə olduğunu qısaca izah etmək mümkün deyil - bunun üçün ayrıca məqalə lazımdır, lakin bu, zamanla statusun monitorinqi üçün çox faydalı bir şeydir, çünki Kubernetes-də biz tez-tez zamanla statusu göstərməliyik. Bizdə LogHouse da var - bu, Kubernetes-də log toplamaq üçün ClickHouse və qara sehrə əsaslanan bir şeydir.
Çoxlu kommunal xidmətlər! Və daha çox olacaq, çünki bu il bir sıra daxili həllər buraxılacaq. Addon operatoruna əsaslanan çox böyük olanlardan Kubernetes üçün bir dəstə əlavə var, ala sert menecerini necə düzgün quraşdırmaq olar - sertifikatları idarə etmək üçün bir alət, bir dəstə aksesuarla Prometheus'u necə düzgün quraşdırmaq olar - bunlar təxminən iyirmi fərqlidir. məlumatları ixrac edən və bir şey toplayan ikili sənədlər, bu Prometey üçün ən heyrətamiz qrafika və xəbərdarlıqlara malikdir. Bütün bunlar bir çoxluqda quraşdırılmış Kubernetes-ə sadəcə bir dəstə əlavədir və sadədən sərin, mürəkkəb, avtomatikə çevrilir, burada bir çox məsələlər artıq həll edilmişdir. Bəli, çox şey edirik.
Ekosistemin inkişafı
"Mənə elə gəlir ki, bu, bu alətin və onun istifadə üsullarının inkişafına çox böyük töhfədir." Ekosistemin inkişafına daha kimin eyni töhfə verəcəyini təxmini təxmin edə bilərsinizmi?
Dmitri: Rusiyada bizim bazarda fəaliyyət göstərən şirkətlərdən heç kim yaxın deyil. Əlbəttə ki, bu, yüksək səsli bir bəyanatdır, çünki Mail və Yandex kimi böyük oyunçular var - onlar da Kubernetes ilə bir şey edirlər, lakin hətta onlar bütün dünyada bizdən daha çox iş görən şirkətlərin töhfəsinə yaxınlaşmırlar. Səhv etmirəmsə, 80 nəfərlik heyəti olan Flant və təkcə Kubernetes başına 300 mühəndisi olan Red Hat-ı müqayisə etmək çətindir. Müqayisə etmək çətindir. RnD şöbəsində mən də daxil olmaqla, bütün alətlərimizi kəsən 6 nəfərimiz var. 6 Red Hat mühəndisinə qarşı 300 nəfər - müqayisə etmək bir qədər çətindir.
- Halbuki, bu 6 nəfərin belə, həqiqətən də faydalı və özgələşdirici bir iş görə bildiyi halda, əməlli-başlı problemlə üzləşib cəmiyyətə həllini verəndə - maraqlı hal. Başa düşürəm ki, öz Kubernetes inkişaf və dəstək komandasının olduğu böyük texnologiya şirkətlərində, prinsipcə, eyni alətlər hazırlana bilər. Bu, onlar üçün Kubernetes-dən istifadə edən bütün cəmiyyətə təkan verən, inkişaf etdirilə və cəmiyyətə nə verilə biləcəyinə dair bir nümunədir.
Dmitri: Bu, yəqin ki, inteqratorun xüsusiyyətidir, özünəməxsusluğudur. Çoxlu layihələrimiz var və bir çox fərqli vəziyyətlər görürük. Bizim üçün əlavə dəyər yaratmağın əsas yolu bu halları təhlil etmək, ümumi cəhətləri tapmaq və bizim üçün mümkün qədər ucuz etməkdir. Biz bunun üzərində fəal işləyirik. Rusiya və dünya haqqında danışmaq mənim üçün çətindir, lakin şirkətdə Kubernetes üzərində işləyən təxminən 40 DevOps mühəndisimiz var. Düşünmürəm ki, Rusiyada, əgər varsa, Kubernetes-i başa düşən müqayisə olunan sayda mütəxəssisi olan şirkətlər çox deyil.
Mən DevOps mühəndisi vəzifəsi haqqında hər şeyi başa düşürəm, hər kəs hər şeyi başa düşür və DevOps mühəndislərini DevOps mühəndisləri adlandırmağa öyrəşib, biz bunu müzakirə etməyəcəyik. Bütün bu 40 heyrətamiz DevOps mühəndisləri hər gün problemlərlə qarşılaşır və həll edirlər, biz sadəcə bu təcrübəni təhlil edirik və ümumiləşdirməyə çalışırıq. Başa düşürük ki, içimizdə qalsa, bir-iki ildən sonra alət yararsız olacaq, çünki cəmiyyətdə bir yerdə hazır Tula görünəcək. Bu təcrübəni daxildə toplamağın mənası yoxdur - o, sadəcə olaraq enerji və vaxtı dev/null-a boşaldır. Və buna qətiyyən təəssüflənmirik. Biz hər şeyi böyük məmnuniyyətlə dərc edirik və başa düşürük ki, onu dərc etmək, inkişaf etdirmək, təbliğ etmək, təbliğ etmək lazımdır ki, insanlar ondan istifadə etsinlər və öz təcrübələrini əlavə etsinlər - sonra hər şey böyüyür və yaşayır. Sonra iki ildən sonra alət zibil qutusuna getmir. Güc tökməyə davam etmək təəssüf doğurmur, çünki kimsə sizin alətinizdən istifadə edir və iki ildən sonra hər kəs ondan istifadə edir.
Bu dapp/werf ilə böyük strategiyamızın bir hissəsidir. Nə vaxt hazırlamağa başladığımızı xatırlamıram, deyəsən 3 il əvvəldir. Əvvəlcə, ümumiyyətlə, qabıqda idi. Bu, konsepsiyanın super sübutu idi, biz bəzi xüsusi problemlərimizi həll etdik - işlədi! Amma qabıqla bağlı problemlər var, onu daha da genişləndirmək mümkün deyil, qabıqda proqramlaşdırma başqa işdir. Ruby-də yazmaq vərdişimiz var idi, buna görə də Ruby-də nəyisə yenidən düzəldirdik, inkişaf etdirdik, inkişaf etdirdik, inkişaf etdirdik və rastlaşdıq ki, camaat, “biz bunu istəyirik, istəmirik” deməyən kütlə. ” burnunu Ruby-yə çevirir, bu nə qədər gülməlidir? Biz başa düşdük ki, bütün bunları Go-da yalnız yoxlama siyahısındakı ilk nöqtəni qarşılamaq üçün yazmalıyıq: DevOps aləti statik binar olmalıdır. Go olmaq və ya olmamaq o qədər də vacib deyil, lakin Go ilə yazılmış statik binar daha yaxşıdır.
Enerjimizi sərf etdik, Go-da dapp-ı yenidən yazdıq və onu werf adlandırdıq. Dapp artıq dəstəklənmir, inkişaf etdirilmir, ən son versiyada işləyir, lakin yuxarıya doğru mütləq təkmilləşdirmə yolu var və siz onu izləyə bilərsiniz.
Dapp niyə yaradıldı?
— Qısaca deyə bilərsiniz ki, dapp nə üçün yaradılıb, hansı problemləri həll edir?
Dmitri: Birinci səbəb məclisdədir. Başlanğıcda, Docker-in çoxmərhələli imkanları olmadığı zaman qurma ilə bağlı ciddi problemlər yaşadıq, ona görə də özümüz çoxmərhələli etdik. Sonra görüntünün təmizlənməsi ilə bağlı bir çox problemimiz oldu. CI/CD ilə məşğul olan hər kəs, gec deyil, bir çox toplanmış şəkillərin olması problemi ilə qarşılaşır, lazım olmayanları birtəhər təmizləmək və lazım olanı tərk etmək lazımdır.
İkinci səbəb yerləşdirmədir. Bəli, Helm var, ancaq bəzi problemləri həll edir. Qəribədir ki, “Helm Kubernetes üçün Paket Meneceridir” yazılıb. Məhz nə "the". "Paket meneceri" sözləri də var - Paket menecerindən adi gözlənti nədir? Biz deyirik: "Paket meneceri - paketi quraşdırın!" və onun bizə deyəcəyini gözləyirik: "Bağlama çatdırıldı."
Maraqlıdır ki, biz deyirik: "Dukan, paketi quraşdırın" və o, quraşdırdığını cavablandırdıqda, quraşdırmaya yeni başladığı məlum oldu - o, Kubernetesə işarə etdi: "Bu şeyi işə salın!" və başladımı, yoxsa yox. , işləsə də, işləməsə də Helm bu məsələni qətiyyən həll etmir.
Məlum oldu ki, Helm sadəcə Kubernetes-ə məlumatları yükləyən mətn preprosessorudur.
Ancaq hər hansı bir yerləşdirmənin bir hissəsi olaraq, tətbiqin istehsal üçün buraxılıb-çıxılmadığını bilmək istəyirik? İstehsal üçün buraxılması o deməkdir ki, proqram ora köçüb, yeni versiya yerləşdirilib və heç olmasa orada qəzaya uğramır və düzgün cavab verir. Helm bu problemi heç bir şəkildə həll etmir. Bunu həll etmək üçün çox səy sərf etməlisiniz, çünki Kubernetes-ə yaymaq və orada baş verənləri izləmək əmrini verməlisiniz - yerləşdirilib və ya yayılıb. Yerləşdirmə, təmizləmə və montajla bağlı bir çox vəzifə də var.
Planlar
Bu il biz yerli inkişafa başlayacağıq. Biz əvvəllər Vagrant-da olana nail olmaq istəyirik - biz “vagrant up” yazdıq və virtual maşınlar yerləşdirdik. Git-də bir layihənin olduğu nöqtəyə çatmaq istəyirik, orada "werf up" yazırıq və o, bu layihənin yerli mini-Kubda yerləşdirilən yerli nüsxəsini gətirir və inkişaf üçün əlverişli bütün kataloqlar birləşdirilmişdir. . İnkişaf dilindən asılı olaraq, bu, fərqli şəkildə edilir, lakin buna baxmayaraq, yerli inkişaf quraşdırılmış fayllar altında rahat şəkildə həyata keçirilə bilər.
Bizim üçün növbəti addımdır tərtibatçılar üçün rahatlığa sərmayə qoyun. Layihəni bir alətlə tez bir zamanda yerli olaraq yerləşdirmək üçün onu inkişaf etdirin, Git-ə itələyin və o, həmçinin boru kəmərlərindən asılı olaraq mərhələ və ya sınaqlara çıxarılacaq və sonra istehsala getmək üçün eyni alətdən istifadə edəcək. Yerli mühitdən satışa qədər infrastrukturun bu birliyi, unifikasiyası, təkrar istehsalı bizim üçün çox vacib məqamdır. Ancaq bu hələ werf-də deyil - biz sadəcə bunu etməyi planlaşdırırıq.
Lakin dapp/werf-ə gedən yol həmişə Kubernetes ilə eyni olub. Problemlərlə qarşılaşdıq, onları həll yolları ilə həll etdik - qabıqda, hər şeydə özümüz üçün bəzi həllər tapdıq. Sonra birtəhər bu həll yollarını düzəltməyə, ümumiləşdirməyə və bu halda ikili sistemlərə birləşdirməyə çalışdılar, biz bunu sadəcə paylaşırıq.
Bütün bu hekayəyə bənzətmələrlə baxmağın başqa bir yolu var.
Kubernetes mühərriki olan avtomobil çərçivəsidir. Qapılar, şüşələr, radiolar, yolkalar yoxdur - ümumiyyətlə heç nə yoxdur. Sadəcə karkas və mühərrik. Bir də Helm var - bu sükandır. Sərin - sükan var, ancaq bir sükan pininə, sükan çarxına, sürət qutusuna və təkərlərə də ehtiyacınız var və onlar olmadan edə bilməzsiniz.
Werf vəziyyətində, bu Kubernetes üçün başqa bir komponentdir. Yalnız indi werf-in alfa versiyasında, məsələn, Helm werf daxilində tərtib edilmişdir, çünki biz bunu özümüz etməkdən yorulmuşuq. Bunu etmək üçün bir çox səbəb var, mən sizə bütün sükanı niyə werf daxilində tiller ilə birlikdə tərtib etdiyimizi ətraflı izah edəcəyəm. .
İndi werf daha inteqrasiya olunmuş komponentdir. Bitmiş sükan, sükan sancağı alırıq - mən avtomobillərdə çox yaxşı deyiləm, amma bu, kifayət qədər geniş problemləri həll edən böyük bir blokdur. Kataloqu özümüz araşdırmaq, bir hissəni digəri üçün seçmək, onları necə birləşdirmək barədə düşünmək lazım deyil. Bir anda çoxlu sayda problemi həll edən hazır kombayn alırıq. Lakin onun daxilində eyni açıq mənbə komponentlərindən qurulub, hələ də montaj üçün Docker-dən, bəzi funksiyalar üçün Helm-dən istifadə edir və bir neçə başqa kitabxana da var. Bu, sərin CI/CD-ni qutudan tez və rahat şəkildə çıxarmaq üçün inteqrasiya olunmuş alətdir.
Kubernetes-ə qulluq etmək çətindir?
— Kubernetes-dən istifadə etməyə başladığınız təcrübədən danışırsınız, bu sizin üçün bir çərçivədir, mühərrikdir və ona çoxlu müxtəlif şeylər asmaq olar: kuzov, sükan çarxı, pedallardakı vintlər, oturacaqlar. Sual yaranır - Kubernetes dəstəyi sizin üçün nə qədər çətindir? Çox təcrübəniz var, hər şeydən təcrid olunmuş şəkildə Kubernetes-i dəstəkləmək üçün nə qədər vaxt və resurs sərf edirsiniz?
Dmitri: Bu çox çətin sualdır və cavab vermək üçün dəstəyin nə olduğunu və Kubernetesdən nə istədiyimizi başa düşməliyik. Bəlkə açıqlayasan?
— Bildiyim qədər və gördüyüm kimi, indi bir çox komanda Kubernetes-i sınamaq istəyir. Hər kəs özünü buna bağlayır, dizləri üstünə qoyur. Mənə elə gəlir ki, insanlar həmişə bu sistemin mürəkkəbliyini başa düşmürlər.
Dmitri: Belədir.
— Kubernetes-i sıfırdan götürüb quraşdırmaq nə qədər çətindir ki, istehsala hazır olsun?
Dmitri: Sizcə ürəyin köçürülməsi nə qədər çətindir? Mən başa düşürəm ki, bu kompromat sualdır. Skalpeldən istifadə etmək və səhv etməmək o qədər də çətin deyil. Əgər sizə harada kəsiləcəyini və harada tikəcəyini söyləyirlərsə, prosedurun özü mürəkkəb deyil. Vaxt keçdikcə hər şeyin düzələcəyinə zəmanət vermək çətindir.
Kubernetes quraşdırmaq və onu işə salmaq asandır: cücə! — quraşdırılıb, bir çox quraşdırma üsulları var. Bəs problemlər yarananda nə baş verir?
Suallar həmişə ortaya çıxır - biz hələ nəyi nəzərə almamışıq? Hələ nə etməmişik? Hansı Linux nüvəsi parametrləri səhv göstərilib? Ya Rəbb, biz onların adını çəkdikmi?! Hansı Kubernetes komponentlərini təqdim etmişik, hansını etməmişik? Minlərlə sual yaranır və onlara cavab vermək üçün bu sənayedə 15-20 il vaxt sərf etmək lazımdır.
Bu mövzuda "Kubernetləri saxlamaq çətindirmi?" Probleminin mənasını aça biləcək bir nümunəm var. Bir müddət əvvəl Cilium-u Kubernetes-də şəbəkə kimi tətbiq etməyə çalışıb-çalışmayacağımızı ciddi şəkildə düşündük.
Ciliumun nə olduğunu izah edim. Kubernetes şəbəkə alt sisteminin bir çox fərqli tətbiqinə malikdir və onlardan biri çox gözəldir - Cilium. Onun mənası nədir? Kerneldə bir müddət əvvəl kernel üçün qarmaqlar yazmaq mümkün oldu ki, onlar bu və ya digər şəkildə şəbəkə alt sistemini və müxtəlif digər alt sistemləri zəbt edir və nüvədəki böyük hissələrdən yan keçməyə imkan verir.
Linux nüvəsi tarixən bir ip marşrutu, həddindən artıq filtr, körpülər və 15, 20, 30 yaşlı bir çox müxtəlif köhnə komponentlərə malikdir. Ümumiyyətlə, işləyirlər, hər şey əladır, amma indi qablar yığıblar və bir-birinin üstünə 15 kərpicdən ibarət qüllə kimi görünür, onun üstündə isə bir ayağın üstündə dayanırsan – qəribə hiss. Bu sistem tarixən bədəndəki appendiks kimi bir çox nüanslarla inkişaf etmişdir. Bəzi hallarda, məsələn, performans problemləri var.
Gözəl bir BPF və kernel üçün qarmaqlar yazmaq qabiliyyəti var - uşaqlar nüvə üçün öz qarmaqlarını yazdılar. Paket Linux nüvəsinə daxil olur, onu birbaşa girişdə çıxarırlar, körpülər olmadan, TCP olmadan, IP yığını olmadan - bir sözlə, Linux nüvəsində yazılan hər şeyi yan keçərək, özləri emal edirlər və sonra tüpürürlər. konteynerə tökün.
Nə olub? Çox gözəl performans, gözəl xüsusiyyətlər - sadəcə sərin! Lakin biz buna baxırıq və görürük ki, hər bir maşında Kubernetes API-yə qoşulan və bu API-dən aldığı məlumatlara əsasən C kodunu yaradan və nüvəyə yüklədiyi ikili faylları tərtib edən proqram var ki, bu qarmaqlar işləsin. nüvə məkanında.
Bir şey səhv olarsa nə olar? Biz bilmirik. Bunu başa düşmək üçün bütün bu kodu oxumalı, bütün məntiqi başa düşməlisiniz və bunun nə qədər çətin olması təəccüblüdür. Ancaq digər tərəfdən, bu körpülər, şəbəkə filtrləri, ip marşrutu var - mən onların mənbə kodunu oxumamışam və şirkətimizdə işləyən 40 mühəndis də yoxdur. Ola bilsin ki, yalnız bir neçəsi bəzi hissələri başa düşür.
Və nə fərqi var? Belə çıxır ki, ip rout, Linux nüvəsi var və yeni bir alət var - bunun nə fərqi var, biz birini və ya digərini başa düşmürük. Ancaq yeni bir şey istifadə etməkdən qorxuruq - niyə? Çünki alətin 30 yaşı varsa, 30 il ərzində bütün səhvlər tapılıb, bütün səhvlər üzərində addım atılıb və hər şey haqqında bilmək lazım deyil - o, qara qutu kimi işləyir və həmişə işləyir. Hər kəs bilir ki, hansı diaqnostik tornavida hansı yerə yapışdırılsın, hansı tcpdump hansı anda işləsin. Hər kəs diaqnostik yardım proqramlarını yaxşı bilir və bu komponentlər dəstinin Linux nüvəsində necə işlədiyini başa düşür - onun necə işlədiyini deyil, ondan necə istifadə olunacağını.
Və çox gözəl Ciliumun 30 yaşı yoxdur, hələ qocalmayıb. Kubernetesdə də eyni problem var, kopyalayın. Cilium mükəmməl quraşdırılıb, Kubernetes mükəmməl quraşdırılıb, lakin istehsalda bir şey səhv olanda, kritik vəziyyətdə nəyin səhv olduğunu tez başa düşə bilirsinizmi?
Kubernetes-ə qulluq etmək çətindir deyəndə - yox, bu, çox asandır və bəli, inanılmaz dərəcədə çətindir. Kubernetes tək başına əla işləyir, lakin bir milyard nüansla.
“Mən şanslı olacağam” yanaşması haqqında
— Demək olar ki, bu nüansların görünəcəyinə zəmanət verilən şirkətlər varmı? Tutaq ki, Yandex birdən bütün xidmətləri Kubernetes-ə köçürür, orada böyük bir yük olacaq.
Dmitri: Xeyr, söhbət yükdən deyil, ən sadə şeylərdən gedir. Məsələn, bizdə Kubernetes var, tətbiqi orada yerləşdirdik. Bunun işlədiyini necə bilirsiniz? Tətbiqin çökmədiyini başa düşmək üçün sadəcə hazır alət yoxdur. Xəbərdarlıqlar göndərən hazır sistem yoxdur, siz bu xəbərdarlıqları və hər bir cədvəli konfiqurasiya etməlisiniz. Və biz Kubernetes-i yeniləyirik.
Məndə Ubuntu 16.04 var. Deyə bilərsiniz ki, bu köhnə versiyadır, lakin LTS olduğu üçün biz hələ də onun üzərindəyik. Sistem var, onun nüansı C qruplarını təmizləməməsidir. Kubernetes podları işə salır, C qrupları yaradır, sonra podları silir və birtəhər belə çıxır - təfərrüatları xatırlamıram, bağışlayın - sistem dilimləri qalır. Bu, zaman keçdikcə istənilən avtomobilin güclü şəkildə yavaşlamağa başlamasına səbəb olur. Bu, hətta yüksək yükləmə ilə bağlı bir sual deyil. Daimi podlar işə salınarsa, məsələn, daim podlar yaradan bir Cron İşi varsa, Ubuntu 16.04 ilə maşın bir həftədən sonra yavaşlamağa başlayacaq. Bir dəstə C-qrupu yaradıldığına görə daimi yüksək yük ortalaması olacaq. Bu, sadəcə Ubuntu 16 və Kubernetes quraşdıran hər kəsin qarşılaşacağı problemdir.
Deyək ki, o, bir şəkildə systemd və ya başqa bir şeyi yeniləyir, lakin Linux nüvəsində 4.16-a qədər bu, daha gülməli görünür - C qruplarını sildiyiniz zaman onlar nüvəyə sızır və əslində silinmir. Ona görə də bu maşın üzərində bir ay işlədikdən sonra ocaqlar üçün yaddaş statistikasına baxmaq mümkün olmayacaq. Faylı çıxarırıq, proqramda yuvarlayırıq və bir fayl 15 saniyə yuvarlanır, çünki nüvə öz daxilində bir milyon C-qrupunu saymaq üçün çox uzun vaxt aparır, görünür, silinir, amma yox - onlar sızır. .
Hələ orda-burda belə xırda şeylər çoxdur. Bu, nəhəng şirkətlərin bəzən çox ağır yüklər altında üzləşə biləcəyi bir məsələ deyil - yox, bu, gündəlik işlərlə bağlı məsələdir. İnsanlar aylarla belə yaşaya bilərlər - onlar Kubernetes quraşdırdılar, tətbiqi yerləşdirdilər - görünür, işləyir. Bir çox insanlar üçün bu normaldır. Bu proqramın nədənsə qəzaya uğrayacağını belə bilməyəcəklər, xəbərdarlıq almayacaqlar, lakin onlar üçün bu normadır. Əvvəllər monitorinq olmadan virtual maşınlarda yaşayırdıq, indi Kubernetesə keçdik, həm də monitorinq etmədən - fərq nədir?
Sual budur ki, biz buzun üzərində yeriyərkən, əvvəlcədən ölçmədikcə, onun qalınlığını heç vaxt bilmirik. Bir çox insan gəzir və narahat olmur, çünki onlar əvvəllər gəziblər.
Mənim fikrimcə, hər hansı bir sistemin işlədilməsinin nüansı və mürəkkəbliyi buzun qalınlığının problemlərimizi həll etmək üçün tam olaraq kifayət etməsini təmin etməkdir. Söhbətimiz budur.
İT-də mənə elə gəlir ki, “bəxtəvər olacağam” yanaşmaları həddən artıq çoxdur. Bir çox insanlar uğur qazanacaqları ümidi ilə proqram təminatı quraşdırır və proqram kitabxanalarından istifadə edirlər. Ümumiyyətlə, bir çox insan şanslıdır. Yəqin buna görə işləyir.
— Pessimist qiymətləndirməmə görə belə görünür: risklər yüksək olduqda və proqram işləməli olduqda, Flaunt-dan, bəlkə də Red Hat-dan dəstək lazımdır və ya xüsusi olaraq Kubernetes-ə həsr olunmuş daxili komandanıza ehtiyacınız olacaq, hansı ki, hazırdır. onu çəkmək üçün.
Dmitri: Obyektiv olaraq belədir. Kiçik bir komanda üçün Kubernetes hekayəsinə təkbaşına daxil olmaq bir sıra riskləri ehtiva edir.
Konteynerlərə ehtiyacımız varmı?
— Rusiyada Kubernetesin nə qədər geniş yayıldığını deyə bilərsinizmi?
Dmitri: Məndə bu məlumat yoxdur və başqa kimsədə olduğuna əmin deyiləm. Biz deyirik: "Kubernetes, Kubernetes", lakin bu məsələyə baxmağın başqa bir yolu var. Mən konteynerlərin nə qədər geniş yayıldığını da bilmirəm, amma İnternetdəki hesabatlardan belə bir rəqəm bilirəm ki, konteynerlərin 70%-i Kubernetes tərəfindən təşkil edilir. Bu, dünyada kifayət qədər böyük bir nümunə üçün etibarlı mənbə idi.
Sonra başqa bir sual - konteynerlərə ehtiyacımız varmı? Mənim şəxsi hisslərim və Flant şirkətinin ümumi mövqeyi ondan ibarətdir ki, Kubernetes faktiki standartdır.
Kubernetesdən başqa heç nə olmayacaq.
Bu, infrastrukturun idarə edilməsi sahəsində mütləq oyun dəyişdiricisidir. Sadəcə mütləq - budur, daha Ansible, Chef, virtual maşınlar, Terraform yoxdur. Mən köhnə kolxoz üsullarını demirəm. Kubernetes mütləq dəyişdiricidir, və indi yalnız belə olacaq.
Aydındır ki, bunu dərk etmək üçün bəzilərinə bir neçə il, bəzilərinə isə bir neçə onillik lazımdır. Şübhə etmirəm ki, Kubernetes və bu yeni görünüşdən başqa heç nə olmayacaq: biz artıq əməliyyat sisteminə zərər vermirik, lakin istifadə edirik. kod kimi infrastruktur, yalnız kodla deyil, yml ilə - deklarativ şəkildə təsvir edilmiş infrastruktur. Məndə elə bir hiss var ki, həmişə belə olacaq.
— Yəni, hələ Kubernetesə keçməmiş şirkətlər mütləq ona keçəcək və ya unudulmuş vəziyyətdə qalacaqlar. Mən sizi düz başa düşdüm?
Dmitri: Bu da tamamilə doğru deyil. Məsələn, əgər DNS serverini idarə etmək vəzifəmiz varsa, o zaman o, FreeBSD 4.10-da işlədilə bilər və 20 il mükəmməl işləyə bilər. Sadəcə çalış və bu qədər. Bəlkə də 20 ildən sonra nəyisə bir dəfə yeniləmək lazım gələcək. Əgər işə saldığımız formatda proqram təminatından danışırıqsa və o, əslində uzun illər heç bir yeniləmə olmadan, dəyişiklik etmədən işləyirsə, əlbəttə ki, Kubernetes olmayacaq. Orada ona ehtiyac yoxdur.
CI/CD ilə əlaqəli hər şey - Davamlı Çatdırılma tələb olunduğu yerdə, versiyaları yeniləməlisiniz, aktiv dəyişikliklər etməlisiniz, nasazlığa dözümlülük yaratmaq lazım olan hər yerdə - yalnız Kubernetes.
Mikroservislər haqqında
- Burada bir az dissonans yaranıb. Kubernetes ilə işləmək üçün xarici və ya daxili dəstəyə ehtiyacınız var - bu, ilk məqamdır. İkincisi, biz inkişafa yeni başlayanda biz kiçik bir startapıq, hələ heç nəyimiz yoxdur, Kubernetes və ya ümumiyyətlə mikroservis arxitekturasının inkişafı mürəkkəb ola bilər və həmişə iqtisadi cəhətdən əsaslandırılmır. Fikrinizlə maraqlanıram - startaplar dərhal Kubernetes üçün sıfırdan yazmağa başlamalıdırlar, yoxsa onlar hələ də monolit yazıb, sonra yalnız Kubernetesə gələ bilərlərmi?
Dmitri: Gözəl sual. Mikroservislər haqqında danışıram Dəfələrlə mikroskopla mismar vurmağa çalışan insanlarla qarşılaşmışam. Yanaşma özü düzgündür, biz öz daxili proqram təminatımızı bu şəkildə dizayn edirik. Ancaq bunu edərkən, nə etdiyinizi aydın başa düşməlisiniz. Mikroservislər haqqında ən çox nifrət etdiyim söz “mikro”dur. Tarixən bu söz orada yaranıb və insanlar nədənsə mikro mikrometr kimi çox kiçik, millimetrdən də az olduğunu düşünürlər. Bu səhvdir.
Məsələn, bir monolit var ki, onu 300 nəfər yazır və inkişafda iştirak edən hər kəs başa düşür ki, orada problemlər var və onu mikro hissələrə bölmək lazımdır - təxminən 10 parça, hər birini 30 nəfər yazır. minimum versiyada. Bu vacibdir, zəruri və sərindir. Ancaq 3 çox sərin və istedadlı oğlanın diz üstə 60 mikroservis yazdığı bizə bir başlanğıc gələndə, hər dəfə Corvalol axtarıram.
Mənə elə gəlir ki, bu barədə artıq minlərlə dəfə danışılıb - bu və ya digər formada paylanmış monolit əldə etdik. Bu, iqtisadi cəhətdən əsaslandırılmır, ümumiyyətlə, hər şeydə çox çətindir. Mən bunu o qədər dəfələrlə görmüşəm ki, bu məni çox incidir, ona görə də bu barədə danışmağa davam edirəm.
İlkin suala, bir tərəfdən Kubernetes-in istifadəsinin qorxulu olması arasında ziddiyyət var, çünki orada nəyin qırılacağı və ya işləməyəcəyi aydın deyil, digər tərəfdən hər şeyin ora getdiyi aydındır. və Kubernetesdən başqa heç bir şey mövcud olmayacaq. Cavab - gələn faydanın miqdarını, həll edə biləcəyiniz vəzifələrin miqdarını çəkin. Bu miqyasın bir tərəfindədir. Digər tərəfdən, dayanma vaxtı və ya cavab müddətinin azalması, mövcudluq səviyyəsi - performans göstəricilərinin azalması ilə bağlı risklər var.
Budur - ya biz tez hərəkət edirik və Kubernetes bizə çox şeyi daha sürətli və daha yaxşı etməyə imkan verir, ya da etibarlı, zamanla sınaqdan keçirilmiş həllərdən istifadə edirik, lakin daha yavaş hərəkət edirik. Bu, hər bir şirkətin etməli olduğu seçimdir. Siz bunu cəngəllikdə bir yol kimi düşünə bilərsiniz - ilk dəfə gəzdiyiniz zaman ilan, pələng və ya dəli porsuqla qarşılaşa bilərsiniz və 10 dəfə getdiyiniz zaman yolu tapdaladınız, çıxardınız. budaqlar və daha asan gəzmək. Hər dəfə yol daha da genişlənir. Sonra asfalt yol, daha sonra isə gözəl bulvardır.
Kubernetes yerində dayanmır. Yenə sual: Kubernetes, bir tərəfdən, 4-5 binar, digər tərəfdən, bütün ekosistemdir. Bu, bizim maşınlarımızda olan əməliyyat sistemidir. Bu nədir? Ubuntu yoxsa Curios? Bu, Linux nüvəsidir, əlavə komponentlər dəstəsidir. Bütün bunlar burada, bir zəhərli ilan yoldan atılıb, ora hasar çəkilib. Kubernetes çox sürətlə və dinamik inkişaf edir və risklərin həcmi, bilinməyənlərin həcmi hər ay azalır və müvafiq olaraq bu tərəzilər yenidən tarazlaşır.
Başlanğıcın nə etməli olduğu sualına cavab olaraq deyərdim - Flaunt-a gəlin, 150 min rubl ödəyin və açar təslim DevOps asan xidmətini əldə edin. Bir neçə tərtibatçı ilə kiçik bir başlanğıcsınızsa, bu işləyir. Problemlərinizi necə həll edəcəyinizi və bu anda maaş verməli olan öz DevOps-larınızı işə götürmək əvəzinə, bütün məsələlərə açar təslim həll tapacaqsınız. Bəli, bəzi çatışmazlıqlar var. Biz autsorser olaraq bu qədər cəlb oluna və dəyişikliklərə tez reaksiya verə bilmərik. Amma bizim çoxlu təcrübəmiz və hazır təcrübəmiz var. Zəmanət veririk ki, istənilən vəziyyətdə biz mütləq bunu tez bir zamanda anlayacağıq və istənilən Kuberneti ölülər arasından dirildəcəyik.
Mən 10 nəfərlik bir komandanı əməliyyatlara həsr edə biləcəyiniz ölçüyə qədər startaplara və qurulmuş bizneslərə autsorsinqi tövsiyə edirəm, çünki əks halda heç bir məna yoxdur. Bunu autsorsing etmək mütləq mənadadır.
Amazon və Google haqqında
— Amazon və ya Google-dan bir həlldən olan hostu autsors hesab etmək olarmı?
Dmitri: Bəli, təbii ki, bu, bir sıra məsələləri həll edir. Ancaq yenə də nüanslar var. Onu necə istifadə edəcəyinizi hələ də başa düşməlisiniz. Məsələn, Amazon AWS-in işində min bir xırda şey var: Yük Balansatorunu qızdırmaq lazımdır və ya əvvəlcədən sorğu yazmaq lazımdır ki, “uşaqlar, biz trafik alacağıq, bizim üçün Load Balancer-i qızdırın!” Bu nüansları bilmək lazımdır.
Bu sahədə ixtisaslaşan insanlara müraciət etdikdə, demək olar ki, bütün tipik şeylər bağlanır. İndi bizim 40 mühəndisimiz var, ilin sonuna qədər yəqin ki, 60 nəfər olacaq - biz bütün bunlarla mütləq qarşılaşmışıq. Hansısa layihədə yenidən bu problemlə rastlaşsaq belə, tez bir zamanda bir-birimizdən soruşub, necə həll edəcəyimizi bilirik.
Yəqin ki, cavab budur - əlbəttə ki, ev sahibliyi edən bir hekayə bəzi hissəni asanlaşdırır. Sual budur ki, siz bu hosterlərə etibar etməyə hazırsınızmı və onlar sizin problemlərinizi həll edəcəkmi? Amazon və Google yaxşı iş gördü. Bütün hallarımız üçün - dəqiq. Artıq müsbət təcrübəmiz yoxdur. Üzərində işləməyə çalışdığımız bütün digər buludlar bir çox problem yaradır - Ager və Rusiyada olan hər şey və müxtəlif tətbiqlərdə hər cür OpenStack: Headster, Overage - nə istəsəniz. Onların hamısı sizin həll etmək istəmədiyiniz problemlər yaradır.
Buna görə də, cavab bəli, amma əslində, çoxlu yetkin hosted həllər yoxdur.
Kubernetes kimə lazımdır?
- Bəs Kubernetes kimə lazımdır? Xüsusilə Kubernetes üçün gələn tipik Flaunt müştərisi olan Kubernetes-ə kim artıq keçməlidir?
Dmitri: Bu maraqlı sualdır, çünki hazırda Kubernetesin ardınca bir çox insan bizə müraciət edir: "Uşaqlar, biz bilirik ki, siz Kubernetes edirsiniz, bunu bizim üçün edin!" Biz onlara cavab veririk: "Cənablar, biz Kubernetes etmirik, istehsal edirik və onunla əlaqəli hər şeyi edirik." Çünki bütün CI/CD-ni və bütün bu hekayəni etmədən məhsul hazırlamaq hazırda qeyri-mümkündür. Bizdə inkişafla inkişaf var, sonra istismarla istismar var bölgüsündən hamı uzaqlaşıb.
Müştərilərimiz fərqli şeylər gözləyirlər, lakin hər kəs onların müəyyən problemlərinin olması üçün yaxşı bir möcüzə gözləyir və indi - hop! - Kubernetes onları həll edəcək. İnsanlar möcüzələrə inanırlar. Ağıllarında möcüzə olmayacağını başa düşürlər, amma ruhlarında ümid edirlər - bu Kubernetlər indi bizim üçün hər şeyi həll edərsə, bu barədə çox danışırlar! Birdən o, indi - asqırır! - və gümüş güllə, asqır! — və bizdə 100% iş vaxtı var, bütün tərtibatçılar istehsala daxil olan hər şeyi 50 dəfə buraxa bilər və o, qəzaya uğramır. Ümumiyyətlə, bir möcüzə!
Bizə belə insanlar gələndə deyirik: “Bağışlayın, amma möcüzə deyilən bir şey yoxdur”. Sağlam olmaq üçün yaxşı yemək və idman etmək lazımdır. Etibarlı bir məhsula sahib olmaq üçün onu etibarlı şəkildə hazırlamaq lazımdır. Rahat CI/CD-yə sahib olmaq üçün siz onu belə etmək lazımdır. Bu, görülməli olan çox işdir.
Kubernetes kimə lazımdır sualına cavab vermək - heç kimə Kubernetes lazım deyil.
Bəzi insanlar Kubernetlərə ehtiyac duyduqları barədə yanlış təsəvvürə sahibdirlər. İnsanlara ehtiyac var, onlar düşünməkdən, öyrənməkdən və infrastrukturun bütün problemləri və tətbiqlərini idarə etmək problemləri ilə maraqlanmağı dayandırmaq üçün dərin ehtiyac duyurlar. Onlar proqramların sadəcə işləməsini və sadəcə yerləşdirilməsini istəyirlər. Onlar üçün Kubernetes ümid edir ki, "biz orada yatırdıq" və ya "çıxara bilmirik" və ya başqa bir şey hekayəsini eşitməyi dayandıracaqlar.
Bizə adətən texniki direktor gəlir. Ondan iki şey soruşurlar: bir tərəfdən bizə xüsusiyyətlər verin, digər tərəfdən sabitlik. Bunu özünüzə götürməyi və bunu etməyi təklif edirik. Gümüş güllə, daha doğrusu gümüşlə örtülmüşdür ki, siz bu problemlər haqqında düşünməyi və vaxt itirməyi dayandıracaqsınız. Bu məsələni bağlayan xüsusi adamlarınız olacaq.
Bizim və ya başqasının Kubernetesə ehtiyacı olduğu ifadəsi düzgün deyil.
Adminlərin həqiqətən Kubernetesə ehtiyacı var, çünki bu, çox maraqlı oyuncaqdır ki, onunla oynaya və işləyə bilərsiniz. Dürüst olaq - hər kəs oyuncaqları sevir. Biz hamımız hardasa uşaqıq və yenisini görəndə onu oynamaq istəyirik. Bəziləri üçün, məsələn, administrasiyada buna mane oldular, çünki onlar artıq kifayət qədər oynadılar və sadəcə istəmədikləri nöqtəyə qədər yoruldular. Ancaq bu, heç kimə tamamilə itirilmir. Məsələn, uzun müddətdir ki, sistem idarəçiliyi və DevOps sahəsində oyuncaqlardan bezmişəmsə, hələ də oyuncaqları sevirəm, yenə də yenilərini alıram. Bütün insanlar, bu və ya digər şəkildə, hələ də bir növ oyuncaq istəyirlər.
İstehsalla oynamaq lazım deyil. Etməməyi qəti şəkildə tövsiyə etdiyim və indi kütləvi şəkildə gördüklərim: "Oh, yeni oyuncaq!" - qaçdılar onu almağa, aldılar və: "İndi məktəbə aparaq və bütün dostlarımıza göstərək." Bunu etmə. Üzr istəyirəm, uşaqlarım yenicə böyüyür, uşaqlarda daim nəsə görürəm, özümdə müşahidə edirəm, sonra başqalarına ümumiləşdirirəm.
Son cavab budur: sizə Kubernetes lazım deyil. Problemlərinizi həll etməlisiniz.
Nəyə nail ola bilərsiniz:
- məhsul düşmür;
- yıxılmağa cəhd etsə belə, biz bu haqda əvvəlcədən bilirik və ona nəsə qoya bilərik;
- biz bunu biznesimizin tələb etdiyi sürətlə dəyişə bilərik və biz bunu rahat edə bilərik; bu, bizə heç bir problem yaratmır.
İki real ehtiyac var: etibarlılıq və yayımın dinamikliyi/çevikliyi. Hal-hazırda bir növ İT layihələri ilə məşğul olan, hansı biznes növündən asılı olmayaraq - dünyanı asanlaşdırmaq üçün yumşaq olan və bunu başa düşən hər kəs bu ehtiyacları həll etməlidir. Düzgün yanaşma, düzgün anlayış və kifayət qədər təcrübə ilə Kubernetes onları həll etməyə imkan verir.
Serversiz haqqında
— Gələcəyə bir az da baxsanız, o zaman infrastrukturla baş ağrısının olmaması problemini, yayılma sürəti və tətbiq dəyişikliklərinin sürəti ilə həll etməyə çalışsanız, yeni həllər, məsələn, serversiz görünür. Bu istiqamətdə hər hansı bir potensial və deyək ki, Kubernetes və buna bənzər həllər üçün təhlükə hiss edirsinizmi?
Dmitri: Burada bir daha qeyd etmək lazımdır ki, mən qabağa baxıb deyən görən deyiləm - belə olacaq! Baxmayaraq ki, mən eyni şeyi etmişəm. Mən ayaqlarıma baxıram və orada bir dəstə problem görürəm, məsələn, tranzistorlar kompüterdə necə işləyir. Gülməli, elə deyilmi? CPU-da bəzi səhvlərlə qarşılaşırıq.
Bütün ekosistem məsələlərini həll edərək serversizləri olduqca etibarlı, ucuz, səmərəli və rahat edin. Burada mən Elon Musk ilə razıyam ki, bəşəriyyət üçün qüsurlara dözümlülük yaratmaq üçün ikinci planet lazımdır. Nə dediyini bilməsəm də, başa düşürəm ki, mən özüm Marsa uçmağa hazır deyiləm və sabah da olmayacaq.
Serversiz ilə aydındır ki, bu, bəşəriyyət üçün səhvlərə dözümlülük kimi ideoloji cəhətdən düzgün bir şeydir - iki planetə sahib olmaq birdən yaxşıdır. Amma indi bunu necə etmək olar? Əgər səylərinizi ona cəmləsəniz, bir ekspedisiya göndərmək problem deyil. Bir neçə ekspedisiya göndərmək, bir neçə min adamı ora yerləşdirmək də, məncə, realdır. Amma bəşəriyyətin yarısının orada yaşaması üçün onu tamamilə qüsurlara dözümlü etmək indi mənə mümkünsüz görünür, nəzərə alınmır.
Serversiz tək-tək: hər şey gözəldir, lakin 2019-cu ilin problemlərindən uzaqdır. 2030-a yaxın - gəlin bunu görmək üçün yaşayaq. Şübhə etmirəm ki, yaşayacağıq, mütləq yaşayacağıq (yatmazdan əvvəl təkrarlayın), amma indi başqa problemləri həll etmək lazımdır. Bu, Göy qurşağı nağılındakı poniyə inanmaq kimidir. Bəli, işlərin bir neçə faizi həll olunur və onlar mükəmməl həll olunur, lakin subyektiv olaraq serversiz bir göy qurşağıdır... Mənim üçün bu mövzu çox uzaq və çox anlaşılmazdır. Mən danışmağa hazır deyiləm. 2019-cu ildə serversiz bir proqram yaza bilməzsiniz.
Kubernetes necə inkişaf edəcək
— Bu potensial gözəl uzaq gələcəyə doğru irəlilədikcə, sizcə Kubernetes və onun ətrafındakı ekosistem necə inkişaf edəcək?
Dmitri: Bu barədə çox düşünmüşəm və aydın cavabım var. Birincisi dövlətlidir - axırda vətəndaşsızlıq etmək daha asandır. Kubernetes əvvəlcə buna daha çox sərmayə qoydu, hər şey onunla başladı. Vətəndaşsızlar Kubernetes-də demək olar ki, mükəmməl işləyir, şikayət etmək üçün sadəcə heç nə yoxdur. Hələ bir çox problemlər, daha doğrusu, nüanslar var. Orada hər şey artıq bizim üçün əla işləyir, amma bu, bizik. Bunun hamı üçün işləməsi üçün ən azı bir neçə il lazım olacaq. Bu, hesablanmış göstərici deyil, başımdan gələn hissdir.
Qısacası, statuslu proqram çox güclü inkişaf etməlidir, çünki bizim bütün proqramlarımız statusu saxlayır; vətəndaşlığı olmayan proqramlar yoxdur. Bu bir illüziyadır, sizə həmişə bir növ verilənlər bazası və başqa bir şey lazımdır. Statefull, mümkün olan hər şeyi düzəltmək, bütün səhvləri düzəltmək, hazırda qarşılaşılan bütün problemləri yaxşılaşdırmaqdır - gəlin buna övladlıq deyək.
Naməlumların səviyyəsi, həll edilməmiş problemlərin səviyyəsi, nə iləsə qarşılaşma ehtimalının səviyyəsi xeyli aşağı düşəcək. Bu mühüm hekayədir. Və operatorlar - asan xidmət əldə etmək üçün idarəetmə məntiqinin kodlaşdırılması, idarəetmə məntiqi ilə əlaqəli hər şey: MySQL asan xidməti, RabbitMQ asan xidməti, Memcache asan xidməti - ümumiyyətlə, işləmək üçün zəmanət verməli olduğumuz bütün bu komponentlər. Qutu. Bu, sadəcə verilənlər bazası istədiyimiz ağrıları həll edir, lakin biz onu idarə etmək istəmirik və ya Kubernetes istəyirik, lakin onu idarə etmək istəmirik.
Operatorun bu və ya digər formada inkişafının bu hekayəsi yaxın bir neçə ildə əhəmiyyətli olacaq.
Düşünürəm ki, istifadə rahatlığı çox artmalıdır - qutu getdikcə daha çox qara, getdikcə daha etibarlı, daha çox sadə düymələrlə olacaq.
Bir dəfə Saturday Night Live-da YouTube-da 80-ci illərdən İsaak Asimovla köhnə müsahibəyə qulaq asdım - Urqant kimi bir proqram, yalnız maraqlıdır. Ondan kompüterlərin gələcəyi haqqında soruşdular. Gələcəyin radio kimi sadəlikdə olduğunu söylədi. Radio qəbuledicisi əvvəlcə mürəkkəb bir şey idi. Bir dalğa tutmaq üçün düymələri 15 dəqiqə çevirmək, şişləri çevirmək və ümumiyyətlə hər şeyin necə işlədiyini bilmək, radio dalğasının ötürülməsinin fizikasını başa düşmək lazım idi. Nəticədə radioda yalnız bir düymə qalmışdı.
İndi 2019-cu ildə hansı radio? Avtomobildə radio qəbuledicisi bütün dalğaları və stansiyaların adlarını tapır. Prosesin fizikası 100 il ərzində dəyişməyib, lakin istifadə rahatlığı var. İndi və nəinki indi, artıq 1980-ci ildə Əzimovla müsahibə olanda hamı radiodan istifadə edir və onun necə işlədiyi barədə heç kim fikirləşmirdi. Həmişə işləmişdir - bu, verilmişdir.
Əzimov sonra dedi ki, kompüterlərdə də belə olacaq - istifadə rahatlığı artacaq. 1980-ci ildə kompüterdə düymələri basmaq üçün təlim keçməli olduğunuz halda, gələcəkdə belə olmayacaq.
Mənə elə gəlir ki, Kubernetes və infrastruktur ilə istifadə rahatlığında da böyük artım olacaq. Bu, mənim fikrimcə, göz qabağındadır - səthdə yatır.
Mühəndislərlə nə etmək lazımdır?
— Bəs Kubernetes-i dəstəkləyən mühəndislər və sistem administratorları nə edəcək?
Dmitri: 1C-nin gəlişindən sonra mühasiblə nə oldu? Təxminən eyni. Bundan əvvəl onlar kağız üzərində hesab edirdilər - indi proqramda. Əmək məhsuldarlığı böyük ölçüdə artdı, amma əməyin özü itmədi. Əgər əvvəllər bir lampanı vidalamaq üçün 10 mühəndis lazım idisə, indi biri kifayət edəcək.
Proqram təminatının miqdarı və tapşırıqların sayı, mənə elə gəlir ki, indi yeni DevOps-ların göründüyündən daha sürətli sürətlə artır və səmərəlilik artır. Hazırda bazarda spesifik çatışmazlıq var və bu, uzun müddət davam edəcək. Daha sonra hər şey bir növ normal vəziyyətə qayıdacaq, burada işin səmərəliliyi artacaq, getdikcə daha çox serversiz olacaq, Kubernetes-ə bir neyron qoşulacaq, bütün resursları tam olaraq lazım olduğu kimi seçəcək və ümumiyyətlə lazım olduğu kimi hər şeyi özü edin - adam sadəcə uzaqlaşın və qarışmayın.
Ancaq yenə də kimsə qərar verməli olacaq. Aydındır ki, bu şəxsin ixtisas və ixtisas səviyyəsi daha yüksəkdir. İndiki vaxtda mühasibatlıqda 10 nəfər dəftər tutan işçiyə ehtiyac yoxdur ki, əlləri yorulmasın. Bu sadəcə lazım deyil. Bir çox sənədlər elektron sənəd dövriyyəsi sistemi tərəfindən avtomatik skan edilir və tanınır. Bir ağıllı baş mühasib kifayətdir, onsuz da daha böyük bacarıqlara malik, yaxşı başa düşülən.
Ümumiyyətlə, bütün sənaye sahələrində bu cür getmək lazımdır. Maşınlarla da eynidir: əvvəllər bir maşın mexanik və üç sürücü ilə gəlirdi. İndiki vaxtda avtomobil idarə etmək hamımızın hər gün iştirak etdiyi sadə bir prosesdir. Heç kim avtomobilin mürəkkəb bir şey olduğunu düşünmür.
DevOps və ya sistem mühəndisliyi getməyəcək - yüksək səviyyəli iş və səmərəlilik artacaq.
— İşin əslində artacağı ilə bağlı maraqlı fikir də eşitdim.
Dmitri: Əlbəttə, yüz faiz! Çünki yazdığımız proqram təminatının həcmi durmadan artır. Proqram təminatı ilə həll etdiyimiz məsələlərin sayı durmadan artır. Görülən işlərin həcmi artır. İndi DevOps bazarı çox qızdırılıb. Bunu maaş gözləntilərində də görmək olar. Yaxşı mənada, təfərrüata varmadan, X istəyən kiçiklər, 1,5X istəyən ortalar və 2X istəyən yaşlılar olmalıdır. İndi, Moskva DevOps əmək haqqı bazarına baxsanız, kiçik bir şagird X-dən 3X-ə qədər, bir böyük isə X-dən 3X-ə qədər istəyir.
Bunun nə qədər başa gəldiyini heç kim bilmir. Maaş səviyyəsi sizin inamınızla ölçülür - tam dəlixana, düzünü desəm, dəhşətli dərəcədə qızmış bazar.
Əlbəttə ki, bu vəziyyət çox tezliklə dəyişəcək - bəzi doyma baş verməlidir. Proqram təminatının hazırlanması ilə bağlı vəziyyət belə deyil - hər kəsin tərtibatçılara ehtiyacı olmasına və hər kəsin yaxşı tərtibatçılara ehtiyacı olmasına baxmayaraq, bazar kimin nəyə dəyər olduğunu başa düşür - sənaye yerində oturub. Bu günlərdə DevOps ilə vəziyyət belə deyil.
— Eşitdiyimdən belə nəticəyə gəldim ki, indiki sistem inzibatçısı çox narahat olmamalıdır, lakin artıq öz bacarıqlarını təkmilləşdirməyin və sabah daha çox iş olacağına, lakin daha yüksək ixtisaslı olacağına hazırlaşmağın vaxtıdır.
Dmitri: Yüz faiz. Ümumiyyətlə, 2019-cu ildə yaşayırıq və həyatın qaydası belədir: ömür boyu öyrənmə - biz həyatımızda öyrənirik. Mənə elə gəlir ki, indi hər kəs bunu bilir və hiss edir, amma bilmək kifayət deyil - bunu etməlisən. Hər gün dəyişməliyik. Bunu etməsək, gec-tez peşənin qırağına düşəcəyik.
180 dərəcə kəskin dönüşlərə hazır olun. Nəyinsə köklü şəkildə dəyişdiyi, yeni bir şeyin icad edildiyi vəziyyəti istisna etmirəm - olur. Hop! - və biz indi fərqli davranırıq. Buna hazır olmaq və narahat olmamaq vacibdir. Elə ola bilər ki, sabah etdiyim hər şey lazımsız olacaq - heç nə, mən bütün ömrüm boyu oxumuşam və başqa bir şey öyrənməyə hazıram. Problem deyil. İş təhlükəsizliyindən qorxmağa ehtiyac yoxdur, ancaq daim yeni bir şey öyrənməyə hazır olmalısınız.
Arzular və bir dəqiqəlik reklam
- İstəyiniz varmı?
Dmitri: Bəli, mənim bir neçə arzum var.
Birinci və ticarət - abunə olun . Əziz oxucular, YouTube-a daxil olun və kanalımıza abunə olun. Təxminən bir ay ərzində biz video xidmətinin aktiv genişləndirilməsinə başlayacağıq. Kubernetes haqqında açıq və müxtəlif olan çoxlu təhsil məzmunumuz olacaq: praktiki şeylərdən tutmuş laboratoriyalara, dərin fundamental nəzəri şeylərə və Kubernetes-dən necə istifadə ediləcəyinə qədər. prinsiplər və nümunələr səviyyəsi.
İkinci ticarət arzusu - gedin və ulduzları qoyduq, çünki biz onlardan qidalanırıq. Bizə ulduz verməsən, yeməyə heç nəyimiz olmayacaq. Bu, kompüter oyunundakı manaya bənzəyir. Biz bir şey edirik, edirik, çalışırıq, kimsə deyir ki, bunlar dəhşətli velosipedlərdir, kimsə hər şeyin tamamilə səhv olduğunu söyləyir, amma davam edirik və tamamilə vicdanla hərəkət edirik. Biz problem görürük, həll edirik və təcrübəmizi paylaşırıq. Buna görə də bizə bir ulduz verin, o sizdən uzaqlaşmayacaq, ancaq bizə gələcək, çünki biz onlardan qidalanırıq.
Üçüncüsü, vacib və artıq ticari olmayan arzu - nağıllara inanmağı dayandırın. Siz peşəkarsınız. DevOps çox ciddi və məsuliyyətli bir peşədir. İş yerində oynamağı dayandırın. Qoy sizin üçün klikləyin və siz bunu başa düşəcəksiniz. Təsəvvür edin ki, xəstəxanaya gəlirsiniz və orada həkim sizin üzərinizdə təcrübə aparır. Başa düşürəm ki, bu, kimisə təhqir edə bilər, amma çox güman ki, bu sizin haqqınızda deyil, başqası haqqındadır. Başqalarına da deyin ki, dayansınlar. Bu, həqiqətən hamımız üçün həyatı məhv edir - bir çoxları əməliyyatlara, adminlərə və DevOps-a yenidən nəyisə sındırmış dostlar kimi yanaşmağa başlayır. Bu, ən çox oynamağa getməyimizdən, soyuq şüurla baxmamağımızdan belə “qırılırdı” ki, belədir, belədir.
Bu, sınaq keçirməməli olduğunuz demək deyil. Təcrübə etməliyik, bunu özümüz edirik. Düzünü desəm, özümüz də bəzən oyun oynayırıq - bu, əlbəttə ki, çox pisdir, amma insanlıq bizə yad deyil. Gəlin 2019-cu ili istehsalda oyunlar deyil, ciddi, düşünülmüş eksperimentlər ili elan edək. Yəqin ki, belədir.
- Çox sağ olun!
Dmitri: Vitali, həm vaxt ayırdığınız, həm də müsahibə üçün təşəkkür edirəm. Hörmətli oxucular, birdən-birə bu həddə çatmısınızsa, çox sağ olun. Ümid edirəm ki, sizə ən azı bir neçə fikir gətirdik.
Müsahibədə Dmitri werf məsələsinə toxunub. İndi bu, demək olar ki, bütün problemləri həll edən universal bir İsveçrə bıçağıdır. Amma həmişə belə olmayıb. Aktiv festivalda Dmitri Stolyarov sizə bu alət haqqında ətraflı məlumat verəcəkdir. hesabatda hər şey olacaq: problemlər və Kubernetesin gizli nüansları, bu çətinliklərin həlli variantları və werf-in cari tətbiqi ətraflı. 27 və 28 May tarixlərində bizə qoşulun, mükəmməl alətlər yaradaq.
Mənbə: www.habr.com