Amazon EKS Windows នៅក្នុង GA មានកំហុស ប៉ុន្តែលឿនបំផុត។

អរុណសួស្តី ខ្ញុំចង់ចែករំលែកជាមួយអ្នកនូវបទពិសោធន៍របស់ខ្ញុំក្នុងការដំឡើង និងប្រើប្រាស់សេវាកម្ម AWS EKS (Elastic Kubernetes Service) សម្រាប់កុងតឺន័រ Windows ឬជាជាងអំពីភាពមិនអាចទៅរួចនៃការប្រើប្រាស់វា និងកំហុសដែលបានរកឃើញនៅក្នុងធុងប្រព័ន្ធ AWS សម្រាប់អ្នកទាំងនោះ។ ដែលចាប់អារម្មណ៍លើសេវាកម្មនេះសម្រាប់ឧបករណ៍ផ្ទុកវីនដូ សូមនៅក្រោមឆ្មា។

ខ្ញុំដឹងថា Windows containers មិនមែនជាប្រធានបទដ៏ពេញនិយមទេ ហើយមានមនុស្សតិចណាស់ដែលប្រើវា ប៉ុន្តែខ្ញុំនៅតែសម្រេចចិត្តសរសេរអត្ថបទនេះ ដោយសារមានអត្ថបទពីរបីនៅលើ Habré នៅលើ kubernetes និង Windows ហើយនៅតែមានមនុស្សបែបនេះ។

Начало

វាទាំងអស់បានចាប់ផ្តើមនៅពេលដែលវាត្រូវបានសម្រេចចិត្តផ្លាស់ប្តូរសេវាកម្មនៅក្នុងក្រុមហ៊ុនរបស់យើងទៅ kubernetes ដែលជា 70% Windows និង 30% Linux ។ ចំពោះគោលបំណងនេះ សេវាកម្មពពក AWS EKS ត្រូវបានចាត់ទុកថាជាជម្រើសមួយក្នុងចំណោមជម្រើសដែលអាចធ្វើបាន។ រហូតដល់ថ្ងៃទី 8 ខែតុលា ឆ្នាំ 2019 AWS EKS Windows ស្ថិតនៅក្នុងការមើលជាសាធារណៈ ខ្ញុំបានចាប់ផ្តើមជាមួយវា កំណែ 1.11 ចាស់របស់ kubernetes ត្រូវបានប្រើប្រាស់នៅទីនោះ ប៉ុន្តែខ្ញុំបានសម្រេចចិត្តពិនិត្យមើលវា ហើយមើលថាតើសេវាពពកនេះស្ថិតក្នុងដំណាក់កាលណា ថាតើវាដំណើរការឬអត់ ទាល់តែសោះ ដូចដែលវាបានប្រែក្លាយ អត់ទេ វាមានកំហុសជាមួយនឹងការបន្ថែមការដក pods ចេញ ខណៈពេលដែលអ្នកចាស់បានឈប់ឆ្លើយតបតាមរយៈ ip ខាងក្នុងពី subnet ដូចគ្នាទៅនឹង windows worker node ។

ដូច្នេះវាត្រូវបានសម្រេចចិត្តបោះបង់ចោលការប្រើប្រាស់ AWS EKS ក្នុងការពេញចិត្តនៃចង្កោមផ្ទាល់ខ្លួនរបស់យើងនៅលើ kubernetes នៅលើ EC2 ដូចគ្នា មានតែយើងទេដែលត្រូវពណ៌នាអំពីតុល្យភាពទាំងអស់ និង HA ខ្លួនយើងតាមរយៈ CloudFormation ។

Amazon EKS Windows Container Support ឥឡូវនេះមានជាទូទៅ

ដោយ Martin Beeby | នៅថ្ងៃទី 08 ខែតុលា ឆ្នាំ 2019

មុនពេលដែលខ្ញុំមានពេលបន្ថែមគំរូមួយទៅ CloudFormation សម្រាប់ចង្កោមផ្ទាល់ខ្លួនរបស់ខ្ញុំ ខ្ញុំបានឃើញព័ត៌មាននេះ។ Amazon EKS Windows Container Support ឥឡូវនេះមានជាទូទៅ

