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 তৈরি করুন, তাকে সঙ্গে সঙ্গে প্রেরণ করতে দিন, এবং প্রথম কয়েক সেকেন্ড দেখুন যদি প্রতিশ্রুতি ছিল যে কিছুই টানেল থেকে পালায় না। পাঁচটি রেপ্লিকায় স্কেল করুন এবং রিমোট প্রান্ত যে সেশন রিপোর্ট করে তা গুনুন যদি প্রতিশ্রুতি প্রতি-ওয়ার্কলোড পরিচয় হয়। এই দুটি যাচাই ম্যানিফেস্ট পর্যালোচনার চেয়ে অনেক দ্রুত প্রক্রিয়াটির সীমা প্রকাশ করে, এবং তারা বলে দেয় পরের ঘটনার মালিক কোন দল।