Ubuntu पर kubelet port 10250 error कैसे ठीक करें

Port 10250 क्या है

Port 10250, kubelet API है, और इससे संबंधित हर error दो विपरीत समस्याओं में से एक होती है। या तो कोई अन्य प्रक्रिया पहले से ही इस port का उपयोग कर रही है, जिसके कारण kubeadm init चलने से मना कर देता है। या फिर कोई भी इस port तक पहुँच नहीं पा रहा है, जिससे kubectl logs और kubectl exec ऐसे node पर विफल हो जाते हैं जो अन्यथा पूरी तरह से ठीक दिखता है।

kubelet वह agent है जिसे Kubernetes हर node पर चलाता है। यह containers को start करता है और उनकी स्थिति control plane को रिपोर्ट करता है। यह TCP 10250 पर 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 वाले अनुरोध का उत्तर आपके containers के अंदर shell देने के बजाय Unauthorized के रूप में मिलता है। इस विवरण को याद रखें, क्योंकि यह साबित करने का सबसे तेज़ तरीका भी है कि port तक पहुँचा जा सकता है। यदि ports आपके लिए नया विषय है, तो Linux पर port वास्तव में क्या है उस मॉडल को कवर करता है जिसे यह गाइड मानकर चलती है।

दोनों विफलता मोड एक ही आवश्यकता से उत्पन्न होते हैं। kubelet के start होने से पहले Port 10250 खाली होना चाहिए, और एक बार चालू हो जाने के बाद इसे control plane से पहुँचा जा सकने योग्य होना चाहिए।

आपको इन दो समस्याओं में से कौन सी है

इन कमांड्स को संबंधित नोड पर चलाएं। नीचे दी गई प्रत्येक कमांड वह है जिसे आप स्वयं अपने सर्वर पर चलाते हैं।

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

ss -lntp प्रत्येक प्रक्रिया के पीछे के listening TCP sockets की सूची दिखाता है। -l का अर्थ है listening, -n पोर्ट्स को numeric रखता है, -t इसे TCP तक सीमित करता है, -p स्वामित्व वाली प्रक्रिया को दिखाता है। उस अंतिम फ्लैग के लिए root की आवश्यकता होती है, अन्यथा process कॉलम खाली आता है और आपको कोई जानकारी नहीं मिलती।

users:(("kubelet",pid=1043,fd=23)) पर समाप्त होने वाली एक लाइन का अर्थ है कि kubelet चल रहा है और पोर्ट को होल्ड किए हुए है। यदि आप पोर्ट के खाली होने की उम्मीद कर रहे थे, तो यही आपका उत्तर है। यदि ss कुछ भी प्रिंट नहीं करता है और control plane अभी भी इस नोड तक नहीं पहुँच पा रहा है, तो अभी तक कोई firewall शामिल नहीं है, क्योंकि कोई भी पोर्ट पर सेवा नहीं दे रहा है। किसी भी नियम को छूने से पहले पता करें कि kubelet डाउन क्यों है।

systemctl status kubelet तस्वीर का दूसरा हिस्सा देता है। कुछ मिनट पहले के start time के साथ active (running) सामान्य है। आपके द्वारा kubeadm init या kubeadm join चलाने से पहले हर कुछ सेकंड में kubelet का रीस्टार्ट होना भी सामान्य है: packaged unit इंस्टॉल के समय शुरू होता है, कोई config नहीं पाता है, और बंद हो जाता है। Upstream दस्तावेज़ इस crash loop को अपेक्षित व्यवहार के रूप में बताते हैं, जबकि kubelet kubeadm के निर्देश का इंतज़ार करता है। यदि systemd रीस्टार्ट व्यवहार अपरिचित है, तो systemd service types और restart policies कैसे काम करती हैं इस अनुभाग के लिए पृष्ठभूमि है।

kubeadm init चलाते समय port 10250 पहले से उपयोग में क्यों होता है

kubeadm init डिस्क पर कुछ भी लिखने से पहले preflight checks चलाता है। इन जांचों में से एक control plane के लिए आवश्यक प्रत्येक port को bind करने का प्रयास करती है, और जब यह bind विफल हो जाता है, तो यह port 10250 का नाम लेते हुए एक त्रुटि के साथ रुक जाता है। यह कोई बग नहीं है। यह kubeadm का व्यवहार है जो पहले cluster के अवशेषों के ऊपर दूसरा cluster बनाने से इनकार करता है।

