Autoscaling sareng manajemén sumberdaya di Kubernetes (Tinjauan sareng laporan video)

27 April dina konférénsi éta Mogok 2019, salaku bagian tina bagian "DevOps", laporan "Autoscaling sarta manajemén sumberdaya di Kubernetes" dibikeun. Ieu ceramah ngeunaan kumaha anjeun tiasa nganggo K8s pikeun mastikeun kasadiaan tinggi aplikasi anjeun sarta mastikeun kinerja puncak.

Ku tradisi, kami resep nampilkeun video laporan (44 menit, leuwih informatif ti artikel) jeung kasimpulan utama dina wangun téks. indit!

Hayu urang nganalisis topik laporan kecap ku kecap tur mimitian ti tungtung.

Kubernetes

Anggap urang gaduh wadah Docker dina host kami. Kanggo naon? Pikeun mastikeun repeatability na isolasi, anu dina gilirannana ngidinan pikeun deployment basajan tur alus, CI / CD. Kami ngagaduhan seueur kendaraan sapertos kontainer.

Naon anu disayogikeun ku Kubernetes dina hal ieu?

1. Urang ngeureunkeun pamikiran ngeunaan mesin ieu sareng mimitian damel sareng "awan" gugusan wadahna atawa polong (golongan wadah).
2. Leuwih ti éta, urang malah teu mikir ngeunaan pods individu, tapi ngatur leuwihоgrup gedé. Sapertos primitif tingkat luhur ngidinan urang disebutkeun yen aya template pikeun ngajalankeun hiji workload tangtu, sarta di dieu nyaeta jumlah diperlukeun tina instansi pikeun ngajalankeun eta. Upami urang saterasna ngarobih témplat, sadaya instansi bakal robih.
3. jeung API déklaratif Gantina ngajalankeun runtuyan paréntah husus, urang ngajelaskeun "struktur dunya" (dina YAML), nu dijieun ku Kubernetes. Sareng deui: nalika katerangan robih, tampilan saleresna ogé bakal robih.

Manajemén sumberdaya

CPU

Hayu urang ngajalankeun nginx, php-fpm sareng mysql dina server. Ladenan ieu saleresna bakal langkung seueur prosés anu dijalankeun, anu masing-masing butuh sumber daya komputasi:

(angka-angka dina slide nyaéta "beo", kabutuhan abstrak unggal prosés pikeun kakuatan komputasi)

Pikeun ngagampangkeun damel sareng ieu, logis pikeun ngagabungkeun prosés kana grup (contona, sadaya prosés nginx kana hiji grup "nginx"). Cara anu saderhana sareng atra pikeun ngalakukeun ieu nyaéta nempatkeun unggal grup dina wadah:

Pikeun neraskeun, anjeun kedah émut naon wadahna (dina Linux). Penampilanna dimungkinkeun berkat tilu fitur konci dina kernel, dilaksanakeun parantos lami pisan: kamampuhan, ngaranspasi и cgroups. Sareng pamekaran salajengna difasilitasi ku téknologi sanés (kalebet "cangkang" anu merenah sapertos Docker):

Dina konteks laporan, urang ngan museurkeun cgroups, sabab grup kontrol mangrupakeun bagian tina pungsionalitas wadahna (Docker, jsb) nu implements manajemén sumberdaya. Prosés digabungkeun kana grup, sakumaha urang hayang, mangrupakeun grup kontrol.

Hayu urang balik deui ka syarat CPU pikeun prosés ieu, sareng ayeuna pikeun grup prosés:

(Kuring ngulang deui yén sadaya nomer mangrupikeun éksprési abstrak ngeunaan kabutuhan sumber daya)

Dina waktos anu sami, CPU sorangan gaduh sumber daya anu terbatas (dina conto ieu 1000), nu bisa jadi kakurangan sadayana (jumlah kabutuhan sadaya grup nyaéta 150+850+460=1460). Naon anu bakal kajadian dina hal ieu?

Kernel mimiti ngadistribusikaeun sumber daya jeung ngalakukeun eta "cukup", mere jumlah sarua sumberdaya ka unggal grup. Tapi dina kasus nu pertama, aya leuwih ti diperlukeun (333> 150), jadi kaleuwihan (333-150=183) tetep dina cadangan, nu ogé disebarkeun merata antara dua wadah séjén:

Hasilna: wadah kahiji boga cukup sumberdaya, kadua - teu boga cukup sumberdaya, katilu - teu boga cukup sumberdaya. Ieu hasil tina lampah "jujur" scheduler dina Linux - CFS. Operasina tiasa disaluyukeun nganggo tugas beurat masing-masing wadahna. Contona, saperti kieu:

Hayu urang tingali dina kasus kakurangan sumberdaya dina wadah kadua (php-fpm). Kabéh sumberdaya wadahna disebarkeun sarua antara prosés. Hasilna, prosés master berpungsi saé, tapi sadaya pagawé ngalambatkeun, nampi kirang ti satengah tina anu diperyogikeun:

Ieu kumaha CFS scheduler jalan. Urang salajengna bakal nelepon beurat nu urang napelkeun kana peti pamundut. Naha ieu kitu - tingali salajengna.

Hayu urang nempo sakabeh kaayaan ti sisi séjén. Sakumaha anjeun terang, sadaya jalan nuju ka Roma, sareng dina kasus komputer, ka CPU. Hiji CPU, seueur tugas - anjeun peryogi lampu lalu lintas. Cara pangbasajanna pikeun ngatur sumberdaya nyaéta "lampu lalu lintas": aranjeunna masihan hiji prosés waktos aksés tetep ka CPU, teras salajengna, jsb.

Pendekatan ieu disebut kuota teuas (watesan teuas). Hayu urang nginget eta saukur salaku wates. Nanging, upami anjeun ngadistribusikaeun wates ka sadaya wadah, timbul masalah: mysql nyetir sapanjang jalan sareng dina waktos anu peryogina pikeun CPU réngsé, tapi sadaya prosés sanésna kedah ngantosan dugi ka CPU. dianggurkeun.

Hayu urang uih deui ka kernel Linux sareng interaksina sareng CPU - gambaran umumna sapertos kieu:

cgroup gaduh dua setélan - dasarna ieu dua "twists" saderhana anu ngamungkinkeun anjeun pikeun nangtukeun:

1. beurat pikeun wadah (requests) nyaeta biasa;
2. perséntase total waktu CPU pikeun digawé dina tugas wadahna (wates) mangrupa batesan.

Kumaha ngukur CPU?

Aya sababaraha cara:

1. naon parrots, Teu aya anu terang - anjeun kedah negotiate unggal waktos.
2. Minat jelas, tapi relatif: 50% tina server kalawan 4 cores sarta kalawan 20 cores mangrupakeun hal lengkep beda.
3. Anjeun tiasa nganggo anu parantos disebatkeun beurat, anu terang Linux, tapi aranjeunna ogé relatif.
4. Pilihan anu paling nyukupan nyaéta pikeun ngukur sumber daya komputasi detik. Jelema-jelema. dina detik waktu processor relatif ka detik real-time: 1 detik waktu processor ieu dibikeun per 1 detik nyata - ieu téh hiji sakabéh inti CPU.

Pikeun ngagampangkeun nyarios, aranjeunna mimiti ngukur langsung kernels, hartina ku aranjeunna waktos CPU sarua relatif ka nyata. Kusabab Linux ngartos beurat, tapi henteu seueur waktos CPU / inti, mékanisme anu diperyogikeun pikeun narjamahkeun tina hiji ka anu sanés.

Hayu urang nganggap conto basajan kalawan server kalawan 3 cores CPU, dimana tilu pods bakal dibere beurat (500, 1000 jeung 1500) nu gampang dirobah kana bagian pakait tina cores disadiakeun pikeun aranjeunna (0,5, 1 jeung 1,5).

Lamun nyokot server kadua, dimana bakal aya dua kali loba cores (6), sarta nempatkeun pods sarua aya, sebaran cores bisa gampang diitung ku ukur ngalikeun 2 (1, 2 jeung 3). Tapi momen penting lumangsung nalika pod kaopat mucunghul dina server ieu, anu beuratna, pikeun genah, bakal 3000. Butuh jauh bagian tina sumberdaya CPU (satengah cores), sarta pikeun pods sésana maranéhna recalculated (halved):

Kubernetes jeung sumber CPU

Dina Kubernetes, sumberdaya CPU biasana diukur dina milliadrax, i.e. 0,001 cores dicokot salaku beurat dasar. (Hal anu sami dina terminologi Linux/cgroups disebut pangsa CPU, sanaos, langkung tepatna, 1000 millicores = 1024 saham CPU.) K8s ensures nu teu nempatkeun leuwih pods on server ti aya sumberdaya CPU pikeun jumlah beurat sadaya pods.

Kumaha ieu kajadian? Nalika anjeun nambihan server kana klaster Kubernetes, dilaporkeun sabaraha inti CPU anu sayogi. Sareng nalika nyiptakeun pod énggal, penjadwal Kubernetes terang sabaraha inti anu diperyogikeun ku pod ieu. Ku kituna, pod bakal ditugaskeun ka server dimana aya cukup cores.

Naon anu bakal kajadian lamun teu pamundut dieusian (ie pod nu teu boga jumlah diartikeun cores eta perlu)? Hayu urang terang kumaha Kubernetes umumna ngitung sumberdaya.

