తిరిగి 2016లో మేము బఫర్‌లో ఉన్నాము , మరియు ఇప్పుడు సుమారు 60 నోడ్‌లు (AWSలో) మరియు 1500 కంటైనర్లు మా k8s క్లస్టర్ ద్వారా నిర్వహించబడుతున్నాయి . అయినప్పటికీ, మేము ట్రయల్ మరియు ఎర్రర్ ద్వారా మైక్రోసర్వీస్‌లకు మారాము మరియు k8sతో పని చేసిన చాలా సంవత్సరాల తర్వాత కూడా మేము ఇంకా కొత్త సమస్యలను ఎదుర్కొంటున్నాము. ఈ పోస్ట్‌లో మనం మాట్లాడతాము ప్రాసెసర్ పరిమితులు: అవి మంచి అభ్యాసం అని మేము ఎందుకు అనుకున్నాము మరియు అవి ఎందుకు అంత మంచివి కావు.
ప్రాసెసర్ పరిమితులు మరియు థ్రోట్లింగ్
అనేక ఇతర Kubernetes వినియోగదారులు వలె, . అటువంటి సెట్టింగ్ లేకుండా, నోడ్‌లోని కంటైనర్లు మొత్తం ప్రాసెసర్ శక్తిని తీసుకోగలవు, ఇది ముఖ్యమైన కుబెర్నెట్స్ ప్రక్రియలకు కారణమవుతుంది (ఉదాహరణకు. kubelet) అభ్యర్థనలకు ప్రతిస్పందించడం ఆపివేస్తుంది. కాబట్టి, మీ నోడ్‌లను రక్షించడానికి CPU పరిమితులను సెట్ చేయడం మంచి మార్గం.
ప్రాసెసర్ పరిమితులు కంటైనర్‌ను నిర్దిష్ట వ్యవధికి ఉపయోగించగల గరిష్ట CPU సమయానికి సెట్ చేస్తాయి (డిఫాల్ట్ 100మి.లు), మరియు కంటైనర్ ఈ పరిమితిని ఎప్పటికీ మించదు. కోసం Kubernetes లో త్రోట్లింగ్ కంటైనర్ మరియు పరిమితిని మించకుండా నిరోధించండి, ఒక ప్రత్యేక సాధనం ఉపయోగించబడుతుంది , కానీ ఈ కృత్రిమ CPU పరిమితులు పనితీరును దెబ్బతీస్తాయి మరియు మీ కంటైనర్‌ల ప్రతిస్పందన సమయాన్ని పెంచుతాయి.
మేము ప్రాసెసర్ పరిమితులను సెట్ చేయకపోతే ఏమి జరుగుతుంది?
దురదృష్టవశాత్తు, మనమే ఈ సమస్యను ఎదుర్కోవలసి వచ్చింది. ప్రతి నోడ్‌కు కంటైనర్‌లను నిర్వహించడానికి బాధ్యత వహించే ప్రక్రియ ఉంటుంది kubelet, మరియు అతను అభ్యర్థనలకు ప్రతిస్పందించడం మానేశాడు. నోడ్, ఇది జరిగినప్పుడు, రాష్ట్రంలోకి వెళుతుంది NotReady, మరియు దాని నుండి కంటైనర్లు మరెక్కడైనా దారి మళ్లించబడతాయి మరియు కొత్త నోడ్‌లలో అదే సమస్యలను సృష్టిస్తాయి. కనీసం చెప్పాలంటే ఆదర్శవంతమైన దృశ్యం కాదు.
థ్రోట్లింగ్ మరియు ప్రతిస్పందన సమస్య యొక్క అభివ్యక్తి
కంటైనర్ ట్రాకింగ్ కోసం కీ మెట్రిక్ trottling, ఇది మీ కంటైనర్ ఎన్నిసార్లు థ్రోటల్ చేయబడిందో చూపిస్తుంది. ప్రాసెసర్ లోడ్ విపరీతంగా ఉందా లేదా అనే దానితో సంబంధం లేకుండా కొన్ని కంటైనర్‌లలో థ్రోట్లింగ్ ఉనికిని మేము ఆసక్తిగా గమనించాము. ఉదాహరణగా, మా ప్రధాన APIలలో ఒకదానిని పరిశీలిద్దాం:
మీరు క్రింద చూడగలిగినట్లుగా, మేము పరిమితిని సెట్ చేసాము 800m (0.8 లేదా 80% కోర్), మరియు గరిష్ట విలువలు ఉత్తమంగా చేరుకుంటాయి 200m (20% కోర్). సేవను త్రోసిపుచ్చడానికి ముందు మనకు ఇంకా ప్రాసెసర్ శక్తి పుష్కలంగా ఉన్నట్లు అనిపిస్తుంది, అయినప్పటికీ...
ప్రాసెసర్ లోడ్ పేర్కొన్న పరిమితుల కంటే తక్కువగా ఉన్నప్పటికీ - గణనీయంగా దిగువన - థ్రోట్లింగ్ ఇప్పటికీ జరుగుతుందని మీరు గమనించి ఉండవచ్చు.
దీనిని ఎదుర్కొన్నప్పుడు, మేము త్వరలో అనేక వనరులను కనుగొన్నాము (, , ) థ్రోట్లింగ్ కారణంగా సేవల పనితీరులో తగ్గుదల మరియు ప్రతిస్పందన సమయం గురించి.
తక్కువ CPU లోడ్‌లో మనం థ్రోట్లింగ్‌ను ఎందుకు చూస్తాము? సంక్షిప్త సంస్కరణ: "Linux కెర్నల్‌లో ఒక బగ్ ఉంది, ఇది నిర్దేశిత ప్రాసెసర్ పరిమితులతో కంటైనర్‌లను అనవసరంగా థ్రోట్లింగ్‌కు కారణమవుతుంది." సమస్య యొక్క స్వభావంపై మీకు ఆసక్తి ఉంటే, మీరు ప్రదర్శనను చదవవచ్చు ( и ఎంపికలు) డేవ్ చిలుక్ ద్వారా.
CPU పరిమితులను తొలగిస్తోంది (తీవ్ర హెచ్చరికతో)
సుదీర్ఘ చర్చల తర్వాత, మా వినియోగదారుల కోసం ప్రత్యక్షంగా లేదా పరోక్షంగా క్లిష్టమైన కార్యాచరణను ప్రభావితం చేసే అన్ని సేవల నుండి ప్రాసెసర్ పరిమితులను తీసివేయాలని మేము నిర్ణయించుకున్నాము.
మా క్లస్టర్ యొక్క స్థిరత్వానికి మేము చాలా విలువ ఇస్తున్నాము కాబట్టి నిర్ణయం సులభం కాదు. గతంలో, మేము ఇప్పటికే మా క్లస్టర్ యొక్క అస్థిరతతో ప్రయోగాలు చేసాము, ఆపై సేవలు చాలా వనరులను వినియోగించాయి మరియు వాటి మొత్తం నోడ్ యొక్క పనిని నెమ్మదించాయి. ఇప్పుడు ప్రతిదీ కొంత భిన్నంగా ఉంది: మా క్లస్టర్‌ల నుండి మనం ఏమి ఆశించామో దాని గురించి మాకు స్పష్టమైన అవగాహన ఉంది, అలాగే ప్రణాళికాబద్ధమైన మార్పులను అమలు చేయడానికి మంచి వ్యూహం ఉంది.
ఒక ముఖ్యమైన సమస్యపై వ్యాపార కరస్పాండెన్స్.
పరిమితులు ఎత్తివేయబడినప్పుడు మీ నోడ్‌లను ఎలా రక్షించుకోవాలి?
"అపరిమిత" సేవలను వేరుచేయడం:
గతంలో, కొన్ని నోడ్‌లు ఒక స్థితిలోకి రావడాన్ని మనం ఇప్పటికే చూశాము notReady, ప్రాథమికంగా చాలా ఎక్కువ వనరులను వినియోగించిన సేవల కారణంగా.
మేము అటువంటి సేవలను "సంబంధిత" సేవలకు అంతరాయం కలిగించకుండా ప్రత్యేక ("లేబుల్") నోడ్‌లలో ఉంచాలని నిర్ణయించుకున్నాము. ఫలితంగా, కొన్ని నోడ్‌లను గుర్తించడం ద్వారా మరియు "సంబంధం లేని" సేవలకు టాలరెన్స్ పరామితిని జోడించడం ద్వారా, మేము క్లస్టర్‌పై ఎక్కువ నియంత్రణను సాధించాము మరియు నోడ్‌లతో సమస్యలను గుర్తించడం మాకు సులభం అయింది. ఇలాంటి ప్రక్రియలను మీరే నిర్వహించడానికి, మీరు మిమ్మల్ని పరిచయం చేసుకోవచ్చు .
సరైన ప్రాసెసర్ మరియు మెమరీ అభ్యర్థనను కేటాయించడం:
మా అతిపెద్ద భయం ఏమిటంటే, ప్రక్రియ చాలా వనరులను వినియోగిస్తుంది మరియు నోడ్ అభ్యర్థనలకు ప్రతిస్పందించడం ఆపివేస్తుంది. ఇప్పటి నుండి (డేటాడాగ్‌కి ధన్యవాదాలు) మేము మా క్లస్టర్‌లోని అన్ని సేవలను స్పష్టంగా పర్యవేక్షించగలము, మేము "సంబంధం లేనివి"గా పేర్కొనాలని ప్లాన్ చేసిన వాటి యొక్క అనేక నెలల ఆపరేషన్‌ను నేను విశ్లేషించాను. నేను కేవలం గరిష్ట CPU వినియోగాన్ని 20% మార్జిన్‌తో సెట్ చేసాను మరియు k8s నోడ్‌కి ఇతర సేవలను కేటాయించడానికి ప్రయత్నిస్తే నోడ్‌లో ఖాళీని కేటాయించాను.
మీరు గ్రాఫ్‌లో చూడగలిగినట్లుగా, ప్రాసెసర్‌పై గరిష్ట లోడ్ చేరుకుంది 242m CPU కోర్లు (0.242 ప్రాసెసర్ కోర్లు). ప్రాసెసర్ అభ్యర్థన కోసం, ఈ విలువ కంటే కొంచెం పెద్ద సంఖ్యను తీసుకుంటే సరిపోతుంది. సేవలు వినియోగదారు-కేంద్రీకృతమైనవి కాబట్టి, పీక్ లోడ్ విలువలు ట్రాఫిక్‌తో సమానంగా ఉంటాయని దయచేసి గమనించండి.
మెమరీ వినియోగం మరియు ప్రశ్నలు మరియు voilaతో కూడా అదే చేయండి - మీరు అంతా సెటప్ చేసారు! ఎక్కువ భద్రత కోసం, మీరు క్షితిజ సమాంతర పాడ్ ఆటోస్కేలింగ్‌ను జోడించవచ్చు. అందువల్ల, రిసోర్స్ లోడ్ ఎక్కువగా ఉన్న ప్రతిసారీ, ఆటోస్కేలింగ్ కొత్త పాడ్‌లను సృష్టిస్తుంది మరియు కుబెర్నెట్‌లు వాటిని ఖాళీ స్థలంతో నోడ్‌లకు పంపిణీ చేస్తాయి. క్లస్టర్‌లోనే ఖాళీ లేనట్లయితే, మీరు మీరే హెచ్చరికను సెట్ చేసుకోవచ్చు లేదా వాటి ఆటోస్కేలింగ్ ద్వారా కొత్త నోడ్‌ల జోడింపును కాన్ఫిగర్ చేయవచ్చు.
మైనస్‌లలో, మనం ఓడిపోయాము అని గమనించాలి", అనగా ఒక నోడ్‌పై నడుస్తున్న కంటైనర్‌ల సంఖ్య. తక్కువ ట్రాఫిక్ సాంద్రత వద్ద మేము చాలా "సడలింపులను" కలిగి ఉండవచ్చు మరియు మీరు అధిక ప్రాసెసర్ లోడ్‌ను చేరుకునే అవకాశం కూడా ఉంది, అయితే ఆటోస్కేలింగ్ నోడ్‌లు రెండోదానికి సహాయపడతాయి.
Результаты
గత కొన్ని వారాలుగా చేసిన ప్రయోగాల నుండి ఈ అద్భుతమైన ఫలితాలను ప్రచురించినందుకు నేను సంతోషిస్తున్నాను; మేము ఇప్పటికే అన్ని సవరించిన సేవల్లో ప్రతిస్పందనగా గణనీయమైన మెరుగుదలలను చూశాము:
మేము మా హోమ్ పేజీలో ఉత్తమ ఫలితాలను సాధించాము (), అక్కడ సేవ వేగవంతం చేయబడింది ఇరవై రెండు సార్లు!
Linux కెర్నల్ బగ్ పరిష్కరించబడిందా?
అవును పంపిణీల వెర్షన్ 4.19 మరియు అంతకంటే ఎక్కువ.
అయితే, చదవగానే సెప్టెంబర్ 2020 రెండవ తేదీకి మేము ఇప్పటికీ ఇలాంటి బగ్‌తో కొన్ని Linux ప్రాజెక్ట్‌ల ప్రస్తావనలను చూస్తున్నాము. కొన్ని Linux డిస్ట్రిబ్యూషన్‌లు ఇప్పటికీ ఈ బగ్‌ని కలిగి ఉన్నాయని మరియు దాన్ని పరిష్కరించే పనిలో ఉన్నాయని నేను నమ్ముతున్నాను.
మీ పంపిణీ సంస్కరణ 4.19 కంటే తక్కువగా ఉంటే, తాజాదానికి అప్‌డేట్ చేయమని నేను సిఫార్సు చేస్తాను, అయితే ఏదైనా సందర్భంలో మీరు ప్రాసెసర్ పరిమితులను తీసివేయడానికి ప్రయత్నించాలి మరియు థ్రోట్లింగ్ కొనసాగుతుందో లేదో చూడాలి. మీరు క్రింద Kubernetes నిర్వహణ సేవలు మరియు Linux పంపిణీల పాక్షిక జాబితాను చూడవచ్చు:
- డెబియన్: పంపిణీ యొక్క తాజా వెర్షన్‌లో పరిష్కరించబడింది, , మరియు చాలా తాజాగా కనిపిస్తుంది () కొన్ని మునుపటి సంస్కరణలు కూడా పరిష్కరించబడవచ్చు.
- ఉబుంటు: తాజా వెర్షన్‌లో పరిష్కరించబడింది
- EKSకి ఇంకా పరిష్కారం లభించింది . మీ వెర్షన్ దీని కంటే తక్కువగా ఉంటే, మీరు AMIని అప్‌డేట్ చేయాలి.
- కోప్స్: у
kops 1.18+ప్రధాన హోస్ట్ చిత్రం ఉబుంటు 20.04. మీ కాప్స్ వెర్షన్ పాతదైతే, మీరు పరిష్కారం కోసం వేచి ఉండాల్సి రావచ్చు. మనమే ఇప్పుడు ఎదురు చూస్తున్నాము. - GKE (Google క్లౌడ్): ఫిక్స్ ఇంటిగ్రేటెడ్ , అయితే థ్రోట్లింగ్‌లో సమస్యలు ఉన్నాయి .
పరిష్కారం థ్రోట్లింగ్ సమస్యను పరిష్కరించినట్లయితే ఏమి చేయాలి?
సమస్య పూర్తిగా పరిష్కరించబడిందని నాకు ఖచ్చితంగా తెలియదు. మేము పరిష్కారముతో కెర్నల్ సంస్కరణకు చేరుకున్నప్పుడు, నేను క్లస్టర్‌ని పరీక్షించి, పోస్ట్‌ను అప్‌డేట్ చేస్తాను. ఎవరైనా ఇప్పటికే అప్‌డేట్ చేసి ఉంటే, మీ ఫలితాలను చదవడానికి నేను ఆసక్తిగా ఉంటాను.
తీర్మానం
- మీరు Linux కింద డాకర్ కంటైనర్‌లతో పని చేస్తే (కుబెర్నెటెస్, మెసోస్, స్వార్మ్ లేదా ఇతర వాటితో సంబంధం లేకుండా), థ్రోట్లింగ్ కారణంగా మీ కంటైనర్లు పనితీరును కోల్పోవచ్చు;
- బగ్ ఇప్పటికే పరిష్కరించబడిందనే ఆశతో మీ పంపిణీ యొక్క తాజా సంస్కరణకు నవీకరించడానికి ప్రయత్నించండి;
- ప్రాసెసర్ పరిమితులను తీసివేయడం సమస్యను పరిష్కరిస్తుంది, అయితే ఇది చాలా జాగ్రత్తగా ఉపయోగించాల్సిన ప్రమాదకరమైన సాంకేతికత (మొదట కెర్నల్‌ను నవీకరించడం మరియు ఫలితాలను సరిపోల్చడం మంచిది);
- మీరు CPU పరిమితులను తీసివేసినట్లయితే, మీ CPU మరియు మెమరీ వినియోగాన్ని జాగ్రత్తగా పర్యవేక్షించండి మరియు మీ CPU వనరులు మీ వినియోగాన్ని మించిపోతున్నాయని నిర్ధారించుకోండి;
- అధిక హార్డ్‌వేర్ లోడ్ విషయంలో కొత్త పాడ్‌లను సృష్టించడానికి పాడ్‌లను ఆటోస్కేల్ చేయడం సురక్షితమైన ఎంపిక, తద్వారా కుబెర్నెట్స్ వాటిని ఉచిత నోడ్‌లకు కేటాయిస్తుంది.
ఈ పోస్ట్ మీ కంటైనర్ సిస్టమ్‌ల పనితీరును మెరుగుపరచడంలో మీకు సహాయపడుతుందని నేను ఆశిస్తున్నాను.
PS రచయిత పాఠకులు మరియు వ్యాఖ్యాతలతో (ఇంగ్లీష్‌లో) అనుగుణంగా ఉంటారు.
మూలం: www.habr.com