සටහන. පරිවර්තනය.: යුරෝපීය සංචාරක එකතුකරන්නෙකු වන Omio හි මෙම ඇස් ඇරෙන ඉතිහාසය පාඨකයන් මූලික සිද්ධාන්තයේ සිට Kubernetes වින්‍යාසයේ සිත් ඇදගන්නාසුළු ප්‍රායෝගික සංකීර්ණතා දක්වා ගෙන යයි. එවැනි අවස්ථාවන් සමඟ හුරුපුරුදු වීම ඔබේ සීමාවන් පුළුල් කිරීමට පමණක් නොව, සුළු නොවන ගැටළු වළක්වා ගැනීමටද උපකාරී වේ.
ඔබ කවදා හෝ තැනක සිරවී, සෞඛ්‍ය පරීක්‍ෂණවලට ප්‍රතිචාර දැක්වීම නවත්වන, සහ ඒ මන්දැයි ඔබට සිතාගත නොහැකි යෙදුමක් අත්විඳ තිබේද? හැකි එක් පැහැදිලි කිරීමක් CPU සම්පත් කෝටා සීමාවන්ට සම්බන්ධ වේ. මෙම ලිපියෙන් අපි කතා කරන්නේ මෙයයි.
TL; ඩී:
ඔබ CFS කෝටා දෝෂයක් සහිත Linux කර්නලයේ අනුවාදයක් භාවිතා කරන්නේ නම්, Kubernetes හි CPU සීමාවන් අබල කිරීම (හෝ Kubelet හි CFS කෝටාවන් අක්‍රිය කිරීම) අපි තරයේ නිර්දේශ කරමු. හරය තුළ බරපතල සහ අධික තෙරපුම සහ ප්‍රමාදයන් ඇති කරන දෝෂයකි.
ඔමියෝ වල සමස්ත යටිතල පහසුකම් Kubernetes විසින් කළමනාකරණය කරනු ලැබේ. අපගේ සියලු රාජ්‍ය සහ අස්ථායී කාර්ය භාරයන් ක්‍යුබර්නෙටස් මත පමණක් ක්රියාත්මක වේ (අපි Google Kubernetes එන්ජිම භාවිතා කරමු). පසුගිය මාස හය තුළ අපි අහඹු ලෙස මන්දගාමී වීම නිරීක්ෂණය කිරීමට පටන් ගත්තෙමු. යෙදුම් කැටි කිරීම හෝ සෞඛ්‍ය පරීක්‍ෂණවලට ප්‍රතිචාර දැක්වීම නැවැත්වීම, ජාලයට සම්බන්ධතා නැති වීම යනාදිය. මෙම හැසිරීම දිගු කලක් තිස්සේ අපව පුදුමයට පත් කළ අතර අවසානයේ අපි ගැටලුව බැරෑරුම් ලෙස ගැනීමට තීරණය කළෙමු.
ලිපියේ සාරාංශය:
- බහාලුම් සහ Kubernetes ගැන වචන කිහිපයක්;
- CPU ඉල්ලීම් සහ සීමාවන් ක්රියාත්මක කරන ආකාරය;
- CPU සීමාව බහු-core පරිසරය තුළ ක්රියා කරන ආකාරය;
- CPU තෙරපුම නිරීක්ෂණය කරන්නේ කෙසේද;
- ගැටළු විසඳුම සහ සූක්ෂ්මතා.
බහාලුම් සහ Kubernetes ගැන වචන කිහිපයක්
Kubernetes යනු යටිතල පහසුකම් ලෝකයේ නවීන ප්‍රමිතියයි. එහි ප්‍රධාන කාර්යය වන්නේ බහාලුම් වාද්‍ය වෘන්දයයි.
බහාලුම්
අතීතයේදී, අපට සේවාදායකයන් මත ධාවනය කිරීමට Java JARs/WARs, Python Eggs, හෝ executables වැනි පුරාවස්තු නිර්මාණය කිරීමට සිදු විය. කෙසේ වෙතත්, ඒවා ක්රියාත්මක කිරීම සඳහා, අමතර කාර්යයන් සිදු කිරීමට සිදු විය: ධාවන පරිසරය (ජාවා / පයිතන්) ස්ථාපනය කිරීම, අවශ්ය ලිපිගොනු නිවැරදි ස්ථානවල තැබීම, මෙහෙයුම් පද්ධතියේ නිශ්චිත අනුවාදයක් සමඟ අනුකූලතාව සහතික කිරීම යනාදිය. වෙනත් වචන වලින් කිවහොත්, වින්‍යාස කළමනාකරණය කෙරෙහි ප්‍රවේශමෙන් අවධානය යොමු කළ යුතු විය (එය බොහෝ විට සංවර්ධකයින් සහ පද්ධති පරිපාලකයින් අතර මතභේදයට තුඩු දුන්නේය).
බහාලුම් සියල්ල වෙනස් කළේය. දැන් කෞතුක වස්තුව බහාලුම් රූපයකි. එය වැඩසටහන පමණක් නොව, සම්පූර්ණ ක්රියාත්මක කිරීමේ පරිසරයක් (Java/Python/...), මෙන්ම අවශ්ය ගොනු/පැකේජ, පෙර ස්ථාපනය කර සූදානම් කර ඇති දිගු ක්රියාත්මක කළ හැකි ගොනුවක් ලෙස නිරූපණය කළ හැක. දුවනවා. කිසිදු අමතර පියවරකින් තොරව විවිධ සර්වර් මත බහාලුම් යෙදවිය හැක.
මීට අමතරව, බහාලුම් ඔවුන්ගේම වැලිපිල්ල පරිසරය තුළ ක්රියාත්මක වේ. ඔවුන්ට ඔවුන්ගේම අථත්‍ය ජාල ඇඩැප්ටරයක්, සීමිත ප්‍රවේශයක් සහිත ඔවුන්ගේම ගොනු පද්ධතියක්, ඔවුන්ගේම ක්‍රියාවලි ධුරාවලියක්, CPU සහ මතකය පිළිබඳ ඔවුන්ගේම සීමාවන් යනාදිය ඇත. මේ සියල්ල ක්රියාත්මක වන්නේ ලිනක්ස් කර්නලයේ විශේෂ උප පද්ධතියක් වන නාම අවකාශයට ස්තුති කරමිනි.
කුබර්නෙට්ස්
කලින් සඳහන් කළ පරිදි, Kubernetes යනු බහාලුම් වාදකයෙකි. එය ක්රියා කරන්නේ මේ ආකාරයට ය: ඔබ එයට යන්ත්‍ර සංචිතයක් ලබා දී, ඉන්පසු මෙසේ පවසන්න: “හේයි, කුබර්නෙටස්, ප්රොසෙසර 2 ක් සහ 3 GB මතකයක් සහිත මගේ කන්ටේනරයේ අවස්ථා දහයක් දියත් කර ඒවා ක්රියාත්මක කර තබා ගනිමු!” Kubernetes ඉතිරිය බලා ගනීවි. එය නොමිලේ ධාරිතාව සොයා ගැනීම, බහාලුම් දියත් කිරීම සහ අවශ්ය නම් ඒවා නැවත ආරම්භ කිරීම, අනුවාද වෙනස් කිරීමේදී යාවත්කාලීන කිරීමක් සිදු කරයි. අත්‍යවශ්‍යයෙන්ම, Kubernetes ඔබට දෘඪාංග සංරචකය වියුක්ත කිරීමට සහ යෙදුම් යෙදවීමට සහ ක්රියාත්මක කිරීමට යෝග්‍ය විවිධ පද්ධති නිර්මාණය කිරීමට ඉඩ සලසයි.
ගිහියාගේ දෘෂ්ටි කෝණයෙන් Kubernetes
Kubernetes හි ඉල්ලීම් සහ සීමාවන් මොනවාද
හරි, අපි බහාලුම් සහ Kubernetes ආවරණය කළා. එකම යන්ත්‍රයක බහු බහාලුම් රැඳී සිටිය හැකි බව ද අපි දනිමු.
වාර්ගික මහල් නිවාසයක් සමඟ ප්‍රතිසමයක් ඇඳිය හැකිය. ඉඩකඩ සහිත පරිශ්‍රයක් (යන්ත්‍ර/ඒකක) ගෙන කුලී නිවැසියන් කිහිප දෙනෙකුට (කන්ටේනර්) කුලියට දෙනු ලැබේ. Kubernetes දේපල වෙළඳාම්කරුවෙකු ලෙස ක්රියා කරයි. ප්රශ්නය පැනනගින්නේ, එකිනෙකා සමඟ ගැටුම් වලින් කුලී නිවැසියන් තබා ගන්නේ කෙසේද? ඔවුන්ගෙන් එක් කෙනෙක්, කියනවා නම්, දින භාගයක් සඳහා නාන කාමරය ණයට ගැනීමට තීරණය කරන්නේ නම්?
ඉල්ලීම් සහ සීමාවන් ක්රියාත්මක වන්නේ මෙහිදීය. CPU ඉල්ලීම සැලසුම් අරමුණු සඳහා පමණක් අවශ්ය වේ. මෙය කන්ටේනරයේ "කැමති ලැයිස්තුවක්" වැනි දෙයක් වන අතර එය වඩාත් සුදුසු නෝඩය තෝරා ගැනීමට භාවිතා කරයි. ඒ සමගම CPU සීමාව කුලී ගිවිසුමක් සමඟ සැසඳිය හැක - අපි බහාලුම් සඳහා ඒකකයක් තෝරාගත් වහාම, ද බැහැ ස්ථාපිත සීමාවන් ඉක්මවා යන්න. අනික මෙතන තමයි ප්‍රශ්නේ එන්නේ...
Kubernetes හි ඉල්ලීම් සහ සීමාවන් ක්රියාත්මක කරන ආකාරය
CPU සීමාවන් ක්රියාත්මක කිරීම සඳහා Kubernetes කර්නලය තුළ ගොඩනගා ඇති throttling යාන්ත්‍රණයක් (ඔරලෝසු චක්‍ර මඟ හැරීම) භාවිතා කරයි. යෙදුමක් සීමාව ඉක්මවන්නේ නම්, තෙරපුම සක්‍රීය වේ (එනම් එයට අඩු CPU චක්‍ර ලැබේ). මතකය සඳහා ඉල්ලීම් සහ සීමාවන් වෙනස් ලෙස සංවිධානය කර ඇත, එබැවින් ඒවා හඳුනා ගැනීම පහසුය. මෙය සිදු කිරීම සඳහා, පොඩ් එකේ අවසන් නැවත ආරම්භ තත්ත්වය පරීක්ෂා කරන්න: එය "OOMKilled" ද යන්න. CPU throttling එතරම් සරල නැත, මන්ද K8s ප්‍රමිතික ලබා ගත හැක්කේ භාවිතයෙන් මිස cgroups මගින් නොවන බැවිනි.
CPU ඉල්ලීම
CPU ඉල්ලීම ක්රියාත්මක කරන ආකාරය
සරල බව සඳහා, උදාහරණයක් ලෙස 4-core CPU සහිත යන්ත්‍රයක් භාවිතා කරන ක්‍රියාවලිය දෙස බලමු.
K8s සම්පත් (මතකය සහ ප්‍රොසෙසරය) බෙදා හැරීම පාලනය කිරීම සඳහා පාලන කණ්ඩායම් යාන්ත්‍රණයක් (cgroups) භාවිතා කරයි. ඒ සඳහා ධූරාවලි ආකෘතියක් ලබා ගත හැකිය: දරුවාට මාපිය කණ්ඩායමේ සීමාවන් උරුම වේ. බෙදා හැරීමේ විස්තර අථත්‍ය ගොනු පද්ධතියක ගබඩා කර ඇත (/sys/fs/cgroup) ප්‍රොසෙසරයක නම් මෙයයි /sys/fs/cgroup/cpu,cpuacct/*.
K8s ගොනුව භාවිතා කරයි cpu.share ප්රොසෙසර සම්පත් වෙන් කිරීමට. අපගේ නඩුවේදී, root cgroup හට CPU සම්පත් කොටස් 4096 ක් ලැබේ - පවතින ප්රොසෙසර බලයෙන් 100% (1 core = 1024; මෙය ස්ථාවර අගයකි). මූල කණ්ඩායම ලියාපදිංචි වූ පරම්පරාවේ කොටස් මත පදනම්ව සමානුපාතිකව සම්පත් බෙදා හරිනු ලැබේ cpu.share, සහ ඔවුන් අනෙක් අතට, ඔවුන්ගේ පරම්පරාවන් සමඟ ද එසේ කරති. සාමාන්‍ය Kubernetes node එකක් මතම, මූල cgroup හට දරුවන් තිදෙනෙක් සිටී: system.slice, user.slice и kubepods. K8s වලින් පිටත විවේචනාත්මක පද්ධති පැටවීම් සහ පරිශීලක වැඩසටහන් අතර සම්පත් බෙදා හැරීම සඳහා පළමු උප කණ්ඩායම් දෙක භාවිතා වේ. අන්තිම එක - kubepods - කරල් අතර සම්පත් බෙදා හැරීම සඳහා Kubernetes විසින් නිර්මාණය කරන ලදී.
ඉහත රූප සටහනෙන් පෙන්නුම් කරන්නේ පළමු සහ දෙවන උප කණ්ඩායම්වලට එක් එක් ලැබුණු බවයි 1024 කොටස්, kuberpod උප සමූහයට වෙන් කර ඇත 4096 කොටස් මෙය කළ හැක්කේ කෙසේද: සියල්ලට පසු, මූල කණ්ඩායමට ප්‍රවේශය ඇත්තේ පමණි 4096 කොටස්, සහ ඇගේ පරම්පරාවේ කොටස්වල එකතුව මෙම සංඛ්යාව සැලකිය යුතු ලෙස ඉක්මවයි (6144)? කාරණය වන්නේ අගය තාර්කික අර්ථයක් ඇති බවයි, එබැවින් Linux උපලේඛනය (CFS) එය සමානුපාතිකව CPU සම්පත් වෙන් කිරීමට භාවිතා කරයි. අපගේ නඩුවේදී, පළමු කණ්ඩායම් දෙක ලබා ගනී 680 සැබෑ කොටස් (16,6 න් 4096%), සහ ඉතිරි කොටස kubepod වෙත ලැබේ 2736 කොටස් අක්‍රිය වූ විට, පළමු කණ්ඩායම් දෙක වෙන් කළ සම්පත් භාවිතා නොකරනු ඇත.
වාසනාවකට මෙන්, භාවිතයට නොගත් CPU සම්පත් නාස්ති නොකිරීමට උපලේඛකයට යාන්ත්‍රණයක් ඇත. එය "නිෂ්ක්‍රීය" ධාරිතාව ගෝලීය සංචිතයකට මාරු කරයි, එයින් එය අතිරේක ප්රොසෙසර බලය අවශ්ය කණ්ඩායම් වෙත බෙදා හරිනු ලැබේ (පරිමාරුව වටකුරු පාඩු වළක්වා ගැනීම සඳහා කණ්ඩායම් වශයෙන් සිදු වේ). ඒ හා සමාන ක්රමයක් පැවත එන්නන්ගෙන් පැවත එන සියලු දෙනාටම අදාළ වේ.
මෙම යාන්ත්‍රණය ප්‍රොසෙසරයේ බලය සාධාරණ ලෙස බෙදා හැරීම සහතික කරන අතර කිසිවකු අන් අයගෙන් සම්පත් “සොරකම්” නොකරන බව සහතික කරයි.
CPU සීමාව
K8s හි සීමාවන් සහ ඉල්ලීම් වල වින්‍යාසයන් සමාන ලෙස පෙනුනද, ඒවා ක්රියාත්මක කිරීම රැඩිකල් ලෙස වෙනස් ය: මෙය වඩාත්ම නොමඟ යවන සුළුය සහ අවම ලේඛනගත කොටස.
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-core යන්ත්‍රවල අවස්ථා දෙකක් බලමු (Omio හි අපට ඇති වඩාත් පොදු පරිගණක වර්ගය):
අවස්ථාව 1: නූල් 2 ක් සහ 200 ms සීමාවක්. තෙරපීම නැත
සිද්ධිය 2: නූල් 10 ක් සහ ms 200 සීමාව. 20 ms ට පසුව Throttling ආරම්භ වේ, ප්රොසෙසර සම්පත් වෙත ප්‍රවේශය තවත් ms 80 කින් පසුව නැවත ආරම්භ වේ
ඔබ CPU සීමාව සකසන්න යැයි සිතමු 2 කර්නල්; Kubernetes මෙම අගය 200 ms වෙත පරිවර්තනය කරනු ඇත. මෙයින් අදහස් කරන්නේ කන්ටේනරයට තෙරපීමකින් තොරව උපරිම වශයෙන් 200ms CPU කාලයක් භාවිතා කළ හැකි බවයි.
තවද විනෝදය ආරම්භ වන්නේ මෙතැනිනි. ඉහත සඳහන් කළ පරිදි, පවතින කෝටාව 200 ms වේ. ඔබ සමාන්තරව වැඩ කරන්නේ නම් දහය 12-core යන්ත්‍රයක නූල් (දර්ශනය 2 සඳහා නිදර්ශනය බලන්න), අනෙකුත් සියලුම කරල් නිෂ්ක්‍රීය වන අතර, කෝටාව 20 ms (10 * 20 ms = 200 ms සිට) අවසන් වන අතර, මෙම පොඩ් එකේ සියලුම නූල් එල්ලේ. » (තෙරපුම) මීළඟ 80 ms සඳහා. දැනටමත් සඳහන් කර ඇත , අධික ලෙස තෙරපීම සිදු වන අතර කන්ටේනරයට පවතින කෝටාව පවා සපුරාලිය නොහැක.
කරල් වල තෙරපීම තක්සේරු කරන්නේ කෙසේද?
පොඩ් එකට ලොග් වෙලා ක්රියාත්මක කරන්න විතරයි cat /sys/fs/cgroup/cpu/cpu.stat.
-
nr_periods- උපලේඛන කාල පරිච්ඡේදවල මුළු ගණන; -
nr_throttled- සංයුතියේ throttled periods ගණනnr_periods; -
throttled_time- නැනෝ තත්පර වලින් සමුච්චිත තෙරපුම් කාලය.
ඇත්තටම මොකද වෙන්නේ?
එහි ප්‍රතිඵලයක් වශයෙන්, අපි සියලුම යෙදුම්වල ඉහළ තෙරපුම ලබා ගනිමු. සමහර විට ඔහු ඇතුලේ එකහමාරක් වතාවක් ගණනය කිරීමට වඩා ශක්තිමත්!
මෙය විවිධ දෝෂ වලට තුඩු දෙයි - සූදානම පරීක්ෂා කිරීමේ අසාර්ථකත්වය, බහාලුම් කැටි කිරීම, ජාල සම්බන්ධතා බිඳ වැටීම්, සේවා ඇමතුම් තුළ කල් ඉකුත්වීම්. මෙය අවසානයේ ප්‍රමාද වැඩි වීම සහ වැඩි දෝෂ අනුපාත ඇති කරයි.
තීරණය සහ ප්රතිවිපාක
මෙහි සෑම දෙයක්ම සරලයි. අපි CPU සීමාවන් අතහැර දමා OS කර්නලය පොකුරුවල ඇති නවතම අනුවාදයට යාවත්කාලීන කිරීම ආරම්භ කළෙමු, එහි දෝෂය නිවැරදි කර ඇත. අපගේ සේවාවන්හි දෝෂ ගණන (HTTP 5xx) වහාම සැලකිය යුතු ලෙස පහත වැටුණි:
HTTP 5xx දෝෂ
එක් තීරණාත්මක සේවාවක් සඳහා HTTP 5xx දෝෂ
ප්‍රතිචාර කාලය p95
විවේචනාත්මක සේවා ඉල්ලීම් ප්‍රමාදය, 95 වැනි ප්‍රතිශතය
මෙහෙයුම් වියදම්
ගත කළ අවස්ථා ගණන
අල්ලා ගැනීම යනු කුමක්ද?
ලිපියේ ආරම්භයේ සඳහන් කර ඇති පරිදි:
වාර්ගික මහල් නිවාසයක් සමඟ ප්‍රතිසමයක් ඇඳිය හැකිය ... කුබර්නෙටස් දේපල වෙළඳාම්කරුවෙකු ලෙස ක්රියා කරයි. නමුත් කුලී නිවැසියන් එකිනෙකා සමඟ ගැටුම් ඇති කර ගන්නේ කෙසේද? ඔවුන්ගෙන් එක් කෙනෙක්, කියනවා නම්, දින භාගයක් සඳහා නාන කාමරය ණයට ගැනීමට තීරණය කරන්නේ නම්?
මෙන්න අල්ලා ගැනීම. එක් නොසැලකිලිමත් බහාලුමක් යන්ත්‍රයක පවතින සියලුම CPU සම්පත් අනුභව කළ හැකිය. ඔබට ස්මාර්ට් යෙදුම් තොගයක් තිබේ නම් (උදාහරණයක් ලෙස, JVM, Go, Node VM නිසි ලෙස වින්‍යාස කර ඇත), එවිට මෙය ගැටළුවක් නොවේ: ඔබට එවැනි තත්වයන් තුළ දිගු කාලයක් වැඩ කළ හැකිය. නමුත් යෙදුම් දුර්වල ලෙස ප්‍රශස්ත කර ඇත්නම් හෝ කිසිසේත් ප්‍රශස්ත නොවේ නම් (FROM java:latest), තත්වය පාලනයෙන් තොර විය හැක. Omio හි අප සතුව ප්‍රධාන භාෂා තොගය සඳහා ප්‍රමාණවත් පෙරනිමි සැකසුම් සහිත ස්වයංක්‍රීය පාදක Dockerfiles ඇත, එබැවින් මෙම ගැටළුව නොතිබුණි.
ප්‍රමිතික නිරීක්ෂණය කිරීම අපි නිර්දේශ කරමු (භාවිතය, සන්තෘප්තිය සහ දෝෂ), API ප්‍රමාදයන් සහ දෝෂ අනුපාත. ප්රතිඵල අපේක්ෂාවන් සපුරාලන බවට සහතික වන්න.
යොමු
මේ අපේ කතාවයි. සිදුවන්නේ කුමක්ද යන්න තේරුම් ගැනීමට පහත සඳහන් ද්‍රව්‍ය බෙහෙවින් උපකාරී විය:
- ;
- ;
- ;
- ;
- - "cpu throttling" සඳහා සොයන්න.
Kubernetes දෝෂ වාර්තා:
- ;
- ;
- .
ඔබේ භාවිතයේදී ඔබට සමාන ගැටළු වලට මුහුණ දී තිබේද නැතහොත් බහාලුම් නිෂ්පාදන පරිසරයන් තුළ තෙරපීම සම්බන්ධ අත්දැකීම් තිබේද? අදහස් දැක්වීමේදී ඔබේ කතාව බෙදා ගන්න!
පරිවර්තකගෙන් PS
අපගේ බ්ලොග් අඩවියේ ද කියවන්න:
- «»;
- «»;
- «".
මූලාශ්රය: www.habr.com