Kubernetes ලෝකය අත්පත් කර ගනු ඇත. කවදාද සහ කෙසේද?

අපේක්ෂාවෙන් DevOpsConf විටාලි කබරොව් සම්මුඛ සාකච්ඡා කළා Dmitry Stolyarov (distol), Flant සමාගමේ තාක්ෂණික අධ්යක්ෂ සහ සම-නිර්මාතෘ. විටාලි දිමිත්‍රිගෙන් විමසුවේ ෆ්ලැන්ට් කරන්නේ කුමක්ද, කුබර්නෙටස් ගැන, පරිසර පද්ධති සංවර්ධනය, සහාය ගැන ය. කුබර්නෙට්ස් අවශ්‍ය වන්නේ ඇයි සහ එය කිසිසේත් අවශ්‍යද යන්න අපි සාකච්ඡා කළෙමු. ඒවගේම microservices, Amazon AWS, DevOps සඳහා “මම වාසනාවන්තයි” ප්‍රවේශය, Kubernetes හි අනාගතය, ඇයි, කවදා සහ එය ලෝකය අත්පත් කර ගන්නේ කෙසේද, DevOps හි අපේක්ෂාවන් සහ ඉංජිනේරුවන් සඳහා සූදානම් විය යුතු දේ ගැන. සරල කිරීම සහ ස්නායු ජාල සමඟ දීප්තිමත් සහ නුදුරු අනාගතය.

මුල් සම්මුඛ පරීක්ෂණය DevOps Deflop හි පොඩ්කාස්ට් එකක් ලෙස සවන් දෙන්න - DevOps පිළිබඳ රුසියානු භාෂාවේ පොඩ්කාස්ට් එකක්, සහ පහත පෙළ අනුවාදය වේ.

Kubernetes ලෝකය අත්පත් කර ගනු ඇත. කවදාද සහ කෙසේද?

මෙන්න සහ යටින් ඔහු ප්රශ්න අසයි විටාලි කබරොව් Express42 හි ඉංජිනේරු.

"Flant" ගැන

- හෙලෝ ඩීමා. ඔබ තාක්ෂණික අධ්‍යක්ෂ"පැතලි"සහ එහි නිර්මාතෘ. කරුණාකර සමාගම කරන්නේ කුමක්ද සහ ඔබ එහි සිටින්නේ කුමක්දැයි අපට කියන්න?

Kubernetes ලෝකය අත්පත් කර ගනු ඇත. කවදාද සහ කෙසේද?දිමිත්රි: පිටින් බැලුවම පේන්නේ අපි හැමෝටම Kubernetes ස්ථාපනය කරලා ඒකෙන් මොනවා හරි කරන කොල්ලෝ කියලා. නමුත් එය සත්‍ය නොවේ. අපි ලිනක්ස් සමඟ ගනුදෙනු කරන සමාගමක් ලෙස ආරම්භ කළ නමුත් ඉතා දිගු කාලයක් අපගේ ප්‍රධාන ක්‍රියාකාරකම වන්නේ නිෂ්පාදන සහ ඉහළ බර පැටවීමේ ව්‍යාපෘති සඳහා සේවා සැපයීමයි. සාමාන්‍යයෙන් අපි මුළු යටිතල ව්‍යුහයම මුල සිටම ගොඩනඟා දිගු කාලයක් තිස්සේ එයට වගකිව යුතුය. එමනිසා, "Flant" විසින් මුදල් ලබා ගන්නා ප්රධාන කාර්යය වන්නේ වගකීම භාර ගැනීම සහ පිරිවැටුම් නිෂ්පාදන ක්රියාත්මක කිරීම.




මම, තාක්‍ෂණික අධ්‍යක්ෂ සහ සමාගමේ ආරම්භකයෙකු ලෙස, නිෂ්පාදනයේ ප්‍රවේශ්‍යතාවය වැඩි කරන්නේ කෙසේද, එහි ක්‍රියාකාරිත්වය සරල කරන්නේ කෙසේද, පරිපාලකයින්ගේ ජීවිතය පහසු කරන්නේ කෙසේද සහ සංවර්ධකයින්ගේ ජීවිතය වඩාත් ප්‍රසන්න කරන්නේ කෙසේදැයි සොයා බැලීමට දිවා රෑ ගත කරමි. .

Kubernetes ගැන

- මෑතක සිට මම Flant සහ වෙතින් බොහෝ වාර්තා දුටුවෙමි ලිපි Kubernetes ගැන. ඔබ එයට පැමිණියේ කෙසේද?

දිමිත්රි: මම දැනටමත් මේ ගැන බොහෝ වාරයක් කතා කර ඇත, නමුත් එය නැවත නැවත කීම මට කමක් නැත. හේතුව සහ ඵලය අතර ව්‍යාකූලත්වයක් ඇති නිසා මෙම මාතෘකාව නැවත කීම නිවැරදි යැයි මම සිතමි.

අපට ඇත්තටම මෙවලමක් අවශ්‍ය විය. අපි ප්‍රශ්න ගොඩකට මුහුණ දීලා, අරගල කරලා, විවිධ කිහිලිකරුවලින් ඒවා ජය ගත්තා, මෙවලමක අවශ්‍යතාවය දැනුණා. අපි විවිධ විකල්ප හරහා ගොස්, අපේම බයිසිකල් සාදා, අත්දැකීම් ලබා ගත්තෙමු. ක්‍රමක්‍රමයෙන් අපි Docker එක පෙනුන ගමන්ම වගේ පාවිච්චි කරන්න පටන් ගන්න තැනට ආවා - 2013 විතර. එය දර්ශනය වන විට, අපට දැනටමත් බහාලුම් පිළිබඳ අත්දැකීම් රාශියක් තිබුණි, අපි දැනටමත් “ඩොකර්” හි ප්‍රතිසමයක් ලියා තිබුණි - පයිතන් හි අපගේම කිහිලිකරු කිහිපයක්. ඩොකර්ගේ පැමිණීමත් සමඟ, කිහිලිකරු ඉවතට විසි කර විශ්වාසදායක සහ ප්‍රජා ආධාරක විසඳුමක් භාවිතා කිරීමට හැකි විය.

Kubernetes සමඟ කතාව සමාන ය. එය වේගවත් වීමට පටන් ගන්නා විට - අපට මෙය 1.2 අනුවාදයයි - අපි දැනටමත් ෂෙල් සහ චෙෆ් යන දෙකෙහිම කිහිලිකරු පොකුරක් තිබුනා, අපි කෙසේ හෝ ඩොකර් සමඟ සංවිධානය කිරීමට උත්සාහ කළෙමු. අපි රැන්චර් සහ වෙනත් විවිධ විසඳුම් දෙස බැරෑරුම් ලෙස බලා සිටියෙමු, නමුත් පසුව කුබර්නෙටස් පෙනී සිටි අතර, එහි සෑම දෙයක්ම අප කළ ආකාරයටම හෝ ඊටත් වඩා හොඳින් ක්‍රියාත්මක වේ. පැමිණිලි කිරීමට කිසිවක් නැත.

ඔව්, මෙහි යම් ආකාරයක අසම්පූර්ණතාවයක් තිබේ, එහි යම් ආකාරයක අසම්පූර්ණකමක් තිබේ - බොහෝ අඩුපාඩු තිබේ, සහ 1.2 සාමාන්යයෙන් භයානක ය, නමුත් ... Kubernetes යනු ඉදිවෙමින් පවතින ගොඩනැගිල්ලක් වැනි ය - ඔබ ව්යාපෘතිය දෙස බලා තේරුම් ගන්න. එය සිසිල් වනු ඇත. ගොඩනැගිල්ලට දැන් අත්තිවාරමක් සහ තට්ටු දෙකක් තිබේ නම්, ඔබ තවමත් නොසැලී සිටීම වඩා හොඳ බව ඔබ තේරුම් ගනී, නමුත් මෘදුකාංගය සමඟ එවැනි ගැටළු නොමැත - ඔබට දැනටමත් එය භාවිතා කළ හැකිය.

අපි Kubernetes භාවිතා කිරීම හෝ නොකිරීම ගැන සිතන මොහොතක් අපට නොතිබුණි. එය දර්ශනය වීමට බොහෝ කලකට පෙර අපි එය බලා සිටි අතර, අප විසින්ම ඇනලොග් නිර්මාණය කිරීමට උත්සාහ කළෙමු.

Kubernetes ගැන

- ඔබ Kubernetes සංවර්ධනයට සෘජුවම සම්බන්ධද?

දිමිත්රි: මධ්යස්ථ. ඒ වෙනුවට, අපි පරිසර පද්ධතියේ සංවර්ධනයට සහභාගී වෙමු. අපි ඇදීමේ ඉල්ලීම් නිශ්චිත සංඛ්‍යාවක් යවමු: Prometheus වෙත, විවිධ ක්‍රියාකරුවන් වෙත, Helm වෙත - පරිසර පද්ධතියට. අවාසනාවකට, මට අප කරන සෑම දෙයක්ම නිරීක්ෂණය කිරීමට නොහැකි වන අතර මම වැරදි විය හැක, නමුත් අපෙන් හරයට එක සංචිතයක් නොමැත.

— ඒ අතරම, ඔබ Kubernetes අවට ඔබේ මෙවලම් බොහොමයක් සංවර්ධනය කරනවාද?

දිමිත්රි: උපාය මාර්ගය මෙයයි: අපි ගොස් දැනටමත් පවතින සෑම දෙයකටම ඉල්ලීම් අදින්නෙමු. ඇදීමේ ඉල්ලීම් එහිදී පිළි නොගන්නේ නම්, අපි ඒවා අප විසින්ම ගෑරුප්පු කර අපගේ ගොඩනැඟිලි සමඟ ඒවා පිළිගන්නා තෙක් ජීවත් වෙමු. ඉන්පසුව, එය උඩු ගංවතුරට ළඟා වූ විට, අපි නැවත උඩුගං අනුවාදය වෙත යමු.

උදාහරණයක් ලෙස, අපට Prometheus ක්‍රියාකරුවෙකු ඇත, එය සමඟ අපි අපගේ එකලස් කිරීමේ ඉහළට 5 වතාවක් දැනටමත් මාරු වී ඇත. අපට යම් ආකාරයක විශේෂාංගයක් අවශ්‍යයි, අපි ඇදීමේ ඉල්ලීමක් යැව්වා, අපට එය හෙට නිකුත් කිරීමට අවශ්‍යයි, නමුත් එය උඩුගං බලා මුදා හැරීමට අපට බලා සිටීමට අවශ්‍ය නැත. ඒ අනුව, අපි අප වෙනුවෙන්ම එක්රැස් වෙමු, කිසියම් හේතුවක් නිසා අපට අවශ්‍ය වන අපගේ විශේෂාංගය සමඟ අපගේ එකලස් කිරීම අපගේ සියලුම පොකුරු වෙත ගෙන යන්නෙමු. ඉන්පසුව, උදාහරණයක් ලෙස, ඔවුන් එය උඩුගං බලා අප වෙත හරවයි: “යාලුවනේ, අපි එය වඩාත් සාමාන්‍ය නඩුවක් සඳහා කරමු,” අපි හෝ වෙනත් කෙනෙකු එය අවසන් කර කාලයත් සමඟ එය නැවත ඒකාබද්ධ වේ.

පවතින සෑම දෙයක්ම සංවර්ධනය කිරීමට අපි උත්සාහ කරමු. තවමත් නොපවතින, තවමත් සොයාගෙන නොමැති, හෝ සොයා ගෙන නොමැති, නමුත් ක්රියාත්මක කිරීමට කාලය නොමැති බොහෝ මූලද්රව්ය - අපි එය කරමින් සිටිමු. කර්මාන්තයක් ලෙස අපි ක්‍රියාවලියට හෝ බයිසිකල් ගොඩනැගීමට කැමති නිසා නොව, අපට මෙම මෙවලම අවශ්‍ය නිසා. ප්‍රශ්නය බොහෝ විට අසනු ලැබේ, ඇයි අපි මේ හෝ ඒ දේ කළේ? පිළිතුර සරලයි - ඔව්, අපට තවත් ඉදිරියට යාමට සිදු වූ නිසා, යම් ප්‍රායෝගික ගැටලුවක් විසඳා, අපි එය මෙම ටූලා සමඟ විසඳා ගත්තෙමු.

