ProHoster > බ්ලොග් > පරිපාලනය > Kubernetes භාවිතා කරන විට 10 පොදු වැරදි

Kubernetes භාවිතා කරන විට 10 පොදු වැරදි

සටහන. පරිවර්තනය.: මෙම ලිපියේ කතුවරුන් කුඩා චෙක් සමාගමක් වන පයිප්ටේල් හි ඉංජිනේරුවන් වේ. Kubernetes පොකුරු ක්‍රියාත්මක කිරීම හා සම්බන්ධ ඉතා දැවෙන ගැටළු සහ වැරදි වැටහීම් [සමහර විට අශෝභන, නමුත් තවමත්] අපූරු ලැයිස්තුවක් එක් කිරීමට ඔවුන් සමත් විය.

Kubernetes භාවිතා කරන විට 10 පොදු වැරදි

Kubernetes භාවිතා කළ වසර ගණනාවක් පුරා, අපි පොකුරු විශාල සංඛ්‍යාවක් සමඟ වැඩ කර ඇත (කළමනාකරණය කළ සහ කළමනාකරණය නොකළ - GCP, AWS සහ Azure මත). කාලයාගේ ඇවෑමෙන්, සමහර වැරදි නිරන්තරයෙන් පුනරාවර්තනය වන බව අපට පෙනෙන්නට පටන් ගත්තේය. කෙසේ වෙතත්, මෙහි ලැජ්ජාවක් නැත: අපි ඒවායින් බොහොමයක් අප විසින්ම කර ඇත!

ලිපියෙහි වඩාත් පොදු දෝෂ අඩංගු වන අතර ඒවා නිවැරදි කරන ආකාරය ද සඳහන් කරයි.

1. සම්පත්: ඉල්ලීම් සහ සීමාවන්

මෙම අයිතමය නිසැකවම සමීපතම අවධානය සහ ලැයිස්තුවේ පළමු ස්ථානය ලැබිය යුතුය.

CPU ඉල්ලීම සාමාන්‍යයෙන් එක්කෝ සම්පූර්ණයෙන්ම සඳහන් කර නැත හෝ ඉතා අඩු අගයක් ඇත (හැකි තරම් සෑම නෝඩයකම කරල් තැබීමට). මේ අනුව, නෝඩ් අධික ලෙස පටවනු ලැබේ. අධික බරක් ඇති කාලවලදී, නෝඩයේ සැකසුම් බලය සම්පූර්ණයෙන්ම භාවිතා වන අතර යම් කාර්ය භාරයකට ලැබෙන්නේ එය "ඉල්ලන" දේ පමණි. CPU තෙරපුම. මෙය යෙදුම් ප්‍රමාදය, කල් ඉකුත්වීම් සහ වෙනත් අප්‍රසන්න ප්‍රතිවිපාක වැඩි කිරීමට හේතු වේ. (අපගේ අනෙකුත් මෑත පරිවර්තනයෙන් මේ ගැන වැඩිදුර කියවන්න: "Kubernetes හි CPU සීමාවන් සහ ආක්‍රමණශීලී තෙරපුම"- ආසන්න වශයෙන්. පරිවර්තනය.)

හොඳම උත්සාහය (අතිශයින්ම නෑ නිර්දේශිත):

resources: {}

ඉතා අඩු CPU ඉල්ලීමක් (අතිශයින්ම නෑ නිර්දේශිත):

   resources:
      Requests:
        cpu: "1m"

අනෙක් අතට, CPU සීමාවක් තිබීම නෝඩ් ප්‍රොසෙසරය සම්පූර්ණයෙන්ම පටවා නොතිබුණද, පොඩ්ස් මගින් ඔරලෝසු චක්‍ර අසාධාරණ ලෙස මඟ හැරීමට හේතු විය හැක. නැවතත්, මෙය ප්රමාදයන් වැඩි කිරීමට හේතු විය හැක. පරාමිතිය වටා මතභේදය දිගටම පවතී CPU CFS කෝටාව Linux kernel සහ CPU හි නියම කර ඇති සීමාවන් මත තෙරපීම, මෙන්ම CFS කෝටාව අක්‍රිය කිරීම... අහෝ, CPU සීමාවන් විසඳිය හැකි ප්‍රමාණයට වඩා ගැටලු ඇති කළ හැක. මේ පිළිබඳ වැඩි විස්තර පහත සබැඳියෙන් සොයාගත හැකිය.

