របៀបចូលប្រើធនធាន Kubernetes Pod

រង្វាន់ដោយ Tohad

នៅពេលចាប់ផ្តើមជាមួយ Kubernetes វាជារឿងធម្មតាទេក្នុងការភ្លេចអំពីការដំឡើងធនធានធុង។ នៅចំណុចនេះ វាគ្រប់គ្រាន់ហើយក្នុងការធានាថារូបភាព Docker ដំណើរការ និងអាចត្រូវបានដាក់ពង្រាយទៅកាន់ក្រុម Kubernetes ។

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

ក្រុមការងារ Kubernetes aaS ពី Mail.ru បកប្រែអត្ថបទអំពីធនធានកុងតឺន័រ (CPU & MEM) សំណើ និងការកំណត់ធនធាន។ អ្នកនឹងរៀនពីអត្ថប្រយោជន៍នៃការកំណត់ទាំងនេះ ហើយនឹងមានអ្វីកើតឡើង ប្រសិនបើអ្នកមិនកំណត់ពួកវា។

ធនធានកុំព្យូទ័រ

យើងមានធនធានពីរប្រភេទដែលមានឯកតាដូចខាងក្រោមៈ

• អង្គភាពដំណើរការកណ្តាល (ស៊ីភីយូ) - ស្នូល;
• អង្គចងចាំ (MEM) - បៃ។

ធនធានត្រូវបានបញ្ជាក់សម្រាប់កុងតឺន័រនីមួយៗ។ នៅក្នុងឯកសារ Pod YAML ខាងក្រោម អ្នកនឹងឃើញផ្នែកធនធានដែលមានធនធានដែលបានស្នើ និងកំណត់៖

• ធនធាន Pod បានស្នើសុំ = ផលបូកនៃធនធានដែលបានស្នើសុំនៃធុងទាំងអស់;
• ដែនកំណត់ធនធាន Pod = ផលបូកនៃដែនកំណត់ធនធាន Pod ទាំងអស់។

apiVersion: v1
kind: Pod
metadata:
  name: backend-pod-name
  labels:
    application: backend
spec:
  containers:
    — name: main-container
      image: my-backend
      tag: v1
      ports:
      — containerPort: 8080
      resources:
        requests:
          cpu: 0.2 # REQUESTED CPU: 200m cores
          memory: "1Gi" # REQUESTED MEM: 1Gi
        limits:
          cpu: 1 # MAX CPU USAGE: 1 core
          memory: "1Gi" # MAX MEM USAGE:  1Gi
    — name: other-container
      image: other-app
      tag: v1
      ports:
      — containerPort: 8000
      resources:
        requests:
          cpu: "200m" # REQUESTED CPU: 200m cores
          memory: "0.5Gi" # REQUESTED MEM: 0.5Gi
        limits:
          cpu: 1 # MAX CPU USAGE: 1 core
          memory: "1Gi" # MAX MEM USAGE:  1Gi

ឧទាហរណ៍នៃធនធានដែលបានស្នើសុំ និងមានកំណត់

វាល resources.requested ពីការបញ្ជាក់ Pod គឺជាធាតុមួយក្នុងចំណោមធាតុដែលត្រូវបានប្រើដើម្បីស្វែងរកថ្នាំងដែលចង់បាន។ អ្នកអាចរៀបចំផែនការដាក់ពង្រាយ Pod សម្រាប់វារួចហើយ។ តើអ្នកស្វែងរកថ្នាំងដែលសមរម្យដោយរបៀបណា?

Kubernetes មានសមាសធាតុជាច្រើន រួមទាំងថ្នាំងមេ ឬថ្នាំងមេ (យន្តហោះគ្រប់គ្រង Kubernetes)។ ថ្នាំងមេមានដំណើរការជាច្រើន៖ kube-apiserver, kube-controller-manager និង kube-scheduler ។

ដំណើរការកម្មវិធីកំណត់ពេល kube ទទួលខុសត្រូវចំពោះការពិនិត្យឡើងវិញនូវផតថលដែលបានបង្កើតថ្មី និងស្វែងរកថ្នាំងកម្មករដែលអាចធ្វើបានដែលត្រូវនឹងសំណើរបស់ផតទាំងអស់ រួមទាំងចំនួនធនធានដែលបានស្នើ។ បញ្ជីថ្នាំងដែលបានរកឃើញដោយ kube-scheduler ត្រូវបានចាត់ថ្នាក់។ pod ត្រូវបានកំណត់ពេលនៅលើថ្នាំងដែលមានពិន្ទុខ្ពស់បំផុត។

