Ubuntu-তে kubelet port 10250 এর ত্রুটি সমাধান করার উপায়

port 10250 কী

port 10250 হলো kubelet API, এবং এটি সংক্রান্ত প্রতিটি ত্রুটি মূলত দুটি বিপরীত সমস্যার একটি। হয় অন্য কোনো প্রসেস ইতিমধ্যে port-টি দখল করে রেখেছে, যার ফলে kubeadm init চলতে অস্বীকার করছে। অথবা, কোনো কিছুই port-টিতে পৌঁছাতে পারছে না, যার ফলে একটি আপাতদৃষ্টিতে সুস্থ node-এর ক্ষেত্রেও kubectl logs এবং kubectl exec ব্যর্থ হচ্ছে।

kubelet হলো সেই agent যা Kubernetes প্রতিটি node-এ চালায়। এটি container শুরু করে এবং control plane-কে সেগুলোর অবস্থা জানায়। এটি TCP 10250 port-এ listen করে এবং একটি HTTPS API পরিবেশন করে যা control plane কল করে। আপনি যখন kubectl logs, kubectl exec, kubectl attach বা kubectl port-forward কমান্ড চালান, তখন API server এই port-এ একটি connection তৈরি করে। metrics-server একই port-এ /metrics/resource scrape করে, যার মাধ্যমেই kubectl top node কাজ করে।

এই API-টি authenticated। kubeadm anonymous access বন্ধ রাখে এবং kubelet-কে cluster CA (certificate authority)-এর দিকে নির্দেশ করে, তাই credentials ছাড়া কোনো অনুরোধের উত্তরে container-এর ভেতরে shell পাওয়ার পরিবর্তে Unauthorized পাওয়া যায়। এই বিষয়টি মনে রাখবেন, কারণ port-টি reachable কি না তা যাচাই করার এটিই সবচেয়ে দ্রুত উপায়। আপনি যদি Linux-এ port-এর ধারণা নতুন হয়ে থাকেন, তবে Linux-এ port আসলে কী বিষয়টি এই গাইডের মূল ভিত্তি হিসেবে কাজ করবে।

উভয় ব্যর্থতার কারণ একটি সাধারণ প্রয়োজনীয়তা থেকে উদ্ভূত। kubelet শুরু হওয়ার আগে port 10250 অবশ্যই খালি থাকতে হবে এবং একবার চালু হয়ে গেলে control plane থেকে এটি reachable হতে হবে।

আপনার কোন সমস্যাটি হচ্ছে

সংশ্লিষ্ট নোডে নিচের কমান্ডগুলো চালান। নিচে দেওয়া প্রতিটি কমান্ড আপনাকে আপনার নিজের সার্ভারে নিজে চালাতে হবে।

sudo ss -lntp | grep 10250
sudo systemctl status kubelet --no-pager

ss -lntp কমান্ডটি প্রতিটি প্রসেসের পেছনে থাকা লিসেনিং TCP সকেটগুলোর তালিকা দেখায়। -l মানে লিসেনিং, -n পোর্টগুলোকে সংখ্যায় রাখে, -t শুধুমাত্র TCP-তে সীমাবদ্ধ রাখে, এবং -p মালিকানাধীন প্রসেসটি দেখায়। শেষ ফ্ল্যাগটির জন্য root প্রিভিলেজ প্রয়োজন, অন্যথায় প্রসেস কলামটি খালি আসবে এবং আপনি কোনো তথ্য পাবেন না।

users:(("kubelet",pid=1043,fd=23)) দিয়ে শেষ হওয়া একটি লাইন মানে হলো kubelet চলছে এবং পোর্টটি দখল করে আছে। যদি আপনি আশা করেন যে পোর্টটি খালি থাকবে, তবে এটিই আপনার উত্তর। যদি ss কিছুই প্রিন্ট না করে এবং কন্ট্রোল প্লেন তবুও এই নোডে পৌঁছাতে না পারে, তবে এর মানে কোনো ফায়ারওয়াল সমস্যা নেই, কারণ পোর্টটিতে কিছুই সার্ভিস দিচ্ছে না। কোনো রুল পরিবর্তন করার আগে kubelet কেন বন্ধ আছে তা খুঁজে বের করুন।