व्यावहारिक रूप से इसके चार कारण होते हैं:

• कोई पिछला kubeadm init या kubeadm join जो बीच में ही विफल हो गया हो। kubelet को पहले ही एक config मिल चुका होता है, इसलिए वह चल रहा होता है और port को होल्ड किए रहता है।
• एक kubeadm reset जिसे शुरू तो किया गया लेकिन पूरा नहीं किया गया। reset kubelet को रोक देता है, लेकिन यह unit को disable नहीं करता है, इसलिए अगला reboot listener को वापस ले आता है।
• उसी सर्वर पर k3s या कोई अन्य Kubernetes distribution इंस्टॉल होना। k3s में एक kubelet एम्बेडेड होता है, और वह kubelet भी 10250 को bind करता है।
• apt द्वारा लाया गया और अपनी systemd unit द्वारा शुरू किया गया kubelet पैकेज, ऐसे सर्वर पर जहाँ आपने अभी तक kubeadm नहीं चलाया है।

कुछ भी बदलने से पहले पता लगाएँ कि इनमें से कौन सा कारण है:

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

यदि listener k3s का है, तो रुकें और तय करें कि आप वास्तव में कौन सा cluster चाहते हैं। k3s और kubeadm एक सर्वर साझा नहीं कर सकते, क्योंकि वे समान ports और समान CNI (container network interface) directory का दावा करते हैं। k3s इंस्टॉलर सर्वर नोड पर /usr/local/bin/k3s-uninstall.sh पर और एजेंट नोड पर k3s-agent-uninstall.sh पर एक uninstall script छोड़ता है।

kubelet को kill करने पर port खाली क्यों नहीं होता

sudo pkill kubelet port 10250 को लगभग दस सेकंड के लिए खाली करता है। packaged unit में एक restart policy सेट होती है, इसलिए systemd एक नया kubelet start कर देता है और वह फिर से उसी port को bind कर लेता है। आप स्वयं इस policy को देख सकते हैं:

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

Restart=always के साथ RestartSec=10 वह सेटिंग है जो unit के साथ आती है, और यही कारण है कि kill ऐसा लगता है जैसे काम कर गया, लेकिन फिर वह काम नहीं करता। systemctl stop port को खाली करने का सही तरीका है, क्योंकि जिस unit को आपने stop करने के लिए कहा है, systemd उसे restart करना बंद कर देता है।

आधे cluster को संभालने वाले node पर केवल port का खाली होना पर्याप्त नहीं है। /var/lib/kubelet/config.yaml, /etc/kubernetes/pki के अंतर्गत मौजूद certificates और /etc/kubernetes/manifests में कोई भी static pod manifests अभी भी वहीं रहते हैं। बाद में होने वाले preflight checks इन files के कारण विफल हो जाते हैं, और उन checks को जबरन bypass करने पर आपको ऐसा cluster मिलता है जिसके certificates उसके config से मेल नहीं खाते। इसके बजाय node को उचित तरीके से reset करें।

नोड को पूरी तरह से रीसेट करना

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 का उपयोग करने पर पुष्टि (confirmation) के लिए प्रॉम्प्ट नहीं आता है। रीसेट कमांड init या join द्वारा किए गए परिवर्तनों को वापस लाने का सर्वोत्तम प्रयास करता है। यह स्थानीय फाइलों और कॉन्फ़िगरेशन को हटा देता है, कंट्रोल प्लेन नोड पर स्थानीय etcd मेंबर को हटा देता है, /etc/kubernetes/pki में मौजूद सर्टिफिकेट्स को साफ कर देता है, और kubelet कॉन्फ़िगरेशन तथा मैनिफेस्ट्स को हटा देता है।

दस्तावेज़ीकरण में स्पष्ट रूप से बताया गया है कि रीसेट के बाद क्या शेष रह जाता है, और यही चीजें अक्सर लोगों के लिए समस्या का कारण बनती हैं। यह /etc/cni/net.d को साफ नहीं करता है, इसलिए पुराना CNI प्लगइन कॉन्फ़िगरेशन बना रहता है और आपका नया क्लस्टर उसे पढ़ लेता है। यह उन iptables, nftables या IPVS नियमों को नहीं हटाता है जिन्हें kube-proxy ने होस्ट पर लागू किया था। यह $HOME/.kube को भी नहीं छूता है, इसलिए kubectl उस क्लस्टर से संपर्क करने की कोशिश करता रहता है जो अब मौजूद नहीं है, जिससे ऐसे सर्टिफिकेट एरर आते हैं जो नई समस्या जैसे लगते हैं।

