Istio និង Kubernetes នៅក្នុងផលិតកម្ម។ ផ្នែកទី 2. ការតាមដាន

ក្នុង​អតីតកាល អត្ថបទ យើងបានពិនិត្យមើលធាតុផ្សំជាមូលដ្ឋាននៃ Service Mesh Istio បានស្គាល់ប្រព័ន្ធ និងបានឆ្លើយសំណួរសំខាន់ៗដែលជាធម្មតាកើតឡើងនៅពេលចាប់ផ្តើមធ្វើការជាមួយ Istio ។ នៅក្នុងផ្នែកនេះ យើងនឹងពិនិត្យមើលរបៀបរៀបចំការប្រមូលព័ត៌មានតាមដានតាមបណ្តាញ។

រឿងដំបូងដែលគិតដល់សម្រាប់អ្នកអភិវឌ្ឍន៍ និងអ្នកគ្រប់គ្រងប្រព័ន្ធជាច្រើននៅពេលពួកគេឮពាក្យ Service Mesh កំពុងតាមដាន។ ជាការពិតណាស់ យើងបន្ថែមម៉ាស៊ីនមេប្រូកស៊ីពិសេសមួយទៅកាន់ថ្នាំងបណ្តាញនីមួយៗ ដែលចរាចរ TCP ទាំងអស់ឆ្លងកាត់។ វាហាក់ដូចជាថាឥឡូវនេះវាអាចធ្វើទៅបានយ៉ាងងាយស្រួលក្នុងការផ្ញើព័ត៌មានអំពីអន្តរកម្មបណ្តាញទាំងអស់នៅលើបណ្តាញ។ ជាអកុសលនៅក្នុងការពិតមាន nuances ជាច្រើនដែលចាំបាច់ត្រូវយកទៅក្នុងគណនី។ សូមក្រឡេកមើលពួកគេ។

ការយល់ច្រឡំលេខមួយ៖ យើងអាចទទួលបានទិន្នន័យដើរលេងតាមអ៊ីនធឺណិតដោយឥតគិតថ្លៃ។

ជាការពិត ដោយមិនគិតថ្លៃ យើងអាចទទួលបានតែថ្នាំងនៃប្រព័ន្ធរបស់យើងដែលភ្ជាប់ដោយព្រួញ និងអត្រាទិន្នន័យដែលឆ្លងកាត់រវាងសេវាកម្ម (តាមពិតមានតែចំនួនបៃក្នុងមួយឯកតានៃពេលវេលា)។ ទោះយ៉ាងណាក៏ដោយ ក្នុងករណីភាគច្រើន សេវាកម្មរបស់យើងទាក់ទងគ្នាលើប្រភេទនៃពិធីការស្រទាប់កម្មវិធីមួយចំនួន ដូចជា HTTP, gRPC, Redis ជាដើម។ ហើយជាការពិតណាស់ យើងចង់ឃើញព័ត៌មានតាមដានជាពិសេសសម្រាប់ពិធីការទាំងនេះ យើងចង់ឃើញអត្រាសំណើ មិនមែនអត្រាទិន្នន័យទេ។ យើងចង់ស្វែងយល់ពីភាពយឺតយ៉ាវនៃសំណើដោយប្រើពិធីការរបស់យើង។ ជាចុងក្រោយ យើងចង់ឃើញផ្លូវពេញលេញដែលសំណើត្រូវការពីការចូលទៅក្នុងប្រព័ន្ធរបស់យើងដើម្បីទទួលបានការឆ្លើយតបពីអ្នកប្រើប្រាស់។ បញ្ហានេះលែងងាយស្រួលដោះស្រាយទៀតហើយ។

