Kubernetes: CPU සීමාවන් ඉවත් කිරීමෙන් ඔබේ සේවාවන් වේගවත් කරන්න

ආපසු 2016 දී අපි බෆරයේ Kubernetes වෙත මාරු විය, සහ දැන් නෝඩ් 60 ක් (AWS මත) සහ බහාලුම් 1500 ක් පමණ කළමනාකරණය කරනු ලබන අපගේ k8s පොකුරේ වැඩ කරයි kops. කෙසේ වෙතත්, අපි අත්හදා බැලීම් සහ දෝෂයන් හරහා ක්ෂුද්‍ර සේවා වෙත ගිය අතර, k8s සමඟ වසර කිහිපයක් වැඩ කිරීමෙන් පසුව පවා අපි තවමත් නව ගැටළු වලට මුහුණ දී සිටිමු. මෙම ලිපියෙන් අපි කතා කරමු ප්රොසෙසර සීමාවන්: ඇයි අපි ඒවා හොඳ පුරුදු කියලා හිතුවේ සහ ඒවා එච්චර හොඳ නැත්තේ ඇයි කියලා.

ප්‍රොසෙසර සීමාවන් සහ තෙරපුම

අනෙකුත් බොහෝ Kubernetes භාවිතා කරන්නන් මෙන්, CPU සීමාවන් සැකසීම Google නිර්දේශ කරයි. එවැනි සැකසුමකින් තොරව, නෝඩයක ඇති බහාලුම්වලට සියලුම ප්‍රොසෙසර බලය ලබා ගත හැකි අතර, එමඟින් වැදගත් Kubernetes ක්‍රියාවලීන් ඇති කරයි (උදාහරණයක් ලෙස kubelet) ඉල්ලීම් වලට ප්‍රතිචාර දැක්වීම නවත්වනු ඇත. මේ අනුව, CPU සීමාවන් සැකසීම ඔබේ නෝඩ් ආරක්ෂා කිරීමට හොඳ ක්‍රමයකි.

ප්‍රොසෙසර සීමාවන් මඟින් කන්ටේනරයක් නිශ්චිත කාල සීමාවක් සඳහා භාවිත කළ හැකි උපරිම CPU කාලයට සකසයි (පෙරනිමිය 100ms), සහ කන්ටේනරය කිසි විටෙකත් මෙම සීමාව නොඉක්මවනු ඇත. සඳහා Kubernetes දී තෙරපුම කන්ටේනරය සහ එය සීමාව ඉක්මවා යාම වැළැක්වීම, විශේෂ මෙවලමක් භාවිතා වේ CFS කෝටාව, නමුත් මෙම කෘතිම CPU සීමාවන් කාර්ය සාධනයට හානියක් සහ ඔබේ බහාලුම්වල ප්‍රතිචාර කාලය වැඩි කරයි.

අපි ප්‍රොසෙසර සීමාවන් සකස් නොකළහොත් කුමක් සිදුවිය හැකිද?

අවාසනාවට, අපටම මෙම ගැටලුවට මුහුණ දීමට සිදු විය. සෑම නෝඩයක්ම බහාලුම් කළමනාකරණය සඳහා වගකිව යුතු ක්රියාවලියක් ඇත kubelet, සහ ඔහු ඉල්ලීම්වලට ප්රතිචාර දැක්වීම නතර කළේය. නෝඩය, මෙය සිදු වූ විට, තත්වයට යයි NotReady, සහ එහි ඇති බහාලුම් වෙනත් ස්ථානයකට හරවා යවනු ලබන අතර නව නෝඩ් වලද එම ගැටළු ඇති කරයි. අවම වශයෙන් පැවසීමට සුදුසු අවස්ථාවක් නොවේ.

තෙරපුම සහ ප්‍රතිචාරයේ ගැටලුව ප්‍රකාශ කිරීම

බහාලුම් ලුහුබැඳීම සඳහා ප්රධාන මෙට්රික් වේ trottling, එය ඔබගේ කන්ටේනරය කොපමණ වාර ගණනක් තෙරපී ඇත් ද යන්න පෙන්වයි. ප්‍රොසෙසරයේ බර අධිකද නැද්ද යන්න නොසලකා සමහර බහාලුම්වල තෙරපීම තිබීම අපි උනන්දුවෙන් දුටුවෙමු. උදාහරණයක් ලෙස, අපගේ ප්‍රධාන API එකක් දෙස බලමු:

ඔබට පහතින් පෙනෙන පරිදි, අපි සීමාව සකසා ඇත 800m (0.8 හෝ 80% හරය), සහ උපරිම අගයන් ළඟා විය හැකිය 200m (20% හරය). සේවාව අවහිර කිරීමට පෙර අපට තවමත් ප්‍රොසෙසර බලය ඕනෑ තරම් ඇති බව පෙනේ, කෙසේ වෙතත් ...

