Istio සමඟ microservices වෙත ආපසු. 1 කොටස

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

ඉස්ටියෝ — Google, IBM සහ Lyft වෙතින් කණ්ඩායම් සමඟ සහයෝගයෙන් සංවර්ධනය කරන ලද විවෘත මූලාශ්‍ර ව්‍යාපෘතියකි. එය ක්ෂුද්‍ර සේවා මත පදනම් වූ යෙදුම්වල පැන නගින සංකීර්ණතා විසඳයි:

• රථවාහන කළමනාකරණය: කල් ඉකුත්වීම්, නැවත උත්සාහ කිරීම්, බර සමතුලිත කිරීම;
• Безопасность: අවසාන පරිශීලක සත්‍යාපනය සහ අවසරය;
• නිරීක්ෂණ හැකියාව: ලුහුබැඳීම, අධීක්ෂණය, ලොග් කිරීම.

මේ සියල්ල යෙදුම් මට්ටමින් විසඳා ගත හැකි නමුත් ඉන් පසුව ඔබේ සේවාවන් තවදුරටත් "මයික්රෝ" නොවේ. මෙම ගැටළු විසඳීම සඳහා සියලු අමතර උත්සාහයන් ව්යාපාරික වටිනාකම සඳහා සෘජුවම භාවිතා කළ හැකි සමාගම් සම්පත් නාස්තියකි. අපි උදාහරණයක් බලමු:

ව්‍යාපෘති කළමනාකරු: ප්‍රතිපෝෂණ විශේෂාංගයක් එක් කිරීමට කොපමණ කාලයක් ගතවේද?
සංවර්ධක: ස්ප්රින්ට් දෙකක්.

මන්ත්‍රී: මොකක්ද?.. ඒක CRUD විතරයි!
R: CRUD කිරීම පහසු කොටසකි, නමුත් අපට තවමත් පරිශීලකයන් සහ සේවාවන් සත්‍යාපනය කිරීමට සහ අවසර දීමට අවශ්‍ය වේ. ජාලය විශ්වාස කළ නොහැකි බැවින්, ඔබ නැවත නැවතත් ඉල්ලීම් ක්රියාත්මක කිරීමට අවශ්ය වනු ඇත, මෙන්ම පරිපථ කඩන රටාව ගනුදෙනුකරුවන් තුළ. එසේම, සම්පූර්ණ පද්ධතිය බිඳවැටෙන්නේ නැති බවට වග බලා ගැනීම සඳහා, ඔබට කල් ඉකුත්වීම් සහ අවශ්ය වනු ඇත තොග ශීර්ෂ (සඳහන් කළ රටා දෙකම පිළිබඳ වැඩි විස්තර සඳහා, ලිපියේ පසුව බලන්න - දළ වශයෙන් පරිවර්තනය.), සහ ගැටළු හඳුනා ගැනීම සඳහා, අධීක්ෂණය, ලුහුබැඳීම, […]

මන්ත්‍රී: ඔහ්, එහෙනම් අපි නිෂ්පාදන සේවාවට මෙම විශේෂාංගය ඇතුළත් කරමු.

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

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

ඉස්තියෝ අදහස

Istio නොමැති ලෝකයක, එක් සේවාවක් තවත් සේවාවක් වෙත සෘජු ඉල්ලීම් කරන අතර, අසාර්ථක වූ විට, සේවාව විසින්ම එය හැසිරවිය යුතුය: නව උත්සාහයක්, කල් ඉකුත්වීමක් ලබා දීම, පරිපථ කඩනයක් විවෘත කිරීම යනාදිය.

Kubernetes හි ජාල ගමනාගමනය

Istio විශේෂිත විසඳුමක් ලබා දෙයි, සේවා වලින් සම්පූර්ණයෙන්ම වෙන් කර ජාල සන්නිවේදනයට බාධා කිරීමෙන් ක්‍රියා කරයි. ඒ අනුව එය ක්රියාත්මක කරයි:

• වැරදි ඉවසීම: ප්‍රතිචාරයේ තත්ව කේතය මත පදනම්ව, ඉල්ලීම අසාර්ථක වූවාද යන්න තේරුම් ගෙන එය නැවත ක්‍රියාත්මක කරයි.
• කැනරි රෝල්අවුට්: සේවාවේ නව අනුවාදය වෙත ඉල්ලීම් වලින් ස්ථාවර ප්‍රතිශතයක් පමණක් හරවා යවයි.
• අධීක්‍ෂණය සහ ප්‍රමිතික: සේවාව ප්‍රතිචාර දැක්වීමට කොපමණ කාලයක් ගත වූවාද?
• ලුහුබැඳීම සහ නිරීක්ෂණ හැකියාව: සෑම ඉල්ලීමකටම විශේෂ ශීර්ෂ එකතු කර ඒවා පොකුර හරහා හඹා යයි.
• Безопасность: JWT ටෝකනය ලබා ගනී, පරිශීලකයින් සත්‍යාපනය කරයි සහ අවසර දෙයි.

මේවා ඔබව කුතුහලයට පත් කිරීමට ඇති හැකියාව (ඇත්ත වශයෙන්ම කිහිපයක් පමණි!) පමණි. දැන් අපි තාක්ෂණික තොරතුරු වෙත කිමිදෙමු!

ඉස්තියෝ ගෘහ නිර්මාණ ශිල්පය

Istio සියලු ජාල ගමනාගමනයට බාධා කරන අතර එයට නීති මාලාවක් යොදයි, එක් එක් පෝඩ් එකකට සයිඩ්කාර් බහාලුම් ස්වරූපයෙන් ස්මාර්ට් ප්‍රොක්සියක් ඇතුළු කරයි. සියලුම හැකියාවන් සක්‍රිය කරන ප්‍රොක්සි සාදයි a දත්ත තලය, සහ ඒවා භාවිතා කරමින් ගතිකව වින්‍යාසගත කළ හැක පාලන තලය.

