ទៅ? បាស! ជួបជាមួយប្រតិបត្តិករសែល (ការពិនិត្យឡើងវិញ និងរបាយការណ៍វីដេអូពី KubeCon EU'2020)

នៅឆ្នាំនេះ សន្និសីទ Kubernetes អឺរ៉ុបដ៏សំខាន់ - KubeCon + CloudNativeCon Europe 2020 - គឺជានិម្មិត។ ទោះជាយ៉ាងណាក៏ដោយ ការផ្លាស់ប្តូរទម្រង់បែបនេះមិនបានរារាំងយើងពីការផ្តល់នូវរបាយការណ៍ដែលបានគ្រោងទុកយូររបស់យើង “ទៅ? បាស! ជួបជាមួយ Shell-operator” ឧទ្ទិសដល់គម្រោង Open Source របស់យើង។ ប្រតិបត្តិករសែល.

អត្ថបទនេះដែលត្រូវបានបំផុសគំនិតដោយការពិភាក្សា បង្ហាញពីវិធីសាស្រ្តក្នុងការសម្រួលដល់ដំណើរការនៃការបង្កើតប្រតិបត្តិករសម្រាប់ Kubernetes និងបង្ហាញពីរបៀបដែលអ្នកអាចបង្កើតដោយខ្លួនឯងដោយការខិតខំប្រឹងប្រែងតិចតួចបំផុតដោយប្រើ shell-operator ។

ការណែនាំ វីដេអូនៃរបាយការណ៍ (~23 នាទីជាភាសាអង់គ្លេស គួរឲ្យកត់សំគាល់ជាងអត្ថបទ) និងការដកស្រង់សំខាន់ពីវាក្នុងទម្រង់ជាអត្ថបទ។ ទៅ!

នៅ Flant យើងតែងតែបង្កើនប្រសិទ្ធភាព និងធ្វើអ្វីៗគ្រប់យ៉ាងដោយស្វ័យប្រវត្តិ។ ថ្ងៃនេះយើងនឹងនិយាយអំពីគំនិតដ៏គួរឱ្យរំភើបមួយទៀត។ ជួប៖ ការសរសេរស្គ្រីបសែលដើមកំណើតពពក!

ទោះយ៉ាងណាក៏ដោយ ចូរចាប់ផ្តើមជាមួយនឹងបរិបទដែលអ្វីៗទាំងអស់នេះកើតឡើង៖ Kubernetes។

Kubernetes API និងឧបករណ៍បញ្ជា

API នៅក្នុង Kubernetes អាចត្រូវបានតំណាងជាប្រភេទម៉ាស៊ីនមេឯកសារដែលមានថតសម្រាប់ប្រភេទវត្ថុនីមួយៗ។ វត្ថុ (ធនធាន) នៅលើម៉ាស៊ីនមេនេះត្រូវបានតំណាងដោយឯកសារ YAML ។ លើសពីនេះទៀតម៉ាស៊ីនមេមាន API មូលដ្ឋានដែលអនុញ្ញាតឱ្យអ្នកធ្វើរឿងបីយ៉ាង៖

• ទទួលបាន ធនធានតាមប្រភេទនិងឈ្មោះរបស់វា;
• ផ្លាស់ប្តូរ ធនធាន (ក្នុងករណីនេះម៉ាស៊ីនមេរក្សាទុកតែវត្ថុ "ត្រឹមត្រូវ" - ទាំងអស់ដែលបានបង្កើតឡើងមិនត្រឹមត្រូវឬមានបំណងសម្រាប់ថតផ្សេងទៀតត្រូវបានលុបចោល);
• បទ សម្រាប់ធនធាន (ក្នុងករណីនេះអ្នកប្រើភ្លាមៗទទួលបានកំណែបច្ចុប្បន្ន / អាប់ដេតរបស់វា) ។

ដូច្នេះ Kubernetes ដើរតួជាប្រភេទនៃម៉ាស៊ីនមេឯកសារ (សម្រាប់ YAML manifests) ជាមួយនឹងវិធីសាស្រ្តមូលដ្ឋានចំនួនបី (បាទ តាមពិតមានផ្សេងទៀត ប៉ុន្តែយើងនឹងលុបវាចោលសម្រាប់ពេលនេះ)។

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

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

សូមក្រឡេកមើលឱ្យកាន់តែច្បាស់អំពីដំណើរការនៃការបង្កើតការដាក់ឱ្យប្រើប្រាស់នៅក្នុង Kubernetes៖

• ឧបករណ៍ត្រួតពិនិត្យការដាក់ពង្រាយ (រួមបញ្ចូលក្នុង kube-controller-manager) ទទួលព័ត៌មានអំពីការដាក់ឱ្យប្រើប្រាស់ និងបង្កើតសំណុំចម្លង។
• ReplicaSet បង្កើតការចម្លងពីរ (ផតថលពីរ) ដោយផ្អែកលើព័ត៌មាននេះ ប៉ុន្តែផតទាំងនេះមិនទាន់ត្រូវបានកំណត់ពេលនៅឡើយទេ។
• កម្មវិធីកំណត់ពេលកំណត់ពេល pods និងបន្ថែមព័ត៌មាន node ទៅ YAMLs របស់ពួកគេ។
• Kubelets ធ្វើការផ្លាស់ប្តូរធនធានខាងក្រៅ (និយាយថា Docker) ។

បន្ទាប់មកលំដាប់ទាំងមូលនេះត្រូវបានធ្វើម្តងទៀតនៅក្នុងលំដាប់បញ្ច្រាស: kubelet ពិនិត្យធុង, គណនាស្ថានភាពរបស់ pod និងបញ្ជូនវាត្រឡប់មកវិញ។ ឧបករណ៍បញ្ជា ReplicaSet ទទួលបានស្ថានភាព និងធ្វើបច្ចុប្បន្នភាពស្ថានភាពនៃសំណុំចម្លង។ រឿងដដែលនេះកើតឡើងជាមួយ Deployment Controller ហើយទីបំផុតអ្នកប្រើប្រាស់ទទួលបានស្ថានភាពអាប់ដេត (បច្ចុប្បន្ន)។

ប្រតិបត្តិករសែល

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

ឧទាហរណ៍សាមញ្ញ៖ ការចម្លងអាថ៌កំបាំង

សូមក្រឡេកមើលឧទាហរណ៍ដ៏សាមញ្ញមួយ។

ឧបមាថាយើងមានចង្កោម Kubernetes ។ វាមានចន្លោះឈ្មោះ default ជាមួយនឹងអាថ៌កំបាំងមួយចំនួន mysecret. លើសពីនេះ មាន​ចន្លោះ​ឈ្មោះ​ផ្សេងទៀត​នៅក្នុង​ចង្កោម។ ពួកគេខ្លះមានស្លាកជាក់លាក់មួយភ្ជាប់ជាមួយពួកគេ។ គោលដៅរបស់យើងគឺចម្លង Secret ទៅក្នុង namespaces ជាមួយនឹងស្លាកមួយ។

កិច្ចការមានភាពស្មុគស្មាញដោយការពិតដែលថា ចន្លោះឈ្មោះថ្មីអាចលេចឡើងក្នុងចង្កោម ហើយពួកវាខ្លះអាចមានស្លាកនេះ។ ម៉្យាងវិញទៀតនៅពេលដែលស្លាកត្រូវបានលុប Secret ក៏គួរតែត្រូវបានលុបផងដែរ។ បន្ថែមពីលើនេះ អាថ៌កំបាំងខ្លួនឯងក៏អាចផ្លាស់ប្តូរផងដែរ៖ ក្នុងករណីនេះ សម្ងាត់ថ្មីត្រូវតែចម្លងទៅកន្លែងដាក់ឈ្មោះទាំងអស់ដែលមានស្លាក។ ប្រសិនបើការសម្ងាត់ត្រូវបានលុបដោយចៃដន្យនៅក្នុង namespace ណាមួយ ប្រតិបត្តិកររបស់យើងគួរតែស្ដារវាឡើងវិញភ្លាមៗ។

ឥឡូវ​នេះ​ដែល​កិច្ចការ​ត្រូវ​បាន​បង្កើត វា​ជា​ពេល​វេលា​ដើម្បី​ចាប់​ផ្តើម​អនុវត្ត​វា​ដោយ​ប្រើ shell-operator។ ប៉ុន្តែជាដំបូងវាមានតម្លៃនិយាយពាក្យពីរបីអំពីសែល - ប្រតិបត្តិករខ្លួនឯង។

របៀបដែលសែល-ប្រតិបត្តិករដំណើរការ

ដូចជាបន្ទុកការងារផ្សេងទៀតនៅក្នុង Kubernetes ប្រតិបត្តិករសែលដំណើរការនៅក្នុងផតផ្ទាល់របស់វា។ នៅក្នុងផតនេះនៅក្នុងថត /hooks ឯកសារដែលអាចប្រតិបត្តិបានត្រូវបានរក្សាទុក។ ទាំងនេះអាចជាស្គ្រីបនៅក្នុង Bash, Python, Ruby ជាដើម។ យើងហៅឯកសារដែលអាចប្រតិបត្តិបានបែបនេះថា ទំពក់ (ទំពក់).

Shell-operator ជាវព្រឹត្តិការណ៍ Kubernetes ហើយដំណើរការទំពក់ទាំងនេះដើម្បីឆ្លើយតបទៅនឹងព្រឹត្តិការណ៍ទាំងនោះដែលយើងត្រូវការ។

តើ shell-operator ដឹងដោយរបៀបណាថាទំពក់មួយណាត្រូវដំណើរការ និងនៅពេលណា? ចំណុចគឺថារាល់ទំពក់មានពីរដំណាក់កាល។ កំឡុងពេលចាប់ផ្តើម ប្រតិបត្តិករសែលដំណើរការទំពក់ទាំងអស់ជាមួយនឹងអាគុយម៉ង់មួយ។ --config នេះគឺជាដំណាក់កាលនៃការកំណត់។ ហើយបន្ទាប់ពីវាទំពក់ត្រូវបានដាក់ឱ្យដំណើរការតាមរបៀបធម្មតា - ដើម្បីឆ្លើយតបទៅនឹងព្រឹត្តិការណ៍ដែលពួកគេត្រូវបានភ្ជាប់។ ក្នុងករណីចុងក្រោយ ទំពក់ទទួលបានបរិបទចង (បរិបទចង) - ទិន្នន័យក្នុងទម្រង់ JSON ដែលយើងនឹងនិយាយអំពីព័ត៌មានលម្អិតខាងក្រោម។

បង្កើតប្រតិបត្តិករនៅក្នុង Bash

ឥឡូវនេះយើងត្រៀមរួចរាល់សម្រាប់ការអនុវត្ត។ ដើម្បីធ្វើដូចនេះយើងត្រូវសរសេរមុខងារពីរ (ដោយវិធីនេះយើងណែនាំ បណ្ណាល័យ shell_libដែលជួយសម្រួលការសរសេរទំពក់ក្នុង Bash យ៉ាងខ្លាំង)៖

• ទីមួយគឺចាំបាច់សម្រាប់ដំណាក់កាលកំណត់រចនាសម្ព័ន្ធ - វាបង្ហាញបរិបទចង។
• ទីពីរមានតក្កវិជ្ជាសំខាន់នៃទំពក់។

#!/bin/bash

source /shell_lib.sh

function __config__() {
  cat << EOF
    configVersion: v1
    # BINDING CONFIGURATION
EOF
}

function __main__() {
  # THE LOGIC
}

hook::run "$@"

ជំហានបន្ទាប់គឺត្រូវសម្រេចចិត្តថាតើយើងត្រូវការវត្ថុអ្វី។ ក្នុងករណីរបស់យើង យើងត្រូវតាមដាន៖

• ប្រភពសម្ងាត់សម្រាប់ការផ្លាស់ប្តូរ;
• ចន្លោះ​ឈ្មោះ​ទាំងអស់​ក្នុង​ចង្កោម ដូច្នេះ​អ្នក​ដឹង​ថា​មួយ​ណា​មាន​ស្លាក​ភ្ជាប់​ជាមួយ​ពួកវា។
• កំណត់គោលដៅសម្ងាត់ ដើម្បីធានាថាពួកវាទាំងអស់ត្រូវគ្នាជាមួយអាថ៌កំបាំងប្រភព។

ជាវប្រភពសម្ងាត់

ការកំណត់រចនាសម្ព័ន្ធចងសម្រាប់វាគឺសាមញ្ញណាស់។ យើងបង្ហាញថាយើងចាប់អារម្មណ៍លើ Secret ជាមួយនឹងឈ្មោះ mysecret នៅក្នុង namespace default:

function __config__() {
  cat << EOF
    configVersion: v1
    kubernetes:
    - name: src_secret
      apiVersion: v1
      kind: Secret
      nameSelector:
        matchNames:
        - mysecret
      namespace:
        nameSelector:
          matchNames: ["default"]
      group: main
EOF

ជាលទ្ធផល ទំពក់នឹងត្រូវបានកេះនៅពេលដែលការសម្ងាត់ប្រភពផ្លាស់ប្តូរ (src_secret) និងទទួលបានបរិបទចងខាងក្រោម៖

ដូចដែលអ្នកអាចឃើញវាមានឈ្មោះនិងវត្ថុទាំងមូល។

ការរក្សាដាននៃចន្លោះឈ្មោះ

ឥឡូវ​នេះ អ្នក​ត្រូវ​ជាវ​កន្លែង​ដាក់​ឈ្មោះ។ ដើម្បីធ្វើដូច្នេះ យើងបញ្ជាក់ការកំណត់រចនាសម្ព័ន្ធចងខាងក្រោម៖

- name: namespaces
  group: main
  apiVersion: v1
  kind: Namespace
  jqFilter: |
    {
      namespace: .metadata.name,
      hasLabel: (
       .metadata.labels // {} |  
         contains({"secret": "yes"})
      )
    }
  group: main
  keepFullObjectsInMemory: false

ដូចដែលអ្នកអាចឃើញ វាលថ្មីមួយបានលេចឡើងក្នុងការកំណត់រចនាសម្ព័ន្ធជាមួយឈ្មោះ jqFilter ។ ដូចដែលឈ្មោះរបស់វាបានបង្ហាញ។ jqFilter ច្រោះព័ត៌មានដែលមិនចាំបាច់ទាំងអស់ និងបង្កើតវត្ថុ JSON ថ្មីជាមួយនឹងវាលដែលយើងចាប់អារម្មណ៍។ ទំពក់​ដែល​មាន​ការ​កំណត់​រចនាសម្ព័ន្ធ​ស្រដៀង​គ្នា​នឹង​ទទួល​បាន​បរិបទ​ចង​ដូច​ខាង​ក្រោម៖

វាមានអារេ filterResults សម្រាប់​ចន្លោះ​ឈ្មោះ​នីមួយៗ​ក្នុង​ចង្កោម។ អថេរប៊ូលីន hasLabel បង្ហាញថាតើស្លាកមួយត្រូវបានភ្ជាប់ទៅកន្លែងដាក់ឈ្មោះដែលបានផ្តល់ឱ្យឬអត់។ អ្នកជ្រើសរើស keepFullObjectsInMemory: false បង្ហាញថាមិនចាំបាច់រក្សាវត្ថុពេញលេញនៅក្នុងសតិទេ។

តាមដានអាថ៌កំបាំងគោលដៅ

យើងជាវប្រចាំទៅអាថ៌កំបាំងទាំងអស់ដែលមានចំណារពន្យល់បញ្ជាក់ managed-secret: "yes" (ទាំងនេះគឺជាគោលដៅរបស់យើង។ dst_secrets):

- name: dst_secrets
  apiVersion: v1
  kind: Secret
  labelSelector:
    matchLabels:
      managed-secret: "yes"
  jqFilter: |
    {
      "namespace":
        .metadata.namespace,
      "resourceVersion":
        .metadata.annotations.resourceVersion
    }
  group: main
  keepFullObjectsInMemory: false

នៅក្នុងករណីនេះ jqFilter ត្រងព័ត៌មានទាំងអស់ លើកលែងតែ namespace និងប៉ារ៉ាម៉ែត្រ resourceVersion. ប៉ារ៉ាម៉ែត្រចុងក្រោយត្រូវបានបញ្ជូនទៅចំណារពន្យល់នៅពេលបង្កើតអាថ៌កំបាំង៖ វាអនុញ្ញាតឱ្យអ្នកប្រៀបធៀបកំណែនៃអាថ៌កំបាំង និងរក្សាវាឱ្យទាន់សម័យ។

ទំពក់​ដែល​បាន​កំណត់​រចនាសម្ព័ន្ធ​តាម​វិធី​នេះ​នឹង​ទទួល​បាន​បរិបទ​ចង​ទាំង​បី​ដែល​បាន​ពិពណ៌នា​ខាងលើ​។ គេ​អាច​គិត​ថា​ជា​ប្រភេទ​រូបថត​មួយ​ប្រភេទ (រូបថត) ចង្កោម។

ដោយផ្អែកលើព័ត៌មានទាំងអស់នេះ ក្បួនដោះស្រាយជាមូលដ្ឋានអាចត្រូវបានបង្កើតឡើង។ វាធ្វើម្តងទៀតលើចន្លោះឈ្មោះទាំងអស់ និង៖

• ប្រសិនបើ hasLabel បញ្ហា true សម្រាប់​លំហ​ឈ្មោះ​បច្ចុប្បន្ន៖
  • ប្រៀបធៀប​អាថ៌កំបាំង​សកល​ជាមួយ​នឹង​ព័ត៌មាន​ក្នុងស្រុក៖
    • ប្រសិនបើពួកគេដូចគ្នា វាមិនធ្វើអ្វីសោះ។
    • ប្រសិនបើពួកគេខុសគ្នា - ប្រតិបត្តិ kubectl replace ឬ create;
• ប្រសិនបើ hasLabel បញ្ហា false សម្រាប់​លំហ​ឈ្មោះ​បច្ចុប្បន្ន៖
  • ត្រូវប្រាកដថា Secret មិនស្ថិតនៅក្នុងឈ្មោះដែលបានផ្តល់ឱ្យ៖
    • ប្រសិនបើការសម្ងាត់ក្នុងតំបន់មានវត្តមាន សូមលុបវាដោយប្រើ kubectl delete;
    • ប្រសិនបើការសម្ងាត់ក្នុងតំបន់មិនត្រូវបានរកឃើញ វាមិនធ្វើអ្វីទាំងអស់។

ការអនុវត្តក្បួនដោះស្រាយនៅក្នុង Bash អ្នកអាចទាញយកនៅក្នុងរបស់យើង។ ឃ្លាំងជាមួយឧទាហរណ៍.

នោះហើយជារបៀបដែលយើងអាចបង្កើតឧបករណ៍បញ្ជា Kubernetes សាមញ្ញដោយប្រើការកំណត់រចនាសម្ព័ន្ធ YAML ចំនួន 35 បន្ទាត់ និងអំពីចំនួនដូចគ្នានៃកូដ Bash! ការងាររបស់ shell-operator គឺភ្ជាប់ពួកវាជាមួយគ្នា។

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

ឧទាហរណ៍ទី 1៖ ធ្វើការផ្លាស់ប្តូរទៅ ConfigMap

សូមក្រឡេកមើលការដាក់ពង្រាយដែលមានបីផត។ Pods ប្រើ ConfigMap ដើម្បីរក្សាទុកការកំណត់រចនាសម្ព័ន្ធមួយចំនួន។ នៅពេលដែលផតត្រូវបានបើកដំណើរការ ConfigMap គឺស្ថិតនៅក្នុងស្ថានភាពជាក់លាក់មួយ (សូមហៅវាថា v.1)។ ដូច្នោះហើយ pods ទាំងអស់ប្រើកំណែពិសេសនៃ ConfigMap នេះ។

ឥឡូវនេះ ចូរសន្មតថា ConfigMap បានផ្លាស់ប្តូរ (v.2)។ ទោះយ៉ាងណាក៏ដោយ ផតឃែរនឹងប្រើកំណែមុននៃ ConfigMap (v.1)៖

តើខ្ញុំអាចឱ្យពួកគេប្តូរទៅ ConfigMap ថ្មី (v.2) ដោយរបៀបណា? ចម្លើយគឺសាមញ្ញ៖ ប្រើគំរូ។ តោះបន្ថែមចំណារពន្យល់អំពី checksum ទៅផ្នែក template ការកំណត់រចនាសម្ព័ន្ធដាក់ឱ្យប្រើប្រាស់៖

ជាលទ្ធផល មូលប្បទានប័ត្រនេះនឹងត្រូវបានចុះឈ្មោះនៅក្នុងផតទាំងអស់ ហើយវានឹងដូចគ្នានឹងការដាក់ពង្រាយដែរ។ ឥឡូវនេះអ្នកគ្រាន់តែត្រូវការធ្វើបច្ចុប្បន្នភាពចំណារពន្យល់នៅពេល ConfigMap ផ្លាស់ប្តូរ។ ហើយសែល - ប្រតិបត្តិករមកនៅក្នុងការងាយស្រួលក្នុងករណីនេះ។ អ្វីដែលអ្នកត្រូវធ្វើគឺកម្មវិធី ទំពក់ដែលនឹងជាវ ConfigMap និងធ្វើបច្ចុប្បន្នភាព checksum.

ប្រសិនបើអ្នកប្រើធ្វើការផ្លាស់ប្តូរទៅលើ ConfigMap នោះ shell-operator នឹងកត់សម្គាល់ពួកគេ ហើយគណនា checksum ឡើងវិញ។ បន្ទាប់ពីនោះវេទមន្តរបស់ Kubernetes នឹងចូលមកលេង៖ អ្នកប្រគុំតន្ត្រីនឹងសម្លាប់ផត បង្កើតថ្មីមួយ រង់ចាំឱ្យវាក្លាយជា Readyហើយបន្តទៅមួយបន្ទាប់ទៀត។ ជាលទ្ធផល ការដាក់ពង្រាយនឹងធ្វើសមកាលកម្ម និងប្តូរទៅកំណែថ្មីនៃ ConfigMap ។

ឧទាហរណ៍ទី 2៖ ធ្វើការជាមួយការកំណត់ធនធានផ្ទាល់ខ្លួន

ដូចដែលអ្នកដឹង Kubernetes អនុញ្ញាតឱ្យអ្នកបង្កើតប្រភេទវត្ថុផ្ទាល់ខ្លួន។ ឧទាហរណ៍អ្នកអាចបង្កើតប្រភេទ MysqlDatabase. ចូរនិយាយថាប្រភេទនេះមានប៉ារ៉ាម៉ែត្រទិន្នន័យមេតាពីរ៖ name и namespace.

apiVersion: example.com/v1alpha1
kind: MysqlDatabase
metadata:
  name: foo
  namespace: bar

យើង​មាន​ចង្កោម Kubernetes ដែល​មាន​ចន្លោះ​ឈ្មោះ​ផ្សេង​គ្នា ដែល​យើង​អាច​បង្កើត​មូលដ្ឋាន​ទិន្នន័យ MySQL ។ ក្នុងករណីនេះ shell-operator អាចត្រូវបានប្រើដើម្បីតាមដានធនធាន MysqlDatabaseភ្ជាប់ពួកវាទៅម៉ាស៊ីនមេ MySQL និងធ្វើសមកាលកម្មស្ថានភាពដែលចង់បាន និងសង្កេតរបស់ចង្កោម។

ឧទាហរណ៍ទី 3៖ ការត្រួតពិនិត្យបណ្តាញចង្កោម

ដូចដែលអ្នកបានដឹងហើយថាការប្រើ ping គឺជាវិធីសាមញ្ញបំផុតក្នុងការត្រួតពិនិត្យបណ្តាញ។ ក្នុងឧទាហរណ៍នេះ យើងនឹងបង្ហាញពីរបៀបអនុវត្តការត្រួតពិនិត្យបែបនេះដោយប្រើ shell-operator ។

ជាដំបូងអ្នកនឹងត្រូវជាវថ្នាំង។ ប្រតិបត្តិករសែលត្រូវការឈ្មោះ និងអាសយដ្ឋាន IP របស់ថ្នាំងនីមួយៗ។ ដោយមានជំនួយរបស់ពួកគេ គាត់នឹងវាយថ្នាំងទាំងនេះ។

configVersion: v1
kubernetes:
- name: nodes
  apiVersion: v1
  kind: Node
  jqFilter: |
    {
      name: .metadata.name,
      ip: (
       .status.addresses[] |  
        select(.type == "InternalIP") |
        .address
      )
    }
  group: main
  keepFullObjectsInMemory: false
  executeHookOnEvent: []
schedule:
- name: every_minute
  group: main
  crontab: "* * * * *"

ប៉ារ៉ាម៉ែត្រ executeHookOnEvent: [] រារាំងទំពក់មិនឱ្យដំណើរការក្នុងការឆ្លើយតបទៅនឹងព្រឹត្តិការណ៍ណាមួយ (នោះគឺជាការឆ្លើយតបទៅនឹងការផ្លាស់ប្តូរ បន្ថែម ការលុបថ្នាំង)។ ទោះយ៉ាងណាក៏ដោយគាត់ នឹងរត់ (និងធ្វើបច្ចុប្បន្នភាពបញ្ជីថ្នាំង) បានកំណត់ពេល - រាល់នាទី តាមការកំណត់ដោយវាល schedule.

ឥឡូវនេះសំណួរកើតឡើងតើយើងដឹងយ៉ាងពិតប្រាកដអំពីបញ្ហាដូចជាការបាត់បង់កញ្ចប់ព័ត៌មាន? តោះមើលកូដទាំងអស់គ្នា៖

function __main__() {
  for i in $(seq 0 "$(context::jq -r '(.snapshots.nodes | length) - 1')"); do
    node_name="$(context::jq -r '.snapshots.nodes['"$i"'].filterResult.name')"
    node_ip="$(context::jq -r '.snapshots.nodes['"$i"'].filterResult.ip')"
    packets_lost=0
    if ! ping -c 1 "$node_ip" -t 1 ; then
      packets_lost=1
    fi
    cat >> "$METRICS_PATH" <<END
      {
        "name": "node_packets_lost",
        "add": $packets_lost,
        "labels": {
          "node": "$node_name"
        }
      }
END
  done
}

យើងធ្វើម្តងទៀតតាមរយៈបញ្ជីថ្នាំង ទទួលបានឈ្មោះ និងអាសយដ្ឋាន IP របស់ពួកគេ វាយពួកវា ហើយផ្ញើលទ្ធផលទៅ Prometheus ។ Shell-operator អាចនាំចេញម៉ែត្រទៅ Prometheusរក្សាទុកពួកវាទៅក្នុងឯកសារដែលមានទីតាំងនៅតាមផ្លូវដែលបានបញ្ជាក់នៅក្នុងអថេរបរិស្ថាន $METRICS_PATH.

នៅទីនេះ អ្នកអាចបង្កើតប្រតិបត្តិករសម្រាប់ការត្រួតពិនិត្យបណ្តាញសាមញ្ញនៅក្នុងចង្កោមមួយ។

យន្តការតម្រង់ជួរ

អត្ថបទនេះនឹងមិនពេញលេញទេ ដោយមិនបានពិពណ៌នាអំពីយន្តការសំខាន់មួយទៀតដែលបានបង្កើតឡើងនៅក្នុងសែល-ប្រតិបត្តិករ។ ស្រមៃថាវាប្រតិបត្តិប្រភេទនៃទំពក់មួយចំនួនក្នុងការឆ្លើយតបទៅនឹងព្រឹត្តិការណ៍នៅក្នុងចង្កោម។

• តើមានអ្វីកើតឡើងប្រសិនបើក្នុងពេលតែមួយមានអ្វីមួយកើតឡើងនៅក្នុងចង្កោម? មួយទៀត ព្រឹត្តិការណ៍?
• តើ shell-operator នឹងដំណើរការឧទាហរណ៍ផ្សេងទៀតនៃ hook ដែរឬទេ?
• ចុះ​បើ​និយាយ​ថា ព្រឹត្តិការណ៍​ប្រាំ​កើត​ឡើង​ក្នុង​ចង្កោម​តែ​មួយ?
• តើ shell-operator នឹងដំណើរការពួកវាស្របគ្នាដែរឬទេ?
• ចុះ​ធនធាន​ដែល​ប្រើ​ប្រាស់​ដូច​ជា អង្គ​ចងចាំ និង CPU វិញ?

ជាសំណាងល្អ ប្រតិបត្តិករសែលមានយន្តការតម្រង់ជួរដែលភ្ជាប់មកជាមួយ។ ព្រឹត្តិការណ៍ទាំងអស់ត្រូវបានតម្រង់ជួរ និងដំណើរការជាបន្តបន្ទាប់។

ចូរយើងបង្ហាញវាជាមួយនឹងឧទាហរណ៍។ ឧបមាថាយើងមានទំពក់ពីរ។ ព្រឹត្តិការណ៍ដំបូងគឺទៅទំពក់ដំបូង។ នៅពេលដែលដំណើរការរបស់វាបានបញ្ចប់ ជួរនឹងទៅមុខ។ ព្រឹត្តិការណ៍បីបន្ទាប់ត្រូវបានបញ្ជូនបន្តទៅទំពក់ទីពីរ - ពួកគេត្រូវបានដកចេញពីជួរហើយបញ្ចូលទៅក្នុងវានៅក្នុង "បាច់" ។ នោះគឺជា hook ទទួលបានអារេនៃព្រឹត្តិការណ៍ — ឬកាន់តែច្បាស់ជាងនេះទៅទៀត អារេនៃបរិបទចង។

ទាំងនេះផងដែរ។ ព្រឹត្តិការណ៍អាចត្រូវបានរួមបញ្ចូលគ្នាទៅជាធំមួយ។. ប៉ារ៉ាម៉ែត្រទទួលខុសត្រូវចំពោះបញ្ហានេះ group នៅក្នុងការកំណត់រចនាសម្ព័ន្ធចង។

អ្នកអាចបង្កើតចំនួនជួរ/ទំពក់ណាមួយ និងបន្សំផ្សេងៗរបស់វា។ ឧទាហរណ៍ ជួរមួយអាចធ្វើការជាមួយទំពក់ពីរ ឬច្រាសមកវិញ។

អ្វីទាំងអស់ដែលអ្នកត្រូវធ្វើគឺកំណត់រចនាសម្ព័ន្ធវាលស្របតាម queue នៅក្នុងការកំណត់រចនាសម្ព័ន្ធចង។ ប្រសិនបើឈ្មោះជួរមិនត្រូវបានបញ្ជាក់ នោះទំពក់ដំណើរការលើជួរលំនាំដើម (default) យន្តការដាក់ជួរនេះអនុញ្ញាតឱ្យអ្នកដោះស្រាយបញ្ហាគ្រប់គ្រងធនធានទាំងស្រុងនៅពេលធ្វើការជាមួយទំពក់។

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

យើងបានពន្យល់ពីអ្វីដែលជាប្រតិបត្តិករសែល បានបង្ហាញពីរបៀបដែលវាអាចត្រូវបានប្រើដើម្បីបង្កើតប្រតិបត្តិករ Kubernetes យ៉ាងឆាប់រហ័ស និងដោយមិនចាំបាច់ប្រឹងប្រែង ហើយបានផ្តល់ឧទាហរណ៍ជាច្រើននៃការប្រើប្រាស់របស់វា។

ព័ត៌មានលម្អិតអំពីប្រតិបត្តិករសែល ក៏ដូចជាការបង្រៀនរហ័សអំពីរបៀបប្រើវា មាននៅក្នុងឯកសារដែលត្រូវគ្នា។ ឃ្លាំងនៅលើ GitHub. កុំស្ទាក់ស្ទើរក្នុងការទាក់ទងមកយើងជាមួយនឹងសំណួរ: អ្នកអាចពិភាក្សាពួកគេនៅក្នុងពិសេសមួយ។ ក្រុម Telegram (ជាភាសារុស្សី) ឬក្នុង វេទិកានេះ។ (ជា​ភាសាអង់គ្លេស)។

ហើយប្រសិនបើអ្នកចូលចិត្តវា យើងតែងតែរីករាយក្នុងការឃើញបញ្ហាថ្មីៗ / PR / តារានៅលើ GitHub ដែលជាកន្លែងដែលអ្នកអាចស្វែងរកអ្នកផ្សេងទៀត គម្រោងគួរឱ្យចាប់អារម្មណ៍. ក្នុងចំណោមពួកគេវាមានតម្លៃក្នុងការបន្លិច addon-operatorដែលជាបងប្រុសធំរបស់សែល-ប្រតិបត្តិករ. ឧបករណ៍ប្រើប្រាស់នេះប្រើគំនូសតាង Helm ដើម្បីដំឡើងកម្មវិធីបន្ថែម អាចផ្តល់ការអាប់ដេត និងត្រួតពិនិត្យប៉ារ៉ាម៉ែត្រ/តម្លៃតារាងផ្សេងៗ គ្រប់គ្រងដំណើរការដំឡើងតារាង ហើយក៏អាចកែប្រែពួកវាជាការឆ្លើយតបទៅនឹងព្រឹត្តិការណ៍នៅក្នុងចង្កោមផងដែរ។

វីដេអូ និងស្លាយ

វីដេអូពីការសម្តែង (~២៣ នាទី)៖

បទបង្ហាញនៃរបាយការណ៍៖

PS

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

• «ភាពងាយស្រួលនៃការបង្កើតប្រតិបត្តិករ Kubernetes ជាមួយសែល-ប្រតិបត្តិករ៖ ដំណើរការគម្រោងក្នុងរយៈពេលមួយឆ្នាំ»
• «ការណែនាំសែល-ប្រតិបត្តិករ៖ ការបង្កើតប្រតិបត្តិករសម្រាប់ Kubernetes កាន់តែងាយស្រួលជាងមុន»
• «តើវាងាយស្រួល និងងាយស្រួលក្នុងការរៀបចំចង្កោម Kubernetes ទេ? ប្រកាស​ប្រតិបត្តិករ addon»
• «ការពង្រីក និងបំពេញបន្ថែម Kubernetes" (ការពិនិត្យឡើងវិញ និងរបាយការណ៍វីដេអូ).

ប្រភព: www.habr.com