අධික තේරීම (අධික කැපවීම) මතක ගැටළු විශාල ගැටළු වලට තුඩු දිය හැකිය. CPU සීමාවට ළඟා වීම ඔරලෝසු චක්‍ර මඟ හැරීමට හේතු වන අතර මතක සීමාවට ළඟා වීම පොඩ් මරා දැමීමකි. ඔබ කවදා හෝ නිරීක්ෂණය කර තිබේද OOMkill? ඔව්, අපි කතා කරන්නේ හරියටම එයයි.

මෙය සිදුවීමේ සම්භාවිතාව අවම කිරීමට ඔබට අවශ්‍යද? මතක ඉල්ලීම සීමාවට සැකසීමෙන් (පහත උදාහරණයේ මෙන්) මතකය අධික ලෙස වෙන් කර සහතික කළ QoS (සේවාවේ ගුණාත්මකභාවය) භාවිතා නොකරන්න. මේ ගැන වැඩිදුර කියවන්න Henning Jacobs ඉදිරිපත් කිරීම් (Zalando හි ප්රධාන ඉංජිනේරු).

පුපුරා යා හැකි (OOMkilled ලබා ගැනීමේ වැඩි සම්භාවිතාව):

   resources:
      requests:
        memory: "128Mi"
        cpu: "500m"
      limits:
        memory: "256Mi"
        cpu: 2

සහතික කර ඇත:

   resources:
      requests:
        memory: "128Mi"
        cpu: 2
      limits:
        memory: "128Mi"
        cpu: 2

සම්පත් සැකසීමේදී උපකාර විය හැක්කේ කුමක් ද?

සහාය ඇතිව metrics-server ඔබට වර්තමාන CPU සම්පත් පරිභෝජනය සහ කරල් (සහ ඒවා තුළ ඇති බහාලුම්) මගින් මතක භාවිතය දැකිය හැක. බොහෝ දුරට, ඔබ දැනටමත් එය භාවිතා කරයි. පහත විධානයන් ක්‍රියාත්මක කරන්න:

kubectl top pods
kubectl top pods --containers
kubectl top nodes

කෙසේ වෙතත්, ඒවා වත්මන් භාවිතය පමණක් පෙන්වයි. එය ඔබට විශාලත්වයේ අනුපිළිවෙල පිළිබඳ දළ අදහසක් ලබා දිය හැකිය, නමුත් අවසානයේ ඔබට අවශ්ය වනු ඇත කාලයත් සමඟ මිනුම්වල වෙනස්වීම් ඉතිහාසය (මෙවැනි ප්‍රශ්නවලට පිළිතුරු දීමට: "උච්ච CPU භාරය කුමක්ද?", "ඊයේ උදෑසන බර කුමක්ද?", ආදිය). මේ සඳහා ඔබට භාවිතා කළ හැකිය Prometheus, DataDog සහ වෙනත් මෙවලම්. ඔවුන් හුදෙක් මෙට්‍රික්-සේවාදායකයෙන් ප්‍රමිතික ලබාගෙන ඒවා ගබඩා කරන අතර පරිශීලකයාට ඒවා විමසා ඒ අනුව සැලසුම් කළ හැකිය.

සිරස් PodAutoscaler එය ඉඩ ස්වයංක්‍රීය කරන්න මෙම ක්රියාවලිය. එය CPU සහ මතක භාවිත ඉතිහාසය නිරීක්ෂණය කරන අතර මෙම තොරතුරු මත පදනම්ව නව ඉල්ලීම් සහ සීමාවන් සකසයි.

පරිගණක බලය කාර්යක්ෂමව භාවිතා කිරීම පහසු කාර්යයක් නොවේ. ඒක හරියට ටෙට්‍රිස් සෙල්ලම් කරනවා වගේ. ඔබ අඩු සාමාන්‍ය පරිභෝජනයක් සහිත (~10% කියන්න) ගණනය කිරීමේ බලය සඳහා වැඩිපුර ගෙවන්නේ නම්, අපි AWS Fargate හෝ Virtual Kubelet මත පදනම් වූ නිෂ්පාදන දෙස බැලීමට නිර්දේශ කරමු. ඒවා සර්වර් රහිත/භාවිතයට ගෙවන බිල්පත් ආකෘතියක් මත ගොඩනගා ඇති අතර, එවැනි තත්ත්‍වයන්හිදී එය ලාභදායී විය හැක.

2. සජීවී බව සහ සූදානම පිරික්සුම්

පෙරනිමියෙන්, Kubernetes හි සජීවී බව සහ සූදානම පරීක්ෂා කිරීම සබල නොවේ. සමහර විට ඒවා සක්‍රිය කිරීමට ඔවුන්ට අමතක වේ ...

