ជួសជុលរន្ធនៅក្នុងចង្កោម Kubernetes ។ រាយការណ៍ និងប្រតិចារឹកពី DevOpsConf

Pavel Selivanov ស្ថាបត្យករដំណោះស្រាយ Southbridge និងជាគ្រូបង្រៀន Slurm បានធ្វើបទបង្ហាញនៅ DevOpsConf 2019។ ការពិភាក្សានេះគឺជាផ្នែកមួយនៃប្រធានបទនៃវគ្គសិក្សាស៊ីជម្រៅលើ Kubernetes "Slurm Mega" ។

Slurm Basic៖ ការណែនាំអំពី Kubernetes ប្រព្រឹត្តទៅនៅទីក្រុងម៉ូស្គូ ថ្ងៃទី 18-20 ខែវិច្ឆិកា។
Slurm Mega: សម្លឹងមើលក្រោមក្រណាត់របស់ Kubernetes — ទីក្រុងម៉ូស្គូ ថ្ងៃទី ២២-២៤ ខែវិច្ឆិកា។
Slurm Online៖ វគ្គសិក្សា Kubernetes ទាំងពីរ តែងតែមាន។

ខាងក្រោមការកាត់គឺជាប្រតិចារិកនៃរបាយការណ៍។

អរុណសួស្តីមិត្តរួមការងារ និងអ្នកដែលអាណិតពួកគេ។ ថ្ងៃនេះខ្ញុំនឹងនិយាយអំពីសុវត្ថិភាព។

ខ្ញុំ​ឃើញ​ថា​មាន​សន្តិសុខ​ច្រើន​នៅ​ក្នុង​សាល​សព្វ​ថ្ងៃ។ ខ្ញុំសុំទោសអ្នកជាមុន ប្រសិនបើខ្ញុំប្រើពាក្យពីពិភពសុវត្ថិភាពមិនពិតប្រាកដដូចទម្លាប់សម្រាប់អ្នក។

វាបានកើតឡើងដូច្នេះប្រហែលប្រាំមួយខែមុនខ្ញុំបានឆ្លងកាត់ចង្កោម Kubernetes សាធារណៈមួយ។ សាធារណៈមានន័យថាមានចំនួន nth នៃ namespaces; នៅក្នុង namespaces ទាំងនេះមានអ្នកប្រើប្រាស់ដាច់ដោយឡែកនៅក្នុង namespace របស់ពួកគេ។ អ្នកប្រើប្រាស់ទាំងអស់នេះជាកម្មសិទ្ធិរបស់ក្រុមហ៊ុនផ្សេងៗគ្នា។ ជាការប្រសើរណាស់, វាត្រូវបានគេសន្មត់ថាចង្កោមនេះគួរតែត្រូវបានប្រើជា CDN ។ នោះគឺពួកគេផ្តល់ឱ្យអ្នកនូវចង្កោមមួយ ពួកគេផ្តល់ឱ្យអ្នកនូវអ្នកប្រើប្រាស់នៅទីនោះ អ្នកទៅទីនោះទៅកាន់ namespace របស់អ្នក ដាក់ពង្រាយផ្នែកខាងមុខរបស់អ្នក។

ក្រុមហ៊ុនមុនរបស់ខ្ញុំបានព្យាយាមលក់សេវាកម្មបែបនេះ។ ហើយ​ខ្ញុំ​ត្រូវ​បាន​គេ​សួរ​ឱ្យ​ចុច​ចង្កោម​ដើម្បី​មើល​ថា​តើ​ដំណោះស្រាយ​នេះ​សមស្រប​ឬ​អត់។

ខ្ញុំបានមកក្រុមនេះ។ ខ្ញុំ​ត្រូវ​បាន​ផ្តល់​សិទ្ធិ​មាន​កំណត់ ចន្លោះ​ឈ្មោះ​មាន​កំណត់។ បុរសនៅទីនោះយល់ថាសុវត្ថិភាពជាអ្វី។ ពួកគេបានអានអំពីការគ្រប់គ្រងការចូលប្រើប្រាស់ដោយផ្អែកលើតួនាទី (RBAC) នៅក្នុង Kubernetes ហើយពួកគេបានបង្វិលវា ដូច្នេះខ្ញុំមិនអាចបើកដំណើរការ pods ដាច់ដោយឡែកពីការដាក់ពង្រាយបានទេ។ ខ្ញុំ​មិន​ចាំ​ថា​បញ្ហា​ដែល​ខ្ញុំ​កំពុង​ព្យាយាម​ដោះស្រាយ​ដោយ​ការ​បើក​ដំណើរការ​ pod មួយ​ដោយ​មិន​មាន​ការ​ដាក់​ពង្រាយ​នោះ​ទេ ប៉ុន្តែ​ខ្ញុំ​ពិត​ជា​ចង់​បើក​ដំណើរការ​គ្រាន់​តែ​ pod ប៉ុណ្ណោះ។ ដើម្បីសំណាងល្អ ខ្ញុំបានសម្រេចចិត្តមើលថាតើខ្ញុំមានសិទ្ធិអ្វីខ្លះនៅក្នុងចង្កោម អ្វីដែលខ្ញុំអាចធ្វើបាន អ្វីដែលខ្ញុំមិនអាចធ្វើបាន និងអ្វីដែលពួកគេបានធ្វើនៅទីនោះ។ ក្នុងពេលជាមួយគ្នានេះ ខ្ញុំនឹងប្រាប់អ្នកពីអ្វីដែលពួកគេបានកំណត់រចនាសម្ព័ន្ធមិនត្រឹមត្រូវនៅក្នុង RBAC។

វាបានកើតឡើងដូច្នេះថាក្នុងរយៈពេលពីរនាទីខ្ញុំបានទទួលអ្នកគ្រប់គ្រងទៅចង្កោមរបស់ពួកគេ ក្រឡេកមើលកន្លែងដាក់ឈ្មោះជិតខាងទាំងអស់ បានឃើញនៅទីនោះនូវផ្នែកផលិតកម្មដែលកំពុងដំណើរការនៃក្រុមហ៊ុនដែលបានទិញសេវាកម្មរួចហើយ និងដាក់ពង្រាយ។ ខ្ញុំស្ទើរតែមិនអាចបញ្ឈប់ខ្លួនឯងពីការចូលទៅមុខនរណាម្នាក់ ហើយដាក់ពាក្យស្បថមួយចំនួននៅលើទំព័រមេ។

