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

कमांड-लाइन कुंजी-मान युग्मों से एक ConfigMap या जेनेरिक Secret बनाएँ।

→`kubectl create configmap <name> --from-literal=<key>=<value>` या `kubectl create secret generic <name> --from-literal=<key>=<value>` का उपयोग करें।

क्यों: `--from-literal` सीधे कुंजी-मान इनपुट के लिए है। कई कुंजियों के लिए इस फ़्लैग का कई बार उपयोग करें। यह सरल मामलों के लिए YAML फ़ाइल बनाने से तेज़ है।

संदर्भ↗

एक ConfigMap या Secret से सभी कुंजी-मान युग्मों को एक कंटेनर में पर्यावरण चर के रूप में इंजेक्ट करें।

→कंटेनर स्पेसिफिकेशन में, `envFrom` का उपयोग `configMapRef` या `secretRef` के साथ करें। उदाहरण: `envFrom: [{configMapRef: {name: my-config}}]`।

क्यों: `envFrom` एक थोक ऑपरेशन है जो स्रोत से सभी कुंजियों को पर्यावरण चर में मैप करता है। यह प्रत्येक कुंजी को मैन्युअल रूप से सूचीबद्ध करने से बचाता है।

संदर्भ↗

एक ConfigMap या Secret से एक एकल, विशिष्ट मान को पर्यावरण चर के रूप में इंजेक्ट करें।

→`env.valueFrom` का उपयोग करें। उदाहरण: `env: [{name: LOG_LEVEL, valueFrom: {configMapKeyRef: {name: my-config, key: log_level}}}]`।

क्यों: `valueFrom` चयनात्मक इंजेक्शन प्रदान करता है और स्रोत कुंजी को एक अलग पर्यावरण चर नाम पर मैप करने की अनुमति देता है।

एक ConfigMap या Secret को Pod में फ़ाइलों के रूप में माउंट करें, जिससे लाइव अपडेट्स की अनुमति मिलती है।

→`configMap` या `secret` प्रकार का एक `volume` परिभाषित करें। इसे `volumeMounts` का उपयोग करके कंटेनर में माउंट करें। फ़ाइलें कुंजियों के नाम पर होंगी।

क्यों: ConfigMaps/Secrets से माउंट की गई फ़ाइलें स्रोत बदलने पर स्वचालित रूप से अपडेट हो जाती हैं। पर्यावरण चर नहीं होते, जिसके लिए Pod को पुनरारंभ करना पड़ता है।

संदर्भ↗

सुरक्षा सर्वोत्तम प्रथाओं को लागू करें: रूट के रूप में चलने से रोकें, रूट फ़ाइलसिस्टम को केवल-पढ़ने योग्य बनाएं, या एक उपयोगकर्ता ID निर्दिष्ट करें।

→Pod या कंटेनर स्तर पर `securityContext` का उपयोग करें। `runAsNonRoot: true`, `readOnlyRootFilesystem: true`, और/या `runAsUser: <UID>` सेट करें।

क्यों: SecurityContext कंटेनर विशेषाधिकारों पर सूक्ष्म, घोषणात्मक नियंत्रण प्रदान करता है, जो अनुप्रयोगों को मजबूत करने और सुरक्षा नीतियों को पूरा करने के लिए आवश्यक है।

संदर्भ↗

एक Pod को Kubernetes API तक पहुँचने के लिए न्यूनतम अनुमतियाँ प्रदान करें।

→1. एक कस्टम `ServiceAccount` बनाएँ। 2. केवल आवश्यक API अनुमतियों (जैसे, पॉड्स सूचीबद्ध करें) के साथ एक `Role` बनाएँ। 3. ServiceAccount और Role को लिंक करने के लिए एक `RoleBinding` बनाएँ। 4. `spec.serviceAccountName` के माध्यम से ServiceAccount को Pod को असाइन करें।

क्यों: न्यूनतम विशेषाधिकार के सिद्धांत का पालन करता है, यदि Pod से समझौता किया जाता है तो हमले की सतह को कम करता है।

एक ServiceAccount टोकन को ऐसे Pod में स्वचालित रूप से माउंट होने से रोकें जिसे API पहुँच की आवश्यकता नहीं है।

→Pod स्पेसिफिकेशन में या ServiceAccount पर `automountServiceAccountToken: false` सेट करें।