නමුත් මාරාන්තික දෝෂයක් ඇති වූ විට ඔබට සේවාව නැවත ආරම්භ කිරීම ආරම්භ කළ හැක්කේ කෙසේද? අනික load balancer එක දැනගන්නේ කොහොමද පොඩ් එකක් ට්‍රැෆික් බාර ගන්න ලෑස්තියි කියලා? එසේත් නැතිනම් වැඩි තදබදයක් පාලනය කළ හැකිද?

මෙම පරීක්ෂණ බොහෝ විට එකිනෙකා සමඟ ව්යාකූල වේ:

  • සජීවී බව - "ජීවත්වීමේ" පරීක්ෂාව, එය අසාර්ථක වුවහොත් එය නැවත ආරම්භ කරයි;
  • සූදානම - සූදානම පරීක්ෂා කරන්න, එය අසාර්ථක වුවහොත්, එය Kubernetes සේවාවෙන් පොඩ් විසන්ධි කරයි (මෙය භාවිතයෙන් පරීක්ෂා කළ හැක kubectl get endpoints) සහ මීළඟ චෙක්පත සාර්ථකව අවසන් වන තුරු ගමනාගමනය එයට නොපැමිණේ.

මෙම චෙක්පත් දෙකම පොඩ්ගේ මුළු ජීවිත චක්‍රය තුළම සිදු කරන ලදී. එය ඉතා වැදගත්.

සාමාන්‍ය වැරදි වැටහීමක් නම්, සූදානම පරීක්ෂණ ආරම්භයේදී පමණක් ක්‍රියාත්මක වන අතර එමඟින් පොඩ් එක සූදානම් බව සමතුලිතයාට දැනගත හැකිය (Ready) සහ ගමනාගමනය සැකසීම ආරම්භ කළ හැක. කෙසේ වෙතත්, මෙය ඔවුන්ගේ භාවිතය සඳහා විකල්ප වලින් එකක් පමණි.

තවත් දෙයක් නම්, පෝඩ් එකේ තදබදය අධික බව සොයා ගැනීමට ඇති හැකියාවයි එය අධික ලෙස පටවයි (හෝ පොඩ් සම්පත්-දැඩි ගණනය කිරීම් සිදු කරයි). මෙම අවස්ථාවේදී, සූදානම පරීක්ෂා කිරීම උපකාරී වේ කරල් මත බර අඩු කර එය "සිසිල්" කරන්න. අනාගතයේ දී සූදානම පරීක්ෂාව සාර්ථකව නිම කිරීම ඉඩ සලසයි නැවත පොඩ් මත බර වැඩි කරන්න. මෙම අවස්ථාවේ දී (සූදානම පරීක්ෂණය අසමත් වුවහොත්), සජීවී පරීක්ෂණය අසමත් වීම ඉතා ප්‍රතිපලදායක වනු ඇත. සෞඛ්‍ය සම්පන්න සහ වෙහෙස මහන්සි වී වැඩ කරන පොඩ් එකක් නැවත ආරම්භ කරන්නේ ඇයි?

එමනිසා, සමහර අවස්ථාවලදී, වැරදි ලෙස වින්‍යාස කර ඇති පරාමිති සමඟ ඒවා සක්‍රීය කිරීමට වඩා කිසිදු චෙක්පතක් වඩා හොඳ නොවේ. ඉහත සඳහන් කළ පරිදි, නම් සජීවී චෙක්පත පිටපත් සූදානම පරීක්ෂාව, එහෙනම් ඔයා ලොකු අමාරුවක වැටිලා. හැකි විකල්පය වන්නේ වින්යාස කිරීමයි සූදානම පරීක්ෂණය පමණිහා භයානක සජීවී බව පසෙකින් තබන්න.

පොදු පරායත්තතා අසාර්ථක වූ විට චෙක්පත් වර්ග දෙකම අසාර්ථක නොවිය යුතුය, එසේ නොමැතිනම් මෙය සියලු කරල්වල කඳුරැල්ලක් (අවලංචි වැනි) අසාර්ථක වීමට හේතු වේ. වෙනත් විදිහකින්, ඔබට හානියක් නොකරන්න.

3. එක් එක් HTTP සේවාව සඳහා LoadBalancer

බොහෝ දුරට, ඔබ බාහිර ලෝකයට යොමු කිරීමට කැමති HTTP සේවාවන් ඔබේ පොකුරේ ඇත.

