🥇10 កំហុសទូទៅនៅពេលប្រើ Kubernetes

ចំណាំ។ បកប្រែ៖ អ្នកនិពន្ធអត្ថបទនេះគឺជាវិស្វករមកពីក្រុមហ៊ុនឆេកតូចមួយ pipetail ។ ពួកគេបានគ្រប់គ្រងដើម្បីប្រមូលបញ្ជីដ៏អស្ចារ្យនៃ [ពេលខ្លះ banal, ប៉ុន្តែនៅតែ] បញ្ហាយ៉ាងខ្លាំង និងការយល់ខុសទាក់ទងនឹងប្រតិបត្តិការនៃក្រុម Kubernetes ។

ក្នុងរយៈពេលជាច្រើនឆ្នាំនៃការប្រើប្រាស់ Kubernetes យើងបានធ្វើការជាមួយក្រុមមួយចំនួនធំ (ទាំងគ្រប់គ្រង និងមិនអាចគ្រប់គ្រងបាន - នៅលើ GCP, AWS និង Azure)។ យូរៗទៅ យើងចាប់ផ្តើមកត់សំគាល់ថា កំហុសខ្លះកើតឡើងដដែលៗ។ ទោះជាយ៉ាងណាក៏ដោយវាមិនមានការខ្មាស់អៀនក្នុងរឿងនេះទេ: យើងបានធ្វើដោយខ្លួនឯងភាគច្រើន!

អត្ថបទមានកំហុសទូទៅបំផុត ហើយក៏និយាយអំពីរបៀបកែកំហុសទាំងនោះផងដែរ។

1. ធនធាន៖ សំណើ និងដែនកំណត់

ធាតុនេះពិតជាសមនឹងទទួលបានការយកចិត្តទុកដាក់ និងកន្លែងដំបូងបំផុតក្នុងបញ្ជី។

