මගේ නම Viktor Yagofarov වන අතර, මම Ops (මෙහෙයුම්) කණ්ඩායමේ තාක්ෂණික සංවර්ධන කළමනාකරුවෙකු ලෙස DomClick හි Kubernetes වේදිකාව සංවර්ධනය කරමින් සිටිමි. අපගේ Dev <-> Ops ක්රියාවලි වල ව්‍යුහය, රුසියාවේ විශාලතම k8s පොකුරු වලින් එකක් ක්රියාත්මක කිරීමේ විශේෂාංග මෙන්ම අපගේ කණ්ඩායම අදාළ වන DevOps/SRE පරිචයන් ගැන කතා කිරීමට මම කැමතියි.
Ops කණ්ඩායම
Ops කණ්ඩායමට දැනට 15 දෙනෙක් ඉන්නවා. ඔවුන්ගෙන් තිදෙනෙකු කාර්යාලයේ වගකීම දරයි, දෙදෙනෙකු වෙනත් කාල කලාපයක වැඩ කරන අතර රාත්‍රිය ඇතුළුව ලබා ගත හැකිය. මේ අනුව, Ops හි කෙනෙකු සැමවිටම මොනිටරයේ සිටින අතර ඕනෑම සංකීර්ණ සිදුවීමකට ප්‍රතිචාර දැක්වීමට සූදානම්ය. අපට රාත්‍රී මුර නොමැති අතර එමඟින් අපගේ මනෝභාවය ආරක්ෂා වන අතර සෑම කෙනෙකුටම ප්‍රමාණවත් නින්දක් ලබා ගැනීමට සහ පරිගණකයේ පමණක් නොව විවේක කාලය ගත කිරීමට අවස්ථාව ලබා දේ.
සෑම කෙනෙකුටම විවිධ නිපුණතා ඇත: ජාලකරුවන්, DBAs, ELK ස්ටැක් විශේෂඥයින්, Kubernetes පරිපාලකයින්/සංවර්ධකයින්, අධීක්ෂණය, අථත්‍යකරණය, දෘඪාංග විශේෂඥයින්, ආදිය. එක් දෙයක් සියලු දෙනා එක්සත් කරයි - සෑම කෙනෙකුටම අපගෙන් ඕනෑම කෙනෙකුට යම් ප්‍රමාණයකට ප්රතිස්ථාපනය කළ හැකිය: උදාහරණයක් ලෙස, k8s පොකුරට නව නෝඩ් හඳුන්වා දීම, PostgreSQL යාවත්කාලීන කිරීම, CI/CD + Ansible නල මාර්ගයක් ලිවීම, Python/Bash/Go හි යමක් ස්වයංක්‍රීය කිරීම, දෘඪාංග සම්බන්ධ කිරීම දත්ත මධ්යස්ථානය. ඕනෑම ප්‍රදේශයක ශක්තිමත් නිපුණතා ඔබේ ක්‍රියාකාරකම් දිශාව වෙනස් කිරීමෙන් සහ වෙනත් ක්ෂේත්‍රයක වැඩිදියුණු වීමට පටන් ගැනීමෙන් ඔබව වළක්වන්නේ නැත. උදාහරණයක් ලෙස, මම PostgreSQL විශේෂඥයෙකු ලෙස සමාගමකට සම්බන්ධ වූ අතර දැන් මගේ ප්රධාන වගකීම් අංශය වන්නේ Kubernetes පොකුරු වේ. කණ්ඩායම තුළ, ඕනෑම උසක් සාදරයෙන් පිළිගනු ලබන අතර උත්තෝලනය පිළිබඳ හැඟීම ඉතා දියුණු වේ.
මාර්ගය වන විට, අපි දඩයම් කරනවා. අපේක්ෂකයින් සඳහා වන අවශ්යතා තරමක් සම්මත වේ. මට පුද්ගලිකව, පුද්ගලයෙකු කණ්ඩායමට ගැළපෙන, ගැටුම් නොවන, නමුත් ඔහුගේ දෘෂ්ටිකෝණය ආරක්ෂා කර ගන්නේ කෙසේදැයි දැන සිටීම, සංවර්ධනය කිරීමට අවශ්ය වන අතර අලුත් දෙයක් කිරීමට බිය නොවී, ඔහුගේ අදහස් ඉදිරිපත් කිරීම වැදගත් වේ. එසේම, ස්ක්‍රිප්ටින් භාෂා පිළිබඳ ක්‍රමලේඛන කුසලතා, ලිනක්ස් සහ ඉංග්‍රීසි මූලික කරුණු පිළිබඳ දැනුම අවශ්ය වේ. ඉංග්‍රීසි සරලව අවශ්ය වන අතර එමඟින් fakap අවස්ථාවකදී පුද්ගලයෙකුට මිනිත්තු 10 කින් නොව තත්පර 10 කින් ගැටලුවට විසඳුමක් ගූගල් කළ හැකිය. ලිනක්ස් පිළිබඳ ගැඹුරු දැනුමක් ඇති විශේෂ ists යින් සොයා ගැනීම දැන් ඉතා අපහසුය: එය විහිළුවක්, නමුත් අපේක්ෂකයින් තිදෙනෙකුගෙන් දෙදෙනෙකුට “පූරණය සාමාන්‍යය යනු කුමක්ද? එය සෑදී ඇත්තේ කුමක් ද?", සහ "C වැඩසටහනකින් මූලික ඩම්ප් එකලස් කරන්නේ කෙසේද" යන ප්‍රශ්නය සුපිරි මිනිසුන්ගේ ... හෝ ඩයිනෝසෝරයන්ගේ ලෝකයෙන් යමක් ලෙස සැලකේ. සාමාන්යයෙන් මිනිසුන් වෙනත් නිපුණතා ඉතා දියුණු කර ඇති බැවින් අපි මෙය ඉවසා සිටිය යුතුය, නමුත් අපි ලිනක්ස් උගන්වමු. "නවීන වලාකුළු ලෝකයේ DevOps ඉංජිනේරුවෙකුට මේ සියල්ල දැනගත යුත්තේ ඇයි" යන ප්‍රශ්නයට පිළිතුර ලිපියේ විෂය පථයෙන් පිටත තැබිය යුතුය, නමුත් වචන තුනකින්: මේ සියල්ල අවශ්ය වේ.
කණ්ඩායම් මෙවලම්
මෙවලම් කණ්ඩායම ස්වයංක්‍රීයකරණයේ වැදගත් කාර්යභාරයක් ඉටු කරයි. ඔවුන්ගේ ප්රධාන කාර්යය වන්නේ සංවර්ධකයින් සඳහා පහසු චිත්රක සහ CLI මෙවලම් නිර්මාණය කිරීමයි. උදාහරණයක් ලෙස, අපගේ අභ්‍යන්තර සංවර්ධන සම්මන්ත්‍රණය ඔබට මූසික ක්ලික් කිරීම් කිහිපයකින් යෙදුමක් වචනාර්ථයෙන් Kubernetes වෙත ගෙනයාමට, එහි සම්පත් වින්‍යාස කිරීමට, සුරක්ෂිතාගාරයෙන් යතුරු ආදිය සැකසීමට ඉඩ සලසයි. මීට පෙර, Jenkins + Helm 2 තිබුනා, නමුත් Copy-paste ඉවත් කිරීමට සහ මෘදුකාංග ජීවන චක්‍රයට ඒකාකාරිත්වය ගෙන ඒමට මට මගේම මෙවලමක් සංවර්ධනය කිරීමට සිදු විය.
Ops කණ්ඩායම සංවර්ධකයින් සඳහා නල මාර්ග ලියන්නේ නැත, නමුත් ඔවුන්ගේ ලිවීමේ ඕනෑම ගැටළුවක් සඳහා උපදෙස් දිය හැකිය (සමහර පුද්ගලයින්ට තවමත් Helm 3 ඇත).
දේ
DevOps සම්බන්ධයෙන් ගත් කල, අපට එය මේ ආකාරයෙන් පෙනේ:
Dev කණ්ඩායම් කේතය ලියන අතර, එය Confer to dev -> qa/stage -> prod වෙත පෙරළන්න. කේතය මන්දගාමී නොවන බව සහ දෝෂ අඩංගු නොවන බව සහතික කිරීමේ වගකීම Dev සහ Ops කණ්ඩායම් වෙත පැවරේ. දිවා කාලයේදී, Ops කණ්ඩායමේ රාජකාරියේ යෙදී සිටින පුද්ගලයා ඔහුගේ අයදුම්පත සමඟ සිදුවීමකට ප්‍රථමයෙන් ප්‍රතිචාර දැක්විය යුතු අතර, සවස් වරුවේ සහ රාත්‍රියේ, රාජකාරියේ යෙදී සිටින පරිපාලක (Ops) ඔහු දන්නේ නම් රාජකාරියේ යෙදී සිටින සංවර්ධකයා අවදි කළ යුතුය. ගැටලුව යටිතල පහසුකම්වල නොවන බව සහතිකයි. නිරීක්‍ෂණයේ ඇති සියලුම ප්‍රමිතික සහ ඇඟවීම් ස්වයංක්‍රීයව හෝ අර්ධ ස්වයංක්‍රීයව දිස්වේ.
Ops හි වගකීම් ප්‍රදේශය ආරම්භ වන්නේ යෙදුම නිෂ්පාදනයට පෙරළන මොහොතේ සිටය, නමුත් දේව්ගේ වගකීම එතැනින් අවසන් නොවේ - අපි එකම දේ කර එකම බෝට්ටුවේ සිටිමු.
පරිපාලක ක්ෂුද්ර සේවාවක් ලිවීමට උදව් අවශ්ය නම් සංවර්ධකයින් පරිපාලකයින්ට උපදෙස් දෙයි (උදාහරණයක් ලෙස, Go backend + HTML5), සහ පරිපාලකයින් සංවර්ධකයින්ට ඕනෑම යටිතල පහසුකම් ගැටළු හෝ k8s සම්බන්ධ ගැටළු පිළිබඳව උපදෙස් දෙයි.
මාර්ගය වන විට, අපට කිසිසේත් මොනොලිත් නැත, ක්ෂුද්ර සේවා පමණි. ඔවුන්ගේ සංඛ්‍යාව සංඛ්‍යාවෙන් මනින්නේ නම්, prod k900s පොකුරේ 1000 සහ 8 අතර උච්චාවචනය වේ. යෙදවීම. කරල් සංඛ්‍යාව 1700ත් 2000ත් අතර උච්චාවචනය වේ. දැනට කරල් 2000ක් පමණ ප්‍රොඩ් පොකුරේ ඇත.
අපි අනවශ්ය ක්ෂුද්ර සේවා නිරීක්ෂණය කර ඒවා අර්ධ ස්වයංක්‍රීයව කපා දමන බැවින් මට නිශ්චිත සංඛ්‍යා ලබා දිය නොහැක. K8s අපට අනවශ්ය ආයතන නිරීක්ෂණය කිරීමට උදවු කරයි , බොහෝ සම්පත් සහ මුදල් ඉතිරි කරයි.
සම්පත් කළමනාකරණය
අධීක්ෂණය
මනාව ව්‍යුහගත සහ තොරතුරු සහිත අධීක්ෂණය විශාල පොකුරක ක්‍රියාකාරිත්වයේ මූලික ගල බවට පත්වේ. සියලුම අධීක්ෂණ අවශ්යතා වලින් 100% ක් ආවරණය වන විශ්වීය විසඳුමක් අප තවමත් සොයාගෙන නැත, එබැවින් අපි මෙම පරිසරය තුළ වරින් වර විවිධ අභිරුචි විසඳුම් නිර්මාණය කරමු.
- සර්බික්ස්. යටිතල ව්‍යුහයේ සමස්ත තත්ත්වය නිරීක්ෂණය කිරීමට මූලික වශයෙන් අදහස් කරන පැරණි හොඳ නිරීක්ෂණ. සැකසීම, මතකය, තැටි, ජාලය සහ යනාදිය අනුව නෝඩයක් මිය යන විට එය අපට කියයි. අද්භූත කිසිවක් නැත, නමුත් අපට වෙනම DaemonSet නියෝජිතයන් ද ඇත, ඒවායේ ආධාරයෙන්, උදාහරණයක් ලෙස, අපි පොකුරේ DNS තත්ත්වය නිරීක්ෂණය කරමු: අපි මෝඩ coredns කරල් සොයමු, බාහිර ධාරක තිබේදැයි අපි පරීක්ෂා කරමු. මේ ගැන කරදර වන්නේ මන්දැයි පෙනේ, නමුත් විශාල වාහන තදබදයක් සමඟ මෙම සංරචකය අසාර්ථක වීමේ බරපතල ලක්ෂ්‍යයකි. මම දැනටමත් , මම පොකුරක් තුළ DNS කාර්ය සාධනය සමඟ අරගල කළ ආකාරය.
- Prometheus ක්රියාකරු. විවිධ අපනයනකරුවන් සමූහයක් පොකුරේ සියලුම සංරචක පිළිබඳ විශාල දළ විශ්ලේෂණයක් ලබා දෙයි. මීළඟට, අපි මේ සියල්ල Grafana හි විශාල උපකරණ පුවරු මත දෘශ්‍යමාන කර, ඇඟවීම් සඳහා ඇඟවීම් කළමනාකරු භාවිතා කරමු.
අපට තවත් ප්රයෝජනවත් මෙවලමක් විය . අපි එය ලිව්වේ එක් කණ්ඩායමක් තවත් කණ්ඩායමක ඇතුල් වීමේ මාර්ග අතිච්ඡාදනය වන අතර 50x දෝෂ ඇති වන තත්වයක් අපට කිහිප වතාවක්ම හමු වූ පසුවය. දැන් නිෂ්පාදනයට යෙදවීමට පෙර, සංවර්ධකයින් කිසිවෙකුට බලපාන්නේ නැති බව පරීක්ෂා කරන අතර, මගේ කණ්ඩායම සඳහා මෙය Ingresses සමඟ ඇති ගැටළු පිළිබඳ මූලික රෝග විනිශ්චය සඳහා හොඳ මෙවලමකි. මුලදී එය පරිපාලකයින් සඳහා ලියා ඇති අතර එය තරමක් “අවුල් සහගත” බවක් පෙනෙන්නට තිබීම හාස්‍යජනක ය, නමුත් dev කණ්ඩායම් මෙවලමට ආදරය කළ පසු, එය බොහෝ වෙනස් වී “පරිපාලකයෙකු පරිපාලකයින් සඳහා වෙබ් මුහුණුවරක් සාදා ඇති බවක් පෙනෙන්නට පටන් ගත්තේය. ” ඉක්මනින් අපි මෙම මෙවලම අතහැර දමනු ඇති අතර නල මාර්ගය පෙරළීමට පෙර පවා එවැනි තත්ත්වයන් වලංගු වේ.
කියුබ් තුළ කණ්ඩායම් සම්පත්
අපි උදාහරණ වෙත යාමට පෙර, අපි සම්පත් වෙන් කරන්නේ කෙසේද යන්න පැහැදිලි කිරීම වටී ක්ෂුද්ර සේවා.
කුමන කණ්ඩායම් සහ ඒවා භාවිතා කරන්නේ කුමන ප්‍රමාණවලින්ද යන්න තේරුම් ගැනීමට සම්පත් (ප්රොසෙසරය, මතකය, දේශීය SSD), අපි සෑම විධානයක්ම එයටම වෙන් කරමු නාම අවකාශය "කියුබ්" හි සහ ප්රොසෙසරය, මතකය සහ තැටිය අනුව එහි උපරිම හැකියාවන් සීමා කිරීම, කණ්ඩායම්වල අවශ්යතා කලින් සාකච්ඡා කර ඇත. ඒ අනුව, එක් විධානයක්, සාමාන්යයෙන්, යෙදවීම සඳහා සම්පූර්ණ පොකුර අවහිර නොකරනු ඇත, මතකය දහස් ගණනක් සහ ටෙරාබයිට් වෙන් කරයි. නාම අවකාශයට ප්‍රවේශය AD හරහා ලබා දෙනු ලැබේ (අපි RBAC භාවිතා කරමු). නාම අවකාශයන් සහ ඒවායේ සීමාවන් GIT ගබඩාවට ඇදීමේ ඉල්ලීමක් හරහා එකතු කරනු ලැබේ, පසුව සියල්ල ස්වයංක්‍රීයව Ansible නල මාර්ගය හරහා පෙරළේ.
කණ්ඩායමකට සම්පත් බෙදා හැරීමේ උදාහරණයක්:
namespaces:
chat-team:
pods: 23
limits:
cpu: 11
memory: 20Gi
requests:
cpu: 11
memory: 20Gi
ඉල්ලීම් සහ සීමාවන්
ඝනක" ඉල්ලීම සඳහා සහතික කළ රක්ෂිත සම්පත් ගණන වේ පොඩ් (ඩොකර් බහාලුම් එකක් හෝ කිහිපයක්) පොකුරක් තුළ. සීමාව යනු සහතික නොකළ උපරිමයකි. සමහර කණ්ඩායමක් එහි සියලුම යෙදුම් සඳහා ඕනෑවට වඩා ඉල්ලීම් සකසා ඇති ආකාරය සහ “කියුබ්” වෙත යෙදුම යෙදවිය නොහැකි ආකාරය ඔබට බොහෝ විට ප්‍රස්ථාරවල දැකිය හැකිය, මන්ද ඔවුන්ගේ නාම අවකාශය යටතේ ඇති සියලුම ඉල්ලීම් දැනටමත් “වියදම් කර” ඇත.
මෙම තත්වයෙන් මිදීමේ නිවැරදි මාර්ගය වන්නේ සත්‍ය සම්පත් පරිභෝජනය දෙස බලා එය ඉල්ලූ මුදල (ඉල්ලීම) සමඟ සංසන්දනය කිරීමයි.
ඉහත තිරපිටපත්වල ඔබට “ඉල්ලන ලද” CPU තථ්‍ය නූල් සංඛ්‍යාවට ගැළපෙන බව දැක ගත හැකි අතර සීමාවන් සැබෑ CPU නූල් සංඛ්‍යාව ඉක්මවිය හැක =)
දැන් අපි යම් නාම අවකාශයක් සවිස්තරාත්මකව බලමු (මම නම් අවකාශය kube-system - “Cube” හි සංරචක සඳහා පද්ධති නාම අවකාශය තෝරා ගත්තෙමි) සහ ඇත්ත වශයෙන්ම භාවිතා කරන ලද ප්‍රොසෙසරයේ කාලය සහ මතකය ඉල්ලුමට ඇති අනුපාතය බලන්න:
ඇත්ත වශයෙන්ම භාවිතා කරන ප්‍රමාණයට වඩා වැඩි මතකයක් සහ CPU පද්ධති සේවා සඳහා වෙන් කර ඇති බව පැහැදිලිය. kube-පද්ධතිය සම්බන්ධයෙන් ගත් කල, මෙය යුක්ති සහගත ය: එය සිදු වූයේ nginx ingress controller හෝ nodelocaldns ඔවුන්ගේ උච්චතම අවස්ථාවෙහිදී CPU වෙත පහර දී RAM විශාල ප්‍රමාණයක් පරිභෝජනය කිරීම, එබැවින් මෙහි එවැනි සංචිතයක් යුක්ති සහගත ය. ඊට අමතරව, අපට පසුගිය පැය 3 සඳහා ප්‍රස්ථාර මත විශ්වාසය තැබිය නොහැක: විශාල කාල පරිච්ඡේදයක් පුරා ඓතිහාසික මිනුම් දණ්ඩ බැලීම සුදුසුය.
"නිර්දේශ" පද්ධතියක් සංවර්ධනය කරන ලදී. උදාහරණයක් ලෙස, "සිමා කිරීම්" (ඉහළ අවසර ලත් තීරුව) ඉහළ නැංවීමෙන් වඩා හොඳ සම්පත් මොනවාදැයි මෙහිදී ඔබට දැක ගත හැක, එවිට "ත්‍රොට්ල් කිරීම" සිදු නොවේ: සම්පතක් දැනටමත් CPU හෝ මතකය වෙන් කර ඇති කාල පෙත්තෙහි වැය කර ඇති මොහොත සහ එය "නොකැඩී" වන තෙක් බලා සිටී:
ඔවුන්ගේ ආහාර රුචිය මැඩපැවැත්විය යුතු කරල් මෙන්න:
මත තෙරපුම + සම්පත් අධීක්ෂණය, ඔබට ලිපි එකකට වඩා ලිවිය හැකිය, එබැවින් අදහස් දැක්වීමේදී ප්‍රශ්න අසන්න. වචන කිහිපයකින්, මට කිව හැක්කේ එවැනි ප්‍රමිතික ස්වයංක්‍රීය කිරීමේ කාර්යය ඉතා අපහසු වන අතර “කවුළු” ශ්‍රිත සහ “CTE” Prometheus / VictoriaMetrics සමඟ බොහෝ කාලයක් සහ සමතුලිත ක්‍රියාවක් අවශ්ය වන බවයි (මෙම නියමයන් උද්ධෘත වල ඇත, මන්ද බොහෝ දුරට ඇත. PromQL හි මෙවන් කිසිවක් නැත, ඔබට බියජනක විමසුම් පෙළ තිර කිහිපයකට බෙදා ඒවා ප්‍රශස්ත කළ යුතුය).
එහි ප්‍රතිඵලයක් වශයෙන්, සංවර්ධකයින්ට Cube තුළ ඔවුන්ගේ නාම අවකාශයන් නිරීක්ෂණය කිරීම සඳහා මෙවලම් ඇති අතර, ඔවුන්ගේ සම්පත් “කපා” දැමිය හැක්කේ කොතැනද සහ කුමන වේලාවකද සහ මුළු රාත්‍රිය පුරාවටම සම්පූර්ණ CPU ලබා දිය හැක්කේ කුමන සේවාදායකයන්ටද යන්න තමන්ටම තෝරා ගැනීමට ඔවුන්ට හැකි වේ.
ක්‍රමවේද
දැන් තියෙන විදියට කම්පැනි එකේ විලාසිතාමය, අපි DevOps- සහ එස්.ආර්.ඊ.- පුහුණුකරු සමාගමකට ක්ෂුද්ර සේවා 1000 ක්, සංවර්ධකයින් 350 ක් සහ සමස්ත යටිතල පහසුකම් සඳහා පරිපාලකයින් 15 ක් පමණ සිටින විට, ඔබ “විලාසිතාගත” විය යුතුය: මෙම සියලු “බාස්වර්ඩ්” පිටුපස සියල්ල සහ සියල්ලන්ම ස්වයංක්‍රීය කිරීමේ හදිසි අවශ්‍යතාවයක් ඇති අතර පරිපාලකයින් බාධාවක් නොවිය යුතුය. ක්රියාවලි තුළ.
Ops ලෙස, අපි සේවා ප්‍රතිචාර අනුපාත සහ දෝෂ සම්බන්ධ සංවර්ධකයින් සඳහා විවිධ ප්‍රමිතික සහ උපකරණ පුවරු සපයන්නෙමු.
අපි එවැනි ක්‍රමවේද භාවිතා කරමු: , и ඒවා එකට එකතු කිරීමෙන්. අපි උපකරණ පුවරු සංඛ්‍යාව අවම කිරීමට උත්සාහ කරන්නෙමු, එවිට බැලූ බැල්මට දැනට පිරිහෙන්නේ කුමන සේවාවද යන්න පැහැදිලි වේ (උදාහරණයක් ලෙස, තත්පරයට ප්‍රතිචාර කේත, ප්‍රතිචාර කාලය 99 වැනි ප්‍රතිශතයකින්) සහ යනාදිය. සාමාන්‍ය උපකරණ පුවරු සඳහා නව ප්‍රමිතික කිහිපයක් අවශ්ය වූ වහාම, අපි වහාම ඒවා ඇද එකතු කරමු.
මම මාසයකින් ප්‍රස්ථාර ඇඳලා නැහැ. මෙය බොහෝ විට හොඳ සලකුණක් විය හැකිය: එයින් අදහස් වන්නේ බොහෝ "අවශ්යතා" දැනටමත් සාක්ෂාත් කර ගෙන ඇති බවයි. සතිය තුළ මම අවම වශයෙන් දිනකට එක් වරක්වත් නව ප්‍රස්ථාරයක් අඳින්නෙමි.
ප්‍රතිඵලය වටිනා වන්නේ දැන් සංවර්ධකයින් “යම් මෙට්‍රික් වර්ගයක් දෙස බැලිය යුත්තේ කොතැනින්ද” යන ප්‍රශ්න සමඟ පරිපාලකයින් වෙත යන්නේ කලාතුරකිනි.
ක්රියාත්මක කිරීම සේවා දැල් ආසන්නයේ ඇති අතර සෑම කෙනෙකුටම ජීවිතය වඩාත් පහසු කළ යුතුය, මෙවලම්වල සගයන් දැනටමත් වියුක්ත “නිරෝගී පුද්ගලයෙකුගේ ඉස්ටියෝ” ක්‍රියාවට නැංවීමට සමීප වී ඇත: එක් එක් HTTP(ය) ඉල්ලීම්වල ජීවන චක්‍රය නිරීක්ෂණයේදී දෘශ්‍යමාන වනු ඇත, සහ එය අන්තර් සේවා (සහ පමණක් නොව) අන්තර්ක්‍රියා අතරතුර “සියල්ල කැඩී ගියේ කුමන අවධියේදීද” යන්න සැමවිටම තේරුම් ගැනීමට හැකි වනු ඇත. DomClick hub වෙතින් පුවත් සඳහා දායක වන්න. =)
Kubernetes යටිතල පහසුකම් සහාය
ඓතිහාසික වශයෙන්, අපි පැච් කරන ලද අනුවාදය භාවිතා කරමු කුබෙස්ප්රේ - Kubernetes යෙදවීම, දීර්ඝ කිරීම සහ යාවත්කාලීන කිරීම සඳහා ප්රධාන භූමිකාව. යම් අවස්ථාවක දී, kubeadm නොවන ස්ථාපනයන් සඳහා සහය ප්රධාන ශාඛාවෙන් කපා හැර ඇති අතර, kubeadm වෙත මාරු කිරීමේ ක්රියාවලිය යෝජනා නොකළේය. එහි ප්‍රතිඵලයක් වශයෙන්, සවුත්බ්‍රිජ් සමාගම තමන්ගේම දෙබලක් (kubeadm සහය ඇතිව සහ තීරණාත්මක ගැටළු සඳහා ඉක්මන් විසඳුමක් සමඟ) සාදන ලදී.
සියලුම k8s පොකුරු යාවත්කාලීන කිරීමේ ක්රියාවලිය මේ ආකාරයට පෙනේ:
- ගන්න කුබෙස්ප්රේ සවුත්බ්‍රිජ් වෙතින්, අපගේ ත්‍රෙඩ් සමඟ පරීක්ෂා කරන්න, මර්ජිම්.
- වෙත යාවත්කාලීන කිරීම අපි සිදු කරන්නෙමු මානසික ආතතිය- "කියුබ්".
- අපි වරකට එක් නෝඩයක් යාවත්කාලීන කරන්නෙමු (ඇන්සිබල්හි මෙය “අනුක්‍රමික: 1”) ඩීව්- "කියුබ්".
- අපි යාවත්කාලීන කරන්නෙමු Prod සෙනසුරාදා සවස එක් වරකට එක් නෝඩ් එකක්.
අනාගතයේදී එය ප්රතිස්ථාපනය කිරීමට සැලසුම් කර ඇත කුබෙස්ප්රේ යමක් සඳහා වේගවත් හා යන්න kubeadm.
සමස්තයක් වශයෙන් අපට "කියුබ්" තුනක් ඇත: ආතතිය, දේව් සහ ප්‍රොඩ්. අපි තවත් එකක් දියත් කිරීමට සැලසුම් කරමින් සිටිමු (උණුසුම් පොරොත්තුවෙන්) Prod-"Cube" දෙවන දත්ත මධ්‍යස්ථානයේ. මානසික ආතතිය и ඩීව් "අථත්‍ය යන්ත්‍ර" තුළ ජීවත් වේ (ආතතිය සඳහා oVirt සහ Dev සඳහා VMWare Cloud). Prod- “කියුබ්” ජීවත් වන්නේ “හිස් ලෝහ” මත ය: මේවා CPU නූල් 32 ක්, 64-128 GB මතකයක් සහ 300 GB SSD RAID 10 සහිත සමාන නෝඩ් වේ - ඒවායින් 50 ක් ඇත. "තුනී" නෝඩ් තුනක් "මාස්ටර්" සඳහා කැප කර ඇත Prod- "කියුබාව": 16 GB මතකය, 12 CPU නූල්.
විකුණුම් සඳහා, අපි "හිස් ලෝහ" භාවිතා කිරීමට කැමති සහ අනවශ්ය ස්ථර වළක්වා ගැනීමට කැමැත්තෙමු OpenStack: අපට "ඝෝෂාකාරී අසල්වැසියන්" සහ CPU අවශ්ය නොවේ කාලය සොරකම් කරති. අභ්‍යන්තර OpenStack සම්බන්ධයෙන් පරිපාලනයේ සංකීර්ණත්වය ආසන්න වශයෙන් දෙගුණ වේ.
CI/CD “Cubic” සහ අනෙකුත් යටිතල පහසුකම් සංරචක සඳහා අපි වෙනම GIT සේවාදායකයක් භාවිතා කරමු, Helm 3 (එය Helm 2 වෙතින් තරමක් වේදනාකාරී සංක්‍රාන්තියක් විය, නමුත් විකල්පයන් පිළිබඳව අපි ඉතා සතුටු වෙමු. පරමාණුක), ජෙන්කින්ස්, ඇන්සිබල් සහ ඩොකර්. අපි විශේෂාංග ශාඛා වලට ප්‍රිය කරන අතර එක් ගබඩාවක සිට විවිධ පරිසරයන් වෙත යෙදවීමට.
නිගමනය
මෙය සාමාන්යයෙන්, මෙහෙයුම් ඉංජිනේරුවෙකුගේ දෘෂ්ටිකෝණයෙන් DomClick හි DevOps ක්රියාවලිය කෙබඳුද යන්නයි. ලිපිය මා බලාපොරොත්තු වූවාට වඩා අඩු තාක්ෂණික එකක් බවට පත් විය: එබැවින්, Habré හි DomClick පුවත් අනුගමනය කරන්න: Kubernetes සහ තවත් බොහෝ දේ ගැන "දැඩි" ලිපි තිබේ.
මූලාශ්රය: www.habr.com