കുബർനെറ്റസിലേക്കുള്ള ടിൻഡർ പരിവർത്തനം

കുറിപ്പ്. വിവർത്തനം.: ലോകപ്രശസ്ത ടിൻഡർ സേവനത്തിലെ ജീവനക്കാർ അവരുടെ അടിസ്ഥാന സൗകര്യങ്ങൾ കുബർനെറ്റിലേക്ക് മാറ്റുന്നതിനുള്ള ചില സാങ്കേതിക വിശദാംശങ്ങൾ അടുത്തിടെ പങ്കിട്ടു. ഈ പ്രക്രിയയ്ക്ക് ഏകദേശം രണ്ട് വർഷമെടുത്തു, 8 ആയിരം കണ്ടെയ്‌നറുകളിൽ ഹോസ്റ്റ് ചെയ്‌ത 200 സേവനങ്ങൾ അടങ്ങുന്ന വളരെ വലിയ തോതിലുള്ള ഒരു പ്ലാറ്റ്‌ഫോം K48-കളിൽ സമാരംഭിക്കുന്നതിന് കാരണമായി. ടിൻഡർ എഞ്ചിനീയർമാർ എന്ത് രസകരമായ ബുദ്ധിമുട്ടുകൾ നേരിട്ടു, എന്ത് ഫലങ്ങളാണ് അവർ നേടിയത്? ഈ വിവർത്തനം വായിക്കുക.

എന്തുകൊണ്ട്?

ഏകദേശം രണ്ട് വർഷം മുമ്പ്, ടിൻഡർ അതിന്റെ പ്ലാറ്റ്ഫോം കുബർനെറ്റസിലേക്ക് മാറ്റാൻ തീരുമാനിച്ചു. മാറ്റമില്ലാത്ത വിന്യാസത്തിലൂടെ കുറഞ്ഞ പ്രയത്നത്തോടെ കണ്ടെയ്നറൈസ് ചെയ്യാനും ഉൽപ്പാദനത്തിലേക്ക് നീങ്ങാനും കുബെർനെറ്റസ് ടിൻഡർ ടീമിനെ അനുവദിക്കും. (മാറ്റമില്ലാത്ത വിന്യാസം). ഈ സാഹചര്യത്തിൽ, ആപ്ലിക്കേഷനുകളുടെ അസംബ്ലി, അവയുടെ വിന്യാസം, ഇൻഫ്രാസ്ട്രക്ചർ എന്നിവ കോഡ് ഉപയോഗിച്ച് അദ്വിതീയമായി നിർവചിക്കപ്പെടും.

സ്കേലബിലിറ്റിയുടെയും സ്ഥിരതയുടെയും പ്രശ്നത്തിന് ഞങ്ങൾ പരിഹാരം തേടുകയായിരുന്നു. സ്കെയിലിംഗ് നിർണായകമായപ്പോൾ, പുതിയ EC2 സംഭവങ്ങൾ സ്പിൻ അപ്പ് ചെയ്യുന്നതിന് ഞങ്ങൾക്ക് പലപ്പോഴും കുറച്ച് മിനിറ്റ് കാത്തിരിക്കേണ്ടി വന്നു. കണ്ടെയ്‌നറുകൾ ലോഞ്ച് ചെയ്യുകയും മിനിറ്റുകൾക്ക് പകരം സെക്കൻഡുകൾക്കുള്ളിൽ ട്രാഫിക്ക് സേവനം ആരംഭിക്കുകയും ചെയ്യുക എന്ന ആശയം ഞങ്ങൾക്ക് വളരെ ആകർഷകമായി.

പ്രക്രിയ ബുദ്ധിമുട്ടായി മാറി. 2019-ന്റെ തുടക്കത്തിൽ ഞങ്ങളുടെ മൈഗ്രേഷൻ സമയത്ത്, കുബെർനെറ്റസ് ക്ലസ്റ്റർ നിർണായക പിണ്ഡത്തിലെത്തി, ട്രാഫിക് വോളിയം, ക്ലസ്റ്റർ വലുപ്പം, DNS എന്നിവ കാരണം ഞങ്ങൾ വിവിധ പ്രശ്നങ്ങൾ നേരിടാൻ തുടങ്ങി. വഴിയിൽ, 200 സേവനങ്ങൾ മൈഗ്രേറ്റ് ചെയ്യുന്നതും 1000 നോഡുകളും 15000 പോഡുകളും 48000 റണ്ണിംഗ് കണ്ടെയ്‌നറുകളും അടങ്ങുന്ന ഒരു കുബർനെറ്റസ് ക്ലസ്റ്റർ പരിപാലിക്കുന്നതുമായി ബന്ധപ്പെട്ട രസകരമായ നിരവധി പ്രശ്‌നങ്ങൾ ഞങ്ങൾ പരിഹരിച്ചു.

എങ്ങനെ?

2018 ജനുവരി മുതൽ ഞങ്ങൾ കുടിയേറ്റത്തിന്റെ വിവിധ ഘട്ടങ്ങളിലൂടെ കടന്നുപോയി. ഞങ്ങളുടെ എല്ലാ സേവനങ്ങളും കണ്ടെയ്‌നറൈസ് ചെയ്‌ത് കുബർനെറ്റസ് ടെസ്റ്റ് ക്ലൗഡ് പരിതസ്ഥിതികളിലേക്ക് വിന്യസിച്ചുകൊണ്ടാണ് ഞങ്ങൾ ആരംഭിച്ചത്. ഒക്‌ടോബർ മുതൽ, നിലവിലുള്ള എല്ലാ സേവനങ്ങളും ഞങ്ങൾ ക്യുബർനെറ്റിലേക്ക് ക്രമാനുഗതമായി മൈഗ്രേറ്റ് ചെയ്യാൻ തുടങ്ങി. അടുത്ത വർഷം മാർച്ചോടെ, ഞങ്ങൾ മൈഗ്രേഷൻ പൂർത്തിയാക്കി, ഇപ്പോൾ ടിൻഡർ പ്ലാറ്റ്‌ഫോം കുബർനെറ്റുകളിൽ മാത്രമായി പ്രവർത്തിക്കുന്നു.

കുബർനെറ്റസിനായുള്ള ബിൽഡിംഗ് ഇമേജുകൾ