දත්ත තලය

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

Envoy තුළ නැවත උත්සාහ කිරීම් සහ පරිපථ කඩනය ක්‍රියාත්මක වන ආකාරය

සාරාංශගත කිරීම සඳහා:

1. නියෝජිතයා (අපි කතා කරන්නේ පැති කාර් කන්ටේනරයක පිහිටා ඇති ප්‍රොක්සියක් ගැන වන අතර එය බෙදා හරිනු ලැබේ වෙනම නිෂ්පාදනයක් - ආසන්න වශයෙන්. පරිවර්තනය.) සේවා B හි පළමු අවස්ථාවට ඉල්ලීමක් යවා අසාර්ථක වේ.
2. එන්වෝයි සයිඩ්කාර් නැවත උත්සාහ කරයි (නැවත උත්සාහ කරන්න). (1)
3. ඉල්ලීම අසාර්ථක වන අතර එය ඇමතූ ප්‍රොක්සි වෙත ආපසු යවනු ලැබේ.
4. මෙය Circuit Breaker විවෘත කරන අතර පසුව ඉල්ලීම් සඳහා ඊළඟ සේවාව අමතන්න. (2)

මෙයින් අදහස් කරන්නේ ඔබට වෙනත් නැවත උත්සාහ කිරීමේ පුස්තකාලයක් භාවිතා කිරීමට අවශ්‍ය නැති බවත්, X, Y හෝ Z ක්‍රමලේඛන භාෂාවෙන් Circuit Breaking සහ Service Discovery ඔබ විසින්ම ක්‍රියාත්මක කිරීමට අවශ්‍ය නොවන බවත්ය. මේ සියල්ල සහ තවත් බොහෝ දේ කොටුවෙන් පිටත තිබේ. Istio හි සහ අවශ්ය නොවේ නැත කේතයේ වෙනස්කම්.

මහා! දැන් ඔබට ඉස්ටියෝ සමඟ මුහුදු ගමනක් යාමට අවශ්‍ය විය හැකිය, නමුත් ඔබට තවමත් යම් සැකයක්, විවෘත ප්‍රශ්න තිබේ. මෙය ජීවිතයේ සියලුම අවස්ථාවන් සඳහා විශ්වීය විසඳුමක් නම්, ඔබට ස්වාභාවික සැකයක් ඇත: සියල්ලට පසු, යථාර්ථයේ දී එවැනි විසඳුම් ඕනෑම අවස්ථාවකට නුසුදුසු බවට හැරේ.

අවසාන වශයෙන් ඔබ අසයි: "එය අභිරුචිකරණය කළ හැකිද?"

දැන් ඔබ මුහුදු ගමනට සූදානම්, අපි පාලන තලය ගැන දැන හඳුනා ගනිමු.

පාලන තලය

එය සංරචක තුනකින් සමන්විත වේ: නියමු ය, මික්සර් и සිටඩෙල්, ගමනාගමනය, ප්‍රතිපත්ති බලාත්මක කිරීම සහ දුරස්ථ දත්ත රැස් කිරීම සඳහා එන්වෝස් වින්‍යාස කිරීමට එක්ව ක්‍රියා කරයි. ක්‍රමානුකූලව, සියල්ල මේ ආකාරයෙන් පෙනේ:

දත්ත තලය සමඟ පාලන තලයේ අන්තර්ක්‍රියා

එන්වොයිස් (එනම් දත්ත තලය) භාවිතයෙන් වින්‍යාස කර ඇත Kubernetes CRD (අභිරුචි සම්පත් අර්ථ දැක්වීම්) Istio විසින් නිර්වචනය කර ඇති අතර මේ සඳහා විශේෂයෙන් අදහස් කෙරේ. මෙයින් ඔබට අදහස් වන්නේ ඔවුන් හුරුපුරුදු වාක්‍ය ඛණ්ඩයක් සහිත Kubernetes හි තවත් සම්පතක් පමණක් බව පෙනේ. නිර්මාණය කළ පසු, මෙම සම්පත පාලන තලය මගින් ලබාගෙන එන්වෝයිස් වෙත යොදනු ලැබේ.

Istio වෙත සේවා සම්බන්ධය

අපි සේවාවලට ඉස්තියෝගේ සම්බන්ධය විස්තර කර ඇත, නමුත් ප්‍රතිලෝම නොවේ: සේවා ඉස්ටියෝට සම්බන්ධ වන්නේ කෙසේද?

ඇත්තම කිව්වොත්, "කෙසේ වෙතත් ජලය යනු කුමක්ද?" යනුවෙන් තමන්ගෙන්ම ප්‍රශ්න කරන විට, මාළු වතුරේ සිටිනා සේම, ඉස්ටියෝගේ පැමිණීම ගැන සේවාවන් දනී.

නිදර්ශනය වික්ටෝරියා ඩිමිත්‍රකොපොලොස්:- ඔබ ජලයට කැමති කෙසේද? - කෙසේ වෙතත් ජලය යනු කුමක්ද?

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

ප්‍රමාණවත් න්‍යාය - අපි මෙම දැනුම ක්‍රියාවට නඟමු!

ප්රායෝගිකව ඉස්තියෝ

Istio සඳහා අවම වශයෙන් 4 vCPUs සහ 8 GB RAM සහිත Kubernetes පොකුරක් අවශ්‍ය වේ. ඉක්මනින් පොකුරක් සැකසීමට සහ ලිපියේ උපදෙස් අනුගමනය කිරීමට, නව පරිශීලකයින්ට ලබා දෙන Google Cloud Platform භාවිතා කිරීමට මම නිර්දේශ කරමි. නොමිලේ $300.

