உற்பத்தியில் இஸ்டியோ மற்றும் குபெர்னெட்ஸ். பகுதி 2. தடமறிதல்

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

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

தவறான எண்ணம் ஒன்று: ஆன்லைன் ஹைகிங் தரவை இலவசமாகப் பெறலாம்.

உண்மையில், ஒப்பீட்டளவில் இலவசமாக, அம்புகள் மற்றும் சேவைகளுக்கு இடையில் செல்லும் தரவு வீதம் (உண்மையில், ஒரு யூனிட் நேரத்திற்கு பைட்டுகளின் எண்ணிக்கை மட்டுமே) மூலம் இணைக்கப்பட்ட எங்கள் கணினியின் முனைகளை மட்டுமே பெற முடியும். இருப்பினும், பெரும்பாலான சந்தர்ப்பங்களில், HTTP, gRPC, Redis மற்றும் பல போன்ற சில வகையான பயன்பாட்டு அடுக்கு நெறிமுறைகள் மூலம் எங்கள் சேவைகள் தொடர்பு கொள்கின்றன. மற்றும், நிச்சயமாக, இந்த நெறிமுறைகளுக்கான டிரேசிங் தகவலைப் பார்க்க விரும்புகிறோம்; கோரிக்கை விகிதத்தைப் பார்க்க விரும்புகிறோம், தரவு வீதத்தை அல்ல. எங்கள் நெறிமுறையைப் பயன்படுத்தி கோரிக்கைகளின் தாமதத்தை நாங்கள் புரிந்து கொள்ள விரும்புகிறோம். இறுதியாக, ஒரு கோரிக்கையானது எங்கள் கணினியில் உள்நுழைவதிலிருந்து பயனரிடமிருந்து பதிலைப் பெறுவதற்கான முழுப் பாதையையும் பார்க்க விரும்புகிறோம். இந்த சிக்கலை தீர்க்க இனி அவ்வளவு எளிதானது அல்ல.

முதலில், இஸ்டியோவில் கட்டடக்கலை பார்வையில் இருந்து டிரேசிங் ஸ்பான்களை அனுப்புவது எப்படி இருக்கும் என்று பார்க்கலாம். முதல் பகுதியிலிருந்து நாம் நினைவில் வைத்திருப்பது போல், டெலிமெட்ரியை சேகரிப்பதற்காக இஸ்டியோவுக்கு மிக்சர் என்ற தனி கூறு உள்ளது. இருப்பினும், தற்போதைய பதிப்பு 1.0.* இல், அனுப்புதல் நேரடியாக ப்ராக்ஸி சர்வர்களில் இருந்து செய்யப்படுகிறது, அதாவது, தூதர் ப்ராக்ஸியிலிருந்து. பெட்டிக்கு வெளியே ஜிப்கின் நெறிமுறையைப் பயன்படுத்தி டிரேசிங் ஸ்பான்களை அனுப்புவதை என்வாய் ப்ராக்ஸி ஆதரிக்கிறது. பிற நெறிமுறைகளை இணைக்க முடியும், ஆனால் ஒரு செருகுநிரல் மூலம் மட்டுமே. இஸ்டியோவுடன் நாம் உடனடியாக அசெம்பிள் செய்யப்பட்ட மற்றும் உள்ளமைக்கப்பட்ட தூதர் ப்ராக்ஸியைப் பெறுகிறோம், இது ஜிப்கின் நெறிமுறையை மட்டுமே ஆதரிக்கிறது. எடுத்துக்காட்டாக, ஜெய்கர் நெறிமுறையைப் பயன்படுத்தவும், UDP வழியாக ட்ரேசிங் ஸ்பான்களை அனுப்பவும் விரும்பினால், நாங்கள் எங்கள் சொந்த istio-proxy படத்தை உருவாக்க வேண்டும். istio-proxyக்கான தனிப்பயன் செருகுநிரல்களுக்கான ஆதரவு உள்ளது, ஆனால் அது இன்னும் ஆல்பா பதிப்பில் உள்ளது. எனவே, அதிக எண்ணிக்கையிலான தனிப்பயன் அமைப்புகள் இல்லாமல் செய்ய விரும்பினால், ட்ரேசிங் ஸ்பான்களை சேமிப்பதற்கும் பெறுவதற்கும் பயன்படுத்தப்படும் தொழில்நுட்பங்களின் வரம்பு குறைக்கப்படுகிறது. முக்கிய அமைப்புகளில், இப்போது நீங்கள் Zipkin அல்லது Jaeger ஐப் பயன்படுத்தலாம், ஆனால் zipkin இணக்கமான நெறிமுறையைப் பயன்படுத்தி எல்லாவற்றையும் அங்கு அனுப்பலாம் (இது மிகவும் குறைவான செயல்திறன் கொண்டது). ஜிப்கின் நெறிமுறையானது HTTP நெறிமுறை மூலம் சேகரிப்பாளர்களுக்கு அனைத்து டிரேசிங் தகவல்களையும் அனுப்புவதை உள்ளடக்குகிறது, இது மிகவும் விலை உயர்ந்தது.

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

apiVersion: v1
kind: Service
metadata:
  name: nginx
spec:
  ports:
  - port: 80
    targetPort: 80
    name: http
  selector:
    app: nginx

நீங்கள் http-magic போன்ற கூட்டுப் பெயர்களையும் பயன்படுத்தலாம் (Istio http ஐப் பார்க்கும் மற்றும் அந்த போர்ட்டை http எண்ட்பாயிண்ட் ஆக அங்கீகரிக்கும்). வடிவம்: புரோட்டோ-எக்ஸ்ட்ரா.

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

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

--serviceCluster ${POD_NAMESPACE}.$(echo ${POD_NAME} | sed -e 's/-[a-z0-9]*-[a-z0-9]*$//g')

தூதுவரில் ட்ரேசிங் எவ்வாறு செயல்படுகிறது என்பதைப் புரிந்து கொள்ள ஒரு சிறந்த எடுத்துக்காட்டு இங்கே.

ட்ரேசிங் ஸ்பான்களை அனுப்புவதற்கான இறுதிப்புள்ளியானது தூதர் ப்ராக்ஸி வெளியீட்டு கொடிகளிலும் குறிப்பிடப்பட வேண்டும், எடுத்துக்காட்டாக: --zipkinAddress tracing-collector.tracing:9411

தவறான கருத்து எண் இரண்டு: பெட்டியின் வெளியே உள்ள கணினி மூலம் கோரிக்கைகளின் முழுமையான தடயங்களை நாம் மலிவான விலையில் பெறலாம்

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

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

• x-request-id,
• x-b3-traceid,
• x-b3-spanid,
• x-b3-parentspanid,
• x-b3-மாதிரி,
• x-b3-கொடிகள்,
• x-ot-span-சூழல்.

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

முடிவுக்கு

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

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

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