27. Abrëll op der Konferenz , als Deel vun der Rubrik "DevOps" gouf de Bericht "Autoscaling and Ressource Management in Kubernetes" gegeben. Et schwätzt iwwer wéi Dir K8s benotze kënnt fir eng héich Disponibilitéit vun Ären Uwendungen ze garantéieren an d'Peakleistung ze garantéieren.
Vun Traditioun si mir frou Iech ze presentéieren (44 Minutten, vill méi informativ wéi den Artikel) an den Haaptresumé an Textform. Gitt!
Loosst eis d'Thema vum Bericht Wuert fir Wuert analyséieren a vum Enn ufänken.
Kubernetes
Loosst eis soen datt mir Docker Container op eisem Host hunn. Fir wat? Fir Widderhuelbarkeet an Isolatioun ze garantéieren, wat am Tour fir einfach a gutt Asaz erlaabt, CI / CD. Mir hu vill esou Gefierer mat Container.
Wat bitt Kubernetes an dësem Fall?
- Mir stoppen un dës Maschinnen ze denken a fänken un mat der "Cloud" ze schaffen Cluster vu Container oder Pods (Gruppen vu Container).
- Ausserdeem denken mir net emol un eenzel Pods, awer verwalten méiоgréisser Gruppen. Esou héich-Niveau Primitiv erlaabt eis ze soen datt et eng Schabloun gëtt fir eng gewëssen Aarbechtslaascht ze lafen, an hei ass déi erfuerderlech Unzuel vun Instanzen fir se auszeféieren. Wa mir duerno d'Schabloun änneren, änneren all Instanzen.
- Mat der Hëllef vun deklarativ API Amplaz eng Sequenz vu spezifesche Kommandoen auszeféieren, beschreiwen mir d'"Struktur vun der Welt" (am YAML), déi vu Kubernetes erstallt gëtt. An nach eng Kéier: Wann d'Beschreiwung ännert, ännert sech och säin eigentleche Display.
Ressource Gestioun
cpu
Loosst eis nginx, php-fpm a mysql um Server lafen. Dës Servicer wäerten tatsächlech nach méi Prozesser lafen, jidderee vun deenen Rechenressourcen erfuerderen:
(d'Zuelen op der Rutsch sinn "Papageien", den abstrakte Besoin vun all Prozess fir Rechenkraaft)
Fir et méi einfach ze maachen mat dësem ze schaffen, ass et logesch Prozesser a Gruppen ze kombinéieren (zum Beispill all nginx Prozesser an eng Grupp "nginx"). En einfachen an offensichtleche Wee fir dëst ze maachen ass all Grupp an engem Container ze setzen:
Fir weiderzemaachen, musst Dir drun erënneren wat e Container ass (a Linux). Hir Erscheinung gouf méiglech gemaach dank dräi Schlësselfeatures am Kernel, déi viru laanger Zäit ëmgesat goufen: , и . A weider Entwécklung gouf duerch aner Technologien erliichtert (och praktesch "Muschelen" wéi Docker):
Am Kontext vum Rapport interesséiere mir eis nëmmen Cgruppen, well Kontrollgruppen den Deel vun der Funktionalitéit vu Behälter sinn (Docker, etc.) déi Ressourcemanagement implementéiert. Prozesser a Gruppen kombinéiert, wéi mir wollten, si Kontrollgruppen.
Loosst eis zréck op d'CPU Ufuerderunge fir dës Prozesser, an elo fir Gruppe vu Prozesser:
(Ech widderhuelen datt all Zuelen en abstrakte Ausdrock vun der Bedierfnes fir Ressourcen sinn)
Zur selwechter Zäit huet d'CPU selwer eng gewëssen endlech Ressource (am Beispill ass dëst 1000), déi jidderengem feele kann (d'Zomm vun de Besoine vun alle Gruppen ass 150+850+460=1460). Wat wäert an dësem Fall geschéien?
De Kär fänkt un Ressourcen ze verdeelen a mécht et "zimmlech", déi selwecht Quantitéit un Ressourcen un all Grupp ginn. Awer am éischte Fall sinn et méi wéi néideg (333>150), sou datt den Iwwerschoss (333-150=183) an der Reserve bleift, déi och gläichméisseg tëscht zwee aner Container verdeelt ass:
Als Resultat: den éischte Container hat genuch Ressourcen, déi zweet - et huet net genuch Ressourcen, déi drëtt - et huet net genuch Ressourcen. Dëst ass d'Resultat vun Aktiounen "éierlech" Scheduler am Linux - . Seng Operatioun kann mat der Aufgab ugepasst ginn Gewiichter jiddereng vun den Container. Zum Beispill, wéi dëst:
Loosst eis de Fall vun engem Mangel u Ressourcen am zweete Container (php-fpm) kucken. All Container Ressourcen sinn gläich tëscht Prozesser verdeelt. Als Resultat funktionnéiert de Masterprozess gutt, awer all Aarbechter verlangsamen, a kréien manner wéi d'Halschent vun deem wat se brauchen:
Dëst ass wéi den CFS Scheduler funktionnéiert. Mir wäerte weider d'Gewichte nennen, déi mir Container zouginn Demande. Firwat dat esou ass - kuckt weider.
Loosst eis déi ganz Situatioun vun der anerer Säit kucken. Wéi Dir wësst, féieren all Stroossen zu Roum, an am Fall vun engem Computer, op d'CPU. Eng CPU, vill Aufgaben - Dir braucht e Traffic Liicht. Deen einfachste Wee fir Ressourcen ze verwalten ass "Traffic Light": si hunn engem Prozess eng fix Zougangszäit op d'CPU ginn, dann deen nächsten, etc.
Dës Approche gëtt schwéier Quoten genannt (schwéier limitéiert). Loosst eis et einfach erënneren wéi Grenzen. Wéi och ëmmer, wann Dir Limiten op all Container verdeelt, entsteet e Problem: mysql war laanscht d'Strooss gefuer an iergendwann ass seng Bedierfnes fir CPU eriwwer, awer all aner Prozesser si gezwongen ze waarden bis d'CPU idle.
Loosst eis zréck op de Linux Kernel a seng Interaktioun mat der CPU - d'Gesamtbild ass wéi follegt:
cgroup huet zwee Astellungen - am Wesentlechen sinn dëst zwee einfach "Twists" déi Iech erlaben ze bestëmmen:
- Gewiicht fir Container (Ufroen) ass Aktien;
- Prozentsaz vun der total CPU Zäit fir eng Aarbecht op Container Aufgaben (Limiten) ass Kontingent.
Wéi moosst CPU?
Et gi verschidde Weeër:
- wat Papageien, Keen weess - Dir musst all Kéier verhandelen.
- Interesse méi kloer, awer relativ: 50% vun engem Server mat 4 Kären a mat 20 Käre si komplett verschidde Saachen.
- Dir kënnt déi schonn ernimmt benotzen Gewiichter, déi Linux weess, awer si sinn och relativ.
- Déi adäquat Optioun ass d'Rechenressourcen ze moossen Sekonnen. Déi. a Sekonnen Prozessor Zäit relativ zu Sekonnen vun Echtzäit: 1 Sekonn Prozessor Zäit gouf pro 1 Echt Sekonn uginn - dëst ass e ganze CPU Kär.
Fir et nach méi einfach ze schwätzen, hu si ugefaang direkt eran ze moossen Kären, Bedeitung vun hinnen déi selwecht CPU Zäit relativ zu der real. Zënter Linux versteet Gewiichter, awer net sou vill CPU Zäit / Kären, war e Mechanismus gebraucht fir vun engem op deen aneren ze iwwersetzen.
Loosst eis en einfacht Beispill mat engem Server mat 3 CPU Cores betruechten, wou dräi Pods Gewiichter ginn (500, 1000 an 1500) déi einfach an déi entspriechend Deeler vun de Cores ëmgewandelt ginn, déi hinnen zougewisen sinn (0,5, 1 an 1,5).
Wann Dir en zweete Server hëlt, wou et duebel sou vill Käre gëtt (6), an déi selwecht Pods do setzen, kann d'Verdeelung vun de Kären einfach berechent ginn andeems Dir einfach mat 2 multiplizéiert (bzw. 1, 2 an 3). Awer e wichtege Moment geschitt wann e véierte Pod op dësem Server erschéngt, deem säi Gewiicht, fir d'Bequemlechkeet, 3000 ass. Et hëlt en Deel vun den CPU-Ressourcen ewech (Halschent vun de Cores), a fir déi verbleiwen Pods gi se nei berechent (halbéiert):
Kubernetes an CPU Ressourcen
A Kubernetes ginn CPU Ressourcen normalerweis gemooss milliadrax, d.h. 0,001 Käre ginn als Basisgewiicht geholl. (Déi selwecht Saach an der Linux / cgroups Terminologie gëtt e CPU Share genannt, obwuel, méi präzis, 1000 Millicores = 1024 CPU Shares.) K8s garantéiert datt et net méi Pods op de Server plazéiert wéi et CPU Ressourcen fir d'Zomm vun de Gewiichter vun all Pods.
Wéi geschitt dat? Wann Dir e Server an e Kubernetes Cluster bäidréit, gëtt gemellt wéivill CPU Cores et verfügbar ass. A wann Dir en neie Pod erstellt, weess de Kubernetes Scheduler wéivill Kären dëse Pod brauch. Sou gëtt de Pod un engem Server zougewisen wou et genuch Käre gëtt.
Wat geschitt wann Net Ufro ass spezifizéiert (dh de Pod huet keng definéiert Unzuel u Kären déi se brauch)? Loosst eis erausfannen wéi Kubernetes allgemeng Ressourcen zielt.
Fir e Pod kënnt Dir béid Ufroen (CFS Scheduler) a Limiten spezifizéieren (erënnert Iech un de Verkéierlicht?):
- Wa se gläich spezifizéiert sinn, da gëtt de Pod eng QoS Klass zougewisen garantéiert. Dës Zuel vu Kären ëmmer verfügbar ass garantéiert.
- Wann d'Ufro manner wéi d'Limite ass - QoS Klass burstable. Déi. Mir erwaarden datt e Pod zum Beispill ëmmer 1 Kär benotzt, awer dëse Wäert ass keng Limitatioun dofir: heiansdo Pod ka méi benotzen (wann de Server gratis Ressourcen dofir huet).
- Et gëtt och eng QoS Klass beschte Effort - et enthält déi ganz Pods fir déi d'Ufro net spezifizéiert ass. Ressourcen ginn hinnen lescht.
Erënnerung
Mat Erënnerung ass d'Situatioun ähnlech, awer liicht anescht - schliisslech ass d'Natur vun dëse Ressourcen anescht. Am Allgemengen ass d'Analogie wéi follegt:
Loosst eis kucken wéi Ufroen an der Erënnerung ëmgesat ginn. Loosst d'pods liewen op de Server, änneren Erënnerung Konsum, bis ee vun hinnen esou grouss gëtt, datt et aus Erënnerung leeft. An dësem Fall erschéngt den OOM Killer a killt de gréisste Prozess:
Dat passt eis net ëmmer, dofir ass et méiglech ze regléieren, wéi eng Prozesser fir eis wichteg sinn an net ëmbruecht ginn. Fir dëst ze maachen, benotzt de Parameter oom_score_adj.
Komme mer zréck op d'QoS Klassen vun der CPU an zéien eng Analogie mat den oom_score_adj Wäerter déi d'Speicherverbrauch Prioritéite fir Pods bestëmmen:
- Den niddregsten oom_score_adj Wäert fir e Pod - -998 - bedeit datt esou en Pod fir d'lescht ëmbruecht soll ginn, dëst garantéiert.
- Déi héchste - 1000 - ass beschte Effort, esou Pods ginn als éischt ëmbruecht.
- Fir déi verbleiwen Wäerter ze berechnen (burstable) et gëtt eng Formel, d'Essenz vun där op d'Tatsaach dréit datt wat méi Ressourcen e Pod gefrot huet, wat manner wahrscheinlech et ëmbruecht gëtt.
Déi zweet "Twist" - limit_in_bytes - fir Grenzen. Mat et ass alles méi einfach: mir ginn einfach de maximalen Betrag vun der erausginn Erënnerung zou, an hei (am Géigesaz zu der CPU) ass et keng Fro wéi et ze moossen (Erënnerung).
Total
All Pod an Kubernetes gëtt requests и limits - béid Parameter fir CPU an Erënnerung:
- baséiert op Ufroen, funktionnéiert de Kubernetes Scheduler, deen Pods tëscht Serveren verdeelt;
- baséiert op all Parameteren, gëtt d'QoS Klass vum Pod bestëmmt;
- Relativ Gewiichter sinn berechent baséiert op CPU Demanden;
- den CFS Scheduler ass konfiguréiert baséiert op CPU Ufroen;
- OOM Killer ass konfiguréiert baséiert op Erënnerung Ufroen;
- engem "Traffic Luucht" baséiert op CPU Grenzen konfiguréiert;
- Baséierend op Erënnerungsgrenze gëtt eng Limit fir d'cgroup konfiguréiert.
Am Allgemengen äntwert dëst Bild all d'Froen iwwer wéi den Haaptdeel vun der Ressourceverwaltung an Kubernetes geschitt.
Autoskaléieren
K8s Cluster-Autoscaler
Loosst eis virstellen, datt de ganze Cluster scho besat ass an en neie Pod muss geschaf ginn. Iwwerdeems de Pod net erschéngen kann, hänkt et am Status Erwaardung. Fir datt et erschéngt, kënne mir en neie Server mam Cluster verbannen oder ... Cluster-Autoscaler installéieren, deen et fir eis mécht: eng virtuell Maschinn vum Cloud Provider bestellen (mat enger API-Ufro) a verbannen se mam Cluster , duerno gëtt de Pod dobäigesat.
Dëst ass Autoscaling vum Kubernetes Cluster, wat super funktionnéiert (an eiser Erfahrung). Allerdéngs, wéi soss anzwousch, ginn et e puer Nuancen hei ...
Soulaang wéi mir de Stärekoup Gréisst vergréissert, alles war gutt, mee wat geschitt wann de Stärekoup ugefaang selwer ze befreien? De Problem ass datt d'Migratioun vu Pods (fir Hosten ze befreien) ganz technesch schwéier an deier ass wat d'Ressourcen ugeet. Kubernetes benotzt eng ganz aner Approche.
Betruecht e Stärekoup vun 3 Serveren déi Deployment hunn. Et huet 6 Pods: elo sinn et 2 fir all Server. Aus iergendengem Grond wollte mir ee vun de Serveren ausschalten. Fir dëst ze maachen benotze mir de Kommando kubectl drain, déi:
- wäert verbidden nei Pods op dëse Server ze schécken;
- wäert existéierend Pods um Server läschen.
Zënter Kubernetes ass verantwortlech fir d'Zuel vun de Pods (6) z'erhalen, ass et einfach wäert nei schafen se op aner Wirbelen, awer net op deem deen deaktivéiert ass, well et scho markéiert ass als net verfügbar fir nei Pods ze hosten. Dëst ass e fundamentale Mechaniker fir Kubernetes.
Allerdéngs gëtt et och hei eng Nuance. An enger ähnlecher Situatioun, fir StatefulSet (amplaz vun Deployment), wäerten d'Aktiounen anescht sinn. Elo hu mir schonn eng statesch Applikatioun - zum Beispill dräi Pods mat MongoDB, vun deenen een eng Zort Problem huet (d'Date si korrupt ginn oder en anere Feeler deen verhënnert datt de Pod richteg ufänkt). A mir décidéieren erëm e Server auszeschalten. Wat wäert geschéien?
MongoDB kéint stierwen well et e Quorum brauch: fir e Stärekoup vun dräi Installatiounen mussen op d'mannst zwee funktionnéieren. Allerdéngs ass dëst net geschitt - merci PodDisruptionBudget. Dëse Parameter bestëmmt d'minimal erfuerderlech Unzuel vun Aarbechtsstécker. Wësse datt ee vun de MongoDB Pods net méi funktionnéiert, a gesinn datt de PodDisruptionBudget fir MongoDB gesat ass minAvailable: 2, Kubernetes erlaabt Iech net e Pod ze läschen.
Bottom Line: Fir datt d'Bewegung (an tatsächlech d'Neischafung) vu Pods richteg funktionnéiert wann de Cluster verëffentlecht gëtt, ass et néideg PodDisruptionBudget ze konfiguréieren.
Horizontal Skala
Loosst eis eng aner Situatioun betruechten. Et gëtt eng Applikatioun déi als Deployment a Kubernetes leeft. De Benotzerverkéier kënnt op seng Pods (zum Beispill, et ginn dräi vun hinnen), a mir moossen e gewëssen Indikator an hinnen (soen CPU-Laascht). Wann d'Laascht eropgeet, notéiere mir et op engem Zäitplang an erhéijen d'Zuel vun de Pods fir Ufroen ze verdeelen.
Haut zu Kubernetes muss dat net manuell gemaach ginn: eng automatesch Erhéijung / Ofsenkung vun der Zuel vun de Pods ass konfiguréiert ofhängeg vun de Wäerter vun de gemoossene Lastindikatoren.
D'Haaptfroen hei sinn: wat genee ze moossen и wéi ze interpretéieren kritt Wäerter (fir eng Entscheedung ze huelen fir d'Zuel vun de Pods z'änneren). Dir kënnt vill moossen:
Wéi maachen ech dat technesch - sammelen Metriken, etc. - Ech hunn am Detail am Bericht iwwer geschwat . An den Haaptrot fir déi optimal Parameteren ze wielen ass experimentéieren!
et ginn (Utilisatioun Saturatioun a Feeler), d'Bedeitung vun deem ass wéi follegt. Op wéi enger Basis mécht et Sënn fir ze skaléieren, zum Beispill php-fpm? Baséierend op der Tatsaach, datt d'Aarbechter lafe sinn, ass dëst Utilisatioun. A wann d'Aarbechter eriwwer sinn an nei Verbindungen net ugeholl ginn, ass dat schonn Sonn ass. Béid vun dëse Parameter musse gemooss ginn, an ofhängeg vun de Wäerter muss d'Skaléierung duerchgefouert ginn.
Amplaz vun enger Konklusioun
De Bericht huet eng Fortsetzung: iwwer vertikal Skala a wéi Dir déi richteg Ressourcen auswielen. Ech wäert iwwer dëst an zukünfteg Videoen schwätzen - abonnéiert fir datt Dir net verpasst!
Videoen a Rutschen
Video vum Optrëtt (44 Minutten):
Presentatioun vum Rapport:
PS
Aner Berichter iwwer Kubernetes op eisem Blog:
- «» (Andrey Polovov; Abrëll 8, 2019 op Saint HighLoad++);
- «» (Dmitry Stolyarov; 8. November 2018 op HighLoad++);
- «» (Dmitry Stolyarov; Mee 28, 2018 bei RootConf);
- «» (Dmitry Stolyarov; 7. November 2017 op HighLoad++);
- «» (Dmitry Stolyarov; Juni 6, 2017 bei RootConf).
Source: will.com