በGA ውስጥ የአማዞን EKS ዊንዶውስ ስህተቶች አሉት ፣ ግን በጣም ፈጣኑ ነው።

በGA ውስጥ የአማዞን EKS ዊንዶውስ ስህተቶች አሉት ፣ ግን በጣም ፈጣኑ ነው።

ደህና ከሰአት፣ የ AWS EKS (Elastic Kubernetes Service) አገልግሎትን ለዊንዶውስ ኮንቴይነሮች በማዘጋጀት እና ለመጠቀም ወይም ደግሞ እሱን ለመጠቀም የማይቻል መሆኑን እና በ AWS ስርዓት መያዣ ውስጥ ስላለው ስህተት ልምዴን ላካፍላችሁ እፈልጋለሁ። ለዊንዶውስ ኮንቴይነሮች በዚህ አገልግሎት ላይ ፍላጎት ያላቸው, እባክዎን በድመት ስር.

እኔ የዊንዶው ኮንቴይነሮች ታዋቂ ርዕስ እንዳልሆኑ አውቃለሁ ፣ እና ጥቂት ሰዎች እነሱን ይጠቀማሉ ፣ ግን አሁንም ይህንን ጽሑፍ ለመፃፍ ወሰንኩ ፣ ምክንያቱም በ Habré ላይ በ kubernetes እና በዊንዶው ላይ ሁለት መጣጥፎች ስለነበሩ እና አሁንም እንደዚህ ያሉ ሰዎች አሉ።

የመጀመሪያው

70% ዊንዶውስ እና 30% ሊኑክስ ወደሆነው በኩባንያችን ውስጥ ያሉትን አገልግሎቶች ወደ kubernetes ለማዛወር ሲወሰን ይህ ሁሉ ተጀመረ። ለዚሁ ዓላማ የAWS EKS የደመና አገልግሎት ከሚቻሉት አማራጮች አንዱ ተደርጎ ይወሰድ ነበር። እስከ ኦክቶበር 8፣ 2019፣ AWS EKS ዊንዶውስ በሕዝብ ቅድመ እይታ ውስጥ ነበር፣ በሱ ጀመርኩ፣ የድሮው 1.11 የ kubernetes ስሪት እዚያ ጥቅም ላይ ውሏል፣ ግን ለማንኛውም ለመፈተሽ ወሰንኩ እና ይህ የደመና አገልግሎት ምን ደረጃ ላይ እንደሆነ፣ እየሰራ እንደሆነ ለማየት ወሰንኩ። በአጠቃላይ ፣ እንደ ተለወጠ ፣ አይሆንም ፣ ፖድዎችን ከማስወገድ በተጨማሪ አንድ ስህተት ነበር ፣ አሮጌዎቹ ከዊንዶውስ ሰራተኛ መስቀለኛ መንገድ ተመሳሳይ ንዑስ አውታረ መረብ በውስጣዊ አይፒ በኩል ምላሽ መስጠት አቆሙ ።

ስለዚህ በተመሳሳይ EC2 ላይ የራሳችንን ክላስተር በመደገፍ የ AWS EKS አጠቃቀምን ለመተው ተወስኗል ፣ እኛ ብቻ ሁሉንም ሚዛናዊ እና HA እራሳችንን በ CloudFormation መግለጽ አለብን።

Amazon EKS የዊንዶው ኮንቴይነር ድጋፍ አሁን በአጠቃላይ ይገኛል።

በ ማርቲን ቢቢ | በ 08 ኦክቶበር 2019 ላይ

አብነት ወደ CloudFormation ለማከል ጊዜ ከማግኘቴ በፊት ለራሴ ክላስተር ይህን ዜና አይቻለሁ Amazon EKS የዊንዶው ኮንቴይነር ድጋፍ አሁን በአጠቃላይ ይገኛል።

