Calico សម្រាប់បណ្តាញនៅក្នុង Kubernetes៖ ការណែនាំ និងបទពិសោធន៍តិចតួច

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

ការណែនាំរហ័សចំពោះឧបករណ៍បណ្តាញ Kubernetes

ចង្កោម Kubernetes មិនអាចត្រូវបានស្រមៃដោយគ្មានបណ្តាញទេ។ យើង​បាន​បោះពុម្ព​ឯកសារ​លើ​មូលដ្ឋាន​របស់​ពួកគេ​រួច​ហើយ៖ "មគ្គុទ្ទេសក៍បង្ហាញអំពីបណ្តាញនៅក្នុង Kubernetes"ហើយ"ការណែនាំអំពីគោលការណ៍បណ្តាញ Kubernetes សម្រាប់អ្នកជំនាញផ្នែកសុវត្ថិភាព"។

នៅក្នុងបរិបទនៃអត្ថបទនេះ វាជារឿងសំខាន់ក្នុងការកត់សម្គាល់ថា K8s ខ្លួនវាមិនទទួលខុសត្រូវចំពោះការភ្ជាប់បណ្តាញរវាងកុងតឺន័រ និងថ្នាំងទេ៖ សម្រាប់បញ្ហានេះ ផ្សេងៗ កម្មវិធីជំនួយ CNI (ចំណុចប្រទាក់បណ្តាញកុងតឺន័រ) ។ បន្ថែមទៀតអំពីគំនិតនេះយើង ពួកគេក៏បានប្រាប់ខ្ញុំដែរ។.

ឧទាហរណ៍ ធម្មតាបំផុតនៃកម្មវិធីជំនួយទាំងនេះគឺ Flannel — ផ្តល់នូវការភ្ជាប់បណ្តាញពេញលេញរវាងថ្នាំងចង្កោមទាំងអស់ដោយការបង្កើនស្ពាននៅលើថ្នាំងនីមួយៗ ដោយកំណត់បណ្តាញរងទៅវា។ ទោះជាយ៉ាងណាក៏ដោយ លទ្ធភាពប្រើប្រាស់ពេញលេញ និងមិនមានការគ្រប់គ្រងគឺមិនតែងតែមានអត្ថប្រយោជន៍នោះទេ។ ដើម្បីផ្តល់នូវភាពឯកោតិចតួចមួយចំនួននៅក្នុងចង្កោម វាចាំបាច់ក្នុងការធ្វើអន្តរាគមន៍ក្នុងការកំណត់រចនាសម្ព័ន្ធជញ្ជាំងភ្លើង។ ក្នុងករណីទូទៅ វាត្រូវបានដាក់នៅក្រោមការគ្រប់គ្រងរបស់ CNI ដូចគ្នា ដែលនេះជាមូលហេតុដែលអន្តរាគមន៍ភាគីទីបីនៅក្នុង iptables អាចត្រូវបានបកស្រាយមិនត្រឹមត្រូវ ឬមិនអើពើទាំងស្រុង។

ហើយ "ក្រៅប្រអប់" សម្រាប់ការរៀបចំការគ្រប់គ្រងគោលនយោបាយបណ្តាញនៅក្នុងចង្កោម Kubernetes ត្រូវបានផ្តល់ជូន NetworkPolicy API. ធនធាននេះ ចែកចាយលើចន្លោះឈ្មោះដែលបានជ្រើសរើស អាចមានច្បាប់សម្រាប់បែងចែកការចូលប្រើប្រាស់ពីកម្មវិធីមួយទៅកម្មវិធីមួយទៀត។ វាក៏អនុញ្ញាតឱ្យអ្នកកំណត់រចនាសម្ព័ន្ធភាពងាយស្រួលរវាង pods ជាក់លាក់ បរិស្ថាន (namespaces) ឬប្លុកនៃអាសយដ្ឋាន IP៖

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: test-network-policy
  namespace: default
