កម្មវិធីជំនួយបណ្តាញ Kubernetes (CNI) លទ្ធផលស្តង់ដារលើសពីបណ្តាញ 10 Gbps (បានធ្វើបច្ចុប្បន្នភាព៖ ខែមេសា ឆ្នាំ 2019)

នេះជាបច្ចុប្បន្នភាពរបស់ខ្ញុំ ស្តង់ដារពីមុនដែលឥឡូវនេះដំណើរការលើ Kubernetes 1.14 ជាមួយនឹងកំណែ CNI ចុងក្រោយបំផុតគិតត្រឹមខែមេសា ឆ្នាំ 2019។

ជាដំបូង ខ្ញុំចង់អរគុណដល់ក្រុម Cilium៖ បុរសៗបានជួយខ្ញុំពិនិត្យ និងកែតម្រូវស្គ្រីបត្រួតពិនិត្យម៉ែត្រ។

អ្វីដែលបានផ្លាស់ប្តូរចាប់តាំងពីខែវិច្ឆិកាឆ្នាំ 2018

នេះជាអ្វីដែលបានផ្លាស់ប្តូរតាំងពីពេលនោះមក (ប្រសិនបើអ្នកចាប់អារម្មណ៍)៖

Flannel នៅតែជាចំណុចប្រទាក់ CNI លឿនបំផុត និងសាមញ្ញបំផុត ប៉ុន្តែនៅតែមិនគាំទ្រគោលការណ៍បណ្តាញ និងការអ៊ិនគ្រីប។

Romana មិន​ត្រូវ​បាន​គាំទ្រ​ទៀត​ទេ ដូច្នេះ​យើង​បាន​ដក​វា​ចេញ​ពី​គោល។

ឥឡូវនេះ WeaveNet គាំទ្រគោលការណ៍បណ្តាញសម្រាប់ Ingress និង Egress! ប៉ុន្តែផលិតភាពបានថយចុះ។

នៅក្នុង Calico អ្នកនៅតែត្រូវកំណត់រចនាសម្ព័ន្ធទំហំកញ្ចប់អតិបរមា (MTU) ដោយដៃសម្រាប់ដំណើរការល្អបំផុត។ Calico ផ្តល់ជម្រើសពីរសម្រាប់ការដំឡើង CNI ដូច្នេះអ្នកអាចធ្វើបានដោយគ្មានឃ្លាំង ETCD ដាច់ដោយឡែក៖

• ការរក្សាទុកស្ថានភាពនៅក្នុង Kubernetes API ជាឃ្លាំងទិន្នន័យ (ទំហំចង្កោម < 50 nodes);
• ការរក្សាទុកស្ថានភាពនៅក្នុង Kubernetes API ជាឃ្លាំងទិន្នន័យដែលមានប្រូកស៊ី Typha ដើម្បីសម្រាលបន្ទុកនៅលើ K8S API (ទំហំចង្កោម > 50 nodes)។

Calico បានប្រកាសគាំទ្រ គោលនយោបាយកម្រិតកម្មវិធី នៅលើ Istio សម្រាប់សុវត្ថិភាពកម្រិតកម្មវិធី។

ឥឡូវនេះ Cilium គាំទ្រការអ៊ិនគ្រីប! Cilium ផ្តល់នូវការអ៊ិនគ្រីបជាមួយនឹងផ្លូវរូងក្រោមដី IPSec និងផ្តល់នូវជម្រើសជំនួសបណ្តាញ WeaveNet ដែលបានអ៊ិនគ្រីប។ ប៉ុន្តែ WeaveNet លឿនជាង Cilium ជាមួយនឹងការបើកការអ៊ិនគ្រីប។

ឥឡូវនេះ Cilium មានភាពងាយស្រួលក្នុងការដាក់ពង្រាយ អរគុណចំពោះប្រតិបត្តិករ ETCD ដែលភ្ជាប់មកជាមួយ។

ក្រុម Cilium បានព្យាយាមកាត់បន្ថយទម្ងន់មួយចំនួនពី CNI របស់ខ្លួនដោយកាត់បន្ថយការប្រើប្រាស់អង្គចងចាំ និងតម្លៃ CPU ប៉ុន្តែគូប្រជែងរបស់វានៅតែស្រាលជាងមុន។