මාර්ගය සෑම විටම මේ වගේ ය: අපි ඉතා පරෙස්සමින් සොයමින්, පාන් රොටියකින් ට්‍රොලිබස් එකක් සාදා ගන්නේ කෙසේද යන්න පිළිබඳ විසඳුමක් සොයාගත නොහැකි නම්, අපි අපේම රොටියක් සහ ට්‍රොලිබස් එකක් සාදන්නෙමු.

ෆ්ලැන්ටා මෙවලම්

— Flant සතුව දැන් addon operators, shell operators සහ dapp/werf මෙවලම් ඇති බව මම දනිමි. මම තේරුම් ගත් පරිදි, මෙය විවිධ අවතාරවල එකම උපකරණයකි. Flaunt තුළ තවත් බොහෝ විවිධ මෙවලම් තිබෙන බව මට වැටහෙනවා. මෙය සත්යයයි?

දිමිත්රි: අපට GitHub හි තවත් බොහෝ දේ ඇත. මට දැන් මතක ඇති පරිදි, අපට තත්ව සිතියමක් ඇත - ග්‍රැෆානා සඳහා පැනලයක් සෑම කෙනෙකුටම හමු වී ඇත. කුබර්නෙටස් මාධ්‍ය අධීක්ෂණය ගැන සෑම දෙවන ලිපියකම පාහේ සඳහන් වේ. තත්ව සිතියමක් යනු කුමක්දැයි කෙටියෙන් පැහැදිලි කළ නොහැක - එයට වෙනම ලිපියක් අවශ්‍ය වේ, නමුත් එය කාලයත් සමඟ තත්වය නිරීක්ෂණය කිරීම සඳහා ඉතා ප්‍රයෝජනවත් දෙයකි, මන්ද Kubernetes හි අපට බොහෝ විට කාලයත් සමඟ තත්වය පෙන්වීමට අවශ්‍ය වේ. අපට ලොග්හවුස් ද ඇත - මෙය ක්ලික් හවුස් සහ කුබර්නෙටස් හි ලොග් එකතු කිරීම සඳහා කළු මැජික් මත පදනම් වූ දෙයකි.

උපයෝගිතා ගොඩක්! මේ වසරේ අභ්‍යන්තර විසඳුම් ගණනාවක් නිකුත් කරන නිසා ඊටත් වඩා වැඩි යමක් වනු ඇත. ඇඩෝන ක්‍රියාකරු මත පදනම් වූ ඉතා විශාල ඒවායින්, කුබර්නෙටස් සඳහා ඇඩෝන පොකුරක් ඇත, සර්ට් කළමණාකරු නිවැරදිව ස්ථාපනය කරන්නේ කෙසේද - සහතික කළමණාකරන මෙවලමක්, උපාංග පොකුරක් සමඟ ප්‍රොමිතියස් නිවැරදිව ස්ථාපනය කරන්නේ කෙසේද - මේවා වෙනස් විස්සක් පමණ වේ. දත්ත අපනයනය කරන සහ යමක් එකතු කරන ද්විමය, මෙම Prometheus වෙත වඩාත්ම විශ්මයජනක ග්‍රැෆික්ස් සහ ඇඟවීම් ඇත. මේ සියල්ල පොකුරක් තුළ ස්ථාපනය කර ඇති Kubernetes වෙත ඇඩෝන පොකුරක් පමණක් වන අතර, එය සරල සිට සිසිල්, නවීන, ස්වයංක්‍රීය, බොහෝ ගැටලු දැනටමත් විසඳා ඇත. ඔව්, අපි බොහෝ දේ කරනවා.

පරිසර පද්ධති සංවර්ධනය

"මෙම උපකරණය සහ එහි භාවිතයේ ක්‍රම සංවර්ධනය කිරීම සඳහා මෙය ඉතා විශාල දායකත්වයක් බව මට පෙනේ." පරිසර පද්ධතියේ සංවර්ධනයට සමාන දායකත්වයක් සපයන්නේ කවුරුන්ද යන්න ඔබට දළ වශයෙන් තක්සේරු කළ හැකිද?

දිමිත්රි: රුසියාවේ, අපගේ වෙළඳපොලේ ක්රියාත්මක වන සමාගම් වලින්, කිසිවෙකු සමීප නැත. ඇත්ත වශයෙන්ම, මෙය ඝෝෂාකාරී ප්‍රකාශයකි, මන්ද Mail සහ Yandex වැනි ප්‍රධාන ක්‍රීඩකයින් සිටින බැවිනි - ඔවුන්ද Kubernetes සමඟ යමක් කරමින් සිටී, නමුත් ඔවුන් පවා අපට වඩා බොහෝ දේ කරන මුළු ලෝකයේම සමාගම්වල දායකත්වයට සමීප නොවේ. පුද්ගලයන් 80 දෙනෙකුගෙන් යුත් කාර්ය මණ්ඩලයක් සිටින Flant සහ Kubernetes එකකට පමණක් ඉංජිනේරුවන් 300 දෙනෙකු සිටින Red Hat, මා වැරදියට වටහා නොගන්නේ නම් සංසන්දනය කිරීම දුෂ්කර ය. සංසන්දනය කරන්න අමාරුයි. අපි RnD දෙපාර්තමේන්තුවේ 6 දෙනෙක් ඉන්නවා, මම ඇතුළුව, අපේ සියලුම මෙවලම් කපා. Red Hat ඉංජිනේරුවන් 6කට එරෙහිව පුද්ගලයන් 300 දෙනෙකු - එය කෙසේ හෝ සැසඳීම දුෂ්කර ය.

- කෙසේ වෙතත්, මෙම පුද්ගලයින් 6 දෙනාට පවා සැබවින්ම ප්‍රයෝජනවත් සහ අන්සතු කරන දෙයක් කළ හැකි විට, ඔවුන් ප්‍රායෝගික ගැටලුවකට මුහුණ දී ප්‍රජාවට විසඳුම ලබා දෙන විට - සිත්ගන්නා නඩුවක්. ඔවුන්ගේම Kubernetes සංවර්ධන සහ සහායක කණ්ඩායමක් ඇති විශාල තාක්‍ෂණ සමාගම්වල, ප්‍රතිපත්තිමය වශයෙන්, එකම මෙවලම් සංවර්ධනය කළ හැකි බව මට වැටහේ. මෙය Kubernetes භාවිතා කරන සමස්ත ප්‍රජාවටම දිරියක් ලබා දෙමින් සංවර්ධනය කර ප්‍රජාවට දිය හැකි දේ පිළිබඳ ඔවුන්ට ආදර්ශයකි.

දිමිත්රි: මෙය බොහෝ විට අනුකලනයෙහි ලක්ෂණයක්, එහි විශේෂත්වය. අපට බොහෝ ව්‍යාපෘති ඇති අතර අපි විවිධ තත්වයන් දකිමු. අපට, එකතු කළ අගයක් නිර්මාණය කිරීමේ ප්‍රධාන ක්‍රමය වන්නේ මෙම අවස්ථා විශ්ලේෂණය කර, පොදු බව සොයා ගැනීම සහ ඒවා අපට හැකි තරම් ලාභදායී කිරීමයි. අපි මේ සඳහා ක්‍රියාකාරීව කටයුතු කරනවා. මට රුසියාව සහ ලෝකය ගැන කතා කිරීම දුෂ්කර ය, නමුත් අපට Kubernetes හි සේවය කරන සමාගමේ DevOps ඉංජිනේරුවන් 40 ක් පමණ සිටී. කුබර්නෙටේස් තේරුම් ගන්නා සැසඳිය හැකි විශේෂඥයින් සංඛ්‍යාවක් සිටින බොහෝ සමාගම් රුසියාවේ ඇතැයි මම නොසිතමි.

DevOps ඉංජිනේරුවරයාගේ රැකියා මාතෘකාව පිළිබඳ සෑම දෙයක්ම මට වැටහෙනවා, සෑම කෙනෙකුටම සියල්ල තේරෙනවා සහ DevOps ඉංජිනේරුවන් DevOps ඉංජිනේරුවන් ලෙස ඇමතීමට පුරුදු වී ඇත, අපි මෙය සාකච්ඡා නොකරමු. මෙම විස්මිත DevOps ඉංජිනේරුවන් 40 දෙනාම දිනපතා ගැටලුවලට මුහුණ දී විසඳා ගනිමු, අපි මෙම අත්දැකීම විශ්ලේෂණය කර සාමාන්‍යකරණය කිරීමට උත්සාහ කරමු. එය අප තුළ පවතී නම්, වසරක් හෝ දෙකකින් මෙවලම නිෂ්ඵල වනු ඇති බව අපට වැටහේ, මන්ද සමාජයේ කොතැනක හෝ සූදානම් කළ Tula එකක් දිස්වනු ඇත. මෙම අත්දැකීම අභ්‍යන්තරව එක්රැස් කිරීමේ තේරුමක් නැත - එය හුදෙක් ශක්තිය සහ කාලය dev/null බවට කාන්දු කරයි. ඒ වගේම අපි ඒ ගැන කිසිසේත්ම අනුකම්පා කරන්නේ නැහැ. අපි සෑම දෙයක්ම ඉතා සතුටින් ප්‍රකාශයට පත් කරන අතර එය ප්‍රකාශ කිරීම, සංවර්ධනය කිරීම, ප්‍රවර්ධනය කිරීම, ප්‍රවර්ධනය කිරීම අවශ්‍ය බව තේරුම් ගනිමු, එවිට මිනිසුන් එය භාවිතා කර ඔවුන්ගේ අත්දැකීම් එකතු කරමු - එවිට සියල්ල වර්ධනය වී ජීවත් වේ. එවිට වසර දෙකකට පසු උපකරණය කුණු කූඩයට යන්නේ නැත. යමෙකු ඔබේ මෙවලම භාවිතා කරන බව පැහැදිලි වන නිසාත්, වසර දෙකකට පසු සෑම කෙනෙකුම එය භාවිතා කරන නිසාත්, ශක්තිය දිගටම ගලා යාම අනුකම්පාවක් නොවේ.

මෙය dapp/werf සමඟ අපගේ විශාල උපාය මාර්ගයේ කොටසකි. අපි එය සෑදීමට පටන් ගත්තේ කවදාදැයි මට මතක නැත, එය වසර 3 කට පෙර මෙන් පෙනේ. මුලදී, එය සාමාන්යයෙන් කවචය මත විය. එය සංකල්පයේ සුපිරි සාක්ෂියක් විය, අපි අපගේ විශේෂිත ගැටළු කිහිපයක් විසඳා ඇත - එය වැඩ කළා! නමුත් කවචයේ ගැටළු තිබේ, එය තවදුරටත් පුළුල් කළ නොහැක, කවචයේ වැඩසටහන් කිරීම තවත් කාර්යයකි. අපිට රූබි වලින් ලියන පුරුද්දක් තිබුණා, ඒ අනුව, අපි රූබි වලින් යමක් ප්‍රතිනිර්මාණය කර, දියුණු කර, දියුණු කර, දියුණු කර, ප්‍රජාව, “අපට එය අවශ්‍ය හෝ අපට එය අවශ්‍ය නැත” යැයි නොකියන සමූහයා බවට දිව ගියෙමු. ” රූබි දෙසට නහය ඔසවයි, එය කෙතරම් විහිලුවක්ද? පිරික්සුම් ලැයිස්තුවේ පළමු කරුණ හමුවීමට පමණක් අපි මේ සියල්ල Go හි ලිවිය යුතු බව අපට වැටහුණා: DevOps මෙවලම ස්ථිතික ද්විමය විය යුතුය. Go වීම හෝ නොවීම එතරම් වැදගත් නොවේ, නමුත් Go හි ලියා ඇති ස්ථිතික ද්විමය වඩා හොඳය.

අපි අපේ ශක්තිය වැය කර, Go හි dapp නැවත ලියා එය werf ලෙස හැඳින්වුවෙමු. Dapp තවදුරටත් සහාය නොදක්වයි, සංවර්ධනය කර නැත, සමහර නවතම අනුවාදයක ධාවනය වේ, නමුත් ඉහළට නිරපේක්ෂ උත්ශ්‍රේණිගත කිරීමේ මාර්ගයක් ඇත, ඔබට එය අනුගමනය කළ හැක.

ඩැප් නිර්මාණය කළේ ඇයි?

— ඔබට කෙටියෙන් අපට කියන්න පුළුවන්ද dapp නිර්මාණය කළේ ඇයි, එය විසඳන ගැටළු මොනවාද?

