GA இல் உள்ள Amazon EKS Windows இல் பிழைகள் உள்ளன, ஆனால் வேகமானது

நல்ல மதியம், விண்டோஸ் கண்டெய்னர்களுக்கான AWS EKS (Elastic Kubernetes Service) சேவையை அமைப்பதில் மற்றும் பயன்படுத்துவதில் எனது அனுபவத்தை உங்களுடன் பகிர்ந்து கொள்ள விரும்புகிறேன், அல்லது அதைப் பயன்படுத்த முடியாதது மற்றும் AWS சிஸ்டம் கண்டெய்னரில் காணப்படும் பிழை விண்டோஸ் கொள்கலன்களுக்கான இந்த சேவையில் ஆர்வமுள்ளவர்கள், தயவுசெய்து பூனையின் கீழ்.

விண்டோஸ் கொள்கலன்கள் பிரபலமான தலைப்பு அல்ல என்பதை நான் அறிவேன், மேலும் சிலர் அவற்றைப் பயன்படுத்துகிறார்கள், ஆனால் நான் இன்னும் இந்த கட்டுரையை எழுத முடிவு செய்தேன், ஏனெனில் குபெர்னெட்ஸ் மற்றும் விண்டோஸில் ஹப்ரே பற்றி இரண்டு கட்டுரைகள் இருந்தன, இன்னும் அத்தகைய நபர்கள் உள்ளனர்.

Начало

எங்கள் நிறுவனத்தில் உள்ள சேவைகளை 70% விண்டோஸ் மற்றும் 30% லினக்ஸ் கொண்ட kubernetes க்கு மாற்ற முடிவு செய்தபோது இது அனைத்தும் தொடங்கியது. இந்த நோக்கத்திற்காக, AWS EKS கிளவுட் சேவை சாத்தியமான விருப்பங்களில் ஒன்றாக கருதப்பட்டது. அக்டோபர் 8, 2019 வரை, AWS EKS விண்டோஸ் பொது முன்னோட்டத்தில் இருந்தது, நான் அதைத் தொடங்கினேன், பழைய 1.11 kubernetes பதிப்பு அங்கு பயன்படுத்தப்பட்டது, ஆனால் அதை எப்படியும் சரிபார்த்து, இந்த கிளவுட் சேவை எந்த கட்டத்தில் வேலை செய்கிறது என்பதைப் பார்க்க முடிவு செய்தேன். அது மாறியது போல், இல்லை, காய்களை அகற்றுவதில் ஒரு பிழை இருந்தது, அதே சமயம் பழையவை விண்டோஸ் வொர்க்கர் நோட் போன்ற சப்நெட்டிலிருந்து உள் ஐபி வழியாக பதிலளிப்பதை நிறுத்திவிட்டன.

எனவே, அதே EC2 இல் உள்ள kubernetes இல் எங்கள் சொந்த கிளஸ்டருக்கு ஆதரவாக AWS EKS ஐப் பயன்படுத்துவதைக் கைவிட முடிவு செய்யப்பட்டது, CloudFormation மூலம் அனைத்து சமநிலை மற்றும் HA ஐ நாமே விவரிக்க வேண்டும்.

Amazon EKS விண்டோஸ் கொள்கலன் ஆதரவு இப்போது பொதுவாகக் கிடைக்கிறது

மார்ட்டின் பீபி மூலம் | 08 OCT 2019 அன்று

எனது சொந்த கிளஸ்டருக்காக CloudFormation இல் ஒரு டெம்ப்ளேட்டைச் சேர்க்க நேரம் கிடைக்கும் முன், இந்தச் செய்தியைப் பார்த்தேன் Amazon EKS விண்டோஸ் கொள்கலன் ஆதரவு இப்போது பொதுவாகக் கிடைக்கிறது

நிச்சயமாக, நான் எனது எல்லா வேலைகளையும் ஒதுக்கி வைத்துவிட்டு, அவர்கள் GA க்காக என்ன செய்தார்கள், பொது முன்னோட்டத்தில் எல்லாம் எப்படி மாறியது என்பதைப் படிக்க ஆரம்பித்தேன். ஆம், AWS, சிறப்பாகச் செய்யப்பட்டுள்ளது, விண்டோஸ் வர்க்கர் முனைக்கான படங்களை பதிப்பு 1.14 க்கு மேம்படுத்தியது, அதே போல் கிளஸ்டரும், EKS இல் பதிப்பு 1.14, இப்போது விண்டோஸ் முனைகளை ஆதரிக்கிறது. பொது முன்னோட்டம் மூலம் திட்டம் கிதுப் அவர்கள் அதை மூடிமறைத்து, இப்போது அதிகாரப்பூர்வ ஆவணங்களை இங்கே பயன்படுத்துங்கள் என்று சொன்னார்கள்: EKS விண்டோஸ் ஆதரவு