បរិបទគោល

ស្តង់ដារត្រូវបានដំណើរការលើម៉ាស៊ីនមេ Supermicro ដែលមិនមែនជានិម្មិតចំនួន 10 ជាមួយនឹងកុងតាក់ Supermicro 9000 Gb ។ ម៉ាស៊ីនមេត្រូវបានភ្ជាប់ដោយផ្ទាល់ទៅកុងតាក់តាមរយៈខ្សែ DAC SFP+ អកម្ម ហើយត្រូវបានកំណត់រចនាសម្ព័ន្ធនៅលើ VLAN ដូចគ្នាជាមួយនឹងស៊ុម jumbo (MTU XNUMX) ។

Kubernetes 1.14.0 បានដំឡើងនៅលើ Ubuntu 18.04 LTS ជាមួយ Docker 18.09.2 (កំណែ Docker លំនាំដើមនៅក្នុងការចេញផ្សាយនេះ)។

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

យើងនឹងពណ៌នាអំពីលទ្ធផលគោលលើមាត្រដ្ឋានខាងក្រោម៖

ការជ្រើសរើស CNI សម្រាប់ស្តង់ដារ

នេះគឺជាគោលសម្រាប់តែ CNI ពីបញ្ជីនៅក្នុងផ្នែកប៉ុណ្ណោះ។ អំពីការបង្កើតក្រុមមេមួយជាមួយ kubeadm សូមមើលឯកសារ Kubernetes ផ្លូវការ។ ក្នុងចំណោម CNI ទាំង 9 យើងនឹងយកតែ 6 ប៉ុណ្ណោះ៖ យើងនឹងដកចេញនូវអ្វីដែលពិបាកក្នុងការដំឡើង និង/ឬមិនដំណើរការដោយគ្មានការកំណត់យោងទៅតាមឯកសារ (Romana, Contiv-VPP និង JuniperContrail/TungstenFabric)។

យើងនឹងប្រៀបធៀប CNIs ខាងក្រោម៖

• Calico v3.6
• Canal v3.6 (ជាសំខាន់ Flannel សម្រាប់បណ្តាញ + Calico ជាជញ្ជាំងភ្លើង)
• Cilium 1.4.2
• Flannel 0.11.0
• Kube-router 0.2.5
• WeaveNet 2.5.1

ការកំណត់

ការដំឡើង CNI កាន់តែងាយស្រួល ចំណាប់អារម្មណ៍ដំបូងរបស់យើងនឹងកាន់តែប្រសើរ។ CNIs ទាំងអស់ពីគោលគឺមានភាពងាយស្រួលក្នុងការដំឡើង (ជាមួយពាក្យបញ្ជាមួយ ឬពីរ)។

ដូចដែលយើងបាននិយាយ ម៉ាស៊ីនមេ និងកុងតាក់ត្រូវបានកំណត់រចនាសម្ព័ន្ធជាមួយស៊ុម jumbo ត្រូវបានបើក (យើងកំណត់ MTU ទៅ 9000) ។ យើងនឹងសប្បាយចិត្តប្រសិនបើ CNI កំណត់ MTU ដោយស្វ័យប្រវត្តិដោយផ្អែកលើការកំណត់របស់អាដាប់ទ័រ។ ទោះយ៉ាងណាក៏ដោយមានតែ Cilium និង Flannel ប៉ុណ្ណោះដែលគ្រប់គ្រងរឿងនេះ។ CNIs ដែលនៅសល់មានសំណើនៅលើ GitHub ដើម្បីបន្ថែមការរកឃើញ MTU ដោយស្វ័យប្រវត្តិ ប៉ុន្តែយើងនឹងកំណត់រចនាសម្ព័ន្ធវាដោយដៃដោយការផ្លាស់ប្តូរ ConfigMap សម្រាប់ Calico, Canal និង Kube-router ឬឆ្លងកាត់អថេរបរិស្ថានសម្រាប់ WeaveNet ។

តើមានបញ្ហាអ្វីជាមួយ MTU មិនត្រឹមត្រូវ? ដ្យាក្រាមនេះបង្ហាញពីភាពខុសគ្នារវាង WeaveNet ជាមួយនឹង MTU លំនាំដើម និងស៊ុម jumbo ត្រូវបានបើក៖

