ઇન્ટરનેટ પર kucha લેખો о સેવા મેશ (સેવા મેશ), અને અહીં બીજું છે. હુરે! પણ શા માટે? પછી, હું મારો અભિપ્રાય વ્યક્ત કરવા માંગુ છું કે ડોકર અને કુબરનેટ્સ જેવા કન્ટેનર પ્લેટફોર્મના આગમન પહેલાં, 10 વર્ષ પહેલાં સર્વિસ મેશ દેખાય તો તે વધુ સારું હોત. હું એમ નથી કહેતો કે મારો દૃષ્ટિકોણ અન્ય કરતાં વધુ સારો કે ખરાબ છે, પરંતુ સર્વિસ મેશ ખૂબ જટિલ પ્રાણીઓ હોવાથી, બહુવિધ દૃષ્ટિકોણ તેમને વધુ સારી રીતે સમજવામાં મદદ કરશે.

હું ડોટક્લાઉડ પ્લેટફોર્મ વિશે વાત કરીશ, જે સોથી વધુ માઇક્રોસર્વિસિસ પર બનેલ છે અને હજારો કન્ટેનરાઇઝ્ડ એપ્લિકેશન્સને સપોર્ટ કરે છે. હું તેને વિકસાવવા અને લોન્ચ કરવામાં અમને જે પડકારોનો સામનો કરવો પડ્યો હતો અને સેવા મેશ કેવી રીતે મદદ કરી શકે (અથવા ન કરી શકે) તે સમજાવીશ.

ડોટક્લાઉડનો ઇતિહાસ

મેં ડોટક્લાઉડના ઇતિહાસ અને આ પ્લેટફોર્મ માટેની આર્કિટેક્ચર પસંદગીઓ વિશે લખ્યું છે, પરંતુ મેં નેટવર્ક સ્તર વિશે વધુ વાત કરી નથી. જો તમે વાંચનમાં ડૂબકી મારવા માંગતા નથી છેલ્લો લેખ ડોટક્લાઉડ વિશે, અહીં ટૂંકમાં ભાવાર્થ છે: તે PaaS પ્લેટફોર્મ-એ-એ-સર્વિસ છે જે ગ્રાહકોને ડેટાની વિશાળ શ્રેણી માટે સપોર્ટ સાથે વિશાળ શ્રેણીની એપ્લિકેશન્સ (જાવા, PHP, પાયથોન...) ચલાવવાની મંજૂરી આપે છે. સેવાઓ (MongoDB, MySQL, Redis...) અને વર્કફ્લો જેમ કે Heroku: તમે તમારો કોડ પ્લેટફોર્મ પર અપલોડ કરો છો, તે કન્ટેનર ઈમેજીસ બનાવે છે અને તેનો ઉપયોગ કરે છે.

હું તમને કહીશ કે ટ્રાફિકને ડોટક્લાઉડ પ્લેટફોર્મ પર કેવી રીતે નિર્દેશિત કરવામાં આવ્યો હતો. એટલા માટે નહીં કે તે ખાસ કરીને ઠંડુ હતું (જોકે સિસ્ટમ તેના સમય માટે સારી રીતે કામ કરતી હતી!), પરંતુ મુખ્યત્વે કારણ કે આધુનિક સાધનો સાથે આવી ડિઝાઇનને સામાન્ય ટીમ દ્વારા ટૂંકા સમયમાં સરળતાથી અમલમાં મૂકી શકાય છે જો તેમને ટોળા વચ્ચે ટ્રાફિકને રૂટ કરવા માટે માર્ગની જરૂર હોય. માઇક્રોસર્વિસિસ અથવા એપ્લિકેશનનો સમૂહ. આ રીતે, તમે વિકલ્પોની તુલના કરી શકો છો: જો તમે બધું જાતે વિકસિત કરો છો અથવા હાલની સેવા મેશનો ઉપયોગ કરો છો તો શું થશે. પ્રમાણભૂત પસંદગી એ છે કે તેને જાતે બનાવો અથવા તેને ખરીદો.

હોસ્ટ કરેલ એપ્લિકેશનો માટે ટ્રાફિક રૂટીંગ

ડોટક્લાઉડ પરની એપ્લિકેશનો એચટીટીપી અને ટીસીપી એન્ડપોઇન્ટ્સને ઉજાગર કરી શકે છે.

