GA માં Amazon EKS વિન્ડોઝમાં બગ્સ છે, પરંતુ તે સૌથી ઝડપી છે

શુભ બપોર, હું તમારી સાથે વિન્ડોઝ કન્ટેનર માટે AWS EKS (ઇલાસ્ટિક કુબરનેટ્સ સર્વિસ) સેવાને સેટ કરવા અને તેનો ઉપયોગ કરવાનો મારો અનુભવ શેર કરવા માંગુ છું, અથવા તેના બદલે તેનો ઉપયોગ કરવાની અશક્યતા વિશે અને AWS સિસ્ટમ કન્ટેનરમાં મળેલી ભૂલ વિશે, તે માટે જેઓ Windows કન્ટેનર માટે આ સેવામાં રસ ધરાવતા હોય, કૃપા કરીને બિલાડી હેઠળ.

હું જાણું છું કે વિન્ડોઝ કન્ટેનર એ લોકપ્રિય વિષય નથી, અને થોડા લોકો તેનો ઉપયોગ કરે છે, પરંતુ મેં હજી પણ આ લેખ લખવાનું નક્કી કર્યું છે, કારણ કે કુબરનેટ્સ અને વિન્ડોઝ પર હેબ્રે પર કેટલાક લેખો હતા અને હજી પણ આવા લોકો છે.

શરૂઆત

આ બધું ત્યારે શરૂ થયું જ્યારે અમારી કંપનીની સેવાઓને kubernetes પર સ્થાનાંતરિત કરવાનો નિર્ણય લેવામાં આવ્યો, જે 70% Windows અને 30% Linux છે. આ હેતુ માટે, AWS EKS ક્લાઉડ સેવાને સંભવિત વિકલ્પોમાંના એક તરીકે ગણવામાં આવી હતી. ઑક્ટોબર 8, 2019 સુધી, AWS EKS વિન્ડોઝ સાર્વજનિક પ્રીવ્યૂમાં હતી, મેં તેની સાથે શરૂઆત કરી, ત્યાં કુબરનેટ્સનું જૂનું 1.11 વર્ઝન ઉપયોગમાં લેવાતું હતું, પરંતુ મેં તેને કોઈપણ રીતે તપાસવાનું નક્કી કર્યું અને જોવાનું નક્કી કર્યું કે આ ક્લાઉડ સેવા કયા તબક્કે છે, શું તે કામ કરી રહી છે. બિલકુલ, જેમ તે બહાર આવ્યું છે, ના, તેમાં પોડ્સને દૂર કરવાના ઉમેરા સાથે એક ભૂલ હતી, જ્યારે જૂના લોકોએ વિન્ડોઝ વર્કર નોડ જેવા જ સબનેટમાંથી આંતરિક ip દ્વારા પ્રતિસાદ આપવાનું બંધ કરી દીધું હતું.

તેથી, એ જ EC2 પર કુબરનેટ્સ પર અમારા પોતાના ક્લસ્ટરની તરફેણમાં AWS EKS નો ઉપયોગ છોડી દેવાનો નિર્ણય લેવામાં આવ્યો હતો, ફક્ત અમારે ક્લાઉડફોર્મેશન દ્વારા તમામ સંતુલન અને HAનું વર્ણન કરવું પડશે.

એમેઝોન ઇકેએસ વિન્ડોઝ કન્ટેનર સપોર્ટ હવે સામાન્ય રીતે ઉપલબ્ધ છે

માર્ટિન બીબી દ્વારા | 08 OCT 2019 ના રોજ

મારા પોતાના ક્લસ્ટર માટે ક્લાઉડફોર્મેશનમાં ટેમ્પલેટ ઉમેરવાનો સમય મળે તે પહેલાં, મેં આ સમાચાર જોયા એમેઝોન ઇકેએસ વિન્ડોઝ કન્ટેનર સપોર્ટ હવે સામાન્ય રીતે ઉપલબ્ધ છે

અલબત્ત, મેં મારું બધું કામ બાજુ પર મૂકી દીધું અને તેઓએ GA માટે શું કર્યું અને સાર્વજનિક પૂર્વાવલોકન સાથે બધું કેવી રીતે બદલાયું તેનો અભ્યાસ કરવાનું શરૂ કર્યું. હા, AWS, સારું કર્યું, વિન્ડોઝ વર્કર નોડ માટે ઇમેજને આવૃત્તિ 1.14 પર અપડેટ કરી, તેમજ ક્લસ્ટર પોતે, EKS માં સંસ્કરણ 1.14, હવે વિન્ડોઝ નોડ્સને સપોર્ટ કરે છે. પર જાહેર પૂર્વાવલોકન દ્વારા પ્રોજેક્ટ ગીથબ તેઓએ તેને આવરી લીધું અને કહ્યું કે હવે અહીં સત્તાવાર દસ્તાવેજોનો ઉપયોગ કરો: EKS વિન્ડોઝ સપોર્ટ

EKS ક્લસ્ટરને વર્તમાન VPC અને સબનેટમાં એકીકૃત કરવું

તમામ સ્ત્રોતોમાં, જાહેરાત પરની ઉપરની લિંકમાં તેમજ દસ્તાવેજીકરણમાં, ક્લસ્ટરને ક્યાં તો માલિકીની eksctl ઉપયોગિતા દ્વારા અથવા CloudFormation + kubectl મારફતે તૈનાત કરવાની દરખાસ્ત કરવામાં આવી હતી, પછી માત્ર Amazon માં જાહેર સબનેટ્સનો ઉપયોગ કરીને, તેમજ એક નવા ક્લસ્ટર માટે અલગ VPC.

