Mənim adım Viktor Yaqofarovdur və mən əməliyyatlar (əməliyyatlar) komandasında texniki inkişaf meneceri kimi DomClick-də Kubernetes platformasını inkişaf etdirirəm. Mən sizə Dev <-> Ops proseslərimizin strukturu, Rusiyadakı ən böyük k8s klasterlərindən birinin işləmə xüsusiyyətləri, həmçinin komandamızın istifadə etdiyi DevOps / SRE təcrübələri haqqında məlumat vermək istərdim.
Komanda əməliyyatları
Əməliyyat komandasında hazırda 15 nəfər var. Onlardan üçü ofisə cavabdehdir, ikisi fərqli vaxt zonasında işləyir və gecə də daxil olmaqla mövcuddur. Beləliklə, Ops-dan kimsə həmişə monitordadır və istənilən mürəkkəblik hadisəsinə cavab verməyə hazırdır. Mentalitetimizi qoruyub saxlayan və hər kəsə kifayət qədər yatmaq və asudə vaxtını təkcə kompüterdə keçirməmək imkanı verən gecə növbəmiz yoxdur.
Hər kəsin müxtəlif səriştələri var: şəbəkəçilər, DBA-lar, ELK stek mütəxəssisləri, Kubernetes administratorları / tərtibatçıları, monitorinq, virtuallaşdırma, aparat mütəxəssisləri və s. Hamını bir şey birləşdirir - hər kəs bizi müəyyən dərəcədə əvəz edə bilər: məsələn, k8s klasterinə yeni qovşaqlar təqdim edin, PostgreSQL-i yeniləyin, CI / CD + Ansible boru xətti yazın, Python / Bash / Go-da nəyisə avtomatlaşdırın, bir parça birləşdirin DPC-yə aparat. Hər hansı bir sahədə güclü səriştələr fəaliyyət istiqamətini dəyişdirməyə və başqa bir sahədə pompalanmağa başlamağa mane olmur. Məsələn, mən bir şirkətdə PostgreSQL mütəxəssisi kimi işə düzəldim və indi mənim əsas məsuliyyət sahəsim Kubernetes klasterləridir. Komandada hər hansı bir böyümə yalnız xoş qarşılanır və çiyin hissi çox inkişaf etmişdir.
Yeri gəlmişkən, biz ov edirik. Namizədlər üçün tələblər olduqca standartdır. Şəxsən mənim üçün insanın komandaya uyğunlaşması, qarşıdurma olmaması, eyni zamanda öz nöqteyi-nəzərini necə müdafiə etməyi bilməsi, inkişaf etmək istəməsi və yeni nəsə etməkdən, ideyalarını təklif etməkdən çəkinməməsi vacibdir. Həmçinin skript dillərində proqramlaşdırma bacarıqları, Linux və ingilis dilinin əsaslarını bilmək tələb olunur. İngilis dili ona görə lazımdır ki, fakap halında olan şəxs problemin həllini 10 dəqiqəyə yox, 10 saniyəyə google-da axtara bilsin. Linux-u dərindən bilən mütəxəssislərlə indi çox çətindir: gülməli, lakin hər üç namizəddən ikisi “Orta Yük nədir? Bu nədən ibarətdir? ”, Və“ Sish proqramından əsas zibil toplamaq ”sualı fövqəlbəşər dünyasından ... və ya dinozavrlardan bir şey hesab olunur. Biz buna dözməliyik, çünki adətən insanlar yüksək dərəcədə inkişaf etmiş digər bacarıqlara malikdirlər və biz Linuxu öyrədəcəyik. "Müasir buludlar dünyasında nə üçün bir DevOps mühəndisi bütün bunları bilməlidir" sualının cavabı məqalənin əhatə dairəsindən kənarda qalmalı olacaq, ancaq üç sözlə: bütün bunlar lazımdır.
Alətlər əmri
Alətlər komandası avtomatlaşdırmada mühüm rol oynayır. Onların əsas vəzifəsi tərtibatçılar üçün rahat qrafik və CLI alətləri yaratmaqdır. Məsələn, Confer-in daxili inkişafı sizə bir neçə siçan klikləməklə bir tətbiqi Kubernetes-ə yaymağa, onun resurslarını, kassadan açarları konfiqurasiya etməyə və s. imkan verir. Əvvəllər Jenkins + Helm 2 var idi, amma kopyala-yapışdırmağı aradan qaldırmaq və proqram təminatının həyat dövrünə vahidlik gətirmək üçün öz alətimi inkişaf etdirməli oldum.
Əməliyyat qrupu tərtibatçılar üçün boru kəmərləri yazmır, lakin onları yazarkən hər hansı bir problemlə bağlı məsləhət verə bilər (bəzilərində hələ də Helm 3 var).
DevOps
DevOps-a gəldikdə, biz bunu belə görürük:
Dev komandaları kod yazır, onu Devlə Konfrans -> qa/stage -> prod vasitəsilə yayır. Kodun yavaşlamamasını və səhvlər atmamasını təmin etmək Dev və Ops komandalarının məsuliyyətidir. Gündüz əməliyyat qrupunun növbətçisi öz ərizəsi ilə bir hadisəyə cavab verməlidir və axşam və gecə növbətçi admin (Ops) problemin olmadığını dəqiq bilirsə növbətçi tərtibatçını oyatmalıdır. infrastrukturda. Monitorinqdəki bütün ölçülər və xəbərdarlıqlar avtomatik və ya yarı avtomatik olaraq görünür.
Ops-un məsuliyyət sahəsi tətbiqin istehsala keçdiyi andan başlayır, lakin Dev-in məsuliyyəti bununla bitmir - biz bir şey edirik və eyni gəmidəyik.
Tərtibatçılar adminlərə admin mikroservisinin (məsələn, Go backend + HTML5) yazılmasında köməyə ehtiyacı olduqda məsləhət görür və adminlər hər hansı infrastruktur və ya k8s ilə bağlı məsələlərdə tərtibatçılara məsləhət görürlər.
Yeri gəlmişkən, bizdə ümumiyyətlə monolit yoxdur, yalnız mikroservislər var. Onların sayı bu günə qədər məhsul k900s klasterində 1000 ilə 8 arasında dəyişir. yerləşdirmələr. Qabıqların sayı 1700 ilə 2000 arasında dəyişir. İstehsal klasterindəki qabıqlar hazırda 2000-ə yaxındır.
Dəqiq rəqəmlər deyə bilmərəm, çünki lazımsız mikroxidmətlərə nəzarət edirik və onları yarı avtomatik rejimdə kəsirik. k8s-də lazımsız obyektləri izləmək bizə kömək edir resurslara və pula qənaət edir.
Resursların idarə edilməsi
Monitorinq
Bacarıqlı qurulmuş və informativ monitorinq böyük klasterin fəaliyyətində təməl daşı olur. Biz hələ ki, bütün monitorinq ehtiyaclarının 100%-ni əhatə edəcək universal həll tapmamışıq, ona görə də bu mühitdə vaxtaşırı müxtəlif fərdi həlləri birləşdiririk.
- Zabbix. Yaxşı köhnə monitorinq, ilk növbədə infrastrukturun ümumi vəziyyətini izləmək üçün nəzərdə tutulmuşdur. Bir node prosessor, yaddaş, disklər, şəbəkə və s. tərəfindən öldüyü zaman bizə məlumat verir. Fövqəltəbii heç nə yoxdur, amma bizdə ayrıca DaemonSet agentləri də var, onların köməyi ilə, məsələn, klasterdə DNS vəziyyətinə nəzarət edirik: axmaq koredns podlarını axtarırıq, xarici hostların mövcudluğunu yoxlayırıq. Görünür ki, bunun üçün niyə narahat olun, amma böyük həcmdə trafikdə bu komponent ciddi bir uğursuzluq nöqtəsidir. Əvvəllər məndə var klasterdə DNS performansı ilə necə mübarizə apardı.
- Prometey operatoru. Müxtəlif ixracatçılar dəsti bütün klaster komponentləri haqqında geniş məlumat verir. Sonra, biz bütün bunları Grafana-da böyük panellərdə vizuallaşdırırıq və bildirişlər üçün alertmanagerdən istifadə edirik.
Bizim üçün başqa bir faydalı vasitədir . Biz bunu bir neçə dəfə bir komandanın başqa bir komandanın girişini yolları ilə üst-üstə düşdüyü və 50x səhvə səbəb olan vəziyyətlə qarşılaşdıqdan sonra yazdıq. İndi, istehsala yerləşdirməzdən əvvəl tərtibatçılar heç kimə zərər verməyəcəyini yoxlayır və mənim komandam üçün bu, Ingresses ilə bağlı problemlərin ilkin diaqnozu üçün yaxşı bir vasitədir. Gülməli odur ki, əvvəlcə bu adminlər üçün yazılmışdı və olduqca “yöndərsiz” görünürdü, lakin inkişaf komandaları alətə aşiq olduqdan sonra o, çox dəyişdi və “admin adminlər üçün veb siması etdi” kimi görünməyə başladı. . Tezliklə biz bu alətdən imtina edəcəyik və belə hallar boru kəməri işə salınmazdan əvvəl də təsdiqlənəcək.
"Kub"da komanda resursları
Nümunələrə davam etməzdən əvvəl, resurs ayırmağımızın necə olduğunu izah etməyə dəyər mikroservislər.
Hansı komandaların və hansı miqdarda istifadə etdiyini başa düşmək ресурсы (prosessor, yaddaş, yerli SSD), özümüz ayırırıq ad sahəsi "Cube" və daha əvvəl komandaların ehtiyaclarını müzakirə edərək, prosessor, yaddaş və disk baxımından onun maksimum imkanlarını məhdudlaşdırın. Müvafiq olaraq, bir əmr, ümumi halda, minlərlə nüvə və terabayt yaddaş ayıraraq, yerləşdirmə üçün bütün klasteri bloklamayacaq. Ad sahəsinə girişlər AD vasitəsilə verilir (biz RBAC-dan istifadə edirik). Ad məkanları və onların məhdudiyyətləri GIT deposuna çəkmə sorğusu vasitəsilə əlavə edilir və sonra hər şey avtomatik olaraq Ansible boru kəməri vasitəsilə yayılır.
Komanda başına resurs bölgüsü nümunəsi:
namespaces:
chat-team:
pods: 23
limits:
cpu: 11
memory: 20Gi
requests:
cpu: 11
memory: 20Gi
İstəklər və məhdudiyyətlər
kub" tələb altında zəmanətli ehtiyat ehtiyatlarının sayıdır ləpələmək klasterdə (bir və ya daha çox doker konteyneri). Limit zəmanət verilməyən maksimumdur. Siz tez-tez qrafiklərdə görə bilərsiniz ki, bəzi komandalar özünün bütün tətbiqləri üçün həddən artıq çox sorğu təyin edib və tətbiqi "Kub"a yerləşdirə bilmir, çünki onların ad məkanı altında bütün sorğular artıq "xərclənib".
Bu vəziyyətdən düzgün çıxış yolu faktiki resurs istehlakına baxmaq və onu tələb olunan məbləğlə müqayisə etməkdir (Sorğu).
Yuxarıdakı ekran görüntüləri göstərir ki, "tələb edilən" (Tələb olunan) CPU-lar real mövzu sayına görə seçilib və Limitlər CPU iplərinin real sayını keçə bilər =)
İndi bəzi ad sahəsinə daha yaxından nəzər salaq (mən kube sistemi ad sahəsini seçdim - "Kub"un özünün komponentləri üçün sistem ad sahəsi) və faktiki istifadə olunan prosessor vaxtının və yaddaşın tələb olunana nisbətinə baxaq:
Aydındır ki, sistem xidmətləri üçün faktiki istifadə ediləndən daha çox yaddaş və CPU ayrılıb. Kube-sisteminə gəldikdə, bu haqlıdır: nginx giriş nəzarətçisi və ya nodelocaldns zirvədə CPU-da dayandı və çoxlu RAM yedi, buna görə də burada belə bir marja əsaslandırıldı. Bundan əlavə, biz son 3 saat ərzində qrafiklərə etibar edə bilmərik: tarixi ölçüləri uzun müddət ərzində görmək arzuolunandır.
“Tövsiyələr” sistemi işlənib hazırlanmışdır. Məsələn, burada siz hansı resursların "məhdudiyyətləri" (yuxarı icazə verilən zolağı) yüksəltməyin daha yaxşı olacağını görə bilərsiniz ki, "boşaltma" baş verməsin: podun ayrılmış vaxt kvantına CPU və ya yaddaş sərf etdiyi an. və onun "donmamış" olmasını gözləyir:
Və iştahalarını tənzimləməli olan qablar bunlardır:
haqqında tənzimləmə + monitorinq resursları, birdən çox məqalə yaza bilərsiniz, buna görə şərhlərdə suallar verin. Bir neçə sözlə deyə bilərəm ki, bu cür ölçülərin avtomatlaşdırılması işi çox çətindir və çox vaxt tələb edir və "pəncərə" funksiyaları və "CTE" Prometheus / VictoriaMetrics ilə balanslaşdırma aktı (bu terminlər dırnaq içərisindədir, çünki orada PromQL-də buna bənzər demək olar ki, heç bir şey yoxdur və siz mətnin bir neçə ekranında qorxulu sorğuların qarşısını almaq və onları optimallaşdırmaq məcburiyyətindəsiniz).
Nəticədə tərtibatçıların "Kub"da öz ad məkanlarına nəzarət etmək üçün alətləri var və onlar harada və hansı vaxtda hansı proqramların resursları "kəsəcəyini" və hansı podlara bütün gecə CPU-ya verilə biləcəyini seçə bilirlər.
Metodologiyalar
İndiki kimi şirkətdə dəbli, biz DevOps-a riayət edirik- və SRE- praktikant Bir şirkətdə 1000 mikroservis, 350-yə yaxın tərtibatçı və bütün infrastruktur üçün 15 admin olduqda, siz “dəbli” olmalısınız: bütün bu “buzzwords”un arxasında hər şeyi və hər şeyi avtomatlaşdırmağa təcili ehtiyac var və adminlər darboğaz olmamalıdır. proseslərdə.
Ops olaraq biz xidmətin cavab sürəti və xidmət xətaları ilə bağlı tərtibatçılar üçün müxtəlif ölçülər və idarə panelləri təqdim edirik.
kimi metodologiyalardan istifadə edirik: , и onları birləşdirərək. Biz tablosunun sayını minimuma endirməyə çalışırıq ki, bir baxışda hansı xidmətin hazırda deqradasiyaya uğradığı aydın olsun (məsələn, saniyədə cavab kodları, 99-cu faizdə cavab müddəti) və s. Ümumi panellər üçün bəzi yeni ölçülərə ehtiyac yaranan kimi dərhal onları çəkirik və əlavə edirik.
Artıq bir aydır ki, qrafika çəkmirəm. Bu, yəqin ki, yaxşı əlamətdir: bu, "istəklərin" əksəriyyətinin artıq həyata keçirildiyini göstərir. Elə oldu ki, bir həftə ərzində gündə ən azı bir dəfə yeni qrafik çəkdim.
Nəticə qiymətlidir ki, indi tərtibatçılar nadir hallarda adminlərə “bir növ ölçüləri harada görmək olar” sualları ilə müraciət edirlər.
İcra Xidmət Mesh az qala yaxındadır və hər kəs üçün həyatı asanlaşdırmalıdır, Tools-dan olan həmkarlar artıq mücərrəd “Sağlam insanın İstismarını” həyata keçirməyə yaxındırlar: hər HTTP(lər) sorğusunun həyat dövrü monitorinqdə görünəcək və xidmətlərarası (və təkcə deyil) qarşılıqlı əlaqədə "hər şeyin hansı mərhələdə pozulduğunu" başa düşmək həmişə mümkün olacaq. DomClick mərkəzindən xəbərlərə abunə olun. =)
Kubernetes infrastruktur dəstəyi
Tarixən biz yamaqlanmış versiyadan istifadə edirik Kubespray - Kubernetes-in yerləşdirilməsi, genişləndirilməsi və yenilənməsi üçün məsuliyyətli rol. Bir nöqtədə, qeyri-kubeadm quraşdırmalar üçün dəstək əsas filialdan kəsildi və kubeadm-ə keçid prosesi təklif edilmədi. Nəticədə Southbridge öz çəngəlini yaratdı (kubeadm dəstəyi və kritik məsələlərin tez həlli ilə).
Bütün k8s klasterləri üçün təkmilləşdirmə prosesi belə görünür:
- Alın Kubespray Southbridge-dən, merjim filialımızla yoxlayın.
- Yeniləmənin yayılması Vurğulamaq- "Kub".
- Yeniləməni hər dəfə bir qovşağı yayırıq (Ansible-da bu "seriya: 1"dir) dev- "Kub".
- Yenilənir Prod şənbə axşamı, bir anda bir node.
Gələcəkdə dəyişdirilməsi planları var Kubespray daha sürətli bir şeyə və gedin kubeadm.
Ümumilikdə üç "Kub"umuz var: Stress, Dev və Prod. Başqasını işə salmağı planlaşdırırıqisti gözləmə rejimi) Prod- ikinci məlumat mərkəzində "Kub". Vurğulamaq и dev virtual maşınlarda yaşayır (Stress üçün oVirt və Dev üçün VMWare bulud). Prod- "Kub" "çılpaq metal" (çılpaq metal) üzərində yaşayır: bunlar 32 CPU ipi, 64-128 GB yaddaş və 300 GB SSD RAID 10 olan eyni qovşaqlardır - cəmi 50 ədəd var. Üç "nazik" qovşaq "ustalara" həsr edilmişdir Prod- "Kuba": 16 GB yaddaş, 12 CPU ipi.
Satış üçün "çılpaq metal" istifadə etməyə və kimi lazımsız təbəqələrdən qaçmağa üstünlük veririk OpenStack: bizə "səs-küylü qonşular" və CPU lazım deyil vaxt oğurlamaq. Daxili OpenStack vəziyyətində idarəetmənin mürəkkəbliyi təxminən yarıya qədər artır.
CI/CD Cubic və digər infrastruktur komponentləri üçün biz ayrıca GIT serverindən Helm 3 istifadə edirik. atom), Jenkins, Ansible və Docker. Biz xüsusiyyət filiallarını sevirik və eyni depodan fərqli mühitlərə yerləşdiririk.
Nəticə
Ümumiyyətlə, DomClick-də DevOps prosesi əməliyyat mühəndisi tərəfindən belə görünür. Məqalə gözlədiyimdən daha az texniki oldu: buna görə də Habré-də DomClick xəbərlərini izləyin: Kubernetes və daha çox haqqında daha çox "hardkor" məqalələr olacaq.
Mənbə: www.habr.com