मार्गदर्शिका

क्लस्टर स्थिति का आपदा रिकवरी बैकअप करने की आवश्यकता है।

→उचित TLS प्रमाणपत्रों (`--cacert`, `--cert`, `--key`) और एंडपॉइंट के साथ `etcdctl snapshot save` का उपयोग करें।

क्यों: etcd पूरे क्लस्टर की स्थिति को संग्रहीत करता है। सीधे स्नैपशॉटिंग इसका बैकअप लेने का एक विहित तरीका है। एक kubeadm क्लस्टर में, TLS सक्षम होता है, इसलिए `etcdctl` के प्रमाणित होने के लिए प्रमाणपत्र अनिवार्य हैं।

संदर्भ↗

आपदा रिकवरी बैकअप से क्लस्टर को पुनर्स्थापित करें।

→एक नई डेटा डायरेक्टरी में `etcdctl snapshot restore` का उपयोग करें। फिर, `etcd.yaml` स्टैटिक पॉड मेनिफेस्ट को नई लोकेशन पर उसके `--data-dir` वॉल्यूम माउंट को इंगित करने के लिए अपडेट करें और kubelet को पुनरारंभ करें।

क्यों: पुनर्स्थापित करने से एक नई डेटा डायरेक्टरी बनती है। स्टैटिक पॉड मेनिफेस्ट को इस नए डेटा का उपयोग करने के लिए अपडेट किया जाना चाहिए, अन्यथा etcd पुरानी (या खाली) डेटा डायरेक्टरी के साथ शुरू होगा।

संदर्भ↗

kubeadm-प्रबंधित क्लस्टर के लिए संस्करण अपग्रेड करें।

→1. कंट्रोल प्लेन पर: `kubeadm` अपग्रेड करें, `kubeadm upgrade plan` चलाएं, फिर `kubeadm upgrade apply`। 2. प्रत्येक वर्कर नोड पर: `kubectl drain`, `kubelet` अपग्रेड करें, kubelet सेवा पुनरारंभ करें, `kubectl uncordon`।

क्यों: प्रक्रिया बहु-चरणीय और क्रमिक है। `kubeadm` केवल कंट्रोल प्लेन कंपोनेंट्स को अपग्रेड करता है; `kubelet` को प्रत्येक नोड पर मैन्युअल रूप से अपग्रेड किया जाना चाहिए। नोड्स को ड्रेन करने से रखरखाव से पहले वर्कलोड्स का सुरक्षित निष्कासन सुनिश्चित होता है।

संदर्भ↗

क्लस्टर प्रमाणपत्र समाप्त हो रहे हैं और उन्हें जांचने या नवीनीकृत करने की आवश्यकता है।

→समाप्ति की तारीखें देखने के लिए `kubeadm certs check-expiration` का उपयोग करें। उन्हें नवीनीकृत करने के लिए `kubeadm certs renew all` (या विशिष्ट कंपोनेंट्स के लिए) का उपयोग करें। नवीनीकरण के बाद कंट्रोल प्लेन पॉड्स को पुनरारंभ करें।

क्यों: Kubeadm-जनरेट किए गए प्रमाणपत्रों की वैधता 1 वर्ष की होती है। नवीनीकरण एक सामान्य रखरखाव कार्य है। नए प्रमाणपत्रों को लोड करने के लिए कंट्रोल प्लेन कंपोनेंट्स को पुनरारंभ किया जाना चाहिए।

एक कंट्रोल प्लेन कंपोनेंट (जैसे, API सर्वर) को कॉन्फ़िगर या पुनरारंभ करने की आवश्यकता है।

→`/etc/kubernetes/manifests/` में कंपोनेंट के मेनिफेस्ट को संशोधित करें। नोड पर kubelet स्वचालित रूप से परिवर्तन का पता लगाएगा और पॉड को पुनरारंभ करेगा।

