Kubernetes Pod VPN vs வெளிச்செல் நுழைவாயில்: சுரங்கப்பாதை யாருக்கு?
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 ஏற்றுக்கொள்வது முரண்பட்ட திட்டத்திற்கு சாக்கு அல்ல.
உரிமையின் அடிப்படையில் முடிவு செய்யுங்கள், பின்னர் வாக்குறுதியளித்த தோல்வியைச் சோதியுங்கள்
தொலை சேவை தனிப்பட்ட பணிச்சுமைகளை அங்கீகரிக்கும்போது, சில Deployment களுக்கு மட்டும் இணைப்பு தேவைப்படும்போது, தோல்வி உள்ளூராகவே இருக்க வேண்டியபோது ஒவ்வொரு Pod க்கும் சுரங்கப்பாதையைத் தேர்ந்தெடுங்கள். வலையமைப்புக் குழு ஏற்கனவே பாதையை வைத்திருக்கும்போது, பல பணிச்சுமைகள் ஒரு இலக்கைப் பங்கிடும்போது, நிலையான மூல முகவரியே முழுப் பயிற்சியின் நோக்கமாக இருக்கும்போது நுழைவாயிலைத் தேர்ந்தெடுங்கள்.
எப்படியிருந்தாலும், நிலையான நிலையை அல்ல, நீங்கள் விற்ற பண்பைச் சரிபாருங்கள். ஒரு Pod ஐ உருவாக்கி, உடனே அனுப்ப அனுமதித்து, சுரங்கப்பாதையிலிருந்து எதுவும் தப்பவில்லை என்பது வாக்குறுதியெனில் முதல் சில வினாடிகளைக் கவனியுங்கள். ஐந்து பிரதிகளாக அளவீடு செய்து, வாக்குறுதி ஒவ்வொரு பணிச்சுமைக்கும் அடையாளமெனில் தொலை முனை தெரிவிக்கும் அமர்வுகளை எண்ணுங்கள். இந்த இரண்டு சோதனைகள் மேனிஃபெஸ்ட் மதிப்பாய்வை விட மிக வேகமாக பொறிமுறையின் வரம்புகளை வெளிப்படுத்துகின்றன, அடுத்த சம்பவம் எந்தக் குழுவுக்கு என்பதை அவை சொல்கின்றன.