តើផតពណ៌ស្វាយនឹងត្រូវដាក់នៅឯណា?

នៅក្នុងរូបភាពអ្នកអាចមើលឃើញថា kube-scheduler គួរតែកំណត់ពេល Pod ពណ៌ស្វាយថ្មី។ ចង្កោម Kubernetes មានថ្នាំងពីរ៖ A និង B. ដូចដែលអ្នកអាចឃើញ អ្នកកំណត់កាលវិភាគ kube មិនអាចកំណត់ពេល Pod នៅលើ node A បានទេ - ធនធានដែលមាន (មិនបានស្នើសុំ) មិនត្រូវគ្នានឹងសំណើរបស់ Pod ពណ៌ស្វាយទេ។ ដូច្នេះ អង្គចងចាំ 1 GB ដែលស្នើសុំដោយ Pod ពណ៌ស្វាយ នឹងមិនសមនៅលើថ្នាំង A ទេ ព្រោះអង្គចងចាំដែលមានគឺ 0,5 GB ។ ប៉ុន្តែថ្នាំង B មានធនធានគ្រប់គ្រាន់។ ជាលទ្ធផល kube-scheduler សម្រេចថាទិសដៅនៃ Pod ពណ៌ស្វាយគឺ node B ។

ឥឡូវនេះយើងដឹងពីរបៀបដែលធនធានដែលបានស្នើសុំប៉ះពាល់ដល់ជម្រើសនៃ node ដើម្បីដំណើរការ Pod ។ ប៉ុន្តែ តើ​អ្វី​ទៅ​ជា​ផល​ប៉ះ​ពាល់​នៃ​ធនធាន​រឹម?

ដែនកំណត់ធនធានគឺជាព្រំដែនដែល CPU/MEM មិនអាចឆ្លងកាត់បានទេ។ ទោះជាយ៉ាងណាក៏ដោយ ធនធាន CPU អាចបត់បែនបាន ដូច្នេះកុងតឺន័រដែលឈានដល់ដែនកំណត់ CPU របស់ពួកគេនឹងមិនបណ្តាលឱ្យ Pod ចាកចេញទេ។ ផ្ទុយទៅវិញ ការបិទ CPU នឹងចាប់ផ្តើម។ ប្រសិនបើដែនកំណត់នៃការប្រើប្រាស់ MEM ត្រូវបានឈានដល់ កុងតឺន័រនឹងត្រូវបានបញ្ឈប់ដោយសារតែ OOM-Killer ហើយចាប់ផ្តើមឡើងវិញ ប្រសិនបើអនុញ្ញាតដោយការកំណត់ RestartPolicy។

បានស្នើសុំ និងធនធានអតិបរិមានៃលម្អិត

ការទំនាក់ទំនងធនធានរវាង Docker និង Kubernetes

វិធីល្អបំផុតដើម្បីពន្យល់ពីរបៀបដែលសំណើធនធាន និងដែនកំណត់ធនធានដំណើរការគឺដើម្បីណែនាំទំនាក់ទំនងរវាង Kubernetes និង Docker ។ នៅក្នុងរូបភាពខាងលើ អ្នកអាចមើលឃើញពីរបៀបដែលវាល Kubernetes និងទង់ចាប់ផ្ដើម Docker មានទំនាក់ទំនងគ្នា។

អង្គចងចាំ៖ សំណើនិងដែនកំណត់

containers:
...
 resources:
   requests:
     memory: "0.5Gi"
   limits:
     memory: "1Gi"

ដូចដែលបានរៀបរាប់ខាងលើអង្គចងចាំត្រូវបានវាស់ជាបៃ។ អាស្រ័យ​លើ ឯកសារ Kubernetesយើងអាចបញ្ជាក់អង្គចងចាំជាលេខ។ ជាធម្មតាវាគឺជាចំនួនគត់ ឧទាហរណ៍ 2678 - នោះគឺ 2678 បៃ។ អ្នកក៏អាចប្រើបច្ច័យបានដែរ។ G и Giរឿងចំបងគឺត្រូវចាំថាពួកគេមិនស្មើ។ ទីមួយគឺទសភាគ ហើយទីពីរគឺគោលពីរ។ ដូចឧទាហរណ៍ដែលបានរៀបរាប់នៅក្នុងឯកសារ k8s៖ 128974848, 129e6, 129M, 123Mi - ពួកគេគឺសមមូលជាក់ស្តែង។