ជាធម្មតាការស្នើសុំស៊ីភីយូ មិនបានបញ្ជាក់អ្វីទាំងអស់ ឬមានតម្លៃទាបបំផុត។ (ដើម្បីដាក់ pods ឱ្យបានច្រើននៅលើថ្នាំងនីមួយៗតាមដែលអាចធ្វើបាន) ។ ដូច្នេះថ្នាំងក្លាយទៅជាលើសទម្ងន់។ ក្នុងអំឡុងពេលនៃបន្ទុកខ្ពស់ ថាមពលដំណើរការរបស់ថ្នាំងត្រូវបានប្រើប្រាស់យ៉ាងពេញលេញ ហើយបន្ទុកការងារជាក់លាក់ណាមួយទទួលបានតែអ្វីដែលវា "បានស្នើសុំ" ដោយ ការបិទដំណើរការស៊ីភីយូ. នេះនាំឱ្យមានការកើនឡើងនៃភាពយឺតយ៉ាវនៃកម្មវិធី ការអស់ពេល និងផលវិបាកមិនល្អផ្សេងទៀត។ (សូមអានបន្ថែមអំពីរឿងនេះនៅក្នុងការបកប្រែថ្មីៗផ្សេងទៀតរបស់យើង៖ “ដែនកំណត់ស៊ីភីយូ និងការបិទបើកដ៏ខ្លាំងក្លានៅក្នុង Kubernetes" - ប្រហែល។ បកប្រែ។ )

ការខិតខំប្រឹងប្រែងល្អបំផុត (យ៉ាងខ្លាំង មិនមាន បានណែនាំ):

resources: {}

សំណើ CPU ទាបខ្លាំង (ខ្លាំងណាស់ មិនមាន បានណែនាំ):

   resources:
      Requests:
        cpu: "1m"

ម្យ៉ាងវិញទៀត វត្តមាននៃដែនកំណត់ស៊ីភីយូអាចនាំឱ្យមានការរំលងវដ្តនាឡិកាដោយមិនសមហេតុផល បើទោះបីជាប្រព័ន្ធដំណើរការថ្នាំងមិនត្រូវបានផ្ទុកពេញលេញក៏ដោយ។ ជាថ្មីម្តងទៀត នេះអាចនាំឱ្យមានការពន្យារពេលកើនឡើង។ ភាពចម្រូងចម្រាសនៅតែបន្តជុំវិញប៉ារ៉ាម៉ែត្រ កូតាស៊ីភីយូ CFS នៅក្នុងខឺណែលលីនុច និងការបិទដំណើរការស៊ីភីយូ អាស្រ័យលើដែនកំណត់ដែលបានកំណត់ ក៏ដូចជាការបិទកូតា CFS... Alas, ដែនកំណត់ស៊ីភីយូអាចបណ្តាលឱ្យមានបញ្ហាច្រើនជាងអ្វីដែលពួកគេអាចដោះស្រាយបាន។ ព័ត៌មានបន្ថែមអំពីរឿងនេះអាចរកបាននៅតំណខាងក្រោម។

ការជ្រើសរើសច្រើនពេក (ហួសចិត្ត) បញ្ហាការចងចាំអាចនាំឱ្យមានបញ្ហាធំ។ ការឈានដល់ដែនកំណត់នៃស៊ីភីយូ រួមបញ្ចូលការរំលងវដ្តនាឡិកា ខណៈពេលដែលការឈានដល់ដែនកំណត់នៃអង្គចងចាំនោះ នាំឱ្យសម្លាប់ផត។ តើអ្នកធ្លាប់សង្កេតទេ? OOMkill? បាទ នោះហើយជាអ្វីដែលយើងកំពុងនិយាយអំពី។

តើអ្នកចង់កាត់បន្ថយលទ្ធភាពនៃការកើតឡើងនេះទេ? កុំបែងចែកអង្គចងចាំច្រើនពេក ហើយប្រើការធានា QoS (គុណភាពនៃសេវាកម្ម) ដោយកំណត់សំណើអង្គចងចាំដល់ដែនកំណត់ (ដូចក្នុងឧទាហរណ៍ខាងក្រោម)។ សូមអានបន្ថែមអំពីរឿងនេះនៅក្នុង បទបង្ហាញ Henning Jacobs (ប្រធានវិស្វករ Zalando) ។

អាចផ្ទុះបាន។ (ឱកាសខ្ពស់ក្នុងការសម្លាប់ OOM)៖

   resources:
      requests:
        memory: "128Mi"
        cpu: "500m"
      limits:
        memory: "256Mi"
        cpu: 2

ធានា:

   resources:
      requests:
        memory: "128Mi"
        cpu: 2
      limits:
        memory: "128Mi"
        cpu: 2

តើអ្វីនឹងអាចជួយបានពេលបង្កើតធនធាន?

ដោយមានជំនួយពី ម៉ែត្រ - ម៉ាស៊ីនមេ អ្នកអាចឃើញការប្រើប្រាស់ធនធាន CPU បច្ចុប្បន្ន និងការប្រើប្រាស់អង្គចងចាំដោយផត (និងធុងផ្ទុកនៅខាងក្នុងពួកវា)។ ភាគច្រើន អ្នកកំពុងប្រើវារួចហើយ។ គ្រាន់តែដំណើរការពាក្យបញ្ជាខាងក្រោម៖

kubectl top pods
kubectl top pods --containers
kubectl top nodes

ទោះយ៉ាងណាក៏ដោយ ពួកគេបង្ហាញតែការប្រើប្រាស់បច្ចុប្បន្នប៉ុណ្ណោះ។ វាអាចផ្តល់ឱ្យអ្នកនូវគំនិតរដុបនៃលំដាប់នៃរ៉ិចទ័រប៉ុន្តែនៅទីបំផុតអ្នកនឹងត្រូវការ ប្រវត្តិនៃការផ្លាស់ប្តូររង្វាស់តាមពេលវេលា (ដើម្បីឆ្លើយសំណួរដូចជា៖ "តើការផ្ទុកស៊ីភីយូខ្ពស់បំផុតគឺជាអ្វី?", "តើអ្វីជាបន្ទុកកាលពីព្រឹកមិញ?" ។ល។) សម្រាប់ការនេះអ្នកអាចប្រើ Prometheus, DataDog និងឧបករណ៍ផ្សេងទៀត។ ពួកគេគ្រាន់តែទទួលបានម៉ែត្រពី metrics-server ហើយរក្សាទុកពួកវា ហើយអ្នកប្រើប្រាស់អាចសួរពួកគេ និងរៀបចំវាតាមតម្រូវការ។

VerticalPodAutoscaler វាអនុញ្ញាតឱ្យ ស្វ័យប្រវត្តិកម្ម ដំណើរការនេះ។ វាតាមដានប្រវត្តិការប្រើប្រាស់ស៊ីភីយូ និងអង្គចងចាំ ហើយកំណត់សំណើ និងដែនកំណត់ថ្មីដោយផ្អែកលើព័ត៌មាននេះ។

ការប្រើប្រាស់ថាមពលកុំព្យូទ័រប្រកបដោយប្រសិទ្ធភាពមិនមែនជាកិច្ចការងាយស្រួលនោះទេ។ វាដូចជាលេង Tetris គ្រប់ពេល។ ប្រសិនបើអ្នកកំពុងចំណាយច្រើនពេកសម្រាប់ថាមពលកុំព្យូទ័រជាមួយនឹងការប្រើប្រាស់ជាមធ្យមទាប (និយាយថា ~10%) យើងសូមណែនាំឱ្យមើលផលិតផលដែលមានមូលដ្ឋានលើ AWS Fargate ឬ Virtual Kubelet។ ពួកវាត្រូវបានបង្កើតឡើងនៅលើគំរូវិក្កយបត្រដែលមិនប្រើម៉ាស៊ីនមេ/បង់ប្រាក់ក្នុងមួយការប្រើប្រាស់ ដែលអាចប្រែទៅជាថោកជាងនៅក្នុងលក្ខខណ្ឌបែបនេះ។

2. ការស៊ើបអង្កេតភាពរស់រវើក និងការត្រៀមខ្លួន

តាមលំនាំដើម ការត្រួតពិនិត្យភាពរស់រវើក និងការត្រៀមខ្លួនមិនត្រូវបានបើកនៅក្នុង Kubernetes ទេ។ ហើយពេលខ្លះពួកគេភ្លេចបើក...

ប៉ុន្តែតើអ្នកអាចចាប់ផ្តើមសេវាកម្មឡើងវិញបានដោយរបៀបណា ក្នុងករណីមានកំហុសធ្ងន់ធ្ងរ? ហើយតើឧបករណ៍តុល្យភាពបន្ទុកដឹងដោយរបៀបណាថាផតបានត្រៀមខ្លួនជាស្រេចដើម្បីទទួលយកចរាចរណ៍? ឬថាវាអាចគ្រប់គ្រងចរាចរណ៍បានកាន់តែច្រើន?

ការធ្វើតេស្តទាំងនេះច្រើនតែច្រឡំជាមួយគ្នា៖

ភាពរស់រវើក - ការត្រួតពិនិត្យ "ការរស់រានមានជីវិត" ដែលចាប់ផ្តើមផតឡើងវិញប្រសិនបើវាបរាជ័យ។
ការត្រៀមខ្លួន។ - ពិនិត្យការត្រៀមខ្លួន ប្រសិនបើវាបរាជ័យ វានឹងផ្តាច់ pod ពីសេវាកម្ម Kubernetes (វាអាចត្រូវបានពិនិត្យដោយប្រើ kubectl get endpoints) ហើយចរាចរណ៍មិនមកដល់វាទេ រហូតដល់ការត្រួតពិនិត្យបន្ទាប់ត្រូវបានបញ្ចប់ដោយជោគជ័យ។

ការត្រួតពិនិត្យទាំងពីរនេះ។ អនុវត្តក្នុងអំឡុងពេលវដ្តជីវិតទាំងមូលនៃ POD. វាពិតជាសំខាន់ណាស់។

ការយល់ខុសជាទូទៅគឺថា ការស៊ើបអង្កេតការត្រៀមខ្លួនគឺដំណើរការតែនៅពេលចាប់ផ្តើមប៉ុណ្ណោះ ដើម្បីឱ្យសមតុល្យអាចដឹងថាផតគឺរួចរាល់ (Readyនិងអាចចាប់ផ្តើមដំណើរការចរាចរណ៍។ ទោះជាយ៉ាងណាក៏ដោយនេះគ្រាន់តែជាជម្រើសមួយក្នុងចំណោមជម្រើសសម្រាប់ការប្រើប្រាស់របស់ពួកគេ។

មួយទៀតគឺលទ្ធភាពនៃការរកឃើញថាចរាចរណ៍នៅលើ pod គឺលើសចំណុះនិង ផ្ទុកលើសទម្ងន់ (ឬ pod អនុវត្តការគណនាដែលពឹងផ្អែកខ្លាំងលើធនធាន) ។ ក្នុងករណីនេះការត្រួតពិនិត្យការត្រៀមខ្លួនជួយ កាត់បន្ថយការផ្ទុកនៅលើផើងហើយ "ត្រជាក់" វា។. ការបញ្ចប់ដោយជោគជ័យនៃការត្រួតពិនិត្យការត្រៀមខ្លួននាពេលអនាគតអនុញ្ញាត បង្កើនការផ្ទុកនៅលើ pod ម្តងទៀត. ក្នុងករណីនេះ (ប្រសិនបើការធ្វើតេស្តការត្រៀមខ្លួនបរាជ័យ) ការបរាជ័យនៃការធ្វើតេស្តភាពរស់រានមានជីវិតនឹងផ្ទុយគ្នាយ៉ាងខ្លាំង។ ហេតុអ្វីបានជាចាប់ផ្ដើមផតដែលមានសុខភាពល្អ និងខិតខំធ្វើការឡើងវិញ?

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

ការត្រួតពិនិត្យទាំងពីរប្រភេទមិនគួរបរាជ័យទេ នៅពេលដែលភាពអាស្រ័យទូទៅបរាជ័យ បើមិនដូច្នោះទេ វានឹងនាំឱ្យមានការបរាជ័យ (ដូចព្រិលទឹកកក) នៃផតឃែរទាំងអស់។ ក្នុងន័យផ្សេងទៀត, កុំធ្វើបាបខ្លួនឯង.

3. LoadBalancer សម្រាប់សេវា HTTP នីមួយៗ

ភាគច្រើន អ្នកមានសេវា HTTP នៅក្នុងចង្កោមរបស់អ្នក ដែលអ្នកចង់បញ្ជូនបន្តទៅកាន់ពិភពខាងក្រៅ។

ប្រសិនបើអ្នកបើកសេវាកម្មដូចជា type: LoadBalancerឧបករណ៍បញ្ជារបស់វា (អាស្រ័យលើអ្នកផ្តល់សេវា) នឹងផ្តល់ និងចរចារ LoadBalancer ខាងក្រៅ (មិនចាំបាច់ដំណើរការលើ L7 ទេ ប៉ុន្តែសូម្បីតែនៅលើ L4) ហើយវាអាចប៉ះពាល់ដល់ការចំណាយ (អាសយដ្ឋាន IPv4 ឋិតិវន្តខាងក្រៅ ថាមពលកុំព្យូទ័រ ការចេញវិក្កយបត្រក្នុងមួយវិនាទី។ ) ដោយសារតម្រូវការបង្កើតធនធានបែបនេះច្រើន។

ក្នុងករណីនេះ វាជាឡូជីខលជាងក្នុងការប្រើឧបករណ៍តុល្យភាពបន្ទុកខាងក្រៅមួយដោយការបើកសេវាកម្ម type: NodePort. ឬប្រសើរជាងនេះ ពង្រីកអ្វីមួយដូចជា nginx-ingress-controller (ឬ ត្រេហ្វិក) ដែលនឹងក្លាយជាតែមួយគត់ NodePort ចំណុចបញ្ចប់ដែលភ្ជាប់ជាមួយឧបករណ៍តុល្យភាពបន្ទុកខាងក្រៅ ហើយនឹងបញ្ជូនចរាចរក្នុងចង្កោមដោយប្រើ ចូល- ធនធាន Kubernetes ។

សេវាកម្មក្នុងក្រុម (មីក្រូ) ផ្សេងទៀតដែលមានអន្តរកម្មជាមួយគ្នាអាច "ទំនាក់ទំនង" ដោយប្រើសេវាកម្មដូចជា ClusterIP និងយន្តការស្វែងរកសេវាដែលភ្ជាប់មកជាមួយតាមរយៈ DNS ។ កុំប្រើ DNS/IP សាធារណៈរបស់ពួកគេ ព្រោះវាអាចប៉ះពាល់ដល់ភាពយឺតយ៉ាវ និងបង្កើនតម្លៃសេវាពពក។

4. ការធ្វើមាត្រដ្ឋានចង្កោមដោយស្វ័យប្រវត្តិដោយមិនគិតពីលក្ខណៈពិសេសរបស់វា។

នៅពេលបន្ថែមថ្នាំងទៅ និងយកពួកវាចេញពីចង្កោម អ្នកមិនគួរពឹងផ្អែកលើការវាស់វែងជាមូលដ្ឋានមួយចំនួនដូចជាការប្រើប្រាស់ស៊ីភីយូនៅលើថ្នាំងទាំងនោះនោះទេ។ ការធ្វើផែនការ Pod ត្រូវតែយកទៅក្នុងគណនីជាច្រើន។ ការរឹតត្បិតដូចជាភាពស្និទ្ធស្នាលរបស់ pod/node, taints និងការអត់ឱន, សំណើធនធាន, QoS ជាដើម។ ការប្រើឧបករណ៍វាស់ស្ទង់ស្វ័យប្រវត្តខាងក្រៅដែលមិនគិតគូរពីភាពខុសប្រក្រតីទាំងនេះអាចនាំឱ្យមានបញ្ហា។

ស្រមៃថាផតជាក់លាក់មួយគួរតែត្រូវបានកំណត់ពេល ប៉ុន្តែថាមពលស៊ីភីយូដែលមានទាំងអស់ត្រូវបានស្នើសុំ/ផ្តាច់ និងផត ជាប់គាំងនៅក្នុងរដ្ឋមួយ។ Pending. ឧបករណ៍ពង្រីកស្វ័យប្រវត្តិខាងក្រៅមើលឃើញការផ្ទុកស៊ីភីយូបច្ចុប្បន្នជាមធ្យម (មិនមែនជាការស្នើសុំ) ហើយមិនចាប់ផ្តើមការពង្រីកទេ។ (ពង្រីក) - មិនបន្ថែមថ្នាំងផ្សេងទៀត។ ជាលទ្ធផល ផតនេះនឹងមិនត្រូវបានកំណត់ពេលទេ។

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

ពេញនិយមយ៉ាងខ្លាំងនៅក្នុងសហគមន៍ Kubernetes cluster-autoscaler. វាដំណើរការលើចង្កោម គាំទ្រ APIs ពីអ្នកផ្តល់សេវាពពកធំៗ ពិចារណាលើការរឹតបន្តឹងទាំងអស់ និងអាចធ្វើមាត្រដ្ឋាននៅក្នុងករណីខាងលើ។ វាក៏អាចធ្វើមាត្រដ្ឋានបានផងដែរ ខណៈពេលដែលរក្សាដែនកំណត់ដែលបានកំណត់ទាំងអស់ ដោយហេតុនេះការសន្សំប្រាក់ (ដែលនឹងត្រូវចំណាយលើសមត្ថភាពដែលមិនប្រើ)។

5. ការធ្វេសប្រហែសសមត្ថភាព IAM/RBAC

ប្រយ័ត្នចំពោះការប្រើប្រាស់អ្នកប្រើប្រាស់ IAM ជាមួយនឹងអាថ៌កំបាំងជាប់លាប់សម្រាប់ ម៉ាស៊ីននិងកម្មវិធី. រៀបចំការចូលប្រើបណ្តោះអាសន្នដោយប្រើតួនាទី និងគណនីសេវាកម្ម (គណនីសេវាកម្ម).

ជារឿយៗយើងជួបប្រទះនឹងការពិតដែលថាសោចូលដំណើរការ (និងអាថ៌កំបាំង) ត្រូវបានសរសេរកូដរឹងនៅក្នុងការកំណត់រចនាសម្ព័ន្ធកម្មវិធី ក៏ដូចជាការធ្វេសប្រហែសចំពោះការបង្វិលនៃអាថ៌កំបាំង បើទោះបីជាមានការចូលប្រើ Cloud IAM ក៏ដោយ។ ប្រើតួនាទី IAM និងគណនីសេវាកម្មជំនួសឱ្យអ្នកប្រើប្រាស់តាមដែលសមរម្យ។

ភ្លេចអំពី kube2iam ហើយទៅត្រង់ទៅតួនាទី IAM សម្រាប់គណនីសេវាកម្ម (ដូចដែលបានពិពណ៌នានៅក្នុង ចំណាំនៃឈ្មោះដូចគ្នា។ Štěpán Vraný)៖

apiVersion: v1
kind: ServiceAccount
metadata:
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::123456789012:role/my-app-role
  name: my-serviceaccount
  namespace: default

ចំណារពន្យល់មួយ។ មិនពិបាកទេមែនទេ?

ដូចគ្នានេះផងដែរ កុំផ្តល់សិទ្ធិដល់គណនីសេវាកម្ម និងកម្រងព័ត៌មាន admin и cluster-adminប្រសិនបើពួកគេមិនត្រូវការវា។ នេះពិបាកជាងបន្តិចក្នុងការអនុវត្ត ជាពិសេសនៅក្នុង RBAC K8s ប៉ុន្តែពិតជាមានប្រយោជន៍។

6. កុំពឹងផ្អែកលើការប្រឆាំងដោយស្វ័យប្រវត្តិសម្រាប់ផត

ស្រមៃថាអ្នកមានការចម្លងចំនួនបីនៃការដាក់ពង្រាយមួយចំនួននៅលើថ្នាំងមួយ។ ថ្នាំងធ្លាក់ហើយរួមជាមួយវាទាំងអស់ចម្លង។ ស្ថានភាពមិនល្អមែនទេ? ប៉ុន្តែហេតុអ្វីបានជាការចម្លងទាំងអស់នៅលើថ្នាំងដូចគ្នា? តើ Kubernetes គួរតែផ្តល់នូវភាពអាចរកបានខ្ពស់ (HA) មែនទេ?!

ជាអកុសល កម្មវិធីកំណត់ពេល Kubernetes តាមគំនិតផ្តួចផ្តើមរបស់ខ្លួន មិនគោរពតាមច្បាប់នៃអត្ថិភាពដាច់ដោយឡែក (ការប្រឆាំងភាពស្និទ្ធស្នាល) សម្រាប់ pods ។ ពួកគេត្រូវតែបញ្ជាក់យ៉ាងច្បាស់៖

// опущено для краткости
      labels:
        app: zk
// опущено для краткости
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            - labelSelector:
                matchExpressions:
                  - key: "app"
                    operator: In
                    values:
                    - zk
              topologyKey: "kubernetes.io/hostname"

អស់ហើយ។ ឥឡូវនេះ pods នឹងត្រូវបានកំណត់ពេលនៅលើថ្នាំងផ្សេងគ្នា (លក្ខខណ្ឌនេះត្រូវបានត្រួតពិនិត្យតែក្នុងអំឡុងពេលកំណត់ពេលវេលា ប៉ុន្តែមិនមែនក្នុងអំឡុងពេលប្រតិបត្តិការរបស់ពួកគេទេ - ហេតុដូច្នេះហើយ requiredDuringSchedulingIgnoredDuringExecution).

នៅទីនេះយើងកំពុងនិយាយអំពី podAntiAffinity នៅលើថ្នាំងផ្សេងៗគ្នា៖ topologyKey: "kubernetes.io/hostname", - ហើយមិនមែនអំពីតំបន់ដែលអាចរកបានផ្សេងគ្នាទេ។ ដើម្បីអនុវត្ត HA ពេញលេញ អ្នកនឹងត្រូវស្វែងយល់ឱ្យកាន់តែស៊ីជម្រៅទៅក្នុងប្រធានបទនេះ។

7. មិនអើពើ PodDisruptionBudgets

ស្រមៃថាអ្នកមានបន្ទុកផលិតកម្មនៅលើចង្កោម Kubernetes ។ តាមកាលកំណត់ ថ្នាំង និងចង្កោមខ្លួនឯងត្រូវតែធ្វើបច្ចុប្បន្នភាព (ឬបញ្ឈប់) ។ PodDisruptionBudget (PDB) គឺជាអ្វីមួយដូចជាកិច្ចព្រមព្រៀងធានាសេវាកម្មរវាងអ្នកគ្រប់គ្រងចង្កោម និងអ្នកប្រើប្រាស់។

PDB អនុញ្ញាតឱ្យអ្នកជៀសវាងការរំខានសេវាកម្មដែលបណ្តាលមកពីកង្វះថ្នាំង៖

apiVersion: policy/v1beta1
kind: PodDisruptionBudget
metadata:
  name: zk-pdb
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: zookeeper

ក្នុងឧទាហរណ៍នេះ អ្នកក្នុងនាមជាអ្នកប្រើចង្កោម សូមថ្លែងទៅកាន់អ្នកគ្រប់គ្រង៖ "ហេ ខ្ញុំមានសេវាអ្នកថែសួនសត្វ ហើយមិនថាអ្នកធ្វើយ៉ាងណាទេ ខ្ញុំចង់មានសេវាកម្មចម្លងយ៉ាងហោចណាស់ 2 នេះជានិច្ច"។

អ្នកអាចអានបន្ថែមអំពីរឿងនេះ នៅទីនេះ.

8. អ្នកប្រើប្រាស់ច្រើន ឬបរិស្ថាននៅក្នុងចង្កោមទូទៅមួយ។

ចន្លោះឈ្មោះ Kubernetes (ចន្លោះឈ្មោះ) មិនផ្តល់អ៊ីសូឡង់រឹងមាំ.

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

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

9. គោលការណ៍ចរាចរណ៍ខាងក្រៅ៖ ចង្កោម

ជាញឹកញាប់យើងឃើញថាចរាចរណ៍ទាំងអស់នៅក្នុងចង្កោមកើតឡើងតាមរយៈសេវាកម្មដូចជា NodePort ដែលគោលការណ៍លំនាំដើមត្រូវបានកំណត់ externalTrafficPolicy: Cluster... វាមានន័យថា NodePort បើកនៅលើគ្រប់ថ្នាំងក្នុងចង្កោម ហើយអ្នកអាចប្រើពួកវាណាមួយដើម្បីធ្វើអន្តរកម្មជាមួយសេវាកម្មដែលចង់បាន (សំណុំនៃផត)។

ក្នុងពេលជាមួយគ្នានេះ ផតថលពិតប្រាកដដែលទាក់ទងនឹងសេវាកម្ម NodePort ដែលបានរៀបរាប់ខាងលើ ជាធម្មតាអាចប្រើបានតែលើសេវាជាក់លាក់មួយប៉ុណ្ណោះ។ សំណុំរងនៃថ្នាំងទាំងនេះ. ម្យ៉ាងវិញទៀត ប្រសិនបើខ្ញុំភ្ជាប់ទៅ node ដែលមិនមាន pod ដែលត្រូវការ វានឹងបញ្ជូន traffic ទៅ node ផ្សេងទៀត ការបន្ថែមហប និងការបង្កើនភាពយឺតយ៉ាវ (ប្រសិនបើថ្នាំងស្ថិតនៅក្នុងតំបន់ដែលអាចរកបាន/មជ្ឈមណ្ឌលទិន្នន័យផ្សេងៗគ្នា ភាពយឺតយ៉ាវអាចខ្ពស់ណាស់ លើសពីនេះ ថ្លៃដើមចរាចរនឹងកើនឡើង)។

ម្យ៉ាងវិញទៀត ប្រសិនបើសេវាកម្ម Kubernetes ជាក់លាក់មួយមានគោលការណ៍កំណត់ externalTrafficPolicy: Localបន្ទាប់មក NodePort បើកតែលើថ្នាំងទាំងនោះដែល pods ដែលត្រូវការពិតជាកំពុងដំណើរការ។ នៅពេលប្រើឧបករណ៍តុល្យភាពបន្ទុកខាងក្រៅដែលពិនិត្យស្ថានភាព (ការពិនិត្យសុខភាព) ចំណុចបញ្ចប់ (តើវាធ្វើដូចម្តេច AWS ELB) គាត់ នឹងបញ្ជូនចរាចរណ៍ទៅថ្នាំងចាំបាច់តែប៉ុណ្ណោះដែលនឹងមានឥទ្ធិពលជន៍លើការពន្យារពេល តម្រូវការក្នុងការគណនា វិក័យប័ត្រចេញ (និងសុភវិនិច្ឆ័យកំណត់ដូចគ្នា)។

មានឱកាសខ្ពស់ដែលអ្នកកំពុងប្រើអ្វីមួយដូចជា ត្រេហ្វិក ឬ nginx-ingress-controller ជាចំណុចបញ្ចប់ NodePort (ឬ LoadBalancer ដែលប្រើ NodePort ផងដែរ) ដើម្បីបញ្ជូនចរាចរចូល HTTP ហើយការកំណត់ជម្រើសនេះអាចកាត់បន្ថយភាពយឺតយ៉ាវសម្រាប់សំណើបែបនេះ។

В ការបោះពុម្ពផ្សាយនេះ។ អ្នកអាចស្វែងយល់បន្ថែមអំពី ExternalTrafficPolicy គុណសម្បត្តិ និងគុណវិបត្តិរបស់វា។

10. កុំចងជាប់នឹងចង្កោម ហើយកុំបំពានលើយន្តហោះបញ្ជា

កាលពីមុន វាជាទម្លាប់ក្នុងការហៅម៉ាស៊ីនមេតាមឈ្មោះត្រឹមត្រូវ៖ លោក Anton, HAL9000 និង Colossus... សព្វថ្ងៃនេះពួកគេត្រូវបានជំនួសដោយឧបករណ៍កំណត់អត្តសញ្ញាណដែលបានបង្កើតដោយចៃដន្យ។ ទោះយ៉ាងណាក៏ដោយ ទំលាប់នៅតែមាន ហើយឥឡូវនេះឈ្មោះត្រឹមត្រូវទៅចង្កោម។

រឿងធម្មតា (ផ្អែកលើព្រឹត្តិការណ៍ពិត)៖ វាទាំងអស់បានចាប់ផ្តើមដោយភស្តុតាងនៃគំនិត ដូច្នេះចង្កោមមានឈ្មោះមោទនភាព ការធ្វើតេស្ត… ជាច្រើនឆ្នាំបានកន្លងផុតទៅហើយ ហើយវានៅតែត្រូវបានប្រើប្រាស់ក្នុងផលិតកម្ម ហើយគ្រប់គ្នាខ្លាចប៉ះវា។

មិនមានអ្វីសប្បាយទេអំពីចង្កោមដែលប្រែទៅជាសត្វចិញ្ចឹម ដូច្នេះយើងសូមណែនាំឱ្យដកពួកវាចេញជាប្រចាំ ខណៈពេលកំពុងអនុវត្ត ការសង្គ្រោះគ្រោះមហន្តរាយ (នេះនឹងជួយ វិស្វកម្មវឹកវរ - ប្រហែល បកប្រែ។ ). លើសពីនេះទៀតវានឹងមិនឈឺចាប់ក្នុងការដំណើរការលើស្រទាប់ត្រួតពិនិត្យទេ។ (យន្តហោះគ្រប់គ្រង). ការភ័យខ្លាចក្នុងការប៉ះគាត់មិនមែនជាសញ្ញាល្អទេ។ ល។ ស្លាប់? បុរសអ្នកពិតជាមានបញ្ហា!

ម៉្យាងវិញទៀត អ្នកមិនគួរយកវាទៅបញ្ឆោតឡើយ។ ជាមួយនឹងពេលវេលា ស្រទាប់ត្រួតពិនិត្យអាចយឺត. ភាគច្រើនទំនងជានេះគឺដោយសារតែវត្ថុមួយចំនួនធំត្រូវបានបង្កើតដោយគ្មានការបង្វិលរបស់វា (ស្ថានភាពទូទៅនៅពេលប្រើ Helm ជាមួយនឹងការកំណត់លំនាំដើម ដែលជាមូលហេតុដែលស្ថានភាពរបស់វានៅក្នុង configmaps/secrets មិនត្រូវបានធ្វើបច្ចុប្បន្នភាព - ជាលទ្ធផល វត្ថុរាប់ពាន់បានប្រមូលផ្តុំនៅក្នុង ស្រទាប់វត្ថុបញ្ជា) ឬជាមួយនឹងការកែសម្រួលថេរនៃវត្ថុ kube-api (សម្រាប់ការធ្វើមាត្រដ្ឋានដោយស្វ័យប្រវត្តិ សម្រាប់ CI/CD សម្រាប់ការត្រួតពិនិត្យ កំណត់ហេតុព្រឹត្តិការណ៍ ឧបករណ៍បញ្ជា។ល។)។

លើសពីនេះ យើងសូមណែនាំឱ្យពិនិត្យមើលកិច្ចព្រមព្រៀង SLA/SLO ជាមួយអ្នកផ្តល់សេវា Kubernetes ដែលបានគ្រប់គ្រង ហើយយកចិត្តទុកដាក់លើការធានា។ អ្នកលក់អាចធានាបាន។ ការគ្រប់គ្រងភាពអាចរកបាននៃស្រទាប់ (ឬសមាសធាតុរងរបស់វា) ប៉ុន្តែមិនមែនជាការពន្យារពេល p99 នៃសំណើដែលអ្នកផ្ញើទៅវានោះទេ។ នៅក្នុងពាក្យផ្សេងទៀតអ្នកអាចចូល kubectl get nodesហើយទទួលបានចម្លើយបន្ទាប់ពី 10 នាទីប៉ុណ្ណោះ ហើយនេះនឹងមិនជាការបំពានលើលក្ខខណ្ឌនៃកិច្ចព្រមព្រៀងសេវាកម្មនោះទេ។

11. ប្រាក់រង្វាន់៖ ដោយប្រើស្លាកចុងក្រោយបំផុត។

ប៉ុន្តែនេះគឺជាបុរាណរួចទៅហើយ។ ថ្មីៗនេះ យើងបានឆ្លងកាត់បច្ចេកទេសនេះមិនសូវជាញឹកញាប់ទេ ដោយសារមនុស្សជាច្រើនបានរៀនពីបទពិសោធន៍ដ៏ជូរចត់ បានឈប់ប្រើស្លាក :latest ហើយបានចាប់ផ្តើមខ្ទាស់កំណែ។ ហ៊ឺយ!

ECR រក្សាភាពមិនប្រែប្រួលនៃស្លាករូបភាព; យើងណែនាំអ្នកឱ្យស្គាល់ខ្លួនអ្នកជាមួយនឹងមុខងារដ៏គួរឱ្យកត់សម្គាល់នេះ។

សង្ខេប

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

អ្នកអាចស្គាល់ពីបទពិសោធន៍មិនជោគជ័យរបស់ក្រុមផ្សេងៗនៅក្នុង ការប្រមូលផ្ដុំនៃរឿងរ៉ាវនេះ។ ដោយ Henning Jacobs។

អ្នកដែលចង់បន្ថែមទៅក្នុងបញ្ជីនៃកំហុសដែលបានផ្ដល់ឱ្យក្នុងអត្ថបទនេះអាចទាក់ទងមកយើងនៅលើ Twitter (@MarekBartik, @MstrsObserver).

PS ពីអ្នកបកប្រែ

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

ប្រភព: www.habr.com

កំហុសទូទៅ 10 នៅពេលប្រើ Kubernetes