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 स्वीकारणे विरोधाभासी योजनेचे कारण नाही.
मालकीनुसार ठरवा, मग वचन दिलेली अयशस्वीता तपासा
दूरस्थ सेवा वैयक्तिक वर्कलोड प्रमाणित करते तेव्हा, फक्त काही Deploymentना दुवा लागतो तेव्हा, आणि अयशस्वीता स्थानिक राहिली पाहिजे तेव्हा प्रत्येक Podसाठी बोगदा निवडा. नेटवर्क संघ आधीच मार्गाचा मालक असतो तेव्हा, अनेक वर्कलोड एक गंतव्य सामायिक करतात तेव्हा, आणि स्थिर स्रोत पत्ता हाच संपूर्ण सरावाचा हेतू असतो तेव्हा गेटवे निवडा.
कसेही असो, स्थिर स्थिती नाही तर तुम्ही विकलेला गुणधर्म तपासा. एक Pod तयार करा, त्याला लगेच पाठवू द्या, आणि बोगद्यातून काहीही सुटत नाही हे वचन असेल तर पहिले काही सेकंद पाहा. पाच रेप्लिकांपर्यंत स्केल करा आणि वचन प्रत्येक वर्कलोडसाठी ओळख असेल तर दूरचे टोक जी सत्रे नोंदवते ती मोजा. या दोन तपासण्या मॅनिफेस्टच्या पुनरावलोकनापेक्षा खूप लवकर यंत्रणेच्या मर्यादा उघड करतात आणि पुढील घटना कोणत्या संघाची आहे हे सांगतात.