Pod, node அல்லது cluster: VPN sidecar உண்மையில் எதை மறுவழிப்படுத்துகிறது

Kubernetes Pod-இல் உள்ள VPN sidecar, சிறந்த நடத்தையுடன் host-நிலை VPN போலத் தெரிகிறது, ஒற்றுமை namespace-இன் எல்லையில் முடிகிறது. ஒரு Pod-இல் உள்ள கொள்கலன்கள் முகவரி மற்றும் போர்ட் இடைவெளி உட்பட network namespace-ஐப் பகிர்கின்றன, எனவே பாதைகளையும் கொள்கையையும் நிறுவும் sidecar, பயன்பாட்டின் பொதிகள்கள் எங்கு செல்கின்றன என்பதை உண்மையில் மாற்றுகிறது. node-இல் உள்ள பிற Pod-களுக்கு எதையும் மாற்றாது, நீங்கள் அதை அவ்வாறு கட்டமைக்காத வரை node-இன் சொந்த stack-ஐயும் தொடாது. இந்த எல்லையைச் சரியாகப் புரிந்துகொள்வது நீங்கள் எதைப் பயன்படுத்தலாம், எதைச் சோதிக்க வேண்டும் என்பதைத் தீர்மானிக்கிறது. கீழே உள்ள பகுதிகள் இதை namespace-இலிருந்து வெளிப்புறமாகப் பின்தொடர்கின்றன.

பகிரப்பட்ட namespace, பகிரப்பட்ட விளைவுகள்

ஒரு Pod-இல் உள்ள இரண்டு கொள்கலன்கள் loopback வழியாகப் பேசி ஒரே இடைமுகங்களைப் பார்க்கின்றன, அதனால்தான் sidecar முறை வேலை செய்கிறது: பயன்பாடு ஒரு tunnel இருப்பதை அறியத் தேவையில்லை, ஏனெனில் அது தீர்க்கும் பாதை அது பயன்படுத்தும் namespace-இல் நிறுவப்பட்டது. அதே பண்பு sidecar-இன் தவறுகள் பயன்பாட்டின் தவறுகள் என்பதைக் குறிக்கிறது. அதிகம் பிடிக்கும் பாதை, அல்லது tunnel-க்குள் உள்ள resolver-ஐ நோக்கும் DNS மாற்றம், அந்த Pod-இல் உள்ள ஒவ்வொரு செயல்முறைக்கும் உடனடியாகப் பொருந்தும். பகிரப்பட்ட namespace-இல் கொள்கலன் வாரியான routing இல்லை, எனவே sidecar-ஐ ஒரு செயல்முறைக்கு மட்டுமே வரம்பிட முடியாது.

மதிப்பாய்வின் போது நினைவில் கொள்ள வேண்டிய வழிமுறை இதுவே: தாக்கத்தின் வரம்பு Pod, node அல்ல cluster-ம் அல்ல.

sidecar எட்டாத இடம்

பிற Pod-கள் தங்கள் சொந்த namespace-ஐயும் தங்கள் சொந்த routing-ஐயும் வைத்திருக்கின்றன, எனவே அதே egress தேவைப்படும் workload-க்கு அதே sidecar அல்லது அதற்குப் பதிலாக node-நிலை வடிவமைப்பு தேவை. node-இன் போக்குவரத்தும் Pod namespace-க்கு வெளியே உள்ளது, host network உள்ள Pod-கள் இந்தத் தனிமையிலிருந்து வேண்டுமென்றே முழுவதுமாக விலகுகின்றன. வசதியான ஒன்றை அடைய sidecar-ஐ host networking உடன் இயக்கினால், நீங்கள் வரம்பை ஒரு Pod-இலிருந்து முழு node-க்கும் விரிவுபடுத்தியுள்ளீர்கள், அதைச் சத்தமாகச் சொல்ல வேண்டும்.

cluster சேவைகளுக்கான போக்குவரத்து மற்றொரு பொதுவான ஆச்சரியம். Pod-க்குள் உள்ள அகலமான இயல்புநிலைப் பாதை API சேவையகத்திற்கோ ClusterIP சேவைக்கோ உத்தேசிக்கப்பட்ட கோரிக்கைகளைப் பிடிக்கலாம், பின்னர் அவை tunnel உடைந்ததைப் போலத் தோன்றும் வகையில் தோல்வியடைகின்றன.

பாதைத் திட்டம்: Pod, சேவை, node மற்றும் VPN வரம்புகள்