දිමිත්රි: පළමු හේතුව සභාව තුළ. මුලදී, Docker සතුව බහු-අදියර හැකියාවන් නොමැති විට අපට ගොඩනැගීම සම්බන්ධයෙන් බරපතල ගැටළු ඇති වූ අතර, අපි තනිවම බහු-අදියර සෑදුවෙමු. එවිට අපට රූපය පිරිසිදු කිරීමේදී තවත් ගැටළු රාශියක් ඇති විය. CI/CD කරන හැම කෙනෙක්ම, ඉක්මනින්ම, එකතු කරන ලද පින්තූර ගොන්නක් තියෙනවා කියන ප්‍රශ්නයට මුහුණ දෙනවා, කොහොම හරි අනවශ්‍ය දේ පිරිසිදු කරලා අවශ්‍ය දේ දාලා යන්න ඕන.

දෙවන හේතුව වන්නේ යෙදවීමයි. ඔව්, Helm ඇත, නමුත් එය විසඳන්නේ ගැටළු කිහිපයක් පමණි. හාස්‍යජනක ලෙස, "Helm යනු Kubernetes සඳහා පැකේජ කළමනාකරු" ලෙස ලියා ඇත. හරියටම "ද". "Package Manager" යන වචන ද ඇත - පැකේජ කළමණාකරුවෙකුගෙන් සුපුරුදු අපේක්ෂාව කුමක්ද? අපි කියන්නේ: "පැකේජ කළමනාකරු - පැකේජය ස්ථාපනය කරන්න!" "පැකේජය භාර දී ඇත" යනුවෙන් ඔහු අපට පවසනු ඇතැයි අපි බලාපොරොත්තු වෙමු.

“හෙල්ම්, පැකේජය ස්ථාපනය කරන්න” යැයි අප පැවසීම සිත්ගන්නා කරුණකි, ඔහු එය ස්ථාපනය කළ බවට පිළිතුරු දුන් විට, ඔහු ස්ථාපනය ආරම්භ කළ බව පෙනේ - ඔහු කුබර්නෙටස් ඇඟවුම් කළේය: “මෙය දියත් කරන්න!”, සහ එය ආරම්භ කළත් නැතත්. , එය ක්‍රියා කළත් නැතත්, හෙල්ම් මෙම ප්‍රශ්නය කිසිසේත් විසඳන්නේ නැත.

Helm යනු Kubernetes වෙත දත්ත පූරණය කරන text preprocessor එකක් පමණක් බව පෙනී යයි.

නමුත් කිසියම් යෙදවීමක කොටසක් ලෙස, යෙදුම නිෂ්පාදනය සඳහා නිකුත් කර තිබේද නැද්ද යන්න අපට දැන ගැනීමට අවශ්‍යද? Prod to prod යන්නෙන් අදහස් වන්නේ යෙදුම එහි ගෙන ගොස් ඇති බවත්, නව අනුවාදය යොදවා ඇති බවත්, අඩුම තරමින් එය එහි බිඳ වැටීමක් සිදු නොවන අතර නිවැරදිව ප්‍රතිචාර දක්වන බවත්ය. Helm මෙම ගැටලුව කිසිම ආකාරයකින් විසඳන්නේ නැත. එය විසඳීම සඳහා, ඔබ විශාල උත්සාහයක් දැරිය යුතුය, මන්ද ඔබ කුබර්නෙටස් හට එහි සිදුවන දේ පෙරළීමට සහ නිරීක්ෂණය කිරීමට විධානය ලබා දිය යුතුය - එය යෙදවූයේ හෝ පෙරළී ගියද යන්නයි. තවද යෙදවීම, පිරිසිදු කිරීම සහ එකලස් කිරීම සම්බන්ධ බොහෝ කාර්යයන් ද ඇත.

සැලසුම්

මේ වසරේ අපි දේශීය සංවර්ධනය ආරම්භ කරනවා. අපට කලින් Vagrant හි තිබූ දේ සාක්ෂාත් කර ගැනීමට අවශ්‍යයි - අපි “vagrant up” ටයිප් කර අපි අතථ්‍ය යන්ත්‍ර යෙදුවෙමු. අපට Git හි ව්‍යාපෘතියක් ඇති තැනට යාමට අවශ්‍යයි, අපි එහි “werf up” ලියන්නෙමු, සහ එය මෙම ව්‍යාපෘතියේ දේශීය පිටපතක් ගෙන එයි, දේශීය කුඩා-කුබ් එකක යොදවා ඇත, සංවර්ධනය සඳහා පහසු සියලුම නාමාවලි සම්බන්ධ කර ඇත. . සංවර්ධන භාෂාව මත පදනම්ව, මෙය වෙනස් ආකාරයකින් සිදු කරයි, නමුත් කෙසේ වෙතත්, දේශීය සංවර්ධනය සවිකර ඇති ගොනු යටතේ පහසුවෙන් සිදු කළ හැකිය.

අපට ඊළඟ පියවර වන්නේ සංවර්ධකයින් සඳහා පහසුව සඳහා ආයෝජනය කරන්න. එක් මෙවලමක් සමඟ ව්‍යාපෘතියක් ඉක්මනින් දේශීයව යෙදවීමට, එය සංවර්ධනය කරන්න, එය Git වෙතට තල්ලු කරන්න, තවද එය නල මාර්ග මත පදනම්ව වේදිකාවට හෝ පරීක්ෂණවලට පෙරළෙනු ඇත, පසුව නිෂ්පාදනයට යාමට එම මෙවලමම භාවිතා කරන්න. දේශීය පරිසරයේ සිට විකුණුම් දක්වා යටිතල පහසුකම් මෙම එකමුතුව, ඒකාබද්ධ කිරීම, ප්‍රතිනිෂ්පාදනය කිරීම අපට ඉතා වැදගත් කරුණකි. නමුත් මෙය තවමත් werf හි නොමැත - අපි එය කිරීමට සැලසුම් කරමින් සිටිමු.

නමුත් dapp/werf වෙත යන මාර්ගය සෑම විටම ආරම්භයේ Kubernetes සමඟ සමාන විය. අපි ගැටළු වලට මුහුණ දුන්නෙමු, ඒවා විසඳුම් සමඟ විසඳා ගත්තෙමු - අපි කවචයේ, ඕනෑම දෙයක් සඳහා අපටම විසඳුම් කිහිපයක් ඉදිරිපත් කළෙමු. ඉන්පසු ඔවුන් කෙසේ හෝ මෙම ක්‍රියා මාර්ග සෘජු කිරීමටත්, සාමාන්‍යකරණය කිරීමටත්, මෙම නඩුවේ ද්විමය බවට ඒකාබද්ධ කිරීමටත් උත්සාහ කළහ, එය අපි සරලව බෙදා ගනිමු.

මේ මුළු කතාව දෙසම සාදෘශ්‍ය සහිතව බැලීමට තවත් ක්‍රමයක් තිබේ.

Kubernetes යනු එන්ජිමක් සහිත කාර් රාමුවකි. දොරවල්, වීදුරු, ගුවන් විදුලි, නත්තල් ගස - කිසිවක් නැත. රාමුව සහ එන්ජිම පමණි. හෙල්ම් ඇත - මෙය සුක්කානම් රෝදයයි. සිසිල් - සුක්කානම් රෝදයක් ඇත, නමුත් ඔබට සුක්කානම් පින් එකක්, සුක්කානම් රාක්කයක්, ගියර් පෙට්ටියක් සහ රෝද අවශ්‍ය වන අතර ඔබට ඒවා නොමැතිව කළ නොහැක.

වර්ෆ් සම්බන්ධයෙන් ගත් කල, මෙය Kubernetes සඳහා තවත් අංගයකි. උදාහරණයක් ලෙස, වර්ෆ් හි ඇල්ෆා අනුවාදයේ දැන් පමණක්, හෙල්ම් වර්ෆ් තුළ සම්පාදනය කර ඇත, මන්ද එය අප විසින්ම කිරීමට අපට මහන්සියි. මෙය කිරීමට බොහෝ හේතු තිබේ, අපි වර්ෆ් ඇතුළත ටිලර් සමඟ මුළු හෙල්මයම සම්පාදනය කළේ මන්දැයි මම ඔබට විස්තරාත්මකව කියමි. RIT++ හි වාර්තාවක.

දැන් werf යනු වඩාත් ඒකාබද්ධ සංරචකයකි. අපට නිමි සුක්කානම් රෝදයක්, සුක්කානම් පින් එකක් ලැබේ - මම කාර් වලට එතරම් දක්ෂ නැත, නමුත් මෙය දැනටමත් තරමක් පුළුල් පරාසයක ගැටළු විසඳන විශාල කොටසකි. අප විසින්ම නාමාවලිය හරහා යාමට අවශ්ය නැත, තවත් කොටසක් සඳහා එක් කොටසක් තෝරන්න, ඒවා එකට ඉස්කුරුප්පු කරන ආකාරය ගැන සිතන්න. අපට එකවර ගැටළු විශාල ප්‍රමාණයක් විසඳන සූදානම් කළ සංයෝජනයක් ලැබේ. නමුත් එය ඇතුළත එකම විවෘත මූලාශ්‍ර සංරචක වලින් ගොඩනගා ඇත, එය තවමත් එකලස් කිරීම සඳහා ඩොකර් භාවිතා කරයි, සමහර ක්‍රියාකාරීත්වය සඳහා හෙල්ම් භාවිතා කරයි, සහ තවත් පුස්තකාල කිහිපයක් තිබේ. මෙය ඉක්මනින් සහ පහසු ලෙස පෙට්ටියෙන් සිසිල් CI/CD ලබා ගැනීමට ඒකාබද්ධ මෙවලමකි.

Kubernetes නඩත්තු කිරීමට අපහසුද?

- ඔබ Kubernetes භාවිතා කිරීමට පටන් ගත් අත්දැකීම ගැන කතා කරයි, මෙය ඔබ සඳහා රාමුවක්, එන්ජිමක්, සහ ඔබට එය මත විවිධ දේවල් එල්ලා තැබිය හැකිය: ශරීරයක්, සුක්කානම් රෝදයක්, පැඩල්වල ඉස්කුරුප්පු ඇණ, ආසන. ප්රශ්නය පැනනගින්නේ - Kubernetes ඔබට කොතරම් දුෂ්කරද? ඔබට බොහෝ අත්දැකීම් තිබේ, අනෙක් සියල්ලෙන් හුදකලා වී කුබර්නෙට්ස්ට සහාය වීමට ඔබ කොපමණ කාලයක් සහ සම්පත් වැය කරනවාද?

දිමිත්රි: මෙය ඉතා දුෂ්කර ප්රශ්නයක් වන අතර පිළිතුරු දීමට, අපි Kubernetes වෙතින් සහයෝගය සහ අපට අවශ්ය කුමක්ද යන්න තේරුම් ගත යුතුය. සමහර විට ඔබට හෙළි කළ හැකිද?

- මා දන්නා පරිදි සහ මා දකින පරිදි, දැන් බොහෝ කණ්ඩායම්වලට Kubernetes උත්සාහ කිරීමට අවශ්‍යයි. සෑම කෙනෙකුම එය භාවිතා කරයි, එය දණින් තබයි. මේ ක්‍රමයේ තියෙන සංකීර්ණත්වය මිනිස්සුන්ට හැම වෙලාවෙම තේරෙන්නේ නැහැ කියන හැඟීම මට තියෙනවා.

දිමිත්රි: එය ඒ වගේ දෙයක්.

- කුබර්නෙටස් නිෂ්පාදනයට සූදානම් වන පරිදි මුල සිටම ගෙන ස්ථාපනය කිරීම කොතරම් දුෂ්කර ද?

දිමිත්රි: හදවතක් බද්ධ කිරීම කොතරම් දුෂ්කර යැයි ඔබ සිතනවාද? මෙය සම්මුතිවාදී ප්‍රශ්නයක් බව මට වැටහේ. හිස්කබල භාවිතා කර වරදක් නොකිරීම එතරම් අපහසු නොවේ. කපා දැමිය යුත්තේ කොතැනද සහ මැසීමට කොතැනදැයි ඔවුන් ඔබට පවසන්නේ නම්, ක්රියා පටිපාටියම සංකීර්ණ නොවේ. සෑම දෙයක්ම සාර්ථක වන බව කාලයෙන් කාලයට සහතික කිරීම අපහසුය.

Kubernetes ස්ථාපනය කිරීම සහ එය ක්‍රියාත්මක කිරීම පහසුය: චික්! - ස්ථාපනය කර ඇත, ස්ථාපන ක්රම ගොඩක් තිබේ. නමුත් ගැටළු ඇති වූ විට කුමක් සිදුවේද?

