របៀបភ្ជាប់ចង្កោម Kubernetes នៅក្នុងមជ្ឈមណ្ឌលទិន្នន័យផ្សេងៗគ្នា

សូមស្វាគមន៍មកកាន់ស៊េរី Kubernetes Quick Start របស់យើង។ នេះគឺជាជួរឈរធម្មតាដែលមានសំណួរគួរឱ្យចាប់អារម្មណ៍បំផុតដែលយើងទទួលបានតាមអ៊ីនធឺណិត និងនៅក្នុងការបណ្តុះបណ្តាលរបស់យើង។ ចម្លើយអ្នកជំនាញ Kubernetes ។

អ្នកជំនាញថ្ងៃនេះគឺ Daniel Polenchik (Daniele Polencic) ដានីយ៉ែល ធ្វើការជាគ្រូបង្រៀន និងអ្នកបង្កើតកម្មវិធីនៅ Learnk8s.

ប្រសិនបើអ្នកចង់ឱ្យសំណួររបស់អ្នកឆ្លើយនៅក្នុងអត្ថបទបន្ទាប់, ទាក់ទងមកយើងតាមអ៊ីមែល ឬ Twitter៖ @learnk8s.

នឹក​ការ​បង្ហោះ​មុន​? ស្វែងរកពួកគេនៅទីនេះ.

តើធ្វើដូចម្តេចដើម្បីភ្ជាប់ចង្កោម Kubernetes នៅក្នុងមជ្ឈមណ្ឌលទិន្នន័យផ្សេងៗគ្នា?

សង្ខេប: Kubefed v2 នឹងមកដល់ឆាប់ៗនេះហើយខ្ញុំក៏សូមណែនាំឱ្យអានអំពី នាវាដឹកទំនិញ и គម្រោងកម្មវិធីកំណត់ពេលច្រើនក្រុម.

ជាញឹកញយ ហេដ្ឋារចនាសម្ព័ន្ធត្រូវបានចម្លង និងចែកចាយពាសពេញតំបន់ផ្សេងៗ ជាពិសេសនៅក្នុងបរិយាកាសដែលបានគ្រប់គ្រង។

ប្រសិនបើតំបន់មួយមិនអាចប្រើបានទេ ចរាចរណ៍ត្រូវបានបញ្ជូនបន្តទៅតំបន់មួយទៀត ដើម្បីជៀសវាងការរំខាន។

ជាមួយ Kubernetes អ្នកអាចប្រើយុទ្ធសាស្ត្រស្រដៀងគ្នា និងចែកចាយបន្ទុកការងារនៅទូទាំងតំបន់ផ្សេងៗគ្នា។

អ្នកអាចមានចង្កោមមួយ ឬច្រើនក្នុងមួយក្រុម តំបន់ បរិស្ថាន ឬការរួមបញ្ចូលគ្នានៃធាតុទាំងនេះ។

ចង្កោមរបស់អ្នកអាចត្រូវបានបង្ហោះនៅក្នុងពពកផ្សេងៗគ្នា និងនៅក្នុងបរិវេណ។

ប៉ុន្តែ​តើ​អ្នក​មាន​គម្រោង​ហេដ្ឋារចនាសម្ព័ន្ធ​សម្រាប់​ការ​រីក​រាលដាល​តាម​ភូមិសាស្ត្រ​បែប​ណា?
តើអ្នកត្រូវការបង្កើតចង្កោមធំមួយសម្រាប់បរិស្ថានពពកជាច្រើននៅលើបណ្តាញតែមួយទេ?
ឬមានចង្កោមតូចៗជាច្រើន ហើយរកវិធីដើម្បីគ្រប់គ្រង និងធ្វើសមកាលកម្មពួកវា?

ចង្កោមភាពជាអ្នកដឹកនាំមួយ។

ការបង្កើតចង្កោមមួយនៅលើបណ្តាញតែមួយគឺមិនងាយស្រួលនោះទេ។

ស្រមៃថាអ្នកមានឧបទ្ទវហេតុមួយ ការតភ្ជាប់រវាងផ្នែកចង្កោមត្រូវបានបាត់បង់។

