របៀបដំណើរការ Istio ដោយប្រើ Kubernetes នៅក្នុងផលិតកម្ម។ ផ្នែកទី 1

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

អ្នកអាចអានអំពីយន្តការនៃការងារនៅក្នុង ឯកសារផ្លូវការ. Istio គឺជាឧបករណ៍ដ៏មានអានុភាពដែលអនុញ្ញាតឱ្យអ្នកដោះស្រាយកិច្ចការ និងបញ្ហាជាច្រើន។ នៅក្នុងអត្ថបទនេះ ខ្ញុំចង់ឆ្លើយសំណួរសំខាន់ៗដែលជាធម្មតាកើតឡើងនៅពេលចាប់ផ្តើមជាមួយ Istio ។ នេះនឹងជួយអ្នកដោះស្រាយវាលឿនជាងមុន។

របៀបដែលវាធ្វើការ

Istio មានផ្នែកសំខាន់ពីរ - យន្តហោះគ្រប់គ្រង និងយន្តហោះទិន្នន័យ។ យន្តហោះបញ្ជាមានធាតុផ្សំសំខាន់ៗដែលធានាបាននូវប្រតិបត្តិការត្រឹមត្រូវនៃនៅសល់។ នៅក្នុងកំណែបច្ចុប្បន្ន (1.0) យន្តហោះគ្រប់គ្រងមានធាតុផ្សំសំខាន់ៗចំនួនបីគឺ Pilot, Mixer, Citadel ។ យើងនឹងមិនពិចារណា Citadel ទេ វាចាំបាច់ដើម្បីបង្កើតវិញ្ញាបនបត្រ ដើម្បីធានាបាននូវ TLS ទៅវិញទៅមករវាងសេវាកម្ម។ សូមពិនិត្យមើលឱ្យកាន់តែដិតដល់នូវឧបករណ៍ និងគោលបំណងរបស់ Pilot និង Mixer ។

អ្នកបើកយន្តហោះគឺជាផ្នែកគ្រប់គ្រងសំខាន់ដែលចែកចាយព័ត៌មានទាំងអស់អំពីអ្វីដែលយើងមាននៅក្នុងចង្កោម - សេវាកម្ម ចំណុចបញ្ចប់ និងច្បាប់កំណត់ផ្លូវ (ឧទាហរណ៍ ច្បាប់សម្រាប់ការដាក់ពង្រាយ Canary ឬច្បាប់បំបែកសៀគ្វី)។

ឧបករណ៍លាយគឺជាធាតុផ្សំនៃយន្តហោះត្រួតពិនិត្យស្រេចចិត្ត ដែលផ្តល់នូវសមត្ថភាពក្នុងការប្រមូលម៉ែត្រ កំណត់ហេតុ និងព័ត៌មានណាមួយអំពីអន្តរកម្មបណ្តាញ។ គាត់ក៏តាមដានការអនុលោមតាមច្បាប់គោលនយោបាយ និងការអនុលោមតាមកម្រិតអត្រាការប្រាក់។

យន្តហោះទិន្នន័យត្រូវបានអនុវត្តដោយប្រើធុងប្រូកស៊ី sidecar ។ ថាមពលត្រូវបានប្រើប្រាស់តាមលំនាំដើម។ ប្រូកស៊ីបេសកជន. វាអាចត្រូវបានជំនួសដោយការអនុវត្តមួយផ្សេងទៀតដូចជា nginx (nginmesh) ។

ដើម្បីឱ្យ Istio ដំណើរការប្រកបដោយតម្លាភាពចំពោះកម្មវិធី មានប្រព័ន្ធចាក់ដោយស្វ័យប្រវត្តិ។ ការអនុវត្តចុងក្រោយបំផុតគឺសមរម្យសម្រាប់កំណែ Kubernetes 1.9+ (ការផ្លាស់ប្តូរការចូលប្រើគេហទំព័រ)។ សម្រាប់ Kubernetes កំណែ 1.7, 1.8 វាគឺអាចធ្វើទៅបានដើម្បីប្រើ Initializer ។