ជាដំបូង សូមក្រឡេកមើលអ្វីដែលការបញ្ជូនបន្តមើលទៅហាក់ដូចជាពីទិដ្ឋភាពស្ថាបត្យកម្មនៅក្នុង Istio ។ ដូចដែលយើងចងចាំពីផ្នែកទីមួយ Istio មានសមាសភាគដាច់ដោយឡែកមួយហៅថា Mixer សម្រាប់ប្រមូល telemetry ។ ទោះយ៉ាងណាក៏ដោយ នៅក្នុងកំណែបច្ចុប្បន្ន 1.0.* ការផ្ញើគឺធ្វើឡើងដោយផ្ទាល់ពីម៉ាស៊ីនមេប្រូកស៊ី ពោលគឺពីប្រូកស៊ីប្រេសិត។ ប្រូកស៊ី​ប្រេសិត​គាំទ្រ​ការ​ផ្ញើ​ចន្លោះ​ការ​តាមដាន​ដោយ​ប្រើ​ពិធីការ zipkin ចេញពី​ប្រអប់។ វាអាចធ្វើទៅបានដើម្បីភ្ជាប់ពិធីការផ្សេងទៀត ប៉ុន្តែបានតែតាមរយៈកម្មវិធីជំនួយប៉ុណ្ណោះ។ ជាមួយ Istio យើងទទួលបានប្រូកស៊ីបេសកជនដែលបានប្រមូលផ្តុំ និងកំណត់រចនាសម្ព័ន្ធភ្លាមៗ ដែលគាំទ្រតែពិធីការ zipkin ប៉ុណ្ណោះ។ ប្រសិនបើយើងចង់ប្រើឧទាហរណ៍ ពិធីការ Jaeger ហើយផ្ញើការតាមដានតាមរយៈ UDP នោះយើងនឹងត្រូវការបង្កើតរូបភាព istio-proxy ផ្ទាល់ខ្លួនរបស់យើង។ មានការគាំទ្រសម្រាប់កម្មវិធីជំនួយផ្ទាល់ខ្លួនសម្រាប់ istio-ប្រូកស៊ី ប៉ុន្តែវានៅតែស្ថិតក្នុងកំណែអាល់ហ្វាដដែល។ ដូច្នេះហើយ ប្រសិនបើយើងចង់ធ្វើដោយគ្មានការកំណត់ផ្ទាល់ខ្លួនមួយចំនួនធំ នោះជួរនៃបច្ចេកវិទ្យាដែលប្រើសម្រាប់ការរក្សាទុក និងទទួលវិសាលភាពតាមដានត្រូវបានកាត់បន្ថយ។ តាមពិតទៅ ប្រព័ន្ធសំខាន់ៗឥឡូវនេះអ្នកអាចប្រើ Zipkin ខ្លួនឯង ឬ Jaeger ប៉ុន្តែផ្ញើអ្វីៗទាំងអស់នៅទីនោះដោយប្រើពិធីការដែលត្រូវគ្នានឹង zipkin (ដែលមានប្រសិទ្ធភាពតិចជាងច្រើន)។ ពិធីការ zipkin ខ្លួនវាពាក់ព័ន្ធនឹងការបញ្ជូនព័ត៌មានតាមដានទាំងអស់ទៅកាន់អ្នកប្រមូលតាមរយៈពិធីការ 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)។ ទម្រង់គឺ៖ proto-extra ។

ដើម្បី​កុំ​ឱ្យ​បំប្លែង​ការ​កំណត់​ចំនួន​ដ៏ច្រើន​ក្នុង​ការ​កំណត់​ពិធីការ អ្នក​អាច​ប្រើ​វិធី​ដោះស្រាយ​កខ្វក់៖ បំណះ​សមាសភាគ​អ្នក​បើក​យន្តហោះ​នៅ​ពេល​ដែល​វា​គ្រាន់តែ អនុវត្តតក្កវិជ្ជានិយមន័យពិធីការ. ជាចុងក្រោយ វានឹងចាំបាច់ក្នុងការផ្លាស់ប្តូរតក្កវិជ្ជានេះទៅជាស្តង់ដារ ហើយប្តូរទៅអនុសញ្ញាដាក់ឈ្មោះសម្រាប់ច្រកទាំងអស់។