ខ្ញុំនឹងប្រាប់អ្នកជាមួយនឹងឧទាហរណ៍អំពីរបៀបដែលខ្ញុំបានធ្វើរឿងនេះ និងរបៀបការពារខ្លួនអ្នកពីរឿងនេះ។

ប៉ុន្តែជាដំបូងខ្ញុំសូមណែនាំខ្លួនខ្ញុំ។ ឈ្មោះរបស់ខ្ញុំគឺ Pavel Selivanov ។ ខ្ញុំជាស្ថាបត្យករនៅ Southbridge ។ ខ្ញុំយល់អំពី Kubernetes, DevOps និងប្រភេទទាំងអស់នៃរឿងប្រឌិត។ វិស្វករ Southbridge និងខ្ញុំកំពុងសាងសង់ទាំងអស់នេះ ហើយខ្ញុំកំពុងប្រឹក្សា។

បន្ថែមពីលើសកម្មភាពសំខាន់ៗរបស់យើង ថ្មីៗនេះយើងបានចាប់ផ្តើមគម្រោងដែលហៅថា Slurms។ យើងកំពុងព្យាយាមនាំយកសមត្ថភាពរបស់យើងក្នុងការធ្វើការជាមួយ Kubernetes បន្តិចទៅកាន់មហាជន ដើម្បីបង្រៀនមនុស្សផ្សេងទៀតឱ្យធ្វើការជាមួយ K8s ផងដែរ។

តើថ្ងៃនេះខ្ញុំនឹងនិយាយអំពីអ្វី? ប្រធានបទនៃរបាយការណ៍គឺជាក់ស្តែង - អំពីសុវត្ថិភាពនៃចង្កោម Kubernetes ។ ប៉ុន្តែខ្ញុំចង់និយាយភ្លាមៗថាប្រធានបទនេះមានទំហំធំណាស់ - ដូច្នេះហើយខ្ញុំចង់បញ្ជាក់ភ្លាមៗនូវអ្វីដែលខ្ញុំនឹងមិននិយាយអំពី។ ខ្ញុំនឹងមិននិយាយអំពីពាក្យ hackneyed ដែលត្រូវបានប្រើប្រាស់មួយរយដងនៅលើអ៊ីនធឺណិតទេ។ គ្រប់ប្រភេទនៃ RBAC និងវិញ្ញាបនបត្រ។

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

មានបីចំណុចដែលខ្ញុំនឹងនិយាយនៅថ្ងៃនេះ៖

1. សិទ្ធិអ្នកប្រើប្រាស់ទល់នឹងសិទ្ធិផត។ សិទ្ធិអ្នកប្រើប្រាស់ និងសិទ្ធិផត គឺមិនដូចគ្នាទេ។
2. ការប្រមូលព័ត៌មានអំពីចង្កោម។ ខ្ញុំនឹងបង្ហាញថាអ្នកអាចប្រមូលព័ត៌មានទាំងអស់ដែលអ្នកត្រូវការពីចង្កោមដោយមិនមានសិទ្ធិពិសេសនៅក្នុងចង្កោមនេះ។
3. ការវាយប្រហារ DoS លើចង្កោម។ ប្រសិនបើយើងមិនអាចប្រមូលព័ត៌មានបានទេ យើងនឹងអាចដាក់ចង្កោមនៅក្នុងករណីណាមួយ។ ខ្ញុំនឹងនិយាយអំពីការវាយប្រហារ DoS លើធាតុគ្រប់គ្រងចង្កោម។

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

យើងយកជាមូលដ្ឋាននៃការដំឡើងចង្កោម Kubernetes ដោយប្រើ Kubespray ។ ប្រសិនបើនរណាម្នាក់មិនដឹង នេះពិតជាសំណុំនៃតួនាទីសម្រាប់ Ansible ។ យើងប្រើវាជានិច្ចនៅក្នុងការងាររបស់យើង។ រឿងល្អគឺថាអ្នកអាចរមៀលវាគ្រប់ទីកន្លែង - អ្នកអាចរមៀលវានៅលើបំណែកដែកឬចូលទៅក្នុងពពកនៅកន្លែងណាមួយ។ វិធីសាស្រ្តដំឡើងមួយដំណើរការជាគោលការណ៍សម្រាប់អ្វីគ្រប់យ៉ាង។

នៅក្នុងចង្កោមនេះ ខ្ញុំនឹងមាន Kubernetes v1.14.5 ។ ចង្កោម Cube ទាំងមូលដែលយើងនឹងពិចារណាត្រូវបានបែងចែកទៅជា namespaces នីមួយៗ namespace ជាកម្មសិទ្ធិរបស់ក្រុមដាច់ដោយឡែក ហើយសមាជិកនៃក្រុមនេះមានសិទ្ធិចូលទៅកាន់ namespace នីមួយៗ។ ពួកគេមិនអាចទៅកន្លែងដាក់ឈ្មោះផ្សេងគ្នាបានឡើយ មានតែពួកគេប៉ុណ្ណោះ។ ប៉ុន្តែមានគណនីគ្រប់គ្រងជាក់លាក់មួយដែលមានសិទ្ធិសម្រាប់ចង្កោមទាំងមូល។

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

kubectl apply -f pod.yaml

ផតនេះនឹងទៅដល់ចៅហ្វាយនាយម្នាក់នៃក្រុម Kubernetes ។ ហើយបន្ទាប់ពីនេះ ចង្កោមនឹងត្រលប់មកយើងវិញដោយរីករាយនូវឯកសារមួយដែលមានឈ្មោះថា admin.conf ។ នៅក្នុង Cube ឯកសារនេះរក្សាទុកវិញ្ញាបនបត្រអ្នកគ្រប់គ្រងទាំងអស់ ហើយក្នុងពេលតែមួយកំណត់រចនាសម្ព័ន្ធ API របស់ចង្កោម។ នេះ​ជា​វិធី​ងាយ​ស្រួល​ក្នុង​ការ​ទទួល​បាន​ការ​ចូល​ប្រើ​ជា​អ្នក​គ្រប់គ្រង​ ខ្ញុំ​គិត​ថា 98% នៃ​ក្រុម Kubernetes ។

ខ្ញុំនិយាយម្តងទៀត ផតនេះត្រូវបានធ្វើឡើងដោយអ្នកអភិវឌ្ឍន៍ម្នាក់នៅក្នុងចង្កោមរបស់អ្នកដែលមានសិទ្ធិប្រើប្រាស់ដើម្បីដាក់ពង្រាយសំណើរបស់គាត់ទៅក្នុងលំហឈ្មោះតូចមួយ វាត្រូវបានបិទដោយ RBAC ។ គាត់គ្មានសិទ្ធិទេ។ ប៉ុន្តែយ៉ាងណាក៏ដោយ វិញ្ញាបនបត្រត្រូវបានប្រគល់មកវិញ។