HTTP અંતિમ બિંદુઓ લોડ બેલેન્સર ક્લસ્ટર ગોઠવણીમાં ગતિશીલ રીતે ઉમેરવામાં આવે છે હિપચે. આજના સંસાધનો જે કરે છે તેના જેવું જ છે પ્રવેશ કુબરનેટ્સમાં અને લોડ બેલેન્સર જેવા ટ્રેફિક.

ક્લાયન્ટ યોગ્ય ડોમેન્સ દ્વારા HTTP એન્ડપોઇન્ટ્સ સાથે જોડાય છે, જો કે ડોમેન નામ ડોટક્લાઉડ લોડ બેલેન્સર્સ તરફ નિર્દેશ કરે છે. કઈ ખાસ નહિ.

TCP અંતિમ બિંદુઓ પોર્ટ નંબર સાથે સંકળાયેલ છે, જે પછી તે સ્ટેકમાંના તમામ કન્ટેનરને પર્યાવરણ ચલો દ્વારા પસાર કરવામાં આવે છે.

ક્લાયન્ટ યોગ્ય હોસ્ટનામ (ગેટવે-X.dotcloud.com જેવું કંઈક) અને પોર્ટ નંબરનો ઉપયોગ કરીને TCP એન્ડપોઇન્ટ્સ સાથે કનેક્ટ થઈ શકે છે.

આ યજમાનનામ “nats” સર્વર ક્લસ્ટરને ઉકેલે છે (જેનાથી સંબંધિત નથી NATS), જે યોગ્ય કન્ટેનર (અથવા, લોડ-બેલેન્સ્ડ સેવાઓના કિસ્સામાં, યોગ્ય કન્ટેનરમાં) ઇનકમિંગ TCP કનેક્શન્સને રૂટ કરશે.

જો તમે કુબરનેટ્સથી પરિચિત છો, તો આ કદાચ તમને સેવાઓની યાદ અપાવશે નોડપોર્ટ.

ડોટક્લાઉડ પ્લેટફોર્મ પર કોઈ સમકક્ષ સેવાઓ ન હતી ક્લસ્ટરઆઈપી: સરળતા માટે, પ્લેટફોર્મની અંદર અને બહાર બંને રીતે સેવાઓનો ઉપયોગ એ જ રીતે કરવામાં આવતો હતો.

બધું એકદમ સરળ રીતે ગોઠવવામાં આવ્યું હતું: HTTP અને TCP રાઉટીંગ નેટવર્કના પ્રારંભિક અમલીકરણો કદાચ પાયથોનની દરેક લાઇનની થોડીક સો લીટીઓ હતી. સરળ (હું નિષ્કપટ કહીશ) એલ્ગોરિધમ્સ કે જે પ્લેટફોર્મ વધવાથી અને વધારાની જરૂરિયાતો દેખાતી હોવાથી શુદ્ધ કરવામાં આવી હતી.

હાલના કોડના વ્યાપક રિફેક્ટરિંગની જરૂર નહોતી. વિશેષ રીતે, 12 પરિબળ એપ્લિકેશનો પર્યાવરણ ચલો દ્વારા મેળવેલા સરનામાંનો સીધો ઉપયોગ કરી શકે છે.

આ આધુનિક સેવા મેશથી કેવી રીતે અલગ છે?

લિમિટેડ દૃશ્યતા. અમારી પાસે TCP રૂટીંગ મેશ માટે બિલકુલ કોઈ મેટ્રિક્સ નથી. જ્યારે HTTP રૂટીંગની વાત આવે છે, તો પછીના સંસ્કરણોએ ભૂલ કોડ્સ અને પ્રતિભાવ સમય સાથે વિગતવાર HTTP મેટ્રિક્સ રજૂ કર્યા હતા, પરંતુ આધુનિક સેવા મેશ વધુ આગળ વધે છે, ઉદાહરણ તરીકે, પ્રોમિથિયસ જેવી મેટ્રિક્સ કલેક્શન સિસ્ટમ્સ સાથે એકીકરણ પ્રદાન કરે છે.

દૃશ્યતા માત્ર ઓપરેશનલ દ્રષ્ટિકોણથી જ મહત્વપૂર્ણ નથી (સમસ્યાઓનું નિવારણ કરવામાં મદદ કરવા માટે), પણ નવી સુવિધાઓ બહાર પાડતી વખતે પણ. તે સલામત વિશે છે વાદળી-લીલો જમાવટ и કેનેરી જમાવટ.