ជម្រើស Kubernetes limits.memory ផ្គូផ្គងទង់ជាតិ --memory ពី Docker ។ ក្នុងករណី request.memory មិនមានព្រួញសម្រាប់ Docker ព្រោះ Docker មិនប្រើវាលនេះទេ។ អ្នក​អាច​សួរ​ថា តើ​នេះ​ចាំបាច់​ឬ​ទេ? បាទត្រូវការ។ ដូចដែលខ្ញុំបាននិយាយពីមុន វាលសំខាន់សម្រាប់ Kubernetes ។ ដោយផ្អែកលើព័ត៌មានពីវា kube-scheduler សម្រេចចិត្តលើថ្នាំងណាដែលត្រូវកំណត់ពេល Pod ។

តើមានអ្វីកើតឡើងប្រសិនបើអ្នកកំណត់អង្គចងចាំមិនគ្រប់គ្រាន់សម្រាប់ការស្នើសុំ?

ប្រសិនបើកុងតឺន័រឈានដល់ដែនកំណត់នៃអង្គចងចាំដែលបានស្នើសុំ នោះ Pod ត្រូវបានដាក់ក្នុងក្រុមនៃ Pods ដែលឈប់នៅពេលដែលមិនមានអង្គចងចាំគ្រប់គ្រាន់នៅក្នុងថ្នាំង។

តើមានអ្វីកើតឡើងប្រសិនបើអ្នកកំណត់កម្រិតអង្គចងចាំទាបពេក?

ប្រសិនបើកុងតឺន័រលើសពីដែនកំណត់នៃអង្គចងចាំ វានឹងត្រូវបានបិទដោយសារតែ OOM-Killed ។ ហើយនឹងចាប់ផ្តើមឡើងវិញប្រសិនបើអាចធ្វើទៅបានដោយផ្អែកលើ RestartPolicy ដែលតម្លៃលំនាំដើមគឺ Always.

តើមានអ្វីកើតឡើងប្រសិនបើអ្នកមិនបញ្ជាក់អង្គចងចាំដែលបានស្នើសុំ?

Kubernetes នឹងយកតម្លៃកំណត់ ហើយកំណត់វាជាតម្លៃលំនាំដើម។

តើមានអ្វីកើតឡើង ប្រសិនបើអ្នកមិនបញ្ជាក់ដែនកំណត់នៃការចងចាំ?

កុងតឺន័រមិនមានការរឹតបន្តឹងទេ វាអាចប្រើអង្គចងចាំបានច្រើនតាមដែលវាចង់បាន។ ប្រសិនបើគាត់ចាប់ផ្តើមប្រើអង្គចងចាំដែលមានទាំងអស់នៃ node នោះ OOM នឹងសម្លាប់គាត់។ បន្ទាប់មកកុងតឺន័រនឹងត្រូវបានចាប់ផ្តើមឡើងវិញប្រសិនបើអាចធ្វើទៅបានដោយផ្អែកលើ RestartPolicy។

តើមានអ្វីកើតឡើងប្រសិនបើអ្នកមិនបញ្ជាក់ដែនកំណត់នៃការចងចាំ?

នេះគឺជាសេណារីយ៉ូករណីដ៏អាក្រក់បំផុត៖ អ្នកកំណត់ពេលមិនដឹងថាធនធានប៉ុន្មានដែលកុងតឺន័រត្រូវការនោះទេ ហើយវាអាចបណ្តាលឱ្យមានបញ្ហាធ្ងន់ធ្ងរនៅលើថ្នាំង។ ក្នុង​ករណី​នេះ វា​ជា​ការ​ល្អ​ដែល​មាន​ការ​កំណត់​លំនាំដើម​លើ​ចន្លោះ​ឈ្មោះ (កំណត់​ដោយ LimitRange)។ មិនមានដែនកំណត់លំនាំដើមទេ - Pod មិនមានដែនកំណត់ទេ វាអាចប្រើអង្គចងចាំបានច្រើនតាមដែលវាចង់បាន។