बचे हुए पैकेट नियम सबसे जटिल हिस्सा हैं। टेबल्स को मैन्युअल रूप से फ्लश करने पर ufw द्वारा इंस्टॉल किए गए नियम भी हट जाते हैं, क्योंकि Ubuntu पर ufw उसी बैकएंड का उपयोग करता है। इससे सर्वर तब तक अनफिल्टर्ड रहता है जब तक आप sudo ufw reload नहीं चलाते। जिस नोड को आप वैसे भी रीबिल्ड कर रहे हैं, उसे रीसेट के बाद रीबूट करें। रीबूट करने से kube-proxy द्वारा जोड़े गए रनटाइम नियम साफ हो जाते हैं और यह आधे-अधूरे फ्लश किए गए रूल्सेट को सुलझाने से कम समय लेता है। iptables नियम और nftables नियम एक-दूसरे के आउटपुट में क्यों दिखाई देते हैं इस बात की व्याख्या करता है कि इसके पीछे क्या हो रहा है।

अंतिम ss कमांड को कुछ भी प्रिंट नहीं करना चाहिए। 10250, 6443 या 2379 पर कोई लिसनर न होने का मतलब है कि नोड एक नए kubeadm init के लिए तैयार है।

kubectl logs और kubectl exec port 10250 पर time out क्यों होते हैं

यह पिछली समस्या के विपरीत है, और यह खुद को port की समस्या के रूप में घोषित नहीं करती है। Cluster चालू हो जाता है। Nodes Ready होते हैं। Pods चलते हैं। फिर एक command विफल हो जाती है:

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 ने node पर port 10250 पर TCP connection खोलने का प्रयास किया और कोई उत्तर नहीं मिला। i/o timeout का अर्थ है कि packets को चुपचाप drop कर दिया गया, इसलिए कोई चीज़ उन्हें filter कर रही है: node पर host firewall, या control panel में आपके provider का अलग network firewall। उसी स्थान पर connect: connection refused का अर्थ इसके विपरीत है। Packet पहुँच गया लेकिन कुछ भी listening नहीं था, इसलिए kubelet down है। यह वही दो कारण हैं जिनका वर्णन connection refused बनाम connection timed out में किया गया है, जिसे यहाँ एक अलग port पर पढ़ें।

इस पूरी प्रक्रिया के दौरान Nodes Ready बने रहते हैं क्योंकि node status दूसरी दिशा में जाता है। Kubelet port 6443 पर API server से outbound connect होता है और अपनी heartbeat पोस्ट करता है, और इसके लिए 10250 पर किसी inbound connection की आवश्यकता नहीं होती है। इसलिए, एक blocked 10250 आपको एक ऐसा cluster देता है जो pods को सामान्य रूप से schedule करता है, लेकिन केवल logs, exec, port-forward और metrics पर विफल हो जाता है।

kubectl top node का उत्तर error: Metrics API not available देना वही दोष है जो metrics-server के माध्यम से देखा जाता है, जिसके log में node और port का नाम होता है:

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

किसी भी firewall rule को edit करने से पहले path का परीक्षण करें

इसे control plane node से, worker के address के विरुद्ध चलाएँ:

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 एक connection खोलता है, उसे बंद करता है, और जब port उसे स्वीकार करता है तो succeeded! print करता है। curl वाली line एक बेहतर परीक्षण है, क्योंकि यह सिद्ध करती है कि kubelet सेवा दे रहा है, न कि केवल यह कि port खुला है। यह 401 print करता है। यह एक स्वस्थ परिणाम है: TLS (transport layer security) handshake पूरा हो गया, और फिर kubelet ने एक unauthenticated request को अस्वीकार कर दिया, जो कि उसे करना ही चाहिए। -k certificate की जाँच को छोड़ देता है, जो ठीक है क्योंकि आप path का परीक्षण कर रहे हैं, न कि trust chain का।

timeout पर समाप्त होने वाला लंबा pause यह दर्शाता है कि packets drop किए जा रहे हैं। तुरंत वापस आने वाला curl: (7) Failed to connect यह दर्शाता है कि reachable host पर port बंद है। परीक्षण control plane node से करें, न कि अपने laptop से, क्योंकि यहाँ केवल control plane की machine का access ही मायने रखता है।