क्यों: kubeadm में कंट्रोल प्लेन कंपोनेंट्स स्टैटिक पॉड्स के रूप में चलते हैं, जिन्हें सीधे kubelet द्वारा प्रबंधित किया जाता है, न कि API सर्वर द्वारा। सभी प्रबंधन निगरानी की गई डायरेक्टरी में मेनिफेस्ट फ़ाइलों के माध्यम से होता है।

उपयोगकर्ताओं या एप्लिकेशनों के लिए एक्सेस नियंत्रण परिभाषित करें।

→नेमस्पेस-स्कोप अनुमतियों के लिए एक `Role` और `RoleBinding` का उपयोग करें। क्लस्टर-व्यापी अनुमतियों के लिए एक `ClusterRole` और `ClusterRoleBinding` का उपयोग करें।

क्यों: यह RBAC में मौलिक अलगाव है। एक Role हमेशा एक नेमस्पेस से जुड़ा होता है, जबकि एक ClusterRole गैर-नेमस्पेस संसाधनों (जैसे नोड्स) या सभी नेमस्पेस में संसाधनों तक पहुंच प्रदान कर सकता है।

संदर्भ↗

एक सर्विस अकाउंट को सभी नेमस्पेस में संसाधनों तक पहुंचने की आवश्यकता है।

→अनुमतियों को परिभाषित करने वाला एक `ClusterRole` बनाएं। उस ClusterRole को विशिष्ट `ServiceAccount` को प्रदान करने के लिए एक `ClusterRoleBinding` बनाएं।

क्यों: भले ही एक ServiceAccount नेम्सपेस्ड हो, एक ClusterRoleBinding इसे क्लस्टर-व्यापी अनुमतियां प्रदान कर सकता है। एक `RoleBinding` केवल RoleBinding के अपने नेमस्पेस के भीतर अनुमतियां प्रदान करेगा।

क्लाउड लोड बैलेंसर के बिना किसी एप्लिकेशन को बाहरी ट्रैफ़िक के लिए उजागर करें।

→`type: NodePort` की एक Service का उपयोग करें। यह सेवा को प्रत्येक नोड के IP एड्रेस पर एक स्टैटिक पोर्ट (डिफ़ॉल्ट रेंज: 30000-32767) पर उजागर करती है।

क्यों: NodePort क्लस्टर में बाहरी ट्रैफ़िक प्राप्त करने का एक सरल तरीका है। यह `type: LoadBalancer` की तुलना में कम खर्चीला और प्लेटफ़ॉर्म-स्वतंत्र है, लेकिन क्लाइंट्स को नोड IP जानने की आवश्यकता होती है।

होस्ट- या पाथ-आधारित रूटिंग के साथ, एक ही IP एड्रेस के तहत कई HTTP/S सेवाओं को उजागर करें।

→एक Ingress Controller (जैसे, NGINX) तैनात करें। `Ingress` संसाधन बनाएं जो होस्ट/पाथ से बैकएंड `Services` तक रूटिंग नियमों को परिभाषित करते हैं।

क्यों: Ingress L7 रूटिंग के लिए मानक Kubernetes संसाधन है। इसे रूटिंग लॉजिक को वास्तव में लागू करने के लिए एक अलग कंट्रोलर की आवश्यकता होती है। यह रूटिंग नियमों को प्रॉक्सी इम्प्लीमेंटेशन से अलग करता है।

डिफ़ॉल्ट रूप से सभी इनग्रेस ट्रैफ़िक को अस्वीकार करके एक नेमस्पेस को सुरक्षित करें।

→एक `NetworkPolicy` बनाएं जो सभी पॉड्स (`podSelector: {}`) का चयन करता है और एक खाली इनग्रेस नियम (`ingress: []`) निर्दिष्ट करता है।

