প্রাইভেট GKE নোডগুলো ঠিক করে না kubectl কোন API ব্যবহার করে

নোডগুলো প্রাইভেট, VPN সেখানে পৌঁছায়, তবুও kubectl ক্লাস্টারের সঙ্গে কথা বলতে পারে না। এই দুটি তথ্যের মধ্যে কোনো সম্পর্ক নেই। kubectl যে ঠিকানা ব্যবহার করে তা আসে kubeconfig-এ সংরক্ষিত সার্ভার URL থেকে, যা ক্রেডেনশিয়াল আনার সময় লেখা হয়, এবং আপনার যোগ করা কোনো রুট তা বদলায় না। এদিকে নোডগুলো আদৌ তা নয়, যেখানে kubectl পৌঁছাতে চাইছে।

পাঁচটি পরীক্ষা, একমাত্র গুরুত্বপূর্ণ মানটি দিয়ে শুরু করে।

পরীক্ষা 1: kubeconfig-এ সার্ভার URL পড়ুন

ক্রেডেনশিয়াল ফাঁকা না করেই এন্ডপয়েন্টটি প্রিন্ট করুন: kubectl config view --minify -o jsonpath="{.clusters[0].cluster.server}"। এই একটি স্ট্রিংই বলে দেয় ক্লায়েন্ট কোনো IP ঠিকানা, DNS নাম, নাকি আপনার অনভিপ্রেত কোনো এক্সটার্নাল ঠিকানায় নির্দেশ করছে। এই তদন্তের বাকি সবকিছু এর থেকেই আসে।

URL যদি আপনার ধারণা অনুযায়ী কনফিগার করা এন্ডপয়েন্ট না হয়, তবে বাকি ডায়াগনোসিস কেবল মনোযোগ বিচ্যুতি।

পরীক্ষা 2: URL-টি এন্ডপয়েন্টের ধরনের সঙ্গে মিলিয়ে দেখুন

বর্তমান GKE IP-ভিত্তিক ও DNS-ভিত্তিক উভয় কন্ট্রোল-প্লেন অ্যাক্সেস সমর্থন করে, এবং আপনার আনা ক্রেডেনশিয়াল এর একটি বেছে নেয়। gcloud container clusters get-credentials NAME --location REGION --internal-ip অভ্যন্তরীণ IP এন্ডপয়েন্ট লেখে, আর --dns-endpoint DNS-ভিত্তিক অ্যাক্সেস বেছে নেয়। কোনোটিই নেটওয়ার্ক পথ তৈরি করে না, যা তাদের অবাক করে যারা ভাবেন ক্রেডেনশিয়াল আনা সংযোগ ঠিক করে দেবে। সচেতনভাবে আবার ফেচ করুন এবং তারপর আবার URL পড়ুন।

URL আবার না পড়ে ফ্ল্যাগ বদলানোই সেই উপায় যেখানে একটি ল্যাপটপ দুই ক্লাস্টারের ক্রেডেনশিয়াল আর একটি বিভ্রান্তিকর ত্রুটি নিয়ে পড়ে থাকে।

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

পরীক্ষা 3: সেই এন্ডপয়েন্ট পর্যন্ত পথ প্রমাণ করুন

URL যদি অভ্যন্তরীণ IP হয়, তবে ক্লায়েন্ট যে নেটওয়ার্কে সত্যিই বসে আছে সেখান থেকে রুট, অনুমোদিত সোর্স রেঞ্জ এবং ক্লাস্টারের আঞ্চলিক বা গ্লোবাল অ্যাক্সেস সেটিং যাচাই করুন। কন্ট্রোল-প্লেন রেঞ্জ আর নোড সাবনেট একই গন্তব্য নয়, তাই নোড পর্যন্ত কাজ করা রুট এন্ডপয়েন্ট সম্পর্কে কিছুই প্রমাণ করে না। DNS-ভিত্তিক অ্যাক্সেসের পথ হলো নথিভুক্ত Private Google Access ব্যবস্থাসহ Google API সংযোগ, ওয়ার্কার সাবনেটে রুট নয়। kubectl-কে দোষ দেওয়ার আগে সাধারণ TCP সংযোগ দিয়ে এন্ডপয়েন্ট পরীক্ষা করুন।

টাইমআউট পথের সমস্যা। 403 নীতির সমস্যা। এদের সমাধান এক নয়।

পরীক্ষা 4: লগ ও exec-কে API কল থেকে আলাদা করুন

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

VPN টিকিট আবার খোলার আগে ত্রুটির শ্রেণি পড়ুন, কারণ দুটি শ্রেণি আলাদা জায়গায় থাকে।

পরীক্ষা 5: পরের ব্যক্তির জন্য তিনটি পর্যবেক্ষণ রাখুন

নির্বাচিত API URL, একটি অনুমোদিত API অনুরোধ কাজ করে কি না, এবং ঠিক কোন পরবর্তী কাজটি ব্যর্থ হয় তা ত্রুটির লেখাসহ লিখে রাখুন। ওই তিনটি লাইন এন্ডপয়েন্ট নির্বাচনকে নোড অ্যাক্সেস থেকে আলাদা করে, আর একটি সম্পূর্ণ ভালো VPN রুটকে এমন অনুরোধের দায় থেকে বাঁচায় যা এটি কখনো বহন করেনি।

পরের ইঞ্জিনিয়ার জিজ্ঞাস করবেন টানেলটি ভাঙা কি না। আপনার নোটেরই ইতিমধ্যে তার উত্তর থাকা উচিত।