VPN વપરાશકર્તાઓ માટે Pod IP, ClusterIP અથવા આંતરિક લોડ બેલેન્સર
Pod બદલાય ત્યાં સુધી Pod IP VPN દ્વારા રૂટ કરી શકાય છે. સીધા Pod ઍક્સેસ, ClusterIP અને આંતરિક બેલેન્સરની સરખામણી કરો અને દરેકનો ખર્ચ શું છે.
VPC CNI સાથે Pod VPC માંથી સરનામું ધરાવી શકે છે, અને યોગ્ય રૂટ ધરાવતો VPN વપરાશકર્તા તેને સીધો પહોંચી શકે છે. તેના કારણે સીધો Pod ઍક્સેસ સૌથી સરળ વિકલ્પ લાગે છે, અને એ ખરેખર છે, Pod બદલાય ત્યાં સુધી. વપરાશકર્તા યાદ રાખે તે સરનામું એપ્લિકેશનનું હોવું જોઈએ, કોઈ રેપ્લિકાનું નહીં. ત્રણ પ્રવેશોની સરખામણી અંતે એમાં આવે છે કે સરનામું કઈ વસ્તુ ધરાવે છે અને વર્કલોડ ખસે ત્યારે શું ચાલુ રહેવું જોઈએ.
પહેલા જીવનચક્ર મુજબ પસંદ કરો, પછી નેટવર્કે પ્રવેશને પહોંચવા યોગ્ય બનાવવા શું કરવું તે મુજબ.
ત્રણ પ્રવેશ, ત્રણ જીવનચક્ર
Pod IP નો માલિક Pod છે: તેની સાથે ફાળવવામાં આવે છે અને તે સમાપ્ત થાય ત્યારે મુક્ત થાય છે. ClusterIP નો માલિક Service છે અને તે વર્ચ્યુઅલ છે, જ્યાં ક્લસ્ટરનું સેવા રૂટિંગ છે ત્યાં જ તેનો અર્થ છે. આંતરિક લોડ બેલેન્સરનો માલિક ક્લાઉડ સ્રોત છે જેને ક્લસ્ટરનું નિયંત્રક બેકએન્ડ સાથે પ્રોગ્રામ કરે છે. આ માલિકીના મોડેલો અગાઉથી કહે છે કે તમને કઈ નિષ્ફળતા મળશે: જૂનું સરનામું, પહોંચ ન શકાય તેવું નામ, અથવા જૂનો બેકએન્ડ સમૂહ.
પસંદ કરતા પહેલા સરખામણી લખો. માલિક અને નિષ્ફળતાને નામ આપ્યા પછી પસંદગી સામાન્ય રીતે જાતે જ થઈ જાય છે.
| Entry | Owner | Failure when the workload moves |
|---|---|---|
| Pod IP | The Pod | Address changes and saved links break |
| ClusterIP | The Service | Virtual address with no meaning outside cluster routing |
| Internal balancer | Cloud resource plus controller | Backends update, but the DNS view is yours to maintain |
સીધો Pod ઍક્સેસ: ઉપયોગી, કામચલાઉ
નિયંત્રિત તપાસ માટે સીધો ઍક્સેસ ખરેખર ઉપયોગી છે: એક વ્યવસ્થાપક, એક ટૂંકું સત્ર, એક ચોક્કસ પોર્ટ. પરંતુ વપરાશકર્તાઓ માટે તે નબળો કરાર છે, કારણ કે સરનામું અમલીકરણની વિગત છે જે દરેક રોલઆઉટમાં બદલાય છે. અને તેને વિકીમાં નોંધવું એ જ રીત છે જેમાં કામ કરતી સેવા અફવા બની જાય છે.
તે પ્રશસ્ત નિયમોને પણ આમંત્રે છે. એક વ્યવસ્થાપકને એક Pod સુધી પહોંચવાની પરવાનગી નોડ સબનેટના દરેક સરનામા માટેની પરવાનગી નથી, અને સામાન્ય રીતે બીજું જ લખવામાં આવે છે.
ClusterIP: ડિઝાઇન દ્વારા ક્લસ્ટર સુધી મર્યાદિત
ClusterIP કામ કરે છે કારણ કે ક્લસ્ટરનું ડેટાપ્લેન તેના માટે ક્લસ્ટરની અંદર રૂટિંગ પ્રોગ્રામ કરે છે. VPN પરના લેપટોપથી સરનામું કંઈ અર્થ ધરાવતું નથી જ્યાં સુધી કંઈક તેને જાણી જોઈને છતું ન કરે. svc.cluster.local પર સમાપ્ત થતું નામ ક્લસ્ટર DNS નું છે, તેથી તેને અલગ રિઝોલ્વર ધરાવતા ક્લાયન્ટ પર કૉપિ કરવાથી રૂટિંગ ભૂલને બદલે અસ્તિત્વમાં ન હોય તેવું નામ મળે છે.
ક્લસ્ટરની અંદરના કૉલર્સ માટે, અન્ય વર્કલોડ સહિત, ClusterIP યોગ્ય પ્રવેશ જ રહે છે. તે ફક્ત ક્લસ્ટરના રૂટિંગ ડોમેનની બહારના વપરાશકર્તાઓ માટે પ્રકાશન વ્યવસ્થા નથી.
આંતરિક લોડ બેલેન્સર: પ્રકાશિત માર્ગ
આંતરિક લોડ બેલેન્સર તમને સ્થિર ખાનગી સરનામું અને એવું નામ આપે છે જે તરફ તમારો પોતાનો ઝોન નિર્દેશ કરી શકે, જ્યારે નિયંત્રક બેકએન્ડ સમૂહને અદ્યતન રાખે છે, જેમ EKS લોડ-બેલેન્સિંગ માર્ગદર્શિકા વર્ણવે છે. આ જ એ પ્રવેશ છે જે સામાન્ય Pod બદલીમાં ટકી રહે છે, કોઈને દસ્તાવેજ સંપાદિત કરવાની જરૂર પડ્યા વિના. તેનો ખર્ચ ક્લાઉડ સ્રોત, નિયંત્રક ગોઠવણી અને VPN થી એક રૂટ છે, અને લોકો આ ભાગોને જ ઓછો અંદાજે છે.
ક્લસ્ટર ખરેખર જે નિયંત્રક મોડેલ ચલાવે છે તેનો ઉપયોગ કરો. એક એકીકરણ માટે લખાયેલી ટીકાઓ બીજા માટે લાગુ પડતી નથી.
સ્રોત સરનામું કોણ છે
સુરક્ષા જૂથો તેમની સરહદે આવતા સ્રોતને જુએ છે, જે VPN અને લોડ-બેલેન્સિંગ માર્ગ પર આધાર રાખીને જોડાયેલ ક્લાયન્ટ અથવા અનુવાદિત સરનામું હોઈ શકે. EC2 આધારિત નોડ્સ પર, સામાન્ય VPC CNI Pod ડિફોલ્ટ રૂપે નોડના ENI જૂથો વારસામાં મેળવે છે, જ્યારે સમર્થિત ગોઠવણીઓ Pod-વિશિષ્ટ જૂથો જોડી શકે છે. અનુમાનિત લેપટોપ સરનામા માટે નહીં, દસ્તાવેજીકૃત માર્ગ માટે નિયમો લખો.
એપ્લિકેશનના પોતાના શ્રોતા અને પ્રમાણીકરણને અલગ નિયંત્રણો તરીકે રાખો. પ્રવાહને મંજૂરી આપતો નેટવર્ક નિયમ અધિકૃતતાનો નિર્ણય નથી અને તેને એ રીતે ગણવો જોઈએ નહીં.
વપરાશકર્તાઓને શું આપવું
વપરાશકર્તાઓને સરનામું નહીં, સેવાનું નામ આપો. નામ ખાનગી ઝોનમાં પ્રકાશિત કરો, તેને આંતરિક પ્રવેશ તરફ નિર્દેશ કરો, અને પછી બેકએન્ડ Pod બદલીને પરીક્ષણ કરો જ્યારે ક્લાયન્ટ એ જ નામ ખુલ્લું રાખે. તે કસરત એ ગુણધર્મ ચકાસે છે જે મહત્વનો છે: નિયમિત ડિપ્લોયમેન્ટ પછી એ જ એપ્લિકેશન સુધી પહોંચવું.
સીધા Pod ઍક્સેસને તેના પોતાના અવકાશ સાથે દસ્તાવેજીકૃત ઓપરેશનલ અપવાદ તરીકે રાખો, વપરાશકર્તા સૂચનાઓથી દૂર.