தற்போதைய VPC மற்றும் சப்நெட்களில் EKS கிளஸ்டரை ஒருங்கிணைத்தல்

அனைத்து ஆதாரங்களிலும், அறிவிப்பு மற்றும் ஆவணத்தில் மேலே உள்ள இணைப்பில், தனியுரிம eksctl பயன்பாடு மூலமாகவோ அல்லது CloudFormation + kubectl மூலமாகவோ கிளஸ்டரை வரிசைப்படுத்த முன்மொழியப்பட்டது, அமேசானில் உள்ள பொது சப்நெட்களை மட்டுமே பயன்படுத்துகிறது, அத்துடன் ஒரு ஒரு புதிய கிளஸ்டருக்கான தனி VPC.

இந்த விருப்பம் பலருக்குப் பொருந்தாது; முதலாவதாக, ஒரு தனி VPC என்பது அதன் செலவுக்கான கூடுதல் செலவுகள் + உங்கள் தற்போதைய VPCக்கான போக்குவரத்து நெரிசலைக் குறிக்கிறது. ஏற்கனவே AWS இல் தங்களின் சொந்த பல AWS கணக்குகள், VPC, சப்நெட்கள், ரூட் டேபிள்கள், ட்ரான்ஸிட் கேட்வே மற்றும் பலவற்றுடன் ஆயத்த உள்கட்டமைப்பு உள்ளவர்கள் என்ன செய்ய வேண்டும்? நிச்சயமாக, நீங்கள் இதையெல்லாம் உடைக்கவோ அல்லது மீண்டும் செய்யவோ விரும்பவில்லை, மேலும் தற்போதைய நெட்வொர்க் உள்கட்டமைப்பில் புதிய EKS கிளஸ்டரை ஒருங்கிணைக்க வேண்டும், ஏற்கனவே உள்ள VPC ஐப் பயன்படுத்தி, பிரிப்பதற்காக, கிளஸ்டருக்கான புதிய சப்நெட்களை உருவாக்க வேண்டும்.

என் விஷயத்தில், இந்த பாதை தேர்ந்தெடுக்கப்பட்டது, நான் ஏற்கனவே உள்ள VPC ஐப் பயன்படுத்தினேன், புதிய கிளஸ்டருக்கு 2 பொது சப்நெட்கள் மற்றும் 2 தனிப்பட்ட சப்நெட்களை மட்டுமே சேர்த்துள்ளேன், நிச்சயமாக, ஆவணங்களின்படி அனைத்து விதிகளும் கணக்கில் எடுத்துக்கொள்ளப்பட்டன. உங்கள் Amazon EKS கிளஸ்டர் VPC ஐ உருவாக்கவும்.

ஒரு நிபந்தனையும் இருந்தது: EIP ஐப் பயன்படுத்தும் பொது சப்நெட்களில் பணியாளர் முனைகள் இல்லை.

eksctl vs CloudFormation

ஒரு கிளஸ்டரை வரிசைப்படுத்துவதற்கான இரண்டு முறைகளையும் முயற்சித்தேன் என்பதை இப்போதே முன்பதிவு செய்வேன், இரண்டு சந்தர்ப்பங்களிலும் படம் ஒன்றுதான்.

இங்கே குறியீடு குறைவாக இருக்கும் என்பதால் eksctl ஐப் பயன்படுத்தி ஒரு உதாரணத்தை மட்டும் காட்டுகிறேன். eksctl ஐப் பயன்படுத்தி, கிளஸ்டரை 3 படிகளில் பயன்படுத்தவும்:

1. நாங்கள் கிளஸ்டரை உருவாக்குகிறோம் + லினக்ஸ் பணியாளரின் முனை, இது பின்னர் கணினி கொள்கலன்களையும் அதே மோசமான vpc-கண்ட்ரோலரையும் வழங்கும்.

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 க்கு வரிசைப்படுத்த, உங்கள் சப்நெட்களின் ஐடியை குறிப்பிடவும், eksctl ஆனது VPC ஐயே தீர்மானிக்கும்.

உங்கள் பணியாளர் முனைகள் ஒரு தனிப்பட்ட சப்நெட்டில் மட்டுமே பயன்படுத்தப்படுவதை உறுதிசெய்ய, nodegroupக்கு --node-private-networking ஐ நீங்கள் குறிப்பிட வேண்டும்.