እርግጥ ነው, ሁሉንም ስራዬን ወደ ጎን አስቀምጫለሁ እና ለ GA ምን እንዳደረጉ እና በህዝብ ቅድመ እይታ ሁሉም ነገር እንዴት እንደተለወጠ ማጥናት ጀመርኩ. አዎ፣ AWS፣ በደንብ ተከናውኗል፣ ምስሎቹን ለዊንዶውስ ሰራተኛ መስቀለኛ መንገድ ወደ ስሪት 1.14 አዘምኗል፣ እንዲሁም ክላስተር ራሱ፣ ስሪት 1.14 በ EKS፣ አሁን የዊንዶው ኖዶችን ይደግፋል። ፕሮጀክት በህዝብ ቅድመ እይታ በ github ሸፍነውታል እና አሁን ኦፊሴላዊውን ሰነድ እዚህ ተጠቀም አሉ፡ የ EKS ዊንዶውስ ድጋፍ

የEKS ስብስብን አሁን ባለው ቪፒሲ እና ንዑስ አውታረ መረቦች ውስጥ በማዋሃድ ላይ

በሁሉም ምንጮች፣ በማስታወቂያው ላይ እና በሰነዶቹ ውስጥ ከላይ ባለው አገናኝ ክላስተርን በባለቤትነት በ eksctl መገልገያ ወይም በ CloudFormation + kubectl በኩል ለማሰማራት ሀሳብ ቀርቧል ፣ በአማዞን ውስጥ የህዝብ ንዑስ መረቦችን ብቻ በመጠቀም ፣ እንዲሁም ለአዲስ ክላስተር VPC ን ይለዩ።

ይህ አማራጭ ለብዙዎች ተስማሚ አይደለም፤ በመጀመሪያ፣ የተለየ ቪፒሲ ማለት ለዋጋው ተጨማሪ ወጪዎች + የአሁኑን ቪፒሲ የማየት ትራፊክ ማለት ነው። አስቀድመው በAWS ውስጥ ዝግጁ የሆነ መሠረተ ልማት ያላቸው የራሳቸው Multiple AWS መለያዎች፣ ቪፒሲ፣ ንዑስ መረቦች፣ የመንገድ ጠረጴዛዎች፣ የመተላለፊያ መግቢያ በር እና የመሳሰሉት ምን ማድረግ አለባቸው? በእርግጥ ይህንን ሁሉ ለመስበር ወይም ለመድገም አይፈልጉም, እና አዲሱን የ EKS ክላስተር አሁን ባለው የኔትወርክ መሠረተ ልማት ውስጥ ማዋሃድ ያስፈልግዎታል, ያለውን VPC በመጠቀም እና ለመለያየት, ቢበዛ ለክላስተር አዲስ ንዑስ መረቦችን ይፍጠሩ.

በእኔ ሁኔታ, ይህ መንገድ ተመርጧል, ነባሩን VPC ተጠቀምኩኝ, ለአዲሱ ክላስተር 2 ህዝባዊ ንዑስ መረቦችን እና 2 የግል ንኡስ መረቦችን ብቻ ጨምሬያለሁ, በእርግጥ ሁሉም ህጎች በሰነዱ መሰረት ግምት ውስጥ ገብተዋል. የእርስዎን Amazon EKS ክላስተር ቪፒሲ ይፍጠሩ.

አንድ ሁኔታም ነበር፡ 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

ወደ ነባር ቪፒሲ ለማሰማራት የንዑስ መረቦችዎን መታወቂያ ብቻ ይጥቀሱ እና eksctl ቪፒሲን ራሱ ይወስናል።

የሰራተኛ ኖዶችዎ ወደ ግል ሳብኔት ብቻ መሰማራታቸውን ለማረጋገጥ --node-private-networking for nodegroup የሚለውን መግለፅ ያስፈልግዎታል።

2. በእኛ ክላስተር ውስጥ vpc-controller ን እንጭናለን, ከዚያም የሰራተኛ ኖዶቻችንን እናስኬዳለን, ነፃ የአይፒ አድራሻዎችን ቁጥር በመቁጠር, እንዲሁም በምሳሌው ላይ የ ENI ዎች ቁጥር በመጨመር እና በማስወገድ ላይ.

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