રૂટીંગ કાર્યક્ષમતા પણ મર્યાદિત છે. ડોટક્લાઉડ રૂટીંગ મેશમાં, તમામ ટ્રાફિકને સમર્પિત રૂટીંગ નોડ્સના ક્લસ્ટરમાંથી પસાર થવું પડતું હતું. આનો અર્થ સંભવિતપણે બહુવિધ AZ (ઉપલબ્ધતા ઝોન) સીમાઓને પાર કરવો અને નોંધપાત્ર રીતે વિલંબિતતામાં વધારો. મને મુશ્કેલીનિવારણ કોડ યાદ છે જે પૃષ્ઠ દીઠ સો કરતાં વધુ SQL ક્વેરીઝ બનાવતો હતો અને દરેક ક્વેરી માટે SQL સર્વર સાથે નવું કનેક્શન ખોલતો હતો. જ્યારે સ્થાનિક રીતે ચાલી રહ્યું હોય, ત્યારે પૃષ્ઠ તરત લોડ થાય છે, પરંતુ ડોટક્લાઉડમાં તે લોડ થવામાં થોડીક સેકંડ લે છે કારણ કે દરેક TCP કનેક્શન (અને અનુગામી SQL ક્વેરી) દસ મિલીસેકન્ડ લે છે. આ ચોક્કસ કિસ્સામાં, સતત જોડાણોએ સમસ્યા હલ કરી.

આવી સમસ્યાઓનો સામનો કરવા માટે આધુનિક સેવા મેશ વધુ સારી છે. સૌ પ્રથમ, તેઓ તપાસ કરે છે કે જોડાણો રૂટ થયેલ છે સ્ત્રોતમાં. તાર્કિક પ્રવાહ સમાન છે: клиент → меш → сервис, પરંતુ હવે મેશ સ્થાનિક રીતે કામ કરે છે અને રિમોટ નોડ્સ પર નહીં, તેથી કનેક્શન клиент → меш સ્થાનિક અને ખૂબ જ ઝડપી છે (મિલિસેકંડને બદલે માઇક્રોસેકન્ડ).

આધુનિક સર્વિસ મેશ સ્માર્ટ લોડ બેલેન્સિંગ એલ્ગોરિધમ્સ પણ અમલમાં મૂકે છે. બેકએન્ડના સ્વાસ્થ્યનું નિરીક્ષણ કરીને, તેઓ ઝડપી બેકએન્ડ પર વધુ ટ્રાફિક મોકલી શકે છે, જેના પરિણામે એકંદર કામગીરીમાં સુધારો થાય છે.

સુરક્ષા વધુ સારું. ડોટક્લાઉડ રૂટીંગ મેશ સંપૂર્ણપણે EC2 ક્લાસિક પર ચાલતું હતું અને ટ્રાફિકને એન્ક્રિપ્ટ કરતું નથી (એ ધારણાને આધારે કે જો કોઈ વ્યક્તિ EC2 નેટવર્ક ટ્રાફિક પર સ્નિફર મૂકવાનું મેનેજ કરે છે, તો તમે પહેલેથી જ મોટી મુશ્કેલીમાં છો). આધુનિક સેવા મેશ અમારા તમામ ટ્રાફિકને પારદર્શક રીતે સુરક્ષિત કરે છે, ઉદાહરણ તરીકે, પરસ્પર TLS પ્રમાણીકરણ અને અનુગામી એન્ક્રિપ્શન સાથે.

પ્લેટફોર્મ સેવાઓ માટે રૂટીંગ ટ્રાફિક

ઠીક છે, અમે એપ્લિકેશનો વચ્ચે ટ્રાફિકની ચર્ચા કરી છે, પરંતુ ડોટક્લાઉડ પ્લેટફોર્મ વિશે શું?

પ્લેટફોર્મમાં વિવિધ કાર્યો માટે જવાબદાર લગભગ સો માઇક્રોસર્વિસિસનો સમાવેશ થતો હતો. કેટલાકે અન્ય લોકોની વિનંતીઓ સ્વીકારી, અને કેટલાક પૃષ્ઠભૂમિ કામદારો હતા કે જેઓ અન્ય સેવાઓ સાથે જોડાયેલા હતા પરંતુ પોતે જોડાણો સ્વીકારતા ન હતા. કોઈ પણ સંજોગોમાં, દરેક સેવાને તેને કનેક્ટ કરવાની જરૂર હોય તેવા સરનામાંના અંતિમ બિંદુઓ જાણતા હોવા જોઈએ.

