GA හි Amazon EKS වින්ඩෝස් වල දෝෂ ඇත, නමුත් වේගවත්ම වේ

සුබ සන්ධ්‍යාවක්, මට Windows බහාලුම් සඳහා AWS EKS (Elastic Kubernetes Service) සේවාව පිහිටුවීමේ සහ භාවිතා කිරීමේ මගේ අත්දැකීම් ඔබ සමඟ බෙදා ගැනීමට අවශ්‍යයි, නැතහොත් එය භාවිතා කිරීමේ නොහැකියාව සහ AWS පද්ධති බහාලුම්වල ඇති දෝෂය ගැන Windows බහාලුම් සඳහා මෙම සේවාව ගැන උනන්දුවක් දක්වන අය, කරුණාකර cat යටතේ.

වින්ඩෝස් බහාලුම් ජනප්‍රිය මාතෘකාවක් නොවන බව මම දනිමි, ස්වල්ප දෙනෙක් ඒවා භාවිතා කරති, නමුත් මම තවමත් මෙම ලිපිය ලිවීමට තීරණය කළෙමි, මන්ද කුබර්නෙට් සහ වින්ඩෝස් හි හබ්‍රේ පිළිබඳ ලිපි කිහිපයක් තිබූ අතර තවමත් එවැනි අය සිටින බැවිනි.

නිවස

ඒ සියල්ල ආරම්භ වූයේ අපගේ සමාගමේ සේවාවන් 70% වින්ඩෝස් සහ 30% ලිනක්ස් වන kubernetes වෙත සංක්‍රමණය කිරීමට තීරණය කළ විටය. මෙම කාර්යය සඳහා, AWS EKS ක්ලවුඩ් සේවාව හැකි විකල්ප වලින් එකක් ලෙස සැලකේ. 8 ඔක්තෝබර් 2019 වන දින දක්වා, AWS EKS වින්ඩෝස් පොදු පෙරදසුනෙහි තිබුණි, මම එය සමඟ ආරම්භ කළෙමි, පැරණි 1.11 kubernetes අනුවාදය එහි භාවිතා කර ඇත, නමුත් මම එය කෙසේ හෝ පරීක්ෂා කර බැලීමට තීරණය කළෙමි, එය ක්‍රියාත්මක වන්නේ දැයි බලන්න. ඇත්ත වශයෙන්ම, එය සිදු වූ පරිදි, නැත, එය කරල් ඉවත් කිරීමේ දෝෂයක් ඇති අතර, පැරණි ඒවා windows වර්කර් නෝඩයේ උපජාලයෙන් අභ්‍යන්තර ip හරහා ප්‍රතිචාර දැක්වීම නැවැත්වීය.

එබැවින්, එකම EC2 හි kubernetes මත අපගේම පොකුරට පක්ෂව AWS EKS භාවිතය අත්හැරීමට තීරණය කරන ලදී, CloudFormation හරහා සියලු සමතුලිතතා සහ HA අප විසින්ම විස්තර කිරීමට අපට සිදුවනු ඇත.

Amazon EKS Windows බහාලුම් සහය දැන් සාමාන්‍යයෙන් පවතී

Martin Beeby විසින් | 08 OCT 2019 දින

මගේම පොකුරක් සඳහා CloudFormation වෙත අච්චුවක් එක් කිරීමට මට කාලය ලැබීමට පෙර, මම මෙම ප්‍රවෘත්තිය දුටුවෙමි Amazon EKS Windows බහාලුම් සහය දැන් සාමාන්‍යයෙන් පවතී

ඇත්ත වශයෙන්ම, මම මගේ සියලු වැඩ පසෙකට දමා ඔවුන් GA සඳහා කළ දේ සහ Public Preview සමඟ සියල්ල වෙනස් වූ ආකාරය අධ්‍යයනය කිරීමට පටන් ගතිමි. ඔව්, AWS, හොඳින් සිදු කර ඇත, වින්ඩෝස් වර්කර් නෝඩ් සඳහා පින්තූර 1.14 අනුවාදයට යාවත්කාලීන කරන ලදී, එසේම පොකුරේම, EKS හි 1.14 අනුවාදය, දැන් වින්ඩෝස් නෝඩ් සඳහා සහය දක්වයි. පොදු පෙරදසුන මගින් ව්‍යාපෘතිය github ඔවුන් එය වසා දැමූ අතර දැන් මෙහි නිල ලේඛන භාවිතා කරන්න: EKS වින්ඩෝස් සහාය

