Pod, নোড নাকি ক্লাস্টার: VPN sidecar আসলে কী রিরুট করে

Kubernetes Pod-এ একটি VPN sidecar দেখতে হোস্ট-স্তরের VPN-এর মতো, শুধু ভালো ব্যবহার নিয়ে, আর মিলটা namespace-এর সীমায় শেষ হয়। একটি Pod-এর কন্টেইনারগুলো ঠিকানা ও পোর্টের জায়গা সহ একই নেটওয়ার্ক namespace ভাগ করে, তাই রুট ও পলিসি বসানো sidecar সত্যিই বদলে দেয় অ্যাপ্লিকেশনের প্যাকেটগুলো কোথায় যায়। নোডের অন্য Pod-গুলোর জন্য এটি কিছুই বদলায় না, আর আপনি সেভাবে কনফিগার না করলে নোডের নিজের স্ট্যাকেও হাত দেয় না। এই সীমাটা ঠিকভাবে বোঝা ঠিক করে দেয় আপনি কী ডিপ্লয় করতে পারবেন আর কী পরীক্ষা করতে হবে। নিচের অংশগুলো namespace থেকে বাইরের দিকে এটার অনুসরণ করে।

ভাগ করা namespace, ভাগ করা পরিণতি

একটি Pod-এর দুই কন্টেইনার loopback দিয়ে কথা বলে আর একই ইন্টারফেস দেখে, তাই sidecar প্যাটার্নটা আদৌ কাজ করে: অ্যাপ্লিকেশনকে টানেলের অস্তিত্ব জানতে হয় না, কারণ যে রুটে সে পৌঁছায় সেটি তার ব্যবহৃত namespace-এ বসানো হয়েছে। একই ধর্মের অর্থ, sidecar-এর ভুল অ্যাপ্লিকেশনেরই ভুল। যে রুট বেশি কিছু ধরে ফেলে, বা যে DNS পরিবর্তন টানেলের ভেতরের রিজলভারের দিকে দেখায়, তা সেই Pod-এর প্রতিটি প্রসেসে সঙ্গে সঙ্গে প্রযোজ্য হয়। ভাগ করা namespace-এ কন্টেইনারভিত্তিক রাউটিং নেই, তাই sidecar-কে এক প্রসেসে সীমাবদ্ধ করা যায় না।

পর্যালোচনার সময় এটাই মনে রাখার মতো প্রক্রিয়া: প্রভাবের পরিধি Pod, নোড নয় আর ক্লাস্টারও নয়।

sidecar যেখানে পৌঁছায় না

অন্য Pod-গুলো নিজেদের namespace আর নিজেদের রাউটিং রাখে, তাই একই নির্গমন দরকার এমন ওয়ার্কলোডের একই sidecar বা বরং নোড-স্তরের নকশা দরকার। নোডের ট্রাফিকও Pod namespace-এর বাইরে, আর হোস্ট-নেটওয়ার্ক Pod-গুলো ইচ্ছাকৃতভাবে এই বিচ্ছিন্নতা পুরোপুরি বাদ দেয়। সুবিধাজনক কিছুতে পৌঁছাতে host networking দিয়ে sidecar চালালে আপনি পরিধি এক Pod থেকে পুরো নোডে বাড়িয়েছেন এবং তা স্পষ্ট করে বলা উচিত।

ক্লাস্টার সার্ভিসের ট্রাফিক আরেকটি সাধারণ অবাক করা বিষয়। Pod-এর ভেতরের চওড়া ডিফল্ট রুট API সার্ভার বা ClusterIP সার্ভিসের জন্য পাঠানো অনুরোধ ধরে ফেলতে পারে, আর সেগুলো পরে এমনভাবে ব্যর্থ হয় যেন টানেলটা ভাঙা।

রুট পরিকল্পনা: Pod, সার্ভিস, নোড ও VPN রেঞ্জ

