இணையத்தில் ஒரு கொத்து கட்டுரைகள் о சேவை மெஷ்கள் (சேவை மெஷ்), இதோ இன்னொன்று. ஹூரே! ஆனால் ஏன்? டோக்கர் மற்றும் குபெர்னெட்ஸ் போன்ற கொள்கலன் தளங்கள் வருவதற்கு முன்பு, 10 ஆண்டுகளுக்கு முன்பு சேவை மெஷ்கள் சிறப்பாக இருந்திருக்கும் என்ற எனது கருத்தை நான் தெரிவிக்க விரும்புகிறேன். எனது பார்வை மற்றவர்களை விட சிறந்தது அல்லது மோசமானது என்று நான் கூறவில்லை, ஆனால் சேவை மெஷ்கள் மிகவும் சிக்கலான விலங்குகள் என்பதால், பல பார்வைகள் அவற்றை நன்கு புரிந்துகொள்ள உதவும்.

டாட்க்ளவுட் இயங்குதளத்தைப் பற்றி நான் பேசுவேன், இது நூற்றுக்கும் மேற்பட்ட மைக்ரோ சர்வீஸ்களில் கட்டப்பட்டது மற்றும் ஆயிரக்கணக்கான பயன்பாடுகளை கொள்கலன்களில் ஆதரிக்கிறது. அதை உருவாக்கி தொடங்குவதில் நாங்கள் எதிர்கொண்ட சவால்கள் மற்றும் சேவை மெஷ்கள் எவ்வாறு உதவக்கூடும் (அல்லது செய்யாமல் போகலாம்) என்பதை விளக்குகிறேன்.

dotCloud வரலாறு

நான் ஏற்கனவே dotCloud இன் வரலாறு மற்றும் இந்த தளத்திற்கான கட்டிடக்கலை தேர்வு பற்றி எழுதியுள்ளேன், ஆனால் நெட்வொர்க் லேயர் பற்றி அதிகம் பேசவில்லை. நீங்கள் படிக்க விரும்பவில்லை என்றால் கடைசி கட்டுரை dotCloud பற்றி, இதோ அதன் சாராம்சம்: இது ஒரு PaaS இயங்குதளம்-ஒரு சேவையாகும், இது வாடிக்கையாளர்களுக்கு பரந்த அளவிலான பயன்பாடுகளை (Java, PHP, Python...), பரந்த அளவிலான தரவு சேவைகளுக்கான ஆதரவுடன் இயக்க அனுமதிக்கிறது. MongoDB, MySQL, Redis...) மற்றும் Heroku போன்ற பணிப்பாய்வு: உங்கள் குறியீட்டை பிளாட்ஃபார்மில் பதிவேற்றுகிறீர்கள், அது கொள்கலன் படங்களை உருவாக்கி அவற்றைப் பயன்படுத்துகிறது.

டாட்க்ளவுட் இயங்குதளத்திற்கு போக்குவரத்து எவ்வாறு அனுப்பப்பட்டது என்பதை நான் உங்களுக்குச் சொல்கிறேன். அது குறிப்பாக குளிர்ச்சியாக இருந்ததால் அல்ல (அதன் காலத்திற்கு கணினி நன்றாக வேலை செய்தாலும்!), ஆனால் முதன்மையாக நவீன கருவிகளின் உதவியுடன், அத்தகைய வடிவமைப்பை ஒரு சாதாரண குழுவால் எளிதாகச் செயல்படுத்த முடியும். ஒரு சில மைக்ரோ சர்வீஸ்கள் அல்லது ஒரு சில பயன்பாடுகள் இடையே போக்குவரத்து. எனவே, நீங்கள் விருப்பங்களை ஒப்பிடலாம்: எல்லாவற்றையும் நீங்களே உருவாக்கினால் அல்லது ஏற்கனவே உள்ள சேவை கண்ணியைப் பயன்படுத்தினால் என்ன ஆகும். நிலையான தேர்வு: நீங்களே உருவாக்கவும் அல்லது வாங்கவும்.