நான்கு வரம்புகளையும் எழுதி, எதையும் பயன்படுத்தும் முன் ஒன்றுடன் ஒன்று மேற்பொருந்துகிறதா எனப் பாருங்கள்: Pod CIDR, சேவை CIDR, node முகவரிகள் மற்றும் VPN-க்குப் பின்னால் உள்ள இலக்குகள். VPN-இன் தனியார் வரம்புகளுக்கும் cluster-இன் சொந்த இடத்திற்கும் இடையிலான மேற்பொருந்துதல் அரிதல்ல, இயல்புநிலைப் பாதை அதற்குத் தவறான தீர்வு. பாதைத் திட்டம் manifest-ஐப் போலவே அதே களஞ்சியத்தில் இருக்க வேண்டும், ஏனெனில் அடுத்த cluster முற்றிலும் வேறுபட்ட Pod மற்றும் சேவை வரம்புகளை வழங்கலாம்.

DNS திட்டத்தின் ஒரு பகுதி, தனிக் கவலை அல்ல. resolver கட்டமைப்பை மீண்டும் எழுதும் sidecar, cluster-க்குள் சேவைக் கண்டறிதலை உடைக்கலாம், அதே சமயம் வெளிப்புறத் தேடல்கள் சரியாக வேலை செய்கின்றன.

தொடக்கம் மற்றும் தோல்வி வெளிப்படையான நிலைகள்

இயங்கும் sidecar செயல்முறை egress கொள்கை அல்ல. tunnel தயாராகும் முன் எந்தப் போக்குவரத்து பாயலாம், பின்னர் அது இறந்தால் என்ன நடக்கும் என்பதைத் தீர்மானித்து, அந்த முடிவைச் செயல்படுத்துங்கள்: பயன்பாட்டுக் கொள்கலனை gate செய்யும் probe, இயல்பாக மறுக்கும் network கொள்கை, அல்லது இரண்டும். அவற்றில் ஒன்றும் இல்லையெனில் பயன்பாடு தொடங்கி, பெயர்களைத் தீர்த்து, tunnel இன்னும் இணைந்துகொண்டிருக்கும் போதே போக்குவரத்தை node-இன் வழக்கமான பாதையிலிருந்து வெளியே அனுப்புகிறது.

அந்த இடைவெளி ஆரோக்கியமான cluster-இல் குறுகியது, உடைந்த cluster-இல் நிரந்தரமானது, தாக்குபவர் அல்லது தற்செயலான தரவுக் கசிவு விரும்பும் பண்பு அதுவே.

வரிசையைத் தோல்விச் சோதனையுடன் இணைக்கவும். sidecar-ஐக் கொன்று, பயன்பாடு அமைதியாகப் பின்வாங்குவதற்குப் பதிலாக அதன் நோக்கமிட்ட egress-ஐ இழக்கிறது என்பதை உறுதிப்படுத்துங்கள்.

திறன்கள், கொள்கைகள் மற்றும் app கொள்கலனிலிருந்து சோதனை

இடைமுகங்களை உருவாக்கவும் பாதைகளை மாற்றவும் தேவையான திறன்களை வழங்குவது சிறப்புரிமை முடிவு, தனிமைப்படுத்தப்பட்ட Pod-க்கு ஏற்ற சிறப்புரிமை node stack-இல் தானாகவே ஏற்றதாக இருக்காது. cluster ஆதரிக்கும் network மற்றும் பாதுகாப்புக் கொள்கை வழிமுறைகளைப் பயன்படுத்துங்கள், ஒவ்வொரு CNI அல்லது கொள்கைச் செயலாக்கமும் VPN இடைமுகத்தை ஒரே மாதிரி கையாளும் எனக் கருத வேண்டாம்; வேறுபாடுகள் உங்களுக்கு முக்கியமான தோல்வி நிகழ்வுகளிலேயே தோன்றும்.

உண்மையான app கொள்கலனிலிருந்து சோதியுங்கள், தனியார் இலக்கு, cluster சேவை மற்றும் பொது இணையத்திற்கு புதிய கோரிக்கைகளுடன். sidecar-இலிருந்து செய்யும் சோதனை tunnel வேலை செய்கிறது என்பதை நிரூபிக்கிறது, பயன்பாடு தேவையானதை அடைகிறது என்பதை அல்ல.

VPN கட்டமைப்பின் அருகில் cluster-இன் network அனுமானங்களை ஆவணப்படுத்துங்கள். பின்னர் workload-ஐ மற்றொரு cluster-க்கு நகர்த்துவது அமைதியாகச் செயல்படுவதை நிறுத்தும் image மாற்றமல்ல, பாதைத் திட்டத்தைச் சரிபார்க்கும் பயிற்சியாகும்.