spec:
  podSelector:
    matchLabels:
      role: db
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - ipBlock:
        cidr: 172.17.0.0/16
        except:
        - 172.17.1.0/24
    - namespaceSelector:
        matchLabels:
          project: myproject
    - podSelector:
        matchLabels:
          role: frontend
    ports:
    - protocol: TCP
      port: 6379
  egress:
  - to:
    - ipBlock:
        cidr: 10.0.0.0/24
    ports:
    - protocol: TCP
      port: 5978

នេះមិនមែនជាឧទាហរណ៍បឋមបំផុតនោះទេ។ ឯកសារផ្លូវការ ម្តង និងសម្រាប់ទាំងអស់អាចបង្អាក់បំណងប្រាថ្នាដើម្បីយល់ពីតក្កវិជ្ជានៃរបៀបដែលគោលការណ៍បណ្តាញដំណើរការ។ ទោះជាយ៉ាងណាក៏ដោយ យើងនឹងនៅតែព្យាយាមស្វែងយល់ពីគោលការណ៍ជាមូលដ្ឋាន និងវិធីសាស្រ្តនៃដំណើរការលំហូរចរាចរណ៍ដោយប្រើគោលការណ៍បណ្តាញ...

វាជាឡូជីខលដែលចរាចរណ៍មាន 2 ប្រភេទ: ចូលផត (ចូល) និងចេញពីវា (អ៊ីហ្គេស) ។

តាម​ពិត នយោបាយ​ត្រូវ​បាន​បែង​ចែក​ជា​២​ប្រភេទ​នេះ ដោយ​ផ្អែក​លើ​ទិសដៅ​នៃ​ចលនា។

គុណលក្ខណៈដែលត្រូវការបន្ទាប់គឺឧបករណ៍ជ្រើសរើស; អ្នកដែលច្បាប់អនុវត្ត។ នេះអាចជា pods (ឬក្រុមនៃ pods) ឬបរិស្ថាន (ឧ. ចន្លោះឈ្មោះ)។ ព័ត៌មានលម្អិតសំខាន់៖ ប្រភេទទាំងពីរនៃវត្ថុទាំងនេះត្រូវតែមានស្លាក (ស្លាក នៅក្នុងវាក្យស័ព្ទ Kubernetes) - ទាំងនេះគឺជាពាក្យដែលអ្នកនយោបាយធ្វើប្រតិបត្តិការជាមួយ។

បន្ថែមពីលើចំនួនកំណត់នៃអ្នកជ្រើសរើសដែលរួបរួមដោយប្រភេទនៃស្លាកមួយចំនួន វាអាចសរសេរច្បាប់ដូចជា "អនុញ្ញាត/បដិសេធអ្វីគ្រប់យ៉ាង/អ្នកគ្រប់គ្នា" នៅក្នុងការប្រែប្រួលផ្សេងៗគ្នា។ ចំពោះគោលបំណងនេះ សំណង់នៃទម្រង់ត្រូវបានប្រើប្រាស់៖

  podSelector: {}
  ingress: []
  policyTypes:
  - Ingress

— ក្នុងឧទាហរណ៍នេះ ផតទាំងអស់នៅក្នុងបរិស្ថានត្រូវបានរារាំងពីចរាចរណ៍ចូល។ អាកប្បកិរិយាផ្ទុយអាចសម្រេចបានជាមួយនឹងការសាងសង់ដូចខាងក្រោមៈ

  podSelector: {}
  ingress:
  - {}
  policyTypes:
  - Ingress

ដូចគ្នានេះដែរសម្រាប់ការចេញ:

  podSelector: {}
  policyTypes:
  - Egress

- ដើម្បីបិទវា។ ហើយនេះជាអ្វីដែលត្រូវរួមបញ្ចូល៖

  podSelector: {}
  egress:
  - {}
  policyTypes:
  - Egress

