একটি VPN সাইডকারের দরকার শুরু নিয়ম ও ব্যর্থতা নিয়ম

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

ক্রম কেবল প্রথম অনুরোধটিকে নিয়ন্ত্রণ করে

Kubernetes রিস্টার্টযোগ্য init কনটেইনার দিয়ে গড়া একটি সাইডকার লাইফসাইকেল সমর্থন করে। সেই মডেলে একটি স্টার্টআপ প্রোব টানেল প্রস্তুত হওয়ার কথা না জানানো পর্যন্ত পরের ইনিশিয়ালাইজেশন ধাপটি আটকে রাখতে পারে। এটি সত্যিকারের উন্নতি, এবং এন্ট্রিপয়েন্ট স্ক্রিপ্টে sleep যোগ করার বদলে সচেতনভাবে এটি ব্যবহার করা উচিত। গেটটি ততটাই ভালো যতটা ভালো তার পরীক্ষিত শর্ত।

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

গেটটি কী পর্যবেক্ষণ করে তা বলুন: একটি প্রসেস আছে, একটি ইন্টারফেস আছে, একটি হ্যান্ডশেক সম্পন্ন হয়েছে। এর প্রতিটি “এই pod-এর প্রয়োজনীয় গন্তব্যগুলোতে ডেটা পথ কাজ করে” দাবির চেয়ে দুর্বল।

ডেটা পথ ধরে নেওয়ার বদলে তা প্রয়োগ করুন

প্রোব হলো এক মুহূর্তের পরীক্ষা, আর ফায়ারওয়াল হলো মুহূর্তগুলোর মধ্যে বলবৎ একটি বৈশিষ্ট্য। যদি প্রয়োজন হয় যে অ্যাপ ট্রাফিক কখনো টানেলের বাইরে যাবে না, তবে তা ভাগ করা নেটওয়ার্ক নেমস্পেসে গ্রহণ-বা-বাতিল নিয়ম হিসেবে প্রকাশ করতে হবে। কনটেইনার শুরুর ক্রম সেই প্রয়োজন বহন করতে পারে না। কেবল একটি নিয়মই পারে।

একই pod-এর কনটেইনারগুলো সেই নেমস্পেস ভাগ করে, তাই প্রয়োগের বিন্দু হলো নেমস্পেস নিজেই। আপনি যা-ই লিখুন, তা টানেলের নিজের বাইরের সংযোগটি খোলা রাখতে হবে, কারণ অ্যাপকে রক্ষা করতে সেটি ব্লক করলে অ্যাপের প্রয়োজনীয় পথটাই কেটে যায়।

ব্যর্থতার নীতি স্পষ্টভাবে ঠিক করুন: টানেল অসুস্থ হলে অ্যাপ ট্রাফিক কি সম্পূর্ণ থামা উচিত, নাকি চলতে থাকবে এবং অরক্ষিত হিসেবে চিহ্নিত হবে? দুটোই যুক্তিসঙ্গত, এবং কোনোটিই নির্দিষ্ট ক্রমে কনটেইনার শুরু করে যা পাওয়া যায় তা নয়।

আপনি যে ট্রাফিকের কথা বলেননি তা পরীক্ষা করুন

নিয়ন্ত্রিত টানেল ব্যর্থতার সময় একটি নতুন অনুরোধ নিন এবং দেখুন তা বেরোয় কি না। তারপর এমন পথের জন্য পরীক্ষাটি পুনরাবৃত্তি করুন যেখানে এক্সিট-অ্যাড্রেস পরীক্ষা কখনো হাত দেয় না: ক্লাস্টারের ভেতরে DNS রিজলিউশন, IPv6 গন্তব্য, এবং পাবলিক ইন্টারনেটের বদলে ক্লাস্টার-অভ্যন্তরীণ ঠিকানা দিয়ে পৌঁছানো সেবাগুলো। এসবই সেই পথ যা টানেল মরে যাওয়ার পরেও চুপচাপ কাজ করতে থাকে।

একটি এক্সিট-অ্যাড্রেস পেজ প্রমাণ করে যে একটি অনুরোধ সেই মুহূর্তে আপনার প্রত্যাশিত জায়গায় গেছে। এটি অন্য পথগুলোর তালিকা করতে পারে না, এবং আপনি যা পরীক্ষা করেছেন আর pod যা পৌঁছাতে পারে তার ফাঁকেই মজার ব্যর্থতাগুলো বাস করে।

কেবল পরিষ্কার শুরুর পরেই নয়, সাইডকার রিস্টার্টের পরেও পরীক্ষাটি পুনরাবৃত্তি করুন। রিস্টার্ট হওয়া টানেল কনটেইনার নেমস্পেসে রুট ও নীতি এক মধ্যবর্তী অবস্থায় রেখে যেতে পারে।

ডিপ্লয়মেন্ট রেকর্ড লিখুন

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

সুরক্ষা ভেবে ভুল করা একটি হেলথ চেক সবচেয়ে ব্যয়বহুল ধরনের সবুজ সূচক, কারণ এটি মানুষকে প্রশ্ন করতে থামিয়ে দেয়। ডকুমেন্টেশনে এটিকে সঠিকভাবে নাম দেওয়া এক বাক্যের খরচ, আর তা ঠেকিয়ে দেয়।

শেষে, অ্যাপ চালু থাকা অবস্থায় পুনরুদ্ধারের পথটি একবার পরীক্ষা করুন। এমন নকশা যা ইগ্রেস ফিরিয়ে আনতে pod পুনরায় তৈরি করা দাবি করে তা একটি সিদ্ধান্ত, এবং তা আপনার নেওয়া সিদ্ধান্ত হওয়া উচিত, আপনি আবিষ্কার করা কিছু নয়।