ඔබ සේවාව විවෘත කරන්නේ නම් type: LoadBalancer, එහි පාලකය (සේවා සපයන්නා මත පදනම්ව) බාහිර LoadBalancer (අවශ්‍යයෙන්ම L7 මත ධාවනය නොවේ, නමුත් L4 මත පවා) ලබා දීම සහ සාකච්ඡා කරනු ඇති අතර, මෙය පිරිවැයට බලපෑ හැකිය (බාහිර ස්ථිතික IPv4 ලිපිනය, පරිගණක බලය, තත්පරයට බිල්පත් කිරීම ) එවැනි සම්පත් විශාල සංඛ්යාවක් නිර්මාණය කිරීමේ අවශ්යතාවය හේතුවෙන්.

මෙම අවස්ථාවේ දී, එක් බාහිර පැටවුම් සමතුලිතතාවයක් භාවිතා කිරීම වඩා තාර්කික ය, සේවා විවෘත කිරීම type: NodePort. නැත්නම් වඩා හොඳයි, එවැනි දෙයක් පුළුල් කරන්න nginx-ingress-controller (හෝ traefik), එකම කෙනා කවුද NodePort අන්ත ලක්ෂ්‍යය බාහිර පැටවුම් සමතුලිතකය හා සම්බන්ධ වන අතර එය භාවිතා කරමින් පොකුරේ ගමනාගමනය මෙහෙයවනු ඇත ඇතුල්වීම-කුබර්නෙට්ස් සම්පත්.

එකිනෙකා සමඟ අන්තර් ක්‍රියා කරන අනෙකුත් අන්තර්-පොකුරු (ක්ෂුද්‍ර) සේවා වැනි සේවාවන් භාවිතයෙන් "සන්නිවේදනය" කළ හැක ClusterIP සහ DNS හරහා බිල්ට් සේවා සොයා ගැනීමේ යාන්ත්‍රණයක්. ඔවුන්ගේ පොදු DNS/IP භාවිතා නොකරන්න, මෙය ප්‍රමාදයට බලපෑම් කළ හැකි අතර ක්ලවුඩ් සේවාවල පිරිවැය වැඩි කරයි.

4. එහි ලක්ෂණ සැලකිල්ලට නොගෙන පොකුරක් ස්වයංක්‍රීයව පරිමාණය කිරීම

පොකුරකට නෝඩ් එකතු කිරීමේදී සහ ඒවා ඉවත් කිරීමේදී, ඔබ එම නෝඩ් වල CPU භාවිතය වැනි මූලික ප්‍රමිතික මත විශ්වාසය නොතැබිය යුතුය. Pod සැලසුම් කිරීම බොහෝ දේ සැලකිල්ලට ගත යුතුය සීමා, Pod/node affinity, taints and tolerations, resource requests, QoS, etc. මෙම සූක්ෂ්ම කරුණු සැලකිල්ලට නොගන්නා බාහිර ස්වයංක්‍රීය පරිමාණය භාවිතා කිරීම ගැටළු වලට තුඩු දිය හැකිය.

කිසියම් පොඩ් එකක් උපලේඛනගත කළ යුතු යැයි සිතන්න, නමුත් පවතින සියලුම CPU බලය ඉල්ලා ඇත/විසුරුවා හරිනු ලැබේ සහ පොඩ් තත්වයක හිර වෙනවා Pending. බාහිර ස්වයංක්‍රීය පරිමාණය සාමාන්‍ය වත්මන් CPU භාරය (ඉල්ලන ලද එක නොවේ) දකින අතර ප්‍රසාරණය ආරම්භ නොකරයි (පරිමාණයෙන් පිටතට) - වෙනත් නෝඩයක් එකතු නොකරයි. එහි ප්‍රතිඵලයක් ලෙස මෙම පොඩ් එක කාලසටහන්ගත නොවනු ඇත.

මෙම අවස්ථාවේදී, ප්‍රතිලෝම පරිමාණය (පරිමාණයෙන්) - පොකුරකින් නෝඩයක් ඉවත් කිරීම සෑම විටම ක්රියාත්මක කිරීම වඩාත් අපහසු වේ. ඔබ සතුව රාජ්‍යමය පොඩ් එකක් ඇති බව සිතන්න (ස්ථිර ගබඩාව සම්බන්ධිත). ස්ථීර වෙළුම් සාමාන්යයෙන් අයත් වේ නිශ්චිත ලබා ගත හැකි කලාපය සහ කලාපය තුළ ප්රතිනිෂ්පාදනය නොවේ. මේ අනුව, බාහිර ස්වයංක්‍රීය පරිමාණය කරන්නෙකු මෙම පොඩ් සමඟ නෝඩයක් මකා දැමුවහොත්, උපලේඛකයාට මෙම පොඩ් එක වෙනත් නෝඩයක උපලේඛනගත කිරීමට නොහැකි වනු ඇත, මන්ද මෙය කළ හැක්කේ ස්ථිර ගබඩාව පිහිටා ඇති ලද හැකි කලාපයේ පමණි. Pod රාජ්යයේ සිරවී ඇත Pending.