systemctl status kubelet চিত্রটির অন্য অর্ধেক তুলে ধরে। কয়েক মিনিট আগের স্টার্ট টাইমসহ active (running) স্বাভাবিক। kubeadm init বা kubeadm join চালানোর আগে প্রতি কয়েক সেকেন্ডে kubelet রিস্টার্ট হওয়াও স্বাভাবিক: প্যাকেজড ইউনিটটি ইন্সটলের সময় চালু হয়, কোনো কনফিগারেশন না পেয়ে বন্ধ হয়ে যায়। আপস্ট্রিম ডকুমেন্টেশন অনুযায়ী, kubeadm-এর নির্দেশনার অপেক্ষায় থাকা অবস্থায় kubelet-এর এই ক্র্যাশ লুপ একটি প্রত্যাশিত আচরণ। যদি systemd রিস্টার্ট আচরণ আপনার কাছে অপরিচিত মনে হয়, তবে systemd service types and restart policies work এই অংশটি আপনার জন্য প্রয়োজনীয় ব্যাকগ্রাউন্ড প্রদান করবে।

kubeadm init চালানোর সময় কেন port 10250 ইতিমধ্যে ব্যবহৃত দেখাচ্ছে

kubeadm init কোনো কিছু ডিস্কে লেখার আগেই প্রি-ফ্লাইট চেক (preflight checks) সম্পন্ন করে। এই চেকগুলোর একটি হলো কন্ট্রোল প্লেনের প্রয়োজনীয় প্রতিটি পোর্টে বাইন্ড (bind) করার চেষ্টা করা, এবং এই বাইন্ড প্রক্রিয়া ব্যর্থ হলে এটি port 10250-এর নাম উল্লেখ করে একটি এরর মেসেজ দেয়। এটি কোনো বাগ নয়। বরং এটি kubeadm-এর একটি সুরক্ষা ব্যবস্থা, যা প্রথম ক্লাস্টারের অবশিষ্টাংশের ওপর দ্বিতীয় কোনো ক্লাস্টার তৈরি হতে বাধা দেয়।

বাস্তব ক্ষেত্রে চারটি কারণে এটি ঘটে:

• পূর্ববর্তী কোনো kubeadm init বা kubeadm join যা মাঝপথে ব্যর্থ হয়েছে। kubelet ইতিমধ্যে কনফিগারেশন পেয়ে গেছে, তাই এটি চালু আছে এবং পোর্টটি দখল করে রেখেছে।
• একটি kubeadm reset যা শুরু করা হয়েছিল কিন্তু শেষ হয়নি। reset কমান্ড kubelet বন্ধ করে দেয়, কিন্তু এটি unit-কে ডিজেবল করে না, তাই পরবর্তী রিবুটের সময় লিসেনারটি আবার চালু হয়ে যায়।
• একই সার্ভারে k3s বা অন্য কোনো Kubernetes ডিস্ট্রিবিউশন ইনস্টল করা আছে। k3s-এর সাথে একটি kubelet এমবেড করা থাকে এবং সেই kubelet-ও 10250 পোর্টটি বাইন্ড করে রাখে।
• kubelet প্যাকেজটি apt-এর মাধ্যমে ইনস্টল হয়েছে এবং নিজস্ব systemd unit দ্বারা চালু হয়েছে, এমন একটি সার্ভারে যেখানে আপনি এখনো kubeadm চালাননি।

কোনো কিছু পরিবর্তন করার আগে নিশ্চিত হয়ে নিন সমস্যাটি ঠিক কোথায়:

sudo ss -lntp 'sport = :10250'
systemctl list-units --type=service --state=running | grep -Ei 'kubelet|k3s|k0s'

যদি লিসেনারটি k3s-এর হয়, তবে থামুন এবং সিদ্ধান্ত নিন আপনি আসলে কোন ক্লাস্টারটি রাখতে চান। k3s এবং kubeadm একই সার্ভারে চলতে পারে না, কারণ তারা একই পোর্ট এবং একই CNI (container network interface) ডিরেক্টরি দাবি করে। k3s ইনস্টলার সার্ভার নোডে /usr/local/bin/k3s-uninstall.sh এবং এজেন্ট নোডে k3s-agent-uninstall.sh-এ একটি আনইনস্টল স্ক্রিপ্ট রেখে দেয়।

