Kubernetes කාර්ය සාධන ඉඟි නවයක්

ආයුබෝවන් සියල්ලටම! මගේ නම Oleg Sidorenkov, මම DomClick හි යටිතල පහසුකම් කණ්ඩායමේ ප්රධානියා ලෙස වැඩ කරමි. අපි වසර තුනකට වැඩි කාලයක් නිෂ්පාදනයේ කුබික් භාවිතා කර ඇති අතර, මෙම කාලය තුළ අපි එය සමඟ විවිධ රසවත් අවස්ථා අත්විඳ ඇත්තෙමු. අද මම ඔබට කියන්නම්, නිවැරදි ප්‍රවේශය සමඟින්, ඔබේ පොකුර සඳහා වැනිලා කුබර්නෙට්ස් වෙතින් ඊටත් වඩා කාර්ය සාධනයක් මිරිකා ගත හැකි ආකාරය. සූදානම් ස්ථාවර ගමනක්!

Kubernetes යනු බහාලුම් වාද්‍ය වෘන්දය සඳහා පරිමාණය කළ හැකි විවෘත කේත පද්ධතියක් බව ඔබ සැවොම හොඳින් දනී. හොඳයි, හෝ සේවාදායක පරිසරයක් තුළ ඔබේ ක්ෂුද්‍ර සේවාවල ජීවන චක්‍රය කළමනාකරණය කිරීමෙන් මැජික් ක්‍රියා කරන ද්විමය 5 ක්. මීට අමතරව, එය විවිධ කාර්යයන් සඳහා උපරිම අභිරුචිකරණය සඳහා Lego මෙන් එකලස් කළ හැකි තරමක් නම්‍යශීලී මෙවලමකි.

සෑම දෙයක්ම හොඳින් ඇති බව පෙනේ: දර වැනි පොකුරට සේවාදායකයන් ගිනි පෙට්ටියකට විසි කරන්න, එවිට ඔබ කිසිදු දුකක් නොදනී. නමුත් ඔබ පරිසරය වෙනුවෙන් නම්, ඔබට මෙසේ සිතෙනු ඇත: "ගින්න නිවාගෙන වනාන්තරය ඉතිරි කරන්නේ කෙසේද?" වෙනත් වචන වලින් කිවහොත්, යටිතල පහසුකම් වැඩිදියුණු කිරීමට සහ පිරිවැය අඩු කිරීමට මාර්ග සොයා ගන්නේ කෙසේද.

1. නිරීක්ෂණ කණ්ඩායම සහ යෙදුම් සම්පත්

වඩාත් පොදු, නමුත් ඵලදායී ක්රමයක් වන්නේ ඉල්ලීම් / සීමාවන් හඳුන්වා දීමයි. යෙදුම් නාම අවකාශ මගින් සහ නාම අවකාශ සංවර්ධන කණ්ඩායම් මගින් බෙදන්න. යෙදවීමට පෙර, ප්‍රොසෙසරයේ කාලය, මතකය සහ තාවකාලික ආචයනය සඳහා යෙදුම් අගයන් සකසන්න.

resources:
   requests:
     memory: 2Gi
     cpu: 250m
   limits:
     memory: 4Gi
     cpu: 500m

අත්දැකීම් තුළින්, අපි නිගමනයට පැමිණියෙමු: ඔබ සීමාවන්ගෙන් ඉල්ලීම් දෙවරකට වඩා වැඩි නොකළ යුතුය. පොකුරේ පරිමාව ගණනය කරනු ලබන්නේ ඉල්ලීම් මත වන අතර, ඔබ යෙදුම් වලට සම්පත් වල වෙනසක් ලබා දෙන්නේ නම්, උදාහරණයක් ලෙස, 5-10 වාරයක්, එවිට ඔබේ නෝඩය කරල් වලින් පුරවා හදිසියේම බරක් ලැබුණු විට කුමක් සිදුවේදැයි සිතා බලන්න. හොඳ කිසිවක් නැත. අවම වශයෙන්, තෙරපීම සහ උපරිම වශයෙන්, ඔබ සේවකයාට සමු දෙන අතර කරල් චලනය වීමට පටන් ගත් පසු ඉතිරි නෝඩ් මත චක්‍රීය බරක් ලබා ගනී.

ඊට අමතරව, උපකාරයෙන් limitranges ආරම්භයේදී, ඔබට බහාලුම් සඳහා සම්පත් අගයන් සැකසිය හැකිය - අවම, උපරිම සහ පෙරනිමිය:

➜  ~ kubectl describe limitranges --namespace ops
Name:       limit-range
Namespace:  ops
Type        Resource           Min   Max   Default Request  Default Limit  Max Limit/Request Ratio
----        --------           ---   ---   ---------------  -------------  -----------------------
Container   cpu                50m   10    100m             100m           2
Container   ephemeral-storage  12Mi  8Gi   128Mi            4Gi            -
Container   memory             64Mi  40Gi  128Mi            128Mi          2

එක් කණ්ඩායමකට පොකුරේ සියලු සම්පත් අත්පත් කර ගැනීමට නොහැකි වන පරිදි නාම අවකාශ සම්පත් සීමා කිරීමට අමතක නොකරන්න:

➜  ~ kubectl describe resourcequotas --namespace ops
Name:                   resource-quota
Namespace:              ops
Resource                Used          Hard
--------                ----          ----
limits.cpu              77250m        80
limits.memory           124814367488  150Gi
pods                    31            45
requests.cpu            53850m        80
requests.memory         75613234944   150Gi
services                26            50
services.loadbalancers  0             0
services.nodeports      0             0

විස්තරයෙන් දැකිය හැකි පරිදි resourcequotas, ops කණ්ඩායමට තවත් cpu 10 ක් පරිභෝජනය කරන කරල් යෙදවීමට අවශ්‍ය නම්, උපලේඛකයා මෙයට ඉඩ නොදෙන අතර දෝෂයක් ඇති කරයි:

Error creating: pods "nginx-proxy-9967d8d78-nh4fs" is forbidden: exceeded quota: resource-quota, requested: limits.cpu=5,requests.cpu=5, used: limits.cpu=77250m,requests.cpu=53850m, limited: limits.cpu=10,requests.cpu=10

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

2. ප්‍රශස්ත ගොනු ගබඩාව තෝරන්න

මෙහිදී මම ස්ථීර වෙළුම් සහ Kubernetes සේවක නෝඩ් වල තැටි උප පද්ධතිය යන මාතෘකාව ස්පර්ශ කිරීමට කැමතියි. නිෂ්පාදනයේ HDD මත කිසිවෙකු "කියුබ්" භාවිතා නොකරන බව මම බලාපොරොත්තු වෙමි, නමුත් සමහර විට සාමාන්ය SSD තවදුරටත් ප්රමාණවත් නොවේ. I/O මෙහෙයුම් හේතුවෙන් ලොග තැටිය විනාශ කරන ගැටලුවකට අප මුහුණ දී ඇති අතර බොහෝ විසඳුම් නොමැත:

• ඉහළ කාර්යසාධනයක් සහිත SSD භාවිතා කරන්න හෝ NVMe වෙත මාරු වන්න (ඔබ ඔබේම දෘඩාංග කළමනාකරණය කරන්නේ නම්).

• ලොග් මට්ටම අඩු කරන්න.

• තැටිය දූෂණය කරන කරල්වල "ස්මාර්ට්" තුලනය කරන්න (podAntiAffinity).

ඉහත තිරය, access_logs logging සක්‍රීය කළ විට තැටියට nginx-ingress-controller යටතේ සිදුවන්නේ කුමක්ද යන්න පෙන්වයි (~12 දහසක් logs/sec). මෙම තත්ත්වය, ඇත්ත වශයෙන්ම, මෙම නෝඩයේ සියලුම යෙදුම්වල පිරිහීමට හේතු විය හැක.

PV සම්බන්ධයෙන් ගත් කල, අහෝ, මම සෑම දෙයක්ම උත්සාහ කර නැත වර්ග ස්ථීර වෙළුම්. ඔබට ගැලපෙන හොඳම විකල්පය භාවිතා කරන්න. ඓතිහාසිකව, අපගේ රටේ සිදු වී ඇත්තේ කුඩා සේවා කොටසක් RWX වෙළුම් අවශ්ය වන අතර, බොහෝ කලකට පෙර ඔවුන් මෙම කාර්යය සඳහා NFS ගබඩාව භාවිතා කිරීමට පටන් ගත්හ. ලාබ සහ... ඇති. ඇත්ත වශයෙන්ම, ඔහු සහ මම ජරාව කෑවා - ඔබට ආශීර්වාද කරන්න, නමුත් අපි එය සුසර කිරීමට ඉගෙන ගත්තෙමු, මගේ හිස තවදුරටත් රිදවන්නේ නැත. හැකි නම්, S3 වස්තු ගබඩාව වෙත යන්න.