ជាការពិតណាស់ ខ្ញុំបានទុកការងារទាំងអស់របស់ខ្ញុំមួយឡែក ហើយចាប់ផ្តើមសិក្សាពីអ្វីដែលពួកគេបានធ្វើសម្រាប់ GA និងរបៀបដែលអ្វីគ្រប់យ៉ាងបានផ្លាស់ប្តូរជាមួយនឹងការមើលជាសាធារណៈ។ បាទ AWS ធ្វើបានល្អ ធ្វើបច្ចុប្បន្នភាពរូបភាពសម្រាប់ windows worker node ទៅកំណែ 1.14 ក៏ដូចជា cluster ខ្លួនវា កំណែ 1.14 នៅក្នុង EKS ឥឡូវនេះគាំទ្រ windows node ។ គម្រោងដោយ Public Preview នៅ github ពួកគេបានបិទបាំងវា ហើយនិយាយថាឥឡូវនេះ សូមប្រើឯកសារផ្លូវការនៅទីនេះ៖ ការគាំទ្រវីនដូ EKS

ការរួមបញ្ចូលចង្កោម EKS ទៅក្នុង VPC និងបណ្តាញរងបច្ចុប្បន្ន

នៅក្នុងប្រភពទាំងអស់ នៅក្នុងតំណភ្ជាប់ខាងលើនៅលើសេចក្តីប្រកាស ក៏ដូចជានៅក្នុងឯកសារ វាត្រូវបានស្នើឱ្យដាក់ពង្រាយចង្កោមតាមរយៈឧបករណ៍ប្រើប្រាស់ eksctl ដែលមានកម្មសិទ្ធិ ឬតាមរយៈ CloudFormation + kubectl បន្ទាប់ពីប្រើតែបណ្តាញរងសាធារណៈនៅក្នុង Amazon ក៏ដូចជាការបង្កើត VPC ដាច់ដោយឡែកសម្រាប់ចង្កោមថ្មី។

ជម្រើសនេះមិនស័ក្តិសមសម្រាប់មនុស្សជាច្រើនទេ ទីមួយ VPC ដាច់ដោយឡែកមានន័យថាការចំណាយបន្ថែមសម្រាប់ការចំណាយរបស់វា + ចរាចរដែលភ្ជាប់ទៅ VPC បច្ចុប្បន្នរបស់អ្នក។ តើ​អ្នក​ដែល​មាន​ហេដ្ឋារចនាសម្ព័ន្ធ​ដែល​ត្រៀម​រួច​ជា​ស្រេច​ក្នុង AWS ជាមួយ​នឹង​គណនី AWS ច្រើន​របស់​ពួកគេ VPC បណ្តាញ​រង តារាង​ផ្លូវ ច្រក​ចេញចូល និង​ធ្វើ​អ្វី​ខ្លះ? ជាការពិតណាស់ អ្នកមិនចង់បំបែក ឬធ្វើឡើងវិញទាំងអស់នេះទេ ហើយអ្នកត្រូវបញ្ចូលចង្កោម EKS ថ្មីទៅក្នុងហេដ្ឋារចនាសម្ព័ន្ធបណ្តាញបច្ចុប្បន្ន ដោយប្រើ VPC ដែលមានស្រាប់ ហើយភាគច្រើនបង្កើតបណ្តាញរងថ្មីសម្រាប់ចង្កោម។

ក្នុងករណីរបស់ខ្ញុំ ផ្លូវនេះត្រូវបានជ្រើសរើស ខ្ញុំបានប្រើ VPC ដែលមានស្រាប់ បន្ថែមតែបណ្តាញរងសាធារណៈ 2 និងបណ្តាញរងឯកជន 2 សម្រាប់ចង្កោមថ្មី ជាការពិត ច្បាប់ទាំងអស់ត្រូវបានយកមកពិចារណាយោងទៅតាមឯកសារ បង្កើត Amazon EKS Cluster VPC របស់អ្នក។.

វាក៏មានលក្ខខណ្ឌមួយផងដែរ៖ មិនមានថ្នាំងកម្មករនៅក្នុងបណ្តាញរងសាធារណៈដោយប្រើ EIP ទេ។

