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

ថ្ងៃនេះ, ថ្ងៃពុធ, នឹងកើតឡើង។ ការចេញផ្សាយបន្ទាប់របស់ Kubernetes - 1.16 ។ យោងតាមប្រពៃណីដែលបានបង្កើតឡើងសម្រាប់ប្លុករបស់យើង នេះគឺជាខួបលើកទីដប់ដែលយើងកំពុងនិយាយអំពីការផ្លាស់ប្តូរដ៏សំខាន់បំផុតនៅក្នុងកំណែថ្មី។

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

ថ្នាំង

មួយចំនួនធំនៃការច្នៃប្រឌិតគួរឱ្យកត់សម្គាល់ (នៅក្នុងស្ថានភាពកំណែអាល់ហ្វា) ត្រូវបានបង្ហាញនៅផ្នែកម្ខាងនៃថ្នាំងចង្កោម K8s (Kubelet) ។

ដំបូងគេហៅថា «ធុងទឹកស្អុយ» (កុងតឺន័រដ៏អភ័ព្វ)រចនាឡើងដើម្បីសម្រួលដំណើរការកែកំហុសនៅក្នុងផត. យន្តការថ្មីអនុញ្ញាតឱ្យអ្នកបើកដំណើរការធុងពិសេសដែលចាប់ផ្តើមនៅក្នុងចន្លោះឈ្មោះនៃផតឃ័រដែលមានស្រាប់ និងរស់នៅក្នុងរយៈពេលខ្លី។ គោលបំណងរបស់ពួកគេគឺដើម្បីធ្វើអន្តរកម្មជាមួយផត និងធុងផ្សេងទៀត ដើម្បីដោះស្រាយបញ្ហា និងបំបាត់កំហុស។ ពាក្យបញ្ជាថ្មីត្រូវបានអនុវត្តសម្រាប់មុខងារនេះ។ kubectl debug, ស្រដៀងគ្នានៅក្នុងខ្លឹមសារ kubectl exec៖ ជំនួសឱ្យដំណើរការនៅក្នុងកុងតឺន័រ (ដូចនៅក្នុង exec) វាបើកកុងតឺន័រនៅក្នុងផត។ ឧទាហរណ៍ ពាក្យបញ្ជានេះនឹងភ្ជាប់កុងតឺន័រថ្មីទៅផតៈ

kubectl debug -c debug-shell --image=debian target-pod -- bash

ព័ត៌មានលម្អិតអំពីធុងផ្ទុកមិនប្រក្រតី (និងឧទាហរណ៍នៃការប្រើប្រាស់របស់វា) អាចរកបាននៅក្នុង KEP ដែលត្រូវគ្នា។. ការអនុវត្តបច្ចុប្បន្ន (នៅក្នុង K8s 1.16) គឺជាកំណែអាល់ហ្វា ហើយក្នុងចំណោមលក្ខណៈវិនិច្ឆ័យសម្រាប់ការផ្ទេររបស់វាទៅកំណែបែតាគឺ "ការសាកល្បង Ephemeral Containers API សម្រាប់ការចេញផ្សាយ [Kubernetes] យ៉ាងហោចណាស់ 2 ដង។"

NB៖ នៅក្នុងខ្លឹមសាររបស់វា និងសូម្បីតែឈ្មោះរបស់វា មុខងារនេះប្រហាក់ប្រហែលនឹងកម្មវិធីជំនួយដែលមានស្រាប់ kubectl-បំបាត់កំហុសអំពីអ្វីដែលយើង បានសរសេររួចហើយ. វាត្រូវបានគេរំពឹងថាជាមួយនឹងការមកដល់នៃកុងតឺន័រដែលមានភាពច្របូកច្របល់ ការអភិវឌ្ឍន៍កម្មវិធីជំនួយខាងក្រៅដាច់ដោយឡែកនឹងឈប់ដំណើរការ។