តើ MTU ប៉ះពាល់ដល់លំហូរចេញយ៉ាងដូចម្តេច?

យើងបានឃើញពីរបៀបដែល MTU មានសារៈសំខាន់សម្រាប់ការអនុវត្ត ឥឡូវនេះសូមមើលពីរបៀបដែល CNIs របស់យើងកំណត់វាដោយស្វ័យប្រវត្តិ៖

CNI រកឃើញ MTU ដោយស្វ័យប្រវត្តិ

ក្រាហ្វបង្ហាញថាអ្នកត្រូវកំណត់រចនាសម្ព័ន្ធ MTU សម្រាប់ Calico, Canal, Kube-router និង WeaveNet សម្រាប់ដំណើរការល្អបំផុត។ Cilium និង Flannel អាចកំណត់ MTU ដោយខ្លួនឯងបានយ៉ាងត្រឹមត្រូវដោយគ្មានការកំណត់ណាមួយឡើយ។

សន្តិសុខ

យើងនឹងប្រៀបធៀបសុវត្ថិភាព CNI ក្នុងទិដ្ឋភាពពីរ៖ សមត្ថភាពក្នុងការអ៊ិនគ្រីបទិន្នន័យដែលបានបញ្ជូន និងការអនុវត្តគោលការណ៍បណ្តាញ Kubernetes (ផ្អែកលើការសាកល្បងពិតប្រាកដ មិនមែនឯកសារ)។

មានតែ CNIs ពីរប៉ុណ្ណោះដែលអ៊ិនគ្រីបទិន្នន័យ: Cilium និង WeaveNet ។ ការអ៊ិនគ្រីប WeaveNet បើកដំណើរការដោយកំណត់ពាក្យសម្ងាត់អ៊ិនគ្រីបជាអថេរបរិស្ថាន CNI ។ IN ឯកសារ WeaveNet ពិពណ៌នាអំពីវានៅក្នុងវិធីដ៏ស្មុគស្មាញមួយ ប៉ុន្តែអ្វីគ្រប់យ៉ាងត្រូវបានធ្វើយ៉ាងសាមញ្ញ។ ការអ៊ិនគ្រីប ស៊ីលីញ៉ូម កំណត់រចនាសម្ព័ន្ធដោយពាក្យបញ្ជា ដោយបង្កើតអាថ៌កំបាំង Kubernetes និងតាមរយៈការកែប្រែ daemonSet (មានភាពស្មុគស្មាញជាងនៅក្នុង WeaveNet បន្តិច ប៉ុន្តែ Cilium មានជំហានដោយជំហាន ការណែនាំ).

ចំណែក​ការ​អនុវត្ត​គោលនយោបាយ​បណ្តាញ​បាន​ជោគជ័យ Calico, Canal, Cilium និង WeaveNetដែលអ្នកអាចកំណត់រចនាសម្ព័ន្ធ Ingress និង Egress rules។ សម្រាប់ Kube-រ៉ោតទ័រ មានច្បាប់សម្រាប់តែ Ingress និង Flannel មិនមានគោលការណ៍បណ្តាញទាល់តែសោះ។

នេះគឺជាលទ្ធផលសរុប៖

លទ្ធផលស្តង់ដារនៃការអនុវត្តសុវត្ថិភាព

ផលិតភាព

ស្តង់ដារនេះបង្ហាញពីការឆ្លងកាត់ជាមធ្យមលើការរត់យ៉ាងហោចណាស់បីដងនៃការធ្វើតេស្តនីមួយៗ។ យើងសាកល្បងដំណើរការរបស់ TCP និង UDP (ដោយប្រើ iperf3) កម្មវិធីពិតដូចជា HTTP (ជាមួយ Nginx និង curl) ឬ FTP (ជាមួយ vsftpd និង curl) ហើយទីបំផុតការអនុវត្តកម្មវិធីដោយប្រើការអ៊ិនគ្រីបផ្អែកលើ SCP (ដោយប្រើម៉ាស៊ីនភ្ញៀវ និងម៉ាស៊ីនមេ OpenSSH) ។