ஹோஸ்ட் செய்யப்பட்ட பயன்பாடுகளுக்கான டிராஃபிக் ரூட்டிங்

dotCloud இல் உள்ள பயன்பாடுகள் HTTP மற்றும் TCP இறுதிப்புள்ளிகளை வெளிப்படுத்தலாம்.

HTTP இறுதிப்புள்ளிகள் சுமை சமநிலை கிளஸ்டர் உள்ளமைவில் மாறும் வகையில் சேர்க்கப்பட்டது இடுப்பு வலி. இது இன்று வளங்கள் செய்து கொண்டிருப்பதைப் போன்றது உட்செல்வதை Kubernetes மற்றும் ஒரு சுமை சமநிலை போன்ற ட்ரேஃபிக்.

டாட்க்ளவுட் லோட் பேலன்சர்களுக்கு டொமைன் பெயர் புள்ளிகள் வழங்கப்பட்டு, பொருத்தமான டொமைன்கள் மூலம் வாடிக்கையாளர்கள் HTTP இறுதிப் புள்ளிகளுடன் இணைக்கின்றனர். சிறப்பு எதுவும் இல்லை.

TCP இறுதிப்புள்ளிகள் ஒரு போர்ட் எண்ணுடன் தொடர்புடையது, இது சூழல் மாறிகள் வழியாக அந்த அடுக்கில் உள்ள அனைத்து கொள்கலன்களுக்கும் அனுப்பப்படும்.

பொருத்தமான ஹோஸ்ட்பெயர் (கேட்வே-X.dotcloud.com போன்றது) மற்றும் போர்ட் எண்ணைப் பயன்படுத்தி வாடிக்கையாளர்கள் TCP இறுதிப் புள்ளிகளுடன் இணைக்க முடியும்.

இந்த புரவலன் பெயர் "நாட்ஸ்" சர்வர் கிளஸ்டருக்கு (தொடர்பற்றது NATS) இது உள்வரும் TCP இணைப்புகளை சரியான கொள்கலனுக்கு (அல்லது, சுமை-சமநிலை சேவைகளின் விஷயத்தில், சரியான கொள்கலன்களுக்கு) செல்லும்.

நீங்கள் குபெர்னெட்டஸை நன்கு அறிந்திருந்தால், இது உங்களுக்கு சேவைகளை நினைவூட்டும் நோட்போர்ட்.

dotCloud இயங்குதளத்தில் அதற்கு இணையான சேவைகள் எதுவும் இல்லை ClusterIP: எளிமைக்காக, சேவைகளுக்கான அணுகல் மேடையின் உள்ளேயும் வெளியேயும் ஒரே மாதிரியாக நடந்தது.

எல்லாம் மிகவும் எளிமையாக ஒழுங்கமைக்கப்பட்டது: HTTP மற்றும் TCP ரூட்டிங் நெட்வொர்க்குகளின் அசல் செயலாக்கங்கள் பைத்தானின் சில நூறு வரிகள் மட்டுமே. தளத்தின் வளர்ச்சி மற்றும் கூடுதல் தேவைகளின் தோற்றம் ஆகியவற்றுடன் சுத்திகரிக்கப்பட்ட எளிய (அப்பாவி என்று நான் கூறுவேன்) அல்காரிதம்கள்.

ஏற்கனவே உள்ள குறியீட்டின் விரிவான மறுசீரமைப்பு தேவையில்லை. குறிப்பாக, 12 காரணி பயன்பாடுகள் சூழல் மாறிகள் மூலம் பெறப்பட்ட முகவரியை நேரடியாகப் பயன்படுத்தலாம்.

நவீன சேவை மெஷிலிருந்து இது எவ்வாறு வேறுபடுகிறது?