ការច្នៃប្រឌិតមួយទៀត - PodOverhead - រចនាឡើងដើម្បីផ្តល់ យន្តការសម្រាប់គណនាថ្លៃដើមសម្រាប់ផតដែលអាចប្រែប្រួលយ៉ាងខ្លាំងអាស្រ័យលើរយៈពេលដំណើរការដែលបានប្រើ។ ជាឧទាហរណ៍អ្នកនិពន្ធ កែបនេះ។ លទ្ធផលនៅក្នុង Kata Containers ដែលតម្រូវឱ្យដំណើរការខឺណែលភ្ញៀវ ភ្នាក់ងារ kata ប្រព័ន្ធ init ។ល។ នៅពេលដែលថ្លៃដើមក្លាយជាធំ វាមិនអាចត្រូវបានព្រងើយកន្តើយ ដែលមានន័យថាចាំបាច់ត្រូវមានវិធីមួយដើម្បីយកទៅពិចារណាសម្រាប់កូតាបន្ថែម ការធ្វើផែនការ។ល។ ដើម្បីអនុវត្តវានៅក្នុង PodSpec វាលបន្ថែម Overhead *ResourceList (ប្រៀបធៀបជាមួយទិន្នន័យនៅក្នុង RuntimeClassប្រសិនបើមួយត្រូវបានប្រើ) ។

