Kubernetes 1.14៖ ទិដ្ឋភាពទូទៅនៃការច្នៃប្រឌិតសំខាន់ៗ

យប់​នេះ នឹងកើតឡើង។ ការចេញផ្សាយបន្ទាប់របស់ Kubernetes - 1.14. យោងតាមប្រពៃណីដែលបានបង្កើតឡើងសម្រាប់ប្លុករបស់យើង យើងកំពុងនិយាយអំពីការផ្លាស់ប្តូរសំខាន់ៗនៅក្នុងកំណែថ្មីនៃផលិតផលប្រភពបើកចំហដ៏អស្ចារ្យនេះ។

ព័ត៌មានដែលប្រើដើម្បីរៀបចំសម្ភារៈនេះត្រូវបានយកចេញពី Kubernetes បង្កើនតារាងតាមដាន, ការផ្លាស់ប្តូរ-1.14 និងបញ្ហាពាក់ព័ន្ធ ទាញសំណើ សំណើបង្កើន Kubernetes (KEP)។

ចូរចាប់ផ្តើមជាមួយនឹងការណែនាំដ៏សំខាន់មួយពី SIG cluster-lifecycle៖ ចង្កោមបរាជ័យថាមវន្ត Kubernetes (ឬដើម្បីឱ្យច្បាស់លាស់ជាងមុន ការដាក់ពង្រាយ HA ដែលរៀបចំដោយខ្លួនឯង) គឺឥឡូវនេះ អាចត្រូវបានបង្កើត ដោយប្រើពាក្យបញ្ជាដែលធ្លាប់ស្គាល់ (នៅក្នុងបរិបទនៃចង្កោមថ្នាំងតែមួយ) kubeadm (init и join) និយាយឱ្យខ្លីសម្រាប់រឿងនេះ៖

• វិញ្ញាបនបត្រដែលប្រើដោយចង្កោមត្រូវបានផ្ទេរទៅសម្ងាត់;
• សម្រាប់​លទ្ធភាព​នៃ​ការ​ប្រើ​ចង្កោម etcd នៅ​ក្នុង​ចង្កោម K8s (ឧ. កម្ចាត់​ភាពអាស្រ័យ​ខាងក្រៅ​ដែល​មាន​ពីមុន) etcd-operator;
• ចងក្រងឯកសារការកំណត់ដែលបានណែនាំសម្រាប់សមតុល្យបន្ទុកខាងក្រៅដែលផ្តល់នូវការកំណត់រចនាសម្ព័ន្ធដែលអត់ឱនកំហុស (នៅពេលអនាគត វាត្រូវបានគ្រោងទុកដើម្បីលុបបំបាត់ភាពអាស្រ័យនេះ ប៉ុន្តែមិនមែននៅដំណាក់កាលនេះទេ)។

ស្ថាបត្យកម្មនៃចង្កោម Kubernetes HA បង្កើតជាមួយ kubeadm

ព័ត៌មានលម្អិតនៃការអនុវត្តអាចរកបាននៅក្នុង សំណើរចនា. លក្ខណៈពិសេសនេះពិតជាត្រូវបានរង់ចាំជាយូរមកហើយ៖ កំណែអាល់ហ្វាត្រូវបានគេរំពឹងថានឹងត្រលប់មកវិញនៅក្នុង K8s 1.9 ប៉ុន្តែទើបតែបង្ហាញខ្លួននៅពេលនេះប៉ុណ្ណោះ។

ការ API

ក្រុមការងារ apply ហើយនិយាយជាទូទៅ ការគ្រប់គ្រងវត្ថុប្រកាស ឆ្លងកាត់ ពី kubectl នៅក្នុង apiserver ។ អ្នកអភិវឌ្ឍន៍ខ្លួនឯងពន្យល់យ៉ាងខ្លីអំពីការសម្រេចចិត្តរបស់ពួកគេដោយនិយាយថា kubectl apply - ផ្នែកជាមូលដ្ឋាននៃការធ្វើការជាមួយការកំណត់នៅក្នុង Kubernetes ទោះជាយ៉ាងណាក៏ដោយ "វាពោរពេញដោយកំហុស និងពិបាកក្នុងការជួសជុល" ដូច្នេះមុខងារនេះចាំបាច់ត្រូវនាំយកមកធម្មតាវិញ ហើយផ្ទេរទៅយន្តហោះបញ្ជា។ ឧទាហរណ៍សាមញ្ញ និងច្បាស់លាស់នៃបញ្ហាដែលមានសព្វថ្ងៃនេះ៖