ප්‍රොසෙසරයේ බර නියමිත සීමාවන්ට වඩා අඩු වූ විට පවා - සැලකිය යුතු ලෙස පහළින් - තෙරපීම සිදු වන බව ඔබ දැක ඇති.

මෙයට මුහුණ දුන් අපි ඉක්මනින් සම්පත් කිහිපයක් සොයා ගත්තෙමු (github හි ගැටලුව, zadano මත ඉදිරිපත් කිරීම, omio හි පළ කරන්න) තෙරපීම හේතුවෙන් සේවා වල කාර්ය සාධනය සහ ප්‍රතිචාර කාලය පහත වැටීම ගැන.

අඩු CPU පැටවීමකදී අපට තෙරපීම පෙනෙන්නේ ඇයි? කෙටි අනුවාදය වන්නේ: "ලිනක්ස් කර්නලයේ දෝෂයක් ඇති අතර එමඟින් නිශ්චිත ප්‍රොසෙසර සීමාවන් සහිත බහාලුම් අනවශ්‍ය ලෙස තෙරපීමකට ලක් කරයි." ඔබ ගැටලුවේ ස්වභාවය ගැන උනන්දුවක් දක්වන්නේ නම්, ඔබට ඉදිරිපත් කිරීම කියවිය හැකිය (видео и පෙළ විකල්ප) ඩේව් චිලුක් විසිනි.

CPU සීමාවන් ඉවත් කිරීම (අතිශයින් ප්‍රවේශමෙන්)

දීර්ඝ සාකච්ඡාවලින් පසුව, අපගේ පරිශීලකයින් සඳහා තීරණාත්මක ක්‍රියාකාරීත්වයට සෘජුව හෝ වක්‍රව බලපෑ සියලුම සේවාවන්ගෙන් ප්‍රොසෙසර සීමා ඉවත් කිරීමට අපි තීරණය කළෙමු.

අපගේ පොකුරේ ස්ථාවරත්වය අප ඉතා අගය කරන නිසා තීරණය පහසු නොවීය. අතීතයේ දී, අපි දැනටමත් අපගේ පොකුරේ අස්ථාවරත්වය සමඟ අත්හදා බලා ඇති අතර, පසුව සේවාවන් බොහෝ සම්පත් පරිභෝජනය කර ඔවුන්ගේ සම්පූර්ණ නෝඩයේ කාර්යය මන්දගාමී විය. දැන් සෑම දෙයක්ම තරමක් වෙනස් විය: අපගේ පොකුරු වලින් අප අපේක්ෂා කළ දේ පිළිබඳ පැහැදිලි අවබෝධයක් මෙන්ම සැලසුම් කළ වෙනස්කම් ක්රියාත්මක කිරීම සඳහා හොඳ උපාය මාර්ගයක් ද අපට තිබුණි.

දැවෙන ගැටලුවක් මත ව්යාපාරික ලිපි හුවමාරුව.

සීමාවන් ඉවත් කළ විට ඔබේ නෝඩ් ආරක්ෂා කරන්නේ කෙසේද?

"සීමා රහිත" සේවාවන් හුදකලා කිරීම:

අතීතයේ දී, සමහර නෝඩ් තත්ත්වයට පත් වන බව අපි දැනටමත් දැක ඇත්තෙමු notReady, මූලික වශයෙන් බොහෝ සම්පත් පරිභෝජනය කරන සේවා හේතුවෙන්.

"ආශ්රිත" සේවාවන්ට බාධා නොවන පරිදි එවැනි සේවාවන් වෙනම ("ලේබල් කරන ලද") නෝඩ් වල තැබීමට අපි තීරණය කළෙමු. එහි ප්රතිඵලයක් වශයෙන්, සමහර නෝඩ් සලකුණු කිරීම සහ "අසම්බන්ධිත" සේවාවන් සඳහා ඉවසීමේ පරාමිතිය එකතු කිරීම මගින්, අපි පොකුරේ වැඩි පාලනයක් ලබා ගත් අතර, නෝඩ් සමඟ ගැටළු හඳුනා ගැනීමට අපට පහසු විය. සමාන ක්රියාවලීන් ඔබම සිදු කිරීම සඳහා, ඔබට ඔබව හුරු කර ගත හැකිය ලේඛනගත කිරීම.

නිවැරදි ප්‍රොසෙසරයක් සහ මතක ඉල්ලීමක් පැවරීම:

අපගේ ලොකුම බිය වූයේ ක්‍රියාවලිය බොහෝ සම්පත් පරිභෝජනය කිරීම සහ නෝඩය ඉල්ලීම්වලට ප්‍රතිචාර දැක්වීම නතර කිරීමයි. මෙතැන් සිට (Datadog ට ස්තූතියි) අපගේ පොකුරේ ඇති සියලුම සේවාවන් අපට පැහැදිලිව නිරීක්ෂණය කළ හැකිය, අපි “සම්බන්ධිත” ලෙස නම් කිරීමට සැලසුම් කළ අයගේ මාස කිහිපයක ක්‍රියාකාරිත්වය මම විශ්ලේෂණය කළෙමි. මම සරලවම උපරිම CPU භාවිතය 20% ක ආන්තිකයකින් සකසා, k8s node වෙත වෙනත් සේවාවන් පැවරීමට උත්සාහ කළහොත් node හි ඉඩ වෙන් කරනු ලැබේ.

ඔබට ප්‍රස්ථාරයේ දැකිය හැකි පරිදි, ප්‍රොසෙසරයේ උපරිම භාරය ළඟා වී ඇත 242m CPU cores (0.242 processor cores). ප්‍රොසෙසර ඉල්ලීමක් සඳහා, මෙම අගයට වඩා තරමක් විශාල සංඛ්‍යාවක් ගැනීම ප්‍රමාණවත් වේ. සේවාවන් පරිශීලක කේන්ද්‍රීය බැවින්, උපරිම පැටවුම් අගයන් ගමනාගමනය සමඟ සමපාත වන බව කරුණාවෙන් සලකන්න.

මතක භාවිතය සහ විමසුම් සමඟද එසේ කරන්න, සහ voila - ඔබ සියල්ල සකසා ඇත! වැඩි ආරක්ෂාවක් සඳහා, ඔබට තිරස් පොඩ් ස්වයං පරිමාණය එක් කළ හැක. මේ අනුව, සම්පත් භාරය වැඩි වන සෑම අවස්ථාවකම, ස්වයංක්‍රීය පරිමාණය නව කරල් නිර්මාණය කරනු ඇති අතර, kubernetes ඒවා නිදහස් ඉඩ සහිත නෝඩ් වෙත බෙදා හරිනු ඇත. පොකුරේම ඉඩක් නොමැති නම්, ඔබටම අනතුරු ඇඟවීමක් සකසා ගැනීමට හෝ ඒවායේ ස්වයංක්‍රීය පරිමාණය හරහා නව නෝඩ් එකතු කිරීම වින්‍යාසගත කළ හැක.

අවාසි අතරින්, අපට අහිමි වූ බව සඳහන් කිරීම වටී "බහාලුම් ඝනත්වය", i.e. එක් නෝඩයක් මත ධාවනය වන බහාලුම් ගණන. අඩු රථවාහන ඝනත්වයකදී අපට "ලිහිල් කිරීම්" බොහෝමයක් තිබිය හැකි අතර, ඔබ ඉහළ ප්‍රොසෙසර භාරයක් කරා ළඟා වීමට අවස්ථාවක් ද ඇත, නමුත් ස්වයංක්‍රීය පරිමාණ නෝඩ් දෙවැන්න සඳහා උපකාරී විය යුතුය.

ප්රතිඵල

පසුගිය සති කිහිපය තුළ සිදු කරන ලද අත්හදා බැලීම් වලින් මෙම විශිෂ්ට ප්‍රතිඵල ප්‍රකාශයට පත් කිරීමට මම සතුටු වෙමි; සියලුම නවීකරණය කරන ලද සේවාවන් හරහා ප්‍රතිචාර දැක්වීමේ සැලකිය යුතු වැඩිදියුණු කිරීම් අපි දැනටමත් දැක ඇත්තෙමු:

අපි අපගේ මුල් පිටුවේ හොඳම ප්‍රතිඵල ලබා ගත්තෙමු (බෆර්), එහිදී සේවාව වේගවත් විය විසි දෙවතාවක්!

ලිනක්ස් කර්නල් දෝෂය නිරාකරණය කර තිබේද?

ඔව් දෝෂය දැනටමත් නිරාකරණය කර ඇති අතර නිවැරදි කිරීම කර්නලයට එකතු කර ඇත බෙදාහැරීම් අනුවාදය 4.19 සහ ඉහළ.

කෙසේ වෙතත්, කියවීමෙන් පසු github හි kubernetes ගැටළු 2020 සැප්තැම්බර් දෙවන දිනය සඳහා සමාන දෝෂයක් ඇති සමහර Linux ව්‍යාපෘති ගැන සඳහන් කිරීම් අපට තවමත් හමු වේ. සමහර ලිනක්ස් බෙදාහැරීම්වල තවමත් මෙම දෝෂය ඇති බවත් එය නිවැරදි කිරීමට කටයුතු කරමින් සිටින බවත් මම විශ්වාස කරමි.