3. ප්‍රශස්ත රූප එකතු කරන්න

Kubernetes හට ඒවා ඉක්මනින් ලබා ගැනීමට සහ වඩාත් කාර්යක්ෂමව ක්‍රියාත්මක කිරීමට හැකි වන පරිදි බහාලුම්-ප්‍රශස්ත කළ රූප භාවිතා කිරීම වඩාත් සුදුසුය. 

ප්‍රශස්තකරණය යනු රූප:

• එක් යෙදුමක් පමණක් අඩංගු හෝ එක් කාර්යයක් පමණක් සිදු කරන්න;

• ප්‍රමාණයෙන් කුඩා, විශාල රූප ජාලය හරහා වඩාත් නරක ලෙස සම්ප්‍රේෂණය වන නිසා;

• ක්‍රියා විරහිත අවස්ථාවකදී ක්‍රියා කිරීමට Kubernetes හට ඉඩ සලසන සෞඛ්‍ය සහ සූදානම අවසන් ලක්ෂ්‍ය තිබීම;

• වින්‍යාස දෝෂ වලට වඩා ප්‍රතිරෝධී බහාලුම් හිතකාමී මෙහෙයුම් පද්ධති (Alpine හෝ CoreOS වැනි) භාවිතා කරන්න;

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

පියාසර කිරීමේදී පින්තූර පරීක්ෂා කිරීමට සහ ප්‍රශස්ත කිරීමට ඔබට ඉඩ සලසන බොහෝ මෙවලම් සහ සේවාවන් තිබේ. ඒවා සැමවිටම යාවත්කාලීනව තබා ගැනීම සහ ආරක්ෂාව සඳහා පරීක්ෂා කිරීම වැදගත් වේ. ප්රතිඵලයක් වශයෙන් ඔබට ලැබෙන්නේ:

1. සම්පූර්ණ පොකුරේ ජාල භාරය අඩු කිරීම.

2. බහාලුම් ආරම්භක කාලය අඩු කිරීම.

3. ඔබේ සම්පූර්ණ ඩොකර් රෙජිස්ට්‍රියේ කුඩා ප්‍රමාණය.

4. DNS හැඹිලිය භාවිතා කරන්න

අපි අධික බර ගැන කතා කරන්නේ නම්, පොකුරේ DNS පද්ධතිය සුසර නොකර ජීවිතය ඉතා නරක ය. වරෙක, Kubernetes සංවර්ධකයින් ඔවුන්ගේ kube-dns විසඳුමට සහාය දුන්හ. එය මෙහි ද ක්‍රියාත්මක කරන ලදී, නමුත් මෙම මෘදුකාංගය විශේෂයෙන් සුසර කර නොතිබූ අතර එය සරල කාර්යයක් ලෙස පෙනුනද අවශ්‍ය කාර්ය සාධනය නිපදවා නැත. පසුව coredns දර්ශනය වූ අතර, අපි එයට මාරු වූ අතර දුකක් නොතිබුණි; එය පසුව K8s හි පෙරනිමි DNS සේවාව බවට පත් විය. යම් අවස්ථාවක දී, අපි DNS පද්ධතියට rps 40 දක්වා වර්ධනය වූ අතර, මෙම විසඳුම ද ප්රමාණවත් නොවීය. නමුත්, වාසනාවකට මෙන්, Nodelocaldns එළියට ආවා, aka node local cache, aka NodeLocal DNSCache.

අපි මෙය භාවිතා කරන්නේ ඇයි? Linux කර්නලයේ දෝෂයක් ඇත, එය UDP හරහා NAT හරහා විවිධ ඇමතුම් ලබා ගන්නා විට, conntrack වගු තුළට ඇතුළත් කිරීම් සඳහා ධාවන තත්ත්වයකට තුඩු දෙන අතර, NAT හරහා ගමනාගමනයෙන් කොටසක් අහිමි වේ (සේවාව හරහා සෑම සංචාරයක්ම NAT වේ). Nodelocaldns NAT ඉවත් කිරීමෙන් සහ TCP වෙත සම්බන්ධතාවය upstream DNS වෙත උත්ශ්‍රේණි කිරීමෙන් මෙන්ම දේශීයව upstream DNS විමසුම් (තත්පර 5-කෙටි සෘණ හැඹිලියක් ඇතුළුව) හැඹිලි කිරීමෙන් මෙම ගැටළුව විසඳයි.

