કુબરનેટ્સમાં ટિન્ડર સંક્રમણ

નૉૅધ. અનુવાદ: વિશ્વ વિખ્યાત ટિન્ડર સેવાના કર્મચારીઓએ તાજેતરમાં કુબરનેટ્સમાં તેમના ઈન્ફ્રાસ્ટ્રક્ચરને સ્થાનાંતરિત કરવાની કેટલીક તકનીકી વિગતો શેર કરી છે. આ પ્રક્રિયામાં લગભગ બે વર્ષ લાગ્યાં અને પરિણામે K8s પર ખૂબ જ મોટા પાયે પ્લેટફોર્મ શરૂ થયું, જેમાં 200 હજાર કન્ટેનર પર હોસ્ટ કરવામાં આવેલી 48 સેવાઓનો સમાવેશ થાય છે. ટિન્ડર એન્જિનિયરોને કઈ રસપ્રદ મુશ્કેલીઓનો સામનો કરવો પડ્યો અને તેઓ કેવા પરિણામો આવ્યા? આ અનુવાદ વાંચો.

શા માટે?

લગભગ બે વર્ષ પહેલાં, ટિંડરે તેનું પ્લેટફોર્મ કુબરનેટ્સ પર ખસેડવાનું નક્કી કર્યું. કુબરનેટ્સ ટિન્ડર ટીમને અપરિવર્તનશીલ જમાવટ દ્વારા ન્યૂનતમ પ્રયત્નો સાથે કન્ટેનરાઇઝ કરવા અને ઉત્પાદનમાં જવાની મંજૂરી આપશે (અચલ જમાવટ). આ કિસ્સામાં, એપ્લિકેશનની એસેમ્બલી, તેમની જમાવટ અને ઇન્ફ્રાસ્ટ્રક્ચર પોતે કોડ દ્વારા વિશિષ્ટ રીતે વ્યાખ્યાયિત કરવામાં આવશે.

અમે માપનીયતા અને સ્થિરતાની સમસ્યાનો ઉકેલ પણ શોધી રહ્યા હતા. જ્યારે સ્કેલિંગ નિર્ણાયક બન્યું, ત્યારે અમારે ઘણી વાર નવા EC2 દાખલાઓ સ્પિન થવા માટે ઘણી મિનિટ રાહ જોવી પડતી હતી. કન્ટેનર લોંચ કરવાનો અને મિનિટોને બદલે સેકન્ડોમાં ટ્રાફિક સેવા આપવાનો વિચાર અમને ખૂબ જ આકર્ષક લાગ્યો.

પ્રક્રિયા મુશ્કેલ હોવાનું બહાર આવ્યું. 2019 ની શરૂઆતમાં અમારા સ્થળાંતર દરમિયાન, કુબરનેટ્સ ક્લસ્ટર ગંભીર સ્તરે પહોંચ્યું અને અમને ટ્રાફિક વોલ્યુમ, ક્લસ્ટર કદ અને DNS ને કારણે વિવિધ સમસ્યાઓનો સામનો કરવો પડ્યો. રસ્તામાં, અમે 200 સેવાઓને સ્થાનાંતરિત કરવા અને 1000 નોડ્સ, 15000 પોડ્સ અને 48000 ચાલતા કન્ટેનર ધરાવતા કુબરનેટ્સ ક્લસ્ટરને જાળવવા સંબંધિત ઘણી રસપ્રદ સમસ્યાઓ હલ કરી.

કેવી રીતે?

જાન્યુઆરી 2018 થી, અમે સ્થળાંતરના વિવિધ તબક્કામાંથી પસાર થયા છીએ. અમે અમારી બધી સેવાઓને કન્ટેનરાઇઝ કરીને અને તેમને કુબરનેટ્સ ટેસ્ટ ક્લાઉડ એન્વાયર્નમેન્ટ્સમાં જમાવવાથી શરૂઆત કરી. ઑક્ટોબરથી શરૂ કરીને, અમે કુબરનેટ્સમાં બધી હાલની સેવાઓને પદ્ધતિસર સ્થાનાંતરિત કરવાનું શરૂ કર્યું. આવતા વર્ષના માર્ચ સુધીમાં, અમે સ્થળાંતર પૂર્ણ કર્યું અને હવે Tinder પ્લેટફોર્મ ફક્ત કુબરનેટ્સ પર ચાલે છે.

કુબરનેટ્સ માટે છબીઓ બનાવવી

