Nami abdi Viktor Yagofarov, sareng abdi nuju ngembangkeun platform Kubernetes di DomClick salaku manajer pangembangan téknis dina tim Ops (operasi). Abdi hoyong ngobrol ngeunaan struktur Dev kami <-> prosés Ops, fitur operasi salah sahiji klaster k8s pangbadagna di Rusia, kitu ogé prakték DevOps / SRE yén tim kami lumaku.
Tim Ops
Tim Ops ayeuna gaduh 15 urang. Tilu di antarana anu jawab kantor, dua gawe dina zona waktu béda jeung sadia, kaasup peuting. Ku kituna, batur ti Ops sok di monitor jeung siap ngabales kajadian naon pajeulitna. Urang teu boga shifts peuting, nu preserves psyche urang jeung méré dulur kasempetan pikeun meunangkeun cukup sare jeung méakkeun waktu luang teu ngan dina komputer.
Masing-masing gaduh kompetensi anu béda: jaringan, DBA, spesialis tumpukan ELK, admin / pamekar Kubernetes, ngawaskeun, virtualisasi, spesialis hardware, jsb. Hiji hal ngahijikeun sadayana - sadayana tiasa ngagentos salah sahiji urang dugi ka sababaraha: contona, ngenalkeun titik-titik énggal kana k8s kXNUMXs, ngapdet PostgreSQL, nyerat CI / CD + Pipa Ansible, ngajadikeun otomatis hiji hal dina Python / Bash / Go, sambungkeun hardware ka Puseur data. Kompeténsi anu kuat di daérah mana waé henteu nyegah anjeun ngarobih arah kagiatan anjeun sareng ngamimitian ningkatkeun di sababaraha daérah sanés. Salaku conto, kuring ngagabung sareng perusahaan salaku spesialis PostgreSQL, sareng ayeuna tanggung jawab utama kuring nyaéta klaster Kubernetes. Dina tim, sagala jangkungna téh wilujeng sumping sarta rasa ngungkit pisan dimekarkeun.
Ku jalan kitu, urang keur moro. Sarat pikeun calon cukup standar. Pikeun kuring pribadi, hal anu penting yén hiji jalma fits kana tim, nyaeta non-konflik, tapi ogé weruh kumaha carana membela sudut pandang na, hayang ngamekarkeun tur teu sieun ngalakukeun hal anyar, nawarkeun gagasan-Na. Ogé, kaahlian pamrograman dina basa skrip, pangaweruh dasar Linux sareng Inggris diperyogikeun. Basa Inggris diperlukeun saukur ku kituna hiji jalma dina acara fakap a tiasa google solusi pikeun masalah dina 10 detik, sarta henteu dina 10 menit. Ayeuna hésé pisan milarian spesialis anu gaduh pangaweruh anu jero ngeunaan Linux: éta lucu, tapi dua ti tilu calon henteu tiasa ngajawab patarosan "Naon Rata-rata Beban? Naon eta dijieunna tina?", Jeung patarosan "Kumaha carana ngumpul a dump inti tina program C" dianggap hal ti dunya supermen ... atawa dinosaurus. Urang kedah nahan ieu, sabab biasana jalma-jalma parantos ngembangkeun kompeténsi sanés, tapi urang bakal ngajarkeun Linux. Jawaban kana patarosan "naha insinyur DevOps kedah terang sadayana ieu di dunya awan modéren" kedah ditinggalkeun di luar ruang lingkup tulisan, tapi dina tilu kecap: sadayana ieu diperyogikeun.
Parabot Tim
Tim Alat maénkeun peran anu penting dina otomatisasi. Tugas utami nyaéta nyiptakeun alat grafis sareng CLI anu cocog pikeun pamekar. Salaku conto, pamekaran internal kami Confer ngamungkinkeun anjeun sacara harfiah ngagulung aplikasi ka Kubernetes kalayan ngan ukur sababaraha klik beurit, ngonpigurasikeun sumberna, konci tina kolong, jsb. Saméméhna, aya Jenkins + Helm 2, tapi kuring kudu ngamekarkeun alat sorangan pikeun ngaleungitkeun salinan-témpél jeung mawa uniformity kana lifecycle software.
Tim Ops teu nulis pipelines pikeun pamekar, tapi bisa mamatahan dina sagala masalah dina tulisan maranéhanana (sababaraha urang masih boga Helm 3).
DevOps
Sedengkeun pikeun DevOps, urang tingali sapertos kieu:
Tim dev nyerat kode, gulung kaluar via Confer to dev -> qa / stage -> prod. Tanggung jawab pikeun mastikeun yén kode henteu ngalambatkeun sareng henteu ngandung kasalahan aya dina tim Dev sareng Ops. Dina beurang, jalma anu ditugaskeun ti tim Ops kedah mimitina ngaréspon kana hiji kajadian kalayan aplikasina, sareng sonten sareng wengi, pangurus anu ditugaskeun (Ops) kedah ngahudangkeun pamekar anu ditugaskeun upami anjeunna terang. yakin yén masalahna henteu dina infrastruktur. Sadaya métrik sareng panggeuing dina ngawaskeun muncul sacara otomatis atanapi semi-otomatis.
Wewengkon tanggung jawab Ops dimimitian ti waktos aplikasi digulung kana produksi, tapi tanggung jawab Dev henteu réngsé di dinya - urang ngalakukeun hal anu sami sareng aya dina kapal anu sami.
Pamekar mamatahan admins lamun maranéhna butuh pitulung nulis hiji microservice admin (Contona, Go backend + HTML5), sarta admins mamatahan pamekar on sagala masalah infrastruktur atawa isu nu patali jeung k8s.
Ku jalan kitu, urang teu boga monolith a, ngan microservices. Jumlah maranéhanana jadi jauh fluctuates antara 900 jeung 1000 dina prod k8s klaster, lamun diukur ku angka nyebarkeun. Jumlah pods fluctuates antara 1700 jeung 2000. Ayeuna aya ngeunaan 2000 pods dina klaster prod.
Abdi teu tiasa masihan angka pasti, saprak urang ngawas microservices perlu sarta motong aranjeunna kaluar semi-otomatis. K8s ngabantosan urang ngalacak éntitas anu teu perlu , nu ngaheéat loba sumber jeung duit.
Manajemén sumberdaya
Ngawaskeun
Pemantauan anu terstruktur sareng informatif janten landasan dina operasi klaster ageung. Kami henteu acan mendakan solusi universal anu bakal nyertakeun 100% sadaya kabutuhan ngawaskeun, ku kituna kami périodik nyiptakeun solusi khusus anu béda dina lingkungan ieu.
- Zabbix. Alus ngawaskeun heubeul, nu dimaksudkeun utamana pikeun ngalacak kaayaan sakabéh infrastruktur. Eta ngabejaan urang nalika hiji titik maot dina watesan processing, memori, disk, jaringan, jeung saterusna. Henteu aya anu gaib, tapi urang ogé gaduh agén DaemonSet anu misah, kalayan bantosan, contona, urang ngawas kaayaan DNS dina kluster: urang milarian pod coredns bodo, urang pariksa kasadiaan host éksternal. Ieu bakal sigana nu naha ganggu jeung ieu, tapi ku volume badag lalulintas komponén ieu titik serius gagal. Baheula mah geus , kumaha kuring bajoang jeung kinerja DNS dina klaster a.
- Operator Prometheus. Hiji set eksportir béda méré gambaran badag sadaya komponén tina klaster. Salajengna, urang visualize sadayana ieu dina dasbor badag di Grafana, sarta ngagunakeun alertmanager pikeun ngabejaan.
alat sejen mangpaat pikeun urang éta . Kami nyerat éta saatos sababaraha kali urang mendakan kaayaan dimana hiji tim tumpang tindih jalur Ingress tim sanés, nyababkeun kasalahan 50x. Ayeuna sateuacan nyebarkeun ka produksi, pamekar pariksa yén teu aya anu bakal kapangaruhan, sareng pikeun tim kuring ieu mangrupikeun alat anu saé pikeun diagnosis awal masalah sareng Ingresses. Lucuna yén mimitina ditulis pikeun admin sareng katingalina rada "kagok", tapi saatos tim dev murag asih sareng alat éta, éta robih pisan sareng mimiti katingalina henteu sapertos "admin ngadamel raray wéb pikeun admin. ” Moal lami deui urang bakal ngantunkeun alat ieu sareng kaayaan sapertos kitu bakal disahkeun bahkan sateuacan pipa digulung.
sumberdaya tim di kubus
Sateuacan urang asup kana conto, éta patut ngajelaskeun kumaha urang alokasi sumberdaya pikeun microservices.
Pikeun ngartos tim mana sareng dina jumlah naon anu dianggo sumberdaya (processor, memori, SSD lokal), kami allocate unggal paréntah sorangan ngaranspasi dina "Kubus" jeung ngawatesan kamampuhan maksimum na dina watesan processor, memori jeung disk, geus dibahas saméméhna kaperluan tim. Sasuai, hiji paréntah, sacara umum, moal meungpeuk sakabéh klaster pikeun deployment, allocating rébuan cores na terabytes memori. Aksés ka namespace dipasihkeun ngaliwatan AD (urang nganggo RBAC). Ruang ngaran sareng watesna ditambihan ku pamenta tarik ka gudang GIT, teras sadayana sacara otomatis digulung ngalangkungan pipa Ansible.
Conto alokasi sumberdaya pikeun tim:
namespaces:
chat-team:
pods: 23
limits:
cpu: 11
memory: 20Gi
requests:
cpu: 11
memory: 20Gi
Requests sarta wates
Cubed" nyuhunkeun nyaeta jumlah dijamin sumberdaya ditangtayungan pikeun pod (hiji atawa leuwih peti docker) dina klaster. Wates mangrupakeun maksimum non-dijamin. Anjeun sering tiasa ningali dina grafik kumaha sababaraha tim parantos nyetél seueur teuing pamenta pikeun sadaya aplikasina sareng teu tiasa nyebarkeun aplikasi kana "Kubus", sabab sadaya pamenta dina ngaranspasi na parantos "dibébaskeun".
Cara anu leres kaluar tina kaayaan ieu nyaéta ningali konsumsi sumberdaya anu saleresna sareng ngabandingkeunana sareng jumlah anu dipénta (Paménta).
Dina Potret layar di luhur anjeun tiasa ningali yén CPU "Dipénta" cocog sareng jumlah benang anu nyata, sareng Watesan tiasa ngaleuwihan jumlah benang CPU nyata =)
Ayeuna hayu urang tingali sababaraha ngaranspasi sacara rinci (kuring milih namespace kube-system - sistem ngaranspasi pikeun komponén tina "Kubus" sorangan) sareng tingali rasio waktos sareng mémori prosésor anu dianggo pikeun anu dipénta:
Éta écés yén langkung seueur mémori sareng CPU ditangtayungan pikeun jasa sistem tibatan anu leres-leres dianggo. Dina kasus kube-sistem, ieu diyakinkeun: kajadian nu nginx ingress controller atanapi nodelocaldns di puncak maranéhanana pencét CPU jeung dihakan loba RAM, jadi didieu cadangan misalna hiji diyakinkeun. Sajaba ti éta, urang teu bisa ngandelkeun grafik pikeun 3 jam panungtungan: éta desirable ningali métrik sajarah dina jangka waktu nu badag.
Sistem "rekomendasi" dikembangkeun. Salaku conto, di dieu anjeun tiasa ningali sumber mana anu langkung saé pikeun naékkeun "wates" (bar anu diidinan luhur) supados "throttling" henteu kajantenan: momen nalika sumber daya parantos nyéépkeun CPU atanapi mémori dina potongan waktos anu disayogikeun sareng ngantosan dugi ka "unfrozen":
Sareng ieu polong anu kedah ngirangan napsu:
dina throttling + ngawaskeun sumberdaya, anjeun tiasa nyerat langkung ti hiji tulisan, janten naroskeun patarosan dina koméntar. Dina sababaraha kecap, abdi tiasa nyebatkeun yén tugas ngajadikeun otomatis métrik sapertos sesah pisan sareng peryogi seueur waktos sareng nyaimbangkeun polah sareng fungsi "jandela" sareng "CTE" Prometheus / VictoriaMetrics (istilah ieu aya dina tanda petik, sabab ampir aya euweuh kawas ieu di PromQL, jeung anjeun kudu ngabagi queries pikasieuneun kana sababaraha layar téks na ngaoptimalkeun aranjeunna).
Hasilna, pamekar boga parabot pikeun ngawas ngaranspasi maranéhanana di Cube, sarta aranjeunna bisa milih sorangan dimana jeung iraha aplikasi nu bisa boga sumberdaya maranéhanana "motong", sarta server mana nu bisa dibikeun sakabéh CPU sapanjang peuting.
Métodologi
Di perusahaan sapertos ayeuna modis, urang taat ka DevOps- jeung Sérér- praktisi Nalika perusahaan ngagaduhan 1000 microservices, sakitar 350 pamekar sareng 15 admin pikeun sadaya infrastruktur, anjeun kedah "modis": di balik sadaya "baswords" ieu aya kabutuhan anu penting pikeun ngajadikeun otomatis sadayana sareng sadayana, sareng admin henteu kedah janten bottleneck. dina prosés.
Salaku Ops, kami nyayogikeun rupa-rupa métrik sareng dasbor pikeun pamekar anu aya hubunganana sareng tingkat réspon jasa sareng kasalahan.
Kami nganggo metodologi sapertos: , и ku ngagabungkeun aranjeunna babarengan. Kami nyobian ngaleutikan jumlah dasbor supados sakedapan jelas jasa mana anu ayeuna ngahinakeun (contona, kode réspon per detik, waktos réspon ku persentil ka-99), sareng saterasna. Pas sababaraha métrik anyar janten dipikabutuh pikeun dasbor umum, urang langsung ngagambar sareng nambihanana.
Geus sabulan kuring teu ngagambar grafik. Ieu meureun tanda alus: eta hartina lolobana "hayang" geus kawujud. Kajadian éta salila saminggu kuring bakal ngagambar sababaraha grafik anyar sahenteuna sakali sapoé.
Hasilna hasilna berharga sabab ayeuna pamekar rada jarang angkat ka admin kalayan patarosan "dimana ningali sababaraha métrik."
Palaksanaan Jasa Jaring nyaeta ngan sabudeureun sudut sarta kudu nyieun hirup loba gampang for everyone, kolega ti Pakakas geus deukeut ka nerapkeun abstrak "Istio jalma cageur": daur hirup unggal HTTP(s) pamundut bakal katingali dina monitoring, sarta eta bakal salawasna mungkin ngartos "dina tahap naon sagalana peupeus" salila interaksi antar-jasa (teu ngan). Ngalanggan warta ti DomClick hub. =)
Pangrojong infrastruktur Kubernetes
Dina sajarahna, kami nganggo versi patched Kubespray - Peran anu tiasa dianggo pikeun nyebarkeun, ngalegaan sareng ngapdet Kubernetes. Dina sababaraha waktos, dukungan pikeun pamasangan non-kubeadm dipotong tina cabang utama, sareng prosés ngalih ka kubeadm henteu diusulkeun. Hasilna, pausahaan Southbridge dijieun garpu sorangan (kalawan rojongan kubeadm sarta fix rusuh pikeun masalah kritis).
Prosés pikeun ngapdet sadaya k8s klaster sapertos kieu:
- Candak Kubespray ti Southbridge, pariksa ku thread urang, Merjim.
- Urang rolling kaluar apdet pikeun tekenan- "Kubus".
- Urang gulung kaluar apdet hiji titik dina hiji waktu (dina Ansible ieu "serial: 1") dina Dev- "Kubus".
- Urang ngamutahirkeun Prod on Sabtu malem hiji titik dina hiji waktu.
Aya rencana pikeun ngaganti eta dina mangsa nu bakal datang Kubespray pikeun hal gancang sarta buka kubeadm.
Jumlahna aya tilu "kubus": Stress, Dev sareng Prod. Kami ngarencanakeun pikeun ngaluncurkeun anu sanés (siaga panas) Prod- "Kubus" dina puseur data kadua. tekenan и Dev hirup di "mesin virtual" (oVirt pikeun Stress jeung VMWare awan pikeun Dev). Prod- "Kubus" hirup dina "logam bulistir": ieu titik idéntik jeung 32 threads CPU, 64-128 GB memori sareng 300 GB SSD RAID 10 - jumlahna aya 50. Tilu titik "ipis" dedicated ka "masters" Prod- "Kuba": 16 GB mémori, 12 benang CPU.
Pikeun jualan, urang resep ngagunakeun "logam bulistir" jeung ulah aya lapisan perlu kawas OpenStack: urang teu butuh "tatanggana ribut" jeung CPU maok waktu. Sareng pajeulitna administrasi sakitar dua kali dina kasus OpenStack in-house.
Pikeun CI / CD "Kubik" sareng komponén infrastruktur sanésna kami nganggo server GIT anu misah, Helm 3 (éta transisi anu rada nyeri tina Helm 2, tapi kami bagja pisan sareng pilihan. atom), Jenkins, Ansible sareng Docker. Urang resep cabang fitur sareng panyebaran kana lingkungan anu béda ti hiji gudang.
kacindekan
Ieu, sacara umum, kumaha prosés DevOps di DomClick tina sudut pandang insinyur operasi. Tulisan éta tétéla kirang téknis ti anu disangka: ku kituna, tuturkeun warta DomClick on Habré: bakal aya deui tulisan "hardcore" ngeunaan Kubernetes sareng seueur deui.
sumber: www.habr.com