kubelet বন্ধ করার পরেও কেন পোর্টটি মুক্ত হয় না

sudo pkill kubelet কমান্ডটি প্রায় দশ সেকেন্ডের জন্য 10250 পোর্টটি মুক্ত করে। প্যাকেজ করা ইউনিটটিতে একটি রিস্টার্ট পলিসি সেট করা থাকে, তাই systemd একটি নতুন kubelet চালু করে এবং এটি পুনরায় একই পোর্টে বাইন্ড হয়। আপনি নিজেই এই পলিসিটি দেখতে পারেন:

systemctl show kubelet -p Restart -p RestartSec
sudo systemctl stop kubelet
sudo ss -lntp | grep 10250

Restart=always এর সাথে RestartSec=10 হলো সেই কনফিগারেশন যা ইউনিটের সাথে আসে, আর ঠিক এই কারণেই kill দেখে মনে হয় যে এটি কাজ করেছে, কিন্তু আসলে তা করে না। systemctl stop হলো পোর্টটি মুক্ত করার সঠিক উপায়, কারণ আপনি যখন systemd-কে কোনো ইউনিট বন্ধ করতে বলেন, তখন এটি আর সেটিকে রিস্টার্ট করে না।

একটি ক্লাস্টারের অর্ধেক ভার বহনকারী নোডে শুধুমাত্র একটি পোর্ট মুক্ত করাই যথেষ্ট নয়। /var/lib/kubelet/config.yaml, /etc/kubernetes/pki এর অধীনে থাকা সার্টিফিকেটসমূহ এবং /etc/kubernetes/manifests এ থাকা যেকোনো স্ট্যাটিক পড ম্যানিফেস্ট তখনও সেখানে থেকে যায়। পরবর্তী প্রি-ফ্লাইট চেকগুলো এই ফাইলগুলোর কারণে বাধাগ্রস্ত হয় এবং চেকগুলো জোরপূর্বক এড়িয়ে গেলে আপনি এমন একটি ক্লাস্টার পাবেন যার সার্টিফিকেটগুলো এর কনফিগারেশনের সাথে মেলে না। এর পরিবর্তে নোডটিকে সঠিকভাবে রিসেট করুন।

নোডটি সঠিকভাবে রিসেট করুন

sudo kubeadm reset -f
sudo rm -rf /etc/cni/net.d
rm -rf $HOME/.kube
sudo systemctl stop kubelet
sudo ss -lntp | grep -E '10250|6443|2379'

-f ফ্ল্যাগটি নিশ্চিতকরণ প্রম্পট এড়িয়ে যায়। রিসেট করার সময় init বা join যা করেছিল, তা ফিরিয়ে আনার সর্বোচ্চ চেষ্টা করা হয়। এটি লোকাল ফাইল এবং কনফিগারেশন মুছে ফেলে, কন্ট্রোল প্লেন নোড থেকে লোকাল etcd মেম্বার সরিয়ে দেয়, /etc/kubernetes/pki-এ থাকা সার্টিফিকেটগুলো পরিষ্কার করে এবং kubelet কনফিগারেশন ও ম্যানিফেস্টগুলো মুছে ফেলে।

রিসেট করার পর কী কী অবশিষ্ট থাকে, তা ডকুমেন্টেশনে স্পষ্টভাবে উল্লেখ করা আছে এবং প্রতিটি বিষয়ই ব্যবহারকারীদের বিভ্রান্ত করতে পারে। এটি /etc/cni/net.d পরিষ্কার করে না, তাই পুরনো CNI প্লাগইন কনফিগারেশন থেকে যায় এবং আপনার নতুন ক্লাস্টার সেটিই পড়ে। এটি kube-proxy হোস্টের জন্য যে iptables, nftables বা IPVS রুল প্রয়োগ করেছিল, তা পরিষ্কার করে না। এটি $HOME/.kube স্পর্শ করে না, তাই kubectl এমন একটি ক্লাস্টারের সাথে যোগাযোগ চালিয়ে যায় যা আর নেই এবং সার্টিফিকেট এরর দেখায়, যা দেখে মনে হতে পারে এটি নতুন কোনো সমস্যা।