क्यों: उन कंटेनरों को API क्रेडेंशियल प्रदान न करके हमले की सतह को कम करता है जिन्हें उनकी आवश्यकता नहीं होती है।

एक Ingress या अन्य सुरक्षित सेवा के लिए TLS समाप्ति में उपयोग के लिए एक Secret बनाएँ।

→`kubectl create secret tls <secret-name> --cert=<path/to/cert.pem> --key=<path/to/key.pem>` का उपयोग करें।

क्यों: यह सही प्रकार `kubernetes.io/tls` का एक Secret बनाता है जिसमें मानक `tls.crt` और `tls.key` डेटा कुंजियाँ होती हैं जिनकी Ingress नियंत्रकों द्वारा अपेक्षा की जाती है।

Pod मेटाडेटा (जैसे नाम, नेमस्पेस, लेबल, या नोड IP) को एक कंटेनर में उजागर करें।

→मेटाडेटा को पर्यावरण चर या `downwardAPI` वॉल्यूम में फ़ाइलों के रूप में प्रोजेक्ट करने के लिए Downward API का उपयोग करें। उदाहरण: `valueFrom: {fieldRef: {fieldPath: metadata.name}}`।

क्यों: कंटेनरों को Kubernetes API से क्वेरी करने की आवश्यकता के बिना आत्म-जागरूक होने की अनुमति देता है, जिससे कॉन्फ़िगरेशन सरल होता है और RBAC आवश्यकताओं को कम करता है।

संदर्भ↗

एक नेमस्पेस में सभी Pods के लिए डिफ़ॉल्ट CPU/मेमोरी अनुरोध और सीमाएँ सेट करें।

→नेमस्पेस में एक `LimitRange` ऑब्जेक्ट बनाएँ। संसाधनों के लिए `default` और `defaultRequest` मान परिभाषित करें।

क्यों: सुनिश्चित करता है कि सभी Pods में संसाधन बाधाएँ हों, शेड्यूलिंग और स्थिरता में सुधार हो, भले ही डेवलपर्स उन्हें निर्दिष्ट करना भूल जाएँ। ResourceQuota के साथ मिलकर काम करता है।

एक नेमस्पेस में खपत किए जा सकने वाले संसाधनों (CPU, मेमोरी, ऑब्जेक्ट काउंट) की कुल मात्रा को सीमित करें।

→एक `ResourceQuota` ऑब्जेक्ट बनाएँ। `spec.hard` में कठोर सीमाएँ परिभाषित करें, उदाहरण के लिए, `requests.cpu: "4"`, `pods: "10"`।

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

मुख्य एप्लिकेशन शुरू होने से पहले आवश्यक कार्य (जैसे, डेटाबेस का इंतजार करना, माइग्रेशन चलाना, डेटा खींचना) चलाएँ।

→Pod स्पेसिफिकेशन में एक या अधिक `initContainers` परिभाषित करें। वे मुख्य ऐप कंटेनर शुरू होने से पहले अनुक्रमिक रूप से पूर्ण होते हैं।

क्यों: सेटअप लॉजिक को एप्लिकेशन कंटेनर से अलग करता है और गारंटी देता है कि एप्लिकेशन लॉन्च होने से पहले निर्भरताएँ पूरी हो जाती हैं।

संदर्भ↗

एक प्राथमिक एप्लिकेशन कंटेनर को सहायक कार्यक्षमताओं जैसे लॉगिंग, मॉनिटरिंग, या प्रॉक्सीइंग के साथ विस्तारित करें।

→Pod स्पेसिफिकेशन में एक दूसरा कंटेनर (साइडकार) जोड़ें। दोनों कंटेनर नेटवर्क और वॉल्यूम जैसे संसाधनों को साझा करते हैं।

क्यों: मुख्य एप्लिकेशन कोड को संशोधित किए बिना कार्यक्षमता बढ़ाता है, चिंताओं के अलगाव को बढ़ावा देता है।

एक ही Pod में कंटेनरों के बीच पढ़ने/लिखने के लिए एक निर्देशिका साझा करें।

→Pod स्पेसिफिकेशन में एक `emptyDir` वॉल्यूम परिभाषित करें और इसे सभी आवश्यक कंटेनरों में माउंट करें।

क्यों: `emptyDir` एक सरल, क्षणिक स्टोरेज वॉल्यूम प्रदान करता है जो Pod के जीवनकाल के लिए मौजूद रहता है, जो अंतर-पॉड डेटा साझाकरण के लिए एकदम सही है।