ઘણી ઉચ્ચ-સ્તરની સેવાઓ ઉપર વર્ણવેલ રૂટીંગ મેશનો ઉપયોગ કરી શકે છે. વાસ્તવમાં, ડોટક્લાઉડની ઘણી સો કરતાં વધુ માઇક્રોસર્વિસિસને ડોટક્લાઉડ પ્લેટફોર્મ પર જ નિયમિત એપ્લિકેશન તરીકે જમાવવામાં આવી છે. પરંતુ ઓછી સંખ્યામાં નિમ્ન-સ્તરની સેવાઓ (ખાસ કરીને જેઓ આ રૂટીંગ મેશને અમલમાં મૂકે છે) ને ઓછા નિર્ભરતા સાથે કંઈક સરળની જરૂર છે (કારણ કે તેઓ કામ કરવા માટે પોતાના પર નિર્ભર ન રહી શકે - સારી જૂની ચિકન અને ઇંડાની સમસ્યા).

આ નિમ્ન-સ્તરની, મિશન-નિર્ણાયક સેવાઓ કેટલાક મુખ્ય ગાંઠો પર સીધા કન્ટેનર ચલાવીને તૈનાત કરવામાં આવી હતી. આ કિસ્સામાં, માનક પ્લેટફોર્મ સેવાઓનો ઉપયોગ કરવામાં આવ્યો ન હતો: લિંકર, શેડ્યૂલર અને રનર. જો તમે આધુનિક કન્ટેનર પ્લેટફોર્મ સાથે સરખામણી કરવા માંગતા હો, તો તે કંટ્રોલ પ્લેન ચલાવવા જેવું છે docker run કુબરનેટ્સને કાર્ય સોંપવાને બદલે સીધા નોડ્સ પર. તે ખ્યાલમાં ખૂબ સમાન છે સ્થિર મોડ્યુલો (પોડ્સ), જેનો તે ઉપયોગ કરે છે kubeadm અથવા bootkube એકલ ક્લસ્ટરને બુટ કરતી વખતે.

આ સેવાઓ સરળ અને અણઘડ રીતે ખુલ્લી કરવામાં આવી હતી: YAML ફાઇલમાં તેમના નામ અને સરનામાની સૂચિ હતી; અને દરેક ક્લાયન્ટે જમાવટ માટે આ YAML ફાઇલની એક નકલ લેવાની હતી.

એક તરફ, તે અત્યંત ભરોસાપાત્ર છે કારણ કે તેને બાહ્ય કી/મૂલ્ય સ્ટોર જેમ કે Zookeeper (યાદ રાખો, etcd અથવા Consul તે સમયે અસ્તિત્વમાં ન હતા) ના સમર્થનની જરૂર નથી. બીજી બાજુ, તેને સેવાઓ ખસેડવાનું મુશ્કેલ બન્યું. દરેક વખતે જ્યારે કોઈ ચાલ કરવામાં આવશે, ત્યારે બધા ક્લાયન્ટ્સને અપડેટ કરેલી YAML ફાઇલ (અને સંભવિત રીબૂટ) પ્રાપ્ત થશે. ખૂબ આરામદાયક નથી!

ત્યારબાદ, અમે એક નવી સ્કીમ અમલમાં મૂકવાનું શરૂ કર્યું, જ્યાં દરેક ક્લાયંટ સ્થાનિક પ્રોક્સી સર્વર સાથે જોડાયેલ. સરનામું અને પોર્ટને બદલે, તેને ફક્ત સેવાનો પોર્ટ નંબર જાણવાની જરૂર છે અને તેના દ્વારા કનેક્ટ થવાની જરૂર છે localhost. સ્થાનિક પ્રોક્સી આ કનેક્શનને હેન્ડલ કરે છે અને તેને વાસ્તવિક સર્વર પર ફોરવર્ડ કરે છે. હવે, જ્યારે બેકએન્ડને અન્ય મશીન પર ખસેડો અથવા સ્કેલિંગ કરો, ત્યારે બધા ક્લાયંટને અપડેટ કરવાને બદલે, તમારે ફક્ત આ તમામ સ્થાનિક પ્રોક્સીને અપડેટ કરવાની જરૂર છે; અને રીબૂટની જરૂર નથી.