5. කරල් තිරස් අතට සහ සිරස් අතට ස්වයංක්‍රීයව පරිමාණය කරන්න

ඔබේ සියලුම ක්ෂුද්‍ර සේවා බර දෙතුන් ගුණයකින් වැඩි කිරීමට සූදානම් බව ඔබට විශ්වාසයෙන් කිව හැකිද? ඔබගේ යෙදුම් සඳහා සම්පත් නිවැරදිව වෙන් කරන්නේ කෙසේද? වැඩ ප්‍රමාණයෙන් ඔබ්බට කරල් කිහිපයක් තබා ගැනීම අනවශ්‍ය විය හැක, නමුත් ඒවා පසුපසට තබා ගැනීමෙන් සේවාව වෙත හදිසි තදබදය වැඩිවීමෙන් අක්‍රීය වීමේ අවදානමක් ඇත. වැනි සේවාවන් තිරස් Pod Autoscaler и සිරස් Pod Autoscaler.

VPA සත්‍ය භාවිතය මත පදනම්ව ඔබගේ බහාලුම්වල ඉල්ලීම්/සීමා ස්වයංක්‍රීයව ඉහළ නැංවීමට ඔබට ඉඩ සලසයි. එය ප්රයෝජනවත් විය හැක්කේ කෙසේද? ඔබ සතුව කිසියම් හේතුවක් නිසා තිරස් අතට පරිමාණය කළ නොහැකි කරල් තිබේ නම් (එය සම්පූර්ණයෙන්ම විශ්වාසදායක නොවේ), එවිට ඔබට එහි සම්පත් වල වෙනස්කම් VPA වෙත භාර දීමට උත්සාහ කළ හැකිය. එහි විශේෂාංගය මෙට්‍රික්-සේවාදායකයේ ඓතිහාසික සහ වත්මන් දත්ත මත පදනම් වූ නිර්දේශ පද්ධතියකි, එබැවින් ඔබට ස්වයංක්‍රීයව ඉල්ලීම්/සීමා වෙනස් කිරීමට අවශ්‍ය නැතිනම්, ඔබට ඔබේ බහාලුම් සඳහා නිර්දේශිත සම්පත් නිරීක්ෂණය කර CPU සුරැකීමට සැකසීම් ප්‍රශස්ත කළ හැක. පොකුරේ මතකය.

පින්තූරය ගත්තේ https://levelup.gitconnected.com/kubernetes-autoscaling-101-cluster-autoscaler-horizontal-pod-autoscaler-and-vertical-pod-2a441d9ad231

Kubernetes හි කාලසටහන්කරු සැමවිටම ඉල්ලීම් මත පදනම් වේ. ඔබ එහි කුමන අගයක් තැබුවද, උපලේඛකයා එය මත පදනම්ව සුදුසු නෝඩයක් සොයනු ඇත. කරල් තෙරපීමට හෝ මරා දැමිය යුත්තේ කවදාද යන්න තේරුම් ගැනීමට කියුබ්ලට් සඳහා සීමාවන් අගයන් අවශ්‍ය වේ. එකම වැදගත් පරාමිතිය ඉල්ලීම් අගය වන බැවින්, VPA එය සමඟ ක්‍රියා කරයි. ඔබ යෙදුමක් සිරස් අතට පරිමාණය කරන සෑම විටම, ඉල්ලීම් කුමක් විය යුතුද යන්න ඔබ නිර්වචනය කරයි. එවිට සීමාවන්ට කුමක් සිදුවේද? මෙම පරාමිතිය ද සමානුපාතිකව පරිමාණය කරනු ලැබේ.

උදාහරණයක් ලෙස, මෙන්න සාමාන්‍ය පොඩ් සැකසුම්:

resources:
   requests:
     memory: 250Mi
     cpu: 200m
   limits:
     memory: 500Mi
     cpu: 350m

ඔබේ යෙදුම නිසි ලෙස ක්‍රියාත්මක වීමට 300m CPU සහ 500Mi අවශ්‍ය බව නිර්දේශ එන්ජිම තීරණය කරයි. ඔබට පහත සැකසුම් ලැබෙනු ඇත:

resources:
   requests:
     memory: 500Mi
     cpu: 300m
   limits:
     memory: 1000Mi
     cpu: 525m

ඉහත සඳහන් කළ පරිදි, මෙය මැනිෆෙස්ටයේ ඉල්ලීම්/සීමා අනුපාතය මත පදනම් වූ සමානුපාතික පරිමාණයකි:

• CPU: 200m → 300m: අනුපාතය 1: 1.75;

• මතකය: 250Mi → 500Mi: අනුපාතය 1:2.

සම්බන්ධයෙන් එච්.ඒ.ඒ., එවිට මෙහෙයුමේ යාන්ත්රණය වඩාත් විනිවිද පෙනෙන ය. CPU සහ මතකය වැනි ප්‍රමිතික ත්‍රිෂෝල්ඩ් කර ඇති අතර, සියලුම අනුපිටපත්වල සාමාන්‍යය එළිපත්ත ඉක්මවන්නේ නම්, අගය එළිපත්තට වඩා පහළට වැටෙන තෙක් හෝ උපරිම අනුපිටපත් සංඛ්‍යාවට ළඟා වන තෙක් යෙදුම +1 උප ප්‍රමාණයකින් පරිමාණය කෙරේ.

පින්තූරය ගත්තේ https://levelup.gitconnected.com/kubernetes-autoscaling-101-cluster-autoscaler-horizontal-pod-autoscaler-and-vertical-pod-2a441d9ad231

CPU සහ මතකය වැනි සාමාන්‍ය ප්‍රමිතිකවලට අමතරව, ඔබට Prometheus වෙතින් ඔබේ අභිරුචි ප්‍රමිතික මත සීමාවන් සකසා ඔබේ යෙදුම පරිමාණය කළ යුත්තේ කවදාද යන්න පිළිබඳ වඩාත් නිවැරදි ඇඟවීම එය යැයි ඔබ සිතන්නේ නම් ඒවා සමඟ වැඩ කළ හැක. යෙදුම නිශ්චිත මෙට්‍රික් එළිපත්තට පහළින් ස්ථායී වූ පසු, HPA අවම අනුරූ සංඛ්‍යාව දක්වා කරල් පරිමාණය කිරීමට හෝ භාරය නියමිත සීමාවට පැමිණෙන තෙක් පරිමාණය කිරීමට පටන් ගනී.

6. Node Affinity සහ Pod Affinity ගැන අමතක කරන්න එපා

සියලුම නෝඩ් එකම දෘඪාංග මත ක්‍රියා නොකරන අතර, සියලුම කරල් පරිගණක-තීව්‍ර යෙදුම් ධාවනය කිරීමට අවශ්‍ය නොවේ. Kubernetes භාවිතා කරමින් නෝඩ් සහ කරල් විශේෂීකරණය කිරීමට ඔබට ඉඩ සලසයි නෝඩ් සම්බන්ධතාවය и පොඩ් ඇෆිනිටි.

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

ඔබට නෝඩ් දෙකක් ඇතැයි කියමු: එකක් සමඟ CPUType=HIGHFREQ සහ වේගවත් හරයන් විශාල සංඛ්යාවක්, තවත් එකක් සමඟ MemoryType=HIGHMEMORY වැඩි මතකයක් සහ වේගවත් කාර්ය සාධනයක්. පහසුම ක්‍රමය නම් නෝඩයකට යෙදවීම පැවරීමයි HIGHFREQකොටසට එකතු කිරීමෙන් spec මෙම තේරීම්කාරකය:

…
nodeSelector:
	CPUType: HIGHFREQ

මෙය කිරීමට වඩා මිල අධික හා විශේෂිත ක්රමයක් භාවිතා කිරීමයි nodeAffinity ක්ෂේත්රයේ affinity කොටස spec. විකල්ප දෙකක් තිබේ:

• requiredDuringSchedulingIgnoredDuringExecution: දෘඪ සැකසුම (උපලේඛකයා විසින් විශේෂිත නෝඩ් මත පමණක් කරල් යොදවනු ඇත (සහ වෙන කොහේවත් නැත));

• preferredDuringSchedulingIgnoredDuringExecution: මෘදු සැකසුම (කාලසටහන් නිශ්චිත නෝඩ් වෙත යෙදවීමට උත්සාහ කරනු ඇත, එය අසාර්ථක වුවහොත්, එය ඊළඟ පවතින නෝඩයට යෙදවීමට උත්සාහ කරනු ඇත).