क्यों: एक बार जब एक पॉड किसी भी NetworkPolicy द्वारा चुना जाता है, तो सभी ट्रैफ़िक जो स्पष्ट रूप से अनुमत नहीं है, अस्वीकार कर दिया जाता है। सभी पॉड्स का चयन करने वाली एक नीति जिसमें एक खाली इनग्रेस नियम होता है, प्रभावी रूप से नेमस्पेस के लिए "deny-all" फ़ायरवॉल बनाता है।

संदर्भ↗

एक "frontend" नेमस्पेस में पॉड्स को "backend" नेमस्पेस में पॉड्स तक पहुंचने की अनुमति दें।

→"backend" नेमस्पेस में, एक NetworkPolicy बनाएं। `ingress.from` नियम में, "frontend" `Namespace` संसाधन पर लेबल का मिलान करने के लिए एक `namespaceSelector` का उपयोग करें।

क्यों: `podSelector` केवल नीति के नेमस्पेस के भीतर काम करता है। अन्य नेमस्पेस से ट्रैफ़िक की अनुमति देने के लिए, आपको एक `namespaceSelector` का उपयोग करना होगा। इसके लिए `Namespace` ऑब्जेक्ट्स को ही लेबल करने की आवश्यकता होती है।

एक एप्लिकेशन को क्लस्टर के भीतर किसी अन्य सेवा से कनेक्ट करने की आवश्यकता है।

→सेवा के आंतरिक DNS नाम का उपयोग करें: `<service-name>.<namespace>.svc.cluster.local`। यदि एक ही नेमस्पेस में है, तो `<service-name>` पर्याप्त है।

क्यों: Kubernetes CoreDNS के माध्यम से स्थिर DNS-आधारित सेवा खोज प्रदान करता है। यह एप्लिकेशन को विशिष्ट पॉड IPs से अलग करता है, जो क्षणभंगुर होते हैं।

एक स्टेटफुल एप्लिकेशन (जैसे, एक डेटाबेस प्रतिकृति सेट) को प्रत्येक पॉड के लिए प्रत्यक्ष नेटवर्क पहचान की आवश्यकता होती है।

→`StatefulSet` के लिए एक हेडलेस `Service` (`clusterIP: None`) बनाएं। यह प्रत्येक पॉड के लिए अद्वितीय DNS A रिकॉर्ड प्रदान करता है (जैसे, `pod-0.my-service.my-ns...`)।

क्यों: एक हेडलेस सेवा लोड बैलेंस नहीं करती है। इसके बजाय, यह प्रत्येक पॉड के लिए DNS रिकॉर्ड प्रदान करती है, जिससे क्लाइंट्स विशिष्ट इंस्टेंस से कनेक्ट हो सकते हैं, जो स्टेटफुल सिस्टम में लीडर इलेक्शन या पीयर डिस्कवरी के लिए महत्वपूर्ण है।

एक बाहरी-फेसिंग सेवा को लॉगिंग या IP-आधारित फ़िल्टरिंग के लिए मूल क्लाइंट IP एड्रेस देखने की आवश्यकता है।

→`NodePort` या `LoadBalancer` Service पर `externalTrafficPolicy: Local` सेट करें।

क्यों: डिफ़ॉल्ट `Cluster` नीति SNAT के माध्यम से क्लाइंट IP को अस्पष्ट करती है। `Local` इस अतिरिक्त नेटवर्क हॉप से ​​बचता है, केवल उसी नोड पर पॉड्स को ट्रैफ़िक रूट करता है जिसने ट्रैफ़िक प्राप्त किया, जिससे स्रोत IP संरक्षित रहता है।

प्रदर्शन या उच्च उपलब्धता के लिए पॉड्स को सह-स्थित करें या अलग-अलग फैलाएं।

→अन्य विशिष्ट पॉड्स के समान नोड/ज़ोन पर पॉड्स को शेड्यूल करने के लिए `podAffinity` का उपयोग करें। उन्हें एक साथ शेड्यूल करने से बचने के लिए `podAntiAffinity` का उपयोग करें।