ត្រលប់ទៅជម្រើសនៃកម្មវិធីជំនួយ CNI សម្រាប់ចង្កោមវាគួរអោយកត់សំគាល់ មិនមែនគ្រប់កម្មវិធីជំនួយបណ្តាញគាំទ្រ NetworkPolicy ទេ។. ឧទាហរណ៍ Flannel ដែលបានរៀបរាប់រួចហើយ មិនដឹងពីរបៀបកំណត់គោលការណ៍បណ្តាញ វាត្រូវបាននិយាយដោយផ្ទាល់ នៅក្នុងឃ្លាំងផ្លូវការ។ ជម្រើសមួយក៏ត្រូវបានលើកឡើងនៅទីនោះផងដែរ - គម្រោងប្រភពបើកចំហ កាលីកូ។ដែលពង្រីកយ៉ាងសំខាន់នូវសំណុំស្តង់ដារនៃ Kubernetes APIs ទាក់ទងនឹងគោលការណ៍បណ្តាញ។

ស្គាល់ Calico: ទ្រឹស្តី

កម្មវិធីជំនួយ Calico អាចត្រូវបានប្រើនៅក្នុងការរួមបញ្ចូលជាមួយ Flannel (គម្រោងរង ប្រឡាយ) ឬដោយឯករាជ្យ គ្របដណ្តប់ទាំងការតភ្ជាប់បណ្តាញ និងសមត្ថភាពគ្រប់គ្រងភាពអាចរកបាន។

តើការប្រើប្រាស់ដំណោះស្រាយ "ប្រអប់" K8s និង API ដែលបានកំណត់ពី Calico ផ្តល់ឱកាសអ្វីខ្លះ?

នេះជាអ្វីដែលត្រូវបានបង្កើតឡើងនៅក្នុង NetworkPolicy៖

• អ្នកនយោបាយត្រូវបានកំណត់ដោយបរិស្ថាន។
• គោលការណ៍ត្រូវបានអនុវត្តចំពោះផតឃែរដែលសម្គាល់ដោយស្លាក។
• ច្បាប់អាចត្រូវបានអនុវត្តទៅ pods បរិស្ថាន ឬបណ្តាញរង។
• ច្បាប់អាចមានពិធីការ ឈ្មោះ ឬលក្ខណៈបច្ចេកទេសច្រកនិមិត្តសញ្ញា។

នេះជារបៀបដែល Calico ពង្រីកមុខងារទាំងនេះ៖

• គោលការណ៍អាចត្រូវបានអនុវត្តចំពោះវត្ថុណាមួយ៖ ផត កុងតឺន័រ ម៉ាស៊ីននិម្មិត ឬចំណុចប្រទាក់។
• ច្បាប់អាចមានសកម្មភាពជាក់លាក់មួយ (ការហាមឃាត់ ការអនុញ្ញាត ការកាប់ឈើ);
• គោលដៅ ឬប្រភពនៃច្បាប់អាចជាច្រក ជួរនៃច្រក ពិធីការ គុណលក្ខណៈ HTTP ឬ ICMP IP ឬបណ្តាញរង (ជំនាន់ទី 4 ឬទី 6) ឧបករណ៍ជ្រើសរើសណាមួយ (ថ្នាំង ម៉ាស៊ីន បរិស្ថាន) ។
• លើសពីនេះទៀត អ្នកអាចគ្រប់គ្រងការឆ្លងកាត់នៃចរាចរណ៍ដោយប្រើការកំណត់ DNAT និងគោលនយោបាយបញ្ជូនបន្តចរាចរណ៍។

ការប្តេជ្ញាចិត្តលើកដំបូងនៅលើ GitHub នៅក្នុងឃ្លាំង Calico មានកាលបរិច្ឆេទត្រឡប់ទៅខែកក្កដា ឆ្នាំ 2016 ហើយមួយឆ្នាំក្រោយមក គម្រោងនេះបានកាន់កាប់មុខតំណែងឈានមុខគេក្នុងការរៀបចំការតភ្ជាប់បណ្តាញ Kubernetes - នេះត្រូវបានបង្ហាញជាឧទាហរណ៍ដោយលទ្ធផលស្ទង់មតិ។ ដឹកនាំដោយ The New Stack:

ដំណោះស្រាយដែលបានគ្រប់គ្រងធំៗជាច្រើនជាមួយ K8s ដូចជា ក្រុមហ៊ុន Amazon EX, Azure AKS, Google GKE និងអ្នកផ្សេងទៀតបានចាប់ផ្តើមណែនាំវាសម្រាប់ការប្រើប្រាស់។

សម្រាប់ការសម្តែង អ្វីៗគឺអស្ចារ្យនៅទីនេះ។ ក្នុងការសាកល្បងផលិតផលរបស់ពួកគេ ក្រុមអភិវឌ្ឍន៍ Calico បានបង្ហាញពីដំណើរការតារាសាស្ត្រ ដោយដំណើរការជាង 50000 កុងតឺន័រលើថ្នាំង 500 ដែលមានអត្រាបង្កើត 20 ធុងក្នុងមួយវិនាទី។ មិនមានបញ្ហាត្រូវបានសម្គាល់ជាមួយការធ្វើមាត្រដ្ឋានទេ។ លទ្ធផលបែបនេះ ត្រូវបានប្រកាស រួចហើយនៅក្នុងការប្រកាសនៃកំណែដំបូង។ ការសិក្សាឯករាជ្យដែលផ្តោតលើការបញ្ជូន និងការប្រើប្រាស់ធនធានក៏បញ្ជាក់ផងដែរថា ដំណើរការរបស់ Calico គឺស្ទើរតែល្អដូច Flannel ដែរ។ ឧទាហរណ៍:

គម្រោងនេះកំពុងអភិវឌ្ឍយ៉ាងឆាប់រហ័ស វាគាំទ្រការងារនៅក្នុងដំណោះស្រាយដ៏ពេញនិយមដែលបានគ្រប់គ្រង K8s, OpenShift, OpenStack វាអាចប្រើ Calico នៅពេលដាក់ពង្រាយចង្កោមដោយប្រើ ទាត់មានឯកសារយោងទៅលើការសាងសង់បណ្តាញ Service Mesh (នេះគឺជាឧទាហរណ៍មួយ។ ប្រើជាមួយ Istio) ។

ហ្វឹកហាត់ជាមួយ Calico

ក្នុងករណីទូទៅនៃការប្រើប្រាស់វ៉ានីឡា Kubernetes ការដំឡើង CNI មកលើការប្រើប្រាស់ឯកសារ calico.yaml, ទាញយកពីគេហទំព័រផ្លូវការ, ដោយប្រើ kubectl apply -f.

តាមក្បួនមួយ កំណែបច្ចុប្បន្ននៃកម្មវិធីជំនួយគឺត្រូវគ្នាជាមួយកំណែ 2-3 ចុងក្រោយបំផុតរបស់ Kubernetes៖ ប្រតិបត្តិការនៅក្នុងកំណែចាស់មិនត្រូវបានសាកល្បង និងមិនត្រូវបានធានាទេ។ យោងតាមអ្នកអភិវឌ្ឍន៍ Calico ដំណើរការលើខឺណែលលីនុចលើសពី 3.10 ដែលដំណើរការ CentOS 7, Ubuntu 16 ឬ Debian 8 នៅលើកំពូល iptables ឬ IPVS ។

ភាពឯកោក្នុងបរិយាកាស

សម្រាប់ការយល់ដឹងទូទៅ សូមក្រឡេកមើលករណីសាមញ្ញមួយ ដើម្បីយល់ពីរបៀបដែលគោលការណ៍បណ្តាញនៅក្នុងសញ្ញាសម្គាល់ Calico ខុសពីស្តង់ដារ និងរបៀបដែលវិធីសាស្រ្តក្នុងការបង្កើតច្បាប់ធ្វើឱ្យភាពងាយស្រួលនៃការអាន និងភាពបត់បែននៃការកំណត់រចនាសម្ព័ន្ធរបស់ពួកគេ៖