Control plane और worker node को किन ports की आवश्यकता होती है

ये वे inbound ports हैं जिन्हें upstream द्वारा सूचीबद्ध किया गया है। Control plane node पर, API server के लिए TCP 6443 को उन सभी के लिए open रखें जो kubectl चलाते हैं। etcd client और peer API के लिए TCP 2379 से 2380 का उपयोग होता है, जिसे API server और स्वयं etcd इस्तेमाल करते हैं। Kubelet API के लिए TCP 10250 का उपयोग होता है, जिसे node और control plane दोनों इस्तेमाल करते हैं। Kube-scheduler के लिए TCP 10259 और kube-controller-manager के लिए TCP 10257 का उपयोग होता है, जिन्हें केवल node ही इस्तेमाल करता है।

Worker node पर, kubelet API के लिए TCP 10250 का उपयोग होता है, जिसे node और control plane दोनों इस्तेमाल करते हैं। Kube-proxy के लिए TCP 10256 का उपयोग होता है, जिसे node और health checks करने वाले load balancers इस्तेमाल करते हैं। NodePort services के लिए TCP और UDP 30000 से 32767 का उपयोग होता है, जो कि default range है और उन सभी के लिए सुलभ है जिन्हें इन services की आवश्यकता है।

आपका CNI plugin इस सूची के अतिरिक्त अपने स्वयं के ports जोड़ता है, जो इसमें शामिल नहीं हैं। VXLAN mode में Flannel और Calico को nodes के बीच UDP 4789 की आवश्यकता होती है। BGP के साथ Calico को TCP 179 की आवश्यकता होती है। अपने plugin के documentation की जाँच करें और इन ports को nodes के बीच open करें, अन्यथा अलग-अलग nodes पर मौजूद pods एक-दूसरे से बात नहीं कर पाएंगे, भले ही इस section के सभी ports open हों।

10250 को इंटरनेट पर expose किए बिना खोलें

kubelet API उस node पर किसी भी container के अंदर एक process शुरू कर सकती है। 10250 port के खुले होने को node पर root access के समान मानें और इसे source address के आधार पर प्रतिबंधित करें। इसे कभी भी कहीं से भी access की अनुमति न दें।

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 को उस network से बदलें जिसे आपके nodes साझा करते हैं। ufw status numbered सक्रिय नियमों को एक index के साथ सूचीबद्ध करता है, ताकि आप sudo ufw delete <number> का उपयोग करके किसी गलत नियम को हटा सकें। VPS के लिए ufw की बुनियादी जानकारी उन नियमों के क्रम को कवर करती है जो यह तय करते हैं कि आपकी कौन सी प्रविष्टियाँ वास्तव में लागू होती हैं।

एक ufw setting अपने आप में Kubernetes को बाधित कर देती है। node से गुजरने वाला Pod traffic forward किया जाता है, स्थानीय रूप से deliver नहीं होता, और ufw डिफ़ॉल्ट रूप से forward किए गए packets को drop कर देता है। /etc/default/ufw में DEFAULT_FORWARD_POLICY="ACCEPT" सेट करें और sudo ufw reload चलाएँ। इसके बिना, port 10250 पूरी तरह खुला हो सकता है और फिर भी nodes के बीच pod-to-pod traffic विफल हो जाएगा।

अपने provider के firewall की भी जाँच करें। अधिकांश VPS panels में एक network-level firewall होता है जो सर्वर के सामने स्थित होता है और ufw status के लिए अदृश्य होता है। यदि packet सर्वर तक पहुँचता ही नहीं है, तो node पर आपके द्वारा जोड़ा गया नियम कोई बदलाव नहीं करेगा।

जब पोर्ट रीचेबल हो और रिक्वेस्ट फिर भी फेल हो जाए

कुछ 10250 फेल्योर हैंग होने के बजाय तुरंत वापस आ जाते हैं, जिसका अर्थ है कि कनेक्शन सफल रहा और रिक्वेस्ट को रिजेक्ट कर दिया गया। metrics-server लॉग में x509: certificate signed by unknown authority का मतलब है कि kubelet एक self-signed सर्टिफिकेट सर्व कर रहा है जिस पर स्क्रैपर भरोसा नहीं करता है। इसके सामान्य समाधान हैं: kubelet सर्विंग सर्टिफिकेट रोटेशन को इनेबल करना ताकि क्लस्टर CA उस पर साइन कर सके और फिर सर्टिफिकेट साइनिंग रिक्वेस्ट को अप्रूव करना, या लैब क्लस्टर पर जोखिम स्वीकार करते हुए metrics-server को --kubelet-insecure-tls के साथ चलाना।