ប្រសិនបើអ្នកមានម៉ាស៊ីនមេតែមួយ ធនធានពាក់កណ្តាលនឹងមិនអាចទទួលពាក្យបញ្ជាថ្មីបានទេ ព្រោះពួកគេនឹងមិនអាចទាក់ទងមេបានទេ។

ហើយក្នុងពេលតែមួយ អ្នកមានតារាងផ្លូវចាស់ (kube-proxy មិន​អាច​ទាញ​យក​ថ្មី​) និង​គ្មាន​ផត​បន្ថែម​ទៀត (kubelet មិន​អាច​ស្នើ​សុំ​ការ​ធ្វើ​ឱ្យ​ទាន់​សម័យ​) ។

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

ជាលទ្ធផលអ្នកមានផតថលច្រើនជាងពីរដង។

ប្រសិនបើអ្នកបង្កើតមេមេមួយសម្រាប់តំបន់នីមួយៗ វានឹងមានបញ្ហាជាមួយក្បួនដោះស្រាយការយល់ស្របនៅក្នុងមូលដ្ឋានទិន្នន័យ etcd ។ (ប្រហែល ed ។ - តាមពិត មូលដ្ឋានទិន្នន័យ etcd មិនចាំបាច់មានទីតាំងនៅលើម៉ាស៊ីនមេទេ។ វាអាចត្រូវបានដំណើរការនៅលើក្រុមដាច់ដោយឡែកនៃម៉ាស៊ីនមេនៅក្នុងតំបន់តែមួយ។ ពិត ក្នុងពេលជាមួយគ្នាទទួលបានចំណុចបរាជ័យនៃចង្កោម។ ប៉ុន្តែយ៉ាងឆាប់រហ័ស។)

ការប្រើប្រាស់ etcd ក្បួនដោះស្រាយក្បូនដើម្បីចរចាតម្លៃមុនពេលសរសេរវាទៅថាស។
នោះគឺ ភាគច្រើននៃករណីត្រូវតែឈានដល់ការឯកភាព មុនពេលរដ្ឋអាចត្រូវបានសរសេរទៅ ល។

ប្រសិនបើភាពយឺតយ៉ាវរវាងវត្ថុ etcd កើនឡើងយ៉ាងខ្លាំង ដូចជាករណី etd បីនៅក្នុងតំបន់ផ្សេងៗគ្នា វាត្រូវការពេលយូរដើម្បីចរចាតម្លៃ ហើយសរសេរវាទៅថាស។
នេះត្រូវបានឆ្លុះបញ្ចាំងនៅក្នុងឧបករណ៍បញ្ជា Kubernetes ។

អ្នកគ្រប់គ្រងឧបករណ៍បញ្ជាត្រូវការពេលវេលាបន្ថែមទៀតដើម្បីស្វែងយល់អំពីការផ្លាស់ប្តូរ និងសរសេរការឆ្លើយតបទៅកាន់មូលដ្ឋានទិន្នន័យ។

ហើយចាប់តាំងពីមិនមានឧបករណ៍បញ្ជាមួយ, ប៉ុន្តែជាច្រើន, លទ្ធផលនៃប្រតិកម្មសង្វាក់ ហើយចង្កោមទាំងមូលចាប់ផ្តើមដំណើរការយឺតណាស់។.

etcd គឺមានភាពរសើបខ្លាំងណាស់ ឯកសារផ្លូវការណែនាំអោយប្រើ SSDs ជំនួសឱ្យ hard drive ធម្មតា។.

បច្ចុប្បន្នមិនមានឧទាហរណ៍ល្អនៃបណ្តាញធំសម្រាប់ចង្កោមតែមួយទេ។

ជាទូទៅ សហគមន៍អ្នកអភិវឌ្ឍន៍ និងក្រុម SIG-cluster កំពុងព្យាយាមរកវិធីរៀបចំក្រុមតាមរបៀបដូចគ្នា Kubernetes រៀបចំកុងតឺន័រ។

ជម្រើសទី 1: សហព័ន្ធចង្កោមជាមួយ kubefed