មានកម្មវិធីបណ្តាញចំនួន 2 ដែលត្រូវបានដាក់ពង្រាយក្នុងចង្កោម៖ នៅក្នុង Node.js និង PHP ដែលមួយក្នុងចំណោមនោះប្រើ Redis ។ ដើម្បីទប់ស្កាត់ការចូលប្រើ Redis ពី PHP ខណៈពេលដែលរក្សាការភ្ជាប់ជាមួយ Node.js គ្រាន់តែអនុវត្តគោលការណ៍ខាងក្រោម៖

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-redis-nodejs
spec:
  podSelector:
    matchLabels:
      service: redis
  ingress:
  - from:
    - podSelector:
        matchLabels:
          service: nodejs
    ports:
    - protocol: TCP
      port: 6379

សំខាន់យើងអនុញ្ញាតឱ្យចរាចរចូលទៅកាន់ច្រក Redis ពី Node.js ។ ហើយ​គេ​ច្បាស់​ជា​មិន​បាន​ហាម​ឃាត់​អ្វី​ផ្សេង​ទៀត។ ដរាបណា NetworkPolicy លេចឡើង អ្នកជ្រើសរើសទាំងអស់ដែលបានរៀបរាប់នៅក្នុងវាចាប់ផ្តើមដាច់ដោយឡែក លើកលែងតែមានការបញ្ជាក់ផ្សេងពីនេះ។ ទោះជាយ៉ាងណាក៏ដោយ ច្បាប់ដាច់ដោយឡែកមិនអនុវត្តចំពោះវត្ថុផ្សេងទៀតដែលមិនត្រូវបានគ្របដណ្តប់ដោយឧបករណ៍ជ្រើសរើសទេ។

ឧទាហរណ៍ប្រើ apiVersion Kubernetes ចេញពីប្រអប់ ប៉ុន្តែគ្មានអ្វីរារាំងអ្នកពីការប្រើប្រាស់វាទេ។ ធនធាននៃឈ្មោះដូចគ្នាពីការចែកចាយ Calico. វាក្យសម្ព័ន្ធនៅទីនោះគឺលម្អិតបន្ថែមទៀត ដូច្នេះអ្នកនឹងត្រូវសរសេរច្បាប់ឡើងវិញសម្រាប់ករណីខាងលើក្នុងទម្រង់ខាងក្រោម៖

apiVersion: crd.projectcalico.org/v1
kind: NetworkPolicy
metadata:
  name: allow-redis-nodejs
spec:
  selector: service == 'redis'
  ingress:
  - action: Allow
    protocol: TCP
    source:
      selector: service == 'nodejs'
    destination:
      ports:
      - 6379

សំណង់ដែលបានរៀបរាប់ខាងលើសម្រាប់ការអនុញ្ញាត ឬបដិសេធចរាចរណ៍ទាំងអស់តាមរយៈ NetworkPolicy API ធម្មតាមានរចនាសម្ព័ន្ធជាមួយនឹងវង់ក្រចកដែលពិបាកយល់ និងចងចាំ។ ក្នុងករណី Calico ដើម្បីផ្លាស់ប្តូរតក្កវិជ្ជានៃច្បាប់ជញ្ជាំងភ្លើងទៅផ្ទុយគឺគ្រាន់តែផ្លាស់ប្តូរ action: Allow នៅលើ action: Deny.

ភាពឯកោដោយបរិស្ថាន

