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-ന്റെ ഉപയോഗം ഉപേക്ഷിക്കാൻ തീരുമാനിച്ചു, ക്ലൗഡ് ഫോർമേഷൻ വഴി എല്ലാ ബാലൻസിംഗും HA-യും ഞങ്ങൾ സ്വയം വിവരിക്കേണ്ടതുണ്ട്.

Amazon EKS വിൻഡോസ് കണ്ടെയ്‌നർ പിന്തുണ ഇപ്പോൾ പൊതുവായി ലഭ്യമാണ്

മാർട്ടിൻ ബീബി | 08 OCT 2019 ന്

എന്റെ സ്വന്തം ക്ലസ്റ്ററിനായി CloudFormation-ലേക്ക് ഒരു ടെംപ്ലേറ്റ് ചേർക്കാൻ സമയം കിട്ടുന്നതിന് മുമ്പ്, ഞാൻ ഈ വാർത്ത കണ്ടു Amazon EKS വിൻഡോസ് കണ്ടെയ്‌നർ പിന്തുണ ഇപ്പോൾ പൊതുവായി ലഭ്യമാണ്

തീർച്ചയായും, ഞാൻ എന്റെ എല്ലാ ജോലികളും മാറ്റിവെച്ച്, അവർ GA-യ്‌ക്കായി എന്താണ് ചെയ്‌തതെന്നും പബ്ലിക് പ്രിവ്യൂ ഉപയോഗിച്ച് എല്ലാം എങ്ങനെ മാറിയെന്നും പഠിക്കാൻ തുടങ്ങി. അതെ, AWS, നന്നായി ചെയ്തു, വിൻഡോസ് വർക്കർ നോഡിനായുള്ള ഇമേജുകൾ പതിപ്പ് 1.14 ലേക്ക് അപ്‌ഡേറ്റുചെയ്‌തു, അതുപോലെ തന്നെ ക്ലസ്റ്റർ തന്നെ, EKS-ലെ പതിപ്പ് 1.14, ഇപ്പോൾ വിൻഡോസ് നോഡുകൾ പിന്തുണയ്ക്കുന്നു. പബ്ലിക് പ്രിവ്യൂ വഴിയുള്ള പ്രോജക്റ്റ് ഗിത്തബ് അവർ അത് മൂടിവെച്ചു, ഇപ്പോൾ ഇവിടെ ഔദ്യോഗിക ഡോക്യുമെന്റേഷൻ ഉപയോഗിക്കുക: EKS വിൻഡോസ് പിന്തുണ

നിലവിലെ VPC, സബ്‌നെറ്റുകൾ എന്നിവയിലേക്ക് ഒരു EKS ക്ലസ്റ്റർ സംയോജിപ്പിക്കുന്നു

എല്ലാ സ്രോതസ്സുകളിലും, അറിയിപ്പിലെയും ഡോക്യുമെന്റേഷനിലെയും മുകളിലുള്ള ലിങ്കിൽ, പ്രൊപ്രൈറ്ററി eksctl യൂട്ടിലിറ്റി വഴിയോ ക്ലൗഡ്ഫോർമേഷൻ + kubectl വഴിയോ ക്ലസ്റ്റർ വിന്യസിക്കാൻ നിർദ്ദേശിക്കപ്പെട്ടിരിക്കുന്നു, ആമസോണിലെ പൊതു സബ്‌നെറ്റുകൾ മാത്രം ഉപയോഗിക്കുക, അതുപോലെ ഒരു സൃഷ്ടിക്കുക ഒരു പുതിയ ക്ലസ്റ്ററിനായി പ്രത്യേക VPC.