ප්‍රශ්න සෑම විටම පැන නගී - අප තවමත් සැලකිල්ලට ගෙන නොමැති දේ කුමක්ද? අපි තවම නොකළේ කුමක්ද? කුමන Linux කර්නල් පරාමිති වැරදි ලෙස සඳහන් කර තිබේද? ස්වාමීනි, අපි ඔවුන් ගැන සඳහන් කළාද?! කුමන Kubernetes සංරචක අප විසින් ලබා දී ඇති අතර අප විසින් ලබා දී නොමැති මොනවාද? ප්රශ්න දහස් ගණනක් පැනනගින අතර, ඒවාට පිළිතුරු සැපයීම සඳහා, ඔබ මෙම කර්මාන්තයේ වසර 15-20 ක් ගත කළ යුතුය.

“කුබර්නෙටස් නඩත්තු කිරීමට අපහසුද?” යන ගැටලුවේ තේරුම හෙළි කළ හැකි මෙම මාතෘකාව පිළිබඳ මෑත කාලීන උදාහරණයක් මා සතුව ඇත. කලකට පෙර අපි කුබර්නෙටේස් හි ජාලයක් ලෙස Cilium ක්‍රියාත්මක කිරීමට උත්සාහ කළ යුතුද යන්න බැරෑරුම් ලෙස සලකා බැලුවෙමු.

Cilium යනු කුමක්දැයි මම පැහැදිලි කරමි. Kubernetes ජාල උප පද්ධතියේ විවිධ ක්‍රියාත්මක කිරීම් ඇති අතර ඒවායින් එකක් ඉතා සිසිල් ය - Cilium. එහි තේරුම කුමක්ද? කර්නලය තුළ, කලකට පෙර කර්නලය සඳහා කොකු ලිවීමට හැකි වූ අතර, එය එක් ආකාරයකින් හෝ වෙනත් ආකාරයකින් ජාල උප පද්ධතිය සහ වෙනත් විවිධ උප පද්ධති ආක්‍රමණය කරන අතර කර්නලයේ විශාල කැබලි මඟ හැරීමට ඔබට ඉඩ සලසයි.

Linux කර්නලය ඓතිහාසික වශයෙන් ip rout එකක්, overfilter එකක්, පාලම් සහ අවුරුදු 15, 20, 30 පැරණි විවිධ පැරණි සංරචක ඇත. පොදුවේ ගත් කල, ඔවුන් වැඩ කරයි, සෑම දෙයක්ම විශිෂ්ටයි, නමුත් දැන් ඔවුන් බහාලුම් ගොඩ ගසා ඇති අතර, එය එකිනෙකට ඉහලින් ගඩොල් 15 ක කුළුණක් මෙන් පෙනේ, ඔබ එය මත එක කකුලක් මත සිටගෙන - අමුතු හැඟීමක්. මෙම ක්‍රමය ශරීරයේ ඇති උපග්‍රන්ථය වැනි බොහෝ සූක්ෂ්මතා සහිතව ඓතිහාසිකව වර්ධනය වී ඇත. සමහර අවස්ථාවලදී, උදාහරණයක් ලෙස, කාර්ය සාධන ගැටළු තිබේ.

පුදුමාකාර BPF සහ කර්නලය සඳහා කොකු ලිවීමේ හැකියාව ඇත - යාලුවනේ කර්නලය සඳහා ඔවුන්ගේම කොකු ලිවීය. පැකේජය ලිනක්ස් කර්නලය තුළට පැමිණේ, ඔවුන් එය ආදානයේදීම පිටතට ගෙන, පාලම් නොමැතිව, TCP නොමැතිව, IP තොගයක් නොමැතිව - කෙටියෙන් කිවහොත්, ලිනක්ස් කර්නලයේ ලියා ඇති සියල්ල මඟ හැර, පසුව කෙළ ගසයි. එය කන්ටේනරය තුළට.

සිදුවුයේ කුමක් ද? ඉතා සිසිල් කාර්ය සාධනය, සිසිල් විශේෂාංග - හුදෙක් සිසිල්! නමුත් අපි මෙය දෙස බලන විට, සෑම යන්ත්‍රයකම Kubernetes API වෙත සම්බන්ධ වන වැඩසටහනක් ඇති අතර, මෙම API වෙතින් ලැබෙන දත්ත මත පදනම්ව, C කේතය ජනනය කර, මෙම කොකු ක්‍රියා කරන පරිදි එය කර්නලයට පැටවෙන ද්විමය සම්පාදනය කරයි. කර්නල් අවකාශයේ .

යමක් වැරදුනහොත් කුමක් සිදුවේද? අපි දන්නෙ නැහැ. මෙය තේරුම් ගැනීම සඳහා, ඔබ මෙම සියලු කේතය කියවිය යුතුය, සියලු තර්කනය තේරුම් ගත යුතු අතර, එය කොතරම් දුෂ්කරද යන්න පුදුම සහගතය. නමුත්, අනෙක් අතට, මෙම පාලම්, net filters, ip rout ඇත - මම ඔවුන්ගේ මූලාශ්‍ර කේතය කියවා නැත, අපගේ සමාගමේ සේවය කරන ඉංජිනේරුවන් 40 දෙනා ද නැත. සමහර කොටස් ටික දෙනෙක්ට විතරක් තේරෙනවා ඇති.

සහ වෙනස කුමක්ද? ip රවුට්, ලිනක්ස් කර්නලය සහ නව මෙවලමක් ඇති බව පෙනේ - එයින් සිදු වන වෙනස කුමක්ද, අපට එකක් හෝ අනෙකක් තේරෙන්නේ නැත. නමුත් අපි අලුත් දෙයක් භාවිතා කිරීමට බිය වෙමු - ඇයි? මක්නිසාද යත් මෙවලම අවුරුදු 30 ක් පැරණි නම්, වසර 30 කින් සියලුම දෝෂ සොයාගෙන ඇත, සියලු වැරදි මත පියවර ගෙන ඇති අතර ඔබ සියල්ල ගැන දැන ගැනීමට අවශ්‍ය නැත - එය කළු පෙට්ටියක් මෙන් ක්‍රියා කරන අතර සෑම විටම ක්‍රියා කරයි. කුමන ස්ථානයේ ඇලවිය යුතුද, කුමන මොහොතේ කුමන tcpdump ක්‍රියාත්මක විය යුතුද යන්න සියලු දෙනා දනිති. සෑම කෙනෙකුම රෝග විනිශ්චය උපයෝගිතා හොඳින් දන්නා අතර Linux කර්නලයේ මෙම සංරචක කට්ටලය ක්‍රියා කරන ආකාරය තේරුම් ගනී - එය ක්‍රියා කරන ආකාරය නොව එය භාවිතා කරන්නේ කෙසේද.

පුදුමාකාර සිසිල් Cilium වයස අවුරුදු 30 ක් නොවේ, එය තවමත් වයසට ගොස් නැත. Kubernetes එකම ගැටළුවක් ඇත, පිටපත් කරන්න. Cilium පරිපූර්ණව ස්ථාපනය කර ඇති බවත්, Kubernetes පරිපූර්ණව ස්ථාපනය කර ඇති බවත්, නමුත් නිෂ්පාදනයේදී යම් දෙයක් වැරදී ගිය විට, වැරදී ඇත්තේ කුමක්ද යන්න විවේචනාත්මක අවස්ථාවකදී ඔබට ඉක්මනින් තේරුම් ගත හැකිද?

කුබර්නෙටස් නඩත්තු කිරීම අපහසුදැයි අප පවසන විට - නැත, එය ඉතා පහසු ය, ඔව්, එය ඇදහිය නොහැකි තරම් දුෂ්කර ය. Kubernetes තනිවම විශිෂ්ට ලෙස ක්‍රියා කරයි, නමුත් බිලියනයක සූක්ෂ්මතාවයන් සමඟ.

"මම වාසනාවන්ත වනු ඇත" ප්රවේශය ගැන

- මෙම සූක්ෂ්මතාවයන් දිස්වනු ඇතැයි සහතික කර ඇති සමාගම් තිබේද? Yandex හදිසියේම සියලුම සේවාවන් Kubernetes වෙත මාරු කරයි යැයි සිතමු, එහි විශාල බරක් පවතිනු ඇත.

දිමිත්රි: නැත, මෙය පැටවීම පිළිබඳ සංවාදයක් නොව සරලම දේ ගැන ය. උදාහරණයක් ලෙස, අපට Kubernetes ඇත, අපි එහි යෙදුම යෙදෙව්වා. එය ක්‍රියාත්මක වන බව ඔබ දන්නේ කෙසේද? යෙදුම බිඳ වැටෙන්නේ නැති බව තේරුම් ගැනීමට සරලව සූදානම් කළ මෙවලමක් නොමැත. ඇඟවීම් යවන සූදානම් කළ පද්ධතියක් නොමැත; ඔබට මෙම ඇඟවීම් සහ එක් එක් කාලසටහන වින්‍යාසගත කළ යුතුය. අපි Kubernetes යාවත්කාලීන කරමින් සිටිමු.

මගේ තියෙන්නේ Ubuntu 16.04. මෙය පැරණි අනුවාදයක් බව ඔබට පැවසිය හැකිය, නමුත් එය LTS නිසා අපි තවමත් එහි සිටිමු. Systemd ඇත, එහි සූක්ෂ්මතාවය නම් එය C කණ්ඩායම් පිරිසිදු නොකිරීමයි. Kubernetes කරල් දියත් කරයි, C-කණ්ඩායම් නිර්මාණය කරයි, පසුව කරල් මකා දමයි, කෙසේ හෝ එය සිදු වේ - මට විස්තර මතක නැත, සමාවන්න - systemd පෙති ඉතිරිව පවතී. මෙය කාලයත් සමඟ ඕනෑම මෝටර් රථයක් දැඩි ලෙස මන්දගාමී වීමට පටන් ගනී. මේක හයිලෝඩ් ගැන ප්‍රශ්නයක්වත් නෙවෙයි. ස්ථිර කරල් දියත් කරන්නේ නම්, උදාහරණයක් ලෙස, නිරන්තරයෙන් කරල් ජනනය කරන ක්‍රෝන් ජොබ් තිබේ නම්, උබුන්ටු 16.04 සහිත යන්ත්‍රය සතියකට පසු මන්දගාමී වීමට පටන් ගනී. C-කණ්ඩායම් සමූහයක් නිර්මාණය කර ඇති නිසා නිරන්තරයෙන් ඉහළ බර පැටවීමේ සාමාන්යයක් පවතිනු ඇත. Ubuntu 16 සහ Kubernetes ඉහලින් සරලව ස්ථාපනය කරන ඕනෑම අයෙකු මුහුණ දෙන ගැටලුව මෙයයි.

ඔහු කෙසේ හෝ systemd හෝ වෙනත් දෙයක් යාවත්කාලීන කරන බව කියමු, නමුත් Linux කර්නලයේ 4.16 දක්වා එය වඩාත් විනෝදජනකයි - ඔබ C-කණ්ඩායම් මකා දැමූ විට, ඒවා කර්නලය තුළ කාන්දු වන අතර ඇත්ත වශයෙන්ම මකා නොදමනු ලැබේ. එමනිසා, මෙම යන්ත්රයේ වැඩ කිරීමෙන් මාසයකට පසු, උදුන සඳහා මතක සංඛ්යා ලේඛන බැලීමට නොහැකි වනු ඇත. අපි ගොනුවක් එළියට ගෙන, එය වැඩසටහනට පෙරළන්න, සහ එක් ගොනුවක් තත්පර 15 ක් පෙරළේ, මන්ද කර්නලය තමා තුළම C-කණ්ඩායම් මිලියනයක් ගණන් කිරීමට ඉතා දිගු කාලයක් ගත වන අතර එය මකා දැමූ බවක් පෙනේ, නමුත් නැත - ඒවා කාන්දු වේ. .

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

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

මගේ දෘෂ්ටි කෝණයෙන්, ඕනෑම පද්ධතියක් ක්‍රියාත්මක කිරීමේ සූක්ෂ්මතාවය සහ සංකීර්ණත්වය වන්නේ අපගේ ගැටළු විසඳීමට අයිස්වල thickness ණකම හරියටම ප්‍රමාණවත් බව සහතික කිරීමයි. මේක තමයි අපි කතා කරන්නේ.