eksctl ទល់នឹង CloudFormation

ខ្ញុំនឹងធ្វើការកក់ទុកភ្លាមៗ ដែលខ្ញុំបានសាកល្បងវិធីទាំងពីរនៃការដាក់ពង្រាយចង្កោម ក្នុងករណីទាំងពីររូបភាពគឺដូចគ្នា។

ខ្ញុំនឹងបង្ហាញឧទាហរណ៍ដោយប្រើ eksctl ពីព្រោះលេខកូដនៅទីនេះនឹងខ្លីជាង។ ដោយប្រើ eksctl ដាក់ពង្រាយចង្កោមជា 3 ជំហាន៖

1. យើងបង្កើតចង្កោមដោយខ្លួនវាផ្ទាល់ + ថ្នាំងកម្មករលីនុច ដែលក្រោយមកនឹងបង្ហោះប្រព័ន្ធកុងតឺន័រ និងឧបករណ៍បញ្ជា vpc-controller ដែលមានវាសនាដូចគ្នា។

eksctl create cluster 
--name yyy 
--region www 
--version 1.14 
--vpc-private-subnets=subnet-xxxxx,subnet-xxxxx 
--vpc-public-subnets=subnet-xxxxx,subnet-xxxxx 
--asg-access 
--nodegroup-name linux-workers 
--node-type t3.small 
--node-volume-size 20 
--ssh-public-key wwwwwwww 
--nodes 1 
--nodes-min 1 
--nodes-max 2 
--node-ami auto 
--node-private-networking

ដើម្បីដាក់ពង្រាយទៅ VPC ដែលមានស្រាប់ គ្រាន់តែបញ្ជាក់ id នៃ subnets របស់អ្នក ហើយ eksctl នឹងកំណត់ VPC ខ្លួនឯង។

ដើម្បីធានាថាថ្នាំងកម្មកររបស់អ្នកត្រូវបានដាក់ឱ្យប្រើតែទៅបណ្តាញរងឯកជន អ្នកត្រូវបញ្ជាក់ --node-private-networking សម្រាប់ nodegroup ។

2. យើងដំឡើង vpc-controller នៅក្នុងចង្កោមរបស់យើង ដែលនឹងដំណើរការថ្នាំងកម្មកររបស់យើង រាប់ចំនួនអាសយដ្ឋាន IP ឥតគិតថ្លៃ ក៏ដូចជាចំនួន ENIs នៅលើ instance បន្ថែម និងយកវាចេញ។

eksctl utils install-vpc-controllers --name yyy --approve

3. បន្ទាប់ពីធុងប្រព័ន្ធរបស់អ្នកបានដំណើរការដោយជោគជ័យនៅលើថ្នាំងអ្នកធ្វើការលីនុចរបស់អ្នក រួមទាំង vpc-controller អ្វីទាំងអស់ដែលនៅសល់គឺបង្កើតក្រុមមួយទៀតជាមួយកម្មករវីនដូ។

eksctl create nodegroup 
--region www 
--cluster yyy 
--version 1.14 
--name windows-workers 
--node-type t3.small 
--ssh-public-key wwwwwwwwww 
--nodes 1 
--nodes-min 1 
--nodes-max 2 
--node-ami-family WindowsServer2019CoreContainer 
--node-ami ami-0573336fc96252d05 
--node-private-networking

បន្ទាប់ពីថ្នាំងរបស់អ្នកបានភ្ជាប់ដោយជោគជ័យទៅចង្កោមរបស់អ្នក ហើយអ្វីៗហាក់ដូចជាល្អ វាស្ថិតនៅក្នុងស្ថានភាពរួចរាល់ ប៉ុន្តែមិនមែនទេ។

កំហុសនៅក្នុង vpc-controller

ប្រសិនបើយើងព្យាយាមដំណើរការ pods នៅលើ windows worker node យើងនឹងទទួលបានកំហុស៖

NetworkPlugin cni failed to teardown pod "windows-server-iis-7dcfc7c79b-4z4v7_default" network: failed to parse Kubernetes args: pod does not have label vpc.amazonaws.com/PrivateIPv4Address]