ហើយឥឡូវនេះអំពី pod បានរៀបចំពិសេស។ យើងដំណើរការវានៅលើរូបភាពណាមួយ។ ចូរយក debian:jessie ជាឧទាហរណ៍។

យើងមានរបស់នេះ៖

tolerations:
-   effect: NoSchedule 
    operator: Exists 
nodeSelector: 
    node-role.kubernetes.io/master: "" 

តើការអត់ឱនជាអ្វី? ថ្នាក់អនុបណ្ឌិតនៅក្នុងចង្កោម Kubernetes ជាធម្មតាត្រូវបានសម្គាល់ដោយអ្វីដែលហៅថា taint ។ ហើយខ្លឹមសារនៃ "ការឆ្លងមេរោគ" នេះគឺថាវានិយាយថា pods មិនអាចត្រូវបានកំណត់ទៅថ្នាំងមេ។ ប៉ុន្តែគ្មាននរណាម្នាក់រំខានក្នុងការចង្អុលបង្ហាញនៅក្នុងផើងណាមួយថាវាអត់ធ្មត់ចំពោះ "ការឆ្លងមេរោគ" នោះទេ។ ផ្នែកអត់ឱនគ្រាន់តែនិយាយថាប្រសិនបើថ្នាំងមួយចំនួនមាន NoSchedule នោះថ្នាំងរបស់យើងគឺអត់ឱនចំពោះការឆ្លងមេរោគបែបនេះ - ហើយវាមិនមានបញ្ហាអ្វីទេ។

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

ជាមួយនឹងផ្នែកទាំងពីរនេះ គាត់ប្រាកដជានឹងមករកមេ។ ហើយគាត់នឹងត្រូវបានអនុញ្ញាតឱ្យរស់នៅទីនោះ។

ប៉ុន្តែ​គ្រាន់​តែ​មក​រក​មេ​មិន​គ្រប់​គ្រាន់​សម្រាប់​យើង​ទេ។ នេះនឹងមិនផ្តល់ឱ្យយើងនូវអ្វីទាំងអស់។ ដូច្នេះបន្ទាប់ យើងមានរឿងពីរនេះ៖

hostNetwork: true 
hostPID: true 

យើង​បញ្ជាក់​ថា​ផត​របស់​យើង​ដែល​យើង​បើក​ដំណើរការ​នឹង​រស់​នៅ​ក្នុង​ចន្លោះ​ឈ្មោះ​ខឺណែល ក្នុង​ចន្លោះ​ឈ្មោះ​បណ្ដាញ និង​ក្នុង​ចន្លោះ​ឈ្មោះ PID ។ នៅពេលដែលផតត្រូវបានបើកដំណើរការនៅលើមេ វានឹងអាចមើលឃើញចំណុចប្រទាក់ជាក់ស្តែងទាំងអស់របស់ថ្នាំងនេះ ស្តាប់ចរាចរណ៍ទាំងអស់ និងមើល PID នៃដំណើរការទាំងអស់។

បន្ទាប់មកវាជារឿងតូចតាច។ យក etcd ហើយអានអ្វីដែលអ្នកចង់បាន។

អ្វីដែលគួរឱ្យចាប់អារម្មណ៍បំផុតគឺលក្ខណៈពិសេស Kubernetes ដែលមានវត្តមាននៅទីនោះតាមលំនាំដើម។

volumeMounts:
- mountPath: /host 
  name: host 
volumes:
- hostPath: 
    path: / 
    type: Directory 
  name: host 

ហើយខ្លឹមសាររបស់វាគឺថាយើងអាចនិយាយបាននៅក្នុងផតថា យើងបើកដំណើរការ ទោះបីជាគ្មានសិទ្ធិចំពោះចង្កោមនេះក៏ដោយ ដែលយើងចង់បង្កើតបរិមាណនៃប្រភេទ hostPath ។ នេះមានន័យថាយកផ្លូវពីម៉ាស៊ីនដែលយើងនឹងបើកដំណើរការ ហើយយកវាជាកម្រិតសំឡេង។ ហើយបន្ទាប់មកយើងហៅវាថាជាម្ចាស់ផ្ទះ។ យើងភ្ជាប់ hostPath ទាំងមូលនេះនៅខាងក្នុងផត។ ក្នុងឧទាហរណ៍នេះទៅកាន់ /host directory.

ខ្ញុំនឹងនិយាយម្តងទៀត។ យើងបានប្រាប់ pod ឱ្យមកមេ យក hostNetwork និង hostPID នៅទីនោះ ហើយភ្ជាប់ root ទាំងមូលរបស់ master នៅខាងក្នុង pod នេះ។

អ្នកយល់ថានៅក្នុង Debian យើងមាន bash ដំណើរការ ហើយ bash នេះដំណើរការនៅក្រោម root ។ នោះ​គឺ​យើង​ទើប​តែ​ទទួល​បាន​ឫសគល់​លើ​មេ ដោយ​មិន​មាន​សិទ្ធិ​ក្នុង​ចង្កោម Kubernetes ទេ។

បន្ទាប់មកភារកិច្ចទាំងមូលគឺត្រូវចូលទៅកាន់ថតរង /host /etc/kubernetes/pki ប្រសិនបើខ្ញុំមិនច្រឡំទេ យកវិញ្ញាបនបត្រមេទាំងអស់នៃចង្កោមនៅទីនោះ ហើយតាមនោះ ក្លាយជាអ្នកគ្រប់គ្រងចង្កោម។

ប្រសិនបើអ្នកក្រឡេកមើលវាតាមវិធីនេះ ទាំងនេះគឺជាសិទ្ធិដ៏គ្រោះថ្នាក់បំផុតមួយចំនួននៅក្នុងផត - មិនថាអ្នកប្រើប្រាស់មានសិទ្ធិអ្វីនោះទេ៖

ប្រសិនបើខ្ញុំមានសិទ្ធិដំណើរការ pod ក្នុង namespace មួយចំនួននៃ cluster នោះ pod នេះមានសិទ្ធិទាំងនេះតាមលំនាំដើម។ ខ្ញុំអាចដំណើរការ pods ដែលមានសិទ្ធិ ហើយជាទូទៅទាំងនេះគឺជាសិទ្ធិទាំងអស់ អនុវត្តជា root នៅលើថ្នាំង។