एक कंटेनर इमेज के डिफ़ॉल्ट ENTRYPOINT और/या CMD को ओवरराइड करें।

→कंटेनर स्पेसिफिकेशन में, ENTRYPOINT को ओवरराइड करने के लिए `command` का और CMD को ओवरराइड करने के लिए `args` का उपयोग करें। `command: ["/bin/sh"], args: ["-c", "echo hello"]`।

क्यों: Pod परिभाषा से कंटेनर स्टार्टअप कमांड पर पूर्ण नियंत्रण प्रदान करता है, जो सामान्य छवियों को अनुकूलित करने के लिए उपयोगी है।

समानांतरता और सफल पूर्णताओं की संख्या को नियंत्रित करते हुए, एक सीमित कार्य को पूर्णता तक चलाएँ।

→एक `Job` संसाधन का उपयोग करें। लक्ष्य सफलता संख्या के लिए `spec.completions` और समवर्ती Pods की संख्या के लिए `spec.parallelism` सेट करें। पुनः प्रयास को नियंत्रित करने के लिए `spec.backoffLimit` का उपयोग करें।

क्यों: Jobs लंबी चलने वाली Deployments के विपरीत, पूर्ण होने तक चलने वाले कार्यों के लिए डिज़ाइन किए गए हैं। ये सेटिंग्स बैच वर्कलोड को प्रबंधित करने के लिए महत्वपूर्ण हैं।

क्रॉन सिंटैक्स का उपयोग करके एक आवर्ती कार्य शेड्यूल करें और नियंत्रित करें कि अतिव्यापी जॉब्स को कैसे संभाला जाता है।

→एक `CronJob` संसाधन का उपयोग करें। क्रॉन प्रारूप में `spec.schedule` परिभाषित करें (उदाहरण के लिए, `*/5 * * * *`)। `spec.concurrencyPolicy` को `Allow`, `Forbid`, या `Replace` पर सेट करें।

क्यों: निर्धारित कार्यों को स्वचालित करता है। `concurrencyPolicy` अतिव्यापी रनों को रोकने (`Forbid`) या पुराने रनों को बदलने (`Replace`) के लिए महत्वपूर्ण है।

क्लस्टर में संसाधन बनाए बिना, उसके लिए एक YAML मैनिफेस्ट तुरंत जनरेट करें।

→अनिवार्य कमांड के साथ `--dry-run=client -o yaml` फ्लैग का उपयोग करें। उदाहरण: `kubectl run nginx --image=nginx --dry-run=client -o yaml > pod.yaml`।

क्यों: एक वैध मैनिफेस्ट को तैयार करके समय बचाता है जिसे अनुकूलित किया जा सकता है और फिर घोषणात्मक रूप से लागू किया जा सकता है।

एक Deployment को अनिवार्य रूप से अपडेट करें, स्केल करें, स्थिति की जाँच करें, इतिहास देखें और रोलबैक करें।

→`kubectl set image`, `kubectl scale`, `kubectl rollout status`, `kubectl rollout history`, और `kubectl rollout undo` का उपयोग करें।

क्यों: ये विकास और समस्या निवारण के दौरान एक डिप्लॉयड एप्लिकेशन के जीवनचक्र को प्रबंधित करने के लिए मुख्य अनिवार्य कमांड हैं।

उपलब्धता सुनिश्चित करने के लिए एक Deployment अपडेट की गति और सुरक्षा को नियंत्रित करें।

→`spec.strategy.rollingUpdate` में, `maxSurge` (कितने अतिरिक्त Pods बनाए जा सकते हैं) और `maxUnavailable` (कितने डाउन हो सकते हैं) को कॉन्फ़िगर करें।

क्यों: अपडेट के दौरान क्षमता बनाम संसाधन उपयोग को प्रबंधित करने के लिए `maxSurge` और `maxUnavailable` को संतुलित करना महत्वपूर्ण है। शून्य डाउनटाइम के लिए, `maxUnavailable` `replicas` से कम होना चाहिए।

यह सुनिश्चित करें कि एक ही समय में किसी एप्लिकेशन के दो संस्करण न चलें, सभी पुराने Pods को समाप्त करने के बाद नए बनाएँ।

→Deployment में `spec.strategy.type: Recreate` सेट करें।