ដើម្បីយល់ថាតើពិធីការពិតជាត្រូវបានកំណត់យ៉ាងត្រឹមត្រូវឬអត់ អ្នកត្រូវចូលទៅក្នុងកុងតឺន័ររថយន្តចំហៀងណាមួយដែលមានប្រូកស៊ីប្រេសិត ហើយធ្វើការស្នើសុំទៅកាន់ច្រករដ្ឋបាលនៃចំណុចប្រទាក់ប្រេសិតជាមួយទីតាំង /config_dump ។ នៅក្នុងការកំណត់រចនាសម្ព័ន្ធលទ្ធផលអ្នកត្រូវមើលវាលប្រតិបត្តិការនៃសេវាកម្មដែលចង់បាន។ វា​ត្រូវ​បាន​ប្រើ​នៅ​ក្នុង Istio ជា​អ្នក​កំណត់​អត្តសញ្ញាណ​សម្រាប់​កន្លែង​ដែល​សំណើ​ត្រូវ​បាន​ធ្វើ​ឡើង។ ដើម្បីប្ដូរតាមបំណងតម្លៃនៃប៉ារ៉ាម៉ែត្រនេះនៅក្នុង Istio (បន្ទាប់មកយើងនឹងឃើញវានៅក្នុងប្រព័ន្ធតាមដានរបស់យើង) វាចាំបាច់ក្នុងការបញ្ជាក់ទង់ serviceCluster នៅដំណាក់កាលនៃការបើកដំណើរការកុងតឺន័រចំហៀង។ ឧទាហរណ៍ វាអាចត្រូវបានគណនាដូចនេះពីអថេរដែលទទួលបានពី kubernetes API ចុះក្រោម៖

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

ឧទាហរណ៍ដ៏ល្អមួយដើម្បីយល់ពីរបៀបដែលការតាមដានដំណើរការនៅក្នុងបេសកជនគឺ នៅទីនេះ.

ចំណុចបញ្ចប់ខ្លួនវាសម្រាប់ការផ្ញើចន្លោះការតាមដានក៏ត្រូវតែបញ្ជាក់នៅក្នុងទង់បើកដំណើរការប្រូកស៊ីបេសកជនផងដែរ ឧទាហរណ៍៖ --zipkinAddress tracing-collector.tracing:9411

ការយល់ខុសទី XNUMX៖ យើងអាចទទួលបានដានពេញលេញនៃសំណើដោយមានតំលៃថោកតាមរយៈប្រព័ន្ធចេញពីប្រអប់

ជាអកុសលវាមិនមែនទេ។ ភាពស្មុគស្មាញនៃការអនុវត្តគឺអាស្រ័យលើរបៀបដែលអ្នកបានអនុវត្តអន្តរកម្មនៃសេវាកម្មរួចហើយ។ ហេតុអ្វីបានជា​អញ្ចឹង?

ការពិតគឺថាដើម្បីឱ្យ istio-ប្រូកស៊ីអាចយល់ពីការឆ្លើយឆ្លងនៃសំណើចូលទៅកាន់សេវាកម្មជាមួយអ្នកដែលចាកចេញពីសេវាកម្មដូចគ្នានោះ វាមិនគ្រប់គ្រាន់ទេក្នុងការស្ទាក់ចាប់រាល់ចរាចរណ៍ទាំងអស់។ អ្នកត្រូវមានប្រភេទឧបករណ៍សម្គាល់ទំនាក់ទំនង។ ប្រូកស៊ីបេសកជន HTTP ប្រើបឋមកថាពិសេស ដោយប្រេសិតយល់ថាសំណើជាក់លាក់ណាមួយចំពោះសេវាកម្មបង្កើតសំណើជាក់លាក់ចំពោះសេវាកម្មផ្សេងទៀត។ បញ្ជីនៃចំណងជើងបែបនេះ៖