অবশিষ্ট প্যাকেট রুলগুলো একটি জটিল বিষয়। ম্যানুয়ালি টেবিল ফ্লাশ করলে ufw দ্বারা ইনস্টল করা রুলগুলোও মুছে যায়, কারণ Ubuntu-তে ufw একই ব্যাকএন্ড ব্যবহার করে। এর ফলে আপনি sudo ufw reload না চালানো পর্যন্ত সার্ভারটি আনফিল্টারড অবস্থায় থাকে। যে নোডটি আপনি পুনরায় তৈরি করছেন, সেটিতে রিসেট করার পর রিবুট করুন। একটি রিবুট kube-proxy দ্বারা যুক্ত রানটাইম রুলগুলো পরিষ্কার করে দেয় এবং অর্ধেক ফ্লাশ হওয়া রুলসেট ঠিক করার চেয়ে এতে সময় কম লাগে। কেন iptables রুল এবং nftables রুল একে অপরের আউটপুটে দেখা যায় বিষয়টি এর পেছনের কারণ ব্যাখ্যা করে।

শেষ ss কমান্ডটি কোনো আউটপুট দেখাবে না। 10250, 6443 বা 2379 পোর্টে কোনো লিসেনার না থাকা মানে হলো নোডটি নতুন একটি kubeadm init-এর জন্য প্রস্তুত।

কেন kubectl logs এবং kubectl exec কমান্ড 10250 পোর্টে টাইম-আউট হয়

এটি আগের সমস্যার বিপরীত একটি অভিযোগ, এবং এটি সরাসরি পোর্ট সমস্যা হিসেবে ধরা দেয় না। ক্লাস্টার সচল হয়। নোডগুলো Ready অবস্থায় থাকে। পডগুলো চলে। কিন্তু একটি কমান্ড ব্যর্থ হয়:

Error from server: Get "https://10.0.0.12:10250/containerLogs/default/web-0/web": dial tcp 10.0.0.12:10250: i/o timeout

বার্তাটি শেষ থেকে পড়ুন। API server নোডের 10250 পোর্টে একটি TCP সংযোগ খোলার চেষ্টা করেছে কিন্তু কোনো উত্তর পায়নি। i/o timeout মানে হলো প্যাকেটগুলো নীরবে ড্রপ করা হয়েছে, অর্থাৎ কোনো কিছু সেগুলোকে ফিল্টার করছে: নোডের হোস্ট ফায়ারওয়াল অথবা কন্ট্রোল প্যানেলে আপনার প্রোভাইডারের আলাদা নেটওয়ার্ক ফায়ারওয়াল। একই স্থানে connect: connection refused থাকার অর্থ ঠিক তার বিপরীত। প্যাকেট পৌঁছেছে কিন্তু সেখানে শোনার মতো কেউ নেই, অর্থাৎ kubelet বন্ধ আছে। এটি connection refused versus connection timed out-এ বর্ণিত কারণ দুটির মতোই, যা এখানে ভিন্ন একটি পোর্টে ঘটছে।

এই পুরো সময় নোডগুলো Ready অবস্থায় থাকে কারণ নোডের স্ট্যাটাস উল্টো পথে যায়। kubelet 6443 পোর্টে API server-এর সাথে আউটবাউন্ড সংযোগ স্থাপন করে এবং নিজের হার্টবিট পাঠায়, যার জন্য 10250 পোর্টে কোনো ইনবাউন্ড সংযোগের প্রয়োজন হয় না। তাই 10250 পোর্ট ব্লক থাকলে আপনার ক্লাস্টার স্বাভাবিকভাবে পড শিডিউল করবে, কিন্তু logs, exec, port-forward এবং metrics-এর ক্ষেত্রে ব্যর্থ হবে।

kubectl top node-এর উত্তর হিসেবে error: Metrics API not available-তে একই ত্রুটি metrics-server-এর মাধ্যমে দেখা যায়, যার লগে নোড এবং পোর্টের নাম উল্লেখ থাকে:

unable to fully scrape metrics from node worker-1: unable to fetch metrics from node worker-1: Get "https://10.0.0.12:10250/metrics/resource": dial tcp 10.0.0.12:10250: i/o timeout

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

একটি control plane নোড থেকে worker-এর ঠিকানার বিপরীতে এটি চালান:

nc -zv 10.0.0.12 10250
curl -sk -o /dev/null -w '%{http_code}\n' https://10.0.0.12:10250/healthz