क्यों: गारंटी देता है कि पुराने और नए संस्करण एक साथ मौजूद नहीं रहते, जो उन अनुप्रयोगों के लिए आवश्यक है जो एक ही डेटा तक पहुँचने वाले दो अलग-अलग संस्करणों को संभाल नहीं सकते। इस रणनीति में डाउनटाइम होता है।

प्रत्येक परिवर्तन के लिए एक मध्यवर्ती रोलआउट को ट्रिगर किए बिना एक लाइव Deployment में कई परिवर्तन करें।

→`kubectl rollout pause deployment/<name>` का उपयोग करें, परिवर्तन लागू करें, फिर `kubectl rollout resume deployment/<name>`।

क्यों: कई अपडेट्स को एक ही रोलआउट इवेंट में समेकित करता है, जिससे बदलाव और रेस कंडीशन को रोका जा सकता है।

etcd स्टोरेज बचाने के लिए एक Deployment के लिए रखे गए पुराने ReplicaSets की संख्या को सीमित करें।

→`spec.revisionHistoryLimit` को रखने के लिए आवश्यक संशोधनों की संख्या पर सेट करें (उदाहरण के लिए, 3)। डिफ़ॉल्ट 10 है।

क्यों: निचली सीमा सेट करने से etcd अव्यवस्था कम होती है। `0` पर सेट करने से रोलबैक क्षमता पूरी तरह से अक्षम हो जाती है।

एक Deployment अपडेट के कारण को दस्तावेज़ित करें ताकि यह संशोधन इतिहास में दिखाई दे।

→Deployment मैनिफेस्ट में `kubernetes.io/change-cause` एनोटेशन जोड़ें। उदाहरण: `kubectl annotate deployment/nginx kubernetes.io/change-cause="update to 1.20"`।

क्यों: रोलआउट इतिहास (`kubectl rollout history`) देखते समय मूल्यवान संदर्भ प्रदान करता है, जिससे यह पहचानना आसान हो जाता है कि किस संशोधन पर रोलबैक करना है।

एक नया एप्लिकेशन संस्करण पुराने वाले के साथ डिप्लॉय करें और शून्य डाउनटाइम के साथ तुरंत ट्रैफिक स्विच करें।

→विभिन्न संस्करण लेबलों के साथ दो Deployments (जैसे, `app-blue`, `app-green`) का उपयोग करें। एक एकल Service अपने `selector` के माध्यम से सक्रिय संस्करण का चयन करती है। स्विच करने के लिए, सेलेक्टर को नए संस्करण लेबल पर अपडेट करने के लिए `kubectl patch service` का उपयोग करें।

क्यों: Service सेलेक्टर को वापस पैच करके तत्काल, कम जोखिम वाले रिलीज़ और तत्काल रोलबैक क्षमता प्रदान करता है।

उत्पादन में परीक्षण के लिए ट्रैफिक का एक छोटा प्रतिशत एक नए एप्लिकेशन संस्करण पर रूट करें।

→एक ही सेलेक्टर लेबल साझा करने वाले दो Deployments (स्थिर, कैनरी) का उपयोग करें। एक Service दोनों को लक्षित करती है। रेप्लिका के अनुपात से ट्रैफिक प्रतिशत को नियंत्रित करें (उदाहरण के लिए, 9 स्थिर रेप्लिका, 10% ट्रैफिक के लिए 1 कैनरी)।

क्यों: सर्विस मेश के बिना कैनरी रिलीज़ करने का एक सरल तरीका, नई सुविधाओं के नियंत्रित, कम जोखिम वाले परीक्षण की अनुमति देता है। ट्रैफिक वितरण अनुमानित है।

क्लस्टर के भीतर से ही संचार के लिए Pods के एक सेट को उजागर करें।

→`type: ClusterIP` के साथ एक Service का उपयोग करें। यह डिफ़ॉल्ट प्रकार है।

क्यों: `ClusterIP` एक सेवा के लिए एक स्थिर आंतरिक IP पता और DNS नाम प्रदान करता है, व्यक्तिगत Pod IP को अमूर्त करता है।

प्रत्येक नोड के IP पते पर एक स्थिर पोर्ट पर एक सेवा को उजागर करें।

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

क्यों: विकास के लिए या जब एक बाहरी लोड बैलेंसर उपलब्ध न हो तो उपयोगी। `<NodeIP>:<NodePort>` पर ट्रैफिक Service को फॉरवर्ड किया जाता है।