क्यों: यह नोड-स्तर की एफिनिटी की तुलना में अधिक उन्नत शेड्यूलिंग नियंत्रण प्रदान करता है। HA के लिए नोड्स या ज़ोन में सेवा की प्रतिकृतियों को फैलाने के लिए `requiredDuringScheduling...` के साथ एंटी-एफिनिटी महत्वपूर्ण है।

नोड्स को विशिष्ट वर्कलोड्स के लिए समर्पित करें या उन्हें उन पर चलने से रोकें।

→नोड पर एक `taint` लागू करें (जैसे, `gpu=true:NoSchedule`)। उन पॉड्स में एक मिलान `toleration` जोड़ें जिन्हें उस नोड पर चलने की अनुमति होनी चाहिए।

क्यों: Taints पॉड्स को हटाते हैं, जबकि tolerations उन्हें अनुमति देते हैं। यह नोड्स को समर्पित करने का प्राथमिक तंत्र है। `NoExecute` प्रभाव पहले से चल रहे पॉड्स को बाहर निकाल देगा जिनमें toleration नहीं है।

क्लस्टर के प्रत्येक नोड पर एक मॉनिटरिंग या लॉगिंग एजेंट तैनात करें।

→एक `DaemonSet` का उपयोग करें। यह सुनिश्चित करता है कि पॉड की एक कॉपी प्रत्येक नोड पर चलती है जो उसके शेड्यूलिंग मानदंडों से मेल खाती है।

क्यों: DaemonSet इस सटीक उद्देश्य के लिए डिज़ाइन किया गया है। यह स्वचालित रूप से नए नोड्स पर तैनात होता है और नोड-स्तर के पॉड प्रबंधन को संभालता है, जो एक Deployment के साथ मुश्किल होगा।

एक बार का बैच कार्य या एक आवर्ती निर्धारित कार्य चलाएं।

→एक बार पूरा होने वाले कार्य के लिए एक `Job` का उपयोग करें। एक दोहराने वाले शेड्यूल पर Jobs बनाने के लिए एक `CronJob` का उपयोग करें (जैसे, nightly backups)।

क्यों: Jobs सुनिश्चित करते हैं कि पॉड्स निर्दिष्ट संख्या में पूरा होने तक चलते हैं। CronJobs एक उच्च-स्तरीय कंट्रोलर हैं जो एक cron शेड्यूल के आधार पर Jobs का प्रबंधन करते हैं।

बिना किसी डाउनटाइम के एक एप्लिकेशन को एक नए संस्करण में अपडेट करें।

→डिफ़ॉल्ट `RollingUpdate` रणनीति के साथ एक `Deployment` का उपयोग करें। अपडेट वेलोसिटी और उपलब्धता को नियंत्रित करने के लिए `maxSurge` और `maxUnavailable` को कॉन्फ़िगर करें।

क्यों: रोलिंग अपडेट धीरे-धीरे पुराने पॉड्स को नए पॉड्स से बदलते हैं, जिससे सेवा उपलब्ध रहती है। `maxUnavailable` यह सुनिश्चित करता है कि न्यूनतम संख्या में पॉड्स चल रहे हैं, जबकि `maxSurge` रोलआउट को गति देने के लिए वांछित प्रतिकृति संख्या से अधिक बस्टिंग की अनुमति देता है।

सुनिश्चित करें कि पॉड्स को गारंटीकृत संसाधन मिलते हैं और नोड पर अत्यधिक संसाधनों का उपभोग नहीं करते हैं।

→शेड्यूलिंग के लिए न्यूनतम गारंटी देने के लिए `resources.requests` (CPU/मेमोरी) सेट करें। एक कंटेनर को एक निश्चित मात्रा से अधिक होने से रोकने के लिए `resources.limits` सेट करें।

क्यों: अनुरोधों का उपयोग शेड्यूलर द्वारा प्लेसमेंट के लिए किया जाता है और संसाधनों की गारंटी देता है। सीमाएं kubelet और कंटेनर रनटाइम द्वारा लागू की जाती हैं; मेमोरी सीमा से अधिक होने पर OOMKill होता है।