આ વિકલ્પ ઘણા લોકો માટે યોગ્ય નથી; પ્રથમ, એક અલગ VPC એટલે તેની કિંમત માટે વધારાના ખર્ચ + તમારા વર્તમાન VPC પર ટ્રાફિક પીઅર. જેમની પાસે પહેલાથી જ AWS માં પોતાના બહુવિધ AWS એકાઉન્ટ્સ, VPC, સબનેટ, રૂટ ટેબલ, ટ્રાન્ઝિટ ગેટવે વગેરે સાથે તૈયાર ઈન્ફ્રાસ્ટ્રક્ચર છે તેઓએ શું કરવું જોઈએ? અલબત્ત, તમે આ બધું તોડવા અથવા ફરીથી કરવા માંગતા નથી, અને તમારે નવા EKS ક્લસ્ટરને વર્તમાન નેટવર્ક ઈન્ફ્રાસ્ટ્રક્ચરમાં એકીકૃત કરવાની જરૂર છે, હાલના VPC નો ઉપયોગ કરીને અને, અલગ કરવા માટે, ક્લસ્ટર માટે નવા સબનેટ્સ બનાવવાની જરૂર છે.

મારા કિસ્સામાં, આ પાથ પસંદ કરવામાં આવ્યો હતો, મેં હાલની VPC નો ઉપયોગ કર્યો, નવા ક્લસ્ટર માટે ફક્ત 2 જાહેર સબનેટ અને 2 ખાનગી સબનેટ ઉમેર્યા, અલબત્ત, દસ્તાવેજો અનુસાર તમામ નિયમો ધ્યાનમાં લેવામાં આવ્યા હતા. તમારું Amazon EKS ક્લસ્ટર VPC બનાવો.

ત્યાં એક શરત પણ હતી: EIP નો ઉપયોગ કરીને જાહેર સબનેટમાં કોઈ કાર્યકર નોડ નહીં.

eksctl vs 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 પોતે નક્કી કરશે.

તમારા વર્કર નોડ્સ ફક્ત ખાનગી સબનેટ પર જ જમાવવામાં આવે તેની ખાતરી કરવા માટે, તમારે નોડગ્રુપ માટે --node-private-networking ને સ્પષ્ટ કરવાની જરૂર છે.

2. અમે અમારા ક્લસ્ટરમાં vpc-કંટ્રોલર ઇન્સ્ટોલ કરીએ છીએ, જે પછી અમારા વર્કર નોડ્સ પર પ્રક્રિયા કરશે, મફત IP એડ્રેસની સંખ્યા તેમજ ઉદાહરણ પર ENI ની સંખ્યાની ગણતરી કરશે, તેમને ઉમેરીને અને દૂર કરશે.

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

3. તમારા લિનક્સ વર્કર નોડ પર તમારા સિસ્ટમ કન્ટેનર સફળતાપૂર્વક લોન્ચ થયા પછી, vpc-કંટ્રોલર સહિત, વિન્ડોઝ કામદારો સાથે બીજું નોડગ્રુપ બનાવવાનું બાકી છે.

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-કંટ્રોલરે કોઈ કારણસર તેનો ભાગ પૂરો કર્યો નથી અને દાખલામાં નવા IP એડ્રેસ ઉમેરી શક્યા નથી જેથી પોડ્સ તેનો ઉપયોગ કરી શકે.

ચાલો vpc-કંટ્રોલર પોડના લોગ જોઈએ અને આ આપણે જોઈએ છીએ:

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.

Google પરની શોધો કંઈપણ તરફ દોરી ન હતી, કારણ કે દેખીતી રીતે હજી સુધી કોઈએ આવી બગ પકડી નથી, અથવા તેના પર કોઈ મુદ્દો પોસ્ટ કર્યો નથી, મારે પહેલા વિકલ્પો વિશે વિચારવું પડશે. પ્રથમ વસ્તુ જે ધ્યાનમાં આવી તે એ હતી કે કદાચ vpc-કંટ્રોલર ip-10-xxx.ap-xxx.compute.internal ને ઉકેલી શકતું નથી અને તેના સુધી પહોંચી શકતું નથી અને તેથી ભૂલો થાય છે.

હા, ખરેખર, અમે VPCમાં કસ્ટમ DNS સર્વર્સનો ઉપયોગ કરીએ છીએ અને, સૈદ્ધાંતિક રીતે, અમે Amazonનો ઉપયોગ કરતા નથી, તેથી આ ap-xxx.compute.internal ડોમેન માટે ફોરવર્ડિંગ પણ ગોઠવવામાં આવ્યું ન હતું. મેં આ વિકલ્પનું પરીક્ષણ કર્યું, અને તે પરિણામ લાવ્યું નહીં, કદાચ પરીક્ષણ સ્વચ્છ ન હતું, અને તેથી, આગળ, તકનીકી સપોર્ટ સાથે વાતચીત કરતી વખતે, હું તેમના વિચારને વળગી ગયો.

ખરેખર કોઈ આઈડિયા ન હોવાથી, બધા સુરક્ષા જૂથો eksctl દ્વારા જ બનાવવામાં આવ્યા હતા, તેથી તેમની સેવાક્ષમતા વિશે કોઈ શંકા ન હતી, રૂટ કોષ્ટકો પણ યોગ્ય હતા, nat, dns, વર્કર નોડ્સ સાથે ઈન્ટરનેટ એક્સેસ પણ હતી.

વધુમાં, જો તમે —node-private-networking નો ઉપયોગ કર્યા વિના કાર્યકર નોડને સાર્વજનિક સબનેટ પર જમાવશો, તો આ નોડ તરત જ 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