පොකුරක් සාදා කොන්සෝල උපයෝගීතාව හරහා Kubernetes වෙත ප්‍රවේශය වින්‍යාස කිරීමෙන් පසු, ඔබට Helm පැකේජ කළමනාකරු හරහා Istio ස්ථාපනය කළ හැකිය.

හෙල්ම් ස්ථාපනය

විස්තර කර ඇති පරිදි, ඔබේ පරිගණකයේ Helm සේවාලාභියා ස්ථාපනය කරන්න නිල ලියකියවිලි. මීළඟ කොටසේදී Istio ස්ථාපනය කිරීම සඳහා සැකිලි උත්පාදනය කිරීමට අපි මෙය භාවිතා කරමු.

Istio ස්ථාපනය කිරීම

Istio සම්පත් බාගන්න නවතම නිකුතුව (1.0.5 අනුවාදයට මුල් කර්තෘගේ සබැඳිය වර්තමාන එකට වෙනස් කර ඇත, එනම් 1.0.6 - දළ වශයෙන්. පරිවර්තනය.), අන්තර්ගතය එක ඩිරෙක්ටරියකට උපුටා ගන්න, මම මෙතැන් සිට එය හඳුන්වනු ඇත [istio-resources].

Istio සම්පත් පහසුවෙන් හඳුනා ගැනීමට, K8s පොකුරේ නාම අවකාශයක් සාදන්න istio-system:

$ kubectl create namespace istio-system

බහලුම වෙත ගොස් ස්ථාපනය සම්පූර්ණ කරන්න [istio-resources] සහ විධානය ක්‍රියාත්මක කරන්න:

$ helm template install/kubernetes/helm/istio 
  --set global.mtls.enabled=false 
  --set tracing.enabled=true 
  --set kiali.enabled=true 
  --set grafana.enabled=true 
  --namespace istio-system > istio.yaml

මෙම විධානය මඟින් Istio හි ප්‍රධාන සංරචක ගොනුවකට ප්‍රතිදානය කරයි istio.yaml. පහත පරාමිතීන් සඳහන් කරමින් අපි අපට ගැලපෙන පරිදි සම්මත අච්චුව වෙනස් කළෙමු:

• global.mtls.enabled තුළ ස්ථාපනය කර ඇත false (එනම් mTLS සත්‍යාපනය අබල කර ඇත - දළ වශයෙන්.)අපගේ ආලය ක්රියාවලිය සරල කිරීමට;
• tracing.enabled ජේගර් භාවිතයෙන් ඉල්ලීම් ලුහුබැඳීම ඇතුළත් වේ;
• kiali.enabled සේවා සහ ගමනාගමනය දෘශ්‍යමාන කිරීමට Kiali පොකුරකට ස්ථාපනය කරයි;
• grafana.enabled එකතු කරන ලද ප්‍රමිතික දෘශ්‍යමාන කිරීමට Grafana ස්ථාපනය කරයි.

විධානය සමඟ ජනනය කරන ලද සම්පත් භාවිතා කරමු:

$ kubectl apply -f istio.yaml

පොකුරේ Istio ස්ථාපනය සම්පූර්ණයි! සියලුම කරල් නාම අවකාශයේ ඇති තෙක් රැඳී සිටින්න istio-system හැකි වනු ඇත Running හෝ Completedපහත විධානය ක්‍රියාත්මක කිරීමෙන්:

$ kubectl get pods -n istio-system

දැන් අපි ඊළඟ කොටසේ ඉදිරියට යාමට සූදානම්ව සිටිමු, එහිදී අපි යෙදුම ක්‍රියාත්මක කර ක්‍රියාත්මක කරන්නෙමු.

හැඟීම් විශ්ලේෂණ යෙදුමේ ගෘහ නිර්මාණ ශිල්පය

අපි දැනටමත් සඳහන් කර ඇති හැඟීම් විශ්ලේෂණ ක්ෂුද්‍ර සේවා යෙදුමේ උදාහරණය භාවිතා කරමු Kubernetes වෙත හැඳින්වීමේ ලිපිය. එය ඉස්ටියෝගේ හැකියාවන් ප්‍රායෝගිකව පෙන්වීමට තරම් සංකීර්ණය.

යෙදුම ක්ෂුද්‍ර සේවා හතරකින් සමන්විත වේ:

1. සේවා SA-Frontend, Reactjs යෙදුමක ඉදිරිපසට සේවය කරන;
2. සේවා SA-WebApp, හැඟීම් විශ්ලේෂණ විමසුම් සඳහා සේවය කරන;
3. සේවා SA-ලොජික්, එයම ඉටු කරයි හැඟීම් විශ්ලේෂණය;
4. සේවා SA-ප්‍රතිපෝෂණ, විශ්ලේෂණයේ නිරවද්‍යතාවය පිළිබඳව පරිශීලකයින්ගෙන් ප්‍රතිපෝෂණ ලබා ගනී.

මෙම රූප සටහනේ, සේවාවන්ට අමතරව, අපි Kubernetes හි එන ඉල්ලීම් සුදුසු සේවාවන් වෙත යොමු කරන Ingress Controller ද දකිමු. Istio එහි Ingress Gateway තුළ සමාන සංකල්පයක් භාවිතා කරයි, එහි වැඩි විස්තර පහත දැක්වේ.

Istio වෙතින් ප්‍රොක්සියක් සමඟ යෙදුමක් ධාවනය කිරීම

ලිපියේ සඳහන් කර ඇති වැඩිදුර මෙහෙයුම් සඳහා, ඔබේ ගබඩාව ක්ලෝන කරන්න istio-mastery. එහි යෙදුම අඩංගු වන අතර Kubernetes සහ Istio සඳහා මැනිෆෙස්ට් වේ.