ប្រសិនបើអង្គចងចាំដែលបានស្នើមានច្រើនជាងថ្នាំងអាចផ្តល់ជូន Pod នឹងមិនត្រូវបានកំណត់ពេលទេ។ វាជារឿងសំខាន់ក្នុងការចងចាំរឿងនោះ។ Requests.memory - មិនមែនជាតម្លៃអប្បបរមាទេ។ នេះគឺជាការពិពណ៌នាអំពីបរិមាណអង្គចងចាំគ្រប់គ្រាន់ ដើម្បីរក្សាកុងតឺន័រដំណើរការជាបន្តបន្ទាប់។

ជាធម្មតាវាត្រូវបានណែនាំឱ្យកំណត់តម្លៃដូចគ្នាសម្រាប់ request.memory и limit.memory. នេះធានាថា Kubernetes នឹងមិនកំណត់ពេល Pod នៅលើថ្នាំងដែលមានអង្គចងចាំគ្រប់គ្រាន់ដើម្បីដំណើរការ Pod ប៉ុន្តែមិនគ្រប់គ្រាន់ដើម្បីដំណើរការវា។ សូមចងចាំ៖ ការធ្វើផែនការ Kubernetes Pod គិតតែពីក្នុងគណនីប៉ុណ្ណោះ។ requests.memoryនិង limits.memory មិនយកទៅក្នុងគណនី។

ស៊ីភីយូ៖ សំណើ និងដែនកំណត់

containers:
...
 resources:
   requests:
     cpu: 1
   limits:
     cpu: "1200m"

ជាមួយនឹង CPU អ្វីគ្រប់យ៉ាងគឺស្មុគស្មាញបន្តិច។ ត្រលប់ទៅរូបភាពនៃទំនាក់ទំនងរវាង Kubernetes និង Docker អ្នកអាចមើលឃើញនោះ។ request.cpu ត្រូវនឹង --cpu-sharesចំណែកឯ limit.cpu ផ្គូផ្គងទង់ជាតិ cpus នៅក្នុង Docker ។

ស៊ីភីយូដែល Kubernetes ស្នើសុំត្រូវបានគុណនឹង 1024 ដែលជាសមាមាត្រនៃវដ្តស៊ីភីយូ។ ប្រសិនបើអ្នកចង់ស្នើសុំ 1 ស្នូលពេញលេញ អ្នកត្រូវតែបន្ថែម cpu: 1ដូចដែលបានបង្ហាញខាងលើ។

ការស្នើសុំខឺណែលពេញលេញ (សមាមាត្រ = 1024) មិនមានន័យថាកុងតឺន័ររបស់អ្នកនឹងទទួលបានវាទេ។ ប្រសិនបើម៉ាស៊ីនម៉ាស៊ីនរបស់អ្នកមានស្នូលតែមួយ ហើយអ្នកកំពុងដំណើរការច្រើនជាងមួយកុងតឺន័រ នោះកុងតឺន័រទាំងអស់ត្រូវតែចែករំលែកស៊ីភីយូដែលមានរវាងពួកវា។ តើរឿងនេះកើតឡើងដោយរបៀបណា? តោះមើលរូបភាព។

សំណើស៊ីភីយូ - ប្រព័ន្ធស្នូលតែមួយ

ចូរស្រមៃថាអ្នកមានប្រព័ន្ធម៉ាស៊ីនតែមួយស្នូលដែលដំណើរការកុងតឺន័រ។ ម៉ាក់ (Kubernetes) ដុតនំនំមួយ (ស៊ីភីយូ) ហើយចង់បែងចែកវារវាងកុមារ (ធុង) ។ កូនបីនាក់ចង់បានចំណិតទាំងមូល (សមាមាត្រ = 1024) កូនម្នាក់ទៀតចង់បាននំពាក់កណ្តាល (512) ។ ម៉ាក់ចង់ឱ្យមានភាពយុត្តិធម៌និងធ្វើការគណនាសាមញ្ញ។