ធុង Sidecar ត្រូវបានភ្ជាប់ជាមួយ Pilot ដោយប្រើពិធីការ GRPC ដែលអនុញ្ញាតឱ្យអ្នកបង្កើនប្រសិទ្ធភាពគំរូជំរុញសម្រាប់ការផ្លាស់ប្តូរដែលកើតឡើងនៅក្នុងចង្កោម។ GRPC ត្រូវបានប្រើនៅក្នុង Envoy ចាប់តាំងពីកំណែ 1.6 នៅក្នុង Istio វាត្រូវបានគេប្រើតាំងពីកំណែ 0.8 និងជាភ្នាក់ងារសាកល្បង - កន្សែងរុំ golang លើបេសកជនដែលកំណត់រចនាសម្ព័ន្ធជម្រើសនៃការចាប់ផ្តើម។

Pilot និង Mixer គឺជាសមាសធាតុគ្មានរដ្ឋទាំងស្រុង រដ្ឋទាំងអស់ត្រូវបានរក្សាទុកក្នុងសតិ។ ការកំណត់រចនាសម្ព័ន្ធសម្រាប់ពួកវាត្រូវបានកំណត់ក្នុងទម្រង់នៃធនធានផ្ទាល់ខ្លួន Kubernetes ដែលត្រូវបានរក្សាទុកក្នុង ល។
ភ្នាក់ងារ Istio ទទួលបានអាសយដ្ឋានរបស់អ្នកបើកយន្តហោះ ហើយបើកស្ទ្រីម GRPC ទៅវា។

ដូចដែលខ្ញុំបាននិយាយ Istio អនុវត្តមុខងារទាំងអស់ប្រកបដោយតម្លាភាពចំពោះកម្មវិធី។ តោះមើលពីរបៀប។ ក្បួនដោះស្រាយគឺនេះ៖

1. ការដាក់ឱ្យប្រើប្រាស់កំណែថ្មីនៃសេវាកម្ម។
2. អាស្រ័យលើវិធីសាស្រ្តនៃការចាក់បញ្ចូលកុងតឺន័រ sidecar កុងតឺន័រ istio-init និងកុងតឺន័រ istio-ភ្នាក់ងារ (បេសកជន) ត្រូវបានបន្ថែមនៅដំណាក់កាលនៃការអនុវត្តការកំណត់រចនាសម្ព័ន្ធ ឬពួកវាអាចត្រូវបានបញ្ចូលដោយដៃចូលទៅក្នុងការពិពណ៌នារបស់អង្គភាព Kubernetes Pod រួចហើយ។
3. កុងតឺន័រ istio-init គឺជាស្គ្រីបដែលអនុវត្តច្បាប់ iptables ទៅផត។ មានជម្រើសពីរសម្រាប់កំណត់រចនាសម្ព័ន្ធចរាចរណ៍ដែលត្រូវរុំក្នុងកុងតឺន័រ istio-ភ្នាក់ងារ៖ ប្រើច្បាប់ប្តូរទិស iptables ឬ TPROXY. នៅពេលសរសេរ វិធីសាស្រ្តលំនាំដើមគឺជាមួយនឹងច្បាប់បញ្ជូនបន្ត។ នៅក្នុង istio-init វាអាចកំណត់រចនាសម្ព័ន្ធចរាចរណ៍ណាមួយដែលគួរត្រូវបានស្ទាក់ចាប់ ហើយផ្ញើទៅកាន់ istio-ភ្នាក់ងារ។ ឧទាហរណ៍ ដើម្បីស្ទាក់ចាប់រាល់ចរាចរណ៍ចូល និងចេញទាំងអស់ អ្នកត្រូវកំណត់ប៉ារ៉ាម៉ែត្រ -i и -b ចូលទៅក្នុងអត្ថន័យ *. អ្នកអាចបញ្ជាក់ច្រកជាក់លាក់ដើម្បីស្ទាក់ចាប់។ ដើម្បីកុំឱ្យស្ទាក់ចាប់បណ្តាញរងជាក់លាក់មួយ អ្នកអាចបញ្ជាក់វាដោយប្រើទង់ -x.
4. បន្ទាប់ពីកុងតឺន័រ init ត្រូវបានប្រតិបត្តិ វត្ថុសំខាន់ៗត្រូវបានដាក់ឱ្យដំណើរការ រួមទាំងភ្នាក់ងារអាកាសយានិក (បេសកជន)។ វាភ្ជាប់ទៅអ្នកបើកបរដែលបានដាក់ពង្រាយរួចហើយតាមរយៈ GRPC និងទទួលបានព័ត៌មានអំពីសេវាកម្មដែលមានស្រាប់ទាំងអស់ និងគោលការណ៍កំណត់ផ្លូវនៅក្នុងចង្កោម។ យោងទៅតាមទិន្នន័យដែលទទួលបាន គាត់កំណត់រចនាសម្ព័ន្ធចង្កោម និងកំណត់ពួកវាដោយផ្ទាល់ទៅចំណុចបញ្ចប់នៃកម្មវិធីរបស់យើងនៅក្នុងចង្កោម Kubernetes ។ វាក៏ចាំបាច់ផងដែរក្នុងការកត់សម្គាល់ចំណុចសំខាន់មួយ៖ បេសកជនកំណត់រចនាសម្ព័ន្ធអ្នកស្តាប់យ៉ាងសកម្ម (IP, ច្រកគូ) ដែលវាចាប់ផ្តើមស្តាប់។ ដូច្នេះ នៅពេលដែលសំណើចូលទៅក្នុង pod ត្រូវបានបញ្ជូនបន្តដោយប្រើច្បាប់ redirect iptables នៅក្នុង sidecar បេសកជនអាចដំណើរការការតភ្ជាប់ទាំងនេះដោយជោគជ័យរួចហើយ និងយល់ពីកន្លែងដែលត្រូវបញ្ជូនបន្តចរាចរ។ ផងដែរនៅដំណាក់កាលនេះ ព័ត៌មានត្រូវបានផ្ញើទៅកាន់ឧបករណ៍លាយ ដែលយើងនឹងពិនិត្យមើលនៅពេលក្រោយ ហើយវិសាលភាពតាមដានត្រូវបានផ្ញើ។