ការឆ្លើយតបជាផ្លូវការពី SIG-cluster - kubefed2 ដែលជាកំណែថ្មីនៃអតិថិជន និងប្រតិបត្តិករសហព័ន្ធ kube ដើម.

ជាលើកដំបូង យើងបានព្យាយាមគ្រប់គ្រងបណ្តុំនៃចង្កោមជាវត្ថុតែមួយដោយប្រើឧបករណ៍សហព័ន្ធ kube ។

ការ​ចាប់​ផ្តើ​ម​គឺ​ជា​ការ​ល្អ​ប៉ុន្តែ​នៅ​ទី​បញ្ចប់​សហព័ន្ធ kube មិន​ដែល​មាន​ប្រជាប្រិយភាព​ដោយ​សារ​តែ​វា​មិន​បាន​គាំទ្រ​ធនធាន​ទាំង​អស់​។

ឧទាហរណ៍ វាគាំទ្រការចែកចាយ និងសេវាកម្មសហព័ន្ធ ប៉ុន្តែមិនមែនជា StatefulSets ទេ។
ផងដែរ ការកំណត់រចនាសម្ព័ន្ធសហព័ន្ធត្រូវបានបញ្ជូនតាមទម្រង់នៃចំណារពន្យល់ និងមិនអាចបត់បែនបាន។

ស្រមៃមើលពីរបៀបដែលអ្នកអាចពិពណ៌នាអំពីការបែងចែកចម្លងសម្រាប់ចង្កោមនីមួយៗនៅក្នុងសហព័ន្ធដោយគ្រាន់តែប្រើចំណារពន្យល់។

វាជាការរញ៉េរញ៉ៃពេញលេញ។

SIG-cluster បានធ្វើការងារជាច្រើនបន្ទាប់ពី kubefed v1 ហើយបានសម្រេចចិត្តដោះស្រាយបញ្ហាពីមុំផ្សេងគ្នា។

ជំនួសឱ្យការពន្យល់ ពួកគេបានសម្រេចចិត្តបញ្ចេញឧបករណ៍បញ្ជាដែលត្រូវបានដំឡើងនៅលើចង្កោម។ វាអាចត្រូវបានប្ដូរតាមបំណងដោយប្រើ Custom Resource Definitions (CRDs)។

សម្រាប់ធនធាននីមួយៗដែលនឹងក្លាយជាផ្នែកនៃសហព័ន្ធ អ្នកមាននិយមន័យ CRD ផ្ទាល់ខ្លួនដែលមានបីផ្នែក៖

• និយមន័យស្តង់ដារនៃធនធាន ឧទាហរណ៍ ការដាក់ពង្រាយ;
• ផ្នែក placementដែលអ្នកកំណត់ពីរបៀបដែលធនធាននឹងត្រូវបានចែកចាយនៅក្នុងសហព័ន្ធ។
• ផ្នែក overrideដែលជាកន្លែងដែលសម្រាប់ធនធានជាក់លាក់មួយ អ្នកអាចបដិសេធទម្ងន់ និងប៉ារ៉ាម៉ែត្រពីការដាក់។

នេះគឺជាឧទាហរណ៍នៃការចែកចាយរួមជាមួយនឹងផ្នែកដាក់ និងបដិសេធ

apiVersion: types.federation.k8s.io/v1alpha1
kind: FederatedDeployment
metadata:
  name: test-deployment
  namespace: test-namespace
spec:
  template:
    metadata:
      labels:
        app: nginx
    spec:
      replicas: 3
      selector:
        matchLabels:
          app: nginx
      template:
        metadata:
          labels:
            app: nginx
        spec:
          containers:
            - image: nginx
              name: nginx
  placement:
    clusterNames:
      - cluster2
      - cluster1
  overrides:
    - clusterName: cluster2
      clusterOverrides:
        - path: spec.replicas
          value: 5

ដូចដែលអ្នកអាចឃើញការផ្គត់ផ្គង់ត្រូវបានចែកចាយនៅទូទាំងចង្កោមពីរ: cluster1 и cluster2.

ចង្កោមទីមួយផ្គត់ផ្គង់ការចម្លងចំនួន 5 ហើយទីពីរត្រូវបានកំណត់ទៅ XNUMX ។