Kubernetes ප්රජාව තුළ ඉතා ජනප්රියයි පොකුරු-ස්වයං පරිමාණය. එය පොකුරක් මත ක්‍රියා කරයි, ප්‍රධාන වලාකුළු සපයන්නන්ගෙන් API සඳහා සහය දක්වයි, සියලු සීමා කිරීම් සැලකිල්ලට ගනී සහ ඉහත අවස්ථා වලදී පරිමාණය කළ හැකිය. එය සියලු නියම කර ඇති සීමාවන් පවත්වා ගනිමින් පරිමාණය කිරීමට ද හැකි වන අතර එමඟින් මුදල් ඉතිරි වේ (එය නොඑසේ නම් භාවිතයට නොගත් ධාරිතාව සඳහා වැය වේ).

5. IAM/RBAC හැකියාවන් නොසලකා හැරීම

නොනවතින රහස් ඇති IAM භාවිතා කරන්නන් භාවිතා කිරීමෙන් පරිස්සම් වන්න යන්ත්ර සහ යෙදුම්. භූමිකාවන් සහ සේවා ගිණුම් භාවිතයෙන් තාවකාලික ප්‍රවේශය සංවිධානය කරන්න (සේවා ගිණුම්).

යෙදුම් වින්‍යාසය තුළ ප්‍රවේශ යතුරු (සහ රහස්) දෘඪ කේත කර ඇති බව මෙන්ම Cloud IAM වෙත ප්‍රවේශය තිබියදීත් රහස් භ්‍රමණය නොසලකා හැරීම අපට බොහෝ විට හමු වේ. සුදුසු අවස්ථාවලදී භාවිතා කරන්නන් වෙනුවට IAM භූමිකාවන් සහ සේවා ගිණුම් භාවිතා කරන්න.

Kubernetes භාවිතා කරන විට 10 පොදු වැරදි

kube2iam ගැන අමතක කර සේවා ගිණුම් සඳහා IAM භූමිකාවන් වෙත කෙලින්ම යන්න ( විස්තර කර ඇති පරිදි එකම නමේ සටහන ස්ටෙපන් Vraný):

apiVersion: v1
kind: ServiceAccount
metadata:
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::123456789012:role/my-app-role
  name: my-serviceaccount
  namespace: default

එක් විවරණයක්. එච්චර අමාරු නෑ නේද?

එසේම, සේවා ගිණුම් සහ උදාහරණ පැතිකඩ වරප්‍රසාද ලබා නොදෙන්න admin и cluster-adminඔවුන්ට එය අවශ්ය නොවේ නම්. විශේෂයෙන්ම RBAC K8s වල මෙය ක්‍රියාත්මක කිරීමට ටිකක් අපහසු නමුත් අනිවාර්යයෙන්ම උත්සාහය වටී.

6. කරල් සඳහා ස්වයංක්‍රීය ප්‍රති-බැඳීම් මත රඳා නොසිටින්න

ඔබ නෝඩයක් මත යම් යෙදවීමක අනුරූ තුනක් ඇති බව සිතන්න. නෝඩය වැටෙන අතර, ඒ සමඟම සියලුම අනුරූ. අප්රසන්න තත්වයක් නේද? නමුත් සියලුම අනුරූ එකම නෝඩයක තිබුණේ ඇයි? Kubernetes ඉහළ ලබා ගත හැකි (HA) ලබා දිය යුතු නොවේ ද?!

අවාසනාවකට මෙන්, Kubernetes උපලේඛකයා, තමන්ගේම මූලිකත්වයෙන්, වෙනම පැවැත්මේ නීතිවලට අනුකූල නොවේ. (විරෝධී සබඳතා) කරල් සඳහා. ඒවා පැහැදිලිව සඳහන් කළ යුතුය:

// опущено для краткости
      labels:
        app: zk
// опущено для краткости
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            - labelSelector:
                matchExpressions:
                  - key: "app"
                    operator: In
                    values:
                    - zk
              topologyKey: "kubernetes.io/hostname"