ഒരു കുബർനെറ്റസ് ക്ലസ്റ്ററിൽ പ്രവർത്തിക്കുന്ന മൈക്രോസർവീസുകൾക്കായി ഞങ്ങൾക്ക് 30-ലധികം സോഴ്‌സ് കോഡ് ശേഖരണങ്ങളുണ്ട്. ഈ റിപ്പോസിറ്ററികളിലെ കോഡ് വ്യത്യസ്ത ഭാഷകളിൽ (ഉദാഹരണത്തിന്, Node.js, Java, Scala, Go) ഒരേ ഭാഷയ്‌ക്കായി ഒന്നിലധികം റൺടൈം പരിതസ്ഥിതികളിൽ എഴുതിയിരിക്കുന്നു.

ഓരോ മൈക്രോസർവീസിനും പൂർണ്ണമായി ഇഷ്ടാനുസൃതമാക്കാവുന്ന "ബിൽഡ് സന്ദർഭം" ലഭ്യമാക്കുന്നതിനാണ് ബിൽഡ് സിസ്റ്റം രൂപകൽപ്പന ചെയ്തിരിക്കുന്നത്. ഇത് സാധാരണയായി ഒരു ഡോക്കർഫയലും ഷെൽ കമാൻഡുകളുടെ ഒരു ലിസ്റ്റും ഉൾക്കൊള്ളുന്നു. അവയുടെ ഉള്ളടക്കം പൂർണ്ണമായും ഇഷ്‌ടാനുസൃതമാക്കാവുന്നതാണ്, അതേ സമയം, ഈ ബിൽഡ് സന്ദർഭങ്ങളെല്ലാം ഒരു സ്റ്റാൻഡേർഡ് ഫോർമാറ്റ് അനുസരിച്ചാണ് എഴുതിയിരിക്കുന്നത്. ബിൽഡ് സന്ദർഭങ്ങൾ സ്റ്റാൻഡേർഡൈസ് ചെയ്യുന്നത് എല്ലാ മൈക്രോസർവീസുകളും കൈകാര്യം ചെയ്യാൻ ഒരൊറ്റ ബിൽഡ് സിസ്റ്റത്തെ അനുവദിക്കുന്നു.

ചിത്രം 1-1. ബിൽഡർ കണ്ടെയ്‌നർ വഴിയുള്ള സ്റ്റാൻഡേർഡ് ബിൽഡ് പ്രോസസ്സ്

റൺടൈമുകൾക്കിടയിൽ പരമാവധി സ്ഥിരത കൈവരിക്കുന്നതിന് (റൺടൈം പരിതസ്ഥിതികൾ) വികസനത്തിലും പരിശോധനയിലും ഒരേ നിർമ്മാണ പ്രക്രിയ ഉപയോഗിക്കുന്നു. ഞങ്ങൾ വളരെ രസകരമായ ഒരു വെല്ലുവിളി നേരിട്ടു: മുഴുവൻ പ്ലാറ്റ്‌ഫോമിലുടനീളമുള്ള ബിൽഡ് പരിതസ്ഥിതിയുടെ സ്ഥിരത ഉറപ്പാക്കാൻ ഞങ്ങൾ ഒരു മാർഗം വികസിപ്പിക്കേണ്ടതുണ്ട്. ഇത് നേടുന്നതിന്, എല്ലാ അസംബ്ലി പ്രക്രിയകളും ഒരു പ്രത്യേക കണ്ടെയ്നറിനുള്ളിൽ നടത്തുന്നു. നിര്മ്മാതാവ്.

അദ്ദേഹത്തിന്റെ കണ്ടെയ്‌നർ നടപ്പിലാക്കുന്നതിന് വിപുലമായ ഡോക്കർ സാങ്കേതിക വിദ്യകൾ ആവശ്യമായിരുന്നു. സ്വകാര്യ ടിൻഡർ ശേഖരണങ്ങൾ ആക്‌സസ് ചെയ്യുന്നതിന് ആവശ്യമായ പ്രാദേശിക ഉപയോക്തൃ ഐഡിയും രഹസ്യങ്ങളും (SSH കീ, AWS ക്രെഡൻഷ്യലുകൾ മുതലായവ) ബിൽഡർക്ക് അവകാശമായി ലഭിക്കുന്നു. ബിൽഡ് ആർട്ടിഫാക്‌റ്റുകൾ സ്വാഭാവികമായി സംഭരിക്കുന്നതിന് ഉറവിടങ്ങൾ അടങ്ങിയ ലോക്കൽ ഡയറക്‌ടറികൾ ഇത് മൗണ്ട് ചെയ്യുന്നു. ഈ സമീപനം പ്രകടനം മെച്ചപ്പെടുത്തുന്നു, കാരണം ബിൽഡർ കണ്ടെയ്‌നറിനും ഹോസ്റ്റിനും ഇടയിൽ ബിൽഡ് ആർട്ടിഫാക്‌റ്റുകൾ പകർത്തേണ്ടതിന്റെ ആവശ്യകത ഇത് ഇല്ലാതാക്കുന്നു. അധിക കോൺഫിഗറേഷൻ കൂടാതെ സംഭരിച്ച ബിൽഡ് ആർട്ടിഫാക്റ്റുകൾ വീണ്ടും ഉപയോഗിക്കാനാകും.

ചില സേവനങ്ങൾക്കായി, റൺടൈം എൻവയോൺമെന്റിലേക്ക് കംപൈലേഷൻ എൻവയോൺമെന്റ് മാപ്പ് ചെയ്യുന്നതിന് ഞങ്ങൾക്ക് മറ്റൊരു കണ്ടെയ്‌നർ സൃഷ്‌ടിക്കേണ്ടതുണ്ട് (ഉദാഹരണത്തിന്, ഇൻസ്റ്റാളേഷൻ സമയത്ത് Node.js bcrypt ലൈബ്രറി പ്ലാറ്റ്‌ഫോം-നിർദ്ദിഷ്ട ബൈനറി ആർട്ടിഫാക്‌റ്റുകൾ സൃഷ്ടിക്കുന്നു). കംപൈലേഷൻ പ്രക്രിയയിൽ, സേവനങ്ങൾക്കിടയിൽ ആവശ്യകതകൾ വ്യത്യാസപ്പെടാം, അവസാന ഡോക്കർഫയൽ ഈച്ചയിൽ സമാഹരിക്കുന്നു.

കുബർനെറ്റസ് ക്ലസ്റ്റർ ആർക്കിടെക്ചറും മൈഗ്രേഷനും

ക്ലസ്റ്റർ വലിപ്പം മാനേജ്മെന്റ്

