Mening ismim Viktor Yagofarov va men Ops (operatsiya) jamoasida texnik rivojlanish menejeri sifatida DomClick-da Kubernetes platformasini ishlab chiqyapman. Men Dev <-> Ops jarayonlarimizning tuzilishi, Rossiyadagi eng yirik k8s klasterlaridan birini ishlatish xususiyatlari, shuningdek, jamoamiz qo'llaydigan DevOps/SRE amaliyotlari haqida gapirmoqchiman.
Operatsiyalar jamoasi
Operatsiyalar jamoasi hozirda 15 kishidan iborat. Ulardan uchtasi ofis uchun mas'uldir, ikkitasi boshqa vaqt zonasida ishlaydi va tunda ham mavjud. Shunday qilib, Opsdan kimdir doimo monitorda va har qanday murakkablikdagi hodisaga javob berishga tayyor. Bizda tungi smenalar yo'q, bu bizning ruhiyatimizni saqlaydi va har kimga etarli darajada uxlash va bo'sh vaqtini nafaqat kompyuterda o'tkazish imkoniyatini beradi.
Har bir inson turli xil vakolatlarga ega: tarmoq bo'yicha mutaxassislar, DBA'lar, ELK stek bo'yicha mutaxassislar, Kubernetes administratorlari/ishlab chiquvchilari, monitoring, virtualizatsiya, apparat mutaxassislari va boshqalar. Hammani bir narsa birlashtiradi - har kim ma'lum darajada har birimizni almashtirishi mumkin: masalan, k8s klasteriga yangi tugunlarni kiritish, PostgreSQL-ni yangilash, CI/CD + Ansible quvur liniyasini yozish, Python/Bash/Go-da biror narsani avtomatlashtirish, uskunani Ma'lumotlar markazi. Har qanday sohada kuchli kompetentsiyalar faoliyat yo'nalishini o'zgartirishga va boshqa sohada yaxshilanishga to'sqinlik qilmaydi. Misol uchun, men kompaniyaga PostgreSQL mutaxassisi sifatida qo'shildim va endi mening asosiy mas'uliyat soham - Kubernetes klasterlari. Jamoada har qanday balandlik mamnuniyat bilan qabul qilinadi va leveraj hissi juda rivojlangan.
Aytgancha, biz ov qilyapmiz. Nomzodlarga qo'yiladigan talablar juda standartdir. Shaxsan men uchun insonning jamoaga mos kelishi, ziddiyatsiz bo‘lishi, shuningdek, o‘z nuqtai nazarini qanday himoya qilishni bilishi, rivojlanishni xohlashi va yangi narsa qilishdan qo‘rqmasligi, o‘z g‘oyalarini taklif qilishi muhim. Shuningdek, skript tillarida dasturlash qobiliyatlari, Linux va ingliz tili asoslarini bilish talab etiladi. Ingliz tili shunchaki kerak, shunda odam fakap holatida muammoning yechimini 10 daqiqada emas, balki 10 soniyada google orqali qidirishi mumkin. Endi Linuxni chuqur biladigan mutaxassislarni topish juda qiyin: bu kulgili, lekin har uch nomzoddan ikkitasi “O'rtacha yuklanish nima? U nimadan yasalgan?", va "C dasturidan asosiy axlatni qanday yig'ish kerak" degan savol supermenlar olamidan ... yoki dinozavrlardan bir narsa deb hisoblanadi. Biz bunga chidashimiz kerak, chunki odatda odamlarda boshqa kompetentsiyalar yuqori darajada rivojlangan, ammo biz Linuxni o'rgatamiz. "Nega zamonaviy bulutlar dunyosida DevOps muhandisi bularning barchasini bilishi kerak" degan savolga javobni maqola doirasidan tashqarida qoldirish kerak, ammo uchta so'z bilan: bularning barchasi zarur.
Jamoa vositalari
Asboblar jamoasi avtomatlashtirishda muhim rol o'ynaydi. Ularning asosiy vazifasi ishlab chiquvchilar uchun qulay grafik va CLI vositalarini yaratishdir. Masalan, bizning ichki rivojlanish konferentsiyasi sizga sichqonchani bir necha marta bosish bilan dasturni Kubernetes-ga tom ma'noda chiqarish, uning resurslarini, kassa kalitlarini sozlash imkonini beradi. Ilgari Jenkins + Helm 2 bor edi, lekin men nusxa ko'chirishni yo'q qilish va dasturiy ta'minotning hayot aylanishiga bir xillik kiritish uchun o'z vositamni ishlab chiqishim kerak edi.
Operatsiyalar jamoasi ishlab chiquvchilar uchun quvurlar yozmaydi, lekin ularning yozishlaridagi har qanday masalalar bo'yicha maslahat berishi mumkin (ba'zi odamlar hali ham Helm 3-ga ega).
DevOps
DevOps-ga kelsak, biz buni shunday ko'ramiz:
Dev guruhlari kod yozadilar, uni Dev to'g'risida konferentsiya -> qa/stage -> prod orqali tarqatadilar. Kod sekinlashmasligi va xatolarga yo'l qo'ymasligi uchun javobgarlik Dev va Ops guruhlariga yuklanadi. Kunduzi Ops guruhining navbatchisi, birinchi navbatda, voqeaga o'z arizasi bilan javob berishi kerak, va kechqurun va tunda navbatchi ma'mur (Ops) agar u bilsa, navbatchi ishlab chiqaruvchini uyg'otishi kerak. muammo infratuzilmada emasligiga ishonch hosil qiling. Monitoringdagi barcha ko'rsatkichlar va ogohlantirishlar avtomatik yoki yarim avtomatik ravishda paydo bo'ladi.
Opsning mas'uliyat sohasi dastur ishlab chiqarishga chiqarilgan paytdan boshlanadi, ammo Devning mas'uliyati shu bilan tugamaydi - biz xuddi shu narsani qilamiz va bitta qayiqdamiz.
Dasturchilar administratorlarga administrator mikroxizmatini yozishda yordam kerak bo'lsa (masalan, Go backend + HTML5) maslahat beradi va administratorlar dasturchilarga har qanday infratuzilma muammolari yoki k8s bilan bog'liq masalalar bo'yicha maslahat beradilar.
Aytgancha, bizda umuman monolit yo'q, faqat mikroservislar. Ularning soni hozirgacha k900s prod klasterida 1000 dan 8 gacha o'zgarib turadi, agar raqam bilan o'lchansa. joylashtirishlar. Koʻsaklar soni 1700 dan 2000 gacha oʻzgarib turadi. Hozirda mahsulot klasterida 2000 ga yaqin koʻsak bor.
Men aniq raqamlarni ayta olmayman, chunki biz keraksiz mikroservislarni kuzatamiz va ularni yarim avtomatik ravishda kesib tashlaymiz. K8s bizga keraksiz ob'ektlarni kuzatishda yordam beradi , bu juda ko'p resurslar va pulni tejaydi.
Resurslarni boshqarish
Monitoring
Yaxshi tuzilgan va informatsion monitoring yirik klaster faoliyatining asosiga aylanadi. Biz hali barcha monitoring ehtiyojlarining 100% ni qoplaydigan universal yechim topmadik, shuning uchun biz vaqti-vaqti bilan ushbu muhitda turli xil maxsus echimlarni yaratamiz.
- Zabbix. Yaxshi eski monitoring, bu birinchi navbatda infratuzilmaning umumiy holatini kuzatish uchun mo'ljallangan. Bu bizga tugunning qayta ishlash, xotira, disklar, tarmoq va boshqalar nuqtai nazaridan o'lishi haqida xabar beradi. Hech qanday g'ayritabiiy narsa yo'q, lekin bizda alohida DaemonSet agentlari mavjud, ular yordamida, masalan, klasterdagi DNS holatini kuzatamiz: biz ahmoq koredns podslarini qidiramiz, tashqi xostlar mavjudligini tekshiramiz. Ko'rinishidan, nima uchun bu bilan bezovtalanasiz, lekin katta hajmdagi trafik bilan ushbu komponent jiddiy nosozlik nuqtasidir. Men allaqachon , klasterda DNS ishlashi bilan qanday kurashganim.
- Prometey operatori. Turli eksportchilar to'plami klasterning barcha tarkibiy qismlari haqida keng ma'lumot beradi. Keyinchalik, bularning barchasini Grafana'dagi katta asboblar panelida tasvirlaymiz va ogohlantirishlar uchun alertmanagerdan foydalanamiz.
Biz uchun yana bir foydali vosita edi . Biz buni bir necha marta bir jamoa boshqa jamoaning kirish yo‘llarini bir-biriga o‘xshatib qo‘ygan va natijada 50 marta xatolikka yo‘l qo‘ygan vaziyatga duch kelganimizdan keyin yozdik. Endi ishlab chiqarishga joylashtirishdan oldin, ishlab chiquvchilar hech kimga ta'sir qilmasligini tekshiradilar va mening jamoam uchun bu Ingresses bilan bog'liq muammolarni dastlabki tashxislash uchun yaxshi vositadir. Qizig'i shundaki, dastlab u administratorlar uchun yozilgan va u anchagina "qo'pol" ko'rinardi, lekin ishlab chiquvchilar ushbu vositaga oshiq bo'lgach, u juda o'zgarib ketdi va "admin administratorlar uchun veb-sahifa yaratgan" kabi ko'rinmay qoldi. ” Tez orada biz ushbu vositadan voz kechamiz va bunday holatlar quvurni ishga tushirishdan oldin ham tasdiqlanadi.
Kubdagi jamoa resurslari
Misollarga kirishdan oldin, resurslarni qanday taqsimlashimizni tushuntirishga arziydi mikroservislar.
Qaysi jamoalar va qanday miqdorda foydalanishini tushunish resurslar (protsessor, xotira, mahalliy SSD), biz har bir buyruqni o'ziga xos tarzda ajratamiz nom maydoni "Cube" da va protsessor, xotira va disk nuqtai nazaridan uning maksimal imkoniyatlarini cheklab qo'ying, bundan oldin jamoalarning ehtiyojlarini muhokama qiling. Shunga ko'ra, bitta buyruq, umuman olganda, minglab yadro va terabayt xotirani ajratib, joylashtirish uchun butun klasterni bloklamaydi. Nomlar maydoniga kirish AD orqali beriladi (biz RBAC dan foydalanamiz). Nom maydonlari va ularning chegaralari GIT omboriga tortish so'rovi orqali qo'shiladi va keyin hamma narsa avtomatik ravishda Ansible quvur liniyasi orqali chiqariladi.
Jamoaga resurslarni taqsimlashga misol:
namespaces:
chat-team:
pods: 23
limits:
cpu: 11
memory: 20Gi
requests:
cpu: 11
memory: 20Gi
So'rovlar va cheklovlar
kubik" so'rov uchun kafolatlangan zahiralangan resurslar soni pod (bir yoki bir nechta docker konteynerlari) klasterda. Limit kafolatlanmagan maksimaldir. Ba'zi jamoalar o'zining barcha ilovalari uchun juda ko'p so'rovlarni o'rnatganligi va dasturni "Cube" ga joylashtira olmasligini grafiklarda tez-tez ko'rishingiz mumkin, chunki ularning nom maydoni ostidagi barcha so'rovlar allaqachon "sarflangan".
Ushbu vaziyatdan chiqishning to'g'ri yo'li - haqiqiy resurs iste'molini ko'rib chiqish va uni so'ralgan miqdor bilan solishtirish (So'rov).
Yuqoridagi skrinshotlarda siz "So'ralgan" protsessorlar iplarning haqiqiy soniga mos kelishini va chegaralar protsessor iplarining haqiqiy sonidan oshib ketishini ko'rishingiz mumkin =)
Keling, ba'zi nomlar maydonini batafsil ko'rib chiqaylik (men kube tizimi nom maydonini tanladim - "Cube" ning o'zi komponentlari uchun tizim nom maydoni) va amalda ishlatilgan protsessor vaqti va xotirasining so'ralganga nisbatini ko'rib chiqaylik:
Ko'rinib turibdiki, tizim xizmatlari uchun amalda foydalanilganidan ko'ra ko'proq xotira va protsessor ajratilgan. Kube tizimiga kelsak, bu o'zini oqladi: nginx kirish boshqaruvchisi yoki nodelocaldns o'zining eng yuqori cho'qqisida protsessorga urilgan va juda ko'p RAM iste'mol qilgan, shuning uchun bu erda bunday zaxira oqlanadi. Bundan tashqari, biz oxirgi 3 soatdagi diagrammalarga tayanolmaymiz: tarixiy o'lchovlarni katta vaqt oralig'ida ko'rish maqsadga muvofiqdir.
“Tavsiyalar” tizimi ishlab chiqildi. Misol uchun, bu erda siz "chegaralar" ni (yuqori ruxsat etilgan satrni) ko'tarish yaxshiroq bo'lishini ko'rishingiz mumkin, shunda "bo'g'inlash" sodir bo'lmaydi: resurs protsessor yoki xotirani ajratilgan vaqt oralig'ida allaqachon sarflagan va. u "muzlatilmagan" bo'lguncha kutmoqda:
Va bu erda ularning ishtahani to'xtatishi kerak bo'lgan dukkaklilar:
haqida bostirish + resurs monitoringi, siz bir nechta maqola yozishingiz mumkin, shuning uchun sharhlarda savollar bering. Bir necha so'z bilan aytishim mumkinki, bunday ko'rsatkichlarni avtomatlashtirish vazifasi juda qiyin va juda ko'p vaqtni talab qiladi va "oyna" funktsiyalari va "CTE" Prometey / VictoriaMetrics bilan muvozanatlash harakatini talab qiladi (bu atamalar tirnoq ichida, chunki deyarli mavjud PromQL-da bunga o'xshash narsa yo'q va siz qo'rqinchli so'rovlarni matnning bir nechta ekranlariga bo'lishingiz va ularni optimallashtirishingiz kerak).
Natijada, ishlab chiquvchilar Cube'da o'zlarining nom maydonlarini kuzatish vositalariga ega va ular qayerda va qaysi vaqtda qaysi ilovalar o'z resurslarini "kesib qo'yishi" mumkinligini va qaysi serverlarga butun tun bo'yi protsessor berilishi mumkinligini o'zlari tanlashlari mumkin.
Metodologiyalar
Hozirgi kabi kompaniyada moda, biz DevOps-ga rioya qilamiz- va SRE- amaliyotchi Agar kompaniyada 1000 ta mikroservis, 350 ga yaqin ishlab chiquvchi va butun infratuzilma uchun 15 administrator mavjud bo'lsa, siz "moda" bo'lishingiz kerak: bu "so'zlar" ortida hamma narsani va hammani avtomatlashtirishga shoshilinch ehtiyoj bor va administratorlar qiyinchilik tug'dirmasligi kerak. jarayonlarda.
Ops sifatida biz ishlab chiquvchilar uchun xizmat ko'rsatish tezligi va xatolar bilan bog'liq turli ko'rsatkichlar va asboblar panelini taqdim etamiz.
Biz quyidagi metodologiyalardan foydalanamiz: , и ularni birlashtirish orqali. Biz asboblar paneli sonini minimallashtirishga harakat qilamiz, shunda bir qarashda qaysi xizmat yomonlashayotgani (masalan, soniyada javob kodlari, javob vaqti 99 foiz) va hokazo. Umumiy asboblar paneli uchun ba'zi yangi ko'rsatkichlar zarur bo'lishi bilan biz ularni darhol chizamiz va qo'shamiz.
Men bir oy davomida grafik chizmadim. Bu, ehtimol, yaxshi belgidir: bu "istaklarning" ko'pchiligi allaqachon amalga oshirilganligini anglatadi. Hafta davomida men kuniga kamida bir marta yangi grafik chizaman.
Olingan natija juda qimmatlidir, chunki hozirda ishlab chiquvchilar administratorlarga "bir turdagi metrikani qayerda ko'rish kerak" degan savollar bilan kamdan-kam murojaat qilishadi.
Dastur Xizmat tarmog'i Yaqinda va hamma uchun hayotni osonlashtirishi kerak, Tools’dagi hamkasblar allaqachon “Sog‘lom odamning ishi” mavhumini amalga oshirishga yaqin: har bir HTTP(lar) so‘rovining hayot aylanishi monitoringda ko‘rinadi va u Xizmatlararo (va nafaqat) o'zaro ta'sir davomida "hamma narsa qaysi bosqichda buzilganligini" tushunish har doim mumkin bo'ladi. DomClick markazidan yangiliklarga obuna bo'ling. =)
Kubernetes infratuzilmasini qo'llab-quvvatlash
Tarixiy jihatdan biz yamalgan versiyadan foydalanamiz Kubespray - Kubernetes-ni joylashtirish, kengaytirish va yangilash uchun muhim rol. Bir nuqtada, kubeadm bo'lmagan o'rnatishlarni qo'llab-quvvatlash asosiy filialdan uzildi va kubeadm-ga o'tish jarayoni taklif qilinmadi. Natijada, Southbridge kompaniyasi o'z vilkasini yaratdi (kubeadm yordami va muhim muammolarni tezda hal qilish bilan).
Barcha k8s klasterlarini yangilash jarayoni quyidagicha ko'rinadi:
- olmoq Kubespray Sautbridjdan, bizning mavzu bilan tekshiring, Merjim.
- Biz yangilanishni chiqarmoqdamiz stress- "Kub".
- Biz yangilashni bir vaqtning o'zida bitta tugunni chiqaramiz (Ansible-da bu "seriya: 1") ichida dev- "Kub".
- Biz yangilaymiz Prod shanba kuni kechqurun bir vaqtning o'zida bitta tugun.
Kelajakda uni almashtirish rejalashtirilgan Kubespray tezroq biror narsa uchun va o'ting kubeadm.
Hammasi bo'lib bizda uchta "kub" bor: Stress, Dev va Prod. Biz boshqasini ishga tushirishni rejalashtirmoqdamiz (issiq kutish) Prod-"Cube" ikkinchi ma'lumotlar markazida. stress и dev “virtual mashinalarda” yashash (oVirt for Stress va VMWare cloud for Dev). Prod- "Kub" "yalang'och metallda" yashaydi: bular 32 protsessorli, 64-128 GB xotira va 300 GB SSD RAID 10 bo'lgan bir xil tugunlar - jami 50 tasi bor. Uchta "nozik" tugun "ustalar" ga bag'ishlangan. Prod- "Kuba": 16 Gb xotira, 12 protsessor torlari.
Sotish uchun biz "yalang'och metall" dan foydalanishni afzal ko'ramiz va shunga o'xshash keraksiz qatlamlardan qoching OpenStack: bizga "shovqinli qo'shnilar" va protsessor kerak emas vaqtni o'g'irlash. Va ichki OpenStack holatida boshqaruvning murakkabligi taxminan ikki baravar ortadi.
CI/CD "Cubic" va boshqa infratuzilma komponentlari uchun biz Helm 3-dan alohida GIT serveridan foydalanamiz (bu Helm 2-dan ancha og'riqli o'tish edi, lekin biz variantlardan juda mamnunmiz. atom), Jenkins, Ansible va Docker. Biz xususiyat filiallarini va bitta ombordan turli muhitlarga joylashtirishni yaxshi ko'ramiz.
xulosa
Bu, umuman olganda, DevOps jarayoni DomClick-da operatsion muhandis nuqtai nazaridan qanday ko'rinishga ega. Maqola men kutganimdan kamroq texnik bo'lib chiqdi: shuning uchun Habré-dagi DomClick yangiliklarini kuzatib boring: Kubernetes va boshqalar haqida ko'proq "qattiq" maqolalar bo'ladi.
Manba: www.habr.com