එච්චරයි. දැන් කරල් විවිධ නෝඩ් මත උපලේඛනගත කරනු ඇත (මෙම තත්ත්වය පරීක්ෂා කරනු ලබන්නේ කාලසටහන්ගත කිරීමේදී පමණක් වන නමුත් ඒවායේ ක්‍රියාකාරිත්වය අතරතුර නොවේ - එබැවින් requiredDuringSchedulingIgnoredDuringExecution).

මෙන්න අපි කතා කරනවා podAntiAffinity විවිධ නෝඩ් මත: topologyKey: "kubernetes.io/hostname", - සහ විවිධ ලබා ගත හැකි කලාප ගැන නොවේ. සම්පූර්ණ HA ක්‍රියාත්මක කිරීම සඳහා, ඔබට මෙම මාතෘකාව ගැඹුරින් හාරා ගත යුතුය.

7. PodDisruptionBudgets නොසලකා හැරීම

ඔබට Kubernetes පොකුරක් මත නිෂ්පාදන බරක් ඇති බව සිතන්න. කාලානුරූපව, නෝඩ් සහ පොකුර යාවත්කාලීන කළ යුතුය (හෝ ඉවත් කළ යුතුය). PodDisruptionBudget (PDB) යනු පොකුරු පරිපාලකයින් සහ පරිශීලකයින් අතර සේවා සහතික ගිවිසුමක් වැනි දෙයකි.

නෝඩ් නොමැතිකම නිසා ඇතිවන සේවා බාධා වළක්වා ගැනීමට PDB ඔබට ඉඩ සලසයි:

apiVersion: policy/v1beta1
kind: PodDisruptionBudget
metadata:
  name: zk-pdb
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: zookeeper

මෙම උදාහරණයේදී, ඔබ, පොකුරේ පරිශීලකයෙකු ලෙස, පරිපාලකයින්ට මෙසේ ප්‍රකාශ කරයි: "ඒයි, මට සත්වෝද්‍යාන පාලක සේවාවක් ඇත, ඔබ කුමක් කළත්, අවම වශයෙන් මෙම සේවාවේ අනුරූ 2ක් සෑම විටම ලබා ගැනීමට මම කැමතියි."

ඔබට මේ ගැන වැඩිදුර කියවිය හැකිය මෙහි.

8. පොදු පොකුරක් තුළ බහු පරිශීලකයන් හෝ පරිසරයන්

Kubernetes නාම අවකාශයන් (නාම අවකාශ) ශක්තිමත් පරිවරණයක් ලබා නොදෙන්න.

පොදු වැරදි වැටහීමක් නම්, ඔබ නිෂ්පාදන නොවන භාරයක් එක් නාම අවකාශයකට සහ නිෂ්පාදන භාරයක් තවත් නාම අවකාශයකට යොදවන්නේ නම්, ඒවා කිසිම ආකාරයකින් එකිනෙකාට බලපෑම් නොකරනු ඇත... කෙසේ වෙතත්, සම්පත් ඉල්ලීම්/සීමාවන්, කෝටා සැකසීම සහ ප්‍රමුඛතා පන්ති සැකසීම භාවිතයෙන් යම් මට්ටමක හුදකලා වීමක් ලබා ගත හැක. දත්ත තලයේ සමහර "භෞතික" හුදකලා කිරීම් සපයනු ලබන්නේ අනුබද්ධතා, ඉවසීම්, අපවිත්‍රකම් (හෝ නෝඩ්සෙලෙක්ටර්) මගිනි, නමුත් එවැනි වෙන් කිරීම් තරමක් වේ. අමාරුයි ක්රියාත්මක කරන්න.

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

9. බාහිර රථවාහන ප්‍රතිපත්තිය: පොකුර

බොහෝ විට අපට පෙනෙන්නේ පොකුර තුළ ඇති සියලුම ගමනාගමනය පෙරනිමි ප්‍රතිපත්තිය සකසා ඇති NodePort වැනි සේවාවක් හරහා පැමිණෙන බවයි. externalTrafficPolicy: Cluster... එහි තේරුම එයයි NodePort පොකුරේ සෑම නෝඩයකම විවෘතව ඇති අතර, ඔබට අවශ්‍ය සේවාව (පොඩ්ස් කට්ටලය) සමඟ අන්තර් ක්‍රියා කිරීමට ඒවායින් ඕනෑම එකක් භාවිතා කළ හැක.

Kubernetes භාවිතා කරන විට 10 පොදු වැරදි