ഉപയോഗിക്കാൻ ഞങ്ങൾ തീരുമാനിച്ചു kube-aws ആമസോൺ EC2 സന്ദർഭങ്ങളിൽ ഓട്ടോമേറ്റഡ് ക്ലസ്റ്റർ വിന്യാസത്തിനായി. തുടക്കത്തിൽ തന്നെ, എല്ലാം ഒരു സാധാരണ നോഡുകളിൽ പ്രവർത്തിച്ചു. വിഭവങ്ങളുടെ കൂടുതൽ കാര്യക്ഷമമായ ഉപയോഗത്തിനായി ജോലിഭാരങ്ങൾ വലുപ്പവും ഉദാഹരണ തരവും അനുസരിച്ച് വേർതിരിക്കേണ്ടതിന്റെ ആവശ്യകത ഞങ്ങൾ പെട്ടെന്ന് മനസ്സിലാക്കി. നിരവധി ലോഡഡ് മൾട്ടി-ത്രെഡഡ് പോഡുകൾ പ്രവർത്തിപ്പിക്കുന്നത് പ്രകടനത്തിന്റെ കാര്യത്തിൽ കൂടുതൽ പ്രവചിക്കാവുന്ന ഒന്നായി മാറിയത്, ഒരു വലിയ ത്രെഡുള്ള പോഡുകളുമായുള്ള അവയുടെ സഹവർത്തിത്വത്തേക്കാൾ കൂടുതലാണ്.

അവസാനം ഞങ്ങൾ സ്ഥിരതാമസമാക്കി:

• m5.4x വലുത് - നിരീക്ഷണത്തിനായി (പ്രോമിത്യൂസ്);
• c5.4x വലുത് - Node.js വർക്ക്ലോഡിന് (സിംഗിൾ-ത്രെഡഡ് വർക്ക്ലോഡ്);
• c5.2x വലുത് - ജാവയ്ക്കും ഗോയ്ക്കും (മൾട്ടി ത്രെഡഡ് വർക്ക്ലോഡ്);
• c5.4x വലുത് - നിയന്ത്രണ പാനലിനായി (3 നോഡുകൾ).

മിഗ്രാഷ്യ