ព័ត៌មានលម្អិតអំពីការអនុវត្តមាននៅក្នុង ខេអេ. ការត្រៀមខ្លួនបច្ចុប្បន្នគឺអាល់ហ្វា (ការផ្សព្វផ្សាយទៅជាបេតាត្រូវបានគ្រោងសម្រាប់ការចេញផ្សាយ Kubernetes បន្ទាប់)។

ផលិតមាននៅក្នុងកំណែអាល់ហ្វា ឱកាស ដោយប្រើគ្រោងការណ៍ OpenAPI v3 សម្រាប់ ការបង្កើត និងបោះពុម្ពឯកសារ OpenAPI សម្រាប់ CustomResources (CR) ប្រើដើម្បីធ្វើសុពលភាព (ផ្នែកខាងម៉ាស៊ីនមេ) ធនធានដែលកំណត់ដោយអ្នកប្រើប្រាស់ K8s (CustomResourceDefinition, CRD)។ ការបោះពុម្ព OpenAPI សម្រាប់ CRD អនុញ្ញាតឱ្យអតិថិជន (ឧ. kubectl) អនុវត្តការបញ្ជាក់នៅខាងអ្នក (ក្នុង kubectl create и kubectl apply) និងចេញឯកសារតាមគ្រោងការណ៍ (kubectl explain) ព័ត៌មានលម្អិត - ក្នុង ខេអេ.

កំណត់ហេតុដែលមានស្រាប់ ឥឡូវនេះកំពុងបើក ជាមួយនឹងទង់ជាតិ O_APPEND (ប៉ុន្តែមិនមែនទេ។ O_TRUNC) ដើម្បីជៀសវាងការបាត់បង់កំណត់ហេតុក្នុងស្ថានភាពមួយចំនួន និងដើម្បីភាពងាយស្រួលនៃការកាត់កំណត់ហេតុជាមួយនឹងឧបករណ៍ប្រើប្រាស់ខាងក្រៅសម្រាប់ការបង្វិល។

ផងដែរនៅក្នុងបរិបទនៃ Kubernetes API វាអាចត្រូវបានកត់សម្គាល់ថានៅក្នុង PodSandbox и PodSandboxStatus បន្ថែម វាល runtime_handler ដើម្បីកត់ត្រាព័ត៌មានអំពី RuntimeClass នៅក្នុង pod (អានបន្ថែមអំពីវានៅក្នុងអត្ថបទអំពី ការចេញផ្សាយ Kubernetes 1.12ដែលជាកន្លែងដែលថ្នាក់នេះបានបង្ហាញខ្លួនជាកំណែអាល់ហ្វា) និងនៅក្នុង Admission Webhooks បានអនុវត្ត សមត្ថភាពក្នុងការកំណត់កំណែណាមួយ។ AdmissionReview ពួកគេគាំទ្រ។ ទីបំផុតច្បាប់ Admission Webhooks ឥឡូវនេះ អាចត្រូវបានកំណត់ វិសាលភាពនៃការប្រើប្រាស់របស់ពួកគេដោយ namespaces និង cluster frameworks ។

ការផ្ទុក

PersistentLocalVolumesដែលមានស្ថានភាពបេតាចាប់តាំងពីការចេញផ្សាយ K8s 1.10, បានប្រកាស មានស្ថេរភាព (GA)៖ ច្រកមុខងារនេះលែងត្រូវបានបិទហើយនឹងត្រូវបានយកចេញនៅក្នុង Kubernetes 1.17។