වැනි නෝඩ් ලේබල් කළමනාකරණය සඳහා ඔබට නිශ්චිත වාක්‍ය ඛණ්ඩයක් නියම කළ හැක In, NotIn, Exists, DoesNotExist, Gt හෝ Lt. කෙසේ වෙතත්, ලේබල් දිගු ලැයිස්තු වල සංකීර්ණ ක්රම තීරණාත්මක අවස්ථාවන්හිදී තීරණ ගැනීම මන්දගාමී වනු ඇති බව මතක තබා ගන්න. වෙනත් වචන වලින් කිවහොත්, එය සරලව තබා ගන්න.

ඉහත සඳහන් කළ පරිදි, වත්මන් කරල්වල සම්බන්ධතාවය සැකසීමට Kubernetes ඔබට ඉඩ සලසයි. එනම්, ඇතැම් කරල් එකම ලද හැකි කලාපයේ (වලාකුළු සඳහා අදාළ) හෝ නෝඩ් වල අනෙකුත් කරල් සමඟ එකට වැඩ කරන බවට ඔබට සහතික විය හැක.

В podAffinity ක්ෂේත්‍ර affinity කොටස spec නඩුවේ මෙන් එම ක්ෂේත්ර තිබේ nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution и preferredDuringSchedulingIgnoredDuringExecution. එකම වෙනස එයයි matchExpressions දැනටමත් එම ලේබලය සහිත පොඩ් එකක් ධාවනය වන නෝඩයකට කරල් බඳිනු ඇත.

Kubernetes ද ක්ෂේත්රයක් පිරිනමයි podAntiAffinity, ඊට පටහැනිව, විශේෂිත කරල් සහිත නෝඩයකට කරල් බැඳ නොගනී.

ප්රකාශන ගැන nodeAffinity එකම උපදෙස් ලබා දිය හැකිය: නීති සරලව හා තාර්කිකව තබා ගැනීමට උත්සාහ කරන්න, සංකීර්ණ නීති මාලාවක් සමඟ පොඩ් පිරිවිතර අධික ලෙස පැටවීමට උත්සාහ නොකරන්න. පොකුරේ කොන්දේසි වලට නොගැලපෙන රීතියක් නිර්මාණය කිරීම ඉතා පහසු වේ, උපලේඛකයා මත අනවශ්ය බරක් නිර්මාණය කිරීම සහ සමස්ත කාර්යසාධනය අඩු කිරීම.

7. පැල්ලම් සහ ඉවසීම්

කාලසටහන කළමනාකරණය කිරීමට තවත් ක්රමයක් තිබේ. ඔබට නෝඩ් සිය ගණනක් සහ ක්ෂුද්‍ර සේවා දහස් ගණනක් සහිත විශාල පොකුරක් තිබේ නම්, ඇතැම් නෝඩ් මත ඇතැම් කරල් සත්කාරකත්වය ලබා නොදීම ඉතා අපහසුය.

දූෂිතයන්ගේ යාන්ත්‍රණය - තහනම් නීති - මේ සඳහා උපකාරී වේ. උදාහරණයක් ලෙස, ඇතැම් අවස්ථා වලදී ඔබට කරල් ධාවනය කිරීම ඇතැම් නෝඩ් තහනම් කළ හැක. නිශ්චිත නෝඩයකට ටේන්ට් යෙදීම සඳහා ඔබ විකල්පය භාවිතා කළ යුතුය taint kubectl හි. යතුර සහ අගය සඳහන් කර පසුව ටේන්ට් ලයික් කරන්න NoSchedule හෝ NoExecute:

$ kubectl taint nodes node10 node-role.kubernetes.io/ingress=true:NoSchedule

දූෂිත යාන්ත්‍රණය ප්‍රධාන බලපෑම් තුනකට සහය දක්වන බව සඳහන් කිරීම වටී: NoSchedule, NoExecute и PreferNoSchedule.

• NoSchedule යන්නෙන් අදහස් කරන්නේ දැනට පොඩ් පිරිවිතරයේ අනුරූප ප්‍රවේශයක් නොමැති බවයි tolerations, එය නෝඩය මත යෙදවීමට නොහැකි වනු ඇත (මෙම උදාහරණයේ node10).