வரையறுக்கப்பட்டவை தெரிவுநிலை. TCP ரூட்டிங் மெஷுக்கான அளவீடுகள் எங்களிடம் இல்லை. HTTP ரூட்டிங்கிற்கு வரும்போது, ​​சமீபத்திய பதிப்புகளில் HTTP அளவீடுகள் பிழைக் குறியீடுகள் மற்றும் மறுமொழி நேரங்கள் உள்ளன, ஆனால் நவீன சேவை மெஷ்கள் இன்னும் மேலே செல்கின்றன, எடுத்துக்காட்டாக, Prometheus போன்ற அளவீட்டு சேகரிப்பு அமைப்புகளுடன் ஒருங்கிணைக்கப்படுகின்றன.

செயல்பாட்டுக் கண்ணோட்டத்தில் (சிக்கல்களை சரிசெய்வதற்கு உதவுவதற்காக) மட்டுமல்லாமல், புதிய அம்சங்கள் வெளியிடப்படும்போதும் தெரிவுநிலை முக்கியமானது. பாதுகாப்பானது பற்றி பேசுகிறது நீல-பச்சை வரிசைப்படுத்தல் и கேனரிகளின் வரிசைப்படுத்தல்.

ரூட்டிங் திறன் வரையறுக்கப்பட்டுள்ளது. டாட்க்ளவுட் ரூட்டிங் மெஷில், அனைத்து ட்ராஃபிக்கையும் பிரத்யேக ரூட்டிங் முனைகளின் கிளஸ்டர் வழியாகச் செல்ல வேண்டும். இதன் பொருள் பல AZ (கிடைக்கும் மண்டலம்) எல்லைகளை கடக்கக்கூடியது மற்றும் தாமதத்தின் குறிப்பிடத்தக்க அதிகரிப்பு. ஒரு பக்கத்திற்கு நூற்றுக்கும் மேற்பட்ட SQL வினவல்களை உருவாக்கி, ஒவ்வொரு வினவலுக்கும் SQL சர்வரில் ஒரு புதிய இணைப்பைத் திறக்கும் சரிசெய்தல் குறியீடு எனக்கு நினைவிருக்கிறது. உள்நாட்டில் இயங்கும் போது, ​​பக்கம் உடனடியாக ஏற்றப்படும், ஆனால் dotCloud இல் ஏற்றுவதற்கு சில வினாடிகள் ஆகும், ஏனெனில் ஒவ்வொரு TCP இணைப்பும் (மற்றும் அடுத்தடுத்த SQL வினவல்) பல்லாயிரம் மில்லி விநாடிகள் ஆகும். இந்த குறிப்பிட்ட வழக்கில், தொடர்ச்சியான இணைப்புகள் சிக்கலைத் தீர்த்தன.

இத்தகைய பிரச்சனைகளை கையாள்வதில் நவீன சேவை மெஷ்கள் சிறந்தவை. முதலில், இணைப்புகள் திசைதிருப்பப்பட்டதா என்பதை அவர்கள் சரிபார்க்கிறார்கள் மூலத்தில். தர்க்கரீதியான ஓட்டம் ஒன்றே: клиент → меш → сервис, ஆனால் இப்போது கண்ணி உள்நாட்டில் வேலை செய்கிறது மற்றும் தொலை முனைகளில் இல்லை, எனவே இணைப்பு клиент → меш உள்ளூர் மற்றும் மிக வேகமாக உள்ளது (மில்லி விநாடிகளுக்கு பதிலாக மைக்ரோ விநாடிகள்).

நவீன சேவை மெஷ்கள் சிறந்த சுமை சமநிலைப்படுத்தும் அல்காரிதங்களையும் செயல்படுத்துகின்றன. பின்தளங்களின் ஆரோக்கியத்தை கண்காணிப்பதன் மூலம், அவை அதிக போக்குவரத்தை வேகமான பின்தளங்களுக்கு அனுப்பலாம், இதன் விளைவாக சிறந்த ஒட்டுமொத்த செயல்திறன் கிடைக்கும்.