ប្រសិនបើយើងមើលឱ្យកាន់តែស៊ីជម្រៅ យើងឃើញថា instance របស់យើងនៅក្នុង AWS មើលទៅដូចនេះ៖

ហើយវាគួរតែដូចនេះ៖

ពីនេះវាច្បាស់ណាស់ថា vpc-controller មិនបានបំពេញផ្នែករបស់វាដោយហេតុផលមួយចំនួន ហើយមិនអាចបន្ថែមអាសយដ្ឋាន IP ថ្មីទៅ instance ដូច្នេះ pods អាចប្រើវាបាន។

តោះមើលកំណត់ហេតុរបស់ vpc-controller pod ហើយនេះជាអ្វីដែលយើងឃើញ៖

កំណត់ហេតុ kubectl -n kube-system

I1011 06:32:03.910140       1 watcher.go:178] Node watcher processing node ip-10-xxx.ap-xxx.compute.internal.
I1011 06:32:03.910162       1 manager.go:109] Node manager adding node ip-10-xxx.ap-xxx.compute.internal with instanceID i-088xxxxx.
I1011 06:32:03.915238       1 watcher.go:238] Node watcher processing update on node ip-10-xxx.ap-xxx.compute.internal.
E1011 06:32:08.200423       1 manager.go:126] Node manager failed to get resource vpc.amazonaws.com/CIDRBlock  pool on node ip-10-xxx.ap-xxx.compute.internal: failed to find the route table for subnet subnet-0xxxx
E1011 06:32:08.201211       1 watcher.go:183] Node watcher failed to add node ip-10-xxx.ap-xxx.compute.internal: failed to find the route table for subnet subnet-0xxx
I1011 06:32:08.201229       1 watcher.go:259] Node watcher adding key ip-10-xxx.ap-xxx.compute.internal (0): failed to find the route table for subnet subnet-0xxxx
I1011 06:32:08.201302       1 manager.go:173] Node manager updating node ip-10-xxx.ap-xxx.compute.internal.
E1011 06:32:08.201313       1 watcher.go:242] Node watcher failed to update node ip-10-xxx.ap-xxx.compute.internal: node manager: failed to find node ip-10-xxx.ap-xxx.compute.internal.

ការស្វែងរកនៅលើ Google មិនបាននាំទៅរកអ្វីនោះទេ ដោយសារជាក់ស្តែង គ្មាននរណាម្នាក់បានចាប់កំហុសបែបនេះនៅឡើយទេ ឬមិនទាន់បានបង្ហោះបញ្ហានៅលើវា ខ្ញុំត្រូវតែគិតពីជម្រើសដោយខ្លួនឯងជាមុនសិន។ រឿងដំបូងដែលនឹកឃើញគឺថា ប្រហែលជា vpc-controller មិនអាចដោះស្រាយ ip-10-xxx.ap-xxx.compute.internal ហើយឈានដល់វា ដូច្នេះហើយមានកំហុសកើតឡើង។

បាទ/ចាស យើងប្រើម៉ាស៊ីនមេ DNS ផ្ទាល់ខ្លួននៅក្នុង VPC ហើយជាគោលការណ៍យើងមិនប្រើ Amazon ទេ ដូច្នេះសូម្បីតែការបញ្ជូនបន្តក៏មិនត្រូវបានកំណត់សម្រាប់ដែន ap-xxx.compute.internal នេះដែរ។ ខ្ញុំបានសាកល្បងជម្រើសនេះ ហើយវាមិននាំមកនូវលទ្ធផលទេ ប្រហែលជាការធ្វើតេស្តនេះមិនស្អាតទេ ដូច្នេះហើយ នៅពេលទំនាក់ទំនងជាមួយជំនួយបច្ចេកទេស ខ្ញុំបានចុះចាញ់នឹងគំនិតរបស់ពួកគេ។

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

លើសពីនេះទៅទៀត ប្រសិនបើអ្នកដាក់ពង្រាយថ្នាំងកម្មករទៅបណ្តាញរងសាធារណៈដោយមិនប្រើ -node-private-networking ថ្នាំងនេះត្រូវបានធ្វើបច្ចុប្បន្នភាពភ្លាមៗដោយ vpc-controller ហើយអ្វីៗដំណើរការដូចការងារនាឡិកា។