වත්මන් VPC සහ උපජාල වෙත EKS පොකුරක් ඒකාබද්ධ කිරීම

සියලුම මූලාශ්‍රවල, නිවේදනයේ මෙන්ම ප්‍රලේඛනයේ ඉහත සබැඳියේ, හිමිකාර eksctl උපයෝගිතා හරහා හෝ CloudFormation + kubectl හරහා පසුව, Amazon හි පොදු උපජාල පමණක් භාවිතා කරමින්, මෙන්ම නිර්මාණය කිරීමටද යෝජනා කරන ලදී. නව පොකුරක් සඳහා වෙනම VPC.

මෙම විකල්පය බොහෝ දෙනෙකුට සුදුසු නොවේ; පළමුව, වෙනම VPC යන්නෙන් අදහස් වන්නේ එහි පිරිවැය සඳහා අමතර වියදම් + ඔබගේ වත්මන් VPC වෙත peering Traffic. AWS හි දැනටමත් තමන්ගේම බහු AWS ගිණුම්, VPC, උපජාල, මාර්ග වගු, සංක්‍රමණ ද්වාර සහ යනාදිය සමඟ සූදානම් කළ යටිතල පහසුකම් ඇති අය කුමක් කළ යුතුද? ඇත්ත වශයෙන්ම, ඔබට මේ සියල්ල බිඳ දැමීමට හෝ නැවත කිරීමට අවශ්‍ය නැති අතර, ඔබ දැනට පවතින VPC භාවිතා කරමින් නව EKS පොකුර වත්මන් ජාල යටිතල ව්‍යුහයට අනුකලනය කළ යුතු අතර, වෙන් කිරීම සඳහා, බොහෝ විට පොකුර සඳහා නව උපජාල නිර්මාණය කළ යුතුය.

මගේ නඩුවේදී, මෙම මාර්ගය තෝරාගෙන ඇත, මම දැනට පවතින VPC භාවිතා කළෙමි, නව පොකුර සඳහා පොදු උපජාල 2 ක් සහ පුද්ගලික උපජාල 2 ක් පමණක් එකතු කළෙමි, ඇත්ත වශයෙන්ම, ලේඛනගත කිරීම අනුව සියලුම නීති සැලකිල්ලට ගන්නා ලදී. ඔබගේ Amazon EKS Cluster VPC සාදන්න.

එක් කොන්දේසියක් ද විය: EIP භාවිතා කරන පොදු උපජාලවල සේවක නෝඩ් නොමැත.

eksctl එදිරිව CloudFormation

මම පොකුරක් යෙදවීමේ ක්‍රම දෙකම උත්සාහ කළ බව මම වහාම වෙන්කරවා ගන්නෙමි, අවස්ථා දෙකේදීම පින්තූරය සමාන විය.

මෙහි කේතය කෙටි වන බැවින් eksctl භාවිතා කිරීමෙන් පමණක් මම උදාහරණයක් පෙන්වන්නම්. eksctl භාවිතා කරමින්, පොකුර පියවර 3කින් යොදන්න:

1. අපි පොකුරු + Linux සේවක නෝඩය නිර්මාණය කරමු, එය පසුව පද්ධති බහාලුම් සහ එම අවාසනාවන්ත 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 වෙත යෙදවීම සඳහා, ඔබගේ උපජාල වල id සඳහන් කරන්න, eksctl විසින් VPC විසින්ම තීරණය කරනු ඇත.

ඔබගේ සේවක නෝඩ් පුද්ගලික උපජාලයකට පමණක් යොදවා ඇති බව සහතික කිරීමට, ඔබ nodegroup සඳහා --node-private-networking සඳහන් කළ යුතුය.