ឱកាស។ ដោយប្រើអថេរបរិស្ថានហៅថា API ចុះក្រោម (ឧទាហរណ៍ ឈ្មោះផត) សម្រាប់ឈ្មោះថតដែលបានម៉ោនជា subPath, ត្រូវបានបង្កើតឡើង - ក្នុងទម្រង់នៃវាលថ្មីមួយ subPathExprដែលឥឡូវនេះត្រូវបានប្រើដើម្បីកំណត់ឈ្មោះថតដែលចង់បាន។ មុខងារនេះបានបង្ហាញខ្លួនដំបូងនៅក្នុង Kubernetes 1.11 ប៉ុន្តែសម្រាប់ 1.14 វានៅតែស្ថិតក្នុងស្ថានភាពកំណែអាល់ហ្វា។

ដូចទៅនឹងការចេញផ្សាយ Kubernetes មុនដែរ ការផ្លាស់ប្តូរសំខាន់ៗជាច្រើនត្រូវបានណែនាំសម្រាប់ CSI (Container Storage Interface) ដែលកំពុងតែអភិវឌ្ឍយ៉ាងសកម្ម៖

CSI

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

លក្ខណៈពិសេសមួយទៀតសម្រាប់ CSI នៅក្នុងកំណែអាល់ហ្វា - ឱកាស យោងដោយផ្ទាល់ (ពោលគឺដោយមិនប្រើ PV/PVC) ទៅកាន់បរិមាណ CSI នៅក្នុងការបញ្ជាក់របស់ផត។ នេះ។ ដកការរឹតបន្តឹងលើការប្រើប្រាស់ CSI ជាការផ្ទុកទិន្នន័យពីចម្ងាយទាំងស្រុងបើកទ្វារទៅកាន់ពិភពលោកសម្រាប់ពួកគេ។ បរិមាណ ephemeral ក្នុងស្រុក. សម្រាប់ការប្រើប្រាស់ (ឧទាហរណ៍ពីឯកសារ) ត្រូវតែបើក CSIInlineVolume ច្រកទ្វារលក្ខណៈពិសេស។

វាក៏មានការវិវឌ្ឍន៍នៅក្នុង "ផ្នែកខាងក្នុង" នៃ Kubernetes ទាក់ទងនឹង CSI ដែលមិនអាចមើលឃើញចំពោះអ្នកប្រើប្រាស់ចុងក្រោយ (អ្នកគ្រប់គ្រងប្រព័ន្ធ) ... បច្ចុប្បន្ននេះ អ្នកអភិវឌ្ឍន៍ត្រូវបានបង្ខំឱ្យគាំទ្រកំណែពីរនៃកម្មវិធីជំនួយការផ្ទុកនីមួយៗ៖ មួយ - "នៅក្នុង វិធីចាស់” នៅខាងក្នុង K8s codebase (in -tree) និងទីពីរ - ជាផ្នែកនៃ CSI ថ្មី (សូមអានបន្ថែមអំពីវា ជាឧទាហរណ៍ ក្នុង នៅទីនេះ). នេះបណ្តាលឱ្យមានការរអាក់រអួលដែលអាចយល់បានដែលចាំបាច់ត្រូវដោះស្រាយនៅពេលដែល CSI ខ្លួនឯងមានស្ថេរភាព។ វាមិនអាចទៅរួចទេក្នុងការបដិសេធ API នៃកម្មវិធីជំនួយខាងក្នុង (នៅក្នុងមែកធាង) ដោយសារតែ គោលនយោបាយ Kubernetes ពាក់ព័ន្ធ.

ទាំងអស់នេះនាំឱ្យការពិតដែលថាកំណែអាល់ហ្វាឈានដល់ ដំណើរការចំណាកស្រុក កូដកម្មវិធីជំនួយខាងក្នុងដែលត្រូវបានអនុវត្តជាដើមឈើនៅក្នុងកម្មវិធីជំនួយ CSI អរគុណដែលការព្រួយបារម្ភរបស់អ្នកអភិវឌ្ឍន៍នឹងត្រូវបានកាត់បន្ថយទៅការគាំទ្រកំណែមួយនៃកម្មវិធីជំនួយរបស់ពួកគេ និងភាពឆបគ្នាជាមួយ APIs ចាស់នឹងនៅតែមាន ហើយពួកគេអាចត្រូវបានគេប្រកាសថាលែងប្រើក្នុងសេណារីយ៉ូធម្មតា។ វាត្រូវបានគេរំពឹងថាដោយការចេញផ្សាយបន្ទាប់នៃ Kubernetes (1.15) កម្មវិធីជំនួយអ្នកផ្តល់សេវាពពកទាំងអស់នឹងត្រូវបានផ្លាស់ប្តូរ ការអនុវត្តនឹងទទួលបានស្ថានភាពបេតា ហើយនឹងត្រូវបានធ្វើឱ្យសកម្មនៅក្នុងការដំឡើង K8s តាមលំនាំដើម។ សម្រាប់ព័ត៌មានលម្អិតសូមមើល សំណើរចនា. ការធ្វើចំណាកស្រុកនេះក៏បណ្តាលឱ្យមាន отказ ពីដែនកំណត់បរិមាណកំណត់ដោយអ្នកផ្តល់សេវាពពកជាក់លាក់ (AWS, Azure, GCE, Cinder) ។