ഈ ഓപ്‌ഷൻ പലർക്കും അനുയോജ്യമല്ല; ഒന്നാമതായി, ഒരു പ്രത്യേക VPC എന്നാൽ നിങ്ങളുടെ നിലവിലെ VPC-യിലേക്കുള്ള ചെലവ് + പിയറിംഗ് ട്രാഫിക്കിന്റെ അധിക ചിലവുകൾ എന്നാണ് അർത്ഥമാക്കുന്നത്. സ്വന്തമായി ഒന്നിലധികം AWS അക്കൗണ്ടുകൾ, VPC, സബ്‌നെറ്റുകൾ, റൂട്ട് ടേബിളുകൾ, ട്രാൻസിറ്റ് ഗേറ്റ്‌വേ തുടങ്ങിയവയുള്ള AWS-ൽ ഇതിനകം തന്നെ റെഡിമെയ്ഡ് ഇൻഫ്രാസ്ട്രക്ചർ ഉള്ളവർ എന്തുചെയ്യണം? തീർച്ചയായും, നിങ്ങൾക്ക് ഇതെല്ലാം തകർക്കാനോ വീണ്ടും ചെയ്യാനോ താൽപ്പര്യമില്ല, കൂടാതെ നിലവിലുള്ള VPC ഉപയോഗിച്ച് നിലവിലെ നെറ്റ്‌വർക്ക് ഇൻഫ്രാസ്ട്രക്ചറിലേക്ക് പുതിയ EKS ക്ലസ്റ്ററിനെ സംയോജിപ്പിക്കുകയും വേർപെടുത്താൻ, ക്ലസ്റ്ററിനായി പുതിയ സബ്‌നെറ്റുകൾ സൃഷ്ടിക്കുകയും വേണം.

എന്റെ കാര്യത്തിൽ, ഈ പാത തിരഞ്ഞെടുത്തു, ഞാൻ നിലവിലുള്ള 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-യിലേക്ക് വിന്യസിക്കുന്നതിന്, നിങ്ങളുടെ സബ്‌നെറ്റുകളുടെ ഐഡി വ്യക്തമാക്കുക, 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 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-കൺട്രോളറിന് വളരെ ആവശ്യമാണ്, ഒരു പൊതു സബ്‌നെറ്റിന്റെ കാര്യത്തിൽ, അതിന് ഒരു ഇഷ്‌ടാനുസൃത റൂട്ട് പട്ടികയുണ്ട്. അതിനൊരു അസോസിയേഷനുണ്ട്.

ആവശ്യമായ സബ്‌നെറ്റുകളുള്ള പ്രധാന റൂട്ട് ടേബിളിനായി സ്വമേധയാ അസോസിയേഷനുകൾ ചേർക്കുന്നതിലൂടെയും നോഡ്ഗ്രൂപ്പ് വീണ്ടും സൃഷ്‌ടിക്കുന്നതിലൂടെയും എല്ലാം നന്നായി പ്രവർത്തിക്കുന്നു.

അരുൺ ബി. ഈ ബഗ് ശരിക്കും EKS ഡെവലപ്പർമാർക്ക് റിപ്പോർട്ട് ചെയ്യുമെന്ന് ഞാൻ പ്രതീക്ഷിക്കുന്നു, കൂടാതെ എല്ലാം ബോക്‌സിന് പുറത്ത് പ്രവർത്തിക്കുന്ന vpc-കൺട്രോളറിന്റെ ഒരു പുതിയ പതിപ്പ് ഞങ്ങൾ കാണും. നിലവിൽ ഏറ്റവും പുതിയ പതിപ്പ് ഇതാണ്: 602401143452.dkr.ecr.ap-southeast-1.amazonaws.com/eks/vpc-resource-controller:0.2.1
ഈ പ്രശ്നം ഉണ്ട്.

അവസാനം വരെ വായിച്ച എല്ലാവർക്കും നന്ദി, നടപ്പിലാക്കുന്നതിന് മുമ്പ് നിങ്ങൾ ഉൽപ്പാദനത്തിൽ ഉപയോഗിക്കാൻ പോകുന്നതെല്ലാം പരിശോധിക്കുക.

അവലംബം: www.habr.com