Pod, નોડ કે ક્લસ્ટર: VPN sidecar ખરેખર શું રીરૂટ કરે છે

Kubernetes Pod માં VPN sidecar હોસ્ટ-સ્તરીય VPN જેવું લાગે છે, પણ વધુ સારા વર્તન સાથે, અને સામ્ય namespace ની સીમા પર પૂરું થાય છે. એક Pod ના કન્ટેનર નેટવર્ક namespace વહેંચે છે, જેમાં સરનામાં અને પોર્ટની જગ્યા પણ આવે છે, તેથી રૂટ અને નીતિ સ્થાપિત કરતું sidecar ખરેખર બદલે છે કે એપ્લિકેશનના પેકેટ ક્યાં જાય છે. નોડ પરના બીજા Pod માટે તે કંઈ બદલતું નથી, અને તમે તેને એ રીતે ગોઠવો નહીં તો નોડના પોતાના સ્ટેકને અડતું નથી. આ સીમા સાચી રીતે સમજવી એ નક્કી કરે છે કે તમે શું તૈનાત કરી શકો અને શું પરીક્ષણ કરવું પડે. નીચેના વિભાગો તેને namespace થી બહાર તરફ અનુસરે છે.

વહેંચાયેલ namespace, વહેંચાયેલ પરિણામો

એક Pod માંના બે કન્ટેનર loopback પર વાત કરે છે અને સમાન ઇન્ટરફેસ જુએ છે, અને તેથી જ sidecar પેટર્ન બિલકુલ કામ કરે છે: એપ્લિકેશનને ટનલ છે એ જાણવાની જરૂર નથી, કારણ કે તે જે રૂટ પર પહોંચે છે તે તેના વપરાતા namespace માં સ્થાપિત થયો હતો. એ જ ગુણધર્મનો અર્થ છે કે sidecar ની ભૂલો એપ્લિકેશનની ભૂલો છે. જે રૂટ વધુ પડતું પકડે, અથવા જે DNS ફેરફાર ટનલની અંદરના રિઝોલ્વર તરફ ઇશારો કરે, તે તે Pod ના દરેક પ્રોસેસ પર તરત લાગુ પડે છે. વહેંચાયેલ namespace માં કન્ટેનર-વાર રાઉટિંગ નથી, તેથી sidecar ને એક પ્રોસેસ સુધી મર્યાદિત કરી શકાતું નથી.

સમીક્ષા દરમિયાન યાદ રાખવાની આ જ પદ્ધતિ છે: અસરનો વ્યાસ Pod છે, નોડ નહીં અને ક્લસ્ટર પણ નહીં.

sidecar જ્યાં પહોંચતું નથી

બીજા Pod પોતાના namespace અને પોતાનું રાઉટિંગ રાખે છે, તેથી સમાન એગ્રેસ જોઈતા વર્કલોડને એ જ sidecar જોઈએ અથવા તેના બદલે નોડ-સ્તરીય ડિઝાઇન જોઈએ. નોડનો ટ્રાફિક પણ Pod ના namespace ની બહાર છે, અને હોસ્ટ નેટવર્કવાળા Pod જાણી જોઈને આ અલગતા સંપૂર્ણપણે છોડી દે છે. જો અનુકૂળ કંઈક સુધી પહોંચવા sidecar ને હોસ્ટ નેટવર્કિંગ સાથે ચલાવો, તો તમે વ્યાપ્તિ એક Pod થી આખા નોડ સુધી વિસ્તારી છે અને તે મોટેથી કહેવું જોઈએ.

ક્લસ્ટર સેવાઓનો ટ્રાફિક બીજું સામાન્ય આશ્ચર્ય છે. Pod ની અંદરનો પહોળો ડિફોલ્ટ રૂટ API સર્વર અથવા ClusterIP સેવા માટેના વિનંતીઓ પકડી શકે છે, અને પછી તે એવી રીતે નિષ્ફળ જાય છે કે જાણે ટનલ તૂટેલી હોય.

રૂટ યોજના: Pod, સેવા, નોડ અને VPN રેન્જ

ચાર રેન્જ લખો અને કંઈપણ તૈનાત કરતાં પહેલાં ઓવરલેપ તપાસો: Pod CIDR, સેવા CIDR, નોડના સરનામાં અને VPN પાછળના ગંતવ્યો. VPN ની ખાનગી રેન્જ અને ક્લસ્ટરની પોતાની જગ્યા વચ્ચેનો ઓવરલેપ દુર્લભ નથી, અને ડિફોલ્ટ રૂટ તેના માટે ખોટો ઉપાય છે. રૂટ યોજના મેનિફેસ્ટની જેમ એ જ રિપોઝિટરીમાં હોવી જોઈએ, કારણ કે આગલું ક્લસ્ટર સંપૂર્ણપણે અલગ Pod અને સેવા રેન્જ આપી શકે છે.

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

શરૂઆત અને નિષ્ફળતા સ્પષ્ટ સ્થિતિઓ છે

ચાલતી sidecar પ્રોસેસ એગ્રેસ નીતિ નથી. ટનલ તૈયાર થાય તે પહેલાં કયો ટ્રાફિક જઈ શકે અને પછી તે મરી જાય તો શું થાય, તે નક્કી કરો, પછી તે નિર્ણય અમલમાં મૂકો: એપ્લિકેશન કન્ટેનરને ગેટ કરતી પ્રોબ, ડિફોલ્ટથી નકારતી નેટવર્ક નીતિ, અથવા બંને. તેમાંથી એક પણ ન હોય તો એપ્લિકેશન શરૂ થાય, નામ ઉકેલે અને ટ્રાફિક નોડના સામાન્ય માર્ગેથી બહાર મોકલે, જ્યારે ટનલ હજી જોડાઈ રહી હોય.

આ ગેપ તંદુરસ્ત ક્લસ્ટરમાં ટૂંકો અને તૂટેલા ક્લસ્ટરમાં કાયમી છે, અને હુમલાખોર કે આકસ્મિક ડેટા લીક પ્રત્યે આ જ ગુણધર્મ પસંદ કરે છે.

ક્રમને નિષ્ફળતા પરીક્ષણ સાથે જોડો. sidecar મારી નાખો અને ખાતરી કરો કે એપ્લિકેશન ચૂપચાપ પાછી ન ખસીને તેનું ઇચ્છિત એગ્રેસ ગુમાવે છે.

ક્ષમતાઓ, નીતિઓ અને એપ કન્ટેનરથી પરીક્ષણ

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

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

VPN ગોઠવણીની બાજુમાં ક્લસ્ટરની નેટવર્ક ધારણાઓનું દસ્તાવેજીકરણ કરો. પછી વર્કલોડને બીજા ક્લસ્ટરમાં ખસેડવું એ ચૂપચાપ કામ કરવાનું બંધ કરતું ઇમેજ ફેરફાર નહીં, પણ રૂટ યોજના ચકાસવાની કસરત બને છે.