សំណព្វរបស់ខ្ញុំគឺអ្នកប្រើប្រាស់ Root ។ ហើយ Kubernetes មានជម្រើស Run As Non-Root ។ នេះគឺជាប្រភេទនៃការការពារពីពួក Hacker ។ តើអ្នកដឹងទេថា "មេរោគម៉ុលដាវី" ជាអ្វី? ប្រសិនបើភ្លាមៗនោះ អ្នកគឺជាអ្នកលួចស្តាប់ ហើយចូលមកចង្កោម Kubernetes របស់ខ្ញុំ នោះយើងដែលជាអ្នកគ្រប់គ្រងក្រីក្រ សួរថា “សូមចង្អុលបង្ហាញនៅក្នុងផតរបស់អ្នកដែលអ្នកនឹង hack ចង្កោមរបស់ខ្ញុំ ដំណើរការដោយមិនមែនជា root ។ បើមិនដូច្នេះទេ វានឹងកើតឡើងដែលអ្នកដំណើរការដំណើរការនៅក្នុង pod របស់អ្នកនៅក្រោម root ហើយវានឹងមានភាពងាយស្រួលសម្រាប់អ្នកក្នុងការ hack ខ្ញុំ។ សូម​ការពារ​ខ្លួន​ពី​ខ្លួន​ឯង»។

តាមគំនិតរបស់ខ្ញុំ បរិមាណផ្លូវម៉ាស៊ីនគឺជាវិធីលឿនបំផុតដើម្បីទទួលបានលទ្ធផលដែលចង់បានពីក្រុម Kubernetes ។

ប៉ុន្តែអ្វីដែលត្រូវធ្វើជាមួយទាំងអស់នេះ?

គំនិតដែលគួរកើតមានចំពោះអ្នកគ្រប់គ្រងធម្មតាដែលជួប Kubernetes គឺ៖ “បាទ ខ្ញុំបានប្រាប់អ្នកថា Kubernetes មិនដំណើរការទេ។ មានរន្ធនៅក្នុងវា។ ហើយ Cube ទាំងមូលគឺឆ្កួត។ តាម​ពិត​វា​មាន​ឯកសារ​អ៊ីចឹង​ហើយ បើ​មើល​ទៅ​មាន​ផ្នែក គោលការណ៍សុវត្ថិភាពផត.

នេះគឺជាវត្ថុ yaml - យើងអាចបង្កើតវានៅក្នុងចង្កោម Kubernetes - ដែលគ្រប់គ្រងទិដ្ឋភាពសុវត្ថិភាពជាពិសេសនៅក្នុងការពិពណ៌នារបស់ pods ។ នោះជាការពិត វាគ្រប់គ្រងសិទ្ធិក្នុងការប្រើប្រាស់ hostNetwork ណាមួយ hostPID ប្រភេទបរិមាណជាក់លាក់ដែលមាននៅក្នុង pods នៅពេលចាប់ផ្តើម។ ដោយមានជំនួយពី Pod Security Policy អ្វីៗទាំងអស់នេះអាចត្រូវបានពិពណ៌នា។

អ្វីដែលគួរឱ្យចាប់អារម្មណ៍បំផុតអំពីគោលការណ៍សុវត្ថិភាព Pod គឺថានៅក្នុងចង្កោម Kubernetes កម្មវិធីដំឡើង PSP ទាំងអស់មិនគ្រាន់តែមិនត្រូវបានពិពណ៌នាតាមវិធីណាមួយនោះទេ ពួកគេត្រូវបានបិទជាធម្មតាតាមលំនាំដើម។ គោលការណ៍សុវត្ថិភាព Pod ត្រូវបានបើកដោយប្រើកម្មវិធីជំនួយការចូល។

មិនអីទេ ចូរយើងដាក់ពង្រាយគោលការណ៍សុវត្ថិភាព Pod ទៅក្នុងចង្កោម ឧបមាថាយើងមានផ្នែកសេវាកម្មមួយចំនួននៅក្នុង namespace ដែលមានតែអ្នកគ្រប់គ្រងប៉ុណ្ណោះដែលអាចចូលប្រើបាន។ ចូរនិយាយថានៅក្នុងករណីផ្សេងទៀតទាំងអស់ pods មានសិទ្ធិមានកម្រិត។ ដោយសារតែអ្នកអភិវឌ្ឍន៍ភាគច្រើនមិនចាំបាច់ដំណើរការផតឃែរដែលមានសិទ្ធិនៅក្នុងចង្កោមរបស់អ្នកទេ។

ហើយអ្វីៗហាក់ដូចជាល្អជាមួយយើង។ ហើយចង្កោម Kubernetes របស់យើងមិនអាចត្រូវបាន hack ក្នុងរយៈពេលពីរនាទី។

មាន​បញ្ហា​មួយ។ ភាគច្រើនទំនងជាប្រសិនបើអ្នកមានចង្កោម Kubernetes នោះការត្រួតពិនិត្យត្រូវបានដំឡើងនៅលើចង្កោមរបស់អ្នក។ ខ្ញុំថែមទាំងអាចទស្សន៍ទាយបានថា ប្រសិនបើចង្កោមរបស់អ្នកមានការត្រួតពិនិត្យ វានឹងត្រូវបានគេហៅថា Prometheus ។

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

ប្រហែលជាអ្នកគ្រប់គ្នាបានអានអត្ថបទដូចគ្នានៅលើ Habre ហើយការត្រួតពិនិត្យមានទីតាំងនៅក្នុងចន្លោះឈ្មោះត្រួតពិនិត្យ។ គំនូសតាង Helm ត្រូវបានគេហៅថាដូចគ្នាសម្រាប់មនុស្សគ្រប់គ្នា។ ខ្ញុំស្មានថាប្រសិនបើអ្នកដំឡើង helm ស្ថេរភាព / prometheus អ្នកនឹងបញ្ចប់ដោយឈ្មោះដូចគ្នា។ ហើយភាគច្រើនខ្ញុំប្រហែលជាមិនចាំបាច់ទាយឈ្មោះ DNS នៅក្នុងចង្កោមរបស់អ្នកទេ។ ព្រោះវាជាស្តង់ដារ។

បន្ទាប់មកយើងមាន dev ns ជាក់លាក់មួយ ដែលអ្នកអាចដំណើរការ pod ជាក់លាក់មួយ។ ហើយបន្ទាប់មកពី pod នេះវាងាយស្រួលណាស់ក្នុងការធ្វើអ្វីមួយដូចនេះ:

$ curl http://prometheus-kube-state-metrics.monitoring 

prometheus-kube-state-metrics គឺជាអ្នកនាំចេញ Prometheus ដែលប្រមូលម៉ែត្រពី Kubernetes API ខ្លួនវាផ្ទាល់។ មានទិន្នន័យជាច្រើននៅទីនោះ អ្វីដែលកំពុងដំណើរការនៅក្នុងចង្កោមរបស់អ្នក តើវាជាអ្វី អ្វីដែលអ្នកមានបញ្ហាជាមួយវា។

ជាឧទាហរណ៍សាមញ្ញ៖

kube_pod_container_info{namespace=“kube-system”,pod=”kube-apiserver-k8s- 1″,container=”kube-apiserver”,រូបភាព=

"gcr.io/google-containers/kube-apiserver:v1.14.5"

,image_id=»docker-pullable://gcr.io/google-containers/kube- apiserver@sha256:e29561119a52adad9edc72bfe0e7fcab308501313b09bf99df4a96 38ee634989″,container_id=»docker://7cbe7b1fea33f811fdd8f7e0e079191110268f2 853397d7daf08e72c22d3cf8b»} 1

ដោយធ្វើការស្នើសុំ curl សាមញ្ញពី pod ដែលមិនមានសិទ្ធិ អ្នកអាចទទួលបានព័ត៌មានខាងក្រោម។ ប្រសិនបើអ្នកមិនដឹងថាតើ Kubernetes ជំនាន់ណាដែលអ្នកកំពុងដំណើរការ វានឹងប្រាប់អ្នកយ៉ាងងាយស្រួល។

ហើយអ្វីដែលគួរឱ្យចាប់អារម្មណ៍បំផុតនោះគឺថា បន្ថែមពីលើការចូលទៅកាន់ kube-state-metrics អ្នកអាចចូលទៅប្រើប្រាស់ Prometheus ដោយផ្ទាល់បានយ៉ាងងាយស្រួល។ អ្នកអាចប្រមូលម៉ែត្រពីទីនោះ។ អ្នកអាចបង្កើតម៉ែត្រពីទីនោះ។ សូម្បីតែទ្រឹស្តីក៏ដោយ អ្នកអាចបង្កើតសំណួរបែបនេះពីចង្កោមនៅក្នុង Prometheus ដែលនឹងបិទវាយ៉ាងសាមញ្ញ។ ហើយការត្រួតពិនិត្យរបស់អ្នកនឹងឈប់ដំណើរការពីចង្កោមទាំងអស់គ្នា។

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

ដូចទៅនឹង PSP ដែរ វាមានអារម្មណ៍ដូចជាបញ្ហាគឺថា បច្ចេកវិទ្យាដ៏ប្រណិតទាំងអស់នេះ - Kubernetes, Prometheus - ពួកគេគ្រាន់តែមិនដំណើរការ និងពោរពេញដោយរន្ធ។ មិន​ប្រាកដ​ទេ។

មានរឿងបែបនេះ - គោលការណ៍បណ្តាញ.

ប្រសិនបើអ្នកជាអ្នកគ្រប់គ្រងធម្មតា នោះទំនងជាអ្នកដឹងអំពីគោលការណ៍បណ្តាញ ដែលនេះគ្រាន់តែជា yaml មួយផ្សេងទៀត ដែលមានពួកវាជាច្រើននៅក្នុងចង្កោម។ ហើយគោលការណ៍បណ្តាញមួយចំនួនពិតជាមិនត្រូវការទេ។ ហើយទោះបីជាអ្នកអានគោលការណ៍បណ្តាញអ្វីក៏ដោយ ថាវាជាជញ្ជាំងភ្លើង yaml របស់ Kubernetes វាអនុញ្ញាតឱ្យអ្នកកំណត់សិទ្ធិចូលប្រើរវាង namespaces រវាង pods បន្ទាប់មកអ្នកប្រាកដជាសម្រេចចិត្តថា firewall ជាទម្រង់ yaml នៅក្នុង Kubernetes គឺផ្អែកលើការសង្ខេបបន្ទាប់។ ... ទេ​ទេ ។ នេះពិតជាមិនចាំបាច់ទេ។

ទោះបីជាអ្នកមិនបានប្រាប់អ្នកឯកទេសផ្នែកសុវត្ថិភាពរបស់អ្នកថា ការប្រើប្រាស់ Kubernetes របស់អ្នកក៏ដោយ អ្នកអាចបង្កើតជញ្ជាំងភ្លើងដ៏ងាយស្រួល និងសាមញ្ញបំផុត ហើយថែមទាំងមានលក្ខណៈលម្អិតផងដែរ។ ប្រសិនបើពួកគេមិនទាន់ដឹងរឿងនេះ ហើយមិនរំខានអ្នកទេ៖ "មែនហើយ ផ្តល់ឱ្យខ្ញុំ ផ្តល់ឱ្យខ្ញុំ ... ដោយគ្មានការអនុញ្ញាត។

ដូចនៅក្នុងឧទាហរណ៍ដែលខ្ញុំបានផ្ដល់ឱ្យ អ្នកអាចទាញយកម៉ែត្ររដ្ឋ kube ពីទំហំឈ្មោះណាមួយនៅក្នុងចង្កោម Kubernetes ដោយមិនមានសិទ្ធិធ្វើដូច្នេះទេ។ គោលការណ៍បណ្តាញបានបិទការចូលប្រើពី namespaces ផ្សេងទៀតទាំងអស់ទៅកាន់ namespace ត្រួតពិនិត្យ ហើយនោះហើយជាវា៖ គ្មានការចូលប្រើ គ្មានបញ្ហាទេ។ នៅក្នុងគំនូសតាងទាំងអស់ដែលមាន ទាំង Prometheus ស្តង់ដារ និង Prometheus ដែលមាននៅក្នុងប្រតិបត្តិករ មានជម្រើសមួយនៅក្នុងតម្លៃមួក ដើម្បីបើកគោលការណ៍បណ្តាញសម្រាប់ពួកគេ។ អ្នកគ្រាន់តែត្រូវបើកវា ហើយពួកគេនឹងដំណើរការ។

ពិតជាមានបញ្ហាមួយនៅទីនេះ។ ក្នុងនាមជាអ្នកគ្រប់គ្រងដែលមានពុកចង្ការធម្មតា អ្នកទំនងជាបានសម្រេចចិត្តថាមិនត្រូវការគោលការណ៍បណ្តាញទេ។ ហើយបន្ទាប់ពីអានអត្ថបទគ្រប់ប្រភេទអំពីធនធានដូចជា Habr អ្នកបានសម្រេចចិត្តថា flannel ជាពិសេសជាមួយ host-gateway mode គឺជារឿងដ៏ល្អបំផុតដែលអ្នកអាចជ្រើសរើសបាន។

តើខ្ញុំគួរធ្វើអ្វី?

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

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

នៅពេលអ្នកលើកចង្កោមថ្មី ក្នុងពេលជាមួយគ្នាបញ្ចូល Calico ជំនួសឱ្យ flannel ។

អ្វីដែលត្រូវធ្វើប្រសិនបើវិញ្ញាបនបត្ររបស់អ្នកត្រូវបានចេញក្នុងរយៈពេលមួយរយឆ្នាំហើយអ្នកនឹងមិនប្រើចង្កោមឡើងវិញទេ? មានរឿងដូចជា Kube-RBAC-Proxy ។ នេះ​ជា​ការ​អភិវឌ្ឍ​ដ៏​ត្រជាក់​ខ្លាំង វា​អនុញ្ញាត​ឱ្យ​អ្នក​បង្កប់​ខ្លួន​វា​ជា​ធុង​ចំហៀង​ទៅ​កាន់​ផត​ក្នុង​ចង្កោម Kubernetes។ ហើយវាពិតជាបន្ថែមការអនុញ្ញាតទៅ pod នេះតាមរយៈ RBAC នៃ Kubernetes ខ្លួនវាផ្ទាល់។

មានបញ្ហាមួយ។ កាលពីមុន ដំណោះស្រាយ Kube-RBAC-Proxy នេះត្រូវបានបង្កើតឡើងនៅក្នុង Prometheus របស់ប្រតិបត្តិករ។ ប៉ុន្តែបន្ទាប់មកគាត់បានទៅ។ ឥឡូវនេះកំណែទំនើបពឹងផ្អែកលើការពិតដែលថាអ្នកមានគោលការណ៍បណ្តាញហើយបិទវាដោយប្រើពួកវា។ ដូច្នេះហើយ យើងនឹងត្រូវសរសេរតារាងឡើងវិញបន្តិច។ តាមពិតទៅ បើអ្នកទៅ ឃ្លាំងនេះ។មានឧទាហរណ៍នៃរបៀបប្រើវាជា sidecars ហើយគំនូសតាងនឹងត្រូវសរសេរឡើងវិញយ៉ាងតិចបំផុត។

មានបញ្ហាតូចមួយទៀត។ Prometheus មិន​មែន​ជា​មនុស្ស​តែ​ម្នាក់​ដែល​ប្រគល់​ម៉ែត្រ​របស់​វា​ទៅ​ឲ្យ​អ្នក​ណា​ម្នាក់​តែ​ប៉ុណ្ណោះ។ សមាសធាតុចង្កោម Kubernetes ទាំងអស់របស់យើងក៏អាចត្រលប់មកវិញនូវម៉ែត្ររបស់ពួកគេផងដែរ។

ប៉ុន្តែដូចដែលខ្ញុំបាននិយាយរួចមកហើយថា ប្រសិនបើអ្នកមិនអាចចូលប្រើចង្កោម និងប្រមូលព័ត៌មានបានទេ នោះយ៉ាងហោចណាស់អ្នកអាចបង្កគ្រោះថ្នាក់ខ្លះ។

ដូច្នេះខ្ញុំនឹងបង្ហាញវិធីពីរយ៉ាងយ៉ាងឆាប់រហ័សអំពីរបៀបដែលក្រុម Kubernetes អាចត្រូវបានបំផ្លាញ។

អ្នកនឹងសើចនៅពេលខ្ញុំប្រាប់អ្នក នេះជាករណីជីវិតពិតពីរ។

វិធីសាស្រ្តមួយ។ ការថយចុះធនធាន។

តោះបើកផេកពិសេសមួយទៀត។ វានឹងមានផ្នែកដូចនេះ។

resources: 
    requests: 
        cpu: 4 
        memory: 4Gi 

ដូចដែលអ្នកដឹង សំណើគឺជាចំនួននៃ CPU និងអង្គចងចាំដែលត្រូវបានបម្រុងទុកនៅលើម៉ាស៊ីនសម្រាប់ pods ជាក់លាក់ជាមួយនឹងសំណើ។ ប្រសិនបើយើងមានម៉ាស៊ីន XNUMX-core នៅក្នុងចង្កោម Kubernetes ហើយផតស៊ីភីយូ XNUMX មកដល់ទីនោះជាមួយនឹងសំណើ វាមានន័យថាលែងមានផតដែលមានសំណើនឹងអាចមកដល់ម៉ាស៊ីននេះទៀតហើយ។

ប្រសិនបើខ្ញុំដំណើរការ pod បែបនេះ ខ្ញុំនឹងដំណើរការពាក្យបញ្ជា៖

$ kubectl scale special-pod --replicas=...

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

ប្រសិនបើយើងក្រឡេកមើលឯកសារ Kubernetes ម្តងទៀត យើងនឹងឃើញវត្ថុនេះហៅថា Limit Range។ វាកំណត់ធនធានសម្រាប់វត្ថុចង្កោម។ អ្នកអាចសរសេរវត្ថុ Limit Range ក្នុង yaml អនុវត្តវាទៅ namespaces ជាក់លាក់ - ហើយបន្ទាប់មកនៅក្នុង namespace នេះ អ្នកអាចនិយាយថាអ្នកមានធនធានលំនាំដើម អតិបរមា និងអប្បបរមាសម្រាប់ pods ។

ដោយមានជំនួយពីរឿងបែបនេះ យើងអាចដាក់កម្រិតអ្នកប្រើប្រាស់នៅក្នុងចន្លោះឈ្មោះផលិតផលជាក់លាក់នៃក្រុមក្នុងសមត្ថភាពក្នុងការបង្ហាញពីប្រភេទទាំងអស់នៃរឿងមិនល្អនៅលើផតផតរបស់ពួកគេ។ ប៉ុន្តែជាអកុសល បើទោះបីជាអ្នកប្រាប់អ្នកប្រើប្រាស់ថា ពួកគេមិនអាចបើកដំណើរការ pods ជាមួយនឹងសំណើសម្រាប់ CPU លើសពីមួយ វាមានពាក្យបញ្ជាខ្នាតដ៏អស្ចារ្យបែបនេះ ឬពួកគេអាចធ្វើមាត្រដ្ឋានតាមរយៈផ្ទាំងគ្រប់គ្រង។

ហើយនេះគឺជាកន្លែងដែលវិធីសាស្ត្រលេខ 11 មកពី។ យើងបើកដំណើរការ 111 pods ។ នោះជាដប់មួយពាន់លាន។ នេះ​មិនមែន​មក​ពី​ខ្ញុំ​ឡើង​លេខ​បែប​នេះ​ទេ ប៉ុន្តែ​មក​ពី​ខ្ញុំ​ឃើញ​វា​ដោយ​ខ្លួន​ឯង។

រឿងពិត។ ពេលល្ងាចខ្ញុំហៀបនឹងចេញពីការិយាល័យ។ ខ្ញុំឃើញក្រុមអ្នកអភិវឌ្ឍន៍កំពុងអង្គុយនៅជ្រុងម្ខាង កំពុងធ្វើអ្វីមួយជាមួយកុំព្យូទ័រយួរដៃរបស់ពួកគេ។ ខ្ញុំ​ដើរ​ទៅ​រក​បុរស​ទាំង​នោះ​សួរ​ថា “តើ​អ្នក​មាន​រឿង​អ្វី​កើត​ឡើង?”

មុននេះបន្តិច ប្រហែលម៉ោងប្រាំបួនល្ងាច អ្នកអភិវឌ្ឍន៍ម្នាក់កំពុងរៀបចំខ្លួនទៅផ្ទះ។ ហើយ​ខ្ញុំ​បាន​សម្រេច​ចិត្ត​ថា​៖ «​ឥឡូវ​នេះ​ខ្ញុំ​នឹង​ធ្វើ​មាត្រដ្ឋាន​ពាក្យ​សុំ​របស់​ខ្ញុំ​ចុះ​ដល់​មួយ​»។ ខ្ញុំ​ចុច​មួយ ប៉ុន្តែ​អ៊ីនធឺណិត​យឺត​បន្តិច។ គាត់បានចុចមួយម្តងទៀត គាត់ចុចមួយ ហើយចុច Enter ។ ខ្ញុំ​ញាប់​ញ័រ​គ្រប់​យ៉ាង​ដែល​ខ្ញុំ​អាច​ធ្វើ​បាន។ បន្ទាប់មកអ៊ិនធឺណិតមានជីវិត - ហើយអ្វីគ្រប់យ៉ាងបានចាប់ផ្តើមធ្លាក់ចុះដល់លេខនេះ។

ពិត រឿងនេះមិនបានកើតឡើងនៅលើ Kubernetes ទេ នៅពេលនោះវាជា Nomad ។ វាបានបញ្ចប់ដោយការពិតដែលថាបន្ទាប់ពីមួយម៉ោងនៃការប៉ុនប៉ងរបស់យើងដើម្បីបញ្ឈប់ Nomad ពីការព្យាយាមបន្តធ្វើមាត្រដ្ឋាន Nomad បានឆ្លើយតបថាគាត់នឹងមិនបញ្ឈប់ការធ្វើមាត្រដ្ឋានទេហើយនឹងមិនធ្វើអ្វីផ្សេងទៀតទេ។ "ខ្ញុំហត់ហើយ ខ្ញុំចាកចេញ" ហើយគាត់បានកោងឡើង។

តាមធម្មជាតិ ខ្ញុំបានព្យាយាមធ្វើដូចគ្នានៅលើ Kubernetes។ Kubernetes មិនសប្បាយចិត្តជាមួយនឹងដប់មួយពាន់លាន pods គាត់បាននិយាយថា: "ខ្ញុំមិនអាច។ លើសពីការការពារមាត់ខាងក្នុង” ។ ប៉ុន្តែ 1 pods អាច។

ជាការឆ្លើយតបទៅនឹងមួយពាន់លាន Cube មិនបានដកខ្លួនចេញទេ។ គាត់ពិតជាចាប់ផ្តើមធ្វើមាត្រដ្ឋាន។ ដំណើរ​ការ​កាន់​តែ​បន្ត​ទៅ​ទៀត វា​ត្រូវ​ចំណាយ​ពេល​កាន់​តែ​ច្រើន​ក្នុង​ការ​បង្កើត​ផតថល​ថ្មី។ ប៉ុន្តែនៅតែដំណើរការបន្ត។ បញ្ហាតែមួយគត់គឺថា ប្រសិនបើខ្ញុំអាចបើកដំណើរការ pods ដោយគ្មានដែនកំណត់ក្នុង namespace របស់ខ្ញុំ នោះទោះបីជាគ្មានសំណើ និងដែនកំណត់ក៏ដោយ ខ្ញុំអាចបើកដំណើរការ pods ជាច្រើនជាមួយនឹងកិច្ចការមួយចំនួន ដែលដោយមានជំនួយពីកិច្ចការទាំងនេះ ថ្នាំងនឹងចាប់ផ្តើមបន្ថែមនៅក្នុង memory នៅក្នុង CPU ។ នៅពេលដែលខ្ញុំបើកដំណើរការ pods ជាច្រើន ព័ត៌មានពីពួកវាគួរតែចូលទៅក្នុងកន្លែងផ្ទុក ពោលគឺជាដើម។ ហើយនៅពេលដែលព័ត៌មានច្រើនពេកមកដល់ទីនោះ ការផ្ទុកចាប់ផ្តើមត្រឡប់មកវិញយឺតពេក ហើយ Kubernetes ចាប់ផ្តើមរិល។

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

ប៉ុន្តែ​ខ្ញុំ​បាន​សម្រេច​ចិត្ត​ទៅ​កាន់​តែ​ឆ្ងាយ។ ដូចដែលអ្នកបានដឹងហើយថានៅក្នុង Kubernetes មានរបស់បែបនេះហៅថាសេវាកម្ម។ ជាការប្រសើរណាស់ តាមលំនាំដើមនៅក្នុងចង្កោមរបស់អ្នក ភាគច្រើនទំនងជាសេវានេះដំណើរការដោយប្រើតារាង IP ។

ឧទាហរណ៍ ប្រសិនបើអ្នកដំណើរការមួយពាន់លានផត ហើយបន្ទាប់មកប្រើស្គ្រីបដើម្បីបង្ខំឱ្យ Kubernetis បង្កើតសេវាកម្មថ្មី៖

for i in {1..1111111}; do
    kubectl expose deployment test --port 80  
        --overrides="{"apiVersion": "v1", 
           "metadata": {"name": "nginx$i"}}"; 