ប្រសិនបើអ្នកត្រូវការការគ្រប់គ្រងបន្ថែមលើចំនួននៃការចម្លងនោះ kubefed2 ផ្តល់នូវវត្ថុ ReplicaSchedulingPreference ថ្មី ដែលការចម្លងអាចត្រូវបានថ្លឹងថ្លែង៖

apiVersion: scheduling.federation.k8s.io/v1alpha1
kind: ReplicaSchedulingPreference
metadata:
  name: test-deployment
  namespace: test-ns
spec:
  targetKind: FederatedDeployment
  totalReplicas: 9
  clusters:
    A:
      weight: 1
    B:
      weight: 2

រចនាសម្ព័ន្ធ CRD និង API មិនទាន់រួចរាល់នៅឡើយទេ ហើយការងារសកម្មកំពុងដំណើរការនៅក្នុងឃ្លាំងគម្រោងផ្លូវការ។

តាមដាន kubefed2 ប៉ុន្តែត្រូវចាំថាវាមិនទាន់សាកសមសម្រាប់ផលិតនៅឡើយ។

មើល​បន្ថែមទៀត​អំពី kubefed2 from អត្ថបទផ្លូវការអំពី kubefed2 នៅក្នុងប្លក់អំពី Kubernetes និងក្នុង ឃ្លាំងផ្លូវការនៃគម្រោង kubefed.

ជម្រើសទី 2៖ ការរួមបញ្ចូលចង្កោមនៅក្នុងរចនាប័ទ្ម Booking.com

អ្នកអភិវឌ្ឍន៍ Booking.com មិនដំណើរការលើ kubefed v2 ទេ ប៉ុន្តែពួកគេបានបង្កើត Shipper ដែលជាប្រតិបត្តិករសម្រាប់ចែកចាយនៅលើចង្កោមជាច្រើន ក្នុងតំបន់ និងក្នុងពពកជាច្រើន។

នាវាដឹកទំនិញ ស្រដៀងទៅនឹង kubefed2.

ឧបករណ៍ទាំងពីរអនុញ្ញាតឱ្យអ្នកប្ដូរតាមបំណងនូវយុទ្ធសាស្ត្រដាក់ពង្រាយច្រើនចង្កោមរបស់អ្នក (ចង្កោមមួយណាត្រូវបានប្រើប្រាស់ និងចំនួនចម្លងដែលពួកគេមាន)។

ប៉ុន្តែ គោលដៅរបស់អ្នកដឹកជញ្ជូនគឺដើម្បីកាត់បន្ថយហានិភ័យនៃកំហុសក្នុងអំឡុងពេលដឹកជញ្ជូន។

នៅក្នុង Shipper អ្នកអាចកំណត់ស៊េរីនៃជំហានដែលពិពណ៌នាអំពីការបែងចែកនៃការចម្លងរវាងការដាក់ពង្រាយពីមុន និងបច្ចុប្បន្ន និងបរិមាណនៃចរាចរចូល។

នៅពេលអ្នករុញធនធានទៅចង្កោម នោះឧបករណ៍បញ្ជាអ្នកដឹកជញ្ជូននឹងបង្កើនការផ្លាស់ប្តូរដែលឆ្លងកាត់គ្រប់ចង្កោមដែលបានចូលរួម។

ដូចគ្នានេះផងដែរ Shipper មានកំណត់ណាស់។

ឧទាហរណ៍ វាទទួលយកតារាងមួកសុវត្ថិភាពជាការបញ្ចូល និងមិនគាំទ្រធនធានវ៉ានីឡា។
ជាទូទៅ Shipper ធ្វើការដូចនេះ។

ជំនួសឱ្យការចែកចាយស្តង់ដារ អ្នកត្រូវបង្កើតធនធានកម្មវិធីដែលរួមបញ្ចូលតារាង Helm៖

apiVersion: shipper.booking.com/v1alpha1
kind: Application
metadata:
  name: super-server
