ઉત્પાદનમાં Istio અને Kubernetes. ભાગ 2. ટ્રેસીંગ

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

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

ગેરસમજ નંબર એક: અમે ઑનલાઇન હાઇકિંગ ડેટા મફતમાં મેળવી શકીએ છીએ.

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

પ્રથમ, ચાલો જોઈએ કે ઇસ્ટિઓમાં આર્કિટેક્ચરલ દૃષ્ટિકોણથી મોકલવાના ટ્રેસિંગ સ્પાન્સ કેવા દેખાય છે. જેમ આપણે પહેલા ભાગથી યાદ રાખીએ છીએ તેમ, ઇસ્ટિઓ પાસે ટેલિમેટ્રી એકત્ર કરવા માટે મિક્સર નામનો એક અલગ ઘટક છે. જો કે, વર્તમાન સંસ્કરણ 1.0.*માં, મોકલવાનું સીધું જ પ્રોક્સી સર્વરથી થાય છે, એટલે કે, દૂત પ્રોક્સીથી. એન્વોય પ્રોક્સી બોક્સની બહાર ઝિપકીન પ્રોટોકોલનો ઉપયોગ કરીને ટ્રેસિંગ સ્પાન્સ મોકલવાનું સમર્થન કરે છે. અન્ય પ્રોટોકોલ્સને કનેક્ટ કરવું શક્ય છે, પરંતુ ફક્ત પ્લગઇન દ્વારા. Istio સાથે અમને તરત જ એસેમ્બલ અને ગોઠવેલ દૂત પ્રોક્સી મળે છે, જે ફક્ત ઝિપકીન પ્રોટોકોલને સપોર્ટ કરે છે. જો આપણે, ઉદાહરણ તરીકે, જેગર પ્રોટોકોલનો ઉપયોગ કરવા અને UDP દ્વારા ટ્રેસીંગ સ્પાન્સ મોકલવા માંગતા હોઈએ, તો આપણે આપણી પોતાની istio-proxy ઇમેજ બનાવવાની જરૂર પડશે. ઇસ્ટિઓ-પ્રોક્સી માટે કસ્ટમ પ્લગિન્સ માટે સપોર્ટ છે, પરંતુ તે હજી પણ આલ્ફા વર્ઝનમાં છે. તેથી, જો આપણે મોટી સંખ્યામાં કસ્ટમ સેટિંગ્સ વિના કરવા માંગીએ છીએ, તો ટ્રેસિંગ સ્પાન્સને સંગ્રહિત કરવા અને પ્રાપ્ત કરવા માટે ઉપયોગમાં લેવાતી તકનીકોની શ્રેણી ઓછી થાય છે. મુખ્ય સિસ્ટમોમાંથી, વાસ્તવમાં, હવે તમે ઝિપકીન અથવા જેગરનો ઉપયોગ કરી શકો છો, પરંતુ ઝિપકીન સુસંગત પ્રોટોકોલ (જે ઘણું ઓછું કાર્યક્ષમ છે) નો ઉપયોગ કરીને બધું ત્યાં મોકલી શકો છો. ઝિપકીન પ્રોટોકોલ પોતે HTTP પ્રોટોકોલ દ્વારા કલેક્ટર્સને તમામ ટ્રેસિંગ માહિતી મોકલવાનો સમાવેશ કરે છે, જે ખૂબ ખર્ચાળ છે.