होस्टनाम या URL पथ के आधार पर बाहरी HTTP/S ट्रैफिक को आंतरिक सेवाओं पर रूट करें।

→एक `Ingress` संसाधन बनाएँ। होस्ट के लिए `rules` और बैकएंड सेवाओं से मैप करने के लिए `http.paths` परिभाषित करें। TLS Secret की ओर इंगित करते हुए `spec.tls` के साथ TLS कॉन्फ़िगर करें।

क्यों: Ingress L7 रूटिंग प्रदान करता है, कई सेवाओं को एक बाहरी IP के तहत समेकित करता है और TLS समाप्ति को ऑफलोड करता है।

लेबल, नेमस्पेस, या IP ब्लॉकों के आधार पर Pods में और उनसे नेटवर्क ट्रैफिक को प्रतिबंधित करें।

→`podSelector` के साथ Pods को लक्षित करते हुए एक `NetworkPolicy` बनाएँ। विशिष्ट ट्रैफिक की अनुमति देने के लिए `ingress` और/या `egress` नियम परिभाषित करें। डिफ़ॉल्ट रूप से, एक Pod पर नीति लागू करने से उन सभी ट्रैफिक को अस्वीकार कर दिया जाता है जिनकी स्पष्ट रूप से अनुमति नहीं है।

क्यों: NetworkPolicies नेटवर्क सेगमेंटेशन और Kubernetes में शून्य-विश्वास सुरक्षा मॉडल को लागू करने के लिए मौलिक हैं।

संदर्भ↗

डिफ़ॉल्ट रूप से एक नेमस्पेस में सभी पॉड्स के लिए सभी इनग्रेस और इग्रेस ट्रैफिक को ब्लॉक करें।

→एक खाली `podSelector: {}` और खाली इनग्रेस/इग्रेस नियमों के साथ एक NetworkPolicy बनाएँ। उदाहरण: `podSelector: {}, policyTypes: [Ingress, Egress]`।

क्यों: एक सुरक्षित आधार रेखा स्थापित करता है जहां सभी ट्रैफिक को अस्वीकार कर दिया जाता है जब तक कि अन्य, अधिक विशिष्ट NetworkPolicies द्वारा स्पष्ट रूप से अनुमति न दी जाए।

एक स्थिर DNS प्रविष्टि प्रदान करें जो लोड बैलेंसिंग के लिए वर्चुअल IP के बिना, सीधे सभी Pod IPs पर हल होती है।

→`spec.clusterIP: None` के साथ एक Service बनाएँ।

क्यों: Stateful अनुप्रयोगों (जैसे StatefulSets) या पीयर-टू-पीयर सिस्टम के लिए आवश्यक है जिन्हें सीधे विशिष्ट Pods के साथ खोजने और संचार करने की आवश्यकता होती है।

सुनिश्चित करें कि बैकएंड Pods एक NodePort या LoadBalancer Service से ट्रैफिक के लिए मूल क्लाइंट IP देखें।

→Service पर `spec.externalTrafficPolicy: Local` सेट करें।

क्यों: डिफ़ॉल्ट (`Cluster`) नीति नेटवर्क एड्रेस ट्रांसलेशन के माध्यम से स्रोत IP को अस्पष्ट करती है। `Local` इसे संरक्षित करता है लेकिन यदि Pods सभी नोड्स पर नहीं हैं तो असमान ट्रैफिक वितरण हो सकता है।

सुनिश्चित करें कि एक विशिष्ट क्लाइंट से सभी अनुरोध एक ही Pod पर भेजे जाते हैं।

→Service पर, `spec.sessionAffinity: ClientIP` सेट करें।

क्यों: 'स्टिकी सेशन्स' प्रदान करता है, जो उन लेगेसी अनुप्रयोगों के लिए आवश्यक है जो एक विशिष्ट Pod पर मेमोरी में सेशन स्थिति संग्रहीत करते हैं।

एक नेमस्पेस में एक Pod को दूसरे नेमस्पेस में एक Service के साथ संचार करने की आवश्यकता है।

→विस्तारित DNS नाम का उपयोग करें: `<service-name>.<namespace-name>.svc.cluster.local` या छोटा रूप `<service-name>.<namespace-name>`।

क्यों: सरल सेवा नाम केवल उसी नेमस्पेस के भीतर हल होते हैं। क्रॉस-नेमस्पेस संचार के लिए DNS क्वेरी में लक्ष्य नेमस्पेस निर्दिष्ट करना आवश्यक है।