# Сколько пирогов хотят дети?
# 3 ребенка хотят по целому пирогу и еще один хочет половину пирога
cakesNumberKidsWant = (3 * 1) + (1 * 0.5) = 3.5
# Выражение получается так:
3 (ребенка/контейнера) * 1 (целый пирог/полное ядро) + 1 (ребенок/контейнер) * 0.5 (половина пирога/половина ядра)
# Сколько пирогов испечено?
availableCakesNumber = 1
# Сколько пирога (максимально) дети реально могут получить?
newMaxRequest = 1 / 3.5 =~ 28%

ដោយផ្អែកលើការគណនាកុមារបីនាក់នឹងទទួលបាន 28% នៃស្នូលហើយមិនមែនស្នូលទាំងមូលទេ។ កូនទីបួននឹងទទួលបាន 14% នៃខឺណែលពេញ មិនមែនពាក់កណ្តាលទេ។ ប៉ុន្តែអ្វីៗនឹងខុសគ្នាប្រសិនបើអ្នកមានប្រព័ន្ធពហុស្នូល។

សំណើ CPU - ប្រព័ន្ធ Multi-Core (4)

នៅក្នុងរូបភាពខាងលើ អ្នកអាចមើលឃើញថាកុមារបីនាក់ចង់បាននំទាំងមូល ហើយម្នាក់ចង់បានពាក់កណ្តាល។ ចាប់តាំងពីម៉ាក់ដុតនំបួនបន្ទះ កូនៗរបស់គាត់នឹងទទួលបានច្រើនតាមដែលពួកគេចង់បាន។ នៅក្នុងប្រព័ន្ធពហុស្នូល ធនធានដំណើរការត្រូវបានចែកចាយនៅទូទាំងស្នូលដំណើរការដែលមានទាំងអស់។ ប្រសិនបើកុងតឺន័រត្រូវបានកំណត់ត្រឹមស្នូលស៊ីភីយូពេញលេញតិចជាងមួយ វានៅតែអាចប្រើវាបាន 100% ។

ការគណនាខាងលើត្រូវបានធ្វើឱ្យសាមញ្ញដើម្បីយល់ពីរបៀបដែលស៊ីភីយូត្រូវបានចែកចាយក្នុងចំណោមកុងតឺន័រ។ ជាការពិតណាស់ ក្រៅពីកុងតឺន័រខ្លួនឯង មានដំណើរការផ្សេងទៀតដែលប្រើប្រាស់ធនធាន CPU ផងដែរ។ នៅពេលដែលដំណើរការនៅក្នុងកុងតឺន័រមួយមិនដំណើរការ អ្នកផ្សេងទៀតអាចប្រើធនធានរបស់វា។ CPU: "200m" ត្រូវនឹង CPU: 0,2ដែលមានន័យថាប្រហែល 20% នៃស្នូលមួយ។

ឥឡូវនេះសូមនិយាយអំពី limit.cpu. ស៊ីភីយូដែល Kubernetes កំណត់ត្រូវបានគុណនឹង 100។ លទ្ធផលគឺចំនួនពេលវេលាដែលកុងតឺន័រអាចប្រើរាល់ 100 µs (cpu-period).

limit.cpu ផ្គូផ្គងទង់ Docker --cpus. នេះគឺជាការរួមបញ្ចូលគ្នាថ្មីនៃចាស់ --cpu-period и --cpu-quota. តាមរយៈការកំណត់វា យើងបង្ហាញពីចំនួនធនធាន CPU ដែលមានស្រាប់ ដែលកុងតឺន័រអាចប្រើជាអតិបរមា មុនពេលបិទបើក៖

• ស៊ីភី - ការរួមបញ្ចូលគ្នា cpu-period и cpu-quota. cpus = 1.5 ស្មើនឹងការកំណត់ cpu-period = 100000 и cpu-quota = 150000;
• រយៈពេលស៊ីភីយូ - រយៈពេល កម្មវិធីកំណត់ពេលស៊ីភីយូ CFSលំនាំដើម 100 មីក្រូវិនាទី;
• cpu-កូតា - ចំនួនមីក្រូវិនាទីនៅខាងក្នុង cpu-periodដែលត្រូវបានចងដោយធុង។

តើមានអ្វីកើតឡើងប្រសិនបើអ្នកដំឡើង CPU ដែលស្នើសុំមិនគ្រប់គ្រាន់?

ប្រសិនបើកុងតឺន័រត្រូវការច្រើនជាងដែលវាបានដំឡើង វានឹងលួចស៊ីភីយូពីដំណើរការផ្សេងទៀត។