පැති කාර් ඇතුළු කිරීම

ඇතුළත් කිරීම සිදු කළ හැකිය ස්වයංක්රීයව හෝ අතින්. සයිඩ් කාර් බහාලුම් ස්වයංක්‍රීයව ඇතුළු කිරීමට, ඔබට නාම අවකාශයට ලේබලයක් සැකසීමට අවශ්‍ය වනු ඇත istio-injection=enabled, එය පහත විධානය සමඟ සිදු කෙරේ:

$ kubectl label namespace default istio-injection=enabled
namespace/default labeled

දැන් පෙරනිමි නාම අවකාශයේ යොදවනු ලබන සෑම පොඩ් එකක්ම (default) එහි සයිඩ්කාර් කන්ටේනරය ලැබෙනු ඇත. මෙය සත්‍යාපනය කිරීම සඳහා, ගබඩාවේ මූල නාමාවලිය වෙත ගොස් පරීක්ෂණ යෙදුම යෙදවමු [istio-mastery] සහ පහත විධානය ක්‍රියාත්මක කරන්න:

$ kubectl apply -f resource-manifests/kube
persistentvolumeclaim/sqlite-pvc created
deployment.extensions/sa-feedback created
service/sa-feedback created
deployment.extensions/sa-frontend created
service/sa-frontend created
deployment.extensions/sa-logic created
service/sa-logic created
deployment.extensions/sa-web-app created
service/sa-web-app created

සේවා යෙදවීමෙන් පසු, විධානය ක්‍රියාත්මක කිරීමෙන් කරල්වල බහාලුම් දෙකක් (සේවාව සහ එහි පැතිකාරයා සමඟ) තිබේදැයි පරීක්ෂා කරමු. kubectl get pods සහ තීරුව යටතේ බව තහවුරු කර ගැනීම READY නිශ්චිතව දක්වා ඇති අගය 2/2, බහාලුම් දෙකම ක්‍රියාත්මක වන බව සංකේතවත් කරයි:

$ kubectl get pods
NAME                           READY     STATUS    RESTARTS   AGE
sa-feedback-55f5dc4d9c-c9wfv   2/2       Running   0          12m
sa-frontend-558f8986-hhkj9     2/2       Running   0          12m
sa-logic-568498cb4d-2sjwj      2/2       Running   0          12m
sa-logic-568498cb4d-p4f8c      2/2       Running   0          12m
sa-web-app-599cf47c7c-s7cvd    2/2       Running   0          12m

දෘශ්‍යමය වශයෙන් එය මේ ආකාරයෙන් පෙනේ:

එක පොඩ් එකක එන්වෝයි ප්‍රොක්සි

දැන් යෙදුම ක්‍රියාත්මක වන අතර, අපි එන ගමනාගමනයට යෙදුමට පැමිණීමට ඉඩ දිය යුතුය.

ඇතුල්වීමේ දොරටුව

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

Ingress Gateway සංරචකය සහ එය බාහිරව යොමු කරන සේවාව Istio ස්ථාපනය අතරතුර පොකුරේ ස්ථාපනය කර ඇත. සේවාවේ බාහිර IP ලිපිනය සොයා ගැනීමට, ධාවනය කරන්න:

$ kubectl get svc -n istio-system -l istio=ingressgateway
NAME                   TYPE           CLUSTER-IP     EXTERNAL-IP
istio-ingressgateway   LoadBalancer   10.0.132.127   13.93.30.120

අපි මෙම IP භාවිතයෙන් යෙදුමට ප්‍රවේශ වීම දිගටම කරගෙන යන්නෙමු (මම එය බාහිර-IP ලෙස සඳහන් කරමි), එබැවින් පහසුව සඳහා අපි අගය විචල්‍යයකට ලියන්නෙමු:

$ EXTERNAL_IP=$(kubectl get svc -n istio-system 
  -l app=istio-ingressgateway 
  -o jsonpath='{.items[0].status.loadBalancer.ingress[0].ip}')

ඔබ දැන් බ්‍රව්සරයක් හරහා මෙම IP වෙත ප්‍රවේශ වීමට උත්සාහ කළහොත්, ඔබට Service Unavailable දෝෂයක් ලැබෙනු ඇත, මන්ද පෙරනිමියෙන් Istio පැමිණෙන සියලුම ගමනාගමනය අවහිර කරයි, ගේට්වේ තවමත් නිර්වචනය කර නොමැත.

ගේට්වේ සම්පත

Gateway යනු Kubernetes හි CRD (අභිරුචි සම්පත් නිර්වචනය) වන අතර, පොකුරේ Istio ස්ථාපනය කිරීමෙන් පසුව අර්ථ දක්වා ඇති අතර අපට පැමිණෙන ගමනාගමනයට ඉඩ දීමට අවශ්‍ය වරාය, ප්‍රොටෝකෝලය සහ ධාරක නියම කිරීමේ හැකියාව සක්‍රීය කරයි.

අපගේ නඩුවේදී, සියලුම ධාරක සඳහා වරාය 80 හි HTTP ගමනාගමනයට ඉඩ දීමට අපට අවශ්‍යය. පහත දැක්වෙන නිර්වචනය මගින් කාර්යය ක්රියාත්මක වේ (http-gateway.yaml):

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: http-gateway
spec:
  selector:
    istio: ingressgateway
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
- "*"

මෙම වින්‍යාසයට තේරීම්කාරකය හැර කිසිදු පැහැදිලි කිරීමක් අවශ්‍ය නොවේ istio: ingressgateway. මෙම තේරීම්කාරකය සමඟින් අපට වින්‍යාසය යෙදිය යුතු ඇතුල්වීමේ දොරටුව සඳහන් කළ හැක. අපගේ නඩුවේදී, මෙය Istio හි පෙරනිමියෙන් ස්ථාපනය කරන ලද Ingress Gateway පාලකයයි.