કુબરનેટ્સ ક્લસ્ટર પર ચાલતી માઇક્રોસર્વિસિસ માટે અમારી પાસે 30 થી વધુ સોર્સ કોડ રિપોઝીટરીઝ છે. આ રીપોઝીટરીઝમાં કોડ એક જ ભાષા માટે બહુવિધ રનટાઇમ એન્વાયર્નમેન્ટ્સ સાથે વિવિધ ભાષાઓમાં (ઉદાહરણ તરીકે, Node.js, Java, Scala, Go) લખાયેલ છે.

બિલ્ડ સિસ્ટમ દરેક માઇક્રોસર્વિસ માટે સંપૂર્ણપણે કસ્ટમાઇઝ કરી શકાય તેવા "બિલ્ડ સંદર્ભ" પ્રદાન કરવા માટે ડિઝાઇન કરવામાં આવી છે. તે સામાન્ય રીતે ડોકરફાઇલ અને શેલ આદેશોની સૂચિ ધરાવે છે. તેમની સામગ્રી સંપૂર્ણપણે કસ્ટમાઇઝ કરી શકાય તેવી છે, અને તે જ સમયે, આ તમામ બિલ્ડ સંદર્ભો પ્રમાણિત ફોર્મેટ અનુસાર લખવામાં આવે છે. બિલ્ડ સંદર્ભોનું માનકીકરણ એક સિંગલ બિલ્ડ સિસ્ટમને તમામ માઇક્રોસર્વિસિસને હેન્ડલ કરવાની મંજૂરી આપે છે.

આકૃતિ 1-1. બિલ્ડર કન્ટેનર દ્વારા પ્રમાણિત બિલ્ડ પ્રક્રિયા

રનટાઇમ વચ્ચે મહત્તમ સુસંગતતા હાંસલ કરવા માટે (રનટાઇમ વાતાવરણ) વિકાસ અને પરીક્ષણ દરમિયાન સમાન બિલ્ડ પ્રક્રિયાનો ઉપયોગ થાય છે. અમે ખૂબ જ રસપ્રદ પડકારનો સામનો કર્યો: સમગ્ર પ્લેટફોર્મ પર બિલ્ડ પર્યાવરણની સુસંગતતા સુનિશ્ચિત કરવા માટે અમારે એક માર્ગ વિકસાવવો પડ્યો. આ હાંસલ કરવા માટે, બધી એસેમ્બલી પ્રક્રિયાઓ ખાસ કન્ટેનરની અંદર હાથ ધરવામાં આવે છે. બિલ્ડર.

તેના કન્ટેનર અમલીકરણ માટે અદ્યતન ડોકર તકનીકોની જરૂર હતી. બિલ્ડરને ખાનગી ટિન્ડર રિપોઝીટરીઝને ઍક્સેસ કરવા માટે જરૂરી સ્થાનિક વપરાશકર્તા ID અને રહસ્યો (જેમ કે SSH કી, AWS ઓળખપત્ર વગેરે) વારસામાં મળે છે. તે બિલ્ડ આર્ટિફેક્ટ્સને કુદરતી રીતે સ્ટોર કરવા માટે સ્ત્રોતો ધરાવતી સ્થાનિક ડિરેક્ટરીઓ માઉન્ટ કરે છે. આ અભિગમ પ્રભાવ સુધારે છે કારણ કે તે બિલ્ડર કન્ટેનર અને હોસ્ટ વચ્ચે બિલ્ડ આર્ટિફેક્ટની નકલ કરવાની જરૂરિયાતને દૂર કરે છે. સંગ્રહિત બિલ્ડ આર્ટિફેક્ટનો વધારાના રૂપરેખાંકન વિના ફરીથી ઉપયોગ કરી શકાય છે.

કેટલીક સેવાઓ માટે, અમારે રનટાઇમ પર્યાવરણમાં સંકલન વાતાવરણને મેપ કરવા માટે બીજું કન્ટેનર બનાવવું પડ્યું હતું (ઉદાહરણ તરીકે, Node.js bcrypt લાઇબ્રેરી ઇન્સ્ટોલેશન દરમિયાન પ્લેટફોર્મ-વિશિષ્ટ બાઈનરી આર્ટિફેક્ટ્સ જનરેટ કરે છે). સંકલન પ્રક્રિયા દરમિયાન, સેવાઓ વચ્ચે જરૂરિયાતો બદલાઈ શકે છે, અને અંતિમ ડોકરફાઈલ ફ્લાય પર સંકલિત કરવામાં આવે છે.

કુબરનેટ્સ ક્લસ્ટર આર્કિટેક્ચર અને સ્થળાંતર

ક્લસ્ટર કદ વ્યવસ્થાપન