एक स्टेटफुल एप्लिकेशन को तैनात करें जिसे प्रत्येक प्रतिकृति के लिए स्थिर, अद्वितीय नेटवर्क पहचानकर्ता और पर्सिस्टेंट स्टोरेज की आवश्यकता होती है।

→एक `volumeClaimTemplate` के साथ एक `StatefulSet` का उपयोग करें। यह प्रत्येक पॉड के लिए एक अद्वितीय `PersistentVolumeClaim` बनाता है, यह सुनिश्चित करता है कि पुनरारंभ होने पर डेटा को उसी पॉड पहचान से फिर से जोड़ा जाता है।

क्यों: StatefulSets स्थिर पॉड नाम (जैसे, `web-0`, `web-1`) और प्रत्येक के लिए एक अद्वितीय, पर्सिस्टेंट PVC प्रदान करते हैं। यह उन एप्लिकेशनों के लिए आवश्यक है जो स्थिर पहचान और स्टोरेज पर निर्भर करते हैं।

वॉल्यूम को पहले से प्रावधान किए बिना किसी एप्लिकेशन के लिए पर्सिस्टेंट स्टोरेज प्रदान करें।

→एक `StorageClass` बनाएं जो एक स्टोरेज प्रावधानकर्ता को परिभाषित करता है। फिर, एक `PersistentVolumeClaim` (PVC) बनाएं जो उस क्लास से स्टोरेज का अनुरोध करता है। एक `PersistentVolume` (PV) को गतिशील रूप से प्रावधान किया जाएगा।

क्यों: यह एप्लिकेशनों को अंतर्निहित स्टोरेज इंफ्रास्ट्रक्चर से अलग करता है। डेवलपर्स PVCs के माध्यम से स्टोरेज का अनुरोध करते हैं, और क्लस्टर एडमिनिस्ट्रेटर परिभाषित करता है कि StorageClasses के माध्यम से उस स्टोरेज को कैसे प्रावधान किया जाता है।

यह नियंत्रित करें कि किसी पर्सिस्टेंट वॉल्यूम का दावा हटा दिए जाने के बाद क्या होता है।

→PV या StorageClass पर `persistentVolumeReclaimPolicy` सेट करें। `Delete` स्वचालित रूप से अंतर्निहित स्टोरेज को हटा देता है। `Retain` वॉल्यूम और डेटा को बरकरार रखता है, जिसके लिए मैन्युअल सफाई की आवश्यकता होती है।

क्यों: `Retain` उत्पादन डेटा के लिए सबसे सुरक्षित विकल्प है, क्योंकि यह आकस्मिक डेटा हानि को रोकता है। `Delete` क्षणभंगुर या विकास वातावरण के लिए सुविधाजनक है। डिफ़ॉल्ट प्रावधानकर्ता पर निर्भर करता है।

परिभाषित करें कि एक वॉल्यूम को पॉड्स द्वारा कैसे माउंट किया जा सकता है।

→`accessModes` का उपयोग करें: `ReadWriteOnce` (RWO) एकल-नोड रीड-राइट के लिए, `ReadOnlyMany` (ROX) बहु-नोड रीड-ओनली के लिए, `ReadWriteMany` (RWX) बहु-नोड रीड-राइट के लिए।

क्यों: एक्सेस मोड को अंतर्निहित स्टोरेज प्रोवाइडर द्वारा समर्थित होना चाहिए। स्टोरेज क्षमताओं (केवल RWO का समर्थन) के साथ एप्लिकेशन की जरूरतों (जैसे, RWX की आवश्यकता) का बेमेल Pending PVCs का एक सामान्य कारण है।

कॉन्फ़िगरेशन फ़ाइलों या संवेदनशील डेटा को एक पॉड में इंजेक्ट करें।