Forbidden युक्त एक मैसेज, जिसके साथ nodes/proxy या nodes/metrics हो, एक RBAC (role based access control) फेल्योर है। कॉलर kubelet तक पहुँच गया, kubelet ने API सर्वर से पूछा कि क्या वह आइडेंटिटी उस सब-रिसोर्स का उपयोग कर सकती है, और जवाब 'नहीं' था। कॉलर के ClusterRole को ठीक करें। कोई भी फायरवॉल बदलाव मदद नहीं करेगा, क्योंकि कुछ भी ब्लॉक नहीं किया गया था।

यदि आपको केवल एक छोटा क्लस्टर चाहिए

यदि आप पहली बार किसी single VPS पर kubeadm सेटअप करते समय इन errors का सामना कर रहे हैं, तो विचार करें कि क्या आपको वास्तव में kubeadm की आवश्यकता है। VPS पर एक single node k3s क्लस्टर आपको एक ही command में एक कार्यशील Kubernetes API प्रदान करता है, जिसमें kubelet, kube-proxy और CNI पहले से ही कॉन्फ़िगर होते हैं। पोर्ट 10250 वहाँ भी मौजूद रहता है और उस पर भी वही नियम लागू होते हैं, लेकिन अब आपको control plane को स्वयं assemble करने की आवश्यकता नहीं है।

FAQ

Kubernetes में port 10250 का उपयोग किस लिए होता है?

यह हर node पर kubelet का authenticated HTTPS API है, चाहे वह control plane हो या worker node। API server इस पर kubectl logs, kubectl exec, kubectl attach और kubectl port-forward के लिए connect करता है, और metrics-server kubectl top प्रदान करने के लिए इस पर /metrics/resource को scrape करता है। Node status के लिए इसका उपयोग नहीं होता, क्योंकि kubelet अपना heartbeat port 6443 पर API server को outbound भेजता है। यही कारण है कि port 10250 ब्लॉक होने पर nodes Ready दिखाते हैं जबकि logs और exec विफल हो जाते हैं।

मैं यह कैसे पता लगाऊं कि port 10250 पर क्या listen कर रहा है?

Node पर sudo ss -lntp | grep 10250 चलाएं। लाइन के अंत में users:((...)) फ़ील्ड process और उसके PID का नाम बताता है। sudo महत्वपूर्ण है, क्योंकि root के बिना process कॉलम खाली रहता है। यदि owner kubelet है, तो sudo systemctl status kubelet --no-pager आपको बताता है कि क्या यह एक healthy kubelet है या लूप में restart हो रहा है। यदि owner k3s है, तो आपके पास एक ही सर्वर पर दो Kubernetes distributions इंस्टॉल हैं और आपको एक को हटाना होगा।

क्या मुझे अपने firewall में port 10250 खोलना होगा?

हाँ, अपने nodes के बीच। Control plane को हर node पर 10250 तक पहुंचना चाहिए, जिसमें स्वयं का node भी शामिल है, अन्यथा logs, exec, port-forward और metrics सभी विफल हो जाएंगे। इसे उस network तक सीमित रखें जिसे आपके nodes साझा करते हैं, उदाहरण के लिए sudo ufw allow from 10.0.0.0/24 to any port 10250 proto tcp। इसे internet के लिए न खोलें: जो कोई भी उस port पर authenticate कर सकता है, वह node पर किसी भी container में process चला सकता है।

केवल एक node पर pods के लिए kubectl logs विफल क्यों होता है?

क्योंकि block प्रति node होता है, और API server उस विशिष्ट node से connect करता है जो pod को host करता है। Error text पढ़ें: इसमें वह node IP address होता है जिस तक पहुंचने का प्रयास किया गया था। फिर control plane node से nc -zv <node-ip> 10250 चलाएं। Timeout उस node के firewall या आपके provider के network firewall की ओर इशारा करता है। connection refused एक ऐसे kubelet की ओर इशारा करता है जो वहां चल नहीं रहा है, इसलिए इसके बजाय उस node पर systemctl status kubelet की जांच करें।