• PreferNoSchedule - සරල කළ අනුවාදය NoSchedule. මෙම අවස්ථාවෙහිදී, උපලේඛකයා ගැළපෙන ප්‍රවේශයක් නොමැති කරල් වෙන් නොකිරීමට උත්සාහ කරයි tolerations node එකකට, නමුත් මෙය දැඩි සීමාවක් නොවේ. පොකුරේ සම්පත් නොමැති නම්, මෙම නෝඩය මත කරල් යෙදවීමට පටන් ගනී.

• NoExecute - මෙම බලපෑම අනුරූප ඇතුල්වීමක් නොමැති කරල් ක්ෂණිකව ඉවත් කිරීම අවුලුවන tolerations.

සිත්ගන්නා කරුණ නම්, ඉවසීමේ යාන්ත්‍රණය භාවිතයෙන් මෙම හැසිරීම අවලංගු කළ හැකිය. "තහනම්" නෝඩයක් ඇති විට මෙය පහසු වන අතර ඔබ එය මත යටිතල පහසුකම් සේවා පමණක් තැබිය යුතුය. එය කරන්නේ කෙසේද? සුදුසු ඉවසීමක් ඇති කරල් වලට පමණක් ඉඩ දෙන්න.

පොඩ් පිරිවිතර කෙබඳු වනු ඇත්ද යන්න මෙන්න:

spec:
   tolerations:
     - key: "node-role.kubernetes.io/ingress"
        operator: "Equal"
        value: "true"
        effect: "NoSchedule"

මීළඟ නැවත යෙදවීම මෙම විශේෂිත නෝඩය මතට වැටෙන බව මින් අදහස් නොවේ, මෙය Node Affinity යාන්ත්‍රණය නොවේ සහ nodeSelector. නමුත් විශේෂාංග කිහිපයක් ඒකාබද්ධ කිරීමෙන් ඔබට ඉතා නම්‍යශීලී කාලසටහන් සැකසුම් ලබා ගත හැකිය.

8. Pod යෙදවීමේ ප්‍රමුඛතාවය සකසන්න

ඔබට නෝඩ් සඳහා කරල් පවරා ඇති පමණින් සියලුම කරල් එකම ප්‍රමුඛතාවයකින් සැලකිය යුතු යැයි අදහස් නොවේ. උදාහරණයක් ලෙස, ඔබට සමහර කරල් අනෙක් ඒවාට පෙර යෙදවීමට අවශ්‍ය විය හැක.

Kubernetes Pod Priority සහ Preemption වින්‍යාස කිරීමට විවිධ ක්‍රම ඉදිරිපත් කරයි. සැකසුම කොටස් කිහිපයකින් සමන්විත වේ: වස්තුව PriorityClass සහ ක්ෂේත්ර විස්තර priorityClassName පොඩ් පිරිවිතරයේ. අපි උදාහරණයක් බලමු:

apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: high-priority
value: 99999
globalDefault: false
description: "This priority class should be used for very important pods only"

අපි නිර්මාණය කරනවා PriorityClass, එයට නමක්, විස්තරයක් සහ වටිනාකමක් දෙන්න. උසස් value, ඉහළ ප්රමුඛත්වය. අගය 32 ට වඩා අඩු හෝ සමාන ඕනෑම 1-bit පූර්ණ සංඛ්‍යාවක් විය හැකිය. සාමාන්‍යයෙන් පූර්වාපේක්‍ෂා කළ නොහැකි මෙහෙයුම්-විවේචනාත්මක පද්ධති කරල් සඳහා ඉහළ අගයන් වෙන් කර ඇත. විස්ථාපනය සිදුවනු ඇත්තේ ඉහළ ප්‍රමුඛතාවයක් ඇති කරුවකට හැරවීමට ස්ථානයක් නොමැති නම් පමණි, එවිට යම් නෝඩයකින් සමහර කරල් ඉවත් කරනු ලැබේ. මෙම යාන්ත්රණය ඔබට ඉතා දැඩි නම්, ඔබට විකල්පය එකතු කළ හැකිය preemptionPolicy: Never, ඉන්පසුව පූර්වෝපායයක් සිදු නොවනු ඇත, පොඩ් පෝලිමේ මුලින්ම සිටගෙන උපලේඛකයා ඒ සඳහා නොමිලේ සම්පත් සොයා ගන්නා තෙක් බලා සිටී.

ඊළඟට, අපි නම සඳහන් කරන පොඩ් එකක් සාදන්න priorityClassName:

apiVersion: v1
kind: Pod
metadata:
  name: static-web
  labels:
    role: myrole
 spec:
  containers:
    - name: web
      image: nginx
      ports:
        - name: web
          containerPort: 80
          protocol: TCP
  priorityClassName: high-priority
          

ඔබට අවශ්‍ය තරම් ප්‍රමුඛතා පන්ති නිර්මාණය කළ හැකිය, නමුත් මෙයින් ඉවත් නොවී සිටීම රෙකමදාරු කරනු ලැබේ (කියන්න, ඔබ පහත්, මධ්‍යම සහ ඉහළ ප්‍රමුඛතාවයට සීමා කරන්න).

මේ අනුව, අවශ්‍ය නම්, ඔබට nginx-ingress-controller, coredns වැනි තීරණාත්මක සේවාවන් යෙදවීමේ කාර්යක්ෂමතාව වැඩි කළ හැකිය.

9. ETCD පොකුර ප්‍රශස්ත කරන්න

ETCD සමස්ත පොකුරේ මොළය ලෙස හැඳින්විය හැක. Cube හි මෙහෙයුම් වේගය එය මත රඳා පවතින බැවින් මෙම දත්ත සමුදායේ ක්‍රියාකාරිත්වය ඉහළ මට්ටමක පවත්වා ගැනීම ඉතා වැදගත් වේ. kube-apiserver වෙත අවම ප්‍රමාදයක් ඇති කිරීම සඳහා ETCD පොකුර ප්‍රධාන නෝඩ් මත තබා ගැනීම තරමක් ප්‍රමිතියක් සහ ඒ සමඟම හොඳ විසඳුමක් වනු ඇත. ඔබට මෙය කළ නොහැකි නම්, සහභාගිවන්නන් අතර හොඳ කලාප පළලක් සහිතව ETCD හැකිතාක් සමීපව තබන්න. පොකුරට හානියක් නොවන පරිදි ETCD වලින් නෝඩ් කීයක් වැටිය හැකිද යන්න පිළිබඳවද අවධානය යොමු කරන්න

පොකුරක සාමාජිකයින් සංඛ්‍යාව අධික ලෙස වැඩි කිරීම කාර්ය සාධනයේ වියදමින් වැරදි ඉවසීම වැඩි කළ හැකි බව මතක තබා ගන්න, සෑම දෙයක්ම මධ්‍යස්ථ විය යුතුය.

අපි සේවාව පිහිටුවීම ගැන කතා කරන්නේ නම්, නිර්දේශ කිහිපයක් තිබේ:

1. පොකුරේ ප්‍රමාණය මත පදනම්ව හොඳ දෘඪාංග තබා ගන්න (ඔබට කියවිය හැක මෙහි).

2. ඔබ DC යුගලයක් හෝ ඔබේ ජාලයක් අතර පොකුරක් විහිදුවා ඇත්නම් සහ තැටි බලාපොරොත්තු වීමට බොහෝ දේ ඉතිරි කර ඇත්නම් පරාමිති කිහිපයක් වෙනස් කරන්න (ඔබට කියවිය හැක මෙහි).

නිගමනය

මෙම ලිපිය අපගේ කණ්ඩායමට අනුකූල වීමට උත්සාහ කරන කරුණු විස්තර කරයි. මෙය ක්‍රියාවන් පිළිබඳ පියවරෙන් පියවර විස්තරයක් නොව, පොකුරු උඩිස් කිරීම සඳහා ප්‍රයෝජනවත් විය හැකි විකල්ප වේ. සෑම පොකුරක්ම තමන්ගේම ආකාරයෙන් අද්විතීය වන අතර, වින්‍යාස විසඳුම් බොහෝ සෙයින් වෙනස් විය හැකි බව පැහැදිලිය, එබැවින් ඔබ ඔබේ Kubernetes පොකුර නිරීක්ෂණය කරන ආකාරය සහ ඔබ එහි ක්‍රියාකාරිත්වය වැඩි දියුණු කරන ආකාරය පිළිබඳ ඔබේ ප්‍රතිපෝෂණය ලබා ගැනීම සිත්ගන්නාසුළු වනු ඇත. අදහස් දැක්වීමේදී ඔබේ අත්දැකීම් බෙදාගන්න, එය දැන ගැනීමට සිත්ගන්නාසුළු වනු ඇත.

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