பாதுகாப்பு சிறப்பாகவும் உள்ளது. டாட்க்ளவுட் ரூட்டிங் மெஷ் முழுவதுமாக EC2 கிளாசிக்கில் இயங்கியது மற்றும் டிராஃபிக்கை என்க்ரிப்ட் செய்யவில்லை (யாராவது EC2 நெட்வொர்க் டிராஃபிக்கில் ஸ்னிஃபரை வைக்க முடிந்தால், நீங்கள் ஏற்கனவே பெரிய சிக்கலில் இருக்கிறீர்கள் என்ற அனுமானத்தின் கீழ்). நவீன சேவை மெஷ்கள் எங்கள் போக்குவரத்தை வெளிப்படையாகப் பாதுகாக்கின்றன, எடுத்துக்காட்டாக, பரஸ்பர TLS அங்கீகாரம் மற்றும் அடுத்தடுத்த குறியாக்கத்துடன்.

பிளாட்ஃபார்ம் சேவைகளுக்கான டிராஃபிக் ரூட்டிங்

சரி, பயன்பாடுகளுக்கு இடையேயான போக்குவரத்தைப் பற்றி விவாதித்தோம், ஆனால் dotCloud இயங்குதளத்தைப் பற்றி என்ன?

இயங்குதளமே பல்வேறு செயல்பாடுகளுக்குப் பொறுப்பான சுமார் நூறு மைக்ரோ சர்வீஸ்களைக் கொண்டிருந்தது. சிலர் பிறரிடமிருந்து கோரிக்கைகளை ஏற்றுக்கொண்டனர், மேலும் சிலர் பிற சேவைகளுடன் இணைந்த பின்னணி பணியாளர்கள் ஆனால் இணைப்புகளை தாங்களாகவே ஏற்கவில்லை. எந்தவொரு சந்தர்ப்பத்திலும், ஒவ்வொரு சேவையும் இணைக்க வேண்டிய முகவரிகளின் இறுதிப்புள்ளிகளை அறிந்திருக்க வேண்டும்.

பல உயர்மட்ட சேவைகள் மேலே விவரிக்கப்பட்ட ரூட்டிங் மெஷைப் பயன்படுத்தலாம். உண்மையில், XNUMX க்கும் மேற்பட்ட டாட்க்ளவுட் மைக்ரோ சர்வீஸ்களில் பல டாட்க்ளவுட் இயங்குதளத்திலேயே வழக்கமான பயன்பாடுகளாக பயன்படுத்தப்பட்டுள்ளன. ஆனால் குறைந்த எண்ணிக்கையிலான குறைந்த அளவிலான சேவைகளுக்கு (குறிப்பாக, இந்த ரூட்டிங் மெஷை செயல்படுத்துபவர்கள்) எளிமையான ஒன்று தேவை, குறைவான சார்புகள் (ஏனெனில் அவர்கள் வேலை செய்ய தங்களைச் சார்ந்திருக்க முடியாது - நல்ல பழைய கோழி மற்றும் முட்டை பிரச்சனை).

இந்த குறைந்த-நிலை, அத்தியாவசிய சேவைகள் ஒரு சில முக்கிய முனைகளில் நேரடியாக கொள்கலன்களை இயக்குவதன் மூலம் பயன்படுத்தப்பட்டன. அதே நேரத்தில், நிலையான இயங்குதள சேவைகள் இதில் ஈடுபடவில்லை: இணைப்பான், திட்டமிடுபவர் மற்றும் ரன்னர். நீங்கள் நவீன கொள்கலன் தளங்களுடன் ஒப்பிட விரும்பினால், அது ஒரு கட்டுப்பாட்டு விமானத்தை ஏவுவது போன்றது docker run குபெர்னெட்டஸுக்கு பணியை வழங்குவதற்குப் பதிலாக நேரடியாக முனைகளில். இது கருத்தில் மிகவும் ஒத்திருக்கிறது நிலையான தொகுதிகள் (காய்கள்), இது பயன்படுத்துகிறது kubeadm அல்லது bootkube தனித்தனி கிளஸ்டரை துவக்கும் போது.

இந்த சேவைகள் எளிமையான மற்றும் கசப்பான முறையில் வெளிப்படுத்தப்பட்டன: YAML கோப்பு அவர்களின் பெயர்கள் மற்றும் முகவரிகளை பட்டியலிட்டது; மேலும் ஒவ்வொரு கிளையண்டும் இந்த YAML கோப்பின் நகலை வரிசைப்படுத்துவதற்கு எடுக்க வேண்டும்.