ឥឡូវនេះស្រមៃមើលស្ថានភាពដែលកម្មវិធីបង្កើតរង្វាស់អាជីវកម្មសម្រាប់ការប្រមូលផ្តុំនៅក្នុង Prometheus និងការវិភាគបន្ថែមដោយប្រើ Grafana ។ ការអាប់ឡូតអាចមានទិន្នន័យរសើប ដែលអាចមើលជាសាធារណៈម្តងទៀតតាមលំនាំដើម។ ចូរ​លាក់​ទិន្នន័យ​នេះ​ពី​ភ្នែក​មើល​ទៅ៖

តាមក្បួនមួយ Prometheus ត្រូវបានដាក់ក្នុងបរិយាកាសសេវាកម្មដាច់ដោយឡែក - ក្នុងឧទាហរណ៍វានឹងមានចន្លោះឈ្មោះដូចនេះ៖

apiVersion: v1
kind: Namespace
metadata:
  labels:
    module: prometheus
  name: kube-prometheus

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

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-metrics-prom
spec:
  podSelector: {}
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          module: prometheus
    ports:
    - protocol: TCP
      port: 9100

ហើយប្រសិនបើអ្នកប្រើគោលការណ៍ Calico វាក្យសម្ព័ន្ធនឹងដូចនេះ៖

apiVersion: crd.projectcalico.org/v1
kind: NetworkPolicy
metadata:
  name: allow-metrics-prom
spec:
  ingress:
  - action: Allow
    protocol: TCP
    source:
      namespaceSelector: module == 'prometheus'
    destination:
      ports:
      - 9100

ជាទូទៅ ដោយការបន្ថែមគោលនយោបាយប្រភេទទាំងនេះសម្រាប់តម្រូវការជាក់លាក់ អ្នកអាចការពារប្រឆាំងនឹងការជ្រៀតជ្រែកដែលមានគំនិតអាក្រក់ ឬការជ្រៀតជ្រែកដោយចៃដន្យនៅក្នុងប្រតិបត្តិការនៃកម្មវិធីនៅក្នុងចង្កោម។

ការអនុវត្តល្អបំផុត យោងទៅតាមអ្នកបង្កើត Calico គឺវិធីសាស្រ្ត "ទប់ស្កាត់អ្វីៗគ្រប់យ៉ាង ហើយបើកយ៉ាងច្បាស់លាស់នូវអ្វីដែលអ្នកត្រូវការ" ដែលចងក្រងជាឯកសារនៅក្នុង ឯកសារផ្លូវការ (អ្នកផ្សេងទៀតអនុវត្តតាមវិធីសាស្រ្តស្រដៀងគ្នា - ជាពិសេសនៅក្នុង អត្ថបទដែលបានរៀបរាប់រួចហើយ).

ការប្រើប្រាស់វត្ថុ Calico បន្ថែម

ខ្ញុំសូមរំលឹកអ្នកថា តាមរយៈសំណុំបន្ថែមនៃ Calico APIs អ្នកអាចគ្រប់គ្រងភាពអាចរកបាននៃ nodes មិនកំណត់ចំពោះ pods នោះទេ។ ក្នុងឧទាហរណ៍ខាងក្រោមដោយប្រើ GlobalNetworkPolicy សមត្ថភាពក្នុងការឆ្លងកាត់សំណើ ICMP នៅក្នុងចង្កោមត្រូវបានបិទ (ឧទាហរណ៍ pings ពី pods ទៅ node រវាង pods ឬពី node ទៅ IP pod)៖

apiVersion: crd.projectcalico.org/v1
kind: GlobalNetworkPolicy
metadata:
  name: block-icmp
spec:
  order: 200
  selector: all()
  types:
  - Ingress
  - Egress
  ingress:
  - action: Deny
    protocol: ICMP
  egress:
  - action: Deny
    protocol: ICMP

ក្នុងករណីខាងលើ វានៅតែអាចធ្វើទៅបានសម្រាប់ថ្នាំងចង្កោមដើម្បី "ឈានដល់" គ្នាទៅវិញទៅមកតាមរយៈ ICMP ។ ហើយបញ្ហានេះត្រូវបានដោះស្រាយដោយមធ្យោបាយ GlobalNetworkPolicyអនុវត្តចំពោះអង្គភាព HostEndpoint:

apiVersion: crd.projectcalico.org/v1
kind: GlobalNetworkPolicy
metadata:
  name: deny-icmp-kube-02
spec:
  selector: "role == 'k8s-node'"
  order: 0
  ingress:
  - action: Allow
    protocol: ICMP
  egress:
  - action: Allow
    protocol: ICMP
---
apiVersion: crd.projectcalico.org/v1
kind: HostEndpoint
metadata:
  name: kube-02-eth0
  labels:
    role: k8s-node
spec:
  interfaceName: eth0
  node: kube-02
  expectedIPs: ["192.168.2.2"]

ករណី VPN

ជាចុងក្រោយ ខ្ញុំនឹងផ្តល់ឧទាហរណ៍ជាក់ស្តែងនៃការប្រើប្រាស់មុខងារ Calico សម្រាប់ករណីនៃអន្តរកម្មជិតចង្កោម នៅពេលដែលសំណុំគោលការណ៍ស្តង់ដារមិនគ្រប់គ្រាន់។ ដើម្បីចូលប្រើកម្មវិធីគេហទំព័រ អតិថិជនប្រើផ្លូវរូងក្រោមដី VPN ហើយការចូលប្រើនេះត្រូវបានគ្រប់គ្រងយ៉ាងតឹងរ៉ឹង និងកំណត់ចំពោះបញ្ជីជាក់លាក់នៃសេវាកម្មដែលត្រូវបានអនុញ្ញាតសម្រាប់ប្រើប្រាស់៖

អតិថិជនភ្ជាប់ទៅ VPN តាមរយៈច្រក UDP ស្តង់ដារ 1194 ហើយនៅពេលភ្ជាប់ ទទួលផ្លូវទៅកាន់បណ្តាញរងនៃផត និងសេវាកម្ម។ បណ្តាញរងទាំងមូលត្រូវបានរុញ ដើម្បីកុំឱ្យបាត់បង់សេវាកម្មកំឡុងពេលចាប់ផ្តើមឡើងវិញ និងការផ្លាស់ប្តូរអាសយដ្ឋាន។

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

ជាលទ្ធផលនៃការស្វែងរកតាមរយៈដំណោះស្រាយដែលអាចមាន ខាងក្រោមនេះត្រូវបានជ្រើសរើស៖

1. Pods ជាមួយ VPN ត្រូវបានកំណត់ពេលក្នុងមួយ node ក្នុង hostNetworkនោះគឺទៅ IP ពិតប្រាកដ។
2. សេវានេះត្រូវបានបង្ហោះនៅខាងក្រៅតាមរយៈ ClusterIP. ច្រកមួយត្រូវបានដំឡើងនៅលើថ្នាំងដែលអាចចូលបានពីខាងក្រៅជាមួយនឹងការកក់តិចតួច (វត្តមានតាមលក្ខខណ្ឌនៃអាសយដ្ឋាន IP ពិតប្រាកដ) ។
3. ការ​កំណត់​ថ្នាំង​ដែល​ផ្កា​រីក​ហួស​ពី​វិសាលភាព​នៃ​រឿង​របស់​យើង។ ខ្ញុំនឹងនិយាយថាអ្នកអាច "ភ្ជាប់" សេវាកម្មយ៉ាងតឹងរ៉ឹងទៅនឹងថ្នាំងឬសរសេរសេវាកម្មរថយន្តតូចមួយដែលនឹងត្រួតពិនិត្យអាសយដ្ឋាន IP បច្ចុប្បន្ននៃសេវាកម្ម VPN និងកែសម្រួលកំណត់ត្រា DNS ដែលបានចុះឈ្មោះជាមួយអតិថិជន - អ្នកដែលមានការស្រមើលស្រមៃគ្រប់គ្រាន់។