• x-request-id
• x-b3-traceid,
• x-b3-អេស្ប៉ាញ,
• x-b3-parentspanid,
• x-b3-គំរូ,
• x-b3-ទង់,
• x-ot-span-context ។

ប្រសិនបើអ្នកមានចំណុចតែមួយ ជាឧទាហរណ៍ ម៉ាស៊ីនភ្ញៀវមូលដ្ឋាន ដែលអ្នកអាចបន្ថែមតក្កវិជ្ជាបែបនេះ អ្វីៗគឺល្អ អ្នកគ្រាន់តែត្រូវការរង់ចាំឱ្យបណ្ណាល័យនេះធ្វើបច្ចុប្បន្នភាពសម្រាប់អតិថិជនទាំងអស់។ ប៉ុន្តែប្រសិនបើអ្នកមានប្រព័ន្ធខុសគ្នាខ្លាំង ហើយមិនមានការបង្រួបបង្រួមក្នុងការផ្លាស់ប្តូរពីសេវាកម្មមួយទៅសេវាកម្មមួយនៅលើបណ្តាញទេនោះ នេះទំនងជាបញ្ហាធំមួយ។ បើគ្មានការបន្ថែមតក្កវិជ្ជាបែបនេះទេ ព័ត៌មានតាមដានទាំងអស់នឹងគ្រាន់តែជា "កម្រិតតែមួយ" ប៉ុណ្ណោះ។ នោះគឺយើងនឹងទទួលបាននូវអន្តរកម្មសេវាកម្មទាំងអស់ ប៉ុន្តែពួកវានឹងមិនត្រូវបានភ្ជាប់ទៅក្នុងខ្សែសង្វាក់តែមួយនៃការឆ្លងកាត់តាមរយៈបណ្តាញនោះទេ។

សេចក្តីសន្និដ្ឋាន

Istio ផ្តល់នូវឧបករណ៍ងាយស្រួលសម្រាប់ការប្រមូលព័ត៌មានតាមដានតាមបណ្តាញ ប៉ុន្តែអ្នកត្រូវតែយល់ថាសម្រាប់ការអនុវត្ត អ្នកនឹងត្រូវសម្របប្រព័ន្ធរបស់អ្នក និងគិតគូរពីលក្ខណៈពិសេសនៃការអនុវត្ត Istio ។ ជាលទ្ធផល ចំណុចសំខាន់ពីរចាំបាច់ត្រូវដោះស្រាយ៖ ការកំណត់ពិធីការកម្រិតកម្មវិធី (ដែលត្រូវតែគាំទ្រដោយប្រូកស៊ីប្រេសិត) និងរៀបចំការបញ្ជូនបន្តព័ត៌មានអំពីការតភ្ជាប់សំណើទៅសេវាកម្មពីសំណើពីសេវាកម្ម (ដោយប្រើបឋមកថា នៅក្នុងករណីនៃពិធីការ HTTP) ។ នៅពេលដែលបញ្ហាទាំងនេះត្រូវបានដោះស្រាយ យើងមានឧបករណ៍ដ៏មានអានុភាពដែលអនុញ្ញាតឱ្យយើងប្រមូលព័ត៌មានពីបណ្តាញប្រកបដោយតម្លាភាព សូម្បីតែនៅក្នុងប្រព័ន្ធដែលខុសគេច្រើនដែលសរសេរជាភាសា និងក្របខ័ណ្ឌផ្សេងៗគ្នាក៏ដោយ។

នៅក្នុងអត្ថបទបន្ទាប់អំពី Service Mesh យើងនឹងពិនិត្យមើលបញ្ហាដ៏ធំបំផុតមួយជាមួយ Istio – ការប្រើប្រាស់ RAM ច្រើនដោយធុងប្រូកស៊ីរបស់ sidecar នីមួយៗ ហើយពិភាក្សាពីរបៀបដែលអ្នកអាចដោះស្រាយវាបាន។

ប្រភព: www.habr.com