សម្រាប់ការធ្វើតេស្តទាំងអស់ យើងបានអនុវត្តស្តង់ដារដែកទទេ (បន្ទាត់ពណ៌បៃតង) ដើម្បីប្រៀបធៀបដំណើរការ CNI ជាមួយនឹងដំណើរការបណ្តាញដើម។ នៅទីនេះយើងប្រើមាត្រដ្ឋានដូចគ្នា ប៉ុន្តែមានពណ៌៖

• លឿង = ល្អណាស់
• ទឹកក្រូច = ល្អ។
• ខៀវ = ដូច្នេះ
• ក្រហម = អាក្រក់

យើងនឹងមិនយក CNIs ដែលបានកំណត់មិនត្រឹមត្រូវទេ ហើយនឹងបង្ហាញតែលទ្ធផលសម្រាប់ CNIs ជាមួយនឹង MTU ត្រឹមត្រូវ។ (ចំណាំ៖ Cilium មិនគណនា MTU បានត្រឹមត្រូវទេ ប្រសិនបើអ្នកបើកការអ៊ិនគ្រីប ដូច្នេះអ្នកនឹងត្រូវកាត់បន្ថយ MTU ដោយដៃទៅ 8900 នៅក្នុងកំណែ 1.4 ។ កំណែបន្ទាប់ 1.5 ធ្វើវាដោយស្វ័យប្រវត្តិ។ )

នេះគឺជាលទ្ធផល៖

ការអនុវត្ត TCP

CNIs ទាំងអស់ដំណើរការបានល្អនៅក្នុង TCP benchmark ។ CNI ដែល​មាន​ការ​អ៊ិនគ្រីប​នៅ​យឺត​ពេល​ឆ្ងាយ​ពី​ព្រោះ​ការ​អ៊ិនគ្រីប​មាន​តម្លៃ​ថ្លៃ។

ការអនុវត្ត UDP

នៅទីនេះផងដែរ CNIs ទាំងអស់កំពុងដំណើរការល្អ។ CNI ជាមួយនឹងការអ៊ិនគ្រីបបានបង្ហាញលទ្ធផលស្ទើរតែដូចគ្នា។ Cilium នៅពីក្រោយការប្រកួតប្រជែងនេះបន្តិច ប៉ុន្តែវាមានត្រឹមតែ 2,3% នៃលោហៈធាតុទទេ ដូច្នេះហើយវាមិនមែនជាលទ្ធផលអាក្រក់នោះទេ។ កុំភ្លេចថាមានតែ Cilium និង Flannel ប៉ុណ្ណោះដែលកំណត់ MTU ដោយខ្លួនឯងបានត្រឹមត្រូវ ហើយទាំងនេះគឺជាលទ្ធផលរបស់ពួកគេដោយគ្មានការកំណត់បន្ថែមណាមួយឡើយ។

ចុះកម្មវិធីពិតវិញ? ដូចដែលអ្នកអាចឃើញការអនុវត្តជាទូទៅសម្រាប់ HTTP គឺទាបជាង TCP បន្តិច។ ទោះបីជាអ្នកប្រើ HTTP ជាមួយ TCP ក៏ដោយ យើងបានកំណត់រចនាសម្ព័ន្ធ iperf3 នៅក្នុងស្តង់ដារ TCP ដើម្បីជៀសវាងការចាប់ផ្តើមយឺតដែលនឹងប៉ះពាល់ដល់ HTTP benchmark ។ គ្រប់គ្នាធ្វើបានល្អនៅទីនេះ។ Kube-router មានអត្ថប្រយោជន៍ច្បាស់លាស់ ប៉ុន្តែ WeaveNet មិនបានដំណើរការល្អទេ៖ ប្រហែល 20% អាក្រក់ជាងដែកទទេ។ Cilium និង WeaveNet ជាមួយនឹងការអ៊ិនគ្រីបមើលទៅពិតជាសោកសៅ។