តើមានអ្វីកើតឡើងប្រសិនបើអ្នកកំណត់ដែនកំណត់ស៊ីភីយូទាបពេក?

ដោយសារធនធាន CPU អាចកែតម្រូវបាន ការបិទបើកនឹងបើក។

តើមានអ្វីកើតឡើងប្រសិនបើអ្នកមិនបញ្ជាក់សំណើ CPU?

ដូចនឹងអង្គចងចាំ តម្លៃសំណើគឺស្មើនឹងដែនកំណត់។

តើមានអ្វីកើតឡើងប្រសិនបើអ្នកមិនបញ្ជាក់ដែនកំណត់ស៊ីភីយូ?

កុងតឺន័រនឹងប្រើស៊ីភីយូច្រើនតាមដែលវាត្រូវការ។ ប្រសិនបើគោលការណ៍ CPU លំនាំដើម (LimitRange) ត្រូវបានកំណត់នៅក្នុង namespace នោះដែនកំណត់នេះក៏ត្រូវបានប្រើសម្រាប់កុងតឺន័រផងដែរ។

តើមានអ្វីកើតឡើងប្រសិនបើអ្នកមិនបញ្ជាក់ទាំងសំណើរ ឬដែនកំណត់ CPU?

ដូចទៅនឹងការចងចាំ នេះគឺជាសេណារីយ៉ូដែលអាក្រក់បំផុត។ កម្មវិធីកំណត់ពេលមិនដឹងថាតើកុងតឺន័ររបស់អ្នកត្រូវការធនធានប៉ុន្មានទេ ហើយវាអាចបណ្តាលឱ្យមានបញ្ហាធ្ងន់ធ្ងរនៅលើថ្នាំង។ ដើម្បីជៀសវាងបញ្ហានេះ អ្នកត្រូវកំណត់ការកំណត់លំនាំដើមសម្រាប់ namespaces (LimitRange)។

ចងចាំ៖ ប្រសិនបើអ្នកស្នើសុំ CPU ច្រើនជាងថ្នាំងអាចផ្តល់ Pod នឹងមិនត្រូវបានកំណត់ពេលទេ។ Requests.cpu - មិនមែនជាតម្លៃអប្បបរមាទេ ប៉ុន្តែជាតម្លៃដែលគ្រប់គ្រាន់ដើម្បីចាប់ផ្តើម Pod និងដំណើរការដោយគ្មានការបរាជ័យ។ ប្រសិនបើកម្មវិធីមិនធ្វើការគណនាស្មុគ្រស្មាញទេ ជម្រើសដ៏ល្អបំផុតគឺត្រូវដំឡើង request.cpu <= 1 និងបើកដំណើរការចម្លងតាមតម្រូវការ។

ចំនួនសមស្របនៃធនធានដែលបានស្នើសុំ ឬដែនកំណត់ធនធាន

យើងបានរៀនអំពីដែនកំណត់នៃធនធានកុំព្យូទ័រ។ ឥឡូវនេះវាដល់ពេលដែលត្រូវឆ្លើយសំណួរ៖ "តើ Pod របស់ខ្ញុំត្រូវការធនធានប៉ុន្មានដើម្បីដំណើរការកម្មវិធីដោយគ្មានបញ្ហាអ្វី? តើ​អ្វី​ជា​ចំនួន​សម​ស្រប?

ជាអកុសល មិនមានចម្លើយច្បាស់លាស់ចំពោះសំណួរទាំងនេះទេ។ ប្រសិនបើអ្នកមិនដឹងថាកម្មវិធីរបស់អ្នកដំណើរការយ៉ាងដូចម្តេច ឬថាតើ CPU ឬ Memory ប៉ុន្មានដែលវាត្រូវការនោះ ជម្រើសដ៏ល្អបំផុតគឺផ្តល់ឱ្យកម្មវិធីនូវ Memory និង CPU ច្រើនហើយបន្ទាប់មកដំណើរការតេស្តដំណើរការ។