nc -z একটি সংযোগ খোলে, তা বন্ধ করে এবং পোর্টটি সংযোগ গ্রহণ করলে succeeded! প্রিন্ট করে। curl লাইনটি আরও ভালো পরীক্ষা, কারণ এটি প্রমাণ করে যে kubelet কাজ করছে, শুধু পোর্ট খোলা আছে তা নয়। এটি 401 প্রিন্ট করে। এটি একটি সঠিক ফলাফল: TLS (transport layer security) হ্যান্ডশেক সম্পন্ন হয়েছে, এবং kubelet একটি অননুমোদিত অনুরোধ প্রত্যাখ্যান করেছে, যা তার করার কথা। -k সার্টিফিকেট চেকিং এড়িয়ে যায়, যা ঠিক আছে কারণ আপনি পাথ পরীক্ষা করছেন, ট্রাস্ট চেইন নয়।

টাইমআউটে শেষ হওয়া দীর্ঘ বিরতির অর্থ হলো প্যাকেট ড্রপ করা হচ্ছে। curl: (7) Failed to connect তাৎক্ষণিকভাবে ফিরে আসার অর্থ হলো একটি reachable হোস্টে পোর্টটি বন্ধ আছে। আপনার ল্যাপটপ থেকে নয়, বরং control plane নোড থেকে পরীক্ষা করুন, কারণ এখানে শুধুমাত্র control plane-এর অ্যাক্সেসই গুরুত্বপূর্ণ।

কন্ট্রোল প্লেন এবং ওয়ার্কার নোডের জন্য প্রয়োজনীয় পোর্টসমূহ

আপস্ট্রিম ডকুমেন্টেশন অনুযায়ী ইনবাউন্ড পোর্টগুলো নিচে দেওয়া হলো। একটি কন্ট্রোল প্লেন নোডে, API server-এর জন্য TCP 6443 পোর্টটি উন্মুক্ত রাখতে হবে, যা kubectl-এ চলমান যেকোনো কিছুর জন্য অ্যাক্সেসযোগ্য। etcd client এবং peer API-এর জন্য TCP 2379 থেকে 2380 পোর্ট প্রয়োজন, যা API server এবং স্বয়ং etcd ব্যবহার করে। kubelet API-এর জন্য TCP 10250 পোর্টটি নোড এবং কন্ট্রোল প্লেন উভয়ের জন্যই ব্যবহৃত হয়। kube-scheduler-এর জন্য TCP 10259 এবং kube-controller-manager-এর জন্য TCP 10257 পোর্ট প্রয়োজন, যা শুধুমাত্র নোড নিজেই ব্যবহার করে।

একটি ওয়ার্কার নোডে, kubelet API-এর জন্য TCP 10250 পোর্টটি নোড এবং কন্ট্রোল প্লেন উভয়ের জন্যই ব্যবহৃত হয়। kube-proxy-এর জন্য TCP 10256 পোর্টটি নোড এবং হেলথ চেক পরিচালনাকারী লোড ব্যালেন্সারগুলো ব্যবহার করে। NodePort সার্ভিসগুলোর জন্য TCP এবং UDP 30000 থেকে 32767 পোর্ট রেঞ্জটি ডিফল্ট হিসেবে থাকে এবং এই সার্ভিসগুলো যাদের প্রয়োজন তারা এটি অ্যাক্সেস করতে পারে।

আপনার ব্যবহৃত CNI প্লাগইন এই তালিকার বাইরেও নিজস্ব কিছু পোর্ট যোগ করতে পারে। Flannel এবং Calico-এর VXLAN মোডের জন্য নোডগুলোর মধ্যে UDP 4789 পোর্ট প্রয়োজন। BGP সহ Calico-এর জন্য TCP 179 পোর্ট প্রয়োজন। আপনার প্লাগইনের ডকুমেন্টেশন যাচাই করুন এবং নোডগুলোর মধ্যে এই পোর্টগুলো উন্মুক্ত রাখুন, অন্যথায় এই সেকশনের সব পোর্ট খোলা থাকলেও ভিন্ন ভিন্ন নোডে থাকা পডগুলো একে অপরের সাথে যোগাযোগ করতে পারবে না।