ជាមួយនឹង FTP ដែលជាពិធីការដែលមានមូលដ្ឋានលើ TCP មួយផ្សេងទៀត លទ្ធផលខុសគ្នា។ Flannel និង Kube-router ធ្វើការងារនេះ ប៉ុន្តែ Calico, Canal និង Cilium នៅខាងក្រោយបន្តិច ហើយយឺតជាងដែកទទេប្រហែល 10% ។ WeaveNet គឺនៅពីក្រោយ 17% ប៉ុន្តែ WeaveNet ដែលបានអ៊ិនគ្រីបគឺ 40% នាំមុខ Cilium ដែលបានអ៊ិនគ្រីប។

ជាមួយ SCP យើងអាចមើលឃើញភ្លាមៗថាតើការអ៊ិនគ្រីប SSH មានតម្លៃប៉ុន្មាន។ ស្ទើរតែ CNIs ទាំងអស់កំពុងដំណើរការបានល្អ ប៉ុន្តែ WeaveNet កំពុងតែយឺតយ៉ាវម្តងទៀត។ Cilium និង WeaveNet ជាមួយនឹងការអ៊ិនគ្រីបត្រូវបានរំពឹងទុកថាអាក្រក់បំផុតដោយសារតែការអ៊ិនគ្រីបពីរដង (SSH + CNI) ។

នេះគឺជាតារាងសង្ខេបជាមួយនឹងលទ្ធផល៖

ការប្រើប្រាស់ធនធាន

ឥឡូវនេះសូមប្រៀបធៀបពីរបៀបដែល CNI ប្រើប្រាស់ធនធានក្រោមបន្ទុកធ្ងន់ (កំឡុងពេលផ្ទេរ TCP, 10 Gbps) ។ នៅក្នុងការធ្វើតេស្តការអនុវត្តយើងប្រៀបធៀប CNI ជាមួយដែកទទេ (បន្ទាត់ពណ៌បៃតង) ។ សម្រាប់ការប្រើប្រាស់ធនធាន សូមបង្ហាញ Kubernetes សុទ្ធ (បន្ទាត់ពណ៌ស្វាយ) ដោយគ្មាន CNI ហើយមើលថាតើធនធានបន្ថែមប៉ុន្មានដែល CNI ប្រើប្រាស់។

ចូរចាប់ផ្តើមជាមួយនឹងការចងចាំ។ នេះគឺជាតម្លៃមធ្យមសម្រាប់ RAM របស់ថ្នាំង (មិនរាប់បញ្ចូលសតិបណ្ដោះអាសន្ន និងឃ្លាំងសម្ងាត់) ក្នុង MB កំឡុងពេលផ្ទេរ។

ការប្រើប្រាស់អង្គចងចាំ

Flannel និង Kube-router បានបង្ហាញលទ្ធផលដ៏ល្អ - ត្រឹមតែ 50 MB ប៉ុណ្ណោះ។ Calico និង Canal នីមួយៗមាន 70 ។ WeaveNet ប្រើប្រាស់យ៉ាងច្បាស់ជាងឧបករណ៍ផ្សេងទៀត - 130 MB ហើយ Cilium ប្រើប្រាស់ច្រើនដល់ទៅ 400 ។
ឥឡូវនេះសូមពិនិត្យមើលការប្រើប្រាស់ពេលវេលារបស់ CPU ។ គួរកត់សំគាល់៖ ដ្យាក្រាមបង្ហាញមិនឃើញភាគរយទេ ប៉ុន្តែ ppm នោះគឺ 38 ppm សម្រាប់ "ដែកទទេ" គឺ 3,8% ។ នេះជាលទ្ធផល៖

ការប្រើប្រាស់ស៊ីភីយូ

Calico, Canal, Flannel និង Kube-router មានប្រសិទ្ធភាព CPU ខ្លាំង - តែ 2% ច្រើនជាង Kubernetes ដែលគ្មាន CNI ។ WeaveNet មានភាពយឺតយ៉ាវជាងជាមួយនឹង 5% បន្ថែមបន្ទាប់មក Cilium នៅ 7% ។

នេះគឺជាសេចក្តីសង្ខេបនៃការប្រើប្រាស់ធនធាន៖

លទ្ធផល

តារាងដែលមានលទ្ធផលទាំងអស់៖

លទ្ធផលស្តង់ដារទូទៅ

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