තොරතුරු තාක්ෂණයේ, මට පෙනෙන පරිදි, "මම වාසනාවන්ත වනු ඇත" ප්‍රවේශයන් ඕනෑවට වඩා තිබේ. බොහෝ අය මෘදුකාංග ස්ථාපනය කර මෘදුකාංග පුස්තකාල භාවිතා කරන්නේ තමන්ට වාසනාව ලැබේ යැයි අපේක්ෂාවෙනි. පොදුවේ ගත් කල, බොහෝ මිනිසුන් වාසනාවන්තයි. එය ක්‍රියාත්මක වන්නේ එබැවිනි.

- මගේ අශුභවාදී තක්සේරුව අනුව, එය පෙනෙන්නේ මෙයයි: අවදානම් වැඩි වන විට සහ යෙදුම ක්‍රියාත්මක විය යුතු විට, Flaunt වෙතින්, සමහර විට Red Hat වෙතින් සහය අවශ්‍ය වේ, නැතහොත් ඔබට කුබර්නෙටස් සඳහා විශේෂයෙන් කැප වූ ඔබේම අභ්‍යන්තර කණ්ඩායමක් අවශ්‍ය වේ. එය ඇද ගැනීමට.

දිමිත්රි: වෛෂයිකව, මෙය එසේ ය. ඔබ විසින්ම කුඩා කණ්ඩායමක් සඳහා Kubernetes කතාවට පිවිසීම අවදානම් ගණනාවක් ඇතුළත් වේ.

අපට බහාලුම් අවශ්යද?

- කුබර්නෙටස් රුසියාවේ කොතරම් පැතිරී ඇත්දැයි ඔබට කියන්න පුළුවන්ද?

දිමිත්රි: මා සතුව මෙම දත්ත නොමැති අතර, වෙනත් කිසිවෙකුට එය ඇති බව මට විශ්වාස නැත. අපි කියනවා: "කුබර්නෙටස්, කුබර්නෙට්ස්", නමුත් මෙම ගැටලුව දෙස බැලීමට තවත් ක්රමයක් තිබේ. බහාලුම් කෙතරම් පුළුල් ලෙස පැතිරී ඇත්දැයි මම නොදනිමි, නමුත් බහාලුම්වලින් 70% ක් කුබර්නෙටස් විසින් සංවිධානය කරන ලද බවට අන්තර්ජාලයේ වාර්තා වලින් සංඛ්‍යාවක් මම දනිමි. එය ලොව පුරා තරමක් විශාල සාම්පලයක් සඳහා විශ්වසනීය මූලාශ්රයක් විය.

එවිට තවත් ප්රශ්නයක් - අපට බහාලුම් අවශ්යද? මගේ පුද්ගලික හැඟීම සහ Flant සමාගමේ සමස්ත ස්ථාවරය නම් Kubernetes යනු තථ්‍ය ප්‍රමිතියකි.

කුබර්නෙට්ස් හැර අන් කිසිවක් නොවනු ඇත.

මෙය යටිතල පහසුකම් කළමනාකරණ ක්ෂේත්‍රයේ නිරපේක්ෂ ක්‍රීඩාව වෙනස් කරන්නකි. නිරපේක්ෂ - එපමණයි, තවදුරටත් Ansible, Chef, virtual machines, Terraform නැත. මම කතා කරන්නේ පැරණි සාමූහික ගොවිපල ක්‍රම ගැන නොවේ. Kubernetes යනු නිරපේක්ෂ වෙනස් කරන්නකි, සහ දැන් එය මේ වගේ වනු ඇත.

සමහරුන්ට මෙය අවබෝධ කර ගැනීමට වසර කිහිපයක් ගත වන අතර තවත් සමහරුන්ට දශක කිහිපයක් ගත වන බව පැහැදිලිය. Kubernetes සහ මෙම නව පෙනුම හැර අන් කිසිවක් නොමැති බවට මට සැකයක් නැත: අපි තවදුරටත් මෙහෙයුම් පද්ධතියට හානි නොකර භාවිතා කරන්නෙමු. කේතය ලෙස යටිතල පහසුකම්, කේතය සමඟ පමණක් නොව, yml සමඟ - ප්රකාශිත ලෙස විස්තර කරන ලද යටිතල පහසුකම්. හැමදාමත් මෙහෙම වෙයි කියලා හිතට දැනෙනවා.

- එනම්, තවමත් Kubernetes වෙත මාරු වී නොමැති එම සමාගම් අනිවාර්යයෙන්ම එයට මාරු වනු ඇත හෝ අමතකව පවතිනු ඇත. මම ඔබව නිවැරදිව තේරුම් ගත්තාද?

දිමිත්රි: මෙයද සම්පූර්ණයෙන්ම සත්‍ය නොවේ. උදාහරණයක් ලෙස, අපට DNS සේවාදායකයක් ක්‍රියාත්මක කිරීමේ කාර්යය තිබේ නම්, එය FreeBSD 4.10 මත ධාවනය කළ හැකි අතර එය වසර 20 ක් පරිපූර්ණව ක්‍රියා කළ හැකිය. නිකන් වැඩ කරන්න, එච්චරයි. සමහර විට වසර 20 කින් යමක් එක් වරක් යාවත්කාලීන කිරීමට අවශ්ය වනු ඇත. අපි දියත් කළ ආකෘතියෙන් මෘදුකාංග ගැන කතා කරන්නේ නම් සහ එය ඇත්ත වශයෙන්ම වසර ගණනාවක් කිසිදු යාවත්කාලීනයකින් තොරව, වෙනස්කම් නොමැතිව ක්‍රියා කරයි නම්, ඇත්ත වශයෙන්ම, කුබර්නෙට්ස් නොමැත. ඔහු එහි අවශ්ය නොවේ.

CI/CD හා සම්බන්ධ සෑම දෙයක්ම - අඛණ්ඩ බෙදා හැරීම අවශ්‍ය ඕනෑම තැනක, ඔබට අනුවාද යාවත්කාලීන කිරීමට, ක්‍රියාකාරී වෙනස්කම් කිරීමට, ඔබට දෝෂ ඉවසීම ගොඩනගා ගැනීමට අවශ්‍ය ඕනෑම තැනක - Kubernetes පමණි.

ක්ෂුද්ර සේවා ගැන

- මෙන්න මට පොඩි විසංවාදයක් තියෙනවා. Kubernetes සමඟ වැඩ කිරීමට, ඔබට බාහිර හෝ අභ්යන්තර සහාය අවශ්ය වේ - මෙය පළමු කරුණයි. දෙවනුව, අපි සංවර්ධනය ආරම්භ කරන විට, අපි කුඩා ආරම්භයක්, අපට තවමත් කිසිවක් නැත, සාමාන්යයෙන් Kubernetes හෝ microservice ගෘහ නිර්මාණ ශිල්පය සඳහා සංවර්ධනය දුෂ්කර විය හැකි අතර සෑම විටම ආර්ථික වශයෙන් යුක්ති සහගත නොවේ. මම ඔබේ මතය ගැන උනන්දු වෙමි - ආරම්භකයින් වහාම Kubernetes සඳහා මුල සිටම ලිවීම ආරම්භ කළ යුතුද, නැතහොත් ඔවුන්ට තවමත් ඒකලිතයක් ලිවිය හැකිද, පසුව පමණක් Kubernetes වෙත පැමිණිය හැකිද?

දිමිත්රි: නියම ප්රශ්නය. මට microservices ගැන කතාවක් තියෙනවා "ක්ෂුද්‍ර සේවා: ප්‍රමාණය වැදගත් වේ." අන්වීක්ෂයකින් ඇණ ගැසීමට උත්සාහ කරන අය බොහෝ විට මට හමු වී ඇත. ප්‍රවේශය ම නිවැරදි ය; අප විසින්ම අපගේ අභ්‍යන්තර මෘදුකාංගය මේ ආකාරයෙන් නිර්මාණය කරමු. නමුත් ඔබ මෙය කරන විට, ඔබ කරන්නේ කුමක්ද යන්න පැහැදිලිව තේරුම් ගත යුතුය. ක්ෂුද්‍ර සේවා ගැන මම වඩාත්ම පිළිකුල් කරන වචනය “මයික්‍රෝ” යන්නයි. ඓතිහාසික වශයෙන්, මෙම වචනය එහි ආරම්භ වූ අතර, යම් හේතුවක් නිසා මිනිසුන් සිතන්නේ මයික්‍රෝ ඉතා කුඩා, මයික්‍රොමීටරයක් ​​වැනි මිලිමීටරයකට වඩා අඩු බවයි. මේක වැරදියි.

උදාහරණයක් ලෙස, 300 දෙනෙකු විසින් ලියන ලද ඒකලිතයක් ඇති අතර, සංවර්ධනයට සහභාගී වූ සෑම කෙනෙකුම එහි ගැටළු ඇති බව වටහාගෙන ඇති අතර, එය ක්ෂුද්‍ර කෑලි වලට කැඩී යා යුතුය - කෑලි 10 ක් පමණ, එක් එක් පුද්ගලයින් 30 දෙනෙකු විසින් ලියා ඇත. අවම අනුවාදයකින්. මෙය වැදගත්, අවශ්ය සහ සිසිල්. නමුත් ආරම්භයක් අප වෙත පැමිණෙන විට, ඉතා සිසිල් සහ දක්ෂ පිරිමි ළමයින් 3 දෙනෙකු ඔවුන්ගේ දණහිස මත මයික්‍රොසර්විස් 60 ක් ලිවූ විට, මම Corvalol සොයන සෑම අවස්ථාවකම.

මෙය දැනටමත් දහස් වාරයක් කතා කර ඇති බව මට පෙනේ - අපට එක් ආකාරයකින් හෝ වෙනත් ආකාරයකින් බෙදා හරින ලද මොනොලිත් ලැබුණි. මෙය ආර්ථික වශයෙන් යුක්ති සහගත නොවේ, සෑම දෙයකම පොදුවේ ඉතා අපහසු වේ. මම මෙය බොහෝ වාරයක් දැක ඇති අතර එය මට ඇත්තටම රිදවන බැවින් මම ඒ ගැන දිගටම කතා කරමි.

ආරම්භක ප්‍රශ්නයට, එක් අතකින්, කුබර්නෙට්ස් භාවිතා කිරීමට බියජනක බව අතර ගැටුමක් ඇත, මන්ද එහි කැඩී යා හැකි හෝ ක්‍රියා නොකරන්නේ කුමක් දැයි පැහැදිලි නැති නිසා, අනෙක් අතට, සියල්ල එහි යන බව පැහැදිලිය. කුබර්නෙට්ස් හැර වෙන කිසිවක් නොපවතියි. පිළිතුර - ලැබෙන ප්‍රතිලාභ ප්‍රමාණය, ඔබට විසඳිය හැකි කාර්යයන් ප්‍රමාණය කිරා මැන බලන්න. මෙය පරිමාණයේ එක් පැත්තකි. අනෙක් අතට, ක්‍රියා විරහිත වීම හෝ ප්‍රතිචාර කාලය අඩුවීම, ලබා ගැනීමේ මට්ටම - කාර්ය සාධන දර්ශකවල අඩුවීමක් සමඟ සම්බන්ධ අවදානම් ඇත.

මෙන්න එයයි - එක්කෝ අපි ඉක්මනින් ගමන් කරමු, සහ Kubernetes අපට බොහෝ දේ වඩා වේගවත් හා වඩා හොඳ කිරීමට ඉඩ සලසයි, නැතහොත් අපි විශ්වාසදායක, කාලය පරීක්ෂා කළ විසඳුම් භාවිතා කරමු, නමුත් වඩා සෙමින් ගමන් කරමු. මෙය සෑම සමාගමක්ම කළ යුතු තේරීමකි. ඔබට එය කැලයේ මාර්ගයක් ලෙස සිතිය හැකිය - ඔබ පළමු වරට ඇවිදින විට, ඔබට සර්පයෙකු, කොටියෙකු හෝ පිස්සු බැජර් හමුවිය හැකිය, ඔබ 10 වතාවක් ඇවිද ගිය විට, ඔබ ඉවත් කර ඇති මාර්ගය පාගා ඇත. අතු සහ ඇවිදීම පහසුය. සෑම අවස්ථාවකදීම මාර්ගය පුළුල් වේ. එවිට එය ඇස්ෆල්ට් මාර්ගයක් වන අතර පසුව එය අලංකාර බෝල්වාර්ඩ් වේ.