ইন্টারনেটে উন্মুক্ত না করে 10250 পোর্টটি ওপেন করা

kubelet API নোডের যেকোনো কন্টেইনারের ভেতরে প্রসেস শুরু করতে পারে। 10250 পোর্ট খোলা থাকাকে নোডের রুট অ্যাক্সেস হিসেবে বিবেচনা করুন এবং সোর্স অ্যাড্রেস অনুযায়ী এটিকে সীমাবদ্ধ করুন। কখনোই এটিকে যেকোনো জায়গা থেকে অ্যাক্সেস করার অনুমতি দেবেন না।

sudo ufw allow from 10.0.0.0/24 to any port 10250 proto tcp comment 'kubelet API'
sudo ufw allow from 10.0.0.0/24 to any port 10256 proto tcp comment 'kube-proxy'
sudo ufw status numbered

10.0.0.0/24-কে আপনার নোডগুলো যে নেটওয়ার্ক শেয়ার করে তা দিয়ে প্রতিস্থাপন করুন। ufw status numbered কমান্ডটি ইনডেক্সসহ সক্রিয় রুলগুলোর তালিকা দেখায়, যাতে আপনি sudo ufw delete <number> ব্যবহার করে ভুল রুল মুছে ফেলতে পারেন। VPS-এর জন্য ufw-এর মৌলিক বিষয়সমূহ অংশে রুলগুলোর ক্রম নিয়ে আলোচনা করা হয়েছে, যা নির্ধারণ করে কোন এন্ট্রিটি কার্যকর হবে।

ufw-এর একটি সেটিং নিজে থেকেই Kubernetes-কে অকার্যকর করে দেয়। নোড অতিক্রমকারী পড ট্রাফিক ফরওয়ার্ড করা হয়, লোকালি ডেলিভারি করা হয় না, আর ufw ডিফল্টভাবে ফরওয়ার্ড করা প্যাকেট ড্রপ করে। /etc/default/ufw ফাইলে DEFAULT_FORWARD_POLICY="ACCEPT" সেট করুন এবং sudo ufw reload কমান্ডটি চালান। এটি না করলে, 10250 পোর্ট পুরোপুরি খোলা থাকলেও নোডগুলোর মধ্যে পড টু পড ট্রাফিক ব্যর্থ হবে।

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

যখন পোর্টটি রিচেবল থাকে কিন্তু অনুরোধটি ব্যর্থ হয়

কিছু 10250 (10250) ব্যর্থতা হ্যাং না হয়ে তাৎক্ষণিকভাবে ফিরে আসে, যার অর্থ সংযোগ সফল হয়েছে কিন্তু অনুরোধটি প্রত্যাখ্যাত হয়েছে। metrics-server লগে x509: certificate signed by unknown authority থাকার অর্থ হলো kubelet একটি সেলফ-সাইনড সার্টিফিকেট ব্যবহার করছে যা স্ক্র্যাপার বিশ্বাস করে না। এর সাধারণ সমাধান হলো kubelet সার্ভিং সার্টিফিকেট রোটেশন চালু করা যাতে ক্লাস্টার CA এটি সাইন করতে পারে এবং তারপর সার্টিফিকেট সাইনিং রিকোয়েস্ট অনুমোদন করা, অথবা ল্যাব ক্লাস্টারের ক্ষেত্রে ঝুঁকি মেনে নিয়ে metrics-server-কে --kubelet-insecure-tls ফ্ল্যাগ দিয়ে চালানো।

Forbidden সম্বলিত কোনো মেসেজের সাথে nodes/proxy বা nodes/metrics থাকলে তা একটি RBAC (role based access control) ব্যর্থতা। কলার kubelet-এ পৌঁছাতে পেরেছে, kubelet তখন API সার্ভারকে জিজ্ঞাসা করেছে যে ওই আইডেন্টিটি সাব-রিসোর্সটি ব্যবহার করতে পারবে কি না, এবং উত্তরটি ছিল না। কলারের ClusterRole ঠিক করুন। ফায়ারওয়াল পরিবর্তন করে কোনো লাভ হবে না, কারণ এখানে কোনো কিছুই ব্লক করা হয়নি।

যদি আপনি কেবল একটি ছোট ক্লাস্টার চান