លើសពីនេះទៀត ការគាំទ្រសម្រាប់ឧបករណ៍ទប់ស្កាត់ជាមួយ CSI (CSIBlockVolume) ផ្ទេរ ទៅកំណែបែតា។

ថ្នាំង/គូបេឡេត

កំណែអាល់ហ្វាត្រូវបានបង្ហាញ ចំណុចបញ្ចប់ថ្មី។ នៅ Kubelet ដែលត្រូវបានរចនាឡើងសម្រាប់ ត្រឡប់មាត្រដ្ឋានលើធនធានសំខាន់ៗ. និយាយជាទូទៅ ប្រសិនបើពីមុន Kubelet បានទទួលស្ថិតិស្តីពីការប្រើប្រាស់កុងតឺន័រពី cAdvisor ឥឡូវនេះទិន្នន័យនេះបានមកពីបរិយាកាសដំណើរការកុងតឺន័រតាមរយៈ CRI (Container Runtime Interface) ប៉ុន្តែភាពឆបគ្នាសម្រាប់ធ្វើការជាមួយកំណែចាស់របស់ Docker ក៏ត្រូវបានរក្សាទុកផងដែរ។ ពីមុន ស្ថិតិដែលប្រមូលបាននៅក្នុង Kubelet ត្រូវបានផ្ញើតាមរយៈ REST API ប៉ុន្តែឥឡូវនេះ ចំណុចបញ្ចប់ដែលមានទីតាំងនៅ /metrics/resource/v1alpha1. យុទ្ធសាស្ត្ររយៈពេលវែងរបស់អ្នកអភិវឌ្ឍន៍ មាន គឺដើម្បីបង្រួមអប្បបរមានៃសំណុំម៉ែត្រដែលផ្តល់ដោយ Kubelet ។ ដោយវិធីនេះម៉ែត្រទាំងនេះខ្លួនឯង ឥឡូវនេះពួកគេហៅ មិន​មែន​ជា "ការ​វាស់​ស្ទង់​ស្នូល" ទេ ប៉ុន្តែ​ជា "រង្វាស់​ធនធាន" ហើយ​ត្រូវ​បាន​ពិពណ៌នា​ថា​ជា "ធនធាន​ថ្នាក់​ទី​មួយ​ដូច​ជា cpu និង memory"។

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

"gRPC មិនឆបគ្នាជាមួយបំពង់ត្រួតពិនិត្យសំខាន់ៗទេ។ Endpoint នឹងមានប្រយោជន៍សម្រាប់តែការបញ្ជូនម៉ែត្រទៅ Metrics Server ឬសមាសធាតុត្រួតពិនិត្យដែលរួមបញ្ចូលដោយផ្ទាល់ជាមួយវា។ ដំណើរការទម្រង់អត្ថបទ Prometheus នៅពេលប្រើឃ្លាំងសម្ងាត់នៅក្នុង Metrics Server ល្អ​គ្រប់គ្រាន់ សម្រាប់ពួកយើងដើម្បីចូលចិត្ត Prometheus ជាង gRPC ដែលបានផ្តល់ឱ្យនូវការទទួលយក Prometheus យ៉ាងទូលំទូលាយនៅក្នុងសហគមន៍។ នៅពេលដែលទម្រង់ OpenMetrics កាន់តែមានស្ថេរភាព យើងនឹងអាចចូលទៅជិតដំណើរការ gRPC ជាមួយនឹងទម្រង់ផ្អែកលើប្រូតូ។