ការច្នៃប្រឌិតគួរឱ្យកត់សម្គាល់មួយទៀតគឺ កម្មវិធីគ្រប់គ្រង node topology (កម្មវិធីគ្រប់គ្រង Node Topology)រចនាឡើងដើម្បីបង្រួបបង្រួមវិធីសាស្រ្តក្នុងការកែសម្រួលការបែងចែកធនធានផ្នែករឹងសម្រាប់សមាសធាតុផ្សេងៗនៅក្នុង Kubernetes ។ គំនិតផ្តួចផ្តើមនេះត្រូវបានជំរុញដោយតម្រូវការដែលកំពុងកើនឡើងនៃប្រព័ន្ធទំនើបផ្សេងៗ (ពីវិស័យទូរគមនាគមន៍ ការរៀនម៉ាស៊ីន សេវាកម្មហិរញ្ញវត្ថុ។ សមត្ថភាពបង្កើនល្បឿនផ្នែករឹង។ ការបង្កើនប្រសិទ្ធភាពបែបនេះនៅក្នុង Kubernetes រហូតមកដល់ពេលនេះត្រូវបានសម្រេចដោយអរគុណចំពោះធាតុផ្សំដែលខុសគ្នា (កម្មវិធីគ្រប់គ្រង CPU, Device manager, CNI) ហើយឥឡូវនេះពួកគេនឹងត្រូវបានបន្ថែមចំណុចប្រទាក់ខាងក្នុងតែមួយដែលបង្រួបបង្រួមវិធីសាស្រ្ត និងសម្រួលដល់ការតភ្ជាប់នៃស្រដៀងគ្នាថ្មី ដែលហៅថា topology- ដឹង - សមាសធាតុនៅខាង Kubelet ។ ព័ត៌មានលម្អិត - ក្នុង KEP ដែលត្រូវគ្នា។.

ដ្យាក្រាមសមាសភាគអ្នកគ្រប់គ្រង Topology

មុខងារបន្ទាប់ - ពិនិត្យធុងខណៈពេលដែលពួកគេកំពុងដំណើរការ (ការស៊ើបអង្កេតចាប់ផ្តើម). ដូចដែលអ្នកបានដឹងហើយថា សម្រាប់កុងតឺន័រដែលប្រើពេលយូរក្នុងការបើកដំណើរការ វាពិបាកក្នុងការទទួលបានស្ថានភាពទាន់សម័យ៖ ពួកគេត្រូវបាន "សម្លាប់" មុនពេលពួកគេចាប់ផ្តើមដំណើរការ ឬពួកគេបញ្ចប់ដោយការជាប់គាំងក្នុងរយៈពេលយូរ។ ការត្រួតពិនិត្យថ្មី (បានបើកតាមរយៈច្រកលក្ខណៈពិសេសហៅថា StartupProbeEnabled) លុបចោល - ឬផ្ទុយទៅវិញ ពន្យារ - ឥទ្ធិពលនៃការត្រួតពិនិត្យផ្សេងទៀតរហូតដល់ពេលដែលផតបានដំណើរការ។ សម្រាប់ហេតុផលនេះលក្ខណៈពិសេសនេះត្រូវបានគេហៅថាដើម pod-startup liveness-probe holdoff. សម្រាប់ផតដែលចំណាយពេលយូរដើម្បីចាប់ផ្តើម អ្នកអាចស្ទង់មតិរដ្ឋក្នុងចន្លោះពេលខ្លី។

លើសពីនេះ ការកែលម្អសម្រាប់ RuntimeClass គឺមានភ្លាមៗនៅក្នុងស្ថានភាពបេតា ដោយបន្ថែមការគាំទ្រសម្រាប់ "ចង្កោមផ្សេងៗគ្នា" ។ គ កាលវិភាគ RuntimeClass ឥឡូវនេះ វាមិនចាំបាច់ទាល់តែសោះសម្រាប់ node នីមួយៗដើម្បីឱ្យមានការគាំទ្រសម្រាប់ RuntimeClass នីមួយៗ៖ សម្រាប់ pods អ្នកអាចជ្រើសរើស RuntimeClass ដោយមិនចាំបាច់គិតពី cluster topology ។ ពីមុន ដើម្បីសម្រេចបាននូវចំណុចនេះ - ដូច្នេះ pods បញ្ចប់នៅលើថ្នាំងជាមួយនឹងការគាំទ្រសម្រាប់អ្វីគ្រប់យ៉ាងដែលពួកគេត្រូវការ - វាចាំបាច់ក្នុងការចាត់ចែងច្បាប់សមស្របដល់ NodeSelector និងការអត់ឱន។ IN ខេអេ វានិយាយអំពីឧទាហរណ៍នៃការប្រើប្រាស់ ហើយជាការពិតណាស់ ព័ត៌មានលម្អិតអំពីការអនុវត្ត។

បណ្តាញ

មុខងារបណ្តាញសំខាន់ៗចំនួនពីរដែលបានបង្ហាញខ្លួនជាលើកដំបូង (នៅក្នុងកំណែអាល់ហ្វា) នៅក្នុង Kubernetes 1.16 គឺ៖

• ការគាំទ្រ ជង់បណ្តាញពីរ - IPv4/IPv6 - និង "ការយល់ដឹង" ដែលត្រូវគ្នារបស់វានៅកម្រិត pods, nodes, services ។ វារួមបញ្ចូល IPv4-to-IPv4 និង IPv6-to-IPv6 អន្តរប្រតិបត្តិការរវាងផត ពីផត ដល់សេវាខាងក្រៅ ការអនុវត្តសេចក្តីយោង (នៅក្នុងកម្មវិធីជំនួយ Bridge CNI, PTP CNI និង Host-Local IPAM plugins) ក៏ដូចជាបញ្ច្រាសដែលត្រូវគ្នាជាមួយក្រុម Kubernetes ដែលដំណើរការ។ IPv4 ឬ IPv6 ប៉ុណ្ណោះ។ ព័ត៌មានលម្អិតនៃការអនុវត្តគឺនៅក្នុង ខេអេ.

  ឧទាហរណ៍នៃការបង្ហាញអាសយដ្ឋាន IP នៃពីរប្រភេទ (IPv4 និង IPv6) នៅក្នុងបញ្ជីផតៈ

  kube-master# kubectl get pods -o wide
  NAME               READY     STATUS    RESTARTS   AGE       IP                          NODE
  nginx-controller   1/1       Running   0          20m       fd00:db8:1::2,192.168.1.3   kube-minion-1
  kube-master#

• API ថ្មីសម្រាប់ Endpoint - EndpointSlice API. វាដោះស្រាយបញ្ហាការអនុវត្ត/ការធ្វើមាត្រដ្ឋាននៃ Endpoint API ដែលមានស្រាប់ ដែលប៉ះពាល់ដល់សមាសធាតុផ្សេងៗនៅក្នុងយន្តហោះបញ្ជា (apiserver, etcd, endpoints-controller, kube-proxy)។ API ថ្មីនឹងត្រូវបានបញ្ចូលទៅក្នុងក្រុម Discovery API ហើយនឹងអាចបម្រើចំណុចបញ្ចប់នៃកម្មវិធីខាងក្រោយរាប់ម៉ឺននៅលើសេវាកម្មនីមួយៗនៅក្នុងចង្កោមដែលមានថ្នាំងរាប់ពាន់។ ដើម្បីធ្វើដូច្នេះ សេវានីមួយៗត្រូវបានគូសផែនទីទៅវត្ថុ N EndpointSliceដែលនីមួយៗតាមលំនាំដើមមានចំណុចបញ្ចប់មិនលើសពី 100 (តម្លៃអាចកំណត់បាន)។ EndpointSlice API ក៏នឹងផ្តល់ឱកាសសម្រាប់ការអភិវឌ្ឍន៍នាពេលអនាគតរបស់វាផងដែរ៖ ការគាំទ្រសម្រាប់អាសយដ្ឋាន IP ច្រើនសម្រាប់ផតនីមួយៗ រដ្ឋថ្មីសម្រាប់ចំណុចបញ្ចប់ (មិនត្រឹមតែប៉ុណ្ណោះ Ready и NotReady) ការកំណត់រងថាមវន្តសម្រាប់ចំណុចបញ្ចប់។

កំណែដែលបានបង្ហាញនៅក្នុងការចេញផ្សាយចុងក្រោយបានឈានដល់កំណែបែតា វគ្គផ្តាច់ព្រ័ត្រ, មានឈ្មោះ service.kubernetes.io/load-balancer-cleanup និងភ្ជាប់ជាមួយសេវាកម្មនីមួយៗជាមួយប្រភេទ LoadBalancer. នៅពេលលុបសេវាកម្មបែបនេះ វាការពារការលុបធនធានពិតប្រាកដរហូតដល់ "ការសម្អាត" នៃធនធានតុល្យភាពដែលពាក់ព័ន្ធទាំងអស់ត្រូវបានបញ្ចប់។

គ្រឿងម៉ាស៊ីន API

"ដំណាក់កាលស្ថេរភាព" ពិតប្រាកដគឺនៅក្នុងតំបន់នៃម៉ាស៊ីនមេ Kubernetes API និងអន្តរកម្មជាមួយវា។ នេះបានកើតឡើងភាគច្រើនអរគុណចំពោះ ផ្ទេរទៅស្ថានភាពស្ថិរភាពអ្នកដែលមិនត្រូវការការណែនាំពិសេស និយមន័យធនធានផ្ទាល់ខ្លួន (CRD)ដែលមានស្ថានភាពបេតាចាប់តាំងពីថ្ងៃឆ្ងាយនៃ Kubernetes 1.7 (ហើយនេះគឺខែមិថុនា 2017!) ស្ថេរភាពដូចគ្នាបានមកដល់លក្ខណៈពិសេសដែលទាក់ទង:

• "ធនធាន​រង" សែ /status и /scale សម្រាប់ CustomResources;
• ការប្រែចិត្តជឿ កំណែសម្រាប់ CRD ដោយផ្អែកលើ webhook ខាងក្រៅ;
• បានបង្ហាញនាពេលថ្មីៗនេះ (ក្នុង K8s 1.15) តម្លៃលំនាំដើម (លំនាំដើម) និងការដកវាលដោយស្វ័យប្រវត្តិ (កាត់ចេញ) សម្រាប់ CustomResources;
• ឱកាស ដោយប្រើគ្រោងការណ៍ OpenAPI v3 ដើម្បីបង្កើត និងបោះពុម្ពឯកសារ OpenAPI ដែលប្រើដើម្បីធ្វើសុពលភាពធនធាន CRD នៅលើផ្នែកម៉ាស៊ីនមេ។

យន្តការមួយទៀតដែលធ្លាប់ស្គាល់ជាយូរមកហើយចំពោះអ្នកគ្រប់គ្រង Kubernetes៖ webhook ចូល - នៅតែស្ថិតក្នុងស្ថានភាពបេតាអស់រយៈពេលជាយូរ (ចាប់តាំងពី K8s 1.9) ហើយឥឡូវនេះត្រូវបានប្រកាសថាមានស្ថេរភាព។

មុខងារពីរផ្សេងទៀតបានឈានដល់បេតា៖ ខាង server អនុវត្ត и មើលចំណាំ.

ហើយការច្នៃប្រឌិតដ៏សំខាន់តែមួយគត់នៅក្នុងកំណែអាល់ហ្វាគឺ отказ ពី SelfLink - URI ពិសេសតំណាងឱ្យវត្ថុដែលបានបញ្ជាក់ និងជាផ្នែកមួយនៃ ObjectMeta и ListMeta (ឧ. ជាផ្នែកនៃវត្ថុណាមួយនៅក្នុង Kubernetes)។ ហេតុអ្វីបានជាពួកគេបោះបង់ចោលវា? ការលើកទឹកចិត្តតាមរបៀបសាមញ្ញ សំឡេង ដូចជាអវត្តមាននៃហេតុផលពិតប្រាកដ (លើសលប់) សម្រាប់វិស័យនេះនៅតែមាន។ ហេតុផលផ្លូវការបន្ថែមទៀតគឺដើម្បីបង្កើនប្រសិទ្ធភាពប្រតិបត្តិការ (ដោយការដកវាលដែលមិនចាំបាច់ចេញ) និងសម្រួលការងាររបស់ generic-apiserver ដែលត្រូវបានបង្ខំឱ្យគ្រប់គ្រងវាលបែបនេះតាមរបៀបពិសេស (នេះគឺជាវាលតែមួយគត់ដែលត្រូវបានកំណត់នៅចំពោះមុខវត្ថុ។ ត្រូវបានដាក់ជាស៊េរី) ។ ភាពអស់សុពលភាពពិតប្រាកដ (នៅក្នុងបេតា) SelfLink នឹងកើតឡើងដោយ Kubernetes កំណែ 1.20 និងចុងក្រោយ - 1.21 ។

ការផ្ទុកទិន្នន័យ

ការងារសំខាន់នៅក្នុងតំបន់នៃការផ្ទុកដូចនៅក្នុងការចេញផ្សាយមុន ៗ ត្រូវបានគេសង្កេតឃើញនៅក្នុងតំបន់ ការគាំទ្រ CSI. ការផ្លាស់ប្តូរសំខាន់ៗនៅទីនេះគឺ៖

• ជាលើកដំបូង (នៅក្នុងកំណែអាល់ហ្វា) បានបង្ហាញខ្លួន កម្មវិធីជំនួយ CSI គាំទ្រសម្រាប់ថ្នាំងកម្មករវីនដូ៖ វិធីបច្ចុប្បន្ននៃការធ្វើការជាមួយឧបករណ៍ផ្ទុកក៏នឹងជំនួសកម្មវិធីជំនួយក្នុងមែកធាងផងដែរនៅក្នុងស្នូល Kubernetes និងកម្មវិធីជំនួយ FlexVolume ពី Microsoft ដោយផ្អែកលើ Powershell;

  
  គ្រោងការណ៍សម្រាប់ការអនុវត្តកម្មវិធីជំនួយ CSI នៅក្នុង Kubernetes សម្រាប់ Windows

• ឱកាស ផ្លាស់ប្តូរទំហំបរិមាណ CSIដែលបានណែនាំឡើងវិញនៅក្នុង K8s 1.12 បានរីកចម្រើនទៅជាកំណែបែតា។
• "ការផ្សព្វផ្សាយ" ស្រដៀងគ្នា (ពីអាល់ហ្វាទៅបេតា) ត្រូវបានសម្រេចដោយសមត្ថភាពក្នុងការប្រើប្រាស់ CSI ដើម្បីបង្កើតបរិមាណ ephemeral ក្នុងតំបន់ (ការគាំទ្រកម្រិតសំឡេងក្នុងបណ្តាញ CSI).

បានណែនាំនៅក្នុងកំណែមុនរបស់ Kubernetes មុខងារក្លូនកម្រិតសំឡេង (ប្រើ PVC ដែលមានស្រាប់ DataSource ដើម្បីបង្កើត PVC ថ្មី) ឥឡូវនេះក៏ទទួលបានស្ថានភាពបេតាផងដែរ។

អ្នករៀបចំកាលវិភាគ

ការផ្លាស់ប្តូរគួរឱ្យកត់សម្គាល់ពីរចំពោះការកំណត់ពេល (ទាំងនៅក្នុងអាល់ហ្វា)៖

• EvenPodsSpreading - ឱកាស ប្រើ pods ជំនួសឱ្យឯកតាកម្មវិធីឡូជីខលសម្រាប់ "ការចែកចាយដោយយុត្តិធម៌" នៃបន្ទុក (ដូចជាការដាក់ពង្រាយ និងឈុតចម្លង) និងការកែសម្រួលការចែកចាយនេះ (ជាតម្រូវការរឹង ឬជាលក្ខខណ្ឌទន់ ពោលគឺអាទិភាព)។ មុខងារនេះនឹងពង្រីកសមត្ថភាពចែកចាយដែលមានស្រាប់នៃផតឃែរដែលបានគ្រោងទុក ដែលបច្ចុប្បន្នត្រូវបានកំណត់ដោយជម្រើស PodAffinity и PodAntiAffinityផ្តល់ឱ្យអ្នកគ្រប់គ្រងនូវការគ្រប់គ្រងកាន់តែល្អិតល្អន់ក្នុងបញ្ហានេះ ដែលមានន័យថាភាពអាចរកបានខ្ពស់កាន់តែប្រសើរ និងការប្រើប្រាស់ធនធានដែលប្រសើរឡើង។ ព័ត៌មានលម្អិត - ក្នុង ខេអេ.
• ប្រើ គោលការណ៍ BestFit в អនុគមន៍​អាទិភាព​នៃ​ការ​ស្នើ​សុំ​ToCapacityRatio ក្នុងអំឡុងពេលធ្វើផែនការ pod ដែលនឹងអនុញ្ញាត ប្រើ ការវេចខ្ចប់ធុងសំរាម ("ការវេចខ្ចប់ក្នុងធុង") សម្រាប់ទាំងធនធានមូលដ្ឋាន (ឧបករណ៍ដំណើរការ អង្គចងចាំ) និងឧបករណ៍បន្ថែម (ដូចជា GPU)។ សម្រាប់ព័ត៌មានលម្អិតសូមមើល ខេអេ.

  
  ការកំណត់កាលវិភាគ៖ មុនពេលប្រើគោលការណ៍សមបំផុត (ដោយផ្ទាល់តាមរយៈកម្មវិធីកំណត់ពេលលំនាំដើម) និងជាមួយនឹងការប្រើប្រាស់របស់វា (តាមរយៈកម្មវិធីពង្រីកកាលវិភាគ)

លើសពីនេះទៀត, បង្ហាញ សមត្ថភាពក្នុងការបង្កើតកម្មវិធីជំនួយកម្មវិធីកំណត់ពេលផ្ទាល់ខ្លួនរបស់អ្នកនៅខាងក្រៅមែកធាងអភិវឌ្ឍន៍ Kubernetes សំខាន់ (ក្រៅដើមឈើ)។

ការផ្លាស់ប្តូរផ្សេងទៀត

ផងដែរនៅក្នុងការចេញផ្សាយ Kubernetes 1.16 អ្នកអាចកត់សម្គាល់ គំនិតផ្តួចផ្តើមសម្រាប់ នាំយក ម៉ែត្រដែលមាននៅក្នុងលំដាប់ពេញលេញឬច្បាស់ជាងនេះ ស្របតាម បទប្បញ្ញត្តិផ្លូវការ ឧបករណ៍ K8s ។ ពួកគេភាគច្រើនពឹងផ្អែកលើការដែលត្រូវគ្នា។ ឯកសារ Prometheus. ភាពមិនស៊ីសង្វាក់គ្នាបានកើតឡើងដោយសារហេតុផលផ្សេងៗ (ឧទាហរណ៍ រង្វាស់មួយចំនួនត្រូវបានបង្កើតឡើងយ៉ាងសាមញ្ញ មុនពេលការណែនាំបច្ចុប្បន្នលេចឡើង) ហើយអ្នកអភិវឌ្ឍន៍បានសម្រេចចិត្តថាវាដល់ពេលដែលត្រូវនាំយកអ្វីគ្រប់យ៉ាងទៅជាស្តង់ដារតែមួយ "ស្របតាមប្រព័ន្ធអេកូឡូស៊ី Prometheus" ។ ការអនុវត្តបច្ចុប្បន្ននៃគំនិតផ្តួចផ្តើមនេះស្ថិតក្នុងស្ថានភាពអាល់ហ្វា ដែលនឹងត្រូវបានផ្សព្វផ្សាយជាលំដាប់នៅក្នុងកំណែបន្តបន្ទាប់នៃ Kubernetes ទៅជាបេតា (1.17) និងស្ថេរភាព (1.18) ។

លើសពីនេះទៀតការផ្លាស់ប្តូរខាងក្រោមអាចត្រូវបានកត់សម្គាល់:

• វីនដូគាំទ្រការអភិវឌ្ឍន៍ с រូបរាង ឧបករណ៍ប្រើប្រាស់ Kubeadm សម្រាប់ប្រព័ន្ធប្រតិបត្តិការនេះ (កំណែអាល់ហ្វា) ឱកាស RunAsUserName សម្រាប់ឧបករណ៍ផ្ទុកវីនដូ (កំណែអាល់ហ្វា) ការកែលម្អ គណនីសេវាកម្មគ្រប់គ្រងក្រុម (gMSA) គាំទ្ររហូតដល់កំណែបែតា គាំទ្រ ម៉ោន / ភ្ជាប់សម្រាប់ភាគ vSphere ។
• កែច្នៃឡើងវិញ យន្តការបង្ហាប់ទិន្នន័យក្នុងការឆ្លើយតប API. ពីមុន តម្រង HTTP ត្រូវបានប្រើសម្រាប់គោលបំណងទាំងនេះ ដែលដាក់កម្រិតមួយចំនួនដែលរារាំងវាពីការបើកដំណើរការតាមលំនាំដើម។ ឥឡូវនេះ "ការបង្ហាប់សំណើតម្លាភាព" ដំណើរការ៖ ការផ្ញើអតិថិជន Accept-Encoding: gzip នៅក្នុងបឋមកថា ពួកគេទទួលបានការឆ្លើយតបដែលបានបង្ហាប់ GZIP ប្រសិនបើទំហំរបស់វាលើសពី 128 KB ។ អតិថិជន Go គាំទ្រការបង្ហាប់ដោយស្វ័យប្រវត្តិ (ផ្ញើបឋមកថាដែលត្រូវការ) ដូច្នេះពួកគេនឹងកត់សម្គាល់ភ្លាមៗនូវការថយចុះនៃចរាចរណ៍។ (អាចមានការកែប្រែបន្តិចបន្តួចសម្រាប់ភាសាផ្សេងទៀត។ )
• បានក្លាយជាអាចធ្វើទៅបាន ធ្វើមាត្រដ្ឋាន HPA ពី/ទៅសូន្យ ផត ដោយផ្អែកលើរង្វាស់ខាងក្រៅ. ប្រសិនបើអ្នកធ្វើមាត្រដ្ឋានដោយផ្អែកលើវត្ថុ/ម៉ែត្រខាងក្រៅ នោះនៅពេលដែលបន្ទុកការងារនៅទំនេរ អ្នកអាចធ្វើមាត្រដ្ឋានទៅ 0 ចម្លងដោយស្វ័យប្រវត្តិ ដើម្បីរក្សាទុកធនធាន។ លក្ខណៈពិសេសនេះគួរតែមានប្រយោជន៍ជាពិសេសសម្រាប់ករណីដែលកម្មករស្នើសុំធនធាន GPU ហើយចំនួននៃប្រភេទផ្សេងគ្នានៃកម្មករទំនេរលើសពីចំនួន GPU ដែលមាន។
• អតិថិជនថ្មី - k8s.io/client-go/metadata.Client - សម្រាប់ការចូលប្រើ "ទូទៅ" ទៅកាន់វត្ថុ។ វាត្រូវបានរចនាឡើងដើម្បីទាញយកទិន្នន័យមេតាបានយ៉ាងងាយស្រួល (ឧ metadata) ពីធនធានចង្កោម ហើយអនុវត្តការប្រមូលសំរាម និងប្រតិបត្តិការកូតាជាមួយពួកគេ។
• បង្កើត Kubernetes ឥឡូវ​អ្នក​អាច ដោយគ្មានកេរ្តិ៍ដំណែល (“ភ្ជាប់មកជាមួយ” នៅក្នុងមែកធាង) អ្នកផ្តល់សេវាពពក (កំណែអាល់ហ្វា)។
• ទៅឧបករណ៍ប្រើប្រាស់ kubeadm បានបន្ថែម សមត្ថភាពពិសោធន៍ (កំណែអាល់ហ្វា) ដើម្បីអនុវត្តបំណះតាមបំណងអំឡុងពេលប្រតិបត្តិការ init, join и upgrade. ស្វែងយល់បន្ថែមអំពីរបៀបប្រើទង់ជាតិ --experimental-kustomizeសូមមើលនៅក្នុង ខេអេ.
• ចំណុចបញ្ចប់ថ្មីសម្រាប់ apiserver - readyz, - អនុញ្ញាតឱ្យអ្នកនាំចេញព័ត៌មានអំពីការត្រៀមខ្លួនរបស់វា។ ម៉ាស៊ីនមេ API ឥឡូវនេះក៏មានទង់ផងដែរ។ --maximum-startup-sequence-durationអនុញ្ញាតឱ្យអ្នកគ្រប់គ្រងការចាប់ផ្តើមឡើងវិញរបស់វា។
• ពីរនាក់ លក្ខណៈពិសេសសម្រាប់ Azure បានប្រកាសថាមានស្ថេរភាព៖ ការគាំទ្រ តំបន់ដែលអាចរកបាន (តំបន់ដែលមាន) និង ក្រុមធនធានឆ្លង (RG) ។ លើសពីនេះ Azure បានបន្ថែមថា:
  • ការគាំទ្រការផ្ទៀងផ្ទាត់ AAD និង ADFS;
  • ចំណារពន្យល់ service.beta.kubernetes.io/azure-pip-name ដើម្បីបញ្ជាក់ IP សាធារណៈរបស់ឧបករណ៍ផ្ទុកតុល្យភាព;
  • ឱកាស ការកំណត់ LoadBalancerName и LoadBalancerResourceGroup.
• AWS ឥឡូវនេះមាន ការគាំទ្រ សម្រាប់ EBS នៅលើ Windows និង បានធ្វើឱ្យប្រសើរ ការហៅ EC2 API DescribeInstances.
• ឥឡូវនេះ Kubeadm គឺឯករាជ្យ ធ្វើចំណាកស្រុក ការកំណត់រចនាសម្ព័ន្ធ CoreDNS នៅពេលធ្វើបច្ចុប្បន្នភាពកំណែ CoreDNS ។
• គោលពីរ ល នៅក្នុងរូបភាព Docker ដែលត្រូវគ្នា។ បានធ្វើ world-executable ដែលអនុញ្ញាតឱ្យអ្នកដំណើរការរូបភាពនេះដោយមិនចាំបាច់មានសិទ្ធិជា root ។ ផងដែរ, etcd រូបភាពការធ្វើចំណាកស្រុក ឈប់ ការគាំទ្រកំណែ etcd2 ។
• В Cluster Autoscaler 1.16.0 បានប្តូរទៅប្រើ distroless ជារូបភាពមូលដ្ឋាន ដំណើរការប្រសើរឡើង បន្ថែមអ្នកផ្តល់សេវាពពកថ្មី (DigitalOcean, Magnum, Packet)។
• ការអាប់ដេតនៅក្នុងកម្មវិធីដែលបានប្រើ/អាស្រ័យ៖ Go 1.12.9, etcd 3.3.15, CoreDNS 1.6.2 ។

PS

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

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

ប្រភព: www.habr.com