සටහන පරිවර්තනය: මෙය සමාගමේ ඉංජිනේරු බ්ලොග් අඩවියෙන් පොදු පශ්චාත් මරණ පරීක්ෂණයක පරිවර්තනයකි . එය Kubernetes පොකුරක් තුළ conntrack සමඟ ඇති ගැටලුවක් විස්තර කරයි, එය සමහර නිෂ්පාදන සේවාවන් අර්ධ වශයෙන් අක්‍රිය වීමට හේතු විය.
පශ්චාත් මරණ පරීක්ෂණ ගැන තව ටිකක් ඉගෙන ගැනීමට හෝ අනාගතයේදී ඇතිවිය හැකි DNS ගැටළු වළක්වා ගැනීමට කැමති අයට මෙම ලිපිය ප්‍රයෝජනවත් විය හැක.
මෙය DNS නොවේ
එය DNS විය නොහැක
එය DNS විය
Preply හි පශ්චාත් මරණ පරීක්ෂණ සහ ක්‍රියාවලි ගැන ටිකක්
පශ්චාත් මරණ පරීක්ෂණයක් නිෂ්පාදනයේ යම් දෝෂයක් හෝ යම් සිදුවීමක් විස්තර කරයි. පශ්චාත් මරණ පරීක්ෂණයට සිදුවීම්, පරිශීලක බලපෑම, මූල හේතුව, ගෙන ඇති ක්‍රියාමාර්ග සහ උගත් පාඩම් කාලසටහනක් ඇතුළත් වේ.
පීසා සමඟ සතිපතා රැස්වීම්වලදී, තාක්ෂණික කණ්ඩායම අතර, අපි විවිධ තොරතුරු බෙදා ගන්නෙමු. එවැනි රැස්වීම්වල වැදගත්ම කොටස්වලින් එකක් වන්නේ පශ්චාත් මරණ පරීක්ෂණ වන අතර, ඒවා බොහෝ විට විනිවිදක සහිත ඉදිරිපත් කිරීමක් සහ සිද්ධිය පිළිබඳ වඩාත් ගැඹුරු විශ්ලේෂණයක් සමඟ සිදු කෙරේ. පශ්චාත් මරණ පරීක්‍ෂණයෙන් පසු අත්පුඩි නොතැබූවද, අපි "දොස් නොකියන" සංස්කෘතියක් වර්ධනය කිරීමට උත්සාහ කරමු.) පශ්චාත් මරණ පරීක්ෂණ ලිවීම සහ ඉදිරිපත් කිරීම අපට (සහ වෙනත් අයට) අනාගතයේදී එවැනි සිදුවීම් වළක්වා ගැනීමට උපකාරී වනු ඇතැයි අපි විශ්වාස කරමු, ඒ නිසා අපි ඒවා බෙදා ගන්නෙමු.
සිද්ධියකට සම්බන්ධ පුද්ගලයන්ට හැඟිය යුත්තේ දඬුවම් හෝ පළිගැනීම්වලට බිය නොවී විස්තරාත්මකව කතා කළ හැකි බවයි. දොස් නැත! පශ්චාත් මරණ පරීක්ෂණයක් ලිවීම දඬුවමක් නොව සමස්ත සමාගමටම ඉගෙනීමේ අවස්ථාවක්.
Kubernetes හි DNS සමඟ ගැටළු. පශ්චාත් මරණ පරීක්ෂණය
දිනය: 28.02.2020
කතුවරුන්: Amet U., Andrey S., Igor K., Alexey P.
තත්ත්වය: අවසන්
කෙටියෙන්: Kubernetes පොකුරේ සමහර සේවා සඳහා අර්ධ DNS නොමැති වීම (මිනිත්තු 26).
බලපෑම: A, B සහ C සේවා සඳහා ඉසව් 15000ක් අහිමි විය
මුල හේතුව: Kube-proxy හට conntrack වගුවෙන් පැරණි ප්‍රවේශයක් නිවැරදිව ඉවත් කිරීමට නොහැකි විය, එම නිසා සමහර සේවාවන් තවමත් නොපවතින Pods වෙත සම්බන්ධ වීමට උත්සාහ කරයි.
E0228 20:13:53.795782 1 proxier.go:610] Failed to delete kube-system/kube-dns:dns endpoint connections, error: error deleting conntrack entries for UDP peer {100.64.0.10, 100.110.33.231}, error: conntrack command returned: ...ප්‍රේරකය: Kubernetes පොකුර තුළ ඇති අඩු බර නිසා, CoreDNS-autoscaler යෙදවීමෙහි ඇති කරල් ගණන තුනේ සිට දෙක දක්වා අඩු කළේය.
විසඳුම: යෙදුමේ මීළඟ යෙදවීම නව නෝඩ් නිර්මාණය කිරීම ආරම්භ කරන ලදී, CoreDNS-autoscaler පොකුරට සේවය කිරීම සඳහා තවත් කරල් එකතු කරන ලද අතර එය සම්බන්ධක වගුව නැවත ලිවීමට හේතු විය.
හඳුනාගැනීම: A, B සහ C සේවා සඳහා 5xx දෝෂ විශාල ප්‍රමාණයක් ප්‍රොමිතියස් නිරීක්‍ෂණය විසින් අනාවරණය කරගෙන රාජකාරියේ යෙදී සිටින ඉංජිනේරුවන් වෙත ඇමතුමක් ලබා දෙන ලදී.
කිබානා හි 5xx දෝෂ
ක්රියා
ක්රියාත්මක
වර්ගය
වගකිව
අරමුණු
CoreDNS සඳහා autoscaler අක්‍රීය කරන්න
වැළකුණා
ඇමේට් යූ.
DEVOPS-695
හැඹිලි DNS සේවාදායකයක් සකසන්න
අඩු වීම
මැක්ස් වී.
DEVOPS-665
සම්බන්ධතා නිරීක්ෂණ සකසන්න
වැළකුණා
ඇමේට් යූ.
DEVOPS-674
උගත් පාඩම්
හොඳින් සිදු වූ දේ:
- අධීක්ෂණය හොඳින් ක්රියාත්මක විය. ප්‍රතිචාරය වේගවත් හා සංවිධානාත්මක විය
- අපි නෝඩ් වල කිසිදු සීමාවකට පහර දුන්නේ නැත
වැරැද්ද කුමක්ද:
- තවමත් නොදන්නා සැබෑ මූල හේතුව, සමානයි conntrack තුළ
- සියලුම ක්රියා නිවැරදි කරන්නේ ප්‍රතිවිපාක පමණක් මිස මූල හේතුව නොවේ (දෝෂය)
- ඉක්මනින් හෝ පසුව අපට DNS සමඟ ගැටලු ඇති විය හැකි බව අපි දැන සිටියෙමු, නමුත් අපි කාර්යයන් සඳහා ප්‍රමුඛත්වය දුන්නේ නැත
අපි වාසනාවන්ත වූ තැන:
- මීළඟ යෙදවීම CoreDNS-autoscaler මගින් ක්‍රියාරම්භ කරන ලදී, එය conntrack වගුව උඩින් ලිවීය.
- මෙම දෝෂය බලපෑවේ සමහර සේවාවන්ට පමණි
කාලරේඛාව (EET)
කාලය
ක්රියාත්මක
22:13
CoreDNS-autoscaler කරල් ගණන තුනේ සිට දෙක දක්වා අඩු කළේය
22:18
රාජකාරියේ යෙදී සිටි ඉංජිනේරුවන්ට අධීක්ෂණ පද්ධතියෙන් ඇමතුම් ලැබීමට පටන් ගත්තේය
22:21
රාජකාරියේ යෙදී සිටි ඉංජිනේරුවන් දෝෂවලට හේතුව සොයා ගැනීමට පටන් ගත්හ.
22:39
රාජකාරියේ යෙදී සිටින ඉංජිනේරුවන් නවතම සේවාවක් පෙර අනුවාදයට පෙරළීමට පටන් ගත්හ
22:40
5xx දෝෂ දර්ශනය වීම නතර විය, තත්වය ස්ථාවර වී ඇත
- හඳුනා ගැනීමට කාලය: 4 මිනි
- ක්රියා කිරීමට පෙර කාලය: 21 මිනි
- නිවැරදි කිරීමට කාලය: 1 මිනි
අමතර තොරතුරු
- CoreDNS ලඝු:
I0228 20:13:53.507780 1 event.go:221] Event(v1.ObjectReference{Kind:"Deployment", Namespace:"kube-system", Name:"coredns", UID:"2493eb55-3dc0-11ea-b3a2-02bb48f8c230", APIVersion:"apps/v1", ResourceVersion:"132690686", FieldPath:""}): type: 'Normal' reason: 'ScalingReplicaSet' Scaled down replica set coredns-6cbb6646c9 to 2 - Kibana (කපා), Grafana (කපා) වෙත සබැඳි
CPU භාවිතය අවම කිරීම සඳහා, Linux කර්නලය conntrack ලෙස හඳුන්වන දෙයක් භාවිතා කරයි. කෙටියෙන් කිවහොත්, මෙය විශේෂ වගුවක ගබඩා කර ඇති NAT වාර්තා ලැයිස්තුවක් අඩංගු උපයෝගීතාවයකි. ඊලග පැකට්ටුව එකම පොඩ් එකේ ඉදන් කලින් පොඩ් එකටම ආවම අන්තිම IP address එක recalculate කරන්නේ නෑ, contrack table එකෙන් ගන්නවා.
Contrack ක්රියා කරන ආකාරය
ප්රතිඵල
මෙය ප්‍රයෝජනවත් සබැඳි කිහිපයක් සහිත අපගේ පශ්චාත් මරණ පරීක්ෂණයක උදාහරණයක් විය. විශේෂයෙන්ම මෙම ලිපියෙන් අපි වෙනත් සමාගම්වලට ප්‍රයෝජනවත් විය හැකි තොරතුරු බෙදා ගනිමු. ඒකයි අපි වැරදි කරන්න බය නෑ අපේ එක පශ්චාත් මරණ පරීක්ෂණයක් ප්‍රසිද්ධ කරන්නේ. මෙන්න තවත් රසවත් මහජන පශ්චාත් මරණ පරීක්ෂණ කිහිපයක්:
- GitLab:
- ඩ්‍රොප්බොක්ස්:
- Spotify:
- තවත් බොහෝ අයගෙන් සහ ගබඩාව
- එසේම SRE පොත සමඟ පොදු පශ්චාත් මරණ පරීක්ෂණය
මූලාශ්රය: www.habr.com