មានជម្រើសពីរ៖

1. បោះបង់វា ហើយរង់ចាំរហូតដល់នរណាម្នាក់ពណ៌នាអំពីកំហុសនេះនៅក្នុង AWS ហើយពួកគេជួសជុលវា ហើយបន្ទាប់មកអ្នកអាចប្រើ AWS EKS Windows ដោយសុវត្ថិភាព ព្រោះពួកគេទើបតែចេញផ្សាយនៅក្នុង GA (8 ថ្ងៃបានកន្លងផុតទៅនៅពេលសរសេរអត្ថបទនេះ) មនុស្សជាច្រើនប្រហែលជានឹង ដើរតាមផ្លូវដូចគ្នានឹងខ្ញុំ។
2. សរសេរទៅកាន់ផ្នែកជំនួយ AWS ហើយប្រាប់ពួកគេពីខ្លឹមសារនៃបញ្ហាជាមួយនឹងកំណត់ហេតុទាំងមូលពីគ្រប់ទិសទី ហើយបង្ហាញឱ្យពួកគេដឹងថាសេវាកម្មរបស់ពួកគេមិនដំណើរការនៅពេលប្រើ VPC និងបណ្តាញរងរបស់អ្នក វាមិនមែនសម្រាប់គ្មានអ្វីដែលយើងមានការគាំទ្រផ្នែកអាជីវកម្មទេ អ្នកគួរតែប្រើ យ៉ាងហោចណាស់ម្តង :)

ទំនាក់ទំនងជាមួយវិស្វករ AWS

ដោយបានបង្កើតសំបុត្រនៅលើវិបផតថល ខ្ញុំច្រឡំជ្រើសរើសឆ្លើយតបមកខ្ញុំតាមរយៈគេហទំព័រ - អ៊ីមែល ឬមជ្ឈមណ្ឌលជំនួយ តាមរយៈជម្រើសនេះ ពួកគេអាចឆ្លើយអ្នកបន្ទាប់ពីពីរបីថ្ងៃទាំងអស់ ទោះបីជាការពិតថាសំបុត្ររបស់ខ្ញុំមានភាពធ្ងន់ធ្ងរ - ប្រព័ន្ធចុះខ្សោយក៏ដោយ ដែល មានន័យថាមានការឆ្លើយតបក្នុងរយៈពេល <12 ម៉ោង ហើយចាប់តាំងពីផែនការជំនួយអាជីវកម្មមានការគាំទ្រ 24/7 ខ្ញុំសង្ឃឹមថាល្អបំផុត ប៉ុន្តែវាបានប្រែក្លាយដូចរាល់ដង។

សំបុត្ររបស់ខ្ញុំត្រូវបានទុកចោលដោយមិនបានកំណត់ចាប់ពីថ្ងៃសុក្ររហូតដល់ថ្ងៃច័ន្ទ បន្ទាប់មកខ្ញុំបានសម្រេចចិត្តសរសេរទៅកាន់ពួកគេម្តងទៀត ហើយជ្រើសរើសជម្រើសឆ្លើយតបការជជែក។ បន្ទាប់ពីរង់ចាំរយៈពេលខ្លី Harshad Madhav ត្រូវបានតែងតាំងឱ្យមកជួបខ្ញុំ ហើយបន្ទាប់មកវាបានចាប់ផ្តើម...

យើងបានបំបាត់កំហុសជាមួយវាតាមអ៊ីនធឺណិតរយៈពេល 3 ម៉ោងជាប់គ្នា ផ្ទេរកំណត់ហេតុ ការដាក់ពង្រាយចង្កោមដូចគ្នានៅក្នុងមន្ទីរពិសោធន៍ AWS ដើម្បីត្រាប់តាមបញ្ហា បង្កើតចង្កោមឡើងវិញនៅលើផ្នែករបស់ខ្ញុំ ហើយដូច្នេះនៅលើនោះ រឿងតែមួយគត់ដែលយើងបានមកនោះគឺមកពី កំណត់ហេតុវាច្បាស់ណាស់ថា Resol មិនដំណើរការឈ្មោះដែនខាងក្នុងរបស់ AWS ដែលខ្ញុំបានសរសេរអំពីខាងលើ ហើយ Harshad Madhav បានសុំឱ្យខ្ញុំបង្កើតការបញ្ជូនបន្ត ដោយចោទប្រកាន់ថាយើងប្រើ DNS ផ្ទាល់ខ្លួន ហើយនេះអាចជាបញ្ហា។