(TLS કનેક્શન્સમાં ટ્રાફિકને સમાવી લેવાનું અને અન્ય પ્રોક્સી સર્વરને રિસીવિંગ બાજુ પર મૂકવાનું પણ આયોજન કરવામાં આવ્યું હતું, તેમજ પ્રાપ્ત સેવાની ભાગીદારી વિના TLS પ્રમાણપત્રો ચકાસવા માટે, જે ફક્ત કનેક્શન્સ સ્વીકારવા માટે ગોઠવેલ છે. localhost. આ વિશે પછીથી વધુ).

આ ખૂબ સમાન છે સ્માર્ટસ્ટેક Airbnb થી, પરંતુ નોંધપાત્ર તફાવત એ છે કે SmartStack અમલમાં મુકવામાં આવે છે અને ઉત્પાદનમાં તૈનાત કરવામાં આવે છે, જ્યારે dotCloud ડોકર બન્યું ત્યારે ડોટક્લાઉડની આંતરિક રૂટીંગ સિસ્ટમ શેલ્વ કરવામાં આવી હતી.

હું અંગત રીતે SmartStack ને Istio, Linkerd અને Consul Connect જેવી સિસ્ટમના પુરોગામી માનું છું કારણ કે તે બધા સમાન પેટર્નને અનુસરે છે:

• દરેક નોડ પર પ્રોક્સી ચલાવો.
• ગ્રાહકો પ્રોક્સી સાથે જોડાય છે.
• જ્યારે બેકએન્ડ બદલાય છે ત્યારે કન્ટ્રોલ પ્લેન પ્રોક્સી રૂપરેખાંકનને અપડેટ કરે છે.
• ... નફો!

સર્વિસ મેશનું આધુનિક અમલીકરણ

જો આપણે આજે સમાન ગ્રીડને અમલમાં મૂકવાની જરૂર હોય, તો અમે સમાન સિદ્ધાંતોનો ઉપયોગ કરી શકીએ છીએ. ઉદાહરણ તરીકે, જગ્યામાં સરનામાંઓ સાથે સેવાના નામોને મેપ કરીને આંતરિક DNS ઝોનને ગોઠવો 127.0.0.0/8. પછી ક્લસ્ટરમાં દરેક નોડ પર HAProxy ચલાવો, દરેક સર્વિસ એડ્રેસ પર કનેક્શન સ્વીકારીને (તે સબનેટમાં 127.0.0.0/8) અને લોડને યોગ્ય બેકએન્ડ્સ પર રીડાયરેક્ટ/બેલેન્સિંગ. HAProxy રૂપરેખાંકન નિયંત્રિત કરી શકાય છે confd, તમને etcd અથવા Consul માં બેકએન્ડ માહિતી સંગ્રહિત કરવાની મંજૂરી આપે છે અને જ્યારે જરૂર પડે ત્યારે અપડેટ કરેલ રૂપરેખાંકનને HAProxy પર આપોઆપ દબાણ કરે છે.

આ ઇસ્ટિઓ કેવી રીતે કામ કરે છે તે ખૂબ જ છે! પરંતુ કેટલાક તફાવતો સાથે:

• ઉપયોગ કરે છે રાજદૂત પ્રોક્સી HAProxy ને બદલે.
• વગેરે વગેરે અથવા કોન્સ્યુલને બદલે કુબરનેટ્સ API મારફતે બેકએન્ડ કન્ફિગરેશન સ્ટોર કરે છે.
• સેવાઓને 127.0.0.0/8 ને બદલે આંતરિક સબનેટ (કુબરનેટ્સ ક્લસ્ટરઆઈપી સરનામાંઓ) પર સરનામાં ફાળવવામાં આવે છે.
• ક્લાયંટ અને સર્વર્સ વચ્ચે મ્યુચ્યુઅલ TLS પ્રમાણીકરણ ઉમેરવા માટે વધારાના ઘટક (સિટાડેલ) ધરાવે છે.
• સર્કિટ બ્રેકિંગ, ડિસ્ટ્રિબ્યુટેડ ટ્રેસિંગ, કેનેરી ડિપ્લોયમેન્ટ વગેરે જેવી નવી સુવિધાઓને સપોર્ટ કરે છે.