আপনি যদি প্রথমবারের মতো একটি VPS-এ kubeadm সেটআপ করার সময় এই ত্রুটিগুলোর সম্মুখীন হন, তবে ভেবে দেখুন আপনার আদৌ kubeadm-এর প্রয়োজন আছে কি না। একটি VPS-এ সিঙ্গেল নোড k3s ক্লাস্টার আপনাকে একটি কমান্ডের মাধ্যমেই কার্যকর Kubernetes API প্রদান করবে, যেখানে kubelet, kube-proxy এবং CNI আগে থেকেই কনফিগার করা থাকে। সেখানেও 10250 পোর্টটি বিদ্যমান এবং এতে একই নিয়ম প্রযোজ্য, কিন্তু আপনাকে আর নিজে থেকে কন্ট্রোল প্লেন তৈরি করতে হবে না।

FAQ

Kubernetes-এ port 10250 কী কাজে ব্যবহৃত হয়?

এটি প্রতিটি node-এ (control plane এবং worker উভয় ক্ষেত্রেই) kubelet-এর authenticated HTTPS API। API server এই port-এর মাধ্যমে kubectl logs, kubectl exec, kubectl attach এবং kubectl port-forward-এর কাজ সম্পন্ন করে এবং metrics-server kubectl top সরবরাহ করার জন্য এতে /metrics/resource scrape করে। Node status-এর জন্য এটি ব্যবহৃত হয় না, কারণ kubelet তার heartbeat port 6443-এর মাধ্যমে API server-এ পাঠায়। এই কারণেই port 10250 ব্লক থাকলে node-এর অবস্থা Ready দেখায় এবং logs ও exec কমান্ড কাজ করে না।

port 10250-এ কী listen করছে তা কীভাবে খুঁজে পাব?

Node-এ sudo ss -lntp | grep 10250 কমান্ডটি চালান। লাইনের শেষে থাকা users:((...)) ফিল্ডটি process-এর নাম এবং এর PID দেখাবে। sudo ব্যবহার করা জরুরি, কারণ root access ছাড়া process কলামটি খালি থাকে। যদি owner kubelet হয়, তবে sudo systemctl status kubelet --no-pager কমান্ডটি আপনাকে জানাবে যে kubelet-টি সঠিকভাবে চলছে নাকি বারবার restart হচ্ছে। যদি owner k3s হয়, তবে বুঝতে হবে একটি সার্ভারে দুটি Kubernetes distribution ইনস্টল করা আছে এবং আপনাকে একটি সরিয়ে ফেলতে হবে।

আমার firewall-এ কি port 10250 খোলা রাখা বাধ্যতামূলক?

হ্যাঁ, আপনার node-গুলোর মধ্যে এটি খোলা রাখতে হবে। Control plane-কে অবশ্যই প্রতিটি node-এর (নিজের node-সহ) 10250 port-এ পৌঁছাতে হবে, অন্যথায় logs, exec, port-forward এবং metrics—সবই ব্যর্থ হবে। এটিকে শুধুমাত্র আপনার node-গুলোর শেয়ার করা network-এর মধ্যে সীমাবদ্ধ রাখুন, উদাহরণস্বরূপ sudo ufw allow from 10.0.0.0/24 to any port 10250 proto tcp। এটিকে ইন্টারনেটের জন্য উন্মুক্ত করবেন না: যে কেউ এই port-এ authenticate করতে পারলে সে node-এর যেকোনো container-এ process চালাতে পারবে।

কেন শুধুমাত্র একটি node-এর pod-গুলোর জন্য kubectl logs ব্যর্থ হয়?

কারণ এই block-টি প্রতি node-এর জন্য আলাদা এবং API server নির্দিষ্ট সেই node-এর সাথেই যোগাযোগ করে যেখানে pod-টি হোস্ট করা আছে। Error message-টি পড়ুন: এতে সেই node-এর IP address থাকে যেখানে সংযোগ করার চেষ্টা করা হয়েছিল। এরপর একটি control plane node থেকে nc -zv <node-ip> 10250 কমান্ডটি চালান। Timeout হলে বুঝতে হবে সেই node-এর firewall অথবা আপনার provider-এর network firewall-এ সমস্যা আছে। connection refused দেখালে বুঝতে হবে সেখানে kubelet চলছে না, তাই সেই node-এ systemctl status kubelet চেক করুন।