ஒருபுறம், இது மிகவும் நம்பகமானது, ஏனெனில் இதற்கு Zookeeper போன்ற வெளிப்புற விசை/மதிப்பு அங்காடியின் ஆதரவு தேவையில்லை (நினைவில் கொள்ளுங்கள், etcd அல்லது கான்சல் அந்த நேரத்தில் இல்லை). மறுபுறம், சேவைகளை நகர்த்துவதில் சிரமம் ஏற்பட்டது. ஒவ்வொரு முறையும் நகர்த்தப்படும் போது, ​​அனைத்து கிளையன்ட்களும் புதுப்பிக்கப்பட்ட 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 க்கு பதிலாக.
• etcd அல்லது Consulக்குப் பதிலாக Kubernetes API வழியாக பின்தள கட்டமைப்பைச் சேமிக்கிறது.
• சேவைகளுக்கு 127.0.0.0/8 க்குப் பதிலாக உள் சப்நெட்டில் (குபெர்னெட்ஸ் கிளஸ்டர்ஐபி முகவரிகள்) முகவரிகள் ஒதுக்கப்படுகின்றன.
• கிளையன்ட் மற்றும் சர்வர்களுக்கிடையே பரஸ்பர TLS அங்கீகாரத்தைச் சேர்க்க கூடுதல் கூறு (Citadel) உள்ளது.
• சர்க்யூட் பிரேக்கிங், டிஸ்ட்ரிப்ட் டிரேசிங், கேனரி வரிசைப்படுத்தல் போன்ற புதிய அம்சங்களை ஆதரிக்கிறது.

சில வேறுபாடுகளை விரைவாகப் பார்ப்போம்.

தூதுவர் பதிலாள்

என்வாய் ப்ராக்ஸி லிஃப்ட்டால் எழுதப்பட்டது [டாக்ஸி சந்தையில் உபெரின் போட்டியாளர் - தோராயமாக. per.]. இது மற்ற ப்ராக்ஸிகளுடன் (எ.கா. HAProxy, Nginx, Traefik...) பல வழிகளில் ஒத்திருக்கிறது, ஆனால் மற்ற ப்ராக்ஸிகளிடம் இல்லாத அம்சங்கள் தேவைப்படுவதால் Lyft சொந்தமாக எழுதியது மற்றும் நீட்டிப்பதற்குப் பதிலாக புதிய ஒன்றை உருவாக்குவது மிகவும் விவேகமானதாகத் தோன்றியது. ஏற்கனவே உள்ள ஒன்று.

தூதுவர் தன்னைப் பயன்படுத்திக் கொள்ளலாம். பிற சேவைகளுடன் இணைக்க வேண்டிய ஒரு குறிப்பிட்ட சேவை என்னிடம் இருந்தால், நான் அதை Envoy உடன் இணைக்க அமைக்கலாம், பின்னர் மற்ற சேவைகளின் இருப்பிடத்துடன் Envoy ஐ மாறும் வகையில் உள்ளமைக்கலாம் மற்றும் மறுகட்டமைக்கலாம், அதே நேரத்தில் தெரிவுநிலை போன்ற சிறந்த கூடுதல் அம்சங்களைப் பெறலாம். பிரத்தியேக கிளையன்ட் லைப்ரரி அல்லது கால் டிரேசிங் குறியீட்டில் உட்செலுத்துவதற்குப் பதிலாக, நாங்கள் டிராஃபிக்கை தூதுவருக்கு அனுப்புகிறோம், மேலும் அது எங்களுக்கான அளவீடுகளைச் சேகரிக்கிறது.

ஆனால் தூதுவராகவும் பணியாற்ற முடியும் தரவு விமானம் (தரவு விமானம்) சேவை கண்ணிக்கு. இதன் பொருள் இப்போது இந்த சேவை மெஷிற்கு, என்வாய் கட்டமைக்கப்பட்டுள்ளது கட்டுப்பாட்டு விமானம் (கட்டுப்பாட்டு விமானம்).