ជាលទ្ធផល យើងទទួលបានបណ្តាញទាំងមូលនៃម៉ាស៊ីនមេប្រូកស៊ីប្រេសិត ដែលយើងអាចកំណត់រចនាសម្ព័ន្ធពីចំណុចមួយ (Pilot)។ រាល់សំណើទាំងក្នុង និងក្រៅប្រទេសត្រូវឆ្លងកាត់បេសកជន។ លើសពីនេះទៅទៀត មានតែចរាចរណ៍ TCP ប៉ុណ្ណោះដែលត្រូវបានស្ទាក់ចាប់។ នេះមានន័យថា IP សេវាកម្ម Kubernetes ត្រូវបានដោះស្រាយដោយប្រើ kube-dns លើ UDP ដោយមិនផ្លាស់ប្តូរ។ បន្ទាប់មក បន្ទាប់ពីការដោះស្រាយ សំណើដែលចេញត្រូវបានស្ទាក់ចាប់ និងដំណើរការដោយបេសកជន ដែលសម្រេចរួចហើយថាតើចំណុចបញ្ចប់ណាមួយដែលសំណើគួរតែត្រូវបានផ្ញើទៅ (ឬមិនផ្ញើ ក្នុងករណីគោលការណ៍ចូលដំណើរការ ឬឧបករណ៍បំបែកសៀគ្វីនៃក្បួនដោះស្រាយ)។

យើងបានស្វែងយល់ពី Pilot ឥឡូវនេះយើងត្រូវយល់ពីរបៀបដែលឧបករណ៍លាយដំណើរការ និងមូលហេតុដែលវាត្រូវការ។ អ្នកអាចអានឯកសារផ្លូវការសម្រាប់វា។ នៅទីនេះ.