મેં પહેલેથી જ કહ્યું છે તેમ, અમે એપ્લિકેશન-લેવલ પ્રોટોકોલ્સને ટ્રેસ કરવા માંગીએ છીએ. આનો અર્થ એ છે કે દરેક સેવાની બાજુમાં રહેલા પ્રોક્સી સર્વર્સે સમજવું જોઈએ કે હવે કેવા પ્રકારની ક્રિયાપ્રતિક્રિયા થઈ રહી છે. મૂળભૂત રીતે, Istio તમામ પોર્ટ્સને સાદા TCP તરીકે ગોઠવે છે, જેનો અર્થ છે કે કોઈ નિશાનો મોકલવામાં આવશે નહીં. નિશાનો મોકલવા માટે, તમારે, સૌ પ્રથમ, મુખ્ય મેશ રૂપરેખામાં આ વિકલ્પને સક્ષમ કરવો જોઈએ અને, જે ખૂબ જ મહત્વપૂર્ણ છે, તે સેવામાં ઉપયોગમાં લેવાતા પ્રોટોકોલ અનુસાર kubernetes સેવા સંસ્થાઓના તમામ પોર્ટને નામ આપવું જોઈએ. તે છે, ઉદાહરણ તરીકે, આના જેવું:

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 સાથે એન્વોય ઇન્ટરફેસના એડમિન પોર્ટને વિનંતી કરવી પડશે. પરિણામી ગોઠવણીમાં, તમારે ઇચ્છિત સેવાના ઑપરેશન ફીલ્ડને જોવાની જરૂર છે. Istio માં જ્યાં વિનંતી કરવામાં આવે છે તેના ઓળખકર્તા તરીકે તેનો ઉપયોગ થાય છે. Istio માં આ પરિમાણના મૂલ્યને કસ્ટમાઇઝ કરવા માટે (પછી અમે તેને અમારી ટ્રેસિંગ સિસ્ટમમાં જોઈશું), સાઇડકાર કન્ટેનર લોંચ કરવાના તબક્કે સર્વિસક્લસ્ટર ફ્લેગનો ઉલ્લેખ કરવો જરૂરી છે. ઉદાહરણ તરીકે, ડાઉનવર્ડ kubernetes API માંથી મેળવેલા ચલોમાંથી તેની આ રીતે ગણતરી કરી શકાય છે:

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

દૂતમાં ટ્રેસિંગ કેવી રીતે કામ કરે છે તે સમજવા માટેનું એક સારું ઉદાહરણ છે અહીં.

ટ્રેસિંગ સ્પાન્સ મોકલવા માટેનો એન્ડપોઇન્ટ પણ એન્વોય પ્રોક્સી લોન્ચ ફ્લેગ્સમાં ઉલ્લેખિત હોવો આવશ્યક છે, ઉદાહરણ તરીકે: --zipkinAddress tracing-collector.tracing:9411

ગેરસમજ નંબર બે: અમે સસ્તી રીતે સિસ્ટમ દ્વારા વિનંતીઓના સંપૂર્ણ નિશાન મેળવી શકીએ છીએ.

કમનસીબે, તે નથી. અમલીકરણની જટિલતા તમે પહેલેથી જ સેવાઓની ક્રિયાપ્રતિક્રિયા કેવી રીતે અમલમાં મૂકી છે તેના પર નિર્ભર છે. તે શા માટે છે?

હકીકત એ છે કે ઇસ્ટિઓ-પ્રોક્સી એ જ સેવા છોડનારાઓ સાથેની સેવા માટે આવનારી વિનંતીઓના પત્રવ્યવહારને સમજવા માટે સક્ષમ થવા માટે, તે ફક્ત તમામ ટ્રાફિકને અટકાવવા માટે પૂરતું નથી. તમારી પાસે કોઈ પ્રકારનું સંચાર ઓળખકર્તા હોવું જરૂરી છે. HTTP દૂત પ્રોક્સી વિશિષ્ટ હેડરોનો ઉપયોગ કરે છે, જેના દ્વારા દૂત સમજે છે કે સેવાની કઈ વિશિષ્ટ વિનંતી અન્ય સેવાઓ માટે વિશિષ્ટ વિનંતીઓ જનરેટ કરે છે. આવા હેડરોની સૂચિ:

• x-request-id,
• x-b3-ટ્રેસિડ,
• x-b3-સ્પેનિડ,
• x-b3-પેરેન્ટસ્પેનિડ,
• x-b3-નમૂનો,
• x-b3-ધ્વજ,
• x-ot-span-સંદર્ભ.

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

નિષ્કર્ષ

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

સર્વિસ મેશ વિશેના આગલા લેખમાં, અમે Istio ની સૌથી મોટી સમસ્યા જોઈશું - દરેક સાઇડકાર પ્રોક્સી કન્ટેનર દ્વારા RAM નો મોટો વપરાશ અને તમે તેની સાથે કેવી રીતે વ્યવહાર કરી શકો તેની ચર્ચા કરીશું.

સોર્સ: www.habr.com