চারটি রেঞ্জ লিখে রাখুন এবং কিছু ডিপ্লয় করার আগে ওভারল্যাপ দেখুন: Pod CIDR, সার্ভিস CIDR, নোডের ঠিকানা আর VPN-এর পেছনের গন্তব্যগুলো। VPN-এর প্রাইভেট রেঞ্জ আর ক্লাস্টারের নিজের জায়গার ওভারল্যাপ বিরল নয়, আর ডিফল্ট রুট তার সঠিক সমাধান নয়। রুট পরিকল্পনা ম্যানিফেস্টের মতো একই রিপোজিটরিতে থাকা উচিত, কারণ পরের ক্লাস্টার সম্পূর্ণ আলাদা Pod ও সার্ভিস রেঞ্জ দিতে পারে।

DNS পরিকল্পনার অংশ, আলাদা দুশ্চিন্তা নয়। যে sidecar রিজলভার কনফিগারেশন নতুন করে লেখে, সে ক্লাস্টারের ভেতরের সার্ভিস আবিষ্কার ভেঙে দিতে পারে, অথচ বাইরের লুকআপ নিখুঁতভাবে কাজ করে।

শুরু আর ব্যর্থতা স্পষ্ট অবস্থা

চলমান sidecar প্রসেস কোনো নির্গমন নীতি নয়। টানেল প্রস্তুত হওয়ার আগে কোন ট্রাফিক যেতে পারে আর পরে এটি মরে গেলে কী ঘটে, তা ঠিক করুন, তারপর সেই সিদ্ধান্ত বাস্তবায়ন করুন: অ্যাপ্লিকেশন কন্টেইনারকে গেট করা একটি প্রোব, ডিফল্টে অস্বীকার করা একটি নেটওয়ার্ক পলিসি, বা দুটোই। এর একটি ছাড়া অ্যাপ্লিকেশন শুরু হয়, নাম সমাধান করে আর ট্রাফিক নোডের স্বাভাবিক পথে পাঠায়, যখন টানেল তখনো সংযোগ করছে।

এই ফাঁক সুস্থ ক্লাস্টারে ক্ষণিকের আর ভাঙা ক্লাস্টারে স্থায়ী, আর ঠিক এই ধর্মটাই আক্রমণকারী বা দুর্ঘটনাজনিত তথ্য ফাঁস পছন্দ করে।

ক্রমটাকে ব্যর্থতার পরীক্ষার সঙ্গে জোড়া দিন। sidecar-টা মেরে ফেলুন এবং নিশ্চিত করুন অ্যাপ্লিকেশন চুপচাপ পিছিয়ে না গিয়ে তার প্রত্যাশিত নির্গমন হারায়।

ক্ষমতা, পলিসি আর অ্যাপ কন্টেইনার থেকে পরীক্ষা

ইন্টারফেস তৈরি আর রুট বদলানোর জন্য দরকারি ক্ষমতাগুলো দেওয়া একটি বিশেষাধিকার সিদ্ধান্ত, আর বিচ্ছিন্ন Pod-এর জন্য উপযুক্ত বিশেষাধিকার স্বয়ংক্রিয়ভাবে নোড স্ট্যাকে উপযুক্ত নয়। ক্লাস্টারের সমর্থিত নেটওয়ার্ক ও নিরাপত্তা পলিসির পদ্ধতি ব্যবহার করুন, আর ধরে নেবেন না যে প্রতিটি CNI বা পলিসি বাস্তবায়ন VPN ইন্টারফেসকে একইভাবে দেখে; পার্থক্যগুলো ঠিক সেই ব্যর্থতার ক্ষেত্রেই দেখা যায় যা আপনার কাছে গুরুত্বপূর্ণ।

আসল অ্যাপ্লিকেশন কন্টেইনার থেকে পরীক্ষা করুন, একটি প্রাইভেট গন্তব্য, একটি ক্লাস্টার সার্ভিস আর পাবলিক ইন্টারনেটে নতুন অনুরোধ দিয়ে। sidecar থেকে চালানো পরীক্ষা প্রমাণ করে টানেল কাজ করে, এই নয় যে অ্যাপ্লিকেশন তার দরকারি জিনিসে পৌঁছাতে পারে।

VPN কনফিগারেশনের পাশে ক্লাস্টারের নেটওয়ার্ক অনুমানগুলো নথিভুক্ত করুন। তখন ওয়ার্কলোড অন্য ক্লাস্টারে সরানোটা চুপচাপ কাজ বন্ধ করা ইমেজ পরিবর্তন নয়, বরং রুট পরিকল্পনা যাচাইয়ের অনুশীলন।