අන්තර්ජාලයේ (සේවා දැලක්), සහ මෙන්න තවත් එකක්. හුරේ! නමුත් ඇයි? එවිට, Docker සහ Kubernetes වැනි බහාලුම් වේදිකා පැමිණීමට පෙර සේවා දැල් මීට වසර 10 කට පෙර වඩා හොඳ වනු ඇතැයි මගේ මතය ප්‍රකාශ කිරීමට මට අවශ්‍යය. මගේ දෘෂ්ටිකෝණය අනෙක් අයට වඩා හොඳ හෝ නරක යැයි මම නොකියමි, නමුත් සේවා දැල් තරමක් සංකීර්ණ සතුන් බැවින්, බහුවිධ දෘෂ්ටි කෝණයන් ඒවා වඩා හොඳින් තේරුම් ගැනීමට උපකාරී වේ.
මම ඩොට්ක්ලවුඩ් වේදිකාව ගැන කතා කරමි, එය ක්ෂුද්ර සේවා සියයකට වඩා ගොඩනගා ඇති අතර බහාලුම්වල යෙදුම් දහස් ගණනකට සහය දක්වයි. එය සංවර්ධනය කිරීමේදී සහ දියත් කිරීමේදී අප මුහුණ දුන් අභියෝග සහ සේවා දැල් උපකාර විය හැකි (හෝ නොවීමට) හැකි ආකාරය මම පැහැදිලි කරන්නම්.
dotCloud ඉතිහාසය
මම දැනටමත් dotCloud හි ඉතිහාසය සහ මෙම වේදිකාව සඳහා ගෘහ නිර්මාණ ශිල්පය තෝරා ගැනීම ගැන ලියා ඇත, නමුත් ජාල ස්ථරය ගැන බොහෝ දේ කතා කර නැත. ඔබට කියවීමට අවශ්ය නැතිනම් dotCloud ගැන, මෙන්න එහි සාරාංශය: එය PaaS වේදිකාවක්-සේවාවක් වන අතර එය සේවාලාභීන්ට පුළුල් පරාසයක යෙදුම් (Java, PHP, Python...) ධාවනය කිරීමට ඉඩ සලසයි, පුළුල් පරාසයක දත්ත සේවා සඳහා සහය දක්වයි ( MongoDB, MySQL, Redis...) සහ Heroku වැනි කාර්ය ප්‍රවාහයක්: ඔබ ඔබේ කේතය වේදිකාවට උඩුගත කරයි, එය බහාලුම් රූප ගොඩනඟා ඒවා යොදවයි.
ඩොට්ක්ලවුඩ් වේදිකාවට ගමනාගමනය යැවූ ආකාරය මම ඔබට කියමි. එය විශේෂයෙන් සිසිල් වූ නිසා නොව (පද්ධතිය එහි කාලය සඳහා හොඳින් ක්රියාත්මක වුවද!), නමුත් මූලික වශයෙන් නවීන මෙවලම් ආධාරයෙන්, එවැනි සැලසුමක් ගමන් කිරීමට මාර්ගයක් අවශ්ය නම්, නිහතමානී කණ්ඩායමකට කෙටි කාලයක් තුළ පහසුවෙන් ක්රියාත්මක කළ හැකිය. ක්ෂුද්ර සේවා පොකුරක් හෝ යෙදුම් පොකුරක් අතර ගමනාගමනය. මේ අනුව, ඔබට විකල්ප සංසන්දනය කළ හැකිය: ඔබ සියල්ල ඔබම සංවර්ධනය කළහොත් හෝ පවතින සේවා දැලක් භාවිතා කරන්නේ නම් කුමක් සිදුවේද? සම්මත තේරීම: ඔබම සාදන්න හෝ මිලදී ගන්න.
සත්කාරක යෙදුම් සඳහා මාර්ගගත කිරීම
dotCloud හි යෙදුම් HTTP සහ TCP අන්ත ලක්ෂ්‍ය නිරාවරණය කළ හැක.
HTTP අන්ත ලක්ෂ්‍ය load balancer පොකුරු වින්‍යාසයට ගතිකව එකතු කර ඇත . මෙය අද සම්පත් කරන දෙයට සමානය Kubernetes හි සහ load balancer වැනි .
dotCloud load balancers වෙත වසම් නාම ලකුණු ලබා දී, සුදුසු වසම් හරහා සේවාදායකයන් HTTP අන්ත ලක්ෂ්‍ය වෙත සම්බන්ධ වේ. විශේෂ දෙයක් නැහැ.
TCP අන්ත ලක්ෂ්‍ය පෝට් අංකයක් සමඟ සම්බන්ධ වන අතර, එය පරිසර විචල්‍ය හරහා එම තොගයේ ඇති සියලුම බහාලුම් වෙත යවනු ලැබේ.
සේවාලාභීන්ට සුදුසු සත්කාරක නාමය (gateway-X.dotcloud.com වැනි දෙයක්) සහ තොට අංකය භාවිතයෙන් TCP අන්ත ලක්ෂ්‍ය වෙත සම්බන්ධ විය හැක.
මෙම සත්කාරක නාමය "nats" සේවාදායක පොකුරට විසඳයි (සම්බන්ධ නොවේ ) එමඟින් ලැබෙන TCP සම්බන්ධතා නිවැරදි බහාලුම් වෙත යොමු කරනු ඇත (හෝ, බර-සමතුලිත සේවා සම්බන්ධයෙන්, නිවැරදි බහාලුම් වෙත).
ඔබ Kubernetes ගැන හුරුපුරුදු නම්, මෙය ඔබට සේවා ගැන මතක් කර දෙනු ඇත .
dotCloud වේදිකාවේ සමාන සේවාවන් කිසිවක් නොතිබුණි : සරල බව සඳහා, සේවා සඳහා ප්රවේශය වේදිකාවේ ඇතුළත සහ පිටත යන දෙකම එකම ආකාරයෙන් සිදු විය.
සෑම දෙයක්ම ඉතා සරලව සංවිධානය කර ඇත: HTTP සහ TCP මාර්ගගත ජාලයන්හි මුල් ක්රියාත්මක කිරීම් බොහෝ විට පයිතන් පේළි සිය ගණනක් පමණක් විය. වේදිකාවේ වර්ධනය සහ අමතර අවශ්‍යතා මතුවීමත් සමඟ පිරිපහදු කර ඇති සරල (මම කියන්නම්, බොළඳ) ඇල්ගොරිතම.
පවතින කේතය පුළුල් ලෙස ප්‍රතිනිර්මාණය කිරීම අවශ්ය නොවීය. විශේෂයෙන්ම, පරිසර විචල්‍ය හරහා ලබාගත් ලිපිනය සෘජුවම භාවිතා කළ හැක.
මෙය නවීන සේවා දැලකින් වෙනස් වන්නේ කෙසේද?
සීමා සහිතයි දෘශ්‍යතාව. අපට TCP රවුටින් දැල් සඳහා කිසිඳු ප්‍රමිතිකයක් නොතිබුණි. HTTP මාර්ගගත කිරීම සම්බන්ධයෙන් ගත් කල, වඩාත් මෑත සංස්කරණවල දෝෂ කේත සහ ප්‍රතිචාර කාලයන් සහිත සවිස්තරාත්මක HTTP ප්‍රමිතික ඇත, නමුත් නවීන සේවා දැල් ඊටත් වඩා ඉදිරියට යයි, උදාහරණයක් ලෙස Prometheus වැනි ප්‍රමිතික එකතු කිරීමේ පද්ධති සමඟ ඒකාබද්ධ කිරීම සපයයි.
දෘශ්‍යතාව වැදගත් වන්නේ මෙහෙයුම් දෘෂ්ටි කෝණයෙන් (ගැටලු නිරාකරණය කිරීමට) පමණක් නොව, නව විශේෂාංග නිකුත් කරන විටය. ආරක්ෂාව ගැන කතා කරනවා и .
මාර්ගගත කිරීමේ කාර්යක්ෂමතාව ද සීමිත වේ. dotCloud routing mesh තුළ, සියලුම ගමනාගමනය සඳහා කැපවූ routing nodes පොකුරක් හරහා යාමට සිදු විය. මෙයින් අදහස් කළේ බහු AZ (ලබා ගත හැකි කලාපය) මායිම් තරණය කළ හැකි බවත් ප්‍රමාදයේ සැලකිය යුතු වැඩි වීමක් බවත්ය. එක් පිටුවකට SQL විමසුම් සියයකට වඩා සෑදූ සහ එක් එක් විමසුම සඳහා SQL සේවාදායකයට නව සම්බන්ධතාවයක් විවෘත කළ දෝශ නිරාකරණ කේතය මට මතකයි. දේශීයව ක්රියාත්මක වන විට, පිටුව ක්ෂණිකව පූරණය වේ, නමුත් dotCloud මත එය පූරණය වීමට තත්පර කිහිපයක් ගත වේ, මන්ද සෑම TCP සම්බන්ධතාවයකටම (සහ පසුව ඇති SQL විමසුමට) මිලි තත්පර දස ගණනක් ගත වේ. මෙම විශේෂිත අවස්ථාවෙහිදී, අඛණ්ඩ සම්බන්ධතා ගැටළුව විසඳා ඇත.
එවැනි ගැටළු සමඟ කටයුතු කිරීමේදී නවීන සේවා දැල් වඩා හොඳය. පළමුවෙන්ම, ඔවුන් සම්බන්ධතා මාර්ගගත කර ඇත්දැයි පරීක්ෂා කරති මූලාශ්රය තුළ. තාර්කික ප්රවාහය සමාන වේ: клиент → меш → сервис, නමුත් දැන් දැල දේශීයව ක්රියා කරන අතර දුරස්ථ නෝඩ් වල නොවේ, එබැවින් සම්බන්ධතාවය клиент → меш දේශීය සහ ඉතා වේගවත් (මිලි තත්පර වෙනුවට මයික්‍රො තත්පර).
නවීන සේවා දැල් ද ස්මාර්ට් බර තුලනය කිරීමේ ඇල්ගොරිතම ක්රියාත්මක කරයි. පසුපෙළවල සෞඛ්‍යය නිරීක්ෂණය කිරීමෙන්, වඩා හොඳ සමස්ත කාර්ය සාධනයක් ඇති කරමින්, වේගවත් පසුබිම් වෙත වැඩි තදබදයක් යැවිය හැක.
Безопасность ද වඩා හොඳය. dotCloud routing mesh සම්පූර්ණයෙන්ම EC2 Classic මත ක්රියාත්මක වූ අතර ගමනාගමනය සංකේතනය නොකළේය (යමෙකු EC2 ජාල ගමනාගමනයට ස්නයිෆර් එකක් දැමීමට සමත් වූවා නම්, ඔබ දැනටමත් විශාල කරදරයක සිටී යන උපකල්පනය යටතේ). නවීන සේවා දැල් අපගේ සියලු ගමනාගමනය විනිවිද පෙනෙන ලෙස ආරක්ෂා කරයි, උදාහරණයක් ලෙස, අන්‍යෝන්‍ය TLS සත්‍යාපනය සහ පසුව සංකේතනය සමඟ.
වේදිකා සේවා සඳහා රථවාහන මාර්ගගත කිරීම
හරි, අපි යෙදුම් අතර ගමනාගමනය ගැන සාකච්ඡා කර ඇත, නමුත් dotCloud වේදිකාව ගැන කුමක් කිව හැකිද?
වේදිකාවම විවිධ කාර්යයන් සඳහා වගකිව යුතු ක්ෂුද්ර සේවා සියයකින් පමණ සමන්විත විය. ඇතැමෙක් අන්‍යයන්ගේ ඉල්ලීම් පිළිගනිමින් සිටි අතර ඇතැමෙක් වෙනත් සේවාවලට සම්බන්ධ වූ නමුත් තමන්ම සම්බන්ධතා භාර නොගත් පසුබිම් සේවකයන් වූහ. අවස්ථා දෙකේදීම, සෑම සේවාවක්ම එයට සම්බන්ධ වීමට අවශ්ය ලිපිනවල අවසාන ලක්ෂ්‍ය දැන සිටිය යුතුය.
බොහෝ ඉහළ මට්ටමේ සේවාවන් ඉහත විස්තර කර ඇති මාර්ග ජාලය භාවිතා කළ හැක. ඇත්ත වශයෙන්ම, dotCloud ක්ෂුද්ර සේවා XNUMXකට වඩා වැඩි ප්‍රමාණයක් dotCloud වේදිකාවේම සාමාන්‍ය යෙදුම් ලෙස යොදවා ඇත. නමුත් අඩු මට්ටමේ සේවා සඳහා (විශේෂයෙන්, මෙම රවුටින් දැල් ක්රියාත්මක කරන අයට) වඩා සරල දෙයක් අවශ්ය විය, අඩු පරායත්තතා (ඔවුන්ට වැඩ කිරීමට තමන් මත යැපීමට නොහැකි වූ නිසා - හොඳ පරණ කුකුල් මස් සහ බිත්තර ගැටලුව).
මෙම පහත් මට්ටමේ අත්‍යාවශ්‍ය සේවා යොදවා ඇත්තේ ප්‍රධාන නෝඩ් කිහිපයක සෘජුවම බහාලුම් ධාවනය කිරීමෙනි. ඒ සමගම, සම්මත වේදිකා සේවාවන් සම්බන්ධ නොවීය: සම්බන්ධකය, උපලේඛන සහ ධාවකය. ඔබට නවීන බහාලුම් වේදිකා සමඟ සංසන්දනය කිරීමට අවශ්ය නම්, එය පාලන තලයක් දියත් කිරීම වැනි ය docker run කාර්යය Kubernetes වෙත පැවරීම වෙනුවට කෙලින්ම නෝඩ් මත. එය සංකල්පයෙන් තරමක් සමාන ය , භාවිතා කරන හෝ ස්වාධීන පොකුරක් ආරම්භ කරන විට.
මෙම සේවාවන් සරල සහ ගොරෝසු ආකාරයෙන් නිරාවරණය විය: YAML ගොනුවක් ඔවුන්ගේ නම් සහ ලිපිනයන් ලැයිස්තුගත කර ඇත; සහ සෑම සේවාදායකයෙකුටම යෙදවීම සඳහා මෙම YAML ගොනුවේ පිටපතක් ගැනීමට සිදු විය.
එක් අතකින්, මෙය අතිශයින්ම විශ්වාසදායකය, මන්ද එයට Zookeeper වැනි බාහිර යතුරු/අගය ගබඩාවක සහය අවශ්ය නොවන බැවිනි (මතක තබා ගන්න, etcd හෝ කොන්සල් එකල නොසිටියේය). අනෙක් අතට, එය සේවාවන් ගෙනයාමට අපහසු විය. චලනයක් සිදු කරන සෑම අවස්ථාවකම, සියලුම සේවාලාභීන්ට යාවත්කාලීන YAML ගොනුවක් ලබා ගැනීමට සිදු විය (සහ නැවත පූරණය විය හැකි). ඉතා සුවපහසු නොවේ!
පසුව, අපි එක් එක් සේවාදායකයා දේශීය ප්‍රොක්සි සේවාදායකයකට සම්බන්ධ වන නව යෝජනා ක්‍රමයක් ක්රියාත්මක කිරීමට පටන් ගත්තෙමු. ලිපිනය සහ වරාය වෙනුවට, එය සේවාවේ වරාය අංකය පමණක් දැන ගැනීමට අවශ්ය වන අතර, හරහා සම්බන්ධ කරන්න localhost. දේශීය ප්‍රොක්සි මෙම සම්බන්ධතාවය හසුරුවන අතර එය සත්‍ය සේවාදායකය වෙත යොමු කරයි. දැන් පසුපෙළ වෙනත් යන්ත්‍රයකට හෝ පරිමාණයට ගෙන යාමේදී, සියලුම සේවාදායකයින් යාවත්කාලීන කිරීම වෙනුවට, මෙම සියලුම දේශීය ප්‍රොක්සි පමණක් යාවත්කාලීන කළ යුතුය; සහ නැවත ආරම්භ කිරීම තවදුරටත් අවශ්ය නොවේ.
(TLS සම්බන්ධතා වල ගමනාගමනය සංග්‍රහ කිරීමට සහ ලැබෙන පැත්තේ වෙනත් ප්‍රොක්සි සේවාදායකයක් ස්ථාපනය කිරීමටත්, ලැබෙන සේවාවේ සහභාගීත්වයෙන් තොරව TLS සහතික පරීක්ෂා කිරීමටත් සැලසුම් කර ඇත, එය සම්බන්ධතා පිළිගැනීමට පමණක් වින්‍යාස කර ඇත. localhost. ඒ ගැන වැඩි විස්තර පසුව).
මෙය බොහෝ දුරට සමාන ය Airbnb වෙතින්, නමුත් සැලකිය යුතු වෙනස නම් SmartStack ක්රියාත්මක කර නිෂ්පාදනය සඳහා යෙදවීමයි, dotCloud හි අභ්‍යන්තර මාර්ගගත පද්ධතිය dotCloud Docker බවට පත් වූ විට කොටු වී තිබීමයි.
මම පුද්ගලිකව SmartStack Istio, Linkerd සහ Consul Connect වැනි පද්ධතිවල පූර්වගාමීන්ගෙන් එකක් ලෙස සලකමි, මන්ද ඒවා සියල්ලම එකම රටාවක් අනුගමනය කරයි:
- සෑම නෝඩයකම ප්‍රොක්සියක් ධාවනය කරන්න.
- සේවාදායකයින් ප්‍රොක්සි වෙත සම්බන්ධ වේ.
- පසුපෙළ වෙනස් වන විට පාලන තලය ප්‍රොක්සි වින්‍යාසය යාවත්කාලීන කරයි.
- … ලාභයක්!
නවීන සේවා දැල් ක්රියාත්මක කිරීම
අද අපට සමාන ජාලයක් ක්රියාත්මක කිරීමට අවශ්ය නම්, අපට සමාන මූලධර්ම භාවිතා කළ හැකිය. උදාහරණයක් ලෙස, අභ්‍යවකාශයේ ඇති ලිපිනයන්ට සේවා නම් සිතියම්ගත කිරීමෙන් අභ්‍යන්තර DNS කලාපයක් සකසන්න 127.0.0.0/8. ඉන්පසු එක් එක් සේවා ලිපිනයෙහි (එම උපජාලයේ) සම්බන්ධතා පිළිගනිමින්, එක් එක් පොකුරු නෝඩය මත HAProxy ධාවනය කරන්න. 127.0.0.0/8) සහ භාරය සුදුසු පසුබිම් වෙත හරවා යැවීම/ තුලනය කිරීම. HAProxy වින්‍යාසය කළමනාකරණය කළ හැක , ඔබට etcd හෝ Consul හි පසුපෙළ තොරතුරු ගබඩා කිරීමට සහ අවශ්ය විටදී ස්වයංක්‍රීයව යාවත්කාලීන වින්‍යාසය HAProxy වෙත තල්ලු කිරීමට ඉඩ සලසයි.
ඉස්තියෝ වැඩ කරන්නේ මෙහෙමයි! නමුත් සමහර වෙනස්කම් සමඟ:
- භාවිතා කරයි HAProxy වෙනුවට.
- etcd හෝ Consul වෙනුවට Kubernetes API හරහා පසුපෙළ වින්‍යාසය සුරකියි.
- 127.0.0.0/8 වෙනුවට අභ්‍යන්තර උපජාලයේ (Kubernetes ClusterIP ලිපින) සේවාවන්ට ලිපින වෙන් කරනු ලැබේ.
- සේවාලාභියා සහ සේවාදායකයන් අතර අන්‍යෝන්‍ය TLS සත්‍යාපනය එක් කිරීමට අමතර සංරචකයක් (Citadel) ඇත.
- පරිපථ කඩනය, බෙදා හරින ලද ලුහුබැඳීම, කැනරි යෙදවීම වැනි නව විශේෂාංග සඳහා සහය දක්වයි.
සමහර වෙනස්කම් ඉක්මනින් බලමු.
නියෝජිත ප්‍රොක්සි
එන්වෝයි ප්‍රොක්සි ලියා ඇත්තේ කුලී රථ වෙළඳපොලේ Uber හි තරඟකරු Lyft විසිනි - දළ වශයෙන්. එක්.]. එය වෙනත් ප්‍රොක්සිවලට (උදා: HAProxy, Nginx, Traefik...) බොහෝ ආකාරවලින් සමාන වේ, නමුත් වෙනත් ප්‍රොක්සිවලට නොමැති විශේෂාංග ඔවුන්ට අවශ්ය වූ නිසා සහ දිගු කිරීමට වඩා අලුත් එකක් සෑදීම වඩා සංවේදී බව පෙනෙන නිසා Lyft ඔවුන්ගේම ලියා ඇත. පවතින එකක්.
නියෝජිතයා විසින්ම භාවිතා කළ හැකිය. මට වෙනත් සේවාවන්ට සම්බන්ධ වීමට අවශ්ය නිශ්චිත සේවාවක් තිබේ නම්, මට එය එන්වෝයි වෙත සම්බන්ධ වීමට සකසා ගත හැකි අතර, දෘශ්‍යතාව වැනි විශිෂ්ට අමතර දේ ලබා ගන්නා අතරම, වෙනත් සේවාවන්හි පිහිටීම සමඟ ගතිකව වින්‍යාස කිරීම සහ නැවත සකස් කළ හැකිය. අභිරුචි සේවාදායක පුස්තකාලයක් හෝ ඇමතුම් ලුහුබැඳීමේ කේතයට එන්නත් කිරීම වෙනුවට, අපි එන්වෝයි වෙත ගමනාගමනය යවන අතර, එය අප සඳහා ප්‍රමිතික රැස් කරයි.
නමුත් එන්වෝයිට වැඩ කරන්නත් පුළුවන් දත්ත තලය (දත්ත තලය) සේවා දැල සඳහා. මෙයින් අදහස් කරන්නේ දැන් මෙම සේවා දැල සඳහා, එන්වෝයි වින්‍යාස කර ඇති බවයි පාලන තලය (පාලක තලය).
පාලන තලය
පාලන තලය තුළ, Istio Kubernetes API මත රඳා පවතී. මෙය confd භාවිතා කිරීමට වඩා බෙහෙවින් වෙනස් නොවේ, දත්ත ගබඩාවේ යතුරු කට්ටලයක් සෙවීමට etcd හෝ කොන්සල් මත රඳා පවතී. ඉස්ටියෝ Kubernetes API හරහා Kubernetes සම්පත් කට්ටලයක් හරහා බලයි.
මේ අතර ඉන් පසුව: මට පුද්ගලිකව මෙය ප්‍රයෝජනවත් විය එහි කියවෙන්නේ:
Kubernetes API සේවාදායකය ගබඩා කිරීම, අනුවාද කිරීම, වලංගු කිරීම, යාවත්කාලීන කිරීම සහ API සම්පත් අර්ථ දැක්වීම් සපයන "මෝඩ සේවාදායකයක්" වේ.
Istio නිර්මාණය කර ඇත්තේ Kubernetes සමඟ වැඩ කිරීමට ය; සහ ඔබට එය Kubernetes වලින් පිටත භාවිතා කිරීමට අවශ්ය නම්, ඔබ Kubernetes API සේවාදායකයේ (සහ etcd උපකාරක සේවාව) උදාහරණයක් ආරම්භ කළ යුතුය.
සේවා ලිපින
Istio රඳා පවතින්නේ Kubernetes වෙන් කරන ClusterIP ලිපින මතයි, එබැවින් Istio සේවාවන්ට අභ්‍යන්තර ලිපිනයක් ලැබේ (පරාසයේ නොවේ 127.0.0.0/8).
Istio නොමැතිව Kubernetes පොකුරක් තුළ නිශ්චිත සේවාවක් සඳහා ClusterIP ලිපිනයකට ගමනාගමනය kube-proxy මගින් බාධා කර ප්‍රොක්සියේ පසුපස කෙළවරට යවනු ලැබේ. ඔබ තාක්ෂණික විස්තර ගැන උනන්දුවක් දක්වන්නේ නම්, kube-proxy විසින් ClusterIP ලිපිනයට යන සම්බන්ධතා වල ගමනාන්ත IP ලිපින නැවත ලිවීමට iptables රීති (හෝ IPVS load balancers, එය වින්‍යාස කර ඇති ආකාරය අනුව) සකසයි.
Kubernetes පොකුරක් මත Istio ස්ථාපනය කළ පසු, කන්ටේනරයක් හඳුන්වා දීමෙන් දී ඇති පාරිභෝගිකයෙකුට හෝ සම්පූර්ණ නාම අවකාශය සඳහා එය පැහැදිලිව සක්‍රීය කරන තෙක් කිසිවක් වෙනස් නොවේ. sidecar අභිරුචි කරල් වලට. මෙම කන්ටේනරය එන්වෝයි අවස්ථාවක් ආරම්භ කර වෙනත් සේවාවන් වෙත යන ගමනාගමනයට බාධා කිරීමට සහ එම ගමනාගමනය එන්වෝයි වෙත හරවා යැවීමට iptables නීති මාලාවක් සකසනු ඇත.
Kubernetes DNS සමඟ ඒකාබද්ධ වූ විට, මෙයින් අදහස් කරන්නේ අපගේ කේතය සේවා නාමයෙන් සම්බන්ධ විය හැකි අතර සෑම දෙයක්ම "පමණක් ක්රියා කරයි" යන්නයි. වෙනත් වචන වලින් කිවහොත්, අපගේ කේතය වැනි විමසුම් නිකුත් කරයි http://api/v1/users/4242එවිට api සඳහා වූ ඉල්ලීම විසඳන්න 10.97.105.48, iptables රීති 10.97.105.48 සිට සම්බන්ධතා වලට බාධා කර ඒවා දේශීය එන්වෝයි ප්‍රොක්සිය වෙත හරවා යවයි, එමඟින් ඉල්ලීම සැබෑ API පසුපෙළ වෙත යොමු කරනු ඇත. පිව්!
අමතර සැරසිලි
Istio mTLS (අන්‍යෝන්‍ය TLS) හරහා අන්තයේ සිට අවසානය දක්වා සංකේතනය සහ සත්‍යාපනය ද සපයයි. කියන සංරචකය සිටඩෙල්.
සංරචකයක් ද ඇත මික්සර්, කුමන නියෝජිතයෙකුට ඉල්ලා සිටිය හැක එකිනෙකා ශීර්ෂයන්, පසුපෙළ පැටවීම, ආදී විවිධ සාධක මත පදනම්ව එම ඉල්ලීම ගැන විශේෂ තීරණයක් ගැනීමට ඉල්ලීම... (කරදර නොවන්න: Mixer එක දිගටම ක්රියා කිරීමට බොහෝ මෙවලම් ඇත, එය බිඳ වැටුණත්, එන්වෝයි දිගටම වැඩ කරනු ඇත ප්‍රොක්සියක් ලෙස).
තවද, ඇත්ත වශයෙන්ම, අපි දෘශ්‍යතාව සඳහන් කළෙමු: බෙදා හරින ලද ලුහුබැඳීම් සපයන අතරතුර නියෝජිතයා විශාල ප්‍රමිතික ප්‍රමාණයක් රැස් කරයි. ක්ෂුද්ර සේවා ගෘහ නිර්මාණ ශිල්පය තුළ, තනි API ඉල්ලීමක් ක්ෂුද්ර සේවා A, B, C සහ D හරහා යාමට අවශ්ය නම්, ලොගින් වූ පසු, බෙදා හරින ලද ලුහුබැඳීම ඉල්ලීමට අනන්‍ය හඳුනාගැනීමක් එක් කරන අතර මෙම සියලු ක්ෂුද්ර සේවා සඳහා උප ඉල්ලීම් හරහා මෙම හඳුනාගැනීම ගබඩා කරයි. ඔබට අදාළ සියලුම ඇමතුම්, ඒවායේ ප්‍රමාදයන් ආදිය ග්‍රහණය කර ගැනීමට.
සංවර්ධනය කරන්න හෝ මිලදී ගන්න
Istio සංකීර්ණ පද්ධතියක් ලෙස කීර්තියක් ඇත. ඊට ප්‍රතිවිරුද්ධව, මෙම සටහනේ ආරම්භයේ මා විස්තර කළ රවුටින් දැල් තැනීම දැනට පවතින මෙවලම් සමඟ සාපේක්ෂව පහසුය. ඉතින්, ඒ වෙනුවට ඔබේම සේවා දැලක් නිර්මාණය කිරීම අර්ථවත්ද?
අපට නිහතමානී අවශ්‍යතා තිබේ නම් (අපට දෘශ්‍යතාව, පරිපථ කඩනයක් සහ වෙනත් සියුම්කම් අවශ්ය නොවේ), එවිට අපගේම මෙවලමක් සංවර්ධනය කිරීම ගැන සිතුවිලි පැමිණේ. නමුත් අපි Kubernetes භාවිතා කරන්නේ නම්, එය අවශ්ය නොවනු ඇත, මන්ද Kubernetes දැනටමත් සේවා සොයා ගැනීම සහ බර සමතුලිත කිරීම සඳහා මූලික මෙවලම් සපයන බැවිනි.
නමුත් අපට උසස් අවශ්‍යතා තිබේ නම්, සේවා දැලක් "මිලදී ගැනීම" වඩා හොඳ විකල්පයක් ලෙස පෙනේ. (Istio විවෘත මූලාශ්‍රයක් බැවින් මෙය සැමවිටම "මිලදී ගැනීමක්" නොවේ, නමුත් එය තේරුම් ගැනීමට, යෙදවීමට සහ කළමනාකරණය කිරීමට අපට තවමත් ඉංජිනේරු කාලය ආයෝජනය කිරීමට අවශ්ය වේ.)
තෝරාගත යුත්තේ කුමක්ද: Istio, Linkerd හෝ Consul Connect?
අපි මෙතෙක් කතා කළේ ඉස්තියෝ ගැන පමණයි, නමුත් එය එකම සේවා දැලක් නොවේ. ජනප්රිය විකල්පය වන්නේ , නමුත් තවත් ඇත .
තෝරාගත යුත්තේ කුමක්ද?
ඇත්තම කිව්වොත් මම දන්නේ නැහැ. මෙම ප්‍රශ්නයට පිළිතුරු දීමට තරම් මා මේ මොහොතේ මා සලකන්නේ නැත. කිහිපයක් ඇත මෙම මෙවලම් සංසන්දනය කිරීම සහ පවා .
එක් පොරොන්දු ප්‍රවේශයක් වන්නේ එවැනි මෙවලමක් භාවිතා කිරීමයි . එය සේවා දැල් මගින් සපයන API සරල කිරීමට සහ ඒකාබද්ධ කිරීමට වියුක්ත ස්ථරයක් ක්රියාත්මක කරයි. විවිධ සේවා දැල් වල විශේෂිත (සහ, මගේ මතය අනුව, සාපේක්ෂ වශයෙන් සංකීර්ණ) API ඉගෙන ගන්නවා වෙනුවට, අපට සරල SuperGloo ඉදිකිරීම් භාවිතා කළ හැකිය - සහ HTTP අතුරුමුහුණත් සහ පසුපෙළ විස්තර කරන අතරමැදි වින්‍යාස ආකෘතියක් ඇති පරිදි පහසුවෙන් එකින් එකකට මාරු විය හැක. Nginx, HAProxy, Traefik, Apache සඳහා සැබෑ වින්‍යාසය ජනනය කිරීමේ හැකියාව ඇත…
මම Istio සහ SuperGloo සමඟ ටිකක් ක්‍රීඩා කළ අතර, ඊළඟ ලිපියෙන් මට SuperGloo භාවිතයෙන් දැනට පවතින පොකුරකට Istio හෝ Linkerd එකතු කරන්නේ කෙසේද සහ දෙවැන්න එහි කාර්යය කරන්නේ කෙසේද යන්න පෙන්වීමට අවශ්‍යයි, එනම්, එය ඔබට මාරු වීමට ඉඩ සලසයි. වින්‍යාසයන් නැවත ලිවීමකින් තොරව එක් සේවා දැලක් තවත් එකකට.
මූලාශ්රය: www.habr.com