Jenengku Viktor Yagofarov, lan aku ngembangake platform Kubernetes ing DomClick minangka manajer pangembangan teknis ing tim Ops (operasi). Aku pengin ngomong babagan struktur proses Dev <-> Ops, fitur operasi salah sawijining klompok k8s paling gedhe ing Rusia, uga praktik DevOps / SRE sing ditrapake tim kita.
Tim Ops
Tim Ops saiki duwe 15 wong. Telu mau tanggung jawab kanggo kantor, loro kerja ing zona wektu sing beda lan kasedhiya, kalebu ing wayah wengi. Mangkono, wong saka Ops tansah ing monitor lan siap kanggo nanggapi kedadean saka kerumitan sembarang. Kita ora duwe shift wengi, sing ngreksa psyche lan menehi kabeh kesempatan kanggo turu cukup lan nglampahi wektu luang ora mung ing komputer.
Saben uwong nduweni kompetensi sing beda-beda: jaringan, DBA, spesialis tumpukan ELK, admin/pengembang Kubernetes, ngawasi, virtualisasi, spesialis hardware, lsp. Siji bab nyawiji saben wong - kabeh wong bisa ngganti salah siji saka kita kanggo sawetara ombone: contone, introduce simpul anyar menyang k8s kluster, nganyari PostgreSQL, nulis CI / CD + pipeline Ansible, ngotomatisasi soko ing Python / Bash / Go, nyambung hardware kanggo Pusat data. Kompetensi sing kuat ing wilayah apa wae ora ngalangi sampeyan ngganti arah kegiatan lan wiwit nambah ing sawetara wilayah liyane. Contone, aku gabung karo perusahaan minangka spesialis PostgreSQL, lan saiki tanggung jawab utamaku yaiku kluster Kubernetes. Ing tim, sembarang dhuwur ditampa lan raos pengaruh banget dikembangaké.
Miturut cara, kita mburu. Syarat kanggo calon cukup standar. Kanggo kula pribadi, iku penting sing wong mathuk menyang tim, iku non-konflik, nanging uga ngerti carane kanggo defend sudut pandang, kepengin kanggo berkembang lan ora wedi kanggo nindakake soko anyar, nawakake gagasan. Kajaba iku, katrampilan pemrograman ing basa skrip, kawruh babagan dhasar Linux lan Inggris dibutuhake. Inggris dibutuhake mung supaya wong ing acara saka fakap bisa google solusi kanggo masalah ing 10 detik, lan ora ing 10 menit. Saiki angel banget golek spesialis sing ngerti babagan Linux: lucu, nanging loro saka telung calon ora bisa mangsuli pitakon "Apa Rata-rata Beban? Apa digawe saka?", Lan pitakonan "Carane ngumpulake dump inti saka program C" dianggep soko saka donya superhumans ... utawa dinosaurus. Kita kudu sabar karo iki, amarga biasane wong wis ngembangake kompetensi liyane, nanging kita bakal mulang Linux. Jawaban kanggo pitakonan "kenapa insinyur DevOps kudu ngerti kabeh iki ing jagad awan modern" kudu ditinggalake ing njaba ruang lingkup artikel kasebut, nanging kanthi telung tembung: kabeh iki dibutuhake.
Alat Tim
Tim Alat nduwe peran penting ing otomatisasi. Tugas utama yaiku nggawe alat grafis lan CLI sing trep kanggo pangembang. Contone, Konferensi pangembangan internal ngidini sampeyan nggulung aplikasi menyang Kubernetes kanthi mung sawetara klik mouse, ngatur sumber daya, tombol saka vault, lsp. Sadurunge, ana Jenkins + Helm 2, nanging aku kudu nggawe alat dhewe kanggo ngilangi salinan-tempel lan nggawa keseragaman menyang siklus urip piranti lunak.
Tim Ops ora nulis pipa kanggo pangembang, nanging bisa menehi saran babagan masalah apa wae ing tulisane (sawetara wong isih duwe Helm 3).
DevOps
Kanggo DevOps, kita ndeleng kaya iki:
Tim dev nulis kode, gulung metu liwat Confer to dev -> qa/stage -> prod. Tanggung jawab kanggo mesthekake yen kode ora alon lan ora ngemot kasalahan dumunung ing tim Dev lan Ops. Ing wayah awan, wong sing tugas saka tim Ops kudu nanggapi kedadeyan kanthi lamaran, lan ing wayah sore lan ing wayah wengi, administrator tugas (Ops) kudu nggugah pangembang sing tugas yen ngerti. manawa masalah ora ana ing infrastruktur. Kabeh metrik lan tandha ing ngawasi katon kanthi otomatis utawa semi-otomatis.
Wilayah tanggung jawab Ops diwiwiti wiwit aplikasi kasebut diluncurake dadi produksi, nanging tanggung jawab Dev ora mungkasi ana - kita nindakake perkara sing padha lan ana ing prau sing padha.
Pangembang menehi saran marang admin yen butuh bantuan nulis layanan mikro admin (contone, Go backend + HTML5), lan admin menehi saran marang pangembang babagan masalah infrastruktur utawa masalah sing ana gandhengane karo k8s.
Miturut cara, kita ora duwe monolith ing kabeh, mung microservices. Jumlahe nganti saiki fluktuasi antarane 900 lan 1000 ing kluster prod k8s, yen diukur nganggo nomer. panyebaran. Jumlah polong fluktuasi antarane 1700 lan 2000. Saiki ana sekitar 2000 polong ing kluster prod.
Aku ora bisa menehi nomer pas, awit kita ngawasi microservices rasah lan Cut mau metu semi-otomatis. K8s mbantu kita nglacak entitas sing ora perlu , sing nyimpen akeh sumber daya lan dhuwit.
Manajemen sumber daya
Ngawasi
Pemantauan sing terstruktur lan informatif dadi landasan ing operasi kluster gedhe. Kita durung nemokake solusi universal sing bakal nutupi 100% kabeh kabutuhan pemantauan, mula kita nggawe solusi khusus kanthi periodik ing lingkungan iki.
- Zabbix. Ngawasi lawas sing apik, sing dimaksudake utamane kanggo nglacak kondisi infrastruktur sakabèhé. Iki ngandhani nalika simpul mati ing babagan pangolahan, memori, disk, jaringan, lan liya-liyane. Ora ana sing gaib, nanging uga duwe agen DaemonSet sing kapisah, kanthi bantuan, contone, kita ngawasi kahanan DNS ing kluster: kita goleki polong coredns bodho, mriksa kasedhiyan host eksternal. Iku bakal katon sing kok keganggu karo iki, nanging karo volume gedhe saka lalu lintas komponen iki minangka titik serius saka Gagal. aku wis , carane aku berjuang karo kinerja DNS ing kluster.
- Operator Prometheus. Sakumpulan eksportir sing beda menehi gambaran gedhe babagan kabeh komponen kluster. Sabanjure, kita nggambarake kabeh iki ing dashboard gedhe ing Grafana, lan nggunakake alertmanager kanggo tandha.
Alat liyane sing migunani kanggo kita yaiku . We wrote iku sawise kaping pirang-pirang kita nemokke kahanan ngendi siji tim tumpang tindih dalan Ingress tim liyane, asil ing 50x kasalahan. Saiki sadurunge nyebarake menyang produksi, pangembang mriksa manawa ora ana sing bakal kena pengaruh, lan kanggo timku iki minangka alat sing apik kanggo diagnosis awal masalah karo Ingresses. Pancen lucu yen wiwitane ditulis kanggo admin lan katon rada "kikuk", nanging sawise tim dev tresna karo alat kasebut, mula saya ganti lan katon ora kaya "admin nggawe pasuryan web kanggo admin. ” Ora suwe, kita bakal ninggalake alat iki lan kahanan kasebut bakal divalidasi sanajan sadurunge pipa diluncurake.
Sumber daya tim ing Cube
Sadurunge kita menyang conto, iku worth nerangake carane kita nyedhiakke sumber daya kanggo layanan mikro.
Kanggo ngerti tim lan jumlah apa sing digunakake sumber daya (prosesor, memori, SSD lokal), kita nyedhiakke saben printah dhewe namespace ing "Cube" lan matesi kabisan maksimum ing syarat-syarat prosesor, memori lan disk, wis sadurunge rembugan kabutuhan tim. Patut, siji printah, ing umum, ora bakal mblokir kabeh cluster kanggo penyebaran prajurit, allocating ewu intine lan terabyte memori. Akses menyang namespace diwenehake liwat AD (kita nggunakake RBAC). Namespaces lan watesan sing ditambahake liwat panjalukan narik menyang repositori GIT, banjur kabeh kanthi otomatis digulung liwat pipa Ansible.
Conto ngalokasi sumber daya menyang tim:
namespaces:
chat-team:
pods: 23
limits:
cpu: 11
memory: 20Gi
requests:
cpu: 11
memory: 20Gi
Panjaluk lan watesan
Kubus" request punika nomer dijamin sumber daya dilindhungi undhang-undhang kanggo pod (siji utawa luwih wadhah docker) ing kluster. Limit punika maksimum non-dijamin. Sampeyan kerep bisa ndeleng ing grafik carane sawetara tim wis nyetel dhewe akeh banget panjalukan kanggo kabeh aplikasi lan ora bisa masang aplikasi kanggo "Cube", amarga kabeh panjalukan ing jeneng sing wis "ngginakaken".
Cara sing bener metu saka kahanan iki yaiku kanggo ndeleng konsumsi sumber daya nyata lan mbandhingake karo jumlah sing dijaluk (Request).
Ing gambar ing ndhuwur sampeyan bisa ndeleng manawa CPU "Dijaluk" cocog karo jumlah benang sing nyata, lan Watesan bisa ngluwihi jumlah benang CPU nyata =)
Saiki ayo ndeleng sawetara ruang jeneng kanthi rinci (Aku milih namespace kube-system - ruang jeneng sistem kanggo komponen "Cube" dhewe) lan deleng rasio wektu lan memori prosesor sing bener digunakake kanggo sing dijaluk:
Iku ketok sing luwih akeh memori lan CPU dilindhungi undhang-undhang kanggo layanan sistem saka bener digunakake. Ing kasus kube-sistem, iki sabdho: kedaden ing nginx ingress controller utawa nodelocaldns ing puncak sing mencet CPU lan migunakaken akèh RAM, supaya ing kene cadangan kuwi sabdho. Kajaba iku, kita ora bisa ngandelake grafik sajrone 3 jam pungkasan: luwih becik ndeleng metrik historis sajrone wektu sing suwe.
Sistem "rekomendasi" dikembangake. Contone, ing kene sampeyan bisa ndeleng sumber daya sing luwih apik kanggo ngunggahake "watesan" (garis ndhuwur sing diidini) supaya "throttling" ora kedadeyan: nalika sumber daya wis ngentekake CPU utawa memori kanggo irisan wektu sing diwenehake kanggo lan ngenteni nganti bakal "unfrozen":
Lan ing ngisor iki polong sing kudu nyegah napsu:
ing throttling + ngawasi sumber daya, sampeyan bisa nulis luwih saka siji artikel, mula takon pitakon ing komentar. Ing sawetara tembung, aku bisa ujar manawa tugas ngotomatisasi metrik kasebut angel banget lan mbutuhake akeh wektu lan tumindak keseimbangan kanthi fungsi "jendhela" lan "CTE" Prometheus / VictoriaMetrics (istilah kasebut ana ing kutipan, amarga meh ana ora kaya iki ing PromQL, lan sampeyan kudu dibagi pitakon medeni menyang sawetara layar teks lan ngoptimalake).
Akibaté, pangembang duwe alat kanggo ngawasi spasi jeneng ing Cube, lan bisa milih dhewe ing ngendi lan ing wektu apa aplikasi bisa "motong", lan server sing bisa diwenehi kabeh CPU ing wayah wengi.
Metodologi
Ing perusahaan kaya saiki modis, kita netepi DevOps- lan SRE- praktisi Nalika perusahaan duwe 1000 microservices, udakara 350 pangembang lan 15 admin kanggo kabeh infrastruktur, sampeyan kudu "modis": ing mburi kabeh "baswords" iki ana kabutuhan urgent kanggo ngotomatisasi kabeh lan kabeh wong, lan admin ngirim ora dadi bottleneck. ing pangolahan.
Minangka Ops, kita nyedhiyakake macem-macem metrik lan dasbor kanggo pangembang sing ana gandhengane karo tingkat tanggapan lan kesalahan layanan.
Kita nggunakake metodologi kayata: , и kanthi nggabungake bebarengan. Kita nyoba kanggo nyilikake jumlah dashboards supaya ing Mirit cetha sing layanan saiki degradasi (contone, kode respon per detik, wektu respon dening persentil 99th), lan ing. Sanalika sawetara metrik anyar dadi perlu kanggo dashboard umum, kita langsung nggambar lan nambah.
Sewulan aku ora nggambar grafik. Iki mbokmenawa minangka tandha apik: tegese akeh "kepengin" wis diwujudake. Iku kedaden sing sak minggu aku bakal tarik sawetara graph anyar ing paling sapisan dina.
Asil asil kasebut larang regane amarga saiki pangembang arang banget menyang admin kanthi pitakon "ing endi ndeleng sawetara metrik."
Implementasi Service Mesh mung watara sudhut lan kudu nggawe urip luwih gampang kanggo kabeh wong, kolega saka Tools wis cedhak kanggo ngleksanakake abstrak "Istio wong sehat": siklus urip saben HTTP(s) request bakal katon ing ngawasi, lan iku mesthi bisa ngerti "ing tataran apa kabeh pecah" sajrone interaksi antar-layanan (lan ora mung). Langganan warta saka hub DomClick. =)
Dhukungan infrastruktur Kubernetes
Secara historis, kita nggunakake versi patched Kubespray - Peran sing bisa ditrapake kanggo nyebarake, nambah lan nganyari Kubernetes. Ing sawetara titik, dhukungan kanggo panginstalan non-kubeadm dipotong saka cabang utama, lan proses ngalih menyang kubeadm ora diusulake. Akibaté, perusahaan Southbridge nggawe garpu dhewe (karo dhukungan kubeadm lan fix cepet kanggo masalah kritis).
Proses nganyari kabeh kluster k8s katon kaya iki:
- Njupuk Kubespray saka Southbridge, mriksa karo thread kita, Merjim.
- We rolling metu nganyari kanggo Stress- "Kubus".
- Kita muter nganyari siji simpul ing wektu (ing Ansible iki "seri: 1") ing Dev- "Kubus".
- Kita nganyari Prod ana sore siji simpul ing wektu.
Ana rencana kanggo ngganti ing mangsa ngarep Kubespray kanggo soko luwih cepet lan pindhah menyang kubeadm.
Total kita duwe telung "Cubes": Stress, Dev lan Prod. Kita arep ngluncurake siji liyane (siyaga panas) Prod-"Cube" ing pusat data kapindho. Stress и Dev manggon ing "mesin virtual" (oVirt kanggo Stress lan maya VMWare kanggo Dev). Prod- "Cube" urip ing "logam gundhul": iki simpul identik karo 32 Utas CPU, 64-128 GB memori lan 300 GB SSD RAID 10 - ana 50 saka total. Telung simpul "tipis" darmabakti kanggo "master" Prod- "Kuba": 16 GB memori, 12 utas CPU.
Kanggo dodolan, kita luwih seneng nggunakake "logam gundhul" lan nyegah lapisan sing ora perlu kaya OpenStack: kita ora perlu "tanggi rame" lan CPU nyolong wektu. Lan kerumitan administrasi kira-kira tikel kaping pindho ing kasus OpenStack ing omah.
Kanggo CI / CD "Kubik" lan komponen infrastruktur liyane, kita nggunakake server GIT sing kapisah, Helm 3 (iku transisi sing rada nglarani saka Helm 2, nanging kita seneng banget karo pilihan kasebut. atom), Jenkins, Ansible lan Docker. Kita seneng cabang fitur lan penyebaran menyang lingkungan sing beda saka siji gudang.
kesimpulan
Iki, ing istilah umum, proses DevOps katon ing DomClick saka sudut pandang insinyur operasi. Artikel kasebut dadi kurang teknis tinimbang sing dikarepake: mula, tindakake warta DomClick ing Habré: bakal luwih akeh artikel "hardcore" babagan Kubernetes lan liya-liyane.
Source: www.habr.com