කුබර්නෙටස් නිශ්චලව සිටින්නේ නැත. නැවතත් ප්‍රශ්නය: Kubernetes, එක් අතකින්, ද්විමය 4-5 ක් වන අතර, අනෙක් අතට, එය සමස්ත පරිසර පද්ධතියයි. මෙය අපගේ යන්ත්‍රවල ඇති මෙහෙයුම් පද්ධතියයි. මේ කුමක් ද? Ubuntu හෝ Curios? මෙය ලිනක්ස් කර්නලය, අතිරේක සංරචක සමූහයකි. මෙන්න මේ හැම දෙයක්ම, එක විසකුරු සර්පයෙක් පාරෙන් එළියට දැම්මා, එතන වැටක් ගැහුවා. Kubernetes ඉතා ඉක්මනින් හා ගතිකව සංවර්ධනය වෙමින් පවතින අතර, අවදානම් පරිමාව, නොදන්නා පරිමාව සෑම මසකම අඩු වන අතර, ඒ අනුව, මෙම පරිමාණයන් නැවත සමතුලිත වේ.

ආරම්භකයක් කළ යුත්තේ කුමක්ද යන ප්‍රශ්නයට පිළිතුරු දෙමින්, මම කියන්නේ - Flaunt වෙත පැමිණ, රූබල් 150 ක් ගෙවා පිරිවැටුම DevOps පහසු සේවාවක් ලබා ගන්න. ඔබ සංවර්ධකයින් කිහිප දෙනෙකු සමඟ කුඩා ආරම්භයක් නම්, මෙය ක්‍රියාත්මක වේ. ඔබේම DevOps කුලියට ගැනීම වෙනුවට, ඔබේ ගැටලු විසඳා ගැනීමට සහ මෙම අවස්ථාවේදී වැටුප් ගෙවීමට ඉගෙන ගැනීමට අවශ්‍ය වනු ඇත, ඔබට සියලු ගැටලු සඳහා හැරවුම් යතුරක් ලැබෙනු ඇත. ඔව්, යම් අවාසි ඇත. අපට, බාහිරින් ලබා ගන්නෙකු ලෙස, එසේ සම්බන්ධ වී වෙනස්කම් වලට ඉක්මන් ප්‍රතිචාර දැක්විය නොහැක. නමුත් අපට බොහෝ විශේෂඥ දැනුම සහ සූදානම් කළ භාවිතයන් තිබේ. ඕනෑම තත්වයකදී අපි එය ඉක්මනින් හඳුනාගෙන ඕනෑම කුබර්නෙට්වරුන් මළවුන්ගෙන් නැගිටුවන බවට අපි සහතික වෙමු.

10 දෙනෙකුගෙන් යුත් කණ්ඩායමක් මෙහෙයුම් සඳහා කැප කළ හැකි ප්‍රමාණය දක්වා ආරම්භක සහ ස්ථාපිත ව්‍යාපාර සඳහා බාහිරින් ලබා ගැනීම මම තරයේ නිර්දේශ කරමි, එසේ නොමැති නම් කිසිදු තේරුමක් නැත. මෙය බාහිරින් ලබා දීම අනිවාර්යයෙන්ම අර්ථවත් කරයි.

Amazon සහ Google ගැන

— Amazon හෝ Google වෙතින් විසඳුමකින් සත්කාරක සමාගමක් බාහිරින් ලබා ගැනීමක් ලෙස සැලකිය හැකිද?

දිමිත්රි: ඔව්, ඇත්ත වශයෙන්ම, මෙය ගැටළු ගණනාවක් විසඳයි. නමුත් නැවතත් සූක්ෂ්මතා තිබේ. එය භාවිතා කරන්නේ කෙසේදැයි ඔබ තවමත් තේරුම් ගත යුතුය. උදාහරණයක් ලෙස, Amazon AWS හි කාර්යයේ කුඩා දේවල් දහසක් ඇත: ලෝඩ් බැලන්සර් උණුසුම් කළ යුතුය, නැතහොත් “යාලුවනේ, අපට ගමනාගමනය ලැබෙනු ඇත, අප වෙනුවෙන් ලෝඩ් බැලන්සරය උණුසුම් කරන්න!” යනුවෙන් ඉල්ලීමක් කල්තියා ලිවිය යුතුය. ඔබ මෙම සූක්ෂ්ම කරුණු දැන සිටිය යුතුය.

ඔබ මේ සඳහා විශේෂඥයින් වෙත හැරෙන විට, ඔබට සාමාන්ය දේවල් සියල්ලම පාහේ වසා ඇත. අපට දැන් ඉංජිනේරුවන් 40 ක් ඇත, වසර අවසන් වන විට බොහෝ විට 60 ක් සිටිනු ඇත - අපි අනිවාර්යයෙන්ම මේ සියල්ලට මුහුණ දී ඇත. කිසියම් ව්‍යාපෘතියකදී අපට මෙම ගැටලුව නැවත හමු වුවද, අපි ඉක්මනින් එකිනෙකාගෙන් විමසා එය විසඳන්නේ කෙසේදැයි දනිමු.

බොහෝ විට පිළිතුර විය හැකිය - ඇත්ත වශයෙන්ම, සත්කාරක කථාවක් යම් කොටසක් පහසු කරයි. ප්රශ්නය වන්නේ ඔබ මෙම සත්කාරකයින් විශ්වාස කිරීමට සූදානම්ද යන්න සහ ඔවුන් ඔබේ ගැටළු විසඳයිද යන්නයි. Amazon සහ Google හොදින් කරලා තියෙනවා. අපගේ සියලුම නඩු සඳහා - හරියටම. අපට තවත් ධනාත්මක අත්දැකීම් නොමැත. අප සමඟ වැඩ කිරීමට උත්සාහ කළ අනෙකුත් සියලුම වලාකුළු ගැටළු රාශියක් නිර්මාණය කරයි - Ager, සහ රුසියාවේ ඇති සෑම දෙයක්ම සහ විවිධ ක්‍රියාත්මක කිරීම් වල ඇති සියලුම OpenStack: Headster, Overage - ඔබට අවශ්‍ය ඕනෑම දෙයක්. ඒවා සියල්ලම ඔබට විසඳා ගැනීමට අවශ්‍ය නැති ප්‍රශ්න ඇති කරයි.

එමනිසා, පිළිතුර ඔව්, නමුත්, ඇත්ත වශයෙන්ම, බොහෝ පරිණත සත්කාරක විසඳුම් නොමැත.

කුබර්නෙට්ස් අවශ්‍ය කාටද?

- එසේ වුවද, කුබර්නෙට්ස් අවශ්‍ය කාටද? දැනටමත් Kubernetes වෙත මාරු විය යුත්තේ කවුද, විශේෂයෙන්ම Kubernetes සඳහා පැමිණෙන සාමාන්‍ය Flaunt සේවාදායකයා කවුද?

දිමිත්රි: මෙය සිත්ගන්නා ප්‍රශ්නයකි, මන්ද මේ වන විට, කුබර්නෙටස් අවදියේදී, බොහෝ අය අප වෙත පැමිණේ: "යාලුවනේ, ඔබ කුබර්නෙට්ස් කරන බව අපි දනිමු, එය අප වෙනුවෙන් කරන්න!" අපි ඔවුන්ට පිළිතුරු දෙමු: "මහත්වරුනි, අපි කුබර්නෙට්ස් කරන්නේ නැහැ, අපි ප්‍රොඩ් සහ ඒ හා සම්බන්ධ සෑම දෙයක්ම කරන්නෙමු." CI/CD සහ මේ මුළු කතාවම නොකර නිෂ්පාදනයක් කිරීමට දැනට නොහැකි නිසා. අපි සංවර්ධනයෙන් සංවර්ධනය, සූරාකෑමෙන් සූරාකෑම යන බෙදීම්වලින් හැමෝම ඈත්වෙලා.

අපගේ ගනුදෙනුකරුවන් විවිධ දේ අපේක්ෂා කරයි, නමුත් සෑම කෙනෙකුම ඔවුන්ට යම් යම් ගැටළු ඇති බව හොඳ ආශ්චර්යයක් බලාපොරොත්තුවෙන් සිටින අතර, දැන් - hop! - Kubernetes ඒවා විසඳයි. මිනිසුන් ආශ්චර්යයන් විශ්වාස කරයි. ප්‍රාතිහාර්යයක් සිදු නොවන බව ඔවුන්ගේ මනසින් ඔවුන් තේරුම් ගනී, නමුත් ඔවුන්ගේ ආත්මය තුළ ඔවුන් බලාපොරොත්තු වේ - මේ කුබර්නෙට් දැන් අපට සියල්ල විසඳන්නේ නම්, ඔවුන් ඒ ගැන බොහෝ දේ කතා කරයි! හදිසියේම ඔහු දැන් - කිවිසුම් යන්න! - සහ රිදී උණ්ඩයක්, කිවිසුම්! - සහ අපට 100% ක්‍රියාකාරී කාලයක් ඇත, සියලුම සංවර්ධකයින්ට නිෂ්පාදනයට ලැබෙන ඕනෑම දෙයක් 50 වතාවක් මුදා හැරිය හැකි අතර එය බිඳ වැටෙන්නේ නැත. පොදුවේ, ආශ්චර්යයක්!

එවැනි අය අප වෙත පැමිණෙන විට, අපි මෙසේ කියමු: "කණගාටුයි, නමුත් ආශ්චර්යයක් කියා දෙයක් නැත." නිරෝගීව සිටීමට නම්, ඔබ හොඳින් ආහාර ගැනීම සහ ව්යායාම කළ යුතුය. විශ්වසනීය නිෂ්පාදනයක් ලබා ගැනීම සඳහා, එය විශ්වාසදායක ලෙස සෑදිය යුතුය. පහසු CI/CD එකක් තියෙන්න නම් මේ විදියට හදාගන්න ඕන. ඒ වැඩ ගොඩක් කරන්න ඕන.

කුබර්නෙට් අවශ්‍ය කාටද යන ප්‍රශ්නයට පිළිතුරු දෙමින් - කිසිවෙකුට කුබර්නෙට් අවශ්‍ය නැත.

සමහරුන්ට Kubernetes අවශ්‍ය බවට වැරදි මතයක් ඇත. මිනිසුන්ට අවශ්‍ය වන්නේ, යටිතල පහසුකම් පිළිබඳ සියලු ගැටලු සහ ඔවුන්ගේ යෙදුම් ක්‍රියාත්මක කිරීමේ ගැටළු ගැන සිතීම, අධ්‍යයනය කිරීම සහ උනන්දු වීම නැවැත්වීමට ඔවුන්ට ගැඹුරු අවශ්‍යතාවයක් ඇත. ඔවුන්ට අවශ්‍ය වන්නේ යෙදුම් ක්‍රියා කිරීමට සහ යෙදවීමට පමණි. ඔවුන් සඳහා, කුබර්නෙටස් යනු "අපි එහි වැතිර සිටියෙමු" හෝ "අපට පෙරළිය නොහැක" හෝ වෙනත් යමක් ඇසීම නවත්වනු ඇතැයි යන බලාපොරොත්තුවයි.

තාක්ෂණික අධ්‍යක්ෂවරයා සාමාන්‍යයෙන් අප වෙත පැමිණේ. ඔවුන් ඔහුගෙන් කරුණු දෙකක් අසයි: එක් අතකින්, අපට විශේෂාංග ලබා දෙන්න, අනෙක් අතට, ස්ථාවරත්වය. අපි ඔබට යෝජනා කරන්නේ එය ඔබම භාරගෙන එය කරන්න. රිදී උණ්ඩය, හෝ ඒ වෙනුවට රිදී ආලේපිත, ඔබ මෙම ගැටළු ගැන සිතීම සහ කාලය නාස්ති කිරීම නවත්වනු ඇත. ඔබට මෙම ගැටලුව වසා දමන විශේෂ පුද්ගලයන් සිටිනු ඇත.

අපට හෝ වෙනත් අයෙකුට කුබර්නෙටස් අවශ්‍යයි යන වචන වැරදිය.

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

නිෂ්පාදනය සමඟ සෙල්ලම් කිරීමට අවශ්ය නැත. මම තරයේ නිර්දේශ කරන ඕනෑම දෙයක් කරන්න එපා සහ මම දැන් සමූහ වශයෙන් දකින දේ: "අනේ, අලුත් සෙල්ලම් බඩුවක්!" - ඔවුන් එය මිලදී ගැනීමට දිව ගොස්, එය මිලදී ගෙන: "අපි එය දැන් පාසලට ගෙන ගොස් අපගේ සියලු මිතුරන්ට පෙන්වමු." මේක කරන්න එපා. මම සමාව ඉල්ලමි, මගේ දරුවන් වැඩෙමින් පවතී, මම නිරන්තරයෙන් දරුවන් තුළ යමක් දකිමි, එය මා තුළ දකිමි, පසුව එය අන් අයට සාමාන්‍යකරණය කරයි.