តាមទស្សនៈផ្លូវ យើងអាចកំណត់អត្តសញ្ញាណម៉ាស៊ីនភ្ញៀវ VPN ដោយអាសយដ្ឋាន IP របស់វាចេញដោយម៉ាស៊ីនមេ VPN ។ ខាងក្រោមនេះគឺជាឧទាហរណ៍ដំបូងនៃការដាក់កម្រិតការចូលប្រើប្រាស់សេវាកម្មរបស់អតិថិជនបែបនេះ ដែលបានបង្ហាញនៅលើ Redis ដែលបានរៀបរាប់ខាងលើ៖

apiVersion: crd.projectcalico.org/v1
kind: HostEndpoint
metadata:
  name: vpnclient-eth0
  labels:
    role: vpnclient
    environment: production
spec:
  interfaceName: "*"
  node: kube-02
  expectedIPs: ["172.176.176.2"]
---
apiVersion: crd.projectcalico.org/v1
kind: GlobalNetworkPolicy
metadata:
  name: vpn-rules
spec:
  selector: "role == 'vpnclient'"
  order: 0
  applyOnForward: true
  preDNAT: true
  ingress:
  - action: Deny
    protocol: TCP
    destination:
      ports: [6379]
  - action: Allow
    protocol: UDP
    destination:
      ports: [53, 67]

នៅទីនេះ ការភ្ជាប់ទៅកាន់ច្រក 6379 ត្រូវបានហាមឃាត់យ៉ាងតឹងរ៉ឹង ប៉ុន្តែនៅពេលជាមួយគ្នានោះ ប្រតិបត្តិការនៃសេវាកម្ម DNS ត្រូវបានរក្សា ដំណើរការដែលតែងតែទទួលរងនៅពេលបង្កើតច្បាប់។ ពីព្រោះ ដូចដែលបានរៀបរាប់ពីមុន នៅពេលអ្នកជ្រើសរើសមួយលេចឡើង គោលការណ៍បដិសេធលំនាំដើមត្រូវបានអនុវត្តចំពោះវា លើកលែងតែមានការបញ្ជាក់ផ្សេងទៀត។

លទ្ធផល

ដូច្នេះ ដោយប្រើ API កម្រិតខ្ពស់របស់ Calico អ្នកអាចកំណត់រចនាសម្ព័ន្ធដោយភាពបត់បែន និងផ្លាស់ប្តូរទិសដៅក្នុង និងជុំវិញចង្កោម។ ជាទូទៅ ការប្រើប្រាស់របស់វាមើលទៅដូចជាបាញ់ចាបដោយកាណុងបាញ់ ហើយការអនុវត្តបណ្តាញ L3 ជាមួយផ្លូវរូងក្រោមដី BGP និង IP-IP មើលទៅអស្ចារ្យក្នុងការដំឡើង Kubernetes សាមញ្ញនៅលើបណ្តាញរាបស្មើ... ទោះជាយ៉ាងណាក៏ដោយ ឧបករណ៍នេះមើលទៅអាចដំណើរការបាន និងមានប្រយោជន៍។ .

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

PS

សូមអានផងដែរនៅលើប្លក់របស់យើង៖

• «ការណែនាំអំពីគោលការណ៍បណ្តាញ Kubernetes សម្រាប់អ្នកជំនាញផ្នែកសុវត្ថិភាព»
• "មគ្គុទ្ទេសក៍គំនូរលើបណ្តាញនៅក្នុង Kubernetes"៖ ផ្នែកទី 1 និងទី 2 (គំរូបណ្តាញ បណ្តាញត្រួតលើគ្នា), ផ្នែកទី 3 (សេវាកម្ម និងដំណើរការចរាចរណ៍);
• «ចំណុចប្រទាក់បណ្តាញកុងតឺន័រ (CNI) - ចំណុចប្រទាក់បណ្តាញនិងស្តង់ដារសម្រាប់ធុងលីនុច"។

ប្រភព: www.habr.com