VPC CNI-এর সাথে একটি Pod VPC থেকে ঠিকানা পেতে পারে, এবং সঠিক রুট থাকা VPN ব্যবহারকারী সরাসরি সেখানে পৌঁছাতে পারে। তাই সরাসরি Pod অ্যাক্সেস সবচেয়ে সহজ বিকল্প মনে হয়, এবং Pod প্রতিস্থাপিত হওয়ার আগ পর্যন্ত তা-ই। ব্যবহারকারীর মনে রাখা ঠিকানাটি অ্যাপ্লিকেশনের হওয়া উচিত, কোনো রেপ্লিকার নয়। তিনটি এন্ট্রির তুলনা শেষ পর্যন্ত এই প্রশ্নে দাঁড়ায়: ঠিকানাটির মালিক কোন বস্তু, এবং ওয়ার্কলোড সরে গেলে কী কাজ করতে থাকতে হবে।

প্রথমে লাইফসাইকল অনুযায়ী বাছুন, তারপর নেটওয়ার্ককে কী করতে হবে তা অনুযায়ী, যাতে এন্ট্রিটি পৌঁছানো যায়।

তিনটি এন্ট্রি, তিনটি লাইফসাইকল

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

বাছাই করার আগে তুলনাটি লিখে রাখুন। মালিক ও ব্যর্থতার নাম দেওয়া হয়ে গেলে সিদ্ধান্ত সাধারণত নিজেই হয়ে যায়।

EntryOwnerFailure when the workload moves
Pod IPThe PodAddress changes and saved links break
ClusterIPThe ServiceVirtual address with no meaning outside cluster routing
Internal balancerCloud resource plus controllerBackends update, but the DNS view is yours to maintain

সরাসরি Pod অ্যাক্সেস: উপকারী, সাময়িক

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

এটি প্রশস্ত নিয়মকেও আমন্ত্রণ জানায়। একজন প্রশাসককে একটি Pod-এ পৌঁছানোর অনুমতি নোড সাবনেটের প্রতিটি ঠিকানার অনুমতি নয়, এবং সাধারণত দ্বিতীয়টিই লেখা হয়।

ClusterIP: নকশা অনুযায়ী ক্লাস্টার-সীমিত

ClusterIP কাজ করে কারণ ক্লাস্টারের ডেটাপ্লেন ক্লাস্টারের ভিতরে এর জন্য রাউটিং প্রোগ্রাম করে। VPN-এ থাকা ল্যাপটপ থেকে ঠিকানাটির কোনো অর্থ নেই, যদি না কিছু সচেতনভাবে এটি প্রকাশ করে। svc.cluster.local-এ শেষ হওয়া নাম ক্লাস্টার DNS-এর, তাই ভিন্ন রিজলভারযুক্ত ক্লায়েন্টে এটি কপি করলে রাউটিং ত্রুটি নয়, বরং অস্তিত্বহীন নাম পাওয়া যায়।

ক্লাস্টারের ভিতরের কলকারীদের জন্য, অন্য ওয়ার্কলোডসহ, ClusterIP সঠিক এন্ট্রি হিসেবেই থাকে। এটি কেবল ক্লাস্টারের রাউটিং ডোমেইনের বাইরের ব্যবহারকারীদের জন্য প্রকাশের ব্যবস্থা নয়।

অভ্যন্তরীণ লোড ব্যালান্সার: প্রকাশিত পথ

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

ক্লাস্টার আসলে যে কন্ট্রোলার মডেল চালায় সেটিই ব্যবহার করুন। এক ইন্টিগ্রেশনের জন্য লেখা অ্যানোটেশন অন্যটিতে প্রযোজ্য নয়।

সোর্স ঠিকানাটি কে

সিকিউরিটি গ্রুপগুলি তাদের সীমানায় আসা সোর্সটি দেখে, যা VPN ও লোড-ব্যালান্সিং পথের উপর নির্ভর করে সংযুক্ত ক্লায়েন্ট বা অনুবাদিত ঠিকানা হতে পারে। EC2-ভিত্তিক নোডে সাধারণ VPC CNI Pod ডিফল্টভাবে নোডের ENI গ্রুপ উত্তরাধিকারী হয়, আর সমর্থিত কনফিগারেশন Pod-নির্দিষ্ট গ্রুপ সংযুক্ত করতে পারে। অনুমান করা ল্যাপটপ ঠিকানার জন্য নয়, নথিভুক্ত পথের জন্য নিয়ম লিখুন।

অ্যাপ্লিকেশনের নিজস্ব লিসেনার ও প্রমাণীকরণকে আলাদা নিয়ন্ত্রণ হিসেবে রাখুন। প্রবাহের অনুমতি দেওয়া একটি নেটওয়ার্ক নিয়ম কোনো অনুমোদন সিদ্ধান্ত নয় এবং এটি তেমনভাবে বিবেচনা করা উচিত নয়।

ব্যবহারকারীদের কী দিতে হবে

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

সরাসরি Pod অ্যাক্সেসকে নিজস্ব পরিধিসহ নথিভুক্ত অপারেশনাল ব্যতিক্রম হিসেবে রাখুন, ব্যবহারকারীর নির্দেশনা থেকে দূরে।

সম্পর্কিত নিবন্ধ