3.Vpc-controllerን ጨምሮ የሲስተም ኮንቴይነሮችዎ በተሳካ ሁኔታ በእርስዎ ሊኑክስ ሰራተኛ መስቀለኛ መንገድ ላይ ከጀመሩ በኋላ የቀረው ከዊንዶውስ ሰራተኞች ጋር ሌላ 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-መቆጣጠሪያ ውስጥ ስህተት

በዊንዶውስ ሰራተኛ መስቀለኛ መንገድ ላይ ፖድዎችን ለማስኬድ ከሞከርን ስህተቱ ይደርስብናል፡-

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 ውስጥ ያለን ምሳሌ ይህን ይመስላል፡-

በGA ውስጥ የአማዞን EKS ዊንዶውስ ስህተቶች አሉት ፣ ግን በጣም ፈጣኑ ነው።

እና እንደዚህ መሆን አለበት.

በGA ውስጥ የአማዞን EKS ዊንዶውስ ስህተቶች አሉት ፣ ግን በጣም ፈጣኑ ነው።

ከዚህ በመነሳት የ vpc-controller በሆነ ምክንያት የራሱን ክፍል እንዳልፈፀመ እና አዲስ የአይፒ አድራሻዎችን ወደ ምሳሌው ማከል አለመቻሉ ግልጽ ነው, ስለዚህም ፖድዎቹ ሊጠቀሙባቸው ይችላሉ.

የ vpc-controller pod ምዝግብ ማስታወሻዎችን እንይ እና የምናየው ይህንን ነው፡-

kubectl መዝገብ -n kube-ስርዓት

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ን መፍታት አይችልም እና ሊደርስበት አይችልም እና ስለዚህ ስህተቶች ይከሰታሉ.

አዎን፣ በእርግጥ፣ በቪፒሲ ውስጥ ብጁ የዲ ኤን ኤስ አገልጋዮችን እንጠቀማለን እና በመርህ ደረጃ አማዞንን አንጠቀምም፣ ስለዚህ ማስተላለፍ እንኳን ለዚህ ap-xxx.compute.internal ጎራ አልተዋቀረም። ይህንን አማራጭ ሞከርኩ, እና ውጤቱን አላመጣም, ምናልባት ፈተናው ንጹህ አልነበረም, እና ስለዚህ, ተጨማሪ, ከቴክኒካዊ ድጋፍ ጋር ስገናኝ, በሃሳባቸው ተሸንፌያለሁ.

በእውነቱ ምንም ሀሳቦች ስላልነበሩ ሁሉም የደህንነት ቡድኖች የተፈጠሩት በ eksctl ራሱ ነው ፣ ስለሆነም ስለአገልግሎት አገልግሎታቸው ምንም ጥርጣሬ አልነበረውም ፣ የመንገድ ጠረጴዛዎች እንዲሁ ትክክል ነበሩ ፣ nat ፣ dns ፣ ከሠራተኛ አንጓዎች ጋር የበይነመረብ መዳረሻ እንዲሁ እዚያ ነበር።

በተጨማሪም፣ የሰራተኛ መስቀለኛ መንገድን ወደ ይፋዊ ንዑስ መረብ — node-private-networking ሳትጠቀሙ ብታሰማሩ፣ ይህ መስቀለኛ መንገድ ወዲያውኑ በ vpc-መቆጣጠሪያው ተዘምኗል እና ሁሉም ነገር እንደ ሰዓት ስራ ይሰራል።