ឧបករណ៍លាយក្នុងទម្រង់បច្ចុប្បន្នរបស់វាមានធាតុផ្សំពីរគឺ istio-telemetry, istio-policy (មុនកំណែ 0.8 វាជាសមាសធាតុ istio-mixer មួយ)។ ពួកគេទាំងពីរគឺជាឧបករណ៍លាយដែលនីមួយៗទទួលខុសត្រូវចំពោះភារកិច្ចរបស់ខ្លួន។ Istio telemetry ទទួលបានព័ត៌មានអំពីអ្នកដែលទៅទីណា និងជាមួយប៉ារ៉ាម៉ែត្រអ្វីខ្លះពីធុងដាក់របាយការណ៍តាម GRPC ។ Istio-policy ទទួលយកសំណើពិនិត្យ ដើម្បីផ្ទៀងផ្ទាត់ថាច្បាប់គោលការណ៍ត្រូវបានពេញចិត្ត។ ជាការពិតណាស់ ការត្រួតពិនិត្យប៉ូឡូញមិនត្រូវបានអនុវត្តសម្រាប់រាល់ការស្នើសុំនោះទេ ប៉ុន្តែត្រូវបានទុកក្នុងឃ្លាំងសម្ងាត់នៅលើម៉ាស៊ីនភ្ញៀវ (នៅក្នុងរថយន្តចំហៀង) សម្រាប់ពេលវេលាជាក់លាក់មួយ។ របាយការណ៍ត្រួតពិនិត្យត្រូវបានផ្ញើជាសំណើជាបាច់។ ចូរយើងមើលពីរបៀបកំណត់រចនាសម្ព័ន្ធ និងប៉ារ៉ាម៉ែត្រអ្វីដែលគួរត្រូវបានផ្ញើនៅពេលក្រោយបន្តិច។

ឧបករណ៍លាយត្រូវបានគេសន្មត់ថាជាសមាសធាតុដែលអាចប្រើបានខ្ពស់ដែលធានានូវការងារដែលមិនមានការរំខានលើការផ្គុំ និងដំណើរការទិន្នន័យទូរលេខ។ ប្រព័ន្ធនេះត្រូវបានទទួលជាលទ្ធផលជាសតិបណ្ដោះអាសន្នពហុកម្រិត។ ដំបូង ទិន្នន័យ​ត្រូវ​បាន​បណ្ដោះ​អាសន្ន​នៅ​ផ្នែក​ខាង​រថយន្ត​នៃ​កុងតឺន័រ បន្ទាប់​មក​នៅ​ខាង​ឧបករណ៍​លាយ ហើយ​បន្ទាប់​មក​ត្រូវ​បាន​ផ្ញើ​ទៅ​អ្វី​ដែល​ហៅ​ថា​ឧបករណ៍​លាយ​ខាងក្រោយ។ ជាលទ្ធផល ប្រសិនបើសមាសធាតុប្រព័ន្ធណាមួយបរាជ័យ សតិបណ្ដោះអាសន្ននឹងលូតលាស់ និងត្រូវបានហូរបន្ទាប់ពីប្រព័ន្ធត្រូវបានស្ដារឡើងវិញ។ ផ្នែកខាងក្រោយរបស់ឧបករណ៍លាយគឺជាចំណុចបញ្ចប់សម្រាប់ការផ្ញើទិន្នន័យ telemetry៖ statsd, newrelic ជាដើម។ អ្នកអាចសរសេរកម្មវិធីខាងក្រោយរបស់អ្នកបាន វាសាមញ្ញណាស់ ហើយយើងនឹងឃើញពីរបៀបធ្វើវា។

ដើម្បីសង្ខេបគ្រោងការណ៍សម្រាប់ធ្វើការជាមួយ istio-telemetry មានដូចខាងក្រោម។

1. សេវា 1 ផ្ញើសំណើទៅសេវាកម្ម 2 ។
2. នៅពេលចាកចេញពីសេវាកម្មទី 1 សំណើត្រូវបានរុំដោយរថយន្តផ្ទាល់ខ្លួនរបស់វា។
3. បេសកជន Sidecar ត្រួតពិនិត្យពីរបៀបដែលសំណើទៅកាន់សេវា 2 និងរៀបចំព័ត៌មានចាំបាច់។
4. បន្ទាប់មកផ្ញើវាទៅ istio-telemetry ដោយប្រើការស្នើសុំរបាយការណ៍។
5. Istio-telemetry កំណត់ថាតើរបាយការណ៍នេះគួរតែត្រូវបានផ្ញើទៅកាន់ផ្នែកខាងក្រោយ តើត្រូវផ្ញើទិន្នន័យណា និងទិន្នន័យអ្វី។
6. Istio-telemetry ផ្ញើទិន្នន័យរាយការណ៍ទៅផ្នែកខាងក្រោយប្រសិនបើចាំបាច់។