ការធ្វើតេស្តការអនុវត្តប្រៀបធៀបមួយនៃការប្រើប្រាស់ទម្រង់ gRPC និង Prometheus នៅក្នុងចំណុចបញ្ចប់ Kubelet ថ្មីសម្រាប់ម៉ែត្រ។ ក្រាហ្វបន្ថែម និងព័ត៌មានលម្អិតផ្សេងទៀតអាចរកបាននៅក្នុង ខេអេ.

ក្នុងចំណោមការផ្លាស់ប្តូរផ្សេងទៀត៖

• Kubelet ឥឡូវនេះ (តែម្តង) ព្យាយាមបញ្ឈប់ កុងតឺន័រនៅក្នុងស្ថានភាពមិនស្គាល់ មុនពេលចាប់ផ្តើមឡើងវិញ និងលុបប្រតិបត្តិការ។
• នៅពេលប្រើ PodPresets ឥឡូវនេះទៅធុងខាងក្នុង បានបន្ថែម ព័ត៌មានដូចគ្នានឹងធុងធម្មតាដែរ។
• គូបេឡេត បានចាប់ផ្តើមប្រើ usageNanoCores ពីអ្នកផ្តល់ស្ថិតិ CRI និងសម្រាប់ថ្នាំង និងកុងតឺន័រនៅលើវីនដូ បន្ថែម ស្ថិតិបណ្តាញ។
• ប្រព័ន្ធប្រតិបត្តិការ និងព័ត៌មានស្ថាបត្យកម្មឥឡូវនេះត្រូវបានកត់ត្រានៅក្នុងស្លាក kubernetes.io/os и kubernetes.io/arch វត្ថុថ្នាំង (ផ្ទេរពីបែតាទៅ GA) ។
• សមត្ថភាពក្នុងការបញ្ជាក់ក្រុមអ្នកប្រើប្រាស់ប្រព័ន្ធជាក់លាក់មួយសម្រាប់កុងតឺន័រនៅក្នុងផត (RunAsGroup, បានបង្ហាញខ្លួននៅក្នុង K8s 1.11) កម្រិតខ្ពស់ មុនពេលបេតា (បើកដំណើរការតាមលំនាំដើម)។
• du និងស្វែងរកប្រើក្នុង cAdvisor, ជំនួស ការអនុវត្ត Go ។

CLI

នៅក្នុង cli-runtime និង kubectl បានបន្ថែម -k ទង់សម្រាប់ការរួមបញ្ចូលជាមួយ ប្ដូរតាមបំណង (ដោយវិធីនេះការអភិវឌ្ឍន៍របស់វាឥឡូវនេះត្រូវបានអនុវត្តនៅក្នុងឃ្លាំងដាច់ដោយឡែក) i.e. ដើម្បីដំណើរការឯកសារ YAML បន្ថែមពីថតការកំណត់ពិសេស (សម្រាប់ព័ត៌មានលម្អិតអំពីការប្រើប្រាស់ពួកវា សូមមើល ខេអេ):

ឧទាហរណ៍នៃការប្រើប្រាស់ឯកសារសាមញ្ញ ការប្ដូរតាមបំណង (កម្មវិធីដែលស្មុគ្រស្មាញជាងមុននៃ kustomize គឺអាចធ្វើទៅបាននៅក្នុង ត្រួតលើគ្នា។)

លើសពីនេះទៀត:

• បន្ថែម ក្រុមថ្មី។ kubectl create cronjobដែលឈ្មោះរបស់វានិយាយដោយខ្លួនឯង។
• В kubectl logs ឥឡូវ​អ្នក​អាច ដើម្បីផ្សំ ទង់ជាតិ -f (--follow សម្រាប់កំណត់ហេតុស្ទ្រីម) និង -l (--selector សម្រាប់សំណួរស្លាក) ។
• kubectl បង្រៀន ចម្លង​ឯកសារ​ដែល​បាន​ជ្រើសរើស​ដោយ​កាត​ព្រៃ។
• ដល់ក្រុម kubectl wait បានបន្ថែម ទង់ --all ដើម្បីជ្រើសរើសធនធានទាំងអស់នៅក្នុង namespace នៃប្រភេទធនធានដែលបានបញ្ជាក់។