បន្ថែមពីលើការធ្វើតេស្តការអនុវត្ត តាមដានឥរិយាបថរបស់កម្មវិធីក្នុងការត្រួតពិនិត្យរយៈពេលមួយសប្តាហ៍។ ប្រសិនបើក្រាហ្វបង្ហាញថាកម្មវិធីរបស់អ្នកប្រើប្រាស់ធនធានតិចជាងអ្នកបានស្នើសុំ អ្នកអាចកាត់បន្ថយបរិមាណស៊ីភីយូ ឬអង្គចងចាំដែលបានស្នើសុំ។

ជាឧទាហរណ៍សូមមើលនេះ។ ផ្ទាំងគ្រប់គ្រង Grafana. វាបង្ហាញភាពខុសគ្នារវាងធនធានដែលបានស្នើសុំ ឬដែនកំណត់ធនធាន និងការប្រើប្រាស់ធនធានបច្ចុប្បន្ន។

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

ការស្នើសុំ និងការកំណត់ធនធានជួយឱ្យក្រុម Kubernetes របស់អ្នកមានសុខភាពល្អ។ ការកំណត់ការកំណត់ត្រឹមត្រូវកាត់បន្ថយការចំណាយ និងធ្វើឱ្យកម្មវិធីដំណើរការគ្រប់ពេល។

សរុបមក មានចំណុចមួយចំនួនដែលត្រូវចងចាំ៖

1. ធនធានដែលបានស្នើសុំគឺជាការកំណត់រចនាសម្ព័ន្ធដែលត្រូវយកមកពិចារណានៅពេលចាប់ផ្តើម (នៅពេល Kubernetes គ្រោងរៀបចំកម្មវិធី)។ ផ្ទុយទៅវិញ ការកំណត់ធនធានមានសារៈសំខាន់នៅពេលដំណើរការ - នៅពេលដែលកម្មវិធីកំពុងដំណើរការនៅលើថ្នាំងរួចហើយ។
2. បើប្រៀបធៀបទៅនឹងអង្គចងចាំ ស៊ីភីយូគឺជាធនធានដែលមានការគ្រប់គ្រង។ ប្រសិនបើមិនមានស៊ីភីយូគ្រប់គ្រាន់ទេ Pod របស់អ្នកនឹងមិនបិទទេ ហើយយន្តការបិទបើកនឹងបើក។
3. ធនធានដែលបានស្នើសុំ និងដែនកំណត់ធនធានមិនមែនជាតម្លៃអប្បបរមា និងអតិបរមាទេ! តាមរយៈការកំណត់ធនធានដែលបានស្នើ អ្នកធានាថាកម្មវិធីនឹងដំណើរការដោយគ្មានបញ្ហា។
4. ការអនុវត្តល្អគឺកំណត់ការស្នើសុំអង្គចងចាំស្មើនឹងដែនកំណត់នៃអង្គចងចាំ។
5. យល់ព្រមដំឡើងបានស្នើ CPU <=1ប្រសិនបើកម្មវិធីមិនធ្វើការគណនាស្មុគស្មាញ។
6. ប្រសិនបើអ្នកស្នើសុំធនធានច្រើនជាងមាននៅលើ node នោះ Pod នឹងមិនត្រូវបានកំណត់ពេលទៅ node នោះទេ។
7. ដើម្បីកំណត់បរិមាណត្រឹមត្រូវនៃធនធាន/ដែនកំណត់ធនធានដែលបានស្នើសុំ សូមប្រើការធ្វើតេស្តផ្ទុក និងការត្រួតពិនិត្យ។

ខ្ញុំសង្ឃឹមថាអត្ថបទនេះជួយអ្នកឱ្យយល់ពីគោលគំនិតជាមូលដ្ឋាននៃការកំណត់ធនធាន។ ហើយអ្នកនឹងអាចអនុវត្តចំណេះដឹងនេះនៅក្នុងការងាររបស់អ្នក។

សូមសំណាងល្អ!

តើមានអ្វីទៀតដែលត្រូវអាន៖

1. SRE Observability: Namespaces និង Metric Structure.
2. ឧបករណ៍មានប្រយោជន៍ 90+ សម្រាប់ Kubernetes៖ ការដាក់ពង្រាយ ការគ្រប់គ្រង ការត្រួតពិនិត្យ សុវត្ថិភាព និងច្រើនទៀត.
3. ប៉ុស្តិ៍របស់យើងនៅជុំវិញ Kubernetes នៅក្នុង Telegram.

ប្រភព: www.habr.com