→एक `ConfigMap` या `Secret` को एक वॉल्यूम के रूप में माउंट करें। डेटा ऑब्जेक्ट में प्रत्येक कुंजी माउंट पाथ में एक फ़ाइल बन जाती है।

क्यों: यह पॉड्स को कॉन्फ़िगरेशन प्रदान करने का मानक तरीका है। यह कॉन्फ़िगरेशन को Kubernetes ऑब्जेक्ट के रूप में प्रबंधित करने और पॉड इमेज से स्वतंत्र रूप से अपडेट करने की अनुमति देता है।

एक एप्लिकेशन को अपने मौजूदा पर्सिस्टेंट वॉल्यूम में अधिक स्टोरेज स्पेस की आवश्यकता है।

→सुनिश्चित करें कि `StorageClass` में `allowVolumeExpansion: true` है। `PVC` को `spec.resources.requests.storage` में एक बड़ा आकार का अनुरोध करने के लिए संपादित करें।

क्यों: वॉल्यूम विस्तार एक ऑप्ट-इन सुविधा है। StorageClass को स्पष्ट रूप से इसकी अनुमति देनी चाहिए, और अंतर्निहित CSI ड्राइवर को इसका समर्थन करना चाहिए। फाइलसिस्टम का आकार बदलने के लिए पॉड को पुनरारंभ करने की आवश्यकता हो सकती है।

एक पॉड `Pending` स्थिति में फंस गया है और शेड्यूल नहीं किया जा रहा है।

→`kubectl describe pod <pod-name>` चलाएं। शेड्यूलर से संदेशों के लिए `Events` अनुभाग की जाँच करें।

क्यों: `describe` कमांड इसके लिए प्राथमिक उपकरण है। यह "Insufficient cpu/memory", "node(s) had taints the pod didn't tolerate", या "didn't match node selector" जैसे कारण दिखाएगा।

एक पॉड `CrashLoopBackOff` स्थिति के साथ बार-बार शुरू और विफल हो रहा है।

→1. क्रैश हुए कंटेनर से लॉग देखने के लिए `kubectl logs <pod-name> --previous`। 2. एग्जिट कोड और कारण की जांच करने के लिए `kubectl describe pod <pod-name>`।

क्यों: `CrashLoopBackOff` का मतलब है कि कंटेनर के अंदर का एप्लिकेशन बाहर निकल रहा है। पिछली इंस्टेंस (`--previous`) से लॉग महत्वपूर्ण हैं, क्योंकि वर्तमान कंटेनर ने अभी तक कुछ भी उपयोगी लॉग नहीं किया होगा। एग्जिट कोड भी त्रुटि के प्रकार को इंगित कर सकता है।

एक पॉड `ImagePullBackOff` या `ErrImagePull` स्थिति के साथ शुरू होने में विफल रहता है।

→`kubectl describe pod <pod-name>` इवेंट संदेश देखने के लिए। इमेज नाम और टैग सही हैं इसकी पुष्टि करें। निजी रजिस्ट्रियों के लिए, सुनिश्चित करें कि एक `imagePullSecrets` कॉन्फ़िगर किया गया है और सीक्रेट वैध है।

क्यों: यह एक रजिस्ट्री या इमेज नाम का मुद्दा है, न कि एप्लिकेशन का मुद्दा। सामान्य कारण टाइपो, गलत टैग, या निजी रजिस्ट्री के साथ प्रमाणीकरण विफलता हैं।

एक नोड की स्थिति `NotReady` है।

→प्रभावित नोड पर SSH करें। `systemctl status kubelet` के साथ kubelet सेवा स्थिति की जाँच करें। `journalctl -u kubelet` के साथ इसके लॉग देखें।

क्यों: `kubelet` नोड स्वास्थ्य रिपोर्टिंग के लिए जिम्मेदार एजेंट है। यदि यह डाउन है या API सर्वर के साथ संवाद नहीं कर सकता है, तो नोड को NotReady चिह्नित किया जाएगा। इसके लॉग देखने के लिए पहली जगह हैं।