અમે ઉપયોગ કરવાનું નક્કી કર્યું kube-aws Amazon EC2 ઉદાહરણો પર સ્વચાલિત ક્લસ્ટર જમાવટ માટે. ખૂબ જ શરૂઆતમાં, બધું નોડ્સના એક સામાન્ય પૂલમાં કામ કરતું હતું. અમે સંસાધનોનો વધુ કાર્યક્ષમ ઉપયોગ કરવા માટે કદ અને દાખલાના પ્રકાર દ્વારા વર્કલોડને અલગ કરવાની જરૂરિયાતને ઝડપથી સમજી લીધી. તર્ક એ હતો કે ઘણી લોડ કરેલી મલ્ટી-થ્રેડેડ શીંગો ચલાવવી એ મોટી સંખ્યામાં સિંગલ-થ્રેડેડ શીંગો સાથે તેમના સહઅસ્તિત્વ કરતાં કામગીરીની દ્રષ્ટિએ વધુ અનુમાનિત હોવાનું બહાર આવ્યું.

અંતે અમે સમાધાન કર્યું:

• m5.4xમોટો - દેખરેખ માટે (પ્રોમિથિયસ);
• c5.4xમોટો - Node.js વર્કલોડ માટે (સિંગલ-થ્રેડેડ વર્કલોડ);
• c5.2xમોટો - જાવા અને ગો માટે (મલ્ટિથ્રેડેડ વર્કલોડ);
• c5.4xમોટો - કંટ્રોલ પેનલ માટે (3 નોડ્સ).

સ્થળાંતર