கட்டுப்பாட்டு விமானம்

கட்டுப்பாட்டு விமானத்தில், இஸ்டியோ குபெர்னெட்ஸ் API ஐ நம்பியுள்ளது. இது confd ஐப் பயன்படுத்துவதில் இருந்து மிகவும் வேறுபட்டதல்ல, தரவு சேமிப்பகத்தில் உள்ள விசைகளின் தொகுப்பைப் பார்க்க etcd அல்லது Consul ஐ நம்பியுள்ளது. குபெர்னெட்ஸ் ஏபிஐ மூலம் குபெர்னெட்ஸ் வளங்களின் தொகுப்பை இஸ்டியோ பார்க்கிறார்.

இதற்கும் அதற்கும் இடையில்: இது தனிப்பட்ட முறையில் எனக்கு பயனுள்ளதாக இருந்தது Kubernetes API இன் விளக்கம்அதில் கூறப்பட்டுள்ளது:

குபெர்னெட்டஸ் ஏபிஐ சர்வர் என்பது ஒரு "முட்டாள் சேவையகம்" ஆகும், இது சேமிப்பகம், பதிப்பு செய்தல், சரிபார்த்தல், புதுப்பித்தல் மற்றும் ஏபிஐ ஆதார சொற்பொருள்களை வழங்குகிறது.

இஸ்டியோ குபெர்னெட்டஸுடன் இணைந்து பணியாற்ற வடிவமைக்கப்பட்டுள்ளது; குபெர்னெட்டஸுக்கு வெளியே இதைப் பயன்படுத்த விரும்பினால், நீங்கள் குபெர்னெட்ஸ் ஏபிஐ சேவையகத்தின் (மற்றும் etcd உதவி சேவை) ஒரு நிகழ்வைத் தொடங்க வேண்டும்.

சேவை முகவரிகள்

குபெர்னெட்ஸ் ஒதுக்கும் கிளஸ்டர்ஐபி முகவரிகளை இஸ்டியோ நம்பியுள்ளது, எனவே இஸ்டியோ சேவைகள் உள் முகவரியைப் பெறுகின்றன (வரம்பில் இல்லை 127.0.0.0/8).

Istio இல்லாமல் Kubernetes கிளஸ்டரில் உள்ள குறிப்பிட்ட சேவைக்கான ClusterIP முகவரிக்கான ட்ராஃபிக் kube-proxy மூலம் இடைமறித்து ப்ராக்ஸியின் பின்தளத்திற்கு அனுப்பப்படும். தொழில்நுட்ப விவரங்களில் நீங்கள் ஆர்வமாக இருந்தால், ClusterIP முகவரிக்குச் செல்லும் இணைப்புகளின் இலக்கு IP முகவரிகளை மீண்டும் எழுத, iptables விதிகளை (அல்லது IPVS லோட் பேலன்சர்கள், அது எவ்வாறு கட்டமைக்கப்பட்டுள்ளது என்பதைப் பொறுத்து) kube-proxy அமைக்கிறது.

குபெர்னெட்டஸ் கிளஸ்டரில் இஸ்டியோ நிறுவப்பட்டதும், ஒரு கொள்கலனை அறிமுகப்படுத்துவதன் மூலம் கொடுக்கப்பட்ட நுகர்வோருக்கு அல்லது முழு பெயர்வெளிக்கும் வெளிப்படையாக இயக்கப்படும் வரை எதுவும் மாறாது. sidecar விருப்ப காய்களுக்கு. இந்தக் கொள்கலன் ஒரு தூதர் நிகழ்வைத் தொடங்கி, பிற சேவைகளுக்குச் செல்லும் போக்குவரத்தை இடைமறித்து, அந்த டிராஃபிக்கைத் தூதருக்குத் திருப்பிவிட iptables விதிகளின் தொகுப்பை அமைக்கும்.

