Kubernetes Pod VPN અને એગ્રેસ ગેટવે: ટનલ કોની છે?
Pod પોતાનું નેટવર્ક નેમસ્પેસ ધરાવે છે, તેથી અસલ પસંદગી એ છે કે કયો સ્તર ટનલનો માલિક છે: દરેક વર્કલોડ માટે ઓળખ કે CNI-નિર્દેશિત એક જ શેર કરેલા સ્રોત સાથેનું એગ્રેસ.
તમે vpn-gateway નામનું Pod ડિપ્લોય કરો છો, ટેસ્ટ ક્લાયન્ટને તેના સરનામા પર મોકલો છો અને પેકેટ ગાયબ થતાં જુઓ છો. મેનિફેસ્ટમાં કંઈ ખોટું નથી અને kubelet પાસે કોઈ ફરિયાદ નથી. કારણ રચનાત્મક છે, રૂપરેખાકીય નહીં: Kubernetes દરેક Pod ને તેનું પોતાનું નેટવર્ક નેમસ્પેસ આપે છે, તેથી નામ, લેબલ કે શેર કરેલું API નેમસ્પેસ પેકેટ ક્યાં જાય છે તેમાં કંઈ બદલતું નથી. તેથી VPN ટ્રાફિક ક્લસ્ટરમાંથી કેવી રીતે નીકળે તે નક્કી કરવું માલિકીના પ્રશ્નથી શરૂ થાય છે, કન્ટેનર ઇમેજથી નહીં.
બે પદ્ધતિઓ મોટાભાગની વાસ્તવિક ડિપ્લોયમેન્ટને આવરી લે છે, અને તે અદલાબદલી કરી શકાય તેવી નથી. એક ટનલને વર્કલોડના પોતાના નેટવર્ક નેમસ્પેસમાં મૂકે છે. બીજી CNI ને પસંદ કરેલા ટ્રાફિકને નિયુક્ત ગેટવે નોડ દ્વારા વાળવા કહે છે. તે અલગ રીતે નિષ્ફળ જાય છે, અલગ રીતે સ્કેલ થાય છે અને અલગ ટીમોને જવાબ આપે છે, તેથી કન્ટેનરનો પ્રશ્ન સામાન્ય રીતે એવી ચર્ચા ઊભી કરે છે જે ક્યારેય ઉકેલાતી નથી.
Pod ની સીમા નેમસ્પેસ છે, જમ્પ હોસ્ટ નહીં
Linux નેટવર્ક નેમસ્પેસ તેના ઇન્ટરફેસ, સરનામાં, રૂટ અને ફાયરવોલ નિયમોનો માલિક છે, અને દરેક Pod ને એક મળે છે. તે Pod ની અંદરના કન્ટેનર તેમાં જોડાય છે, અને તેથી જ સહાયક કન્ટેનર એવા રૂટ ફરી લખી શકે છે જે પછી એપ્લિકેશન અનુસરે છે. પાડોશી Pod પાસે દેખાવમાં સમાન પણ સંપૂર્ણ અલગ સ્ટેક છે. ગેટવે Pod વારસો લઈ શકે એવું કોઈ શેર કરેલું ટેબલ નથી, અને એક નેમસ્પેસથી બીજામાં ટ્રાફિકનું કોઈ ગર્ભિત હસ્તાંતરણ નથી.
તેથી જ ગેટવે-Pod પેટર્ન ત્યારે જ કામ કરે છે જ્યારે ઉપરનું કંઈક ખરેખર તેને પેકેટ મોકલે: Service, નોડ પર સ્થિર રૂટ કે CNI માં સ્ટીયરિંગ પોલિસી. એકલું સરનામું કંઈ આકર્ષતું નથી.
દરેક Pod માટે ટનલ શું આપે છે અને શું કિંમત ચૂકવાડે છે
વર્કલોડના નેમસ્પેસમાં ચાલતી ટનલ તે વર્કલોડને તેની પોતાની ક્લાયન્ટ ઓળખ આપે છે, જે ઘણી રિમોટ-એક્સેસ સેવાઓ સત્રને અધિકૃત કે હિસાબ કરતાં પહેલાં માંગે છે. નુકસાનની ત્રિજ્યા પણ સ્થાનિક રહે છે: તૂટેલી ટનલ બધું વાપરતા શેર કરેલા માર્ગને બદલે એક Deployment બંધ કરે છે. તે કેવી રીતે ચાલે છે તે અમલીકરણ પર આધાર રાખે છે, અને અહીં જ લોકો ખોટું અનુમાન કરે છે.
જે સેટઅપને ફક્ત કર્નલ સ્થિતિની જરૂર છે તે init કન્ટેનરમાં પૂર્ણ થઈને બહાર નીકળી શકે છે. જે યુઝરસ્પેસ ડેમન Pod ના આખા જીવનકાળ દરમિયાન જીવંત રહેવું પડે તેને Kubernetes 1.29 માં નેટિવ સાઇડકાર તરીકે દાખલ કરાયેલા ફરી શરૂ કરી શકાય તેવા init કન્ટેનર સ્વરૂપની જરૂર છે, અને આ તફાવત સ્વાદમાંથી નહીં, ટનલના અમલીકરણમાંથી આવે છે. આ મોડેલની કિંમત નકલ છે: દરેક રેપ્લિકા પ્રમાણીકરણ કરે છે, પોતાનું ટનલ સરનામું મેળવે છે અને રિમોટ સત્ર સ્લોટ વાપરે છે, તેથી ઓટોસ્કેલિંગ ઘટના લિંકની બીજી બાજુએ ક્ષમતાની ઘટના બને છે. એક ક્રેડેન્શિયલ બધી રેપ્લિકામાં કોપી કરવાથી તે કિંમત દૂર થતી નથી, તે ઓડિટ ટ્રેઇલ દૂર કરે છે. ક્ષમતાઓ પણ એ જ તપાસને પાત્ર છે, કારણ કે પોતાના નેમસ્પેસમાં NET_ADMIN ઇચ્છતી ટનલને privileged: true ઉદાહરણના આખા હોસ્ટ પરનું અધિકાર વારસો લેવાનું કોઈ કારણ નથી.
જ્યારે CNI એગ્રેસનો માલિક હોય
જો CNI તેને સમર્થન આપે, તો એગ્રેસ ગેટવે વર્કલોડ અને ગંતવ્ય શ્રેણી દ્વારા ટ્રાફિક પસંદ કરે છે, પછી એક અનુમાનિત સ્રોત સરનામા હેઠળ પસંદ કરેલા નોડ દ્વારા મોકલે છે. Cilium નું સંસ્કરણ સામાન્ય સંદર્ભ છે, અને તેનું દસ્તાવેજીકરણ સ્પષ્ટ કહે છે કે સુવિધા માટે ચોક્કસ Cilium રૂપરેખાંકન અને યોગ્ય ઇન્ટરફેસ તથા સરનામાં સાથે પ્રાપ્ત ગેટવે નોડની જરૂર છે. તે Pod બન્યા પછીનો પ્રારંભિક સમયગાળો પણ નોંધે છે જ્યારે સ્ટીયરિંગ હજી લાગુ થયું નથી, જે પદટીપ નહીં, ડિઝાઇન ઇનપુટ છે.
તે વિલંબને તમારા પોતાના વચન સામે વાંચો. જો નિયમ એ છે કે કોઈ ટ્રાફિક બીજા માર્ગે ન નીકળે, તો ગેપ દરમિયાન મોકલતું નવું Pod તેને પહેલેથી તોડી ચૂક્યું છે, તેથી સ્ટાર્ટઅપ ક્રમને પોતાનો જવાબ જોઈએ: પોલિસી લાગુ થાય ત્યાં સુધી એપ્લિકેશન રોકો, અથવા વિન્ડો સ્વીકારો અને દસ્તાવેજ કરો.
દાવાને સાંકડો રાખો. એગ્રેસ ગેટવે માર્ગ પસંદ કરે છે અને અનુવાદ કરે છે. તે VPN સમાપ્ત કરતું નથી, અને તેની પાછળ સમર્થિત જોડાણ વિના ક્લસ્ટરને તમારા રિમોટ નેટવર્કનું ક્લાયન્ટ બનાવતું નથી.
| Question | Per-Pod tunnel | CNI egress gateway |
|---|---|---|
| Who holds the client identity | Each workload | The gateway, shared |
| What scaling changes | Enrollment and sessions per replica | Throughput and capacity per node |
| What the remote side sees | Distinct addresses | One translated source |
| Failure scope | One Deployment | Every workload behind the gateway |
અનુવાદ શાંતિથી બદલે છે કે રિમોટ બાજુ શું જુએ છે
ગેટવે સ્રોત ફરી લખે એટલે દરેક Pod ના સરનામાં જતાં રહે છે, તેથી ઓળખ આધારિત મંજૂરી-યાદી એક શેર કરેલા સરનામા આધારિત યાદી બને છે. આ ખામી નહીં, બદલો છે: જાળવવા માટે ઓછા નિયમો, કંઈ ખોટું વર્તે ત્યારે જડ બોલતું આરોપણ.
એપ્લિકેશન-સ્તરનું પ્રમાણીકરણ અને વિનંતી લોગિંગે નેટવર્ક હવે જે જાણ નથી કરતું તે ઉપાડવું પડશે. ગેટવે ક્ષમતા અને બદલીને શેર કરેલી માળખાગત સુવિધા ગણો, કારણ કે એક નોડ રીબૂટ હવે તેની પાછળના દરેક વર્કલોડને વિક્ષેપિત કરે છે, અને પરત માર્ગ વહેલો તપાસો: રિમોટ છેડાને અનુવાદિત સરનામે કેવી રીતે પહોંચવું તે ખબર હોવી જોઈએ, સામાન્ય રીતે એવા રૂટ કે NAT દ્વારા જે માણસે, મેનિફેસ્ટે નહીં, ધરાવવું પડે. સરનામા આયોજન પણ અહીં આવે છે, કારણ કે ઓવરલેપ થતી ક્લસ્ટર અને રિમોટ શ્રેણીઓ બંને મોડેલ તોડે છે અને IPv6 અપનાવવું વિરોધાભાસી યોજનાનું બહાનું નથી.
માલિકી દ્વારા નક્કી કરો, પછી વચન આપેલી નિષ્ફળતા ચકાસો
દરેક Pod માટે ટનલ ત્યારે પસંદ કરો જ્યારે રિમોટ સેવા વ્યક્તિગત વર્કલોડનું પ્રમાણીકરણ કરે, જ્યારે થોડા જ Deployment ને લિંકની જરૂર હોય, અને જ્યારે નિષ્ફળતા સ્થાનિક રહેવી જોઈએ. ગેટવે ત્યારે પસંદ કરો જ્યારે નેટવર્ક ટીમ પહેલેથી માર્ગની માલિક હોય, જ્યારે ઘણા વર્કલોડ એક ગંતવ્ય શેર કરે, અને જ્યારે સ્થિર સ્રોત સરનામું આખા અભ્યાસનો હેતુ હોય.
ગમે તે રીતે, સ્થિર સ્થિતિ નહીં, તમે વેચેલી ગુણવત્તા ચકાસો. એક Pod બનાવો, તેને તરત મોકલવા દો, અને જો વચન હતું કે ટનલમાંથી કંઈ છટકતું નથી તો પ્રથમ સેકન્ડ જુઓ. પાંચ રેપ્લિકા સુધી સ્કેલ કરો અને જો વચન દરેક વર્કલોડ માટે ઓળખ હતું તો રિમોટ છેડો જે સત્રો જાણ કરે તે ગણો. તે બે તપાસ મેનિફેસ્ટની સમીક્ષા કરતાં ઘણી ઝડપથી પદ્ધતિની મર્યાદા ઉજાગર કરે છે, અને કહે છે કે આગલી ઘટના કઈ ટીમની છે.