જૂના ઈન્ફ્રાસ્ટ્રક્ચરમાંથી કુબરનેટસમાં સ્થળાંતર કરવા માટેનું એક પ્રારંભિક પગલું એ હતું કે સેવાઓ વચ્ચેના હાલના પ્રત્યક્ષ સંચારને નવા લોડ બેલેન્સર્સ (ઈલાસ્ટીક લોડ બેલેન્સર્સ (ELB) માટે રીડાયરેક્ટ કરવું. તેઓ વર્ચ્યુઅલ પ્રાઇવેટ ક્લાઉડ (VPC) ના ચોક્કસ સબનેટ પર બનાવવામાં આવ્યા હતા. આ સબનેટ Kubernetes VPC સાથે જોડાયેલ હતું. આનાથી અમને સેવા નિર્ભરતાના ચોક્કસ ક્રમને ધ્યાનમાં લીધા વિના, ધીમે ધીમે મોડ્યુલોને સ્થાનાંતરિત કરવાની મંજૂરી મળી.

આ અંતિમ બિંદુઓ DNS રેકોર્ડ્સના ભારિત સેટનો ઉપયોગ કરીને બનાવવામાં આવ્યા હતા જેમાં CNAMEs દરેક નવા ELB તરફ નિર્દેશ કરે છે. સ્વિચ કરવા માટે, અમે 0 ના વજન સાથે કુબરનેટ્સ સેવાના નવા ELB તરફ નિર્દેશ કરતી નવી એન્ટ્રી ઉમેરી. અમે પછી એન્ટ્રી સેટનો ટાઈમ ટુ લાઈવ (TTL) 0 પર સેટ કર્યો. આ પછી, જૂના અને નવા વજન ધીમે ધીમે સમાયોજિત, અને આખરે 100% લોડ નવા સર્વર પર મોકલવામાં આવ્યો. સ્વિચિંગ પૂર્ણ થયા પછી, TTL મૂલ્ય વધુ પર્યાપ્ત સ્તરે પાછું આવ્યું.

અમારી પાસે જે Java મોડ્યુલો હતા તે ઓછા TTL DNS નો સામનો કરી શકે છે, પરંતુ નોડ એપ્લીકેશન કરી શકી નથી. એક એન્જિનિયરે કનેક્શન પૂલ કોડનો ભાગ ફરીથી લખ્યો અને તેને એક મેનેજરમાં લપેટી જે દર 60 સેકન્ડે પૂલ અપડેટ કરે છે. પસંદ કરેલ અભિગમ ખૂબ જ સારી રીતે કાર્ય કરે છે અને કોઈપણ નોંધપાત્ર કામગીરીમાં ઘટાડો કર્યા વિના.

પાઠ

નેટવર્ક ફેબ્રિકની મર્યાદાઓ

8 જાન્યુઆરી, 2019 ની વહેલી સવારે, Tinder પ્લેટફોર્મ અનપેક્ષિત રીતે ક્રેશ થયું. તે વહેલી સવારે પ્લેટફોર્મ લેટન્સીમાં અસંબંધિત વધારાના પ્રતિભાવમાં, ક્લસ્ટરમાં પોડ્સ અને નોડ્સની સંખ્યામાં વધારો થયો. આના કારણે અમારા તમામ નોડ્સ પર ARP કેશ ખતમ થઈ ગઈ.

ARP કેશ સંબંધિત ત્રણ Linux વિકલ્પો છે:

(સ્રોત)

gc_thresh3 - આ એક સખત મર્યાદા છે. લોગમાં "નેબર ટેબલ ઓવરફ્લો" એન્ટ્રીઓના દેખાવનો અર્થ એ થયો કે સિંક્રનસ ગાર્બેજ કલેક્શન (GC) પછી પણ, ARP કેશમાં પડોશી એન્ટ્રી સ્ટોર કરવા માટે પૂરતી જગ્યા નથી. આ કિસ્સામાં, કર્નલ ફક્ત પેકેટને સંપૂર્ણપણે કાઢી નાખે છે.

અમે ઉપયોગ કરીએ છીએ ફલાનીલ Kubernetes માં નેટવર્ક ફેબ્રિક તરીકે. પેકેટો VXLAN પર પ્રસારિત થાય છે. VXLAN એ L2 નેટવર્કની ટોચ પર ઊભી થયેલી L3 ટનલ છે. ટેક્નોલોજી MAC-in-UDP (MAC એડ્રેસ-ઇન-યુઝર ડેટાગ્રામ પ્રોટોકોલ) એન્કેપ્સ્યુલેશનનો ઉપયોગ કરે છે અને લેયર 2 નેટવર્ક સેગમેન્ટના વિસ્તરણને મંજૂરી આપે છે. ભૌતિક ડેટા સેન્ટર નેટવર્ક પર પરિવહન પ્રોટોકોલ IP પ્લસ UDP છે.

આકૃતિ 2-1. ફલેનલ ડાયાગ્રામ (સ્રોત)

આકૃતિ 2-2. VXLAN પેકેજ (સ્રોત)

દરેક કુબરનેટ્સ વર્કર નોડ મોટા /24 બ્લોકમાંથી /9 માસ્ક સાથે વર્ચ્યુઅલ એડ્રેસ સ્પેસ ફાળવે છે. દરેક નોડ માટે આ છે અર્થ રૂટીંગ ટેબલમાં એક એન્ટ્રી, એઆરપી ટેબલમાં એક એન્ટ્રી (ફ્લાનલ.1 ઈન્ટરફેસ પર), અને એક એન્ટ્રી સ્વિચિંગ ટેબલ (FDB)માં. જ્યારે પ્રથમ વખત વર્કર નોડ શરૂ થાય અથવા દરેક વખતે નવો નોડ શોધાય ત્યારે તેઓ ઉમેરવામાં આવે છે.

વધુમાં, નોડ-પોડ (અથવા પોડ-પોડ) સંચાર આખરે ઇન્ટરફેસમાંથી પસાર થાય છે eth0 (ઉપરના ફલેનલ ડાયાગ્રામમાં બતાવ્યા પ્રમાણે). આના પરિણામે દરેક અનુરૂપ સ્ત્રોત અને ગંતવ્ય હોસ્ટ માટે ARP કોષ્ટકમાં વધારાની એન્ટ્રી થાય છે.

આપણા વાતાવરણમાં, આ પ્રકારનો સંચાર ખૂબ સામાન્ય છે. કુબરનેટ્સમાં સર્વિસ ઑબ્જેક્ટ્સ માટે, એક ELB બનાવવામાં આવે છે અને Kubernetes દરેક નોડને ELB સાથે રજીસ્ટર કરે છે. ELB પોડ્સ વિશે કશું જ જાણતું નથી અને પસંદ કરેલ નોડ પેકેટનું અંતિમ મુકામ ન હોઈ શકે. મુદ્દો એ છે કે જ્યારે નોડ ELB તરફથી પેકેટ મેળવે છે, ત્યારે તે નિયમોને ધ્યાનમાં લે છે. iptables ચોક્કસ સેવા માટે અને રેન્ડમલી બીજા નોડ પર પોડ પસંદ કરે છે.

નિષ્ફળતા સમયે, ક્લસ્ટરમાં 605 નોડ્સ હતા. ઉપર જણાવેલ કારણોસર, આ મહત્વને દૂર કરવા માટે પૂરતું હતું gc_thresh3, જે ડિફોલ્ટ છે. જ્યારે આવું થાય છે, ત્યારે માત્ર પેકેટો જ છોડવાનું શરૂ થતું નથી, પરંતુ /24 માસ્ક સાથેની સમગ્ર ફ્લેનેલ વર્ચ્યુઅલ એડ્રેસ સ્પેસ ARP ટેબલમાંથી અદૃશ્ય થઈ જાય છે. નોડ-પોડ કમ્યુનિકેશન અને DNS ક્વેરીઝ વિક્ષેપિત થાય છે (DNS ક્લસ્ટરમાં હોસ્ટ કરવામાં આવે છે; વિગતો માટે આ લેખમાં પછીથી વાંચો).

આ સમસ્યાને ઉકેલવા માટે, તમારે મૂલ્યો વધારવાની જરૂર છે gc_thresh1, gc_thresh2 и gc_thresh3 અને ગુમ થયેલ નેટવર્કને ફરીથી નોંધણી કરવા માટે ફ્લેનેલને પુનઃપ્રારંભ કરો.

અનપેક્ષિત DNS સ્કેલિંગ

સ્થળાંતર પ્રક્રિયા દરમિયાન, અમે ટ્રાફિકનું સંચાલન કરવા અને ધીમે ધીમે સેવાઓને જૂના ઈન્ફ્રાસ્ટ્રક્ચરમાંથી કુબરનેટ્સમાં સ્થાનાંતરિત કરવા માટે DNSનો સક્રિયપણે ઉપયોગ કર્યો. અમે રૂટ53 માં સંકળાયેલ રેકોર્ડસેટ્સ માટે પ્રમાણમાં ઓછા TTL મૂલ્યો સેટ કર્યા છે. જ્યારે જૂનું ઈન્ફ્રાસ્ટ્રક્ચર EC2 દાખલાઓ પર ચાલી રહ્યું હતું, ત્યારે અમારા રિઝોલ્વર કન્ફિગરેશન એમેઝોન DNS તરફ નિર્દેશ કરે છે. અમે આને ગ્રાન્ટેડ લીધું અને અમારી સેવાઓ અને એમેઝોન સેવાઓ (જેમ કે DynamoDB) પર નીચા TTLની અસર મોટાભાગે કોઈના ધ્યાને ન આવી.

જેમ જેમ અમે સેવાઓને કુબરનેટ્સ પર સ્થાનાંતરિત કરી, અમને જાણવા મળ્યું કે DNS પ્રતિ સેકન્ડ 250 હજાર વિનંતીઓ પર પ્રક્રિયા કરી રહ્યું છે. પરિણામે, એપ્લિકેશનોએ DNS ક્વેરીઝ માટે સતત અને ગંભીર સમયસમાપ્તિનો અનુભવ કરવાનું શરૂ કર્યું. DNS પ્રદાતાને CoreDNS (જે પીક લોડ પર 1000 કોરો પર ચાલતા 120 પોડ્સ સુધી પહોંચે છે) પર ઑપ્ટિમાઇઝ કરવા અને સ્વિચ કરવાના અવિશ્વસનીય પ્રયાસો છતાં આ બન્યું.

અન્ય સંભવિત કારણો અને ઉકેલોનું સંશોધન કરતી વખતે, અમે શોધ્યું એક લેખ, પેકેટ ફિલ્ટરિંગ ફ્રેમવર્કને અસર કરતી જાતિની પરિસ્થિતિઓનું વર્ણન કરે છે નેટફિલ્ટર Linux માં. અમે અવલોકન કરેલ સમયસમાપ્તિ, વધતા જતા કાઉન્ટર સાથે insert_failed ફલેનલ ઇન્ટરફેસમાં લેખના તારણો સાથે સુસંગત હતા.

સોર્સ એન્ડ ડેસ્ટિનેશન નેટવર્ક એડ્રેસ ટ્રાન્સલેશન (SNAT અને DNAT) અને ત્યારબાદ કોષ્ટકમાં પ્રવેશના તબક્કે સમસ્યા ઊભી થાય છે. કોન્ટ્રાક. આંતરિક રીતે ચર્ચા કરાયેલા અને સમુદાય દ્વારા સૂચવવામાં આવેલા ઉકેલોમાંથી એક DNS ને વર્કર નોડ પર જ ખસેડવાનું હતું. આ બાબતે:

• SNAT ની જરૂર નથી કારણ કે ટ્રાફિક નોડની અંદર રહે છે. તેને ઇન્ટરફેસ દ્વારા રૂટ કરવાની જરૂર નથી eth0.
• DNAT ની જરૂર નથી કારણ કે ગંતવ્ય IP નોડ માટે સ્થાનિક છે, અને નિયમો અનુસાર રેન્ડમલી પસંદ કરેલ પોડ નથી iptables.

અમે આ અભિગમ સાથે વળગી રહેવાનું નક્કી કર્યું. CoreDNS ને કુબરનેટીસમાં ડેમનસેટ તરીકે તૈનાત કરવામાં આવ્યું હતું અને અમે સ્થાનિક નોડ DNS સર્વરનો અમલ કર્યો solve.conf ધ્વજ સેટ કરીને દરેક પોડ --ક્લસ્ટર-ડીએનએસ આદેશો કુબેલેટ . આ ઉકેલ DNS સમયસમાપ્તિ માટે અસરકારક હોવાનું બહાર આવ્યું છે.

જો કે, અમે હજુ પણ પેકેટની ખોટ અને કાઉન્ટરમાં વધારો જોયો છે insert_failed ફલેનલ ઇન્ટરફેસમાં. વર્કઅરાઉન્ડ લાગુ થયા પછી આ ચાલુ રહ્યું કારણ કે અમે ફક્ત DNS ટ્રાફિક માટે SNAT અને/અથવા DNAT નાબૂદ કરવામાં સક્ષમ હતા. અન્ય પ્રકારના ટ્રાફિક માટે રેસની સ્થિતિ સાચવવામાં આવી હતી. સદભાગ્યે, અમારા મોટાભાગના પેકેટો TCP છે, અને જો કોઈ સમસ્યા આવે તો તે ફક્ત ફરીથી ટ્રાન્સમિટ કરવામાં આવે છે. અમે હજુ પણ તમામ પ્રકારના ટ્રાફિક માટે યોગ્ય ઉકેલ શોધવાનો પ્રયાસ કરી રહ્યા છીએ.

બહેતર લોડ બેલેન્સિંગ માટે દૂતનો ઉપયોગ કરવો

જેમ જેમ અમે બેકએન્ડ સેવાઓને કુબરનેટ્સમાં સ્થાનાંતરિત કરી, અમે શીંગો વચ્ચેના અસંતુલિત ભારથી પીડાવા લાગ્યા. અમને જાણવા મળ્યું છે કે HTTP Keepalive ને કારણે ELB કનેક્શન્સ દરેક જમાવટના રોલઆઉટના પ્રથમ તૈયાર પોડ્સ પર અટકી જાય છે. આમ, મોટાભાગનો ટ્રાફિક ઉપલબ્ધ પોડની નાની ટકાવારીમાંથી પસાર થતો હતો. અમે ચકાસાયેલ પ્રથમ સોલ્યુશન સૌથી ખરાબ પરિસ્થિતિ માટે નવા જમાવટ પર MaxSurge ને 100% પર સેટ કરવાનું હતું. મોટી જમાવટના સંદર્ભમાં અસર નજીવી અને આશાસ્પદ હોવાનું બહાર આવ્યું.

અમે ઉપયોગમાં લેવાતા અન્ય ઉકેલો જટિલ સેવાઓ માટે સંસાધન વિનંતીઓને કૃત્રિમ રીતે વધારવાનો હતો. આ કિસ્સામાં, અન્ય ભારે શીંગોની સરખામણીમાં નજીકમાં મૂકવામાં આવેલી શીંગોમાં દાવપેચ કરવા માટે વધુ જગ્યા હશે. તે લાંબા ગાળે કામ કરશે નહીં કારણ કે તે સંસાધનોનો બગાડ હશે. વધુમાં, અમારી નોડ એપ્લિકેશનો સિંગલ-થ્રેડેડ હતી અને તે મુજબ, માત્ર એક કોરનો ઉપયોગ કરી શકતી હતી. એક માત્ર વાસ્તવિક ઉકેલ વધુ સારી રીતે લોડ બેલેન્સિંગનો ઉપયોગ કરવાનો હતો.

અમે લાંબા સમયથી સંપૂર્ણ પ્રશંસા કરવા માગીએ છીએ દૂત. વર્તમાન પરિસ્થિતિએ અમને તેને ખૂબ જ મર્યાદિત રીતે તૈનાત કરવાની અને તાત્કાલિક પરિણામો મેળવવાની મંજૂરી આપી. દૂત એ ઉચ્ચ-પ્રદર્શન, ઓપન-સોર્સ, લેયર-XNUMX પ્રોક્સી છે જે મોટા SOA એપ્લિકેશનો માટે રચાયેલ છે. તે અદ્યતન લોડ સંતુલન તકનીકોનો અમલ કરી શકે છે, જેમાં સ્વચાલિત પુનઃપ્રયાસો, સર્કિટ બ્રેકર્સ અને વૈશ્વિક દર મર્યાદાનો સમાવેશ થાય છે. (નૉૅધ. અનુવાદ: તમે આ વિશે વધુ વાંચી શકો છો આ લેખ Istio વિશે, જે રાજદૂત પર આધારિત છે.)

અમે નીચેની રૂપરેખાંકન સાથે આવ્યા છીએ: દરેક પોડ અને એક જ રૂટ માટે એક દૂત સાઇડકાર રાખો અને ક્લસ્ટરને પોર્ટ દ્વારા સ્થાનિક રીતે કન્ટેનર સાથે કનેક્ટ કરો. સંભવિત કાસ્કેડિંગ ઘટાડવા અને નાની હિટ ત્રિજ્યા જાળવવા માટે, અમે દરેક સેવા માટે ઉપલબ્ધતા ઝોન (AZ) દીઠ એક, એન્વોય ફ્રન્ટ-પ્રોક્સી પોડ્સના કાફલાનો ઉપયોગ કર્યો. તેઓ અમારા એન્જિનિયરોમાંથી એક દ્વારા લખવામાં આવેલા સરળ સેવા શોધ એન્જિન પર આધાર રાખતા હતા જે આપેલ સેવા માટે દરેક AZ માં પોડ્સની સૂચિ પરત કરે છે.

સર્વિસ ફ્રન્ટ-એન્વોયસે પછી એક અપસ્ટ્રીમ ક્લસ્ટર અને રૂટ સાથે આ સર્વિસ ડિસ્કવરી મિકેનિઝમનો ઉપયોગ કર્યો. અમે પર્યાપ્ત સમયસમાપ્તિ સેટ કરી છે, તમામ સર્કિટ બ્રેકર સેટિંગ્સમાં વધારો કર્યો છે, અને એક નિષ્ફળતામાં મદદ કરવા અને સરળ જમાવટની ખાતરી કરવા માટે ન્યૂનતમ પુનઃપ્રયાસ ગોઠવણી ઉમેરી છે. અમે આ દરેક સેવાના ફ્રન્ટ-એન્વોયની સામે TCP ELB મૂક્યું છે. જો અમારા મુખ્ય પ્રોક્સી લેયરમાંથી કીપલાઈવ કેટલાક એન્વોય પોડ્સ પર અટવાઈ ગયું હોય, તો પણ તેઓ લોડને વધુ સારી રીતે હેન્ડલ કરવામાં સક્ષમ હતા અને બેકએન્ડમાં ઓછામાં ઓછા_રિક્વેસ્ટ દ્વારા સંતુલિત કરવા માટે ગોઠવવામાં આવ્યા હતા.

જમાવટ માટે, અમે એપ્લીકેશન પોડ્સ અને સાઇડકાર પોડ્સ બંને પર પ્રીસ્ટોપ હૂકનો ઉપયોગ કર્યો. હૂકએ સાઇડકાર કન્ટેનર પર સ્થિત એડમિન એન્ડપોઇન્ટની સ્થિતિ તપાસવામાં ભૂલ ઉભી કરી અને સક્રિય કનેક્શન્સને સમાપ્ત કરવાની મંજૂરી આપવા માટે થોડીવાર માટે ઊંઘી ગયો.

અમે આટલી ઝડપથી આગળ વધી શક્યા તે કારણોમાંનું એક વિગતવાર મેટ્રિક્સને કારણે છે જેને અમે સામાન્ય પ્રોમિથિયસ ઇન્સ્ટોલેશનમાં સરળતાથી એકીકૃત કરવામાં સક્ષમ હતા. આનાથી અમને રૂપરેખાંકન પરિમાણોને સમાયોજિત કરવામાં અને ટ્રાફિકને ફરીથી વિતરણ કરતી વખતે શું થઈ રહ્યું હતું તે જોવાની મંજૂરી મળી.

પરિણામો તાત્કાલિક અને સ્પષ્ટ હતા. અમે સૌથી અસંતુલિત સેવાઓ સાથે શરૂઆત કરી હતી, અને આ ક્ષણે તે ક્લસ્ટરમાં 12 સૌથી મહત્વપૂર્ણ સેવાઓની સામે કાર્યરત છે. આ વર્ષે અમે વધુ અદ્યતન સેવા શોધ, સર્કિટ બ્રેકિંગ, આઉટલીયર ડિટેક્શન, રેટ લિમિટિંગ અને ટ્રેસિંગ સાથે સંપૂર્ણ સેવા મેશમાં સંક્રમણની યોજના બનાવી રહ્યા છીએ.

આકૃતિ 3-1. દૂતમાં સંક્રમણ દરમિયાન એક સેવાનું CPU કન્વર્જન્સ

અંતિમ પરિણામ

આ અનુભવ અને વધારાના સંશોધન દ્વારા, અમે મોટા કુબરનેટ્સ ક્લસ્ટરોની ડિઝાઇન, જમાવટ અને સંચાલનમાં મજબૂત કૌશલ્ય સાથે મજબૂત ઇન્ફ્રાસ્ટ્રક્ચર ટીમ બનાવી છે. બધા ટિન્ડર એન્જિનિયરો પાસે હવે કન્ટેનરને પેકેજ કરવા અને કુબરનેટ્સ પર એપ્લિકેશન્સ ગોઠવવાનું જ્ઞાન અને અનુભવ છે.

જ્યારે જૂના ઈન્ફ્રાસ્ટ્રક્ચર પર વધારાની ક્ષમતાની જરૂરિયાત ઊભી થઈ, ત્યારે અમારે નવા EC2 દાખલાઓ શરૂ થવા માટે ઘણી મિનિટ રાહ જોવી પડી. હવે કન્ટેનર દોડવાનું શરૂ કરે છે અને મિનિટોને બદલે સેકંડમાં ટ્રાફિક પર પ્રક્રિયા કરવાનું શરૂ કરે છે. એક જ EC2 દાખલા પર બહુવિધ કન્ટેનરનું સુનિશ્ચિત કરવું પણ સુધારેલ આડી સાંદ્રતા પ્રદાન કરે છે. પરિણામે, અમે ગયા વર્ષની સરખામણીમાં 2019 માં EC2 ખર્ચમાં નોંધપાત્ર ઘટાડો થવાની આગાહી કરી છે.

સ્થળાંતરમાં લગભગ બે વર્ષ લાગ્યાં, પરંતુ અમે તેને માર્ચ 2019માં પૂર્ણ કર્યું. હાલમાં, ટિન્ડર પ્લેટફોર્મ 200 સેવાઓ, 1000 નોડ્સ, 15 પોડ્સ અને 000 ચાલતા કન્ટેનર ધરાવતા કુબરનેટ્સ ક્લસ્ટર પર વિશિષ્ટ રીતે ચાલે છે. ઇન્ફ્રાસ્ટ્રક્ચર હવે ઓપરેશન ટીમોનું એકમાત્ર ડોમેન નથી. અમારા તમામ ઇજનેરો આ જવાબદારીને વહેંચે છે અને માત્ર કોડનો ઉપયોગ કરીને તેમની એપ્લિકેશન બનાવવા અને જમાવવાની પ્રક્રિયાને નિયંત્રિત કરે છે.

અનુવાદક તરફથી પીએસ

અમારા બ્લોગ પર લેખોની શ્રેણી પણ વાંચો:

• «ઉત્પાદનમાં કુબરનેટ્સની સફળતાની વાર્તાઓ. ભાગ 1: eBay તરફથી 4200 હર્થ અને ટેસમાસ્ટર».
• «ઉત્પાદનમાં કુબરનેટ્સની સફળતાની વાર્તાઓ. ભાગ 2: સહમત અને SAP».
• «ઉત્પાદનમાં કુબરનેટ્સની સફળતાની વાર્તાઓ. ભાગ 3: GitHub».
• «ઉત્પાદનમાં કુબરનેટ્સની સફળતાની વાર્તાઓ. ભાગ 4: સાઉન્ડક્લાઉડ (પ્રોમિથિયસ દ્વારા)».
• «ઉત્પાદનમાં કુબરનેટ્સની સફળતાની વાર્તાઓ. ભાગ 5: ડિજિટલ બેંક મોન્ઝો».
• «ઉત્પાદનમાં કુબરનેટ્સની સફળતાની વાર્તાઓ. ભાગ 6: BlaBlaCar».
• «ઉત્પાદનમાં કુબરનેટ્સની સફળતાની વાર્તાઓ. ભાગ 7: બ્લેકરોક».
• «ઉત્પાદનમાં કુબરનેટ્સની સફળતાની વાર્તાઓ. ભાગ 8: હ્યુઆવેઇ».
• «ઉત્પાદનમાં કુબરનેટ્સની સફળતાની વાર્તાઓ. ભાગ 9: CERN અને 210 K8s ક્લસ્ટરો».
• «ઉત્પાદનમાં કુબરનેટ્સની સફળતાની વાર્તાઓ. ભાગ 10: Reddit».

સોર્સ: www.habr.com