spec:
  revisionHistoryLimit: 3
  template:
    chart:
      name: nginx
      repoUrl: https://storage.googleapis.com/shipper-demo
      version: 0.0.1
    clusterRequirements:
      regions:
        - name: local
    strategy:
      steps:
        - capacity:
            contender: 1
            incumbent: 100
          name: staging
          traffic:
            contender: 0
            incumbent: 100
        - capacity:
            contender: 100
            incumbent: 0
          name: full on
          traffic:
            contender: 100
            incumbent: 0
    values:
      replicaCount: 3

Shipper គឺជាជម្រើសដ៏ល្អសម្រាប់ការគ្រប់គ្រងចង្កោមជាច្រើន ប៉ុន្តែទំនាក់ទំនងជិតស្និទ្ធរបស់វាជាមួយ Helm ទទួលបានតែនៅក្នុងផ្លូវប៉ុណ្ណោះ។

ចុះបើយើងទាំងអស់គ្នាប្តូរពី Helm ទៅ ប្ដូរតាមបំណង ឬ ប្រធានក្រុម?

មើល​បន្ថែមទៀត​អំពី Shipper and its philosophy at សេចក្តីប្រកាសព័ត៌មានផ្លូវការនេះ។.

ប្រសិនបើអ្នកចង់ជីកចូលទៅក្នុងកូដ, ទៅកាន់ឃ្លាំងគម្រោងផ្លូវការ.

ជម្រើសទី 3៖ ការរួមបញ្ចូលគ្នានៃចង្កោម "វេទមន្ត"

Kubefed v2 និងអ្នកដឹកជញ្ជូនធ្វើការជាមួយសហព័ន្ធចង្កោម ដោយផ្តល់ធនធានថ្មីដល់ក្រុមតាមរយៈការកំណត់ធនធានផ្ទាល់ខ្លួន។

ប៉ុន្តែចុះយ៉ាងណាបើអ្នកមិនចង់សរសេរឡើងវិញនូវការចែកចាយទាំងអស់ StatefulSets, DaemonSets ជាដើម ដើម្បីបញ្ចូលគ្នា?

តើធ្វើដូចម្តេចដើម្បីរួមបញ្ចូលចង្កោមដែលមានស្រាប់នៅក្នុងសហព័ន្ធដោយមិនផ្លាស់ប្តូរ YAML?

multi-cluster-scheduler គឺជាគម្រោង Admiralityដែលទាក់ទងនឹងការកំណត់កាលវិភាគការងារនៅលើចង្កោម។

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

ផតដែលបានបង្កើតនីមួយៗត្រូវបានជំនួសភ្លាមៗដោយអត់ចេះសោះ។

ការប្រើប្រាស់កម្មវិធីកំណត់ពេលច្រើនក្រុម webhooks សម្រាប់ការកែប្រែការចូលប្រើដើម្បី​ស្ទាក់​ចាប់​ការ​ហៅ​ទូរសព្ទ និង​បង្កើត​ផត​អត់​ចេះ​ទំនេរ។

ផតថលដើមឆ្លងកាត់វដ្តនៃផែនការមួយផ្សេងទៀត ដែលបន្ទាប់ពីការស្ទង់មតិសហព័ន្ធទាំងមូល ការសម្រេចចិត្តដាក់ត្រូវបានធ្វើឡើង។

ជាចុងក្រោយ ផតត្រូវបានបញ្ជូនទៅចង្កោមគោលដៅ។

ជាលទ្ធផល អ្នកមានផតបន្ថែមដែលមិនធ្វើអ្វីសោះ គ្រាន់តែយកកន្លែងទំនេរ។

អត្ថប្រយោជន៍គឺថាអ្នកមិនចាំបាច់សរសេរធនធានថ្មីដើម្បីបញ្ចូលគ្នានូវការផ្គត់ផ្គង់នោះទេ។

ធនធាននីមួយៗដែលបង្កើតផតគឺត្រៀមខ្លួនជាស្រេចដោយស្វ័យប្រវត្តិក្នុងការបញ្ចូលគ្នា។