Pikeun pod a Anjeun bisa nangtukeun duanana requests (CFS scheduler) jeung wates (inget lampu lalulintas?):

• Mun aranjeunna dieusian sarua, lajeng pod ditugaskeun kelas QoS dijamin. Jumlah cores ieu salawasna sadia pikeun eta dijamin.
• Lamun pamundut kirang ti wates - kelas QoS burstable. Jelema-jelema. Urang ngaharepkeun pod a, contona, salawasna ngagunakeun 1 inti, tapi nilai ieu teu watesan pikeun eta: sakapeung pod bisa make leuwih (lamun server boga sumberdaya bébas pikeun ieu).
• Aya ogé kelas QoS usaha pangsaéna - éta kalebet polong anu henteu dipénta. Sumberdaya dibikeun ka aranjeunna panungtungan.

ingetan

Kalayan mémori, kaayaanna sami, tapi rada béda - saatosna, sifat sumber daya ieu béda. Sacara umum, analogi nyaéta kieu:

Hayu urang tingali kumaha requests dilaksanakeun dina mémori. Hayu pods hirup dina server, ngarobah konsumsi memori, nepi ka salah sahijina meunang jadi badag nu ngalir kaluar memori. Dina hal ieu, pembunuh OOM muncul sareng maéhan prosés panggedéna:

Ieu henteu salawasna cocog pikeun urang, jadi kasebut nyaéta dimungkinkeun pikeun ngatur prosés nu penting pikeun urang jeung teu kudu dipaéhan. Jang ngalampahkeun ieu, nganggo parameter oom_score_adj.

Hayu urang uih deui ka kelas QoS CPU sareng ngagambar analogi sareng nilai oom_score_adj anu nangtukeun prioritas konsumsi mémori pikeun pods:

• Nilai oom_score_adj panghandapna pikeun pod - -998 - hartina pod kitu kudu dipaehan panungtungan, ieu dijamin.
• Pangluhurna - 1000 - nyaéta usaha pangsaéna, polong sapertos dipaehan heula.
• Pikeun ngitung nilai sésana (burstable) aya rumus, hakekat nu bisul kana kanyataan yén beuki sumberdaya a pod geus dipénta, nu kurang kamungkinan éta pikeun ditelasan.

The kadua "pulas" - limit_in_bytes - pikeun wates. Kalayan éta, sadayana langkung saderhana: urang ngan ukur napelkeun jumlah maksimal mémori anu dikaluarkeun, sareng di dieu (teu sapertos CPU) henteu aya patarosan kumaha ngukurna (memori).

dina total

Unggal pod di Kubernetes dibéré requests и limits - duanana parameter pikeun CPU sareng mémori:

1. dumasar kana pamundut, scheduler Kubernetes jalan, nu distributes pods diantara server;
2. dumasar kana sagala parameter, kelas QoS pod urang ditangtukeun;
3. beurat relatif diitung dumasar kana requests CPU;
4. scheduler CFS geus ngonpigurasi dumasar kana requests CPU;
5. Killer OOM dikonpigurasi dumasar kana pamundut memori;
6. a "lampu lalulintas" geus ngonpigurasi dumasar kana wates CPU;
7. Dumasar wates memori, wates a ngonpigurasi pikeun cgroup nu.

Sacara umum, gambar ieu ngajawab sagala patarosan ngeunaan kumaha bagian utama manajemén sumberdaya lumangsung dina Kubernetes.

Autoscaling

K8s klaster-autoscaler

Hayu urang bayangkeun yén sadaya kluster parantos dijajah sareng pod énggal kedah didamel. Bari pod teu bisa muncul, éta hangs dina status sabari nunggu. Pikeun némbongan, urang tiasa nyambungkeun server anyar kana klaster atawa ... install klaster-autoscaler, nu bakal ngalakukeun eta pikeun urang: mesen mesin virtual ti panyadia awan (ngagunakeun hiji pamundut API) tur sambungkeun ka klaster. , sanggeus éta pod bakal ditambahkeun.

Ieu mangrupikeun skala otomatis tina klaster Kubernetes, anu tiasa dianggo saé (dina pangalaman urang). Nanging, sapertos di tempat sanés, aya sababaraha nuansa di dieu ...

Salami kami ngaronjat ukuran klaster, sagalana éta rupa, tapi naon anu lumangsung nalika klaster mimiti ngabébaskeun dirina? Masalahna nyaéta migrasi pods (pikeun ngosongkeun host) sacara téknis hésé pisan sareng mahal tina segi sumber. Kubernetes ngagunakeun pendekatan lengkep béda.

Pertimbangkeun klaster 3 server anu gaduh Deployment. Cai mibanda 6 pods: ayeuna aya 2 pikeun tiap server. Kanggo sababaraha alesan urang hoyong mareuman salah sahiji server. Jang ngalampahkeun ieu kami bakal ngagunakeun paréntah kubectl drain, anu:

• bakal ngalarang ngirim pods anyar ka server ieu;
• bakal ngahapus pods aya dina server.

Kusabab Kubernetes tanggung jawab pikeun ngajaga jumlah pods (6), ngan saukur bakal nyieun deui aranjeunna dina titik anu sanés, tapi henteu dina anu ditumpurkeun, sabab éta parantos ditandaan salaku henteu sayogi pikeun hosting pod anyar. Ieu mékanis dasar pikeun Kubernetes.

Nanging, aya ogé nuansa di dieu. Dina kaayaan anu sami, pikeun StatefulSet (gaganti Deployment), tindakanna bakal béda. Ayeuna kami parantos ngagaduhan aplikasi stateful - contona, tilu pods sareng MongoDB, salah sahijina ngagaduhan sababaraha masalah (data parantos rusak atanapi kasalahan sanésna anu nyegah pod tina ngamimitian leres). Sarta kami deui mutuskeun nganonaktipkeun hiji server. Naon anu bakal kajadian?

MongoDB bisa maot sabab perlu quorum a: pikeun klaster tilu pamasangan, sahenteuna dua kudu fungsi. Sanajan kitu, ieu henteu lumangsung - hatur nuhun ka PodDisruptionBudget. Parameter ieu nangtukeun jumlah minimum diperlukeun tina pods gawé. Nyaho yén salah sahiji pods MongoDB teu tiasa dianggo deui, sareng ningali yén PodDisruptionBudget disetel pikeun MongoDB minAvailable: 2, Kubernetes moal ngidinan Anjeun mupus pod a.

Garis handap: supados gerakan (sareng kanyataanna, nyiptakeun ulang) polong tiasa leres nalika kluster dileupaskeun, perlu pikeun ngonpigurasikeun PodDisruptionBudget.

Skala horizontal

Hayu urang nganggap kaayaan sejen. Aya hiji aplikasi ngajalankeun sakumaha Deployment di Kubernetes. Lalu lintas pamaké datang ka pods na (contona, aya tilu di antarana), sarta kami ngukur hiji indikator tangtu di antarana (sebutkeun, beban CPU). Nalika beban ningkat, urang ngarékam éta dina jadwal sareng ningkatkeun jumlah pod pikeun ngadistribusikaeun pamundut.

Kiwari di Kubernetes ieu henteu kedah dilakukeun sacara manual: paningkatan otomatis / panurunan dina jumlah pod dikonpigurasi gumantung kana nilai indikator beban anu diukur.

Patarosan utama di dieu nyaéta: naon kahayang pikeun ngukur и kumaha nafsirkeun nilai diala (pikeun nyieun kaputusan ngeunaan ngarobah jumlah pods). Anjeun tiasa ngukur seueur:

Kumaha ngalakukeun ieu téhnisna - ngumpulkeun metrics, jsb. - Kuring spoke di jéntré dina laporan ngeunaan Ngawaskeun sarta Kubernetes. Sareng saran utama pikeun milih parameter optimal nyaéta percobaan!

aya Maké métode (Utilization Saturasi sareng Kasalahan), hartina saperti ieu di handap. Dina dasar naon éta masuk akal pikeun skala, contona, php-fpm? Dumasar kana kanyataan yén pagawe keur ngajalankeun kaluar, ieu téh garapan. Sareng upami padamel parantos réngsé sareng sambungan énggal henteu ditampi, ieu parantos jenuh. Kadua parameter ieu kedah diukur, sareng gumantung kana nilai, skala kedah dilaksanakeun.

Gantina kacindekan

Laporan éta gaduh tuluyan: ngeunaan skala vertikal sareng kumaha milih sumber anu leres. Kuring bakal ngobrol ngeunaan ieu dina video hareup on YouTube urang - ngalanggan supados anjeun teu sono!

Video sareng slide

Video tina pagelaran (44 menit):

Presentasi laporan:

PS

Laporan séjén ngeunaan Kubernetes dina blog kami:

• «Ngalegaan sareng ngalengkepan Kubernetes» (Andrey Polovov; 8 April 2019 dina Saint HighLoad++);
• «Basis data sareng Kubernetes» (Dmitry Stolyarov; 8 Nopémber 2018 dina HighLoad++);
• «Ngawaskeun sarta Kubernetes» (Dmitry Stolyarov; 28 Méi 2018 di RootConf);
• «Praktek Pangalusna CI/CD sareng Kubernetes sareng GitLab» (Dmitry Stolyarov; 7 Nopémber 2017 dina HighLoad++);
• «Pangalaman urang sareng Kubernetes dina proyék-proyék leutik» (Dmitry Stolyarov; 6 Juni 2017 di RootConf).

sumber: www.habr.com