2. අපි අපගේ පොකුරේ vpc-පාලකය ස්ථාපනය කරන්නෙමු, ඉන් පසුව අපගේ සේවක නෝඩ් සකසනු ඇත, නොමිලේ IP ලිපින ගණන ගණන් කිරීම, උදාහරණයේ ඇති ENI ගණන, ඒවා එකතු කිරීම සහ ඉවත් කිරීම.

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

3.vpc-controller ඇතුළුව ඔබේ Linux සේවක නෝඩය මත ඔබේ පද්ධති බහාලුම් සාර්ථකව දියත් කළ පසු ඉතිරිව ඇත්තේ windows කම්කරුවන් සමඟ තවත් nodegroup එකක් සෑදීමයි.

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-පාලකයේ දෝෂයකි

අපි windows වර්කර් නෝඩයක පොඩ් ධාවනය කිරීමට උත්සාහ කළහොත්, අපට දෝෂය ලැබෙනු ඇත:

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-පාලකය එහි කොටස ඉටු නොකළ බවත්, එම අවස්ථාවට නව IP ලිපින එක් කළ නොහැකි බවත්, එවිට ඒවා භාවිතා කළ හැකි බවත්ය.

අපි බලමු vpc-controller Pod හි ලොග් දෙස සහ අපි දකින්නේ මෙයයි:

kubectl ලොගය -n කියුබ්-පද්ධතිය

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, සේවක නෝඩ් සමඟ අන්තර්ජාල ප්රවේශය ද විය.

එපමනක් නොව, ඔබ —node-private-networking භාවිතා නොකර පොදු උපජාලයකට සේවක node එකක් යොදවන්නේ නම්, මෙම node එක vpc-controller විසින් වහාම යාවත්කාලීන කරන ලද අතර සෑම දෙයක්ම ඔරලෝසු වැඩ මෙන් ක්‍රියා කරයි.

විකල්ප දෙකක් විය:

1. එය අත්හරින්න සහ යමෙකු AWS හි මෙම දෝෂය විස්තර කර ඔවුන් එය නිවැරදි කරන තෙක් රැඳී සිටින්න, එවිට ඔබට ආරක්ෂිතව AWS EKS වින්ඩෝස් භාවිතා කළ හැකිය, මන්ද ඔවුන් දැන් GA හි නිකුත් කර ඇත (මෙම ලිපිය ලියන විට දින 8 ක් ගත වී ඇත), බොහෝ දෙනෙක් බොහෝ විට එසේ කරනු ඇත. මා ගිය මාර්ගයම අනුගමනය කරන්න.
2. AWS Support වෙත ලියා සෑම තැනකම ඇති ලොග් සමූහයක් සමඟ ගැටලුවේ සාරය ඔවුන්ට පවසන්න සහ ඔබේ VPC සහ උපජාල භාවිතා කරන විට ඔවුන්ගේ සේවාව ක්‍රියා නොකරන බව ඔවුන්ට ඔප්පු කරන්න, අපට ව්‍යාපාර සහාය තිබුණේ නිකම්ම නොවේ, ඔබ භාවිතා කළ යුතුය. එය අවම වශයෙන් එක් වරක් :)

AWS ඉංජිනේරුවන් සමඟ සන්නිවේදනය

ද්වාරයෙහි ප්‍රවේශ පත්‍රයක් නිර්මාණය කිරීමෙන් පසු, මම වැරදි ලෙස මට වෙබ් - විද්‍යුත් තැපෑල හෝ උපකාරක මධ්‍යස්ථානය හරහා ප්‍රතිචාර දැක්වීමට තෝරා ගත්තෙමි, මෙම විකල්පය හරහා ඔවුන්ට දින කිහිපයකට පසු ඔබට පිළිතුරු දිය හැකිය, මගේ ටිකට් පතේ බරපතලකම - පද්ධතිය දුර්වල වී තිබියදීත්, <12 පැය තුළ ප්‍රතිචාරයක් අදහස් කරන අතර, ව්‍යාපාර සහාය සැලැස්මට 24/7 සහය ඇති බැවින්, මම හොඳම දේ බලාපොරොත්තු වූ නමුත් එය සෑම විටම මෙන් විය.