ચાલો કેટલાક તફાવતો પર એક ઝડપી નજર કરીએ.

રાજદૂત પ્રોક્સી

એન્વોય પ્રોક્સી લિફ્ટ દ્વારા લખવામાં આવી હતી [ટેક્સી માર્કેટમાં ઉબેરના હરીફ - આશરે. લેન]. તે અન્ય પ્રોક્સીઓ (દા.ત. HAProxy, Nginx, Traefik...) માટે ઘણી રીતે સમાન છે, પરંતુ Lyft એ તેમની રચના લખી છે કારણ કે તેમને એવા લક્ષણોની જરૂર હતી જે અન્ય પ્રોક્સીઓમાં અભાવ હતો, અને તે હાલના પ્રોક્સીને લંબાવવાને બદલે નવું બનાવવું વધુ સ્માર્ટ લાગતું હતું.

દૂતનો ઉપયોગ તેના પોતાના પર થઈ શકે છે. જો મારી પાસે કોઈ વિશિષ્ટ સેવા હોય જેને અન્ય સેવાઓ સાથે કનેક્ટ કરવાની જરૂર હોય, તો હું તેને દૂત સાથે કનેક્ટ કરવા માટે રૂપરેખાંકિત કરી શકું છું, અને પછી અન્ય સેવાઓના સ્થાન સાથે દૂતને ગતિશીલ રીતે ગોઠવી અને પુનઃરૂપરેખાંકિત કરી શકું છું, જ્યારે ઘણી બધી મહાન વધારાની કાર્યક્ષમતા, જેમ કે દૃશ્યતા પ્રાપ્ત થાય છે. કસ્ટમ ક્લાયંટ લાઇબ્રેરીને બદલે અથવા કોડમાં કોલ ટ્રેસ ઇન્જેક્ટ કરવાને બદલે, અમે દૂતને ટ્રાફિક મોકલીએ છીએ અને તે અમારા માટે મેટ્રિક્સ એકત્રિત કરે છે.

પરંતુ રાજદૂત તરીકે પણ કામ કરવા સક્ષમ છે ડેટા પ્લેન સેવા મેશ માટે (ડેટા પ્લેન). આનો અર્થ એ છે કે દૂત હવે આ સેવા મેશ માટે ગોઠવેલ છે નિયંત્રણ વિમાન (નિયંત્રણ વિમાન).

નિયંત્રણ વિમાન

કંટ્રોલ પ્લેન માટે, Istio કુબરનેટ્સ API પર આધાર રાખે છે. આ confd નો ઉપયોગ કરતા બહુ અલગ નથી, જે ડેટા સ્ટોરમાં કીના સેટને જોવા માટે etcd અથવા કોન્સલ પર આધાર રાખે છે. Istio Kubernetes સંસાધનોનો સમૂહ જોવા માટે Kubernetes API નો ઉપયોગ કરે છે.

આ અને પછી વચ્ચે: મને અંગત રીતે આ ઉપયોગી લાગ્યું Kubernetes API વર્ણનજે વાંચે છે:

Kubernetes API સર્વર એ "ડમ્બ સર્વર" છે જે API સંસાધનો માટે સ્ટોરેજ, વર્ઝનિંગ, માન્યતા, અપડેટિંગ અને સિમેન્ટિક્સ ઑફર કરે છે.

Istio કુબરનેટ્સ સાથે કામ કરવા માટે રચાયેલ છે; અને જો તમે તેનો ઉપયોગ કુબરનેટ્સની બહાર કરવા માંગો છો, તો તમારે કુબરનેટ્સ API સર્વર (અને etcd હેલ્પર સર્વિસ)નો એક દાખલો ચલાવવાની જરૂર છે.

સેવા સરનામાં

Istio ClusterIP સરનામાંઓ પર આધાર રાખે છે જે કુબરનેટ્સ ફાળવે છે, તેથી Istio સેવાઓ આંતરિક સરનામું મેળવે છે (રેન્જમાં નથી 127.0.0.0/8).