នៅផ្នែកចុងក្រោយ ខ្ញុំនឹងបញ្ចេញមតិយោបល់លើលទ្ធផល។ សូមចាំថា គោលនេះសាកល្បងតែការឆ្លងកាត់នៃការតភ្ជាប់តែមួយនៅលើចង្កោមតូចបំផុត (3 ថ្នាំង)។ វាមិនអនុវត្តចំពោះចង្កោមធំ (<50 nodes) ឬការតភ្ជាប់ប៉ារ៉ាឡែលទេ។

ខ្ញុំសូមណែនាំឱ្យប្រើ CNIs ខាងក្រោមអាស្រ័យលើសេណារីយ៉ូ៖

• តើអ្នកមាននៅក្នុងចង្កោមរបស់អ្នក។ ថ្នាំងដែលមានធនធានតិចតួច (RAM ជាច្រើន GB ស្នូលជាច្រើន) ហើយអ្នកមិនត្រូវការមុខងារសុវត្ថិភាពទេ - ជ្រើសរើស Flannel. នេះគឺជា CNIs ដែលមានប្រសិទ្ធភាពបំផុតមួយ។ ហើយវាអាចប្រើបានជាមួយស្ថាបត្យកម្មជាច្រើនប្រភេទ (amd64, arm, arm64 ជាដើម)។ លើសពីនេះទៀតនេះគឺជាមួយក្នុងចំណោមពីរ (មួយទៀតគឺ Cilium) CNI ដែលអាចកំណត់ MTU ដោយស្វ័យប្រវត្តិ ដូច្នេះអ្នកមិនចាំបាច់កំណត់រចនាសម្ព័ន្ធអ្វីនោះទេ។ Kube-router ក៏សមរម្យដែរ ប៉ុន្តែវាមិនមានលក្ខណៈស្តង់ដារទេ ហើយអ្នកនឹងត្រូវកំណត់រចនាសម្ព័ន្ធ MTU ដោយដៃ។
• បើត្រូវការ អ៊ិនគ្រីបបណ្តាញ ដើម្បីសុវត្ថិភាព យក WeaveNet. កុំភ្លេចបញ្ជាក់ទំហំ MTU ប្រសិនបើអ្នកកំពុងប្រើស៊ុម jumbo ហើយបើកការអ៊ិនគ្រីបដោយបញ្ជាក់ពាក្យសម្ងាត់តាមរយៈអថេរបរិស្ថាន។ ប៉ុន្តែវាជាការប្រសើរជាងក្នុងការភ្លេចអំពីការអនុវត្ត - នោះគឺជាតម្លៃនៃការអ៊ិនគ្រីប។
• សម្រាប់ ការប្រើប្រាស់ធម្មតា។ ខ្ញុំណែនាំ កាលីកូ។. CNI នេះត្រូវបានប្រើប្រាស់យ៉ាងទូលំទូលាយនៅក្នុងឧបករណ៍ដាក់ពង្រាយ Kubernetes ផ្សេងៗ (Kops, Kubespray, Rancher ជាដើម)។ ដូចនឹង WeaveNet ត្រូវប្រាកដថាកំណត់រចនាសម្ព័ន្ធ MTU នៅក្នុង ConfigMap ប្រសិនបើប្រើស៊ុម jumbo ។ វាជាឧបករណ៍ពហុមុខងារដែលមានប្រសិទ្ធភាពក្នុងលក្ខខណ្ឌនៃការប្រើប្រាស់ធនធាន ការអនុវត្ត និងសុវត្ថិភាព។

ហើយចុងក្រោយខ្ញុំណែនាំអ្នកឱ្យធ្វើតាមការអភិវឌ្ឍន៍ ស៊ីលីញ៉ូម. CNI នេះមានក្រុមសកម្មខ្លាំងដែលធ្វើការច្រើនលើផលិតផលរបស់ពួកគេ (លក្ខណៈពិសេស ការសន្សំធនធាន ការអនុវត្ត សុវត្ថិភាព ចង្កោម...) ហើយពួកគេមានផែនការគួរឱ្យចាប់អារម្មណ៍ណាស់។

ដ្យាក្រាមដែលមើលឃើញសម្រាប់ការជ្រើសរើស CNI

ប្រភព: www.habr.com