done 

នៅលើថ្នាំងទាំងអស់នៃចង្កោម ច្បាប់ iptables ថ្មីកាន់តែច្រើននឹងត្រូវបានបង្កើតប្រហែលក្នុងពេលដំណាលគ្នា។ លើសពីនេះទៅទៀត ច្បាប់ iptables មួយពាន់លាននឹងត្រូវបានបង្កើតឡើងសម្រាប់សេវាកម្មនីមួយៗ។

ខ្ញុំ​បាន​ពិនិត្យ​មើល​រឿង​នេះ​រាប់​ពាន់​រហូត​ដល់​ដប់។ ហើយបញ្ហាគឺថានៅកម្រិតនេះវាមានបញ្ហាណាស់ក្នុងការធ្វើ ssh ទៅ node ។ ដោយសារតែកញ្ចប់ដែលឆ្លងកាត់ខ្សែសង្វាក់ជាច្រើនចាប់ផ្តើមមានអារម្មណ៍មិនល្អ។

ហើយបញ្ហានេះក៏ត្រូវបានដោះស្រាយផងដែរ ដោយមានជំនួយពី Kubernetes ។ មានវត្ថុកូតាធនធានបែបនេះ។ កំណត់ចំនួនធនធាន និងវត្ថុដែលមានសម្រាប់ចន្លោះឈ្មោះក្នុងចង្កោម។ យើងអាចបង្កើតវត្ថុ yaml នៅក្នុង namespace នីមួយៗនៃក្រុម Kubernetes ។ ដោយប្រើវត្ថុនេះ យើងអាចនិយាយបានថា យើងមានសំណើមួយចំនួន និងដែនកំណត់ជាក់លាក់ដែលបានបែងចែកសម្រាប់ namespace នេះ ហើយបន្ទាប់មកយើងអាចនិយាយបានថានៅក្នុង namespace នេះ វាអាចបង្កើតសេវា 10 និង 10 pods ។ ហើយ​អ្នក​អភិវឌ្ឍន៍​តែ​ម្នាក់​យ៉ាង​ហោច​ណាស់​អាច​ញាក់​ខ្លួន​ឯង​នៅ​ពេល​ល្ងាច។ Kubernetes នឹងប្រាប់គាត់ថា "អ្នកមិនអាចធ្វើមាត្រដ្ឋានផតរបស់អ្នកដល់ចំនួននោះបានទេ ពីព្រោះធនធានលើសពីកូតា។" នោះហើយជាវាបញ្ហាត្រូវបានដោះស្រាយ។ ឯកសារនៅទីនេះ.