ඔබේ බෙදාහැරීමේ අනුවාදය 4.19 ට වඩා අඩු නම්, නවතම එකට යාවත්කාලීන කිරීමට මම නිර්දේශ කරමි, නමුත් ඕනෑම අවස්ථාවක ඔබ ප්‍රොසෙසර සීමාවන් ඉවත් කර තෙරපීම දිගටම පවතින්නේ දැයි බලන්න. පහතින් ඔබට Kubernetes කළමනාකරණ සේවා සහ Linux බෙදාහැරීම්වල අර්ධ ලැයිස්තුවක් දැකිය හැක:

• ඩේබියන්: බෙදාහැරීමේ නවතම අනුවාදයට සවි කර ඇත, බස්ටර්, සහ තරමක් නැවුම් පෙනුමක් (අගෝස්තු 2020) සමහර පෙර අනුවාදයන් ද ස්ථාවර විය හැකිය.
• උබුන්ටු: නවතම අනුවාදයට ඒකාබද්ධ කර ඇත Ubuntu Focal Fossa 20.04
• EKS ට තවම විසඳුමක් ලැබී ඇත 2019 දෙසැම්බර් මාසයේදී. ඔබගේ අනුවාදය මෙයට වඩා අඩු නම්, ඔබ AMI යාවත්කාලීන කළ යුතුය.
• kops: 2020 ජුනි සිට у kops 1.18+ ප්‍රධාන සත්කාරක රූපය Ubuntu 20.04 වේ. ඔබගේ kops අනුවාදය පැරණි නම්, ඔබට නිවැරදි කිරීමක් සඳහා රැඳී සිටීමට සිදු විය හැක. අපිම තමයි දැන් බලාගෙන ඉන්නේ.
• GKE (Google Cloud): Fix Integrated 2020 ජනවාරි මාසයේදී, කෙසේ වෙතත් throttling සමග ගැටළු ඇත තවමත් නිරීක්ෂණය කරනු ලැබේ.

විසඳුම මඟින් තෙරපුම් ගැටලුව විසඳා ඇත්නම් කුමක් කළ යුතුද?

ගැටලුව සම්පූර්ණයෙන්ම විසඳී ඇති බව මට විශ්වාස නැත. අපි නිවැරදි කිරීම සමඟ කර්නල් අනුවාදයට පැමිණි විට, මම පොකුර පරීක්ෂා කර පෝස්ට් යාවත්කාලීන කරමි. කවුරුහරි දැනටමත් යාවත්කාලීන කර ඇත්නම්, මම ඔබේ ප්‍රතිඵල කියවීමට උනන්දු වෙමි.

නිගමනය

• ඔබ Linux යටතේ Docker බහාලුම් සමඟ වැඩ කරන්නේ නම් (Kubernetes, Mesos, Swarm හෝ වෙනත් කුමක් වුවත්), ඔබේ බහාලුම් තෙරපීම හේතුවෙන් කාර්ය සාධනය නැති විය හැක;
• දෝෂය දැනටමත් නිරාකරණය කර ඇති බවට බලාපොරොත්තුවෙන් ඔබේ බෙදාහැරීමේ නවතම අනුවාදයට යාවත්කාලීන කිරීමට උත්සාහ කරන්න;
• ප්රොසෙසරයේ සීමාවන් ඉවත් කිරීම ගැටළුව විසඳනු ඇත, නමුත් මෙය ඉතා ප්රවේශමෙන් භාවිතා කළ යුතු භයානක තාක්ෂණයකි (එය මුලින්ම කර්නලය යාවත්කාලීන කිරීම සහ ප්රතිඵල සංසන්දනය කිරීම වඩා හොඳය);
• ඔබ CPU සීමාවන් ඉවත් කර ඇත්නම්, ඔබේ CPU සහ මතක භාවිතය හොඳින් නිරීක්ෂණය කර ඔබේ CPU සම්පත් ඔබේ පරිභෝජනය ඉක්මවා යන බවට වග බලා ගන්න;
• ආරක්ෂිත විකල්පයක් වනුයේ ඉහළ දෘඪාංග පැටවීමකදී නව කරල් නිර්මාණය කිරීම සඳහා කරල් ස්වයංක්‍රීයව පරිමාණය කිරීමයි, එවිට kubernetes ඒවා නොමිලේ නෝඩ් වෙත පවරයි.

ඔබේ බහාලුම් පද්ධතිවල ක්‍රියාකාරිත්වය වැඩි දියුණු කිරීමට මෙම සටහන ඔබට උපකාරී වනු ඇතැයි මම බලාපොරොත්තු වෙමි.

ප්රාදේශීය සභා එය කතුවරයා පාඨකයන් සහ විචාරකයන් සමඟ අනුරූප වේ (ඉංග්රීසියෙන්).


මූලාශ්රය: www.habr.com