Менин атым Виктор Ягофаров, мен DomClick'те Ops (операция) командасынын техникалык өнүктүрүү боюнча менеджери катары Kubernetes платформасын иштеп жатам. Мен Dev <-> Ops процесстерибиздин структурасы, Россиядагы эң чоң k8s кластерлеринин биринин иштөө өзгөчөлүктөрү, ошондой эле биздин команда колдонгон DevOps/SRE тажрыйбалары жөнүндө айткым келет.
Ops командасы
Операциянын командасында учурда 15 адам бар. Алардын үчөө кеңсеге жооптуу, экөө башка убакыт алкагында иштешет жана жеткиликтүү, анын ичинде түнкүсүн. Ошентип, Опстан бирөө ар дайым монитордо жана ар кандай татаалдыктагы окуяга жооп берүүгө даяр. Бизде түнкү нөөмөт жок, бул биздин психикабызды сактап, ар бир адамга жетиштүү уктап, бош убактысын компьютерде гана өткөрүүгө мүмкүнчүлүк берет.
Ар бир адамдын ар кандай компетенциялары бар: тармактык адистер, DBAлар, ELK стек адистери, Kubernetes администраторлору/иштеп чыгуучулары, мониторинг, виртуалдаштыруу, аппараттык адистер ж.б. Баарын бир нерсе бириктирет – ар бир адам кандайдыр бир деңгээлде биздин ар бирибизди алмаштыра алат: мисалы, k8s кластерине жаңы түйүндөрдү киргизиңиз, PostgreSQLди жаңыртыңыз, CI/CD + Ansible конвейерин жазыңыз, Python/Bash/Go'до бир нерсени автоматташтырыңыз, жабдыктарды туташтырыңыз Маалымат борбору. Кандайдыр бир чөйрөдө күчтүү компетенциялар сиздин ишмердүүлүк багытыңызды өзгөртүүгө жана башка чөйрөдө өркүндөй баштоого тоскоол болбойт. Мисалы, мен компанияга PostgreSQL адиси катары кошулдум, эми менин негизги жоопкерчилигим бул Kubernetes кластерлери. Командада кандай гана бийиктик болбосун кабыл алынат жана рычагдык сезим абдан өнүккөн.
Баса, биз аңчылык кылып жатабыз. Талапкерлерге коюлган талаптар абдан стандарттуу. Жеке мен үчүн адамдын командага туура келиши, конфликтсиз, бирок ошондой эле өз көз карашын коргой билгени, өнүгүүнү каалап, жаңы нерсе жасоодон коркпогону, өз идеяларын сунуштаганы маанилүү. Ошондой эле, скрипт тилдеринде программалоо көндүмдөрү, Linux жана англис тилдеринин негиздерин билүү талап кылынат. Англис тили жөн гана факапка кабылган адам 10 мүнөттүн ичинде эмес, 10 секунданын ичинде Google'да маселени чече алышы үчүн керек. Азыр Linux боюнча терең билими бар адистерди табуу абдан кыйын: бул күлкүлүү, бирок үч талапкердин экөөсү “Орточо жүктөө деген эмне? Ал эмнеден жасалган?», жана «С программасынан негизги таштандыны кантип чогултуу керек» деген суроо супермендер... же динозаврлар дүйнөсүнөн бир нерсе деп эсептелет. Биз буга чыдашыбыз керек, анткени адатта адамдар башка компетенцияларды өнүктүргөн, бирок биз Linuxту үйрөтөбүз. "Эмне үчүн DevOps инженери булуттардын заманбап дүйнөсүндө мунун баарын билиши керек" деген суроого жоопту макаланын чегинен тышкары калтыруу керек, бирок үч сөз менен айтканда: мунун баары керек.
Команда куралдары
Tools командасы автоматташтырууда маанилүү роль ойнойт. Алардын негизги милдети - иштеп чыгуучулар үчүн ыңгайлуу графикалык жана CLI куралдарын түзүү. Мисалы, биздин ички өнүктүрүү конференциябыз сизге бир нече чычкан чыкылдатуу менен Kubernetes тиркемесин түзмө-түз чыгарууга, анын ресурстарын конфигурациялоого, сактагычтан ачкычтарды ж. Буга чейин Jenkins + Helm 2 бар болчу, бирок мен көчүрүп чаптоону жок кылуу жана программалык камсыздоонун жашоо циклине бирдейликти алып келүү үчүн өз куралымды иштеп чыгышым керек болчу.
Ops командасы иштеп чыгуучулар үчүн куурларды жазбайт, бирок алардын жазууларында ар кандай маселелер боюнча кеңеш бере алат (айрым адамдар дагы эле Helm 3 бар).
тамтык
DevOpsке келсек, биз муну мындайча көрөбүз:
Dev топтору код жазышат, аны Confer to dev -> qa/stage -> prod аркылуу чыгарышат. Коддун жайлабашы жана каталар болбошу үчүн жоопкерчилик Dev жана Ops топторуна жүктөлөт. Күндүз Операция командасынын нөөмөтчүсү биринчи кезекте өзүнүн арызы менен болгон окуяга жооп бериши керек, ал эми кечинде жана түнкүсүн нөөмөтчү администратор (Ops) нөөмөтчү иштеп чыгуучуну билсе, ойготушу керек. көйгөй инфраструктурада эмес экенине ишен. Мониторингдеги бардык көрсөткүчтөр жана эскертүүлөр автоматтык түрдө же жарым автоматтык түрдө пайда болот.
Ops жоопкерчилик чөйрөсү тиркеме өндүрүшкө киргизилген учурдан тартып башталат, бирок Девдин жоопкерчилиги ушуну менен эле бүтпөйт - биз бир эле нерсени кылабыз жана бир кайыктабыз.
Иштеп чыгуучулар администраторлорго администратор микросервисин жазууга жардам керек болсо (мисалы, Go backend + HTML5) кеңеш беришет жана администраторлор иштеп чыгуучуларга бардык инфраструктура маселелери же k8s менен байланышкан маселелер боюнча кеңеш беришет.
Баса, бизде такыр монолит жок, микросервистер гана. Алардын саны ушул кезге чейин прод к900с кластеринде 1000дөн 8ге чейин өзгөрүп турат, эгер саны менен өлчөнөт жайгаштыруу. Бакчалардын саны 1700дөн 2000ге чейин өзгөрүп турат. Учурда өндүрүш кластеринде 2000ге жакын кабык бар.
Мен так сандарды айта албайм, анткени биз керексиз микросервистерди көзөмөлдөп, жарым автоматтык түрдө өчүрөбүз. K8s бизге керексиз объекттерди көзөмөлдөөгө жардам берет , бул көп ресурстарды жана акчаны үнөмдөйт.
Ресурстарды башкаруу
Мониторинг
Жакшы структураланган жана маалыматтык мониторинг чоң кластердин ишинин негизи болуп калат. Биз мониторингдин бардык муктаждыктарын 100% камтый турган универсалдуу чечим таба элекпиз, ошондуктан биз мезгил-мезгили менен бул чөйрөдө ар кандай жекече чечимдерди түзөбүз.
- Апенди. Жакшы эски мониторинг, биринчи кезекте, инфраструктуранын жалпы абалын көзөмөлдөө үчүн арналган. Бул түйүн кайра иштетүү, эстутум, дисктер, тармак ж.б. Табияттан тыш эч нерсе жок, бирок бизде өзүнчө DaemonSet агенттери бар, анын жардамы менен, мисалы, кластердеги DNS абалын көзөмөлдөйбүз: биз акылсыз coredns поддондорун издейбиз, тышкы хосттордун болушун текшеребиз. Бул эмне үчүн убара болуп жаткандай сезилет, бирок трафиктин чоң көлөмү менен бул компонент олуттуу бузулуу болуп саналат. мен уже , кластерде DNS иштеши менен кантип күрөшкөм.
- Прометей оператору. Ар түрдүү экспорттоочулар топтому кластердин бардык компоненттеринин кеңири баяндамасын берет. Андан кийин, биз мунун баарын Grafanaдагы чоң панелдерде визуализациялап, эскертүүлөр үчүн alertmanager колдонобуз.
Биз үчүн дагы бир пайдалуу курал болду . Биз аны бир нече жолу бир команда башка команданын кириш жолдорун кайталап, натыйжада 50x ката кетирген кырдаалга туш болгондон кийин жаздык. Азыр өндүрүшкө жайылтуудан мурун, иштеп чыгуучулар эч кимге таасирин тийгизбей турганын текшеришет жана менин командам үчүн бул Ingresses менен көйгөйлөрдү алгачкы диагностикалоо үчүн жакшы курал. Башында ал администраторлор үчүн жазылганы күлкүлүү, бирок иштеп чыгуучулар бул куралды сүйүп калгандан кийин, ал бир топ өзгөрүп, "админ администраторлор үчүн веб жүзүн жасаган" сыяктуу көрүнбөй калды. ” Жакында биз бул куралдан баш тартабыз жана мындай жагдайлар куур ишке киргенге чейин эле текшерилет.
Кубдогу команда ресурстары
Мисалдарга кирүүдөн мурун, биз ресурстарды кантип бөлүштүрөөрүбүздү түшүндүрүп берүү керек микросервис.
Кайсы командаларды жана кандай өлчөмдө колдонорун түшүнүү ресурстар (процессор, эс тутум, жергиликтүү SSD), биз ар бир буйрукту өзүнчө бөлүп беребиз Аталыштар мейкиндиги "Cube" жана процессор, эстутум жана диск жагынан анын максималдуу мүмкүнчүлүктөрүн чектеп, командалардын муктаждыктарын мурда талкуулаган. Демек, бир команда, жалпысынан, миӊдеген өзөктөрдү жана терабайт эстутумдарды бөлүп, жайылтуу үчүн бүткүл кластерди бөгөттөбөйт. Ат мейкиндигине кирүү AD аркылуу берилет (биз RBAC колдонобуз). Ат мейкиндиктери жана алардын чектери GIT репозиторийине тартуу өтүнүчү аркылуу кошулат, андан кийин баары автоматтык түрдө Ansible түтүгү аркылуу чыгарылат.
Командага ресурстарды бөлүштүрүүнүн мисалы:
namespaces:
chat-team:
pods: 23
limits:
cpu: 11
memory: 20Gi
requests:
cpu: 11
memory: 20Gi
Сурамдар жана чектөөлөр
кубик" өтүнүч үчүн кепилденген резервдик ресурстардын саны Гадылбек (бир же бир нече докер контейнерлери) кластерде. Лимит - кепилденбеген максимум. Кээ бир команда өзүнүн бардык тиркемелери үчүн өтө көп суроо-талаптарды койгонун жана тиркемени "Cube"га жайгаштыра албаганын графиктерден көрө аласыз, анткени алардын аталыш мейкиндигиндеги бардык суроо-талаптар мурунтан эле "коротулган".
Бул абалдан чыгуунун туура жолу - ресурстун чыныгы керектөөсүн карап, аны суралган сумма менен салыштыруу (Сураныч).
Жогорудагы скриншоттордо сиз "Суранган" CPU жиптердин чыныгы санына дал келгенин көрө аласыз, ал эми Лимиттер CPU жиптеринин чыныгы санынан ашып кетиши мүмкүн =)
Эми кээ бир аттар мейкиндигин майда-чүйдөсүнө чейин карап көрөлү (мен аттар мейкиндигин kube-системаны тандадым - "Cube" компоненттеринин система мейкиндиги) жана иш жүзүндө колдонулган процессор убактысынын жана эстутумунун суралганга карата катышын көрөлү:
Иш жүзүндө колдонулгандан алда канча көп эстутум жана CPU тутумдук кызматтар үчүн сакталганы айдан ачык. Kube-системасынын учурда, бул негиздүү: nginx кириш контроллери же nodelocaldns эң жогорку чегинде CPUга тийип, көп оперативдүү эстутум керектешкен, ошондуктан бул жерде мындай резерв негиздүү. Кошумчалай кетсек, биз акыркы 3 сааттын диаграммаларына ишене албайбыз: тарыхый метрикаларды көп убакыттын ичинде көрүү зарыл.
«сунуштардын» системасы иштелип чыккан. Мисалы, бул жерден сиз кайсы ресурстарды "чектөөлөрдү" (жогорку уруксат берилген тилке) көтөрүү жакшыраак болорун көрө аласыз, ошондо "токтоо" болбойт: ресурс CPU же эстутумду бөлүнгөн убакыт тилкесинде мурунтан эле сарптаган учур жана ал "тоңдурулбай" калгыча күтүп жатат:
Жана бул жерде алардын табитин ооздукташы керек болгон кабыктар:
боюнча дроссель + ресурс мониторинги, сиз бирден ашык макала жаза аласыз, андыктан комментарийлерде суроолорду бериңиз. Бир нече сөз менен айтканда, мындай метрикаларды автоматташтыруу милдети абдан татаал жана көп убакытты талап кылат жана “терезе” функциялары жана “CTE” Prometheus / VictoriaMetrics менен тең салмактуулукту талап кылат деп айта алам (бул терминдер тырмакчада, анткени дээрлик бар PromQLде ушуга окшош эч нерсе жок жана сиз коркунучтуу сурамдарды тексттин бир нече экрандарына бөлүп, аларды оптималдаштырышыңыз керек).
Натыйжада, иштеп чыгуучулардын Cube ичиндеги аттар мейкиндиктерин көзөмөлдөө үчүн куралдары бар жана алар кайда жана кайсыл убакта кайсы колдонмолордун ресурстарын “кесип” алаарын жана кайсы серверлерге бүтүндөй CPU түнү бою берилээрин өздөрү тандай алышат.
Методологиялар
Компанияда азыркыдай модалуу, биз DevOps- жана карманабыз мушташ-практик Компанияда 1000 микросервис, 350гө жакын иштеп чыгуучулар жана бүткүл инфраструктура үчүн 15 администратор болгондо, сиз "модалуу" болушуңуз керек: бул "жалган сөздөрдүн" артында бардыгын жана бардыгын автоматташтыруу зарыл жана администраторлор тоскоолдук болбошу керек. процесстерде.
Ops катары биз иштеп чыгуучулар үчүн кызматтын жооп берүү ылдамдыктарына жана каталарына байланыштуу ар кандай көрсөткүчтөрдү жана такталарды камсыз кылабыз.
Биз төмөнкүдөй методологияларды колдонобуз: , и аларды бириктирүү менен. Биз башкаруу такталарынын санын азайтууга аракет кылабыз, ошондо кайсы кызмат азыркы учурда начарлап жатканын (мисалы, секундасына жооп коддору, 99-проценттилге жооп берүү убактысы) жана башкалар айкын көрүнүп турат. Кээ бир жаңы көрсөткүчтөр жалпы панелдер үчүн зарыл болуп калганда, биз аларды дароо чийип, кошобуз.
Мен бир айдан бери график тартпай калдым. Бул, балким, жакшы жышаан: бул "каалоолордун" көбү ишке ашканын билдирет. Аптанын ичинде мен күнүнө жок дегенде бир жолу жаңы график тартчумун.
Натыйжа баалуу, анткени азыр иштеп чыгуучулар администраторлорго "кандайдыр бир метриканы кайдан кароо керек" деген суроолор менен сейрек кайрылышат.
киргизүү Кызмат тор бурчта турат жана ар бир адамдын жашоосун бир топ жеңилдетет, Tools кесиптештери абстракттуу "Дени сак адам" программасын ишке ашырууга жакындап калышты: ар бир HTTP(лардын) сурамынын жашоо цикли мониторингде көрүнүп турат жана Кызматтар аралык (жана гана эмес) өз ара аракеттешүү учурунда "кандай этапта баары бузулганын" түшүнүүгө ар дайым мүмкүн болот. DomClick хабынан жаңылыктарга жазылыңыз. =)
Kubernetes инфраструктурасын колдоо
Тарыхый жактан биз жамаачыланган версияны колдонобуз Kubespray — Kubernetesти жайылтуу, кеңейтүү жана жаңыртуу үчүн маанилүү роль. Кайсы бир учурда кубеадм эмес установкаларга колдоо негизги бутактуу кесилип, кубеадмга өтүү процесси сунуш кылынган эмес. Натыйжада, Southbridge компаниясы өзүнүн айрысын жасады (kubeadm колдоосу жана орчундуу көйгөйлөрдү тез чечүү менен).
Бардык k8s кластерлерин жаңыртуу процесси төмөнкүдөй көрүнөт:
- Келгиле, алалы Kubespray Southbridge тартып, биздин жип менен текшерип, Merjim.
- Биз жаңыртууну чыгарып жатабыз басым- "Куб".
- Биз жаңыртууну бирден бир түйүнгө чыгарабыз (Ansibleде бул "серия: 1") Dev- "Куб".
- Жаңыртабыз Prod ишемби күнү кечинде бирден түйүн.
Келечекте аны алмаштыруу пландары бар Kubespray тезирээк бир нерсе үчүн жана барыңыз кубеадм.
Жалпысынан бизде үч "Куб" бар: Стресс, Dev жана Прод. Дагы бирөөнү ишке киргизүүнү пландап жатабыз (ысык күтүү) Экинчи маалымат борборунда Prod-"Cube". басым и Dev "виртуалдык машиналарда" жашайт (Stress үчүн oVirt жана Dev үчүн VMWare булуту). Prod- "Cube" "жылаңач металлда" жашайт: бул 32 CPU жиптери, 64-128 ГБ эс тутуму жана 300 ГБ SSD RAID 10 менен бирдей түйүндөр - бардыгы болуп алардын 50ү бар. Үч "ичке" түйүн "мастерлерге" арналган Prod- "Куба": 16 ГБ эс тутуму, 12 CPU жиптери.
Сатуу үчүн биз "жылаңач металлды" колдонууну жана сыяктуу керексиз катмарлардан качууну каалайбыз OpenStack: бизге "ызы-чуу кошуналар" жана CPU керек эмес убакыт уурдоо. Ал эми башкаруунун татаалдыгы ички OpenStack учурда эки эсеге көбөйөт.
CI/CD "Cubic" жана башка инфраструктуралык компоненттер үчүн биз өзүнчө GIT серверин колдонобуз, Helm 3 (бул Helm 2ден өтө оор өтүү болду, бирок биз варианттарга абдан ыраазыбыз. атомдук), Дженкинс, Ансибл жана Докер. Биз өзгөчөлүк бутактарын жана бир репозиторийден ар кандай чөйрөлөргө жайылтууну жакшы көрөбүз.
жыйынтыктоо
Бул, жалпысынан алганда, DevOps процесси DomClick'те операциялык инженердин көз карашы боюнча кандай көрүнөт. Макала мен күткөндөн азыраак техникалык болуп чыкты: ошондуктан, Habréдеги DomClick жаңылыктарына көз салыңыз: Kubernetes жана башкалар жөнүндө көбүрөөк "хардкор" макалалар болот.
Source: www.habr.com