ចំណុចបញ្ហាមួយកើតឡើងក្នុងរឿងនេះ។ អ្នកមានអារម្មណ៍ថាពិបាកបង្កើតកន្លែងដាក់ឈ្មោះនៅក្នុង Kubernetes។ ដើម្បីបង្កើតវា យើងត្រូវយករឿងជាច្រើនមកពិចារណា។

កូតាធនធាន + ជួរដែនកំណត់ + RBAC
• បង្កើតលំហឈ្មោះ
• បង្កើតដែនកំណត់មួយនៅខាងក្នុង
• បង្កើតនៅខាងក្នុងកូតាធនធាន
• បង្កើតគណនីសេវាកម្មសម្រាប់ CI
• បង្កើតតួនាទីចងសម្រាប់ CI និងអ្នកប្រើប្រាស់
• បើកដំណើរការសេវាកម្មចាំបាច់ជាជម្រើស

ដូច្នេះ ខ្ញុំ​សូម​យក​ឱកាស​នេះ​ដើម្បី​ចែក​រំលែក​ការ​អភិវឌ្ឍ​របស់​ខ្ញុំ។ មានរឿងបែបនេះហៅថា ប្រតិបត្តិករ SDK ។ នេះគឺជាវិធីមួយសម្រាប់ចង្កោម Kubernetes ដើម្បីសរសេរប្រតិបត្តិករសម្រាប់វា។ អ្នកអាចសរសេរសេចក្តីថ្លែងការណ៍ដោយប្រើ Ansible ។

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