ឥឡូវនេះសូមមើលពីរបៀបដាក់ពង្រាយ Istio នៅក្នុងប្រព័ន្ធដែលមានតែធាតុផ្សំសំខាន់ៗ (អ្នកបើកបរយន្តហោះ និងបេសកជនខាងរថយន្ត)។

ជាដំបូង សូមក្រឡេកមើល ការកំណត់រចនាសម្ព័ន្ធចម្បង (សំណាញ់) ដែល Pilot អាន៖

apiVersion: v1
kind: ConfigMap
metadata:
  name: istio
  namespace: istio-system
  labels:
    app: istio
    service: istio
data:
  mesh: |-

    # пока что не включаем отправку tracing информации (pilot настроит envoy’и таким образом, что отправка не будет происходить)
    enableTracing: false

    # пока что не указываем mixer endpoint’ы, чтобы sidecar контейнеры не отправляли информацию туда
    #mixerCheckServer: istio-policy.istio-system:15004
    #mixerReportServer: istio-telemetry.istio-system:15004

    # ставим временной промежуток, с которым будет envoy переспрашивать Pilot (это для старой версии envoy proxy)
    rdsRefreshDelay: 5s

    # default конфигурация для envoy sidecar
    defaultConfig:
      # аналогично как rdsRefreshDelay
      discoveryRefreshDelay: 5s

      # оставляем по умолчанию (путь к конфигурации и бинарю envoy)
      configPath: "/etc/istio/proxy"
      binaryPath: "/usr/local/bin/envoy"

      # дефолтное имя запущенного sidecar контейнера (используется, например, в именах сервиса при отправке tracing span’ов)
      serviceCluster: istio-proxy

      # время, которое будет ждать envoy до того, как он принудительно завершит все установленные соединения
      drainDuration: 45s
      parentShutdownDuration: 1m0s

      # по умолчанию используются REDIRECT правила iptables. Можно изменить на TPROXY.
      #interceptionMode: REDIRECT

      # Порт, на котором будет запущена admin панель каждого sidecar контейнера (envoy)
      proxyAdminPort: 15000

      # адрес, по которому будут отправляться trace’ы по zipkin протоколу (в начале мы отключили саму отправку, поэтому это поле сейчас не будет использоваться)
      zipkinAddress: tracing-collector.tracing:9411

      # statsd адрес для отправки метрик envoy контейнеров (отключаем)
      # statsdUdpAddress: aggregator:8126

      # выключаем поддержку опции Mutual TLS
      controlPlaneAuthPolicy: NONE

      # адрес, на котором будет слушать istio-pilot для того, чтобы сообщать информацию о service discovery всем sidecar контейнерам
      discoveryAddress: istio-pilot.istio-system:15007

សមាសធាតុគ្រប់គ្រងសំខាន់ៗទាំងអស់ (យន្តហោះបញ្ជា) នឹងមានទីតាំងនៅក្នុងប្រព័ន្ធ namespace istio-system នៅក្នុង Kubernetes ។

យ៉ាងហោចណាស់ យើងគ្រាន់តែត្រូវដាក់ពង្រាយ Pilot ប៉ុណ្ណោះ។ សម្រាប់រឿងនេះយើងនឹងប្រើ ការកំណត់រចនាសម្ព័ន្ធបែបនេះ។

ហើយ​យើង​នឹង​កំណត់​រចនាសម្ព័ន្ធ​រថយន្ត​ចាក់​បញ្ចូល​គ្នា​នៃ​កុងតឺន័រ​ដោយដៃ។

ធុងផ្ទុក៖

initContainers:
 - name: istio-init
   args:
   - -p
   - "15001"
   - -u
   - "1337"
   - -m
   - REDIRECT
   - -i
   - '*'
   - -b
   - '*'
   - -d
   - ""
   image: istio/proxy_init:1.0.0
   imagePullPolicy: IfNotPresent
   resources:
     limits:
       memory: 128Mi
   securityContext:
     capabilities:
       add:
       - NET_ADMIN