एक सेवा मौजूद है, लेकिन ट्रैफ़िक बैकएंड पॉड्स तक नहीं पहुंच रहा है।

→1. `kubectl describe svc <service-name>` और सत्यापित करें कि `Selector` पॉड लेबलों से मेल खाता है। 2. `kubectl get endpoints <service-name>` और सुनिश्चित करें कि यह सही पॉड IPs को सूचीबद्ध करता है। यदि नहीं, तो लेबल बेमेल हैं।

क्यों: एक सेवा और उसके पॉड्स के बीच का लिंक लेबल सेलेक्टर है। यदि सेलेक्टर गलत है या पॉड्स में सही लेबल नहीं हैं, तो Endpoints ऑब्जेक्ट खाली होगा, और सेवा के पास ट्रैफ़िक को रूट करने के लिए कहीं नहीं होगा।

पॉड्स सेवा नामों या बाहरी होस्टनेम को हल करने में असमर्थ हैं।

→1. जांचें कि `kube-system` में CoreDNS पॉड्स चल रहे हैं या नहीं। 2. CoreDNS लॉग की जाँच करें। 3. एक डीबग पॉड (जैसे, `busybox`) चलाएं और क्लस्टर के भीतर से रिज़ॉल्यूशन का परीक्षण करने के लिए `nslookup` का उपयोग करें।

क्यों: DNS एक महत्वपूर्ण क्लस्टर निर्भरता है। विफलताएं आमतौर पर CoreDNS डिप्लॉयमेंट से ही, उसके कॉन्फ़िगरेशन (एक ConfigMap में), या UDP/TCP पोर्ट 53 पर DNS ट्रैफ़िक को ब्लॉक करने वाली नेटवर्क नीतियों से जुड़ी होती हैं।

रखरखाव के लिए एक नोड को ऑफ़लाइन करना होगा।

→सबसे पहले, `kubectl cordon <node-name>` इसे अनशेड्यूलेबल चिह्नित करने के लिए। फिर, सभी उपयोगकर्ता पॉड्स को सुरक्षित रूप से निकालने के लिए `kubectl drain <node-name> --ignore-daemonsets`।

क्यों: `cordon` नए पॉड्स को शेड्यूल होने से रोकता है। `drain` PodDisruptionBudgets का सम्मान करता है और पॉड्स को शालीनता से बाहर निकालता है। `--ignore-daemonsets` की आवश्यकता है क्योंकि DaemonSet पॉड्स को निकाला नहीं जा सकता है।

पहचान करें कि कौन से पॉड्स या नोड्स सबसे अधिक CPU या मेमोरी का उपभोग कर रहे हैं।

→`kubectl top pods` और `kubectl top nodes` का उपयोग करें। इसके लिए `metrics-server` को क्लस्टर में तैनात करने की आवश्यकता है।

क्यों: `kubectl top` संसाधन खपत का एक त्वरित, वास्तविक समय दृश्य प्रदान करता है, जो संसाधन-भूखे एप्लिकेशनों या नोड संसाधन दबाव की पहचान करने के लिए आवश्यक है।

एक पॉड लंबे समय से `Terminating` स्थिति में है और हटाया नहीं जा रहा है।

→`kubectl delete pod <pod-name> --grace-period=0 --force` के साथ पॉड को जबरदस्ती हटा दें।

क्यों: यह तब हो सकता है जब एक फाइनलाइज़र फंस गया हो या kubelet संसाधनों को साफ नहीं कर सकता हो। जबरदस्ती हटाने से पॉड API सर्वर से तुरंत हटा दिया जाता है, लेकिन इसे अंतिम उपाय के रूप में इस्तेमाल किया जाना चाहिए क्योंकि यह नोड पर अनाथ संसाधन छोड़ सकता है।