குபெர்னெட்டஸ் டிஎன்எஸ் உடன் ஒருங்கிணைக்கப்படும் போது, ​​எங்கள் குறியீடு சேவையின் பெயரால் இணைக்க முடியும், மேலும் அனைத்தும் "வேலை செய்யும்". வேறு வார்த்தைகளில் கூறுவதானால், எங்கள் குறியீடு போன்ற கேள்விகளை வெளியிடுகிறது http://api/v1/users/4242பின்னர் api என்ற கோரிக்கையை தீர்க்கவும் 10.97.105.48, iptables விதிகள் 10.97.105.48 இலிருந்து இணைப்புகளை இடைமறித்து அவற்றை உள்ளூர் தூதர் ப்ராக்ஸிக்கு திருப்பிவிடும், இது உண்மையான API பின்தளத்திற்கு கோரிக்கையை அனுப்பும். அச்சச்சோ!

கூடுதல் அலங்காரங்கள்

இஸ்டியோ எம்டிஎல்எஸ் (மியூச்சுவல் டிஎல்எஸ்) வழியாக என்ட்-டு-எண்ட் என்க்ரிப்ஷன் மற்றும் அங்கீகாரத்தையும் வழங்குகிறது. என்ற கூறு சிட்டாடல்.

ஒரு கூறும் உள்ளது கலவை, எந்த தூதர் கோரலாம் ஒவ்வொருவரும் தலைப்புகள், பின்தளத்தில் ஏற்றுதல் போன்ற பல்வேறு காரணிகளைப் பொறுத்து அந்தக் கோரிக்கையைப் பற்றி சிறப்பு முடிவெடுக்கக் கோருங்கள்... (கவலைப்பட வேண்டாம்: மிக்சரை தொடர்ந்து வேலை செய்ய பல கருவிகள் உள்ளன, அது செயலிழந்தாலும், தூதர் தொடர்ந்து வேலை செய்வார் ப்ராக்ஸியாக) .

மற்றும், நிச்சயமாக, நாங்கள் தெரிவுநிலையைக் குறிப்பிட்டோம்: விநியோகிக்கப்பட்ட ட்ரேசிங்கை வழங்கும் போது தூதுவர் பெரிய அளவிலான அளவீடுகளை சேகரிக்கிறார். மைக்ரோ சர்வீஸ் கட்டமைப்பில், ஒரு ஏபிஐ கோரிக்கை மைக்ரோ சர்வீஸ் ஏ, பி, சி மற்றும் டி வழியாக செல்ல வேண்டும் என்றால், உள்நுழைந்ததும், விநியோகிக்கப்பட்ட டிரேசிங் கோரிக்கையில் ஒரு தனித்துவமான அடையாளங்காட்டியைச் சேர்க்கும் மற்றும் இந்த மைக்ரோ சர்வீஸ்கள் அனைத்திற்கும் துணை கோரிக்கைகள் மூலம் இந்த அடையாளங்காட்டியை சேமிக்கும். தொடர்புடைய அனைத்து அழைப்புகள், அவற்றின் தாமதங்கள் போன்றவற்றை நீங்கள் கைப்பற்றலாம்.

உருவாக்கவும் அல்லது வாங்கவும்

இஸ்டியோ ஒரு சிக்கலான அமைப்பாக நற்பெயரைக் கொண்டுள்ளது. இதற்கு நேர்மாறாக, இந்த இடுகையின் தொடக்கத்தில் நான் விவரித்த ரூட்டிங் மெஷை உருவாக்குவது தற்போதுள்ள கருவிகளைக் கொண்டு ஒப்பீட்டளவில் எளிதானது. எனவே, அதற்கு பதிலாக உங்கள் சொந்த சேவை வலையை உருவாக்குவது அர்த்தமுள்ளதாக இருக்கிறதா?

