Note. iwwersat.: Dës opfälleg Geschicht vum Omio - en europäesche Reesaggregator - hëlt d'Lieser vun der Basistheorie op déi faszinéierend praktesch Intricacies vun der Kubernetes Konfiguratioun. Bekanntheet mat esou Fäll hëlleft net nëmmen Ären Horizont ze erweideren, awer och net-trivial Problemer ze verhënneren.
Hutt Dir jeemools eng Applikatioun op der Plaz hänke bliwwen, ophalen op Gesondheetskontrollen ze reagéieren, an net fäeg erauszefannen firwat? Eng méiglech Erklärung ass Zesummenhang mat CPU Ressource Quote Grenzen. Dëst ass wat mir an dësem Artikel schwätzen.
TL; DR:
Mir recommandéieren d'CPU Limiten an Kubernetes auszeschalten (oder CFS Quoten an Kubelet auszeschalten) wann Dir eng Versioun vum Linux Kernel mat engem CFS Quote Käfer benotzt. Am Kär sérieux an e Feeler deen zu exzessive Drossel a Verspéidungen féiert.
An Omio déi ganz Infrastruktur gëtt vu Kubernetes geréiert. All eis statesch a stateless Aarbechtslaascht lafen exklusiv op Kubernetes (mir benotze Google Kubernetes Engine). An de leschte sechs Méint hu mir ugefaang zoufälleg Verlängerungen ze beobachten. Uwendungen afréieren oder stoppen op Gesondheetschecken ze reagéieren, d'Verbindung mam Netz verléieren, asw. Dëst Verhalen huet eis fir eng laang Zäit verwonnert, a schlussendlech hu mir decidéiert de Problem eescht ze huelen.
Resumé vum Artikel:
- E puer Wierder iwwer Container a Kubernetes;
- Wéi CPU Ufroen a Limiten ëmgesat ginn;
- Wéi CPU Limite Wierker an Multi-Kär Ëmfeld;
- Wéi verfollegen d'CPU Drossel;
- Problem Léisung an Nuancen.
E puer Wierder iwwer Container a Kubernetes
Kubernetes ass wesentlech de modernen Standard an der Infrastrukturwelt. Seng Haaptaufgab ass d'Containerorchestratioun.
Container
An der Vergaangenheet hu mir Artefakte wéi Java JARs / WARs, Python Eggs oder Ausféierbaren ze kreéieren fir op Serveren ze lafen. Wéi och ëmmer, fir se ze funktionnéieren, muss zousätzlech Aarbecht gemaach ginn: Installatioun vum Runtime-Ëmfeld (Java/Python), déi néideg Dateien op de richtege Plazen placéieren, Kompatibilitéit mat enger spezifescher Versioun vum Betribssystem garantéieren, asw. An anere Wierder, virsiichteg Opmierksamkeet muss op d'Konfiguratiounsmanagement bezuelt ginn (wat dacks eng Quell vu Sträit tëscht Entwéckler a Systemadministratoren war).
Container hunn alles geännert. Elo ass den Artefakt e Containerbild. Et kann als eng Zort erweidert ausführbar Datei duergestallt ginn, déi net nëmmen de Programm enthält, awer och e vollwäertegt Ausféierungsëmfeld (Java/Python/...), souwéi déi néideg Dateien/Packagen, virinstalléiert a prett fir lafen. Container kënnen ofgebaut a lafen op verschiddene Serveren ouni zousätzlech Schrëtt.
Zousätzlech funktionnéiere Container an hirem eegene Sandkëschtëmfeld. Si hunn hiren eegene virtuellen Netzwierkadapter, hiren eegene Dateiesystem mat limitéierten Zougang, hir eege Hierarchie vu Prozesser, hir eege Beschränkungen op CPU an Erënnerung, etc.. All dëst gëtt duerch e speziellen Ënnersystem vum Linux Kernel ëmgesat - Nummraim.
Kubernetes
Wéi virdru scho gesot, Kubernetes ass e Containerorchester. Et funktionnéiert esou: Dir gitt et e Pool vu Maschinnen, a seet dann: "Hey, Kubernetes, loosst eis zéng Instanzen vu mengem Container mat 2 Prozessoren an all 3 GB Erënnerung starten, an halen se lafen!" Kubernetes këmmert sech ëm de Rescht. Et wäert gratis Kapazitéit fannen, Container starten an se nei starten wann néideg, en Update ausrollen wann Dir Versiounen ännert, asw. Wesentlech erlaabt Kubernetes Iech d'Hardwarekomponent abstrakéieren a mécht eng breet Varietéit vu Systemer gëeegent fir Uwendungen z'installéieren an ze lafen.
Kubernetes aus der Siicht vum Laie
Wat sinn Ufroen a Limiten a Kubernetes
Okay, mir hunn Container a Kubernetes ofgedeckt. Mir wëssen och datt verschidde Container op der selwechter Maschinn wunne kënnen.
Eng Analogie kann mat engem kommunale Appartement gezunn ginn. E grousst Raimlechkeeten (Maschinnen / Unitéiten) gëtt geholl an u verschidde Locataire (Container) gelount. Kubernetes handelt als Realtor. D'Fro stellt sech, wéi Locataire aus Konflikter mat all aner ze halen? Wat wann ee vun hinnen, sot, decidéiert d'Buedzëmmer fir en halleft Dag ze léinen?
Dëst ass wou Ufroen a Limiten an d'Spill kommen. cpu Ufro nëmme fir Planungszwecker gebraucht. Dëst ass eppes wéi eng "Wonschlëscht" vum Container, an et gëtt benotzt fir de gëeegentste Node ze wielen. Zur selwechter Zäit ass d'CPU limitéiert kann mat engem Mietvertrag verglach ginn - soubal mir eng Eenheet fir de Container auswielen, de kann nët iwwer etabléiert Grenzen goen. An dat ass wou de Problem entsteet ...
Wéi Ufroen a Limiten a Kubernetes ëmgesat ginn
Kubernetes benotzt en Drosselmechanismus (Sprangen Auerzyklen) agebaut an de Kernel fir CPU Limiten ëmzesetzen. Wann eng Applikatioun d'Limite iwwerschreift, ass Drossel aktivéiert (dh et kritt manner CPU-Zyklen). Ufroen a Limite fir Erënnerung sinn anescht organiséiert, sou datt se méi einfach z'entdecken. Fir dëst ze maachen, kontrolléiert just de leschte Restartstatus vum Pod: ob et "OOMKilled" ass. CPU Throttling ass net sou einfach, well K8s nëmme Metriken duerch d'Benotzung verfügbar mécht, net vu cgroups.
CPU Ufro
Wéi CPU Ufro ëmgesat gëtt
Fir d'Einfachheet, kucke mer de Prozess mat enger Maschinn mat enger 4-Kär CPU als Beispill.
K8s benotzt engem Kontroll Grupp Mechanismus (cgroups) der Allokatioun vun Ressourcen ze kontrolléieren (Erënnerung an Prozessor). En hierarchesche Modell ass dofir verfügbar: d'Kand ierft d'Limite vun der Elteregrupp. D'Verdeelungsdetailer ginn an engem virtuelle Dateiesystem gespäichert (/sys/fs/cgroup). Am Fall vun engem Prozessor ass dëst /sys/fs/cgroup/cpu,cpuacct/*.
K8s benotzt Fichier cpu.share Prozessor Ressourcen ze verdeelen. An eisem Fall kritt d'Root cgroup 4096 Aktien vun CPU Ressourcen - 100% vun der verfügbarer Prozessorkraaft (1 Kär = 1024; dëst ass e fixe Wäert). D'Wuerzelgrupp verdeelt Ressourcen proportional ofhängeg vun den Aktien vun den Nokommen, déi registréiert sinn cpu.share, a si, am Tour, maachen dat selwecht mat hiren Nokommen, etc. Op engem typesche Kubernetes Node huet d'Root cgroup dräi Kanner: system.slice, user.slice и kubepods. Déi éischt zwou Ënnergruppen gi benotzt fir Ressourcen tëscht kriteschen Systemlasten a Benotzerprogrammer ausserhalb vu K8s ze verdeelen. Dee Leschten - kubepods - erstallt vu Kubernetes fir Ressourcen tëscht Pods ze verdeelen.
D'Diagramm uewen weist datt déi éischt an zweet Ënnergruppen jidderee kritt hunn 1024 deelt, mat der Kuberpod Ënnergrupp zougewisen 4096 deelt Wéi ass dat méiglech: schliisslech huet d'Rootgrupp Zougang zu nëmmen 4096 Aktien, an d'Zomm vun den Aktien vun hiren Nokommen iwwerschreift dës Zuel wesentlech (6144)? De Punkt ass datt de Wäert logesche Sënn mécht, sou datt de Linux Scheduler (CFS) et benotzt fir d'CPU Ressourcen proportional ze verdeelen. An eisem Fall kréien déi éischt zwou Gruppen 680 real Aktien (16,6% vun 4096), an kubepod kritt de Rescht 2736 deelt Am Fall vun Ausdauer benotzen déi éischt zwou Gruppen déi zougewisen Ressourcen net.
Glécklecherweis huet de Scheduler e Mechanismus fir net benotzte CPU Ressourcen ze verschwenden. Et transferéiert "Idle" Kapazitéit op e globalen Pool, aus deem et a Gruppen verdeelt gëtt, déi zousätzlech Prozessorkraaft brauchen (den Transfer geschitt a Chargen fir Ronnverloschter ze vermeiden). Eng ähnlech Method gëtt fir all Nokommen vun Nokommen applizéiert.
Dëse Mechanismus suergt fir eng fair Verdeelung vun der Prozessorkraaft a garantéiert datt keen Prozess Ressourcen vun aneren "klaut".
CPU Limit
Trotz der Tatsaach, datt d'Konfiguratioun vu Grenzen an Ufroen an K8s ähnlech ausgesinn, ass hir Ëmsetzung radikal anescht: dëst meescht irreführend an déi mannst dokumentéiert Deel.
K8s engagéiert Limiten ëmzesetzen. Hir Astellunge sinn an Fichieren uginn cfs_period_us и cfs_quota_us am cgroup Verzeichnis (d'Datei ass och do cpu.share).
Anescht wéi cpu.share, der Quote baséiert op Zäit Period, an net op der sinn Prozessor Muecht. cfs_period_us spezifizéiert d'Dauer vun der Period (Epoch) - et ass ëmmer 100000 μs (100 ms). Et gëtt eng Optioun fir dëse Wäert an K8s z'änneren, awer et ass nëmme verfügbar an Alpha fir de Moment. De Scheduler benotzt d'Epoch fir benotzte Quoten nei ze starten. Zweet Fichier cfs_quota_us, spezifizéiert déi verfügbar Zäit (Quot) an all Epoch. Notéiert datt et och a Mikrosekonne spezifizéiert gëtt. D'Quot kann d'Epochlängt iwwerschreiden; an anere Wierder, et kann méi wéi 100 ms sinn.
Loosst eis zwee Szenarie op 16-Kär Maschinnen kucken (déi meescht üblech Computertyp déi mir bei Omio hunn):
Szenario 1: 2 Threads an eng 200 ms Limit. Keng Drossel
Szenario 2: 10 thread an 200 ms Limit. Throttling fänkt no 20 ms un, den Zougang zu de Prozessorressourcen gëtt no weideren 80 ms erëm
Loosst eis soen datt Dir d'CPU Limit op setzt 2 Kären; Kubernetes wäert dëse Wäert op 200 ms iwwersetzen. Dëst bedeit datt de Container maximal 200ms CPU-Zäit ouni Drossel benotzen kann.
An hei fänkt de Spaass un. Wéi uewen ernimmt, ass déi verfügbar Quote 200 ms. Wann Dir schafft parallel zéng thread op enger 12-Kär Maschinn (kuckt d'Illustratioun fir Szenario 2), wärend all aner Pods idle sinn, gëtt d'Quot an nëmmen 20 ms erschöpft (zënter 10 * 20 ms = 200 ms), an all Threads vun dësem Pod hänken » (Drossel) fir déi nächst 80 ms. Déi schonn ernimmt , duerch déi exzessiv Drossel geschitt an de Container net emol déi bestehend Quot erfëllen kann.
Wéi evaluéieren d'Drossel an de Pods?
Login einfach op de Pod an ausféieren cat /sys/fs/cgroup/cpu/cpu.stat.
-
nr_periods- d'Gesamtzuel vun de Schedulerperioden; -
nr_throttled- Zuel vun throttled Perioden an der Zesummesetzungnr_periods; -
throttled_time- kumulativ gedrosselt Zäit an Nanosekonnen.
Wat ass wierklech lass?
Als Resultat kréie mir héich Drossel an all Uwendungen. Heiansdo ass hien an annerhallefmol méi staark wéi erwaart!
Dëst féiert zu verschiddene Feeler - Bereetschaft Check Feeler, Container afréiert, Netzwierkverbindung Pausen, Timeouts bannent Service Uriff. Dëst resultéiert schlussendlech zu enger erhéiter Latenz a méi héije Feelerraten.
Entscheedung a Konsequenzen
Alles ass einfach hei. Mir hunn d'CPU Limiten opginn an hunn ugefaang den OS Kernel a Cluster op déi lescht Versioun ze aktualiséieren, an där de Feeler fixéiert gouf. D'Zuel vu Feeler (HTTP 5xx) an eise Servicer ass direkt wesentlech erofgaang:
HTTP 5xx Feeler
HTTP 5xx Feeler fir ee kriteschen Service
Äntwert Zäit p95
Kritesch Service Ufro latency, 95. Prozenttil
Operatiounskäschte
Zuel vun Instanz Stonnen verbruecht
Wat ass de Fang?
Wéi am Ufank vum Artikel gesot:
Eng Analogie kann mat engem Gemengenappartement gezunn ginn ... Kubernetes handelt als Realtor. Awer wéi kënne Mieter aus Konflikter mateneen halen? Wat wann ee vun hinnen, sot, decidéiert d'Buedzëmmer fir en halleft Dag ze léinen?
Hei ass de Fang. Ee suergfälteg Container kann all déi verfügbar CPU Ressourcen op enger Maschinn iessen. Wann Dir e Smart Applikatioun Stack hutt (zum Beispill, JVM, Go, Node VM sinn richteg konfiguréiert), dann ass dëst kee Problem: Dir kënnt an esou Konditioune fir eng laang Zäit schaffen. Awer wann d'Applikatioune schlecht optimiséiert sinn oder guer net optimiséiert (FROM java:latest), kann d'Situatioun ausser Kontroll kommen. Bei Omio hu mir automatiséiert Basis Dockerfiles mat adäquate Standardastellunge fir de grousse Sprooche Stack, sou datt dëst Thema net existéiert.
Mir recommandéieren d'Metriken ze iwwerwaachen (Notzung, Sättigung a Feeler), API Verspéidungen a Feelerraten. Vergewëssert Iech datt d'Resultater d'Erwaardungen entspriechen.
Referenze
Dëst ass eis Geschicht. Déi folgend Materialien hu vill gehollef ze verstoen wat geschitt ass:
- ;
- ;
- ;
- ;
- - kuckt no "cpu throttling".
Kubernetes Feeler bericht:
- ;
- ;
- .
Hutt Dir ähnlech Probleemer an Ärer Praxis begéint oder hutt Erfahrung am Zesummenhang mat Drosselen a containeriséierte Produktiounsëmfeld? Deelt Är Geschicht an de Kommentaren!
PS vum Iwwersetzer
Liest och op eisem Blog:
- «";
- «";
- «".
Source: will.com