This is the multi-page printable view of this section. Click here to print.
कुबेरनेट्स प्रलेखन के इस खंड के पृष्ठ एकल कार्य करने का तरीका दिखाते हैं। आमतौर पर, कार्य पृष्ठ दिखाता है कि किसी एक काम को कई छोटे चरणों में विभाजित करके कैसे करना है।
यदि आप एक कार्य पृष्ठ लिखना चाहते हैं, तो देखेंप्रलेखन के लिए एक पुल अनुरोध (Pull Request) बनाएं.
कुबेरनेट्स कमांड-लाइन टूल, kubectl, आपको कुबेरनेट्स क्लस्टर पर कमांड चलाने की अनुमति देता है।
आप एप्लिकेशन को डिप्लॉय करने, क्लस्टर संसाधनों का निरीक्षण और प्रबंधन करने और लॉग देखने के लिए kubectl का उपयोग कर सकते हैं।
kubectl संचालन की पूरी सूची सहित अधिक जानकारी के लिए, देखें
kubectl संदर्भ प्रलेखन.
kubectl विभिन्न प्रकार के Linux प्लेटफॉर्म, macOS और Windows पर इंस्टॉल करने योग्य है।नीचे अपना उपयुक्त ऑपरेटिंग सिस्टम खोजें।
kind आपको अपने कंप्यूटर पर कुबेरनेट्स चलाने देता है।इस उपकरण के लिए आवश्यक है कि आपके पास
Docker इंस्टॉल और कॉन्फ़िगर किया गया हो।
kind क्विक स्टार्ट पृष्ठ आपको दिखाता है कि kind चलाने के लिए आपको क्या करने की आवश्यकता है।
kind की तरह, minikube एक उपकरण
है जो आपको स्थानीय स्तर पर कुबेरनेट्स चलाने देता है। minikube आपके कंप्यूटर
(windows, macOS और linux पीसी सहित) पर सिंगल-नोड कुबेरनेट्स क्लस्टर चलाता
है ताकि आप कुबेरनेट्स सीख सकें या डेवलपमेंट कर सकें।
यदि आपका ध्यान उपकरण को इंस्टॉल करने पर है तो आप मुख्य आरंभ करें! गाइड का अनुसरण कर सकते हैं।
minikube क्विक स्टार्ट गाइड देखें
एक बार जब आपके पास minikube काम कर रहा हो, तो आप इसका उपयोग नमूना एप्लिकेशन चलाने के लिए कर सकते हैं।
कुबेरनेट्स क्लस्टर बनाने और प्रबंधित करने के लिए आप kubeadm टूल का उपयोग कर सकते हैं।यह उपयोगकर्ता के अनुकूल तरीके से न्यूनतम व्यवहार्य, सुरक्षित क्लस्टर बनाने और चलाने के लिए आवश्यक कार्य करता है।
kubeadm इंस्टॉल करना आपको दिखाता है कि kubeadm को कैसे इंस्टॉल किया जाए।एक बार इंस्टॉल होने के बाद, आप इसका उपयोग क्लस्टर बनाने के लिए कर सकते हैं।
आप kubectl संस्करण का उपयोग करे जो आपके क्लस्टर के एक माइनर संस्करण के भीतर हो। उदाहरण के लिए, v1.35 क्लाइंट v1.34, v1.35 और v1.36 कण्ट्रोल प्लेन के साथ संवाद कर सकते हैं।kubectl के नवीनतम संस्करण का उपयोग करने से अप्रत्याशित मुद्दों से बचने में मदद मिलती है।
Linux पर kubectl संस्थापित करने के लिए निम्नलिखित विधियाँ मौजूद हैं:
कमांड से नवीनतम रिलीज डाउनलोड करें:
curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl"
एक विशिष्ट संस्करण डाउनलोड करने के लिए, कमांड के $(curl -L -s https://dl.k8s.io/release/stable.txt) हिस्से को विशिष्ट संस्करण से बदलें।
उदाहरण के लिए, लिनक्स पर 1.35.0 संस्करण डाउनलोड करने के लिए, टाइप करें:
curl -LO https://dl.k8s.io/release/v1.35.0/bin/linux/amd64/kubectl
बाइनरी को मान्य करें (वैकल्पिक)
kubectl चेकसम फाइल डाउनलोड करें:
curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl.sha256"
चेकसम फ़ाइल से kubectl बाइनरी को मान्य करें:
echo "$(<kubectl.sha256) kubectl" | sha256sum --check
यदि मान्य है, तो आउटपुट है:
kubectl: OK
अगर चेक फेल हो जाता है, तो sha256 nonzero स्थिति के साथ बाहर निकलता है और इस आउटपुट के समान प्रिंट करता है:
kubectl: FAILED
sha256sum: WARNING: 1 computed checksum did NOT match
kubectl इंस्टॉल करें
sudo install -o root -g root -m 0755 kubectl /usr/local/bin/kubectl
यदि आपके पास टारगेट सिस्टम पर रुट एक्सेस नहीं है, आप तब भी kubectl को ~/.local/bin डायरेक्टरी में इंस्टॉल कर सकते हैं:
chmod +x kubectl
mkdir -p ~/.local/bin/kubectl
mv ./kubectl ~/.local/bin/kubectl
# and then add ~/.local/bin/kubectl to $PATH
यह सुनिश्चित करने के लिए परीक्षण करें कि आपके द्वारा इंस्टॉल किया गया संस्करण उप-टू-डेट है:
kubectl version --client
apt पैकेज इंडेक्स को अपडेट करे और कुबेरनेट्स apt रिपॉजिटरी का उपयोग करने के लिए आवश्यक पैकेज इंस्टॉल करें:
sudo apt-get update
sudo apt-get install -y apt-transport-https ca-certificates curl gnupg
गूगल क्लाउड पब्लिक साइनिंग कुंजी (key) डाउनलोड करें:
sudo curl -fsSLo /usr/share/keyrings/kubernetes-archive-keyring.gpg https://packages.cloud.google.com/apt/doc/apt-key.gpg
कुबेरनेट्स apt रिपॉजिटरी को जोड़े:
echo "deb [signed-by=/usr/share/keyrings/kubernetes-archive-keyring.gpg] https://apt.kubernetes.io/ kubernetes-xenial main" | sudo tee /etc/apt/sources.list.d/kubernetes.list
नए रिपॉजिटरी के साथ apt पैकेज इंडेक्स अपडेट करें और kubectl इंस्टॉल करें:
sudo apt-get update
sudo apt-get install -y kubectl
cat <<EOF > /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64
enabled=1
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
EOF
yum install -y kubectl
यदि आप Ubuntu या किसी अन्य Linux डिस्ट्रीब्यूशन पर हैं जो snap पैकेज मैनेजर को सपोर्ट करता है, तो kubectl snap एप्लिकेशन के रूप में उपलब्ध है।
snap install kubectl --classic
kubectl version --client
यदि आप Linux पर Homebrew पैकेज मैनेजर का उपयोग कर रहे हैं, तो kubectl इंस्टालेशन के लिए उपलब्ध है।
brew install kubectl
kubectl version --client
kubectl को कुबेरनेट्स क्लस्टर को खोजने और एक्सेस करने के लिए, उसेक्यूबकॉन्फिग फाइल(kubeconfig) की आवश्यकता होती है,जो स्वचालित रूप से तब बनता है जब आपkube-up.sh का उपयोग करके क्लस्टर बनाते हैं
या मिनीक्यूब क्लस्टर को सफलतापूर्वक डिप्लॉय करते हैं।डिफ़ॉल्ट रूप से, kubectl कॉन्फ़िगरेशन ~/.kube/config पर स्थित होता है।
जाँच करें कि क्लस्टर स्टेट प्राप्त करके kubectl को ठीक से कॉन्फ़िगर किया गया है:
kubectl cluster-info
यदि आपको एक URL प्रतिक्रिया दिखती हैं, तो kubectl आपके क्लस्टर तक पहुँचने के लिए सही ढंग से कॉन्फ़िगर हुआ है।
यदि आपको निम्नलिखित संदेश दिखाई देता है, तो kubectl ठीक से कॉन्फ़िगर नहीं हुआ है या कुबेरनेट्स क्लस्टर से कनेक्ट करने में सक्षम नहीं है।
The connection to the server <server-name:port> was refused - did you specify the right host or port?
उदाहरण के लिए, यदि आप अपने लैपटॉप (स्थानीय रूप से) पर कुबेरनेट्स क्लस्टर चलाना चाहते हैं, तो आपको पहले मिनीक्यूब (minikube) जैसे टूल को इंस्टॉल करना होगा और ऊपर बताए गए कमांड को फिर से चलाना होगा।
यदि kubectl cluster-info URL प्रतिक्रिया देता है, लेकिन आप अपने क्लस्टर को एक्सेस नहीं कर पा रहें हैं, तो यह जाँचने के लिए कि क्या यह ठीक से कॉन्फ़िगर किया गया है, इस कमांड का उपयोग करें:
kubectl cluster-info dump
kubectl Bash और Zsh के लिए ऑटोकम्प्लेशन का सपोर्ट प्रदान करता है, जो आपका काफी समय बचा सकता है।
नीचे Bash और Zsh के लिए ऑटोकम्प्लेशन स्थापित करने की प्रक्रियाएँ हैं।
Bash के लिए kubectl समापन स्क्रिप्ट kubectl completion bash कमांड के साथ उत्पन्न की जा सकती है। आपके शेल में समापन स्क्रिप्ट को सोर्स करने से kubectl ऑटोकम्पलीशन सक्षम हो जाती है।
हालाँकि, समापन की स्क्रिप्ट bash-completion पर निर्भर हैं जिसका अर्थ है कि आपको पहले इस सॉफ़्टवेयर को इंस्टॉल करना होगा (आप type _init_completion चलाकर परीक्षण कर सकते हैं कि आपने पहले से bash-completion इंस्टॉल की है या नहीं)।
कई पैकेज मैनेजर द्वारा bash-completion प्रदान की जाती है (यहाँ देखें)। आप इसे apt-get install bash-completion या yum install bash-completion आदि के साथ इंस्टॉल कर सकते हैं।
यह कमांड /usr/share/bash-completion/bash_completion उत्त्पन्न करता है, जो bash-completion की मुख्य स्क्रिप्ट है। आपके पैकेज मैनेजर के आधार पर, आपको इस फाइल को अपनी ~/.bashrc फाइल में मैन्युअल रूप से सोर्स करना होगा।
यह पता लगाने के लिए, अपना शेल पुनः लोड करें और type _init_completion रन करे। यदि कमांड सफल होता है, तो आप पहले से ही तैयार हैं, अन्यथा अपनी ~/.bashrc फ़ाइल में निम्नलिखित जोड़ें:
source /usr/share/bash-completion/bash_completion
अपना शेल पुनः लोड करें और type _init_completion टाइप करके सत्यापित करें कि बैश-कम्पलीशन सही ढंग से इंस्टॉल है।
अब आपको यह सुनिश्चित करने की आवश्यकता है कि kubectl समापन स्क्रिप्ट आपके सभी शेल सत्रों (sourced) में प्राप्त हो जाए। आप ऐसा दो तरीकों से कर सकते हैं:
अपनी ~/.bashrc फ़ाइल में समापन स्क्रिप्ट सॉर्स करें:
echo 'source <(kubectl completion bash)' >>~/.bashr
समापन स्क्रिप्ट को /etc/bash_completion.d डायरेक्टरी में जोड़ें:bash kubectl completion bash >/etc/bash_completion.d/kubectl
यदि आप के पास kubectl के लिए एक अन्य नाम (alias) है, तो आप उस अन्य नाम के साथ काम करने के लिए शेल समापन को बढ़ा सकते हैं:
echo 'alias k=kubectl' >>~/.bashrc
echo 'complete -F __start_kubectl k' >>~/.bashrc
/etc/bash_completion.d में सोर्स करता है।दोनों दृष्टिकोण बराबर हैं। आपके शेल को पुनः लोड करने के बाद, Kubectl ऑटोकम्पलीशन कार्य करना शुरू कर देगा।
Zsh के लिए kubectl कम्पलीशन स्क्रिप्ट kubectl completion zsh कमांड के साथ उत्पन्न की जा सकती है। आपके शेल में कम्पलीशन स्क्रिप्ट को सोर्स करने से kubectl ऑटो-कम्पलीशन सक्षम हो जाती है।
अपने सभी शेल सत्रों में ऐसा करने के लिए, निम्नलिखित को अपनी ~/.zshrc फ़ाइल में जोड़ें:
source <(kubectl completion zsh)
यदि आपके पास kubectl के लिए एक उपनाम है, तो आप उस उपनाम के साथ काम करने के लिए शेल कम्पलीशन को बढ़ा सकते हैं:
echo 'alias k=kubectl' >>~/.zshrc
echo 'complete -F __start_kubectl k' >>~/.zshrc
अपने शेल को पुनः लोड करने के बाद, kubectl ऑटो-कम्पलीशन कार्य करना चाहिए।
यदि आपको कोई त्रुटि मिलती है जैसे complete:13: command not found: compdef, तो अपनी ~/.zshrc फ़ाइल की शुरुआत में निम्नलिखित जोड़ें:
autoload -Uz compinit
compinit
kubectl convert प्लगइन इंस्टॉल करेंकुबेरनेट्स कमांड-लाइन टूल kubectl के लिए एक प्लगइन, जो आपको विभिन्न API संस्करण के बीच मैनिफ़ेस्ट को बदलने करने की अनुमति देता है।यह विशेष रूप से नए कुबेरनेट्स रिलीज के साथ एक गैर-बहिष्कृत API संस्करण में मैनिफेस्ट को माइग्रेट करने में सहायक हो सकता है।अधिक जानकारी के लिए, गैर पदावनत एपिस में विस्थापित करें पर जाएं।
कमांड से नवीनतम रिलीज डाउनलोड करें:
curl -LO https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl-convert
बाइनरी को मान्य करें (वैकल्पिक)
kubectl-convert चेकसम फ़ाइल डाउनलोड करें:
curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl-convert.sha256"
चेकसम फ़ाइल से kubectl-convert बाइनरी को मान्य करें:
echo "$(<kubectl-convert.sha256) kubectl-convert" | sha256sum --check
यदि मान्य है, तो आउटपुट है:
kubectl-convert: OK
अगर चेक फेल हो जाता है, तो sha256 nonzero स्थिति के साथ बाहर निकलता है और इस आउटपुट के समान प्रिंट करता है:
kubectl-convert: FAILED
sha256sum: WARNING: 1 computed checksum did NOT match
kubectl-convert इंस्टॉल करें
sudo install -o root -g root -m 0755 kubectl-convert /usr/local/bin/kubectl-convert
सत्यापित करें कि प्लगइन सफलतापूर्वक इंस्टॉल है
kubectl convert --help
यदि आपको कोई त्रुटि नहीं दिखाई देती है, तो इसका मतलब है कि प्लगइन सफलतापूर्वक इंस्टॉल हो गया है।
आप kubectl संस्करण का उपयोग करे जो आपके क्लस्टर के एक माइनर संस्करण भीतर हो। उदाहरण के लिए, v1.35 क्लाइंट v1.34, v1.35 और v1.36 कण्ट्रोल प्लेन के साथ कम्युनिकेट कर सकते हैं।kubectl के नए संस्करण का उपयोग करने से समस्या से बचत हो सकती है।
macOS पर kubectl संस्थापित करने के लिए निम्नलिखित विधियाँ मौजूद हैं:
नवीनतम रिलीज़ डाउनलोड करें:
curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/amd64/kubectl"
curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/arm64/kubectl"
एक विशिष्ट संस्करण डाउनलोड करने के लिए, कमांड के इस हिस्से $(curl -L -s https://dl.k8s.io/release/stable.txt) को विशिष्ट संस्करण से बदलें।
उदाहरण के लिए, Intel macOS पर 1.35.0 संस्करण डाउनलोड करने के लिए, टाइप करें:
curl -LO "https://dl.k8s.io/release/v1.35.0/bin/darwin/amd64/kubectl"
और Apple Silicon macOS के लिए, टाइप करें:
curl -LO "https://dl.k8s.io/release/v1.35.0/bin/darwin/arm64/kubectl"
बाइनरी को मान्य करें (वैकल्पिक))
kubectl चेकसम फाइल डाउनलोड करें:
curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/amd64/kubectl.sha256"
curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/arm64/kubectl.sha256"
चेकसम फ़ाइल से kubectl बाइनरी को मान्य करें:
echo "$(<kubectl.sha256) kubectl" | shasum -a 256 --check
यदि मान्य है, तो आउटपुट है:
kubectl: OK
अगर चेक फेल हो जाता है, तो shasum nonzero स्थिति के साथ बाहर निकलता है और इस आउटपुट के समान प्रिंट करता है:
kubectl: FAILED
shasum: WARNING: 1 computed checksum did NOT match
kubectl बाइनरी को एक्सेक्यूट करने योग्य बनायें।
chmod +x ./kubectl
kubectl बाइनरी को अपने सिस्टम PATH के फ़ाइल स्थान पर ले जाएँ।
sudo mv ./kubectl /usr/local/bin/kubectl
sudo chown root: /usr/local/bin/kubectl
/usr/local/bin आपके पाथ एनवायरनमेंट वेरिएबल में है।यह सुनिश्चित करने के लिए परीक्षण करें कि आपके द्वारा इंस्टॉल किया गया संस्करण उप-टू-डेट है:
kubectl version --client
यदि आप macOS पर हैं और Homebrew पैकेज मैनेजर का उपयोग कर रहे हैं, आप Homebrew के साथ kubectl इंस्टॉल कर सकते हैं।
इंस्टालेशन कमांड रन करें:
brew install kubectl
या
brew install kubernetes-cli
यह सुनिश्चित करने के लिए परीक्षण करें कि आपके द्वारा इंस्टॉल किया गया संस्करण उप-टू-डेट है:
kubectl version --client
यदि आप macOS पर हैं और Macports पैकेज मैनेजर का उपयोग कर रहे हैं, आप Macports के साथ kubectl इंस्टॉल कर सकते हैं।
इंस्टालेशन कमांड रन करें:
sudo port selfupdate
sudo port install kubectl
यह सुनिश्चित करने के लिए परीक्षण करें कि आपके द्वारा इंस्टॉल किया गया संस्करण उप-टू-डेट है:
kubectl version --client
kubectl को कुबेरनेट्स क्लस्टर को खोजने और एक्सेस करने के लिए, उसेक्यूबकॉन्फिग फाइल(kubeconfig) की आवश्यकता होती है,जो स्वचालित रूप से तब बनता है जब आपkube-up.sh का उपयोग करके क्लस्टर बनाते हैं
या मिनीक्यूब क्लस्टर को सफलतापूर्वक डिप्लॉय करते हैं।डिफ़ॉल्ट रूप से, kubectl कॉन्फ़िगरेशन ~/.kube/config पर स्थित होता है।
जाँच करें कि क्लस्टर स्टेट प्राप्त करके kubectl को ठीक से कॉन्फ़िगर किया गया है:
kubectl cluster-info
यदि आपको एक URL प्रतिक्रिया दिखती हैं, तो kubectl आपके क्लस्टर तक पहुँचने के लिए सही ढंग से कॉन्फ़िगर हुआ है।
यदि आपको निम्नलिखित संदेश दिखाई देता है, तो kubectl ठीक से कॉन्फ़िगर नहीं हुआ है या कुबेरनेट्स क्लस्टर से कनेक्ट करने में सक्षम नहीं है।
The connection to the server <server-name:port> was refused - did you specify the right host or port?
उदाहरण के लिए, यदि आप अपने लैपटॉप (स्थानीय रूप से) पर कुबेरनेट्स क्लस्टर चलाना चाहते हैं, तो आपको पहले मिनीक्यूब (minikube) जैसे टूल को इंस्टॉल करना होगा और ऊपर बताए गए कमांड को फिर से चलाना होगा।
यदि kubectl cluster-info URL प्रतिक्रिया देता है, लेकिन आप अपने क्लस्टर को एक्सेस नहीं कर पा रहें हैं, तो यह जाँचने के लिए कि क्या यह ठीक से कॉन्फ़िगर किया गया है, इस कमांड का उपयोग करें:
kubectl cluster-info dump
kubectl Bash और Zsh के लिए ऑटोकम्प्लेशन का सपोर्ट प्रदान करता है, जो आपका काफी समय बचा सकता है।
नीचे Bash और Zsh के लिए ऑटोकम्प्लेशन स्थापित करने की प्रक्रियाएँ हैं।
Bash के लिए kubectl समापन स्क्रिप्ट kubectl completion bash कमांड के साथ उत्पन्न की जा सकती है। आपके शेल में समापन स्क्रिप्ट को सोर्स करने से kubectl ऑटोकम्पलीशन सक्षम हो जाती है।```
हालाँकि, समापन की स्क्रिप्ट bash-completion पर निर्भर हैं जिसका अर्थ है कि आपको पहले इस सॉफ़्टवेयर को इंस्टॉल करना होगा।
निम्नलिखित निर्देश मानते हैं कि आप बैश 4.1+ का उपयोग करते हैं। आप अपने बैश के संस्करण को यह चलाकर देख सकते हैं:
echo $BASH_VERSION
यदि यह बहुत पुराना है, तो आप Homebrew का उपयोग करके इसे इनस्टॉल/अपग्रेड कर सकते हैं:
brew install bash
अपने शेल को पुनः लोड करें और सत्यापित करें कि इच्छित संस्करण का उपयोग किया जा रहा है:
echo $BASH_VERSION $SHELL
Homebrew आमतौर पर इसे /usr/local/bin/bash पर इनस्टॉल करता है।
आप type_init_completion से सत्यापित कर सकते हैं कि क्या आपके पास bash-completion v2 पहले से इनस्टॉल है। यदि नहीं, तो आप इसे Homebrew से इनस्टॉल कर सकते हैं
brew install bash-completion@2
जैसा कि इस कमांड के आउटपुट में बताया गया है, अपनी ~/.bash_profile फ़ाइल में निम्नलिखित जोड़ें:
export BASH_COMPLETION_COMPAT_DIR="/usr/local/etc/bash_completion.d"
[[ -r "/usr/local/etc/profile.d/bash_completion.sh" ]] && . "/usr/local/etc/profile.d/bash_completion.sh"
अपने शेल को पुनः लोड करें और type_init_completion से सत्यापित करें कि bash-completion v2 सही ढंग से इनस्टॉल है।
अब आपको यह सुनिश्चित करने की आवश्यकता है कि kubectl समापन स्क्रिप्ट आपके सभी शेल सत्रों (sourced) में प्राप्त हो जाए। इसे हासिल करने के कई तरीके हैं:
अपने कम्पलीशन स्क्रिप्ट को ~/.bash_profile में सोर्स करें:
echo 'source <(kubectl completion bash)' >>~/.bash_profile
कम्पलीशन स्क्रिप्ट को /usr/local/etc/bash_completion.d डायरेक्टरी में जोड़ें:
kubectl completion bash >/usr/local/etc/bash_completion.d/kubectl
यदि आपके पास kubectl के लिए एक नाम (alias) है, तो आप उस उपनाम के साथ काम करने के लिए शेल कम्पलीशन को बढ़ा सकते हैं:
echo 'alias k=kubectl' >>~/.bash_profile
echo 'complete -F __start_kubectl k' >>~/.bash_profile
यदि आपने Homebrew के साथ kubectl इनस्टॉल किया है (जैसा कि यहां बताया गया है), तो kubectl कम्पलीशन स्क्रिप्ट पहले से ही /usr/local/etc/bash_completion.d/kubectl में होनी चाहिए। ऐसे में आपको कुछ भी करने की जरूरत नहीं है।
BASH_COMPLETION_COMPAT_DIR डायरेक्टरी में सोर्स कर देता है। इसलिए आखरी दो तरीके काम करते हैं।Zsh के लिए kubectl कम्पलीशन स्क्रिप्ट kubectl completion zsh कमांड के साथ उत्पन्न की जा सकती है। आपके शेल में कम्पलीशन स्क्रिप्ट को सोर्स करने से kubectl ऑटो-कम्पलीशन सक्षम हो जाती है।
अपने सभी शेल सत्रों में ऐसा करने के लिए, निम्नलिखित को अपनी ~/.zshrc फ़ाइल में जोड़ें:
source <(kubectl completion zsh)
यदि आपके पास kubectl के लिए एक उपनाम है, तो आप उस उपनाम के साथ काम करने के लिए शेल कम्पलीशन को बढ़ा सकते हैं:
echo 'alias k=kubectl' >>~/.zshrc
echo 'complete -F __start_kubectl k' >>~/.zshrc
अपने शेल को पुनः लोड करने के बाद, kubectl ऑटो-कम्पलीशन कार्य करना चाहिए।
यदि आपको कोई त्रुटि मिलती है जैसे complete:13: command not found: compdef, तो अपनी ~/.zshrc फ़ाइल की शुरुआत में निम्नलिखित जोड़ें:
autoload -Uz compinit
compinit
kubectl convert प्लगइन इंस्टॉल करेंकुबेरनेट्स कमांड-लाइन टूल kubectl के लिए एक प्लगइन, जो आपको विभिन्न API संस्करण के बीच मैनिफ़ेस्ट को बदलने करने की अनुमति देता है।यह विशेष रूप से नए कुबेरनेट्स रिलीज के साथ एक गैर-बहिष्कृत API संस्करण में मैनिफेस्ट को माइग्रेट करने में सहायक हो सकता है।अधिक जानकारी के लिए, गैर पदावनत एपिस में विस्थापित करें पर जाएं।
इस कमांड से नवीनतम रिलीज डाउनलोड करें:
curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/amd64/kubectl-convert"
curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/arm64/kubectl-convert"
बाइनरी को मान्य करें (वैकल्पिक)
kubectl-convert चेकसम फ़ाइल डाउनलोड करें:
curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/amd64/kubectl-convert.sha256"
curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/arm64/kubectl-convert.sha256"
चेकसम फ़ाइल से kubectl-convert बाइनरी को मान्य करें:
echo "$(<kubectl-convert.sha256) kubectl-convert" | shasum -a 256 --check
यदि मान्य है, तो आउटपुट है:
kubectl-convert: OK
अगर चेक फेल हो जाता है, तो sha256 nonzero स्थिति के साथ बाहर निकलता है और इस आउटपुट के समान प्रिंट करता है:
kubectl-convert: FAILED
shasum: WARNING: 1 computed checksum did NOT match
Kubectl-कन्वर्ट बाइनरी को एक्सेक्यूट करने योग्य बनाएं
chmod +x ./kubectl-convert
kubectl-convert binary बाइनरी को अपने सिस्टम PATH के फ़ाइल स्थान पर ले जाएँ।
sudo mv ./kubectl-convert /usr/local/bin/kubectl-convert
sudo chown root: /usr/local/bin/kubectl-convert
/usr/local/bin आपके पाथ एनवायरनमेंट वेरिएबल में है।सत्यापित करें कि प्लगइन सफलतापूर्वक इंस्टॉल हो गया है
kubectl convert --help
यदि आपको कोई त्रुटि नहीं दिखाई देती है, तो इसका मतलब है कि प्लगइन सफलतापूर्वक इंस्टॉल हो गया है।
आप kubectl संस्करण का उपयोग करे जो आपके क्लस्टर के एक माइनर संस्करण भीतर हो। उदाहरण के लिए, v1.35 क्लाइंट v1.34, v1.35 और v1.36 कण्ट्रोल प्लेन के साथ कम्युनिकेट कर सकते हैं।kubectl के नए संस्करण का उपयोग करने से समस्या से बचत हो सकती है।
Windows पर kubectl संस्थापित करने के लिए निम्नलिखित विधियाँ मौजूद हैं:
latest release 1.35.0 डाउनलोड करें।
या यदि आपके पास curl है, तो इस कमांड का उपयोग करें:
curl -LO https://dl.k8s.io/release/v1.35.0/bin/windows/amd64/kubectl.exe
बाइनरी को मान्य करें (वैकल्पिक)
kubectl चेकसम फाइल डाउनलोड करें:
curl -LO https://dl.k8s.io/v1.35.0/bin/windows/amd64/kubectl.exe.sha256
चेकसम फ़ाइल से kubectl बाइनरी को मान्य करें:
मैन्युअल रूप से कमांड प्रॉम्प्ट का उपयोग करके CertUtil के आउटपुट की तुलना डाउनलोडेड चेकसम फ़ाइल से करें:
CertUtil -hashfile kubectl.exe SHA256
type kubectl.exe.sha256
True या False परिणाम प्राप्त करने के लिए -eq ऑपरेटर का उपयोग करके सत्यापन को ऑटोमेट करने के लिए powershell का उपयोग करें:
$(Get-FileHash -Algorithm SHA256 .\kubectl.exe).Hash -eq $(Get-Content .\kubectl.exe.sha256)
अपने PATH में बाइनरी जोड़ें।
यह सुनिश्चित करने के लिए परीक्षण करें कि kubectl संस्करण डाउनलोड के समान है:
kubectl version --client
kubectl का अपना संस्करण PATH में जोड़ता है।यदि आपने पहले Docker Desktop स्थापित किया है, तो आपको Docker Desktop इंस्टॉलर द्वारा जोड़े गए एक PATH से पहले अपनी PATH प्रविष्टि डालने की आवश्यकता हो सकती है या Docker Desktop के kubectl को हटा दें।Windows पर kubectl इंस्टॉल करने के लिए आप या तो Chocolatey पैकेज मैनेजर अथवा Scoop कमांड-लाइन इंस्टॉलर का उपयोग कर सकते हैं।
choco install kubernetes-cli
scoop install kubectl
यह सुनिश्चित करने के लिए परीक्षण करें कि आपके द्वारा इंस्टॉल किया गया संस्करण उप-टू-डेट है:
kubectl version --client
अपनी होम डायरेक्टरी पर जाएं:
# यदि आप cmd.exe का प्रयोग कर रहे हैं, तो: cd %USERPROFILE%
cd ~
.kube डायरेक्टरी बनाएं:
mkdir .kube
आपके द्वारा अभी बनाई गई .kube डायरेक्टरी में जाएं:
cd .kube
दूरस्थ कुबेरनेट्स क्लस्टर का उपयोग करने के लिए kubectl को कॉन्फ़िगर करें:
New-Item config -type file
kubectl को कुबेरनेट्स क्लस्टर को खोजने और एक्सेस करने के लिए, उसेक्यूबकॉन्फिग फाइल(kubeconfig) की आवश्यकता होती है,जो स्वचालित रूप से तब बनता है जब आपkube-up.sh का उपयोग करके क्लस्टर बनाते हैं
या मिनीक्यूब क्लस्टर को सफलतापूर्वक डिप्लॉय करते हैं।डिफ़ॉल्ट रूप से, kubectl कॉन्फ़िगरेशन ~/.kube/config पर स्थित होता है।
जाँच करें कि क्लस्टर स्टेट प्राप्त करके kubectl को ठीक से कॉन्फ़िगर किया गया है:
kubectl cluster-info
यदि आपको एक URL प्रतिक्रिया दिखती हैं, तो kubectl आपके क्लस्टर तक पहुँचने के लिए सही ढंग से कॉन्फ़िगर हुआ है।
यदि आपको निम्नलिखित संदेश दिखाई देता है, तो kubectl ठीक से कॉन्फ़िगर नहीं हुआ है या कुबेरनेट्स क्लस्टर से कनेक्ट करने में सक्षम नहीं है।
The connection to the server <server-name:port> was refused - did you specify the right host or port?
उदाहरण के लिए, यदि आप अपने लैपटॉप (स्थानीय रूप से) पर कुबेरनेट्स क्लस्टर चलाना चाहते हैं, तो आपको पहले मिनीक्यूब (minikube) जैसे टूल को इंस्टॉल करना होगा और ऊपर बताए गए कमांड को फिर से चलाना होगा।
यदि kubectl cluster-info URL प्रतिक्रिया देता है, लेकिन आप अपने क्लस्टर को एक्सेस नहीं कर पा रहें हैं, तो यह जाँचने के लिए कि क्या यह ठीक से कॉन्फ़िगर किया गया है, इस कमांड का उपयोग करें:
kubectl cluster-info dump
kubectl Bash और Zsh के लिए ऑटोकम्प्लेशन का सपोर्ट प्रदान करता है, जो आपको बहुत सारी टाइपिंग बचा सकता है।
नीचे Zsh के लिए ऑटोकम्प्लेशन स्थापित करने की प्रक्रियाएँ हैं, यदि आप इसे Windows पर चला रहे हैं।
Zsh के लिए kubectl कम्पलीशन स्क्रिप्ट kubectl completion zsh कमांड के साथ उत्पन्न की जा सकती है। आपके शेल में कम्पलीशन स्क्रिप्ट को सोर्स करने से kubectl ऑटो-कम्पलीशन सक्षम हो जाती है।
अपने सभी शेल सत्रों में ऐसा करने के लिए, निम्नलिखित को अपनी ~/.zshrc फ़ाइल में जोड़ें:
source <(kubectl completion zsh)
यदि आपके पास kubectl के लिए एक उपनाम है, तो आप उस उपनाम के साथ काम करने के लिए शेल कम्पलीशन को बढ़ा सकते हैं:
echo 'alias k=kubectl' >>~/.zshrc
echo 'complete -F __start_kubectl k' >>~/.zshrc
अपने शेल को पुनः लोड करने के बाद, kubectl ऑटो-कम्पलीशन कार्य करना चाहिए।
यदि आपको कोई त्रुटि मिलती है जैसे complete:13: command not found: compdef, तो अपनी ~/.zshrc फ़ाइल की शुरुआत में निम्नलिखित जोड़ें:
autoload -Uz compinit
compinit
kubectl convert प्लगइनकुबेरनेट्स कमांड-लाइन टूल kubectl के लिए एक प्लगइन, जो आपको विभिन्न API संस्करण के बीच मैनिफ़ेस्ट को बदलने करने की अनुमति देता है।यह विशेष रूप से नए कुबेरनेट्स रिलीज के साथ एक गैर-बहिष्कृत API संस्करण में मैनिफेस्ट को माइग्रेट करने में सहायक हो सकता है।अधिक जानकारी के लिए, गैर पदावनत एपिस में विस्थापित करें पर जाएं।
इस कमांड से नवीनतम रिलीज डाउनलोड करें:
curl -LO https://dl.k8s.io/release/v1.35.0/bin/windows/amd64/kubectl-convert.exe
बाइनरी को मान्य करें (वैकल्पिक)
kubectl-convert चेकसम फ़ाइल डाउनलोड करें:
curl -LO https://dl.k8s.io/v1.35.0/bin/windows/amd64/kubectl-convert.exe.sha256
चेकसम फ़ाइल से kubectl-convert बाइनरी को मान्य करें:
मैन्युअल रूप से कमांड प्रॉम्प्ट का उपयोग करके CertUtil के आउटपुट की तुलना डाउनलोड किये गये चेकसम फ़ाइल से करें:
CertUtil -hashfile kubectl-convert.exe SHA256
type kubectl-convert.exe.sha256
True या False परिणाम प्राप्त करने और -eq ऑपरेटर का उपयोग करके सत्यापन को ऑटोमेट करने के लिए Powershell का उपयोग करें:
$($(CertUtil -hashfile .\kubectl-convert.exe SHA256)[1] -replace " ", "") -eq $(type .\kubectl-convert.exe.sha256)
अपने PATH में बाइनरी जोड़ें।
सत्यापित करें कि प्लगइन सफलतापूर्वक इंस्टॉल हो गया है।
kubectl convert --help
यदि आपको कोई त्रुटि नहीं दिखाई देती है, तो इसका मतलब है कि प्लगइन सफलतापूर्वक इंस्टॉल हो गया है।
आपको कुबरनेट्स क्लस्टर की ज़रूरत पड़ेगी और क्यूब सीटीएल कमांड लाइन साधन को समनुरूप करना होगा ताकि वो आपके क्लस्टर के साथ संवाद कर सकें। हमारी सलाह है की इस टुटोरिअल को क्लस्टर में रन करने के लिए कम से कम दो नोड का इस्तेमाल करे जो कि कंट्रोल प्लेन होस्ट के तरह ना एक्ट करे। अगर आपके पास पहले से क्लस्टर नही है, आप minikube की मदद से वह बना सकते है या आप नीचे दिए हुए इन दो कुबरनेट्स प्लेग्राउंड का इस्तेमाल कर सकते हैं:
आप पहले JSON या YAML फॉर्मेट में एक मैनिफेस्ट में Secret ऑब्जेक्ट को परिभाषित कर सकते हैं, और फिर उस ऑब्जेक्ट को बना सकते हैं। Secret रिसोर्स में दो मैप्स होते हैं: data और stringData। data फील्ड का उपयोग मनमाना डेटा स्टोर करने के लिए किया जाता है, जो base64 का उपयोग करके एनकोड किया जाता है। stringData फील्ड सुविधा के लिए प्रदान किया जाता है, और यह आपको समान डेटा को अनएनकोडेड स्ट्रिंग्स के रूप में प्रदान करने की अनुमति देता है। data और stringData की कुंजियों में अल्फ़ान्यूमेरिक वर्ण, -, _ या . होने चाहिए।
निम्नलिखित उदाहरण data फील्ड का उपयोग करके एक सीक्रेट में दो स्ट्रिंग्स स्टोर करता है।
स्ट्रिंग्स को base64 में कनवर्ट करें:
echo -n 'admin' | base64
echo -n '1f2d1e2e67df' | base64
base64 यूटिलिटी का उपयोग करते समय, उपयोगकर्ताओं को लंबी लाइनों को विभाजित करने के लिए -b विकल्प का उपयोग करने से बचना चाहिए। इसके विपरीत, Linux उपयोगकर्ताओं को base64 कमांड में -w 0 विकल्प जोड़ना चाहिए या यदि -w विकल्प उपलब्ध नहीं है तो base64 | tr -d '\n' पाइपलाइन का उपयोग करना चाहिए।आउटपुट इस तरह का होता है:
YWRtaW4=
MWYyZDFlMmU2N2Rm
मैनिफेस्ट बनाएं:
apiVersion: v1
kind: Secret
metadata:
name: mysecret
type: Opaque
data:
username: YWRtaW4=
password: MWYyZDFlMmU2N2Rm
ध्यान दें कि एक सीक्रेट ऑब्जेक्ट का नाम एक मान्य DNS सबडोमेन नाम होना चाहिए।
kubectl apply का उपयोग करके सीक्रेट बनाएं:
kubectl apply -f ./secret.yaml
आउटपुट इस तरह का होता है:
secret/mysecret created
यह सत्यापित करने के लिए कि सीक्रेट बनाया गया था और सीक्रेट डेटा को डिकोड करने के लिए, kubectl का उपयोग करके सीक्रेट्स का प्रबंधन देखें।
कुछ परिदृश्यों के लिए, आप stringData फील्ड का उपयोग करना चाह सकते हैं। यह फील्ड आपको सीक्रेट में सीधे एक नॉन-base64 एनकोडेड स्ट्रिंग डालने की अनुमति देता है, और जब सीक्रेट बनाया या अपडेट किया जाता है तो स्ट्रिंग आपके लिए एनकोड की जाएगी।
इसका एक व्यावहारिक उदाहरण यह हो सकता है जहां आप एक एप्लिकेशन डिप्लॉय कर रहे हैं जो कॉन्फ़िगरेशन फाइल को स्टोर करने के लिए एक सीक्रेट का उपयोग करता है, और आप अपनी डिप्लॉयमेंट प्रक्रिया के दौरान उस कॉन्फ़िगरेशन फाइल के कुछ हिस्सों को पॉप्युलेट करना चाहते हैं।
उदाहरण के लिए, यदि आपका एप्लिकेशन निम्नलिखित कॉन्फ़िगरेशन फाइल का उपयोग करता है:
apiUrl: "https://my.api.com/api/v1"
username: "<user>"
password: "<password>"
आप इसे निम्नलिखित परिभाषा का उपयोग करके एक सीक्रेट में स्टोर कर सकते हैं:
apiVersion: v1
kind: Secret
metadata:
name: mysecret
type: Opaque
stringData:
config.yaml: |
apiUrl: "https://my.api.com/api/v1"
username: <user>
password: <password>
stringData फील्ड सर्वर-साइड एप्लाई के साथ अच्छी तरह से काम नहीं करता है।जब आप सीक्रेट डेटा प्राप्त करते हैं, तो कमांड एनकोडेड वैल्यू वापस करता है, न कि वे प्लेनटेक्स्ट वैल्यू जो आपने stringData में प्रदान किए थे।
उदाहरण के लिए, यदि आप निम्नलिखित कमांड चलाते हैं:
kubectl get secret mysecret -o yaml
आउटपुट इस तरह का होता है:
apiVersion: v1
data:
config.yaml: YXBpVXJsOiAiaHR0cHM6Ly9teS5hcGkuY29tL2FwaS92MSIKdXNlcm5hbWU6IHt7dXNlcm5hbWV9fQpwYXNzd29yZDoge3twYXNzd29yZH19
kind: Secret
metadata:
creationTimestamp: 2018-11-15T20:40:59Z
name: mysecret
namespace: default
resourceVersion: "7225"
uid: c280ad2e-e916-11e8-98f2-025000000001
type: Opaque
data और stringData दोनों निर्दिष्ट करेंयदि आप एक फील्ड को data और stringData दोनों में निर्दिष्ट करते हैं, तो stringData से वैल्यू का उपयोग किया जाता है।
उदाहरण के लिए, यदि आप निम्नलिखित सीक्रेट को परिभाषित करते हैं:
apiVersion: v1
kind: Secret
metadata:
name: mysecret
type: Opaque
data:
username: YWRtaW4=
stringData:
username: administrator
stringData फील्ड सर्वर-साइड एप्लाई के साथ अच्छी तरह से काम नहीं करता है।Secret ऑब्जेक्ट इस प्रकार बनाया जाता है:
apiVersion: v1
data:
username: YWRtaW5pc3RyYXRvcg==
kind: Secret
metadata:
creationTimestamp: 2018-11-15T20:46:46Z
name: mysecret
namespace: default
resourceVersion: "7579"
uid: 91460ecb-e917-11e8-98f2-025000000001
type: Opaque
YWRtaW5pc3RyYXRvcg== डिकोड होकर administrator बनता है।
मैनिफेस्ट का उपयोग करके बनाए गए सीक्रेट में डेटा को संपादित करने के लिए, अपने मैनिफेस्ट में data या stringData फील्ड को संशोधित करें और फाइल को अपने क्लस्टर में लागू करें। आप एक मौजूदा Secret ऑब्जेक्ट को संपादित कर सकते हैं जब तक कि वह अपरिवर्तनीय नहीं है।
उदाहरण के लिए, यदि आप पिछले उदाहरण से पासवर्ड को birdsarentreal में बदलना चाहते हैं, तो निम्नलिखित करें:
नई पासवर्ड स्ट्रिंग को एनकोड करें:
echo -n 'birdsarentreal' | base64
आउटपुट इस तरह का होता है:
YmlyZHNhcmVudHJlYWw=
अपनी नई पासवर्ड स्ट्रिंग के साथ data फील्ड को अपडेट करें:
apiVersion: v1
kind: Secret
metadata:
name: mysecret
type: Opaque
data:
username: YWRtaW4=
password: YmlyZHNhcmVudHJlYWw=
मैनिफेस्ट को अपने क्लस्टर में लागू करें:
kubectl apply -f ./secret.yaml
आउटपुट इस तरह का होता है:
secret/mysecret configured
कुबेरनेट्स मौजूदा Secret ऑब्जेक्ट को अपडेट करता है। विस्तार से, kubectl टूल नोटिस करता है कि समान नाम का एक मौजूदा Secret ऑब्जेक्ट है। kubectl मौजूदा ऑब्जेक्ट को प्राप्त करता है, उसमें परिवर्तनों की योजना बनाता है, और बदले हुए Secret ऑब्जेक्ट को आपके क्लस्टर कंट्रोल प्लेन को सबमिट करता है।
यदि आपने इसके बजाय kubectl apply --server-side निर्दिष्ट किया है, तो kubectl सर्वर साइड एप्लाई का उपयोग करता है।
आपके द्वारा बनाए गए सीक्रेट को हटाने के लिए:
kubectl delete secret mysecret
यह पृष्ठ दिखाता है कि कुबेरनेट्स पॉड में किसी कंटेनर के लिए निर्भर एनवायरनमेंट वेरिएबल्स कैसे परिभाषित करें।
आपको कुबरनेट्स क्लस्टर की ज़रूरत पड़ेगी और क्यूब सीटीएल कमांड लाइन साधन को समनुरूप करना होगा ताकि वो आपके क्लस्टर के साथ संवाद कर सकें। हमारी सलाह है की इस टुटोरिअल को क्लस्टर में रन करने के लिए कम से कम दो नोड का इस्तेमाल करे जो कि कंट्रोल प्लेन होस्ट के तरह ना एक्ट करे। अगर आपके पास पहले से क्लस्टर नही है, आप minikube की मदद से वह बना सकते है या आप नीचे दिए हुए इन दो कुबरनेट्स प्लेग्राउंड का इस्तेमाल कर सकते हैं:
जब आप एक पॉड बनाते हैं, तो आप उसमें चलने वाले कंटेनरों के लिए निर्भर एनवायरनमेंट वेरिएबल्स सेट कर सकते हैं। निर्भर एनवायरनमेंट वेरिएबल्स सेट करने के लिए, आप कॉन्फ़िगरेशन फ़ाइल में env की value में $(VAR_NAME) का उपयोग कर सकते हैं।
इस अभ्यास में, आप एक ऐसा पॉड बनाएंगे जो एक कंटेनर चलाता है।
पॉड के लिए कॉन्फ़िगरेशन फ़ाइल में एक निर्भर एनवायरनमेंट वेरिएबल्स परिभाषित किया गया है, जिसका सामान्य उपयोग निर्धारित किया गया है।पॉड के लिए कॉन्फ़िगरेशन मैनिफेस्ट इस प्रकार है:
apiVersion: v1
kind: Pod
metadata:
name: dependent-envars-demo
spec:
containers:
- name: dependent-envars-demo
args:
- while true; do echo -en '\n'; printf UNCHANGED_REFERENCE=$UNCHANGED_REFERENCE'\n'; printf SERVICE_ADDRESS=$SERVICE_ADDRESS'\n';printf ESCAPED_REFERENCE=$ESCAPED_REFERENCE'\n'; sleep 30; done;
command:
- sh
- -c
image: busybox:1.28
env:
- name: SERVICE_PORT
value: "80"
- name: SERVICE_IP
value: "172.17.0.1"
- name: UNCHANGED_REFERENCE
value: "$(PROTOCOL)://$(SERVICE_IP):$(SERVICE_PORT)"
- name: PROTOCOL
value: "https"
- name: SERVICE_ADDRESS
value: "$(PROTOCOL)://$(SERVICE_IP):$(SERVICE_PORT)"
- name: ESCAPED_REFERENCE
value: "$$(PROTOCOL)://$(SERVICE_IP):$(SERVICE_PORT)"
उस मैनिफेस्ट के आधार पर एक पॉड बनाएँ:
kubectl apply -f https://k8s.io/examples/pods/inject/dependent-envars.yaml
pod/dependent-envars-demo created
चल रहे पॉड्स की सूची देखें:
kubectl get pods dependent-envars-demo
NAME READY STATUS RESTARTS AGE
dependent-envars-demo 1/1 Running 0 9s
अपने पॉड में चल रहे कंटेनर के लॉग्स देखें:
kubectl logs pod/dependent-envars-demo
UNCHANGED_REFERENCE=$(PROTOCOL)://172.17.0.1:80
SERVICE_ADDRESS=https://172.17.0.1:80
ESCAPED_REFERENCE=$(PROTOCOL)://172.17.0.1:80
जैसा कि ऊपर दिखाया गया है, आपने SERVICE_ADDRESS के लिए एक सही डिपेंडेंसी रेफरेंस,UNCHANGED_REFERENCE के लिए एक गलत डिपेंडेंसी रेफरेंस, और ESCAPED_REFERENCE के लिए एक स्किप किया गया रेफरेंस परिभाषित किया है।
जब कोई एनवायरनमेंट वेरिएबल पहले से परिभाषित होता है और उसका रेफरेंस दिया जाता है,तो वह रेफरेंस सही तरीके से हल हो सकता है, जैसा कि SERVICE_ADDRESS के मामले में हुआ।
ध्यान दें कि env सूची में क्रम महत्वपूर्ण होता है।अगर कोई वेरिएबल सूची में नीचे परिभाषित है, तो उसे परिभाषित नहीं माना जाता।इसी कारण से UNCHANGED_REFERENCE $(PROTOCOL) को हल करने में विफल रहता है।
जब कोई एनवायरनमेंट वेरिएबल परिभाषित नहीं होता या उसमें कुछ वेरिएबल्स ही शामिल होते हैं,तो वह वेरिएबल एक सामान्य स्ट्रिंग की तरह माना जाता है, जैसे कि UNCHANGED_REFERENCE।
ध्यान दें कि सामान्यतः गलत तरीके से पार्स किए गए एनवायरनमेंट वेरिएबल्स कंटेनर को शुरू होने से नहीं रोकते।
$(VAR_NAME) सिंटैक्स को डबल $, जैसे $$(VAR_NAME) से एस्केप किया जा सकता है।एस्केप किए गए रेफरेंस कभी भी विस्तारित नहीं होते, चाहे संबंधित वेरिएबल परिभाषित हो या नहीं।यह ESCAPED_REFERENCE उदाहरण में देखा जा सकता है।
Kubernetes v1.18 [stable]
यह पेज दिखाता है कि Windows nodes पर चलने वाले Pods और containers के लिएrunAsUserName सेटिंग का उपयोग कैसे करें। यह लगभग Linux-विशिष्ट runAsUser
सेटिंग के समकक्ष है, जिससे आप container में applications को default username से
अलग username पर चला सकते हैं।
आपके पास Kubernetes cluster होना चाहिए और kubectl command-line tool आपके cluster से communicate करने के लिए configured होना चाहिए। cluster में Windows worker nodes होने चाहिए,जहाँ Windows workloads चलाने वाले containers वाले pods schedule किए जा सकें।
Pod के container processes किस username से execute हों, यह बताने के लिए Pod specification मेंsecurityContext field (PodSecurityContext)शामिल करें, और उसके अंदर windowsOptions
(WindowsSecurityContextOptions)field में runAsUserName field दें।
Pod के लिए जो Windows security context options आप specify करते हैं, वे Pod के सभी Containers और init Containers पर लागू होते हैं।
यहाँ Windows Pod की configuration file है जिसमें runAsUserName field सेट है:
apiVersion: v1
kind: Pod
metadata:
name: run-as-username-pod-demo
spec:
securityContext:
windowsOptions:
runAsUserName: "ContainerUser"
containers:
- name: run-as-username-demo
image: mcr.microsoft.com/windows/servercore:ltsc2019
command: ["ping", "-t", "localhost"]
nodeSelector:
kubernetes.io/os: windows
Pod बनाएं:
kubectl apply -f https://k8s.io/examples/windows/run-as-username-pod.yaml
जांचें कि Pod का Container चल रहा है:
kubectl get pod run-as-username-pod-demo
चल रहे Container में shell खोलें:
kubectl exec -it run-as-username-pod-demo -- powershell
जांचें कि shell सही username के रूप में चल रही है:
echo $env:USERNAME
आउटपुट यह होना चाहिए:
ContainerUser
Container के processes किस username से execute हों, यह बताने के लिए Container manifest मेंsecurityContext field (SecurityContext)शामिल करें, और उसके अंदर windowsOptions
(WindowsSecurityContextOptions)field में runAsUserName field दें।
Container के लिए जो Windows security context options आप specify करते हैं, वे केवल उसी Container पर लागू होते हैं, और Pod level पर की गई settings को override करते हैं।
यहाँ Pod की configuration file है जिसमें एक Container है, और runAsUserName field
Pod level तथा Container level दोनों पर सेट है:
apiVersion: v1
kind: Pod
metadata:
name: run-as-username-container-demo
spec:
securityContext:
windowsOptions:
runAsUserName: "ContainerUser"
containers:
- name: run-as-username-demo
image: mcr.microsoft.com/windows/servercore:ltsc2019
command: ["ping", "-t", "localhost"]
securityContext:
windowsOptions:
runAsUserName: "ContainerAdministrator"
nodeSelector:
kubernetes.io/os: windows
Pod बनाएं:
kubectl apply -f https://k8s.io/examples/windows/run-as-username-container.yaml
जांचें कि Pod का Container चल रहा है:
kubectl get pod run-as-username-container-demo
चल रहे Container में shell खोलें:
kubectl exec -it run-as-username-container-demo -- powershell
जांचें कि shell सही username के रूप में चल रही है (यानी वही जो Container level पर सेट है):
echo $env:USERNAME
आउटपुट यह होना चाहिए:
ContainerAdministrator
इस feature का उपयोग करने के लिए runAsUserName field में दिया गया मान एक वैध username होना चाहिए।यह format DOMAIN\USER में होना चाहिए, जहाँ DOMAIN\ वैकल्पिक है। Windows usernames case insensitive होते हैं।इसके अलावा DOMAIN और USER के संबंध में कुछ प्रतिबंध हैं:
runAsUserName field खाली नहीं हो सकती और इसमें control characters (ASCII values: 0x00-0x1F, 0x7F) नहीं होने चाहिए।DOMAIN या तो NetBios नाम होना चाहिए या DNS नाम, और दोनों पर अलग-अलग सीमाएँ लागू होती हैं:
. (dot) से शुरू नहीं होना चाहिए, और इन characters को शामिल नहीं कर सकता: \ / : * ? " < > |. (dot) या - (dash) से शुरू/समाप्त न हो।USER अधिकतम 20 characters का होना चाहिए, केवल dots या spaces से बना नहीं होना चाहिए, और इनमें से कोई character शामिल नहीं होना चाहिए: " / \ [ ] : ; | = , + * ? < > @।runAsUserName field के स्वीकार्य मानों के उदाहरण:ContainerAdministrator, ContainerUser, NT AUTHORITY\NETWORK SERVICE, NT AUTHORITY\LOCAL SERVICE।
इन सीमाओं के बारे में अधिक जानकारी के लिए here और here देखें।
यह पेज कुबेरनेट्स पर Antrea CNI प्लगइन को कैसे इंस्टॉल और उपयोग करें, यह दिखाता है।प्रोजेक्ट Antrea की पृष्ठभूमि के लिए, Antrea का परिचय पढ़ें।
आपके पास एक कुबेरनेट्स क्लस्टर होना चाहिए। एक क्लस्टर को बूटस्ट्रैप करने के लिएkubeadm आरंभ करने की गाइड का पालन करें।
kubeadm के लिए Antrea को डिप्लॉय करने के लिए आरंभ करने की गाइड का पालन करें।
एक बार जब आपका क्लस्टर चल रहा हो, तो आप कुबेरनेट्स नेटवर्कपॉलिसी को आज़माने के लिए नेटवर्क पॉलिसी घोषित करें का पालन कर सकते हैं।
यह पेज कुबेरनेट्स पर Calico क्लस्टर बनाने के कुछ त्वरित तरीके दिखाता है।
तय करें कि आप cloud या local क्लस्टर डिप्लॉय करना चाहते हैं।
पूर्वापेक्षा: gcloud।
Calico के साथ GKE क्लस्टर लॉन्च करने के लिए, --enable-network-policy फ्लैग शामिल करें।
सिंटैक्स
gcloud container clusters create [CLUSTER_NAME] --enable-network-policy
उदाहरण
gcloud container clusters create my-calico-cluster --enable-network-policy
डिप्लॉयमेंट को सत्यापित करने के लिए, निम्नलिखित कमांड का उपयोग करें।
kubectl get pods --namespace=kube-system
Calico पॉड्स calico से शुरू होते हैं। जांचें कि प्रत्येक की स्थिति Running है।
kubeadm का उपयोग करके पंद्रह मिनट में एक लोकल सिंगल-होस्ट Calico क्लस्टर प्राप्त करने के लिए,Calico क्विकस्टार्ट देखें।
एक बार जब आपका क्लस्टर चल रहा हो, तो आप कुबेरनेट्स नेटवर्कपॉलिसी को आज़माने के लिए नेटवर्क पॉलिसी घोषित करें का पालन कर सकते हैं।
यह पेज दिखाता है कि storage के लिए Volume उपयोग करने हेतु Pod को कैसे कॉन्फ़िगर करें।
किसी Container का file system केवल उतनी देर तक रहता है जितनी देर Container रहता है।इसलिए जब कोई Container terminate होकर फिर restart होता है, तो filesystem में किए गए बदलाव खो जाते हैं।Container से स्वतंत्र और अधिक consistent storage के लिए आपVolume का उपयोग कर सकते हैं।यह stateful applications (जैसे key-value stores, उदाहरण के लिए Redis, और databases) के लिए विशेष रूप से महत्वपूर्ण है।
आपको कुबरनेट्स क्लस्टर की ज़रूरत पड़ेगी और क्यूब सीटीएल कमांड लाइन साधन को समनुरूप करना होगा ताकि वो आपके क्लस्टर के साथ संवाद कर सकें। हमारी सलाह है की इस टुटोरिअल को क्लस्टर में रन करने के लिए कम से कम दो नोड का इस्तेमाल करे जो कि कंट्रोल प्लेन होस्ट के तरह ना एक्ट करे। अगर आपके पास पहले से क्लस्टर नही है, आप minikube की मदद से वह बना सकते है या आप नीचे दिए हुए इन दो कुबरनेट्स प्लेग्राउंड का इस्तेमाल कर सकते हैं:
संस्करण की जांच करने के लिए, लिखें kubectl version.
इस अभ्यास में आप ऐसा Pod बनाते हैं जिसमें एक Container चलता है। इस Pod मेंemptyDir प्रकार का Volume होता है जो Pod के जीवनकाल तक बना रहता है, भले ही Container terminate होकर restart हो जाए।यह Pod की configuration file है:
apiVersion: v1
kind: Pod
metadata:
name: redis
spec:
containers:
- name: redis
image: redis
volumeMounts:
- name: redis-storage
mountPath: /data/redis
volumes:
- name: redis-storage
emptyDir: {}
Pod बनाएं:
kubectl apply -f https://k8s.io/examples/pods/storage/redis.yaml
जांचें कि Pod का Container चल रहा है, और फिर Pod में होने वाले बदलाव देखें:
kubectl get pod redis --watch
आउटपुट इस तरह दिखेगा:
NAME READY STATUS RESTARTS AGE
redis 1/1 Running 0 13s
दूसरे terminal में, चल रहे Container का shell खोलें:
kubectl exec -it redis -- /bin/bash
अपनी shell में /data/redis पर जाएँ, और फिर एक फ़ाइल बनाएं:
root@redis:/data# cd /data/redis/
root@redis:/data/redis# echo Hello > test-file
अपनी shell में चल रही processes की सूची देखें:
root@redis:/data/redis# apt-get update
root@redis:/data/redis# apt-get install procps
root@redis:/data/redis# ps aux
आउटपुट इस तरह होगा:
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
redis 1 0.1 0.1 33308 3828 ? Ssl 00:46 0:00 redis-server *:6379
root 12 0.0 0.0 20228 3020 ? Ss 00:47 0:00 /bin/bash
root 15 0.0 0.0 17500 2072 ? R+ 00:48 0:00 ps aux
अपनी shell में Redis process को kill करें:
root@redis:/data/redis# kill <pid>
जहाँ <pid> Redis process ID (PID) है।
अपने मूल terminal में Redis Pod में होने वाले बदलाव देखें। अंततः आपको कुछ ऐसा दिखाई देगा:
NAME READY STATUS RESTARTS AGE
redis 1/1 Running 0 13s
redis 0/1 Completed 0 6m
redis 1/1 Running 1 6m
इस बिंदु पर Container terminate होकर restart हो चुका है। ऐसा इसलिए है क्योंकि
Redis Pod कीrestartPolicy
Always है।
restarted Container के अंदर shell खोलें:
kubectl exec -it redis -- /bin/bash
अपनी shell में /data/redis पर जाएँ, और सत्यापित करें कि test-file अभी भी मौजूद है।
root@redis:/data/redis# cd /data/redis/
root@redis:/data/redis# ls
test-file
इस अभ्यास के लिए बनाया गया Pod हटाएं:
kubectl delete pod redis
Volume देखें।
Pod देखें।
emptyDir द्वारा दिए गए local disk storage के अलावा, Kubernetes कई प्रकार के
network-attached storage solutions को सपोर्ट करता है, जिनमें GCE पर PD और EC2 पर EBS शामिल हैं।ये critical data के लिए अधिक उपयुक्त हैं और nodes पर devices को mount/unmount करने जैसे
विवरण संभालते हैं। अधिक जानकारी के लिएVolumes देखें।
यह पेज दिखाता है कि एक ही directory में कई मौजूदा volume sources को mount करने के लिएprojected Volume का उपयोग कैसे करें।वर्तमान में secret, configMap, downwardAPI और serviceAccountToken volumes को project किया जा सकता है।
serviceAccountToken कोई volume type नहीं है।आपको कुबरनेट्स क्लस्टर की ज़रूरत पड़ेगी और क्यूब सीटीएल कमांड लाइन साधन को समनुरूप करना होगा ताकि वो आपके क्लस्टर के साथ संवाद कर सकें। हमारी सलाह है की इस टुटोरिअल को क्लस्टर में रन करने के लिए कम से कम दो नोड का इस्तेमाल करे जो कि कंट्रोल प्लेन होस्ट के तरह ना एक्ट करे। अगर आपके पास पहले से क्लस्टर नही है, आप minikube की मदद से वह बना सकते है या आप नीचे दिए हुए इन दो कुबरनेट्स प्लेग्राउंड का इस्तेमाल कर सकते हैं:
संस्करण की जांच करने के लिए, लिखें kubectl version.
इस अभ्यास में आप local files से username और password वाले Secrets बनाते हैं।फिर आप एक ऐसा Pod बनाते हैं जिसमें एक container चलता है, और projected Volume का उपयोग करके
Secrets को उसी shared directory में mount किया जाता है।
यह Pod की configuration file है:
apiVersion: v1
kind: Pod
metadata:
name: test-projected-volume
spec:
containers:
- name: test-projected-volume
image: busybox:1.28
args:
- sleep
- "86400"
volumeMounts:
- name: all-in-one
mountPath: "/projected-volume"
readOnly: true
volumes:
- name: all-in-one
projected:
sources:
- secret:
name: user
- secret:
name: pass
Secrets बनाएं:
# Create files containing the username and password:
echo -n "admin" > ./username.txt
echo -n "1f2d1e2e67df" > ./password.txt
# Package these files into secrets:
kubectl create secret generic user --from-file=./username.txt
kubectl create secret generic pass --from-file=./password.txt
Pod बनाएं:
kubectl apply -f https://k8s.io/examples/pods/storage/projected.yaml
जांचें कि Pod का container चल रहा है, और फिर Pod में होने वाले बदलाव देखें:
kubectl get --watch pod test-projected-volume
आउटपुट इस तरह दिखेगा:
NAME READY STATUS RESTARTS AGE
test-projected-volume 1/1 Running 0 14s
दूसरे terminal में, चल रहे container का shell खोलें:
kubectl exec -it test-projected-volume -- /bin/sh
अपनी shell में, जांचें कि projected-volume directory में आपके projected sources मौजूद हैं:
ls /projected-volume/
Pod और Secrets हटाएँ:
kubectl delete pod test-projected-volume
kubectl delete secret user pass
projected volumes के बारे में और जानें।Kubernetes उन clients के लिए, जो आपके cluster के भीतर चलते हैं या जिनका आपके cluster के control plane से किसी प्रकार का संबंध होता है, authentication के दो अलग तरीके प्रदान करता है ताकि वे API server से प्रमाणित हो सकें।
एक service account Pod में चलने वाली processes के लिए identity प्रदान करता है,और यह ServiceAccount object से map होता है। जब आप API server से authenticate करते हैं,तो आप स्वयं को एक विशेष user के रूप में पहचानते हैं। Kubernetes user की अवधारणा को पहचानता है,लेकिन स्वयं Kubernetes में User API नहीं है।
यह task guide ServiceAccounts के बारे में है, जो Kubernetes API में मौजूद हैं।यह guide आपको Pods के लिए ServiceAccounts कॉन्फ़िगर करने के कुछ तरीके दिखाती है।
आपको कुबरनेट्स क्लस्टर की ज़रूरत पड़ेगी और क्यूब सीटीएल कमांड लाइन साधन को समनुरूप करना होगा ताकि वो आपके क्लस्टर के साथ संवाद कर सकें। हमारी सलाह है की इस टुटोरिअल को क्लस्टर में रन करने के लिए कम से कम दो नोड का इस्तेमाल करे जो कि कंट्रोल प्लेन होस्ट के तरह ना एक्ट करे। अगर आपके पास पहले से क्लस्टर नही है, आप minikube की मदद से वह बना सकते है या आप नीचे दिए हुए इन दो कुबरनेट्स प्लेग्राउंड का इस्तेमाल कर सकते हैं:
जब Pods API server से संपर्क करते हैं, तो वे किसी विशेष ServiceAccount(उदाहरण के लिए default) के रूप में authenticate करते हैं।हर namespace में हमेशा कम से कम एक ServiceAccount होता है।
हर Kubernetes namespace में कम से कम एक ServiceAccount होता है:उस namespace का default ServiceAccount, जिसका नाम default होता है।अगर आप Pod बनाते समय ServiceAccount specify नहीं करते,तो Kubernetes उस namespace का default ServiceAccount अपने-आप असाइन कर देता है।
आप अपने बनाए Pod का विवरण प्राप्त कर सकते हैं। उदाहरण के लिए:
kubectl get pods/<podname> -o yaml
आउटपुट में आपको spec.serviceAccountName field दिखाई देगी।अगर Pod बनाते समय आप यह मान सेट नहीं करते, तो Kubernetes इसे अपने-आप सेट करता है।
Pod के अंदर चल रहा application, automatically mounted service account credentials का उपयोग करके Kubernetes API तक पहुँच सकता है।अधिक जानने के लिए accessing the Cluster देखें।
जब Pod, ServiceAccount के रूप में authenticate करता है, तो उसका access level उपयोग में मौजूद authorization plugin and policy पर निर्भर करता है।
Pod delete होने पर API credentials अपने-आप revoke हो जाते हैं, भले ही
finalizers लगे हों। विशेष रूप से, Pod पर .metadata.deletionTimestamp सेट होने के 60 seconds बाद
API credentials revoke हो जाते हैं (deletion timestamp आमतौर पर वह समय होता है जब delete
request स्वीकार की गई, plus Pod का termination grace period)।
अगर आप नहीं चाहते कि kubelet
ServiceAccount की API credentials अपने-आप mount करे, तो आप default behavior से बाहर निकल सकते हैं।आप service account पर automountServiceAccountToken: false सेट करके/var/run/secrets/kubernetes.io/serviceaccount/token पर API credentials की automounting बंद कर सकते हैं:
उदाहरण के लिए:
apiVersion: v1
kind: ServiceAccount
metadata:
name: build-robot
automountServiceAccountToken: false
...
आप किसी विशेष Pod के लिए भी API credentials की automounting बंद कर सकते हैं:
apiVersion: v1
kind: Pod
metadata:
name: my-pod
spec:
serviceAccountName: build-robot
automountServiceAccountToken: false
...
यदि ServiceAccount और Pod की .spec दोनों मेंautomountServiceAccountToken का मान दिया गया है, तो Pod spec को प्राथमिकता मिलती है।
हर namespace में कम से कम एक ServiceAccount होता है: default ServiceAccount
resource, जिसका नाम default है। आपवर्तमान namespace
में सभी ServiceAccount resources की सूची इस तरह देख सकते हैं:
kubectl get serviceaccounts
आउटपुट इस प्रकार होगा:
NAME SECRETS AGE
default 1 1d
आप अतिरिक्त ServiceAccount objects इस तरह बना सकते हैं:
kubectl apply -f - <<EOF
apiVersion: v1
kind: ServiceAccount
metadata:
name: build-robot
EOF
ServiceAccount object का नाम एक वैधDNS subdomain name होना चाहिए।
अगर आप service account object का पूरा dump ऐसे लेते हैं:
kubectl get serviceaccounts/build-robot -o yaml
तो आउटपुट इस तरह होगा:
apiVersion: v1
kind: ServiceAccount
metadata:
creationTimestamp: 2019-06-16T00:12:34Z
name: build-robot
namespace: default
resourceVersion: "272500"
uid: 721ab723-13bc-11e5-aec2-42010af0021e
आप authorization plugins का उपयोग करकेservice accounts पर permissions सेट कर सकते हैं।
non-default service account का उपयोग करने के लिए Pod के spec.serviceAccountName
field में उस ServiceAccount का नाम सेट करें जिसे आप उपयोग करना चाहते हैं।
आप serviceAccountName field केवल Pod बनाते समय या नए Pod के template में ही सेट कर सकते हैं।पहले से मौजूद Pod की .spec.serviceAccountName field अपडेट नहीं की जा सकती।
.spec.serviceAccount field, .spec.serviceAccountName का deprecated alias है।अगर आप workload resource से fields हटाना चाहते हैं, तो pod template
पर दोनों fields को स्पष्ट रूप से empty सेट करें।अगर आपने ऊपर के उदाहरण से build-robot ServiceAccount बनाया है,तो इसे हटाने के लिए यह चलाएँ:
kubectl delete serviceaccount/build-robot
मान लीजिए आपके पास पहले बताए अनुसार "build-robot" नाम का service account मौजूद है।
आप kubectl से उस ServiceAccount के लिए time-limited API token प्राप्त कर सकते हैं:
kubectl create token build-robot
इस command का आउटपुट एक token होता है, जिससे आप उस
ServiceAccount के रूप में authenticate कर सकते हैं। आप kubectl create token में--duration command line argument देकर token की विशेष duration मांग सकते हैं(हालांकि वास्तविक issued token duration छोटी भी हो सकती है या कभी-कभी लंबी भी)।
Kubernetes v1.33 [stable](enabled by default)kubectl v1.31 या बाद के version में आप ऐसा service account token बना सकते हैं
जो सीधे किसी Node से bound हो:
kubectl create token build-robot --bound-object-kind Node --bound-object-name node-001 --bound-object-uid 123...456
token तब तक वैध रहेगा जब तक वह expire न हो जाए, या उससे संबंधित Node या service account delete न हो जाए।
Kubernetes v1.22 से पहले के versions Kubernetes API access करने के लिए long term credentials स्वतः बनाते थे। यह पुराना तरीका token Secrets बनाने पर आधारित था जिन्हें फिर running Pods में mount किया जा सकता था।अधिक नए versions में, जिनमें Kubernetes v1.35 भी शामिल है, API credentials सीधेTokenRequest API के जरिए प्राप्त की जाती हैं,और इन्हें Pods मेंprojected volume (प्रोजेक्टेड वॉल्यूम) के जरिए mount किया जाता है।इस तरीके से प्राप्त tokens की सीमित lifetime होती है, और जिस Pod में वे mount हैं उसके delete होने पर वे स्वतः invalid हो जाते हैं।
आप फिर भी manually service account token Secret बना सकते हैं; उदाहरण के लिए अगर आपको ऐसा token चाहिए जो कभी expire न हो। हालांकि API access के लिए token लेने का recommended तरीका TokenRequest subresource ही है।
अगर आप ServiceAccount के लिए API token लेना चाहते हैं, तो आपको
एक नई Secret बनानी होगी जिसमें special annotation kubernetes.io/service-account.name हो।
kubectl apply -f - <<EOF
apiVersion: v1
kind: Secret
metadata:
name: build-robot-secret
annotations:
kubernetes.io/service-account.name: build-robot
type: kubernetes.io/service-account-token
EOF
अगर आप Secret को इस तरह देखें:
kubectl get secret/build-robot-secret -o yaml
तो आप देखेंगे कि अब इस Secret में "build-robot" ServiceAccount के लिए API token मौजूद है।
आपके द्वारा सेट annotation की वजह से control plane उस ServiceAccount के लिए अपने-आप token बनाता है और उसे संबंधित Secret में store करता है। control plane delete किए गए ServiceAccounts के tokens भी साफ करता है।
kubectl describe secrets/build-robot-secret
आउटपुट इस तरह होगा:
Name: build-robot-secret
Namespace: default
Labels: <none>
Annotations: kubernetes.io/service-account.name: build-robot
kubernetes.io/service-account.uid: da68f9c6-9d26-11e7-b84e-002dc52800da
Type: kubernetes.io/service-account-token
Data
====
ca.crt: 1338 bytes
namespace: 7 bytes
token: ...
यहाँ token की सामग्री छोड़ी गई है।
ध्यान रखें कि kubernetes.io/service-account-token Secret की सामग्री ऐसी जगह display न करें
जहाँ कोई अन्य व्यक्ति आपकी terminal/computer screen देख सके।
जब आप associated Secret वाले ServiceAccount को delete करते हैं, तो Kubernetes control plane उस Secret से long-lived token अपने-आप साफ कर देता है।
अगर आप ServiceAccount को इस तरह देखते हैं:
kubectl get serviceaccount build-robot -o yaml
तो ServiceAccount API object के.secrets field में
आपको build-robot-secret Secret नहीं दिखेगी, क्योंकि वह field केवल auto-generated Secrets से भरी जाती है।
पहले, imagePullSecret बनाएं।फिर जांचें कि वह बन चुकी है। उदाहरण के लिए:
imagePullSecret बनाएं, जैसा किSpecifying ImagePullSecrets on a Pod में बताया गया है।
kubectl create secret docker-registry myregistrykey --docker-server=<registry name> \
--docker-username=DUMMY_USERNAME --docker-password=DUMMY_DOCKER_PASSWORD \
--docker-email=DUMMY_DOCKER_EMAIL
जांचें कि यह बन चुकी है।
kubectl get secrets myregistrykey
आउटपुट इस तरह होगा:
NAME TYPE DATA AGE
myregistrykey kubernetes.io/.dockerconfigjson 1 1d
अब namespace के default service account को modify करें ताकि वह इस Secret को imagePullSecret के रूप में उपयोग करे।
kubectl patch serviceaccount default -p '{"imagePullSecrets": [{"name": "myregistrykey"}]}'
आप object को manually edit करके भी यही परिणाम पा सकते हैं:
kubectl edit serviceaccount/default
sa.yaml file का आउटपुट कुछ ऐसा होगा:
आपके चुने हुए text editor में कुछ इस तरह की configuration खुलेगी:
apiVersion: v1
kind: ServiceAccount
metadata:
creationTimestamp: 2021-07-07T22:02:39Z
name: default
namespace: default
resourceVersion: "243024"
uid: 052fb0f4-3d50-11e5-b066-42010af0d7b6
अपने editor का उपयोग करके resourceVersion key वाली line हटाएँ, imagePullSecrets:
के लिए lines जोड़ें और save करें। uid value को उसी तरह रहने दें जैसा मिला था।
इन बदलावों के बाद edited ServiceAccount कुछ ऐसा दिखेगा:
apiVersion: v1
kind: ServiceAccount
metadata:
creationTimestamp: 2021-07-07T22:02:39Z
name: default
namespace: default
uid: 052fb0f4-3d50-11e5-b066-42010af0d7b6
imagePullSecrets:
- name: myregistrykey
अब जब current namespace में default ServiceAccount का उपयोग करते हुए नया Pod बनाया जाएगा,तो नए Pod की spec.imagePullSecrets field अपने-आप सेट होगी:
kubectl run nginx --image=<registry name>/nginx --restart=Never
kubectl get pod nginx -o=jsonpath='{.spec.imagePullSecrets[0].name}{"\n"}'
आउटपुट:
myregistrykey
Kubernetes v1.20 [stable]
token request projection को enable और उपयोग करने के लिए, आपको kube-apiserver में
निम्न command line arguments specify करने होंगे:
--service-account-issuer--service-account-issuer argument कई बार दे सकते हैं; यह issuer को बिना बाधा बदलेने के लिए उपयोगी हो सकता है।जब यह flag कई बार दिया जाता है, तो पहला token generate करने के लिए उपयोग होता है और सभी values
accepted issuers तय करने के लिए उपयोग होती हैं। --service-account-issuer को कई बार
specify करने के लिए Kubernetes v1.22 या बाद का version आवश्यक है।--service-account-key-file--service-account-signing-key-file--api-audiences (छोड़ा जा सकता है)api-audiences कई बार दिया जाए, तो किसी भी निर्दिष्ट audience के tokens Kubernetes API server द्वारा वैध माने जाते हैं।यदि आप --service-account-issuer सेट करते हैं लेकिन --api-audiences नहीं सेट करते,तो control plane default रूप से एक single-element audience list उपयोग करता है जिसमें केवल issuer URL होता है।kubelet ServiceAccount token को Pod में project भी कर सकता है। आप token की वांछित properties (जैसे audience और validity duration) specify कर सकते हैं।ये properties default ServiceAccount token पर configurable नहीं होतीं।Pod या ServiceAccount में से किसी एक के delete होने पर token API के लिए invalid हो जाएगा।
Pod की spec में आप यह behaviorprojected volume (प्रोजेक्टेड वॉल्यूम) typeServiceAccountToken का उपयोग करके कॉन्फ़िगर कर सकते हैं।
इस projected volume का token एक JSON Web Token (JWT) होता है।इस token का JSON payload एक well-defined schema का पालन करता है। Pod-bound token का उदाहरण payload:
{
"aud": [ # matches the requested audiences, or the API server's default audiences when none are explicitly requested
"https://kubernetes.default.svc"
],
"exp": 1731613413,
"iat": 1700077413,
"iss": "https://kubernetes.default.svc", # matches the first value passed to the --service-account-issuer flag
"jti": "ea28ed49-2e11-4280-9ec5-bc3d1d84661a",
"kubernetes.io": {
"namespace": "kube-system",
"node": {
"name": "127.0.0.1",
"uid": "58456cb0-dd00-45ed-b797-5578fdceaced"
},
"pod": {
"name": "coredns-69cbfb9798-jv9gn",
"uid": "778a530c-b3f4-47c0-9cd5-ab018fb64f33"
},
"serviceaccount": {
"name": "coredns",
"uid": "a087d5a0-e1dd-43ec-93ac-f13d89cd13af"
},
"warnafter": 1700081020
},
"nbf": 1700077413,
"sub": "system:serviceaccount:kube-system:coredns"
}
Pod को vault audience और दो घंटे की validity duration वाला token देने के लिए
आप ऐसा Pod manifest define कर सकते हैं:
apiVersion: v1
kind: Pod
metadata:
name: nginx
spec:
containers:
- image: nginx
name: nginx
volumeMounts:
- mountPath: /var/run/secrets/tokens
name: vault-token
serviceAccountName: build-robot
volumes:
- name: vault-token
projected:
sources:
- serviceAccountToken:
path: vault-token
expirationSeconds: 7200
audience: vault
Pod बनाएं:
kubectl create -f https://k8s.io/examples/pods/pod-projected-svc-token.yaml
kubelet यह करेगा: Pod की ओर से token request और store करेगा;token को Pod में configurable file path पर उपलब्ध कराएगा;और expiration के करीब आते ही token refresh करेगा।यदि token अपनी कुल time-to-live (TTL) का 80% से पुराना हो जाए,या token 24 घंटे से पुराना हो, तो kubelet proactively rotation request करता है।
token rotate होने पर application को token reload करना जिम्मेदारी है।अक्सर application के लिए token को schedule पर reload करना पर्याप्त होता है(उदाहरण: हर 5 मिनट), बिना वास्तविक expiry time track किए।
Kubernetes v1.21 [stable]
यदि आपने अपने cluster में ServiceAccounts के लिएtoken projection enable किया है,तो आप discovery feature भी उपयोग कर सकते हैं। Kubernetes clients कोidentity provider की तरह federate करने का तरीका देता है, ताकि एक या अधिक external systems relying party की तरह काम कर सकें।
issuer URL कोOIDC Discovery Spec का पालन करना चाहिए।व्यवहार में इसका अर्थ है कि URL https scheme का उपयोग करे और{service-account-issuer}/.well-known/openid-configuration पर OpenID provider configuration serve करे।
यदि URL इसका पालन नहीं करता, तो ServiceAccount issuer discovery endpoints register या accessible नहीं होंगे।
enable होने पर Kubernetes API server HTTP के जरिए OpenID Provider
Configuration document publish करता है। यह document/.well-known/openid-configuration पर उपलब्ध होता है।OpenID Provider Configuration को कभी-कभी discovery document भी कहा जाता है।Kubernetes API server इससे संबंधित JSON Web Key Set (JWKS) भी HTTP के जरिए/openid/v1/jwks पर publish करता है।
/.well-known/openid-configuration और /openid/v1/jwks पर मिलने वाले responses
OIDC compatible होने के लिए डिज़ाइन किए गए हैं, लेकिन strictly OIDC compliant नहीं हैं।इन documents में केवल वे parameters होते हैं जो Kubernetes service account tokens को
validate करने के लिए आवश्यक हैं।जो clusters RBAC का उपयोग करते हैं, उनमेंsystem:service-account-issuer-discovery नाम का एक default ClusterRole शामिल होता है।एक default ClusterRoleBinding यह role system:serviceaccounts group को assign करता है,जिससे सभी ServiceAccounts निहित रूप से जुड़े होते हैं।इससे cluster पर चल रहे pods अपने mounted service account token के जरिए
service account discovery document access कर सकते हैं।इसके अतिरिक्त administrators अपनी सुरक्षा आवश्यकताओं और जिन external systems से वे federate करना चाहते हैं,उनके आधार पर इस role को system:authenticated या system:unauthenticated से भी bind कर सकते हैं।
JWKS response में public keys होती हैं जिन्हें relying party Kubernetes service account tokens
validate करने के लिए उपयोग कर सकती है। Relying parties पहले OpenID Provider Configuration query करती हैं,और response में jwks_uri field का उपयोग करके JWKS location प्राप्त करती हैं।
कई स्थितियों में Kubernetes API servers public internet पर उपलब्ध नहीं होते,लेकिन API server से cached responses serve करने वाले public endpoints users या service providers द्वारा उपलब्ध कराए जा सकते हैं।ऐसे मामलों में OpenID Provider Configuration में jwks_uri को override किया जा सकता है ताकि वह API server address के बजाय
public endpoint पर point करे। इसके लिए API server पर --service-account-jwks-uri flag पास किया जाता है।issuer URL की तरह JWKS URI में भी https scheme आवश्यक है।
यह भी देखें:
यह पृष्ठ दिखाता है कि क्यूबलेट के लिए प्रमाणपत्र आवर्तन कैसे सक्षम और कॉन्फ़िगर कर सकते है।
Kubernetes v1.19 [stable]
क्यूबलेट प्रमाणपत्रों का उपयोग कुबरनेट्स API के साथ प्रमाणित करने के लिए करता है। डिफ़ॉल्ट रूप से, ये प्रमाणपत्र एक वर्ष की समाप्ति के साथ जारी किए जाते हैं ताकि उन्हें बार-बार नवीनीकृत करने की आवश्यकता न हो।
कुबरनेट्स में क्यूबलेट प्रमाणपत्र आवर्तन शामिल है, जो स्वचालित रूप से एक नई कुंजी उत्पन्न करेगा जो स्वचालित रूप से एक नई कुंजी उत्पन्न करेगा और वर्तमान प्रमाणपत्र की समाप्ति के करीब आने पर कुबरनेट्स API से एक नया प्रमाणपत्र अनुरोध करेगा। एक बार नया प्रमाणपत्र उपलब्ध हो जाने पर, यह कुबरनेट्स API के साथ कनेक्शन को प्रमाणित करने के लिए उपयोग किया जाएगा।
kubelet प्रक्रिया एक प्राचल --rotate-certificates स्वीकार करती है जो नियंत्रित करती है कि क्या कुबलेट स्वचालित रूप से वर्तमान में उपयोग किए जा रहे प्रमाणपत्र की समाप्ति के करीब आने पर एक नया प्रमाणपत्र अनुरोध करेगा।
kube-controller-manager प्रक्रिया एक प्राचल स्वीकार करती है
--cluster-signing-duration (--experimental-cluster-signing-duration 1.19 से पहले)जो नियंत्रित करता है कि प्रमाणपत्र कितने समय के लिए जारी किए जाएंगे।
जब एक कुबलेट शुरू होता है, यदि इसे बूटस्ट्रैप करने के लिए कॉन्फ़िगर किया गया है (उपयोग करते हुए
--bootstrap-kubeconfig फ्लैग), तो यह कुबरनेट्स API से कनेक्ट करने और एक प्रमाणपत्र हस्ताक्षर अनुरोध जारी करने के लिए अपने प्रारंभिक प्रमाणपत्र का उपयोग करेगा। आप प्रमाणपत्र हस्ताक्षर अनुरोधों की स्थिति देख सकते हैं:
kubectl get csr
शुरुआत में, किसी नोड पर कुबलेट से एक प्रमाणपत्र हस्ताक्षर अनुरोध की स्थिति Pending होगी।
यदि प्रमाणपत्र हस्ताक्षर अनुरोध विशिष्ट मानदंडों को पूरा करता है, तो इसे नियंत्रक प्रबंधक द्वारा स्वचालित रूप से अनुमोदित किया जाएगा, और फिर इसकी स्थिति Approved होगी।
इसके बाद, नियंत्रक प्रबंधक एक प्रमाणपत्र पर हस्ताक्षर करेगा, जो
--cluster-signing-duration पैरामीटर द्वारा निर्दिष्ट अवधि के लिए जारी किया जाएगा, और हस्ताक्षरित प्रमाणपत्र को प्रमाणपत्र हस्ताक्षर अनुरोध से जोड़ा जाएगा।
कुबलेट कुबरनेट्स API से हस्ताक्षरित प्रमाणपत्र प्राप्त करेगा और इसे डिस्क पर लिखेगा,
--cert-dir द्वारा निर्दिष्ट स्थान में। फिर कुबलेट कुबरनेट्स API से कनेक्ट करने के लिए नए प्रमाणपत्र का उपयोग करेगा।
जैसे ही हस्ताक्षरित प्रमाणपत्र की समाप्ति निकट आती है, कुबलेट स्वचालित रूप से कुबरनेट्स API का उपयोग करके एक नया प्रमाणपत्र हस्ताक्षर अनुरोध जारी करेगा। यह प्रमाणपत्र पर शेष समय के 30% और 10% के बीच किसी भी बिंदु पर हो सकता है। फिर से, नियंत्रक प्रबंधक स्वचालित रूप से प्रमाणपत्र अनुरोध को अनुमोदित करेगा और प्रमाणपत्र हस्ताक्षर अनुरोध से एक हस्ताक्षरित प्रमाणपत्र जोड़ेगा। कुबलेट कुबरनेट्स API से नया हस्ताक्षरित प्रमाणपत्र प्राप्त करेगा और इसे डिस्क पर लिखेगा। फिर यह कुबरनेट्स API के साथ कनेक्शन को नए प्रमाणपत्र का उपयोग करके पुन: कनेक्ट करने के लिए अपडेट करेगा।
यह पेज दिखाता है कि containers के लिए liveness, readiness और startup probes कैसे कॉन्फ़िगर करें।
probes के बारे में अधिक जानकारी के लिए देखें:Liveness, Readiness और Startup Probes
kubelet यह जानने के लिए liveness probes का उपयोग करता है कि container को कब restart करना है।उदाहरण के लिए, liveness probes deadlock पकड़ सकते हैं, जहाँ application चल तो रही होती है लेकिन आगे प्रगति नहीं कर पा रही होती। ऐसे state में container restart करना,bugs होने के बावजूद application की availability बेहतर कर सकता है।
liveness probes का एक सामान्य pattern यह है कि readiness probes वाली same low-cost HTTP endpoint का उपयोग किया जाए, लेकिन higher failureThreshold के साथ।इससे Pod को hard kill करने से पहले कुछ समय तक not-ready के रूप में observe किया जाता है।
kubelet readiness probes का उपयोग यह जानने के लिए करता है कि container traffic
स्वीकार करने के लिए कब तैयार है। इस signal का एक उपयोग यह नियंत्रित करना है कि
किन Pods को Services के backends के रूप में उपयोग किया जाए।Pod तब ready माना जाता है जब उसका Ready
condition true हो।जब Pod ready नहीं होता, तो उसे Service load balancers से हटा दिया जाता है।Pod की Ready condition false होती है जब उसके Node की Ready condition true न हो,या Pod के किसी readinessGates की condition false हो, या उसके containers में से कम से कम एक ready न हो।
kubelet startup probes का उपयोग यह जानने के लिए करता है कि container application शुरू हुई या नहीं।यदि ऐसा probe कॉन्फ़िगर है, तो liveness और readiness probes तब तक शुरू नहीं होतीं जब तक startup probe सफल न हो जाए। इससे यह सुनिश्चित होता है कि वे probes application startup में हस्तक्षेप न करें।इससे धीमे शुरू होने वाले containers पर liveness checks अपनाई जा सकती हैं और container को पूरी तरह शुरू होने से पहले kubelet द्वारा kill होने से बचाया जा सकता है।
आपको कुबरनेट्स क्लस्टर की ज़रूरत पड़ेगी और क्यूब सीटीएल कमांड लाइन साधन को समनुरूप करना होगा ताकि वो आपके क्लस्टर के साथ संवाद कर सकें। हमारी सलाह है की इस टुटोरिअल को क्लस्टर में रन करने के लिए कम से कम दो नोड का इस्तेमाल करे जो कि कंट्रोल प्लेन होस्ट के तरह ना एक्ट करे। अगर आपके पास पहले से क्लस्टर नही है, आप minikube की मदद से वह बना सकते है या आप नीचे दिए हुए इन दो कुबरनेट्स प्लेग्राउंड का इस्तेमाल कर सकते हैं:
लंबे समय तक चलने वाले कई applications अंततः broken states में पहुँच जाते हैं और restart किए बिना recover नहीं कर पाते।Kubernetes ऐसी स्थितियों का पता लगाने और सुधारने के लिए liveness probes देता है।
इस अभ्यास में आप ऐसा Pod बनाते हैं जो registry.k8s.io/busybox:1.27.2 image पर आधारित container चलाता है।यह Pod की configuration file है:
apiVersion: v1
kind: Pod
metadata:
labels:
test: liveness
name: liveness-exec
spec:
containers:
- name: liveness
image: registry.k8s.io/busybox:1.27.2
args:
- /bin/sh
- -c
- touch /tmp/healthy; sleep 30; rm -f /tmp/healthy; sleep 600
livenessProbe:
exec:
command:
- cat
- /tmp/healthy
initialDelaySeconds: 5
periodSeconds: 5
configuration file में आप देख सकते हैं कि Pod में एक ही Container है।periodSeconds field बताती है कि kubelet हर 5 seconds में liveness probe चलाए।initialDelaySeconds field बताती है कि पहली probe चलाने से पहले kubelet 5 seconds प्रतीक्षा करे।probe चलाने के लिए kubelet target container में cat /tmp/healthy command execute करता है।अगर command सफल होती है, तो 0 return होता है और kubelet container को जीवित और healthy मानता है।अगर command non-zero return करती है, तो kubelet container को kill करके restart कर देता है।
जब container शुरू होता है, तो वह यह command चलाता है:
/bin/sh -c "touch /tmp/healthy; sleep 30; rm -f /tmp/healthy; sleep 600"
container के जीवन के पहले 30 seconds तक /tmp/healthy फ़ाइल मौजूद रहती है।इसलिए पहले 30 seconds के दौरान cat /tmp/healthy success code लौटाता है।30 seconds के बाद cat /tmp/healthy failure code लौटाता है।
Pod बनाएं:
kubectl apply -f https://k8s.io/examples/pods/probe/exec-liveness.yaml
30 seconds के भीतर Pod events देखें:
kubectl describe pod liveness-exec
आउटपुट दर्शाता है कि अभी तक कोई liveness probe fail नहीं हुई:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled 11s default-scheduler Successfully assigned default/liveness-exec to node01
Normal Pulling 9s kubelet, node01 Pulling image "registry.k8s.io/busybox:1.27.2"
Normal Pulled 7s kubelet, node01 Successfully pulled image "registry.k8s.io/busybox:1.27.2"
Normal Created 7s kubelet, node01 Created container liveness
Normal Started 7s kubelet, node01 Started container liveness
35 seconds के बाद Pod events फिर देखें:
kubectl describe pod liveness-exec
आउटपुट के नीचे ऐसे messages होंगे जो दिखाते हैं कि liveness probes fail हुईं और failed containers को kill करके दोबारा बनाया गया।
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled 57s default-scheduler Successfully assigned default/liveness-exec to node01
Normal Pulling 55s kubelet, node01 Pulling image "registry.k8s.io/busybox:1.27.2"
Normal Pulled 53s kubelet, node01 Successfully pulled image "registry.k8s.io/busybox:1.27.2"
Normal Created 53s kubelet, node01 Created container liveness
Normal Started 53s kubelet, node01 Started container liveness
Warning Unhealthy 10s (x3 over 20s) kubelet, node01 Liveness probe failed: cat: can't open '/tmp/healthy': No such file or directory
Normal Killing 10s kubelet, node01 Container liveness failed liveness probe, will be restarted
और 30 seconds प्रतीक्षा करें, फिर सत्यापित करें कि container restart हुआ है:
kubectl get pod liveness-exec
आउटपुट दिखाता है कि RESTARTS बढ़ गया है। ध्यान दें कि RESTARTS counter
जैसे ही failed container फिर running state में आता है, बढ़ जाता है:
NAME READY STATUS RESTARTS AGE
liveness-exec 1/1 Running 1 1m
liveness probe का दूसरा प्रकार HTTP GET request का उपयोग करता है।यहाँ उस Pod की configuration file है जो registry.k8s.io/e2e-test-images/agnhost image पर आधारित container चलाता है।
apiVersion: v1
kind: Pod
metadata:
labels:
test: liveness
name: liveness-http
spec:
containers:
- name: liveness
image: registry.k8s.io/e2e-test-images/agnhost:2.40
args:
- liveness
livenessProbe:
httpGet:
path: /healthz
port: 8080
httpHeaders:
- name: Custom-Header
value: Awesome
initialDelaySeconds: 3
periodSeconds: 3
configuration file में आप देख सकते हैं कि Pod में एक ही container है।periodSeconds field बताती है कि kubelet हर 3 seconds में liveness probe चलाए।initialDelaySeconds field बताती है कि पहली probe से पहले kubelet 3 seconds प्रतीक्षा करे।probe चलाने के लिए kubelet container में चल रहे server को HTTP GET request भेजता है,जो port 8080 पर listen कर रहा है। अगर server के /healthz path का handler success code लौटाता है,तो kubelet container को alive और healthy मानता है। अगर handler failure code लौटाए,तो kubelet container को kill करके restart कर देता है।
200 या उससे बड़ा और 400 से छोटा कोई भी code success दर्शाता है।अन्य कोई भी code failure दर्शाता है।
आप server का source code यहाँ देख सकते हैं:server.go।
container के जीवित रहने के पहले 10 seconds तक /healthz handler
status 200 लौटाता है। उसके बाद handler status 500 लौटाता है।
http.HandleFunc("/healthz", func(w http.ResponseWriter, r *http.Request) {
duration := time.Now().Sub(started)
if duration.Seconds() > 10 {
w.WriteHeader(500)
w.Write([]byte(fmt.Sprintf("error: %v", duration.Seconds())))
} else {
w.WriteHeader(200)
w.Write([]byte("ok"))
}
})
container start होने के 3 seconds बाद kubelet health checks शुरू करता है।इसलिए शुरुआती कुछ checks सफल होंगी। लेकिन 10 seconds के बाद checks fail होंगी और kubelet container को kill करके restart कर देगा।
HTTP liveness check आज़माने के लिए Pod बनाएं:
kubectl apply -f https://k8s.io/examples/pods/probe/http-liveness.yaml
10 seconds बाद Pod events देखें और सत्यापित करें कि liveness probes fail हुईं और container restart हुआ:
kubectl describe pod liveness-http
v1.13 के बाद के releases में local HTTP proxy environment variable settings HTTP liveness probe को प्रभावित नहीं करतीं।
liveness probe का तीसरा प्रकार TCP socket का उपयोग करता है।इस configuration के साथ kubelet निर्दिष्ट port पर आपके container से socket connection खोलने की कोशिश करेगा।यदि connection बन जाता है तो container healthy माना जाता है, अन्यथा इसे failure माना जाता है।
apiVersion: v1
kind: Pod
metadata:
name: goproxy
labels:
app: goproxy
spec:
containers:
- name: goproxy
image: registry.k8s.io/goproxy:0.1
ports:
- containerPort: 8080
readinessProbe:
tcpSocket:
port: 8080
initialDelaySeconds: 15
periodSeconds: 10
livenessProbe:
tcpSocket:
port: 8080
initialDelaySeconds: 15
periodSeconds: 10
जैसा आप देख सकते हैं, TCP check की configuration HTTP check जैसी ही है।यह उदाहरण readiness और liveness दोनों probes का उपयोग करता है।kubelet container शुरू होने के 15 seconds बाद पहली liveness probe चलाएगा।यह port 8080 पर goproxy container से connect करने की कोशिश करेगा।अगर liveness probe fail होती है, तो container restart होगा।kubelet हर 10 seconds में यह check चलाता रहेगा।
liveness probe के अलावा इस configuration में readiness probe भी शामिल है।kubelet container शुरू होने के 15 seconds बाद पहली readiness probe चलाएगा।liveness probe की तरह यह भी port 8080 पर goproxy container से connect करने की कोशिश करेगा।यदि probe सफल होती है, तो Pod ready mark होगा और services से traffic प्राप्त करेगा।यदि readiness probe fail होती है, तो Pod unready mark होगा और किसी भी service से traffic नहीं पाएगा।
TCP liveness check आज़माने के लिए Pod बनाएं:
kubectl apply -f https://k8s.io/examples/pods/probe/tcp-liveness-readiness.yaml
15 seconds बाद Pod events देखें और liveness probes की स्थिति सत्यापित करें:
kubectl describe pod goproxy
Kubernetes v1.27 [stable]
यदि आपकी applicationgRPC Health Checking Protocol implement करती है, तो यह उदाहरण दिखाता है कि application liveness checks के लिए Kubernetes को इसका उपयोग करने हेतु कैसे कॉन्फ़िगर करें।इसी तरह आप readiness और startup probes भी कॉन्फ़िगर कर सकते हैं।
यहाँ एक example manifest है:
apiVersion: v1
kind: Pod
metadata:
name: etcd-with-grpc
spec:
containers:
- name: etcd
image: registry.k8s.io/etcd:3.5.1-0
command: [ "/usr/local/bin/etcd", "--data-dir", "/var/lib/etcd", "--listen-client-urls", "http://0.0.0.0:2379", "--advertise-client-urls", "http://127.0.0.1:2379", "--log-level", "debug"]
ports:
- containerPort: 2379
livenessProbe:
grpc:
port: 2379
initialDelaySeconds: 10
gRPC probe उपयोग करने के लिए port कॉन्फ़िगर होना आवश्यक है।अगर आप अलग प्रकार की probes और अलग features की probes में भेद करना चाहते हैं,तो service field उपयोग कर सकते हैं।आप service को liveness सेट कर सकते हैं और gRPC Health Checking endpoint को
यह request मिलने पर service को readiness सेट करने से अलग response देने के लिए कॉन्फ़िगर कर सकते हैं।इससे आप दो अलग ports पर listen करने के बजाय एक ही endpoint का उपयोग
विभिन्न प्रकार के container health checks के लिए कर सकते हैं।यदि आप अपना custom service name भी देना चाहते हैं और probe type भी बताना चाहते हैं,तो Kubernetes project सुझाव देता है कि आप दोनों को जोड़कर नाम रखें।उदाहरण: myservice-liveness (- separator के रूप में)।
configuration problems (उदाहरण: गलत port/service, health checking protocol implement न होना)को probe failure माना जाता है, ठीक HTTP और TCP probes की तरह।
gRPC liveness check आज़माने के लिए नीचे दी गई command से Pod बनाएं।नीचे के उदाहरण में etcd pod को gRPC liveness probe उपयोग करने के लिए कॉन्फ़िगर किया गया है।
kubectl apply -f https://k8s.io/examples/pods/probe/grpc-liveness.yaml
15 seconds बाद Pod events देखें और सत्यापित करें कि liveness check fail नहीं हुई:
kubectl describe pod etcd-with-grpc
gRPC probe का उपयोग करते समय कुछ तकनीकी बातें ध्यान रखने योग्य हैं:
-tls) को support नहीं करतीं।ExecProbeTimeout feature gate false पर सेट है, तो grpc-health-probetimeoutSeconds setting (जिसका default 1s है) का पालन नहीं करता, जबकि built-in probe timeout पर fail हो जाती है।आप HTTP और TCP probes के लिए named port
उपयोग कर सकते हैं। gRPC probes named ports को support नहीं करतीं।
उदाहरण:
ports:
- name: liveness-port
containerPort: 8080
livenessProbe:
httpGet:
path: /healthz
port: liveness-port
कभी-कभी आपको ऐसी applications से निपटना पड़ता है जिन्हें पहली initialization पर
अतिरिक्त startup time चाहिए। ऐसे मामलों में liveness probe parameters सेट करना मुश्किल हो सकता है,क्योंकि deadlock पर तेज प्रतिक्रिया भी चाहिए और startup समय पर probe से समस्या भी नहीं होनी चाहिए।इसका समाधान है startup probe सेट करना जिसमें वही command, HTTP या TCP check हो, औरfailureThreshold * periodSeconds इतना लंबा हो कि worst-case startup time कवर हो जाए।
तो पिछला उदाहरण इस प्रकार बन जाएगा:
ports:
- name: liveness-port
containerPort: 8080
livenessProbe:
httpGet:
path: /healthz
port: liveness-port
failureThreshold: 1
periodSeconds: 10
startupProbe:
httpGet:
path: /healthz
port: liveness-port
failureThreshold: 30
periodSeconds: 10
startup probe की वजह से application को startup पूरा करने के लिए अधिकतम 5 minutes(30 * 10 = 300s) मिलेंगे।startup probe एक बार सफल होते ही liveness probe takeover करती है
ताकि container deadlocks पर तेज प्रतिक्रिया मिल सके।अगर startup probe कभी सफल नहीं होती, तो container 300s के बाद kill हो जाएगा
और Pod की restartPolicy लागू होगी।
कभी-कभी applications अस्थायी रूप से traffic serve नहीं कर पातीं।उदाहरण के लिए startup के दौरान application को बड़े data या configuration files load करने पड़ सकते हैं,या startup के बाद external services पर निर्भर होना पड़ सकता है।ऐसी स्थितियों में आप application को kill नहीं करना चाहते,लेकिन उसे requests भी नहीं भेजना चाहते। Kubernetes इसके लिए readiness probes प्रदान करता है।जिस pod में containers report करते हैं कि वे ready नहीं हैं, उसे Kubernetes Services के जरिए traffic नहीं मिलता।
initialDelaySeconds या startupProbe का उपयोग करें।Readiness probes, liveness probes की तरह ही कॉन्फ़िगर होती हैं।केवल अंतर यह है कि livenessProbe के बजाय readinessProbe field उपयोग होती है।
readinessProbe:
exec:
command:
- cat
- /tmp/healthy
initialDelaySeconds: 5
periodSeconds: 5
HTTP और TCP readiness probes की configuration भी liveness probes जैसी ही रहती है।
Readiness और liveness probes एक ही container के लिए parallel में उपयोग की जा सकती हैं।दोनों का उपयोग यह सुनिश्चित कर सकता है कि traffic ऐसे container तक न पहुँचे जो उसके लिए ready नहीं है,और failure होने पर containers restart हों।
प्रोब्स (Probes) में कई fields होती हैं जिनसे आप startup, liveness और readiness checks के behavior को अधिक सटीक रूप से नियंत्रित कर सकते हैं:
initialDelaySeconds: container start होने के बाद startup, liveness या readiness probes शुरू करने से पहले कितने seconds प्रतीक्षा करनी है।यदि startup probe परिभाषित है, तो liveness और readiness की delays तब तक शुरू नहीं होतीं जब तक startup probe सफल न हो जाए।Kubernetes के कुछ पुराने versions में, यदि periodSeconds को initialDelaySeconds से बड़ा सेट किया गया हो,तो initialDelaySeconds को नज़रअंदाज़ किया जा सकता था। लेकिन वर्तमान versions में initialDelaySeconds हमेशा मान्य होती है
और probe इस शुरुआती delay के बाद ही शुरू होती है। Default 0 seconds, minimum 0।periodSeconds: probe कितनी बार (seconds में) चलानी है। Default 10 seconds।Minimum value 1 है।जब container Ready नहीं होता, तो ReadinessProbe कभी-कभी configured periodSeconds interval से अलग समय पर भी चल सकती है,ताकि Pod जल्दी ready हो सके।timeoutSeconds: probe timeout होने से पहले कितने seconds प्रतीक्षा करनी है।Default 1 second, minimum 1।successThreshold: fail होने के बाद probe को successful मानने के लिए लगातार सफल probes की न्यूनतम संख्या।Default 1। liveness और startup Probes के लिए यह 1 ही होना चाहिए।Minimum value 1।failureThreshold: probe लगातार failureThreshold बार fail हो जाए तो Kubernetes
overall check को failed मानता है: container ready/healthy/live नहीं है।Default 3। Minimum value 1।startup या liveness probe के मामले में, यदि कम से कम failureThreshold probes fail हों,तो Kubernetes container को unhealthy मानता है और उसी specific container का restart trigger करता है।kubelet उस container के terminationGracePeriodSeconds setting का सम्मान करता है।readiness probe fail होने पर kubelet failed container को चलाता रहता है और probes भी जारी रखता है;check fail होने के कारण kubelet Pod की Ready
condition को false सेट कर देता है।terminationGracePeriodSeconds: failed container को shutdown trigger करने और फिर container runtime को उसे force stop करने के बीच
kubelet कितना grace period दे, यह कॉन्फ़िगर करता है।Default रूप से यह Pod-level terminationGracePeriodSeconds को inherit करता है(यदि न दिया हो तो 30 seconds), और minimum value 1 है।अधिक जानकारी के लिए probe-level terminationGracePeriodSeconds देखें।HTTP प्रोब्स
में httpGet पर कुछ अतिरिक्त fields सेट की जा सकती हैं:
host: connect करने के लिए host name; default pod IP होता है।आमतौर पर इसके बजाय httpHeaders में "Host" सेट करना बेहतर है।scheme: host से connect करने के लिए scheme (HTTP या HTTPS)। Default "HTTP" है।path: HTTP server पर access करने का path। Default "/" है।httpHeaders: request में सेट करने के लिए custom headers। HTTP repeated headers को अनुमति देता है।port: container पर access करने वाले port का नाम या संख्या। संख्या 1 से 65535 के बीच होनी चाहिए।HTTP probe के लिए kubelet निर्दिष्ट port और path पर HTTP request भेजकर check करता है।kubelet probe को Pod के IP address पर भेजता है, जब तक httpGet में optional host field से address override न हो।अगर scheme field HTTPS हो, तो kubelet certificate verification skip करते हुए HTTPS request भेजता है।अधिकांश स्थितियों में आप host field सेट नहीं करना चाहेंगे।एक स्थिति जहाँ आप इसे सेट करेंगे: मान लें container 127.0.0.1 पर listen करता है
और Pod की hostNetwork field true है। तब httpGet के अंतर्गत host को 127.0.0.1 सेट करना चाहिए।अगर आपका pod virtual hosts पर निर्भर है (जो अधिक सामान्य मामला है),तो host का उपयोग न करें; बल्कि httpHeaders में Host header सेट करें।
HTTP probe के लिए kubelet अनिवार्य Host header के अलावा दो request headers भेजता है:
User-Agent: default value kube-probe/1.35 है,जहाँ 1.35 kubelet का version है।Accept: default value */* है।आप probe के लिए httpHeaders define करके default headers override कर सकते हैं।उदाहरण:
livenessProbe:
httpGet:
httpHeaders:
- name: Accept
value: application/json
startupProbe:
httpGet:
httpHeaders:
- name: User-Agent
value: MyUserAgent
इन दोनों headers को empty value देकर आप इन्हें हटा भी सकते हैं।
livenessProbe:
httpGet:
httpHeaders:
- name: Accept
value: ""
startupProbe:
httpGet:
httpHeaders:
- name: User-Agent
value: ""
जब kubelet HTTP का उपयोग करके Pod probe करता है, तो वह redirects केवल तब follow करता है जब redirect उसी host पर हो।अगर probing के दौरान kubelet को 11 या उससे अधिक redirects मिलते हैं, तो probe को successful माना जाता है और संबंधित Event बनाया जाता है:
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled 29m default-scheduler Successfully assigned default/httpbin-7b8bc9cb85-bjzwn to daocloud
Normal Pulling 29m kubelet Pulling image "docker.io/kennethreitz/httpbin"
Normal Pulled 24m kubelet Successfully pulled image "docker.io/kennethreitz/httpbin" in 5m12.402735213s
Normal Created 24m kubelet Created container httpbin
Normal Started 24m kubelet Started container httpbin
Warning ProbeWarning 4m11s (x1197 over 24m) kubelet Readiness probe warning: Probe terminated redirects
यदि kubelet को ऐसा redirect मिलता है जिसमें hostname request से अलग है, तो probe outcome को successful माना जाता है और kubelet redirect failure रिपोर्ट करने के लिए event बनाता है।
httpGet probe process करते समय kubelet response body का केवल पहले 10KiB तक पढ़ता है।probe की success केवल response status code से तय होती है, जो response headers में मिलता है।
यदि आप ऐसे endpoint को probe करते हैं जो 10KiB से बड़ा response body लौटाता है,तो kubelet status code के आधार पर probe को successful mark कर सकता है,लेकिन 10KiB limit पर पहुंचने के बाद connection बंद कर देगा।इस अचानक closure से application logs में connection reset by peer या broken pipe errors दिख सकती हैं,जिन्हें वास्तविक network issues से अलग पहचानना कठिन हो सकता है।
विश्वसनीय httpGet probes के लिए strongly recommended है कि dedicated health check endpoints उपयोग करें
जो minimal response body लौटाएँ। यदि बड़े payload वाले existing endpoint का उपयोग करना ही पड़े,तो उसके बजाय HEAD request करने के लिए exec probe उपयोग करने पर विचार करें।
TCP probe के लिए kubelet probe connection node से बनाता है, Pod के अंदर से नहीं।इसका मतलब है कि host parameter में service name का उपयोग नहीं किया जा सकता,क्योंकि kubelet उसे resolve नहीं कर पाता।
terminationGracePeriodSecondsKubernetes v1.28 [stable]
1.25 और उसके बाद, users probe specification के हिस्से के रूप में
probe-level terminationGracePeriodSeconds सेट कर सकते हैं।जब pod-level और probe-level दोनों terminationGracePeriodSeconds सेट हों,तो kubelet probe-level value का उपयोग करेगा।
terminationGracePeriodSeconds सेट करते समय निम्न बातों का ध्यान रखें:
kubelet हमेशा probe-level terminationGracePeriodSeconds field का सम्मान करता है
यदि वह Pod पर मौजूद है।
यदि आपके पास existing Pods हैं जिनमें terminationGracePeriodSeconds field सेट है और
आप per-probe termination grace periods का उपयोग नहीं करना चाहते,तो आपको वे existing Pods delete करने होंगे।
उदाहरण:
spec:
terminationGracePeriodSeconds: 3600 # pod-level
containers:
- name: test
image: ...
ports:
- name: liveness-port
containerPort: 8080
livenessProbe:
httpGet:
path: /healthz
port: liveness-port
failureThreshold: 1
periodSeconds: 60
# Override pod-level terminationGracePeriodSeconds #
terminationGracePeriodSeconds: 60
readiness probes के लिए probe-level terminationGracePeriodSeconds सेट नहीं किया जा सकता।API server इसे reject कर देगा।
आप API references भी पढ़ सकते हैं:
यह पेज दिखाता है कि किसी एप्लिकेशन Container के चलने से पहले Pod को initialize करने के लिए Init Container का उपयोग कैसे करें।
आपको कुबरनेट्स क्लस्टर की ज़रूरत पड़ेगी और क्यूब सीटीएल कमांड लाइन साधन को समनुरूप करना होगा ताकि वो आपके क्लस्टर के साथ संवाद कर सकें। हमारी सलाह है की इस टुटोरिअल को क्लस्टर में रन करने के लिए कम से कम दो नोड का इस्तेमाल करे जो कि कंट्रोल प्लेन होस्ट के तरह ना एक्ट करे। अगर आपके पास पहले से क्लस्टर नही है, आप minikube की मदद से वह बना सकते है या आप नीचे दिए हुए इन दो कुबरनेट्स प्लेग्राउंड का इस्तेमाल कर सकते हैं:
संस्करण की जांच करने के लिए, लिखें kubectl version.
इस अभ्यास में आप ऐसा Pod बनाते हैं जिसमें एक application Container और एक Init Container होता है। application container शुरू होने से पहले init container पूरा चलकर समाप्त हो जाता है।
यह Pod की configuration file है:
apiVersion: v1
kind: Pod
metadata:
name: init-demo
spec:
containers:
- name: nginx
image: nginx
ports:
- containerPort: 80
volumeMounts:
- name: workdir
mountPath: /usr/share/nginx/html
# These containers are run during pod initialization
initContainers:
- name: install
image: busybox:1.28
command:
- wget
- "-O"
- "/work-dir/index.html"
- http://info.cern.ch
volumeMounts:
- name: workdir
mountPath: "/work-dir"
dnsPolicy: Default
volumes:
- name: workdir
emptyDir: {}
configuration file में आप देख सकते हैं कि Pod में एक Volume है जिसे init container और application container share करते हैं।
init container shared Volume को /work-dir पर mount करता है, और application container
shared Volume को /usr/share/nginx/html पर mount करता है। init container नीचे दी गई कमांड चलाता है
और फिर समाप्त हो जाता है:
wget -O /work-dir/index.html http://info.cern.ch
ध्यान दें कि init container, nginx server की root directory में index.html फ़ाइल लिखता है।
Pod बनाएं:
kubectl apply -f https://k8s.io/examples/pods/init-containers.yaml
जांचें कि nginx container चल रहा है:
kubectl get pod init-demo
आउटपुट दिखाता है कि nginx container चल रहा है:
NAME READY STATUS RESTARTS AGE
init-demo 1/1 Running 0 1m
init-demo Pod में चल रहे nginx container के अंदर shell खोलें:
kubectl exec -it init-demo -- /bin/bash
अपनी shell में, nginx server पर GET request भेजें:
root@nginx:~# apt-get update
root@nginx:~# apt-get install curl
root@nginx:~# curl localhost
आउटपुट दिखाता है कि nginx वही web page serve कर रहा है जिसे init container ने लिखा था:
<html><head></head><body><header>
<title>http://info.cern.ch</title>
</header>
<h1>http://info.cern.ch - home of the first website</h1>
...
<li><a href="http://info.cern.ch/hypertext/WWW/TheProject.html">Browse the first website</a></li>
...
कई एप्लिकेशन कॉन्फ़िगरेशन पर निर्भर करते हैं, जिसका उपयोग एप्लिकेशन के initialization के दौरान या runtime में किया जाता है।ज़्यादातर बार, कॉन्फ़िगरेशन पैरामीटर को दिए गए मानों को समायोजित करने की आवश्यकता होती है।ConfigMap, Kubernetes का एक मैकेनिज़्म है जो आपको कॉन्फ़िगरेशन डेटा को एप्लिकेशन pods में inject करने देता है।
ConfigMap का कॉन्सेप्ट आपको कॉन्फ़िगरेशन artifacts को image content से अलग (decouple) करने देता है,ताकि containerized applications पोर्टेबल बनी रहें। उदाहरण के लिए, आप एक ही container image को डाउनलोड और रन करके local development, system test, या live end-user workload चलाने के लिए कंटेनर शुरू कर सकते हैं।
यह पेज उपयोग के कई उदाहरण देता है, जिनसे यह दिखाया गया है कि ConfigMap कैसे बनाएँ और ConfigMap में स्टोर किए गए डेटा का उपयोग करके Pods को कैसे कॉन्फ़िगर करें।
आपको कुबरनेट्स क्लस्टर की ज़रूरत पड़ेगी और क्यूब सीटीएल कमांड लाइन साधन को समनुरूप करना होगा ताकि वो आपके क्लस्टर के साथ संवाद कर सकें। हमारी सलाह है की इस टुटोरिअल को क्लस्टर में रन करने के लिए कम से कम दो नोड का इस्तेमाल करे जो कि कंट्रोल प्लेन होस्ट के तरह ना एक्ट करे। अगर आपके पास पहले से क्लस्टर नही है, आप minikube की मदद से वह बना सकते है या आप नीचे दिए हुए इन दो कुबरनेट्स प्लेग्राउंड का इस्तेमाल कर सकते हैं:
आपके सिस्टम में wget टूल इंस्टॉल होना चाहिए। अगर आपके पास कोई दूसरा टूल
जैसे curl है और wget नहीं है, तो आपको example data डाउनलोड करने वाला
step उसी के अनुसार बदलना होगा।
ConfigMap बनाने के लिए आप या तो kubectl create configmap का उपयोग कर सकते हैं याkustomization.yaml में ConfigMap generator का।
kubectl create configmap का उपयोग करके ConfigMap बनाएंkubectl create configmap कमांड का उपयोग करके आपdirectories, files,या literal values से ConfigMap बना सकते हैं:
kubectl create configmap <map-name> <data-source>
जहाँ <map-name> वह नाम है जो आप ConfigMap को देना चाहते हैं और <data-source> वह directory, file, या literal value है जिससे डेटा लिया जाएगा।ConfigMap ऑब्जेक्ट का नाम एक वैधDNS subdomain name होना चाहिए।
जब आप किसी फ़ाइल के आधार पर ConfigMap बनाते हैं, तो <data-source> में key डिफ़ॉल्ट रूप से उस फ़ाइल का basename होती है, और value डिफ़ॉल्ट रूप से फ़ाइल का content होता है।
आप kubectl describe याkubectl get का उपयोग करके
ConfigMap की जानकारी प्राप्त कर सकते हैं।
आप kubectl create configmap का उपयोग करके एक ही डायरेक्टरी में मौजूद कई फ़ाइलों से
ConfigMap बना सकते हैं। जब आप डायरेक्टरी के आधार पर ConfigMap बनाते हैं, तो kubectl उन
फ़ाइलों की पहचान करता है जिनका filename वैध key होता है, और हर ऐसी फ़ाइल को नए
ConfigMap में पैकेज करता है। सामान्य फ़ाइलों (regular files) के अलावा बाकी डायरेक्टरी entries
नज़रअंदाज़ कर दी जाती हैं (जैसे: subdirectories, symlinks, devices, pipes, आदि)।
ConfigMap बनाने के लिए उपयोग होने वाला हर filename केवल स्वीकार्य अक्षरों से बना होना चाहिए:letters (A से Z और a से z), digits (0 से 9), '-', '_', या '.'।अगर आप kubectl create configmap को ऐसी डायरेक्टरी पर चलाते हैं जहाँ किसी फ़ाइल के नाम में
अस्वीकार्य कैरेक्टर हो, तो kubectl कमांड fail हो सकती है।
जब kubectl कमांड को invalid filename मिलता है, तो यह हमेशा error प्रिंट नहीं करता।
लोकल डायरेक्टरी बनाएं:
mkdir -p configure-pod-container/configmap/
अब sample configuration डाउनलोड करें और ConfigMap बनाएं:
# Download the sample files into `configure-pod-container/configmap/` directory
wget https://kubernetes.io/examples/configmap/game.properties -O configure-pod-container/configmap/game.properties
wget https://kubernetes.io/examples/configmap/ui.properties -O configure-pod-container/configmap/ui.properties
# Create the ConfigMap
kubectl create configmap game-config --from-file=configure-pod-container/configmap/
ऊपर दी गई कमांड हर फ़ाइल को पैकेज करती है, इस केस में game.properties और ui.properties
को configure-pod-container/configmap/ डायरेक्टरी से game-config ConfigMap में जोड़ती है।आप नीचे दी गई कमांड से ConfigMap का विवरण देख सकते हैं:
kubectl describe configmaps game-config
आउटपुट कुछ इस तरह होगा:
Name: game-config
Namespace: default
Labels: <none>
Annotations: <none>
Data
====
game.properties:
----
enemies=aliens
lives=3
enemies.cheat=true
enemies.cheat.level=noGoodRotten
secret.code.passphrase=UUDDLRLRBABAS
secret.code.allowed=true
secret.code.lives=30
ui.properties:
----
color.good=purple
color.bad=yellow
allow.textmode=true
how.nice.to.look=fairlyNice
configure-pod-container/configmap/ डायरेक्टरी में मौजूद game.properties और ui.properties
फ़ाइलें ConfigMap के data सेक्शन में प्रदर्शित होती हैं।
kubectl get configmaps game-config -o yaml
आउटपुट कुछ इस तरह होगा:
apiVersion: v1
kind: ConfigMap
metadata:
creationTimestamp: 2022-02-18T18:52:05Z
name: game-config
namespace: default
resourceVersion: "516"
uid: b4952dc3-d670-11e5-8cd0-68f728db1985
data:
game.properties: |
enemies=aliens
lives=3
enemies.cheat=true
enemies.cheat.level=noGoodRotten
secret.code.passphrase=UUDDLRLRBABAS
secret.code.allowed=true
secret.code.lives=30
ui.properties: |
color.good=purple
color.bad=yellow
allow.textmode=true
how.nice.to.look=fairlyNice
आप kubectl create configmap का उपयोग करके एक फ़ाइल या
कई फ़ाइलों से ConfigMap बना सकते हैं।
उदाहरण के लिए,
kubectl create configmap game-config-2 --from-file=configure-pod-container/configmap/game.properties
यह निम्न ConfigMap बनाएगा:
kubectl describe configmaps game-config-2
जहाँ आउटपुट कुछ इस तरह होगा:
Name: game-config-2
Namespace: default
Labels: <none>
Annotations: <none>
Data
====
game.properties:
----
enemies=aliens
lives=3
enemies.cheat=true
enemies.cheat.level=noGoodRotten
secret.code.passphrase=UUDDLRLRBABAS
secret.code.allowed=true
secret.code.lives=30
कई data sources से ConfigMap बनाने के लिए आप --from-file argument को कई बार दे सकते हैं।
kubectl create configmap game-config-2 --from-file=configure-pod-container/configmap/game.properties --from-file=configure-pod-container/configmap/ui.properties
आप नीचे दी गई कमांड से game-config-2 ConfigMap का विवरण देख सकते हैं:
kubectl describe configmaps game-config-2
आउटपुट कुछ इस तरह होगा:
Name: game-config-2
Namespace: default
Labels: <none>
Annotations: <none>
Data
====
game.properties:
----
enemies=aliens
lives=3
enemies.cheat=true
enemies.cheat.level=noGoodRotten
secret.code.passphrase=UUDDLRLRBABAS
secret.code.allowed=true
secret.code.lives=30
ui.properties:
----
color.good=purple
color.bad=yellow
allow.textmode=true
how.nice.to.look=fairlyNice
env-file से ConfigMap बनाने के लिए --from-env-file विकल्प का उपयोग करें, उदाहरण के लिए:
# Env-files contain a list of environment variables.
# These syntax rules apply:
# Each line in an env file has to be in VAR=VAL format.
# Lines beginning with # (i.e. comments) are ignored.
# Blank lines are ignored.
# There is no special handling of quotation marks (i.e. they will be part of the ConfigMap value)).
# Download the sample files into `configure-pod-container/configmap/` directory
wget https://kubernetes.io/examples/configmap/game-env-file.properties -O configure-pod-container/configmap/game-env-file.properties
wget https://kubernetes.io/examples/configmap/ui-env-file.properties -O configure-pod-container/configmap/ui-env-file.properties
# The env-file `game-env-file.properties` looks like below
cat configure-pod-container/configmap/game-env-file.properties
enemies=aliens
lives=3
allowed="true"
# This comment and the empty line above it are ignored
kubectl create configmap game-config-env-file \
--from-env-file=configure-pod-container/configmap/game-env-file.properties
यह एक ConfigMap बनाएगा। ConfigMap देखें:
kubectl get configmap game-config-env-file -o yaml
आउटपुट कुछ इस तरह होगा:
apiVersion: v1
kind: ConfigMap
metadata:
creationTimestamp: 2019-12-27T18:36:28Z
name: game-config-env-file
namespace: default
resourceVersion: "809965"
uid: d9d1ca5b-eb34-11e7-887b-42010a8002b8
data:
allowed: '"true"'
enemies: aliens
lives: "3"
Kubernetes v1.23 से, kubectl में --from-env-file argument को
कई बार specify करके कई data sources से ConfigMap बनाना समर्थित है।
kubectl create configmap config-multi-env-files \
--from-env-file=configure-pod-container/configmap/game-env-file.properties \
--from-env-file=configure-pod-container/configmap/ui-env-file.properties
यह निम्न ConfigMap बनाएगा:
kubectl get configmap config-multi-env-files -o yaml
जहाँ आउटपुट कुछ इस तरह होगा:
apiVersion: v1
kind: ConfigMap
metadata:
creationTimestamp: 2019-12-27T18:38:34Z
name: config-multi-env-files
namespace: default
resourceVersion: "810136"
uid: 252c4572-eb35-11e7-887b-42010a8002b8
data:
allowed: '"true"'
color: purple
enemies: aliens
how: fairlyNice
lives: "3"
textmode: "true"
जब आप --from-file argument का उपयोग करते हैं, तब ConfigMap के data सेक्शन में
फ़ाइल नाम के बजाय कोई दूसरी key भी परिभाषित कर सकते हैं:
kubectl create configmap game-config-3 --from-file=<my-key-name>=<path-to-file>
जहाँ <my-key-name> वह key है जिसे आप ConfigMap में उपयोग करना चाहते हैं और <path-to-file>
वह data source फ़ाइल का स्थान है जिसे वह key represent करेगी।
उदाहरण के लिए:
kubectl create configmap game-config-3 --from-file=game-special-key=configure-pod-container/configmap/game.properties
यह निम्न ConfigMap बनाएगा:
kubectl get configmaps game-config-3 -o yaml
जहाँ आउटपुट कुछ इस तरह होगा:
apiVersion: v1
kind: ConfigMap
metadata:
creationTimestamp: 2022-02-18T18:54:22Z
name: game-config-3
namespace: default
resourceVersion: "530"
uid: 05f8da22-d671-11e5-8cd0-68f728db1985
data:
game-special-key: |
enemies=aliens
lives=3
enemies.cheat=true
enemies.cheat.level=noGoodRotten
secret.code.passphrase=UUDDLRLRBABAS
secret.code.allowed=true
secret.code.lives=30
आप kubectl create configmap के साथ --from-literal argument का उपयोग करके
command line से literal value परिभाषित कर सकते हैं:
kubectl create configmap special-config --from-literal=special.how=very --from-literal=special.type=charm
आप कई key-value pairs दे सकते हैं। command line पर दिया गया हर pair ConfigMap केdata सेक्शन में अलग entry के रूप में दिखता है।
kubectl get configmaps special-config -o yaml
आउटपुट कुछ इस तरह होगा:
apiVersion: v1
kind: ConfigMap
metadata:
creationTimestamp: 2022-02-18T19:14:38Z
name: special-config
namespace: default
resourceVersion: "651"
uid: dadce046-d673-11e5-8cd0-68f728db1985
data:
special.how: very
special.type: charm
आप generators से भी ConfigMap बना सकते हैं और फिर उसे apply करके cluster के API server
में object बना सकते हैं।आपको generators को किसी डायरेक्टरी के भीतर kustomization.yaml फ़ाइल में define करना चाहिए।
उदाहरण के लिए, फ़ाइल configure-pod-container/configmap/game.properties से ConfigMap generate करने के लिए:
# Create a kustomization.yaml file with ConfigMapGenerator
cat <<EOF >./kustomization.yaml
configMapGenerator:
- name: game-config-4
options:
labels:
game-config: config-4
files:
- configure-pod-container/configmap/game.properties
EOF
ConfigMap object बनाने के लिए kustomization डायरेक्टरी apply करें:
kubectl apply -k .
configmap/game-config-4-m9dm2f92bt created
आप यह इस तरह जांच सकते हैं कि ConfigMap बना है:
kubectl get configmap
NAME DATA AGE
game-config-4-m9dm2f92bt 1 37s
और यह भी:
kubectl describe configmaps/game-config-4-m9dm2f92bt
Name: game-config-4-m9dm2f92bt
Namespace: default
Labels: game-config=config-4
Annotations: kubectl.kubernetes.io/last-applied-configuration:
{"apiVersion":"v1","data":{"game.properties":"enemies=aliens\nlives=3\nenemies.cheat=true\nenemies.cheat.level=noGoodRotten\nsecret.code.p...
Data
====
game.properties:
----
enemies=aliens
lives=3
enemies.cheat=true
enemies.cheat.level=noGoodRotten
secret.code.passphrase=UUDDLRLRBABAS
secret.code.allowed=true
secret.code.lives=30
Events: <none>
ध्यान दें कि generated ConfigMap नाम के अंत में content का hash जोड़कर एक suffix लगाया जाता है।इससे यह सुनिश्चित होता है कि content बदलने पर हर बार नया ConfigMap generate हो।
आप ConfigMap generator में फ़ाइल नाम के बजाय दूसरी key परिभाषित कर सकते हैं।उदाहरण के लिए, configure-pod-container/configmap/game.properties से game-special-key
key के साथ ConfigMap generate करने के लिए:
# Create a kustomization.yaml file with ConfigMapGenerator
cat <<EOF >./kustomization.yaml
configMapGenerator:
- name: game-config-5
options:
labels:
game-config: config-5
files:
- game-special-key=configure-pod-container/configmap/game.properties
EOF
ConfigMap object बनाने के लिए kustomization डायरेक्टरी apply करें।
kubectl apply -k .
configmap/game-config-5-m67dt67794 created
यह उदाहरण दिखाता है कि Kustomize और kubectl का उपयोग करके दो literal key/value pairsspecial.type=charm और special.how=very से ConfigMap कैसे बनाया जाए।इसके लिए आप ConfigMap generator specify कर सकते हैं। kustomization.yaml बनाएं (या replace करें),ताकि उसका content नीचे जैसा हो:
---
# kustomization.yaml contents for creating a ConfigMap from literals
configMapGenerator:
- name: special-config-2
literals:
- special.how=very
- special.type=charm
ConfigMap object बनाने के लिए kustomization डायरेक्टरी apply करें:
kubectl apply -k .
configmap/special-config-2-c92b5mmcf2 created
आगे बढ़ने से पहले, बनाए गए कुछ ConfigMaps को साफ़ करें:
kubectl delete configmap special-config
kubectl delete configmap env-config
kubectl delete configmap -l 'game-config in (config-4,config-5)'
अब आपने ConfigMap परिभाषित करना सीख लिया है, तो आप अगले सेक्शन में जाकर सीख सकते हैं कि Pods के साथ इन ऑब्जेक्ट्स का उपयोग कैसे करें।
ConfigMap में key-value pair के रूप में एक environment variable परिभाषित करें:
kubectl create configmap special-config --from-literal=special.how=very
ConfigMap में परिभाषित special.how मान को Pod specification में SPECIAL_LEVEL_KEY
environment variable को असाइन करें।
apiVersion: v1
kind: Pod
metadata:
name: dapi-test-pod
spec:
containers:
- name: test-container
image: registry.k8s.io/busybox:1.27.2
command: [ "/bin/sh", "-c", "env" ]
env:
# Define the environment variable
- name: SPECIAL_LEVEL_KEY
valueFrom:
configMapKeyRef:
# The ConfigMap containing the value you want to assign to SPECIAL_LEVEL_KEY
name: special-config
# Specify the key associated with the value
key: special.how
restartPolicy: Never
Pod बनाएं:
kubectl create -f https://kubernetes.io/examples/pods/pod-single-configmap-env-variable.yaml
अब Pod के आउटपुट में environment variable SPECIAL_LEVEL_KEY=very शामिल होगा।
पिछले उदाहरण की तरह पहले ConfigMaps बनाएं।यहाँ वह manifest है जिसका आप उपयोग करेंगे:
apiVersion: v1
kind: ConfigMap
metadata:
name: special-config
namespace: default
data:
special.how: very
---
apiVersion: v1
kind: ConfigMap
metadata:
name: env-config
namespace: default
data:
log_level: INFO
ConfigMap बनाएं:
kubectl create -f https://kubernetes.io/examples/configmap/configmaps.yaml
Pod specification में environment variables परिभाषित करें।
apiVersion: v1
kind: Pod
metadata:
name: dapi-test-pod
spec:
containers:
- name: test-container
image: registry.k8s.io/busybox:1.27.2
command: [ "/bin/sh", "-c", "env" ]
env:
- name: SPECIAL_LEVEL_KEY
valueFrom:
configMapKeyRef:
name: special-config
key: special.how
- name: LOG_LEVEL
valueFrom:
configMapKeyRef:
name: env-config
key: log_level
restartPolicy: Never
Pod बनाएं:
kubectl create -f https://kubernetes.io/examples/pods/pod-multiple-configmap-env-variable.yaml
अब Pod के आउटपुट में environment variables SPECIAL_LEVEL_KEY=very और LOG_LEVEL=INFO शामिल होंगे।
आगे बढ़ने के बाद, वह Pod और ConfigMap हटा दें:
kubectl delete pod dapi-test-pod --now
kubectl delete configmap special-config
kubectl delete configmap env-config
कई key-value pairs वाला एक ConfigMap बनाएं।
apiVersion: v1
kind: ConfigMap
metadata:
name: special-config
namespace: default
data:
SPECIAL_LEVEL: very
SPECIAL_TYPE: charm
ConfigMap बनाएं:
kubectl create -f https://kubernetes.io/examples/configmap/configmap-multikeys.yaml
envFrom का उपयोग करके ConfigMap के सभी डेटा को कंटेनर environment variables के रूप में परिभाषित करें।ConfigMap की key, Pod में environment variable नाम बन जाती है।
apiVersion: v1
kind: Pod
metadata:
name: dapi-test-pod
spec:
containers:
- name: test-container
image: registry.k8s.io/busybox:1.27.2
command: [ "/bin/sh", "-c", "env" ]
envFrom:
- configMapRef:
name: special-config
restartPolicy: Never
Pod बनाएं:
kubectl create -f https://kubernetes.io/examples/pods/pod-configmap-envFrom.yaml
अब Pod के आउटपुट में environment variables SPECIAL_LEVEL=very औरSPECIAL_TYPE=charm शामिल होंगे।
आगे बढ़ने के बाद, वह Pod हटा दें:
kubectl delete pod dapi-test-pod --now
आप कंटेनर के command और args में ConfigMap-परिभाषित environment variables का उपयोग
Kubernetes substitution syntax $(VAR_NAME) के साथ कर सकते हैं।
उदाहरण के लिए, नीचे दिया गया Pod manifest:
apiVersion: v1
kind: Pod
metadata:
name: dapi-test-pod
spec:
containers:
- name: test-container
image: registry.k8s.io/busybox:1.27.2
command: [ "/bin/echo", "$(SPECIAL_LEVEL_KEY) $(SPECIAL_TYPE_KEY)" ]
env:
- name: SPECIAL_LEVEL_KEY
valueFrom:
configMapKeyRef:
name: special-config
key: SPECIAL_LEVEL
- name: SPECIAL_TYPE_KEY
valueFrom:
configMapKeyRef:
name: special-config
key: SPECIAL_TYPE
restartPolicy: Never
उस Pod को चलाकर बनाएं:
kubectl create -f https://kubernetes.io/examples/pods/pod-configmap-env-var-valueFrom.yaml
वह Pod test-container कंटेनर से नीचे दिया गया आउटपुट देता है:
kubectl logs dapi-test-pod
very charm
आगे बढ़ने के बाद, वह Pod हटा दें:
kubectl delete pod dapi-test-pod --now
फ़ाइलों से ConfigMap बनाएं में बताए अनुसार, जब आप--from-file का उपयोग करके ConfigMap बनाते हैं, तो filename, ConfigMap के data सेक्शन में
store होने वाली key बन जाता है। फ़ाइल का content उस key की value बनता है।
इस सेक्शन के उदाहरण special-config नाम के ConfigMap को refer करते हैं:
apiVersion: v1
kind: ConfigMap
metadata:
name: special-config
namespace: default
data:
SPECIAL_LEVEL: very
SPECIAL_TYPE: charm
ConfigMap बनाएं:
kubectl create -f https://kubernetes.io/examples/configmap/configmap-multikeys.yaml
Pod specification के volumes सेक्शन में ConfigMap का नाम जोड़ें।इससे ConfigMap डेटा volumeMounts.mountPath द्वारा बताए गए डायरेक्टरी में जुड़ता है (इस
उदाहरण में /etc/config)। command सेक्शन डायरेक्टरी की उन फ़ाइलों को सूचीबद्ध करता है
जिनके नाम ConfigMap की keys से मेल खाते हैं।
apiVersion: v1
kind: Pod
metadata:
name: dapi-test-pod
spec:
containers:
- name: test-container
image: registry.k8s.io/busybox:1.27.2
command: [ "/bin/sh", "-c", "ls /etc/config/" ]
volumeMounts:
- name: config-volume
mountPath: /etc/config
volumes:
- name: config-volume
configMap:
# Provide the name of the ConfigMap containing the files you want
# to add to the container
name: special-config
restartPolicy: Never
Pod बनाएं:
kubectl create -f https://kubernetes.io/examples/pods/pod-configmap-volume.yaml
जब Pod चलता है, तो ls /etc/config/ कमांड नीचे जैसा आउटपुट देता है:
SPECIAL_LEVEL
SPECIAL_TYPE
Text data को UTF-8 character encoding के साथ फ़ाइलों के रूप में expose किया जाता है।अगर आप कोई दूसरी character encoding उपयोग करना चाहते हैं, तो binaryData उपयोग करें(अधिक जानकारी के लिए ConfigMap object देखें)।
/etc/config डायरेक्टरी में कोई फ़ाइलें मौजूद हैं, तो volume
mount image की उन फ़ाइलों को inaccessible बना देगा।आगे बढ़ने के बाद, वह Pod हटा दें:
kubectl delete pod dapi-test-pod --now
specific ConfigMap items के लिए इच्छित फ़ाइल पथ बताने हेतु path फ़ील्ड उपयोग करें।इस केस में SPECIAL_LEVEL item, config-volume volume में /etc/config/keys पर mount होगा।
apiVersion: v1
kind: Pod
metadata:
name: dapi-test-pod
spec:
containers:
- name: test-container
image: registry.k8s.io/busybox:1.27.2
command: [ "/bin/sh","-c","cat /etc/config/keys" ]
volumeMounts:
- name: config-volume
mountPath: /etc/config
volumes:
- name: config-volume
configMap:
name: special-config
items:
- key: SPECIAL_LEVEL
path: keys
restartPolicy: Never
Pod बनाएं:
kubectl create -f https://kubernetes.io/examples/pods/pod-configmap-volume-specific-key.yaml
जब Pod चलता है, तो cat /etc/config/keys कमांड नीचे जैसा आउटपुट देता है:
very
/etc/config/ डायरेक्टरी में मौजूद सभी पहले की फ़ाइलें हट जाएँगी।वह Pod हटा दें:
kubectl delete pod dapi-test-pod --now
आप keys को specific paths पर project कर सकते हैं। syntax के लिए Secrets गाइड के संबंधित सेक्शन को देखें।
आप keys के लिए POSIX permissions सेट कर सकते हैं। syntax के लिए Secrets गाइड के संबंधित सेक्शन को देखें।
ConfigMap reference को optional के रूप में चिह्नित किया जा सकता है। अगर ConfigMap मौजूद नहीं है,तो mounted volume खाली होगा। अगर ConfigMap मौजूद है लेकिन referenced key मौजूद नहीं है, तो mount point के नीचे वह path मौजूद नहीं होगा। अधिक जानकारी के लिए Optional ConfigMaps देखें।
जब mounted ConfigMap अपडेट होता है, तो projected content भी eventually अपडेट हो जाता है।यह उस केस में भी लागू होता है जहाँ optional रूप से referenced ConfigMap, pod शुरू होने के बाद अस्तित्व में आता है।
Kubelet हर periodic sync पर जांचता है कि mounted ConfigMap fresh है या नहीं। हालांकि,current value लाने के लिए यह अपना local TTL-based cache इस्तेमाल करता है। परिणामस्वरूप,ConfigMap अपडेट होने के समय से लेकर pod में नई keys project होने तक कुल देरी अधिकतम kubelet sync period (डिफ़ॉल्ट 1 मिनट) + kubelet में ConfigMaps cache का TTL (डिफ़ॉल्ट 1 मिनट)जितनी हो सकती है। आप pod की किसी annotation को अपडेट करके तुरंत refresh ट्रिगर कर सकते हैं।
ConfigMap API resource, configuration data को key-value pairs के रूप में store करता है। इस डेटा को pods में उपयोग किया जा सकता है या controllers जैसे system components के configurations देने के लिए।ConfigMap, Secrets जैसा है, लेकिन यह ऐसे strings के साथ काम करने का तरीका देता है जिनमें संवेदनशील जानकारी नहीं होती। उपयोगकर्ता और system components, दोनों ConfigMap में configuration data store कर सकते हैं।
/etc डायरेक्टरी और उसके content जैसी किसी चीज़ का प्रतिनिधित्व करने वाला समझें। उदाहरण के लिए,अगर आप ConfigMap से Kubernetes Volume बनाते हैं, तो ConfigMap का
हर data item volume में एक अलग फ़ाइल के रूप में दर्शाया जाता है।ConfigMap के data फ़ील्ड में configuration data होता है। नीचे दिए उदाहरण की तरह, यह साधारण भी हो सकता है(जैसे --from-literal से परिभाषित individual properties) या जटिल भी(जैसे --from-file से परिभाषित configuration files या JSON blobs)।
apiVersion: v1
kind: ConfigMap
metadata:
creationTimestamp: 2016-02-18T19:14:38Z
name: example-config
namespace: default
data:
# example of a simple property defined using --from-literal
example.property.1: hello
example.property.2: world
# example of a complex property defined using --from-file
example.property.file: |-
property.1=value-1
property.2=value-2
property.3=value-3
जब kubectl ऐसे inputs से ConfigMap बनाता है जो ASCII या UTF-8 नहीं होते, तो टूल
उन्हें ConfigMap के binaryData फ़ील्ड में रखता है, data में नहीं। text और binary
दोनों data sources को एक ConfigMap में मिलाया जा सकता है।
अगर आप ConfigMap में binaryData keys (और उनकी values) देखना चाहते हैं, तो आपkubectl get configmap -o jsonpath='{.binaryData}' <name> चला सकते हैं।
Pods, data या binaryData में से किसी का उपयोग करने वाले ConfigMap से डेटा लोड कर सकते हैं।
आप Pod specification में ConfigMap reference को optional के रूप में चिह्नित कर सकते हैं।अगर ConfigMap मौजूद नहीं है, तो Pod में वह configuration जिसके लिए ConfigMap डेटा देता है (उदाहरण: environment variable, mounted volume) खाली रहेगा।अगर ConfigMap मौजूद है, लेकिन referenced key मौजूद नहीं है, तो डेटा भी खाली रहेगा।
उदाहरण के लिए, नीचे दिया Pod specification ConfigMap से environment variable को optional चिह्नित करता है:
apiVersion: v1
kind: Pod
metadata:
name: dapi-test-pod
spec:
containers:
- name: test-container
image: gcr.io/google_containers/busybox
command: ["/bin/sh", "-c", "env"]
env:
- name: SPECIAL_LEVEL_KEY
valueFrom:
configMapKeyRef:
name: a-config
key: akey
optional: true # mark the variable as optional
restartPolicy: Never
अगर आप यह pod चलाते हैं और a-config नाम का ConfigMap मौजूद नहीं है, तो आउटपुट खाली होगा।अगर आप यह pod चलाते हैं और a-config नाम का ConfigMap मौजूद है लेकिन उसमें akey नाम की key नहीं है,तो आउटपुट फिर भी खाली होगा। अगर आप a-config ConfigMap में akey के लिए value सेट करते हैं,तो यह pod वह value प्रिंट करके terminate हो जाता है।
आप ConfigMap द्वारा प्रदान किए गए volumes और files को भी optional चिह्नित कर सकते हैं। Kubernetes,भले ही referenced ConfigMap या key मौजूद न हो, volume के mount paths हमेशा बनाता है। उदाहरण के लिए,नीचे दिया Pod specification ConfigMap को refer करने वाले volume को optional चिह्नित करता है:
apiVersion: v1
kind: Pod
metadata:
name: dapi-test-pod
spec:
containers:
- name: test-container
image: gcr.io/google_containers/busybox
command: ["/bin/sh", "-c", "ls /etc/config"]
volumeMounts:
- name: config-volume
mountPath: /etc/config
volumes:
- name: config-volume
configMap:
name: no-config
optional: true # mark the source ConfigMap as optional
restartPolicy: Never
Pod specification में reference करने से पहले आपको ConfigMap object बनाना होगा।वैकल्पिक रूप से, Pod spec में ConfigMap reference को optional चिह्नित करें (देखेंOptional ConfigMaps)। अगर आप ऐसे ConfigMap को reference करते हैं जो मौजूद नहीं है
और reference को optional नहीं चिह्नित करते, तो Pod शुरू नहीं होगा। इसी तरह ConfigMap में
मौजूद न रहने वाली keys के references भी Pod को शुरू होने से रोकेंगे, जब तक कि आप key references
को optional चिह्नित न करें।
अगर आप ConfigMaps से environment variables परिभाषित करने के लिए envFrom उपयोग करते हैं, तो
invalid मानी जाने वाली keys skip कर दी जाती हैं। pod शुरू हो जाएगा, लेकिन invalid names event log(InvalidVariableNames) में रिकॉर्ड किए जाएंगे। log message हर skipped key की सूची देता है।उदाहरण के लिए:
kubectl get events
आउटपुट कुछ इस तरह होगा:
LASTSEEN FIRSTSEEN COUNT NAME KIND SUBOBJECT TYPE REASON SOURCE MESSAGE
0s 0s 1 dapi-test-pod Pod Warning InvalidEnvironmentVariableNames {kubelet, 127.0.0.1} Keys [1badkey, 2alsobad] from the EnvFrom configMap default/myconfig were skipped since they are considered invalid environment variable names.
ConfigMaps किसी विशेष Namespace में रहते हैं।Pods केवल उसी namespace के ConfigMaps को refer कर सकते हैं जिसमें वह Pod मौजूद है।
आप ConfigMaps का उपयोग static pods के लिए नहीं कर सकते, क्योंकि kubelet इसका समर्थन नहीं करता।
आपके बनाए हुए ConfigMaps और Pods हटाएं:
kubectl delete configmaps/game-config configmaps/game-config-2 configmaps/game-config-3 \
configmaps/game-config-env-file
kubectl delete pod dapi-test-pod --now
# You might already have removed the next set
kubectl delete configmaps/special-config configmaps/env-config
kubectl delete configmap -l 'game-config in (config-4,config-5)'
ConfigMap generate करने के लिए उपयोग की गई kustomization.yaml फ़ाइल हटाएं:
rm kustomization.yaml
अगर आपने configure-pod-container नाम की डायरेक्टरी बनाई थी और अब उसकी ज़रूरत नहीं है, तो उसे भी हटाएँ
या उसे trash / deleted files location में ले जाएँ।
rm -r configure-pod-container
Kubernetes, Pod Security Standards को लागू करने के लिए एक built-in admission controller प्रदान करता है।आप इस admission controller को cluster-wide defaults औरexemptions सेट करने के लिए कॉन्फ़िगर कर सकते हैं।
Kubernetes v1.22 में alpha release के बाद,Pod Security Admission Kubernetes v1.23 में beta रूप में default रूप से उपलब्ध हुआ।version 1.25 से आगे, Pod Security Admission सामान्य रूप से उपलब्ध (generally available) है।
संस्करण की जांच करने के लिए, लिखें kubectl version.
अगर आप Kubernetes 1.35 नहीं चला रहे हैं, तो आप इस पेज का वह documentation version चुन सकते हैं जो आपके चल रहे Kubernetes version से मेल खाता है।
pod-security.admission.config.k8s.io/v1 configuration के लिए v1.25+ आवश्यक है।v1.23 और v1.24 के लिए v1beta1 उपयोग करें।v1.22 के लिए v1alpha1 उपयोग करें।apiVersion: apiserver.config.k8s.io/v1
kind: AdmissionConfiguration
plugins:
- name: PodSecurity
configuration:
apiVersion: pod-security.admission.config.k8s.io/v1 # see compatibility note
kind: PodSecurityConfiguration
# Defaults applied when a mode label is not set.
#
# Level label values must be one of:
# - "privileged" (default)
# - "baseline"
# - "restricted"
#
# Version label values must be one of:
# - "latest" (default)
# - specific version like "v1.35"
defaults:
enforce: "privileged"
enforce-version: "latest"
audit: "privileged"
audit-version: "latest"
warn: "privileged"
warn-version: "latest"
exemptions:
# Array of authenticated usernames to exempt.
usernames: []
# Array of runtime class names to exempt.
runtimeClasses: []
# Array of namespaces to exempt.
namespaces: []
--admission-control-config-file के माध्यम से specify करना होगा।Namespaces को label करके Pod Security Standards लागू किए जा सकते हैं।तीन policiesprivileged (प्रिविलेज्ड), baseline (बेसलाइन) और restricted सुरक्षा स्पेक्ट्रम को व्यापक रूप से कवर करती हैं और इन्हें Pod Security admission controller द्वारा लागू किया जाता है।
Pod Security Admission Kubernetes v1.23 में beta रूप में default रूप से उपलब्ध था।version 1.25 से आगे, Pod Security Admission सामान्य रूप से उपलब्ध (generally available) है।
संस्करण की जांच करने के लिए, लिखें kubectl version.
baseline Pod Security Standard अनिवार्य करनायह manifest my-baseline-namespace नाम का Namespace परिभाषित करता है, जो:
baseline policy requirements पूरी नहीं करते।restricted policy requirements पूरी नहीं करते।baseline और restricted policies के versions को v1.35 पर pin करता है।apiVersion: v1
kind: Namespace
metadata:
name: my-baseline-namespace
labels:
pod-security.kubernetes.io/enforce: baseline
pod-security.kubernetes.io/enforce-version: v1.35
# We are setting these to our _desired_ `enforce` level.
pod-security.kubernetes.io/audit: restricted
pod-security.kubernetes.io/audit-version: v1.35
pod-security.kubernetes.io/warn: restricted
pod-security.kubernetes.io/warn-version: v1.35
kubectl label के साथ मौजूदा namespaces में labels जोड़ेंenforce policy (या version) label जोड़ा या बदला जाता है, admission plugin namespace के
हर pod को नई policy के विरुद्ध test करता है। उल्लंघन user को warnings के रूप में लौटाए जाते हैं।namespaces के लिए security profile changes का प्रारंभिक मूल्यांकन करते समय --dry-run flag लगाना उपयोगी होता है।Pod Security Standard checks dry run mode में भी चलेंगी, जिससे आपको यह जानकारी मिलेगी
कि नई policy मौजूदा pods को कैसे treat करेगी, बिना वास्तव में policy अपडेट किए।
kubectl label --dry-run=server --overwrite ns --all \
pod-security.kubernetes.io/enforce=baseline
अगर आप Pod Security Standards के साथ शुरुआत कर रहे हैं, तो एक उपयुक्त पहला कदम यह होगा कि
सभी namespaces में baseline जैसे अधिक सख्त स्तर के लिए audit annotations कॉन्फ़िगर करें:
kubectl label --overwrite ns --all \
pod-security.kubernetes.io/audit=baseline \
pod-security.kubernetes.io/warn=baseline
ध्यान दें कि यह enforce level सेट नहीं कर रहा है, ताकि जिन namespaces का स्पष्ट रूप से मूल्यांकन नहीं हुआ है उन्हें अलग पहचाना जा सके। आप explicit enforce level के बिना namespaces को इस कमांड से सूचीबद्ध कर सकते हैं:
kubectl get namespaces --selector='!pod-security.kubernetes.io/enforce'
आप किसी specific namespace को भी अपडेट कर सकते हैं। यह कमांड my-existing-namespace मेंenforce=restricted policy जोड़ती है, और restricted policy version को
v1.35 पर pin करती है।
kubectl label --overwrite ns my-existing-namespace \
pod-security.kubernetes.io/enforce=restricted \
pod-security.kubernetes.io/enforce-version=v1.35