និងខាងឡាន៖

       name: istio-proxy
       args:
         - "bash"
         - "-c"
         - |
           exec /usr/local/bin/pilot-agent proxy sidecar 
           --configPath 
           /etc/istio/proxy 
           --binaryPath 
           /usr/local/bin/envoy 
           --serviceCluster 
           service-name 
           --drainDuration 
           45s 
           --parentShutdownDuration 
           1m0s 
           --discoveryAddress 
           istio-pilot.istio-system:15007 
           --discoveryRefreshDelay 
           1s 
           --connectTimeout 
           10s 
           --proxyAdminPort 
           "15000" 
           --controlPlaneAuthPolicy 
           NONE
         env:
         - name: POD_NAME
           valueFrom:
             fieldRef:
               fieldPath: metadata.name
         - name: POD_NAMESPACE
           valueFrom:
             fieldRef:
               fieldPath: metadata.namespace
         - name: INSTANCE_IP
           valueFrom:
             fieldRef:
               fieldPath: status.podIP
         - name: ISTIO_META_POD_NAME
           valueFrom:
             fieldRef:
               fieldPath: metadata.name
         - name: ISTIO_META_INTERCEPTION_MODE
           value: REDIRECT
         image: istio/proxyv2:1.0.0
         imagePullPolicy: IfNotPresent
         resources:
           requests:
             cpu: 100m
             memory: 128Mi
           limits:
             memory: 2048Mi
         securityContext:
           privileged: false
           readOnlyRootFilesystem: true
           runAsUser: 1337
         volumeMounts:
         - mountPath: /etc/istio/proxy
           name: istio-envoy

ដើម្បីឱ្យអ្វីៗចាប់ផ្តើមដោយជោគជ័យ អ្នកត្រូវបង្កើត ServiceAccount, ClusterRole, ClusterRoleBinding, CRD for Pilot ការពិពណ៌នាដែលអាចត្រូវបានរកឃើញ នៅទីនេះ.

ជាលទ្ធផល សេវាកម្មដែលយើងចាក់រថយន្តចំហៀងជាមួយប្រេសិតគួរតែចាប់ផ្តើមដោយជោគជ័យ ទទួលបានការរកឃើញទាំងអស់ពីអ្នកបើកបរ និងសំណើដំណើរការ។

វាជាការសំខាន់ណាស់ដែលត្រូវយល់ថាធាតុផ្សំនៃយន្តហោះគ្រប់គ្រងទាំងអស់គឺជាកម្មវិធីគ្មានរដ្ឋ ហើយអាចធ្វើមាត្រដ្ឋានផ្ដេកដោយគ្មានបញ្ហា។ ទិន្នន័យទាំងអស់ត្រូវបានរក្សាទុកក្នុង etcd ក្នុងទម្រង់នៃការពិពណ៌នាផ្ទាល់ខ្លួននៃធនធាន Kubernetes ។

ដូចគ្នានេះផងដែរ Istio (នៅតែពិសោធន៍) មានសមត្ថភាពក្នុងការដំណើរការនៅខាងក្រៅចង្កោម និងសមត្ថភាពក្នុងការមើល និងការរកឃើញសេវាកម្មដែលគួរឱ្យធុញទ្រាន់រវាងក្រុម Kubernetes ជាច្រើន។ អ្នកអាចអានបន្ថែមអំពីរឿងនេះ នៅទីនេះ.

សម្រាប់ការដំឡើងពហុចង្កោម ត្រូវដឹងពីដែនកំណត់ខាងក្រោម៖

1. Pod CIDR និង Service CIDR ត្រូវតែមានតែមួយនៅទូទាំងចង្កោមទាំងអស់ ហើយមិនត្រូវត្រួតលើគ្នា។
2. CIDR Pods ទាំងអស់ត្រូវតែអាចទៅដល់ពី CIDR Pods ណាមួយរវាងចង្កោម។
3. ម៉ាស៊ីនមេ Kubernetes API ទាំងអស់ត្រូវតែអាចចូលប្រើបានគ្នាទៅវិញទៅមក។

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

ប្រភព: www.habr.com