minikube ব্যক্তিগত API-তে পৌঁছাচ্ছে না? আগে ড্রাইভার দেখুন
হোস্ট, নোড ও Pod—প্রত্যেকের নিজস্ব রুট ও নিজস্ব resolver আছে। ড্রাইভারের নাম বলুন, একই endpoint তিনটি থেকেই পরীক্ষা করুন, তারপর যে context ব্যর্থ হয়েছে সেটি ঠিক করুন।
একটি ব্যক্তিগত API আপনার ল্যাপটপ থেকে উত্তর দেয় আর minikube-এর ভিতরের Pod সেখানে পৌঁছাতে পারে না। হোস্টে কিছু বদলানোর আগে সক্রিয় প্রোফাইলের পেছনের ড্রাইভারের নাম বলুন, কারণ এই একটি তথ্যই ঠিক করে অনুরোধটি আসলে কোন নেটওয়ার্ক থেকে বেরোয়। তারপর একই endpoint হোস্ট থেকে, নোড থেকে এবং Pod থেকে পরীক্ষা করুন। ওই তিনটির মধ্যে কেবল একটি-ই সেই জিনিস যা ব্যর্থ হয়েছে, আর ভুল অনুমান একটি দুপুর নষ্ট করে।
ধাপ 0: ড্রাইভার ও উৎসের নাম বলুন
minikube-কে জিজ্ঞাসা করুন কোন প্রোফাইল সক্রিয় এবং এটি কীভাবে চলছে। কনটেইনার ড্রাইভার নোডকে আপনার মেশিনের একটি কনটেইনারে রাখে, VM ড্রাইভার এটিকে ভার্চুয়াল মেশিনে রাখে, আর রিমোট ড্রাইভার এটিকে সম্পূর্ণ অন্য জায়গায় রাখে।
minikube profile list
minikube status
kubectl config current-contextএখান থেকে লিখুন অনুরোধ কোথা থেকে আসে। উত্তর ঠিক করে কার resolver এবং কোন রুট গুরুত্বপূর্ণ, আর এটি সবসময় হোস্টের নয়। একই ল্যাপটপে দুটি প্রোফাইল একই URL-এর জন্য সম্পূর্ণ আলাদা আচরণ করতে পারে।
| Context | What has to work |
|---|---|
| Host process | Host resolver and host route to the private destination |
| minikube node | The node's own resolver and its outbound path |
| Pod | Pod DNS through cluster services plus the cluster network path |
ধাপ 1: একই endpoint তিনবার পরীক্ষা করুন
একটি নিরীহ endpoint ব্যবহার করুন এবং তিনটি পরীক্ষায় হোস্টনেম, পোর্ট ও অ্যাড্রেস ফ্যামিলি একই রাখুন। এগুলোর যেকোনোটি রানের মধ্যে বদলালে ফলাফল তুলনাযোগ্য থাকে না।
curl -sS -o /dev/null -w '%{http_code}\n' https://api.corp.example/health
minikube ssh -- curl -sS -o /dev/null -w '%{http_code}\n' https://api.corp.example/health
kubectl run probe --rm -it --image=curlimages/curl --restart=Never -- \
curl -sS -o /dev/null -w '%{http_code}\n' https://api.corp.example/healthনোডের সফল image pull ব্যক্তিগত হোস্টের জন্য নাম সমাধান সম্পর্কে কিছুই প্রমাণ করে না। সফল পাবলিক অনুরোধ আরও কম প্রমাণ করে। ফলাফল context অনুযায়ী আলাদা রাখুন, কারণ তিন সারিতে দেখা প্যাটার্ন একটি রোগনির্ণয় আর একক ব্যর্থতা একটি সূত্র।
হোস্টের সারিও যদি ব্যর্থ হয়, থামুন। আপনার হোস্টের নেটওয়ার্ক সমস্যা আছে আর ক্লাস্টার মনোযোগ সরানোর জিনিস।
ধাপ 2: হোস্টের ক্লাস্টার পর্যন্ত পথ ধরে রাখুন
এমন একটি দ্বিতীয় দিক আছে যা মানুষ ভুলে যায়: হোস্টকে ক্লাস্টারের নিজের API ও সেবাগুলোতে পৌঁছাতে থাকতে হবে। একটি VPN ক্লায়েন্ট এমন রুট বসাতে পারে যা minikube তার নোড নেটওয়ার্ক, সার্ভিস রেঞ্জ ও pod রেঞ্জের জন্য ব্যবহার করা prefixes-এর সঙ্গে প্রতিযোগিতা করে।
এমন হলে উপসর্গ বিভ্রান্তিকর, কারণ টানেল কাজ করে আর kubectl সাড়া দেওয়া বন্ধ করে বা NodePort সংযোগ প্রত্যাখ্যান করে। এটি ক্লাস্টারের ত্রুটি মনে হয় আর আসলে ল্যাপটপের রাউটিং ত্রুটি।
টানেলকে অন্য কিছুর জন্য দোষারোপ করার আগে হোস্টের রাউটিং টেবিলের সঙ্গে minikube-এর রেঞ্জগুলো মিলিয়ে দেখুন। ওভারল্যাপ সাধারণত আরও নির্দিষ্ট একটি রুট হিসেবে দেখা যায় যা ক্লাস্টার নিজের বলে ধরে নেওয়া prefix-এর জন্য টানেল ইন্টারফেসে নির্দেশ করে।
ধাপ 3: VPN বন্ধ না করে ওভারল্যাপ সমাধান করুন
minikube-এর নিজস্ব VPN ও proxy হ্যান্ডবুক এই দ্বন্দ্বগুলো নিয়ে আলোচনা করে এবং তার উদাহরণ রেঞ্জগুলোকে পরীক্ষা করার জিনিস বলে মনে করে, সর্বজনীন তালিকা নয়। এটি আপনার কাছে সত্যিই থাকা প্রোফাইলের সঙ্গে পড়ুন।
যেখানে সত্যিকারের ওভারল্যাপ আছে, সেখানে সমর্থিত উত্তর হলো একটি ন-ওভারল্যাপিং রেঞ্জ বা VPN-এর মালিকের অনুমোদিত ইচ্ছাকৃত স্থানীয় অ্যাক্সেস নীতি। সার্ভিস রেঞ্জ বদলানো pod রেঞ্জ বদলানোর সমান নয়, আর এর কোনোটিই নোড নেটওয়ার্ক বদলানোর সমান নয়।
স্থানীয় ক্লাস্টার চলার জন্য কর্পোরেট টানেল বন্ধ করা কোনো শর্টকাট নয়; এটি একটি নীতি-সিদ্ধান্ত যা অন্য কাউকে নিতে হবে। বাকিরা সবাই বাড়ি যাওয়ার পর চুপচাপ করার বদলে এটি সেই ব্যক্তির কাছে নিন। যদি আগেই করে থাকেন, জিজ্ঞাসা করার আগে ফিরিয়ে দিন।
ধাপ 4: proxy, DNS এবং ব্যর্থতার চারটি রূপ আলাদা করুন
proxy প্রয়োজন হলে কোন context-এর এটি দরকার তা চিহ্নিত করুন। হোস্টে ব্রাউজার সেটিং নোডের ভিতরের প্রক্রিয়া কনফিগার করে না, আর Pod-এর দরকার পরিবেশ চলক বা ক্লাস্টার-স্তরের proxy কনফিগারেশন।
তারপর ব্যর্থতার বর্ণনা না দিয়ে শ্রেণিবদ্ধ করুন। যে নাম সমাধান হয় না তা DNS। যে নাম সমাধান হয় এবং সংযোগ প্রত্যাখ্যান করে তা রাউটিং বা listener। যে সংযোগ তৈরি হয় এবং পরিচয়ে ব্যর্থ হয় তা TLS। ত্রুটির body সহ সফল সংযোগ হলো অ্যাপ্লিকেশন।
এই চারটির প্রত্যেকটি আলাদা সংশোধনের সঙ্গে সম্পর্কিত, আর কেবল একটি VPN নিয়ে। প্রতিটি context-এ আপনি কোনটি দেখেছেন লিখুন, আর পরের ব্যক্তি গল্পের বদলে প্রমাণ উত্তরাধিকারে পাবে।