പഴയ ഇൻഫ്രാസ്ട്രക്ചറിൽ നിന്ന് കുബർനെറ്റസിലേക്ക് മാറുന്നതിനുള്ള തയ്യാറെടുപ്പ് ഘട്ടങ്ങളിലൊന്ന്, സേവനങ്ങൾ തമ്മിലുള്ള നിലവിലുള്ള നേരിട്ടുള്ള ആശയവിനിമയം പുതിയ ലോഡ് ബാലൻസറുകളിലേക്ക് (ഇലാസ്റ്റിക് ലോഡ് ബാലൻസറുകൾ (ELB) റീഡയറക്ട് ചെയ്യുക എന്നതാണ്. ഒരു വെർച്വൽ പ്രൈവറ്റ് ക്ലൗഡിന്റെ (VPC) ഒരു പ്രത്യേക സബ്‌നെറ്റിലാണ് അവ സൃഷ്‌ടിച്ചത്. ഈ സബ്‌നെറ്റ് ഒരു കുബർനെറ്റസ് വിപിസിയുമായി ബന്ധിപ്പിച്ചിരിക്കുന്നു. സേവന ഡിപൻഡൻസികളുടെ പ്രത്യേക ക്രമം പരിഗണിക്കാതെ മൊഡ്യൂളുകൾ ക്രമേണ മൈഗ്രേറ്റ് ചെയ്യാൻ ഇത് ഞങ്ങളെ അനുവദിച്ചു.

ഓരോ പുതിയ ELB-ലേയ്ക്കും ചൂണ്ടിക്കാണിക്കുന്ന CNAME-കൾ ഉള്ള DNS റെക്കോർഡുകളുടെ വെയ്റ്റഡ് സെറ്റുകൾ ഉപയോഗിച്ചാണ് ഈ എൻഡ് പോയിന്റുകൾ സൃഷ്‌ടിച്ചത്. മാറുന്നതിന്, 0 ഭാരമുള്ള കുബർനെറ്റസ് സേവനത്തിന്റെ പുതിയ ELB-ലേക്ക് ചൂണ്ടിക്കാണിക്കുന്ന ഒരു പുതിയ എൻട്രി ഞങ്ങൾ ചേർത്തു. തുടർന്ന് ഞങ്ങൾ എൻട്രിയുടെ ടൈം ടു ലൈവ് (TTL) 0 ആയി സജ്ജീകരിച്ചു. ഇതിന് ശേഷം, പഴയതും പുതിയതുമായ ഭാരങ്ങൾ സാവധാനം ക്രമീകരിച്ചു, ഒടുവിൽ ലോഡിന്റെ 100% പുതിയ സെർവറിലേക്ക് അയച്ചു. സ്വിച്ചിംഗ് പൂർത്തിയായ ശേഷം, TTL മൂല്യം കൂടുതൽ മതിയായ തലത്തിലേക്ക് മടങ്ങി.

ഞങ്ങളുടെ പക്കലുണ്ടായിരുന്ന ജാവ മൊഡ്യൂളുകൾക്ക് കുറഞ്ഞ TTL DNS-നെ നേരിടാൻ കഴിയും, പക്ഷേ നോഡ് ആപ്ലിക്കേഷനുകൾക്ക് കഴിഞ്ഞില്ല. എഞ്ചിനീയർമാരിൽ ഒരാൾ കണക്ഷൻ പൂൾ കോഡിന്റെ ഒരു ഭാഗം മാറ്റിയെഴുതി, ഓരോ 60 സെക്കൻഡിലും പൂളുകൾ അപ്ഡേറ്റ് ചെയ്യുന്ന ഒരു മാനേജരിൽ പൊതിഞ്ഞു. തിരഞ്ഞെടുക്കപ്പെട്ട സമീപനം വളരെ നന്നായി പ്രവർത്തിച്ചു, കൂടാതെ ശ്രദ്ധേയമായ പ്രകടന തകർച്ചയൊന്നും കൂടാതെ.

പാഠങ്ങൾ

നെറ്റ്‌വർക്ക് ഫാബ്രിക്കിന്റെ പരിധികൾ

8 ജനുവരി 2019 ന് അതിരാവിലെ, ടിൻഡർ പ്ലാറ്റ്ഫോം അപ്രതീക്ഷിതമായി തകർന്നു. അന്നുരാവിലെ പ്ലാറ്റ്‌ഫോം ലേറ്റൻസിയിൽ ബന്ധമില്ലാത്ത വർദ്ധനവിന് മറുപടിയായി, ക്ലസ്റ്ററിലെ പോഡുകളുടെയും നോഡുകളുടെയും എണ്ണം വർദ്ധിച്ചു. ഇത് ഞങ്ങളുടെ എല്ലാ നോഡുകളിലും ARP കാഷെ തീർന്നു.

ARP കാഷെയുമായി ബന്ധപ്പെട്ട മൂന്ന് ലിനക്സ് ഓപ്ഷനുകൾ ഉണ്ട്:

(ഉറവിടം)

gc_thresh3 - ഇതൊരു കഠിനമായ പരിധിയാണ്. ലോഗിൽ "അയൽപക്കത്തെ മേശ ഓവർഫ്ലോ" എൻട്രികൾ പ്രത്യക്ഷപ്പെടുന്നതിന്റെ അർത്ഥം, സിൻക്രണസ് ഗാർബേജ് കളക്ഷന് (ജിസി) ശേഷവും, അയൽ എൻട്രി സംഭരിക്കുന്നതിന് ARP കാഷെയിൽ മതിയായ ഇടമില്ല എന്നാണ്. ഈ സാഹചര്യത്തിൽ, കേർണൽ പാക്കറ്റ് പൂർണ്ണമായും നിരസിച്ചു.

ഞങ്ങൾ ഉപയോഗിക്കുന്നു ഫ്ലാനെൽ കുബെർനെറ്റസിലെ ഒരു നെറ്റ്‌വർക്ക് ഫാബ്രിക്കായി. VXLAN വഴിയാണ് പാക്കറ്റുകൾ കൈമാറുന്നത്. VXLAN ഒരു L2 നെറ്റ്‌വർക്കിന് മുകളിൽ ഉയർത്തിയ ഒരു L3 തുരങ്കമാണ്. സാങ്കേതികവിദ്യ MAC-in-UDP (MAC അഡ്രസ്-ഇൻ-യൂസർ ഡാറ്റാഗ്രാം പ്രോട്ടോക്കോൾ) എൻക്യാപ്‌സുലേഷൻ ഉപയോഗിക്കുന്നു കൂടാതെ ലെയർ 2 നെറ്റ്‌വർക്ക് സെഗ്‌മെന്റുകളുടെ വിപുലീകരണം അനുവദിക്കുന്നു. ഫിസിക്കൽ ഡാറ്റാ സെന്റർ നെറ്റ്‌വർക്കിലെ ട്രാൻസ്പോർട്ട് പ്രോട്ടോക്കോൾ IP പ്ലസ് UDP ആണ്.

ചിത്രം 2-1. ഫ്ലാനൽ ഡയഗ്രം (ഉറവിടം)

ചിത്രം 2-2. VXLAN പാക്കേജ് (ഉറവിടം)

ഓരോ കുബർനെറ്റസ് വർക്കർ നോഡും ഒരു വലിയ /24 ബ്ലോക്കിൽ നിന്ന് /9 മാസ്കുള്ള ഒരു വെർച്വൽ അഡ്രസ് സ്പേസ് അനുവദിക്കുന്നു. ഓരോ നോഡിനും ഇത് അർത്ഥം റൂട്ടിംഗ് ടേബിളിൽ ഒരു എൻട്രി, ARP ടേബിളിൽ ഒരു എൻട്രി (ഫ്ലാനെൽ.1 ഇന്റർഫേസിൽ), സ്വിച്ചിംഗ് ടേബിളിൽ ഒരു എൻട്രി (FDB). ഒരു വർക്കർ നോഡ് ആരംഭിക്കുമ്പോഴോ ഓരോ തവണയും ഒരു പുതിയ നോഡ് കണ്ടെത്തുമ്പോഴോ അവ ചേർക്കുന്നു.

കൂടാതെ, നോഡ്-പോഡ് (അല്ലെങ്കിൽ പോഡ്-പോഡ്) ആശയവിനിമയം ആത്യന്തികമായി ഇന്റർഫേസിലൂടെ കടന്നുപോകുന്നു eth0 (മുകളിലുള്ള ഫ്ലാനൽ ഡയഗ്രാമിൽ കാണിച്ചിരിക്കുന്നതുപോലെ). ഇത് ഓരോ അനുബന്ധ ഉറവിടത്തിനും ഡെസ്റ്റിനേഷൻ ഹോസ്റ്റിനുമായി ARP പട്ടികയിൽ ഒരു അധിക എൻട്രിക്ക് കാരണമാകുന്നു.

നമ്മുടെ പരിതസ്ഥിതിയിൽ, ഇത്തരത്തിലുള്ള ആശയവിനിമയം വളരെ സാധാരണമാണ്. Kubernetes-ലെ സേവന വസ്തുക്കൾക്കായി, ഒരു ELB സൃഷ്‌ടിക്കുകയും Kubernetes ഓരോ നോഡും ELB-ൽ രജിസ്റ്റർ ചെയ്യുകയും ചെയ്യുന്നു. ELB-ന് പോഡുകളെക്കുറിച്ച് ഒന്നും അറിയില്ല, തിരഞ്ഞെടുത്ത നോഡ് പാക്കറ്റിന്റെ അന്തിമ ലക്ഷ്യസ്ഥാനമായിരിക്കില്ല. ELB-യിൽ നിന്ന് ഒരു നോഡിന് ഒരു പാക്കറ്റ് ലഭിക്കുമ്പോൾ, അത് നിയമങ്ങൾ കണക്കിലെടുത്ത് അത് പരിഗണിക്കുന്നു എന്നതാണ് കാര്യം. iptables ഒരു നിർദ്ദിഷ്ട സേവനത്തിനായി മറ്റൊരു നോഡിൽ ക്രമരഹിതമായി ഒരു പോഡ് തിരഞ്ഞെടുക്കുന്നു.

പരാജയസമയത്ത്, ക്ലസ്റ്ററിൽ 605 നോഡുകൾ ഉണ്ടായിരുന്നു. മുകളിൽ പറഞ്ഞ കാരണങ്ങളാൽ, പ്രാധാന്യം മറികടക്കാൻ ഇത് മതിയായിരുന്നു gc_thresh3, ഏതാണ് സ്ഥിരസ്ഥിതി. ഇത് സംഭവിക്കുമ്പോൾ, പാക്കറ്റുകൾ ഡ്രോപ്പ് ചെയ്യാൻ തുടങ്ങുക മാത്രമല്ല, /24 മാസ്കുള്ള മുഴുവൻ ഫ്ലാനൽ വെർച്വൽ വിലാസ ഇടവും ARP പട്ടികയിൽ നിന്ന് അപ്രത്യക്ഷമാകും. നോഡ്-പോഡ് ആശയവിനിമയവും ഡിഎൻഎസ് അന്വേഷണങ്ങളും തടസ്സപ്പെട്ടു (ഡിഎൻഎസ് ഒരു ക്ലസ്റ്ററിലാണ് ഹോസ്റ്റ് ചെയ്തിരിക്കുന്നത്; വിശദാംശങ്ങൾക്ക് ഈ ലേഖനത്തിൽ പിന്നീട് വായിക്കുക).

ഈ പ്രശ്നം പരിഹരിക്കാൻ, നിങ്ങൾ മൂല്യങ്ങൾ വർദ്ധിപ്പിക്കേണ്ടതുണ്ട് gc_thresh1, gc_thresh2 и gc_thresh3 നഷ്‌ടമായ നെറ്റ്‌വർക്കുകൾ വീണ്ടും രജിസ്റ്റർ ചെയ്യുന്നതിന് ഫ്ലാനൽ പുനരാരംഭിക്കുക.

അപ്രതീക്ഷിത DNS സ്കെയിലിംഗ്

മൈഗ്രേഷൻ പ്രക്രിയയിൽ, ട്രാഫിക് നിയന്ത്രിക്കാനും പഴയ ഇൻഫ്രാസ്ട്രക്ചറിൽ നിന്ന് കുബർനെറ്റസിലേക്ക് സേവനങ്ങൾ ക്രമേണ കൈമാറാനും ഞങ്ങൾ DNS സജീവമായി ഉപയോഗിച്ചു. Route53-ൽ ബന്ധപ്പെട്ട റെക്കോർഡ്സെറ്റുകൾക്കായി ഞങ്ങൾ താരതമ്യേന കുറഞ്ഞ TTL മൂല്യങ്ങൾ സജ്ജമാക്കി. പഴയ ഇൻഫ്രാസ്ട്രക്ചർ EC2 സന്ദർഭങ്ങളിൽ പ്രവർത്തിക്കുമ്പോൾ, ഞങ്ങളുടെ റിസോൾവർ കോൺഫിഗറേഷൻ ആമസോൺ DNS-ലേക്ക് ചൂണ്ടിക്കാണിച്ചു. ഞങ്ങൾ ഇത് നിസ്സാരമായി കണക്കാക്കി, ഞങ്ങളുടെ സേവനങ്ങളിലും ആമസോൺ സേവനങ്ങളിലും (ഡൈനമോഡിബി പോലുള്ളവ) കുറഞ്ഞ TTL-ന്റെ സ്വാധീനം കാര്യമായി ശ്രദ്ധിക്കപ്പെടാതെ പോയി.

ഞങ്ങൾ കുബർനെറ്റസിലേക്ക് സേവനങ്ങൾ മൈഗ്രേറ്റ് ചെയ്യുമ്പോൾ, DNS സെക്കൻഡിൽ 250 ആയിരം അഭ്യർത്ഥനകൾ പ്രോസസ്സ് ചെയ്യുന്നതായി ഞങ്ങൾ കണ്ടെത്തി. തൽഫലമായി, ഡിഎൻഎസ് അന്വേഷണങ്ങൾക്കായി ആപ്ലിക്കേഷനുകൾ സ്ഥിരവും ഗൗരവമേറിയതുമായ സമയപരിധി അനുഭവിക്കാൻ തുടങ്ങി. DNS ദാതാവിനെ ഒപ്റ്റിമൈസ് ചെയ്യാനും CoreDNS ലേക്ക് മാറ്റാനുമുള്ള അവിശ്വസനീയമായ ശ്രമങ്ങൾക്കിടയിലും ഇത് സംഭവിച്ചു (അത് പീക്ക് ലോഡിൽ 1000 കോറുകളിൽ പ്രവർത്തിക്കുന്ന 120 പോഡുകളിൽ എത്തി).

സാധ്യമായ മറ്റ് കാരണങ്ങളും പരിഹാരങ്ങളും ഗവേഷണം ചെയ്യുമ്പോൾ, ഞങ്ങൾ കണ്ടെത്തി ഒരു ലേഖനം, പാക്കറ്റ് ഫിൽട്ടറിംഗ് ചട്ടക്കൂടിനെ ബാധിക്കുന്ന റേസ് അവസ്ഥകൾ വിവരിക്കുന്നു netfilter ലിനക്സിൽ. വർദ്ധിച്ചുവരുന്ന കൗണ്ടറിനൊപ്പം ഞങ്ങൾ നിരീക്ഷിച്ച സമയപരിധി insert_failed ഫ്ലാനൽ ഇന്റർഫേസിൽ ലേഖനത്തിന്റെ കണ്ടെത്തലുകളുമായി പൊരുത്തപ്പെടുന്നു.

സോഴ്‌സ് ആൻഡ് ഡെസ്റ്റിനേഷൻ നെറ്റ്‌വർക്ക് അഡ്രസ് ട്രാൻസ്ലേഷന്റെ (SNAT, DNAT) ഘട്ടത്തിലാണ് പ്രശ്നം സംഭവിക്കുന്നത്, തുടർന്ന് പട്ടികയിലേക്കുള്ള എൻട്രി കോൺട്രാക്ക്. ആന്തരികമായി ചർച്ച ചെയ്യുകയും സമൂഹം നിർദ്ദേശിക്കുകയും ചെയ്ത ഒരു പരിഹാരമാർഗ്ഗം DNS വർക്കർ നോഡിലേക്ക് തന്നെ നീക്കുക എന്നതായിരുന്നു. ഈ സാഹചര്യത്തിൽ:

• SNAT ആവശ്യമില്ല, കാരണം ട്രാഫിക് നോഡിനുള്ളിൽ തന്നെ തുടരുന്നു. ഇത് ഇന്റർഫേസിലൂടെ റൂട്ട് ചെയ്യേണ്ടതില്ല eth0.
• ലക്ഷ്യസ്ഥാന ഐപി നോഡിന് പ്രാദേശികമായതിനാൽ ഡിഎൻഎടി ആവശ്യമില്ല, നിയമങ്ങൾക്കനുസരിച്ച് ക്രമരഹിതമായി തിരഞ്ഞെടുത്ത പോഡ് അല്ല iptables.

ഈ സമീപനത്തിൽ ഉറച്ചുനിൽക്കാൻ ഞങ്ങൾ തീരുമാനിച്ചു. CoreDNS ഒരു ഡെമൺസെറ്റായി കുബർനെറ്റസിൽ വിന്യസിച്ചു, ഞങ്ങൾ ഒരു ലോക്കൽ നോഡ് DNS സെർവർ നടപ്പിലാക്കി resolutionv.conf ഓരോ പോഡും ഒരു പതാക സജ്ജീകരിച്ചുകൊണ്ട് --ക്ലസ്റ്റർ-ഡിഎൻഎസ് കമാൻഡുകൾ കുബെലെറ്റ് . DNS കാലഹരണപ്പെടലുകൾക്ക് ഈ പരിഹാരം ഫലപ്രദമാണ്.

എന്നിരുന്നാലും, ഞങ്ങൾ ഇപ്പോഴും പാക്കറ്റ് നഷ്ടവും കൗണ്ടറിൽ വർദ്ധനവും കണ്ടു insert_failed ഫ്ലാനൽ ഇന്റർഫേസിൽ. DNS ട്രാഫിക്കിന് വേണ്ടി മാത്രം SNAT കൂടാതെ/അല്ലെങ്കിൽ DNAT ഇല്ലാതാക്കാൻ ഞങ്ങൾക്ക് കഴിഞ്ഞതിനാൽ, പരിഹാരം നടപ്പിലാക്കിയതിന് ശേഷവും ഇത് തുടർന്നു. മറ്റ് തരത്തിലുള്ള ട്രാഫിക്കുകൾക്കായി റേസ് വ്യവസ്ഥകൾ സംരക്ഷിക്കപ്പെട്ടു. ഭാഗ്യവശാൽ, ഞങ്ങളുടെ പാക്കറ്റുകളിൽ ഭൂരിഭാഗവും TCP ആണ്, ഒരു പ്രശ്നം ഉണ്ടായാൽ അവ വീണ്ടും സംപ്രേഷണം ചെയ്യപ്പെടും. എല്ലാത്തരം ട്രാഫിക്കുകൾക്കും അനുയോജ്യമായ ഒരു പരിഹാരം കണ്ടെത്താൻ ഞങ്ങൾ ഇപ്പോഴും ശ്രമിക്കുന്നു.

മികച്ച ലോഡ് ബാലൻസിംഗിനായി ദൂതനെ ഉപയോഗിക്കുന്നു

ഞങ്ങൾ ബാക്കെൻഡ് സേവനങ്ങൾ കുബെർനെറ്റസിലേക്ക് മൈഗ്രേറ്റ് ചെയ്‌തപ്പോൾ, കായ്‌കൾക്കിടയിലുള്ള അസന്തുലിതമായ ലോഡ് ഞങ്ങൾ അനുഭവിക്കാൻ തുടങ്ങി. ഓരോ വിന്യാസത്തിന്റെയും ആദ്യ റെഡി പോഡുകളിൽ ELB കണക്ഷനുകൾ തൂങ്ങിക്കിടക്കാൻ HTTP Keepalive കാരണമായെന്ന് ഞങ്ങൾ കണ്ടെത്തി. അങ്ങനെ, ട്രാഫിക്കിന്റെ ഭൂരിഭാഗവും ലഭ്യമായ പോഡുകളുടെ ഒരു ചെറിയ ശതമാനം കടന്നുപോയി. ഏറ്റവും മോശം സാഹചര്യങ്ങൾക്കുള്ള പുതിയ വിന്യാസങ്ങളിൽ MaxSurge 100% ആയി സജ്ജീകരിക്കുക എന്നതാണ് ഞങ്ങൾ പരീക്ഷിച്ച ആദ്യ പരിഹാരം. വലിയ വിന്യാസങ്ങളുടെ കാര്യത്തിൽ പ്രഭാവം നിസ്സാരവും വിട്ടുവീഴ്ചയില്ലാത്തതുമായി മാറി.

നിർണായക സേവനങ്ങൾക്കായുള്ള റിസോഴ്സ് അഭ്യർത്ഥനകൾ കൃത്രിമമായി വർദ്ധിപ്പിക്കുക എന്നതാണ് ഞങ്ങൾ ഉപയോഗിച്ച മറ്റൊരു പരിഹാരം. ഈ സാഹചര്യത്തിൽ, മറ്റ് ഭാരമുള്ള കായ്കളുമായി താരതമ്യം ചെയ്യുമ്പോൾ സമീപത്ത് സ്ഥാപിച്ചിരിക്കുന്ന കായ്കൾക്ക് കൂടുതൽ ഇടം ലഭിക്കും. ഇത് ദീർഘകാലാടിസ്ഥാനത്തിൽ പ്രവർത്തിക്കില്ല, കാരണം ഇത് വിഭവങ്ങൾ പാഴാക്കും. കൂടാതെ, ഞങ്ങളുടെ നോഡ് ആപ്ലിക്കേഷനുകൾ ഒറ്റ-ത്രെഡ് ആയിരുന്നു, അതനുസരിച്ച്, ഒരു കോർ മാത്രമേ ഉപയോഗിക്കാനാകൂ. മികച്ച ലോഡ് ബാലൻസിങ് ഉപയോഗിക്കുക എന്നതായിരുന്നു യഥാർത്ഥ പരിഹാരം.

പൂർണ്ണമായി അഭിനന്ദിക്കാൻ ഞങ്ങൾ വളരെക്കാലമായി ആഗ്രഹിക്കുന്നു എൻവയ്ക്കൊപ്പം. നിലവിലെ സാഹചര്യം അത് വളരെ പരിമിതമായ രീതിയിൽ വിന്യസിക്കാനും ഉടനടി ഫലങ്ങൾ നേടാനും ഞങ്ങളെ അനുവദിച്ചു. വലിയ SOA ആപ്ലിക്കേഷനുകൾക്കായി രൂപകൽപ്പന ചെയ്‌തിരിക്കുന്ന ഉയർന്ന പ്രവർത്തനക്ഷമതയുള്ള, ഓപ്പൺ സോഴ്‌സ്, ലെയർ-XNUMX പ്രോക്‌സിയാണ് എൻവോയ്. ഇതിന് ഓട്ടോമാറ്റിക് റിട്രീകൾ, സർക്യൂട്ട് ബ്രേക്കറുകൾ, ആഗോള നിരക്ക് പരിമിതപ്പെടുത്തൽ എന്നിവ ഉൾപ്പെടെ വിപുലമായ ലോഡ് ബാലൻസിങ് ടെക്നിക്കുകൾ നടപ്പിലാക്കാൻ കഴിയും. (കുറിപ്പ്. വിവർത്തനം.: നിങ്ങൾക്ക് ഇതിനെക്കുറിച്ച് കൂടുതൽ വായിക്കാം ഈ ലേഖനം ദൂതനെ അടിസ്ഥാനമാക്കിയുള്ള ഇസ്തിയോയെക്കുറിച്ച്.)

ഞങ്ങൾ ഇനിപ്പറയുന്ന കോൺഫിഗറേഷനുമായി എത്തി: ഓരോ പോഡിനും ഒരു എൻവോയ് സൈഡ്‌കാറും ഒരൊറ്റ റൂട്ടും ഉണ്ടായിരിക്കുക, കൂടാതെ പോർട്ട് വഴി പ്രാദേശികമായി കണ്ടെയ്‌നറുമായി ക്ലസ്റ്ററിനെ ബന്ധിപ്പിക്കുക. സാധ്യതയുള്ള കാസ്‌കേഡിംഗ് കുറയ്ക്കുന്നതിനും ഒരു ചെറിയ ഹിറ്റ് റേഡിയസ് നിലനിർത്തുന്നതിനും, ഞങ്ങൾ എൻവോയ് ഫ്രണ്ട്-പ്രോക്‌സി പോഡുകളുടെ ഒരു കൂട്ടം ഉപയോഗിച്ചു, ഓരോ സേവനത്തിനും ഓരോ ലഭ്യത മേഖലയിലും (AZ) ഒന്ന്. ഞങ്ങളുടെ എഞ്ചിനീയർമാരിൽ ഒരാൾ എഴുതിയ ഒരു ലളിതമായ സേവന കണ്ടെത്തൽ എഞ്ചിനെ അവർ ആശ്രയിച്ചു, അത് നൽകിയ സേവനത്തിനായി ഓരോ AZ-ലെയും പോഡുകളുടെ ഒരു ലിസ്റ്റ് തിരികെ നൽകി.

സർവീസ് ഫ്രണ്ട്-എൻവോയ്‌സ് പിന്നീട് ഒരു അപ്‌സ്ട്രീം ക്ലസ്റ്ററും റൂട്ടും ഉപയോഗിച്ച് ഈ സേവന കണ്ടെത്തൽ സംവിധാനം ഉപയോഗിച്ചു. ഞങ്ങൾ മതിയായ സമയപരിധി സജ്ജീകരിച്ചു, എല്ലാ സർക്യൂട്ട് ബ്രേക്കർ ക്രമീകരണങ്ങളും വർദ്ധിപ്പിച്ചു, ഒറ്റ പരാജയങ്ങളെ സഹായിക്കുന്നതിനും സുഗമമായ വിന്യാസങ്ങൾ ഉറപ്പാക്കുന്നതിനുമായി ഏറ്റവും കുറഞ്ഞ റീട്രി കോൺഫിഗറേഷൻ ചേർത്തു. ഈ സർവീസ് ഫ്രണ്ട് എൻവോയ്‌സിന് മുന്നിൽ ഞങ്ങൾ ഒരു TCP ELB സ്ഥാപിച്ചു. ഞങ്ങളുടെ പ്രധാന പ്രോക്‌സി ലെയറിൽ നിന്നുള്ള കീപലൈവ് ചില എൻവോയ് പോഡുകളിൽ കുടുങ്ങിയിട്ടുണ്ടെങ്കിലും, അവർക്ക് ഇപ്പോഴും ലോഡ് കൂടുതൽ നന്നായി കൈകാര്യം ചെയ്യാൻ കഴിയും, കൂടാതെ ബാക്കെൻഡിലെ lowest_request വഴി ബാലൻസ് ചെയ്യാൻ കോൺഫിഗർ ചെയ്‌തു.

വിന്യാസത്തിനായി, ആപ്ലിക്കേഷൻ പോഡുകളിലും സൈഡ്കാർ പോഡുകളിലും ഞങ്ങൾ പ്രീസ്റ്റോപ്പ് ഹുക്ക് ഉപയോഗിച്ചു. സൈഡ്‌കാർ കണ്ടെയ്‌നറിൽ സ്ഥിതിചെയ്യുന്ന അഡ്‌മിൻ എൻഡ്‌പോയിന്റിന്റെ നില പരിശോധിക്കുന്നതിൽ ഹുക്ക് ഒരു പിശക് സൃഷ്‌ടിക്കുകയും സജീവമായ കണക്ഷനുകൾ അവസാനിപ്പിക്കാൻ അനുവദിക്കുന്നതിന് അൽപ്പസമയം ഉറങ്ങുകയും ചെയ്‌തു.

ഒരു സാധാരണ പ്രോമിത്യൂസ് ഇൻസ്റ്റാളേഷനിലേക്ക് എളുപ്പത്തിൽ സംയോജിപ്പിക്കാൻ കഴിയുന്ന വിശദമായ മെട്രിക്‌സാണ് ഞങ്ങൾക്ക് ഇത്ര വേഗത്തിൽ നീങ്ങാൻ കഴിഞ്ഞതിന്റെ ഒരു കാരണം. ഞങ്ങൾ കോൺഫിഗറേഷൻ പാരാമീറ്ററുകൾ ക്രമീകരിക്കുകയും ട്രാഫിക് പുനർവിതരണം ചെയ്യുകയും ചെയ്യുമ്പോൾ എന്താണ് സംഭവിക്കുന്നതെന്ന് കൃത്യമായി കാണാൻ ഇത് ഞങ്ങളെ അനുവദിച്ചു.

ഫലങ്ങൾ ഉടനടി വ്യക്തമായിരുന്നു. ഞങ്ങൾ ആരംഭിച്ചത് ഏറ്റവും അസന്തുലിതമായ സേവനങ്ങളിൽ നിന്നാണ്, ഇപ്പോൾ ഇത് ക്ലസ്റ്ററിലെ ഏറ്റവും പ്രധാനപ്പെട്ട 12 സേവനങ്ങൾക്ക് മുന്നിൽ പ്രവർത്തിക്കുന്നു. ഈ വർഷം കൂടുതൽ നൂതനമായ സേവന കണ്ടെത്തൽ, സർക്യൂട്ട് ബ്രേക്കിംഗ്, ഔട്ട്‌ലിയർ കണ്ടെത്തൽ, നിരക്ക് പരിമിതപ്പെടുത്തൽ, കണ്ടെത്തൽ എന്നിവയുള്ള ഒരു പൂർണ്ണ സേവന മെഷിലേക്ക് മാറാൻ ഞങ്ങൾ പദ്ധതിയിടുന്നു.

ചിത്രം 3-1. എൻവോയിലേക്കുള്ള പരിവർത്തന സമയത്ത് ഒരു സേവനത്തിന്റെ സിപിയു സംയോജനം

അന്തിമഫലം

ഈ അനുഭവത്തിലൂടെയും അധിക ഗവേഷണത്തിലൂടെയും, വലിയ കുബർനെറ്റസ് ക്ലസ്റ്ററുകൾ രൂപകൽപ്പന ചെയ്യുന്നതിലും വിന്യസിക്കുന്നതിലും പ്രവർത്തിപ്പിക്കുന്നതിലും ശക്തമായ വൈദഗ്ധ്യമുള്ള ശക്തമായ ഒരു ഇൻഫ്രാസ്ട്രക്ചർ ടീമിനെ ഞങ്ങൾ നിർമ്മിച്ചിട്ടുണ്ട്. എല്ലാ ടിൻഡർ എഞ്ചിനീയർമാർക്കും ഇപ്പോൾ കണ്ടെയ്‌നറുകൾ പാക്കേജുചെയ്യാനും കുബർനെറ്റുകളിലേക്ക് ആപ്ലിക്കേഷനുകൾ വിന്യസിക്കാനും അറിവും അനുഭവവും ഉണ്ട്.

പഴയ ഇൻഫ്രാസ്ട്രക്ചറിൽ അധിക ശേഷി ആവശ്യമായി വന്നപ്പോൾ, പുതിയ EC2 സംഭവങ്ങൾ സമാരംഭിക്കുന്നതിന് ഞങ്ങൾക്ക് കുറച്ച് മിനിറ്റ് കാത്തിരിക്കേണ്ടി വന്നു. ഇപ്പോൾ കണ്ടെയ്‌നറുകൾ പ്രവർത്തിക്കാൻ തുടങ്ങുകയും മിനിറ്റുകൾക്കുള്ളിൽ ട്രാഫിക് പ്രോസസ്സ് ചെയ്യാൻ തുടങ്ങുകയും ചെയ്യുന്നു. ഒരൊറ്റ EC2 ഉദാഹരണത്തിൽ ഒന്നിലധികം കണ്ടെയ്‌നറുകൾ ഷെഡ്യൂൾ ചെയ്യുന്നത് മെച്ചപ്പെട്ട തിരശ്ചീന സാന്ദ്രത നൽകുന്നു. തൽഫലമായി, കഴിഞ്ഞ വർഷത്തെ അപേക്ഷിച്ച് 2019 ൽ EC2 ചെലവിൽ ഗണ്യമായ കുറവുണ്ടാകുമെന്ന് ഞങ്ങൾ പ്രവചിക്കുന്നു.

മൈഗ്രേഷൻ ഏകദേശം രണ്ട് വർഷമെടുത്തു, പക്ഷേ ഞങ്ങൾ അത് 2019 മാർച്ചിൽ പൂർത്തിയാക്കി. നിലവിൽ, ടിൻഡർ പ്ലാറ്റ്‌ഫോം 200 സേവനങ്ങളും 1000 നോഡുകളും 15 പോഡുകളും 000 റണ്ണിംഗ് കണ്ടെയ്‌നറുകളും അടങ്ങുന്ന ഒരു കുബർനെറ്റസ് ക്ലസ്റ്ററിൽ മാത്രം പ്രവർത്തിക്കുന്നു. ഇൻഫ്രാസ്ട്രക്ചർ ഇപ്പോൾ ഓപ്പറേഷൻ ടീമുകളുടെ ഏക ഡൊമെയ്‌നല്ല. ഞങ്ങളുടെ എല്ലാ എഞ്ചിനീയർമാരും ഈ ഉത്തരവാദിത്തം പങ്കിടുകയും കോഡ് മാത്രം ഉപയോഗിച്ച് അവരുടെ ആപ്ലിക്കേഷനുകൾ നിർമ്മിക്കുകയും വിന്യസിക്കുകയും ചെയ്യുന്ന പ്രക്രിയ നിയന്ത്രിക്കുകയും ചെയ്യുന്നു.

വിവർത്തകനിൽ നിന്ന് പി.എസ്

ഞങ്ങളുടെ ബ്ലോഗിലെ ലേഖനങ്ങളുടെ ഒരു പരമ്പരയും വായിക്കുക:

• «നിർമ്മാണത്തിലെ കുബർനെറ്റിന്റെ വിജയഗാഥകൾ. ഭാഗം 1: eBay-യിൽ നിന്നുള്ള 4200 അടുപ്പുകളും ടെസ്മാസ്റ്ററും".
• «നിർമ്മാണത്തിലെ കുബർനെറ്റിന്റെ വിജയഗാഥകൾ. ഭാഗം 2: Concur ആൻഡ് SAP".
• «നിർമ്മാണത്തിലെ കുബർനെറ്റിന്റെ വിജയഗാഥകൾ. ഭാഗം 3: സാമൂഹികം".
• «നിർമ്മാണത്തിലെ കുബർനെറ്റിന്റെ വിജയഗാഥകൾ. ഭാഗം 4: SoundCloud (പ്രോമിത്യൂസ് എഴുതിയത്)".
• «നിർമ്മാണത്തിലെ കുബർനെറ്റിന്റെ വിജയഗാഥകൾ. ഭാഗം 5: ഡിജിറ്റൽ ബാങ്ക് മോൺസോ".
• «നിർമ്മാണത്തിലെ കുബർനെറ്റിന്റെ വിജയഗാഥകൾ. ഭാഗം 6: ബ്ലാക്ലാർ".
• «നിർമ്മാണത്തിലെ കുബർനെറ്റിന്റെ വിജയഗാഥകൾ. ഭാഗം 7: കറുത്ത പാറ".
• «നിർമ്മാണത്തിലെ കുബർനെറ്റിന്റെ വിജയഗാഥകൾ. ഭാഗം 8: ഹുവായ്".
• «നിർമ്മാണത്തിലെ കുബർനെറ്റിന്റെ വിജയഗാഥകൾ. ഭാഗം 9: CERN, 210 K8s ക്ലസ്റ്ററുകൾ".
• «നിർമ്മാണത്തിലെ കുബർനെറ്റിന്റെ വിജയഗാഥകൾ. ഭാഗം 10: റെഡ്ഡിറ്റ്".

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