ផ្សេងទៀត

សមត្ថភាពខាងក្រោមបានទទួលស្ថានភាពស្ថិរភាព (GA)៖

• ReadinessGateប្រើនៅក្នុងការបញ្ជាក់របស់ pod ដើម្បីកំណត់លក្ខខណ្ឌបន្ថែមដែលយកទៅក្នុងគណនីការត្រៀមខ្លួនរបស់ pod;
• ការគាំទ្រសម្រាប់ទំព័រធំ (ច្រកទ្វារលក្ខណៈពិសេសហៅថា HugePages);
• CustomPodDNS;
• PriorityClass API អាទិភាព Pod & Preemption.

ការផ្លាស់ប្តូរផ្សេងទៀតដែលបានណែនាំនៅក្នុង Kubernetes 1.14៖

• គោលការណ៍ RBAC លំនាំដើមលែងអនុញ្ញាតឱ្យចូលប្រើ API ទៀតហើយ discovery и access-review អ្នកប្រើប្រាស់ដោយគ្មានការផ្ទៀងផ្ទាត់ (មិនបានផ្ទៀងផ្ទាត់).
• ការគាំទ្រ CoreDNS ផ្លូវការ ធានា លីនុចតែប៉ុណ្ណោះ ដូច្នេះនៅពេលប្រើ kubeadm ដើម្បីដាក់ពង្រាយវា (CoreDNS) នៅក្នុងចង្កោម ថ្នាំងត្រូវតែដំណើរការតែលើលីនុច (nodeSelectors ត្រូវបានប្រើសម្រាប់ការកំណត់នេះ)។
• ការកំណត់រចនាសម្ព័ន្ធ CoreDNS លំនាំដើមគឺឥឡូវនេះ ការប្រើប្រាស់ កម្មវិធីជំនួយទៅមុខ ជំនួសឱ្យប្រូកស៊ី។ ផងដែរនៅក្នុង CoreDNS បន្ថែម readinessProbe ដែលការពារតុល្យភាពបន្ទុកនៅលើផតដែលសមស្រប (មិនទាន់រួចរាល់សម្រាប់សេវាកម្ម)។
• នៅក្នុង kubeadm នៅលើដំណាក់កាល init ឬ upload-certs, បានក្លាយជាអាចធ្វើទៅបាន ផ្ទុកវិញ្ញាបនបត្រដែលត្រូវការដើម្បីភ្ជាប់យន្តហោះបញ្ជាថ្មីទៅនឹងការសម្ងាត់ kubeadm-certs (ប្រើទង់ --experimental-upload-certs).
• កំណែអាល់ហ្វាបានបង្ហាញខ្លួនសម្រាប់ការដំឡើងវីនដូ គាំទ្រ gMSA (គណនីសេវាកម្មគ្រប់គ្រងក្រុម) - គណនីពិសេសនៅក្នុង Active Directory ដែលអាចត្រូវបានប្រើដោយកុងតឺន័រផងដែរ។
• សម្រាប់ G.C.E. បានធ្វើឱ្យសកម្ម ការអ៊ិនគ្រីប mTLS រវាង etcd និង kube-apiserver ។
• ការអាប់ដេតនៅក្នុងកម្មវិធីដែលបានប្រើ/អាស្រ័យ៖ Go 1.12.1, CSI 1.1, CoreDNS 1.3.1, Docker 18.09 support in kubeadm ហើយកំណែ Docker API ដែលគាំទ្រអប្បបរមាឥឡូវនេះគឺ 1.26។

PS

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

• «Kubernetes 1.13៖ ទិដ្ឋភាពទូទៅនៃការច្នៃប្រឌិតសំខាន់ៗ»
• «Kubernetes 1.12៖ ទិដ្ឋភាពទូទៅនៃការច្នៃប្រឌិតសំខាន់ៗ»
• «Kubernetes 1.11៖ ទិដ្ឋភាពទូទៅនៃការច្នៃប្រឌិតសំខាន់ៗ»
• «Kubernetes 1.10៖ ទិដ្ឋភាពទូទៅនៃការច្នៃប្រឌិតសំខាន់ៗ"។

ប្រភព: www.habr.com