எங்களிடம் மிதமான தேவைகள் இருந்தால் (எங்களுக்குத் தெரிவுநிலை, சர்க்யூட் பிரேக்கர் மற்றும் பிற நுணுக்கங்கள் தேவையில்லை), பின்னர் எங்கள் சொந்த கருவியை உருவாக்குவது பற்றிய எண்ணங்கள் வரும். ஆனால் நாங்கள் குபெர்னெட்டஸைப் பயன்படுத்தினால், அது தேவைப்படாமல் போகலாம், ஏனெனில் குபெர்னெட்ஸ் ஏற்கனவே சேவை கண்டுபிடிப்பு மற்றும் சுமை சமநிலைக்கான அடிப்படைக் கருவிகளை வழங்குகிறது.

ஆனால் எங்களிடம் மேம்பட்ட தேவைகள் இருந்தால், சேவை கண்ணியை "வாங்குவது" மிகச் சிறந்த விருப்பமாகத் தெரிகிறது. (இஸ்டியோ ஓப்பன் சோர்ஸ் என்பதால் இது எப்போதும் "வாங்குதல்" அல்ல, ஆனால் அதைப் புரிந்து கொள்ளவும், பயன்படுத்தவும் மற்றும் நிர்வகிக்கவும் நாம் இன்னும் பொறியியல் நேரத்தை முதலீடு செய்ய வேண்டும்.)

எதை தேர்வு செய்வது: இஸ்டியோ, லிங்கர்ட் அல்லது கன்சல் கனெக்ட்?

இதுவரை நாங்கள் இஸ்டியோவைப் பற்றி மட்டுமே பேசினோம், ஆனால் இது ஒரே சேவை மெஷ் அல்ல. பிரபலமான மாற்று உள்ளது லிங்கர்ட், ஆனால் இன்னும் இருக்கிறது கன்சல் இணைப்பு.

என்ன தேர்வு செய்ய வேண்டும்?

உண்மையைச் சொல்வதென்றால், எனக்குத் தெரியாது. இந்தக் கேள்விக்குப் பதில் சொல்லும் அளவுக்கு இப்போது நான் என்னைப் பற்றிக் கருதவில்லை. ஒரு சில உள்ளன சுவாரஸ்யமான கட்டுரைகள் இந்த கருவிகளின் ஒப்பீடு மற்றும் கூட வரையறைகள்.

போன்ற ஒரு கருவியைப் பயன்படுத்துவது ஒரு நம்பிக்கைக்குரிய அணுகுமுறை சூப்பர் குளோ. சேவை மெஷ்களால் வழங்கப்படும் APIகளை எளிமைப்படுத்தவும் ஒருங்கிணைக்கவும் இது ஒரு சுருக்க அடுக்கை செயல்படுத்துகிறது. பல்வேறு சேவை மெஷ்களின் குறிப்பிட்ட (மற்றும், என் கருத்துப்படி, ஒப்பீட்டளவில் சிக்கலான) APIகளைக் கற்றுக்கொள்வதற்குப் பதிலாக, எளிமையான SuperGloo கட்டுமானங்களைப் பயன்படுத்தலாம் - மேலும் HTTP இடைமுகங்கள் மற்றும் பின்தளங்களை விவரிக்கும் ஒரு இடைநிலை உள்ளமைவு வடிவமைப்பைப் போல, எளிதாக ஒன்றிலிருந்து மற்றொன்றுக்கு மாறலாம். Nginx, HAProxy, Traefik, Apache...க்கான உண்மையான உள்ளமைவை உருவாக்கும் திறன் கொண்டது.

நான் Istio மற்றும் SuperGloo உடன் சிறிது விளையாடினேன், அடுத்த கட்டுரையில் SuperGloo ஐப் பயன்படுத்தி ஏற்கனவே உள்ள கிளஸ்டரில் Istio அல்லது Linkerd ஐ எவ்வாறு சேர்ப்பது மற்றும் பிந்தையது அதன் வேலையை எவ்வாறு செய்யும், அதாவது, இது உங்களை மாற்ற அனுமதிக்கிறது. உள்ளமைவுகளை மீண்டும் எழுதாமல் ஒரு சேவை மெஷ் மற்றொன்றுக்கு.

ஆதாரம்: www.habr.com