සිකුරාදා සිට සඳුදා දක්වා මගේ ප්‍රවේශ පත්‍රය පැවරීමකින් තොරව තැබිණි, පසුව මම ඔවුන්ට නැවත ලිවීමට තීරණය කර Chat ප්‍රතිචාර විකල්පය තෝරා ගත්තෙමි. ටික වෙලාවක් බලන් ඉඳලා හර්ෂද් මාධව් මාව බලන්න පත් කළා, ඊට පස්සේ පටන් ගත්තා...

අපි එය සමඟින් පැය 3ක් එක දිගට දෝශ නිරාකරණය කර, ලඝු-සටහන් මාරු කිරීම, ගැටලුව අනුකරණය කිරීම සඳහා එම පොකුර AWS රසායනාගාරයේ යෙදවීම, මගේ පැත්තෙන් පොකුර නැවත නිර්මාණය කිරීම සහ යනාදී වශයෙන් අප පැමිණි එකම දෙය වන්නේ එයයි. මා ඉහත ලියා ඇති AWS අභ්‍යන්තර වසම් නාම රෙසෝල් ක්‍රියා නොකරන බව ලඝු-සටහන් වලින් පැහැදිලි විය, හර්ෂද් මාධව් මගෙන් ඉදිරියට යැවීමක් නිර්මාණය කරන ලෙස ඉල්ලා සිටියේය, අපි අභිරුචි DNS භාවිතා කරන අතර මෙය ගැටළුවක් විය හැකිය.

යොමු කිරීම

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

එය සිදු කරන ලදී, දවස අවසන් විය, එය පරීක්ෂා කිරීමට හර්ෂද් මාධව් නැවත ලිවීය, එය ක්‍රියාත්මක විය යුතුය, නමුත් නැත, යෝජනාව කිසිසේත් උදව් කළේ නැත.

ඉන්පසුව තවත් ඉංජිනේරුවන් දෙදෙනෙකු සමඟ සන්නිවේදනයක් ඇති විය, එක් අයෙක් කතාබස් වලින් ඉවත් විය, පෙනෙන විදිහට ඔහු සංකීර්ණ නඩුවකට බිය විය, දෙවැන්නා නැවතත් මගේ දවස ගත කළේ දෝශ නිරාකරණය, ලඝු-සටහන් යැවීම, දෙපැත්තෙන්ම පොකුරු නිර්මාණය කිරීම වැනි සම්පූර්ණ චක්‍රයක ය. අවසානය ඔහු හොඳින් කීවේය, එය මට ක්‍රියා කරයි, මෙන්න මම නිල ලේඛනයේ සෑම දෙයක්ම පියවරෙන් පියවර කරමි, එවිට ඔබ සහ ඔබ සාර්ථක වනු ඇත.

එයට මම කාරුණිකව ඔහුගෙන් ඉල්ලා සිටියේ ඔබ ගැටලුව සොයන්නේ කොහෙන්දැයි නොදන්නේ නම් ඉවත්ව ගොස් මගේ ටිකට් පතට වෙනත් අයෙකු යොදවන ලෙසයි.

අවසාන

තුන්වන දින, නව ඉංජිනේරුවෙකු අරුන් බී. ඔහු මුළු ඉතිහාසයම කියවා වහාම ඔහුගේ ගිතුබ් එකේ තිබූ ps3 හි ඔහුගේම ස්ක්‍රිප්ට් භාවිතා කර ලොග් එකතු කරන ලෙස ඉල්ලා සිටියේය. මෙයින් පසු නැවතත් පොකුරු සෑදීම, විධාන ප්‍රතිඵල නිකුත් කිරීම, ලඝු-සටහන් එකතු කිරීම වැනි සියලු පුනරාවර්තන සිදු වූ නමුත් අරුන් බී. මගෙන් අසන ලද ප්‍රශ්නවලින් විනිශ්චය කරමින් නිවැරදි දිශාවට ගමන් කරමින් සිටියේය.

අපි ඔවුන්ගේ 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