Istio વગર Kubernetes ક્લસ્ટરમાં ચોક્કસ સેવા માટે ClusterIP સરનામાં પરના ટ્રાફિકને kube-proxy દ્વારા અટકાવવામાં આવે છે અને તે પ્રોક્સીના બેકએન્ડ પર મોકલવામાં આવે છે. જો તમને ટેકનિકલ વિગતોમાં રસ હોય, તો kube-proxy ક્લસ્ટરઆઈપી એડ્રેસ પર જતા કનેક્શન્સના ગંતવ્ય IP એડ્રેસને ફરીથી લખવા માટે iptables નિયમો (અથવા IPVS લોડ બેલેન્સર્સ, તે કેવી રીતે ગોઠવેલ છે તેના આધારે) સેટ કરે છે.

એકવાર Istio કુબરનેટ્સ ક્લસ્ટર પર ઇન્સ્ટોલ થઈ જાય, પછી કન્ટેનર રજૂ કરીને આપેલ ગ્રાહક અથવા તો સમગ્ર નેમસ્પેસ માટે સ્પષ્ટપણે સક્ષમ ન થાય ત્યાં સુધી કંઈ બદલાતું નથી. sidecar કસ્ટમ શીંગો માં. આ કન્ટેનર દૂતના ઉદાહરણને સ્પિન કરશે અને અન્ય સેવાઓ પર જતા ટ્રાફિકને અટકાવવા અને તે ટ્રાફિકને દૂત તરફ રીડાયરેક્ટ કરવા માટે iptables નિયમોનો સમૂહ સેટ કરશે.

જ્યારે Kubernetes DNS સાથે સંકલિત કરવામાં આવે છે, ત્યારે આનો અર્થ એ થાય છે કે અમારો કોડ સેવાના નામ અને બધું "ફક્ત કાર્ય કરે છે" દ્વારા કનેક્ટ થઈ શકે છે. બીજા શબ્દોમાં કહીએ તો, અમારો કોડ ક્વેરી ઇશ્યૂ કરે છે જેમ કે http://api/v1/users/4242પછી api માટે વિનંતી ઉકેલો 10.97.105.48, iptables નિયમો 10.97.105.48 થી કનેક્શન્સને અટકાવશે અને તેમને સ્થાનિક એન્વોય પ્રોક્સીને ફોરવર્ડ કરશે, અને તે સ્થાનિક પ્રોક્સી વિનંતીને વાસ્તવિક બેકએન્ડ API પર ફોરવર્ડ કરશે. ફફ!

વધારાના ફ્રિલ્સ

Istio એમટીએલએસ (મ્યુચ્યુઅલ TLS) દ્વારા એન્ડ-ટુ-એન્ડ એન્ક્રિપ્શન અને પ્રમાણીકરણ પણ પ્રદાન કરે છે. એક ઘટક કહેવાય છે સિટાડેલ.

એક ઘટક પણ છે મિક્સર, જેના માટે રાજદૂત વિનંતી કરી શકે છે દરેક વિવિધ પરિબળો જેમ કે હેડર, બેકએન્ડ લોડ, વગેરેના આધારે તે વિનંતી વિશે વિશેષ નિર્ણય લેવાની વિનંતી... (ચિંતા કરશો નહીં: મિક્સરને ચાલુ રાખવાની ઘણી રીતો છે, અને જો તે ક્રેશ થાય તો પણ, દૂત કામ કરવાનું ચાલુ રાખશે. પ્રોક્સી તરીકે દંડ).

અને, અલબત્ત, અમે દૃશ્યતાનો ઉલ્લેખ કર્યો છે: દૂત વિતરિત ટ્રેસિંગ પ્રદાન કરતી વખતે મેટ્રિક્સનો વિશાળ જથ્થો એકત્રિત કરે છે. માઇક્રોસર્વિસિસ આર્કિટેક્ચરમાં, જો એક API વિનંતી માઇક્રોસર્વિસિસ A, B, C અને Dમાંથી પસાર થવી આવશ્યક છે, તો પછી લોગિન પર, વિતરિત ટ્રેસિંગ વિનંતીમાં એક અનન્ય ઓળખકર્તા ઉમેરશે અને આ ઓળખકર્તાને આ બધી માઇક્રોસર્વિસિસ માટે સબ-રિક્વેસ્ટ્સ દ્વારા સંગ્રહિત કરશે, પરવાનગી આપે છે. તમામ સંબંધિત કોલ્સ કેપ્ચર કરવામાં આવશે. વિલંબ, વગેરે.