2. நாங்கள் எங்கள் கிளஸ்டரில் vpc-கண்ட்ரோலரை நிறுவுகிறோம், அது எங்கள் பணியாளரின் முனைகளைச் செயல்படுத்தும், இலவச IP முகவரிகளின் எண்ணிக்கையையும், அதே போல் ENIகளின் எண்ணிக்கையையும் எண்ணி, அவற்றைச் சேர்த்து நீக்குகிறது.

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

3.விபிசி-கண்ட்ரோலர் உட்பட, உங்கள் லினக்ஸ் பணியாளரின் முனையில் உங்கள் சிஸ்டம் கன்டெய்னர்கள் வெற்றிகரமாகத் தொடங்கப்பட்ட பிறகு, விண்டோஸ் பணியாளர்களுடன் மற்றொரு நோட்குரூப்பை உருவாக்குவதே எஞ்சியுள்ளது.

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-கண்ட்ரோலரில் பிழை

விண்டோஸ் ஒர்க்கர் நோடில் பாட்களை இயக்க முயற்சித்தால், பிழையைப் பெறுவோம்:

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]

நாம் ஆழமாகப் பார்த்தால், AWS இல் உள்ள எங்கள் உதாரணம் இப்படி இருப்பதைக் காண்கிறோம்:

மேலும் இது இப்படி இருக்க வேண்டும்:

சில காரணங்களால் vpc-கண்ட்ரோலர் அதன் பங்கை நிறைவேற்றவில்லை என்பதும், புதிய ஐபி முகவரிகளைச் சேர்க்க முடியவில்லை என்பதும் இதிலிருந்து தெளிவாகிறது, இதனால் காய்கள் அவற்றைப் பயன்படுத்த முடியும்.

விபிசி-கண்ட்ரோலர் பாட்டின் பதிவுகளைப் பார்ப்போம், இதைத்தான் நாம் காண்கிறோம்:

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.

கூகுளில் தேடுதல்கள் எதற்கும் வழிவகுக்கவில்லை, ஏனெனில் இதுபோன்ற பிழையை இதுவரை யாரும் பிடிக்கவில்லை, அல்லது அதில் சிக்கலை இடுகையிடவில்லை, முதலில் விருப்பங்களை நானே சிந்திக்க வேண்டியிருந்தது. முதலில் மனதில் தோன்றிய விஷயம் என்னவென்றால், ஒருவேளை vpc-கண்ட்ரோலரால் ip-10-xxx.ap-xxx.compute.internal ஐத் தீர்த்து அதை அடைய முடியாது, அதனால் பிழைகள் ஏற்படுகின்றன.

ஆம், உண்மையில், VPC இல் தனிப்பயன் DNS சேவையகங்களைப் பயன்படுத்துகிறோம், கொள்கையளவில், Amazon ஐப் பயன்படுத்துவதில்லை, எனவே இந்த ap-xxx.compute.internal டொமைனுக்காக பகிர்தல் கூட கட்டமைக்கப்படவில்லை. நான் இந்த விருப்பத்தை சோதித்தேன், அது முடிவுகளை கொண்டு வரவில்லை, ஒருவேளை சோதனை சுத்தமாக இல்லை, எனவே, மேலும், தொழில்நுட்ப ஆதரவுடன் தொடர்பு கொள்ளும்போது, ​​நான் அவர்களின் யோசனைக்கு அடிபணிந்தேன்.

உண்மையில் எந்த யோசனையும் இல்லாததால், அனைத்து பாதுகாப்பு குழுக்களும் eksctl ஆல் உருவாக்கப்பட்டன, எனவே அவற்றின் சேவைத்திறன் குறித்து எந்த சந்தேகமும் இல்லை, பாதை அட்டவணைகளும் சரியாக இருந்தன, nat, dns, வேலை செய்பவர் முனைகளுடன் இணைய அணுகலும் இருந்தது.

மேலும், -நோட்-பிரைவேட்-நெட்வொர்க்கிங்கைப் பயன்படுத்தாமல், பொது சப்நெட்டில் ஒரு பணியாளரின் முனையை நீங்கள் பயன்படுத்தினால், இந்த முனை உடனடியாக vpc-கண்ட்ரோலரால் புதுப்பிக்கப்பட்டு, அனைத்தும் கடிகார வேலைகளைப் போலவே வேலை செய்யும்.

இரண்டு விருப்பங்கள் இருந்தன:

1. அதை விட்டுவிட்டு, AWS இல் இந்த பிழையை யாராவது விவரிக்கும் வரை காத்திருங்கள், அவர்கள் அதை சரிசெய்யும் வரை, நீங்கள் AWS EKS விண்டோஸைப் பாதுகாப்பாகப் பயன்படுத்தலாம், ஏனெனில் அவர்கள் GA இல் வெளியிடப்பட்டனர் (இந்த கட்டுரையை எழுதும் நேரத்தில் 8 நாட்கள் கடந்துவிட்டன), பலர் அநேகமாக என்னைப் போலவே அதே பாதையில் செல்லுங்கள்.
2. AWS ஆதரவுக்கு எழுதி, எல்லா இடங்களிலிருந்தும் உள்ள மொத்தப் பதிவுகளின் மூலம் பிரச்சனையின் சாராம்சத்தை அவர்களுக்குச் சொல்லுங்கள், மேலும் உங்கள் VPC மற்றும் சப்நெட்களைப் பயன்படுத்தும் போது அவர்களின் சேவை வேலை செய்யாது என்பதை அவர்களுக்கு நிரூபிக்கவும், நாங்கள் வணிக ஆதரவைக் கொண்டிருப்பது ஒன்றும் இல்லை, நீங்கள் பயன்படுத்த வேண்டும். ஒரு முறையாவது :)

AWS பொறியாளர்களுடன் தொடர்பு

போர்ட்டலில் ஒரு டிக்கெட்டை உருவாக்கியதால், வலை - மின்னஞ்சல் அல்லது ஆதரவு மையம் வழியாக எனக்குப் பதிலளிப்பதை நான் தவறாகத் தேர்ந்தெடுத்தேன், இந்த விருப்பத்தின் மூலம் அவர்கள் சில நாட்களுக்குப் பிறகு உங்களுக்கு பதிலளிக்க முடியும், எனது டிக்கெட்டின் தீவிரத்தன்மை - கணினி குறைபாடு இருந்தபோதிலும், <12 மணி நேரத்திற்குள் பதில் கிடைக்கும், மேலும் வணிக ஆதரவுத் திட்டத்திற்கு 24/7 ஆதரவு இருப்பதால், நான் சிறப்பாகச் செயல்படும் என்று நம்புகிறேன், ஆனால் அது எப்போதும் போல் மாறியது.

எனது டிக்கெட் வெள்ளிக்கிழமை முதல் திங்கள் வரை ஒதுக்கப்படாமல் விடப்பட்டது, பின்னர் அவர்களுக்கு மீண்டும் எழுத முடிவு செய்து அரட்டை மறுமொழி விருப்பத்தைத் தேர்ந்தெடுத்தேன். சிறிது நேரம் காத்திருந்த பிறகு, ஹர்ஷத் மாதவ் என்னைப் பார்க்க நியமிக்கப்பட்டார், பின்னர் அது தொடங்கியது ...

தொடர்ந்து 3 மணிநேரம் ஆன்லைனில் பிழைத்திருத்தம் செய்தோம், பதிவுகளை மாற்றினோம், அதே கிளஸ்டரை AWS ஆய்வகத்தில் பயன்படுத்துகிறோம், சிக்கலைப் பின்பற்றுகிறோம், எனது தரப்பில் கிளஸ்டரை மீண்டும் உருவாக்குகிறோம், மேலும் நாங்கள் வந்த ஒரே விஷயம் என்னவென்றால் பதிவுகளில், ரெசோல் AWS இன்டர்னல் டொமைன் பெயர்களில் வேலை செய்யவில்லை என்பது தெளிவாகத் தெரிந்தது, இதைப் பற்றி நான் மேலே எழுதியுள்ளேன், மேலும் ஹர்ஷத் மாதவ் என்னை ஃபார்வர்டிங்கை உருவாக்கச் சொன்னார், நாங்கள் தனிப்பயன் DNS ஐப் பயன்படுத்துகிறோம், இது ஒரு சிக்கலாக இருக்கலாம்.

முன்னனுப்புவதும்

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

அதுதான் முடிந்தது, நாள் முடிந்தது. ஹர்ஷத் மாதவ் அதைச் சரிபார்த்து, அது வேலை செய்ய வேண்டும் என்று பதில் எழுதினார், ஆனால் இல்லை, தீர்மானம் உதவவில்லை.

பின்னர் மேலும் 2 பொறியாளர்களுடன் தொடர்பு இருந்தது, ஒருவர் அரட்டையிலிருந்து வெளியேறினார், வெளிப்படையாக அவர் ஒரு சிக்கலான வழக்கைக் கண்டு பயந்தார், இரண்டாவது எனது நாளை மீண்டும் பிழைத்திருத்தம், பதிவுகளை அனுப்புதல், இருபுறமும் கிளஸ்டர்களை உருவாக்குதல் போன்ற முழு சுழற்சியில் கழித்தார். இறுதியில் அவர் நன்றாகச் சொன்னார், இது எனக்கு வேலை செய்கிறது, இங்கே நான் அதிகாரப்பூர்வ ஆவணத்தில் படிப்படியாக எல்லாவற்றையும் செய்கிறேன், நீங்களும் நீங்களும் வெற்றி பெறுவீர்கள்.

