Még 2016-ban a Bufferben , és jelenleg körülbelül 60 csomópont (AWS-en) és 1500 konténer dolgozik a által kezelt k8s-fürtön. . Próba és hiba útján azonban áttértünk a mikroszolgáltatásokra, és még több éves k8-as munka után is újabb problémákkal kell szembenéznünk. Ebben a bejegyzésben arról fogunk beszélni processzor korlátozások: miért gondoltuk, hogy jó gyakorlat, és miért nem lettek olyan jók.
Processzor korlátozások és szabályozás
Sok más Kubernetes-felhasználóhoz hasonlóan . Ilyen beállítás nélkül a csomópontban lévő tárolók felvehetik a processzor teljes teljesítményét, ami viszont fontos Kubernetes folyamatokat idéz elő (pl. kubelet) nem válaszol a kérésekre. Így a CPU-korlátok beállítása jó módszer a csomópontok védelmére.
A processzorkorlátok a tároló számára a maximális CPU-időt állítják be, amelyet egy adott időszakra használhat (alapértelmezett 100 ms), és a tároló soha nem lépi túl ezt a korlátot. In Kubernetes for fojtó tartályt, és megakadályozza, hogy túllépje a határértéket, speciális szerszámot használnak , de ezek a mesterséges CPU-korlátok végül rontják a teljesítményt és növelik a tárolók válaszidejét.
Mi történhet, ha nem állítunk be processzorkorlátokat?
Sajnos nekünk magunknak kellett ezzel a problémával szembesülnünk. Minden csomópontnak van egy folyamata, amely a tárolók kezeléséért felelős kubelet, és nem válaszolt a kérésekre. Amikor ez megtörténik, a csomópont állapotba kerül NotReady, és a belőle származó tárolók át lesznek irányítva máshová, és ugyanazokat a problémákat okozzák az új csomópontokon. Finoman szólva sem ideális forgatókönyv.
A fojtás és a reagálás problémájának megnyilvánulása
A konténerkövetés legfontosabb mutatója az trottling, azt mutatja, hogy hányszor fojtották le a tartályt. Érdeklődve vettük észre, hogy egyes konténerekben fojtás van, függetlenül attól, hogy a processzor terhelése extrém volt-e vagy sem. Példaként vessünk egy pillantást az egyik fő API-ra:
Amint az alábbiakban látható, a korlátot erre állítottuk be 800m (0.8 vagy 80% mag), és a legjobb elérési csúcsértékek 200m (20% mag). Úgy tűnik, hogy a szolgáltatás lefojtása előtt még bőven van processzorteljesítményünk, azonban...
Lehet, hogy észrevette, hogy még akkor is előfordul, ha a processzor terhelése a megadott határértékek alatt van – jelentősen az alatt –.
Ezzel szemben hamarosan számos forrást fedeztünk fel (, , ) a szolgáltatások teljesítményének és válaszidejének a fojtás miatti csökkenéséről.
Miért látunk szabályozást alacsony CPU terhelésnél? A rövid verzió a következő: „Van egy hiba a Linux kernelben, amely a megadott processzorkorlátokkal rendelkező konténerek szükségtelen korlátozását okozza.” Ha érdekli a probléma mibenléte, akkor elolvashatja az előadást ( и opciók) írta Dave Chiluk.
CPU-korlátozások eltávolítása (nagy körültekintéssel)
Hosszas megbeszélések után úgy döntöttünk, hogy eltávolítjuk a processzorkorlátozásokat minden olyan szolgáltatásból, amely közvetlenül vagy közvetve befolyásolta a felhasználóink kritikus funkcióit.
A döntés nem volt könnyű, mert nagyra értékeljük klaszterünk stabilitását. Korábban már kísérleteztünk klaszterünk instabilitásával, majd a szolgáltatások túl sok erőforrást fogyasztottak és lelassították a teljes csomópontjuk munkáját. Most minden némileg másként alakult: világosan megértettük, mit várunk el klasztereinktől, valamint jó stratégiát dolgoztunk ki a tervezett változtatások végrehajtására.
Üzleti levelezés sürgető kérdésről.
Hogyan védheti meg csomópontjait a korlátozások feloldásakor?
A „korlátlan” szolgáltatások elkülönítése:
A múltban már láttuk, hogy egyes csomópontok állapotba kerültek notReady, elsősorban a túl sok erőforrást felemésztő szolgáltatások miatt.
Úgy döntöttünk, hogy az ilyen szolgáltatásokat külön („felcímkézett”) csomópontokba helyezzük, hogy ne zavarják a „kapcsolódó” szolgáltatásokat. Ennek eredményeként néhány csomópont megjelölésével és a tolerancia paraméter hozzáadásával a „független” szolgáltatásokhoz nagyobb ellenőrzést értünk el a fürt felett, és könnyebbé vált a csomópontokkal kapcsolatos problémák azonosítása. Ha hasonló folyamatokat szeretne saját maga is végrehajtani, ismerkedjen meg .
A megfelelő processzor- és memóriakérelem hozzárendelése:
A legnagyobb félelmünk az volt, hogy a folyamat túl sok erőforrást emészt fel, és a csomópont nem válaszol a kérésekre. Mivel mostanra (a Datadognak köszönhetően) egyértelműen nyomon követhettük a klaszterünk összes szolgáltatását, több hónapos működést elemeztem azoknak, amelyeket „függetlennek” terveztünk jelölni. Egyszerűen beállítottam a maximális CPU-használatot 20%-os ráhagyással, és így lefoglaltam a helyet a csomópontban arra az esetre, ha a k8s más szolgáltatásokat próbálna hozzárendelni a csomóponthoz.
Amint az a grafikonon is látható, a processzor maximális terhelése elérte 242m CPU magok (0.242 processzormag). Processzorkéréshez elegendő ennél az értéknél valamivel nagyobb számot venni. Felhívjuk figyelmét, hogy mivel a szolgáltatások felhasználó-központúak, a csúcsterhelési értékek egybeesnek a forgalommal.
Tegye ugyanezt a memóriahasználattal és a lekérdezésekkel, és íme, kész is! A nagyobb biztonság érdekében vízszintes pod automatikus skálázást is hozzáadhat. Így minden alkalommal, amikor az erőforrás terhelés magas, az automatikus skálázás új podokat hoz létre, és a kubernetes szétosztja azokat a szabad hellyel rendelkező csomópontok között. Abban az esetben, ha magában a fürtben nem marad hely, riasztást állíthat be, vagy konfigurálhatja az új csomópontok hozzáadását az automatikus skálázással.
A mínuszok közül érdemes megjegyezni, hogy veszítettünk", azaz egy csomóponton futó tárolók száma. Alacsony forgalomsűrűség mellett is sok „lazításunk” lehet, és arra is van esély, hogy nagy processzorterhelést érünk el, de ez utóbbin az autoscaling node-oknak kell segíteni.
Álláspontja
Örömmel teszem közzé az elmúlt hetekben végzett kísérletek kiváló eredményeit; máris jelentős javulást tapasztaltunk az összes módosított szolgáltatásban:
A legjobb eredményeket a honlapunkon értük el (), ott felgyorsult a szolgáltatás huszonkét alkalommal!
Javítva a Linux kernel hibája?
Igen, disztribúciók 4.19-es és újabb verziói.
Olvasás után azonban 2020. szeptember másodikára még mindig találkozunk néhány hasonló hibával rendelkező Linux-projekt említésével. Úgy gondolom, hogy egyes Linux-disztribúciókban még mindig megtalálható ez a hiba, és éppen dolgoznak a javításán.
Ha a terjesztési verzió 4.19-nél alacsonyabb, azt javaslom, hogy frissítsen a legújabbra, de minden esetben próbálja meg eltávolítani a processzorkorlátozásokat, és ellenőrizze, hogy a szabályozás továbbra is fennáll-e. Alább láthatja a Kubernetes felügyeleti szolgáltatások és Linux disztribúciók részleges listáját:
- Debian: javítás integrálva a disztribúció legújabb verziójába, és egészen frissnek tűnik (). Néhány korábbi verzió is javítható.
- Ubuntu: javítás integrálva a legújabb verzióba
- Az EKS-nek még van javítása . Ha az Ön verziója ennél régebbi, frissítse az AMI-t.
- kops: у
kops 1.18+A fő gazdagép kép az Ubuntu 20.04 lesz. Ha a kops verziója régebbi, előfordulhat, hogy várnia kell a javításra. Mi magunk most várunk. - GKE (Google Cloud): Integrált javítás , azonban problémák vannak a fojtással .
Mi a teendő, ha a javítás megoldotta a fojtószabályozási problémát?
Nem vagyok benne biztos, hogy a probléma teljesen megoldódott. Amikor a javítással elérünk a kernel verzióhoz, tesztelem a fürtöt és frissítem a bejegyzést. Ha valaki frissített már, kíváncsi lennék az eredményeidre.
Következtetés
- Ha Docker-tárolókkal dolgozik Linux alatt (mindegy, hogy Kubernetes, Mesos, Swarm vagy mások), a konténerek teljesítménye csökkenhet a szabályozás miatt;
- Próbáljon meg frissíteni a disztribúció legújabb verziójára abban a reményben, hogy a hibát már kijavították;
- A processzorkorlátok eltávolítása megoldja a problémát, de ez egy veszélyes technika, amelyet rendkívül óvatosan kell használni (jobb először frissíteni a kernelt és összehasonlítani az eredményeket);
- Ha eltávolította a CPU-korlátokat, gondosan figyelje CPU- és memóriahasználatát, és győződjön meg arról, hogy a CPU-erőforrások meghaladják a fogyasztást;
- Biztonságos megoldás a podok automatikus skálázása, hogy új podokat hozzanak létre nagy hardverterhelés esetén, így a kubernetes szabad csomópontokhoz rendeli őket.
Remélem, hogy ez a bejegyzés segít javítani konténerrendszerei teljesítményét.
PS a szerző levelez az olvasókkal és a kommentátorokkal (angol nyelven).
Forrás: will.com