පහත විධානය ඇමතීමෙන් වින්‍යාසය යොදනු ලැබේ:

$ kubectl apply -f resource-manifests/istio/http-gateway.yaml gateway.networking.istio.io/http-gateway created

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

VirtualService සම්පත

VirtualService විසින් Ingress Gateway හට පොකුර තුළ අවසර දී ඇති ඉල්ලීම් මෙහෙයවන ආකාරය කියයි.

http-gateway හරහා එන අපගේ අයදුම්පත සඳහා වන ඉල්ලීම් sa-frontend, sa-web-app සහ sa-feedback සේවා වෙත යැවිය යුතුය:

VirtualServices සමඟ වින්‍යාස කළ යුතු මාර්ග

SA-Frontend වෙත යැවිය යුතු ඉල්ලීම් දෙස බලමු:

• මාර්ගය දිගේ හරියටම ගැලපේ / index.html ලබා ගැනීමට SA-Frontend වෙත යැවිය යුතුය;
• උපසර්ග මාර්ග /static/* CSS සහ JavaScript වැනි ඉදිරිපස භාවිතා කරන ස්ථිතික ගොනු ලබා ගැනීමට SA-Frontend වෙත යැවිය යුතුය;
• නිත්‍ය ප්‍රකාශනයට ගැළපෙන මාර්ග '^.*.(ico|png|jpg)$', SA-Frontend වෙත යැවිය යුතුය, මන්ද මෙම පිටුවේ දර්ශනය වන පින්තූර වේ.

පහත වින්‍යාසය මඟින් ක්‍රියාත්මක කිරීම සාක්ෂාත් කරගනු ලැබේ (sa-virtualservice-external.yaml):

kind: VirtualService
metadata:
  name: sa-external-services
spec:
  hosts:
  - "*"
  gateways:
  - http-gateway                      # 1
  http:
  - match:
    - uri:
        exact: /
    - uri:
        exact: /callback
    - uri:
        prefix: /static
    - uri:
        regex: '^.*.(ico|png|jpg)

Важные моменты:



 	
 Этот VirtualService относится к запросам, приходящим через http-gateway;


 	
 В destination определяется сервис, куда отправляются запросы.




Примечание: Конфигурация выше хранится в файле sa-virtualservice-external.yaml, который также содержит настройки для маршрутизации в SA-WebApp и SA-Feedback, но был сокращён здесь в статье для лаконичности.

Применим VirtualService вызовом:

$ kubectl apply -f resource-manifests/istio/sa-virtualservice-external.yaml
virtualservice.networking.istio.io/sa-external-services created
Примечание: Когда мы применяем ресурсы Istio, Kubernetes API Server создаёт событие, которое получает Istio Control Plane, и уже после этого новая конфигурация применяется к прокси-серверам Envoy каждого pod'а. А контроллер Ingress Gateway представляется очередным Envoy, сконфигурированным в Control Plane. Всё это на схеме выглядит так:


Конфигурация Istio-IngressGateway для маршрутизации запросов
Приложение Sentiment Analysis стало доступным по http://{EXTERNAL-IP}/. Не переживайте, если вы получаете статус Not Found: иногда требуется чуть больше времени для того, чтобы конфигурация вступила в силу и кэши Envoy обновились.
Перед тем, как продолжить, поработайте немного с приложением, чтобы сгенерировать трафик (его наличие необходимо для наглядности в последующих действиях — прим. перев.).
Kiali : наблюдаемость
Чтобы попасть в административный интерфейс Kiali, выполните следующую команду:
$ kubectl port-forward 
    $(kubectl get pod -n istio-system -l app=kiali 
    -o jsonpath='{.items[0].metadata.name}') 
    -n istio-system 20001
… и откройте http://localhost:20001/, залогинившись под admin/admin. Здесь вы найдете множество полезных возможностей, например, для проверки конфигурации компонентов Istio, визуализации сервисов по информации, собранной при перехвате сетевых запросов, получения ответов на вопросы «Кто к кому обращается?», «У какой версии сервиса возникают сбои?» и т.п. В общем, изучите возможности Kiali перед тем, как двигаться дальше — к визуализации метрик с Grafana.

Grafana: визуализация метрик
Собранные в Istio метрики попадают в Prometheus и визуализируются с Grafana. Чтобы попасть в административный интерфейс Grafana, выполните команду ниже, после чего откройте http://localhost:3000/:
$ kubectl -n istio-system port-forward 
    $(kubectl -n istio-system get pod -l app=grafana 
    -o jsonpath={.items[0].metadata.name}) 3000
Кликнув на меню Home слева сверху и выбрав Istio Service Dashboard в левом верхнем углу, начните с сервиса sa-web-app, чтобы посмотреть на собранные метрики:

Здесь нас ждёт пустое и совершенно скучное представление — руководство никогда такое не одобрит. Давайте же создадим небольшую нагрузку следующей командой:
$ while true; do 
    curl -i http://$EXTERNAL_IP/sentiment 
    -H "Content-type: application/json" 
    -d '{"sentence": "I love yogobella"}'; 
    sleep .8; done
Вот теперь у нас гораздо более симпатичные графики, а в дополнение к ним — замечательные инструменты Prometheus для мониторинга и Grafana для визуализации метрик, что позволят нам узнать о производительности, состоянии здоровья, улучшениях/деградации в работе сервисов на протяжении времени.
Наконец, посмотрим на трассировку запросов в сервисах.
Jaeger : трассировка
Трассировка нам потребуется, потому что чем больше у нас сервисов, тем сложнее добраться до причины сбоя. Посмотрим на простой случай из картинки ниже:


Типовой пример случайного неудачного запроса
Запрос приходит, падает — в чём же причина? Первый сервис? Или второй? Исключения есть в обоих — давайте посмотрим на логи каждого. Как часто вы ловили себя за таким занятием? Наша работа больше похожа на детективов программного обеспечения, а не разработчиков…
Это широко распространённая проблема в микросервисах и решается она распределёнными системами трассировки, в которых сервисы передают друг другу уникальный заголовок, после чего эта информация перенаправляется в систему трассировки, где она сопоставляется с данными запроса. Вот иллюстрация:


Для идентификации запроса используется TraceId
В Istio используется Jaeger Tracer, который реализует независимый от вендоров фреймворк OpenTracing API. Получить доступ к пользовательского интерфейсу Jaeger можно следующей командой:
$ kubectl port-forward -n istio-system 
    $(kubectl get pod -n istio-system -l app=jaeger 
    -o jsonpath='{.items[0].metadata.name}') 16686
Теперь зайдите на http://localhost:16686/ и выберите сервис sa-web-app. Если сервис не показан в выпадающем меню — проявите/сгенерируйте активность на странице и обновите интерфейс. После этого нажмите на кнопку Find Traces, которая покажет самые последние трейсы — выберите любой — покажется детализированная информация по всем трейсам:

Этот трейс показывает:

 Запрос приходит в istio-ingressgateway (это первое взаимодействие с одним из сервисов, и для запроса генерируется Trace ID), после чего шлюз направляет запрос в сервис sa-web-app.
 В сервисе sa-web-app запрос подхватывается Envoy sidecar'ом, создаётся «ребёнок» в span'е (поэтому мы видим его в трейсах) и перенаправляется в контейнер sa-web-app. (Span — логическая единица работы в Jaeger, имеющая название, время начало операции и её продолжительность. Span'ы могут быть вложенными и упорядоченными. Ориентированный ациклический граф из span'ов образует trace. — прим. перев.)
 Здесь запрос обрабатывается методом sentimentAnalysis. Эти трейсы уже сгенерированы приложением, т.е. для них потребовались изменения в коде.
 С этого момента инициируется POST-запрос в sa-logic. Trace ID должен быть проброшен из sa-web-app.
 …

Примечание: На 4 шаге приложение должно увидеть заголовки, сгенерированные Istio, и передать их в последующие запросы, как показано на изображении ниже:


(A) За проброс заголовков отвечает Istio; (B) За заголовки отвечают сервисы
Istio делает основную работу, т.к. генерирует заголовки для входящих запросов, создаёт новые span'ы в каждом sidecare'е и пробрасывает их. Однако без работы с заголовками внутри сервисов полный путь трассировки запроса будет утерян.
Необходимо учитывать (пробрасывать) следующие заголовки:
x-request-id
x-b3-traceid
x-b3-spanid
x-b3-parentspanid
x-b3-sampled
x-b3-flags
x-ot-span-context
Это несложная задача, однако для упрощения её реализации уже существует множество библиотек — например, в сервисе sa-web-app клиент RestTemplate пробрасывает эти заголовки, если просто добавить библиотеки Jaeger и OpenTracing в его зависимости.
Заметьте, что приложение Sentiment Analysis демонстрирует реализации на Flask, Spring и ASP.NET Core.
Теперь, когда стало ясно, что мы получаем из коробки (или почти «из коробки»), рассмотрим вопросы тонко настраиваемой маршрутизации, управления сетевым трафиком, безопасности и т.п.!
Прим. перев.: об этом читайте в следующей части материалов по Istio от Rinor Maloku, переводы которых последуют в нашем блоге в ближайшее время. UPDATE (14 марта): Вторая часть уже опубликована.
P.S. от переводчика
Читайте также в нашем блоге:

 «Назад к микросервисам вместе с Istio»: часть 2 (маршрутизация, управление трафиком), часть 3 (аутентификация и авторизация);
 «Conduit — легковесный service mesh для Kubernetes»;
 «Что такое service mesh и почему он мне нужен [для облачного приложения с микросервисами]?»;
 «Иллюстрированное руководство по устройству сети в Kubernetes. Части 1 и 2»;
 «Как этот sidecar-контейнер оказался здесь [в Kubernetes]?».

Источник: habr.com
route:

- destination:

host: sa-frontend             # 2

port:

number: 80

වැදගත් කරුණු:

 මෙම VirtualService යන්නෙන් ලැබෙන ඉල්ලීම් ගැන සඳහන් වේ http-ගේට්වේ;
 В destination ඉල්ලීම් යවන සේවාව තීරණය කරනු ලැබේ.

අදහස් දැක්වීම්: ඉහත වින්‍යාසය ගොනුවක ගබඩා කර ඇත sa-virtualservice-external.yaml, එය SA-WebApp සහ SA-Feedback හි මාර්ගගත කිරීම සඳහා සැකසුම් ද අඩංගු වේ, නමුත් කෙටිකතාව සඳහා ලිපියේ කෙටි කර ඇත.
ඇමතීමෙන් VirtualService අයදුම් කරමු:

අදහස් දැක්වීම්: අපි Istio සම්පත් පරිභෝජනය කරන විට, Kubernetes API සේවාදායකය Istio පාලන තලයට ලැබෙන සිදුවීමක් නිර්මාණය කරයි, ඉන්පසු නව වින්‍යාසය එක් එක් පොඩ්ගේ එන්වෝයි ප්‍රොක්සි සඳහා යොදනු ලැබේ. ඉන්ග්‍රෙස් ගේට්වේ පාලකය පාලක තලයේ වින්‍යාස කර ඇති තවත් නියෝජිතයෙකු බව පෙනේ. රූප සටහනේ මේ සියල්ල මේ ආකාරයෙන් පෙනේ:


ඉල්ලීම් මාර්ගගත කිරීම සඳහා Istio-IngressGateway වින්‍යාසය
හැඟීම් විශ්ලේෂණ යෙදුම දැන් ලබා ගත හැක http://{EXTERNAL-IP}/. ඔබ සොයා නොගත් තත්ත්වය ලබා ගන්නේ නම් කරදර නොවන්න: සමහර විට වින්‍යාසය ක්‍රියාත්මක වීමට සහ Envoy හැඹිලි යාවත්කාලීන කිරීමට ටිකක් වැඩි කාලයක් ගතවේ.
ඉදිරියට යාමට පෙර, තදබදය උත්පාදනය කිරීමට යෙදුම සමඟ ටිකක් සෙල්ලම් කරන්න. (පසුකාලීන ක්‍රියාවන්හි පැහැදිලිකම සඳහා එහි පැමිණීම අවශ්‍ය වේ - දළ වශයෙන් පරිවර්තනය.).
Kiali: නිරීක්ෂණ හැකියාව
Kiali පරිපාලන අතුරුමුහුණත වෙත යාමට, පහත විධානය ක්‍රියාත්මක කරන්න:

... සහ විවෘත http://localhost:20001/, පරිපාලක/පරිපාලක ලෙස ලොග් වීම. මෙහිදී ඔබට බොහෝ ප්‍රයෝජනවත් විශේෂාංග සොයා ගත හැකි වනු ඇත, උදාහරණයක් ලෙස, Istio සංරචකවල වින්‍යාසය පරීක්ෂා කිරීම, ජාල ඉල්ලීම් වලට බාධා කිරීමෙන් එකතු කරන ලද තොරතුරු භාවිතයෙන් සේවා දෘශ්‍යමාන කිරීම, “කවුද සම්බන්ධ කර ගන්නේ කවුද?”, “සේවාවේ කුමන අනුවාදය අත්විඳින්නේද?” යන ප්‍රශ්නවලට පිළිතුරු ලබා ගන්න. අසාර්ථකද?" සහ යනාදි. සාමාන්‍යයෙන්, Grafana සමඟ ප්‍රමිතික දෘශ්‍යකරණය කිරීමට පෙර Kiali හි හැකියාවන් ගවේෂණය කරන්න.

ග්‍රැෆනා: ප්‍රමිතික දෘශ්‍යකරණය
Istio හි එකතු කරන ලද ප්‍රමිතික Prometheus වෙත ගොස් Grafana සමඟින් දෘශ්‍යමාන වේ. Grafana පරිපාලන අතුරුමුහුණත වෙත යාමට, පහත විධානය ක්‍රියාත්මක කර විවෘත කරන්න http://localhost:3000/:

මෙනුව මත ක්ලික් කිරීම මුල් පිටුව ඉහළ වම් සහ තේරීම Istio සේවා උපකරණ පුවරුව ඉහළ වම් කෙළවරේ, සේවාව සමඟ ආරම්භ කරන්න sa-web-appඑකතු කරන ලද ප්‍රමිතික බැලීමට:

මෙහි අපව බලා සිටින්නේ හිස් හා සම්පූර්ණයෙන්ම නීරස කාර්ය සාධනයකි - කළමනාකාරිත්වය කිසි විටෙකත් මෙය අනුමත නොකරනු ඇත. පහත විධානය සමඟ කුඩා බරක් නිර්මාණය කරමු:

දැන් අපට වඩා හොඳ ප්‍රස්ථාර ඇති අතර, ඒවාට අමතරව, නිරීක්ෂණ සඳහා අපූරු Prometheus මෙවලම් සහ කාලයත් සමඟ කාර්ය සාධනය, සෞඛ්‍යය, වැඩිදියුණු කිරීම් / පිරිහීම ගැන අපට ඉගෙන ගැනීමට ඉඩ සලසන මිනුම් දෘෂ්‍යමාන කිරීම සඳහා Grafana.
අවසාන වශයෙන්, සේවාවන්හි ඉල්ලීම් සොයා ගැනීම දෙස බලමු.
ජේගර්: ලුහුබැඳීම
අපට ලුහුබැඳීම අවශ්‍ය වනු ඇත, මන්ද අප සතුව ඇති සේවාවන් වැඩි වන තරමට අසාර්ථක වීමට හේතුව සොයා ගැනීම වඩාත් අපහසු වේ. පහත පින්තූරයෙන් සරල නඩුවක් බලමු:


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


ඉල්ලීම හඳුනා ගැනීමට TraceId භාවිතා කරයි
Istio විකුණුම්කරු-ස්වාධීන OpenTracing API රාමුව ක්‍රියාත්මක කරන Jaeger Tracer භාවිතා කරයි. පහත දැක්වෙන විධානය සමඟින් ඔබට Jaeger පරිශීලක අතුරුමුහුණත වෙත පිවිසිය හැක:

දැන් යන්න http://localhost:16686/ සහ සේවාවක් තෝරන්න sa-web-app. සේවාව පතන මෙනුවේ නොපෙන්වන්නේ නම්, පිටුවේ ක්‍රියාකාරකම් පෙන්වන්න/උත්පාදනය කර අතුරු මුහුණත යාවත්කාලීන කරන්න. ඊට පසු, බොත්තම මත ක්ලික් කරන්න හෝඩුවාවන් සොයන්න, නවතම හෝඩුවාවන් පෙන්වනු ඇත - ඕනෑම එකක් තෝරන්න - සියලු හෝඩුවාවන් පිළිබඳ සවිස්තරාත්මක තොරතුරු දිස්වනු ඇත:

මෙම සටහන පෙන්නුම් කරන්නේ:

 ඉල්ලීම පැමිණේ istio-ingressgateway (මෙය එක් සේවාවක් සමඟ පළමු අන්තර්ක්‍රියා වන අතර, ඉල්ලීම සඳහා ලුහුබැඳීමේ හැඳුනුම්පතක් ජනනය කරනු ලැබේ), ඉන් පසුව ද්වාරය සේවාව වෙත ඉල්ලීම යවයි sa-web-app.
 ක්රියාත්මකයි sa-web-app ඉල්ලීම එන්වෝයි සයිඩ්කාර් විසින් ගනු ලැබේ, කාල පරාසය තුළ “ළමයෙකු” නිර්මාණය කරනු ලැබේ (අපි එය හෝඩුවාවන් තුළ දකින්නේ එබැවිනි) සහ කන්ටේනරය වෙත හරවා යවනු ලැබේ sa-web-app. (කාලයක් - නමක්, මෙහෙයුමේ ආරම්භක වේලාව සහ එහි කාලසීමාව ඇති ජේගර් හි තාර්කික වැඩ ඒකකයක්. ස්පාන්ස් කූඩු කර ඇණවුම් කළ හැකිය. විහිදුවන ඇසික්ලික් ප්‍රස්ථාරයක් හෝඩුවාවක් සාදයි. - ආසන්න වශයෙන්. පරිවර්තනය.)
 මෙහිදී ඉල්ලීම ක්‍රමයෙන් ක්‍රියාත්මක වේ හැඟීම් විශ්ලේෂණය. මෙම හෝඩුවාවන් දැනටමත් යෙදුම මගින් ජනනය කර ඇත, i.e. ඔවුන්ට කේතය වෙනස් කිරීමට අවශ්‍ය විය.
 මේ මොහොතේ සිට, POST ඉල්ලීමක් ආරම්භ වේ sa-logic. ලුහුබැඳීමේ හැඳුනුම්පත යොමු කළ යුතුය sa-web-app.
 ...

අදහස් දැක්වීම්: 4 පියවරේදී, යෙදුම Istio විසින් ජනනය කරන ලද ශීර්ෂයන් දැකිය යුතු අතර පහත රූපයේ පෙන්වා ඇති පරිදි ඒවා පසුකාලීන ඉල්ලීම් වෙත යොමු කළ යුතුය:


(A) ශීර්ෂ යොමු කිරීම සඳහා Istio වගකිව යුතුය; (B) ශීර්ෂ සඳහා සේවා වගකිව යුතුය
ඉස්තියෝ ගොඩක් වැඩ කරන්නේ මොකද... එන ඉල්ලීම් සඳහා ශීර්ෂ උත්පාදනය කරයි, එක් එක් අතුරු සත්කාරය තුළ නව පරාසයන් නිර්මාණය කර ඒවා ඉදිරිපත් කරයි. කෙසේ වෙතත්, සේවා ඇතුළත ශීර්ෂ සමඟ වැඩ නොකර, සම්පූර්ණ ඉල්ලීම් ලුහුබැඳීමේ මාර්ගය අහිමි වනු ඇත.
පහත සඳහන් ශීර්ෂයන් සැලකිල්ලට ගත යුතුය:

මෙය අපහසු කාර්යයක් නොවේ, නමුත් එය ක්රියාත්මක කිරීම සරල කිරීම සඳහා දැනටමත් පවතී බොහෝ පුස්තකාල - උදාහරණයක් ලෙස, sa-web-app සේවාව තුළ, ඔබ හුදෙක් Jaeger සහ OpenTracing පුස්තකාල එකතු කළහොත් RestTemplate සේවාදායකයා මෙම ශීර්ෂයන් යොමු කරයි. ඔහුගේ ඇබ්බැහිවීම්.
හැඟීම් විශ්ලේෂණ යෙදුම Flask, Spring, සහ ASP.NET Core හි ක්‍රියාත්මක කිරීම් පෙන්නුම් කරන බව සලකන්න.
දැන් අපට පෙට්ටියෙන් (හෝ පෙට්ටියෙන් පිටත) ලැබෙන්නේ කුමක්ද යන්න පැහැදිලි බැවින්, අපි හොඳින් සුසර කළ මාර්ගගත කිරීම, ජාල ගමනාගමන කළමනාකරණය, ආරක්ෂාව යනාදිය දෙස බලමු!
සටහන. පරිවර්තනය.: Rinor Maloku වෙතින් Istio පිළිබඳ ද්‍රව්‍යවල ඊළඟ කොටසෙහි මේ ගැන කියවන්න, එහි පරිවර්තන නුදුරු අනාගතයේදී අපගේ බ්ලොග් අඩවියේ අනුගමනය කරනු ඇත. UPDATE (මාර්තු 14): දෙවන කොටස දැනටමත් ප්රකාශයට පත් කර ඇත.
පරිවර්තකගෙන් PS
අපගේ බ්ලොග් අඩවියේ ද කියවන්න:

 "ඉස්ටියෝ සමඟ ක්ෂුද්‍ර සේවා වෙත ආපසු": 2 කොටස (මාර්ගගත කිරීම, රථවාහන පාලනය), 3 කොටස (සත්‍යාපනය සහ අවසරය);
 «Conduit - Kubernetes සඳහා සැහැල්ලු සේවා දැලක්»;
 «සේවා දැලක් යනු කුමක්ද සහ මට එය [ක්ෂුද්‍ර සේවා සහිත වලාකුළු යෙදුමක් සඳහා] අවශ්‍ය වන්නේ ඇයි?»;
 «Kubernetes හි ජාලකරණය සඳහා නිදර්ශන මාර්ගෝපදේශයකි. කොටස් 1 සහ 2»;
 «මෙම පැති කාර් කන්ටේනරය මෙහි [කුබර්නෙටස් හි] අවසන් වූයේ කෙසේද?".

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