Pod जीवनचक्र को प्रबंधित करने के लिए स्वास्थ्य जांच परिभाषित करें: विफलता पर पुनरारंभ बनाम सेवा से हटाना।

→`livenessProbe`: यदि जांच विफल हो जाती है तो कंटेनर को पुनरारंभ करता है। `readinessProbe`: यदि जांच विफल हो जाती है तो Pod को Service एंडपॉइंट्स से हटा देता है। `startupProbe`: जब तक कंटेनर अपना स्टार्टअप पूरा नहीं कर लेता तब तक अन्य जांचों को अक्षम कर देता है।

क्यों: सही ढंग से कॉन्फ़िगर की गई जांचें एप्लिकेशन आत्म-उपचार और शून्य-डाउनटाइम डिप्लॉयमेंट प्राप्त करने के लिए आवश्यक हैं।

संदर्भ↗

निदान करें कि एक Pod गैर-चलती स्थिति (जैसे, Pending, ContainerCreating, CrashLoopBackOff) में क्यों अटका हुआ है।

→`kubectl describe pod <pod-name>` का उपयोग करें। `Events` अनुभाग शेड्यूलर (संसाधन समस्याएँ), kubelet (इमेज पुल त्रुटियाँ), या कंटेनर रनटाइम से महत्वपूर्ण सुराग प्रदान करता है।

क्यों: `describe` उन Pod जीवनचक्र समस्याओं को समझने के लिए सबसे महत्वपूर्ण कमांड है जो एप्लिकेशन शुरू होने या कुछ भी लॉग करने से पहले होती हैं।

एक कंटेनर से लॉग का निरीक्षण करें जो क्रैश हो गया है और अब पुनरारंभ लूप (CrashLoopBackOff) में है।

→`kubectl logs <pod-name> --previous` का उपयोग करें।

क्यों: `--previous` फ़्लैग कंटेनर के अंतिम समाप्त उदाहरण से लॉग दिखाता है, जिसमें क्रैश का कारण बनने वाली त्रुटि होती है।

वास्तविक समय में लेबल सेलेक्टर से मेल खाने वाले सभी Pods से लॉग देखें और फॉलो करें।

→`kubectl logs -l <label-selector> -f` का उपयोग करें। यह देखने के लिए `--prefix` जोड़ें कि प्रत्येक पंक्ति किस पॉड से आई है।

क्यों: एक वितरित एप्लिकेशन से लॉग्स को एकत्रित करता है, इसके व्यवहार का एक एकीकृत दृश्य प्रदान करता है।

डिबगिंग के लिए एक चल रहे कंटेनर के अंदर एक कमांड निष्पादित करें या एक इंटरैक्टिव शेल प्राप्त करें।

→`kubectl exec -it <pod-name> -- /bin/sh` (या `/bin/bash`) का उपयोग करें। `--` kubectl फ़्लैग्स को कमांड से अलग करता है।

क्यों: लाइव डिबगिंग, फ़ाइलों का निरीक्षण करने, या नेटवर्क कनेक्टिविटी की जाँच के लिए कंटेनर के वातावरण तक सीधी पहुँच प्रदान करता है।

एक चल रहे Pod की वर्तमान CPU और मेमोरी खपत देखें।

→`kubectl top pod <pod-name>` का उपयोग करें। Pod में प्रत्येक कंटेनर के उपयोग को देखने के लिए `--containers` का उपयोग करें।

क्यों: Metrics Server स्थापित होना आवश्यक है। यह संसाधन-भूखे अनुप्रयोगों, मेमोरी लीक, या CPU बॉटलनेक की पहचान करने के लिए आवश्यक है।

एक चल रहे कंटेनर का समस्या निवारण करें जिसमें शेल या डिबगिंग टूल की कमी हो।

→`kubectl debug <pod-name> -it --image=busybox --share-processes --copy-to=debug-pod` का उपयोग करें। यह एक नया Pod बनाता है जिसमें एक डिबग कंटेनर एक ही प्रक्रिया नेमस्पेस को साझा करता है।

क्यों: `kubectl debug` मूल Pod स्पेसिफिकेशन को संशोधित किए बिना एक चल रहे Pod से डिबगिंग टूल के साथ एक अस्थायी "एफ़ेमरल कंटेनर" संलग्न करने का आधुनिक तरीका है।