បញ្ជូនបន្ត

ap-xxx.compute.internal  -> 10.x.x.2 (VPC CIDRBlock)
amazonaws.com -> 10.x.x.2 (VPC CIDRBlock)

នោះហើយជាអ្វីដែលបានធ្វើ មួយថ្ងៃបានកន្លងផុតទៅហើយ។ Harshad Madhav បានសរសេរត្រឡប់មកវិញដើម្បីពិនិត្យមើលវា ហើយវាគួរតែដំណើរការ ប៉ុន្តែទេ ដំណោះស្រាយមិនបានជួយអ្វីទាំងអស់។

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

ដែលខ្ញុំបានសុំឱ្យគាត់ចាកចេញដោយគួរសម ហើយចាត់ឱ្យអ្នកផ្សេងទៅសំបុត្ររបស់ខ្ញុំ ប្រសិនបើអ្នកមិនដឹងថាត្រូវរកមើលបញ្ហានៅឯណា។

ចុងក្រោយ

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

តើនៅពេលណាដែលយើងឈានដល់ចំណុចនៃការបើកដំណើរការ -stderrthreshold=debug នៅក្នុង vpc-controller របស់ពួកគេ ហើយតើមានអ្វីកើតឡើងបន្ទាប់ទៀត? ជា​ការ​ពិត​ណាស់​វា​មិន​ដំណើរ​ការ​) pod គ្រាន់​តែ​មិន​ចាប់​ផ្តើ​ម​ជា​មួយ​នឹង​ជម្រើស​នេះ​, តែ -stderrthreshold=info ដំណើរការ។

យើងបានបញ្ចប់នៅទីនេះហើយ Arun B. បាននិយាយថាគាត់នឹងព្យាយាមបង្កើតជំហានរបស់ខ្ញុំឡើងវិញដើម្បីទទួលបានកំហុសដូចគ្នា។ នៅថ្ងៃបន្ទាប់ខ្ញុំទទួលបានការឆ្លើយតបពី Arun B. គាត់មិនបានបោះបង់ចោលករណីនេះទេ ប៉ុន្តែបានយកលេខកូដត្រួតពិនិត្យ vpc-controller របស់ពួកគេ ហើយបានរកឃើញកន្លែងដែលវានៅ ហើយហេតុអ្វីបានជាវាមិនដំណើរការ៖

ដូច្នេះ ប្រសិនបើអ្នកប្រើតារាងផ្លូវសំខាន់នៅក្នុង VPC របស់អ្នក នោះតាមលំនាំដើម វាមិនមានទំនាក់ទំនងជាមួយបណ្តាញរងចាំបាច់ទេ ដែលចាំបាច់សម្រាប់ vpc-controller ក្នុងករណីនៃបណ្តាញរងសាធារណៈ វាមានតារាងផ្លូវផ្ទាល់ខ្លួន។ ដែលមានសមាគម។

ដោយការបន្ថែមសមាគមដោយដៃសម្រាប់តារាងផ្លូវមេជាមួយបណ្តាញរងចាំបាច់ និងបង្កើតក្រុមឡើងវិញ អ្វីៗដំណើរការយ៉ាងល្អឥតខ្ចោះ។

ខ្ញុំសង្ឃឹមថា Arun B. ពិតជានឹងរាយការណ៍អំពីកំហុសនេះទៅកាន់អ្នកអភិវឌ្ឍន៍ EKS ហើយយើងនឹងឃើញកំណែថ្មីនៃ vpc-controller ដែលអ្វីៗនឹងដំណើរការចេញពីប្រអប់។ បច្ចុប្បន្នកំណែចុងក្រោយបំផុតគឺ៖ 602401143452.dkr.ecr.ap-southeast-1.amazonaws.com/eks/vpc-resource-controller:0.2.1
មានបញ្ហានេះ។

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

ប្រភព: www.habr.com