વિકાસ કરો અથવા ખરીદો

Istio જટિલ હોવા માટે પ્રતિષ્ઠા ધરાવે છે. તેનાથી વિપરીત, મેં આ પોસ્ટની શરૂઆતમાં વર્ણવેલ રૂટીંગ મેશનું નિર્માણ હાલના ટૂલ્સનો ઉપયોગ કરીને પ્રમાણમાં સરળ છે. તો, શું તેના બદલે તમારી પોતાની સેવા મેશ બનાવવાનો અર્થ છે?

જો આપણી પાસે સાધારણ જરૂરિયાતો હોય (અમને દૃશ્યતા, સર્કિટ બ્રેકર અને અન્ય સૂક્ષ્મતાની જરૂર નથી), તો પછી વિચારો આપણા પોતાના સાધનને વિકસાવવા માટે આવે છે. પરંતુ જો આપણે કુબરનેટ્સનો ઉપયોગ કરીએ, તો તેની જરૂર પણ ન હોઈ શકે કારણ કે કુબરનેટ્સ પહેલેથી જ સેવાની શોધ અને લોડ બેલેન્સિંગ માટે મૂળભૂત સાધનો પ્રદાન કરે છે.

પરંતુ જો અમારી પાસે અદ્યતન આવશ્યકતાઓ છે, તો સેવા મેશ "ખરીદી" એ વધુ સારો વિકલ્પ લાગે છે. (આ હંમેશા "ખરીદો" નથી કારણ કે Istio ઓપન સોર્સ છે, પરંતુ અમારે તેને સમજવા, જમાવટ કરવા અને મેનેજ કરવા માટે હજુ પણ એન્જિનિયરિંગ સમયનું રોકાણ કરવાની જરૂર છે.)

શું મારે Istio, Linkerd અથવા Consul Connect પસંદ કરવું જોઈએ?

અત્યાર સુધી અમે માત્ર Istio વિશે વાત કરી છે, પરંતુ આ એકમાત્ર સર્વિસ મેશ નથી. એક લોકપ્રિય વિકલ્પ છે લિંકર્ડ, અને ત્યાં વધુ છે કોન્સ્યુલ કનેક્ટ.

શું પસંદ કરવું?

પ્રામાણિકપણે, મને ખબર નથી. આ ક્ષણે હું મારી જાતને આ પ્રશ્નનો જવાબ આપવા માટે પૂરતો સક્ષમ નથી માનતો. ત્યાં થોડા છે રસપ્રદ લેખો આ સાધનોની સરખામણી સાથે અને તે પણ બેન્ચમાર્ક.

એક આશાસ્પદ અભિગમ જેવા સાધનનો ઉપયોગ કરવાનો છે સુપરગ્લૂ. તે સર્વિસ મેશ દ્વારા ખુલ્લા API ને સરળ અને એકીકૃત કરવા માટે એબ્સ્ટ્રેક્શન લેયરનો અમલ કરે છે. વિવિધ સર્વિસ મેશના વિશિષ્ટ (અને, મારા મતે, પ્રમાણમાં જટિલ) API શીખવાને બદલે, અમે સુપરગ્લોના સરળ બાંધકામોનો ઉપયોગ કરી શકીએ છીએ - અને સરળતાથી એકથી બીજા પર સ્વિચ કરી શકીએ છીએ, જેમ કે અમારી પાસે HTTP ઇન્ટરફેસ અને બેકએન્ડ્સનું વર્ણન કરતું મધ્યવર્તી રૂપરેખાંકન ફોર્મેટ છે. Nginx, HAProxy, Traefik, Apache... માટે વાસ્તવિક રૂપરેખાંકન જનરેટ કરવાનું

મેં Istio અને SuperGloo સાથે થોડું ડૅબલ કર્યું છે, અને આગલા લેખમાં હું બતાવવા માંગું છું કે સુપરગ્લોનો ઉપયોગ કરીને અસ્તિત્વમાંના ક્લસ્ટરમાં Istio અથવા Linkerd કેવી રીતે ઉમેરવું, અને પછીનું કામ કેવી રીતે થાય છે, એટલે કે, તમને સ્વિચ કરવાની મંજૂરી આપે છે. રૂપરેખાંકનો પર ફરીથી લખ્યા વિના એક સેવા બીજા સાથે મેશ.

સોર્સ: www.habr.com