గమనిక. అనువాదం.: ఓమియో యొక్క ఈ కళ్లు తెరిచే చరిత్ర—యూరోపియన్ ట్రావెల్ అగ్రిగేటర్—పాఠకులను ప్రాథమిక సిద్ధాంతం నుండి కుబెర్నెటెస్ కాన్ఫిగరేషన్ యొక్క ఆకర్షణీయమైన ఆచరణాత్మక చిక్కుల వరకు తీసుకువెళుతుంది. అటువంటి కేసులతో పరిచయం మీ పరిధులను విస్తృతం చేయడమే కాకుండా, చిన్నవిషయం కాని సమస్యలను నివారించడానికి కూడా సహాయపడుతుంది.
మీరు ఎప్పుడైనా అప్లికేషన్‌లో చిక్కుకుపోయి, ఆరోగ్య తనిఖీలకు ప్రతిస్పందించడం ఆపివేసి, ఎందుకు అని గుర్తించలేకపోయారా? ఒక సాధ్యమైన వివరణ CPU వనరుల కోటా పరిమితులకు సంబంధించినది. దీని గురించి మనం ఈ వ్యాసంలో మాట్లాడుతాము.
TL; DR:
మీరు CFS కోటా బగ్‌తో Linux కెర్నల్ సంస్కరణను ఉపయోగిస్తుంటే, Kubernetes (లేదా Kubeletలో CFS కోటాలను నిలిపివేయడం)లో CPU పరిమితులను నిలిపివేయాలని మేము గట్టిగా సిఫార్సు చేస్తున్నాము. కోర్ లో తీవ్రమైన మరియు అధిక థ్రోట్లింగ్ మరియు ఆలస్యంకు దారితీసే బగ్.
ఓమియోలో మొత్తం అవస్థాపన కుబెర్నెట్స్ ద్వారా నిర్వహించబడుతుంది. మా స్టేట్‌ఫుల్ మరియు స్టేటస్‌లెస్ వర్క్‌లోడ్‌లు అన్నీ ప్రత్యేకంగా Kubernetes (మేము Google Kubernetes ఇంజిన్‌ని ఉపయోగిస్తాము)లో అమలవుతాయి. గత ఆరు నెలల్లో, మేము యాదృచ్ఛిక మందగమనాలను గమనించడం ప్రారంభించాము. అప్లికేషన్‌లు స్తంభింపజేయడం లేదా ఆరోగ్య తనిఖీలకు ప్రతిస్పందించడం ఆపివేయడం, నెట్‌వర్క్‌కు కనెక్షన్‌ని కోల్పోవడం మొదలైనవి. ఈ ప్రవర్తన మమ్మల్ని చాలా కాలం పాటు అబ్బురపరిచింది, చివరకు మేము సమస్యను తీవ్రంగా పరిగణించాలని నిర్ణయించుకున్నాము.
వ్యాసం యొక్క సారాంశం:
- కంటైనర్లు మరియు కుబెర్నెట్స్ గురించి కొన్ని మాటలు;
- CPU అభ్యర్థనలు మరియు పరిమితులు ఎలా అమలు చేయబడతాయి;
- బహుళ-కోర్ పరిసరాలలో CPU పరిమితి ఎలా పనిచేస్తుంది;
- CPU థ్రోట్లింగ్‌ను ఎలా ట్రాక్ చేయాలి;
- సమస్య పరిష్కారం మరియు సూక్ష్మ నైపుణ్యాలు.
కంటైనర్లు మరియు కుబెర్నెట్స్ గురించి కొన్ని మాటలు
కుబెర్నెటెస్ తప్పనిసరిగా మౌలిక ప్రపంచంలో ఆధునిక ప్రమాణం. దీని ప్రధాన పని కంటైనర్ ఆర్కెస్ట్రేషన్.
కంటైనర్లు
గతంలో, మేము సర్వర్‌లపై అమలు చేయడానికి Java JARs/WARs, Python Eggs లేదా ఎగ్జిక్యూటబుల్స్ వంటి కళాఖండాలను సృష్టించాల్సి ఉంటుంది. అయినప్పటికీ, వాటిని పని చేయడానికి, అదనపు పని చేయవలసి ఉంది: రన్‌టైమ్ ఎన్విరాన్మెంట్ (జావా/పైథాన్) ఇన్‌స్టాల్ చేయడం, అవసరమైన ఫైల్‌లను సరైన ప్రదేశాలలో ఉంచడం, ఆపరేటింగ్ సిస్టమ్ యొక్క నిర్దిష్ట సంస్కరణతో అనుకూలతను నిర్ధారించడం మొదలైనవి. మరో మాటలో చెప్పాలంటే, కాన్ఫిగరేషన్ మేనేజ్‌మెంట్‌పై జాగ్రత్తగా శ్రద్ధ వహించాలి (ఇది డెవలపర్‌లు మరియు సిస్టమ్ అడ్మినిస్ట్రేటర్‌ల మధ్య తరచుగా వివాదానికి మూలంగా ఉంటుంది).
కంటైనర్లు ప్రతిదీ మార్చాయి. ఇప్పుడు కళాఖండం ఒక కంటైనర్ చిత్రం. ఇది ప్రోగ్రామ్‌ను మాత్రమే కాకుండా, పూర్తి స్థాయి ఎగ్జిక్యూషన్ ఎన్విరాన్మెంట్ (జావా/పైథాన్/...), అలాగే అవసరమైన ఫైల్‌లు/ప్యాకేజీలను కలిగి ఉన్న ఒక రకమైన ఎక్స్‌టెండెడ్ ఎక్జిక్యూటబుల్ ఫైల్‌గా సూచించబడుతుంది, ముందే ఇన్‌స్టాల్ చేయబడి సిద్ధంగా ఉంది. పరుగు. ఎలాంటి అదనపు దశలు లేకుండా వివిధ సర్వర్‌లలో కంటైనర్‌లను అమలు చేయవచ్చు మరియు అమలు చేయవచ్చు.
అదనంగా, కంటైనర్లు వారి స్వంత శాండ్‌బాక్స్ వాతావరణంలో పనిచేస్తాయి. వారి స్వంత వర్చువల్ నెట్‌వర్క్ అడాప్టర్, పరిమిత యాక్సెస్‌తో వారి స్వంత ఫైల్ సిస్టమ్, వారి స్వంత ప్రక్రియల సోపానక్రమం, CPU మరియు మెమరీపై వారి స్వంత పరిమితులు మొదలైనవి ఉన్నాయి. ఇవన్నీ Linux కెర్నల్ యొక్క ప్రత్యేక ఉపవ్యవస్థ - నేమ్‌స్పేస్‌ల కారణంగా అమలు చేయబడతాయి.
Kubernetes
ముందే చెప్పినట్లుగా, కుబెర్నెటెస్ ఒక కంటైనర్ ఆర్కెస్ట్రేటర్. ఇది ఇలా పని చేస్తుంది: మీరు దానికి మెషీన్ల సమూహాన్ని ఇచ్చి, ఆపై ఇలా చెప్పండి: "హే, కుబెర్నెటెస్, 2 ప్రాసెసర్‌లు మరియు ఒక్కొక్కటి 3 GB మెమరీతో నా కంటైనర్‌లో పది ఉదాహరణలను ప్రారంభించి, వాటిని అమలులో ఉంచుదాం!" మిగిలినవి కుబెర్నెట్స్ చూసుకుంటారు. ఇది ఉచిత కెపాసిటీని కనుగొంటుంది, కంటైనర్‌లను లాంచ్ చేస్తుంది మరియు అవసరమైతే వాటిని రీస్టార్ట్ చేస్తుంది, వెర్షన్‌లను మార్చేటప్పుడు అప్‌డేట్‌ను విడుదల చేస్తుంది. ముఖ్యంగా, కుబెర్నెటెస్ హార్డ్‌వేర్ కాంపోనెంట్‌ను తీసివేయడానికి మిమ్మల్ని అనుమతిస్తుంది మరియు అప్లికేషన్‌లను అమలు చేయడానికి మరియు అమలు చేయడానికి అనువైన అనేక రకాల సిస్టమ్‌లను చేస్తుంది.
సామాన్యుడి కోణం నుండి కుబెర్నెట్స్
కుబెర్నెట్స్‌లో అభ్యర్థనలు మరియు పరిమితులు ఏమిటి
సరే, మేము కంటైనర్లు మరియు కుబెర్నెట్‌లను కవర్ చేసాము. ఒకే మెషీన్‌లో బహుళ కంటైనర్లు ఉండవచ్చని కూడా మాకు తెలుసు.
ఒక సారూప్యత ఒక సామూహిక అపార్ట్మెంట్తో డ్రా చేయవచ్చు. ఒక విశాలమైన ప్రాంగణాన్ని (యంత్రాలు/యూనిట్‌లు) తీసుకుని అనేక మంది అద్దెదారులకు (కంటెయినర్లు) అద్దెకు ఇస్తారు. కుబెర్నెటెస్ రియల్టర్‌గా వ్యవహరిస్తాడు. ప్రశ్న తలెత్తుతుంది, అద్దెదారులను పరస్పరం విభేదాల నుండి ఎలా ఉంచాలి? వారిలో ఒకరు, చెప్పాలంటే, సగం రోజుకి బాత్రూమ్ అరువు తీసుకోవాలని నిర్ణయించుకుంటే?
ఇక్కడే అభ్యర్థనలు మరియు పరిమితులు అమలులోకి వస్తాయి. CPU అభ్యర్థన ప్రణాళిక ప్రయోజనాల కోసం మాత్రమే అవసరం. ఇది కంటైనర్ యొక్క “కోరికల జాబితా” లాంటిది మరియు ఇది చాలా సరిఅయిన నోడ్‌ని ఎంచుకోవడానికి ఉపయోగించబడుతుంది. అదే సమయంలో CPU పరిమితి అద్దె ఒప్పందంతో పోల్చవచ్చు - మేము కంటైనర్ కోసం యూనిట్‌ని ఎంచుకున్న వెంటనే, ది కుదరదు స్థాపించబడిన పరిమితులను దాటి వెళ్ళండి. మరియు ఇక్కడే సమస్య తలెత్తుతుంది ...
కుబెర్నెట్స్‌లో అభ్యర్థనలు మరియు పరిమితులు ఎలా అమలు చేయబడతాయి
కుబెర్నెటెస్ CPU పరిమితులను అమలు చేయడానికి కెర్నల్‌లో నిర్మించబడిన థ్రోట్లింగ్ మెకానిజం (స్కిప్పింగ్ క్లాక్ సైకిల్స్)ను ఉపయోగిస్తుంది. అప్లికేషన్ పరిమితిని మించి ఉంటే, థ్రోట్లింగ్ ప్రారంభించబడుతుంది (అనగా ఇది తక్కువ CPU చక్రాలను అందుకుంటుంది). మెమరీ కోసం అభ్యర్థనలు మరియు పరిమితులు విభిన్నంగా నిర్వహించబడతాయి, కాబట్టి వాటిని గుర్తించడం సులభం. దీన్ని చేయడానికి, పాడ్ యొక్క చివరి పునఃప్రారంభ స్థితిని తనిఖీ చేయండి: అది “OOMKilled” కాదా. CPU థ్రోట్లింగ్ అంత సులభం కాదు, ఎందుకంటే K8s వినియోగం ద్వారా మాత్రమే కొలమానాలను అందుబాటులో ఉంచుతుంది, cgroups ద్వారా కాదు.
CPU అభ్యర్థన
CPU అభ్యర్థన ఎలా అమలు చేయబడుతుంది
సరళత కోసం, ఉదాహరణగా 4-కోర్ CPUతో కూడిన మెషీన్‌ని ఉపయోగించి ప్రక్రియను చూద్దాం.
K8s వనరుల కేటాయింపును (మెమరీ మరియు ప్రాసెసర్) నియంత్రించడానికి నియంత్రణ సమూహ యంత్రాంగాన్ని (cgroups) ఉపయోగిస్తుంది. దాని కోసం క్రమానుగత నమూనా అందుబాటులో ఉంది: పిల్లవాడు మాతృ సమూహం యొక్క పరిమితులను వారసత్వంగా పొందుతాడు. పంపిణీ వివరాలు వర్చువల్ ఫైల్ సిస్టమ్‌లో నిల్వ చేయబడతాయి (/sys/fs/cgroup) ప్రాసెసర్ విషయంలో ఇది /sys/fs/cgroup/cpu,cpuacct/*.
K8s ఫైల్‌ని ఉపయోగిస్తుంది cpu.share ప్రాసెసర్ వనరులను కేటాయించడానికి. మా విషయంలో, రూట్ cgroup 4096 CPU వనరులను పొందుతుంది - అందుబాటులో ఉన్న ప్రాసెసర్ శక్తిలో 100% (1 కోర్ = 1024; ఇది స్థిర విలువ). రూట్ గ్రూప్ రిజిస్టర్ అయిన వారసుల షేర్లను బట్టి దామాషా ప్రకారం వనరులను పంపిణీ చేస్తుంది cpu.share, మరియు వారు, వారి వారసులు మొదలైనవాటితో కూడా అదే చేస్తారు. ఒక సాధారణ కుబెర్నెట్స్ నోడ్‌లో, రూట్ cgroupకి ముగ్గురు పిల్లలు ఉన్నారు: system.slice, user.slice и kubepods. మొదటి రెండు ఉప సమూహాలు K8s వెలుపల క్లిష్టమైన సిస్టమ్ లోడ్‌లు మరియు వినియోగదారు ప్రోగ్రామ్‌ల మధ్య వనరులను పంపిణీ చేయడానికి ఉపయోగించబడతాయి. చివరిది - kubepods - పాడ్‌ల మధ్య వనరులను పంపిణీ చేయడానికి కుబెర్నెట్స్ రూపొందించారు.
మొదటి మరియు రెండవ ఉప సమూహాలు ఒక్కొక్కటి పొందాయని పై రేఖాచిత్రం చూపిస్తుంది 1024 kuberpod సబ్‌గ్రూప్‌తో షేర్లు కేటాయించబడ్డాయి 4096 షేర్లు ఇది ఎలా సాధ్యమవుతుంది: అన్నింటికంటే, రూట్ సమూహానికి మాత్రమే ప్రాప్యత ఉంది 4096 షేర్లు, మరియు ఆమె వారసుల షేర్ల మొత్తం గణనీయంగా ఈ సంఖ్యను మించిపోయింది (6144)? పాయింట్ ఏమిటంటే, విలువ తార్కికంగా అర్ధవంతంగా ఉంటుంది, కాబట్టి Linux షెడ్యూలర్ (CFS) CPU వనరులను దామాషా ప్రకారం కేటాయించడానికి ఉపయోగిస్తుంది. మా విషయంలో, మొదటి రెండు సమూహాలు అందుకుంటారు 680 నిజమైన షేర్లు (16,6లో 4096%), మరియు kubepod మిగిలిన వాటిని పొందుతుంది 2736 షేర్లు పనికిరాని సమయంలో, మొదటి రెండు సమూహాలు కేటాయించిన వనరులను ఉపయోగించవు.
అదృష్టవశాత్తూ, ఉపయోగించని CPU వనరులను వృధా చేయకుండా ఉండేందుకు షెడ్యూలర్‌కు మెకానిజం ఉంది. ఇది "నిష్క్రియ" సామర్థ్యాన్ని గ్లోబల్ పూల్‌కు బదిలీ చేస్తుంది, దాని నుండి అదనపు ప్రాసెసర్ శక్తి అవసరమయ్యే సమూహాలకు పంపిణీ చేయబడుతుంది (రౌండింగ్ నష్టాలను నివారించడానికి బ్యాచ్‌లలో బదిలీ జరుగుతుంది). ఇదే పద్ధతి వారసుల వారందరికీ వర్తించబడుతుంది.
ఈ మెకానిజం ప్రాసెసర్ పవర్ యొక్క సరసమైన పంపిణీని నిర్ధారిస్తుంది మరియు ఎవరూ ఇతరుల నుండి వనరులను "దొంగిలించకుండా" నిర్ధారిస్తుంది.
CPU పరిమితి
K8 లలో పరిమితులు మరియు అభ్యర్థనల కాన్ఫిగరేషన్‌లు ఒకేలా కనిపిస్తున్నప్పటికీ, వాటి అమలు పూర్తిగా భిన్నంగా ఉంటుంది: ఇది అత్యంత తప్పుదారి పట్టించేది మరియు అతి తక్కువ డాక్యుమెంట్ చేయబడిన భాగం.
K8s నిమగ్నమై ఉంది పరిమితులను అమలు చేయడానికి. వాటి సెట్టింగ్‌లు ఫైల్‌లలో పేర్కొనబడ్డాయి cfs_period_us и cfs_quota_us cgroup డైరెక్టరీలో (ఫైల్ కూడా అక్కడే ఉంది cpu.share).
కాకుండా cpu.share, కోటా ఆధారంగా ఉంటుంది సమయ వ్యవధి, మరియు అందుబాటులో ఉన్న ప్రాసెసర్ పవర్‌పై కాదు. cfs_period_us కాలం (యుగం) యొక్క వ్యవధిని నిర్దేశిస్తుంది - ఇది ఎల్లప్పుడూ 100000 μs (100 ms) ఉంటుంది. K8sలో ఈ విలువను మార్చడానికి ఒక ఎంపిక ఉంది, కానీ ఇది ప్రస్తుతానికి ఆల్ఫాలో మాత్రమే అందుబాటులో ఉంది. ఉపయోగించిన కోటాలను పునఃప్రారంభించడానికి షెడ్యూలర్ యుగాన్ని ఉపయోగిస్తుంది. రెండవ ఫైల్ cfs_quota_us, ప్రతి యుగంలో అందుబాటులో ఉన్న సమయాన్ని (కోటా) నిర్దేశిస్తుంది. ఇది మైక్రోసెకన్లలో కూడా పేర్కొనబడిందని గమనించండి. కోటా యుగం పొడవును మించవచ్చు; మరో మాటలో చెప్పాలంటే, ఇది 100 ms కంటే ఎక్కువగా ఉండవచ్చు.
16-కోర్ మెషీన్‌లపై రెండు దృశ్యాలను చూద్దాం (ఓమియోలో మనకు ఉన్న అత్యంత సాధారణ రకం కంప్యూటర్):
దృశ్యం 1: 2 థ్రెడ్‌లు మరియు 200 ms పరిమితి. థ్రోట్లింగ్ లేదు
దృశ్యం 2: 10 థ్రెడ్‌లు మరియు 200 ms పరిమితి. థ్రోట్లింగ్ 20 ms తర్వాత ప్రారంభమవుతుంది, ప్రాసెసర్ వనరులకు యాక్సెస్ మరొక 80 ms తర్వాత పునఃప్రారంభించబడుతుంది
మీరు CPU పరిమితిని సెట్ చేశారనుకుందాం 2 కెర్నలు; Kubernetes ఈ విలువను 200 msకి అనువదిస్తుంది. దీని అర్థం కంటైనర్ థ్రోట్లింగ్ లేకుండా గరిష్టంగా 200ms CPU సమయాన్ని ఉపయోగించగలదు.
మరియు ఇక్కడే సరదా ప్రారంభమవుతుంది. పైన పేర్కొన్న విధంగా, అందుబాటులో ఉన్న కోటా 200 ms. మీరు సమాంతరంగా పనిచేస్తుంటే పది 12-కోర్ మెషీన్‌లోని థ్రెడ్‌లు (దృష్టాంతం 2 కోసం దృష్టాంతం చూడండి), అన్ని ఇతర పాడ్‌లు నిష్క్రియంగా ఉన్నప్పుడు, కోటా కేవలం 20 msలో అయిపోతుంది (10 * 20 ms = 200 ms నుండి), మరియు ఈ పాడ్‌లోని అన్ని థ్రెడ్‌లు వేలాడతాయి » (థొరెటల్) తదుపరి 80 ms కోసం. ఇప్పటికే పేర్కొన్నది , దీని కారణంగా అధిక థ్రోట్లింగ్ ఏర్పడుతుంది మరియు కంటైనర్ ఇప్పటికే ఉన్న కోటాను కూడా పూర్తి చేయదు.
పాడ్‌లలో థ్రోట్లింగ్‌ను ఎలా అంచనా వేయాలి?
కేవలం పాడ్‌కి లాగిన్ చేసి అమలు చేయండి cat /sys/fs/cgroup/cpu/cpu.stat.
-
nr_periods- షెడ్యూలర్ కాలాల మొత్తం సంఖ్య; -
nr_throttled- కూర్పులో థొరెటల్ పీరియడ్స్ సంఖ్యnr_periods; -
throttled_time- నానోసెకన్లలో సంచిత త్రోటెల్డ్ సమయం.
అసలు ఏం జరుగుతోంది?
ఫలితంగా, మేము అన్ని అప్లికేషన్‌లలో అధిక థ్రోట్లింగ్‌ను పొందుతాము. కొన్నిసార్లు అతను లోపల ఉంటాడు ఒకటిన్నర సార్లు లెక్కించిన దానికంటే బలమైనది!
ఇది వివిధ లోపాలకు దారి తీస్తుంది - సంసిద్ధత తనిఖీ వైఫల్యాలు, కంటైనర్ ఫ్రీజ్‌లు, నెట్‌వర్క్ కనెక్షన్ బ్రేక్‌లు, సర్వీస్ కాల్‌లలో సమయం ముగిసింది. ఇది అంతిమంగా పెరిగిన జాప్యం మరియు అధిక ఎర్రర్ రేట్లకు దారి తీస్తుంది.
నిర్ణయం మరియు పరిణామాలు
ఇక్కడ ప్రతిదీ సులభం. మేము CPU పరిమితులను విడిచిపెట్టాము మరియు బగ్ పరిష్కరించబడిన తాజా సంస్కరణకు క్లస్టర్‌లలోని OS కెర్నల్‌ను నవీకరించడం ప్రారంభించాము. మా సేవల్లో ఎర్రర్‌ల సంఖ్య (HTTP 5xx) వెంటనే గణనీయంగా తగ్గింది:
HTTP 5xx లోపాలు
ఒక క్లిష్టమైన సేవ కోసం HTTP 5xx లోపాలు
ప్రతిస్పందన సమయం p95
క్లిష్టమైన సేవా అభ్యర్థన జాప్యం, 95వ శాతం
నిర్వహణ ఖర్చులు
గడిపిన ఉదాహరణ గంటల సంఖ్య
క్యాచ్ అంటే ఏమిటి?
వ్యాసం ప్రారంభంలో చెప్పినట్లుగా:
కమ్యూనల్ అపార్ట్మెంట్తో సారూప్యతను గీయవచ్చు... కుబెర్నెటెస్ రియల్టర్‌గా వ్యవహరిస్తాడు. కానీ అద్దెదారులను ఒకరితో ఒకరు విభేదాల నుండి ఎలా ఉంచాలి? వారిలో ఒకరు, చెప్పాలంటే, సగం రోజుకి బాత్రూమ్ అరువు తీసుకోవాలని నిర్ణయించుకుంటే?
ఇక్కడ క్యాచ్ ఉంది. ఒక అజాగ్రత్త కంటైనర్ మెషీన్‌లో అందుబాటులో ఉన్న అన్ని CPU వనరులను తినేస్తుంది. మీకు స్మార్ట్ అప్లికేషన్ స్టాక్ ఉంటే (ఉదాహరణకు, JVM, Go, Node VM సరిగ్గా కాన్ఫిగర్ చేయబడ్డాయి), అప్పుడు ఇది సమస్య కాదు: మీరు చాలా కాలం పాటు అలాంటి పరిస్థితుల్లో పని చేయవచ్చు. కానీ అప్లికేషన్‌లు పేలవంగా ఆప్టిమైజ్ చేయబడి ఉంటే లేదా ఆప్టిమైజ్ చేయకపోతే (FROM java:latest), పరిస్థితి అదుపు తప్పవచ్చు. Omio వద్ద మేము ప్రధాన భాషా స్టాక్ కోసం తగిన డిఫాల్ట్ సెట్టింగ్‌లతో ఆటోమేటెడ్ బేస్ డాకర్ ఫైల్‌లను కలిగి ఉన్నాము, కాబట్టి ఈ సమస్య ఉనికిలో లేదు.
కొలమానాలను పర్యవేక్షించాలని మేము సిఫార్సు చేస్తున్నాము (ఉపయోగం, సంతృప్తత మరియు లోపాలు), API ఆలస్యం మరియు లోపం రేట్లు. ఫలితాలు అంచనాలకు అనుగుణంగా ఉన్నాయని నిర్ధారించుకోండి.
సూచనలు
ఇది మన కథ. ఏమి జరుగుతుందో అర్థం చేసుకోవడానికి క్రింది పదార్థాలు బాగా సహాయపడతాయి:
- ;
- ;
- ;
- ;
- - "cpu థ్రోట్లింగ్" కోసం చూడండి.
Kubernetes బగ్ నివేదికలు:
- ;
- ;
- .
మీరు మీ ప్రాక్టీస్‌లో ఇలాంటి సమస్యలను ఎదుర్కొన్నారా లేదా కంటెయినరైజ్డ్ ప్రొడక్షన్ పరిసరాలలో థ్రోట్లింగ్‌కు సంబంధించిన అనుభవం ఉందా? వ్యాఖ్యలలో మీ కథనాన్ని పంచుకోండి!
అనువాదకుని నుండి PS
మా బ్లాగులో కూడా చదవండి:
- «";
- «";
- «".
మూలం: www.habr.com