අවසාන පිළිතුර නම්: ඔබට කුබර්නෙට්ස් අවශ්‍ය නොවේ. ඔබ ඔබේ ගැටළු විසඳා ගත යුතුය.

ඔබට සාක්ෂාත් කරගත හැක්කේ:

  • prod වැටෙන්නේ නැත;
  • ඔහු වැටීමට උත්සාහ කළත්, අපි ඒ ගැන කල්තියා දන්නා අතර අපට එය තුළ යමක් තැබිය හැකිය;
  • අපට එය අපගේ ව්‍යාපාරයට අවශ්‍ය වන වේගයෙන් වෙනස් කළ හැකි අතර අපට එය පහසුවෙන් කළ හැකිය; එය අපට කිසිදු ගැටළුවක් ඇති නොකරයි.

සැබෑ අවශ්‍යතා දෙකක් තිබේ: විශ්වසනීයත්වය සහ ගතිකත්වය / පෙරළීමේ නම්‍යශීලී බව. දැනට යම් ආකාරයක තොරතුරු තාක්ෂණ ව්‍යාපෘති කරන සෑම කෙනෙකුම, කුමන ආකාරයේ ව්‍යාපාරයක වුවද - ලෝකය ලිහිල් කිරීමට මෘදු, සහ මෙය තේරුම් ගන්නා සෑම කෙනෙකුටම මෙම අවශ්‍යතා විසඳා ගත යුතුය. Kubernetes නිවැරදි ප්‍රවේශය, නිවැරදි අවබෝධය සහ ප්‍රමාණවත් අත්දැකීම් ඇති ඔබට ඒවා විසඳීමට ඉඩ සලසයි.

serverless ගැන

- ඔබ අනාගතය දෙස මඳක් ඉදිරියට බැලුවහොත්, යටිතල පහසුකම් සමඟ හිසරදය නොමැතිකම පිළිබඳ ගැටළුව විසඳීමට උත්සාහ කිරීම, පෙරළීමේ වේගය සහ යෙදුම් වෙනස් වීමේ වේගය සමඟ, නව විසඳුම් දිස්වේ, උදාහරණයක් ලෙස, සේවාදායකය රහිත. මෙම දිශාවට ඔබට කිසියම් විභවයක් දැනෙනවාද සහ, අපි කියමු, Kubernetes සහ ඒ හා සමාන විසඳුම් සඳහා අනතුරක්?

දිමිත්රි: මෙන්න අපි නැවත වරක් ප්‍රකාශයක් කළ යුතුයි මම ඉදිරිය බලාගෙන - එය එසේ වනු ඇත! මම එකම දේ කළත්. මම මගේ පාද දෙස බලන අතර එහි ගැටලු රාශියක් දකිමි, උදාහරණයක් ලෙස, පරිගණකයක ට්‍රාන්සිස්ටර ක්‍රියා කරන ආකාරය. ඒක විහිලුවක් නේද? අපට CPU හි දෝෂ කිහිපයක් හමු වේ.

සර්වර්ලස් තරමක් විශ්වාසදායක, ලාභ, කාර්යක්ෂම සහ පහසු කරන්න, සියලු පරිසර පද්ධති ගැටළු විසඳන්න. මනුෂ්‍යත්වයට වැරදි ඉවසීමේ හැකියාවක් ඇති කිරීමට දෙවන ග්‍රහලෝකයක් අවශ්‍ය බව මම එලොන් මස්ක් සමඟ එකඟ වෙමි. ඔහු පවසන්නේ කුමක්දැයි මම නොදන්නවා වුවද, මම අඟහරු වෙත පියාසර කිරීමට සූදානම් නැති බවත් එය හෙට සිදු නොවන බවත් මට වැටහෙනවා.

සර්වර්ලස් සමඟ, මෙය මනුෂ්‍යත්වයට වැරදි ඉවසීම වැනි දෘෂ්ටිවාදීමය වශයෙන් නිවැරදි දෙයක් බව පැහැදිලිය - ග්‍රහලෝක දෙකක් තිබීම එකකට වඩා හොඳය. නමුත් දැන් එය කරන්නේ කෙසේද? ඔබ ඔබේ උත්සාහය ඒ වෙත යොමු කරන්නේ නම් එක් ගවේෂණයක් යැවීම ගැටලුවක් නොවේ. ගවේෂණ කිහිපයක් යැවීම සහ දහස් ගණනක් මිනිසුන් එහි පදිංචි කිරීම ද යථාර්ථවාදී යැයි මම සිතමි. නමුත් මනුෂ්‍ය වර්ගයාගෙන් අඩක් එහි ජීවත් වන පරිදි එය සම්පූර්ණයෙන්ම වැරදි-ඉවසන බවට පත් කිරීම, එය දැන් මට නොසැලකිය නොහැකි බව පෙනේ.

සර්වර් රහිත එකක් සමඟ: දෙය සිසිල් ය, නමුත් එය 2019 ගැටළු වලින් බොහෝ දුරස් ය. 2030 ට ආසන්නයි - අපි එය දැකීමට ජීවත් වෙමු. අපි ජීවත් වන බවට මට සැකයක් නැත, අපි නියත වශයෙන්ම ජීවත් වනු ඇත (නින්දට යාමට පෙර නැවත නැවත කරන්න), නමුත් දැන් අපි වෙනත් ගැටළු විසඳා ගත යුතුය. හරියට සුරංගනා කතා පෝනියා දේදුනු විශ්වාස කරනවා වගේ. ඔව්, නඩු වලින් සියයට යුගලයක් විසඳා ඇති අතර, ඒවා පරිපූර්ණ ලෙස විසඳනු ලැබේ, නමුත් ආත්මීය වශයෙන්, සර්වර්ලස් දේදුන්නකි ... මට නම්, මෙම මාතෘකාව ඉතා දුරස්ථ හා තේරුම්ගත නොහැකි ය. මම කතා කරන්න සූදානම් නැහැ. 2019 දී, ඔබට සේවාදායක රහිත එක යෙදුමක් ලිවිය නොහැක.

Kubernetes පරිණාමය වන ආකාරය

— අප මෙම විශ්මයජනක දුරස්ථ අනාගතය කරා ගමන් කරන විට, Kubernetes සහ එය වටා ඇති පරිසර පද්ධතිය වර්ධනය වනු ඇතැයි ඔබ සිතන්නේ කෙසේද?

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

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

නොදන්නා මට්ටම, නොවිසඳුණු ගැටළු මට්ටම, යමක් හමුවීමේ සම්භාවිතාවේ මට්ටම සැලකිය යුතු ලෙස පහත වැටෙනු ඇත. මේක වැදගත් කතාවක්. සහ ක්‍රියාකරුවන් - පහසු සේවාවක් ලබා ගැනීම සඳහා පරිපාලන තර්කනය, පාලනය තාර්කික සංග්‍රහයට සම්බන්ධ සෑම දෙයක්ම: MySQL පහසු සේවාව, RabbitMQ පහසු සේවාව, Memcache පහසු සේවාව - පොදුවේ ගත් කල, මෙම සියලු සංරචක අපට වැඩ කිරීමට සහතික විය යුතුය. පෙට්ටිය. මෙය අපට දත්ත සමුදායක් අවශ්‍ය වන වේදනාව විසඳයි, නමුත් අපට එය පරිපාලනය කිරීමට අවශ්‍ය නැත, නැතහොත් අපට කුබර්නෙටස් අවශ්‍ය නමුත් අපට එය පරිපාලනය කිරීමට අවශ්‍ය නැත.

එක් ආකාරයකින් හෝ වෙනත් ආකාරයකින් ක්‍රියාකරු සංවර්ධනය පිළිබඳ මෙම කතාව ඉදිරි වසර දෙක තුළ වැදගත් වනු ඇත.

මම හිතන්නේ භාවිතයේ පහසුව විශාල ලෙස වැඩි විය යුතුයි - පෙට්ටිය වඩ වඩාත් කළු, වඩ වඩාත් විශ්වාසදායක, වැඩි වැඩියෙන් සරල බොත්තම් සමඟ.

මම වරක් යූ ටියුබ් හි 80 දශකයේ අයිසැක් අසිමොව් සමඟ පැරණි සම්මුඛ සාකච්ඡාවකට සවන් දුන්නෙමි - Urgant වැනි වැඩසටහනක්, රසවත් පමණි. ඔවුන් ඔහුගෙන් පරිගණකවල අනාගතය ගැන විමසුවා. ගුවන්විදුලිය වගේම අනාගතයත් සරල බව ඔහු කීවේය. රේඩියෝ ග්‍රාහකය මුලින් සංකීර්ණ දෙයක් විය. තරංගයක් අල්ලා ගැනීම සඳහා, ඔබ විනාඩි 15 ක් සඳහා බොත්තම් හැරවීමට, skewers හැරවීමට සහ සාමාන්යයෙන් සියල්ල ක්රියා කරන ආකාරය දැන ගැනීමට, ගුවන්විදුලි තරංග සම්ප්රේෂණයේ භෞතික විද්යාව තේරුම් ගැනීමට සිදු විය. එහි ප්‍රතිඵලයක් ලෙස ගුවන් විදුලියේ ඉතිරිව තිබුණේ එක බොත්තමක් පමණි.

දැන් 2019 දී මොන රේඩියෝවද? මෝටර් රථය තුළ, රේඩියෝ ග්රාහකයා සියලු තරංග සහ ස්ථාන වල නම් සොයා ගනී. ක්රියාවලියේ භෞතික විද්යාව වසර 100 ක් තුළ වෙනස් වී නැත, නමුත් භාවිතයේ පහසුව ඇත. දැන්, දැන් පමණක් නොව, දැනටමත් 1980 දී, අසිමොව් සමඟ සම්මුඛ සාකච්ඡාවක් පැවති විට, සෑම කෙනෙකුම ගුවන් විදුලිය භාවිතා කළ අතර එය ක්‍රියාත්මක වන ආකාරය ගැන කිසිවෙකු සිතුවේ නැත. එය සැමවිටම ක්‍රියාත්මක විය - එය ලබා දී ඇත.

Azimov පසුව පැවසුවේ එය පරිගණක සම්බන්ධයෙන්ද එසේම වනු ඇති බවයි. භාවිතයේ පහසුව වැඩි වනු ඇත. 1980 දී ඔබට පරිගණකයක බොත්තම් එබීම සඳහා පුහුණු වීමට සිදු වුවද, අනාගතයේදී එය එසේ නොවනු ඇත.

Kubernetes සමඟ සහ යටිතල පහසුකම් සමඟ භාවිතයේ පහසුවෙහි විශාල වැඩිවීමක් ඇති බව මට හැඟේ. මෙය, මගේ මතය අනුව, පැහැදිලිය - එය මතුපිට පිහිටා ඇත.

ඉංජිනේරුවන් සමඟ කුමක් කළ යුතුද?

- එවිට කුබර්නෙට්ස්ට සහය දක්වන ඉංජිනේරුවන්ට සහ පද්ධති පරිපාලකයින්ට කුමක් සිදුවේද?

දිමිත්රි: 1C ආවට පස්සේ ගණකාධිකාරීවරයාට මොකද වුණේ? එකම ගැන. මෙයට පෙර, ඔවුන් කඩදාසි මත ගණන් කළහ - දැන් වැඩසටහනේ. ශ්‍රම ඵලදායිතාව විශාලත්වයේ නියෝග මගින් වැඩි වී ඇත, නමුත් ශ්‍රමයම අතුරුදහන් වී නැත. කලින් බල්බයක් ඉස්කුරුප්පු කිරීමට ඉංජිනේරුවන් 10 ක් ගත වූවා නම්, දැන් එක් අයෙකු ප්රමාණවත් වනු ඇත.