ඒ අතරම, ඉහත සඳහන් NodePort සේවාව හා සම්බන්ධ සැබෑ කරල් සාමාන්‍යයෙන් ලබා ගත හැක්කේ යම් නිශ්චිත මත පමණි. මෙම නෝඩ් වල උප කුලකය. වෙනත් වචන වලින් කිවහොත්, අවශ්‍ය පොඩ් නොමැති නෝඩයකට මා සම්බන්ධ වුවහොත්, එය වෙනත් නෝඩයකට ගමනාගමනය යොමු කරයි, hop එකතු කිරීම සහ ප්‍රමාදය වැඩි කිරීම (නෝඩ් විවිධ ලබා ගත හැකි කලාප/දත්ත මධ්‍යස්ථානවල පිහිටා තිබේ නම්, ප්‍රමාදය තරමක් ඉහළ විය හැක; ඊට අමතරව, පිටවීමේ ගමනාගමන පිරිවැය වැඩි වේ).

අනෙක් අතට, කිසියම් Kubernetes සේවාවකට ප්‍රතිපත්ති මාලාවක් තිබේ නම් externalTrafficPolicy: Local, එවිට NodePort විවෘත වන්නේ අවශ්‍ය කරල් සැබවින්ම ක්‍රියාත්මක වන එම නෝඩ් වල පමණි. රාජ්ය පරීක්ෂා කරන බාහිර පැටවුම් ශේෂයක් භාවිතා කරන විට (සෞඛ්‍ය පරීක්ෂාව) අවසාන ලක්ෂ්‍ය (එය කරන්නේ කෙසේද? AWS ELB), ඔහු අවශ්‍ය නෝඩ් වෙත පමණක් ගමනාගමනය යවනු ඇත, එය ප්‍රමාදයන්, පරිගණක අවශ්‍යතා, පිටවීමේ බිල්පත් (සහ සාමාන්‍ය බුද්ධිය එයම නියම කරයි) කෙරෙහි හිතකර බලපෑමක් ඇති කරයි.

ඔබ දැනටමත් එවැනි දෙයක් භාවිතා කිරීමට ඇති ඉඩකඩ වැඩිය traefik හෝ nginx-ingress-controller HTTP ඇතුල්වීමේ ගමනාගමනය සඳහා NodePort endpoint (හෝ LoadBalancer, NodePort භාවිතා කරන) ලෙස, සහ මෙම විකල්පය සැකසීමෙන් එවැනි ඉල්ලීම් සඳහා ප්‍රමාදය සැලකිය යුතු ලෙස අඩු කළ හැක.

В මෙම ප්රකාශනය ඔබට බාහිර ගමනාගමන ප්‍රතිපත්තිය, එහි වාසි සහ අවාසි ගැන වැඩිදුර ඉගෙන ගත හැක.

10. පොකුරු බැඳ නොගන්න සහ පාලන තලය අනිසි ලෙස භාවිතා නොකරන්න

මීට පෙර, සේවාදායකයන් නිසි නම් වලින් ඇමතීම සිරිතක් විය: ඇන්ටන්, HAL9000 සහ Colossus... අද ඒවා අහඹු ලෙස ජනනය කරන ලද හඳුනාගැනීම් මගින් ප්‍රතිස්ථාපනය කර ඇත. කෙසේ වෙතත්, පුරුද්ද පැවතුන අතර දැන් නිසි නම් පොකුරු වලට යයි.

සාමාන්‍ය කථාවක් (සැබෑ සිදුවීම් මත පදනම්ව): ඒ සියල්ල ආරම්භ වූයේ සංකල්පය සනාථ කිරීමෙනි, එබැවින් පොකුරට ආඩම්බර නමක් තිබුණි පරීක්ෂණ… වසර ගණනාවක් ගත වී ඇති අතර එය තවමත් නිෂ්පාදනයේ භාවිතා වන අතර සෑම කෙනෙකුම එය ස්පර්ශ කිරීමට බිය වේ.

පොකුරු සුරතල් සතුන් බවට පත්වීමේ විනෝදයක් නැත, එබැවින් පුහුණුවීම් කරන අතරතුර වරින් වර ඒවා ඉවත් කිරීමට අපි නිර්දේශ කරමු ආපදා ප්රතිසාධනය (මෙය උපකාර වනු ඇත අවුල් ඉංජිනේරු - ආසන්න වශයෙන්. පරිවර්තනය.). ඊට අමතරව, පාලක ස්තරය මත වැඩ කිරීමට හානියක් නොවනු ඇත (පාලන තලය). ඔහුව ස්පර්ශ කිරීමට බිය වීම හොඳ ලකුණක් නොවේ. ආදිය. මිය ගියාද? යාලුවනේ, ඔබ ඇත්තටම කරදරයක!

