Më quajti Viktor Yagofarov, dhe unë merrem me zhvillimin e platformës Kubernetes në kompaninë DomKlik si udhëheqës teknik i zhvillimit në ekipin Ops (eksplorim). Dëshiroj të flas për organizimin e proceseve tona Dev Ops, për karakteristikat e funksionimit të një nga klasave më të mëdha k8s në Rusi, si dhe për praktikat DevOps/SRE që ekipi ynë përdor.
Ekipi Ops
Në ekipin Ops aktualisht punojnë 15 persona. Tre prej tyre përgjigjen për zyrën, dy punojnë në një zonë tjetër kohore dhe janë të disponueshëm, përfshirë dhe natën. Kështu, gjithmonë dikush nga Ops është pranë monitorit dhe gati për t'u reaguar ndaj çdo incidenti të ndonjë vështirësie. Ne nuk kemi turne nate, çka ruan psikologjinë tonë dhe na jep mundësinë të gjithëve të flejnë mjaftueshëm dhe të kalojnë kohë të lirë jashtë kompjuterit.
Kompetencat janë të ndryshme për të gjithë: specialistët e rrjeteve, DBA, ekspertët në teknologjinë ELK, administratorët/zhvilluesit e Kubernetes, specialistët për monitorim, virtualizim, hardware, etj. E përbashkëta midis të gjithëve është se secili mund të zëvendësojë në një farë forme çdo një nga ne: për shembull, të shtojë node të reja në klasterin k8s, të përditësojë PostgreSQL, të shkruajë pipeline CI/CD + Ansible, të automatizojë diçka në Python/Bash/Go, të lidhë pajisje në Qendrën e të Dhënave. Kompetencat e forta në një fushë nuk e pengojnë ndryshimin të drejtimit të aktivitetit dhe të fillosh të përmirësosh veten në një fushë tjetër. Për shembull, unë u punësova në një kompani si specialist për PostgreSQL, dhe tani zona ime kryesore e përgjegjësisë është klasteret Kubernetes. Në ekip, çdo rritje mirëpritet dhe është zhvilluar një ndjenjë e fortë e mbështetjes.
Sido, ne jemi në kërkim të punonjësve. Kërkesat për kandidatët janë mjaft standarde. Personalish për mua, është e rëndësishme që personi të integrohet në ekip, të jetë pa konflikte, por gjithashtu të dijë të mbrojë pikëpamjen e tij, të dëshirojë të zhvillohet dhe të mos ketë frikë të bëjë gjëra të reja duke ofruar idetë e tij. Gjithashtu, janë të nevojshme aftësi programimi në gjuhë skritpor, njohuri të bazave të Linux-it dhe të gjuhës angleze. Anglishtja është e nevojshme thjesht për të mundësuar që personi, në rast të një situate kritike, të gjejë zgjidhjen për problemin në 10 sekonda, e jo në 10 minuta. Me specialistët që kanë njohuri të thella të Linux-it tani është vështirë: është qesharake, por dy nga tre kandidatë nuk mund të përgjigjen për pyetjen "Çfarë është Load Average? Nga çfarë përbëhet?", ndersa pyetjen "Si të krijoni core dump nga një program në C" e konsiderojnë si diçka nga bota e supernjerëzve... apo dinosaurëve. Kjo është diçka që duhet pranuar, pasi zakonisht njerëzit kanë kompetenca të tjera të zhvilluara shumë mirë, ndërsa "linux-in" ne do ta mësojmë. Përgjigjen për pyetjen "pse është e nevojshme të dihet të gjithë kjo për një inxhinier DevOps në botën moderne të reve" do ta lëmë jashtë këtij artikulli, por nëse do ta shprehim me tri fjalë: e gjithë kjo është e nevojshme.
Ekipi Tools
Një rol të madh në automatizim luan ekipi i Tools. Detyra e tyre kryesore është krijimi i mjeteve të përshtatshme grafike dhe CLI për zhvilluesit. Për shembull, zhvillimi ynë i brendshëm Confer lejon që me disa klikime miu të nxitet një aplikacion në Kubernetes, të konfigurohen burimet, çelësat nga vault etj. Më parë kishim Jenkins + Helm 2, por ishte e nevojshme të zhvillohej një mjet i ri për të eliminuar kopjimin dhe ngjitjen dhe për të sjellë njëlloj në ciklin e jetës së softuerit.
Ekipi i Ops nuk shkruan pipeline për zhvilluesit, por mund të japë këshilla për çdo pyetje në lidhje me shkrimin e tyre (disa njerëz ende përdorin Helm 3).
DevOps
Sa i përket DevOps, ne e shohim atë kështu:
Ekipet e zhvillimit shkruajnë kodin, e publikojnë atë përmes Confer në dev -> qa/stage -> prod. Pesha për të siguruar që kodi të mos humbë performancën dhe të mos krijojë gabime i takon ekipeve të Zhvillimit dhe Operacioneve. Gjatë orëve të ditës, përgjigjja ndaj një incidenti me aplikacionin e tij duhet të jetë, para së gjithash, nga mbikëqyrësi i ekipit të Operacioneve, ndërsa gjatë orëve të mbrëmjes dhe natës, administratori i turnit (Ops) duhet të zgjojë zhvilluesin në turn, nëse është i sigurt se problemi nuk është në infrastrukturë. Të gjitha metrikat dhe alarmin në monitorim dalin automatikisht ose gjysmëautomatikisht.
Zona e përgjegjësisë së Operacioneve fillon në momentin e publikimit të aplikacionit në prodhim, por përgjegjësia e Zhvillimit nuk mbyllet këtu — ne po bëjmë një gjë dhe jemi në të njëjtën anije.
Zhvilluesit konsultojnë administratoret nëse nevojitet ndihmë në shkrimin e një mikroshërbimi për administratoret (për shembull, Go backend + HTML5), ndërsa administratoret konsultojnë zhvilluesit për çdo çështje infrastrukturore, ose për pyetje në lidhje me k8s.
Me thënë tërë të vërtetën, ne nuk kemi asnjë monolit, vetëm mikroshërbime. Numri i tyre aktualisht luhatet mes 900 dhe 1000 në prodhimin e klasës k8s, nëse e matim sipas numrit. dispozita. Numri i pod-ëve luhatet midis 1700 dhe 2000. Aktualisht ka rreth 2000 pod-e në prodhimin e klasës.
Nuk mund të jap numra të saktë, pasi ne monitorojmë mikroshërbimet e panevojshme dhe i eliminojmë ato në një modë gjysmëautomatik. Monitoring për entitetet e panevojshme në k8s na ndihmon , që ndihmon të kursejmë burime dhe para.
Menaxhimi i burimeve
Monitorimi
Këndi i rëndësishëm në funksionimin e një klasteri të madh bëhet monitorimi i ndërtuar mirë dhe informativ. Për momentin, nuk kemi gjetur një zgjidhje universale që të mbulojë 100% të të gjitha kërkesave për monitorim, prandaj herë pas here krijojmë zgjidhje të ndryshme të personalizuara në këtë ambient.
- Zabbix. Monitorimi tradicional, i cili është krijuar kryesisht për të ndjekur gjendjen e përgjithshme të infrastrukturës. Ai na tregon kur një nodë dështon për shkak të procesorit, memories, disqeve, rrjetit dhe kështu me radhë. Asgjë misterioze, por gjithashtu kemi një DaemonSet të veçantë nga agjentët, me anë të të cilëve, për shembull, monitorojmë gjendjen e DNS-it në klaster: kërkojmë pod-at e coredns që kanë ngecur, kontrollojmë disponueshmërinë e hosteve të jashtëm. Duke parë, çfarë ka nevojë për aq përpjekje, por me volume të mëdha trafiku, ky komponent është një pikë serioze dështimi. Më parë, kam , si kam luftuar me performancën e DNS-it në klaster.
- Prometheus Operator. Një grup ekspozerash ofron një pamje të gjerë të të gjitha komponenteve të klasterit. Pastaj vizualizojmë gjithçka në tabela të mëdha në Grafana, dhe për njoftimet përdorim alertmanager.
Një tjetër mjet i dobishëm për ne ishte . E shkruam atë pas disa herësh përballë situatave kur një ekip mbulon rrugët e Ingress të një ekipi tjetër, duke shkaktuar gabime 50x. Tani, para se të deploy-në në prodhim, zhvilluesit kontrollojnë që askënd të mos e prekin, dhe për ekipin tim, ky është një mjet i mirë për diagnozën fillestare të problemeve me Ingress. Është e çuditshme që fillimisht u shkrua për administratorët dhe dukej mjaft 'të papërshtatshëm', por pasi që mjeti u pëlqye nga ekipet dev, ai u transformua ndjeshëm dhe tani duket si diçka që nuk është bërë vetëm nga një administrator për administratorët. Shpejt do të heqim dorë nga ky mjet dhe situata të ngjashme do të validohen para se të lançohen pipeline-t.
Burimet e ekipeve në 'Kube'
Para se të fillojmë me shembujt, është e nevojshme të shpjegohet se si punon ndarja e burimeve për mikrosherbimesh.
Për të kuptuar se cilat ekipe dhe në çfarë sasi përdorin burimet e tyre burimet (procesori, memoria, SSD lokal), ne i rezervojmë çdo ekipi burime të veta namespace në "Kube" dhe e kufizojmë kapacitetin maksimale për procesorin, memorien dhe diskun, duke diskutuar paraprakisht nevojat e ekipeve. Kështu, një ekip, në përgjithësi, nuk do të bllokojë të gjithë klasterin për implementimin, duke ndarë me vete mijëra bërthamë dhe terabajtë e memories. Qasjet në namespace lëshohen përmes AD (ne përdorim RBAC). Namespace-t dhe limitet e tyre shtohen përmes një kërkese në GIT-repository, dhe më pas përmes pipeline-it Ansible gjithçka shpërndahet automatikisht.
Shembuj të ndarjes së burimeve për një ekip:
namespaces:
chat-team:
pods: 23
limits:
cpu: 11
memory: 20Gi
requests:
cpu: 11
memory: 20Gi
Kërkesat dhe limitet
Në "Kube" Kërkesa — kjo është sasia e burimeve të rezervuara garantuar për pod (një ose më shumë kontejnerë docker) në klaster. Limit - është maksimumi i pa garantuar. Shpesh mund të shihni në grafikë se si një ekip ka akorduar shumë kërkesa për të gjitha aplikacionet e tij dhe nuk mund të implementojë një aplikacion në "Kube", pasi nën namespace-in e tyre të gjitha kërkesat janë tashmë "shpenzuar."
Zgjidhja e duhur nga një situatë e tillë: të shikoni konsumimin e vërtetë të burimeve dhe ta krahasoni me sasinë e kërkuar (Request).
Në screenshotet e mësipërme, duket se CPU-të "të kërkuara" (Requested) përshtaten me numrin real të fijeve, ndërsa Limits mund të tejkalojnë numrin real të fijeve të procesorëve centralë =)
Tani do të shqyrtojmë një namespace (kam zgjedhur namespace kube-system — namespace sistemor për komponentët e "Kubes") dhe do të shikojmë raportin ndërmjet kohës së vërtetë të përdorur të procesorit dhe memories me atë që është e kërkuar:
Është e qartë se memorja dhe CPU janë rezervuar për shërbimet sistemore shumë më tepër se sa përdoren në të vërtetë. Në rastin e kube-system, kjo është e arsyeshme: ndodhi që nginx ingress controller ose nodelocaldns në kulm të ngarkohej në CPU dhe të digjte shumë RAM, prandaj këtu një rezervë e tillë është e arsyeshme. Më tej, nuk mund të mbështetemi në grafikat për tri orët e fundit: është e dëshirueshme të shohim metrikat historike për një periudhë të gjatë kohore.
U zhvillua një sistem "rekomandimesh". Për shembull, këtu mund të shihni cilave resurse do të ishte më mirë të rriteshin "limitet" (kuota maksimale e lejuar), në mënyrë që të mos ndodhte "trotllimi" (throttling): momenti kur CPU ose memoria e përdorur kalon kufirin e caktuar për një periudhë të caktuar dhe pritet derisa të "zhbllokohet".
Këtu janë pods që duhet të frenojnë apetitet:
Për trotlling + monitorimi i burimeve mund të shkruajë shumë artikuj, prandaj bëni pyetje në komentet. Në disa fjali mund të them se automatizimi i metricave të tilla është një detyrë mjaft e vështirë dhe kërkon shumë kohë dhe ekvilibrizëm me funksionet "window" dhe "CTE" në Prometheus / VictoriaMetrics (këto terma janë në thonjëza, pasi në PromQL gati nuk ka asgjë të tillë dhe duhet të krijohen kërkesa të tmerrshme që zënë disa ekrane teksti dhe të merremi me optimizimin e tyre).
Si rezultat, zhvilluesit kanë mjete për të monitoruar namespaces e tyre në "Kube", dhe ata mund të zgjedhin vetë se ku dhe në çfarë kohe mund të "presin" burimet për aplikacione të caktuara, ndërsa cilave pods mund t'u japin të gjithë CPU-në për një natë.
Metodologjitë
Në kompaninë tonë, siç është tani moderne, ne ndjekim praktikat DevOps dhe SRE.Kur në kompani ka 1000 mikrosherbime, rreth 350 zhvillues dhe 15 adminë për të gjithë infrastrukturën, duhet të "jepesh modern": pas këtyre "buzzwords" fshihet një nevojë urgjente për automatizimin e gjithçkaje, dhe adminët nuk duhet të jenë pika kritike në procese.
Si Ops, ne ofrojmë metrika dhe panele të ndryshme për zhvilluesit që lidhen me shpejtësinë e përgjigjes së shërbimeve dhe gabimet e tyre.
Ne përdorim metodologji si: , dhe , duke i kombinuar ato së bashku. Ne përpiqemi të minimizojmë numrin e paneleve në mënyrë që nga një shikim të jetë e qartë se cili shërbim po degradohet (për shembull, kodet e përgjigjes për sekondë, koha e përgjigjes në percentilin 99), e kështu me radhë. Sa herë që nevojiten ndonjë metrikë e re për panelet e përbashkëta, ne menjëherë i vizatojmë dhe i shtojmë.
Nuk kam vizatuar grafika tashmë një muaj. Sigurisht, kjo është një shenjë e mirë: do të thotë që shumica e "deshirave" janë realizuar. Ka ndodhur që gjatë një jave për të paktën një herë në ditë kam vizatuar ndonjë grafik të ri.
Rezultati që kemi arritur është i vlefshëm sepse tani zhvilluesit rrallë shkojnë te administratorët me pyetje "ku mund ta shoh ndonjë metrikë".
Implementimi Service Mesh nuk ka ardhur dhe do të lehtësojë shumë jetën e të gjithëve, kolegët nga Tools janë afër zbatimit të abstraktit "Istio i njeriut të shëndetshëm": cikli i jetës së çdo kërkese HTTP(s) do të jetë i dukshëm në monitorim, dhe gjithmonë do të jetë e mundur të kuptohet "në cilin hap u prish gjithçka" gjatë ndërveprimit ndër-shërbim (dhe jo vetëm) . Abonohuni në lajmet e qendrës së kompanisë DomKlik. =)
Mbështetje për infrastrukturën Kubernetes
Historikisht ka ndodhur që ne përdorim versionin e patchuar Kubespray — Rol Ansible për shpërndarjen, zgjerimin dhe përditësimin e Kubernetes. Në një moment, mbështetja për instalimet non-kubeadm u hoq nga dega kryesore, dhe procesi i kalimit në kubeadm nuk u propozua. Si rezultat, kompania Southbridge bëri forkun e saj (me mbështetje për kubeadm dhe një rregullim të shpejtë për problemet kritike).
Procesi i përditësimit të të gjitha klastereve k8s duket kështu:
- Merr Kubespray nga Southbridge, krahasojmë me degën tonë, bashkojmë.
- Kryejmë përditësimin në Stress-"Kub".
- Kryejmë përditësimin një nga një nodë (në Ansible kjo është "serial: 1") në Dev-"Kub".
- Përditësojmë Prod të shtunën në mbrëmje një nga një nodë.
Në të ardhmen ka plane për të zëvendësuar Kubespray me ndonjë gjë më të shpejtë dhe për të kaluar në kubeadm.
Kemi gjithsej tre «Kuba»: Stress, Dev dhe Prod. Përshtasim për të lançuar një tjetër (standby të nxehtë) Prod-«Kub» në qendrën e dytë të të dhënave. Stress dhe Dev ata jetojnë në «virtualka» (oVirt për Stress dhe VMWare cloud për Dev). Prod-«Kubi» jeton në «metal të zbrazët»: këto janë node të njëjta me 32 CPU threads, 64-128 GB memorie dhe 300 GB SSD RAID 10 — gjithsej janë 50 copë. Tri node «të holla» janë të dedikuara për «mastera» Prod-«Kuba»: 16 GB memorie, 12 CPU threads.
Për prodhim preferojmë të përdorim «metal të zbrazët» dhe shmangim shtresa të tepërta si OpenStack: nuk na duhen «fqinjtë e zhurmshëm» dhe CPU vjedhja e kohës. Po ashtu, kompleksiteti i administratës rritet rreth dy herë në rastin e OpenStack in-house.
Për CI/CD të «Kuba» dhe komponenteve të tjera infrastrukturore përdorim një server të veçantë GIT, Helm 3 (kalimi ishte mjaft i dhimbshëm nga Helm 2, por jemi shumë të kënaqur me opsionin atomic), Jenkins, Ansible dhe Docker. Na pëlqejnë feature-branch-ët dhe deploy në ambiente të ndryshme nga një depo.
Përfundimi
Kështu, në përgjithësi, në kompaninë DomKlik duket procesi i DevOps nga perspektiva e inxhinierit të operacioneve. Artikulli doli më pak teknik se sa prisja: kështu, ndjekni lajmet e DomKlik në Habra: do të ketë artikuj më «hardcore» për Kubernetes dhe jo vetëm.
Burimi: habr.com