මෘදුකාංග ප්‍රමාණය සහ කාර්යයන් සංඛ්‍යාව, මට පෙනෙන පරිදි, දැන් නව DevOps දර්ශනය වීමට වඩා වේගවත් වේගයකින් වර්ධනය වන අතර කාර්යක්ෂමතාව වැඩි වේ. දැන් වෙළඳපොලේ නිශ්චිත හිඟයක් පවතින අතර එය දිගු කාලයක් පවතිනු ඇත. පසුව, සෑම දෙයක්ම යම් ආකාරයක සාමාන්‍ය තත්වයකට පැමිණෙනු ඇත, එහිදී කාර්යයේ කාර්යක්ෂමතාව වැඩි වනු ඇත, වැඩි වැඩියෙන් සේවාදායකයක් නොමැති වනු ඇත, නියුරෝනයක් Kubernetes වෙත අනුයුක්ත කරනු ඇත, එමඟින් අවශ්‍ය පරිදි සියලු සම්පත් හරියටම තෝරා ගනු ඇත, සහ පොදුවේ කළ යුතු පරිදි සෑම දෙයක්ම තනිවම කරන්න - පුද්ගලයා ඉවත්ව ගොස් මැදිහත් නොවන්න.

නමුත් යමෙකුට තවමත් තීරණ ගැනීමට අවශ්ය වනු ඇත. මෙම පුද්ගලයාගේ සුදුසුකම් සහ විශේෂීකරණයේ මට්ටම ඉහළ බව පැහැදිලිය. අද කාලේ ගණකාධිකරණ අංශයේ අතේ මහන්සි නොවෙන්න පොත් තියාගෙන ඉන්න සේවකයෝ 10ක් ඕන නෑ. එය සරලවම අවශ්ය නොවේ. බොහෝ ලේඛන ඉලෙක්ට්‍රොනික ලේඛන කළමනාකරණ පද්ධතිය මඟින් ස්වයංක්‍රීයව පරිලෝකනය කර හඳුනා ගැනේ. එක් දක්ෂ ප්‍රධාන ගණකාධිකාරීවරයෙකු ප්‍රමාණවත්, දැනටමත් වඩා හොඳ කුසලතා ඇති, හොඳ අවබෝධයක් ඇත.

පොදුවේ ගත් කල, සෑම කර්මාන්තයකම යා යුතු මාර්ගය මෙයයි. මෝටර් රථ සම්බන්ධයෙන්ද එයම වේ: මීට පෙර, මෝටර් රථයක් කාර්මිකයෙකු සහ රියදුරන් තිදෙනෙකු සමඟ පැමිණියේය. වර්තමානයේ, මෝටර් රථයක් පැදවීම අපි සෑම දිනකම සහභාගී වන සරල ක්රියාවලියකි. මෝටර් රථයක් සංකීර්ණ දෙයක් යැයි කිසිවෙකු සිතන්නේ නැත.

DevOps හෝ පද්ධති ඉංජිනේරු විද්‍යාව පහව යන්නේ නැත - ඉහළ මට්ටමේ වැඩ සහ කාර්යක්ෂමතාව වැඩි වනු ඇත.

- කාර්යය ඇත්ත වශයෙන්ම වැඩි වනු ඇති බවට සිත්ගන්නා අදහසක් ද මට අසන්නට ලැබුණි.

දිමිත්රි: ඇත්ත වශයෙන්ම, සියයට සියයක්! මොකද අපි ලියන Software ප්‍රමාණය නිරන්තරයෙන් වැඩි වෙනවා. මෘදුකාංග සමඟ අප විසඳන ගැටළු ගණන නිරන්තරයෙන් වර්ධනය වේ. වැඩ ප්රමාණය වැඩි වෙමින් පවතී. දැන් DevOps වෙළඳපොළ දරුණු ලෙස රත් වී ඇත. වැටුප් අපේක්ෂාවෙන් මෙය දැකිය හැකිය. හොඳ විදියට කිව්වොත්, විස්තරේ යන්නෙ නැතුව, X ඕන ජූනියර්ස්, 1,5X ඕන මැද, 2X ඕන සීනියර්ස් ඉන්න ඕන. දැන්, ඔබ මොස්කව් DevOps වැටුප් වෙළඳපොළ දෙස බැලුවහොත්, කනිෂ්ඨයෙකුට X සිට 3X දක්වා අවශ්ය වන අතර, ජේෂ්ඨයෙකුට X සිට 3X දක්වා අවශ්ය වේ.

ඒ සඳහා කොපමණ මුදලක් වැය වේද යන්න කිසිවෙකු දන්නේ නැත. වැටුප් මට්ටම මනිනු ලබන්නේ ඔබේ විශ්වාසය මතයි - සම්පූර්ණ පිස්සුවකි, අවංකව කිවහොත්, දරුණු ලෙස රත් වූ වෙළඳපොලකි.

ඇත්ත වශයෙන්ම, මෙම තත්වය ඉතා ඉක්මනින් වෙනස් වනු ඇත - යම් සංතෘප්තියක් සිදුවිය යුතුය. මෘදුකාංග සංවර්ධනයේදී මෙය එසේ නොවේ - සෑම කෙනෙකුටම සංවර්ධකයින් අවශ්‍ය වන අතර සෑම කෙනෙකුටම හොඳ සංවර්ධකයින් අවශ්‍ය වුවද, වෙළඳපල තේරුම් ගනී කවුද වටින්නේ - කර්මාන්තය ස්ථාවර වී ඇත. මේ දවස් වල DevOps වල එහෙම නෑ.

- මා අසා ඇති දෙයින්, වත්මන් පද්ධති පරිපාලකයා ඕනෑවට වඩා කරදර නොවිය යුතු බව මම නිගමනය කළෙමි, නමුත් ඔහුගේ කුසලතා වැඩි දියුණු කිරීමට සහ හෙට තවත් වැඩ කිරීමට සූදානම් වීමට කාලයයි, නමුත් එය වඩාත් ඉහළ සුදුසුකම් ලත් වනු ඇත.

දිමිත්රි: සියයට සියයක්. පොදුවේ ගත් කල, අපි 2019 ජීවත් වන අතර ජීවිතයේ රීතිය මෙයයි: ජීවිත කාලය ඉගෙනීම - අපි අපේ ජීවිත කාලය පුරාම ඉගෙන ගනිමු. දැන් සෑම කෙනෙකුම මෙය දැනටමත් දන්නා සහ දැනෙන බව මට පෙනේ, නමුත් එය දැන ගැනීමට ප්‍රමාණවත් නොවේ - ඔබ එය කළ යුතුය. සෑම දිනකම අප වෙනස් විය යුතුය. අපි මෙය නොකළහොත්, ඉක්මනින් හෝ පසුව අපි වෘත්තියෙන් පැත්තකට වැටෙනු ඇත.

තියුණු අංශක 180 හැරීම් සඳහා සූදානම් වන්න. යමක් රැඩිකල් ලෙස වෙනස් වන, අලුත් දෙයක් සොයා ගන්නා තත්වයක් මම බැහැර නොකරමි - එය සිදු වේ. හොප්! - අපි දැන් වෙනස් ලෙස ක්රියා කරමු. මේ සඳහා සූදානම් වීම සහ කරදර නොවී සිටීම වැදගත්ය. හෙට මා කරන සෑම දෙයක්ම අනවශ්‍ය වනු ඇත - කිසිවක් නැත, මම මගේ මුළු ජීවිත කාලයම අධ්‍යයනය කර වෙනත් දෙයක් ඉගෙන ගැනීමට සූදානම්ව සිටිමි. ඒක ප්‍රශ්නයක් නෙවෙයි. රැකියා සුරක්ෂිතභාවය ගැන බිය විය යුතු නැත, නමුත් ඔබ නිරන්තරයෙන් අලුත් දෙයක් ඉගෙන ගැනීමට සූදානම් විය යුතුය.

ප්‍රාර්ථනා සහ ප්‍රචාරණයේ මිනිත්තුවක්

- ඔබට කිසියම් ආශාවක් තිබේද?

දිමිත්රි: ඔව්, මට ප්‍රාර්ථනා කිහිපයක් තියෙනවා.

පළමු සහ වෙළඳ - දායක වන්න යූ ටියුබ්. හිතවත් පාඨක ඔබ YouTube වෙත ගොස් අපගේ නාලිකාවට දායක වන්න. මාසයකින් පමණ අපි වීඩියෝ සේවාවෙහි ක්‍රියාකාරී ව්‍යාප්තිය අරඹන්නෙමු. Kubernetes පිළිබඳ විවෘත හා විවිධ අධ්‍යාපනික අන්තර්ගතයන් රාශියක් අප සතුව ඇත: ප්‍රායෝගික දේවල සිට විද්‍යාගාර දක්වා, ගැඹුරු මූලික න්‍යායාත්මක දේවල් සහ Kubernetes භාවිතා කරන ආකාරය මූලධර්ම සහ රටා මට්ටම.

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

තෙවනුව, වැදගත් සහ තවදුරටත් වෙළඳ ප්‍රාර්ථනාව - සුරංගනා කතා විශ්වාස කිරීම නවත්වන්න. ඔබ වෘත්තිකයන්. DevOps යනු ඉතා බැරෑරුම් සහ වගකිවයුතු වෘත්තියකි. රැකියා ස්ථානයේ සෙල්ලම් කිරීම නවත්වන්න. එය ඔබට ක්ලික් කිරීමට ඉඩ දෙන්න, එවිට ඔබට එය වැටහෙනු ඇත. ඔබ රෝහලට පැමිණෙන බව සිතන්න, එහිදී වෛද්‍යවරයා ඔබ ගැන අත්හදා බලනවා. මෙය යමෙකුට අහිතකර විය හැකි බව මට වැටහේ, නමුත්, බොහෝ දුරට, මෙය ඔබ ගැන නොව වෙනත් කෙනෙකු ගැන ය. අනිත් අයටත් නවතින්න කියන්න. මෙය සැබවින්ම අප සැමගේ ජීවිතය විනාශ කරයි - බොහෝ අය මෙහෙයුම්, පරිපාලකයින් සහ DevOps නැවත යමක් කැඩී ගිය අය ලෙස සැලකීමට පටන් ගනී. මෙය බොහෝ විට “කැඩුණේ” අපි සෙල්ලම් කරන්න ගිය නිසා, එහෙමයි, එහෙමයි කියලා සීතල සිහියෙන් නොබලපු නිසා.

ඔබ අත්හදා බැලීම් නොකළ යුතු බව මින් අදහස් නොවේ. අපි අත්හදා බැලීම් කළ යුතුයි, අපි එය තනිවම කරන්නෙමු. ඇත්තම කිව්වොත්, අපි සමහර විට ක්‍රීඩා කරන්නෙමු - මෙය ඇත්ත වශයෙන්ම ඉතා නරක ය, නමුත් මිනිසුන් කිසිවක් අපට පිටසක්වල නොවේ. 2019 නිෂ්පාදනය පිළිබඳ ක්‍රීඩා නොව, බැරෑරුම්, හොඳින් සිතා බලා අත්හදා බැලීම්වල වසරක් ලෙස ප්‍රකාශ කරමු. සමහරවිට එහෙම වෙන්න ඇති.

- ඔයාට බොහෝම ස්තූතියි!

දිමිත්රි: ස්තූතියි විටාලි, කාලය සහ සම්මුඛ පරීක්ෂණය සඳහා. හිතවත් පාඨකයින්, ඔබ හදිසියේ මෙම ස්ථානයට පැමිණියේ නම් ඔබට බොහෝම ස්තූතියි. අපි ඔබට අවම වශයෙන් අදහස් කිහිපයක් ගෙන එනු ඇතැයි මම බලාපොරොත්තු වෙමි.

සම්මුඛ සාකච්ඡාවේදී දිමිත්‍රි වර්ෆ්ගේ ගැටලුව ස්පර්ශ කළේය. දැන් මෙය සියලු ගැටලු පාහේ විසඳන විශ්වීය ස්විස් පිහියකි. නමුත් එය සැමවිටම එසේ නොවීය. මත DevOpsConf  උත්සවයේදී RIT++ Dmitry Stolyarov මෙම මෙවලම ගැන විස්තරාත්මකව ඔබට කියනු ඇත. වාර්තාවේ "werf යනු Kubernetes හි CI/CD සඳහා අපගේ මෙවලමයි" සෑම දෙයක්ම වනු ඇත: Kubernetes හි ගැටළු සහ සැඟවුණු සූක්ෂ්මතා, මෙම දුෂ්කරතා විසඳීම සඳහා විකල්ප සහ වර්ෆ් වත්මන් ක්රියාත්මක කිරීම විස්තරාත්මකව. මැයි 27 සහ 28 දිනවල අප හා එක්වන්න, අපි පරිපූර්ණ මෙවලම් නිර්මාණය කරන්නෙමු.

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

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