අනෙක් අතට, ඔබ එය හැසිරවීමෙන් ඉවතට නොයා යුතුය. කාලය සමග පාලන ස්ථරය මන්දගාමී විය හැක. බොහෝ දුරට, මෙයට හේතුව වස්තූන් විශාල ප්‍රමාණයක් ඒවායේ භ්‍රමණයකින් තොරව නිර්මාණය වීමයි (පෙරනිමි සැකසුම් සමඟ හෙල්ම් භාවිතා කරන විට පොදු තත්වයක්, වින්‍යාස සිතියම්/රහස් වල එහි තත්වය යාවත්කාලීන නොවන්නේ එබැවිනි - ප්‍රතිඵලයක් ලෙස, වස්තූන් දහස් ගණනක් එකතු වේ. පාලන ස්තරය) හෝ kube-api වස්තුවල නිරන්තර සංස්කරණය සමඟ (ස්වයංක්‍රීය පරිමාණය සඳහා, CI/CD සඳහා, අධීක්ෂණය සඳහා, සිදුවීම් ලොග, පාලක, ආදිය).

ඊට අමතරව, කළමනාකරණය කරන ලද Kubernetes සැපයුම්කරු සමඟ SLA/SLO ගිවිසුම් පරීක්ෂා කර ඇපකර කෙරෙහි අවධානය යොමු කිරීම අපි නිර්දේශ කරමු. වෙළෙන්දාට සහතික විය හැක පාලන ස්ථරය ලබා ගැනීම (හෝ එහි උප සංරචක), නමුත් ඔබ එයට එවන ඉල්ලීම්වල p99 ප්‍රමාදය නොවේ. වෙනත් වචන වලින් කිවහොත්, ඔබට ඇතුල් විය හැකිය kubectl get nodes, සහ පිළිතුරක් ලැබෙන්නේ මිනිත්තු 10 කට පසුව පමණක් වන අතර, මෙය සේවා ගිවිසුමේ නියමයන් උල්ලංඝනය කිරීමක් නොවනු ඇත.

11. බෝනස්: නවතම ටැගය භාවිතා කිරීම

නමුත් මෙය දැනටමත් සම්භාව්යයකි. කටුක අත්දැකීම් වලින් ඉගෙන ගත් බොහෝ දෙනෙක් ටැගය භාවිතා කිරීම නැවැත්වූ බැවින් මෑතකදී අපට මෙම තාක්ෂණය හමු වූයේ අඩුවෙන්. :latest සහ අනුවාද පින් කිරීම ආරම්භ කළා. හුරේ!

එස්.කේ. රූප ටැග් වල වෙනස් නොවන බව පවත්වාගෙන යයි; මෙම කැපී පෙනෙන විශේෂාංගය සමඟ ඔබ හුරුපුරුදු වන ලෙස අපි නිර්දේශ කරමු.

සාරාංශය

සෑම දෙයක්ම එක රැයකින් ක්‍රියාත්මක වනු ඇතැයි අපේක්ෂා නොකරන්න: කුබර්නෙටස් කෝකටත් තෛලයක් නොවේ. නරක යෙදුම Kubernetes හි පවා මේ ආකාරයෙන් පවතිනු ඇත (එය බොහෝ විට නරක අතට හැරෙනු ඇත). නොසැලකිලිමත්කම නිසා පාලක ස්ථරයේ අධික සංකීර්ණත්වය, මන්දගාමී හා ආතති සහගත වැඩ කිරීමට හේතු වනු ඇත. ඊට අමතරව, ඔබ ආපදා ප්‍රතිසාධන උපාය මාර්ගයක් නොමැතිව ඉතිරි වීමේ අවදානමක් ඇත. Kubernetes හුදකලා වීම සහ කොටුවෙන් පිටත ඉහළ ලබා ගැනීමේ හැකියාවක් ලබා දෙනු ඇතැයි අපේක්ෂා නොකරන්න. ඔබගේ යෙදුම සැබවින්ම වලාකුළු ස්වදේශික බවට පත් කිරීමට යම් කාලයක් ගත කරන්න.

විවිධ කණ්ඩායම්වල අසාර්ථක අත්දැකීම් පිළිබඳව ඔබට දැනගත හැකිය මෙම කතා එකතුව Henning Jacobs විසිනි.

මෙම ලිපියේ දක්වා ඇති දෝෂ ලැයිස්තුවට එකතු කිරීමට කැමති අයට Twitter හි අප හා සම්බන්ධ විය හැකිය (@MarekBartik, @MstrsObserver).

පරිවර්තකගෙන් PS

අපගේ බ්ලොග් අඩවියේ ද කියවන්න:

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

අදහස් එක් කරන්න