តិចតួច ធ្វើឱ្យដំណើរការស្មុគស្មាញទាំងមូលនេះកាន់តែងាយស្រួល.

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

គោលការណ៍បណ្តាញមិនមែនគ្រាន់តែជាមុខងារដែលមិនចាំបាច់ផ្សេងទៀតនោះទេ។ នេះគឺជាអ្វីដែលពិតជាត្រូវការនៅក្នុងចង្កោម។

LimitRange/ResourceQuota - វាដល់ពេលដែលត្រូវប្រើវា។ យើងចាប់ផ្តើមប្រើវាតាំងពីយូរយារណាស់មកហើយ ហើយខ្ញុំដឹងច្បាស់ថាគ្រប់គ្នាកំពុងប្រើវា។ វាបានប្រែក្លាយថានេះគឺកម្រណាស់។

បន្ថែមពីលើអ្វីដែលខ្ញុំបានលើកឡើងក្នុងអំឡុងពេលរបាយការណ៍ មានលក្ខណៈពិសេសដែលមិនមានឯកសារដែលអនុញ្ញាតឱ្យអ្នកវាយប្រហារចង្កោម។ ចេញផ្សាយថ្មីៗនេះ ការវិភាគយ៉ាងទូលំទូលាយនៃភាពងាយរងគ្រោះ Kubernetes.

រឿងខ្លះពិតជាសោកសៅ និងឈឺចាប់ណាស់។ ជាឧទាហរណ៍ នៅក្រោមលក្ខខណ្ឌជាក់លាក់មួយ cubelets នៅក្នុងចង្កោម Kubernetes អាចផ្តល់ខ្លឹមសារនៃបញ្ជីឈ្មោះ warlocks ដល់អ្នកប្រើប្រាស់ដែលគ្មានការអនុញ្ញាត។

នៅទីនេះ មានការណែនាំអំពីរបៀបបង្កើតឡើងវិញនូវអ្វីគ្រប់យ៉ាងដែលខ្ញុំបានប្រាប់អ្នក។ មានឯកសារដែលមានឧទាហរណ៍ផលិតកម្មនៃអ្វីដែល ResourceQuota និង Pod Security Policy មើលទៅដូច។ ហើយអ្នកអាចប៉ះទាំងអស់នេះ។

អរគុណ​ដល់​អ្នក​ទាំងអស់គ្នា។

ប្រភព: www.habr.com