அதற்கு நான் அவரை விட்டுவிட்டு, பிரச்சனையை எங்கு தேடுவது என்று உங்களுக்குத் தெரியாவிட்டால் எனது டிக்கெட்டுக்கு வேறு ஒருவரை ஒதுக்குமாறு பணிவுடன் கேட்டுக் கொண்டேன்.

இறுதி

மூன்றாவது நாளில், எனக்கு ஒரு புதிய பொறியாளர் அருண் பி. நியமிக்கப்பட்டார், அவருடனான தொடர்பு ஆரம்பத்தில் இருந்தே, இது முந்தைய 3 பொறியாளர்கள் அல்ல என்பது உடனடியாகத் தெரிந்தது. அவர் முழு வரலாற்றையும் படித்தார் மற்றும் உடனடியாக தனது சொந்த ஸ்கிரிப்ட் ps1 இல் பதிவுகளை சேகரிக்கச் சொன்னார், அது அவரது கிதுப்பில் இருந்தது. இதைத் தொடர்ந்து கிளஸ்டர்களை உருவாக்குதல், கட்டளை முடிவுகளை வெளியிடுதல், பதிவுகளை சேகரித்தல் என அனைத்து மறு செய்கைகளும் மீண்டும் தொடர்ந்தன, ஆனால் அருண் பி. என்னிடம் கேட்கப்பட்ட கேள்விகளின் அடிப்படையில் சரியான திசையில் நகர்ந்தார்.

அவர்களின் vpc-கண்ட்ரோலரில் -stderrthreshold=debug ஐ இயக்கும் நிலைக்கு நாம் எப்போது வந்தோம், அடுத்து என்ன நடந்தது? நிச்சயமாக இது வேலை செய்யாது) இந்த விருப்பத்துடன் பாட் தொடங்காது, -stderrthreshold=info மட்டுமே செயல்படுகிறது.

நாங்கள் இங்கே முடித்தோம், அதே பிழையைப் பெற எனது படிகளை மீண்டும் உருவாக்க முயற்சிக்கிறேன் என்று அருண் பி. மறுநாள் அருண் பியிடம் இருந்து எனக்கு பதில் வந்தது. அவர் இந்த வழக்கை கைவிடவில்லை, ஆனால் அவர்களின் vpc-கண்ட்ரோலரின் மதிப்பாய்வு குறியீட்டை எடுத்து, அது இருக்கும் இடத்தையும் அது ஏன் வேலை செய்யவில்லை என்பதையும் கண்டுபிடித்தேன்:

எனவே, உங்கள் VPC இல் பிரதான வழி அட்டவணையைப் பயன்படுத்தினால், இயல்பாகவே அது vpc-கண்ட்ரோலருக்கு மிகவும் அவசியமான தேவையான சப்நெட்களுடன் தொடர்புகளை கொண்டிருக்காது, பொது சப்நெட்டின் விஷயத்தில், இது தனிப்பயன் பாதை அட்டவணையைக் கொண்டுள்ளது. என்று ஒரு சங்கம் உள்ளது.

முக்கிய வழி அட்டவணைக்கு தேவையான சப்நெட்களுடன் சங்கங்களை கைமுறையாக சேர்ப்பதன் மூலம், மற்றும் நோட்குரூப்பை மீண்டும் உருவாக்குவதன் மூலம், எல்லாம் சரியாக வேலை செய்கிறது.

அருண் பி. இந்த பிழையை EKS டெவலப்பர்களிடம் உண்மையில் புகாரளிப்பார் என்று நம்புகிறேன், மேலும் vpc-கண்ட்ரோலரின் புதிய பதிப்பைக் காண்போம், அங்கு எல்லாம் சரியாகச் செயல்படும். தற்போது சமீபத்திய பதிப்பு: 602401143452.dkr.ecr.ap-southeast-1.amazonaws.com/eks/vpc-resource-controller:0.2.1
இந்த பிரச்சனை உள்ளது.

இறுதிவரை படித்த அனைவருக்கும் நன்றி, செயல்படுத்துவதற்கு முன் நீங்கள் தயாரிப்பில் பயன்படுத்தப் போகும் அனைத்தையும் சோதிக்கவும்.

ஆதாரம்: www.habr.com