ሁለት አማራጮች ነበሩ

  1. ተው እና አንድ ሰው ይህን ስህተት በAWS ውስጥ ሲገልጽ እና እስኪያስተካክለው ድረስ ይጠብቁ እና ከዚያ AWS EKS ዊንዶውስ በደህና መጠቀም ይችላሉ ምክንያቱም ገና በGA ውስጥ ስለለቀቁ (ይህን ጽሑፍ በሚጽፍበት ጊዜ 8 ቀናት አልፈዋል) ፣ ብዙዎች ምናልባት ሊሆኑ ይችላሉ ። እንደ እኔ ተመሳሳይ መንገድ ተከተል.
  2. ወደ AWS ድጋፍ ይፃፉ እና የችግሩን ምንነት ከየቦታው ባሉ ሙሉ ምዝግብ ማስታወሻዎች ይንገሯቸው እና የእርስዎን ቪፒሲ እና ንዑስ አውታረ መረቦች ሲጠቀሙ አገልግሎታቸው እንደማይሰራ ያረጋግጡ ፣ እኛ የንግድ ድጋፍ ያለን በከንቱ አይደለም ፣ መጠቀም አለብዎት። ቢያንስ አንድ ጊዜ ነው :)

ከ AWS መሐንዲሶች ጋር ግንኙነት

በፖርታሉ ላይ ትኬት ከፈጠርኩ በኋላ በስህተት በድር - በኢሜል ወይም በድጋፍ ማእከል በኩል ምላሽ ለመስጠት መረጥኩኝ ፣ በዚህ አማራጭ በኩል ከጥቂት ቀናት በኋላ መልስ ሊሰጡዎት ይችላሉ ፣ ምንም እንኳን ትኬቴ ከባድነት - ስርዓት ችግር ያለበት ቢሆንም ፣ በ<12 ሰዓታት ውስጥ ምላሽ መስጠት ማለት ነው፣ እና የቢዝነስ ድጋፍ እቅድ 24/7 ድጋፍ ስላለው፣ ምርጡን ተስፋ አድርጌ ነበር፣ ነገር ግን እንደ ሁልጊዜው ሆነ።

ትኬቴ ከአርብ እስከ ሰኞ ሳይመደብ ቀርቷል፣ ከዚያ እንደገና ልጽፍላቸው ወሰንኩ እና የቻት ምላሽ ምርጫን መረጥኩ። ለአጭር ጊዜ ከጠበቅኩ በኋላ፣ ሃርሻድ ማድሃቭ እኔን ለማየት ተሾመ፣ እና ከዚያ ጀመረ...

በተከታታይ ለ 3 ሰአታት በመስመር ላይ ማረም ፣ ሎግ ማስተላለፎችን ፣ ችግሩን ለመምሰል ያው ክላስተር በ AWS ላብራቶሪ ውስጥ በማሰማራት ፣ በእኔ በኩል ክላስተር እንደገና መፍጠር እና ሌሎችም ፣ የመጣነው ብቸኛው ነገር ከ ነው ። ምዝግብ ማስታወሻው ከላይ የጻፍኩትን የAWS የውስጥ ጎራ ስሞችን እንደማይሰራ ግልጽ ነበር፣ እና ሃርሻድ ማድሃቭ ብጁ ዲ ኤን ኤስ እንጠቀማለን በሚል ጥቆማ እንድፈጥር ጠየቀኝ እና ይህ ችግር ሊሆን ይችላል።

ማስተላለፍ

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

ያ ነው የተደረገው፣ ቀኑ አልቋል። ሃርሻድ ማድሃቭ በድጋሚ ፈትሾ ጻፈ እና መስራት አለበት፣ ግን አይሆንም፣ ውሳኔው ምንም አልረዳም።

ከዛ ከ 2 ተጨማሪ መሐንዲሶች ጋር ግንኙነት ተፈጠረ ፣ አንዱ በቀላሉ ከውይይት ወጣ ፣ ውስብስብ ጉዳይን ፈርቶ ይመስላል ፣ ሁለተኛው እንደገና የእኔን ቀን ሙሉ የማረም ዑደት ላይ አሳልፋለሁ ፣ ምዝግብ ማስታወሻዎችን በመላክ ፣ በሁለቱም በኩል ዘለላዎችን በመፍጠር ፣ በመጨረሻ እሱ ጥሩ ተናግሯል ፣ ለእኔ ይሰራል ፣ እዚህ ነኝ በይፋዊው ሰነድ ውስጥ ሁሉንም ነገር ደረጃ በደረጃ አደርጋለሁ እና እርስዎ እና እርስዎ ይሳካሉ።