នេះ​ជា​ការ​ចាប់​អារម្មណ៍ ព្រោះ​ភ្លាមៗ​នោះ​អ្នក​មាន​គ្រឿង​ផ្គត់ផ្គង់​ចែកចាយ​ទូទាំង​តំបន់​ជា​ច្រើន ហើយ​អ្នក​មិន​បាន​កត់​សម្គាល់​ផង។ ទោះយ៉ាងណាក៏ដោយ នេះគឺពិតជាប្រថុយប្រថានណាស់ ព្រោះអ្វីៗនៅទីនេះពឹងផ្អែកលើវេទមន្ត។

ប៉ុន្តែខណៈពេលដែលអ្នកដឹកជញ្ជូនកំពុងព្យាយាមកាត់បន្ថយផលប៉ះពាល់នៃការចែកចាយភាគច្រើន អ្នកកំណត់ពេលច្រើនក្រុមគ្រប់គ្រងការងារទូទៅបន្ថែមទៀត ហើយប្រហែលជាសមជាងសម្រាប់ការងារជាបាច់។

វាមិនមានយន្តការបញ្ជូនបន្តបន្ទាប់កម្រិតខ្ពស់ទេ។

ព័ត៌មានបន្ថែមអំពី multi-cluster-scheduler អាចរកបាននៅ ទំព័រឃ្លាំងផ្លូវការ.

ប្រសិនបើអ្នកចង់អានអំពី multi-cluster-scheduler នៅក្នុងសកម្មភាព Admiralty មាន ករណីប្រើប្រាស់គួរឱ្យចាប់អារម្មណ៍ជាមួយ Argo - លំហូរការងារ ព្រឹត្តិការណ៍ CI និង CD Kubernetes ។

ឧបករណ៍ និងដំណោះស្រាយផ្សេងៗ

ការភ្ជាប់ និងគ្រប់គ្រងចង្កោមច្រើនគឺជាកិច្ចការដ៏ស្មុគស្មាញ ហើយមិនមានដំណោះស្រាយជាសកលទេ។

ប្រសិនបើអ្នកចង់ស្វែងយល់អំពីប្រធានបទនេះបន្ថែមទៀត ខាងក្រោមនេះជាធនធានមួយចំនួន៖

• នាវាមុជទឹកដោយ Rancher គឺជាឧបករណ៍ដែលភ្ជាប់បណ្តាញត្រួតលើគ្នានៃចង្កោម Kubernetes ផ្សេងៗគ្នា។
• ខ្សែសង្វាក់លក់រាយគោលដៅប្រើប្រាស់ Unimatrix រួមបញ្ចូលគ្នាជាមួយ Spinnaker ដើម្បីរៀបចំការដាក់ពង្រាយនៅទូទាំងចង្កោមជាច្រើន។.
• សាកល្បងប្រើ IPV6 និង បណ្តាញតែមួយនៅក្នុងតំបន់ជាច្រើន។.
• ឧទាហរណ៍អ្នកអាចប្រើសំណាញ់សេវាកម្ម Istio សម្រាប់ភ្ជាប់ចង្កោមច្រើន។.
• Cilium ដែលជាកម្មវិធីជំនួយចំណុចប្រទាក់បណ្តាញកុងតឺន័រ ផ្តល់ជូន មុខងារសំណាញ់ចង្កោមដែលអនុញ្ញាតឱ្យអ្នកបញ្ចូលគ្នានូវចង្កោមជាច្រើន។

នោះហើយជាទាំងអស់សម្រាប់ថ្ងៃនេះ

អរគុណសម្រាប់ការអានដល់ចប់!

ប្រសិនបើអ្នកដឹងពីរបៀបភ្ជាប់ចង្កោមច្រើនឱ្យកាន់តែមានប្រសិទ្ធភាព។ ប្រាប់​ពូក​យើង​មក.

យើងនឹងបន្ថែមវិធីសាស្ត្ររបស់អ្នកទៅតំណភ្ជាប់។

សូមអរគុណជាពិសេសដល់ Chris Nesbitt-Smith (Chris Nesbitt-Smith) និង Vincent de Sme (លោក Vincent De Smet) (វិស្វករភាពជឿជាក់នៅក្នុង swatmobile.io) សម្រាប់ការអានអត្ថបទ និងចែករំលែកព័ត៌មានមានប្រយោជន៍អំពីរបៀបដែលសហព័ន្ធដំណើរការ។

ប្រភព: www.habr.com