ችግሩን የት እንደሚፈልጉ ካላወቁ ትኬቱን እንዲለቅ እና ሌላ ሰው እንዲመድበው በትህትና ጠየቅኩት።

የመጨረሻ

በሦስተኛው ቀን አዲስ ኢንጂነር አሩን ቢ ተመደብኩኝ እና ከእሱ ጋር ከተገናኘንበት ጊዜ ጀምሮ ይህ የቀደሙት 3 መሐንዲሶች እንዳልሆኑ ወዲያውኑ ታወቀ። ሙሉውን ታሪክ አነበበ እና ወዲያውኑ በgithub ላይ ባለው በps1 ላይ የራሱን ስክሪፕት ተጠቅሞ መዝገቦቹን እንዲሰበስብ ጠየቀ። ይህ እንደገና ክላስተሮችን የመፍጠር ፣ የትዕዛዝ ውጤቶችን የማውጣት ፣ የምዝግብ ማስታወሻዎችን የመሰብሰብ ድግግሞሾችን ተከትሎ ነበር ፣ ግን አሩን ቢ በተጠየቁኝ ጥያቄዎች በመመዘን በትክክለኛው አቅጣጫ እየሄደ ነበር።

በቪፒሲ መቆጣጠሪያቸው ውስጥ -stderrthreshold=ማረምን የማንቃት ደረጃ ላይ መቼ ደረስን እና ቀጥሎ ምን ሆነ? በእርግጥ አይሰራም) ፖድ በቀላሉ በዚህ አማራጭ አይጀምርም, -stderrthreshold=መረጃ ብቻ ይሰራል.

እዚህ ጨረስን እና አሩን ቢ ተመሳሳይ ስህተት ለማግኘት እርምጃዬን እንደገና ለማባዛት እሞክራለሁ አለ። በሚቀጥለው ቀን ከአሩን ቢ ምላሽ አገኘሁ እሱ ይህንን ጉዳይ አልተወም፣ ነገር ግን የvpc-መቆጣጠሪያቸውን የግምገማ ኮድ ወሰደ እና ያለበትን ቦታ አገኘ እና ለምን አይሰራም።

በGA ውስጥ የአማዞን EKS ዊንዶውስ ስህተቶች አሉት ፣ ግን በጣም ፈጣኑ ነው።

ስለዚህ, በእርስዎ VPC ውስጥ ዋናውን የመንገድ ሰንጠረዥን ከተጠቀሙ, በነባሪነት ከአስፈላጊው ንኡስ ኔትወርኮች ጋር ማህበራት የሉትም, ይህም ለ vpc-ተቆጣጣሪው በጣም አስፈላጊ ነው, በአደባባይ ሳብኔት ውስጥ, ብጁ የመንገድ ሰንጠረዥ አለው. ማህበር ያለው።

አስፈላጊ በሆኑ ንዑስ አውታረ መረቦች ለዋናው የመንገድ ጠረጴዛ ማኅበራትን በእጅ በመጨመር እና መስቀለኛ ቡድኑን እንደገና በመፍጠር ሁሉም ነገር በትክክል ይሰራል።

Arun B. ይህንን ስህተት ለ EKS ገንቢዎች በእውነት እንደሚያሳውቅ ተስፋ አደርጋለሁ እና ሁሉም ነገር ከሳጥኑ ውጭ የሚሰራበት አዲስ የvpc-controller ስሪት እናያለን። በአሁኑ ጊዜ አዲሱ ስሪት: 602401143452.dkr.ecr.ap-southeast-1.amazonaws.com/eks/vpc-resource-controller:0.2.1
ይህ ችግር አለበት.

እስከ መጨረሻው ላነበቡት ሁሉ ምስጋና ይግባውና ከመተግበሩ በፊት በምርት ውስጥ የሚጠቀሙባቸውን ሁሉንም ነገሮች ይፈትሹ.

ምንጭ: hab.com

አስተያየት ያክሉ